(defun factorial (x)
(if (= x 0)
1
(* x (factorial (- x 1)))))
(Sorry about the indenting!)
Some things to note:
(1) In Lisp, integers automatically overflow into big integers, so you can type (factorial 1000) with confidence; try that with your C version.
(2) Note that my function does the right thing on (factorial 1) and (factorial 0).
(3) Because Lisp is expression-oriented, there's no need for the explicit return statements (in this case) that clutter your definition.
(4) Of course, factorial can be written iteratively in Lisp using one of its many iteration constructs (dotimes, do, loop). The latter two put for(;;) style loops to utter shame, by the way.
(5) The Lisp functions are much more general than this example shows. For example, the = function can compare a variable number of items a once, e.g., (= arg1 arg2 arg3 20). The * function also takes multiple arguments (e.g., (* 1 2 3 4) -> 24) and includes the correct identity: (*) -> 1.
(1) Yeah, but how do you find good Lisp programmers? Java programmers are a dime a dozen.
Maybe it's because Lisp is esoteric these days, but most Lisp programmers are good. Where do you find GOOD Java programmers (i.e., not the "21 days" variety) and when you do, are they a dime a dozen?
use of programming languages in the Real World is often tightly constrained by the fact that not everybody knows every language.
Yeah, we should just cut the crap and use one language for everything. Hmmm. What should that be? C#, VB, or x86 assembler? Running under Windows or...Windows?
I wonder why other high-level programming languages appeared after Backus and the boys invented Fortran? I mean, they had a high-level language and all high-level programmers spoke it. Why invent others? Why Babel?
And given that Campbell's soups are the most popular, and are probably nutritionally adequate, why slurp anything else?
It should also be noted that Guy Steele, the editor of the original definition of Common Lisp in 1984 and the pre-ANSI definition in 1990, is the same guy who:
(1) Co-invented scheme.
(2) Co-wrote the best reference manual on C with Samuel Habison ("C: A Reference Manual", I think)
(3) Co-wrote the best reference manual on Java ("The Java Programming Language Specification", I think)
(4) Collected the original Jargon file and is therefore responsible for the funny stuff (as opposed to Raymond's contributions) in "The Hacker's Dictionary".
There are no typing issues with Lisp. If you want a string you've got a string. You can't go changing it without explicit conversion, just like in C. The idea that Lisp is weakly typed is a myth, something perpetuated from the 1960s and 1970s. Just like the myth that Lisp is slow, which is also a holdover from the 1960s.
Lisp is a strongly but *dynamically* typed language. Any datum has one type. That typed cannot be changed. If you wish to have that datum converted to another type then you use something like 'coerce' which will create a new datum of different type holding the result of mapping the information in question from the old type to the new.
It is *dynamically* typed because types are not static. You can change types, you can create new types, etc. It's not restrictive, but it is *safe*.
C is actually *weakly* and *statically* typed. It's weak because any datum can be converted to any other, particularly through the use of a void pointer. It's static because you have to declare your types at compile time, which limits your program's capabilities, and makes things such as polymorphism very difficult.
Many "modern" functional languages, like ML andHaskell , have strong-yet-polymorphic typing and all of the functional abilities of Lisp. Of course, these languages suffer from a derth of libraries, too.
And they lack macros, class systems as advanced as Common Lisp's CLOS, etc.
I prefer stronger typing than lisp has. I think C++'s type system is just right.
I'm not sure what you're after, but in Common Lisp, you can optionally declare the types of variables (e.g., function parameters) and, under strict safety checking by the compiler (such as CMUCL's), some compile-time type-checking can be done.
That prejudice alone is perhaps forgivable, but the logic used to support the claim - in particular, the reference to their use of Lisp macros - is laughable.
Sure, I'll follow that thread. I'll follow that thread right to where it ends in a frayed, tattered mess at the foot of a giant billboard
Macros allow one to write programs that write other programs. You can also recurse -- write macros that write other macros, macros that write macros that write macros, etc. Graham and friends did this. When it bottomed out, he was writing a few lines of code for every 10 or 100 his competitors were writing.
Don't think stupid "replace this bit of text with that bit of text" C macros. They're laughable. In case you missed it, Lisp macros write Lisp code into other Lisp code, with the full power of Lisp available to compute each expansion.
If you want to truly understand this, work through an intro text on Common Lisp and then read Graham's "On Lisp" for a peek at what real macros can buy you.
Would anyone know if his co-author Robert Morris is the same Robert Morris (or his father) of the infamous Morris internet worm from the late 80's?
RTM the senior is the Unix/Security guru. He was a big fan of Brunner's "Shockwave Rider", which described a future world sporting a global network riddled with transient "worms". His son, RTM the junior, authored the infamous internet worm as a grad student at Cornell. I think Paul Graham and RTM the son were undergrads together at Harvard.
Scheme is much prettier than CL; it's breathtaking in its conceptual purity.
But Scheme can also feel like a straightjacket. It's easy to write beautfil small programs in Scheme, but what about beautiful LARGE programs? Common Lisp has 95% of Scheme's beauty on small programs but includes the extras (e.g., objects, macros) that allow it to scale beautifully to large programs.
a previosu poster pretty much stole my thunder, but these points bear repeating:
I'd like to point out how bad the I/O is in Lisp
Not true. Lisp provides a myriad of I/O facilities, some of top-notch efficiency. It *is* true that the various options vary in efficiency. If you want to write a file of bytes, using FORMAT (think printf on ben-johnson-quality steroids) is overkill and inefficient. The knowledgable programmer instead uses WRITE-BYTE.
how hard it is to properly handle the myriad possible errors a program has to handle gracefully when working with humans
The Common Lisp condition system is at least as powerful as the C++ and Java equivalents. Maybe you're an old timer who's knowledge stops at CATCH and THROW?
Also, most lisp engines I've seen are interpreted (save for things like the Lisp Machine).
Not just untrue for decades now, but a persistent myth/slur. The Common Lisp implementation I use has NO interpreter. I can process files in batches or I can prototype interactively and incrementally, all using the compiler.
Lisp is good for writing programs that are unthinkable in other langauges -- exploring bleeding-edge ideas. When such programs prove feasible, they are often rewritten in conventional languages boasting plenty of cheap programmers. The Lisp origin is lost, for marketing reasons or whatever. For example, MACSYMA, the progenitor of all mathematical programming environments (mathematica, mathlab, etc.) was written in Lisp, as were the expert system shells of the 1970s and 1980s.
Check out http://www.lisp.org/table/commercial-use.htm for a bevy of current applications and http://www.lisp.org/ for general information on lisp.
It's a bit weird to put Lisp in the "functional" programming languages bin. It does have its roots in McCarthy's (its inventor) attempts to understand the lambda calculus, which is the formal foundation of functional programming languages. But functional programming languages as a separate category didn't really emerge until well after Lisp, with Backus's Turing Award lecture. This is why "purer" languages such as scheme, ml, and haskell are much better exemplars of functional programming languages.
Lisp programmers view the language as multi-paradigmatic, but in an elegant way as opposed to the "bolted on afterwards" feel of C++. Lisp was one of the first programming languages to support OOP, for example. In fact, I believe it was the first OOP language to pass ANSI standardization. (Also, Alan Kay was a frequent visitor to MIT in the early 1970s and claims simula and lisp as twin influences on smalltalk.)
Perhaps the dominant view of lisp programmers of lisp is that it supports metalinguistic programming -- the implementation of custom programming languages which are then used to elegantly solve problems. It's a compiler construction kit!
(1) who would win in a fistfight, you or larry wall?
(2) who speaks more languages, you or (that supposed linguist) larry wall?
(3) if you could eliminate one planet from the solar system (besides the earth), which one would it be?
(4) how do you feel about the euro?
Some of you are going to say "what about Linux??!!?", but in all honesty, nothing is ready for mainstream until your mom or a pot-smoking graphic designer can figure it out.
Spoken like a Jolt-addled, command-line-worshipping system administrator. Now go un-jam the printer so your mom, the graphic designer, and I can get back to work.
(1) Are you willing and able to pay for established professionals?
Amen. Look, you're between a rock and a hard place. You want excellence but don't want to pay an industry salary for it. You might have been able to get away with this ten or more years ago, when academic and starting industry salaries were not THAT discrepant, by touting the virtues of academic life -- flexible schedules, good benefits, smart colleagues, etc. Unfortunately, the gap between industry and academic salaries has grown so wide that it's a much tougher sell these days. (I know, I've been a "research programmer" in academia off and on during the past twelve years.)
That's the rock. The hard place is that you say that your project is not sexy enough to attract the pure computer science types with deep mathematical skills. Are you surprised? Abstract thinkers of this sort are in the game to chase Platonic ideals, not administrate systems. The lab in which I work has two full-time system administrators that support everyone's work, including mine. If you want people with big brains, you can't expect them to clean your toilets too.
To sum up, I think you're in a bad position Your main hope would seem to be to split the position, hire a sys admin for the sys admin duties (or share someone else's), and try to lure a talented programmer who's more interested in the presumably cutting-edge nature of your research than in salary and stock options.
Isn't this a bit like suggesting supermarkets couldn't succeed because people wouldn't want to buy meat, vegetables, and magazines from the same place?
IMO, supermarkets succeed in the US because they offer convenience, transportation-wise. It is a hassle in our car culture to drive to and park at the produce stand, then the butcher, then the bakery, etc. We find it easier to drive to one place, park, and get all of our shopping done ONCE. Contrast this with many European cities, where the various speciality stores one might visit are densely located around your home. There is almost no cost to visiting the produce store, butcher's shop, and bakery separately when they're next door to one another. The web is like an urban shopping environment -- i can instantaneously switch between pages at different sites. There is almost no convenience associated with different pages being hosted at the same versus different sites.
And just as there are advantages with shopping at different speciality stores -- there is a wider selection of better-prepared breads and pastries at a bakery versus a supermarket -- one tends to get better content in area A from a website devoted to domain A than one spread over A-Z. (For example, as a native of Chicago, I prefer to read the chicagosports.com to cnnsi.com and espn.com, let alone the stuff available at the more general portals.)
I signed an 'Inventions & IP Rights' contract. That contract stated that the work that I had been carrying out off (and was planning to continue with) of my own back, and in my own time and was my own.
It seems that an IP lawyer should be able to use this to beat the company over the head as long as you can document that (1) you started your project before starting employment and (2) there's no evidence that you did work for your project on their time, e.g., performance reviews wondering why you seem to work furiously yet get nothing done.
If I was in your shoes, I'd want all of my options AND no more to do with this company.
Predominately white schools in affluent neighborhoods don't always get better funding
They do in places where school expenditures are tied to real estate taxes (because more affluent folks have more expensive homes and therefore generate more tax money, per capita, for local school districts). This has been the case in the municipalities where I have lived.
Once in a while a student can rise above their surroundings and achieve great things without the help of their (often absent) parents, but this is like 1 in 1000
Like RMS he seems to have become famous whilst only having produced a single piece of well-known code, but at least RMS has something he believes in.
I don't know much about RMS's GNU activities, but I always assumed he wrote EMACS and significant portions of GCC, the HURD kernel, etc. But I do know that he produced a TON of software before his GNU days in the Lisp world. Check out the last chapter of Steven Levy's "Hackers" for details on this part of his life, including a description of a year when he single-handidly matched the productivty of the world-class hackers of an entire company (Symbolics) that he felt was unethical.
In the programming language research community, the feeling is that dynamic languages are very good for things like scripting and prototyping, but are not as good an idea for large software systems.
If you are equating dynamic languages with interpreted languages (e.g., most scripting languages), and i'm not sure that you are, then you are mistaken. There are compiled languages that are dynamic (e.g., don't throw a bunch of information away at compile time, allow the definition of new bits of "program" or the modification of existing definitions at run-time, etc.). One is Common Lisp.
The problem is twofold - first, as you mention, dynamic languages always get a performance hit.
The performance hit incurred by good dynamic programming languages is no more than 50% according to comparisons that I have seen, and can go the other way under certain patterns of memory allocation. Again, I'm thinking of Common Lisp.
But the second reason - which you miss - might be more important - fewer errors can be detected at compile time... they would only turn up at runtime, or worse, end up as hard to detect bugs.
Good dynamic languages allow you to OPTIONALLY declare the types of quantities and check these types to varying levels of tightness. Given this flexibility, it is common to develop in a dynamic language with little or no type checking, adding declarations later when the types have been nailed down.
Slashdot Mirror
First of all, a Lisper MIGHT write this as:
(defun factorial (x)
(if (= x 0)
1
(* x (factorial (- x 1)))))
(Sorry about the indenting!)
Some things to note:
(1) In Lisp, integers automatically overflow into big integers, so you can type (factorial 1000) with confidence; try that with your C version.
(2) Note that my function does the right thing on (factorial 1) and (factorial 0).
(3) Because Lisp is expression-oriented, there's no need for the explicit return statements (in this case) that clutter your definition.
(4) Of course, factorial can be written iteratively in Lisp using one of its many iteration constructs (dotimes, do, loop). The latter two put for(;;) style loops to utter shame, by the way.
(5) The Lisp functions are much more general than this example shows. For example, the = function can compare a variable number of items a once, e.g., (= arg1 arg2 arg3 20). The * function also takes multiple arguments (e.g., (* 1 2 3 4) -> 24) and includes the correct identity: (*) -> 1.
(1) Yeah, but how do you find good Lisp programmers? Java programmers are a dime a dozen.
Maybe it's because Lisp is esoteric these days, but most Lisp programmers are good. Where do you find GOOD Java programmers (i.e., not the "21 days" variety) and when you do, are they a dime a dozen?
What does LISP have that Python doesn't?
...) statement?
What does Python have that Lisp doesn't?
Is a macro similar to Python's exec() or eval() statements?
Is exec() similar to Lisp's (eval
(The answer to your second question is "no", by the way.)
use of programming languages in the Real World is often tightly constrained by the fact that not everybody knows every language.
Yeah, we should just cut the crap and use one language for everything. Hmmm. What should that be? C#, VB, or x86 assembler? Running under Windows or...Windows?
I wonder why other high-level programming languages appeared after Backus and the boys invented Fortran? I mean, they had a high-level language and all high-level programmers spoke it. Why invent others? Why Babel?
And given that Campbell's soups are the most popular, and are probably nutritionally adequate, why slurp anything else?
It should also be noted that Guy Steele, the editor of the original definition of Common Lisp in 1984 and the pre-ANSI definition in 1990, is the same guy who:
(1) Co-invented scheme.
(2) Co-wrote the best reference manual on C with Samuel Habison ("C: A Reference Manual", I think)
(3) Co-wrote the best reference manual on Java ("The Java Programming Language Specification", I think)
(4) Collected the original Jargon file and is therefore responsible for the funny stuff (as opposed to Raymond's contributions) in "The Hacker's Dictionary".
> Typing issues.
There are no typing issues with Lisp. If you want a string you've got a string. You can't go changing it without explicit conversion, just like in C. The idea that Lisp is weakly typed is a myth, something perpetuated from the 1960s and 1970s. Just like the myth that Lisp is slow, which is also a holdover from the 1960s.
Lisp is a strongly but *dynamically* typed language. Any datum has one type. That typed cannot be changed. If you wish to have that datum converted to another type then you use something like 'coerce' which will create a new datum of different type holding the result of mapping the information in question from the old type to the new.
It is *dynamically* typed because types are not static. You can change types, you can create new types, etc. It's not restrictive, but it is *safe*.
C is actually *weakly* and *statically* typed. It's weak because any datum can be converted to any other, particularly through the use of a void pointer. It's static because you have to declare your types at compile time, which limits your program's capabilities, and makes things such as polymorphism very difficult.
This is a brilliant point, moderators.
Many "modern" functional languages, like ML andHaskell , have strong-yet-polymorphic typing and all of the functional abilities of Lisp. Of course, these languages suffer from a derth of libraries, too.
And they lack macros, class systems as advanced as Common Lisp's CLOS, etc.
I prefer stronger typing than lisp has. I think C++'s type system is just right.
I'm not sure what you're after, but in Common Lisp, you can optionally declare the types of variables (e.g., function parameters) and, under strict safety checking by the compiler (such as CMUCL's), some compile-time type-checking can be done.
That prejudice alone is perhaps forgivable, but the logic used to support the claim - in particular, the reference to their use of Lisp macros - is laughable.
Sure, I'll follow that thread. I'll follow that thread right to where it ends in a frayed, tattered mess at the foot of a giant billboard
Macros allow one to write programs that write other programs. You can also recurse -- write macros that write other macros, macros that write macros that write macros, etc. Graham and friends did this. When it bottomed out, he was writing a few lines of code for every 10 or 100 his competitors were writing.
Don't think stupid "replace this bit of text with that bit of text" C macros. They're laughable. In case you missed it, Lisp macros write Lisp code into other Lisp code, with the full power of Lisp available to compute each expansion.
If you want to truly understand this, work through an intro text on Common Lisp and then read Graham's "On Lisp" for a peek at what real macros can buy you.
In fact, it's not for something like graphics programming.
As has been noted, Nichimen's (http://www.nichimen.com/) tools for authoring Ninetendo games are written in Lisp.
Would anyone know if his co-author Robert Morris is the same Robert Morris (or his father) of the infamous Morris internet worm from the late 80's?
RTM the senior is the Unix/Security guru. He was a big fan of Brunner's "Shockwave Rider", which described a future world sporting a global network riddled with transient "worms". His son, RTM the junior, authored the infamous internet worm as a grad student at Cornell. I think Paul Graham and RTM the son were undergrads together at Harvard.
Scheme is much prettier than CL; it's breathtaking in its conceptual purity.
But Scheme can also feel like a straightjacket. It's easy to write beautfil small programs in Scheme, but what about beautiful LARGE programs? Common Lisp has 95% of Scheme's beauty on small programs but includes the extras (e.g., objects, macros) that allow it to scale beautifully to large programs.
a previosu poster pretty much stole my thunder, but these points bear repeating:
I'd like to point out how bad the I/O is in Lisp
Not true. Lisp provides a myriad of I/O facilities, some of top-notch efficiency. It *is* true that the various options vary in efficiency. If you want to write a file of bytes, using FORMAT (think printf on ben-johnson-quality steroids) is overkill and inefficient. The knowledgable programmer instead uses WRITE-BYTE.
how hard it is to properly handle the myriad possible errors a program has to handle gracefully when working with humans
The Common Lisp condition system is at least as powerful as the C++ and Java equivalents. Maybe you're an old timer who's knowledge stops at CATCH and THROW?
Also, most lisp engines I've seen are interpreted (save for things like the Lisp Machine).
Not just untrue for decades now, but a persistent myth/slur. The Common Lisp implementation I use has NO interpreter. I can process files in batches or I can prototype interactively and incrementally, all using the compiler.
Lisp is good for writing programs that are unthinkable in other langauges -- exploring bleeding-edge ideas. When such programs prove feasible, they are often rewritten in conventional languages boasting plenty of cheap programmers. The Lisp origin is lost, for marketing reasons or whatever. For example, MACSYMA, the progenitor of all mathematical programming environments (mathematica, mathlab, etc.) was written in Lisp, as were the expert system shells of the 1970s and 1980s.
Check out http://www.lisp.org/table/commercial-use.htm for a bevy of current applications and http://www.lisp.org/ for general information on lisp.
It's a bit weird to put Lisp in the "functional" programming languages bin. It does have its roots in McCarthy's (its inventor) attempts to understand the lambda calculus, which is the formal foundation of functional programming languages. But functional programming languages as a separate category didn't really emerge until well after Lisp, with Backus's Turing Award lecture. This is why "purer" languages such as scheme, ml, and haskell are much better exemplars of functional programming languages.
Lisp programmers view the language as multi-paradigmatic, but in an elegant way as opposed to the "bolted on afterwards" feel of C++. Lisp was one of the first programming languages to support OOP, for example. In fact, I believe it was the first OOP language to pass ANSI standardization. (Also, Alan Kay was a frequent visitor to MIT in the early 1970s and claims simula and lisp as twin influences on smalltalk.)
Perhaps the dominant view of lisp programmers of lisp is that it supports metalinguistic programming -- the implementation of custom programming languages which are then used to elegantly solve problems. It's a compiler construction kit!
(1) who would win in a fistfight, you or larry wall?
(2) who speaks more languages, you or (that supposed linguist) larry wall?
(3) if you could eliminate one planet from the solar system (besides the earth), which one would it be?
(4) how do you feel about the euro?
Some of you are going to say "what about Linux??!!?", but in all honesty, nothing is ready for mainstream until your mom or a pot-smoking graphic designer can figure it out.
Spoken like a Jolt-addled, command-line-worshipping system administrator. Now go un-jam the printer so your mom, the graphic designer, and I can get back to work.
(1) Are you willing and able to pay for established professionals?
Amen. Look, you're between a rock and a hard place. You want excellence but don't want to pay an industry salary for it. You might have been able to get away with this ten or more years ago, when academic and starting industry salaries were not THAT discrepant, by touting the virtues of academic life -- flexible schedules, good benefits, smart colleagues, etc. Unfortunately, the gap between industry and academic salaries has grown so wide that it's a much tougher sell these days. (I know, I've been a "research programmer" in academia off and on during the past twelve years.)
That's the rock. The hard place is that you say that your project is not sexy enough to attract the pure computer science types with deep mathematical skills. Are you surprised? Abstract thinkers of this sort are in the game to chase Platonic ideals, not administrate systems. The lab in which I work has two full-time system administrators that support everyone's work, including mine. If you want people with big brains, you can't expect them to clean your toilets too.
To sum up, I think you're in a bad position Your main hope would seem to be to split the position, hire a sys admin for the sys admin duties (or share someone else's), and try to lure a talented programmer who's more interested in the presumably cutting-edge nature of your research than in salary and stock options.
Isn't this a bit like suggesting supermarkets couldn't succeed because people wouldn't want to buy meat, vegetables, and magazines from the same place?
IMO, supermarkets succeed in the US because they offer convenience, transportation-wise. It is a hassle in our car culture to drive to and park at the produce stand, then the butcher, then the bakery, etc. We find it easier to drive to one place, park, and get all of our shopping done ONCE. Contrast this with many European cities, where the various speciality stores one might visit are densely located around your home. There is almost no cost to visiting the produce store, butcher's shop, and bakery separately when they're next door to one another. The web is like an urban shopping environment -- i can instantaneously switch between pages at different sites. There is almost no convenience associated with different pages being hosted at the same versus different sites.
And just as there are advantages with shopping at different speciality stores -- there is a wider selection of better-prepared breads and pastries at a bakery versus a supermarket -- one tends to get better content in area A from a website devoted to domain A than one spread over A-Z. (For example, as a native of Chicago, I prefer to read the chicagosports.com to cnnsi.com and espn.com, let alone the stuff available at the more general portals.)
IANAL...
I signed an 'Inventions & IP Rights' contract. That contract stated that the work that I had been carrying out off (and was planning to continue with) of my own back, and in my own time and was my own.
It seems that an IP lawyer should be able to use this to beat the company over the head as long as you can document that (1) you started your project before starting employment and (2) there's no evidence that you did work for your project on their time, e.g., performance reviews wondering why you seem to work furiously yet get nothing done.
If I was in your shoes, I'd want all of my options AND no more to do with this company.
Predominately white schools in affluent neighborhoods don't always get better funding
They do in places where school expenditures are tied to real estate taxes (because more affluent folks have more expensive homes and therefore generate more tax money, per capita, for local school districts). This has been the case in the municipalities where I have lived.
Once in a while a student can rise above their surroundings and achieve great things without the help of their (often absent) parents, but this is like 1 in 1000
Agreed, for the most part.
Like RMS he seems to have become famous whilst only having produced a single piece of well-known code, but at least RMS has something he believes in.
I don't know much about RMS's GNU activities, but I always assumed he wrote EMACS and significant portions of GCC, the HURD kernel, etc. But I do know that he produced a TON of software before his GNU days in the Lisp world. Check out the last chapter of Steven Levy's "Hackers" for details on this part of his life, including a description of a year when he single-handidly matched the productivty of the world-class hackers of an entire company (Symbolics) that he felt was unethical.
RMS can hack.
"Wichert Akkerman" is kind of a scary name. It suggests demonic uses of Ackermann's function, no? Oh, well, back to Nickelodeon.
99.44% "You are the product of a mutational union of ~640Mbytes of genetic information."
Damn. Looks like the 640 *bytes barrier is back.
In the programming language research community, the feeling is that dynamic languages are very good for things like scripting and prototyping, but are not as good an idea for large software systems.
If you are equating dynamic languages with interpreted languages (e.g., most scripting languages), and i'm not sure that you are, then you are mistaken. There are compiled languages that are dynamic (e.g., don't throw a bunch of information away at compile time, allow the definition of new bits of "program" or the modification of existing definitions at run-time, etc.). One is Common Lisp.
The problem is twofold - first, as you mention, dynamic languages always get a performance hit.
The performance hit incurred by good dynamic programming languages is no more than 50% according to comparisons that I have seen, and can go the other way under certain patterns of memory allocation. Again, I'm thinking of Common Lisp.
But the second reason - which you miss - might be more important - fewer errors can be detected at compile time... they would only turn up at runtime, or worse, end up as hard to detect bugs.
Good dynamic languages allow you to OPTIONALLY declare the types of quantities and check these types to varying levels of tightness. Given this flexibility, it is common to develop in a dynamic language with little or no type checking, adding declarations later when the types have been nailed down.