Parentheses are not Lisp's problem. The lack of useful and compatible libraries is.
Lisp is basically a ghetto where it's every man for himself. You have all the tools to build the most wonderful abstractions ever, and many people do. The problem is that person A's abstractions don't play well with person B's. And that means where the other less-perfect languages have libraries that everyone can share, with Lisp, you're stuck with your own.
This is not a result of syntax flexibility, though, it's the result of attitude. Perl has pluggable syntax and nine billion different ways to do OO. And yet, all the syntax extensions are composible. An object created with Moose can be subclassed "by hand". It all works.
It's attitude, not tools. If you believe that you're the smartest person in the world and that only you see the light... well, it's going to be lonely. And programming is about 50% being smart and 50% not reinventing the wheel. The attitude of a "smug lisp weenie" immediately puts him 50% behind.
(BTW, I say this as a CL fanboi. I love the language. I can just never do anything fun with it, because I have to decipher ten different libraries for writing unit tests, none of which have all the features I need.)
It's not a lack of libraries - there are probably too many libraries, and all of them subtly (or blatantly) incompatible and difficult to use together.
You need a bootstrap. Ideas for libraries come from writing applications. If you can't get some sort of app started, you aren't going to have any ideas that should be distilled into a library.
In the last paragraph, the author talks about how (paraphrasing - the site won't reload, so I can't get an exact quote) Lisp provides a set of powerful tools that you can use to build any abstraction.
I haven't really used Lisp beyond a few toy projects, but it seems, in this respect, to be similar to Javascript, which I do have quite a bit of experience with. The classic example in Javascript is inheritence. In his "Advanced Javascript" talks, Crockford lists three different patterns for inheritence, each of which is incompatible with the others. Furthermore, I know from experience that each of the techniques has some severe drawbacks - some (such as Crockford's "parasite inheritence") are incredibly wasteful of resources, keeping a copy of each function declared for the object with every instance. Others, such as "pseudoclassical inheritence" don't work if you want to inherit from a native object.
I use Javascript for my day job, but my favourite language is Ruby. And I can't help missing the fact that it is much easier to share code with other people in Ruby (largely because it does have defined mechanisms for code reuse) than it is in Javascript. I'll never get two objects in Ruby that can't be used the same way because their system of construction is different.
I appreciate that such flexibility helps with the expressiveness of the language, but when expressiveness comes with the price of not being able to easily work with others, I can't help wondering if the price is too high.
This depends on what you mean by "I'll never get two objects in Ruby that can't be used the same way because their system of construction is different." You have very few guarantees in Ruby, even fewer than in JavaScript.
It took me a while to figure out how your comment was relevant to your parent, when I realised that you interpreted "system of construction" differently. (I humbly posit that) You are demonstrating how to create an instance of a Struct or Class, whereas the parent's intent was how the Struct or Class is implemented behind the curtain.
This comes down to whether a languages is "opinionated" or not - whether it claims that a certain way of doing things is the best and makes it easy to do. I've realized I tend to like opinionated languages more. I still want it to be possible to do anything I want, but for the common case, having a sane, opinionated language lets me worry about my problem and not about, for example, implementing an object/dispatch system.
While I can appreciate the sentiment, it's kinda funny to say "Once you get past Lips's parentheses..." to someone who's just said, "I don't like fighting with languages."
First, that wasn't said. It was "[o]nce you get past Lisp's idiosyncrasies", such as those described in a later post. It does not talk about getting past fundamental language features that are perhaps missing.
I personally believe we have so many programming languages because we have many problems to solve. When it comes to bad programmers, that's because they use and defend just one language.
A good programmer is one that knows as many languages as possible and uses the correct language for the job.
For example, if you need to create a nice UI then you use CSS and Javascript. If you need a simple server side language then you use PHP. If you need a program to be fast yet small then you use C. If you need scalable performance then you use Java. All of these languages have their purpose and using them correctly makes a good programmer.
It's funny, I'm not particularly fond of formal mathematics, and I always thought it would be made really easier if it looked more like programming. One thing I particularly hate about math are the inconsistent and often not very legible notations.
Let's also not forget that Lisp was originally conceived as an alternative mathematical notation.
YES! As a programmer it really annoys me the way mathematicians insist on using single letter variable names. Programmers doing this get laughed out, no exceptions.
Even worse, using the same single letter and adding ` (prime) after it different numbers of times! WHY IS THIS ACCEPTABLE?
I understand a lot of it has to do with blackboards, but this does not apply in a teaching scenario! You do not need to worry about characters-per-minute on the blackboard until everyone in the room is a maths prostgrad. Don't inflict that shit on me and my fellow computational complexity students. Any minor ergonomic gains are offset by that fact that half the room has no fucking idea what is being written about.
edit: the WORST thing is when all the single-letter variable names are letters that RHYME. e, c, d, p, g. There are other letters dammit! We're not all on your end of the autistic spectrum! Have some consideration!
I think this is why some programmers go through periods of having to be told what to do. It's easier to swallow telling yourself you're working with a certain programming language when it's assigned.
I think if DHH hadn't had the php constraint, he might have got lost trying to decide which church was true. After a few years of php he was able to forge ahead with a language that fit his ideals better.
I think if someone finds themselves similarly stuck it might be good to spend most of their programming time on something popular for a while.
Lisp is basically a ghetto where it's every man for himself. You have all the tools to build the most wonderful abstractions ever, and many people do. The problem is that person A's abstractions don't play well with person B's. And that means where the other less-perfect languages have libraries that everyone can share, with Lisp, you're stuck with your own.
This is not a result of syntax flexibility, though, it's the result of attitude. Perl has pluggable syntax and nine billion different ways to do OO. And yet, all the syntax extensions are composible. An object created with Moose can be subclassed "by hand". It all works.
It's attitude, not tools. If you believe that you're the smartest person in the world and that only you see the light... well, it's going to be lonely. And programming is about 50% being smart and 50% not reinventing the wheel. The attitude of a "smug lisp weenie" immediately puts him 50% behind.
(BTW, I say this as a CL fanboi. I love the language. I can just never do anything fun with it, because I have to decipher ten different libraries for writing unit tests, none of which have all the features I need.)