Imba – A friendly full-stack language(imba.io)
imba.io
Imba – A friendly full-stack language
https://imba.io/
101 comments
[deleted]
[deleted]
I’ve been building all my projects with Imba for the past few years, I love it.
- TaskTXT - Plain text todos and tasks with timers https://www.tasktxt.com
- ReadyRunner - GPT chat for desktop https://www.readyrunner.ai
- Chonky Menu Re-Creation - Breakdown of a fancy menu UI https://www.nathanmanousos.com/posts/chonky-menu
I’ve made several videos about Imba too:
- Building a counter in 49 seconds: https://www.youtube.com/watch?v=8XS5q9xhaMc
- Video timeline UI: https://www.youtube.com/watch?v=GbKTEqmCAJM
- All of my Imba videos here: https://www.youtube.com/playlist?list=PLYxkh3w952l5cwxYLcCsd...
I made the (free) official course on Scrimba: https://www.imba.io/learn/imba
Which is also on YouTube: https://www.youtube.com/watch?v=8DcOgcCy7zs
I understand that Imba is not appropriate for everyone and every project but I encourage you not to dismiss it. One are where it is clearly valuable is in building prototypes and side projects.
- TaskTXT - Plain text todos and tasks with timers https://www.tasktxt.com
- ReadyRunner - GPT chat for desktop https://www.readyrunner.ai
- Chonky Menu Re-Creation - Breakdown of a fancy menu UI https://www.nathanmanousos.com/posts/chonky-menu
I’ve made several videos about Imba too:
- Building a counter in 49 seconds: https://www.youtube.com/watch?v=8XS5q9xhaMc
- Video timeline UI: https://www.youtube.com/watch?v=GbKTEqmCAJM
- All of my Imba videos here: https://www.youtube.com/playlist?list=PLYxkh3w952l5cwxYLcCsd...
I made the (free) official course on Scrimba: https://www.imba.io/learn/imba
Which is also on YouTube: https://www.youtube.com/watch?v=8DcOgcCy7zs
I understand that Imba is not appropriate for everyone and every project but I encourage you not to dismiss it. One are where it is clearly valuable is in building prototypes and side projects.
Thanks for sharing, this is cool to see. Do you use electron to wrap an Imba app for desktop?
Yes, via https://www.todesktop.com/ which makes it very easy.
Previously: https://news.ycombinator.com/item?id=10091454
Imba was actually forked from CoffeeScript... hopefully, they've managed to avoid all the downsides.
Imba was actually forked from CoffeeScript... hopefully, they've managed to avoid all the downsides.
Imba powers Scrimba which is an incredibly cool platform with interactive coding screencasts: https://scrimba.com/
Which includes learning Imba: https://scrimba.com/learn/imba
Confusingly, they seem to be using the term “tag” for what is really an HTML element or component.
(E.g. “<div>…</div>” in HTML is not a tag, it’s an element delimited by one starting and one ending tag.)
(E.g. “<div>…</div>” in HTML is not a tag, it’s an element delimited by one starting and one ending tag.)
This is a fairly common, and I believe correct, use of the word "tag". The MSDN reference uses the term in a similar manner (as do countless other definitive resources and tools). Consider the first sentence of the MSDN's page on HTML elements:
> This page lists all the HTML elements, which are created using tags.
-- https://developer.mozilla.org/en-US/docs/Web/HTML/Element
The "tag" is the word between the "<" ">".
> This page lists all the HTML elements, which are created using tags.
-- https://developer.mozilla.org/en-US/docs/Web/HTML/Element
The "tag" is the word between the "<" ">".
Things are often messy IRL - especially when they happen organically such as the meaning of words (try defining what is a sea and a lake with no exceptions).
I remember ‘tag’ was used colloquially in the ‘90s - this was before Javascript was popular. When DOM became a thing in 1998, the definition was more formalized to be consistent across JS and HTML. As things stand, tags usually come in pairs, except for a few (such as <br/>?). An element is now defined as both tags + the content.
I believe this evolution happened organically, and many people still prefer the use of ‘tag’ to mean an ‘element’ for conciseness.
Update: edited for clarity
I remember ‘tag’ was used colloquially in the ‘90s - this was before Javascript was popular. When DOM became a thing in 1998, the definition was more formalized to be consistent across JS and HTML. As things stand, tags usually come in pairs, except for a few (such as <br/>?). An element is now defined as both tags + the content.
I believe this evolution happened organically, and many people still prefer the use of ‘tag’ to mean an ‘element’ for conciseness.
Update: edited for clarity
Words naturally become overloaded.
It helps lower the barrier to understanding a new concept because you have an existing concept to leap from and language to use. It comes at the cost of precision.
The words `node`, `class`, and `tag` in particular are used all over the place.
There's a reason for the joke that the two hardest things in software are cache invalidation and naming things.
It helps lower the barrier to understanding a new concept because you have an existing concept to leap from and language to use. It comes at the cost of precision.
The words `node`, `class`, and `tag` in particular are used all over the place.
There's a reason for the joke that the two hardest things in software are cache invalidation and naming things.
Your quote doesn’t support your argument. Yes, elements are created out of tags (plus content). But a single tag generally does not constitute an element, except for self-closing tags like <br>.
I agree that it’s a somewhat common mistake to refer to HTML elements as “tags”, but it’s unfortunate to bake that mistake into a language.
I agree that it’s a somewhat common mistake to refer to HTML elements as “tags”, but it’s unfortunate to bake that mistake into a language.
If it's common enough it's no longer a mistake, it's just how the English language is. If everyone understands each other, then insisting on a "more correct" usage is just pedantry.
Can you provide a concrete example of a case where this usage would be confusing?
Can you provide a concrete example of a case where this usage would be confusing?
I think it’s better framed as an imprecision than a mistake. The naming language has evolved in common real world usage, in the “can’t put the toothpaste back in the tube” sense of language evolution. As such, it isn’t (any longer) incorrect, only imprecise. It isn’t even necessarily ambiguous, because the usage context tends to disambiguate it.
There are certainly cases where the precision matters, but I think this is only one such case if the imprecision causes misunderstanding by users of the Imba language.
There are certainly cases where the precision matters, but I think this is only one such case if the imprecision causes misunderstanding by users of the Imba language.
You can't really have a "mistake" unless there's an authoritative source and standard that everyone agrees to use.
Language evolves with use, and being really passionate about an idealized standard in your head doesn't somewhat materialize it as the "correct" way.
Language evolves with use, and being really passionate about an idealized standard in your head doesn't somewhat materialize it as the "correct" way.
There is an authoritative source – the HTML specification.
The HTML5 spec does not take a stance on how the words "tag" and "element" should be used in day-to-day speech or in other projects, it just distinguishes them for the purpose of the spec. A specification has to be very precise in its wording, but that doesn't mean we all do all the time.
Given that there is no end tag in Imba, that's not especially confusing—there's a one-to-one relationship between tags and elements.
Also, colloquially it's very common to use "tag" because to refer to both, because "element" is longer, including in pretty formal places like Shopify's API:
https://shopify.dev/docs/api/admin-rest/2023-07/resources/sc...
Also, colloquially it's very common to use "tag" because to refer to both, because "element" is longer, including in pretty formal places like Shopify's API:
https://shopify.dev/docs/api/admin-rest/2023-07/resources/sc...
> there's a one-to-one relationship between tags and elements.
There’s not a one-to-one relationship between HTML tags and elements, so if there is a one-to-one relationship between Imba tags and HTML elements, it follows that there is not a one-to-one relationship between Imba tags and HTML tags — that’s what’s confusing.
There’s not a one-to-one relationship between HTML tags and elements, so if there is a one-to-one relationship between Imba tags and HTML elements, it follows that there is not a one-to-one relationship between Imba tags and HTML tags — that’s what’s confusing.
By your own insistence a tag is simply a syntax construct, so I'm not sure why it matters that there's a one-to-one relationship between Imba tags and HTML tags. All that matters is that there's an obvious mapping from one to the other (and preferably back), which there is.
Also, I want to re-emphasize that most people use the words "tag" and "element" interchangeably when talking about written HTML. That may be a pet peeve of yours, but it's common enough that it's not an incorrect usage.
Also, I want to re-emphasize that most people use the words "tag" and "element" interchangeably when talking about written HTML. That may be a pet peeve of yours, but it's common enough that it's not an incorrect usage.
[deleted]
Yeah, I always called it tag because vim calls them tags.
It seems to make sense with the example. The `tag` keyword defines a tag that is used the same as HTML tags to create an element.
tag Box
css pos:relative
x = 0
y = 0
<self[x:{x}px y:{y}px] @touch.moved.sync(self)> <slot> "box"
tag app
<self[inset:0 d:hflex ja:center]>
<Box[hue:blue]> 'One'Looks interesting. Has anyone used this for something “serious”?
Well it powers https://scrimba.com which looks serious enough. I’ve known about it for the past 6 years, but never had the chance to use it because I’ve only done static websites lately.
I am starting work on an automatic irrigation system that will have a web/PWA frontend and I remembered about Imba which I plan to use this time.
I am starting work on an automatic irrigation system that will have a web/PWA frontend and I remembered about Imba which I plan to use this time.
It was used for https://tasktxt.com, a neat task manager / time tracker that I love
Imba has so many cool ideas.
Anyone knows how development is going with v2?
Anyone knows how development is going with v2?
It is stable and features are done, but docs needs to be improved.
Was partial hydration ever implemented?
Seems novel. Does anyone know if any comparable technologies exist?
Civet[1] is a similar idea for a programming language based off of TypeScript and 99% ES compatibility.
[1]: https://civet.dev
[1]: https://civet.dev
Some of the syntactic sugar is very nice, but the overhead of transpiling that to TypeScript to get type checking, then to JS for runtime seems excessive.
I remember Opa http://opalang.org/ tried something similar at the time when MongoDB was new and modern.
Those were the days :)
I believe that we made a few mistakes with Opa, though. The slicer (the component of the compiler that decided which code should be compiled to client and whic hto server) was a great idea, but it came with considerable pitfalls in terms of security. Since then, I have concluded that too much multi-tier magic is actually a bad thing.
If I were to start a new version of Opa, I would probably force developers to split their code manually between client, server, database and location-independent (presumably by putting stuff in distinct directories). This would be much easier to read/audit. But at this stage, this raises the question of whether an entirely new language is really useful. Why not simply do it with a sufficiently smart toolchain based on TypeScript or any language that compiles to wasm?
Source: I did not start the project but I led the design and implementation.
I believe that we made a few mistakes with Opa, though. The slicer (the component of the compiler that decided which code should be compiled to client and whic hto server) was a great idea, but it came with considerable pitfalls in terms of security. Since then, I have concluded that too much multi-tier magic is actually a bad thing.
If I were to start a new version of Opa, I would probably force developers to split their code manually between client, server, database and location-independent (presumably by putting stuff in distinct directories). This would be much easier to read/audit. But at this stage, this raises the question of whether an entirely new language is really useful. Why not simply do it with a sufficiently smart toolchain based on TypeScript or any language that compiles to wasm?
Source: I did not start the project but I led the design and implementation.
Small world :) I love when these things happen!
I still remember the sunny day I was at a Starbucks table with a huge americano and my first second-hand MacBook, stumbling upon Opa and thinking "what a great idea!".
It looked so simple, intuitive, and the fact that I could write both front and back end in the same file was amazing!
I never got to do a large project with it, so I didn't notice the pitfalls you are talking about. But I want to thank you and your team for making me understand that web dev does not have to be painful if you choose tools that you like.
I still remember the sunny day I was at a Starbucks table with a huge americano and my first second-hand MacBook, stumbling upon Opa and thinking "what a great idea!".
It looked so simple, intuitive, and the fact that I could write both front and back end in the same file was amazing!
I never got to do a large project with it, so I didn't notice the pitfalls you are talking about. But I want to thank you and your team for making me understand that web dev does not have to be painful if you choose tools that you like.
Thanks :)
While I think that we made some mistakes in the design, I'm surprised that, to this day, there isn't any widely-used language/toolkit/framework [1] that seems to do as well.
[1] Alright, there's GWT, which does pretty well with different tradeoffs. But for some reason, it seems to be extremely niche. The website mentions that "thousands of developers" use it.
While I think that we made some mistakes in the design, I'm surprised that, to this day, there isn't any widely-used language/toolkit/framework [1] that seems to do as well.
[1] Alright, there's GWT, which does pretty well with different tradeoffs. But for some reason, it seems to be extremely niche. The website mentions that "thousands of developers" use it.
Opa was ahead of its time by at least 10 years. Have you seen Electric Clojure [0]?
[0] https://github.com/hyperfiddle/electric
[0] https://github.com/hyperfiddle/electric
Looking at it right now, thanks!
> If I were to start a new version of Opa, I would probably force developers to split their code manually between client, server, database and location-independent (presumably by putting stuff in distinct directories)
Exactly how GWT worked (and still does!). there's a server/, client/ and shared/ directories... but all code is written in Java.
Exactly how GWT worked (and still does!). there's a server/, client/ and shared/ directories... but all code is written in Java.
I may have involuntarily stolen this idea from GWT at some point during the last 15 years or so :)
For the new version of Opa, seems like you are reinventing COBOL:
A COBOL program basically divided into the following four divisions: Identification division. Environment division. Data division. Procedure division.
A COBOL program basically divided into the following four divisions: Identification division. Environment division. Data division. Procedure division.
That's entirely possible. I'm probably in the process of graduating to graybeard, because I've been witness to a few cycles in computer science already :)
i was rooting for opa! it was pretty sad when it died. ocsigen does do a lot of the same thing in theory, but in practice i found it really hard to learn and eventually gave up.
Thanks :)
Now that OCaml has gained algebraic effects, I suspect that it should be feasible to reimplement Lwt to use these instead of monads, which should make writing async code much easier, which in turn should make Ocsigen much easier.
I don't know if that's in the books, though.
Now that OCaml has gained algebraic effects, I suspect that it should be feasible to reimplement Lwt to use these instead of monads, which should make writing async code much easier, which in turn should make Ocsigen much easier.
I don't know if that's in the books, though.
Hey, we at Electric Clojure believe our model is secure, can you say more about the problems you encountered?
Well, it very much depends on your definition of "secure". The OWASP top 10 were pretty easy to eliminate entirely with a language that supports static analysis, but we accidentally introduced a couple more:
1. the model made it hard for the developer to know what data was flowing from the server to the client (e.g. are we leaking a secret as part of a closure?)
2. on the web, you can only (mostly) trust the code that's executed on the server, as the client could have been patched to be running arbitrary malicious code, but the syntax of Opa made it very easy to forget that some of the code was living in this client-side warzone, which in turn could lead to serious security vulnerabilities;
3. when you patch code, especially in auxiliary functions, it's easy to lose track of where it's going to be executed, which means that it's easy to accidentally add a secret leak/capability leak.
We tried many things to reduce the problems, and eventually settled on removing most of the intelligence from the slicer, to make it more predictable, and replacing most of the slicer's tier inference with annotations, to make sure that the developers actually paid attention to the decision. I believe that this wasn't sufficient.
1. the model made it hard for the developer to know what data was flowing from the server to the client (e.g. are we leaking a secret as part of a closure?)
2. on the web, you can only (mostly) trust the code that's executed on the server, as the client could have been patched to be running arbitrary malicious code, but the syntax of Opa made it very easy to forget that some of the code was living in this client-side warzone, which in turn could lead to serious security vulnerabilities;
3. when you patch code, especially in auxiliary functions, it's easy to lose track of where it's going to be executed, which means that it's easy to accidentally add a secret leak/capability leak.
We tried many things to reduce the problems, and eventually settled on removing most of the intelligence from the slicer, to make it more predictable, and replacing most of the slicer's tier inference with annotations, to make sure that the developers actually paid attention to the decision. I believe that this wasn't sufficient.
thanks, in #3 what is “patch code”?
I mean during a refactoring.
I don't know how much of this applies to Electric Clojure, mind you, that's only my experience from Opa.
I don't know how much of this applies to Electric Clojure, mind you, that's only my experience from Opa.
it's actually very old! Even older than React
I wonder why this didn't take off?!
This is so much better than React or svelte, no state management, built-in tailwind and more concise and expressive!
This is so much better than React or svelte, no state management, built-in tailwind and more concise and expressive!
What do you mean by ‘no state management’ and why is it a good thing?
You don't need any special state management tools like "stores" or "setState" you can just use regular variables.
let count = 0
tag Counter
<self @click=(count++)> "Count is: {count}"
imba.mount <Counter>, document.bodyHow will it work if I put 2 counter components on one page?
If it’s just using global variable for state then it will be shared between component. You can do the same thing in React, it’s just a bad idea.
If it does some magic under the hood to convert regular variables into something different like Svelte pre-5.0 (which Svelte decided to make more explicit in 5.0), then could you point me to docs describing it, I’m curious which approach they took with this.
If it’s just using global variable for state then it will be shared between component. You can do the same thing in React, it’s just a bad idea.
If it does some magic under the hood to convert regular variables into something different like Svelte pre-5.0 (which Svelte decided to make more explicit in 5.0), then could you point me to docs describing it, I’m curious which approach they took with this.
the point is there is no need for "reactivity" constructs. Organize your "state" the way you want.
tag App
it doesn't have to be anything. You're free to organize your code as you wish: colocate, in a different file ... the compiler doesn't transform the variable in any way, nor does it track its "mutation", it "just" "rerenders" on every change. And it's super fast too!
tag App
counter = 0
<self>
<button @click=counter++> "{counter}"
it doesn't have to be anything. You're free to organize your code as you wish: colocate, in a different file ... the compiler doesn't transform the variable in any way, nor does it track its "mutation", it "just" "rerenders" on every change. And it's super fast too!
The tricky part here is to determine what should trigger the rerender.
If you look on the linked page under the "Styling Evolved" section. It appears variables are scoped to the component instance. In the example given each clock has its own variables, even though it is individually set to a different UTC.
In that case the count variable should be moved into a property of the tag. I just like putting it outside the tag because it really drives home "its just a variable".
tag Counter
count = 0
<self @click=(count++)> "count: {count}"Of course you manage state with Imba. There's no reactivity though.
It seems that main focus of Imba is code compression. I wonder, at which point they decided that they need a new language for that. I’ve seen things similar to ‘d:hflex ja:center’ many times, and it was achieved by writing a component that translates short props into CSS. I wonder, if there is a popular React library of such components (the ones I’ve seen were internal).
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.
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.
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.
This looks interesting. Can this be easily embedded? Could I let my users do some minor customization of my app by giving them an Imba editing window?
Currently thinking about something like Workerbox https://news.ycombinator.com/item?id=33673047
Currently thinking about something like Workerbox https://news.ycombinator.com/item?id=33673047
I did use Imba on some of my side projects.
Easy to get most things up and kind of fun to work with. Has many cool ideas as some one pointed out.
The only web framework worth learning and getting into. 100x better than react, svelte and vue.
Thanks for sharing I was looking at something new to do tomorrow instead of taking time off
Does it support SSG yet? This was a deal breaker for me when I assessed it a year ago.
Haven’t heard about Imba for years! Completely forgot about it.
I wish haxe would invest into something like this
[deleted]
lofaszvanitt(1)
_"Is it imba, or do I suck?"_
Do we really need more languages?
Do you think in the year 2100 we'll still write Python and C? From that point of view, sounds like we should be happy with the status quo and not create anything more.
Imagine if that was the case in 1991 when I'm sure someone else said "Do we really need Python and other languages? Isn't C, Lisp, Fortran enough?" We would have none of the nice ergonomics that current programming languages provide.
Imagine if that was the case in 1991 when I'm sure someone else said "Do we really need Python and other languages? Isn't C, Lisp, Fortran enough?" We would have none of the nice ergonomics that current programming languages provide.
I just think making a new language (and therefore new ecosystem) just to make slight changes to syntax is a total waste of time personally.
Unless you really do something profoundly different in terms of type system, memory management etc, you're just making a new thing to learn and an extra nuisance to use if its toolchain sucks. "JavaScript but looks kind of different" doesn't clear that bar for me. We learned that from CoffeeScript.
I don't have any problem with people making languages for fun but to me if you're asking people to deal with the hassle of a new language it better be for a good reason.
Unless you really do something profoundly different in terms of type system, memory management etc, you're just making a new thing to learn and an extra nuisance to use if its toolchain sucks. "JavaScript but looks kind of different" doesn't clear that bar for me. We learned that from CoffeeScript.
I don't have any problem with people making languages for fun but to me if you're asking people to deal with the hassle of a new language it better be for a good reason.
I seem to haven't learned that yet, as I still use Coffeescript heavily and I'm happy it exists.
It's only one data point, but if it makes even just a few people happy, it already has enough reasons to exist.
Couldn't be further from the truth. The creators build a language for their project (Scrimba.com) and had the nice idea to share it with us. If we find it compelling, we are allowed to use it, give feedback, and contribute to its development if we want it to grow.
I personally can only feel gratitude towards these people.
It's only one data point, but if it makes even just a few people happy, it already has enough reasons to exist.
> a new thing to learn and an extra nuisance to use if its toolchain sucks
> if you're asking people to deal with the hassle of a new language it better be for a good reason
Couldn't be further from the truth. The creators build a language for their project (Scrimba.com) and had the nice idea to share it with us. If we find it compelling, we are allowed to use it, give feedback, and contribute to its development if we want it to grow.
I personally can only feel gratitude towards these people.
Sure, people are welcome to use it. I just personally think it's a bad idea.
That's why I created https://civet.dev as a personal slight against chaptrick.
civet looks really nice, especially single argument lambda and spreads in any position
For whatever it's worth, this is interesting as someone who (a) wants to learn to build UIs, (b) doesn't care about getting a front-end job (so I don't care about learning React or whatever to get me a job) and (c) absolutely hates the Javascript bundled-compiling-insanity hell that is modern front-end.
I will absolutely consider any new simplified language and new ecosystem over this garbage that people only use because its pushed by FAANG companies to have enough labour to keep costs down.
So yeah, if you're a front end dev, maybe not worth it, but there are other demographics than hyper-specialized next/nuxt/react/svelte developers who MUST have the most artistic control possible to create little doodads and whatever.
I will absolutely consider any new simplified language and new ecosystem over this garbage that people only use because its pushed by FAANG companies to have enough labour to keep costs down.
So yeah, if you're a front end dev, maybe not worth it, but there are other demographics than hyper-specialized next/nuxt/react/svelte developers who MUST have the most artistic control possible to create little doodads and whatever.
You need to do the bundled-compiling-insanity hell to use this language.
The question isn't what "slight changes to syntax" the language makes now -- it's what the language can develop into over time. Python 30(!) years ago wasn't the same as Python today.
A small community of people might be interested enough in a language to keep it going until it develops into something interesting, or they might not. It's pretty near to classic darwinian evolution. You don't have to pay attention to every new language, and that's okay. If others do, and it grows into something you're interested later, pay attention to it then. For now, you can ignore it.
A small community of people might be interested enough in a language to keep it going until it develops into something interesting, or they might not. It's pretty near to classic darwinian evolution. You don't have to pay attention to every new language, and that's okay. If others do, and it grows into something you're interested later, pay attention to it then. For now, you can ignore it.
CoffeeScript brought more to the table than just syntax changes. Some of the recent niceties we have in JavaScript today were influenced by it.
Also, recall that the whole JavaScript ecosystem was kind of a mess when CoffeeScript was created. ES5 happened at around the same time and its predecessor, ES4, had gone nowhere. I don't remember polyfills really being a thing and you couldn't even use `forEach` reliably. Every JS question on StackOverflow used jQuery in the response whether or not you wanted it.
Also, recall that the whole JavaScript ecosystem was kind of a mess when CoffeeScript was created. ES5 happened at around the same time and its predecessor, ES4, had gone nowhere. I don't remember polyfills really being a thing and you couldn't even use `forEach` reliably. Every JS question on StackOverflow used jQuery in the response whether or not you wanted it.
I've been in the computer programming game for about thirty-five years, FWIW, and my considered opinion is that we should have all just used Lisp.
Programming languages are video games for smarties. There is no good reason to use anything other than Lisp.
(I'm not even a Lisp programmer. I wrote a Scheme program last month and that's about it. I love Python! But it never should have existed.)
(The interesting question is, did these later non-Lisp PLs have to exist to provide the information that shows that they shouldn't?)
Programming languages are video games for smarties. There is no good reason to use anything other than Lisp.
(I'm not even a Lisp programmer. I wrote a Scheme program last month and that's about it. I love Python! But it never should have existed.)
(The interesting question is, did these later non-Lisp PLs have to exist to provide the information that shows that they shouldn't?)
> Do we really need Python and other languages? Isn't C, Lisp, Fortran enough?
Well, actually... Those days we already had Prolog, Miranda, ML, Smalltalk... Lisp was already doing stuff even today's languages are just starting to do...
I don't know, but I kind of think that yes, that was quite enough... imagine if all the effort that went into Java/Swift/Python/JS had been put into those great languages.
Well, actually... Those days we already had Prolog, Miranda, ML, Smalltalk... Lisp was already doing stuff even today's languages are just starting to do...
I don't know, but I kind of think that yes, that was quite enough... imagine if all the effort that went into Java/Swift/Python/JS had been put into those great languages.
I wouldn't be surprised if there is still a version of C in the year 2100, that can compile code written in the year 2060 or maybe even 2023.
That language might be mostly generated as a form of portable assembly by whatever new language is fashionable in 2100, although humans might still be writing in that language directly, possibly for IOCCC.
That language might be mostly generated as a form of portable assembly by whatever new language is fashionable in 2100, although humans might still be writing in that language directly, possibly for IOCCC.
Yes. Modern frontend apps consist of a ton of data flow bookkeeping which is something compilers are well suited for.
Programming languages are like plastics: there are 100s of 'em, each with their own characteristics, strenghts & weaknesses. Every single 1 of them has some niche in which they're better (or at least, preferred) over the others. Sometimes for historical reasons.
That said, like plastics I'm pretty sure we could get by with 10..20 (max) different ones. And those would be nicer to use if all development effort were spent on them vs. spread out over all the other ones.
But hey, who am I to tell someone to stop using / working on language x, y or z? Or which ones to pick as standard?
That said, like plastics I'm pretty sure we could get by with 10..20 (max) different ones. And those would be nicer to use if all development effort were spent on them vs. spread out over all the other ones.
But hey, who am I to tell someone to stop using / working on language x, y or z? Or which ones to pick as standard?
Show HN: My free course for learning Imba - https://news.ycombinator.com/item?id=31493263 - May 2022 (14 comments)
Show HN: Imba – I have spent 7 years creating a programming language for the web - https://news.ycombinator.com/item?id=28207662 - Aug 2021 (345 comments)
Show HN: Imba 2.0 – The JavaScript Alternative by Scrimba (YC S20) - https://news.ycombinator.com/item?id=28196158 - Aug 2021 (5 comments)
Imba – Create complex web apps with ease - https://news.ycombinator.com/item?id=20487972 - July 2019 (36 comments)
Imba the new JavaScript based language having Python,Ruby inspired syntax - https://news.ycombinator.com/item?id=18487942 - Nov 2018 (3 comments)
IMBA the new programming language for web apps - https://news.ycombinator.com/item?id=17505816 - July 2018 (2 comments)
Imba – 10 times faster than React - https://news.ycombinator.com/item?id=14837231 - July 2017 (1 comment)
Imba: A new programming language for web apps - https://news.ycombinator.com/item?id=10901054 - Jan 2016 (128 comments)
Imba - create complex web apps with ease! - https://news.ycombinator.com/item?id=10863827 - Jan 2016 (8 comments)
Imba – A new programming language for the web - https://news.ycombinator.com/item?id=10091454 - Aug 2015 (171 comments)