Comment by aaron-lebo | Hacker News Reader

Comment by aaron-lebo | Hacker News Reader

Parent Full thread

There's probably some truth to this. My mathy friends have a deep appreciation of Haskell. I always try to get into it for a few weeks, marvel at it, grok some new things, then inevitably end up in more "practical" languages (only because there are almost no domains, save parsers and compilers, where Haskell is obviously the "best" fit).

This may describe why: Haskell it built for the sake of itself, it's coherence, it's design. It is first and foremost designed to do things the Haskell way, which may be conceptually pure and "right" but aren't necessarily the most straightforward. In contrast, most other languages exist to solve a problem C++ (performance and control), PHP (a templating language for the web), Python (web, data science), JS (browser), etc. This being my understanding/paraphrasing of what the author is saying.

I think the answer is somewhere in the middle: the good parts of Haskell, selected for pragmatism (strict instead lazy like most languages), with an emphasis on being approachable to users. There's a lot of languages that are almost there. Elm gets the ease of use but strips too many features. OCaml is practical but has std lib split, multicore issues, and is kind of crufty. Go is arguably too simple, Rust is too low-level, Kotlin is almost there but the JVM can't replace languages that can produce straight binaries for the most part. Nim is very easy to write in a functional style and is maybe the most practical language I've ever used. It lacks the support, libraries, and mindshare of the others, though.

What kind of worries me is there is a strong incentive for languages to promulgate themselves into domains they aren't especially suited for, so it's more likely that one of these flawed languages will be Frankensteined into a domain it doesn't really belong and we'll be hacking around those disadvantages in a couple decades. Maybe the real answer is to take a step back and consider what is a middle ground that gets 90-95% of what anybody needs. I'm not convinced that something like Nim or a new language couldn't be 99%, with the 1% of the time being necessary to drop into domain specific languages. If one of the big corps put support and funding into the "right" language, it's not really a difficult job, but it is those damn incentives. How do you fix them?

Regarding other languages out there, I'm gradually starting to appreciate what has been accomplished with Swift. I did not like it at first, and the new version 4 of the language is much improved over the first a few years ago. But the algebraic data types that are pervasive in the language, and the versatile and type-checked pattern matching, and the familiar functional toolset with first class functions, map, filter, etc, and the widespread use of value types over object references, there are a lot of things there that come from other languages, and most importantly, it's a highly practical language for getting real work done on billions of devices. I'd like to see Swift adopted elsewhere other than just Linux and Apple platforms, as I think it has a lot to offer, some great compromises.

Middle ground. Compromise. You're looking at language diversity with the assumption that it's a problem. No corp, no matter how powerful, could make the be-all-end-all language because a language isn't a tool; it's the culture around the tool.

Imagine you have three teams of hackers, each composed of die-hard devotees of a language: C++, Rust, and PHP. You task each team with building a program to the same spec, in C++. You already know what to expect, don't you? The PHP bunch will finish first, with a program that works probably well enough. The Rust gang will make something frighteningly safe, that doesn't use any memory. 10 years later the C++ folks are still writing clever templates.

Different languages are good at different things not just because of the strengths and weaknesses of the language itself, but because a language has an associated worldview, and different worldviews lend themselves to different goals. Within hackerdom there are many communities adapted to different ideological ecosystems.

In a future with one "perfect" language, where would you go when safety was the only thing that mattered? You'd have to find some old geezer who cut her teeth on Ada, before the Programming Cultural Revolution.

> Maybe the real answer is to take a step back and consider what is a middle ground that gets 90-95% of what anybody needs.

I call this "pragmaticaly typed language", but should just call it "a pragmatic language"

Actually the same could be said about Python and the Python way, pythonic programs, etc.

The thing about the Python way is it is dogmatic but it is also very practical: it's dogmatic about being practical. For loops and list comprehensions are more familiar or easily explainable to many programmers, so Guido kind of hid map/filter/reduce instead of leaning on them or having alternatives like other languages (Cloure or JS).

I've got friends who I'm not sure can read that are able to understand Python. Haskell isn't like that.

Fun thing - list comprehensions could be seen as map/filter and so on but they could also be seen as syntax sugar for monads:

     [ x + y
      for x in xs
      for y in ys]

     foo = do
         x <- xs
         y <- ys
         return (x + y)

Just that this is overloaded in haskell so that it works with lists but also as async/await, as the `?` operator that propagates errors in rust and so on.

So maybe it isn't the basic concepts of haskell that are hard to get but that they are so general.

Haskell aims for simplicity. That is favoring the reader/maintainer of code over the writer. It’s a different trade off that is not obviously worse.

I don't really consider Haskell an example of simplicity, I consider something like Elm or Go simple. Haskell is...correct?

