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! ^.^;
2 Likes
BuckleScript 3.0 has just released!
3 Likes
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…
1 Like
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
- etc.
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.
1 Like
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?
2 Likes
Yep, https://elixirforum.com/t/discussion-about-syntax-preferences-split-posts/3436 
You do a great job of that as well 
I really really like them! 
2 Likes
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. 
1 Like
Hi All,
My goal is to write offline first, commercial app and have a normal language on frontend with ionic framework 
and with phoenix on backend.
I’ve read a lot about Elm, BuckleScript, Ocaml, PureScript, Svelte etc.
I am wondering between Svelte and BuckleScript, but I am afraid of small community and resources around BuckleScript. I have no experience in building apps also, so it might be another obstacle to get pretty niche technology.
I read a lot of good thinks about BuckleScript, mostly from @OvermindDL1 , but I have still some doubts:
I didn’t find any nice looking application written in BS.
I didn’t find any performance benchmarks compared to popular frameworks ;/
I didn’t find any resources how looks SSR with BS also.
Most of information about BS is from 2017 and older.
Svelte is fast, has SSR, offline support, has no VDOM, it is fully reactive, it seems to me there is more up-to-date resources, but on the other hand Svelte has no strong and static types ;/
@OvermindDL1, @adrianrl, @entire_forum I would be really grateful for your opinion.
Thanks!
I am sure @OvermindDL1 will have a better answer, but I can tell You it’s hard to compare Svelte with BS because they don’t have the same goal…
You might compare Svelte with React, Vue, or any other JS framework
You might compare BS with Babel, or Typescript.
1 Like
Ok, I thought if my goal is to build app, and there are a lot of technologies which makes it easier, then I can compare these, and pick the best for me.
I saw threads where BS was compared with Elm, and Elm is comparable with Svelte, React-Redux and others.
Maybe should I ask for BS-tea vs Svelte?
And You are lucky because BS-tea was writtem by @OvermindDL1 so he might have a better answer.
Picking up the right solution for frontend is a real nightmare… so many choices and You don’t know how long it will last.
You can also add ReasonML to your list, which is the way to write React with BS types…
But I think Web Assembly will change the way we do frontend.
There is razor for dotnet which looks like React in C#. Or Yew, in Rust.
I am waiting to see the next way to do web frontend.
2 Likes
It can’t be emphasized enough that you should be focusing on the fundamentals first: HTML, CSS, JavaScript (ES6+, Browser APIs) and how the web works (HTTP) in general.
Then you can tackle Progressive Web Apps which are “offline first”.
https://codelabs.developers.google.com/dev-pwa-training/
but on the other hand Svelte has no strong and static types
Svelte does intend to support TypeScript eventually. (Personally though I wonder whether TypeScript will in the long term suffer the same fate as CoffeeScript - so I’d be inclined to use it with JSDoc annotations instead).
Web Assembly won’t fundamentally change how the web works, nor what kind of capabilities web browsers have. All of that can be explored now with the JS Browser APIs. What will likely happen is that alternate abstractions on top of all that will continue to proliferate (in the way JS frameworks have), none of them “winning”, making it even more confusing to choose the “right one” or the “right approach”.
2 Likes
