HN Theater @HNTheaterMonth

WTF is going on in this thread? How did we become so sensitive, Haskell has had a lot of criticisms here at HN, never saw any flags/downvotes. People argued vehemently but without any animosity.

Maybe something to be learned here https://youtu.be/iSmkqocn0oQ

⬐ zemo

it's probably the fourth time this article has been posted and people are tired of it

I have different take on OOP

It's beautiful thing that managed to enable milions of people to express more or less complex reality inside computers.

Sure it has it's quirks, something could be done better in $language, but that was decision/vision of $language design team how do they interprete object oriented programming.

The bad thing is that it is incredibly hard.

OOP and SOLID are kinda "basics of programming", yet those are incredibly difficult.

You need to have a lot of hands-on experience with creating software, modeling systems in order to make it good (maintainable, sane, easy to understand, consistent, testable, yada yada)

Simon Peyton Jones (Known for Glasgow Haskell Compiler) - Haskell is useless https://www.youtube.com/watch?v=iSmkqocn0oQ

>Why is mutable state such a big problem? The human brain is the most powerful machine in the known universe. However, our brains are really bad at working with state since we can only hold about 5 items at a time in our working memory. It is much easier to reason about a piece of code if you only think about what the code does, not what variables it changes around the codebase.

Isn't this part more about code "branches" instead of mutating state?

>Yes, one can pass immutable objects to methods in Java/C#, but this is rarely done since most of the developers default to data mutation.

Maybe because language designers didn't provide them right tool that'd enable their OOP vision to be more handy?

It's seems like there work being done that want to make this better in C# world.

>You, as a person, don’t have a “write” method either — you make the decision to write some text based on outside events or your internal thoughts

Why you don't have "write" "skill"/"ability"/"method"?

>Some people say that private methods shouldn’t be tested… I tend to disagree, unit testing is called “unit” for a reason — test small units of code in isolation. Yet testing of private methods in OOP is nearly impossible. We shouldn’t be making private methodsinternal just for the sake of testability.

"test small units of code in isolation"

everything is about how you define "unit"

"nearly impossible"

I bet that even C# and Java provide "hacks" to OOP to test private methods.

>public class InputValidatorFactory { public IInputValidator CreateInputValidator() => new InputValidator(); }

You don't need factory, so in smaller version you added 6 lines of code (interface and impl) which allowed your code to be more flexible, I'd say that this is reasonable trade-off, but what if instead of interface, then you used function? like Func<T, bool> as argument, but maybe not to btnAddClick, cuz it's bad method anyway, but to some validate method.

Func<string, bool> predicate = str => str.Length > 5;

myFunction(predicate);

So maybe OOP could be ""fixed"" by just introducting a few FP features? e.g C# - LINQ (not mutating state) and stuff like delegates, records, discriminated unions?

>TransactionAwarePersistenceManagerFactoryProxy or RequestProcessorFactor

>https://www.reddit.com/r/ProgrammerHumor/comments/418x95/the...

>Further reading: FizzBuzzEnterpriseEdition

Of course you can make OOP look dumb if you'll use example that were created with that purpose in mind.

OOP itself doesn't force you to use things like TransactionAwarePersistenceManagerFactoryProxy that people meme about it being common within Java world, but I personally don't think I've witnessed stuff as hardcore as this in C# more than once, twice or thrice.

I always remember SPJ’s chart in a short jokey video “Haskell is useless” https://youtu.be/iSmkqocn0oQ

Really made me see things clearer.

⬐ ksec

I really like his chart about usefulness and Unsafe programming. And that was in 2011! We have seen in the past 10 years how programming moving in the direction he was pointing at.

⬐ graffitici

I guess Rust is a language that went the move to Safe and Useful, following the top arrow?

⬐ kzrdude

I think SPJ is using a slightly different definition of safe than Rust does! But Rust should definitely be a bit up his safeness scale, but not all the way, doesn't fully control all effects.

⬐ amelius

It lacks a GC however, which Haskell has for a reason.

⬐ WJW

Rust prevents a few types of unsafety, mostly relating to memory and concurrency. There are many more on which Rust does not do particularly well though. Specifically, Rust allows arbitrary side effects from basically any part of the code. You can always write to stdout or a logfile, or open up new sockets, or delete files from the filesystem and there will be nothing in the type signature to even warn you about this.

⬐ discreteevent

>write to stdout or a logfile, or open up new sockets, or delete files from the filesystem

Do those things come under the category of unsafe? Why would we be programming if it weren't to do those kinds of things? If I buy a shovel, at some point I'll probably want to dig a hole with it.

⬐ WJW

If you'd watched the video from the grandparent comment, you'd have seen that those kind of uncontrolled side effects are exactly what Simon Peyton Jones was talking about in the video when talking about "safe" versus "unsafe" languages.

