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

211–220 of 240 posts

Re: I learned Haskell in just 15 years

#211

Post by agentultra »

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…

I think we can drop the "real-world," qualifier as it is unlikely there is an "imaginary-world" that we write programs for.

What engineering merits did you have in mind?

Re: I learned Haskell in just 15 years

#212

Post by Dylan16807 »

elbear wrote: post #192
Dylan16807 wrote: post #188

Earlier quoted context omitted.

I mean that the identity is unrelated. Yes, you can say they're the same type. But I'm actually passing the same object in. If f evaluated lazily, it could return 2 from both calls. Something like: define f(o): return o.x let a = {x=1} n = f(a) // n is not evaluated yet a.x = 2 m = f(a) return n + m // returns 4

Ok, you're probably proving the point that purity also requires immutability. I'm not sure, as I haven't considered all the implications of Haskell's design. My two rules about inputs and outputs are more like heuristics. They can improve code organisation and probably also decrease the likelihood of some errors, but they don't guarantee correctness, as you're pointing out. They're shortcuts, so they're not perfect.…

Even without laziness, you can get similar problems if f creates a closure or returns something that includes the parameter object.

Re: I learned Haskell in just 15 years

#213

Post by trealira »

Dylan16807 wrote: post #212
elbear wrote: post #192

Earlier quoted context omitted.

Ok, you're probably proving the point that purity also requires immutability. I'm not sure, as I haven't considered all the implications of Haskell's design. My two rules about inputs and outputs are more like heuristics. They can improve code organisation and probably also decrease the likelihood of some errors, but they don't guarantee correctness, as you're pointing out. They're shortcuts, so they're not perfect.…

Even without laziness, you can get similar problems if f creates a closure or returns something that includes the parameter object.

Yeah, this is a common source of confusion with closures in Python. Example on Stack Overflow:

https://stackoverflow.com/questions/233673/how-do-lexical-cl...

Re: I learned Haskell in just 15 years

#214

Post by trealira »

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.

From the point of view of writing a parser, Haskell's whitespace syntax seems like a hack. So, the grammar is defined with braces and semicolons, and to implement significant whitespace, the lexer inserts opening braces and semicolons at the start of each line according to some layout rules. That's not the hacky part; what makes it a hack is that to insert closing braces, the lexer inserts a closing brace when the parser signals an error. You can read about it here [0].

Also, on an aesthetic level, I think a lot of infix operators are kind of ugly. Examples include (), ($), and (). I think Haskell has too many infix operators. This is probably a result of allowing user-definable operators. I do like how you can turn functions into infix operators using backticks, though (e.g. "f x y" can be written as "x `f` y").

[0]: https://amelia.how/posts/parsing-layout.html

Re: I learned Haskell in just 15 years

#215

Post by dllthomas »

agentultra wrote: post #211
crabbone wrote: post #206

Earlier quoted context omitted.

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…

I think we can drop the "real-world," qualifier as it is unlikely there is an "imaginary-world" that we write programs for. What engineering merits did you have in mind?

> it is unlikely there is an "imaginary-world" that we write programs for

I think academia is typically what's meant as an imaginary world, along with play that may be in reference to no world at all.

Re: I learned Haskell in just 15 years

#216

Post by baby »

Bostonian wrote: post #142
baby wrote: post #117

Earlier quoted context omitted.

Ocaml definitely doesn’t make you more productive

I have not used OCaml, but presumably Jane Street thinks OCaml makes their coders more productive.

I've looked at their code and, I would not wish it on anyone to work there, it's on par with large Java codebase at a bank institution

Re: I learned Haskell in just 15 years

#217

Post by crabbone »

tome wrote: post #209
crabbone wrote: post #206

Earlier quoted context omitted.

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.

This is not really what maintainability means to me. To me, it just means you have a good memory.

To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously towards a common goal.

Haskell scores poorly on any of those points.

It's very hard to transfer ownership because Haskell programs have too much bespoke syntax that anyone but the original author will not be familiar with. Haskell programs are very hard to understand by executing them because there's no chance of a good step debugger due to the language being "lazy". Haskell programs are always "full of surprises" because they allow a lot of flexibility in the interpretation of the same symbols. The problems C++ programmers complain about when faced with operators overloading are the kind of things Haskell programmers call "Tuesday".

"Pure" functions are a lot harder to modify to add functionality. Typically, such modifications would require swiping changes across the entire codebase. One may argue that this preserves "single responsibility" constraint, but in practice it means a lot more work.

Objects and modules were advertised as a solution to code modularity -- another necessary quality for maintainability. While Haskell has modules, it doesn't really have smaller units of encapsulation other than functions. If two programmers are tasked to work on the same module, they aren't going to have a good time.

Re: I learned Haskell in just 15 years

#218

Post by Nemerie »

massysett wrote: post #178
nequo wrote: post #174

Earlier quoted context omitted.

The world is much less black and white than you’d like to see it. Functions in Haskell including Prelude can throw exceptions which is not reflected in the type signature of the function. That is an effect that makes seemingly pure functions impure. You can’t judge a language from a list of buzzwords. You need to look at how it is used in practice.

> Functions in Haskell including Prelude can throw exceptions which is not reflected in the type signature of the function. That is an effect that makes seemingly pure functions impure. No, bottom, or _|_, is an inhabitant of every lifted type. An exception is bottom. So the / function is still pure even though it can throw a divide-by-zero exception.

Does it make it type-safe though? In dynamic languages type errors also result in exceptions.

Re: I learned Haskell in just 15 years

#219

Post by agentultra »

crabbone wrote: post #217
tome wrote: post #209

Earlier quoted context omitted.

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.

This is not really what maintainability means to me. To me, it just means you have a good memory. To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously tow…

> To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously towards a common goal.

> Haskell scores poorly on any of those points

Interesting. I work at a company with over a hundred people committing to a Haskell code-base that runs our entire back-end. As far as I can tell we're continuously shipping code several times a day, every day, with very low impact on our service level indicators.

When we do have production issues they're rarely attributed to Haskell. I can think of one incident in 3 years where a space leak was caught in production. It was straight forward to address and fix before it impacted customers.

In practice, Haskell has been amazing to work with. I just rewrote over a thousand lines of code and shipped that to production without incident. I've never had that go off easily in any other language I've worked with (and I've been around for over twenty years and worked in everything from C, C++, Python, and JS).

Re: I learned Haskell in just 15 years

#220

Post by tome »

crabbone wrote: post #217
tome wrote: post #209

Earlier quoted context omitted.

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.

This is not really what maintainability means to me. To me, it just means you have a good memory. To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously tow…

I don't know what to tell you. I've been successfully using Haskell in production for over ten years, and it's the most maintainable language I've used for a variety of reasons, including the one given in my message above.
Post reply on HN