9 ms·

I'm reminded of one of my favourite HN comments on Haskell: 'There's something very seductive about languages like Rust or Scala or Haskell or even C++. These

by hhmc 8y ago

I'm reminded of one of my favourite HN comments on Haskell: 'There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen.' https://news.ycombinator.com/item?id=7962612 https://news.ycombinator.com/item?id=7962612 Although it's not 100% applicable in this case (unless you argue that the cost is to your own time) - I think the sentiment is perfect.

village-idiot 8y ago
Oh yeah, as I mentioned in another comment, this is me. The result is that I have a bunch of 20% finished Haskell projects, and a bunch of finished Rails projects that accomplish the exact same task.
zengid 8y ago
I think Rich Hickey described it pretty well when he said (paraphrasing from [0]) that static languages present the programmer with neat little puzzles to solve that feels like we're writing applications but we're just creating intricate types and abstractions. I think he has a point, but I certainly don't want to give up the benefits of static languages, like being able to catch all of my silly errors. [0] https://youtu.be/2V1FtfBDsLU?t=39m44s https://youtu.be/2V1FtfBDsLU?t=39m44s
- acdha 8y ago
  I think a key part is never losing track of the real goal so you can remind yourself what percentage of your time is going to things which anyone who isn’t a developer on your project would care about.
- codebje 8y ago
  His argument begs the question. If you pre-suppose that describing types and finding appropriate abstractions aren't "writing applications", that is, they offer no value in the process, then spending time doing them is of course solving neat little puzzles to no benefit. On the other hand, if you pre-suppose that types and abstractions offer some value to the process of writing an application, then solving those puzzles is adding value. Calling types and abstractions a "neat little puzzle" is a diminution we could apply to other aspects of writing an application: implementing an algorithm to correctly process some data is a neat little puzzle presented by our test cases. Rich Hickey would need to demonstrate the lack of value of types and abstractions for producing applications to make a solid argument here, and that I believe is a steep uphill battle, because Clojure would be a pretty terrible language if you took out the ISeq abstraction, and there's an awful lot of effort spent shifting the puzzle of "is this function being used right" from the type system game engine to the test harness game engine.
  - rictic 8y ago
    Time spent with a type system buys you compiler-checked proofs of some properties. The important question is whether the time is worth the benefit. One of many things that I love about the TypeScript type system is that it gives so much power to the author. It is the most expressive industrial type system I know of, but it also makes it easy for the programmer to say "I can't prove that this is true, just trust me that it is". A nice side benefit is that this is also practice, so you can also gain skill. This is how I justify sometimes spending much more time with the type system than it would otherwise be worth when learning a new language or hacking on a personal project.
    - lmm 8y ago
      > One of many things that I love about the TypeScript type system is that it gives so much power to the author. It is the most expressive industrial type system I know of, but it also makes it easy for the programmer to say "I can't prove that this is true, just trust me that it is". I really wanted to like Typescript, but once you're thinking in HKT it's incredibly frustrating to have to manually translate a function into its flattened expansion (just like it's incredibly frustrating to use a type system without generics once you've used one that has generics). Every serious industrial language allows a programmer to say "I can't prove that this is true, just trust me that it is"; I suspect many people who struggle to start out in Haskell would do well to make a little more use of unsafeCoerce and unsafePerformIO (they would no doubt give themselves runtime errors, but sometimes the easiest way to understand why you had a type error is to run the code and see what the values are at runtime). (I made a small hobby tool with ScalaJS and was amazed how easy it was, so I'll be advocating for that over Typescript).
  - snaky 8y ago
    And most often the most beneficial is to spend more time on the problem and its domain, brilliantly illustrated in this comment https://news.ycombinator.com/item?id=17906700 https://news.ycombinator.com/item?id=17906700
- cynicalkane 8y ago
  Former Clojure programmer here. I eventually learned I'd rather write neat little puzzles about static types than solve frustrating little puzzles on the root causes of runtime exceptions.
- api 8y ago
  Go is static but doesn't encourage this. The more experienced I've become the less I find myself doing this in languages like C++ either. It's seductive until you start getting excited more about higher order reasoning about algorithms and about what programs really accomplish and less about just showing off. A breakthrough program written in some uncool language like VB.NET is more impressive to me than yet another ________ written in Haskell or Rust with perfect abstractions.
- tokyodude 8y ago
  I agree but I feel like the fact that it's a puzzle is a sign the language could be improved. Describing generic types shouldn't have to look like stl's or boost's implementation details. They are nightmares of "neat puzzle solving"
chongli 8y ago
The blank canvas analogy is a good one but for the wrong reason. Think of the aspiring novelist with a blank stack of paper in front of them. The problem is not the freedom they have, it's their lack of discipline. It's far easier to write PR for an agency or injury reports for a sports blog than it is to write a novel. The reason so many programmers struggle with this problem is because nobody is paying them to write CRUD applications in Haskell. If they were, they'd find it more than adequate to the task and the job would be easy and painless. People only go down rabbit holes when they don't have a manager breathing down their neck all day. It takes real discipline to create really good hobby projects on your own, regardless of language.
- taeric 8y ago
  Better than a manager, is a customer. Though, any stakeholder is probably better than none, which I believe is your main point. (And one I agree with.)
  - anonytrary 8y ago
    I've always found interacting with clients to more satisfying than interacting with a manager. Managers have a probability of feeling like unnecessary middlemen, which presents a conundrum because they are your manager.
- tomxor 8y ago
  > People only go down rabbit holes when they don't have a manager breathing down their neck all day. It takes real discipline to create really good hobby projects on your own, regardless of language. I agree, but perhaps discipline is not necessarily complete restraint... I think some rabbit holes are worth exploring, they can separate outstanding projects from mediocrity. Perhaps it's about choosing the right rabbit holes in the right projects, another way of achieving that is minimalism where you limit the scope and not the depth.
  - namibj 8y ago
    Or you just fail due to your own miss-management more than just once, and learn that structure is not for the boss but for you, yourself. Happens more often when the style of abstraction is restricted for performance reasons (i.e., no java-like OO and so) and you fall on something like buffer mismatch like I once did (to e fair, it was a bug that repeatably depended on the presence of explicit synchronization calls and there was no documentation about that possibly changing anything).
vmchale 8y ago
> 'There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen.' Do they? I think the Haskell community online is pretty crappy for this and other reasons, but GHC/Haskell are at their best when you actually use them to write programs instead of doing things like this.
workleg 8y ago
There's something very seductive about a chance to comment on posts like this one for a particular group of people. These posts whisper in your ears "the fact that you've had a hard time and failed to understand, learn and harness these exotic languages does not mean that you are not brilliant. Here's a blank canvas for you to convince others of same, perpetuating the perspective convenient to your ego, which got bruised by the hard task in the past" (all in good humor) Jokes aside, I code professionally Haskell every day all day long. I'm very productive and get more productive and love the language more every day. It's all about realistic expectations and commitment (just like anything that's hard). You cannot expect to learn and be productive in Haskell within a week/month or even a year. You need a lot of patience and dedication, but you will be rewarded, that i can promise.

