5 ms·

On the other hand, I find myself unable to plateau in Haskell, it seems that there is always new abstractions behind the corner. Want to thread exceptions throu

On the other hand, I find myself unable to plateau in Haskell, it seems that there is always new abstractions behind the corner. Want to thread exceptions through your monad transformers? Learn MonadState. Want accessors which do not suck? Learn Lens. And then you have free monads, comonads, Operational, Kleisli arrows, Pipes/Conduits/IO Streams/Iteratees... It may be an issue with the language: make a powerful language, and many things which ought to be part of the core system are going to be in a library. And as Haskell's syntax unfortunately allows library designers to go wild with ASCII symbols, you can easily end up with really hard-to-grok code (especially with the right amount of point-free style). Bonus if you use one-character variables. Unfortunately, in the real world code is read more than it is written, and the prevalent cleverness doesn't really help with that.

lostcolony 13y ago
I'm working to learn Haskell, and that's actually part of the appeal. I don't expect to ever write Haskell in production. Oh, sure, some places do, but they're very, very few; I suspect it's pretty much impossible in any area where you expect to grow, simply because finding people who know it already is nearly impossible, and learning it is difficult, especially as your established crew learns new and more powerful abstractions; the amount of learning required to get someone up to speed gets higher and higher, which is not what you want as you expand. But that said, as a developer even in more approachable languages, learning that cleverness has its benefits. It provides new insights into ways problems can be expressed. Most developers agree on the benefits of learning a new language; you learn a few good ideas, a few paradigms and approaches, that can carry over and affect the way you code in your day to day. Haskell, with its depth, is better still; you have a seemingly neverending set of ideas to learn and draw from. Many, yes, are too clever to see a full implementation elsewhere in production code that has many maintainers. But borrowing even part of an idea expressed in Haskell may lead to a simple, reusable, and concise solution to a problem that otherwise would be an ugly bug riddled one off solution.
- copergi 13y ago
  Your assumptions are not very accurate at all. The job I just left we had moved to haskell precisely for growth. We had no problems hiring haskellers, or having our existing PHP devs learn haskell. The new job I took is getting tons of applications from experienced haskellers. There's tons of people who know haskell and don't get to use it at work. They are generally quite eager to fix that problem.
  - seddona 13y ago
    Can you mention the company? We're interested in using Haskell and I'm looking for reference experiences, particularly use in startups.
  - MetaCosm 13y ago
    cough bullshit cough I meant it in good humor, but over the last 15 years, I have had the joy (and pain) of getting to ship production systems in a lot of less popular stacks including: Erlang (multiple), Eiffel, Haskell, and OCaml. Hiring and training for these less popular stacks has been a goddamn nightmare in "win" conditions. You have the benefit of the better signal to noise ratio in resumes, absolutely. But, you pay for that in rarity, salary and job demands, which is fine as long as you go in eyes wide open and plan to have a small team (under 10). Rapid team growth (from money injection, or simply success and need) is really, really hard when you don't have a large pool of qualified candidates to pull from... and training, I honestly can't fathom trying to train PHP developers in Haskell. If you company has done this successfully, please setup a newsletter, I would subscribe.
    - copergi 13y ago
      >But, you pay for that in rarity, salary and job demands Quite the opposite. As I said, there are a lot of people who know haskell but don't get to use it in their job. There's tons of people applying for haskell jobs at $50-60k/year. Being able to use haskell is a big enough draw in and of itself. >If you company has done this successfully, please setup a newsletter, I would subscribe. There would be nothing to go in it. Haskell is not particularly difficult to learn. People can get up and running doing web development very quickly, without any significant changes to how they normally do things since you don't do much destructive updating in most web apps anyways.
chongli 13y ago
make a powerful language, and many things which ought to be part of the core system are going to be in a library. That's an issue? I would consider it a feature. Core language features which cannot be extended are very frustrating to deal with; just look at generic containers in Go!
- davidw 13y ago
  It was an issue for Tcl and OO systems: http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-... > Somewhat related to the large Tcl vs small Tcl issue was one particular extension, or extensions to the language that was noticeably absent: a system for writing “object oriented” code. Tcl, at heart, will never be an OO language through and through, like Ruby or Smalltalk, but that doesn’t mean that an OO system for it is not a useful way of organizing larger Tcl systems. Indeed, Tcl’s syntax is flexible enough that it’s possible to write an OO system in Tcl itself, or, optimizing for speed, utilizing the extensive C API in order to create new commands. Over the years, a number of such systems have arisen, the most well-known being “Incr Tcl” (a play on the incr command, which is akin to += 1 in languages like C). However, none of these extensions was ever included with the standard Tcl distribution or somehow “blessed” as the official OO system for Tcl. This meant that a newcomer to Tcl wishing to organize their code according to OO principles had to pick a system to use from several competing options. And of course, newcomers are the least able to judge a complex feature like that in a language, making it a doubly stressful choice. Furthermore, even experienced Tcl programmers who wanted to share their code could not utilize an OO system if they wanted their code to work with just standard Tcl. Also, if their code had a dependancy on some OO system, it would require the user to download not only the extension in question, but the OO system it was built on, which, naturally, might conflict with whatever OO system the user had already selected! As of Tcl 8.6, thanks to the work of Donal Fellows, Tcl is finally integrating the building blocks of an OO system in the core itself, but this effort is probably something like 10 years too late.
  - chongli 13y ago
    This is not the same thing. You are talking about language extensions, I am talking about libraries. Features which require language modification/extension in other languages can usually be implemented as ordinary libraries in Haskell.

