[noname123]

I'm 27, used to be in tech like the biggest nerd of them all. But not anymore, frankly I'm tired of all of the changes that happened in the industry - it's not that I'm tired of learning but it's that the changes lack substance. Learning a new framework that does the same thing like layout or user design; it's not like learning music and digging into a deeper discipline like moving from acoustic strumming to jazz improvisation, it's just learning new keywords to do the same crap because the old keywords have been remapped.

I'm reminded by a writing blog, like writers of popular fiction, programmers aren't creating technology anymore but we are simply selling a idea (e.g., Martha Stewart for home furnishings flash sales sites, fear of missing out for Facebook/Instagram, diversion or outlet for teenage aggression/frustration for iPhone games) that validates a user's idea that is wrapped around technology. Hence, tech trends surrounds consumer tech instead of system programming now and new web frameworks sprouts by the day that emphasize shaving the man-hours of a routine set of mundane tasks down by a fraction of an hour for the benefit of the agile burn-down chart.

This is not meant to be depressing nor cynical comment but a liberating one for me. Too often, I or I have witnessed a lot of my mostly younger peers try to reconcile the art and commerce, or to put in blunt way, have our cake and eat it too. I see that as a cowardice or indecisive but perhaps necessary stage in one's journey of growth, not to commit yourself and not to express your personal values through the imperfect tradeoff's and limited circumstances of a finite professional life - but be swayed by the arbitrary trinkets that one's professional guild assigns and equating its idea of worth to your self worth.

VB/Pythonistas/Rails/Node.js I've seen them come and go like names on the Billboards charts moving to VH1's "Behind the Music/Where are They Now?". I'm convinced now that you have two routes in this business, 1) make your programming craft secondary to the development of your domain expertise, so learn finance, SEO or sales whatever is the main objective of your business, 2) make your programming craft your domain business and work at companies where their business is the software.

[matwood]

I reminded a co-worker last week as he was figuring out whether to use Grunt or Gulp - Computers aren't the thing. They're the thing that gets us to the thing. - Quoted from Halt and Catch Fire.

Photography has its own version of the same quote. Amateurs worry about equipment, Professionals worry about time, Masters worry about light.

User do not care about the technology used, they care about results.

[noname123]

Same thing bro with musicians, "Amateurs are gear-heads, pro's worry about techniques, and masters tries to listen to the sound"; traders/gamblers, "Amateurs focus on their winning, pro's worry about preserving their capital and masters worry about executing their performance where losing and winning money is only a side effect," and ad infinitum.

[sanderjd]

Reminds me of the Freaks and Geeks episode where he goes to a drumming audition and gets made fun of a bit for his enormous kit before completely bombing.

[eru]

And in war, strategy, logistics, capability.

[xorcist]

They may come and go in the small bubble of blogs you read, but the real world works very differently.

Heck, I work with Perl on a regular basis. Not for some amateur web pages but for real, important, back end stuff. What matters is that the code is solid, not how many new blogs are started on the subject.

Remember that the ones who get things done in the world does not blog about it. No blogs chronicled how they chose dynamic frameworks for the first version of Google. Because they didn't. They whipped out their editor and compiler and went to work.

[agentultra]

> Remember that the ones who get things done in the world does not blog about it.

Perhaps not necessarily true. I don't blog as often as I used to but I still get things done. The act of writing helps to strengthen and reinforce good ideas and train one to recognize them in the future. Publicly or privately matters little... but some of us do "blog."

[sanderjd]

I think your parent's language was a bit inflammatory, but I like the reminder that not everybody doing interesting things is blogging and tweeting about it. Lots of people just work.

[eru]

> Learning a new framework that does the same thing like layout or user design; it's not like learning music and digging into a deeper discipline like moving from acoustic strumming to jazz improvisation, it's just learning new keywords to do the same crap because the old keywords have been remapped.

Perhaps you should look into Haskell, Clojure or Erlang for a change?

[retroencabulato]

I love HN. In response to a complaint about learning new frameworks, you suggest three other alternatives.

[WickyNilliams]

They are all languages (not frameworks), which are valid analogies to the guitar metaphor. They are so different from your usual C-like languages that they will be challenging to learn (and likely fun also)

[mercer]

