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.
IMO there is inherent complexity in the task of creating dynamic user interfaces and reactivity/signals/directives are different tools to deal with this complexity by imposing different mental model on top.
In any case, if Imba offers a new approach it fails to communicate this on the landing page and focuses on code compression instead. To me it reads like Imba is a re-pack of status quo approach (React + Next.js) that focuses on compressed syntax. This is actually a good thing, I just wonder, whether a new language is necessary to achieve this.
> 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.
From what I see, it vaguely claims to create so-called ‘edit maps’ at compile time, similar to Svelte and million.js. It doesn’t say anything about the algorithm it uses to generate them and what limitations their algorithm puts on application code. I’m planning to do a little research and a blog post on ‘edit maps’, I’ll probably include Imba there too.
My neutered male cat sometimes disappeares but with exception of that one time I had to fetch him from the top of a 14m tall pine tree he always returns. My other cat (also a neutered male) never goes away for more than half a day.
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 is basically Erlang, just like Lisp Flavored Erlang and Gleam (the statically-checked language for the BEAM). The BEAM in general is a very specialized VM, which is why I used as an example, as the Julia compiler is also a very specialized platform and other languages targeting it would also be just Julia. Like Julia with s-expression, a typescript like extension for Julia that maybe would focus on different tradeoffs by reducing polymorphism in exchange for type checked contracts (but still use the same machinery and ecosystem since it would compile to Julia/Julia IR). I really wouldn't expect something completely different like the JVM supports (as at this point it would be better to use the LLVM directly).
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.
Is it to its detriment? What's really at stake here? Elixir's pipe operator takes a stance, and I love that. It enforces consistency. I feel it's a lot better than having the "sometimes first, sometimes last" that Erlang and Clojure have.
Huh? Almost always the parameter order is "the type of the module first" (except builders bla bla). This is super easy to remember, and this convention also encourages good code organization and module naming.
The only place where pipe order bristles is Enum.reduce, but I'd bet if I counted I'd have wanted it the normal way more often than the backwards way.
I just gave reduce as an example in my response without reading yours first. Can you explain why it would be more desirable to have it last in reduce? I have never felt this pain though, again, don't come from a functional background.
I don't have a functional background so I can only empathize that only being allowed to pipe first is not what folks are used to. I am having trouble understanding your argument, however, that includes both "consistent" and "choose your own adventure". I also don't buy that, other than simply being used to it, that piping last to sequences is more "natural". "reduce a into b with c" or "reduce value a into value b using function c" reads perfectly natural to me. I'm happy to hear arguments otherwise.
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.
I'm familiar with auto-currying from Haskell I've never worked seriously in a language that has it. But yes, that makes sense! I never thought about that.
I'm a bit stuck on your Clojure example still, though. If a language doesn't have auto-currying (or even currying at all in Elixir's case), why does the argument order matter? Whether it's a List or a Map, what does it matter if it's passed first instead of last?
There is no general implicit currying. I suppose if we are exact with CS terminology, currying means converting to 1-argument functions, so that's out.
But the threading macros do partial application in that they put the threaded-through value as an implicit argument. Look at the first examples in https://clojure.org/guides/threading_macros - the -> (thread-first) macro needs functions like assoc and update to take the map as the first argument.
And of course explicit use of partial application is also pretty common and argument order matters similarly there, just like it would eg in Python.
I was more after an example of why argument order matters in currying collection functions, but I actually get it now :) With the object as the last parameter, you are able to create a function that, say, always reduces to a list with a specific function and takes an object. So yes, I understand peoples' objections now.
> 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.
Elixir code out there is much cleaner than erlang code bases. In terms of organization, picking names. And there's much more dedication to testing and documentation. I think these software habits are very important for newcomers, and so if you are truly dedicated to the craft of software you probably should want them to learn Elixir even if the language is 25% more cumbersome in the small. There is something about the terseness of erlang that I think carries over to a mentality of not writing tests and not documenting. It doesn't help that it is less of a part of the culture (probably since it's an older language, Elixir is a post-"software-testing-revolution" language; Erlang is a pre-testing-revolution language).
> 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.
I legitimately could not get passed the choice of syntax, module organization etc. I believe many people feel the same way. Verbosity is good imo, languages are read more than written and Erlang is too terse for me. I love Erlang conceptually and I love that Elixir made it accessible to me because I otherwise would have just avoided the Erlang ecosystem all together and would have gone with Go, the thought of which makes me shudder because I am not a fan there. I can completely understand it being bittersweet and not that I knowingly represent a majority but I suspect many people think the same way I do in regards to writing in Erlang. To me terse != elegant and I find Elixir goes the mile for me there in what I do find elegant.
It's curious how these matters can be subjective. It's Erlang the verbose one for me: the commas at the end of the lines.
Of course Elixir has all those do/end and commas in the with statement (I wish it was part of the language and not a macro). Maybe I was just too happy to do without the trailing ; when I moved to Ruby and Python from C and Java.
- 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.
