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

Haskell for a New Decade [pdf]

dev.stephendiehl.com

Post reply on HN
Print view View original

121–130 of 190 posts

Re: Haskell for a New Decade [pdf]

#121

Post by lmm »

cageface wrote: post #111
lmm wrote: post #59

Earlier quoted context omitted.

> I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell). But only at the most superficial level. It was heartbreaking to hear Kotlin ignore decades of Haskell and Scala experience when it couldn't be condensed into a 10-line example. They've adopted a fundamentally broken approach to representing absence and they'll regret it in 10 years, but it's already too…

What do you see as the deficiency of kotlin's handling of nulls?

Nested nullable types collapse to the same type, meaning it's very easy for generic code to contain really subtle bugs. If you have some generic code that has a T? and assumes that whenever it is null it is not T, this assumption will be almost correct and very easy to miss during testing.

Also, it's very common to have option-style code and as your code evolves you need to refactor it to either/result-style code (that includes a reason why something was not present) - indeed I'd say this almost always happens in code that lives long enough. In kotlin this is unnecessarily difficult because it's impossible to write code that works with both nullable types and an either/result-like type, and since null has special language-level support you can't even use the same syntax.

Re: Haskell for a New Decade [pdf]

#122

Post by pron »

These slides simply assume that Haskell as-is is progress, and then bemoan the "fashions, whims, and tastes" of the industry in being slow to relise that. But to measure the "timescale of progress" you need to consider the duration not from the time an idea first appears until mass adoption, but from the time the idea is proven and market-ready. GCs were widely adopted within 5 seconds of them having acceptable performance and not being packaged in runtimes with other significant downsides. The adoption rate of technology -- in general and in software in particular -- is largely consistent with what we'd expect from traits in selective environments. Ideas that trickle slowly through fashions (genetic drift?) are those that aren't adaptive (yet?).

Re: Haskell for a New Decade [pdf]

#123

Post by regisg »

JoelMcCracken wrote: post #50
pydry wrote: post #42

Earlier quoted context omitted.

I've always been somewhat skeptical of Haskell due to the scarcity of things you could point to and say "that was made with Haskell and it made it so much better". it's usually the same 3 pieces of software people point to, none of which are particularly noteworthy. with rust, by contrast, which is ostensibly much less general purpose and hasn't been around as long there's already quite a collection and it's easy to…

Haskell does have an issue of people using it being more interested in doing clever things and researching topics than building cool applications. Haskell jobs do exist, I have one of them. The big problem is that there are more people who want to do those jobs than there are jobs, so they seem very scarce. But anyway there are also a number of investment banks I have heard that use Haskell as their “secret weapon” a…

Top blockchain development in Haskell soon on Cardano... https://prod.playground.plutus.iohkdev.io/

Re: Haskell for a New Decade [pdf]

#124

Post by nextos »

logicchains wrote: post #69
nextos wrote: post #10

Very informative slides. I do not have real-world experience with Haskell, aside from little toy projects, but I have a lot of experience with other functional languages in the ML family and Scheme. Idris 2 looks appealing, but they should have also mentioned other approaches like Fstar, Lean and Z3. I quite like Fstar since they are delivering a big verified code base, as implied by the name of the effort: Project E…

>A toolkit where you can create DSLs with limited expressiveness, which in turn make it easy to build and verify things. This is a common approach in the Coq ecosystem, writing DSls for building things, and custom automation for them. See for instance papers by Adam Chlipala.

I know. His FRAP & CPDT books are great reads.

Re: Haskell for a New Decade [pdf]

#125

Post by 08-15 »

blackrock wrote: post #76

Why Haskell, and why not just write it in Lisp? It appears Lisp has proven itself consistently, at solving difficult problems.

No types, but implicit side effects everywhere. Also, recursive functions blow the stack (in Lisp, not in Scheme).

Re: Haskell for a New Decade [pdf]

#126

Post by sfvisser »

quickthrower2 wrote: post #49
nightski wrote: post #19

Earlier quoted context omitted.