I think the difference is not just that these are languages rather than frameworks, but also that each of these teach you different skills and approaches by their nature (that aren't 'new', so clearly have a stood the test of time).

[CmonDev]

All but one are profoundly old, yet making a come back.

[eru]

Haskell is from the 80s. Erlang is also pretty old, and Clojure is a Lisp, the second oldest programming language around. Which is the `but one'?

[CmonDev]

If you put it this way, Clojure is old too I guess.

[eru]

Though to be honest, Lisp has come a long way since the 50s.

[doktrin]

In the context of web applications, what do Haskell or Clojure bring to the table that makes them worth the learning curve?

[eru]

In the context of noname123's post they bring interesting learning to the table: they are not more of the same with renamed keywords. To quote,

> [...] it's not like learning music and digging into a deeper discipline like moving from acoustic strumming to jazz improvisation, it's just learning new keywords to do the same crap because the old keywords have been remapped.

Haskell _is_ digging deeper into the discipline.

I am sure one can make good arguments for some of the Haskell and Clojure frameworks for web applications. Alas, I am not qualified. I only used Haskell professionally for embedded development, and for rapid desktop application development, but I've never done web development seriously.

In any case, the Haskell answer for web development will probably include what all Haskell advocacy ever includes: purity and the strong static typing.

[chrisdew]

How do you Haskell on embedded systems? Are you talking about baremetal with 1-32K SRAM?

[sanderjd]

To take this thread yet further into self-parody, you might like Rust; it borrows some interesting stuff from Haskell (or really, the ML family), but is actively targeting embedded systems.

Edit: Also, I have heard that Ocaml can be made to work pretty nicely in an embedded environment.

[eru]

You can make OCaml (and Haskell) run on Xen, no need for a full blown operating system. (Not sure if that counts for anything.) The OCaml project for that is called mirage.

[eru]

No, not nearly that baremetal. I was talking about control processes running in dom0 of xen. They are embedded in the sense that there are `no user serviceable parts'.

(I just looked up embedded software on Wikipedia; it seems like the traditional use of the term is very different to how I used it here. Please pardon the confusion.)

[Ixiaus]

Ignoring the joy of writing software with much more powerful abstractions for a moment (Python, Ruby, JS, PHP all look like jalopies now compared to Haskell) out has very real industrial benefits:

Write software faster with fewer bugs, easier to maintain down the road because the "mental model" is maintained in the types by the compiler, it's more succinct, it's fast, some of the world's brightest computer scientists work on it, and so on...

[doktrin]

Thanks for your response. I'd like to dive a little deeper into the basis for these claims. My current stance is that there isn't sufficient reason to adopt Haskell for use in production.

> Write software faster with fewer bugs

Is there an evidentiary basis for the 'fewer bugs' claim? What type of software are people writing faster with Haskell?

>> easier to maintain down the road because the "mental model" is maintained in the types by the compiler

That seems fair.

>> it's more succinct, it's fast

In isolation, that's a bit hand wavy IMO.

>> some of the world's brightest computer scientists work on it

This is something I hear quite often from the Haskell community in particular. It may or may not be true, but it gets repeated far too often IMHO. It feels like a bit of an appeal to authority.

[eru]

>> Write software faster with fewer bugs > Is there an evidentiary basis for the 'fewer bugs' claim? What type of software are people writing faster with Haskell?

http://donsbot.wordpress.com/2007/05/01/roll-your-own-window... and especially http://donsbot.wordpress.com/2007/05/17/roll-your-own-window... give a good introduction into the mindset behind programming in Haskell.

The latter focusses on zippers. Zippers solve the problem of having a connection and a `cursor' into that connection to mark one element--in the case of XMonad we mark the window that has focus.

In C you would probably solve this with an array and an int. Unfortunately, the compiler can't help ensure that your int always points into the array, and that deleting and inserting are doing the right thing. Zippers help here.

[Ixiaus]

Interesting you should ask for more verification of my claim to fewer bugs because I'm about to embark on using Haskell in the new startup I'm working for and they may require stronger reasoning than I have been providing.

I've been thinking about how to qualify the claim logically or maybe quantify it. Anywho, aside from that I can tell you that the vast majority of bugs I introduce into my Python code (or other languages) are caught by GHC - these are bugs that purely have to do with my inability to remember what something is or is doing, or fear of refactoring something, or some tangled mess of types that are harder to reason about in Python because they're in my head instead of encoded in Haskell.

I've discovered that when I've been able to compile my Haskell programs the bugs I find in them are usually business logic bugs now. Occasionally I'll make use of QuickCheck / HUnit for automated property testing and unit testing, and that will help catch those business logic bugs.

Very subjective and anecdotal but I can promise you that the experience is very real.

> In isolation, that's a bit hand wavy IMO.

Sure, but if you take into account Haskell's denotational semantics vs. other language's operational semantics it should be pretty clear that Haskell inherits Mathematic's idiom for succinct expression. That idiom also informed the language designers when building Haskell's grammar and syntax, it's very flexible and abstract - both in the essence of the language (it's semantics) and its modality.

When reading idiomatic Haskell, there's a lot of information packed into a line, conceptually and syntactically.

> This is something I hear quite often from the Haskell community...

Sure, it probably borders on it, but in many ways other language communities commit the bandwagon fallacy (Go is one) - so I think you can poke holes all over the place. The fact though that proof proving systems and dependently typed languages like Agda and Idris (which are the future and I think will supplant Haskell unless Haskell can evolve) are being written in Haskell which speaks to the level of intellect and forward thinking in the community.

[59nadir]

> Ignoring the joy of writing software with much more powerful abstractions for a moment (Python, Ruby, JS, PHP all look like jalopies now compared to Haskell)

Just out of curiosity: Which abstractions are we talking about here that Haskell doesn't have? OO?

[Ixiaus]

I didn't write that sentence very well if that's how it was interpreted, sorry. I meant to say that the abstractions available to Haskell are more powerful.

I can't really think of any abstraction that's not available to it - even an Object System is possible in Haskell, it just wouldn't be as easy to use as Monads are.

[eru]

> I can't really think of any abstraction that's not available to it [...]

Dependent typing doesn't work very well in Haskell (yet).

[dasil003]

I believe he meant Haskell's abstractions are more powerful.