Earlier quoted context omitted.
But you can format and indent your lisp code so the reader (people) doesn't have to rely on counting parentheses. Example from taken from http://www.gigamonkeys.com/book/ (defun test-+ () (let ((*test-name* 'test-+) (another-var 'foo)) (check (= (+ 1 2) 3) (= (+ 1 2 3) 5) (= (+ -1 -3) -4)))) You should be able to read what this code does (check basically runs the statements and reports if they return true or false) w…
I agree that lisp can be made readable. And C can be made unreadable. OTOH lisp encourages deep nesting, which makes it harder to be readable. Here's a rougly equivalent program, if I read the lisp correctly. void test-+() { *test-name* = test-+; another-var = foo; assert( 1+2 == 3 ); assert( 1+2+3 == 5 ); assert( -1 + -3 == -4 ); } I'm not saying that this is any better than the lisp equivalent - the lisp function i…
Why Lisp Is Unpopular
111–120 of 159 posts
Re: Why Lisp Is Unpopular
#112Earlier quoted context omitted.
In my experience, Common Lisp often doesn't come out best at the code snippet level. Where it shines is in building whole systems. After a while one passes an inflection point where one realizes, "Holy cow - what I'm doing now is supposed to be way harder than it is". I probably have this experience every week. You obviously put a lot of sincere effort into learning Lisp and I agree with much of what you say. After a…
It may well be that it only really becomes apparent on larger projects. It's hard to get to that point, though, and maybe that's why the takeup is low. OTOH, some languages are particularly good on small things, but don't offer much help for large problems.
Re: Why Lisp Is Unpopular
#113Re: Why Lisp Is Unpopular
#114Earlier quoted context omitted.
I can't help but think that people who want to replace HTML+CSS+JS haven't written a widely used web application before, because the idea seems so absurdly impractical and would become such an incredible time sink.
I'd tend to agree on those who want to replace HTML/CSS/JS with some other abstraction. What I'm suggesting is that they're arbitrarily divided and should be unified under one syntax, which then compiles into the served "bytecode." JSON would probably make the most sense. But, as you suggest, it would take some time to get it right. So I'm sticking to doing it by hand, all divided up, for now. Maybe after our startup…
Most of lisps problems these days stem from social issues and logistical issues. The core tech is excruciatingly sound, and the language itself is great.
To someone out in the startup circles, it almost seems like Lisp and Scheme focus more on being a standard than being a pragmatic and global platform. While noble, this is not the path to massive popularity. Some people might be okay with that, but it seems to me like you could serve both goals and end up with an overall better product.
Re: Why Lisp Is Unpopular
#115Earlier quoted context omitted.
The point is that "requires you to think " is not a feature, it is a bug, because that thinking could be put to better use on whatever it is the program is trying to solve. Everything else being equal, this means that language features that can be used without much thinking will do better than language features that can't.
So programmers who work with objects and methods don't have to think about them, while programmers who work with macros do? Sorry, but this just seems ludicrous to me. Perhaps what you mean is that when a construct is unfamiliar to a programmer then they have to think harder about how to use it? http://www.google.com/search?q=blub
No, I don't mean unfamiliar. Things like parentheses and prefix notation are unfamiliar to many people, but once learned, they don't require much more cognitive processing than other notation. There are several things in Java that are similarly weird until you learn them.
Re: Why Lisp Is Unpopular
#116Earlier quoted context omitted.
So programmers who work with objects and methods don't have to think about them, while programmers who work with macros do? Sorry, but this just seems ludicrous to me. Perhaps what you mean is that when a construct is unfamiliar to a programmer then they have to think harder about how to use it? http://www.google.com/search?q=blub
I am saying that working with objects and methods requires less high-level cognitive processing than macros and continuations, not that you don't have to think about them. This is because the brain can treat the objects largely as if they were physical objects. With macros that is much harder. No, I don't mean unfamiliar. Things like parentheses and prefix notation are unfamiliar to many people, but once learned, the…
Certainly if you're habituated to the object-model style of programming, other forms of abstraction may seem weird. The irony here is that twenty years ago, the people making your kind of argument were directing it all against objects.
As a side note, treating programming objects as if they were physical objects works as long as there's a good fit between the two. As soon as you need the objects to behave in ways that physical objects don't (and believe me, in any complex OO system, you will), you find yourself tied up in knots that it will take a lot of thinking to extricate yourself from. (Speaking of complexity that isn't intrinsic to the problem...) Not accidentally, the tools that people reach for then tend to be ersatz versions of metaprogramming (reflection, code generation), and Greenspun is off to the races...
Re: Why Lisp Is Unpopular
#117Earlier quoted context omitted.
It may well be that it only really becomes apparent on larger projects. It's hard to get to that point, though, and maybe that's why the takeup is low. OTOH, some languages are particularly good on small things, but don't offer much help for large problems.
Just out of curiosity, did you like working in Lisp? I mean, if you can abstract away from the annoyances you cited, did you actually enjoy the Lisp mode of programming (basically, writing syntax trees)?
The "I did": It seems very sensible to use s-expressions for everything. That lispy syntax meant that I started seeing ways to encode almost everything as lisp. I even started keeping a todo list in s-expressions;
(do (buy bread) (tidy (kitchen living-room bathroom)) (get life))
The classic XKCD cartoon had it perfectly: "I felt a great enlightment. I saw the naked structure of Lisp code unfold before me. The patterns and metapatterns danced. Syntax faded"
I didn't: when it came to actual common lisp, cracks started to appear. The crazy mini-language for looping. The arbitrary-sounding names. The feeling that, if I ever wanted to do anything remotely windows-specific I would face years of horror.
I've blooged about it more at http://www.stevecooper.org/2008/02/13/impractical-uncommon-l..., if you've got too much free time. ;)
Re: Why Lisp Is Unpopular
#118Earlier quoted context omitted.
My tentacles have only found two decent hashtable-oriented languages: JavaScript >~1.5 and Io. I'm not sure whether or not you'd find it "decent", but you might consider adding Lua to your list. It's small, relatively fast, and uses hashtables as its composite data structure. It also has some other neat stuff, like tail-calls and coroutines.
Thanks for the tip. I've heard some good things about Lua, but never gone further than Wikipedia.
The basic structure is the hashtable. You can use any first-class value as a key (number, string, function, another table) and similarly any first-class value as a value. Creating a table is done with the table constructor "{ }" ('> ' is the repl prompt):
> a = { }
So now we have an empty table named 'a'. Let's say we wanted to have a table containing a list of colors - this is represented in Lua as a table with ascending integers as the keys. (Starting at 1, rather than 0, which is a bit unconventional) > a = { 'red', 'green', 'blue' }
This is equivalent to saying > a = { [1] = 'red', [2] = 'green', [3] = 'blue' }
If we use strings as keys, we start seeing some of the syntactical sugar Lua offers. Let's look at favorite foods: faves = { bob = 'pizza', george = 'cake', mary = 'pie' }
Note that no quotation marks are needed around string keys. (Well, unless the key is a language keyword. That's a bit annoying, but is related to the single-pass compilation, which is valuable. { if = 'can't do it' } fails. { ["if"] = "can do it" } succeeds.)We can use numeric indices along with string ones in the same table:
mixed = { 'a', 'b', 'c'; state = 'NC', city = 'Charlotte', county = 'Mecklenburg' }
If we want to access values from a table, we can use a subscript notation. > print(a[1])
red
> print(faves['bob'])
pizza
Here's a winner though. If we want to subscript a string, we just use the dot notation. > print(faves.mary)
pie
What happens if we subscript a nonexistent entry in a table? > print(faves.james)
nil
No error is thrown, which is handy. Tables are defined as having the unique value nil as the value for all nonexisting keys. In fact, if you wanted to remove an entry from the table, you just set the key to nil: faves.george = nil -- the cake is a lie! And the key 'george' is removed.
One nice thing about Lua tables is that they are extremely regular. There aren't special cases in their behavior. They're easy to construct, inspect, and manipulate. They are the fundamental data type of the language, and everything is done in terms of tables. Objects are created out of tables. Namespaces are tables. Modules are tables. Configuration files are tables. It's an extremely clean and convenient design.In addition to the tables, you get first-class functions:
> function a() print 'hello' end
> a()
hello
Is syntax sugar for: > a = function() print 'hello' end
> a()
hello
These syntax sweeteners we've seen work together, too: > function a.foo() print 'world' end
> print(a["foo"])
function: 0x807f2e8
> a.foo()
world
Ok, we're almost to objects. The next sugar we see is the ':' notation. > a = { color = blue }
> function a:fave_color()
> print('My favorite color is ' .. self.color) -- .. is concatenation
> end
If a function is defined with the ':' notation then it has an implicit local value called 'self' which is set to the containing table. > a:fave_color()
My favorite color is blue
At this point it's pretty easy to create simple prototype-based objects.What brings even more power to the table is that we can define custom behavior on each one. We can set a 'metatable' which defines how the table responds to subscripting, the various mathematical operators, and being called in the functional position. In a quick script I worked on I implemented a prototype-based class system in under 20 lines of code, all with the power of metatables. Lua tables are very powerful and though similar to the ones in Javascript are even cleaner and more pleasant to work with.
Anyway, it's all nifty stuff. Other features you get: fast incremental garbage collection, first-class functions, asymmetric coroutines (isomorphic to one-shot continuations), lexical scoping, closures. Lua is also one of the fastest interpreted languages and has an excellent API for binding to C if you want to do something performance sensitive, or want to use a library written in C. The language itself is written in 100% pure ANSI C. It runs on everything from embedded microprocessors to mainframes, in lego robots and on space satellites. And the community is very friendly.
If you want macros, there are several community-run variants of the language with macro facilities... I haven't gotten very deep into those though.
Good documentation for getting started:
http://www.lua.org -- official lua home page
http://www.lua-users.org -- lua community wiki
http://www.lua.org/docs.html -- lua documentation
http://www.lua.org/manual/5.1/ -- lua language reference
http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf -- a fascinating article on the history and features of lua
Check Lua out and see how you like it. I find it to be a very pleasant language which is fun to work in.Re: Why Lisp Is Unpopular
#119Earlier quoted context omitted.
"I've tried really hard to learn lisp, and it turns out that actually, while there may be some platonic lisp that IS great, actually programming common lisp, now, is a massive effort in struggling in the dark." The weedout process has worked its magic again ;P You usually get rewards proportional to the effort... I don't think lisp is beyond anyone's reach if they work faithfully on gaining proficiency in it for 3 mo…
"The weedout process has worked its magic again ;P" Please don't call me a weed. You point out that the more effort you expend, the better you get. The problem is the rate of reward. Getting a productive lisp environment is hard work. Competing implementations, sometimes-compatible libraries, very little documentation -- these are things that make lisp, holistically, hard to adopt. Every other production language mak…
Exactly. Common Lisp is close to a superset of the features of other programming languages.
Even in cases where Common Lisp lacks a feature, if it's something that can be expressed by changing syntax, macros can get you pretty close. I remember a thread on comp.lang.lisp where several people had a go at adding pattern matching to Common Lisp, for example, and were able to get a pretty long way towards that goal in a short amount of time. Another example: seems like half of the Lisp books out there present an implementation of Prolog in Lisp.
Re: Why Lisp Is Unpopular
#120The power of a programming language is proportional to its capability for innate abstraction. If that's true, it follows list-oriented languages are inherently inferior to their hashtable-oriented brethren. (These orientations are often misguidedly referred to as "functional" and "object-oriented" paradigms, which I find to be useless, over-overloaded terms.) Basically, with list-oriented langs the primary abstractio…
And what about CLOS? Does not make Lisp, in your words, a "hash programming language"? Really I don't get the difference you state between list/hash programming languages, I've work a little with EcmaScript and I don't know anything about Io, but I'll put it in my to-do list. Can you, please, extend it? What's the main difference between them? Because you say that the primary abstraction of a "list" programming langu…
I think in the "hash" languages, you usually consider the method to "belong" to an object in some way.
With multi-method dispatch, the relationship between objects and methods is more fluid. So I think there is a difference here, too.
It's not that "list" languages only use tree structures for everything, just that trees are the more "natural" choice in those languages.