But in any case, yes those things I mentioned can fall under the category of "unsafe". In the category of memory safety, you want to be sure (with compiler guarantees!) that no thread will secretly free some allocated memory while you are still using it. This is something the borrow checker can give you in rust. There are no builtin guarantees in Rust that this fancy new library you imported won't do `DROP TABLE users`, or open a socket to https://haxorz.com and pass on all the environment variables. There are other languages in which you can be sure that a function cannot open any sockets unless it specifically has "can open sockets" encoded in its type.

⬐ discreteevent

I get that. (Another way to do it at run time is capabilities). What I don't like is calling this "unsafe". We know that use after free is never something anyone intended. We don't know that about opening a socket. If we take the attitude that any effect is unsafe then soon we will feel we have to control every one of them. If I have to control everything someone else does then I might as well do it myself (i.e. you eventually start to leak the implementation details and lose flexibility). Call it contracts or capabilities or something but not unsafe.

⬐ chriswarbo

Use-after-free is bad. "Unsafe" isn't the same as bad; unsafe means "could be bad". The reason that is a useful definition for unsafe, is that it allows us to define safe as "definitely not bad".

In Haskell, a function like 'Int -> String' is safe (definitely not bad). A function like 'Int -> IO String' is unsafe (it might be bad; we hope not). If it were possible to specify "bad" via the type system (like the type of use-after-free) then we would want that to be a type error (like it is in Rust).

⬐ fiddlerwoaroof

Except this isn’t true. I can embed arbitrary side effects in any line of Haskell code with something like

    foo :: Int -> String
    foo x = seq
            (unsafePerformIO $
              println “pwned”)
            (show x)

⬐ chriswarbo

FYI this sort of 'backdoor' can be forbidden using the "safe haskell" extension in GHC:

https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

⬐ kqr

Yes, we know unsafePerformIO exists, but nobody really uses it, it's clearly "unsafe", you can have your build chain scream at its occurrence, and... fast and loose reasoning is morally correct[1].

[1]: https://dl.acm.org/doi/10.1145/1111320.1111056

⬐ discreteevent

I don't know. Int -> String could be bad if the algorithm that calculates the value of the string is bad. But anyway I suppose I don't like changing the use of language where "unknown" now becomes "unsafe". Unsafe to me means that I know something about it. If I know nothing about it then it is neither safe nor unsafe. It's just unknown. Why not call it that? Otherwise we have two words for the same thing and have made our language more imprecise. (Alternatively if we take the attitude that something unknown could be good then we could argue that we call it safe).

⬐ PeterisP

I do believe that "unknown" should mean "unsafe". Safe means that you can rely on it, if you don't know anything about it then from a safety perspective this must be treated as unsafe.

⬐ chriswarbo

> I suppose I don't like changing the use of language where "unknown" now becomes "unsafe".

I don't think that's changing the use of language at all. For example, playing one round of russian roulette is 'unsafe'; even though (a) we don't know if it will have a bad outcome or not, and (b) the chance of a good outcome is much higher than that of a bad outcome.

⬐ dllthomas

> There are no builtin guarantees in Rust that this fancy new library you imported won't do `DROP TABLE users`, or open a socket to https://haxorz.com and pass on all the environment variables.

In practice that's true of Haskell as well.

⬐ tinco

Yeah the hacking examples are not a good illustration at all. Haskell protects against well intentioned unsafety. It doesn't protect against malignant writers of code. If you assume the writers of a fancy new library are in fact trustworthy and disciplined then you certainly are guaranteed there is no sneaky IO as the only way to do so is using `unsafePerformIO` of which the use is highly unorthodox.

⬐ Quekid5

Indeed, and I think it was a mistake by the parent poster to cast it as some sort of security thing. It very much isn't.[0]

Anyway, controlling side effects is really about avoiding accidental/unintentional side effects, i.e. mutating the world[1] by accident. Of course if everything is in IO, you only get "can do anything to the world" and "can't change the world at all", so Haskellers are usually interested in more fine-grained separation of effects than just pure/impure.

Of course, you are also trusting that code you're using doesn't do crazy unsafePerformIO, etc. stuff, but at least you can grep the code for that :). And sometimes unsafePerformIO can be a good thing to do 'magical' things which are referentially transparent but require mutation for asymptotics or performance generally.

[0] Safe Haskell is more about that kind of thing, but AFAIUI it isn't really in much use and never really took off. IIRC, it might even be slated for removal?

[1] Which is the ultimate shared mutable state, after all.

⬐ dllthomas

Right, my "in practice" was hedging for the existence of SafeHaskell, which does rely on the types and is "built in" to GHC, but as you say isn't really used by the community.

⬐ colonwqbang

The point is not that you shouldn't do these things. The point is that Rust does not provide any tools to help you do it safely. Mutation is also a necessary thing in programming, which can be unsafe if done incorrectly. Rust has many built in rules for keeping mutation safe and requires labelling functions that mutate. For side effects, there is not much of a safety net in rust.

⬐ feanaro

The part you missed is "always". The unsafe part is being able to do this from any function, instead of only from functions explicitly marked as being able to perform effects.

⬐ pyrale

