,
33 tweets,
8 min read
Read on Twitter
Recently someone asked me what I liked about Haskell and if I thought it was the best language. I said I liked it, but it wasn't the best. The gist of it was this tweet by @DRMacIver. (thread)
I like Haskell because it lets me build larger systems, more easily, and with less hassle, than any other lang I've used. It feels much more solid in the hand, like a quality hammer, compared to eg Python, which to me feels fragile, and cheap. I'll put more confidence in Haskell.
Haskell solves pretty much all issues that arise for small to medium sized projects and many that arise for large and very large projects. This is unlike Python/Java/C/PHP/Bash/C#/Scala which have issues at all scales. (I will collectively call them Python#++)
As we look at ever larger Haskell codebases, while Haskell allows us to work with them orders of magnitude better than any language I have used, and while it guards us from outright bugs and errors, beginning some size it still starts to yield inelegant, or cumbersome solutions.
My thesis was that if you compare issues you get in large Python#++ projects and take away all the issues that happen because Python#++ isn't a very good language, then Haskell still retains a lot of the issues that remain.
Haskell is really great for day to day programming tasks, solving nearly all you can throw at it in elegant, succinct code. It is so good that it pushes the issues it has in common with Python#++ far, far away, towards when the code base is very large; under the rug.
I think all the decades^W centuries spent on formal methods, type systems, &c are ultimately just incremental improvements upon the issues of Python#++. They're genius, and crucial going forward, but real flaws run much deeper.
Abstraction alone is a flawed base for programming.
Abstraction alone is a flawed base for programming.
To fix programming, we should revisit the basic questions of conveying ideas.
I think the solution is in the study of the mind itself: psychology, sociology, philosophy, pedagogy, andragogy, and human-related parts of linguistics, game theory, systems design, and other sciences.
I think the solution is in the study of the mind itself: psychology, sociology, philosophy, pedagogy, andragogy, and human-related parts of linguistics, game theory, systems design, and other sciences.
I remember saying that Haskell can't be the ultimate solution to bugs and software engineering because you won't see a PL designer pick up a dozen psychology or philosophy books.
A good solution can only come once programmers have decades of insight into psychology and the mind.
A good solution can only come once programmers have decades of insight into psychology and the mind.
Here's a good example: the subset of Python#++ known as PHP has a bunch of functions like mysql_escape_string, mysqli_escape_string, mysql_real_escape_string, mysqli_real_escape_string.
A linguist, pedagogue, or psychologist would tell you such similar names are easily confused.
A linguist, pedagogue, or psychologist would tell you such similar names are easily confused.
You can only use one PHP mysql escaping function, all others are bad and allow exploits. But psychology tells us that in this situation it's like knowing which of four identical red buttons to press. So which one do you press? Not so fast...
The human aspects of game theory study human behavior and outcomes. A Schelling point is the concept of the most likely choice one makes. It's our nature to assume the right PHP function has "mysql" and "escape" in it and we get four of these. So is the trick to not confuse them?
In Python#++/PHP, the right choice is not the obvious one, but a combination of the prepare, execute, and fetchAll (but not fetch) methods of a PDO object. This is really unexpected, unless you know the catch-22.
A career in programming is a sad life of collecting catch-22s.
A career in programming is a sad life of collecting catch-22s.
Code: You came looking for a red button and found four huge, identical red buttons, but the right action is to unscrew a lit bulb, flip a switch hidden under the table, turn a crank 5 times (but not 4 or 6), and pull the chain that blows the steam whistle. _You should know that_.
This is kind of idiotic, and you can easily say that Haskell solves many of those issues. We don't have 4 wrong functions for mysql, and if there's a bug we choose safety and break compat. But the quality is only incidental and hinges on discipline and experience; we lack method.
You want to do stream IO in Haskell. What do you use? conduit? pipes? streaming? machines? Arrow? iteratee? iterIO? enumerator? liboleg? io-streams? You are now confronted with not four, but ten!!! red buttons, and you don't really know that any one of them is the right choice.
If you go to the docs of any one, they exist in blissful ignorance of the others. There is a hard to find wiki page somewhere, covered in two fingers of dust, which lists them, and doesn't help you choose. The trivial problem of choice remains unsolved.
You could easily imagine a *sociological* solution to this: you subscribe to a prominent coder's curation. When your build system sees you use a package over which he prefers another, it could show you a warning, and include his explanation. But... no one here studies sociology.
Conway's Law is a theorem from sociology, of prominent impact in software, by Mel Conway / @conways_law: "program module boundaries follow societal bounds of teams". Deep insight into software engineering. Just you wait til you read a book on sociology, it'll blow your mind.
We build a rose tree by writing all the same code as in a binary tree, and replacing pairs with lists. For us, a "rose tree" = "binary tree where pair -> list". But we keep the compiler in the dark. It thinks they're two totally unrelated code bases. They're now prone to diverge.
We have two things which we believe are similar, but the compiler is happy to have them do wildly different things. We make wrong assumptions, and get bugs. Our solution is to make a single rose-or-binary-or-redblack-or-kitchensink tree. Our solution to bugs is more complexity.
Computer science has taken a single concept from philosophy - abstraction - and made every problem a nail for this hammer. What if we could just say "RoseTree = BinaryTree where Pair -> List"?
This is how we reason and learn: by analogy, not abstraction. And it's possible.
This is how we reason and learn: by analogy, not abstraction. And it's possible.
Analogies and abstractions are just two ideas that make software better. If this is your sort of thing, philosophy is for you. It has more than two concepts.
Programmers are all just bad philosophers.
Just you wait til you get to Wittgenstein, he has some heavy ideas for you:
Programmers are all just bad philosophers.
Just you wait til you get to Wittgenstein, he has some heavy ideas for you:
The limits of my language mean the limits of my world - Wittgenstein
Philosophy is a battle against the bewitchment of our intelligence by means of language - also Wittgenstein
the harmony between thought and reality is to be found in the grammar of the language - Wittgenstein
Philosophy is a battle against the bewitchment of our intelligence by means of language - also Wittgenstein
the harmony between thought and reality is to be found in the grammar of the language - Wittgenstein
Nothing is as difficult as not deceiving oneself - Wittgenstein
Logic must look after itself - Wittgenstein too
His considerations obviously have deep connections to *and* impact on programming. Just wait til you find out there are other philosophers.
Logic must look after itself - Wittgenstein too
His considerations obviously have deep connections to *and* impact on programming. Just wait til you find out there are other philosophers.
The issue of four red buttons is studied in psychology. It spawned UX design. The military tests control panels for validity by making soldiers sit in a dark rotating room with strobe lights and loud noises and making them perform complex scenarios. Failure means redesign.
Microservices are great not because of Docker, AWS or the cloud, but because they are unwittingly a direct implementation of Mel Conway's law. They let teams explicitly define boundaries and work within their comfort zones. Conway's Law is the only reason Amazon hasn't imploded.
The inability to discover a path from mysql_escape_string to PDO makes it clear why we need blogs or @codinghorror's and @spolsky's StackOverflow. They're ways for veterans to communicate in stories.
Coding is a sequel to Darmok.
We should study this. Make stories a PL feature.
Coding is a sequel to Darmok.
We should study this. Make stories a PL feature.
The ability to formally subscribe to some coder or entity's coding practices could be great. You could get to use their favorite libraries, their preferred lint rules, their idioms, and read their thoughts on coding, all in your dev env, prompted by your code. Social programming.
This is a really good way to put it!
Oh yea I always thought this was php's One Good Thing!
Sun Microsystems cofounder Vinod Khosla (@vkhosla): “Little of (..) Liberal Arts programs today is relevant to the future.”
I don't think that's right, Vinod. For the hardest tech to grow they're crucial, in a direct, non-bs way. See rest of thread.
hbr.org/2017/07/libera…
I don't think that's right, Vinod. For the hardest tech to grow they're crucial, in a direct, non-bs way. See rest of thread.
hbr.org/2017/07/libera…
