91–100 of 161 posts
Earlier quoted context omitted.
I haven’t used it myself, but EQL5 is attempting to make it possible to use ECL to iOS and Android apps
LispWorks also has offers an iOS/Android runtime, but no CAPI unfortunately.
Assuming that the subtext here is wanting to address potential reasons for Lisp's chronic underpopularity, I think that all conversations like this miss the mark. Lisp was never failing to attract many users because people hadn't experienced sufficient evangelism about all its advanced features. It fails to attract many people because it's not a fun language to get started in. A year or so back I picked up a copy of…
The effort to get an editor going and to open a file and load a package (“system” in CL) is a lot. Of course, I’ll die on a hill claiming that those things are a constant overhead and aren’t even detectable when you wield lisp’s power.
Nothing inherently stops lisp from becoming simpler to start with and use, but most everybody who knows lisp has become not only competent with the current tooling, they’re happy with it. I’m happy too: I love using Emacs and SLIME. I love it better than VSCode, PyCharm, etc. I’m faster and more productive.
I wonder why other professions aren’t like programming. Adobe Premier isn’t exactly easy to use, yet professionals aren’t apparently clamoring for an iMovie equivalent.
Earlier quoted context omitted.
Of course many implementations do compile to machine code but there are also a few that don't (clisp, ecl, abcl). It is really complicated to talk about languages that have multiple implementations. That is why I went with "interpreter". That was pretty lazy of me :). But you didn't say anything about the original question. Have you seen Common Lisp code deployed as an executable or as source code?
Interpreted in Lisp usually means 'executing s-expressions by a Lisp interpreter'. ECL and CLISP also use compilers. ECL usually compiles to C, which then is compiled to native code via a C compiler. CLISP has its own virtual machine, which is the target of its compiler. Don't know what ABCL does, would have to look it up - but in the end it usually would execute JVM code, which gets compiled by its JIT compiler. Que…
> CLISP has its own virtual machine, which is the target of its compiler
Then CPython is also a compiler? and Lua?
This doesn't scratch my itch at all. I love Lisp but boring old Python has the libraries I need. EDIT: Based on a comment and downvote I suppose I didn't make my point clear above. I am saying that myths are not the only thing holding Lisp back. (I may be wrong. I hope I'm wrong. Big thank-you to people who are linking ways to get libraries in Lisp, especially Python libraries.) I care 10x as much about libraries as…
I really need to learn CL one of these days; I know Clojure reasonably well, and enough Lisp-Flavour-Erlang, Chicken Scheme, and Racket to be dangerous, but for some reason I seem to have completely avoided CL. Based on the blog posts I've read, it seems like CL occupies the kind of space I want to be in: sort of the halfway point between theoretical and engineering. Is that a fair conclusion to draw?
Just mentioning it for historical reasons (someone correct if this is wrong), Rich Hickey was enlightened by CL after doing lots of Java/C#/C++, after doing much CL he created Clojure. To answer your question, the JVM has wide acceptance in the industry and a big ecosystem of libraries, from a business and practical point of view, it seems the most adequate choice for a Lisp?
Assuming that the subtext here is wanting to address potential reasons for Lisp's chronic underpopularity, I think that all conversations like this miss the mark. Lisp was never failing to attract many users because people hadn't experienced sufficient evangelism about all its advanced features. It fails to attract many people because it's not a fun language to get started in. A year or so back I picked up a copy of…
There are languages for people who want to get things done, and languages for people who want the perfect language for getting things done. The problem is that definitions of perfection differ between people, so people who are searching for perfect languages wind up in a small niche of people who agree, separated from people next door whose idea of perfection is just slightly different.
In the meantime people whose focus is on getting things done go with a popular language which builds a critical mass of ways to get things done. And the availability of useful libraries makes them actually better to get stuff done with than languages that are theoretically nicer in some way.
This is, of course, a worse is better kind of argument. See https://www.dreamsongs.com/RiseOfWorseIsBetter.html for context on that.
Earlier quoted context omitted.
Interpreted in Lisp usually means 'executing s-expressions by a Lisp interpreter'. ECL and CLISP also use compilers. ECL usually compiles to C, which then is compiled to native code via a C compiler. CLISP has its own virtual machine, which is the target of its compiler. Don't know what ABCL does, would have to look it up - but in the end it usually would execute JVM code, which gets compiled by its JIT compiler. Que…
The word "compiler" is so overloaded that every time someone mentions one it turns into an argument. This is the whole transpiler vs compiler vs interpreter vs JIT argument. The trouble is that sometimes some programmers implement all of them (myself included). > CLISP has its own virtual machine, which is the target of its compiler Then CPython is also a compiler? and Lua?
Originally interpreters were implementations which execute source code - which in Lisp is widely available. For example SBCL for a long time only had a native code AOT compiler, but now also includes s-expressions.
Famous is also the Lisp interpreter in Lisp from McCarthy, where he defined the core language in itself. See the paper from Paul Graham about that: http://languagelog.ldc.upenn.edu/myl/llog/jmc.pdf That's a very primitive Lisp interpreter - many real ones are implemented in C, Assembler...
Just be aware, that in the Lisp world 'Interpreter' means something very specific: an interpreter of the source language.
This doesn't scratch my itch at all. I love Lisp but boring old Python has the libraries I need. EDIT: Based on a comment and downvote I suppose I didn't make my point clear above. I am saying that myths are not the only thing holding Lisp back. (I may be wrong. I hope I'm wrong. Big thank-you to people who are linking ways to get libraries in Lisp, especially Python libraries.) I care 10x as much about libraries as…
It's true that are many more for Python than for Common Lisp. Do you have some examples of libraries you are missing in Common Lisp?
Earlier quoted context omitted.
Just mentioning it for historical reasons (someone correct if this is wrong), Rich Hickey was enlightened by CL after doing lots of Java/C#/C++, after doing much CL he created Clojure. To answer your question, the JVM has wide acceptance in the industry and a big ecosystem of libraries, from a business and practical point of view, it seems the most adequate choice for a Lisp?
Most adequate for what? Peer acceptance?
Assuming that the subtext here is wanting to address potential reasons for Lisp's chronic underpopularity, I think that all conversations like this miss the mark. Lisp was never failing to attract many users because people hadn't experienced sufficient evangelism about all its advanced features. It fails to attract many people because it's not a fun language to get started in. A year or so back I picked up a copy of…
I think that it is even simpler than that. There are languages for people who want to get things done, and languages for people who want the perfect language for getting things done. The problem is that definitions of perfection differ between people, so people who are searching for perfect languages wind up in a small niche of people who agree, separated from people next door whose idea of perfection is just slightl…
It’s true. Importing flask in Python and starting a server takes about 1/2 as much code as in Lisp. Some extraordinarily routine stuff Python has down to a one-liner. A lot of people have also written more Python libraries, so chances are you’ll be able to cobble any random doodad together with a huge dependency tree. But after a certain very short prototyping period, I end up fighting Python’s terrible deployment, terrible efficiency, and slapdash language implementation when trying to build something robust.