The basic idea isn't that you want to avoid such activities, but that you want to know which functions do it, so that it is easier to reason about your program.

⬐ TheDong

Absolutely. If you watch the youtube video linked in this thread, SPJ makes that very comment, that a program with zero effects is useless.

However, the goal of haskell (and indeed any language trying to be safe in the way SPJ means) is to be able to have most code be safe/effect-free, and then to have effects be very carefully controlled and limited in their use. Things like the IO monad mean many parts of haskell code can't do IO in fact.

We obviously do want some sort of effect in the end, but the idea is it's safer to contain those effects in very limited places, and not allow effects to happen literally anywhere at any time.

Note, unsafe in the SPJ video was specifically about effects, while "unsafe" in rust terminology is mostly about memory safety, so those two terms really aren't the same word, and to be honest that can make communication less clear. I don't know what "category of unsafe" meant in your comment really.

⬐ logicchains

>You can always write to stdout or a logfile, or open up new sockets, or delete files from the filesystem

Haskell has a separate problem here: all of these can fail, and there's nothing in the type system to alert you of this (in the standard library), such failures just mindlessly throw exceptions like some Java monstrosity. In Rust, on the other hand, all such functions return something like Either Result Error, forcing the caller to check (and ideally handle) any errors. Not to mention async exceptions in Haskell, which can happen anywhere, and the fact that every value is really of type value|undefined, due to laziness. It's practically impossible to cleanly formally reason about code in Haskell due to the fact that anywhere could be interrupted by an async exception.

When even C++ is considering trying to remove exceptions from the standard library, Haskell's love for untyped exceptions everywhere is seriously behind the times for a language that prides itself on correctness.

⬐ juxtapose

I used to bash Haskell exceptions but my views changed recently after programming in Haskell for a while.

> all of these can fail, and there's nothing in the type system to alert you of this (in the standard library), such failures just mindlessly throw exceptions like some Java monstrosity

There's `MonadThrow` in Control.Monad.Catch which hints that the monad in question can throw exceptions. Admittedly, partial functions like `undefined` and `error` are still usable...

> Not to mention async exceptions in Haskell, which can happen anywhere, [...] anywhere could be interrupted by an async exception

... and they can throw exceptions everywhere, just like asynchronous exceptions, but it's actually a strength! Haskell enforces a clean separation between impure code (typically in a monad) and pure code. You can only catch exceptions in the IO monad, which often lies outside of the core logic. Due to this unique strength, Haskell is one of the very few languages that can safely terminate running threads.

Impure code can become harder to write because of exceptions, but since you don't write everything in the IO monad, the problem is largely mitigated. Yes, exceptions are hard to get right, and that's exactly why other languages are trying to get rid of, but Haskell makes it quite tractable, (though still quite annoying). Rust used more Maybes and Eithers in the IO monad (to borrow jargons from Haskell), but it's also got panic, which is the actual Haskell exception counterpart.

> and the fact that every value is really of type value|undefined, due to laziness

To be pedantic, Haskell has levity polymorphism, which gives you unlifted datatypes, like in OCaml and Idris. Even older Haskell has unboxed datatypes that are not lifted.

> ...Haskell's love for untyped exceptions everywhere...

Nope, Haskell's exceptions are typed.

⬐ tome

> > ...Haskell's love for untyped exceptions everywhere...

> Nope, Haskell's exceptions are typed.

logicchains means that the exceptions that a function can throw are not noted in its type (and as a massive Haskell fan I agree with him/her that that is very annoying).

⬐ Mikeb85

Good video, never seen it before. Thanks! Also love the fact he doesn't take himself or programming things too seriously (Haskell in useless category is great).

⬐ eklavya

It’s funny in my mind that I laughed at his joke about “the computer would just produce heat” and somehow the whole of cryptocurrency is literally doing just that.

I like SPJs' explanation why Haskell is useless: https://www.youtube.com/watch?v=iSmkqocn0oQ

Disclaimer: tongue in cheek

> Why not start from the imperative model

This video gives a bit of discussion around that point: https://www.youtube.com/watch?v=iSmkqocn0oQ

My take on it is that it's too hard to put the side-effect genie back into the bottle once you take it out. It's hard to write side-effect-free code out of side-effectful pieces.

E.g. You can't make a reasonable transaction system if you allow side-effects. You just have to hope that the programmer doesn't include any code that can't be rolled back.

> Haskell's "do" notation seems to be an acknowledgment of this, but to me it's adding another layer of abstraction just to recover what imperative syntax gives in the first place.

Haskell do-notation and Scala for-comprehensions kick arse and I always miss them when I don't have them. I think lack of do-notation is my biggest complaint about Java syntax.

⬐ weinzierl

Original title seems like click-bait but the content is really good and to defend the title SPJ really puts Haskell in the useless category right in the video. Of course the more interesting thing is his way of classifying languages along two axes of useful/useless and safe/unsafe and that he sees a general trend of movement along the safe/unsafe axis.

