Ask HN: Is clojure (lisp in JVM) next big thing?
There seems to be a lot of people even some intelligent ones who are lately talking about and exploring clojure, a new lisp dialect run in JVM. It looks really promising, but a lot of people especially lisp programmers have an inherent hatred in java. How is that? what do you think about this ``lisp in JVM''? Is the clojure the future of lisp?
8 comments
The reason Clojure is successful right now IMHO is because:
The reason arc is crashing and burning right now is that it doesn't address #2 at all. Plus, arc is suffering from an absentee benevolent dictator.
1. It isn't afraid to revisit the basic design tenets of Common Lisp and Scheme
2. It has reasonably useful libraries (both through the JVM and written in native Clojure)
The reason arc is crashing and burning right now is that it doesn't address #2 at all. Plus, arc is suffering from an absentee benevolent dictator.
its success doesn't have much to do, from what I can tell, with the actual design of the language
Of course it does. "Revisit[ing] the basic design tenets of Common Lisp and Scheme" is actual language design. Moreover, "fixing" CL and Scheme is not "low hanging fruit". It's a hard thing to do, and most people who try make a mess of things.
Of course it does. "Revisit[ing] the basic design tenets of Common Lisp and Scheme" is actual language design. Moreover, "fixing" CL and Scheme is not "low hanging fruit". It's a hard thing to do, and most people who try make a mess of things.
Moreover, "fixing" CL and Scheme is not "low hanging fruit". It's a hard thing to do, and most people who try make a mess of things.
I agree here. Most people think fixing CL means making "let" use fewer parenthesis. (Clojure does this.)
Anyone that has used Lisp for more than 30 seconds knows that this is not a particularly worthwhile change. More syntax characters just to save two characters in a let binding? No thanks.
(BTW, you can always use destructuring-bind instead of let -- (destructuring-bind (foo bar baz) '(1 2 3) ...). There, you saved some parens!)
Honestly, Clojure doesn't sit really well with me. It tries to be different from both CL and Scheme simply for the sake of being different, which is pretty annoying. For example, look at the "definers". In CL, the scheme is pretty simple -- defun, defvar, defgeneric, defmethod, ... In Scheme, "define" is polymorphic, so it's all you ever need. In Clojure, the "definers" are just random words; def/defn, etc. Oh boy, we saved 3 characters! I am going to be so much more productive now!
Anyway, I will stick to CL for now.
I agree here. Most people think fixing CL means making "let" use fewer parenthesis. (Clojure does this.)
Anyone that has used Lisp for more than 30 seconds knows that this is not a particularly worthwhile change. More syntax characters just to save two characters in a let binding? No thanks.
(BTW, you can always use destructuring-bind instead of let -- (destructuring-bind (foo bar baz) '(1 2 3) ...). There, you saved some parens!)
Honestly, Clojure doesn't sit really well with me. It tries to be different from both CL and Scheme simply for the sake of being different, which is pretty annoying. For example, look at the "definers". In CL, the scheme is pretty simple -- defun, defvar, defgeneric, defmethod, ... In Scheme, "define" is polymorphic, so it's all you ever need. In Clojure, the "definers" are just random words; def/defn, etc. Oh boy, we saved 3 characters! I am going to be so much more productive now!
Anyway, I will stick to CL for now.
The syntax changes are a very minor part of what "fixing" CL/Scheme means. Clojure makes some serious semantic changes.
For instance, data structures are immutable (not setq). If you need state, you have to use the software transactional memory system. These two features combine to make Clojure very safe for concurrency.
Clojure also uses sequences as it's primary object, which are more like "immutable" python generators than lisp lists.
Take a closer look, Clojure is actually quite nice.
For instance, data structures are immutable (not setq). If you need state, you have to use the software transactional memory system. These two features combine to make Clojure very safe for concurrency.
Clojure also uses sequences as it's primary object, which are more like "immutable" python generators than lisp lists.
Take a closer look, Clojure is actually quite nice.
I guess my point is that I wish it only made semantic changes and not syntactic change, or that I could easily turn off the odd syntax.
> its success doesn't have much to do, from what I can tell, with the actual design of the language.
Wow, really? This seems way off base to me. The only reason I care about Clojure is 'persistent' data structures that give us some chance of writing code that /just, maybe, possibly/ will execute usefully on the 1024+-core boxes we're going to be using shortly. That's the only reason I care about it, and I'd say that's fundamentally the design of the language.
Wow, really? This seems way off base to me. The only reason I care about Clojure is 'persistent' data structures that give us some chance of writing code that /just, maybe, possibly/ will execute usefully on the 1024+-core boxes we're going to be using shortly. That's the only reason I care about it, and I'd say that's fundamentally the design of the language.
Powerful libraries are a cheap way to make a new language the language du jour. (Think Rails.) They're not the critical ingredient if you're trying to make something to last; they may even hurt.
Yes, but without powerful libraries a language isn't much good for real world use. And if nobody uses the language it won't have a community and feedback. Without a community people will move on, and it will end up as a pet project.
There are two senses of powerful: breadth and depth. To make a language massively popular you need breadth. But for a language to have a user community all you need is depth, which is why I released news.arc with Arc.
This post just seems to be begging for comment ~ maybe it's because it's relatively rare that we get pg talking about arc.
they may even hurt.
I'm assuming you are referring to the maintenance and backward compatibility that is required as soon as you have libraries. Plus good libraries can be had even in bad languages - so it's not a good reflection of the language. Are you suggesting libraries should be a completely separate project with potentially many choices? The problem with this can be seen in Scheme. It's hard to move from project to project (job to job) when they use different implementations and those related libraries. Learning the related core libraries is often not worth it; if the scope of the project is small. Invariably libraries do not transfer well - maybe that is the problem that needs to be solved... Even with formalities like R5RS or R6RS core libraries are still implementation specific.
Plus, arc is suffering from an absentee benevolent dictator.
... You are missed over at the arclanguage forums. (http://arclanguage.org/item?id=8462) Specifically some direction for those of us that enjoy writing arc would be great. There are plenty of people that know and write arc - why not put them to work. What is your opinion of the community version of arc (http://github.com/nex3/arc/tree/master)? Do you use it? Is it blasphemy? Is this all just a giant social experiment to see what will happen to the language and community given no leadership and x-number of years?
they may even hurt.
I'm assuming you are referring to the maintenance and backward compatibility that is required as soon as you have libraries. Plus good libraries can be had even in bad languages - so it's not a good reflection of the language. Are you suggesting libraries should be a completely separate project with potentially many choices? The problem with this can be seen in Scheme. It's hard to move from project to project (job to job) when they use different implementations and those related libraries. Learning the related core libraries is often not worth it; if the scope of the project is small. Invariably libraries do not transfer well - maybe that is the problem that needs to be solved... Even with formalities like R5RS or R6RS core libraries are still implementation specific.
Plus, arc is suffering from an absentee benevolent dictator.
... You are missed over at the arclanguage forums. (http://arclanguage.org/item?id=8462) Specifically some direction for those of us that enjoy writing arc would be great. There are plenty of people that know and write arc - why not put them to work. What is your opinion of the community version of arc (http://github.com/nex3/arc/tree/master)? Do you use it? Is it blasphemy? Is this all just a giant social experiment to see what will happen to the language and community given no leadership and x-number of years?
> Is this all just a giant social experiment to see what will happen to the language and community given no leadership and x-number of years?
It's pretty clear already: arc has failed.
It's pretty clear already: arc has failed.
arc has failed
Failed at what, exactly? Being a toaster?
You guys all seem to be projecting your own expectations about "language and community" onto Arc, none of which have to do with the stated goals of the project. What part of making-a-better-Lisp-where-better-mostly-equals-shorter-programs don't you understand?
Failed at what, exactly? Being a toaster?
You guys all seem to be projecting your own expectations about "language and community" onto Arc, none of which have to do with the stated goals of the project. What part of making-a-better-Lisp-where-better-mostly-equals-shorter-programs don't you understand?
Failed at being a hundred year language. Arc programs are shorter, but only by a constant factor due to small syntax enhancements. It doesn't provide interesting new abstractions like Lisp did.
To make the statement that arc has failed with credibility, you'd need the following:
1. A completed version of arc 2. 100 years since 1.
1. A completed version of arc 2. 100 years since 1.
Libraries are just one aspect of it. Clojure's already got an excellent VM and a sound programming model to deal with concurrency.
How could it hurt a language's lasting power for it to have powerful libraries?
Do you mean that it might hurt Clojure specifically, because it relies on Java's libraries in particular? Or was it a more general point?
Do you mean that it might hurt Clojure specifically, because it relies on Java's libraries in particular? Or was it a more general point?
It was just a general point. I don't know anything about Clojure.
The dangers of libraries are that they distract one's attention from the core language, and that they could conceal or perpetuate flaws in the core language.
I'm not saying that languages shouldn't have powerful libraries, btw, just that they may not be 100% upside.
The dangers of libraries are that they distract one's attention from the core language, and that they could conceal or perpetuate flaws in the core language.
I'm not saying that languages shouldn't have powerful libraries, btw, just that they may not be 100% upside.
I think it's unfortunate you haven't even looked at Clojure. If you did, it's possible both languages could benefit. While I am a fan of the JVM, one downside of the language is that compromises were needed to work nicely on the JVM. Besides that, Clojure has many features that make programming in it great for experimentation (and large-scale), and I don't see those features in Arc. If Arc had immutability, threading, STM concurrency, lazy functions, and literal data structures, but without the JVM compromises and with the 100-year goal, it might be more interesting to me and others. I looked at Arc when it first came out, but the homepage still doesn't spell out what makes it worthwhile other than "brief and malleable".
What about the design of Arc do you prefer over Clojure?
Number 2 is the killer feature in my opinion. Leveraging a humongous, popular, and mature set of libraries that the JVM gives makes Clojure stand out, and is probably why it's getting so much attention. The "real world" usually favors languages with "batteries included".
If that were true, Kawa and SISC (good Scheme compiler and interpreter for the JVM, respectively) would already have grabbed that attention.
It's too early for libraries to be built on a language that is still in the experimental stage.
While I enjoyed writing arc code, I'm in no hurry to see a huge infrastructure pop up around the language as it stands. What's the rush? Let pg and rtm take whatever time they need to build a language they are happy with.
While I enjoyed writing arc code, I'm in no hurry to see a huge infrastructure pop up around the language as it stands. What's the rush? Let pg and rtm take whatever time they need to build a language they are happy with.
> Let pg and rtm take whatever time they need to build a language they are happy with.
Yeah, pg and rtm can do whatever they want. Meanwhile, I want a language I'm happy with.
Yeah, pg and rtm can do whatever they want. Meanwhile, I want a language I'm happy with.
I guess you could choose a different language, provide ideas to enhance arc, or design your own...
There is a video (http://clojure.blip.tv/) by the creator of Clojure which argues (quite convincingly) that it is really Java, the language, that some people may have problems with and that Java, the runtime environment, (JVM) is a great platform in which to target your code.
Lots of work is being done in areas such as JIT and adaptive optimization in the runtime environment. By targeting the JVM you get to take advantage of all that work put into optimization and thousands of libraries; it gets you a lot of leverage fast.
Lots of work is being done in areas such as JIT and adaptive optimization in the runtime environment. By targeting the JVM you get to take advantage of all that work put into optimization and thousands of libraries; it gets you a lot of leverage fast.
arguing about clojure vs. scala is the next big religious war
http://www.cio.com/article/print/454520
http://almaer.com/blog/the-next-big-language-theory-practice...
http://www.cio.com/article/print/454520
http://almaer.com/blog/the-next-big-language-theory-practice...
I find that after a year of Common Lisp, I don't really care about Clojure. On the other hand, through the JVM and the Java API, it offers for free some of the things which were never available as a CL standard feature.
However, CL is a language specification, while Java is for better or worse much more than that.
However, CL is a language specification, while Java is for better or worse much more than that.
Lisp will never be popular. We are humans and our brains are wired for a certain type of thinking. Lisp breaks this model, and so it's difficult for people to pick it up.
The trend has always been to easier and easier languages - I don't remember any case where a more complex language, no matter how useful, has become the next big thing.
The only thing that can make lisp popular is a framework or API based off it. Something that offers something new or something easier.
The trend has always been to easier and easier languages - I don't remember any case where a more complex language, no matter how useful, has become the next big thing.
The only thing that can make lisp popular is a framework or API based off it. Something that offers something new or something easier.
So how does that trend explain C++, or Java, or C#, all of which are clearly evolving in the direction of increased complexity. Likewise Python today is a vastly more complicated environment than the language I learned 8 years ago. And Ruby is quirkier still, taking most of perl's weird syntax and adding an object model from smalltalk and a statement-based execution metaphor that comes straight out of BASIC -- certainly not a "simple" language.
C is a simple language. Scheme is a simple language. Everything else is growing more complicated by the day.
C is a simple language. Scheme is a simple language. Everything else is growing more complicated by the day.
I don't think that Java is more complex than C++ in terms of the language itself. I think that being simpler is actually one of the reasons it has caught on.
A language will always grow in complexity. But it does not become more popular because it grows in complexity.
My point was that the trend in popularity is towards less complex languages - i.e, languages that abstract away difficulty. In that respect, C++ is less complex than C.
My point was that the trend in popularity is towards less complex languages - i.e, languages that abstract away difficulty. In that respect, C++ is less complex than C.
less complex languages - i.e, languages that abstract away difficulty
That is a very anomalous definition of complexity. In truth, a language that is more complex may or may not be more abstract. For example, Prolog operates at a very high level of abstraction, and it is far less complex than a language like C++.
C++ is less complex than C
C++ allows programs to be written at a higher level of abstraction than C, but it is not less complex than C by any reasonable definition of "complexity". In fact, it is the very existence of the C++ tools for abstraction (classes, templates, virtual functions, MI) that cause much of C++'s language complexity. Perhaps you are conflating the complexity of the language with the complexity of a typical program written in that language?
That is a very anomalous definition of complexity. In truth, a language that is more complex may or may not be more abstract. For example, Prolog operates at a very high level of abstraction, and it is far less complex than a language like C++.
C++ is less complex than C
C++ allows programs to be written at a higher level of abstraction than C, but it is not less complex than C by any reasonable definition of "complexity". In fact, it is the very existence of the C++ tools for abstraction (classes, templates, virtual functions, MI) that cause much of C++'s language complexity. Perhaps you are conflating the complexity of the language with the complexity of a typical program written in that language?
"And Ruby is quirkier still, taking most of perl's weird syntax ..."
Um, what?
I don't think you know much Ruby.
Um, what?
I don't think you know much Ruby.
> We are humans and our brains are wired for a certain type of thinking. Lisp breaks this model, and so it's difficult for people to pick it up.
If you have ever parsed a syntactic tree, you'll realize that it's inherently an s-expression. That means that everything you ever say, and all human communication for that matter, are s-expressions.
Sans the logic, operators, symbol quoting and observance of rules (first item is interpreted as a function), lisp is at its core as close to human language you'll ever get. Popularity depends on other things, but lisp doesn't break the way we think.
If you have ever parsed a syntactic tree, you'll realize that it's inherently an s-expression. That means that everything you ever say, and all human communication for that matter, are s-expressions.
Sans the logic, operators, symbol quoting and observance of rules (first item is interpreted as a function), lisp is at its core as close to human language you'll ever get. Popularity depends on other things, but lisp doesn't break the way we think.
Take a look at this sample from wikipedia:
(defun factorial (n) (if (<= n 1) 1 (* n (factorial (- n 1)))))
Now imagine trying to explain that to a person who does not use a computer. Humans always start learning by looking for the objects, then applying an action on the object. With lisp, this object is not obvious, and the actions being applies are not obvious either.
(defun factorial (n) (if (<= n 1) 1 (* n (factorial (- n 1)))))
Now imagine trying to explain that to a person who does not use a computer. Humans always start learning by looking for the objects, then applying an action on the object. With lisp, this object is not obvious, and the actions being applies are not obvious either.
I never found this objects first idea very plausible. It's just OO dogma, not cognitive science. Which of the following expressions is most "natural" in your view?
person.buy(house, agency, contract)
agency.sell(house, contract, person)
house.sale(person, agency, contract)
contract.fulfil(house, person, agency)
Of course the decision is not taken based on what's easiest to explain to non computer users but rather on which object's encapsulated data is most affected by the operation, or which inheritance hierarchy should be used to look up the operation. In most non trivial cases that's extremely subjective. Being forced to make that decision _every time_ you call or write a function is a complete waste of intellectual effort.
Since there is always one name for what should happen (the name of the function) but potentially many objects that are involved in some capacity, it seems much more consistent to give a special syntactical place to the function rather than to any of the objects:
sell(house, person, contract) or if you prefer (sell house person contract)
person.buy(house, agency, contract)
agency.sell(house, contract, person)
house.sale(person, agency, contract)
contract.fulfil(house, person, agency)
Of course the decision is not taken based on what's easiest to explain to non computer users but rather on which object's encapsulated data is most affected by the operation, or which inheritance hierarchy should be used to look up the operation. In most non trivial cases that's extremely subjective. Being forced to make that decision _every time_ you call or write a function is a complete waste of intellectual effort.
Since there is always one name for what should happen (the name of the function) but potentially many objects that are involved in some capacity, it seems much more consistent to give a special syntactical place to the function rather than to any of the objects:
sell(house, person, contract) or if you prefer (sell house person contract)
I'm not directly arguing for OO. In my opinion, a good language is one which forces the black box encapsulation of complex behaviour.
'House' as an abstraction for a house is a good model. Performing an action on an abstraction should be in an intuitive manner, for example:
sell House
That's pretty clear. To cause the interaction between two objects, then one should place the action between the objects:
make "Agency" sell "House"
where 'make' is equivalent to calling a function. Now, let's bring in a contract
make "Agency" sell "House" using "Contract"
this OO model works in my opinion because there is one path between the objects, and the arguments describe the contents of the path.
make "Person" buy "House" using "TerribleContract"
I believe that programming languages are too flexible. I believe that programming languages should be constructed in a manner that forces you to abstract complex structures into aggregates of behaviour, where the input to these aggregates consist of a very low number of paths. Java, C+++ fail in this in that they allow you to break out of the abstraction hierachy. They allow you to have callbacks and inheritance and so on, which breaks the black-boxiness of your program.
A black-box should always take the same inputs and should always produce the same behaviour from those inputs. Now, what about other types of programming constructs?
Let's say I wanted to send a file to another PC using sockets:
create "File" using "/hello.txt"
As the next step I'm trying to open a port. However, a port has a number. I could try to do this:
create "Socket" using ("Port" using 8934)
"Port 8934" is something that can be merged together into a composite structure and so the user should be forced to do so:
"InputPort" is "Port" using 8934
create "Socket" using "InputPort"
make "Socket" send "File"
destroy "Socket"
This is an example of how I think a properly abstracted language should look like. Force single paths to all abstractions, and force abstraction use.
'House' as an abstraction for a house is a good model. Performing an action on an abstraction should be in an intuitive manner, for example:
sell House
That's pretty clear. To cause the interaction between two objects, then one should place the action between the objects:
make "Agency" sell "House"
where 'make' is equivalent to calling a function. Now, let's bring in a contract
make "Agency" sell "House" using "Contract"
this OO model works in my opinion because there is one path between the objects, and the arguments describe the contents of the path.
make "Person" buy "House" using "TerribleContract"
I believe that programming languages are too flexible. I believe that programming languages should be constructed in a manner that forces you to abstract complex structures into aggregates of behaviour, where the input to these aggregates consist of a very low number of paths. Java, C+++ fail in this in that they allow you to break out of the abstraction hierachy. They allow you to have callbacks and inheritance and so on, which breaks the black-boxiness of your program.
A black-box should always take the same inputs and should always produce the same behaviour from those inputs. Now, what about other types of programming constructs?
Let's say I wanted to send a file to another PC using sockets:
create "File" using "/hello.txt"
As the next step I'm trying to open a port. However, a port has a number. I could try to do this:
create "Socket" using ("Port" using 8934)
"Port 8934" is something that can be merged together into a composite structure and so the user should be forced to do so:
"InputPort" is "Port" using 8934
create "Socket" using "InputPort"
make "Socket" send "File"
destroy "Socket"
This is an example of how I think a properly abstracted language should look like. Force single paths to all abstractions, and force abstraction use.
Isn't the abstraction, and sticking to the abstraction, the job of the programmer, and not the language?
We all speak English here; you can say, "let's all speak like Yoda now." Quite easy, that is. But the underlying language doesn't need to change; other people can invent different rules and create different settings where these rules apply strictly.
So imperatively, your socket program is like this:
f = file("/hello.txt")
p = makeport(8934)
s = makesocket(p)
s.send(f)
s.destroy()
which is perfectly fine. This is basically a line by line translation from your English-looking pseudocode to this OO-code-looking pseudocode. Using s-expressions would make the whole process read much more like speaking:
Let's say I wanted to send a file: Using the socket that uses the port 8934, send the file hello.txt, and destroy the socket.
Plain English, right? Reorder into:
Destroy the socket that is used to send the file hello.txt and is created with port 8934.
Translate to s-expr:
(destroy-socket (send-file (make-file "hello.txt") using (make-socket (make-port 8934)))
I'm taking liberties with the send-file function syntax.
Looks ugly, but that's pretty close to the natural language representation. If you parse the syntactic tree it will almost overlap completely.
We all speak English here; you can say, "let's all speak like Yoda now." Quite easy, that is. But the underlying language doesn't need to change; other people can invent different rules and create different settings where these rules apply strictly.
So imperatively, your socket program is like this:
f = file("/hello.txt")
p = makeport(8934)
s = makesocket(p)
s.send(f)
s.destroy()
which is perfectly fine. This is basically a line by line translation from your English-looking pseudocode to this OO-code-looking pseudocode. Using s-expressions would make the whole process read much more like speaking:
Let's say I wanted to send a file: Using the socket that uses the port 8934, send the file hello.txt, and destroy the socket.
Plain English, right? Reorder into:
Destroy the socket that is used to send the file hello.txt and is created with port 8934.
Translate to s-expr:
(destroy-socket (send-file (make-file "hello.txt") using (make-socket (make-port 8934)))
I'm taking liberties with the send-file function syntax.
Looks ugly, but that's pretty close to the natural language representation. If you parse the syntactic tree it will almost overlap completely.
The inversion you applied to the plain english makes it into a format that is, while technically english, the sort of construct that one imagines an alien or robot might produce when trying to talk to us. If you actually spoke like that people would look at you very strangely, and this is the difficulty in understanding s-expressions that I think a lot of people have.
That said, since my own programming style in C-derived languages seems over the years to slowly be attempting to imitate s-expressions, I think a lot of the mental difficulty people mention is just being overly comfortable with the familiar.
That said, since my own programming style in C-derived languages seems over the years to slowly be attempting to imitate s-expressions, I think a lot of the mental difficulty people mention is just being overly comfortable with the familiar.
Sure, lisp syntax is itself not intuitive, but I was pointing out that the reasoning involved in lisp programming does not clash with how humans are wired. It could clash with how humans are trained, but inherently, s-expressions are a good representation of human speech.
If the person knows the mathematical meaning of factorial and the underlying concepts, this will be very easy.
If not, this will be really hard using any programming language.
If not, this will be really hard using any programming language.
are the axioms of non-euclidean geometry obvious? what about special relativity?
You are saying that I am using the solution for a tough problem as being representative of the use of the language?
That may be so, but what I was pointing out was how different they language structure was from traditional human languages.
That may be so, but what I was pointing out was how different they language structure was from traditional human languages.
they are different domains of expression. so that should not come as surprise. maybe one day when computers are super powerful. for now "code is data and we write in the same data structures the compiler understands" seem like the bigger win. that of course means a lisp of some sort.
"We are humans and our brains are wired for a certain type of thinking. Lisp breaks this model, and so it's difficult for people to pick it up."
Please elaborate. I'd love to refute if there was something in there to refute. I really don't see how Lisp is inherently less (or for that matter, more) graspable on a fundamental level. Are you a neurologist? And do you have any actual experience with Lisp?
Please elaborate. I'd love to refute if there was something in there to refute. I really don't see how Lisp is inherently less (or for that matter, more) graspable on a fundamental level. Are you a neurologist? And do you have any actual experience with Lisp?
If you have ever been in a math class with people who are not programmers, who are just plain old Joes, you'll notice that the most difficult subjects have to do with abstractions.
When particular concepts are represented by abstract concepts, and operations are executed on these concepts, that's where most people shut down. That's why many people don't go into programming - they are not able to easily deal with the abstractions that programmers have to deal with.
Languages that are similar to human languages - i.e, one word, one 'object' or 'concept' are easy for people to understand. A language like lisp is not even near to that - it depends completely on abstractions of concepts, and this is where the core difficulty for most people would lie.
For example, to take this example from wikipedia:
(list '1 '2 'foo)
The statement above is very difficult to reconcile with real world concepts, it's very difficult to put into the mental boxes we have grown up with.
Contrast with python:
if object is not null:
Languages don't have to be similar to english, but they have to be mentally mapable to models we already know. This is difficult to do with Lisp. With lisp, you have to understand new concepts. It's just not that easy for most people.
When particular concepts are represented by abstract concepts, and operations are executed on these concepts, that's where most people shut down. That's why many people don't go into programming - they are not able to easily deal with the abstractions that programmers have to deal with.
Languages that are similar to human languages - i.e, one word, one 'object' or 'concept' are easy for people to understand. A language like lisp is not even near to that - it depends completely on abstractions of concepts, and this is where the core difficulty for most people would lie.
For example, to take this example from wikipedia:
(list '1 '2 'foo)
The statement above is very difficult to reconcile with real world concepts, it's very difficult to put into the mental boxes we have grown up with.
Contrast with python:
if object is not null:
Languages don't have to be similar to english, but they have to be mentally mapable to models we already know. This is difficult to do with Lisp. With lisp, you have to understand new concepts. It's just not that easy for most people.
You are making statements without data, and I do not share your intuitions.
I think you underestimate the leap that doing the kinds of abstraction needed for doing any kind of programming at all, and the very small differences between programming languages. There are probably many (most?) people to whom both "if object is not null:" and "(if foo 1 2)" will never be comprehensible. But I think the number of people who can understand the first but not the second or vice versa is negligible. And I think you can make just as good a case that Lisp is easier for the beginner to understand. We tend to think that non-Lisp languages are easier to understand because they are superficially similar to one another. But to the beginner they are just a jumble of symbols arranged in strange ways. The simplicity and consistency of Lisp forms may very well be more quickly comprehended by a mind undamaged by Java or C or any of those similar languages.
I think you underestimate the leap that doing the kinds of abstraction needed for doing any kind of programming at all, and the very small differences between programming languages. There are probably many (most?) people to whom both "if object is not null:" and "(if foo 1 2)" will never be comprehensible. But I think the number of people who can understand the first but not the second or vice versa is negligible. And I think you can make just as good a case that Lisp is easier for the beginner to understand. We tend to think that non-Lisp languages are easier to understand because they are superficially similar to one another. But to the beginner they are just a jumble of symbols arranged in strange ways. The simplicity and consistency of Lisp forms may very well be more quickly comprehended by a mind undamaged by Java or C or any of those similar languages.
But who's to say your experience with a given subject domain does not expand your intuition and creates new models of understanding?
btw, if object is not null is closer to (nil? object) than to (list '1 '2 'foo)
lisp may not be simpler, it is more powerful. it is a distillation of the ideas that gave rise to computer languages.
btw, if object is not null is closer to (nil? object) than to (list '1 '2 'foo)
lisp may not be simpler, it is more powerful. it is a distillation of the ideas that gave rise to computer languages.
I don't doubt that learning lisp makes you better. But the argument is about if Lisp is the next big thing. My argument is that it is not because people have to learn new things, and they don't want to. They will only want to if there are concrete advantages to it (make a website in 3 hours), and not because of a more abstract result like 'expand your intuition'.
Lisp is likely more powerful, but it is unlikely to become very popular in the form it currently exists in.
Lisp is likely more powerful, but it is unlikely to become very popular in the form it currently exists in.
sure. but i only put forward the 'expand your intuition" argument as a rebuttal to your "models of understanding". i am saying though that the very same concepts that gave rise to lisp, also make it more powerful in practice. "in the field" as they say. but it takes a little practice to get there.
yes, lisp won't ever be more popular. just like "30 Rock" won't ever be more popular than "the office"
yes, lisp won't ever be more popular. just like "30 Rock" won't ever be more popular than "the office"
"If you have ever been in a math class with people who are not programmers, who are just plain old Joes, you'll notice that the most difficult subjects have to do with abstractions."
People who can't think in abstractions shouldn't become programmers, that's all. Besides using very simple DSLs, perhaps (ha!).
I don't see how arguing that people who aren't hard-wired to program have greater difficulty with Lisp than they do with languages with more exposure makes the case that Lisp is too complex.
People who can't think in abstractions shouldn't become programmers, that's all. Besides using very simple DSLs, perhaps (ha!).
I don't see how arguing that people who aren't hard-wired to program have greater difficulty with Lisp than they do with languages with more exposure makes the case that Lisp is too complex.
Your example is hideously flawed, why don't you compare creation of a list with creation of a list / vector rather than an if statement. The equivalent lisp (clojure) to your python example
(if (not (nil? object)))
Is very simple to read, even if you hate parens.
(if (not (nil? object)))
Is very simple to read, even if you hate parens.
It's not "hard", it's just "different". I don't see how it breaks a "certain type of thinking" that we are "wired" for, other than that it fundamentally different from the imperative / structured programming that 99% of programmers are introduced to in their first language. I don't see how breaking with that model is beyond the ken of human beings. You can even take intermediate steps; learning Python and its code introspection features makes "code == data" a lot simpler to grok because you've already seen that sort of thing before.
Maybe the electrician just wired your brain wrong. You might want to try and get a refund.
Maybe the electrician just wired your brain wrong. You might want to try and get a refund.
No, it's fundamentally difficult for human beings. You know why? Take a look at mathematics. It is fundamentally difficult for human beings because it does not fit the model that we grew up with evolutionarily.
Math is just a language, but it's a very difficult language for most human beings to learn because we don't naturally think using those type of expressions.
Lisp was created as mathematical notation for computers. It is based of a language that the most people have difficulty with in school.
I'm good at math, and I have no problem with lisp. I'm just pointing out that it will not be the next big thing because this type of thinking is not easy for most people to get into. Pythonic thinking on the other hand is easy for people to understand.
Math is just a language, but it's a very difficult language for most human beings to learn because we don't naturally think using those type of expressions.
Lisp was created as mathematical notation for computers. It is based of a language that the most people have difficulty with in school.
I'm good at math, and I have no problem with lisp. I'm just pointing out that it will not be the next big thing because this type of thinking is not easy for most people to get into. Pythonic thinking on the other hand is easy for people to understand.
If lisp is hard to pick up but those who do have a grasp of it are significantly more productive than they would be in other languages, then it should be a success.
Since so little software is written in lisp, I can only conclude that the language doesn't actually make its users much more productive or that the significance of libraries is greater than pg wants to admit or that most brilliant programmers are rather ignorant when it comes to selecting their tools.
Since so little software is written in lisp, I can only conclude that the language doesn't actually make its users much more productive or that the significance of libraries is greater than pg wants to admit or that most brilliant programmers are rather ignorant when it comes to selecting their tools.
Actually, I have authored a piece commercial Common Lisp based web 2.0 software. It's small, simple, and for whatever problems I didn't feel like resolving myself, I could find a library to solve it for me.
In my book, Lisp is great.
P.S. And I'll keep using it for future projects!
In my book, Lisp is great.
P.S. And I'll keep using it for future projects!
on the surface. yes. which one do you consider more powerful as a tool for expressing ideas?
Ideas are best expressed in plain english. Commands to computers are best expressed in simplistic statements like those that exist in python.
Complex systems should be modelled by reducing the complexity. What I mean is that one has to black-box certain parts of complex systems such that human minds can deal with the concepts effectively. Object oriented programming is a way of doing this, but it's not the perfect way.
Complex systems should be modelled by reducing the complexity. What I mean is that one has to black-box certain parts of complex systems such that human minds can deal with the concepts effectively. Object oriented programming is a way of doing this, but it's not the perfect way.
sorry, i meant explicitly to a computer.
some of the ideas i need to express in order to make a living are not so easily expressed in python:
http://news.ycombinator.com/item?id=343738
some of the ideas i need to express in order to make a living are not so easily expressed in python:
http://news.ycombinator.com/item?id=343738
While I disagree with you, I think it's unfortunate that your comment was modded down.
I'd respond by saying that lisp is an easier language to learn than C (for example) - they syntax is much more consistent.
I'd respond by saying that lisp is an easier language to learn than C (for example) - they syntax is much more consistent.
Lisp would not be easier to learn than C if you had to do the OS specific stuff you do in C in Lisp.
please explain.
C code is usually very simple. The difficulty in C is not in grasping the syntax, it's in manipulating pointers, understanding the byte layout of structures, linking libraries and so on.
If you had to do the same stuff in lisp, you'd face the same problems.
If you had to do the same stuff in lisp, you'd face the same problems.
yes, but you have the ability to tailor the language and create constructs to deal with your problems more concisely.
i learned lisp before C. i always found C to be very obtuse and arbitrary. for example:
1. why can't i define a function inside a function and then return it, why can't i define a function based on some conditional?
2. macros that are just text expansions are useless (well not useless but in comparison to lisp macros!)
3. no way to embed a mini language. or way, but too difficult. in lisp you don't even have to think about it. (a little query language, or a little configuration language, or a language to do gene annotations based on certain protein sequences that non-computer people can write in :)
4. you have to compile and use a debugger. in lisp you can change and run things as you write them.
5. recursion is unequivocally expensive.
6. can't write new iteration constructs (or you can by passing function pointers but it's limited and ugly)
7. no anonymous functions! c'mon!
etc etc
so the fact that lisp doesn't map into a preconceived model of understanding has very little practical significance ... C, by all measures, is less powerful and wouldn't allow me to do my work with reasonable amount of effort. neither would python btw. as i maintain a domain specific language that would have been very difficult to write in some other language.
i learned lisp before C. i always found C to be very obtuse and arbitrary. for example:
1. why can't i define a function inside a function and then return it, why can't i define a function based on some conditional?
2. macros that are just text expansions are useless (well not useless but in comparison to lisp macros!)
3. no way to embed a mini language. or way, but too difficult. in lisp you don't even have to think about it. (a little query language, or a little configuration language, or a language to do gene annotations based on certain protein sequences that non-computer people can write in :)
4. you have to compile and use a debugger. in lisp you can change and run things as you write them.
5. recursion is unequivocally expensive.
6. can't write new iteration constructs (or you can by passing function pointers but it's limited and ugly)
7. no anonymous functions! c'mon!
etc etc
so the fact that lisp doesn't map into a preconceived model of understanding has very little practical significance ... C, by all measures, is less powerful and wouldn't allow me to do my work with reasonable amount of effort. neither would python btw. as i maintain a domain specific language that would have been very difficult to write in some other language.
Yes, you use the power of lisp to solve your own problem, and that's good. And I absolutely agree with you that lisp is an excellent languages for solving problems.
But it does not change the fact that lisp is not easily accessible for most people, and that particular limitation of lisp is why it will not be 'the next big thing'.
On a personal note, I don't think that using DSLs is good programming practise. It is my opinion that this makes your code too specific to you and you force anyone trying to understand your code to first learn a new language - the one you just invented.
It's like comparing Seth Godins writing to the writings of Kant. There was a time when I was in philosophical mood and I bought the original German version of a book by Kant. Kant is often described as one of the great thinkers, but he sure is not one of the great writers. His sentences are long and unwieldy and it's very difficult to understand what he's trying to say. Seth Godin writes plainly, however, and he communicates his ideas clearly.
The core purpose of reading both their writings is to gain in knowledge, and when the sentence structure of one writing is so obscure that one can't even parse the sentence, then this purpose is not being achieved.
Writing a DSL is the same thing - if nobody else understands what you wrote, then, though you may have succeeded in communicating your meaning to the computer, you have failed in communicating to anybody else who may want to improve your code. And that second part of things is also an important part of programming.
But it does not change the fact that lisp is not easily accessible for most people, and that particular limitation of lisp is why it will not be 'the next big thing'.
On a personal note, I don't think that using DSLs is good programming practise. It is my opinion that this makes your code too specific to you and you force anyone trying to understand your code to first learn a new language - the one you just invented.
It's like comparing Seth Godins writing to the writings of Kant. There was a time when I was in philosophical mood and I bought the original German version of a book by Kant. Kant is often described as one of the great thinkers, but he sure is not one of the great writers. His sentences are long and unwieldy and it's very difficult to understand what he's trying to say. Seth Godin writes plainly, however, and he communicates his ideas clearly.
The core purpose of reading both their writings is to gain in knowledge, and when the sentence structure of one writing is so obscure that one can't even parse the sentence, then this purpose is not being achieved.
Writing a DSL is the same thing - if nobody else understands what you wrote, then, though you may have succeeded in communicating your meaning to the computer, you have failed in communicating to anybody else who may want to improve your code. And that second part of things is also an important part of programming.
You're completely off-track on the DSL part.
I'd rather have to learn a new small DSL language that lets me read and write exactly what is meant (the semantics of the language map almost directly to the language of the domain) than a big clunky API (apis are languages!) that will make my code littered with book-keeping tasks when I use it.
I'd rather have to learn a new small DSL language that lets me read and write exactly what is meant (the semantics of the language map almost directly to the language of the domain) than a big clunky API (apis are languages!) that will make my code littered with book-keeping tasks when I use it.
that's interesting. in the original german! you're braver than me.
i think DSL's are good for the same points you bring up. i am more concerned with the DSL ability to express a problem/solution. the DSL itself of course necessitates different expertise. just like there a lots of python users, but only a few people who work on the python core. or for that matter linux users vs the linux kernel team.
i think DSL's are good for the same points you bring up. i am more concerned with the DSL ability to express a problem/solution. the DSL itself of course necessitates different expertise. just like there a lots of python users, but only a few people who work on the python core. or for that matter linux users vs the linux kernel team.
[deleted]
Danielle Steele vs. Jane Austen ... or something.
It is possible to write very dense and abstract functional code that is hard to understand but some Lisp-code is so readable you wonder if it is actually code!
That said I don't see Lisp becoming big. Scala probably has a better chance.
Scalalooks great on paper and is better than JAVA in my opinion. However in practice it still feels very heavy and kind of JAVA-ish. Not for me but perhaps a natural step for a lot of JAVA-developers.
That said I don't see Lisp becoming big. Scala probably has a better chance.
Scalalooks great on paper and is better than JAVA in my opinion. However in practice it still feels very heavy and kind of JAVA-ish. Not for me but perhaps a natural step for a lot of JAVA-developers.
Anyone played much with compjure? I loved the ideas in it - last I tried however I wasn't able to make changes and refresh - I had to restart the app to see changes. Interestingly (and nicely) it "compiled" the changes up front, telling me of any errors. That part was nice but having a F5 refresh/change cycle for web apps I think is expected now.
Good luck teaching the unwashed masses lisp.
A friend of mine was being taught Java in an introductory programming course (although he already knew some BASIC). He was having a lot of trouble, so I introduced him to Lisp... After touring through some of the more basic features (no macro-writing or call/cc), he responded with, "Whoa... This is so much simpler than Java, it makes so much more sense."
My take on that was that the only reason people find Java easier is because it's more similar to other curly-brace languages, the ones they already know. If you take a newcomer to programming, Lisp just may actually be simpler. So the unwashed masses still have some hope.
My take on that was that the only reason people find Java easier is because it's more similar to other curly-brace languages, the ones they already know. If you take a newcomer to programming, Lisp just may actually be simpler. So the unwashed masses still have some hope.
Anecdotal evidence of teaching Scheme as a first language in a French university shows that it's rather easy to learn, provided that there isn't too much to be unlearned by the audience. Mind you, on 2nd semester they had to learn some Visual Basic and found it gratuitously complicated.
Unwashed masses have accepted to learned very complex frameworks and metaprogramming tools around Java; those stuff are not simpler than, say, Common Lisp. They learned it because the consensus (among their peers) was that these were professional tools, useful for one's career. If a Lisp ever gained that fashionability, it would no doubt be learned very quickly by those "unwashed" masses, even if most of them wouldn't ever reach the guru status.
Unwashed masses have accepted to learned very complex frameworks and metaprogramming tools around Java; those stuff are not simpler than, say, Common Lisp. They learned it because the consensus (among their peers) was that these were professional tools, useful for one's career. If a Lisp ever gained that fashionability, it would no doubt be learned very quickly by those "unwashed" masses, even if most of them wouldn't ever reach the guru status.
"Good luck teaching the unwashed masses lisp."
What problems did you have learning Lisp?
What problems did you have learning Lisp?
I know its a cliche, and not really a "programming language" but XML has caught on with the masses (yes, its still popular, although I would wager most here would hate to edit it by hand).
Who knows what the future holds. Good luck indeed !
Who knows what the future holds. Good luck indeed !
Careful. The year of the Lisp is not far off.