You mean language server protocol?
Yeah, ReasonML originally made some fantastic changes and I was about to start using it, aaaaand then they kept going… right off the deep end… >.>
Er, yep that! ^.^;
BuckleScript 3.0 has just released!
That’s not what I mean and it is also not true.
But most of professional programmer I knew tend to find those elements to make them comfortable when they trying a new programming language. I saw a bunch of people heard of Haskell’s reputation and tried to throw themselves directly to the world of Haskell. And they mostly felt drown and gives up in the next few days/weeks/months since there was no place they can grasp.
That’s why new languages tend to look like the old ones. Even though something’s different fundamentally.
That’s why after C being a mainstream language, you’ll see C++ became it’s successor for being the first popular OO language in the age of OO. And same for Java and Scala for FP.
I’m pretty sad for excellent languages like Smalltalk, for it would never come into mainstream’s sight again. But I’m sure one of the functional we love today would share same fate when we look back 20 years later.
And also that’s somehow why are Ruby / Elixir are alike. Both Elixir and Erlang are great, but the communities is pretty active and promising partially(though might be one small part of the whole thing) because the syntax, and the author’s connection to the Ruby and Rails worlds.
But back to your point. You’re right. C like programming language isn’t necessarily easy, and far cry from good. I have introduced scheme to some people who don’t know programming at all through “How to Design Program” from MIT. And they learned fast and enjoyed them a lot. Since most of the perquisites learnt from middle school. (Those who failed you must be introducing another specific wrong book, you know it )
For those “niche” languages (compared to Java), an experienced but only a Java programmer would be uncomfortable when he tries to use them. That does not mean Java is simple (consider invariant and covariant etc). But he needs to forget what he familiar with, and start from scratch.
Same thing happens to me every time I tried to learn iOS development. I found it’s pretty annoying because there’s to many differences from typical development. And I was so bored to recite those buttons every time. But iOS is not hard and actually it is pretty friendly to most people.
The elixir syntax is what almost puts me off of elixir though, it is just so incredibly noisy and hard to read compared to better syntax (even Erlangs is far better), but then I did not come from the Ruby world either. The syntax is just so bad and makes maintenance such a nightmare compared to alternatives…
Oh right, that reminds me, I need to make a new topic soon about something…
Preferring the familiar while “natural” has become a dangerous liability in this business. People need to be much more self-aware when they are gravitating towards something simply because it is familiar and compensate for that tendency in the same way they need to compensate for being overly cautious about the unfamiliar (keep your mind open — but not so open that your brain falls out).
Something being familiar/unfamiliar should no longer be an asset/liability.
“Syntax is irrelevant” works both ways. What any individual considers reasonable is mostly subjective. Unfortunately familiarity does impact how we look at things. So an OCaml mind will have an easier time scanning (“pattern matching”) Bucklescript code while an ESNext mind will have an easier time scanning ReasonML code.
Now granted a cleaner/less noisy syntax should be easier to scan once one gets familiar with it but for the time being we’re in a period of pandering to familiarity:
- Elixir to make Erlang look like Ruby (… I know there are the macros …)
- JSX to make function calls look like markup
- ReasonML to make Bucklescript look like ESNext
One thing I see working against Bucklescript is the lack of quantity of documentation/educational material. OCaml content is a bit slim to begin with and that applies to Bucklescript even more so. In my view the body of content for ReasonML is growing at a much faster pace.
Which fantastic changes? You said they did all just about super rare corner cases?
And Phoenix (which you can’t use from Erlang). Don’t forget how awesome Phoenix’s PubSub and the corresponding JS client are.
I think you are in the minority
A lot of people came to Elixir precisely because they liked the syntax. Some might argue Elixir’s popularity is in no insignificant part down to the large number of Ruby folk who came over to it, so whether one likes it or not, it’s difficult to deny the role it has played in the success of Elixir
I love what some folk said when Elixir was born - that “Erlang and Ruby had a baby - and it wasn’t a mistake!”
I know people talk of familiarity, but I don’t think that’s the whole story. I did not come to Elixir primarily because its syntax was like some other language - because the language itself is irrelevant - I came to Elixir because I liked the syntax… it just happens to be like Ruby’s.
Not sure if that makes sense but I know what I mean
What I’m saying is, if there was no Ruby today and Elixir looked exactly it does today, I would still choose it over any other language in the same space (because the syntax of those is either too convoluted or too sparse for me - i.e not to my taste).
We should probably split these posts into the Syntax Discussions thread, otherwise it could go on for years
Just a couple of cleanups, like I find
# as an operator a bit disturbing in OCaml…
They could be written in Erlang though, parse transforms are whole module macros, and someone could indeed make an elixir-like macro system in those too (hmm, I wonder if anyone has yet…).
Heh, there are more people here than you’d expect that are not a fan of such noisy syntaxes, I’m just the squeaky wheel.
/me squeaks on
I came to elixir because mix and macros. They should be talked up more, especially if you want erlangers to come.
Hmm, isn’t there a thread for that around somewhere?
You do a great job of that as well
I really really like them!
AFAIK plug relies a lot on code generation, so even if they could have been written in Erlang it would probably be quite convoluted. And the important fact is that it was indeed written in Elixir, so if you want to use it you must use Elixir xD
Making parse transforms was not really hard at all, just the AST was not as uniform as elixirs pretty AST, but it could easily have been done (heck, the pipe operator of a form was implemented as a parse transform in Erlang ).
But yep, if written in Erlang it could have been used anywhere, if written in elixir then only elixir until someone writes an Erlang parse transform that can transform the Erlang ast to elixir AST and back again, which is doable.