Hacker News new | past | comments | ask | show | jobs | submit login

If it's written in Haskell, it's highly likely that it'll be far harder to modify than something written in, well, not-Haskell.

Haskell might be easy when you get the hang of it, but the vast majority of programmers haven't, and the language ideas are alien compared to the mainstream ones (Python, JS, C++, Lua).

The design of Haskell also encourages users to be very clever, which only makes code harder to read.




I don't think writing Haskell ever gets easy, at least it hasn't for me over about ten years. Writing good code in any language is hard, but Haskell makes it harder to write bad code.

I have to write object-oriented bullshit all day for my job, if I started a fun new project like this I'd happily choose Haskell. If people who only know JS and won't learn anything new can't contribute then that's a cost worth bearing.


> If people who only know JS and won't learn anything new can't contribute then that's a cost worth bearing.

I think this is an unfair and unnecessarily-snarky take.

My list of languages is fairly long these days. I’ve written php, ruby, and go in reasonable volume for mostly personal projects. I used to teach embedded C at uni. I write python professionally every day. Recently I’ve even started playing with rust (and had some success thanks to the awesome book). The list is far longer, these are just the ones used the most. I’ve been writing code in some capacity for the last 20 or so years (first self-taught, then at university, and more recently professionally full-time).

Despite all that, and not for lack of trying, for whatever reason purely functional languages are the only ones that elude me. Every couple of years I try Haskell or erlang again and I just get nowhere fast.

Maybe it’s because I was never very good at maths, maybe it’s because I haven’t had sufficient motivation, or maybe I just haven’t found the right monad blog post to convert me. All I know is Haskell remains chronically out of reach to many experienced and inexperienced devs alike.


> for whatever reason purely functional languages are the only ones that elude me

That's because all of the languages you listed are really similar conceptually. PHP, Ruby, Go, C, and Python (and others you didn't list: Java, C++, C#, Perl, Lua, JavaScript) are far more similar to each other than they are to Haskell - they have different syntax and slightly different semantics, but for the most part they're all in the same language family. It's much easier to pick up Java after learning PHP than it is to learn programming for the first time - or, alternatively, to learn a structured language after having written unstructured BASIC for your whole life.

Lisp users (of which I am one) frequently talk about how all of those languages are "basically the same" - but for all that, Common Lisp is still way more similar to Python than it is to Haskell (which I've also tried and failed to learn).

Also, Haskell isn't just a functional language - it also is a lazy language, which means you have to now learn two new ways of thinking at once.

Erlang is similarly in a different world from the mainstream imperative-OO languages, but I don't think that being functional is the only thing that makes it hard to learn - it also has a fundamentally different model of concurrency (as well as being designed around concurrency) that is difficult to learn if you're just used to pthreads.

Similarly, I think that Prolog (logic programming), Adga (is it a programming language, or a theorem prover?), Rust (maybe; lifetimes), and Forth (stack programming) all present unique challenges to people like us that have only written Python/Ruby/Perl/Go/Lisp...


Yeah, I agree with all this. Amusingly, from your extended list I have also written a non-trivial amount of Java, JS, and Perl too which perhaps demonstrates your point further.

I hadn’t before considered the laziness part of Haskell, perhaps I simply hadn’t made it far enough to be aware of it before. Maybe that perspective will help me next time I feel the urge to try out fp again.

fwiw to your point about other languages, Rust has certainly presented a challenge due to new paradigms but it’s never felt insurmountable. The rust book is truly an incredible piece of writing that imo makes the language so much more accessible than it would otherwise be.


Yeah, I don't really see functional programming being that great of a fit for VR. I mean, the 3D environment is inherently object-oriented and stateful. And you're working in an extremely performance intensive task, such that pure immutability really starts to get in the way. Also, Haskell's lazy evaluation has a bad reputation for poor and/or unpredictable performance. It's better to have a higher mean execution time with an extremely narrow standard deviation so you can plan your frame budget and not occasionally blow it, dropping frames all over the floor.

What you want is something that puts the movement of memory between processes and threads front-and-center. Half the difficulty of writing a 3D rendering engine is coming up with a good memory model for loading 3D models and textures to push them onto the GPU. That really sounds more like Rust's wheelhouse than Haskell.


I disagree on the 3D environment being inherently OOP. ECS, a popular paradigm in 3D and 2D game making, can map pretty well to functional programming.

I would pick Rust as well here but just because Haskell has exceptions and it has less emphasis on safety and less pleasant defaults than Rust. In order to get the Haskell I want I need several pragmas and a different prelude...

I would say Rust is pretty functional itself, though.


What? ECS is soooo object oriented. It's basically the modern OOP attitude of poo-pooing inheritance in favor of composition, writ-large. Yet, somehow, all the components have deep inheritance hierarchies themselves, so [shrug].


Today I'd definitely use Rust. Most of the rendering work is gone in Godot, which is C++.

GC hasn't been an noticeable issue as a result.


> the 3D environment is inherently object-oriented

What does it mean for the 3D environment to be inherently object-oriented?


Haskell reduces the size of the developer pool, but increases their productivity (the Haskell ecosystem is enormous and astoundingly solid given the number of devs in that space), and also makes the docs a joy to read.


This. Im wondering how this is possible, high haskell reusability / easy to get familiar with codebases & extend them when familiar with hs or being a genius? I guess its the first


Strict static types reduce a giant class of errors (including most of the footguns I'm always triggering in my dayjob with Python). Purity reduces another giant class: It makes it easy (indeed kind of forces you) to restrict your IO to a thin, top-level error, hence keeping the vast majority of the code purely functional and thus easy to test.

Exactly how Haddock produces such wonderful automatic documentation, I don't know, but good God it does. The strict static types clearly help -- you can see exactly what every function inputs and outputs, what every data type needs, etc. And then you can jump to the definitions of any of those things, and if need be (almost never), the source code that defines them.


And what if it was the other way round? A steeper learning curve means that only the brightest, more motivated individuals can enter the realm, and those individuals are capable of doing more than the average developer.


You're right, that's clearly happening too.


> The design of Haskell also encourages users to be very clever, which only makes code harder to read.

This is BS - find me some "clever" code in one of these Haskell projects and I bet it's not clever but simply using a set of abstractions there maintainers like and grok and the reader just doesn't understand.


Maybe I'm being overly pedantic but I think that's a textbook description for overly "clever" code in any language- it makes perfect sense to the authors but is nontrivial for the reader to understand


Except in Haskell, it's not just some pet bit of code by the authors. It's a shared abstraction with well understood laws and theoretical underpinning.

What people call "clever" code in mainstream programming is not in any way similar to the Haskell being referred to.

Luckily in the Haskell world, we don't ascribe negative attributes like "cleverness" to code that isn't outsider-friendly. We gain a lot by not requiring that all our code is understandable by a mainstream programmer.


I find Haskell to be absolutely impenetrable, but I run XMonad and work with my config file just fine.

So users will probably be able to hack together what they want, but they may struggle to grow a large developer community. But that can still work out okay.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: