Paul Graham has written extensively on how languages are becoming more and more like one from yesteryear: LISP.
See Beating the averages [paulgraham.com] for a well-written and thoughtful essay.
In a nutshell, languages themselves vary in power. No one disputes that. All things being equal, you should generally choose the most powerful language you can all the time. As we move more and more to server-hosted software, your choice of language is incredibly important because a) it's your choice, not forced on your by being the language of the OS and b) it can be a huge competitive advantage.
Matz (Ruby's creator) acknowledges ripping off ideas from Lisp (but putting a friendlier face to it). Python is Lispy. Javascript has been called Lisp in C's clothing. These are all functional languages, or can be used functionally.
Graham noted how all languages are trending more towards Lisp in terms of features (see the essay linked above). Want further proof? C# 2.0 is getting lexical closures. Innovation from Microsoft! These were available in Lisp for 30 years, javascript for 10 (since it was created), they're in Perl 5, Ruby, I can go on...
If languages continue to become higher and higher level, wouldn't we need to investigate this weird AI language from 1958 and see what features it doesn't have in order to do more meaningful research? 'cause these days, all the "new" features of today's languages are decades old...
For newbies to Lisp, the parentheses don't vanish because of some mystical enlightenment. They vanish primarily because you've written your code according to a standard that specifies how it is to be indented. You parenthesize correctly when writing then simply ignore the parens when reading and look at the indentation level.
Of course I'm doing some handwaving here about the writing it correctly part. Until you memorize the major idioms, you'll often experience starting something with a single paren when it really needs to start with two, for example, and you'll get weird behavior that ends up driving you to randomly adding and removing parens until it seems to work. Admittedly that's a bit of a hurdle at first, but after some experience, that part gets easy. (Like glancing at for (int x=0; x10; x++) and reading "do it ten times" without having to think about it. A lot of people forget how much thinking a newbie has to do to parse such an expression the first few times.)
The real problem with Lisp isn't the parens. Once you get over the initial hurdle, you just look at the indentation. The problem is that dev platforms these days are so much more than just a language. The basic concepts underlying a Lispy language are almost timeless. The whole rest of the dev system, though, has a shelf life of about a decade or less, after which time the way it is made available, the libraries, the editors you have to use, the string model, the constraints it's optimized for, the compromises it has made, its interaction with other technologies, etc., are all out of touch with current realities. Such is Lisp today.
(Paul Graham once seemed like the guy who could rejuvenate Lisp, but each year that passes makes that less likely. Speaking of out of touch with current realities.... Even Microsoft's secret projects are more open.)
Reminds me of a post I saw on Usenet (r.h.f.?) many years ago; I can't find a reference to it any more, but it was someone claiming to have a copy of the LISP source code to SDI (Reagan's Star Wars project, from way back). They proved it by showing the last page of the code:
Slashdot won't let me post it, but it was a solid page of ))))'s.
If you're afraid of parenthesis, then you'd better not use XML! It has TWICE as many parens as Lisp. You should get a job flipping burgers or something, instead.
Also, the facts that they're never nested directly next to each other and that they describe themselves helps. With LISP you get stuff like
(((((this)))))
where it's difficult to count the number of parens, and what they close depends solely on their placement. In contrast, something like
<1><2><3><4><5>this</5></4></3></2></1>
would be the equivalent in XML. As you can see, even though there's no whitespace it's still easier to read because each tag describes what its closing and is easier to pick out from its neighbors (for easier counting).
Of course, all this ignores the fact that LISP and XML can't be directly compared anyway, since one is a programming language and the other is a data format!
1) Lisp is a data format, as the previous poster pointed out. Shame on you for missing one of the most important points about Lisp.
2) XML is a data format, which is used for many different programming languages. Shame on you for missing one of the most important points about XML.
Even if you didn't score zero out of two, what is it about XML's angled brackets that make it ok to use twice as many of them, than Lisp's parenthesis? Is it the smooth curves of the Lisp parens t
The entire Jakarta Project is an attept to reinvent as many wheels as possible using XML and Java. Ant is a good example of how they take a decent idea for a program (make) and rewrite a broken version in Java with unmaintainable XML syntax.
Excuse me, but there is NOTHING decent about "make [cowboylyrics.com]". As long as we were talking about syntax, how do you like the way makefiles distinguish between indentation with tabs and spaces.
One of the coolest parts of the Java tool chain is ant, which uses XML instead of make's ridiculous syntax.
Ant has its limitations because it doesn't provide an actual scripting language. That's one of the problems that Jelly is attempting to address.
Another approach to programming with XML that works well is embedding a
Now tell me what it means. Specifically, tell me what expression it ends.
In contrast, take this XML example:
</p>
Now tell me what expression it ends. See how much easier it is?
See, that's the difference: In XML, the angle brackets aren't units really units of syntax in and of themselves; tags as a whole are. Moreover, in XML these units of syntax are self-discribing. Also, angle brackets are never nested; they always occur in "" pairs without any more brackets between them.
Comparing Lisp TO XML is still apples to oranges. There are cases were simple data formats (e.g. Lisp, JSON) are better, and there are cases where self-describing formats (e.g. XML) are better. Just try creating a Lisp equivalent of XHTML, and you'll see what I mean.
And you know, if being able to identify the trailing end of a block out of context was a common job in programming, that might be a serious issue. Similarly, you might well claim that MathML is a better programming language than C because it provides better control of vertical positioning of complex algorithms in flow than C's flat text, and what if the screen was too small to see the whole alg? Back in the real world, the answer to your question is simple.
Now tell me what it means. Specifically, tell me wh
Wait, you're lambasting someone who thinks the most important feature of a language is how it denotes its blocks for not grokking a language? Isn't that like berating your dog for insufficient calculus skills? Another point: Your "(((((this)))))" example is a straw man argument. Lisp programs use white space and indentation to make the structure clear, just like any other programming language.
The phrase you're probably looking for is "red herring," though in fact it's also not a red herring. A straw man ar
hold on, you're saying that reading:
<1><2><3><4><5>this</5></4></3></2></1>
is easier than reading:
(((((this)))))
?? I'd rather read the lisp, there's just one thing to read: 'this' whereas the xml has all those numbers, and they have to match, and they have to be in order, what matters 'this' is now buried and do not stand out whatsoever; what the?
By the way, please learn XML (and Lisp) before arguing that XML is a better syntax than Lisp. You can't use numbers as element names.
The XML page cannot be displayed
Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later.
A name was started with an invalid character. Error processing resource 'file:///C:/temp/moronic.xml'
<1><2><3><4><5>this</5></4></3></2></1>
-^
The examples used were just that -- examples. They aren't real code, nor would they even be valid code (see the other reply). The point I was trying to make, though, was that the tags in XML hold meaningful information, whereas the parentheses in LISP don't. In the Real World, those numbers wouldn't be numbers, so the XML example would represent much more information than the LISP example. If we compared examples that contained equal amounts of information, the XML would be more obviously better. The LIS
You said: "so the XML example would represent much more information than the LISP example"
They "represent" the same amount of information. Requiring you to repeat the same information twice is not the same as representing more information.
Each level of nesting in XML requires you to use a tag name, even if it's not necessary to represent the information required (a 5-deep array of a single string, in this example). So XML requires you to insert extra useless information, and then repeat it. It results i
They are different types of languages so comparing them makes little sense. I disagree that xml is hard to read though. Some people create lame schemas that are hard to use (see tomcat config files for an example). Note i used () there:) In most cases, XML is used to markup data to make it more meaningful to the computer. A tag indicates some property or identifier on data. An extension of this idea makes it useful. RDF comes to mind.
I personally like to use xml heavily for data storage when writing w
Of course, all this ignores the fact that LISP and XML can't be directly compared anyway, since one is a programming language and the other is a data format!
Try again, grasshopper. In lisp, the program is the data is the program. There is no distinction. XML is simply s-expressions without the ability to execute them.
<lispFanatic> XML documents can be represented as S-Expressions, makeing XML a poorly implemented Lisp, a la Greespun. </lispFanatic> I agree that the parens are nasty. Still, I belive FP is the way to go.
Well, you could easily write programs with XML by just defining an appropriate DTD and a correcponding semantics. For example, a program in an FPML (Functional Programming Markup Language) could look like this:
<function name="fac">
Calculate the factorial of an integer
<argumentlist>
This function takes only one argument: The integer to calculate the factorial for
<argument name="n" type="integer"/>
</argumentlist>
<precond
Also, the facts that they're never nested directly next to each other and that they describe themselves helps. With LISP you get stuff like
(((((this)))))
Erm, no you don't. You might conceivably have a data structure with that level of vacuous nesting (just as you might have in any other language, where it wouldn't be any more readable than in Lisp), but actual Lisp code would never look like that.
I prefer Haskell to Lisp mself, but it's sad to see ignorant criticisms inevitably modified insight
Excellent point, despite the lack of explanation! I was thinking about the semantics and how the XML tags carry additional information not present in the lisp version. I think your comparison of syntax is much more accurate, though others may disagree.
I wish I could moderate you both funny and insightful.
WTF?! First I get people flaming me because they say that LISP and XML are both data formats and programming languages, then I get one flaming me saying that they aren't! If you cared to read, I already stated your third point myself!
The difference between a programming language and a tag "language" for presenting data structures is obviously of no concern to you. XML is actually rather easy to learn (that is, the XML specification, never mention the additional techniques around it). There are excelent editors (that display the XML in trees) just for you. Not so with Lisp, displaying Lisp in a tree would do little to nothing for readability.
Anyway, XML uses </tag> to show the end of a tag, while lisp uses ). I know which one I pref
In practice it has a very clean and elegant syntax though. If your editor doesn't do bracket matching you might have a few issues, but then what sort of half assed editor are you using?
Besides you can always try ML or Haskell which are much more pure functional than LISP and have hardly any parentheses (which I actually find occasionally irritating).
... and the irony is that the parentheses aren't
necessary. camlp4 [jambon.free.fr]
is a macro language for extending
ocaml [ocaml-tutorial.org]
and it shows that you don't need to express
the language unnaturally just to allow
macros.
Can you name a programming language that doesn't require you to balance all your parenthesis?
(Of course Forth lets you define words with any punctuation, even unbalanced parens, like "<BUILDS" and "DOES>", but the punctuation doesn't mean anything other than being a character in a token.)
Perl proves your point wrong. It has a horribly crappy syntax, and lots of people use it.
I am a Perl lover and the only lanuage I'd really prefer is Lisp. (Nice macroassemblers like C takes place three in my top list.)
The reasons are very different.
Perl breaks every "rule" for programming languages but still work; a hilarious combination of ugly, neat and power. Wall was into linguistics. Perl is like my beloved second language, English; funny and rich.
Have you programmed in Lisp? I haven't used it much,
but when I did it seemed elegant and natural.
It's kind of like the difference between infix and postfix notation:
2 + 4 * 3
vs.
2 4 3 * +
It might take a little practice to get used to postfix
notation, but there are clear advantages to it. The reason I don't generally use Lisp isn't its syntax, but rather that I couldn't find sufficient libraries for it.
I learned "Scheme" which is a variation on Lisp. But both use 'prefix' not 'postfix' notation.
(+ (* 4 3) 2)
At least one of the serious problems I have with the whole prefix notation is that it tends to place the operator (in this case '+') pretty far from one of the items being worked on (in this case the '2'). This is a simple example and thus not *too* difficult. But some of the more complicated things I'd written exposed that flaw quite clearly.
I started on BASIC, then learned PASCAL. Moved on to C, then C++. At some point I did scheme, Java, korn shell scripting, bash scripting, Perl, PHP, jsp, javascript, etc. Many of those languages are not alike.
This is not about similarity. This is about an *aweful* syntax. Just plain bad IMHO.
Is it about "*aweful*" syntax, or awful spelling? Or are you full of awe?
What's wrong with parenthesis? If you hate parenthesis, then do you hate XML twice as much as Lisp?
Lisp syntax is excellent because it's simple and consistent, and that's the reason Lisp macros are so powerful. Perl syntax is absolutely awful, and that's the reason Perl will never have macros like Lisp.
Is it about "*aweful*" syntax, or awful spelling? Or are you full of awe? What's wrong with parenthesis? If you hate parenthesis...
What's wrong with it is that you spelled parentheses wrong. One parenthesis, multiple parentheses. But at least you're consistent in your misspellings.
And yes, FWIW I hate XML as well. Did I make any indication that I felt otherwise about XML? Did I even mention XML? Why do you care so much about XML?
I also don't recall saying that I hated parenthesis. I've got nothing against them per se. I dislike LISP and Scheme and the like because of their syntax. If you didn't like "C" because of its syntax, I wouldn't assume you dislike curly-braces.
The only thing that actually makes XML slightly better
If you believe that XML Sucks [c2.com], then what's wrong with it, how would you fix it, what would you propose as an alternative, and what do you use instead?
I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.
There's an interesting discussion of Lisp -vs- XML [c2.com].
Some people think
The only thing that actually makes XML slightly better to deal with is that it's a document format, not a programming language.
Erm, XML and S-expressions are both data formats. It so happens that S-expressions are used to express programs in a number of programming languages in the Lisp family, but this doesn't stop them being a data format. You're very confused.
Fine. I concede. Jebus, will you List/Scheme folks stop bitching about XML now? I never even mentioned it. Lisp sucks, it'll never come back. Thank $DIETY it's dead. I'm done here.
So do you agree that you should reject XML for the same reason you reject Lisp: too many parentheses? Or do you claim that it's easier to read twice as many XML angled brackets with repeated tag names, than Lisp parenthesis? If so, then why's that?
More properly, Lisp macros operate on the program structure itself. Macros for languages like C and C++ operate on text. I believe this is the why most programmers don't immediately comprehend why Lisp macros are so much more powerful and useful. They are used to macro systems which are useful for for putting CONSTANT_VALUE instead of a hard-coded number in the program text, but quickly become a bear to use when it is time to do something more sophisticated.
You can't make a false statement true by writing it a lot of times, but you can make a bunch of fools believe it.
Lisp is a programming language and also a data description language. Lisp programs are exactly the same stuff as lisp data, so Lisp macros operate directly on lisp programs as well as any kind of Lisp data (S-Expressions), which makes them extremely powerful, in ways that C-preprocessor-like text substitution based macros and type system based C++ templates simply can't approach. Lisp is the or
Don, that's bullshit, and worse, you know that. Lisp has deeper structure than sexprs. Arbitrary sexprs are not the same as Lisp syntax. The next time you have a macro that accidentally feeds a procedure in the first-arg place instead of a symbol, you can give me some Slashdot karma. Or when you screw up the levels of parens for a cond. Your penance is a RELAX-NG schema for a Lisp-disgustingly-expressed-in-XML system. While I share your amusement at XML conquering the non-Lisp barbarians (by way of hypo
Perl syntax is absolutely awful, and that's the reason Perl will never have macros
According to Synopsis 6 [perl.com], Damian Conway and Allison Randal's summary of Perl 6's "Subroutines and Other Code Objects":
Macros are routines whose calls execute as soon as they are parsed (i.e. at compile-time). Macros may return another source code string or a parse-tree.
Having once upon a time built an application based almost entirely on IBM System/360 Assembler macros, even Perl < 6 syntax is a breeze in comparison.
Is it about "*aweful*" syntax, or awful spelling? Or are you full of awe?
Well as long as you're playing dress-up with your daddy's grammar cop outfit, let me show you how the safety on that gun works. Awful means "filled with awe." God is awful. Awful does not mean bad, and awe does not mean good. "God is awful" means "omg god is scary."
That's why when you say "huhu i hate when people say awful smart" educated people within earshot sigh and shake their heads.
"Doh! Why do we need to learn from the past? Everyone knows that we don't have to study history to avoid repeating the mistakes and building on the successes of the past. God wrote everything we'll ever need to know into the bible. It's a creationist fact!"
Matz (Ruby's creator) acknowledges ripping off ideas from Lisp (but putting a friendlier face to it). Python is Lispy. Javascript has been called Lisp in C's clothing. These are all functional languages, or can be used functionally.
How do you define "functional language"? The key features of functional languages are that they (a) they reduce, or entirely eliminate, side effects, (b) have functions as first-class objects, (c) provide support for function currying, and (d) provide lambda expressions. No
No, it isn't. At least, it isn't pure. Most functional languages (Haskell is a noteable exception) bend this rule, and Lisp is no exception. Re-assignment is just so darned useful.
From Graham's ANSI Common Lisp, Chapter 2:
In all the sections before this, we kept to what is called "pure" Lisp---that is, Lisp without side-effects. A side-effect is some
change to the state of the world that happens as a consequence of evaluating an expression. When we evaluate a pu
I prefer 'functional' languages over the 'dysfunctional' ones.
What I _want_ is a functional language that I can use to generate real-time code for an embedded dsp. What functional languages are options for me? I would think that dsp and functional languages would be a match made in heaven... but I cannot find the path...
I prefer 'functional' languages over the 'dysfunctional' ones.
Now, that's funny.
What I _want_ is a functional language that I can use to generate real-time code for an embedded dsp. What functional languages are options for me?
Doesn't that depend on the DSP chip? I know almost nothing about DSPs, but don't you have to target your chip specifically?
There's an interesting article [embedded.com] that talks about PPL, which might be interesting, but since I'm entirely ignorant about embedded systems in general and e
The DSP's I'm thinking of are the Texas Instruments TMS6701 family, and maybe even altivec code. I'd like to see a functional programming language that has a compiler which generates C code, ideally with customizable pipeline hints. (the assembly language for these dsp's are insane)
Typically DSP algorithms come down to pure math. The hard trick is to make representation of that math in C code that pipelines/optimizes well.
C and C++ really limit the compiler's ability to optimize well for non-Von Neumann arch
What I envision is that I can express my DSP algorithm in the high level lazy evaluation functional language, and then it would get compiled down to C or ASM, taking into account the multiple execution units and software pipelining - basically re-order the math steps so it is most efficient on the specific DSP or Altivec.
That said, you're not the first person I've heard say that all languages are, ultimately, Lisp machines, and there's some merit to that.
Pfft. Same merit there is in looking at them as Turing Machines, Babbage Machines, piles of assembly or a physics project involved in the correspondance of capacitance.
Just because something can be expressed in terms of an X doesn't make it an X. That's why the universe isn't a turing machine, no matter how many times you watch The Matrix - first, you have to find evidenc
There's a lot more to a program than the results it outputs.
On the contrary; for practical purposes, there's nothing more to a program than the results it outputs. This is exactly what makes the examples you gave of daft programs daft: they don't output anything.
No, dear. Let me hold your hand through what I thought was a relatively simple example.
For a 3x3 grid, the travelling salesman problem can be solved quite quickly through brute force; for 4x4, still so but less so. The output from brute force will be correct. However, you don't want to brute force a 500x500 TS problem, even though the output will be correct. Perhaps now you'll understand the bit about there being more to it than output? Time matters.
"Javascript has been called Lisp in C's clothing." So the ways Javascript differs from C are due to being LISP like? I find it hard to imagine a more damning indictment of a language.
"All things being equal, you should generally choose the most powerful language you can all the time"
But all things are not equal. Being able to use that power is important too. Sure, LISP is powerful, in theory. But writing it makes me yearn for the straightforward simplicity of C++!
Clearly you haven't written 'quite a bit of LISP', you just find Lisp advocates annoying. You probably gave it a cursory examination, decided it looked too weird, or too hard to get your brain around, and therefore is no good. But you still have to deal with those occasional annoying Lisp zealots, and the nagging worry they might be right.
I clearly haven't written much LISP? Thanks for letting me know. I must have just imagined it. Too bad, I seem to recall having enjoyed it quite a bit. I didn't mean to imply LISP was "no good"; for talking about programming languages; for examining the concepts other languages take for granted, it's excellent. For a CompSci grad student, LISP is the perfect language. For a comercial software engineer, not so much. C++ (for example) is much more popular than LISP pretty much ever
So the ways Javascript differs from C are due to being LISP like? I find it hard to imagine a more damning indictment of a language.
Then you've never used Intercal, which has the expressiveness of cobol, the readability of k, the write-once-read-many of perl cubed, the speed of logo and the linkage of apple basic. And then there are Ook, befunge, kvakkiutl, and that damn bear-oriented language I can't find anymore.
"Then you've never used Intercal..."
Hold on there! I'll have you know I was once a totally 1337 Intercal coder! (this was before "1337", but anyway...) Though it was rough, I once even sucessfully implemented addition. So there. To this day, I can read large numbers in Roman Numerals faster than most...
In any case, your comparisons significantly overstate Intercals expressiveness, readability, etc. When compared based on their worst features, it is much much worse than any of those langu
The central point of the linked article is, that Lisp is the "highest Language" around - Could somebody comment on this? Sureley there must be a higher, even more experimental language somewhere, no?
Lisp will probably always have this place, just like Godel's Therom will always have it's place in mathamatics, for the fact that they are so fundemental. Lisp is a meta-language, a way of describing algorithims. Metaprogramming is not a fancy trick in Lisp, but how you get it done.
With other languages, a compiler 'parses' your code into an Abstract syntax tree [wikipedia.org], in Lisp, your code is that tree.
Thank you! Glad to see both Paul Graham and Lisp getting credit, here!
And to the other replys: Parenthesis, parenthesis, parenthesis is all I ever hear people complaining about Lisp talk about. Name ONE other flaw of Lisp, please? Now think of any other programming languages with just *one* flaw? I *love* parenthesis, they're (and (round) (look like (they're hugging the code))) . Makes me all warm and fuzzy! Too many sharp corners on {}, [], and <> .
> All things being equal, you should generally choose the most powerful language you can all the time.
Sorry but this sentence is not very usefull as things are *never* being equal: numbers of programmers knowing the language, completeness of the support libraries, memory usage, easiness of interfacing with a 'fast language' (if the powerful language happens to do some parts too slow)..
Also IMHO you're confusing research and usefulness: there are research language which tries to search features independen
Generally by people without the faintest clue what they're talking about. People think that if a language supports lambda, it's a Lisp child; you might as well say all modern programming languages are descendants of algebra. It's nonsense.
Lambda is a tiny fraction of LISP, and frankly it's a silly assertion to claim that languages are becoming LISPish just because some of the features LISP implemented are becoming common in broad-paradigm languages that ever
Generally speaking, it should make the wrong thing hard to do, as well
Except how do you define "the wrong thing"? I dont really like the compiler telling me I cant do something because someone decided "it's the wrong thing".
Best practices and code review should be used ( imho ) to weed out "wrong things".
FP (Score:5, Funny)
funny AND interesting, but yeah FP... (Score:5, Interesting)
See Beating the averages [paulgraham.com] for a well-written and thoughtful essay.
In a nutshell, languages themselves vary in power. No one disputes that. All things being equal, you should generally choose the most powerful language you can all the time. As we move more and more to server-hosted software, your choice of language is incredibly important because a) it's your choice, not forced on your by being the language of the OS and b) it can be a huge competitive advantage.
Matz (Ruby's creator) acknowledges ripping off ideas from Lisp (but putting a friendlier face to it). Python is Lispy. Javascript has been called Lisp in C's clothing. These are all functional languages, or can be used functionally.
Graham noted how all languages are trending more towards Lisp in terms of features (see the essay linked above). Want further proof? C# 2.0 is getting lexical closures. Innovation from Microsoft! These were available in Lisp for 30 years, javascript for 10 (since it was created), they're in Perl 5, Ruby, I can go on...
If languages continue to become higher and higher level, wouldn't we need to investigate this weird AI language from 1958 and see what features it doesn't have in order to do more meaningful research? 'cause these days, all the "new" features of today's languages are decades old...
Re:funny AND interesting, but yeah FP... (Score:5, Funny)
(I'd (stab (my (eyeballs out)) (if I needed)) (to look)(at LISP) all ) day)
))))))))))))))))))))
Obligatory 20 closing paren's that inevitably appear...
Re:funny AND interesting, but yeah FP... (Score:5, Funny)
Re:funny AND interesting, but yeah FP... (Score:4, Interesting)
Of course I'm doing some handwaving here about the writing it correctly part. Until you memorize the major idioms, you'll often experience starting something with a single paren when it really needs to start with two, for example, and you'll get weird behavior that ends up driving you to randomly adding and removing parens until it seems to work. Admittedly that's a bit of a hurdle at first, but after some experience, that part gets easy. (Like glancing at for (int x=0; x10; x++) and reading "do it ten times" without having to think about it. A lot of people forget how much thinking a newbie has to do to parse such an expression the first few times.)
The real problem with Lisp isn't the parens. Once you get over the initial hurdle, you just look at the indentation. The problem is that dev platforms these days are so much more than just a language. The basic concepts underlying a Lispy language are almost timeless. The whole rest of the dev system, though, has a shelf life of about a decade or less, after which time the way it is made available, the libraries, the editors you have to use, the string model, the constraints it's optimized for, the compromises it has made, its interaction with other technologies, etc., are all out of touch with current realities. Such is Lisp today.
(Paul Graham once seemed like the guy who could rejuvenate Lisp, but each year that passes makes that less likely. Speaking of out of touch with current realities.... Even Microsoft's secret projects are more open.)
Re:funny AND interesting, but yeah FP... (Score:3, Funny)
Slashdot won't let me post it, but it was a solid page of ))))'s.
Afraid of parenthesis? Stay away from XML! (Score:4, Funny)
-Don
Re:Afraid of parenthesis? Stay away from XML! (Score:1)
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
-Don
Re:Afraid of parenthesis? Stay away from XML! (Score:5, Informative)
Also, the facts that they're never nested directly next to each other and that they describe themselves helps. With LISP you get stuff like where it's difficult to count the number of parens, and what they close depends solely on their placement. In contrast, something like
<1><2><3><4><5>this</5></4></3></2></1>
would be the equivalent in XML. As you can see, even though there's no whitespace it's still easier to read because each tag describes what its closing and is easier to pick out from its neighbors (for easier counting).Of course, all this ignores the fact that LISP and XML can't be directly compared anyway, since one is a programming language and the other is a data format!
Re:Afraid of parenthesis? Stay away from XML! (Score:1)
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
Re:Afraid of parenthesis? Stay away from XML! (Score:3, Interesting)
Some very sick people [apache.org] disagree...
Re:Afraid of parenthesis? Stay away from XML! (Score:3, Informative)
1) Lisp is a data format, as the previous poster pointed out. Shame on you for missing one of the most important points about Lisp.
2) XML is a data format, which is used for many different programming languages. Shame on you for missing one of the most important points about XML.
Even if you didn't score zero out of two, what is it about XML's angled brackets that make it ok to use twice as many of them, than Lisp's parenthesis? Is it the smooth curves of the Lisp parens t
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
Make a Mistake (Score:2)
One of the coolest parts of the Java tool chain is ant, which uses XML instead of make's ridiculous syntax.
Ant has its limitations because it doesn't provide an actual scripting language. That's one of the problems that Jelly is attempting to address.
Another approach to programming with XML that works well is embedding a
Re:Afraid of parenthesis? Stay away from XML! (Score:5, Interesting)
)
Now tell me what it means. Specifically, tell me what expression it ends.In contrast, take this XML example:
</p>
Now tell me what expression it ends. See how much easier it is?See, that's the difference: In XML, the angle brackets aren't units really units of syntax in and of themselves; tags as a whole are. Moreover, in XML these units of syntax are self-discribing. Also, angle brackets are never nested; they always occur in "" pairs without any more brackets between them.
Re:Afraid of parenthesis? Stay away from XML! (Score:1)
Please show me how you can express an 5-deep nested array in any other language
Please show me why you would ever, ever want to do such a horrible thing.
Re:Afraid of parenthesis? Stay away from XML! (Score:2, Insightful)
<tag2>
some data
</tag1>
</tag2> ; OOPS
(tag1 (tag2 some data))
I'll take the second one thanks. My editor can show me which closing paren corresponds to which opening one.
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
Re:Afraid of parenthesis? Stay away from XML! (Score:1)
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
Simple: A list.
I don't know. If it is XHTML, it probably ends a paragraph (but, of which class?)
No.
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
Back in the real world, the answer to your question is simple.
Now tell me what it means. Specifically, tell me wh
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
Another point: Your "(((((this)))))" example is a straw man argument. Lisp programs use white space and indentation to make the structure clear, just like any other programming language.
The phrase you're probably looking for is "red herring," though in fact it's also not a red herring. A straw man ar
Re:Afraid of parenthesis? Stay away from XML! (Score:2, Insightful)
<1><2><3><4><5>this</5></4></3></2></1>
is easier than reading:
(((((this)))))
??
I'd rather read the lisp, there's just one thing to read: 'this' whereas the xml has all those numbers, and they have to match, and they have to be in order, what matters 'this' is now buried and do not stand out whatsoever; what the?
Sure, I don't want to count parenthesis, that
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
The XML page cannot be displayed
Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later.
A name was started with an invalid character. Error processing resource 'file:///C:/temp/moronic.xml' <1><2><3><4><5>this</5></4></3></2></1>
-^
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
In the Real World, those numbers wouldn't be numbers, so the XML example would represent much more information than the LISP example. If we compared examples that contained equal amounts of information, the XML would be more obviously better. The LIS
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
They "represent" the same amount of information. Requiring you to repeat the same information twice is not the same as representing more information.
Each level of nesting in XML requires you to use a tag name, even if it's not necessary to represent the information required (a 5-deep array of a single string, in this example). So XML requires you to insert extra useless information, and then repeat it. It results i
Re:Afraid of parenthesis? Stay away from XML! (Score:1)
In most cases, XML is used to markup data to make it more meaningful to the computer. A tag indicates some property or identifier on data. An extension of this idea makes it useful. RDF comes to mind.
I personally like to use xml heavily for data storage when writing w
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
XML is much harder to read and more verbose than Lisp. That's discussed here: XML Is a Poor Copy Of Lisp S-Expressions [c2.com].
A schema is like a stigma: when you have more than one of them, they're called stigmata (schemata).
Could you possibly think of a worse example of a hard-to-read XML application than RDF??!
XML is like electricity: it's a great way to transmit information (power), but a
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
-Don
Re:Afraid of parenthesis? Stay away from XML! (Score:1)
Try again, grasshopper. In lisp, the program is the data is the program. There is no distinction. XML is simply s-expressions without the ability to execute them.
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
XML documents can be represented as S-Expressions, makeing XML a poorly implemented Lisp, a la Greespun.
</lispFanatic>
I agree that the parens are nasty. Still, I belive FP is the way to go.
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
Also, the facts that they're never nested directly next to each other and that they describe themselves helps. With LISP you get stuff like (((((this)))))
Erm, no you don't. You might conceivably have a data structure with that level of vacuous nesting (just as you might have in any other language, where it wouldn't be any more readable than in Lisp), but actual Lisp code would never look like that.
I prefer Haskell to Lisp mself, but it's sad to see ignorant criticisms inevitably modified insight
Re:Afraid of parenthesis? Stay away from XML! (Score:1)
I wish I could moderate you both funny and insightful.
Re:Afraid of parenthesis? Stay away from XML! (Score:1)
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
Re:Afraid of parenthesis? Stay away from XML! (Score:2)
XML is actually rather easy to learn (that is, the XML specification, never mention the additional techniques around it). There are excelent editors (that display the XML in trees) just for you. Not so with Lisp, displaying Lisp in a tree would do little to nothing for readability.
Anyway, XML uses </tag> to show the end of a tag, while lisp uses ). I know which one I pref
Re:Afraid of parenthesis? Stay away from XML! (Score:1)
Re:funny AND interesting, but yeah FP... (Score:3, Funny)
Re:funny AND interesting, but yeah FP... (Score:4, Insightful)
In practice it has a very clean and elegant syntax though. If your editor doesn't do bracket matching you might have a few issues, but then what sort of half assed editor are you using?
Besides you can always try ML or Haskell which are much more pure functional than LISP and have hardly any parentheses (which I actually find occasionally irritating).
Jedidiah.
Re:funny AND interesting, but yeah FP... (Score:3, Informative)
Rich.
What language doesn't require balanced parens? (Score:2)
(Of course Forth lets you define words with any punctuation, even unbalanced parens, like "<BUILDS" and "DOES>", but the punctuation doesn't mean anything other than being a character in a token.)
-Don
Perl has a crappy syntax and people use it. (Score:2)
-Don
Re:Perl has a crappy syntax and people use it. (Score:2)
I am a Perl lover and the only lanuage I'd really prefer is Lisp. (Nice macroassemblers like C takes place three in my top list.)
The reasons are very different.
Perl breaks every "rule" for programming languages but still work; a hilarious combination of ugly, neat and power. Wall was into linguistics. Perl is like my beloved second language, English; funny and rich.
Besides, Lisp's parentheses aren't crappy
LISP sounds like Tarzan's speech (Score:1, Informative)
The problem wasn't just the parenthsis. Actually, a LISP program for your sentence would be (more confusingly):
(if (needed I (to-look (at LISP) (day all)))
(would-stab I (eyeballs my) out))
That doesn't quite roll off the tongue so easily...
Me T
Re:LISP sounds like Tarzan's speech (Score:1)
Re:funny AND interesting, but yeah FP... (Score:1)
Have you programmed in Lisp? I haven't used it much, but when I did it seemed elegant and natural. It's kind of like the difference between infix and postfix notation:
vs.
It might take a little practice to get used to postfix notation, but there are clear advantages to it. The reason I don't generally use Lisp isn't its syntax, but rather that I couldn't find sufficient libraries for it.
Re:funny AND interesting, but yeah FP... (Score:2)
(+ (* 4 3) 2)
At least one of the serious problems I have with the whole prefix notation is that it tends to place the operator (in this case '+') pretty far from one of the items being worked on (in this case the '2'). This is a simple example and thus not *too* difficult. But some of the more complicated things I'd written exposed that flaw quite clearly.
Re:funny AND interesting, but yeah Smalltalk. (Score:3, Insightful)
This is not about similarity. This is about an *aweful* syntax. Just plain bad IMHO.
Re:funny AND interesting, but yeah Smalltalk. (Score:3, Insightful)
What's wrong with parenthesis? If you hate parenthesis, then do you hate XML twice as much as Lisp?
Lisp syntax is excellent because it's simple and consistent, and that's the reason Lisp macros are so powerful. Perl syntax is absolutely awful, and that's the reason Perl will never have macros like Lisp.
-Don
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
What's wrong with parenthesis? If you hate parenthesis...
What's wrong with it is that you spelled parentheses wrong. One parenthesis, multiple parentheses. But at least you're consistent in your misspellings.
Re:funny AND interesting, but yeah Smalltalk. (Score:1)
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
-Don
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
And yes, FWIW I hate XML as well. Did I make any indication that I felt otherwise about XML? Did I even mention XML? Why do you care so much about XML?
I also don't recall saying that I hated parenthesis. I've got nothing against them per se. I dislike LISP and Scheme and the like because of their syntax. If you didn't like "C" because of its syntax, I wouldn't assume you dislike curly-braces.
The only thing that actually makes XML slightly better
Think of XML as Lisp for COBOL programmers -Tony-A (Score:2)
I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.
There's an interesting discussion of Lisp -vs- XML [c2.com]. Some people think
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
The only thing that actually makes XML slightly better to deal with is that it's a document format, not a programming language.
Erm, XML and S-expressions are both data formats. It so happens that S-expressions are used to express programs in a number of programming languages in the Lisp family, but this doesn't stop them being a data format. You're very confused.
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
So do you agree that you should reject XML for the same reason you reject Lisp: too many parentheses? Or do you claim that it's easier to read twice as many XML angled brackets with repeated tag names, than Lisp parenthesis? If so, then why's that?
-Don
macro systems (Score:2)
More properly, Lisp macros operate on the program structure itself. Macros for languages like C and C++ operate on text. I believe this is the why most programmers don't immediately comprehend why Lisp macros are so much more powerful and useful. They are used to macro systems which are useful for for putting CONSTANT_VALUE instead of a hard-coded number in the program text, but quickly become a bear to use when it is time to do something more sophisticated.
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
Unless of course you are using super-dooper edition..
Arguing in favor of both LISP _and_ XML? Jesus man, get a hold of yourself! cold water in face!
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
- Lisp is a programming language
- XML is a data description language
If you haven't learned by then, follow up by writing one hundred times:
- Lisp is created mostly by humans
- XML is created mostly by computers
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
Lisp is a programming language and also a data description language. Lisp programs are exactly the same stuff as lisp data, so Lisp macros operate directly on lisp programs as well as any kind of Lisp data (S-Expressions), which makes them extremely powerful, in ways that C-preprocessor-like text substitution based macros and type system based C++ templates simply can't approach. Lisp is the or
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
While I share your amusement at XML conquering the non-Lisp barbarians (by way of hypo
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
- C is a programming language
- Lisp is a data description language
- XML is crippled Lisp with no semantics.
Perl 6 macros (Score:2)
According to Synopsis 6 [perl.com], Damian Conway and Allison Randal's summary of Perl 6's "Subroutines and Other Code Objects":
Having once upon a time built an application based almost entirely on IBM System/360 Assembler macros, even Perl < 6 syntax is a breeze in comparison.
Desp
Re:funny AND interesting, but yeah Smalltalk. (Score:2)
Well as long as you're playing dress-up with your daddy's grammar cop outfit, let me show you how the safety on that gun works. Awful means "filled with awe." God is awful. Awful does not mean bad, and awe does not mean good. "God is awful" means "omg god is scary."
That's why when you say "huhu i hate when people say awful smart" educated people within earshot sigh and shake their heads.
Lisp syntax is excellent because it's simple
Re:funny AND interesting, but yeah FP... (Score:5, Funny)
"Doh! Why do we need all these _new_ languages? Everyone knows programming languages were perfected in 1958. It's a scientific fact!"
Re:funny AND interesting, but yeah FP... (Score:2)
-Don
Re:funny AND interesting, but yeah FP... (Score:2)
Re:funny AND interesting, but yeah FP... (Score:2)
Yeah, we should build on the sucesses of the past, like LISP! You know it's a success, because it still has just as many users as it did in 1958!
Re:funny AND interesting, but yeah FP... (Score:2)
Jerk.
Shameless promotion (Score:2)
Rich.
Re:funny AND interesting, but yeah FP... (Score:3, Insightful)
How do you define "functional language"? The key features of functional languages are that they (a) they reduce, or entirely eliminate, side effects, (b) have functions as first-class objects, (c) provide support for function currying, and (d) provide lambda expressions. No
Re:funny AND interesting, but yeah FP... (Score:2)
Then LISP is not functional either:
Re:funny AND interesting, but yeah FP... (Score:2)
No, it isn't. At least, it isn't pure. Most functional languages (Haskell is a noteable exception) bend this rule, and Lisp is no exception. Re-assignment is just so darned useful.
From Graham's ANSI Common Lisp, Chapter 2:
I wish I had mod points (Score:2)
That line really got to me too. I was going to reply but then you already said everything much better than I could. Excellent.
Re:funny AND interesting, but yeah FP... (Score:2)
What I _want_ is a functional language that I can use to generate real-time code for an embedded dsp. What functional languages are options for me? I would think that dsp and functional languages would be a match made in heaven... but I cannot find the path...
--jeff++
Re:funny AND interesting, but yeah FP... (Score:2)
Now, that's funny.
Doesn't that depend on the DSP chip? I know almost nothing about DSPs, but don't you have to target your chip specifically?
There's an interesting article [embedded.com] that talks about PPL, which might be interesting, but since I'm entirely ignorant about embedded systems in general and e
Re:funny AND interesting, but yeah FP... (Score:2)
I'd like to see a functional programming language that has a compiler which generates C code, ideally with customizable pipeline hints. (the assembly language for these dsp's are insane)
Typically DSP algorithms come down to pure math. The hard trick is to make representation of that math in C code that pipelines/optimizes well.
C and C++ really limit the compiler's ability to optimize well for non-Von Neumann arch
Re:funny AND interesting, but yeah FP... (Score:2)
Re:funny AND interesting, but yeah FP... (Score:2)
What I envision is that I can express my DSP algorithm in the high level lazy evaluation functional language, and then it would get compiled down to C or ASM, taking into account the multiple execution units and software pipelining - basically re-order the math steps so it is most efficient on the specific DSP or Altivec.
--jeff++
Re:funny AND interesting, but yeah FP... (Score:2)
Pfft. Same merit there is in looking at them as Turing Machines, Babbage Machines, piles of assembly or a physics project involved in the correspondance of capacitance.
Just because something can be expressed in terms of an X doesn't make it an X. That's why the universe isn't a turing machine, no matter how many times you watch The Matrix - first, you have to find evidenc
Re:funny AND interesting, but yeah FP... (Score:2)
On the contrary; for practical purposes, there's nothing more to a program than the results it outputs. This is exactly what makes the examples you gave of daft programs daft: they don't output anything.
Re:funny AND interesting, but yeah FP... (Score:2)
For a 3x3 grid, the travelling salesman problem can be solved quite quickly through brute force; for 4x4, still so but less so. The output from brute force will be correct. However, you don't want to brute force a 500x500 TS problem, even though the output will be correct. Perhaps now you'll understand the bit about there being more to it than output? Time matters.
Re:funny AND interesting, but yeah FP... (Score:3, Insightful)
So the ways Javascript differs from C are due to being LISP like? I find it hard to imagine a more damning indictment of a language.
"All things being equal, you should generally choose the most powerful language you can all the time"
But all things are not equal. Being able to use that power is important too. Sure, LISP is powerful, in theory. But writing it makes me yearn for the straightforward simplicity of C++!
LISP fanatics bug me. If everyone just a
Re:funny AND interesting, but yeah FP... (Score:1)
Re:funny AND interesting, but yeah FP... (Score:2)
I clearly haven't written much LISP? Thanks for letting me know. I must have just imagined it. Too bad, I seem to recall having enjoyed it quite a bit. I didn't mean to imply LISP was "no good"; for talking about programming languages; for examining the concepts other languages take for granted, it's excellent. For a CompSci grad student, LISP is the perfect language. For a comercial software engineer, not so much.
C++ (for example) is much more popular than LISP pretty much ever
Re:funny AND interesting, but yeah FP... (Score:2)
Then you've never used Intercal, which has the expressiveness of cobol, the readability of k, the write-once-read-many of perl cubed, the speed of logo and the linkage of apple basic. And then there are Ook, befunge, kvakkiutl, and that damn bear-oriented language I can't find anymore.
Re:funny AND interesting, but yeah FP... (Score:2)
Hold on there! I'll have you know I was once a totally 1337 Intercal coder! (this was before "1337", but anyway...) Though it was rough, I once even sucessfully implemented addition. So there. To this day, I can read large numbers in Roman Numerals faster than most...
In any case, your comparisons significantly overstate Intercals expressiveness, readability, etc. When compared based on their worst features, it is much much worse than any of those langu
Lisp is the "highest language"? (Score:1)
Re:Lisp is the "highest language"? (Score:3, Insightful)
With other languages, a compiler 'parses' your code into an Abstract syntax tree [wikipedia.org], in Lisp, your code is that tree.
Re:Lisp is the "highest language"? (Score:2)
Even better. I think it was Rudy Rucker who once wrote a book about Godel's Theorem and proved that it was Godel who really invented Lisp.
Re:funny AND interesting, but yeah FP... (Score:1)
And to the other replys: Parenthesis, parenthesis, parenthesis is all I ever hear people complaining about Lisp talk about. Name ONE other flaw of Lisp, please? Now think of any other programming languages with just *one* flaw? I *love* parenthesis, they're (and (round) (look like (they're hugging the code))) . Makes me all warm and fuzzy! Too many sharp corners on {}, [], and <> .
Re:funny AND interesting, but yeah FP... (Score:2)
Sorry but this sentence is not very usefull as things are *never* being equal: numbers of programmers knowing the language, completeness of the support libraries, memory usage, easiness of interfacing with a 'fast language' (if the powerful language happens to do some parts too slow)..
Also IMHO you're confusing research and usefulness: there are research language which tries to search features independen
Re:funny AND interesting, but yeah FP... (Score:2)
Generally by people without the faintest clue what they're talking about. People think that if a language supports lambda, it's a Lisp child; you might as well say all modern programming languages are descendants of algebra. It's nonsense.
Lambda is a tiny fraction of LISP, and frankly it's a silly assertion to claim that languages are becoming LISPish just because some of the features LISP implemented are becoming common in broad-paradigm languages that ever
Re:funny AND interesting, but yeah FP... (Score:2)
Except how do you define "the wrong thing"? I dont really like the compiler telling me I cant do something because someone decided "it's the wrong thing".
Best practices and code review should be used ( imho ) to weed out "wrong things".