4 ms·

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

by 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"

by zengid 8y ago

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"