Lucene was mentioned earlier - it, at least, is very good.
I have the same impression about the numerical computation and machine learning libs too.
However, the JVM libraries are well-supported and generally can be trusted to work. For a lot of the wheels I'd rather not reimplement, they're quite useful. I don't think that the Clojure of 2020 will be as reliant on Java, but for now, the JVM libraries are very useful.
I asked: "why is this Java component in the Windows client app?" The answer was that the server was also implemented in Java and the SOAP libraries were compatible, whereas Microsoft's and Java's were not (at that time).
I nearly choked: they chose a "standard" like SOAP and then re-standardized on a particular library (client and server components of it) "for compatibility."
So to bring this digression back to relevance, I'll say this: if you already have Java code around, it will be easiest to talk to it from Java. And since Java is the new COBOL, there is a bunch of Java floating around. (but if you need a Java client to talk to a Java server using a "standard" protocol then something is seriously awry somewhere)
I'm not saying they are all are high quality, or relevant to your task, or that there are no C++ or Python equivalents - just that there is a high quantity of Java projects. Why not have a quick search? Maybe there is a project there that will convince you.
AWT is about the most prejudiced example imaginable - it was rushed out, disowned by its authors, and quickly replaced.
I think one of the key aspects of the java ecosystem is the idea of free reference-implementation libraries, but you can pay ridiculous amount of money for corporate versions with better implementations. For example, the BEA Systems implementation of Java itself and related tools seems pretty good, well-documented and so on.
I find Java itself and its OO style is pretty horrible for writing prototype code that can be changed quickly and arbitrarily - so, probably, any revolutionary ideas that require that flexibility of interfaces will be hard to iterate in java, and therefore we probably won't find many such projects written in java.
Ahh yes -- replaced with Swing. Do I need to spell it out?
{
"x": [
{
"y": "a",
"z": 23,
"q": [
54,
32,
45
]
}
],
"r": 43
}The other difference is that there are JSON parsers and generators for more languages and they're not programmable.
{ ("x" ( { ("y" "a") ("z" 23) ("q" ( 54 32 45 )) } )) ("r" 43) }
SBCL:
(defun f (x y) (let ((z (gethash x :a))) (+ z y))
Clojure
(defn f [x y] (let [z (get x :a)] (+ x y)))
Having syntax for maps is a huge win. Like ML's pattern matching, it's one of those things that changes your coding style entirely for the better, in a way that you wouldn't predict just by looking at the feature.
The only think I miss from CL when I work in Clojure is keyword arguments to functions. There, the Clojure way is a bit worse:
(defun f (x &key y z) (list x y z)) (f 2 :z 3) => (2 nil 3)
(defn f [x {y :y z :z}] (list x y z)) (f 2 {:z 3}) => (2 nil 3)
vs
> (defn f [x y] (let [z (get x :a)] (+ x y)))
The CL defn of f is a function that is called with two arguments. That function is called like "(f a b)" If the Clojure definition is comparable, that is, the call looks like "(f a b)", why are []s used in the definition and the let?
> This slight decrease in regularity makes a lot of functionality more visible.
What functionality? x,y aren't part of a vector and neither is z. (x,y may come from a vector in the caller, but I'll assume that the defn works if they don't, so that shouldn't matter.)
(I actually prefer Python's style of using indentation to indicate blocks, but I recognize generating such code is harder than code with tokens.)
def indent(code): return code.replace('\n', '\n ')
The code I generate has no indents and no newlines. Not having to keep track of these makes life simpler. To make my generated code more legible, I just run indent on it.
Again, I see no point in making efforts to generate clean looking code when utilities like indent exist.
surely this is unambiguous?
x:
y: "a",
z: "23",
q: 54,
32,
45
,
r: 43(defn sum-vec [vec] (let [vec-len (count vec)] (loop [idx 0 acc 0] (if (< idx vec-len) (recur (inc idx) (+ acc (vec idx))) acc))))
If I have Javascript then I already have mobile code.
If I'm using json in a situation where I don't have a Javascript interpreter, then I probably don't have a Lisp interpreter around either.
My experience is that it is as little as and possibly less initial development and maintenance as a custom flat-file format or a really robust csv parser.
Lucene is sort of Doug Cutting's Java version of Text Database (TDB), which he and Jan Pedersen developed at Xerox PARC, and which, to complete the circle, was written in Common Lisp (see "An Object-Oriented Architecture for Text Retrieval").
It's a great language, but there is nothing to gain here by claiming it somehow is mature because Lisp is 50.