On Jul 24, 2:06 pm, Raffael Cavallaro <raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote: > On 2009-07-23 23:51:02 -0400, Carl Banks <pavlovevide...@gmail.com> said: > > > On Jul 23, 5:52 pm, Rui Maciel <rui.mac...@gmail.com> wrote: > >> fft1976 wrote: > >>> How do you explain that something as inferior as Python beat Lisp in > >>> the market place despite starting 40 years later. > > >> Probably due to similar reasons that lead php to become remotely relevant > > . > > > Well, the only reason PHP became relevant because it was an > > easy > > ^^^^^^^^ > ^^^^^^^^ (emphasis added) > > > to > > deploy solution in a single application domain, the web, that happened > > to explode. > > i.e., Python "beat" lisp because it is ~70% of lisp in a form that is > much more palatable to the average programmer, just as php became > popular because it is powerful enough to do websites and, most > importantly, apprehensible to mediocre programmers and even some > non-programmers. > > -- > Raffael Cavallaro
I actually think that the thing holding lisp back is 'bus factor'. Lets assume I have a java project and a lisp project: Java project: I have maybe 10 or 12 people on my team working on various subsystems of my project. There are probably one or two 'technical leader' types in the group, and a bunch of others who are sort of 'serfs', banging out java classes. Lets say one of my important guys gets totally splattered by a bus... I've still got another one left! I can rely on the other guy to keep things afloat while I train up a new leader type. Lisp project: I don't need as many people. I have 3 or 4 people, and one person is my technical leader and lisp guru. Guru is probably in charge of more difficult macros and (because of that), also in charge of the overall design (macros are design patterns embodied in code). Lets say he gets totally annihilated by the bus. What do I do now? I had all my eggs in one basket and my project is now stalled. I think that (for example) when people are saying that lisp macros make projects difficult to understand, or that lisp hackers are much harder to find than other programmers, what they are really showing is that because of the nature of the language, lisp projects get organized in a different way. This different way of organization is especially hard on corporate projects, because managers are expected to plan for when some important guy drops dead. The problem with lisp is that if you hire too many extra hackers, you end up with a bunch of people sitting around twiddling their thumbs. This may also explain why it gets touted as an academic language. In academia if a professor who is leading some important research drops dead, who cares? Most likely no one had interest as to whether the university would make a profit on this particular research endeavor (except maybe the deceased, as he would like to get grant funding). So I guess then we can give some tips for making lisp more acceptable for 'paying gigs'. 1.) If you are a lisp hacker, it is your duty to be lazier and write less code. We need to make it so that these projects need sizable teams of people to complete. 2.) Write down everything that you do, everything you are going to do. Maybe draw some object diagrams of your important/fancy macros, make sure these are stored with the source. (You'll note that an iterative approach to programming isn't really conducive to making a lot of diagrams of stuff...) I don't know what this has to do with python or scheme or people dumping scheme for python. Honestly, I seriously doubt that any undergraduate programming course will give you enough actual programming experience to make you seriously proficient in the language (research projects not counted). The language used to teach the material is a cursory detail. -- http://mail.python.org/mailman/listinfo/python-list