Well F# obviosly never gained enough momentum and C# has to grow somewhere so why not in this direction. All "big" languages are gaining more and more functional and declarative features each version. I always remember this chat by Simon PJ, the "father" of Haskell about convergence of languages in features https://m.youtube.com/watch?v=iSmkqocn0oQ

⬐ myu701

> Well F# obviosly never gained enough momentum

As a member of the F# Evangelism Strike Force (to use an n-gate ism), I want to argue this point but there is not enough info to determine what 'enough momentum' means.

I can produce, without leaving F#: libraries, cli apps, windows services, windows desktop apps, websites (asp.net core + giraffe), web apps, SPAs (SAFE stack), and more. If I target .NET Core, I can run my F# in windows land, linux land, and anywhere else .net core has been ported. What features does C# offer that F# doesn't, aside from being more familiar to lots of MS devs? Even I started my dev journey with C# on Windows Mobile 5 via .Net Compact Framework.

Cons: The F# tooling is just worse than C# tooling. Compare the 20-year old language with support since Visual Studio 2003 .NET to the one that has for some reason focused on the VSCode + Ionide plugins rather than the tooling that VS users run into and even I can't really argue that C# has better tooling. Biggest weakness of F# is all the wonkiness when it comes to common tasks like making, running, building, publishing codebases. The use case of something common like 'make me a new blank app, I want it to use paket for dependencies and to spit out an alpine docker image with .net core sdk at the end' should be 1 command, then triggerable from the VS Debug/F5 button. It just isn't that yet.

> C# has to grow somewhere why not this direction

I'd rather C# lean more FP than lean more OOP, sure, but _does_ C# have to grow somewhere? Can't a language spec be declared good enough / maintenance mode at some point so the programmers can focus their learnings on fuller understanding of the spec itself, as well as improving the implementations and tooling around a language?

⬐ pjmlp

It is called Go.

⬐ kungato

A language could be declaered good enough but none of the popular languages are there. They all had plenty of "bad but popular" design decisions at the beginning and now they are trying to compensate. What I hate is the constant repeating of everything. I'd rather one language have everything crammed in and we get to choose what we want and what we don't want. No "good" (my opinion) language will ever have only "one way of doing things" so why not just add everything and get over with it. In any case, all the "big" languages seem to be racing to "add everything" anyways.

IMHO my biggest issue with languages like F# and Haskell is like you mentioned the lack of tooling. I can even get over the fact that the ecosystem is smaller but the lack of ergonomics (things are harder to do, there's more friction in the dev process) always sends me back to C#. I wish F# tried to get into Roslyn instead of having their own compiler. I get the prestige and practicality of doing your own thing but I think it costed them a lot of missed out features and polish. I'm not that familiar with F#. It very well could be the language is too different to reuse almost anything from the semantic part of Roslyn but there's still so much else there they could get for free

> learning Haskell has changed the way I write code in any language

I think that's the bottom line. The creator of Haskell confirmed and explained: https://youtu.be/iSmkqocn0oQ?t=22

At some point, you need to modify some state, otherwise your program/language is useless. And that's not me saying that, I am just quoting, or at least paraphrasing, Simon Peyton Jones:

https://www.youtube.com/watch?v=iSmkqocn0oQ

And of course a lot of so-called "functional" programs just outsource their state management to some sort of relational database. And the people talking about their creation will praise the state-less-ness of their creation. Unironically.

What can you do? ¯\_(ツ)_/¯

Anyway, more practically, the vast majority of workloads do not have computation as their primary function. They store, load and move data around. Computers, generally, don't compute. Much. For those workloads, a paradigm that tries to eliminate the very thing that the problem domain is about, and can only get it back by jumping through hoops, is arguably not ideal.

https://carlstrom.com/stanford/cs315a/papers/barroso00piranh...

I did a little digging and even started reading "System design from provably correct constructs: the beginnings of true software engineering". From what I can see, it's mostly garbage used to sell the products of the HOS company. James Martin was on the board Higher Order Software, Inc. A company that despite claiming being able to provide "bug free software" went out of business.

Here's Edsger Dijkstra debunking the books written about HOS.

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

An evaluation by the US Navy concluded. "the HOS literature tends to advertise their ideas and products more than making a contribution in substance to the field of Computer Science. The author recommends that USEIT not be used in the TRIDENT program or any program development at NSWC. Even for a high level system specification, USEIT is not seen as a good choice. A mathematical functional notation or a PROLOG-like notation appears better suited for that purpose. The examples in the Appendices of this report, especially Appendices C, D, and E, show that a LISP-style mathematical notation is more compact and normally easier to read than the control map notation of USEIT. On a more positive note, the author considers the functional approach to system development and programing very promising. Systems so conceived and programs so constructed are more amenable to analysis and therefore, in principle, more reliable and better manageable."

http://www.dtic.mil/dtic/tr/fulltext/u2/a198753.pdf

So are we just talking about functional programming when we say HOS? If so, the pros and cons of functional programming have been discussed at great length.

