Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I learned Haskell in just 15 years

duckrabbit.tech

Post reply on HN
Print view View original

201–210 of 240 posts

Re: I learned Haskell in just 15 years

#201

Post by nextaccountic »

bspammer wrote: post #118
empath75 wrote: post #90

Earlier quoted context omitted.

I was a college dropout and self taught bash and python programmer and quite some time ago, I read about Haskell, decided to teach myself to use it, and then realized I had absolutely no idea what programming actually was, and basically spent the next 15 years teaching myself computer science, category theory, abstract algebra and so on, so that I could finally understand Haskell code. I still don't understand Haskel…

I think that's a good starting definition for programmers, but still could cause confusion when you run into something like IO in Haskell. IO isn't really a data structure, and it's hard to fit the "flat map" concept to it.

If you want you can still keep this point of view, by saying that IO is conceptually a data structure that builds a description of what the program does. In this point of view it follows that there is another, impure program that interprets the IO data structure and actually performs the computations

(Of course in practice IO isn't implemented like this, because it would be too slow)

(But in every other language, like Javascript or Python, you can define IO as a data structure. Or even in Haskell itself, you can define for eg. a free monad that gets interpreted later, and it can be made to be just as good as IO itself, though typically people make it less powerful than IO)

However note that every other "computational" monad (like the list monad or the Cont monad) actually is a data structure, even though they describe effects just like IO does. This is because IO is the only possible exception to the "monads are data structures" thing in Haskell (if you don't subscribe to the above view), because Haskell doesn't let you define types that aren't data structures

The only issue with this point of view is that you now need to say what flatMap means for things that are not shaped like arrays. Eg. does it make intuitive sense to flatMap a tree? (A retort is that it must make sense, whatever you call this operation; and flattening a tree means to turn a tree of trees into an one-level tree)

Re: I learned Haskell in just 15 years

#202

Post by jiiam »

whytevuhuni wrote: post #199
jiiam wrote: post #180

Earlier quoted context omitted.

Just to give a different pov I find Haskell very intuitive, and particularly I find that code written by other people is very easy to understand (compared to Java or TypeScript at least). And by the way x and x' are totally fine names for a value of a very generic type (or even a very specific type depending on the circumstances), as long as the types and the functions are decently named. I mean, how else would you c…

> I mean, how else would you call the arguments of > splitAt :: Eq a => a -> [a] -> [[a]] Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely. I spent a good 2 minutes looking at that signature trying to figure it out (and I've read some Haskell tutorials so I'm at least familiar with the syntax). This would've helped: def split_by (separator: T, list: List[T]) -> Li…

> Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely.

The rest of the definition is at the end, to see it as a whole:

  splitAt :: Eq a => a -> [a] -> [[a]]

  splitAt x xs = ...
To clarify, I assumed that by using the constraint `Eq a` and the name splitAt there was no need for extra clarification in the names of the parameters but apparently I was wrong.

Re: I learned Haskell in just 15 years

#203

Post by nextaccountic »

IshKebab wrote: post #182
fire_lake wrote: post #35

Earlier quoted context omitted.

Is Haskell pure? It has exceptions You can divide by zero It has unsafe IO primitives

It is pure in the same way that Rust is memory safe. That is too say there are a tiny number of exceptions/escape hatches, but they are not meant to be the norm. Every day programming doesn't involve them. Exceptions aren't impure anyway.

Exceptions define an effect. Code with exceptions aren't actually pure in the sense that their return type doesn't fully describe what the code does, so it doesn't just map an input into an output: there is something else going on

In some pure functional languages, the pure fragment doesn't have exceptions, and you add exceptions as an effect (or as a monad)

(If you reify the effect with a type like Either or Result, then the code becomes pure: but that's just a monad like said above)

Re: I learned Haskell in just 15 years

#204

Post by nextaccountic »

IshKebab wrote: post #182
fire_lake wrote: post #35

Earlier quoted context omitted.

Is Haskell pure? It has exceptions You can divide by zero It has unsafe IO primitives

It is pure in the same way that Rust is memory safe. That is too say there are a tiny number of exceptions/escape hatches, but they are not meant to be the norm. Every day programming doesn't involve them. Exceptions aren't impure anyway.

Anyway I really like the take that Haskell is pure in the same sense that Rust is safe

Haskell has impure constructs but sets you up to define referentially transparent abstractions with them, and this is actually valued by the Haskell community

Re: I learned Haskell in just 15 years

#205

Post by crabbone »

neonsunset wrote: post #148
crabbone wrote: post #144

Earlier quoted context omitted.

Where are you getting your info from? Typical OCaml programs, when compared to similar C++ would be slower but use less memory. F# and Scala are both OCaml in disuse. I don't know what you mean by "reasonable"... but, if the idea is "easy to reason about", then these two don't particularly stand out much. Languages that are easy to reason about would be generally in the category where you need to do fewer translation…

Heh, no. You are suggesting to replace FP languages with powerful type systems that perform marginally slower than C# and Java (and can access their ecosystems) with a language that is dynamically typed and performs, in most situations, marginally slower than PHP and marginally faster than Ruby.

Every language is both statically and dynamically typed. But the more correct way of saying this is "dynamically or statically checked". Types don't appear or disappear when a program runs. The difference is in what can be known about types and at what stage.

What programmers actually care about is this:

How can we check more and sooner in a way that requires less mental energy on the side of the programmer to write?

In other words, we have three variables we want to optimize for: how much is checked, how much is checked before execution, how much effort does it take to write the check. When people argue for "statically or dynamically typed languages", they generally don't understand what they argue for (or against), as they don't have this kind of mental model in mind (they just learned the terms w/o clear understanding of what they mean).

And so do you.

So, I don't really know what do you mean when you say "dynamically typed". Which language is that? Are you talking about Erlang? SML? What aspect of the language are you trying to describe?

NB. I don't think either C# or Java have good type systems. My particular problem with these is subtyping, which is also a problem in OCaml and derivatives s.a. Scala or F#. It's not a solution anyone wanted, it's a kludge that was added into these systems to deal with classes and objects. So, if we are going after good type systems... well, it wouldn't be in any language with objects, that's for sure.

NB2. Unix Shell has a great type system. Everything is a string. It's a pleasure to work with, and you don't even need a type checker! For its domain, it seems like a perfect compromise between the three optimization objectives.

Re: I learned Haskell in just 15 years

#206

Post by crabbone »

agentultra wrote: post #155
crabbone wrote: post #129

Earlier quoted context omitted.

> I still don't understand Haskell It's not you. Haskell has very bad syntax. It's not hard to understand it, it you rewrite the same things in something saner. Haskell was developed by people who enjoy one-liners and don't really need to write practical programs. Another aspect of Haskell is that it was written by people who were so misguided as to think that mathematical formulas are somehow superior to typical imp…

You knew Paul Hudak, Simon Peyton Jones, Phil Wadler, etc? Were they thinking about the benefits of mathematical formulas over program counters and procedural keywords when designing Haskell? I was under the impression from the History of Haskell [0] that they were interested in unifying research into lazy evaluation of functional programming languages. > This makes no sense, and is, in fact, very harmful when writin…

You don't need to know the author personally to appreciate the result of their work...

> Gosh, what am I doing with my life?

I would ask the same question, but unironically. No, you didn't make up those programs of course. I didn't claim that real-world programs are impossible to write in Haskell. I claimed that Haskell is a bad tool for writing real-world programs. People make sub-optimal decisions all the time. That's just human nature... choosing Haskell for any program that would require debugging, long-term maintenance, cross-platform UI, or plenty of other desirable properties is just a very bad choice. But people like you do it anyways!

Why? -- there are plenty of possible answers. If I wanted to look for the flattering answers, I'd say that a lot of experienced and talented programmers like Haskell. So, choosing to write in Haskell for that reason isn't such a bad idea. But, if I wanted to judge Haskell on its engineering rather than social merits: it has very little to bring to the table.

Re: I learned Haskell in just 15 years

#207

Post by crabbone »

nequo wrote: post #187
crabbone wrote: post #176

Earlier quoted context omitted.

Well, MS didn't have to do anything. It's enough that they have (or had) the opportunity to do something. There isn't an Overmind in MS that in a creepy voice tells you to spawn more overlords. Less than that, there doesn't need to be a written document that tells you to give money to MS or your data etc. There's just a general accepted understanding among the people who run that company that ends justify the means.…

Do you also suspect homicidal money making motives behind Z3, Lean, and F*? It seems more likely to me that they just want some useful knowledge out of these projects that they can integrate into a product that actually sells.

I have a misfortune to know personally some of the mid-to-high level execs from MS. What I write is based on the experience of working with these people. And I don't even know what Z3, Lean or F* are, so, pardon my ignorance, but I cannot answer your question.

Re: I learned Haskell in just 15 years

#208

Post by crabbone »

bmoxb wrote: post #183
crabbone wrote: post #126

Earlier quoted context omitted.

I would recommend neither of those. Haskell has very bad syntax (with extensive backing from Microsoft, iirc the guy who writes the compiler is a Microsoft's Research employee). F# is a straight-up Microsoft's language. It doesn't matter what other benefits it has. Just don't touch anything created by that company, and you will have one fewer regrets in your life. But, if you still want a language from that category:…

What's wrong with Haskell's syntax? I think it's generally pretty nice though can be excessively terse at times.

* Significant white space, and the rules around whitespace are very convoluted.

* There's no pattern or regularity to how infix / prefix / suffix operators are used which makes splitting program text into self-contained sub-programs virtually impossible if you don't know the exact behavior, including priority of each operator.

* There's a tradition of exceptionally bad names for variables, inherited from the realm of mathematical formulas. In mathematics, it's desirable to give variables names devoid of everyday meaning to emphasize the generic nature of the idea being expressed. This works in the context of very short formulas, but breaks entirely in the context of programs which are usually many orders of magnitude bigger than even the largest formula you've ever seen. There, having meaningful names is a life west.

* It's impossible to make a good debugger for Haskell because of the language being "lazy". Debuggers are essential tools that help programmers in understanding the behavior of their programs. Haskell programmers are forced to rely on their imagination when explaining to themselves how their program works.

* Excessive flexibility. For example, a Haskell programmer may decide to overload string literals (or any literals for that matter). This is orders of magnitude worse than eg. overloading operators in C++, which is criticizes for defying expectations of the reader.

One of these points would've been enough for me to make the experience of working with a language unpleasant. All of them combined is a lot more than unpleasant.

Re: I learned Haskell in just 15 years

#209

Post by tome »

crabbone wrote: post #206
agentultra wrote: post #155

Earlier quoted context omitted.

You knew Paul Hudak, Simon Peyton Jones, Phil Wadler, etc? Were they thinking about the benefits of mathematical formulas over program counters and procedural keywords when designing Haskell? I was under the impression from the History of Haskell [0] that they were interested in unifying research into lazy evaluation of functional programming languages. > This makes no sense, and is, in fact, very harmful when writin…

You don't need to know the author personally to appreciate the result of their work... > Gosh, what am I doing with my life? I would ask the same question, but unironically. No, you didn't make up those programs of course. I didn't claim that real-world programs are impossible to write in Haskell. I claimed that Haskell is a bad tool for writing real-world programs. People make sub-optimal decisions all the time. Tha…

Strange. In my experience Haskell is the best language for long-term maintainability! I can actually come back to code I've written years ago and understand what it does. I've never experience that with another language.

Re: I learned Haskell in just 15 years

#210

Post by cess11 »

usgroup wrote: post #191
cess11 wrote: post #189

Earlier quoted context omitted.

I don't know, most things I've written in Prolog 'runs backwards'. Doesn't seem special to me, things like cut and whatnot that might interfere do. I kind of feel that clpfd, clpz and so on are just libraries, in what way do you consider them extensions to the language? For me it's a neat way to model problems, and when I have I've commonly learned something new about the problem domain. Performance might not be grea…

In SWI for example, clpfd and friends rely on attribute values and hook predicates to interject the backtracking process with their own thing. SWI provides those things so that it can be extended. Non trivial Prolog programs which only use pure predicates and do not use cut are sparse. Yet those are also the only circumstances in which things like clpfd will work without special consideration.

Besides pengines and web development I have very little experience with SWI specifically.

And, well, yeah, it's common (e.g. look for cuts in https://github.com/mthom/scryer-prolog/blob/master/src/lib/c... ), but I don't think I've ever written a cut and I use Prolog rather effectively as a tool for problem solving. It's an interesting and quite powerful way to model and examine problems even if I don't produce programs with 'imperative' interfaces. Some scripting tasks are also quite easy in Prolog, e.g. certain log parsing, stuff like that.

Post reply on HN