I can't speak for everyone but for me the type system is not what made Haskell difficult. I loved it. What made it difficult was laziness. I'd find myself always trying to reason about execution (even though most of the time you probably shouldn't). Laziness might even be fine in a world built around it, but for a language to be practical it has to interface with systems that are not designed that way (numerous exter…

I find the type system and the errors difficult. The basics are easy (like you would use in Elm for example) but once you are talking about types that are related to other types, GHC extensions and all that, I quickly run into inscrutable errors that might take 1-2 hours of Googling to resolve. Basic Haskell is lovely though. It's why I liked Elm initially although it does take it a bit too far in the basic direction…

GHC's type errors can be daunting, but the complexity of the errors usually scales quite linearly with the complexity of your code. That's good, it keeps you in line.

> The problem with Haskell is it's purity and thirst for abstraction means more and more complex type definitions and ideas [...]

If that's the case something goed wrong. Proper abstraction means having complex definition with simple types!

Re: Haskell for a New Decade [pdf]

#127

Post by namelosw »

quickthrower2 wrote: post #9

I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language to try out ideas. Over the years it has turned into a production ready platform. As the PDF shows there are many languages spun off Haskell and it doesn't even mention them all. Then there are language features in C# and Java, Typescript etc. that are coming acr…

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages.

I believe Scala is already such a language.

> There are even features not in Haskell proper like Liquid Haskell that would be interesting to have in C# or Typescript.

There are many advanced type system feature are very hard or mathematically impossible to implement in main stream languages. The reason Haskell can maintain its novelty is due to purist and minimalist approach on many aspect of the language.

For example, Hindley-Milner languages cannot add sub-typing. But it can easily infer the type of parameters and the return type of the recursive function, while Scala cannot despite the fact it's very advanced.

> C# -> Ruby is 10 hours to be productive, 100 hours to be reasonable. C# -> Haskell is ten times that. > would be interesting to have in C# or TypeScript

While I tend to agree, there are also many teams are also burnt by these languages because multiple paradigm actually makes things even harder. It's easy to be productive, but as people climbing the tower of advanced type, the code diverse, the idioms people speak diverse, too. It's not as easy as we thought to be reasonable. There are also many people in Scala community eventually found out it's better to just use the functional part only rather than mix everything.

Re: Haskell for a New Decade [pdf]

#128

Post by mratsim »

namelosw wrote: post #127
quickthrower2 wrote: post #9

I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language to try out ideas. Over the years it has turned into a production ready platform. As the PDF shows there are many languages spun off Haskell and it doesn't even mention them all. Then there are language features in C# and Java, Typescript etc. that are coming acr…

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. I believe Scala is already such a language. > There are even features not in Haskell proper like Liquid Haskell that would be interesting to have in C# or Typescript. There are many advanced type system feature are very hard or mathematically impossible to implement in main stream l…

> For example, Hindley-Milner languages cannot add sub-typing

Subtyping? Haskell has ADTs.

Re: Haskell for a New Decade [pdf]

#130

Post by yiyus »

jeffdavis wrote: post #88

"Software is Terrible and Getting Worse" I wonder if increasing bloat is a permanent thing? Will software ever transition to a cycle of simplification? Has it ever gone through a simplification cycle in the past? Physical engineering has some limits that push back on complexity. You can only cram so many gears into a Swiss watch. An item can only have so many parts before manfacturing becomes a nightmare. What will p…

> Has it ever gone through a simplification cycle in the past?

Not as a whole, but there have been some significant attempts. Maybe the most radical one I can think of is Chuck Moore's Forth systems. Every new version is simpler than the previous one. Arthur Whitney has done something similar with APL, A+ and k, constantly trying to remove non-essential features. A more mainstream example is Unix and Plan 9, the 7th version of Unix was simpler than previous ones, and Plan 9 was much simpler than Unix. There are also initiatives like suckless, which try to write simpler software.

I am sure there are many more similar examples. Trying to remove bloat and complexity is a very important goal for many developers. Unfortunately, the real world usually gets in the way (colorForth has quite limited hardware support, Plan 9 never included a full-featured web browser, suckless software is not too friendly for novice users...).

Post reply on HN