But this is a problem with these discussions because my definition is different than yours and they could both be argued to be correct. Is this like Hickey's easy vs simple? Is my definition incorrect?

I meant it in the objective sense of information theoretic complexity. I’m not sure what other measurements would be objective in comparison.

Is there any research which shows that Haskell is superior in terms of information theoretic complexity.?

I'm not familiar with the term. The only thing I can find it in reference to Haskell is this:

https://en.wikibooks.org/wiki/Haskell/Algorithm_complexity

which isn't really related to this:

That is favoring the reader/maintainer of code over the writer.

What material is there which shows that Haskell is simple in terms of information theoretic complexity and superior to other languages (not?) designed for that?

Being more rigid about semantics and formalization of program meaning means that it is a simpler process to answer queries about what a certain piece of code does vs an alternative “pragmatic” language that is riddled with exceptions and lacks a strong type system.

If your job is to take a piece of code written by someone else and either fix a bug or add a feature, it is objectively easier to do when you have strong guarantees about input types and format, exceptions generated, referential transparency, side effects, execution model, etc.

You also get shorter programs and simpler programs in the algorithmic complexity sense when you have strong first class features for modularity, interface definition, and constrained polymorphism.

Haskell has all of these properties as good and often better than “production” languages, and has since the 90’s. Haskell is objectively better on all counts.

However what matters is not objective truths but subjective realities. Haskell is also “different” in a way that is only endearing to mathematicians and CS theorists (which are really the same in the extremes). You can hire someone and train them on Haskell, but it’ll take much time and money to get them to similar comfort levels, and not everyone is willing. And with Rust, which carries over many of Haskell’s benefits to the imperative world, you can get 80% of the benefit for 20% of the cost. So why bother?

If I had a time machine though, I think code dropping Haskell 98 back prior to the invention of FORTRAN would have put us in a much more desirable alternative history. One where code mostly works as advertised, security is based on proofs of correctness not boxing, requirements and intentions are more clear and explicit, etc. Too bad we live in the world we do.

Two of the core tennents of Python is: simple is better than complex and code is read much more often than it is written.

It amazes me that someone could write down that principle and then design an untyped programming language.

Dynamic types can be more problematic to modify, but many of us find them easier to read: assume that the code actually worked and does something reasonable, now skim for the gist of it (without having to see a bunch of extra detail).

Assembler is untyped (just bytes and words). I'm not big into Python, but I'm pretty sure it has types, but they are late/runtime bound.

Dynamic types are probably not a good choice for an army of idiots, but if dynamic types were so completely unworkable, you would think that they would disappear, eh?

That said, I'd rather see avionics written in Ada than Python, but not every problem needs that level of scrutiny and pain.

> assume that the code actually worked and does something reasonable

That's almost never the case if you're in a situation where you're reading code

Why is dynamic typing (with reliance on duck typing) any harder to read, or more complex?

    def add(a, b):
        return a + b

In a dynamically-typed language, you can't actually know if this dead-simple function will throw an exception, until you know the entire call graph leading up to where this function was called. That's fine in small scripts, but really freakin hard if you have call-stacks 10 levels deep.

Sure, but it is both exceedingly readable and exceedingly simple. It is pretty much pseudocode. Which is what we are discussing, not type safety in huge codebases.

Thats true in small functions, but that's also true for statically-typed languages with type inference. In OCaml, the same function would also be

    let add x y = x + y

Looks reasonable to me, and this is statically type-checked

If I were making an argument in this case, I'd say that several other languages have fulfilled the "readability" benefit while also fulfilling orders of magnitude higher performance and type safety garuantees. This implicates that one case is write only instant legacy code and the other will be highly maintainable going forward if the codebase and team need to scale in size.

Sure. That doesn’t mean it achieves those goals very well.

Could you give a few examples of good parts about Haskell and why do you believe they are good for anybody?

I think Haskell's view of the world with types is basically right. Pattern matching, algebraic datatypes, typeclasses, powerful and usable functions, and immutability (by default) are a great way of reasoning about code. Add the other common aspects of functional programming (map) and you have a very lean and expressive core. Haskell also has a lot of really cool and crazy stuff related to parallelism/concurrency, which are at least partially possible/easy because of aspects like immutability (Erlang/Elixir show this, too).

http://chimera.labs.oreilly.com/books/1230000000929/index.ht...

To be honest I'm extrapolating a bit; my experience in static typing is mostly in other languages and my experience with functional programming is mostly in Elixir/Clojure, but a mix of the two in my book is the most bang for the buck you'll find. But as a disclaimer, ....I'm acting like I know what I'm talking about, these are just my feelings from working with some of these languages off and on. Haskellers can answer this much better than me.

Reply on news.ycombinator.com