OS improvement has plateaued precisely because of people thinking it has. In fact, there have been plenty of innovations in the past that have been by-passed by the industry and forgotten. That alone indicates that there is a great amount room for improvement. Looking at the major Operating Systems of our time--Windows, Linux, Unix, and Mac OSX--it is quite clear that there are many unsolved problems.
Why, every day, we see new exploits and bugs? And why do users feel constrained and lost in the morass we call a UI? Where is the fully verified, theorem-prover-checked, OS code? Where is the OS built on high level language concepts? Where is the OS that actually thinks of data as objects rather than octets?
"The theory that underlies Operating Systems"...pfooey...I would like to see real Operating Systems actually try to take a formal approach towards the problem, instead of the kludged up hacks that are currently used.
As for nonsensical metaphors:
The Michaelson-Morley experiments were a greatly flawed attempt to prove the existence of the aether. And the negative results were most certainly not taken as evidence of the incorrectness of the physics of the time.
Special relativity derives wholy from two axioms, in addition to basic geometry and mathematics:
1) That the laws of physics are the same in all inertial frames of reference.
2) That one of the laws of physics is: the speed of light is always a constant, in a vacuum.
From this, everything else is fairly trivial.
The Michaelson-Morley experiments could be taken as evidence towards axiom (2), but most certainly do not constitute proof.
The most significant contribution towards special relativity not provided by Einstein was probably due to Lorentz.
The primary problem with Emacs is Emacs Lisp. You can find many instances of people suggesting to Stallman over the years that he should switch to Common Lisp, the budding standard. Others suggested Scheme. Either would've been a better choice.
Emacs Lisp is a throwback to MACLISP, from the 70s. It is not a well designed language, and has an almost C-like essence to it which flies in the face of Lisp. For example, typing (expt 2 32) into Emacs gives you 0, as if you typed it into a C program. That's supposed to be 2^32 = 4294967296, and all proper Lisps will give you the correct answer. Common Lisp is very smart about numerical operations, even automatically choosing the best representation for a number object.
One of the choices that will surprise an inexperienced programmer is the use of so-called "dynamic scope" for variables. This sort of thing died out in Lisps after the mid-80s but still remains in Emacs to this day. "Dynamic scope" while useful in some instances, is generally not held to be a good default for variable scope because it breaks referential transparency. Common Lisp offers the ability to designate a local variable as "special" (dynamic scope) if you wish that behavior, otherwise it defaults to the normal lexical (static) scope. "Dynamic scope" had some popularity in the past due to it being extremely easy to implement in an interpreter, in fact it originated out of a mistake made in the "original LISP" eval function.
And, in general, Emacs Lisp doesn't have any of the advanced functionality of Common Lisp at all. So in terms of writing applications, Emacs Lisp can be a pain. The reason given by Stallman for not using Common Lisp? "Too big". The ironic part is that Emacs ended up attempting to reproduce the functionality of Common Lisp (see the package named CL) but in a half-assed way. Much like many other large programs.
Clearly the implementations of FSF and X Emacs are very simple, almost just a wrapper over C. And the GC sucks.
With all its flaws, Emacs is still one of the best editors available. I'm just pointing out ways it could have been better. The Genera editor (Zmacs), was related to early Emacsen, was fully integrated with the Operating System, and programmable in ZetaLisp. The CMUCL project has an emacs-like editor written for it, named Hemlock, which has been resurrected recently. The LispWorks editor is supposedly based on Hemlock, I do not know for sure. McCLIM has an editor pane, which could possibly evolve into a full blown editor with advanced capabilities.
What did Emacs get right? It's fully customizable, and it is a great IDE for Emacs Lisp, with online help, cross referencing, and all. That's probably why there are so many packages for it. And keybindings, regexps, etc, are fairly irrelevant, since it's all customizable anyway.
Perhaps. But it would require an awful lot of work because Ruby does not really have the infrastructure for this sort of dynamic programmable environment. It is not something that simply materializes out of an OOP language. Looking at McCLIM source code, you'll see that it's a lot of work just to map graphical figures to objects. And Ruby doesn't have a condition system, s-expressions, or a real implementation.
I find it difficult to take any language seriously if it does not have a standardized definition and high performance compilers. Usually the former leads to the latter. Both mean that there is a group of people who care significantly about the language.
There were a number of Object Oriented systems written on top of Lisp; because Lisp allowed such flexibility in the language.
Genera, unless I'm mistaken, was based on Zetalisp (LispMachine Lisp) with an object system named "Flavors", a message-passing system with mix-ins loosely based on Smalltalk. The GUI was written with this system, and the GUI itself was interesting because its introspective abilities closely mirrored that of the underlying language. The elements of the GUI were all objects that could be manipulated, selected, inspected. Even graphical and text output on the screen could be categorized into classes and later manipulated as objects. This became the basis for CLIM (Common Lisp Interface Manager).
Unfortunately this style of GUI has fallen to the wayside in favor of the simpler but stupider Windows-style one. C and C++ do not have the flexibility that is required, in any case, for a dynamic GUI like that on the Lisp Machine. Look to Smalltalk, Squeak, Slate, or the reinvigorated CLIM projects (McCLIM, FreeCLIM) instead.
Symbolics made bad business decisions, indeed. They still do exist, and even have the oldest.com name registered: symbolics.com. There is hope that someday all the thousands of man-hours of work on Genera will become unencumbered or re-released.
Stallman helped popularize Emacs, along with the free software movement, which developed in parallel with the similar editors of the Lisp machines. The problem with Stallman is that he is incredibly stubborn (no kidding), and made mistakes early on that he was unwilling to fix. Hence FSF Emacs and even XEmacs is crippled as an editor, a language, and a platform, though people who only make simple use of it might not understand why.
It is just as well that Lisp languished in FSF, because it sprouted elsewhere in the open source community, with no philosophical encumbrances which don't necessarily make sense in a dynamic environment like a Lisp.
Over the last five years, I've seen quite a revival of Lisp. The regular programming crowd slowly accepts new ideas; they still insist on making the same mistakes that were already passed by Lisp programmers years ago. Ah well. My job is working on systems in Common Lisp, I am happy.
Not sure why you keep harping on functional programming. Lisp at the time was hardly a functional programming language. It HAD functions, yes, but was nothing like ML or Scheme. At the time, I suppose, that was something amazing and advanced.
If you look at code from that era, it is often startling different from code you would see today from Lisp programmers. The influence of Scheme on modern Common Lisp is undeniable.
The fact is, Emacs is an echo from the Lisp machine era. Those who understand Emacs, understand at least to a small extent why the Lisp machines were so powerful. And Emacs is not unpopular.
A quick calculation shows that to gain 1 day out of 90, you would have to be travelling ~15% of the speed of light. At that rate, you could travel to Mars and back within a day.
I use Subversion at work with a large (half-gig) source tree, and primarily on Windows (with TortoiseSVN). We use the new FSFS backend. Seems to do quite well, even on a networked filesystem.
Then you have the option of sending your changes to other repositories, since Darcs is distributed. You can copy/upload them directly, pull them from the other side, or even email them.
No, you completely misinterpreted my statement. I said that people who do exist now should have priority on decisions regarding their own personal life over people who do not exist now but might at some future time. Old folks quite clearly fit into the former category.
Otherwise, why not ban pregnant women (or even women of child bearing age) from spending money, eating certain foods, crossing streets, taking risks etc... simply because it might endanger a future child!
> You mean murder? Not everybody against murdering fetuses is against it for religious reasons.
Yes, there are a few people who genuinely care about the life of the infant, as opposed to caring about their need to spread the religion. My counter-argument to this is that the life of people who already exist and have worked hard to establish themselves takes priority over the unknown. (And if they haven't worked hard, then how are they going to support the child?) Think pragmatically, not at moral extremes.
As for gambling, while there are several examples of crime-ridden gambling areas, there's a few problems with establishing laws based on this observation: (a) statistical correlation and causation: did gambling actually directly cause it? (b) can the crime be eliminated while keeping the casinos? (c) people want the casinos anyway, check out the debate going on between PA, MD, WV, and DE residents about losing gambling dollars to each other. There was a recent article you can probably find it online. More and more areas are allowing casinos and I think you will find that not all of them become crime-ridden like Atlantic City (which has plenty of other reasons to be crime-ridden). And anyway, what does this have to do with online casinos? Online casinos solve the location problem pretty easily, don't you think?
As I hinted, without built-in support for higher-order functions and closures, a language cannot be considered to be `functional', because you would essentially have to implement these features yourself in your program (and most likely need to work around the limitations of that language also).
Does attending a university make me an academic? I don't think so---I also work, and understand the practical viewpoint of a coder; I just don't see it as adequate justification for throwing away the dictionary. As it is, `functional programming' is also supposed to mean `no side effects' but that has now been relegated to `pure functional programming'.
Personally, I backed away from the pure FP stance a long time ago, but I still think that higher-order functions and closures can be an extremely useful tool for any programmer and they can easily be mixed into other paradigms (just look at Smalltalk and Common Lisp).
Many languages run on existing hardware, but can they easily call each others' functions and share each others' objects/data? I understand that CLR attempts to make this work, but that is a very hard problem when the languages in question have a large conceptual mismatch.
I don't know why the OP mentioned Lisp macros, because they certainly have nothing to do with the backend of a Lisp compiler. However, problems still do exist with compiling to IL, mostly focusing around calling-conventions and potential limitations instituted by the CLR.
For example, Common Lisp has advanced object-oriented features such as multiple-dispatch methods and method combination, and this would most have a large conceptual mismatch with the typical calling conventions used by languages in IL, hence the CL compiler would need to use its own calling conventions and would be incompatible with other languages (thus defeating the point of IL).
Same goes for memory layout, stack management, etc... all due to Common Lisp's advanced data types and capabilities such as multiple-inheritance, CHANGE-CLASS, resumable conditions...
As far as I know, all real Common Lisp compilers that support Windows have not yet made any serious steps towards adding an IL backend, since there is very little benefit to be gained until those issues can somehow be worked out. Franz, in particular, put out a list of roadblocks a few years ago, but I do not know what became of it.
Scheme, on the other hand, has call/cc which requires heap-allocated stacks. This has been a sticking point with Scheme on JVM; the Schemes there simply do not support the full call/cc as a result. JVM is very limited with what the call-stack can do, for "security" reasons. I imagine CLR has similar issues, unless someone clever found a way around it.
In general, the problem of an ideal "Universal Intermediate Representation" for all languages, so that only one backend is needed per platform, has been extensively studied for probably 30 years and I do believe the conclusion so far is: it's not possible.
I highly doubt that Microsoft has beat out academia in this regard.
As for your other statement regarding various languages and their supported paradigms, I would like to clarify something:
C, Basic, Pascal, Fortran, and Cobol are not regarded as functional nor object-oriented languages. I highly recommend you consult the definitions of said terms. In addition, I would not count the following as object-oriented languages, in an ideal world: C++ and Java, due to their mostly static (and pain-in-the-ass) nature.
(Hint: functional language means higher order functions and closures)
Well someone has corrected my old impression of CLISP, it seems to have shaped up in recent times. So it is ANSI-compliant with -ansi option, modulo bugs.
I only found the DrScheme IDE to be annoying. Emacs w/ILISP is better, certainly the commercial IDEs are. And just because they're not free doesn't mean they don't exist.
As for CLISP, I think it used to not support CHANGE-CLASS (which is in ANSI). But you are right, even without -ansi option it seems to support it in recent CVS, at least.
CLISP is a fairly well-established implementation but due to some reason I cannot fathom, the implementors choose not to be fully ANSI-compliant. You won't notice it at first, but if you get into advanced object-system hacking CLISP will become unsuitable. Also, it's a byte-code interpreter system. This severely affects performance (except in bignums, due to some numerical methods magic), but it does have a smaller memory footprint. And it's widely ported.
CMUCL does purport to be a complete ANSI-conforming implementation, and it has a high-performance native-code compiler. But it's not ported very much (some ports have gone unmaintained) and only to Unixy systems. The current maintainers are interested mostly in features and speed, whereas...
SBCL is a fork of CMUCL, with the goal of being more easily maintained, cleaner, and conforming. It's also more widely ported now, having resurrected some of the old CMUCL ports and added some new ones (someone is working on OS X now). SBCL has been adding features back that were dropped, sometimes improving, for example, kernel-threads recently (vs user-threads in CMUCL).
Lately they've been driving the development of each other, since many patches can be cross-ported easily. This is all the better for the users:-).
I use CMUCL for most of my work, which involves database-driven web-app development, and it works fine. Though I am thinking about switching to SBCL soon, with nice features like kernel-threads coming around. Well, presumably I would be able to use either. I use libraries like AllegroServe (HTTP server), UncommonSQL (RDBMS OO interface), and IMHO (web apps w/Apache).
Neither work on Windows (yet) so there you would need to look into Allegro, LispWorks, or Corman Lisp (which I forgot to list in the previous post). All these are native compilers that can produce Windows applications. There are no free compilers for Windows which produce native code, afaik. You can investigate GCL or ECLS, which compile to C and may work under mingw. The commercial compilers all have GUI toolkits or bindings to the Windows API. Allegro is probably out of your price range, LispWorks is ~$900 and Corman is ~$150. All have free personal editions to play with.
Why do I say Scheme isn't as practical? Well, most Scheme implementations aren't anywhere near the same quality as the CL ones (with a few notable exceptions) and they all have to implement incompatible supersets of the language (because R5RS defines approximately nothing). Personally I think the design of Scheme itself works against practical usage and implementation, but there are those who disagree. In universities they teach Scheme, but as I was saying, as an academic exercise and not something to be used in industry. Which is a real shame.
Anyway, if you want a learning environment, I recommend the LispWorks personal edition IDE (Linux, Windows, Unix, and soon OS X). This will get you started with a minimum of fuss. Later on, you can setup Emacs with the ILISP package and interface with your CL implementation; this is a popular way. Or you may find some other IDE. The minimum needed really is parenthesis-matching and auto-indentation. After that you might like interactive features such as shortcuts to compile code-fragments, documentation at a keystroke, easy access to a Lisp listener, inspector, debugger, etc.
There are many books, such as Paul Graham's ANSI Common Lisp, Peter Norvig's Paradigms of AI Programming, online tutorial Successful Lisp, and sites such as CLiki with lots of pointers to resources.
I've been using Common Lisp for 3 years, and this is how I see it:
Common Lisp is actually a relatively new language. It draws on older languages such as MACLISP, ZetaLisp, Scheme, and ALGOL, certainly, but it breaks away from each of them. Unlike every Lisp before, it takes lexical scoping (by default) from Scheme. But it retains a separate namespace for variables, functions, etc, unlike Scheme. It uses function names drawn from MACLISP but hammers down the semantics of interpretation and compilation (in MACLISP these could be very different).
The language design was originally coordinated by Guy Steele, and from that the ANSI standard was created. This took the better part of a decade. The intent of the language was to be practical and to resolve problems that existed, so implementations did arise and follow the ongoing standardization. But it still took a long time for them to become mature and settle down. I cannot speak from personal experience, but it does seem that in the mid-90s the quality/quantity of the available compilers was not at all near what we have today. Particularly the free ones.
Nowadays there are four high-quality commercial implementations that I can think of right away (Allegro, LispWorks, Scieneer, MCL), three high-quality free implementations (CMUCL, SBCL, OpenMCL) and three up-and-coming or partially-compliant (CLISP, GCL, ECLS).
Every day it seems that there is more and more progress. I think that what happened is there was a lull over the past ten years and now things are starting to speed up once again.
But why was there a lull at all? It's hard to say exactly, and I wasn't personally involved in it, but what I have read has led me to see the problem as one of poor business decisions and a drop in confidence. Many eggs were placed in the Lisp Machine basket (many CL ones too) and when those failed in the marketplace (in the late 80s/early 90s) it took a lot with it. The LispM failure was probably due to two factors: (1) Overblown expectations of AI falling over, and (2) Too far ahead of its time to be financially feasible. The LispMs were very interesting machines and environments but they were far too expensive to be able to compete against Unixes, even if they had more features and better design. (The Unix Hater's Handbook enshrines the feelings of those people forced to move from LispMs and Genera, among other systems, to Unix).
In the meantime, there was the "Free Unix"es which grew up in the early 90s and helped to push out most of the remaining non-Unix systems. Only Microsoft, with its budget, managed to survive; and Macintosh on its hardware platform. Perl and Python grew up in the Unix environment, and given the current lock Unix has, it is no surprise that these languages are widely used. They also marketed themselves as "scripting languages" to fit in under the radar of C and C++ programmers, whereas Common Lisp was built to be an industrial-strength application (or even system) programming language. Anyone who knows Lisp also knows that it makes for it's own "scripting language" very easily, though.
Common Lisp didn't grow up in the Unix environment (not solely, anyway), and Lisp users had different ideas of what an OS should be. So there was an conceptual mismatch between the two that really hasn't been fully resolved. These days, there are many people (like me) who learned on Unix/C and then picked up Lisp. So there is more and more a trend to play well with Unix. The commercial Lisps are ahead in this game because they need to be in order to survive.
I wouldn't say that CL is so much difficult as it is different. This is probably another reason why it didn't catch on in ths Unix world as much. Universities did, in many cases, chug out students who were exposed to Lisp (or very often Scheme, which is different). The trouble is, many inculcated their students with the concept that Lisp is a language for theoretical AI work rather than practical programming. Actually, many high-level langu
..to anyone who has ever used a Lisp Machine, Forth Machine, Smalltalk system, or any one of the other dynamic, interactive programming language environments.
The Hotdog compiler for Scheme does not support full continuations on the.NET and JVM backends, because these VMs are just too brain-dead to be able to do it sanely (ie. control over the stack). Without that, it's not really Scheme.
As for Lisp, I would love to see an implementation of multi-dispatch methods and method combination on.NET and JVM. Can you imagine adding the condition system restarts, too?
(Yes, Lisp and Scheme are very different. Time to start reading if you don't believe me.)
JVM and.NET were designed for crappy languages with little expressivity, such as Java and C#, not for the more powerful languages such as Common Lisp or even Scheme.
Slashdot Mirror
1. Truly object oriented systems.
2. Persistant Virtual Memory.
3. Presentation types.
Those are just off the top of my head. You can go do some research yourself, instead of being lazy, now.
OS improvement has plateaued precisely because of people thinking it has. In fact, there have been plenty of innovations in the past that have been by-passed by the industry and forgotten. That alone indicates that there is a great amount room for improvement. Looking at the major Operating Systems of our time--Windows, Linux, Unix, and Mac OSX--it is quite clear that there are many unsolved problems.
Why, every day, we see new exploits and bugs? And why do users feel constrained and lost in the morass we call a UI? Where is the fully verified, theorem-prover-checked, OS code? Where is the OS built on high level language concepts? Where is the OS that actually thinks of data as objects rather than octets?
"The theory that underlies Operating Systems"...pfooey...I would like to see real Operating Systems actually try to take a formal approach towards the problem, instead of the kludged up hacks that are currently used.
As for nonsensical metaphors:
The Michaelson-Morley experiments were a greatly flawed attempt to prove the existence of the aether. And the negative results were most certainly not taken as evidence of the incorrectness of the physics of the time.
Special relativity derives wholy from two axioms, in addition to basic geometry and mathematics:
1) That the laws of physics are the same in all inertial frames of reference.
2) That one of the laws of physics is: the speed of light is always a constant, in a vacuum.
From this, everything else is fairly trivial.
The Michaelson-Morley experiments could be taken as evidence towards axiom (2), but most certainly do not constitute proof.
The most significant contribution towards special relativity not provided by Einstein was probably due to Lorentz.
The primary problem with Emacs is Emacs Lisp. You can find many instances of people suggesting to Stallman over the years that he should switch to Common Lisp, the budding standard. Others suggested Scheme. Either would've been a better choice.
Emacs Lisp is a throwback to MACLISP, from the 70s. It is not a well designed language, and has an almost C-like essence to it which flies in the face of Lisp. For example, typing (expt 2 32) into Emacs gives you 0, as if you typed it into a C program. That's supposed to be 2^32 = 4294967296, and all proper Lisps will give you the correct answer. Common Lisp is very smart about numerical operations, even automatically choosing the best representation for a number object.
One of the choices that will surprise an inexperienced programmer is the use of so-called "dynamic scope" for variables. This sort of thing died out in Lisps after the mid-80s but still remains in Emacs to this day. "Dynamic scope" while useful in some instances, is generally not held to be a good default for variable scope because it breaks referential transparency. Common Lisp offers the ability to designate a local variable as "special" (dynamic scope) if you wish that behavior, otherwise it defaults to the normal lexical (static) scope. "Dynamic scope" had some popularity in the past due to it being extremely easy to implement in an interpreter, in fact it originated out of a mistake made in the "original LISP" eval function.
And, in general, Emacs Lisp doesn't have any of the advanced functionality of Common Lisp at all. So in terms of writing applications, Emacs Lisp can be a pain. The reason given by Stallman for not using Common Lisp? "Too big". The ironic part is that Emacs ended up attempting to reproduce the functionality of Common Lisp (see the package named CL) but in a half-assed way. Much like many other large programs.
Clearly the implementations of FSF and X Emacs are very simple, almost just a wrapper over C. And the GC sucks.
With all its flaws, Emacs is still one of the best editors available. I'm just pointing out ways it could have been better. The Genera editor (Zmacs), was related to early Emacsen, was fully integrated with the Operating System, and programmable in ZetaLisp. The CMUCL project has an emacs-like editor written for it, named Hemlock, which has been resurrected recently. The LispWorks editor is supposedly based on Hemlock, I do not know for sure. McCLIM has an editor pane, which could possibly evolve into a full blown editor with advanced capabilities.
What did Emacs get right? It's fully customizable, and it is a great IDE for Emacs Lisp, with online help, cross referencing, and all. That's probably why there are so many packages for it. And keybindings, regexps, etc, are fairly irrelevant, since it's all customizable anyway.
Perhaps. But it would require an awful lot of work because Ruby does not really have the infrastructure for this sort of dynamic programmable environment. It is not something that simply materializes out of an OOP language. Looking at McCLIM source code, you'll see that it's a lot of work just to map graphical figures to objects. And Ruby doesn't have a condition system, s-expressions, or a real implementation.
I find it difficult to take any language seriously if it does not have a standardized definition and high performance compilers. Usually the former leads to the latter. Both mean that there is a group of people who care significantly about the language.
Maybe we should close the patent office, since everything's been invented.
There were a number of Object Oriented systems written on top of Lisp; because Lisp allowed such flexibility in the language.
.com name registered: symbolics.com. There is hope that someday all the thousands of man-hours of work on Genera will become unencumbered or re-released.
Genera, unless I'm mistaken, was based on Zetalisp (LispMachine Lisp) with an object system named "Flavors", a message-passing system with mix-ins loosely based on Smalltalk. The GUI was written with this system, and the GUI itself was interesting because its introspective abilities closely mirrored that of the underlying language. The elements of the GUI were all objects that could be manipulated, selected, inspected. Even graphical and text output on the screen could be categorized into classes and later manipulated as objects. This became the basis for CLIM (Common Lisp Interface Manager).
Unfortunately this style of GUI has fallen to the wayside in favor of the simpler but stupider Windows-style one. C and C++ do not have the flexibility that is required, in any case, for a dynamic GUI like that on the Lisp Machine. Look to Smalltalk, Squeak, Slate, or the reinvigorated CLIM projects (McCLIM, FreeCLIM) instead.
Symbolics made bad business decisions, indeed. They still do exist, and even have the oldest
Stallman helped popularize Emacs, along with the free software movement, which developed in parallel with the similar editors of the Lisp machines. The problem with Stallman is that he is incredibly stubborn (no kidding), and made mistakes early on that he was unwilling to fix. Hence FSF Emacs and even XEmacs is crippled as an editor, a language, and a platform, though people who only make simple use of it might not understand why.
It is just as well that Lisp languished in FSF, because it sprouted elsewhere in the open source community, with no philosophical encumbrances which don't necessarily make sense in a dynamic environment like a Lisp.
Over the last five years, I've seen quite a revival of Lisp. The regular programming crowd slowly accepts new ideas; they still insist on making the same mistakes that were already passed by Lisp programmers years ago. Ah well. My job is working on systems in Common Lisp, I am happy.
Not sure why you keep harping on functional programming. Lisp at the time was hardly a functional programming language. It HAD functions, yes, but was nothing like ML or Scheme. At the time, I suppose, that was something amazing and advanced.
If you look at code from that era, it is often startling different from code you would see today from Lisp programmers. The influence of Scheme on modern Common Lisp is undeniable.
The fact is, Emacs is an echo from the Lisp machine era. Those who understand Emacs, understand at least to a small extent why the Lisp machines were so powerful. And Emacs is not unpopular.
How fast is the speed of light at that speed? :-P
A quick calculation shows that to gain 1 day out of 90, you would have to be travelling ~15% of the speed of light. At that rate, you could travel to Mars and back within a day.
I use Subversion at work with a large (half-gig) source tree, and primarily on Windows (with TortoiseSVN). We use the new FSFS backend. Seems to do quite well, even on a networked filesystem.
You want Darcs. http://abridgegame.org/darcs/.
.. hack hack ..
.. interactive questions about changes ..
Using it is as simple as:
darcs init <dir>
darcs add <file>
darcs record
Then you have the option of sending your changes to other repositories, since Darcs is distributed.
You can copy/upload them directly, pull them from the other side, or even email them.
[OT (and I know you are trolling) but]:
No, you completely misinterpreted my statement. I said that people who do exist now should have priority on decisions regarding their own personal life over people who do not exist now but might at some future time. Old folks quite clearly fit into the former category.
Otherwise, why not ban pregnant women (or even women of child bearing age) from spending money, eating certain foods, crossing streets, taking risks etc... simply because it might endanger a future child!
Why should we allow you to impose your values on the United States of America?
> You mean murder? Not everybody against murdering fetuses is against it for religious reasons.
Yes, there are a few people who genuinely care about the life of the infant, as opposed to caring about their need to spread the religion. My counter-argument to this is that the life of people who already exist and have worked hard to establish themselves takes priority over the unknown. (And if they haven't worked hard, then how are they going to support the child?) Think pragmatically, not at moral extremes.
As for gambling, while there are several examples of crime-ridden gambling areas, there's a few problems with establishing laws based on this observation: (a) statistical correlation and causation: did gambling actually directly cause it? (b) can the crime be eliminated while keeping the casinos? (c) people want the casinos anyway, check out the debate going on between PA, MD, WV, and DE residents about losing gambling dollars to each other. There was a recent article you can probably find it online. More and more areas are allowing casinos and I think you will find that not all of them become crime-ridden like Atlantic City (which has plenty of other reasons to be crime-ridden). And anyway, what does this have to do with online casinos? Online casinos solve the location problem pretty easily, don't you think?
As I hinted, without built-in support for higher-order functions and closures, a language cannot be considered to be `functional', because you would essentially have to implement these features yourself in your program (and most likely need to work around the limitations of that language also).
Does attending a university make me an academic? I don't think so---I also work, and understand the practical viewpoint of a coder; I just don't see it as adequate justification for throwing away the dictionary. As it is, `functional programming' is also supposed to mean `no side effects' but that has now been relegated to `pure functional programming'.
Personally, I backed away from the pure FP stance a long time ago, but I still think that higher-order functions and closures can be an extremely useful tool for any programmer and they can easily be mixed into other paradigms (just look at Smalltalk and Common Lisp).
Many languages run on existing hardware, but can they easily call each others' functions and share each others' objects/data? I understand that CLR attempts to make this work, but that is a very hard problem when the languages in question have a large conceptual mismatch.
I don't know why the OP mentioned Lisp macros, because they certainly have nothing to do with the backend of a Lisp compiler. However, problems still do exist with compiling to IL, mostly focusing around calling-conventions and potential limitations instituted by the CLR.
For example, Common Lisp has advanced object-oriented features such as multiple-dispatch methods and method combination, and this would most have a large conceptual mismatch with the typical calling conventions used by languages in IL, hence the CL compiler would need to use its own calling conventions and would be incompatible with other languages (thus defeating the point of IL).
Same goes for memory layout, stack management, etc... all due to Common Lisp's advanced data types and capabilities such as multiple-inheritance, CHANGE-CLASS, resumable conditions...
As far as I know, all real Common Lisp compilers that support Windows have not yet made any serious steps towards adding an IL backend, since there is very little benefit to be gained until those issues can somehow be worked out. Franz, in particular, put out a list of roadblocks a few years ago, but I do not know what became of it.
Scheme, on the other hand, has call/cc which requires heap-allocated stacks. This has been a sticking point with Scheme on JVM; the Schemes there simply do not support the full call/cc as a result. JVM is very limited with what the call-stack can do, for "security" reasons. I imagine CLR has similar issues, unless someone clever found a way around it.
In general, the problem of an ideal "Universal Intermediate Representation" for all languages, so that only one backend is needed per platform, has been extensively studied for probably 30 years and I do believe the conclusion so far is: it's not possible.
I highly doubt that Microsoft has beat out academia in this regard.
As for your other statement regarding various languages and their supported paradigms, I would like to clarify something:
C, Basic, Pascal, Fortran, and Cobol are not regarded as functional nor object-oriented languages. I highly recommend you consult the definitions of said terms. In addition, I would not count the following as object-oriented languages, in an ideal world: C++ and Java, due to their mostly static (and pain-in-the-ass) nature.
(Hint: functional language means higher order functions and closures)
Well someone has corrected my old impression of CLISP, it seems to have shaped up in recent times. So it is ANSI-compliant with -ansi option, modulo bugs.
I only found the DrScheme IDE to be annoying. Emacs w/ILISP is better, certainly the commercial IDEs are. And just because they're not free doesn't mean they don't exist.
As for CLISP, I think it used to not support CHANGE-CLASS (which is in ANSI). But you are right, even without -ansi option it seems to support it in recent CVS, at least.
CLISP is a fairly well-established implementation but due to some reason I cannot fathom, the implementors choose not to be fully ANSI-compliant. You won't notice it at first, but if you get into advanced object-system hacking CLISP will become unsuitable. Also, it's a byte-code interpreter system. This severely affects performance (except in bignums, due to some numerical methods magic), but it does have a smaller memory footprint. And it's widely ported.
:-).
CMUCL does purport to be a complete ANSI-conforming implementation, and it has a high-performance native-code compiler. But it's not ported very much (some ports have gone unmaintained) and only to Unixy systems. The current maintainers are interested mostly in features and speed, whereas...
SBCL is a fork of CMUCL, with the goal of being more easily maintained, cleaner, and conforming. It's also more widely ported now, having resurrected some of the old CMUCL ports and added some new ones (someone is working on OS X now). SBCL has been adding features back that were dropped, sometimes improving, for example, kernel-threads recently (vs user-threads in CMUCL).
Lately they've been driving the development of each other, since many patches can be cross-ported easily. This is all the better for the users
I use CMUCL for most of my work, which involves database-driven web-app development, and it works fine. Though I am thinking about switching to SBCL soon, with nice features like kernel-threads coming around. Well, presumably I would be able to use either. I use libraries like AllegroServe (HTTP server), UncommonSQL (RDBMS OO interface), and IMHO (web apps w/Apache).
Neither work on Windows (yet) so there you would need to look into Allegro, LispWorks, or Corman Lisp (which I forgot to list in the previous post). All these are native compilers that can produce Windows applications. There are no free compilers for Windows which produce native code, afaik. You can investigate GCL or ECLS, which compile to C and may work under mingw. The commercial compilers all have GUI toolkits or bindings to the Windows API. Allegro is probably out of your price range, LispWorks is ~$900 and Corman is ~$150. All have free personal editions to play with.
Why do I say Scheme isn't as practical? Well, most Scheme implementations aren't anywhere near the same quality as the CL ones (with a few notable exceptions) and they all have to implement incompatible supersets of the language (because R5RS defines approximately nothing). Personally I think the design of Scheme itself works against practical usage and implementation, but there are those who disagree. In universities they teach Scheme, but as I was saying, as an academic exercise and not something to be used in industry. Which is a real shame.
Anyway, if you want a learning environment, I recommend the LispWorks personal edition IDE (Linux, Windows, Unix, and soon OS X). This will get you started with a minimum of fuss. Later on, you can setup Emacs with the ILISP package and interface with your CL implementation; this is a popular way. Or you may find some other IDE. The minimum needed really is parenthesis-matching and auto-indentation. After that you might like interactive features such as shortcuts to compile code-fragments, documentation at a keystroke, easy access to a Lisp listener, inspector, debugger, etc.
There are many books, such as Paul Graham's ANSI Common Lisp, Peter Norvig's Paradigms of AI Programming, online tutorial Successful Lisp, and sites such as CLiki with lots of pointers to resources.
CMUCL
SBCL
LispWorks
Corman Lisp
I've been using Common Lisp for 3 years, and this is how I see it:
Common Lisp is actually a relatively new language. It draws on older languages such as MACLISP, ZetaLisp, Scheme, and ALGOL, certainly, but it breaks away from each of them. Unlike every Lisp before, it takes lexical scoping (by default) from Scheme. But it retains a separate namespace for variables, functions, etc, unlike Scheme. It uses function names drawn from MACLISP but hammers down the semantics of interpretation and compilation (in MACLISP these could be very different).
The language design was originally coordinated by Guy Steele, and from that the ANSI standard was created. This took the better part of a decade. The intent of the language was to be practical and to resolve problems that existed, so implementations did arise and follow the ongoing standardization. But it still took a long time for them to become mature and settle down. I cannot speak from personal experience, but it does seem that in the mid-90s the quality/quantity of the available compilers was not at all near what we have today. Particularly the free ones.
Nowadays there are four high-quality commercial implementations that I can think of right away (Allegro, LispWorks, Scieneer, MCL), three high-quality free implementations (CMUCL, SBCL, OpenMCL) and three up-and-coming or partially-compliant (CLISP, GCL, ECLS).
Every day it seems that there is more and more progress. I think that what happened is there was a lull over the past ten years and now things are starting to speed up once again.
But why was there a lull at all? It's hard to say exactly, and I wasn't personally involved in it, but what I have read has led me to see the problem as one of poor business decisions and a drop in confidence. Many eggs were placed in the Lisp Machine basket (many CL ones too) and when those failed in the marketplace (in the late 80s/early 90s) it took a lot with it. The LispM failure was probably due to two factors: (1) Overblown expectations of AI falling over, and (2) Too far ahead of its time to be financially feasible. The LispMs were very interesting machines and environments but they were far too expensive to be able to compete against Unixes, even if they had more features and better design. (The Unix Hater's Handbook enshrines the feelings of those people forced to move from LispMs and Genera, among other systems, to Unix).
In the meantime, there was the "Free Unix"es which grew up in the early 90s and helped to push out most of the remaining non-Unix systems. Only Microsoft, with its budget, managed to survive; and Macintosh on its hardware platform. Perl and Python grew up in the Unix environment, and given the current lock Unix has, it is no surprise that these languages are widely used. They also marketed themselves as "scripting languages" to fit in under the radar of C and C++ programmers, whereas Common Lisp was built to be an industrial-strength application (or even system) programming language. Anyone who knows Lisp also knows that it makes for it's own "scripting language" very easily, though.
Common Lisp didn't grow up in the Unix environment (not solely, anyway), and Lisp users had different ideas of what an OS should be. So there was an conceptual mismatch between the two that really hasn't been fully resolved. These days, there are many people (like me) who learned on Unix/C and then picked up Lisp. So there is more and more a trend to play well with Unix. The commercial Lisps are ahead in this game because they need to be in order to survive.
I wouldn't say that CL is so much difficult as it is different. This is probably another reason why it didn't catch on in ths Unix world as much. Universities did, in many cases, chug out students who were exposed to Lisp (or very often Scheme, which is different). The trouble is, many inculcated their students with the concept that Lisp is a language for theoretical AI work rather than practical programming. Actually, many high-level langu
Matt's Script archive is well-known among Perl programmers as one of the densest collections of hole-ridden crappy code on the net.
Second only to CPAN, I suppose.
I think this post should win the Pullet Surprise.
..to anyone who has ever used a Lisp Machine, Forth Machine, Smalltalk system, or any one of the other dynamic, interactive programming language environments.
Here's a useful link:
No-Kernel systems.
You're wrong in both respects.
.NET and JVM backends, because these VMs are just too brain-dead to be able to do it sanely (ie. control over the stack). Without that, it's not really Scheme.
.NET and JVM. Can you imagine adding the condition system restarts, too?
.NET were designed for crappy languages with little expressivity, such as Java and C#, not for the more powerful languages such as Common Lisp or even Scheme.
The Hotdog compiler for Scheme does not support full continuations on the
As for Lisp, I would love to see an implementation of multi-dispatch methods and method combination on
(Yes, Lisp and Scheme are very different. Time to start reading if you don't believe me.)
JVM and