lostcolony 13y ago

I'm working to learn Haskell, and that's actually part of the appeal. I don't expect to ever write Haskell in production. Oh, sure, some places do, but they're very, very few; I suspect it's pretty much impossible in any area where you expect to grow, simply because finding people who know it already is nearly impossible, and learning it is difficult, especially as your established crew learns new and more powerful abstractions; the amount of learning required to get someone up to speed gets higher and higher, which is not what you want as you expand. But that said, as a developer even in more approachable languages, learning that cleverness has its benefits. It provides new insights into ways problems can be expressed. Most developers agree on the benefits of learning a new language; you learn a few good ideas, a few paradigms and approaches, that can carry over and affect the way you code in your day to day. Haskell, with its depth, is better still; you have a seemingly neverending set of ideas to learn and draw from. Many, yes, are too clever to see a full implementation elsewhere in production code that has many maintainers. But borrowing even part of an idea expressed in Haskell may lead to a simple, reusable, and concise solution to a problem that otherwise would be an ugly bug riddled one off solution.

copergi 13y ago
Your assumptions are not very accurate at all. The job I just left we had moved to haskell precisely for growth. We had no problems hiring haskellers, or having our existing PHP devs learn haskell. The new job I took is getting tons of applications from experienced haskellers. There's tons of people who know haskell and don't get to use it at work. They are generally quite eager to fix that problem.
- seddona 13y ago
  Can you mention the company? We're interested in using Haskell and I'm looking for reference experiences, particularly use in startups.
- MetaCosm 13y ago
  cough bullshit cough I meant it in good humor, but over the last 15 years, I have had the joy (and pain) of getting to ship production systems in a lot of less popular stacks including: Erlang (multiple), Eiffel, Haskell, and OCaml. Hiring and training for these less popular stacks has been a goddamn nightmare in "win" conditions. You have the benefit of the better signal to noise ratio in resumes, absolutely. But, you pay for that in rarity, salary and job demands, which is fine as long as you go in eyes wide open and plan to have a small team (under 10). Rapid team growth (from money injection, or simply success and need) is really, really hard when you don't have a large pool of qualified candidates to pull from... and training, I honestly can't fathom trying to train PHP developers in Haskell. If you company has done this successfully, please setup a newsletter, I would subscribe.
  - copergi 13y ago
    >But, you pay for that in rarity, salary and job demands Quite the opposite. As I said, there are a lot of people who know haskell but don't get to use it in their job. There's tons of people applying for haskell jobs at $50-60k/year. Being able to use haskell is a big enough draw in and of itself. >If you company has done this successfully, please setup a newsletter, I would subscribe. There would be nothing to go in it. Haskell is not particularly difficult to learn. People can get up and running doing web development very quickly, without any significant changes to how they normally do things since you don't do much destructive updating in most web apps anyways.

chongli 13y ago

make a powerful language, and many things which ought to be part of the core system are going to be in a library. That's an issue? I would consider it a feature. Core language features which cannot be extended are very frustrating to deal with; just look at generic containers in Go!

davidw 13y ago
It was an issue for Tcl and OO systems: http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-... > Somewhat related to the large Tcl vs small Tcl issue was one particular extension, or extensions to the language that was noticeably absent: a system for writing “object oriented” code. Tcl, at heart, will never be an OO language through and through, like Ruby or Smalltalk, but that doesn’t mean that an OO system for it is not a useful way of organizing larger Tcl systems. Indeed, Tcl’s syntax is flexible enough that it’s possible to write an OO system in Tcl itself, or, optimizing for speed, utilizing the extensive C API in order to create new commands. Over the years, a number of such systems have arisen, the most well-known being “Incr Tcl” (a play on the incr command, which is akin to += 1 in languages like C). However, none of these extensions was ever included with the standard Tcl distribution or somehow “blessed” as the official OO system for Tcl. This meant that a newcomer to Tcl wishing to organize their code according to OO principles had to pick a system to use from several competing options. And of course, newcomers are the least able to judge a complex feature like that in a language, making it a doubly stressful choice. Furthermore, even experienced Tcl programmers who wanted to share their code could not utilize an OO system if they wanted their code to work with just standard Tcl. Also, if their code had a dependancy on some OO system, it would require the user to download not only the extension in question, but the OO system it was built on, which, naturally, might conflict with whatever OO system the user had already selected! As of Tcl 8.6, thanks to the work of Donal Fellows, Tcl is finally integrating the building blocks of an OO system in the core itself, but this effort is probably something like 10 years too late.
- chongli 13y ago
  This is not the same thing. You are talking about language extensions, I am talking about libraries. Features which require language modification/extension in other languages can usually be implemented as ordinary libraries in Haskell.