Why does no one use lisp?
Been learning it recently and at some point it "clicked"... I drank the koolaid.
But why does no one use it? I'm guessing there's a gotcha somewhere down the road when your projects get big and complex that I'm not seeing yet.
People say it's difficult to learn but I really don't think that's inherently true. It's just "awkward" coming from an ALGOL/C style language.
Other urls found in this thread:
www-sop.inria.fr
youtu.be
youtube.com
clojure.org
twitter.com
lisp is primarily used and endorsed by neckbeards who aren't charismatic enough to spread their philosophies regarding languages.
So autism is holding back the language of God?
> no one uses lisp
the parens
What's the support for multithreading and simd like?
>be a manager
>should I choose elegant powerful language with a pool of 10k potential candidates
>shitty language taught at every school with a pool of 100million potential candidates
For some reason that science has yet to understand, retards sperg out when they see parenthesis.
it's a fucking great language.
pajeet come here and shill garbage like haskell or go.
Only intellectuals use it
my best guess is that people who get deep into lisp, their programs start to become more and more compiler like and less comprehensible to outsiders. That's poison to a language, you need something where it's easy to read someone else's code.
(((lisp)))
((lis)p)
Javascript is directly based on Lisp and everyone uses Javascript - it's the most used programming language. Think of Lisp as the theory and Javascript as the practical application.
(((li)s)p)
lmao what
The main descriptor of a Lisp is that its data structure notation and its code notation is one and the same.
JavaScript/ECMAScript does not hold an ounce of this.
>The main descriptor of a Lisp is that its data structure notation and its code notation is one and the same.
This is particularly important because it gives rise to the read-eval-print loop, of which Javascript has no equivalent.
im looking into chicken scheme but there's no community nor sample programs like for example C.
You don't need homoiconicity to enable REPLs.
chicken compiles to c so why not use both chicken and c?
You do under the Lisp understanding of read/eval/print. Of course other languages neuter these concepts and use the same name, but the name is all they share.
Quite good in SBCL and Chicken. Also Clojure is a JVM language and has excellent multithreading.
bump for clojure concurency
You're thinking of the ease in which metacircular evaluators are created in lisp, which is an academic exercise and not how REPLs are implemented in practice in lisp or scheme, and really has nothing to do with how REPLs are implemented in any other languages either.
Metacircular evaluators are learning exercises, not practical engineering.
Racket has 'places' for parallelism and 'threads' for concurrent (but not parallel) greenthreads. It also has 'futures' for parallel float and fixed math, although futures are tricky to use correctly.
So pretty good for most sort of stuff. But obviously no replacement for scientific computing. Stick with julia or numpy for that sort of thing.
Metacircular evaluators have nothing to do with this.
The heart of homoiconicity is clear - programs of a language are expressions within that language, and can be manipulated by other programs of that language.
The definition of eval is just as clear. It consumes a Lisp expression, evaluates it as a Lisp program, and produces a Lisp expression as the result of evaluation.
Homoiconicity is at the core of the principle of eval. eval does not consume opaque strings, it consumes regular old lists which just happen to contain lisp programs. The separation of read and print (parsing and serialising) from eval exists precisely so that you can manipulate programs to be eval'd as expressions.
Homoiconicity is at the core of the Lisp definitions of read/eval/print.
>eval does not consume opaque strings
Neither does it in other languages. 'Read' takes a string and returns an AST. That's how it works in lisp, and how it works in nearly any other modern language/repl too. You type characters into your terminal emulator, and your lisp process receives characters through (usually) stdin. Those text characters may conceptually represent s-expressions, but in memory it's just an array of characters. To turn it into a pile of cons cells, you need to lex and parse the string, just like normal. That's part of what read does.
So you see, you do not need homoiconicity to separate read from eval.
Here is the trick, and probably the reason you're confused: when you are writing your first metacircular evaluator after buying a copy of SICP, you don't write any string parsing code. You don't write your own read. You just use the read provided by the enclosing environment, which is a useful shortcut for pedagogical reasons but has little engineering significance since, if you're not writing a metacircular evaluator for lisp you would in fact have to parse strings.
This allows the student to learn how to write an interpreter without having to worry about how to write a parser. But make no mistake, the parser is still there. Inside read.
(This is why it's called a metacircular EVALuator. Because you're just implementing eval, not read or print. You exploit the existing implementations of read and print, since implementing those is seen as bitch work that's not particularly instructive.)
>So you see, you do not need homoiconicity to separate read from eval.
If you separate read from eval, how is the result of read anything except an expression containing a (parsed) program? The capability of representing a program in AST form as an expression is what it means to be homoiconic.
In truth homoiconicity is just a word that gets tossed around a lot without very rigorous definitions, often to make mistaken points.
In lisp, `read` is a parser, it's not the equivalent of gets/readline or something like that, which only ever returns a string of bytes.
If you pass the string "(foo bar baz)" through to read, the result is going to be '(foo bar baz), which is not a string. It's a data structure comprising of cons cells strung together to form a list. Converting the string to that data structure is parsing. Because `read` is a parser, not just some sort of "get text from the user" function.
Critical to note, '(foo bar baz) is not actually how it's represented in memory, that's a human-readable representation of a data structure in memory that is likely conceptually similar to pic related. s-expressions are just one text notation used to describe such data structures. The mapping between the textual representation of s-expressions and the underlying data structures is created by `read` and `print`. One parses text and outputs the corresponding data structure, and the other walks the data structure and outputs text. They're both set up such that output from one is valid input to the other.
[continued]
[continued]
>The capability of representing a program in AST form as an expression is what it means to be homoiconic.
This is part of what I mean by the term being poorly defined. All you need to satisfy these requirements are creating a data scheme for your AST that can be represented by data structure literals in your programming language. In scheme you can do that simply by quoting the form. However that's not some special property of lisp or scheme. In javascript you can create arbitrarily complex data structure literals too, the trendy kids call it "json". So all you'd need to satisfy that definition of homoiconicity is a javascript parser that takes a string representing javascript code and returns a json object representing that same code (and also a print function that performs the inverse operation).
This of course would be unsatisfying. Why? Because the javascript AST represented as javascript objects doesn't really look like javascript code. In actuallity it actually is, the datastructure literal needed to represent that AST is something the javascript interpreter can parse, on account of it being a javascript literal. But that doesn't get you the satisfying sensation of enlightenment. It's that satisfying sensation of enlightenment which people are actually talking about when they refer to homoiconicity. The data structure literal representing an AST of the code LOOKS like the code it represents. That's the essence of what people really mean by homoiconicity.
But that is not some sort of special property from an engineering perspective. It's totally reasonable to write a javascript `read` that takes a string and returns json, and then a javascript `eval` which takes that json and interprets it. The separation of read and eval is NOT a property of homoiconicity.
All right, I'm on board with this. This is why I was careful to use a particular definition of homoiconicity but I can see that yours is more reasonable.
>All right, I'm on board with this. This is why I was careful to use a particular definition of homoiconicity but I can see that yours is more reasonable.
Holy shit. Reasonable discussion? On *my* Jow Forums? GTFO
Ok, why would I ever learn that ugly shit?
My company used to use clojure a lot, but we switched to kotlin. Lisp is fun and all but kotlin is much more powerful, and involves less parentheses manipulation.
Translation: your manager didn't like spending money on Clojure developers.
I actually learnt something on Jow Forums today. Thanks user, well and understandably written!
We don't hire based on language. We just hire "smart" people and then make them learn clojure.
Interesting. Would you like me to put you in touch with The Icon Of Java, Durgasoft?
Not sure what you're implying, but I would bet he's a better programmer than you
>Why does no one use lisp?
because of java and javascript.
>there a still people shilling for chicken scheme.
bigloo has native multi-threading, better performances, does support android, is still maintained
www-sop.inria.fr
Bigloo is a Scheme implementation devoted to one goal: enabling Scheme based programming style where C(++) is usually required. Bigloo attempts to make Scheme practical by offering features usually presented by traditional programming languages but not offered by Scheme and functional programming. Bigloo compiles Scheme modules. It delivers small and fast stand alone binary executables. Bigloo enables full connections between Scheme and C programs, between Scheme and Java programs, and between Scheme and C# programs.
>poo in bigloo
Does it have a cross platform gui library? Something similar to racket/gui or maybe lambdanative?
>.fr
Even worse.
wow baste, I want to use what walmart uses!
Well, let me tell you a story.
I work for a company developing in Clojure.
We invest plenty of time in getting new employees up to speed and training them. They learn the language, do plenty of both sandbox and more real world exercises.
Even with a well oiled process and plenty of support from more experienced personnel, it's a complete pain, plenty of people don't "get" it and some trainees get completely and permanently put off by the language.
Why does no one use lisp? Becaue people are brainlets, uncurious, or brian damaged by ALGOL family languages. We try to not hire the retards which leaves us with the other two, and it's really hard and frustrating to break through that conditioning.
what methods have you found most successful in training them?
This is pretty much the correct answer. Building your program out of lots of little functions, a macro here and there... Next thing you know it's basically a whole different custom language you've created for whatever you're doing. Which is great, for you. But for anyone else, it's difficult to grasp the program. Effectively all serious lisp programs are "non-standard".
We put them through a mixture of lectures, 4clojure, hackerank and some mock exercises conjured up by the teams that they'll go through during their training. We're talking about ~14 weeks of training.
We keep improving the process, haven't found a magic formula yet.
Do you have them read any books?
Clojure for the brave
What's their background before Clojure? Have they used any other functional language?
most haven't. It's rare that people use functional languagegs in the industry. If we are lucky they used some Scheme in college.
I wonder if a detour through a stricter language like F# or Haskell could smooth out the transition.
How difficult is Clojure coming from Common Lisp? Should be pretty straightforward right? And would that be a reasonable path if one were seeking to make themselves employable? Since Common Lisp isn't exactly and in demand language and all.
Doubt it, moreover, our time is limited. If we had to teach them two langs they'll quit or cost us too much to train. We just have to improve the process.
youtu.be
More employable than CL, less than java
I haven't used Common Lisp but Rich Hickey made Clojure because his clients wouldn't accept programs written in Common Lisp. Here is his presentation aimed at lisp programmers.
youtube.com
If your browser cuts off at 6:35, search for the re-upload.
In other words: Yes, it should be pretty straightforward.
Just make your own company, bro.
Or, more realistically, make good, mission critical programs in Lisp that make it worth learning or at least filter the shitty coders.
cause i like strict typing, libraries, and not-lisp syntax
I donth lieth youthing lithsp becawse I have a lithsp
Clojure can have the first, has the second, and cleans up the third
>or brian damaged by ALGOL family languages
C family is not the same as ALGOL family, dumbass. The work of many smart people has been buried and defiled over the years by Ctard and Lispnik fools. I'd say more but I don't cast pearls before swine.
Shut up then. No one is begging you to stay.
Yeah algol has lexical closures and if expressions. You know what it doesnt have? users
>ALGOL
>The work of many smart people
>buried
Different poster here. You piqued my interest. Can you say more? I'll be nothing but respectful.
ALGOL is basically the inspiration for unix shell. If you've done bash scripting you'll be right at home. Check out a68g for a GPL modern implementation.
Thanks.
> won't accept Common Lisp, a 30+ year old language with an ANSI standard and multiple high quality implementations, both free and proprietary
> will accept some shit he made himself because it's implemented in Java
People are fucking weird
>brian damaged by ALGOL
scheme is the marriage between lisp and algol
Nobody uses delphi.
My mind telling me no...
But my body... My body telling Lisp
Naughy Dog still programs in lisp, but they are one of the very few lisp shops that exist
Clojure it's a good language, but it's a bad lisp to learn first . The correct approach would be to learn Scheme/CL first.
>parentheses manipulation
no offence, but it seems that you do not understand Lisp
>kotlin is much more powerful..
It's not. Clojure it's a Lisp, therefore it has syntax abstraction capabilities
clojure.org
starting a new project
Lisp or Rust?
crystal
Why do you think clojure is a bad lisp?
>crystal
saucy
Depends on what kind of project.
I thought they stopped using Lisp after the PS2 era. Do you know what they're doing with Lisp nowadays?
Basically it all boils down to immigration fraud. Managers can't hire cut rate Common Lisp developers by the barrel on H1B visas but they sure can find Java developers.
Lisp obviously.
Except Clojure isn't Java, and I don't believe that experience with Java helps you with Clojure any more than it would any other Lisp. I have to guess it's a victory of marketing over common sense.