Earlier quoted context omitted.
I currently use Python much more than any other language and regularly advocate for its use as a learning language both for formal education and for self-teaching. That said, I don't think most of the below supports your assertion that "Clojure [could definitely never] steal the machine learning niche back from Python" > Python is easier to learn. I have not seen a learnability comparison between Python and Clojure a…
Well these are the hurdles that Clojure needs to get over. And it's not good enough that Python fails because R and Julia are competing with Python. So is Matlab. So to take the ML pole position, Clojure would need to gain traction beyond all of these. So I don't have a reasonable doubt when I say "Clojure will take not the machine learning niche from Python."
Is Clojure dying, and what has Ruby got to do with it?
231–240 of 261 posts
Re: Is Clojure dying, and what has Ruby got to do with it?
#232Earlier quoted context omitted.
Very unlikely. Incanter is basically dead, so I don't think Clojure is one of the go-to numerical computing platforms. Therefore I just don't see it getting the mind-share required to thrive for these sorts of applications. Besides, at the technical level AI in the age of Lisp was a very different beast than AI today. If you take Eurisko to be the apex of Lisp-based AI, it benefited from code-as-data, dynamism, creat…
Incanter is not the only game in town, FYI.
Re: Is Clojure dying, and what has Ruby got to do with it?
#233Earlier quoted context omitted.
Lisp was invented to produce AI. Machine learning is a better way to produce AI. So in a sense, Machine learning takes the needs for Lisp (in AI) away.
Lisp was invented by the guy who coined the term AI, not for AI. Its popularity in AI circles in the past stems from a) being developed by the same groups of people and b) being well-suited for symbolic computation; something that many mainstream langauges suck about to this day , even though it's nothing AI-specific. ML takes the needs for Lisp more-less in the same way Entity-Component-System architecture takes the…
Lisp was designed for AI programming.
http://www-formal.stanford.edu/jmc/recursive/node1.html
> A programming system called LISP (for LISt Processor) has been developed for the IBM 704 computer by the Artificial Intelligence group at M.I.T. The system was designed to facilitate experiments with a proposed system called the Advice Taker, whereby a machine could be instructed to handle declarative as well as imperative sentences and could exhibit ``common sense'' in carrying out its instructions. The original proposal [1] for the Advice Taker was made in November 1958. The main requirement was a programming system for manipulating expressions representing formalized declarative and imperative sentences so that the Advice Taker system could make deductions.
So it was designed for the 'Advice Talker'. The AI domains were natural language processing and common sense reasoning.
Re: Is Clojure dying, and what has Ruby got to do with it?
#234Oddly, as someone who was reasonably into Common Lisp, what really viscerally turned me off to Clojure was the use of square brackets. This sounds petty but I actually have some rationalization for it. Once you learn to read Lisp (mostly looking at the indentation and ignoring the parens) it's really nice that there's only one kind of delimiter in the language. It allows a lot of easy structure editing with a decent…
What's interesting is that for me Clojure was my first lisp. One of the main reasons I never learned lisp before Clojure was all the parens that made the language impossible to read. Clojure cleans up the "normal" lisp syntax quite a bit, and that made it a lot more palatable. Beauty is in the eye, and all that, but CL code still makes me want to claw my eyes out.
And while I do not like object oriented languages its far more natural to English readers such as myself to write and read things from top to bottom and left to write.
Now of course some FP languages have operators to (Haskell, F#) to allow left to right function application and you could of course make macros in Lisp in whole it doesn't really fix the problem entirely.
You can also of course mitigate the above with judicious use of let expressions but more often than not people inline anyway.
Re: Is Clojure dying, and what has Ruby got to do with it?
#235Earlier quoted context omitted.
Quantity is only one aspect. Structure and ability to mentally parse out patterns matters too. I don't mind Lisps and use Clojure regularly, yet I'd still argue your JS examples are easier to read than the Lisp ones. Heck even Clojure seems to agree, just the simple act of using vectors for various things (ie function parameters) helps with the readability ((fn [a b] (* a b) ) 6 4)
Well, vectors are a workaround for the challenges in creating homeoiconic lists that the JVM understands. And if I'm frank, the JS examples are easy to read because you're familiar with the syntax. When you first started to learn C style syntax, it was likely just as confusing. I've spent a fair bit of time with lisp now, and the parenthesis are no more or less confusing than any of the symbols used in other language…
Re: Is Clojure dying, and what has Ruby got to do with it?
#236Earlier quoted context omitted.
Well these are the hurdles that Clojure needs to get over. And it's not good enough that Python fails because R and Julia are competing with Python. So is Matlab. So to take the ML pole position, Clojure would need to gain traction beyond all of these. So I don't have a reasonable doubt when I say "Clojure will take not the machine learning niche from Python."
I don't think it's likely. The libraries are the real issue. It's not that they couldn't emerge, it's just that they're not likely to emerge out of the current situation.
Look at Torch for example. It has been a well established library, and yet because it uses Lua, its future is bleak. PyTorch, on the other hand, is gaining popularity.
Re: Is Clojure dying, and what has Ruby got to do with it?
#237Earlier quoted context omitted.
I don't really have anything to say about your other points, but the only comparable compile-to-JS tech in your list to ClojureScript is Scala.js. The other options assume you don't see significant value in using the same programming idioms across client and server.
As someone who chose ClojureScript over many of the other compile-to-JS languages without using Clojure on the server, I disagree. Especially if ClojureScript could become more attractive than (or at least have a real solid standing amongst) Elm/PureScript/etc., I could see that being a big boon to Clojure development as well.
That all said, I think all 'piles-to-JS language bets are off in the face of WASM.
Re: Is Clojure dying, and what has Ruby got to do with it?
#238Earlier quoted context omitted.
I can't find the quote for the of me, but it was from Rich Hickey and went something like: "First, you use Clojure to escape Java. Then, you use Clojure to write better Java." I definitely found it to be true. Clojure takes the good parts of Java's OO system.
Doesn't make any sense as Rich makes a big point of having wasted years writing large applications in Java and C++ before discovering Lisp and FP. If anything Clojure is the ultimate anti-OOP which, I think, partly explains its lack of adoption sitting, as it does, on top of a mass of libraries designed with OOP.
I think it was in reference to the java ecosystem, more than "a better way to write java," although I still see it that way.
Re: Is Clojure dying, and what has Ruby got to do with it?
#239Earlier quoted context omitted.
I can't find the quote for the of me, but it was from Rich Hickey and went something like: "First, you use Clojure to escape Java. Then, you use Clojure to write better Java." I definitely found it to be true. Clojure takes the good parts of Java's OO system.
> Clojure takes the good parts of Java's OO system. Such as?
Re: Is Clojure dying, and what has Ruby got to do with it?
#240Earlier quoted context omitted.
There's nothing preventing you from manually doing that when you type the code, but editors and pretty-printers won't know about it. Special-casing them to have "if the car of a list is cond, or this vector was preceded by let, ..., then every second element gets extra indentation if it's on a different line" vs just using the regular list formatting rules just squicks me.
FWIW, running code through machine-formatting is an idea that squicks me enough that I hadn't even considered that you would be trying to do that... :(.