Here is an interview with Simon Peyton Jones (one of the creators of Haskell) talking about why Haskell is "useless". It's a short interview worth watching if you want to understand the nuances and challenges and costs around creating high quality and bug-free software.

https://www.youtube.com/watch?v=iSmkqocn0oQ

⬐ carapace

Cheers! (I reply on sibling comment.)

I find this post a bit wordy but interesting. It notably points out well how the two approaches to deal with the state of a system, using versions or overwriting it, are in competition since a long time and in various domain of computer sciences.

Alan also cites a paper about [Worlds: Controlling the Scope of Side Effects](http://www.vpri.org/pdf/tr2011001_final_worlds.pdf). A hot topic in the functional programming world. That paper makes me remember that ideas from FP and OO can mutually improve (an idea well developed in this short video https://www.youtube.com/watch?v=iSmkqocn0oQ.

Let's get this out of the way: Rust is great. Rust apologia like this article is not so great.

> As an aside, remember that the only difference to C/c++ is that if you write a “basic linked list” in them, all of your code will be unsafe.

There's a bit of mental gymnastics going on here. The word "unsafe" is performing double duty, since it means "memory safety not guaranteed by the compiler" in Rust and it means something else entirely when you are talking about C++, since memory safety was never guaranteed by the compiler in the first place. The other problem with this statement is that linked lists in C or C++ aren’t really that hard to get right, in fact, they’re easy. Maybe you draw out a diagram on pen and paper before you write the code, but you’re unlikely to be facing segfaults.

I admit I’m biased here, because I’ve been using Haskell for something like 15 years now, but I feel like the Haskell community acknowledges that Haskell’s type system gets in the way and prevents you from doing useful, interesting work, and that even a great library ecosystem isn’t enough to overcome this. That’s how safety generally works. It’s harder to write programs that do useful things, but in exchange, it’s also harder to write programs that behave unpredictably or do dangerous things. Because Rust and Haskell put you in such restrictive type systems, sometimes you have to break out to get real work done.

Haskell’s pitch, in my mind, is, “Let’s make it easy to reason about side effects and value semantics.” From the article, Rust’s pitch could be, “Let’s make it easy to reason about control- and data flow.” These are both evolutionary steps in the development of programming languages, all programming languages being somewhat flawed. Future languages will steal ideas from Rust the same way modern languages have stolen ideas from Haskell.

But apologia still leaves a bad taste in my mouth. The article says, “Is this a problem with Rust? Not at all.” There’s a worrying unwillingness to acknowledge that Rust is flawed, and the article describes Rust users as “Rustaceans” and makes broad generalizations about how they behave. This reminds me of the excesses of 2000s-era object-oriented programming. The comment about “Rust’s facilities for code reuse” could have been taken straight out of a press release for Java back in the late 1990s for all I know.

Rust is great, but this article is further cementing my distaste for the Rust community.

By comparison, here is Simon Peyton Jones talking about how Haskell is useless: https://www.youtube.com/watch?v=iSmkqocn0oQ

I feel like the author didn't do this as a way to bash Clojure but to try and progress Common Lisp. Anecdotally, I remember Hickey saying something about a stagnation in the CL community, so if Clojure inspires cross-pollination of ideas then that's a good thing.

For instance, Simon Peyton Jones describes [1] how they took the ideas around STM from 'unsafe' languages and put it into Haskell, developed it further, and then later the 'unsafe' languages took the Haskell innovations and put it back into their languages.

Clojure isn't perfect, and Common Lisp isn't perfect, but hey, they're better than programming in assembly. We should be stoked about someone trying to innovate; why do these posts always turn into language wars?

[1] https://youtu.be/iSmkqocn0oQ around 3:50, but the video is short so it's worth watching the whole thing.

⬐ brudgers

I didn't take it as Clojure bashing either. On the other hand, it does seem to be a sort of back-footed defense of Common Lisp, to me. Partially because it seems to miss acknowledgement that part of the goal of Clojure was to bring the level of abstraction that Common Lisp affords to the JVM, for example Common Lisp has the abstraction of Seq(uences) and functions that operate upon them.

But the big elephant to me is that Common Lisp provides a very strong set of Von Neumann abstractions in addition to its functional abstractions. Lists are an abstraction that maps to sequential reads of a contiguous block of memory. Setf has pointer and offset semantics. And the much maligned `loop` is a brilliant abstraction over iteration that lets a program be explicit about the why of a loop.

That's not to say there are not advantages to functional programming. But the popularity of Go and Python etc. suggest that abstractions that run counter to functional programming mores is not a reason to find fault in Common Lisp. Like Clojure, it's a big language that tries to meet programmers where they are in the projects that they work on. Nobody faults Clojure for allowing Java's mutable vectors because they're there in the language for practical reasons.

> .. role model ..

And don't forget, the superior way to project confidence [1] in your 'precious'.

[1]: https://www.youtube.com/watch?v=iSmkqocn0oQ

>Maybe 'aninhumer has a point - restricting the language is kind of the opposite goal of making it expressive/powerful.

My point was more that safety is a separate, important metric of language quality. It often conflicts with expressiveness, but not necessarily.

See also SPJ's "Haskell is Useless" video: https://www.youtube.com/watch?v=iSmkqocn0oQ

Simon Peyton Jones - Haskell is useless: https://www.youtube.com/watch?v=iSmkqocn0oQ

https://www.youtube.com/watch?v=iSmkqocn0oQ

⬐ swalsh

oh cool, that's the same guy... same concept, but different video.

Awesome! I assume you intentionally released this on a Friday just to eat up everyone's weekends :) Thanks for the hard work. As I dig in, I'm hoping that Rust will fit in the "useful and safe" sweet spot in Simon Peyton Jones's diagram here: https://www.youtube.com/watch?v=iSmkqocn0oQ

⬐ None

None

⬐ steveklabnik

> I assume you intentionally released this on a Friday just to eat up everyone's weekends :)

Hehe, we didn't choose it for any specific reason, but when we started to do the six-week cycle, it landed on a Friday. I like shipping on Friday for a number of reasons, but there's good reason to pick any particular day.

⬐ not_with_retard

You should _always_ be shipping on the first day of your own work week, so you can handle emergency cases should any arise.

⬐ burntsushi

I actually liked it for selfish reasons. I got to stay out way past my bedtime and geek out about Rust at the Boston meetup. :D

Simon Peyton Jones himself does not count Haskell among the “useful” languages (Simon Peyton Jones - Haskell is useless): http://www.youtube.com/watch?v=iSmkqocn0oQ

Ruby and Python are everywhere in the enterprise. Haskell is currently "useless" [1] for the enterprise for the obvious human resource reasons.

[1]: https://youtu.be/iSmkqocn0oQ

⬐ codygman

> the obvious human resource reasons

Can you elaborate on these?

⬐ eternalban

Why bother? Count the down votes in this thread and then note the number of thoughtful rebuttals. (But for the record, imo Haskell is a glorious language.)

Reference for the SPJ quote: https://www.youtube.com/watch?feature=player_detailpage&v=iS...

Hmm...didn't realize this was (or could be) a serious question.

Anything with state comes to mind. The text field I am typing this into, for example. I type on my keyboard and the state of the text field changes, and after I hit "reply", the state of the page changes with a comment appended. Before/after.

Yes, you can implement this by creating a completely new page containing the concatenation of the old page with the comment, but externally (when you visit the URL), the state of that page has changed. So if you choose to implement the problem in a functional style, you have to bridge that gap somehow between that style and the problem at hand.

Any sort of document processing done on computers in Word, Excel (regarding the document itself, not the one way dataflow constraint program inside), OpenOffice, PowerPoint, Pages, Keynote, Quark XPress, InDesign, Photoshop, Illustrator etc. People use these programs to change the state of documents. That is the purpose of these programs.

Anything that interacts with the world, for example the user interface.

Or Wikipedia. Pages change, sometimes because there is new information, sometimes because something in the world has changed. Or most any other web site.

Really, the world (a) has (a lot of) state and (b) that state is changing incessantly. It is not (a) stateless or (b) immutable.

But don't take it from me: "In the end, any program must manipulate state. If it doesn't, there is no point in running it. You hit go and the box gets hotter" - Simon Peyton-Jones. https://www.youtube.com/watch?v=iSmkqocn0oQ&t=3m20s

⬐ tome

Thank you for the food for thought.

⬐ nbevans

It's pretty rubbish food he just gave you there. This is why F# has the mutable keyword. If you are so desperate to use it, that is. Most good programmers try to avoid it.

It's funny that this guy claims fitting the problem to suit FP is a bad thing. But fitting the problem to suit OOP is seemingly a good thing. There is no difference really. All problems have to be made to fit your tooling and practices in same way. The difference is how much squashing is required and the two or three second decision it takes to select the right tool. Only performance optimisations really warrant falling back to mutation of state, other than IO of course. The default should always be immutable. Don't let some brain dead OOP-only troll deter you from seeing the light.

He is speaking is riddles, like pseudo academics love to. Seriously, he is suggesting you can't have an editable text box on a GUI, written in a language like Scala, F# or OCaml? What a moron. (This link will prove particularly embarrassing to a certain person here: http://www.scala-lang.org/api/2.10.2/index.html#scala.swing....) He is arguing an argument that doesn't even exist here, but one that only exists in his own head.

Pure FP, much like pure OOP, is utter shit and painful. The sweet spot is reached by mixing the two and using a multi-paradigm language, ala F#, Scala, OCaml, etc.

Disappointed that this wasn't actually a workshop for families. Cambridge used to use (still uses?) ML as a first language for CS undergrads, making its obscurity a strength (it is a new experience for most students).

I see one of the abstracts talks about a "classless society" as a pun relating to object orientation. This makes me groan a bit, as there seems to be a general tendency in FP to make superficial quips, puns or observations like this while the community of FP programmers remains totally divorced from reality.

A good example is the notorious video interview https://www.youtube.com/watch?v=iSmkqocn0oQ in which Simon Peyton Jones laments the fact that pure functional programming languages just make the CPU heat up and nothing else (i.e. they have no useful side effects.) He probably wasn't being completely ingenuous but it comes across as a lack of self-awareness: FP is all about calculation and expressions, the program is an input and the value it evaluates to is the output... That's all you can expect. You need some other paradigm to "do" things, IO monads notwithstanding.

Conan Elliot has a fun blog post on the c preprocessor which dances around this issue a bit: http://conal.net/blog/posts/the-c-language-is-purely-functio...

⬐ ZenoArrow

"A good example is the notorious video interview https://www.youtube.com/watch?v=iSmkqocn0oQ in which Simon Peyton Jones laments the fact that pure functional programming languages just make the CPU heat up and nothing else (i.e. they have no useful side effects.)"

You're not the first person I've seen that's misunderstood this video, I can only guess at why... One thing it's probably worth remembering is that Haskell has been a research platform for many years, and some of the Haskell features that people take for granted today did not exist in earlier versions.

SPJ is not saying that Haskell is useless now, but it was close to useless for creating programs for a number of years. As a case in point, try to imagine Haskell without monads. Hopefully knowing that Haskell did not have monads at one point helps you understand the historical context of this discussion.

⬐ theoh

Are you saying the video predates the IO monad? I don't think that's true.

In any case, I don't think I have misunderstood: I just don't agree with his notion that a hypothetical purely functional language is "useless", as I explained.

⬐ cheepin

The video certainly doesn't predate the IO monad, but the point was that Haskell was designed as an academic language with zero emphasis on practicality, and has grown in usefulness over time.

⬐ kenko

I must have missed that explanation. What would the use of a really pure functional programming language be? One with no side-effects, not even printing to a console? (How are you going to get the answer to your computation back out?)

⬐ theoh

OK, maybe I didn't make myself clear. Basically I am just saying that a "useless" pure functional language as characterised by Peyton Jones is equivalent to a souped-up desk calculator. You type an expression in (a form of IO provided by the runtime), you press Enter, and you get a value back. This is far from useless, nothing to he ashamed of. A "classic" bit of functional programming like Hutton's solution of the Countdown problem requires nothing more. http://www.cs.nott.ac.uk/~gmh/bib.html#countdown

I reckon a lot of people want to use that kind of machine, though it rules out systems programming. See for example the requirements expressed in this article: http://www.americanscientist.org/issues/pub/calculemus

⬐ ZenoArrow

A desk calculator manipulates state, does it not?

⬐ theoh

So do the implementations of functional programming languages.

⬐ ZenoArrow

All the state-altering functions of Haskell are kept separate from the non-state-altering ones. That's what makes Haskell "pure functional" as opposed to "functional". The state-changing functions were designed after the non-state-changing ones, which is what we've been trying to tell you!

⬐ theoh

Good grief. I said the _implementation_, not the language. They all use mutable state. Go read a paper. http://research.microsoft.com/apps/pubs/default.aspx?id=6708...

⬐ kenko

How do you get the value back?

⬐ ZenoArrow

"Are you saying the video predates the IO monad? I don't think that's true."

No, I'm not saying that. Listen to the video...

(3:34): Nevertheless, we put up with that embarrasment for many years until we figured out how to combine, in a single language, a single programming (...), we can combine effectful computations with effect-free ones, without making them pollute each other, right. The type system keeps them apart.

(...) Can't quite make out this word, "methodology" perhaps?

In any case, as you can hopefully see from reading that quote, SPJ is talking about the situation with Haskell in the past. Until they worked out how to do effectful computation in a pure functional language Haskell was basically useless, after they worked it out then Haskell was not useless. Do you understand what SPJ was saying now?

⬐ theoh

He is not saying that Haskell moved from the category of "Useless" to "Useful" (the spot on his diagram marked "Nirvana"), he is saying they are moving in that direction...

But in any case that's not my point. I am arguing that Haskell was never useless in the first place.

(You seem to be ignoring the substance of my comments, so continuing this thread is probably a waste of our time.)

⬐ ZenoArrow

" I am arguing that Haskell was never useless in the first place."

Okay, let's get break this down. The Haskell project was started in 1987. Version 1.0 of Haskell was released in 1990. Version 1.0 had no monads (they didn't come until version 1.3). If you had to code something that was both pure functional and useful in version 1.0, could you do it?

