Every time I read an article from Paul Graham or any other Lisp Weenie, they're always talking about how the most powerful language is Lisp because you can use macros and lexical closures, and blah blah you can do this and that with Lisp Lisp Lisp Spit Spit Spit Lips Lips Lips Pils Pips Pips Pils Plis Plis Lisp.
The fact that Lisp allows you to create languages inside Lisp and do meta-programming is supposedly the reason why Lisp is *better* than any other programming language. Well I don't know which Lisp he is talking about since there is no single Lisp that people use (i.e. everyone does their own little thing, breaking apart the whole community, another problem with Lisp).
The Best Language is One With A Procedure and Strings
You know what, something struck me (actually, I've always known this, but I decided to write about it at this moment).
--- BEGIN SARCASM ---
Pascal is more powerful than Lisp, because I can fork my own effing Lisp interpreter inside Pascal if I want.
--- END SARCASM ---
var s: string;
begin
s:= 'powerful(because(I(can(parse(cool(languages(inside(pascal))))))';
ParseThatLanguage(s);
end.
Pascal is very powerful.. because we can do things like this in our programs:
procedure ParseLisp(s: string);
begin
// do parsing of string here
end;
procedure ParseIni(s: string);
begin
// do parsing of string here
end;
procedure ParsePhpSubset(s: string);
begin
// do parsing of string here
end;
procedure ParsePythonSubset(s: string);
begin
// do parsing of string here
end;
This above lets us build our own languages inside the language we are using. And if we have a compiler that is fast enough, we can compile our program at runtime so that it regenerates itself and then launches a second program while killing the old program. This is all cool and powerful.. but, define a reason or purpose for this power? What do we honestly need to do with these cool tricks that will help us access a database and retrieve data.. or build a shopping cart system?
The problem of course is the amount of time it takes you to build a parser.... and people claim that building a parser is too much work in many languages.. and that lisp sort of let's you parse the parser within the parser already.. instead of reinventing your parser. You might not know what I'm talking about unless you have read a lot about lisp and the way it let's you redefine lisp.
Well I built a wiki parser in only two nights and I didn't use lisp or a lisp subset so if you are experienced you can do parsing even in a more verbose language like Pascal. And I plan to use this wiki parser not just for wikis, but for other things like web forums, news post systems, offline software that let's me create quick articles instead of using bloated OpenOffice or Word, etc.
So you can make mini languages of your own.. without the language being tied to lisp macros/lisp meta programming. And it isn't that hard to build a parser, even in languages that are not lisp... if you stop using regexes and learn to parse then parsing isn't that hard. In Cee language or other forms of crap, it is hard to build parsers because of the time it takes to debug your Cee Pchars or Cee char* crap. That's definitely true. Methinks some of the Lisp folks think Lisp is so productive because they are used to using Cee.. and they haven't considered Pascal because they think Pascal is the worst language of all time (and standard pascal is bad, today.. and that is not the modern pascal I'm talking about).
Many lisp folks won't use languages like Ruby because ruby is like Lisp without the power of Lisp. Personally, I don't like Ruby as much as I would like to like Ruby because a lot of Ruby programmers are Perl wankers who use regexes for lots of stuff they don't need regexes for..
In fact you can consider Regexes just another language inside a language.. and it is a bad language.. since it is abused. Lisp, is abused too.. people make languages inside languages when they don't always need that.
So there we have it. Any programming language can create languages inside itself. Keep the scripts or other languages in a separate text file. Heck, you can even create pascal programs that build pascal program source code at run time, which calls a compiler at run time (or an interpreter) and then the program can kill itself or give birth to itself at run time. We could build compilers which then compile themselves that build other compilers and other languages which parse themselves twice before we knew what the purpose was before parsing other compiler sources that have generated themselves through compilers that are interpreted by other compiled interpreters. There is lots of power, but not necessarily so much purpose.
Have I wrapped your brain in a knot yet? Do you see the problem? All this recursively cool stuff about generating programs or scripts at run time which then regenerate themselves again is more of an academic thing rather than a useful thing. I mean, academically, someone could write a good University Thesis Paper about how a compile compiler compiles compilers which compiles compiler compilers that ends up interpreting another compiler. Buy why?
I don't see why if there is a simpler solution which is more dedicated to doing the job.
Structure Theory
Houses are structures... and any house can be extended. But isn't the structure more important than the ability to extend? In order to extend a structure, first you have to have some structure that serves a purpose. If you just have extendability and almost zero structure, then you are just extending extensiblities without structure! That's what lisp is: no aim or direction, just extending extension.
Really, anything can be extended.. but there must be some initial useful structure in the first place. Does lisp have this initially useful structure, or does Lisp cause everyone to go off inventing their own lisps?
Lisp Is Some Good Dirt
Imagine someone gives you a piece of Dirt and says "this dirt will build you a house if you find some seeds and then plant them and grow trees.. isn't dirt powerful?".
Yeah, dirt is powerful - but it's also brown and it looks like shit - and it doesn't really help me right now with my real world problems.. I think I'll go find a Pulp and Paper mill and ask them to give me some logs, or maybe I'll just call the Housing Development Company and ask them if they can build me a house.. because although the Housing Development Company is not as powerful as Dirt itself.. they at least provide me a useful framework FOR MY HOUSE TO BE BUILT. And although dirt is more flexible than a Housing Development Co. since I can do anything I want with dirt.. the fact is that I don't necessarily have time to turn dirt into a house! Especially at this point in my life where I'm already, uhm, kinda busy, you know?
So what is the problem with lisp macros and meta programming and all that? The problem is that it is powerful and cool but for what purpose? If we can use a subset of a language that is limited - then it gives us aims and goals (for example an INI file is dedicated for configuration settings.. it is not dedicated to do while loops). Without an aim, direction, and purpose - a language becomes useless - and Lisp is perceived as useless by the programming community since it can do 'everything' and it is 'the best language to do anything since it is the best language'.
You can even fork a pascal interpreter from within a Lisp program. Ooops, now Lisp must be more powerful than Pascal because Lisp can parse Pascal? Or maybe Lisp weenies just aren't in the know.. people in the know, know that there isn't one most powerful programming language.
Seriously, the problem with Lisp is that it doesn't serve any specific purpose - you're supposed to make the Lisp language do whatever you want by making your own languages inside lisp. Can I ask, who the eff has time for that? Programmers need libraries. I can build a cute Lisp interpretter or Lisp Parse procedure inside my Pascal program but why would I want such a thing? I can convert all my HTML to lisp and parse it and generate HTML.. but why, if the HTML designers aren't going to understand lisp?
The problem with Lisp is that there are no standards - you invent your own lisps and your own macros. Does the car drive, or does the car fly? What's it going to be?
You have to have some dedicated structures and libraries for programmers to use. Things like API's and units. Being able to extend lisp inside lisp isn't neccessarily what real world developers are looking for - because any language can fork an interpreter or the language can parse a string within the language!
Lisp may have lots of API's an units that can be used.. such as hookups to the WinAPI and libC. This isn't really the problem with Lisp. The problem with Lisp is that people that use Lisp think that Lisp is good because Lisp is Lisp. This isn't what real world developers want. People want a programming language that focuses on being useful in the real world. Lisp focuses on being cool because Lisp is Cool. That's why they have social problems in the Lisp Community. Recursively, people use Lisp Because Lisp Is Lisp. This an impossible recursive statement, and this is why Lisp fails.
Let me repeat it again. People think that Lisp is good because Lisp is Lisp. But that doesn't attract any real world developers.. because Lisp has got to do something more than just Lisp. A 'Lisp Lisp' doesn't do us any good. It just creates never ending Lisp recursion leading to more Lisp.
We All Make Languages Inside Languages
Let's take for example when people use {$macrovars} inside a GUI program that has a tools menu such as text editors. {$CurOpenFile} and {$CurSelection} come to mind. Or we also see $macrovars inside HTML templates. Parsing a string containing {$macrovars} is actually inventing a mini programming language inside your existing language. You're inventing a language that is better suited for a certain task.
INI files and CONFIG files are another example of inventing mini programming languages. If the INI and CONFIG files were a full fledged programming language, then people wouldn't enjoy editing their INI files and that would destroy the purpose of an INI file.
Even an Edit Widget that has a wildcard in it is a mini programming language that we have to parse.. we have to find the asterisks and special characters. We've created a mini programming language that needs to be used inside another language.
Well, there is nothing stopping someone from building a Pascal program that creates more Pascal programs, which then create other Pascal programs. But why do this? It sounds cool and powerful.. but is it really what developers need?
What Developer Need
Most of the time developers are looking for something like this:
Call_Some_Code()
CallSomeCode()
call-some-code()
Where are we calling this code from? We are calling it from someone else's nice little API that they so politely wrote for us (sometimes for free, sometimes with bugs).
The above is what API's and libraries are all about. Calling other people's code.. and consistent code that doesn't change. Consistent libraries that have, well, consistency to them. Consistency is important so that we can remain sane, instead of becoming, well, insane programmers.
Oops, lisp isn't consistent. Problem 22 (catch). The whole point of Lisp is not to be consistent. You can create any Lisp you want inside Lisp. Oh. Shit. That's good. But, in reality, that's, NOT good.
(Yes, i realize that the () brackets in Lisp make it consistent, but that's not the consistency I was talking about. I was talking about library consistency.. and if everyone is inventing their own Lisps, you have to relearn Lisp each time you read Lisp, which is avoiding consistency)
The fact that the language can create other languages inside languages and do meta programming and lexical closures is really not what developers are looking for. Developers are looking to reuse code that other people have written. Any real programming language can utilize a parse() algorithm which parses another language inside a language. That's why Lisp isn't so good as they think it is. I realize it is not quite the same as a macro system built into the language.. but my point is that macros are not always the only way to extend a language inside a language.. you can instead just fork an interpreter. When ever we parse INI files or config files we are using a language inside a language! That doesn't require lisp macros or lisp.
Developers Want Blackboxes
An operating system itself is just a bunch of code that we reuse each day. No one wants to look into the operating system kernel source code so that we can invent a meta programming language that rewrites the kernel at run time.. we just want a working robust kernel blackbox that has a library available that we can tap into! The linux API is just a blackbox that people tap into. The WinAPI is a blackbox that people tap into. HTML is a blackbox that people tap into. Blackboxes are structures. Without structure, you don't have any direction, purpose, or aim. Lisp, has no aims or direction. There lay the problem.
Yes, even Open Source folk want blackboxes. Not many Linux users look into the kernel source code each day submitting patches and changes. Only a few do. Linux users treat the kernel as a nice blackbox to run programs on. Even if the kernel has meta programmable source with extensible macros in it, no one would give a shit. What's more important is the fact that the kernel is reusable and has an API. What's not important is whether the kernel is written in Lisp with meta programming and macros.
|
