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

Haskell is our first choice for building production software systems

foxhound.systems

Post reply on HN
Print view View original

91–100 of 297 posts

Re: Haskell is our first choice for building production software systems

#91

Post by xdavidliu »

jcelerier wrote: post #35
kungito wrote: post #33

Earlier quoted context omitted.

faculty helps students debug their code?? where?

I'm in france haha. why wouldn't you help a student who asks you kindly ?

Parent is probably referring to situations where faculty are too busy researching, writing grants, or just plain don't feel like it, and tell students something like

"go play with it"

"look it up"

"google it"

"read the fudging manual"

Of course, there are many great faculty who _do_ care greatly about teaching and always help students.

Re: Haskell is our first choice for building production software systems

#93

Post by _query »

kreetx wrote: post #44
fegu wrote: post #32

If you want to get a feel of the productivity using Haskell in production start with a simple CRUD app and use IHP ( https://ihp.digitallyinduced.com/ ) to build it. You will have something usable within a day - GUI and all. Then move further down the rabbit hole from there.

How about servant, and some popular js framework on top of that? IHP might be putting a lot of effort into the project, but the code generation part... I (personally) don't like that at all. And it's not common practice in haskell.

IHP is very opinionated in the way how it approaches building web applications (Code Gen, Project structure, Naming, ..). But exactly this kind of opinionated design makes it possible to be very productive, compared to doing everything yourselves.

Re: Haskell is our first choice for building production software systems

#94

Post by dgb23 »

jrh206 wrote: post #10

Haskell is nice and all, but I'm not a huge fan of this take. I can't help but think that many of the arguments boil down to something like 'you can write types so that the compiler checks things for you' (not a quote), whilst the author disregarded the Java/C++ compiler as "an annoyance" (a quote). The rest of the article is mostly a comparison between Haskell and PHP/Python/JavaScript, and most laid out benefits bo…

The claims in the article sound weak, because they communicate in an informal and natural way.

"Haskell's type system is more expressive than X and Y" is a strong claim and can be proven by showing that X and Y need to compose run-time workarounds for a given property that can be checked statically in Haskell.

"Functional Programming reduces the surface area for Bugs" is a strong claim and can be proven by showing that a single mutable reference strictly introduces a set of possible bugs that were not possible before and that these bugs cannot be checked in language X.

It is kind of annoying that these discussions often seem superficial, cultural or partisan, when in fact they could be much more rigorous.

Now, If we assume or find these claims to be true we can finally proceed with the real discussion: What are the costs and benefits of these properties in a given setting?

Re: Haskell is our first choice for building production software systems

#95

Post by coldtea »

tome wrote: post #55
coldtea wrote: post #5

Why Haskell is our first choice for building production software systems: a rationalization of our excitement to get to write Haskell in production Here, I've fixed the title

Would you say that you've engaged in good faith with the point the author was trying to make?

Absolutely

Re: Haskell is our first choice for building production software systems

#96

Post by FpUser »

mjburgess wrote: post #25
jcelerier wrote: post #18

Earlier quoted context omitted.

> the types are really low level (missing basic things like tuples) and lack of type inference how far ago was this in the past ? C++ had tuples and type inference for ten+ years officially now - gcc 4.4 had it in 2009

There's also the culture around the language to fold in. A culture of writing code assuming inference and structural typing is quite different than it merely being available.

I have zero problems using type inference, tuples, etc in my code. Other developers I deal with and who do use C++ have no problems using those "novel" concepts either. So I am completely at loss about what type of culture you are talking about here. It looks like grasping at a straw type of argument to me.

Re: Haskell is our first choice for building production software systems

#97

Post by nudpiedo »

wombat23 wrote: post #88

What I'd like to understand: When/why does one choose Haskell over other functional languages e.g. F# or OCaml? It looks to me like they would satisfy the same points that the article makes. Edit: just did a quick comparison of the last 2 SO developer surveys, and it looks like Haskell "replaced" F# in their popularity ranking last year.

all them are equally competent languages. F# with corporative support and a giant ecosysten, ocaml being very fast and portable and haskell being very... special and pure.

Re: Haskell is our first choice for building production software systems

#98

Post by oblio »

nicoburns wrote: post #89
mehrdadn wrote: post #78

Earlier quoted context omitted.

> You have to repeat the type information, a lot. Nope you don't, that's what typedefs are for. They're underrated for sure though. People don't use them nearly as much as they should. They're incredibly valuable for avoiding precisely this problem.

That doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

Java now has (limited) type inference, bar. As does C++, auto. They're limited but they remove a lot of tedium.

Re: Haskell is our first choice for building production software systems

#99

Post by emteycz »

Rompect wrote: post #69
corty wrote: post #26

Earlier quoted context omitted.

Annoyance about C++ errors isn't only about the error occuring. With me, it is predominantly about the utter unusability of the error messages. C++ has postprocessors you can use to get your 20 page STL errors down to a few lines just by reversing the expansion the compiler did to show you mere mortal something that you might recognize as your code instead of template-cthulhu. Haskell has such situations as well, but…

In contrast, Rust's compiler sometimes gives suggestions for changes which can often just be copied.

That's not entirely true. It gives suggestions in the cases where the C++ compiler does too. There are more than a few very cryptic errors you can encounter with Rust. I like it though, just needs more work.

Re: Haskell is our first choice for building production software systems

#100

Post by ernst_klim »

dan-robertson wrote: post #71
ernst_klim wrote: post #54

Earlier quoted context omitted.

> there isn’t much evidence in either direction Oh, I think there are great evidences, such as: dialyzer, or ruby3 and python3 shifting towards type signatures everywhere and gradual typing, or recent racket focus on typed racket. Oh, and the rise of typescript of course. I mean, I've abandoned Python years ago, and I was quite surprised when I discovered python people are adding type annotations everywhere. Sure, gr…

What you have described is an anecdote rather than any study that attempts to be impartial which is what I really meant when I wrote ‘evidence.’ I’m sorry for not being clear enough. I don’t feel like this anecdote is evidence because I don’t think it’s inconsistent with the trend towards more static types over the last 5-10 years or so. For this anecdote to be convincing I would need to think that programming langua…

This is not an anecdote by definition, since these languages represents quite a huge marketshare (and most of the rest langs are already statically typed).

Yes, this is not a sound rigid empirical proof, it's an observation (i.e. unlike the case of anecdotal, you can measure the marketshare of user, how many do use dialyzer or typescript, etc etc). We can't simply ignore any observations that are not scientifically rigid, otherwise the whole edifice of philosophy or even some natural sciences should simply perish.

I don't think you can just omit that. I'm a fan of Lakatos here, if I have some observation, I think one need at least as convincing evidence or more rigid one to prove otherwise.

> because of carefully thought out and researched decisions

I think it's a better evidence exactly because it's what language users are asking about, and what large chunk of language users choose to use when they got a choice. This shows that quite a big share if not majority of programmers value type annotations.

Post reply on HN