Common Lisp has had multiple dispatch for decades. Yet another Lisp feature "taken" by another language - why not just start with a Lisp and improve it (e.g. Typed Racket, for performance) rather then repeatedly creating new languages and just adding a tiny piece of Lisp to them each time?
That is how Julia started. In the early days it was a scheme reader macro. You can still run `julia --lisp` to get a scheme prompt since the frontend is still written in it. Obviously lots of improvements have happened since then. Julia itself also feels a lot like a lisp, since Jeff is a huge fan, but of course people get hung up on the syntax.
It's nice that you can write Julia in a more Lispy way, but if you did that you'd probably be one of the only Julia users did so, and your code would not be readily understandable or accpetable to the rest of Julia's users and if you wanted to integrate other Julia code in to your own you'd be stuck with having to use the more Python-like syntax that the vast majority of Julia code is written in.
In short, the Julia ecosystem is not a Lisp ecosystem.
If you wanted Lisp, you'd be far better off using a real Lisp to begin with, so you can unreservedly participate in an entire Lisp ecosystem, instead of using a language that hides its Lispyness behind a Python-like syntax.
Having a language that hides it's lispness behind a python-like syntax can be good for the lisp community though, even if they don't use them. People do have prejudice against those parenthesis, so having an entry point that is "Python-like" (the most popular language for beginners and non programmers) that can still teach the core features of Lisp (everything is an expression, sort of easy AST manipulation, macros, parts of CLOS like multiple dispatch) will only help people appreciate the languages it was inspired on. And possibly they'll also feel the limitations of non sexp macros and decide to actually move to racket or common lisp to free themselves from those restrictions once they become aware of them.
Possibly those people will even do something like Clojure for the Julia compiler (a mature version of [1]), with an entire community around it so you don't have to worry about doing "unacceptably lispy" code (and it will certainly interop much better than Clojure and Java).
The reason is pretty clear. Mainstream programmers are just allergic to Lisp syntax.
They don't like all the parenthesis, and want a more Algol-like syntax (which, these days, and especially for the users who Julia is trying to attract, means a more Python-like syntax).
Lisp for a lot of developers also has an old, stale feel to it. Programming is dominated by fads, and most programmers (especially younger ones) want instead to chase the new shiny.
Decades ago, I read that there were already something like 4,000 languages. I expect in another couple of decades there'll be 4,000 more, with every new generation of developers eager to jump on the bandwagon of yet another new language.
Python, once the new kid on the block dethroning Perl, is now itself considered to be kind of old and stale, so people are looking for the new thing. Maybe Julia is it!
This is an issue for me. Although I find the lisp idea beautiful, my programming usually has some relation to mathematics, to equations. In lisp, math just doesn’t look like math. Julia goes the opposite way: it's use of Unicode for identifiers and such things as allowing juxtaposition for multiplication (when not ambiguous) make math look more like math than in any other language.
I do like the the option of using unicode symbols in Julia, but this need not be thought of as only a language feature.
Emacs allows you to substitute any text for any other when viewing a document, so you can pretty much do the same in Emacs for any language.
I did this when editing LaTeX papers full of logic symbols, which Emacs would display as the symbols themselves rather than as the underlying LaTeX markup.
It could do the same for Lisp or any other language.
I believe the bigger problem is that macros are too powerful. This leads to that every project becomes its own DSL, which is not compatible with other projects. So code sharing/ availability of tested libraries is low. This leads to low adoption rate.
Of course if you want to build your own (mega-) fortress all by yourself, Lisp is the language to go to. Most people and stakeholder prefer not to.
Yes, common lisp has certainly had multiple dispatch for decades. I think what makes Julia interesting is that the Dispatch Ratio and reuse is significantly higher in Julia than in other languages with multiple dispatch. Some of that is certainly attributable to the ways in which Julia differs from a lisp.
As I mention in the article. Note that Julia is in a sense lisp-based, and you can easily see the AST of your functions. You can say +(a, b, c) in Julia, for example.
Don't fight the universe, common lisp is too old for the mainstream to care, you can argue the same for es6, python, php .. it was all ridiculously bad and evolved by adding old ideas.
If you want to make CL exist in a commercial driven world.. make a successful CL business, that's the only thing this soil understands.
ps: viaweb was ages ago, it was cool and famous and world didn't care. Social structures are odd and people want to belong to their own cult, php, js, python were a 'better' fit for the uneducated people of that time, now they are the world and still only care about their own little world. Until they get a new idea, which they now see the value of and will integrate them shamelessly. CL nowhere to be found. It's a sad fact of life, CL heads don't have the desire to dominate, so their language features will be assimilated silently.
This might sound harsh, but Common Lisp fans should stop whining about what everybody else is doing and start making some killer apps to bring back some life into their language. Hearing all about Lisp's past glories is far less convincing than working code. It's just off-putting to hear complaints about what someone else did. As always in free software, the one who puts in the hours gets to call the shots.
Please don't take HN threads further into programming language flamewar. I realize that you're trying to defend something good, but good intentions don't remove the duty to take out name-calling and swipes.
There's a psychological paradox at play. Many idealistic lispers want a lot of things but they don't play the current game, they (I can include myself partially) care more about the tool than the product and it just dies a quick death.
For this to happen they have to turn their view of lisp from beauty to an effective tool to win on pragmatic points: time to develop, number of bugs, ease of adaptability. CL has a hammer for all this points but you have to see the field that way and produce things.. well basically 'less is more' vs 'perfectionism'
As a huge Lisp fan (though more of Scheme than Common Lisp), I kind of agree.
If a Lisper had come up with Jupyter notebooks before Python did, they could have captured the interest of academia.
If they'd come out with a Ruby On Rails framework before Ruby did, they could have made inroads in to the web development community.
That is, of course, if you could somehow get developers to embrace all the parenthesis, which seem to be an albatross around Lisp's neck that it can never shake.
Don't get me wrong, I love org, but this is really not nearly the same as Jupyter notebooks.
Jupyter notebooks are web based, and only require a web browser to use. That's not the case for org.
Using org effectively also means using Emacs, which is a high barrier of entry for most people.
Jupyter notebooks have no such requirements, and anyone can get rolling by just installing some packages and opening a web browser.
Jupyter notebooks are also really polished, while org is more bare bones visually.
Jupyter notebooks also have all these tools integrated in to it (all the graphing and inline image display tools are particularly appealing)
Yes, you could potentially do all of these with org, but it'd take way more knowledge and setup than is required for Jupyter notebooks.
If something as visually appealing, powerful, and easy to set up and use for people who don't know Emacs then it'd have a chance of getting widespread adoption. But that's not org.
It's better. Already serialized. Can be kept under version control. Can be shared between people without needing to signup for anything. And as already stated, code is automatically extractable.
Notebooks are only a thing because you don't need to install anything on work laptops and get around terrible IT policies.
> This might sound harsh, but Common Lisp fans should stop whining about what everybody else is doing and start making some killer apps to bring back some life into their language.
They can't. They are all busy implementing another Lisp in Lisp.
