6 ms·

As someone who thinks that more advanced type systems and proof-carrying-code are some of the biggest advances in theoretical computer science and practical pr

As someone who thinks that more advanced type systems and proof-carrying-code are some of the biggest advances in theoretical computer science and practical programming in the last few decades, but also is a C# compiler developer, I have also noticed this. Haskell is really interesting, but C# developers get shit done. I'm not sure what the cause is, but it definitely gnaws at me.

pnathan 12y ago
> C# developers get shit done. Yes, and that says a lot about the final quality too, no? We could say the same about Perl/PHP/Java/C++ and then we're sitting in the same horrible morass we live in today, because people settle for minimally bad code produced as fast as possible. Good, cheap, fast. Pick 2. Almost invariably: Cheap+fast are the picked results.
- pron 12y ago
  > and then we're sitting in the same horrible morass we live in today But you see, this is the claim that requires substantial evidence. Let's assume we're in a mess. If Haskell is one way out of it, as some people claim, why won't they show us the way? They've had more than 20 years to do it. There are enough Haskell developers out there to give us this pesky evidence we need. And yet we've seen absolutely none. There are way more impressive BASIC programs out there than Haskell programs. I think that there are two reasons for that: 1) People involved in PL research are less interested in programs that aren't compilers, and 2) languages like Haskell make certain tradeoffs that their designers fail to see, and as a result their advantages fall way short of the claims they make.
  - pnathan 12y ago
    I don't even understand your question. My internet is filled with half-baked webapps with bad errors and riddled with stupid security vulnerabilities, many of which can be defined to not occur in an adequately designed tech stack. Desktop programs work through dint of manpower, crufty testing environments, and users-as-QA. What exactly are you looking for? Web app frameworks? they exist. database connectors? they exist. mathematical proofs relating to correctness? they exist, in abundance. data structures arcane and common? they exist. regex libs? they exist. Sophisticated programs running sophisticated systems? They exist, and you won't hear about them except as a rumor on message boards... If you mean, "is there going to be a big marketing campaign to make me and my manager feel comfortable"... I doubt it.
    - pron 12y ago
      > Sophisticated programs running sophisticated systems? They exist Not really. Well, far less than in all those horrible, unusable languages. All I'm saying is, if Haskell makes writing correct code so easy, where is it? There should be tons of it now. It should be practically everywhere. In fact, it should be financially stupid to do anything in any language other than Haskell. So where are all the companies making a fortune by betting on Haskell?
      - pnathan 12y ago
        You're arguing from perfection. The reality is that most companies choose "fast+cheap" and usually incur significant technical debt which is paid off through throwing bodies at the problem. It is usually considered better to hire 3 people who are mediocre than 1 person who is very skilled. This is extremely well addressed in the software engineering literature going back to the late 60s. It's also the case that software engineering is very conservative: "Don't change ANYTHING" is the default state of the industry with regards to practices.
        Locke1689 12y ago
        I don't buy this either. If this were true you'd still see, for lack of a better term, the "redis" of Haskell. You can't argue that antirez skimped on development or that he isn't talented enough. Where is the redis of Haskell? The ffmpeg of ML? There's something else at play here.
        pnathan 12y ago
        I think the simple answer is that a lot of problems people consider useful are intellectually not terribly interesting. Among other things, if it's been done before, the cool factor drops off a good deal. e.g., I run a tutorial site for common lisp. One request has been for 'example of web framework'. At some point, I'll do it (it's useful), but my heart at the moment is in implementing an extensible indexing system for n-dimensional tuples. It's a good deal more esoteric and a lot more fun than screwing with http/html.
  - dangirsh 12y ago
    Show me a BASIC program as impressive as any of: - Elm's Time Travelling Debugger: http://debug.elm-lang.org/ http://debug.elm-lang.org/ - Pandoc: https://github.com/jgm/pandoc https://github.com/jgm/pandoc - XMonad: http://xmonad.org/ http://xmonad.org/ - (GHC, should really count)
- platz 12y ago
  It's interesting. There's so much more C# code out there, but I wonder about the lifetime of that code, and when it will be swept under the rug (i.e. if javascript eats the enterprise). Haskell seems to disseminate ideas rather than code. It even disseminated LINQ into C#. Perhaps this makes the lack of volume of production Haskell code less stinging because it has contributed to languages in other ways? There's kind of an upside to this as well, because Haskell isn't entrenched in industry, it's still free to make changes and grow the language (i.e. Applicative becomes superclass of Monad), although this gap may be starting to slowly close with the recent popularity.
- yongjik 12y ago
  More often than not, it is: Good, existent, fast. Pick 2.
nostrademons 12y ago
It's not a good thing - for production software - for a language to be too much fun to use. It means that developers spend all their time using the language and not enough time solving problems. The suckiness of Java/C# tends to encourage people to solve their problem and move on quickly to the next problem, because it's honestly not much fun trying to extend the language or build abstractions. Haskell & Lisp programmers, however, can spend hours constructing utility libraries, DSLs, and custom monads to solve their problem elegantly, and as a result they have extremely elegant source code that nobody but themselves will ever read, a library of utilities that they will probably not use again, and a solved problem that took 4 hours while the hacky Java solution took an hour.
- Dewie 12y ago
  Then I guess that Emacs users never get any work done? ;) (I wouldn't know, but I would be surprised if that was the case)
  - nostrademons 12y ago
    The average emacs user I know doesn't actually know or write Elisp, they just grab preconfigured .el files off the Internet or corporate intranet and add the appropriate snippets to their .emacs. Elisp gurus, in my experience, don't get all that much work done, other than writing lots of editor extensions. This is great if their job is writing editor extensions, less great if their job is something else. It's the same as with compiler writers: they're great at making other people more productive, but when it comes to writing end-user software, not so much. In general, of course - there are exceptions.
- rurban 12y ago
  Nonsense. A high-level language developer uses the higher concepts to get more work done, in better ways, and less time. Hacks always strike back, sooner or later.
- spoiler 12y ago
  I disagree with these premises. I find Ruby, C[0] and Go really fun. The reason I get shit done is because they are so fun! I can't wait to do something else in them! Also, the elegant utility library code that took four hours to write can—and likely will—be reused, and save you hours upon hours. Meanwhile, the Java hacker will always have +1 hour of coding, because he never learns. [0]: I realise calling C fun is weird, but I enjoy writing C code, and it's my guilty pleasure, I guess.
bsg75 12y ago
> Haskell is really interesting, but C# developers get shit done. > I'm not sure what the cause is, but it definitely gnaws at me. Stuff that people are willing to pay for, which can be a very important concept for many (if not most) of us.
Guvante 12y ago
> I'm not sure what the cause is, but it definitely gnaws at me. My theory is that it is because that is what we teach. If you go to school you learn Java (which is basically C#) and if you learn a language on your own most people recommend Java/C# because it will get you a job. By extension we end up with the vast majority of coders knowing Java/C#, thus most code gets written that way.
- Periodic 12y ago
  I think many experienced programmers forget how hard it was to write good code in the first place, whatever abstraction they started to use. I "learned" Java and C++ very quickly. I'm sure I was banging out code and stopped looking up most things within weeks. However, it took me years to actually understand how to write good code in those languages. I had to learn the patterns, I had to learn where the short-cuts and sharp edges were. I had to learn what features to avoid and which ones to embrace. It took a long time, but now it's all habit and instinct. I don't even have to think about it. Asking someone to switch to using a new paradigm—like moving from OOP to FP—is asking them to relearn how to structure a program. All those habits and instincts no longer apply and new ones need to be learned. It takes years to learn how to write good high-quality FP programs. I know I'm still learning and I first picked up Haskell as a primary hobby four years ago. It probably took me a year before I really understood what a monad was and could apply that abstraction, similar to how long it took me to really understand and apply things like visitor patterns. I believe that if you took an entirely untrained person you could get them to be at least as productive if you taught them with FP versus OOP from the start.
pron 12y ago
> I'm not sure what the cause is, but it definitely gnaws at me. Here's my hypothesis: programming language are made for people to use, and people spending time thinking about designing Watson, don't want to spend it thinking about expressing their program using lambda calculus. The only group for whom the stuff they develop coincides with language concepts are those writing compilers. So they get confused because their domain is the programming language, so they don't feel like they're spending their mind power on two different things. They can't imagine that someone trying to solve a tricky scheduling problem wouldn't want to spend time thinking about types. The other group that can adopt languages like Haskell are those whose domain doesn't require too much thought: namely CRUD applications. These guys want to spend time thinking about type-driven-design. It might actually make their code quality better. They, too, can't understand why people solving a hard concurrent-data-structure problem wouldn't want to spend time thinking about expressing their ideas elegantly through types. Both of these groups have one thing in common: expendable energy to spend thinking about programming language concepts. So to them, it seems easy; and it probably is, if you're willing to put some effort into it, which is precisely what many developers don't want to do.
- Locke1689 12y ago
  Or, in other words, advanced languages have some cognitive overhead that people working on extraordinarily complex applications can't spare? Maybe. Then again, I've been using C++ again recently and I feel like the cognitive overhead there is so huge that I can barely understand my simple programs. Nonetheless, Microsoft pretty much runs on C++ (and C#).
  - spoiler 12y ago
    I've started recently working in and properly learning C++ (most because I hoped the OO model would suit me over C). Sometimes, I get so frustrated by how weird the syntax can get (the templates always confuse me to the point I have to stop and slowly read the code before I get its meaning)!
  - pron 12y ago
    It's not so much that they can't but that they won't. And the same people don't use C++'s confusing features (crazy template stuff) either. But the problem isn't just the cognitive overhead inherent to the language, but that of the switching cost. As I said in another comment, while Haskell certainly has some advantages, they don't easily overcome the switching cost. People writing compilers happily pay the cognitive price for the switch because that's their core business, while those doing CRUD apps can certainly afford the price.
zem 12y ago
this is a thought-provoking article on the subject: http://prog21.dadgum.com/21.html http://prog21.dadgum.com/21.html

pnathan 12y ago

> C# developers get shit done. Yes, and that says a lot about the final quality too, no? We could say the same about Perl/PHP/Java/C++ and then we're sitting in the same horrible morass we live in today, because people settle for minimally bad code produced as fast as possible. Good, cheap, fast. Pick 2. Almost invariably: Cheap+fast are the picked results.

pron 12y ago
> and then we're sitting in the same horrible morass we live in today But you see, this is the claim that requires substantial evidence. Let's assume we're in a mess. If Haskell is one way out of it, as some people claim, why won't they show us the way? They've had more than 20 years to do it. There are enough Haskell developers out there to give us this pesky evidence we need. And yet we've seen absolutely none. There are way more impressive BASIC programs out there than Haskell programs. I think that there are two reasons for that: 1) People involved in PL research are less interested in programs that aren't compilers, and 2) languages like Haskell make certain tradeoffs that their designers fail to see, and as a result their advantages fall way short of the claims they make.
- pnathan 12y ago
  I don't even understand your question. My internet is filled with half-baked webapps with bad errors and riddled with stupid security vulnerabilities, many of which can be defined to not occur in an adequately designed tech stack. Desktop programs work through dint of manpower, crufty testing environments, and users-as-QA. What exactly are you looking for? Web app frameworks? they exist. database connectors? they exist. mathematical proofs relating to correctness? they exist, in abundance. data structures arcane and common? they exist. regex libs? they exist. Sophisticated programs running sophisticated systems? They exist, and you won't hear about them except as a rumor on message boards... If you mean, "is there going to be a big marketing campaign to make me and my manager feel comfortable"... I doubt it.
  - pron 12y ago
    > Sophisticated programs running sophisticated systems? They exist Not really. Well, far less than in all those horrible, unusable languages. All I'm saying is, if Haskell makes writing correct code so easy, where is it? There should be tons of it now. It should be practically everywhere. In fact, it should be financially stupid to do anything in any language other than Haskell. So where are all the companies making a fortune by betting on Haskell?
    - pnathan 12y ago
      You're arguing from perfection. The reality is that most companies choose "fast+cheap" and usually incur significant technical debt which is paid off through throwing bodies at the problem. It is usually considered better to hire 3 people who are mediocre than 1 person who is very skilled. This is extremely well addressed in the software engineering literature going back to the late 60s. It's also the case that software engineering is very conservative: "Don't change ANYTHING" is the default state of the industry with regards to practices.
      - Locke1689 12y ago
        I don't buy this either. If this were true you'd still see, for lack of a better term, the "redis" of Haskell. You can't argue that antirez skimped on development or that he isn't talented enough. Where is the redis of Haskell? The ffmpeg of ML? There's something else at play here.
        pnathan 12y ago
        I think the simple answer is that a lot of problems people consider useful are intellectually not terribly interesting. Among other things, if it's been done before, the cool factor drops off a good deal. e.g., I run a tutorial site for common lisp. One request has been for 'example of web framework'. At some point, I'll do it (it's useful), but my heart at the moment is in implementing an extensible indexing system for n-dimensional tuples. It's a good deal more esoteric and a lot more fun than screwing with http/html.
- dangirsh 12y ago
  Show me a BASIC program as impressive as any of: - Elm's Time Travelling Debugger: http://debug.elm-lang.org/ http://debug.elm-lang.org/ - Pandoc: https://github.com/jgm/pandoc https://github.com/jgm/pandoc - XMonad: http://xmonad.org/ http://xmonad.org/ - (GHC, should really count)
platz 12y ago
It's interesting. There's so much more C# code out there, but I wonder about the lifetime of that code, and when it will be swept under the rug (i.e. if javascript eats the enterprise). Haskell seems to disseminate ideas rather than code. It even disseminated LINQ into C#. Perhaps this makes the lack of volume of production Haskell code less stinging because it has contributed to languages in other ways? There's kind of an upside to this as well, because Haskell isn't entrenched in industry, it's still free to make changes and grow the language (i.e. Applicative becomes superclass of Monad), although this gap may be starting to slowly close with the recent popularity.
yongjik 12y ago
More often than not, it is: Good, existent, fast. Pick 2.

nostrademons 12y ago

It's not a good thing - for production software - for a language to be too much fun to use. It means that developers spend all their time using the language and not enough time solving problems. The suckiness of Java/C# tends to encourage people to solve their problem and move on quickly to the next problem, because it's honestly not much fun trying to extend the language or build abstractions. Haskell & Lisp programmers, however, can spend hours constructing utility libraries, DSLs, and custom monads to solve their problem elegantly, and as a result they have extremely elegant source code that nobody but themselves will ever read, a library of utilities that they will probably not use again, and a solved problem that took 4 hours while the hacky Java solution took an hour.

Dewie 12y ago
Then I guess that Emacs users never get any work done? ;) (I wouldn't know, but I would be surprised if that was the case)
- nostrademons 12y ago
  The average emacs user I know doesn't actually know or write Elisp, they just grab preconfigured .el files off the Internet or corporate intranet and add the appropriate snippets to their .emacs. Elisp gurus, in my experience, don't get all that much work done, other than writing lots of editor extensions. This is great if their job is writing editor extensions, less great if their job is something else. It's the same as with compiler writers: they're great at making other people more productive, but when it comes to writing end-user software, not so much. In general, of course - there are exceptions.
rurban 12y ago
Nonsense. A high-level language developer uses the higher concepts to get more work done, in better ways, and less time. Hacks always strike back, sooner or later.
spoiler 12y ago
I disagree with these premises. I find Ruby, C[0] and Go really fun. The reason I get shit done is because they are so fun! I can't wait to do something else in them! Also, the elegant utility library code that took four hours to write can—and likely will—be reused, and save you hours upon hours. Meanwhile, the Java hacker will always have +1 hour of coding, because he never learns. [0]: I realise calling C fun is weird, but I enjoy writing C code, and it's my guilty pleasure, I guess.

bsg75 12y ago

> Haskell is really interesting, but C# developers get shit done. > I'm not sure what the cause is, but it definitely gnaws at me. Stuff that people are willing to pay for, which can be a very important concept for many (if not most) of us.

Guvante 12y ago

> I'm not sure what the cause is, but it definitely gnaws at me. My theory is that it is because that is what we teach. If you go to school you learn Java (which is basically C#) and if you learn a language on your own most people recommend Java/C# because it will get you a job. By extension we end up with the vast majority of coders knowing Java/C#, thus most code gets written that way.

Periodic 12y ago
I think many experienced programmers forget how hard it was to write good code in the first place, whatever abstraction they started to use. I "learned" Java and C++ very quickly. I'm sure I was banging out code and stopped looking up most things within weeks. However, it took me years to actually understand how to write good code in those languages. I had to learn the patterns, I had to learn where the short-cuts and sharp edges were. I had to learn what features to avoid and which ones to embrace. It took a long time, but now it's all habit and instinct. I don't even have to think about it. Asking someone to switch to using a new paradigm—like moving from OOP to FP—is asking them to relearn how to structure a program. All those habits and instincts no longer apply and new ones need to be learned. It takes years to learn how to write good high-quality FP programs. I know I'm still learning and I first picked up Haskell as a primary hobby four years ago. It probably took me a year before I really understood what a monad was and could apply that abstraction, similar to how long it took me to really understand and apply things like visitor patterns. I believe that if you took an entirely untrained person you could get them to be at least as productive if you taught them with FP versus OOP from the start.

pron 12y ago

> I'm not sure what the cause is, but it definitely gnaws at me. Here's my hypothesis: programming language are made for people to use, and people spending time thinking about designing Watson, don't want to spend it thinking about expressing their program using lambda calculus. The only group for whom the stuff they develop coincides with language concepts are those writing compilers. So they get confused because their domain is the programming language, so they don't feel like they're spending their mind power on two different things. They can't imagine that someone trying to solve a tricky scheduling problem wouldn't want to spend time thinking about types. The other group that can adopt languages like Haskell are those whose domain doesn't require too much thought: namely CRUD applications. These guys want to spend time thinking about type-driven-design. It might actually make their code quality better. They, too, can't understand why people solving a hard concurrent-data-structure problem wouldn't want to spend time thinking about expressing their ideas elegantly through types. Both of these groups have one thing in common: expendable energy to spend thinking about programming language concepts. So to them, it seems easy; and it probably is, if you're willing to put some effort into it, which is precisely what many developers don't want to do.

Locke1689 12y ago
Or, in other words, advanced languages have some cognitive overhead that people working on extraordinarily complex applications can't spare? Maybe. Then again, I've been using C++ again recently and I feel like the cognitive overhead there is so huge that I can barely understand my simple programs. Nonetheless, Microsoft pretty much runs on C++ (and C#).
- spoiler 12y ago
  I've started recently working in and properly learning C++ (most because I hoped the OO model would suit me over C). Sometimes, I get so frustrated by how weird the syntax can get (the templates always confuse me to the point I have to stop and slowly read the code before I get its meaning)!
- pron 12y ago
  It's not so much that they can't but that they won't. And the same people don't use C++'s confusing features (crazy template stuff) either. But the problem isn't just the cognitive overhead inherent to the language, but that of the switching cost. As I said in another comment, while Haskell certainly has some advantages, they don't easily overcome the switching cost. People writing compilers happily pay the cognitive price for the switch because that's their core business, while those doing CRUD apps can certainly afford the price.

zem 12y ago

this is a thought-provoking article on the subject: http://prog21.dadgum.com/21.html http://prog21.dadgum.com/21.html