The whole point of macro is readability! Reading Lisp code with a well-chosen set of macros is like reading code written in a language precisely-designed for the problem you're trying to solve. It keeps the boiler-plate and the implementation details from interfering with the expression of the core algorithms.
It's not false. I'm a relative Lisp newbie and it doesn't confuse me. You just need to learn how to use the editor properly. As for the ML type languages, they don't have parens, but they also don't have macros, which is what the parens enable. Compare a kludge like caml4p to Lisp's macros.
Yeah right. Dylan tried that, look where it got them. People just use parentheses as an excuse to not try a language they're too chicken to try anyway.
Um, what? Visual Basic 1.0 dates from 1991. ANSI Common Lisp had already come out by then! Lisp had GC since the 1960s. It might not have been a "major language" by the time VB1 came out, but it was certainly a major language at the time.
Lisp is generally as OO as Smalltalk, and CLOS is anything but pseudo-OO (and far from the monstrosity that is Perl). All Lisp objects are CLOS objects, and you can specialize CLOS methods on any Lisp type.
1) A Lisp machine isn't a VM. It's a computer with a native-code Lisp compiler and an OS and development environment written in Lisp.
2) Lisp was designed by an AI professor at Stanford, John McCarthy.
3) The early Lisp's were anything but portable, usually written in PDP or IBM assembly. Most modern Lisp's aren't terribly portable either. The major current Lisp compilers generate native code. Indeed, the only major non-compiled Lisps are Emacs Lisp and Clisp.
So you're saying that the problem isn't too many parentheses, but that the parentheses are hard to distinguish? First, that's an awfully subjective argument. I find { and } and ; to be much harder on the eyes than ( and ). They stand out too much compared the actual code. Which leads to my second point: the parentheses aren't supposed to be easy to distinguish. You're not supposed to pay attention to them. It's a skill, but no more so, for example, than learning to not voice the words in your head when reading. The editor is supposed to take care of the parentheses. For example, say I have:
What's the proper termination for that fragment? It's '))))))'. How many parentheses is that? What closes what? Who cares! No Lisp programmer actually looks and counts to see if they have 6 parentheses. A Lisp programmer simply tapes SHIFT-0 until the paren to the left of the 'defun' lights up. What happens when he needs to insert something after the "when" clause? Does he look through the '))))))' at the end and try to figure out where to insert the cursor? No! He uses an editor hotkey to place the cursor for him. It takes a bit of practice to get the hang of it, but there is a benefit. Since the parens demark the bounderies of each fragment, the editor is fully capable of moving the cursor around the AST. One of the benefits is that Lisp programmers don't have to use the arrow keys to move between expressions. They simply use the hotkeys for "next sibling expression" or "parent expression". Say I'm deep in a nested IF statement, and want to edit the predicate. In C, I'd arrow up and over until I get to the predicate clause. in Lisp, I'd tap the "parent expression" a couple of times, then "next child" once. Since the editor highlights what is currently selected, this process can be extremely efficient, since it basically becomes a hand-eye exercise.
Hmm. The Macsyma code dates from around the same period (and was also developed at MIT), and it (well, Maxima, the continuation of the codebase), is still one of the best free computer algebra systems out there. I use it every day, and I don't miss Mathematica at all.
Here here! I find it incredible to see that C/Java people bitch about "superflous" punctuation. Compare this:
(defun square (x) (* x x)) ; 6 punctuation marks
To C:
double square(double x) {return x * x;} // 5 punctuation marks
To C++:
template <typename T> T square(T x) {return x * x;} // 7 punctuation marks
To Java:
public class Square { public double operate(double x) {return x * x;} }; // 7 punctuation marks
Compare this:
(if (something) ; 8 punctuation marks (do-this) (do-that))
To C/C++/Java:
if(something()) // 10 punctuation marks (11 if you count the 'else') do_this(); else do_that();
Compare this:
(do-something to-this with-that in-there) ; 2 punctuation marks
To C/C++/Java:
do_something(to-this, with-that, in-there) // 4 punctuation marks
The only reason it seems like there are so many parentheses in Lisp is because of LET and because Lisp uses just a single type of punctuation while C/C++/Java use all sorts of different punctuation. With a good editor, the parentheses don't even matter, all you see is the indented structure!
A surprising number of people, actually. Of the 230 million LOC in Debian, 3% (or 7 million) are written in Lisp. This puts it fourth, right after C, C++, and shell, and ahead of Perl, Python, Java, etc. With then number of people who hang out on comp.lang.lisp, you'd never know it was dead:)
I don't know about you, but I don't particularly want either my doctors or my engineers to be "revolutionary" thinkers. It's safer that way. The problem with revolutionary thinking is that it often takes many failed attempts before a success. The problem with failed attempts in medicine (and engineering, to a degree), is that they usually end up killing people. I'm reminded of Dilbert's "risk-reward" for engineers: if you succeed, you get a nice plaque and congratulations at a professional conference. If you fail, innocent people die.
LOL. I'm reminded of a comedian (Carlin maybe?) who talked about this very subject. He said, "I don't care what you do to my body after I'm dead; I *can't* care, because I'm dead!"
To be fair, there is nothing particularly Christian about your quote. The statements are as much Muslim or Jewish as they are Christian! It is not a belief in God that defines Christianity, any more than it is a belief in science that defines Biology.
You know, that's a very interesting thing for me. How in god's name did Sun manage to make Swing apps so bloody slow? Compare something like NetBeans and OpenDylan. The former is written in Java, a relatively simple, statically-typed language with a large team working on the compiler. The latter is written in Dylan, a very powerful, dynamically typed language, with a small development team working on the compiler. Yet, the Open Dylan IDE feels exactly like a native MFC app, while NetBeans is glacial. How did Sun pull that off?
Professors are doing an enormous disservice to the Lisp community by teaching Scheme in undergrad CS. It just creates legions of CS people who instinctively associate Lisp with all the pain of learning the fundamentals of computer science. Not only that, but they expose them to the language at a time when they haven't done enough real programming to be able to form a decent opinion of what is useful and what is not useful. I don't find it at all surprising that most Lisp programmers you meet came to it after years of doing C/C++/Java work, not after seeing it for the first time in college and loving it ever since!
Ah, I see. You're right that we're talking about two different pictures. I guess I wasn't thinking about the particles at all, as the AE in me considers air to be a continuous fluid:)
Actually, I never read it in my high-school textbooks. As far as I can tell, its a very simplified, but not wholly inaccurate version of the theory taught in low-speed aerodynamics courses. In incompressible theory (which is a low-speed theory), the two streamlines do meet at the trailing edge, and must have the same velocity at that point. This constraint (the Kutta condition), is a basic element of the theory of incompressible airflow over an airfoil. Also, the tip vortices aren't an effect of a turbulent layer right behind the TE, but a finite wing effect. They do not exist on infinite wings. With regards to verticity being conserved, its more precise to say that circulation is conserved, but you're basically right. However, its interesting to point out that its the conservation of circulation that enables the Kutta condition to exist in the first place. When the flow over an airfoil first starts, a large vortex is created at the trailing edge (to conserve the total circulation). This vortex induces circulation around the wing. Eventually, this vortex stops grown in strength when the induced circulation is just enough to ensure that the streamlines on the top and bottom of the wing meet in a way that preserves the Kutta condition.
I don't know what you're really getting at. The popular explanation isn't so much wrong as its very simplified. At low speeds, where you can approximate the flow as an incompressible one, its a fairly decent explanation of what happens.
I'd really love to see how the laws of thermodynamics say that 28mpg is necessarily a lie. Seriously, what law does this violate? Zeroth, first, or second?
Slight correction. Nothing requires them to ever meet again, but that's not what the popular explanation says. It says that the two streamlines must have the same velocity when they meat at the trailing edge. In the context of incompressible flow (Bernoulli's theory), this is true, because otherwise you'd have a contradiction wherein the same point (the TE) has two values of pressure.
IAAE (I Am an Aerospace Engineer). I find the Wikipedia article is a bit strange. You can use Bernoulli's theory of incompressible flow to come up with why airfoils develop lift. Unlike what the article claims, it does not fail to explain why symmetric airfoils generate lift. If you work out the mathematics, you can see that its caused by the angle-of-attack. Indeed, one of the first things you learn in an aerodynamics course is how a symmetric flat plate can develop lift based on its angle of attack. The "top must move faster to catch up with the bottom" explanation is simplified, but its not wholly inaccurate. In incompressible flow, the pressure is a function of the velocity at a point on the airfoil compared to the freestream velocity. The top of the airfoil has a higher velocity, and therefore lower pressure. It's also not inaccurate to say that the velocities at the trailing-edge must be equal. In incompressible flow, since the pressure is proprotional to the velocity, the pressure at the trailing edge can only have one value, the velocities on the top and bottom must converge to the same value as the flow approaches the trailing edge. In aerodynamics, this is called the Kutta condition.
That's an utterly retarded statement. If the terrorists wanted, they could build their own planes. It's not that damn hard. You can build the damn things in your garage! By themselves, they don't have enough mass to do jack shit to a building (even a car-sized one), so you'd have to load them up with C4. Then, you'd have a weapons delivery platform about as attractive, as, well, getting some guy to strap-on some C4 and run into the damn building! Hell, for the price of one of these sky cars, you can get a couple of dozen guys to do it. That becomes a far more attractive delivery platform than the sky car, because now you don't have a single point of failure.
That's nonsense. Flying can be a rather efficient way of getting around. Aerodynamics kinda kick you in the ass for high-speed flight, but for low-speed flight its actually kind of friendly. There are high-lift devices being developed that can give aircraft an L/D of 45 or so. That means with a 100 lb thrust miniature jet engine, you can lift a 4500 lb car-sized vehicle. The trick is getting that 100 lb of thrust efficiently. The most efficient jet engines in the world have an sfc at sea-level of 0.3. For a 100 lb thrust engine, that's about 30 lb of fuel per hour. If you get such a plane to a cruise speed of 300 mph (entirely possible with today's technology), then you're talking about 70 mpg, more efficient than most cars.
The trick is figuring out propulsion. Today's small jet engines are several times less efficient than the 70,000lb behemoths that achieve 0.3 sfc. That's not inherent to the technology, however. It's more of an engineering problem, trying to miniaturize the high-pressure high-temperature technologies enough to fit in a jet engine targetted for 100lb of thurst.
That's a completely asnine statement. By your logic, CATIA or SoftImage are failures. You not only need a manual for those, most people even take classes on them and spend years learning their ins-and-outs! That's a silly statement, of course, CATIA and SoftImage are widely regarded as category-leading pieces of software. A programmer doesn't just "type and save text" with a text editor. That's like saying an engineer "draws lines" with CATIA, or an artist "colors pixels" with SoftImage. It's superficially true, but completely misleading. In reality, all three professions use these programs to create very complex works. For them, a few months spent learning the software is nothing compared to years of daily use of the software. If a steep learning curve is the price of software that makes the programmer/artist/engineer more productive during those years of daily use, well, that's quite a good deal indeed.
Slashdot Mirror
The whole point of macro is readability! Reading Lisp code with a well-chosen set of macros is like reading code written in a language precisely-designed for the problem you're trying to solve. It keeps the boiler-plate and the implementation details from interfering with the expression of the core algorithms.
It's not false. I'm a relative Lisp newbie and it doesn't confuse me. You just need to learn how to use the editor properly. As for the ML type languages, they don't have parens, but they also don't have macros, which is what the parens enable. Compare a kludge like caml4p to Lisp's macros.
Yeah right. Dylan tried that, look where it got them. People just use parentheses as an excuse to not try a language they're too chicken to try anyway.
Um, what? Visual Basic 1.0 dates from 1991. ANSI Common Lisp had already come out by then! Lisp had GC since the 1960s. It might not have been a "major language" by the time VB1 came out, but it was certainly a major language at the time.
Lisp is generally as OO as Smalltalk, and CLOS is anything but pseudo-OO (and far from the monstrosity that is Perl). All Lisp objects are CLOS objects, and you can specialize CLOS methods on any Lisp type.
Egads.
1) A Lisp machine isn't a VM. It's a computer with a native-code Lisp compiler and an OS and development environment written in Lisp.
2) Lisp was designed by an AI professor at Stanford, John McCarthy.
3) The early Lisp's were anything but portable, usually written in PDP or IBM assembly. Most modern Lisp's aren't terribly portable either. The major current Lisp compilers generate native code. Indeed, the only major non-compiled Lisps are Emacs Lisp and Clisp.
LOL. I'm too dumb to remap keys in X :-/ Also, I need a keyboard with #' and ,@ keys :)
So you're saying that the problem isn't too many parentheses, but that the parentheses are hard to distinguish? First, that's an awfully subjective argument. I find { and } and ; to be much harder on the eyes than ( and ). They stand out too much compared the actual code. Which leads to my second point: the parentheses aren't supposed to be easy to distinguish. You're not supposed to pay attention to them. It's a skill, but no more so, for example, than learning to not voice the words in your head when reading. The editor is supposed to take care of the parentheses. For example, say I have:
(defun wumpus (x)
(let ((foo 1)
(bar 2)
(baz 3))
(when (+ foo bar baz)
(let ((temp (do-something foo bar baz)))
(when (> temp 0)
(do-something-else temp...
What's the proper termination for that fragment? It's '))))))'. How many parentheses is that? What closes what? Who cares! No Lisp programmer actually looks and counts to see if they have 6 parentheses. A Lisp programmer simply tapes SHIFT-0 until the paren to the left of the 'defun' lights up. What happens when he needs to insert something after the "when" clause? Does he look through the '))))))' at the end and try to figure out where to insert the cursor? No! He uses an editor hotkey to place the cursor for him. It takes a bit of practice to get the hang of it, but there is a benefit. Since the parens demark the bounderies of each fragment, the editor is fully capable of moving the cursor around the AST. One of the benefits is that Lisp programmers don't have to use the arrow keys to move between expressions. They simply use the hotkeys for "next sibling expression" or "parent expression". Say I'm deep in a nested IF statement, and want to edit the predicate. In C, I'd arrow up and over until I get to the predicate clause. in Lisp, I'd tap the "parent expression" a couple of times, then "next child" once. Since the editor highlights what is currently selected, this process can be extremely efficient, since it basically becomes a hand-eye exercise.
The problem with the Python mechanism is that it makes macros quite a bit trickier to implement.
Hmm. The Macsyma code dates from around the same period (and was also developed at MIT), and it (well, Maxima, the continuation of the codebase), is still one of the best free computer algebra systems out there. I use it every day, and I don't miss Mathematica at all.
Here here! I find it incredible to see that C/Java people bitch about "superflous" punctuation. Compare this:
// 5 punctuation marks
// 7 punctuation marks
// 7 punctuation marks
// 10 punctuation marks (11 if you count the 'else')
// 4 punctuation marks
(defun square (x) (* x x)) ; 6 punctuation marks
To C:
double square(double x) {return x * x;}
To C++:
template <typename T>
T square(T x) {return x * x;}
To Java:
public class Square
{
public double operate(double x) {return x * x;}
};
Compare this:
(if (something) ; 8 punctuation marks
(do-this)
(do-that))
To C/C++/Java:
if(something())
do_this();
else
do_that();
Compare this:
(do-something to-this with-that in-there) ; 2 punctuation marks
To C/C++/Java:
do_something(to-this, with-that, in-there)
The only reason it seems like there are so many parentheses in Lisp is because of LET and because Lisp uses just a single type of punctuation while C/C++/Java use all sorts of different punctuation. With a good editor, the parentheses don't even matter, all you see is the indented structure!
A surprising number of people, actually. Of the 230 million LOC in Debian, 3% (or 7 million) are written in Lisp. This puts it fourth, right after C, C++, and shell, and ahead of Perl, Python, Java, etc. With then number of people who hang out on comp.lang.lisp, you'd never know it was dead :)
I don't know about you, but I don't particularly want either my doctors or my engineers to be "revolutionary" thinkers. It's safer that way. The problem with revolutionary thinking is that it often takes many failed attempts before a success. The problem with failed attempts in medicine (and engineering, to a degree), is that they usually end up killing people. I'm reminded of Dilbert's "risk-reward" for engineers: if you succeed, you get a nice plaque and congratulations at a professional conference. If you fail, innocent people die.
LOL. I'm reminded of a comedian (Carlin maybe?) who talked about this very subject. He said, "I don't care what you do to my body after I'm dead; I *can't* care, because I'm dead!"
To be fair, there is nothing particularly Christian about your quote. The statements are as much Muslim or Jewish as they are Christian! It is not a belief in God that defines Christianity, any more than it is a belief in science that defines Biology.
You know, that's a very interesting thing for me. How in god's name did Sun manage to make Swing apps so bloody slow? Compare something like NetBeans and OpenDylan. The former is written in Java, a relatively simple, statically-typed language with a large team working on the compiler. The latter is written in Dylan, a very powerful, dynamically typed language, with a small development team working on the compiler. Yet, the Open Dylan IDE feels exactly like a native MFC app, while NetBeans is glacial. How did Sun pull that off?
Professors are doing an enormous disservice to the Lisp community by teaching Scheme in undergrad CS. It just creates legions of CS people who instinctively associate Lisp with all the pain of learning the fundamentals of computer science. Not only that, but they expose them to the language at a time when they haven't done enough real programming to be able to form a decent opinion of what is useful and what is not useful. I don't find it at all surprising that most Lisp programmers you meet came to it after years of doing C/C++/Java work, not after seeing it for the first time in college and loving it ever since!
Ah, I see. You're right that we're talking about two different pictures. I guess I wasn't thinking about the particles at all, as the AE in me considers air to be a continuous fluid :)
Actually, I never read it in my high-school textbooks. As far as I can tell, its a very simplified, but not wholly inaccurate version of the theory taught in low-speed aerodynamics courses. In incompressible theory (which is a low-speed theory), the two streamlines do meet at the trailing edge, and must have the same velocity at that point. This constraint (the Kutta condition), is a basic element of the theory of incompressible airflow over an airfoil. Also, the tip vortices aren't an effect of a turbulent layer right behind the TE, but a finite wing effect. They do not exist on infinite wings. With regards to verticity being conserved, its more precise to say that circulation is conserved, but you're basically right. However, its interesting to point out that its the conservation of circulation that enables the Kutta condition to exist in the first place. When the flow over an airfoil first starts, a large vortex is created at the trailing edge (to conserve the total circulation). This vortex induces circulation around the wing. Eventually, this vortex stops grown in strength when the induced circulation is just enough to ensure that the streamlines on the top and bottom of the wing meet in a way that preserves the Kutta condition.
I don't know what you're really getting at. The popular explanation isn't so much wrong as its very simplified. At low speeds, where you can approximate the flow as an incompressible one, its a fairly decent explanation of what happens.
I'd really love to see how the laws of thermodynamics say that 28mpg is necessarily a lie. Seriously, what law does this violate? Zeroth, first, or second?
Slight correction. Nothing requires them to ever meet again, but that's not what the popular explanation says. It says that the two streamlines must have the same velocity when they meat at the trailing edge. In the context of incompressible flow (Bernoulli's theory), this is true, because otherwise you'd have a contradiction wherein the same point (the TE) has two values of pressure.
IAAE (I Am an Aerospace Engineer). I find the Wikipedia article is a bit strange. You can use Bernoulli's theory of incompressible flow to come up with why airfoils develop lift. Unlike what the article claims, it does not fail to explain why symmetric airfoils generate lift. If you work out the mathematics, you can see that its caused by the angle-of-attack. Indeed, one of the first things you learn in an aerodynamics course is how a symmetric flat plate can develop lift based on its angle of attack. The "top must move faster to catch up with the bottom" explanation is simplified, but its not wholly inaccurate. In incompressible flow, the pressure is a function of the velocity at a point on the airfoil compared to the freestream velocity. The top of the airfoil has a higher velocity, and therefore lower pressure. It's also not inaccurate to say that the velocities at the trailing-edge must be equal. In incompressible flow, since the pressure is proprotional to the velocity, the pressure at the trailing edge can only have one value, the velocities on the top and bottom must converge to the same value as the flow approaches the trailing edge. In aerodynamics, this is called the Kutta condition.
That's an utterly retarded statement. If the terrorists wanted, they could build their own planes. It's not that damn hard. You can build the damn things in your garage! By themselves, they don't have enough mass to do jack shit to a building (even a car-sized one), so you'd have to load them up with C4. Then, you'd have a weapons delivery platform about as attractive, as, well, getting some guy to strap-on some C4 and run into the damn building! Hell, for the price of one of these sky cars, you can get a couple of dozen guys to do it. That becomes a far more attractive delivery platform than the sky car, because now you don't have a single point of failure.
That's nonsense. Flying can be a rather efficient way of getting around. Aerodynamics kinda kick you in the ass for high-speed flight, but for low-speed flight its actually kind of friendly. There are high-lift devices being developed that can give aircraft an L/D of 45 or so. That means with a 100 lb thrust miniature jet engine, you can lift a 4500 lb car-sized vehicle. The trick is getting that 100 lb of thrust efficiently. The most efficient jet engines in the world have an sfc at sea-level of 0.3. For a 100 lb thrust engine, that's about 30 lb of fuel per hour. If you get such a plane to a cruise speed of 300 mph (entirely possible with today's technology), then you're talking about 70 mpg, more efficient than most cars.
The trick is figuring out propulsion. Today's small jet engines are several times less efficient than the 70,000lb behemoths that achieve 0.3 sfc. That's not inherent to the technology, however. It's more of an engineering problem, trying to miniaturize the high-pressure high-temperature technologies enough to fit in a jet engine targetted for 100lb of thurst.
That's a completely asnine statement. By your logic, CATIA or SoftImage are failures. You not only need a manual for those, most people even take classes on them and spend years learning their ins-and-outs! That's a silly statement, of course, CATIA and SoftImage are widely regarded as category-leading pieces of software. A programmer doesn't just "type and save text" with a text editor. That's like saying an engineer "draws lines" with CATIA, or an artist "colors pixels" with SoftImage. It's superficially true, but completely misleading. In reality, all three professions use these programs to create very complex works. For them, a few months spent learning the software is nothing compared to years of daily use of the software. If a steep learning curve is the price of software that makes the programmer/artist/engineer more productive during those years of daily use, well, that's quite a good deal indeed.