True, but GDP is often a decent proxy for material living standards, especially across countries and over time (so long as we note what it leaves out).
That’s not a small cycle count for a normal household.
90 × 24 = 2,160 total hours.
I sous vide now and then, about twice a week for 6 hours each, so around 12 hours a week.
That works out to roughly 15 years of usable machine time for the average person.
> if Imba offers a new approach it fails to communicate this on the landing page and focuses on code compression instead.
Fair enough. While it does touch upon `memoized DOM`, you're correct; it might not be sufficient for readers to grasp the full implications unless they're well-versed in these kinds of libraries. For a deeper dive, you can check out this subpage: https://imba.io/guides/rendering. BTW, I don't have any affiliation with this library whatsoever.
> I just wonder, whether a new language is necessary to achieve this.
To achieve compression, no. But to achieve DOM reconciliation without a v-dom, yes.
I feel like you missed the point of Imba. It's not solely focused on code compression (although that does appear to be a secondary objective). Instead, Imba is all about empowering developers to create declarative user interfaces without the typical complexities that often accompany such tasks, like dealing with reactivity, signals, custom directives, v-dom, and so on.
That’s weird. We moved to a new house and I was surprised one morning to see the cat scratching the upper balcony door, waiting to be let in, even though he’d never used that particular door until that day. He seems to always wait by the door that’s closest to the nearest awaken human, regardless if he’s ever used that entrance.
> Elixir code out there is much cleaner than erlang code bases.
You do understand this is just your subjective opinion and not a universal truth, right?
You are basing your argument as if it was a fact that Elixir is “cleaner” (whatever that means) and that there was a thing called “software-testing-revolution” which Erlang was never a part of. Both are subjective and, frankly, plain BS.
> if you are truly dedicated to the craft of software you probably should want them to learn Elixir
Oh boy, I don’t even know where to start... so you’re basically implying that Erlang programmers are not “truly dedicated to the craft of software”? It would be laughable if it wasn’t just sad.
This is the Ruby world mentality that just rubs me the wrong way. Not even worth carrying on with the discussion.
You’re missing the crux of the argument: auto-currying. In languages like Elm and Ocaml all functions are single arity which means a multi-arity function is just a partially-applied single arity function thus you can treat all functions as being single arity. This also means the pipe operator can be implemented as a higher order function being, as such, first class. Languages without auto-currying have to resort to macros.
Clojure also doesn’t have auto currrying, but makes up for it by giving you 6 variants and creating a consistent default library for sequences and associative structures.
Well I believe that no pipe is better than a a handicapped pipe operator.
The Elixir implementation inverts the classical order of piping last in functional languages to the detriment of it. IMO a language should either support pipe last AND currying by default or supply a multitude of thread operators like Clojure does (->, ->>, as->, etc). Elixir's is just middle-of-the-road-weird.
> Elixir just did it better imo and this person seemingly can't stand that people seem to like it more.
The post does read more like venting than a structured critique, but a few of his points are still valid.
Every time I hear someone praising Elixir, it's never about some Elixir-specific feature but usually about something that Erlang has provided for ages like pattern matching, lightweight processes, supervisors, the preemptive scheduler. Given this, I'm sure you can appreciate how bittersweet this can be for an Erlang developer.
To me Elixir is just a more complex, verbose and less elegant version of Erlang so it kinda frustrates me when newcomers would rather learn Elixir than plain Erlang.
- simpler syntax: there’s no Erlang program that you can’t read after getting comfortable with the language. Seriously. Go read OTP source or Ryaks, everything is extremely clear and explicit. To me, easier to read also means less bugs.
- It’s so different from other languages that, IMO, it makes it easier to “think in Erlang”; the syntax fits so well the semantics that I find it easier to think in terms of processes, patterns and the ocasional recursion when switching from other language (most Erlangers are polyglots IME).
*Edit: Reliable network services (Erlangs sweet spot) are much easier to write and maintain when written in a clear and explicit way. I love macros (consider myself a lisper actually) but I think they’re the wrong tool when writing bullet proof network servers (macros are basically everywhere in Elixir).
What "tons complexity" are you talking about? Clojure is a much simpler language (in the decomplected sense) than JS. Less syntax, better build tools, uniform stdlib, no webpack/babel nonsense. This sentence makes no sense.
> interacting with the JS ecosystem is painful cause of its reliance on the closure compiler.
Again, what? With tools like shadow-cljs, requiring JS libs and using them in you project is trivial (just require and import like you would any cljs library).
> In Clojure, is almost the same, most Java libs are over-engineered and horrible to use but you need to reach for them because Clojure lacks an ecosystem.
I've been writing Clojure for 10 years and rarely have I had to reach for Java. This is absolute rubbish.
You seem to hold strong opinions about a language you barely understand.
Edit: reading you comment history, you seem to have an axe to grind with Clojure.
Please don’t listen to the peanut gallery. The re-frame docs are in a league of their own and most of us appreciate the enormous effort put in to make them awesome. Keep rocking.