"he is saying they are moving in that direction..."

Yes, of course, because "useful" is a relative term. It's a goal, but the work on making a language more "useful" is never complete. The sketch is not important here, it's just a simple sketch, listen to SPJ's words.

⬐ kenko

He was obviously not being ingenuous and it's amazing to me that anyone can watch the video and think there's any question about it; he's describing the fact that they had to figure how to do side-effects. And indeed, they did figure out a way to do side-effects.

⬐ lindig

The "classless society" was mentioned by Andreas Rossberg, the author of the talk. He works at Google on the JavaScript V8 engine as a compiler engineer and is on the JavaScript (ECMAScript) language committee. I'd call this pretty well grounded in reality.

⬐ theoh

I was calling him out on the frivolous and unfunny quip, not implying he isn't a serious programmer. And I don't mean to single him out for criticism in particular, I was just reminded of the Foozles phenomenon: https://wiki.hh.se/wg211/images/5/58/Foozles.pdf

For me the context here is that Cambridge is a massively elitist centre of frivolous intellectual pursuits, in a country with the highest levels of inequality in Europe. http://www.theguardian.com/society/2014/aug/28/closed-shop-d...

Perhaps I have a chip on my shoulder about this, but I actually did my undergraduate CS degree in Cambridge before I knew anything about the world so I am at least somewhat qualified to comment on that milieu, from a political point of view. It's cosy but relevance to the everyday life of the masses is not a strong point. I don't have any comment on whether JavaScript implementation details have political consequences.

⬐ lindig

The V8 engine is implemented in C++ and so I'm sure Andreas has a good grasp of the relative benefits of FP and OO. In the context of your observation about inequality in the UK I find the "classless society" actually funny.

⬐ samth

Andreas' comment is not about OO at all. It's about the second-class status of modules in ML, where the 1ML design that he described in the talk makes modules first-class values.

And is your claim really that people in the functional programming community shouldn't make jokes in their talks until FP lives up to your notion of practicality? How many banks need to use Haskell, how many switches need to run on Erlang, etc etc, until you're satisfied?

⬐ theoh

Actually, for what it's worth, it's the widely accepted status of FP as a kind of elite ghetto that I was alluding to, rather than its practicality. I'm not the first to comment on that, and not the best placed to know how to fix it, but, you know, I was musing on what it might be like to have an ML family event involving kids learning functional programming. Something a bit "soft" rather than relentless logic and category theory.

⬐ samth

Actually, there was no category theory at the ML workshop. And the particular complaints you made were based on misunderstanding Andreas' joke, and on being annoyed that FP people are playful while being an "elite ghetto". The particular example of someone who makes a joke, Simon Peyton-Jones, has spent the last several years pushing computing into every elementary school in the UK.

Sign. Yet another discussion full of trolling pros and cons of FP vs. OO

