Hacker Newsnew | past | comments | ask | show | jobs | submit | morshu9001's commentslogin

Couldn't they have figured out one decent way to do things before releasing features to all users? I tried Scala for a bit then decided it was complicated for no good reason.

Idk about Haskell, but I used Erlang which is also purely functional. No matter how long I used it and tried to appreciate its elegance, it became clear this isn't a convenient way to do things generally. But it was designed well, unlike Scala.


Erlang is, by my accounting, not even a functional langauge at all. It takes more than just having immutable values to be functional, and forcing users to leave varibles as immutable was a mistake, which Elixir fixes. Erlang code in practice is just imperative code written with immutable values, and like a lot of other modern languages, occasional callouts to things borrowed from functional programming like "map", but it is not a functional language in the modern sense.

If you go to learn Haskell, you will find that it has a lot to say about functional programming that Erlang did not teach you. You will also find that you've already gotten over one of the major hurdles to writing Haskell, which is writing with immutable values, which significantly reduces the difficult of swallowing the entire language at once and makes it relatively easier. I know it's a relatively easy path because it's the one I took.


> Erlang is, by my accounting, not even a functional langauge at all.

How do you figure?

The essence of FP is functions of the shape `data -> data` rather than `data -> void`, deemphasizing object-based identity, and treating functions as first-class tools for abstraction. There's enough dynamic FP languages at this point to establish that these traits are held in common with the static FP languages. Is Clojure not an FP language?

> It takes more than just having immutable values to be functional, and forcing users to leave varibles as immutable was a mistake, which Elixir fixes.

All data in Elixir is immutable. Bindings can be rebound but the data the bindings point to remains immutable, identical to Erlang.

Elixir just rewrites `x = 1; x = x + 1` to `x1 = 1; x2 = x1 + 1`. The immutable value semantics remain, and anything that sees `x` in between expressions never has its `x` mutated.

> Erlang code in practice is just imperative code written with immutable values, and like a lot of other modern languages, occasional callouts to things borrowed from functional programming like "map", but it is not a functional language in the modern sense.

I did a large amount of Scala prior to doing Erlang/Elixir and while I had a lot of fun with Applicative and Monoid I'm not sure they're the essence of FP. Certainly an important piece of the puzzle but not the totality.


Pretty sure FP is exactly what you said. If it's not, I'm ok calling it a "no variables" language.

If you wanted to write a quick on off script then using magic variables,etc made sense. Writing something you’ll keep? Don’t use those. When Perl 5 introduced references they could have simplified the syntax though.

I looked at Perl once and decided to just not use it, and hoped it'd go away so I never have to use it. Sorry, the decline was probably due to it being bad.

I know this is a tangent, but graph DB gets overused a lot because it's so often a neat-looking idea.

What if they did HDR for audio? So an audio file can tell your speakers to output at 300% of the normal max volume, even more than what compression can do.

HDR audio already exists in the form of 24-bit and 32-bit floating point audio (vs. the previous 16-bit CD standard). Volumes are still mapped to the same levels because anything else doesn't make sense, just as SDR content can be mapped to HDR levels to achieve the same levels of brightness (but not the same dynamic range, as with audio).

Isn't that just by having generally low volume levels? I'm being pedantic, but audio already supports a kind of HDR like that. That said, I wonder if the "volume normalisation" tech that definitely Spotify, presumably other media apps / players / etc have, can be abused to think a song is really quiet.

HDR has a slight purpose, but the way it was rolled out was so disrespectful that I just want it permanently gone everywhere. Even the rare times it's used in a non-abusive way, it can hurt your eyes or make things display weirdly.

I think JS is still overall more popular than TS, but if your team forces TS then yeah. It's like Java devs reluctantly switched to JS and were like, this needs more boilerplate.

Yeah, I spent years in Java and then even longer in .NET and it felt like everything I was getting a bit fed up of in those worlds had invaded JS. 20 years ago I could never have imagined defending JS as a language but, as time wore on, I started to appreciate its more stripped back syntax. And then a lot of what’s been added in later ES standards has been great so it seems even more unnecessary to layer TS on top.

Was going to say, I only vaguely look at Angular code from adjacent projects at work, and noticed all of a sudden the entire structure changed with the ngModule deprecation thing. Glad I'm not knee-deep in that.

I don't want static typing in a web language. This is something people getting dragged from Java and C++ want. JS and Py got popular without it.

Also there's TS if you really want it


Dart looks ok, but looking at the Dart equivalents of JS examples like {foo: 1}, I'd rather use JS

There is sadly no equivalent to {foo: 1} in Dart. This difference stems from Darts class based object model while JSs is, as you probably know, prototype based

That's my issue with this, I like the prototype system. It's very convenient for this kind of use case.

Seriously JS is the best choice for the things it's commonly used for

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

Search: