Self-modifying code is rare enough that all code should be in read-only (except by privileged processes, like the kernel which sets it up and tears it down) segments,
You're forgetting about systems that do code generation on the fly such as Lisp systems. In such systems code is data and thus executable code is also just data. It's stored in the heap and must be executable.
Let's not restrict our operating systems to support only the lowest common denominator (the C programming language).
In this day and age where things are named by the opposite of their actual effect (e.g. "The Patriot Act") I suggest that DRM's CD's be called "Freedom CDs"
> You cannot bind dynamic-length strings into a > language and match the efficency (at least on a > function-level) of a static language.
Actually it turns out you can Anonymous Coward, at least in Common Lisp. Through the use of type declarations and the 'optimize' declaration you can declare your intentions that it's more important that a piece of code run fast than it be safe from bad input. In that case string operations are as fast as C.
Generally you only worry about speeding up the key loops in your code (there's that old saying that N% of the time is spent in M% of the code for N >> M). Before removing type checks through the optimize declaration you add code to ensure that the input is ok and then you let the compiler generate optimized code for the loop. Thus you're only vulnerable in a small part of your code and with your own checks you eliminte that vulnerability. With C you're vulnerable in all your code by default. And that brings us back to zlib...
Most Common Lisp compilers compile to machine code just like C compilers do. The overhead imposed by the runtime type dispatch for operations is very small (and can even go to zero in many cases). Any difference in deflate speed is likely to be insignificant part of the overall speed any application using zlib.
Has anyone read the zlib code? While the author clearly tried to make it readable it's still very complex and it's very hard to see at a glance or even after many glances where potential buffer overflow problems may exist (or even where it might fail to implement the deflate algorithm). C is great language for writing an operating system where all you care about is setting bits in a machine register but this algorithm really taxes its abilties.
For comparison here is the deflate algorithm written in Common Lisp. It all fits neaty into a few pages. This is a far better language comparison example than the oft-cited hello world comparison.
What's going to keep me away from this site is the same thing that bothers me about all the Yahoo sites: you have to keep logging in.
I work on a bunch of computers at work and at home and Yahoo won't let me stay logged in for more than a few days. Multiply that annoyance by about six computers and it seems that I'm constantly having to enter my password.
Yahoo has decided to make things somewhat safer for those who use public internet terminals but at the expense of most of us who have exclusive use of our machines.
The key to keeping a job is to get off the well worn path of C/Java/Perl/Python and develop specialized skills that won't be so easily duplicated by the programmer factories. Learn to use high performance Common Lisp systems for example. (see http://www.paulgraham.com/avg.html for a Lisp case study).
At the time Bill didn't have a Ph.D (and still may not.. I don't know if they gave him an honorary one years later). How could he have a post-doctorate position?
JiL - java in lisp ... compiles to the jvm
on
The Future of Java?
·
· Score: 2, Informative
Here's another language JiL that compiles to Java Byte Codes. It's a language that's better than Java but worse than Common Lisp, so it kind of sits there in the middle.
It allows Java programmers to get around one of Java's biggest weaknesses - the lack of a macros.
Having written a Common Lisp compiler (to machine code) and a Java compiler (to Java class files) I can say that Java is by far the more complex language.
Common Lisp looks like a huge language because when it was made an ANSI standard it wasn't made clear which parts comprised the language itself and which parts were just the APIs for library functions. This was a mistake made by the Common Lisp standards committee. They wanted to make sure that every Common Lisp implementation contained a rich set of library functions.
This mistake in the ANSI spec doesn't change the fact that Common Lisp is a simple regular language.
Common Lisp is actually a pretty simple language. What throws people off is the size of the Common Lisp ANSI specification. It's large because the authors decided to specify a large library of functions as well as the core of the language. If you ignore the library (and you are free to) then you're left with a language which is probably simpler than ML.
No one using a WYSIWYG editor has counted parentheses in 20 years. That's the editor's job. This is a non-issue.
Common Lisp's object system (CLOS) allows you to specify that a certain method be called only if specific arguments are passed. This sounds a lot like what you're referring to with ML.
The part about third party libraries just isn't true. Ever since the 1980's Lisps (beginning with Franz Lisp) have had the ability to link to libraries written in other languages. Thus all libraries written for C programmers became libraries for Lisp programmers.
Since Lisps usually offer an interactive interface, you can load in C libraries and interactively call functions in them.
There are now interfaces to Java VM's as well and once again not only can you call Java functions form Lisp and vice versa, but you can interactively call Java functions and view the results.
Lisp has become the ultimate interactive interface to functions normally accessed in the slow compile-link-run manner.
Slashdot Mirror
Self-modifying code is rare enough that all code should be in read-only (except by privileged processes, like the kernel which sets it up and tears it down) segments,
You're forgetting about systems that do code generation on the fly such as Lisp systems. In such systems code is data and thus executable code is also just data. It's stored in the heap and must be executable.
Let's not restrict our operating systems to support only the lowest common denominator (the C programming language).
In this day and age where things are named by the opposite of their actual effect (e.g. "The Patriot Act") I suggest that DRM's CD's be called "Freedom CDs"
> You cannot bind dynamic-length strings into a
> language and match the efficency (at least on a
> function-level) of a static language.
Actually it turns out you can Anonymous Coward, at least in Common Lisp. Through the use of type declarations and the 'optimize' declaration you can declare your intentions that it's more important that a piece of code run fast than it be safe from bad input. In that case string operations are as fast as C.
Generally you only worry about speeding up the key loops in your code (there's that old saying that N% of the time is spent in M% of the code for N >> M). Before removing type checks through the optimize declaration you add code to ensure that the input is ok and then you let the compiler generate optimized code for the loop. Thus you're only vulnerable in a small part of your code and with your own checks you eliminte that vulnerability. With C you're vulnerable in all your code by default. And that brings us back to zlib...
Absolutely.
Most Common Lisp compilers compile to machine code just like C compilers do. The overhead imposed by the runtime type dispatch for operations is very small (and can even go to zero in many cases). Any difference in deflate speed is likely to be insignificant part of the overall speed any application using zlib.
Has anyone read the zlib code? While the author clearly tried to make it readable it's still very complex and it's very hard to see at a glance or even after many glances where potential buffer overflow problems may exist (or even where it might fail to implement the deflate algorithm). C is great language for writing an operating system where all you care about is setting bits in a machine register but this algorithm really taxes its abilties.
For comparison here is the deflate algorithm written in Common Lisp. It all fits neaty into a few pages. This is a far better language comparison example than the oft-cited hello world comparison.
I work on a bunch of computers at work and at home and Yahoo won't let me stay logged in for more than a few days. Multiply that annoyance by about six computers and it seems that I'm constantly having to enter my password.
Yahoo has decided to make things somewhat safer for those who use public internet terminals but at the expense of most of us who have exclusive use of our machines.
The key to keeping a job is to get off the well worn path of C/Java/Perl/Python and develop specialized skills that won't be so easily duplicated by the programmer factories. Learn to use high performance Common Lisp systems for example.
(see http://www.paulgraham.com/avg.html for a Lisp case study).
At the time Bill didn't have a Ph.D (and still may not.. I don't know if they gave him an honorary one years later). How could he have a post-doctorate position?
Here's another language JiL that compiles to Java Byte Codes. It's a language that's better than Java but worse than Common Lisp, so it kind of sits there in the middle.
It allows Java programmers to get around one of Java's biggest weaknesses - the lack of a macros.
http://www.franz.com/support/documentation/6.2/doc /jil.htm
you have an extra space in that url... here's the correct one
Having written a Common Lisp compiler (to machine code) and a Java compiler (to Java class files) I can say that Java is by far the more complex language.
Common Lisp looks like a huge language because when it was made an ANSI standard it wasn't made clear which parts comprised the language itself and which parts were just the APIs for library functions. This was a mistake made by the Common Lisp standards committee. They wanted to make sure that every Common Lisp implementation contained a rich set of library functions.
This mistake in the ANSI spec doesn't change the fact that Common Lisp is a simple regular language.
The part about third party libraries just isn't true. Ever since the 1980's Lisps (beginning with Franz Lisp) have had the ability to link to libraries written in other languages. Thus all libraries written for C programmers became libraries for Lisp programmers. Since Lisps usually offer an interactive interface, you can load in C libraries and interactively call functions in them. There are now interfaces to Java VM's as well and once again not only can you call Java functions form Lisp and vice versa, but you can interactively call Java functions and view the results. Lisp has become the ultimate interactive interface to functions normally accessed in the slow compile-link-run manner.