Guys, listen to Simon Peyton Jones himself: "Haskell is useless". He's discussing stuff with Erik Meijer in this video:

http://www.youtube.com/watch?v=iSmkqocn0oQ

⬐ codygman

You didn't actually watch this video did you?

⬐ freyrs3

His comment was of course tongue in cheek. He wouldn't spend 25 years of his life working on it if he thought it was useless.

I think he may be talking about this: https://www.youtube.com/watch?v=iSmkqocn0oQ

⬐ coldtea

Yes. Plus the cheeky "avoid success at all costs" remarks etc. Of course he doesn't mean it's not usable (or used already) in the real world at all.

Just that it's not in the perfect practical form that a real world language would have.

I think Simon Peyton Jones says it best about Haskell :

http://www.youtube.com/watch?v=iSmkqocn0oQ

He says Haskell is useless. Without even debating that (it can certainly be useful for certain classes of programming problems), you can see his point : The goal of Haskell was to start from an ideal view (pure functional programming without side effects) and try and see how to make that eventually practical for everyday programming, without sacrificing the pure core of the language.

You have languages, like F# (or even C# !) that takes lessons from Haskell, with at the same time being practical for pretty much every programming task (their platform , .Net, makes them useless for a lot of use cases, but that is another problem)

And on the other side (in my opinion), you have languages like Go, being pretty dismissive about pretty much everything learned from languages like Haskell.

I respect the point of view of Go's creator, i just disagree with it, and don't see any project i could do in Go that i wouldn't prefer doing in Scala/OCaml/C#. But more power to people who want to do great things in Go !

Go fills a niche (AOT compiled without a VM) that only OCaml fills in the list of languages i have listed, and OCaml is probably much more complicated to learn, even if it is way simpler than Haskell, so even if i don't agree with the design choices, i can see why Go could gain traction (apart from the fact that it is Google powered)

⬐ kenko

Peyton-Jones said that Haskell was useless before they got a handle on how to do IO. Haskell is clearly not useless at present.

⬐ meaty

However it's far harder to make it not useless than other choices. To me at least, Haskell appears to be alphabet soup like badly written Perl. The syntax is so close to the metal it's unreal.

⬐ pcwalton

SPJ's comment had nothing to do with lexical syntax.

I was particularly thinking about things like order and group in list comprehensions[1]. Turns out the paper introducing them was actually from 2007, so maybe it's not that recent :). (I thought it was newer than that.)

[1]: http://research.microsoft.com/en-us/um/people/simonpj/papers...

Here is a random video I found earlier where SPJ talks both about this in particular and the exchange of ideas between Haskell and .NET in general: http://www.youtube.com/watch?v=iSmkqocn0oQ