by hhmc 8y ago

village-idiot 8y ago

Oh yeah, as I mentioned in another comment, this is me. The result is that I have a bunch of 20% finished Haskell projects, and a bunch of finished Rails projects that accomplish the exact same task.

zengid 8y ago

I think Rich Hickey described it pretty well when he said (paraphrasing from [0]) that static languages present the programmer with neat little puzzles to solve that feels like we're writing applications but we're just creating intricate types and abstractions. I think he has a point, but I certainly don't want to give up the benefits of static languages, like being able to catch all of my silly errors. [0] https://youtu.be/2V1FtfBDsLU?t=39m44s https://youtu.be/2V1FtfBDsLU?t=39m44s

acdha 8y ago
I think a key part is never losing track of the real goal so you can remind yourself what percentage of your time is going to things which anyone who isn’t a developer on your project would care about.
codebje 8y ago
His argument begs the question. If you pre-suppose that describing types and finding appropriate abstractions aren't "writing applications", that is, they offer no value in the process, then spending time doing them is of course solving neat little puzzles to no benefit. On the other hand, if you pre-suppose that types and abstractions offer some value to the process of writing an application, then solving those puzzles is adding value. Calling types and abstractions a "neat little puzzle" is a diminution we could apply to other aspects of writing an application: implementing an algorithm to correctly process some data is a neat little puzzle presented by our test cases. Rich Hickey would need to demonstrate the lack of value of types and abstractions for producing applications to make a solid argument here, and that I believe is a steep uphill battle, because Clojure would be a pretty terrible language if you took out the ISeq abstraction, and there's an awful lot of effort spent shifting the puzzle of "is this function being used right" from the type system game engine to the test harness game engine.
- rictic 8y ago
  Time spent with a type system buys you compiler-checked proofs of some properties. The important question is whether the time is worth the benefit. One of many things that I love about the TypeScript type system is that it gives so much power to the author. It is the most expressive industrial type system I know of, but it also makes it easy for the programmer to say "I can't prove that this is true, just trust me that it is". A nice side benefit is that this is also practice, so you can also gain skill. This is how I justify sometimes spending much more time with the type system than it would otherwise be worth when learning a new language or hacking on a personal project.
  - lmm 8y ago
    > One of many things that I love about the TypeScript type system is that it gives so much power to the author. It is the most expressive industrial type system I know of, but it also makes it easy for the programmer to say "I can't prove that this is true, just trust me that it is". I really wanted to like Typescript, but once you're thinking in HKT it's incredibly frustrating to have to manually translate a function into its flattened expansion (just like it's incredibly frustrating to use a type system without generics once you've used one that has generics). Every serious industrial language allows a programmer to say "I can't prove that this is true, just trust me that it is"; I suspect many people who struggle to start out in Haskell would do well to make a little more use of unsafeCoerce and unsafePerformIO (they would no doubt give themselves runtime errors, but sometimes the easiest way to understand why you had a type error is to run the code and see what the values are at runtime). (I made a small hobby tool with ScalaJS and was amazed how easy it was, so I'll be advocating for that over Typescript).
- snaky 8y ago
  And most often the most beneficial is to spend more time on the problem and its domain, brilliantly illustrated in this comment https://news.ycombinator.com/item?id=17906700 https://news.ycombinator.com/item?id=17906700
cynicalkane 8y ago
Former Clojure programmer here. I eventually learned I'd rather write neat little puzzles about static types than solve frustrating little puzzles on the root causes of runtime exceptions.
api 8y ago
Go is static but doesn't encourage this. The more experienced I've become the less I find myself doing this in languages like C++ either. It's seductive until you start getting excited more about higher order reasoning about algorithms and about what programs really accomplish and less about just showing off. A breakthrough program written in some uncool language like VB.NET is more impressive to me than yet another ________ written in Haskell or Rust with perfect abstractions.
tokyodude 8y ago
I agree but I feel like the fact that it's a puzzle is a sign the language could be improved. Describing generic types shouldn't have to look like stl's or boost's implementation details. They are nightmares of "neat puzzle solving"

chongli 8y ago

The blank canvas analogy is a good one but for the wrong reason. Think of the aspiring novelist with a blank stack of paper in front of them. The problem is not the freedom they have, it's their lack of discipline. It's far easier to write PR for an agency or injury reports for a sports blog than it is to write a novel. The reason so many programmers struggle with this problem is because nobody is paying them to write CRUD applications in Haskell. If they were, they'd find it more than adequate to the task and the job would be easy and painless. People only go down rabbit holes when they don't have a manager breathing down their neck all day. It takes real discipline to create really good hobby projects on your own, regardless of language.

taeric 8y ago
Better than a manager, is a customer. Though, any stakeholder is probably better than none, which I believe is your main point. (And one I agree with.)
- anonytrary 8y ago
  I've always found interacting with clients to more satisfying than interacting with a manager. Managers have a probability of feeling like unnecessary middlemen, which presents a conundrum because they are your manager.
tomxor 8y ago
> People only go down rabbit holes when they don't have a manager breathing down their neck all day. It takes real discipline to create really good hobby projects on your own, regardless of language. I agree, but perhaps discipline is not necessarily complete restraint... I think some rabbit holes are worth exploring, they can separate outstanding projects from mediocrity. Perhaps it's about choosing the right rabbit holes in the right projects, another way of achieving that is minimalism where you limit the scope and not the depth.
- namibj 8y ago
  Or you just fail due to your own miss-management more than just once, and learn that structure is not for the boss but for you, yourself. Happens more often when the style of abstraction is restricted for performance reasons (i.e., no java-like OO and so) and you fall on something like buffer mismatch like I once did (to e fair, it was a bug that repeatably depended on the presence of explicit synchronization calls and there was no documentation about that possibly changing anything).

vmchale 8y ago

> 'There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen.' Do they? I think the Haskell community online is pretty crappy for this and other reasons, but GHC/Haskell are at their best when you actually use them to write programs instead of doing things like this.

workleg 8y ago

There's something very seductive about a chance to comment on posts like this one for a particular group of people. These posts whisper in your ears "the fact that you've had a hard time and failed to understand, learn and harness these exotic languages does not mean that you are not brilliant. Here's a blank canvas for you to convince others of same, perpetuating the perspective convenient to your ego, which got bruised by the hard task in the past" (all in good humor) Jokes aside, I code professionally Haskell every day all day long. I'm very productive and get more productive and love the language more every day. It's all about realistic expectations and commitment (just like anything that's hard). You cannot expect to learn and be productive in Haskell within a week/month or even a year. You need a lot of patience and dedication, but you will be rewarded, that i can promise.