From what I understand, currently the problem with forming game start-ups isn't with finding capital or producing the product (god knows there's enough amateurs out there), but with the publishing end. Even established firms with hit titles (for example Troika, and I'm sure there are others that I don't follow) have trouble negotiating agreeable publishing agreements. Just look at the squeeze Vivendi tried to put on Valve over Steam. Big publishers have retailers locked down when it comes to distribution (read David Sheff's Game Over for an account of how Nintendo used to strong-arm stores in the late 80s/early 90s, something that eventually earned them an antitrust lawsuit). Distributing games over the Internet isn't yet feasible (maybe Steam will change that, but it does have it's downsides). And of course this is talking about the PC market only - if you're developing for the consoles, you have to shell out big bucks for development kits, pay a hefty sum on each game sold to the console maker, and be subject to major distribution restrictions (more than one Gamecube game has been sacked after Nintendo deemed it too violent). There was hope a few years ago that Internet and cell-phone minigames would bring about a sort of developer's Renaissance, but so far it seems the margins and the markets are too small and there is too much competition for any real success stories.
It's not as bleak as it sounds though. There is at least one mom and pop game developer that's been successful making and selling games independently over the Internet for a number of years. Maybe some more operations can follow their formula successfuly.
I think the real problem is with people who can't be bothered to search the web for 5 minutes before opening their mouth to demonstrate their ignorance, because guess what? You know all those people who designed Common Lisp? Well, many of them went on to design a nice, clean infix Lisp, 10 years ago. Anyone who knows about Dylan and still complains about Lisp's syntax is just trolling.
We all use vonNeuman [sic] architecture machines these days. The machines which separated data and code were called "Harverd [sic] Architecture" and were abandoned long ago.
Not quite. All modern processors have separate instruction and data caches. Although x86 still allows you to cross the boundary, this is done at considerable expense because of the cache misses. The difference in access patterns between code and data are such that the Harvard Architecture is actually a very big win in performance.
The problem with the examples you listed is that you're confusing representation and evaluation. While bytecodes and text strings are data representing programs, they aren't actually programs themselves - the VM/interpreter is. Translate your representation to machine code, stuff it in memory, and there is your code.
Performance reasons aside, the stuff going on now with non-executable stacks and pages and whatnot with x86 is pretty stupid. Most people don't notice because most apps are programmed in C (which is the cause for all of these measures in the first place!), but when you need to do non-trivial things with stack manipulation and code generation this gets in the way (it also doesn't work very nice memory-wise on the x86 because you either get 4kb or obscenely humongous 2meg pages with nothing inbetween).
Anybody who has been in an American public high school in the past two decades has become thoroughly familiar with the "fill-in-the-bubbles" Scantron multiple-choice sheets. Almost all schools own scanning machines. The forms themselves are inexpensive to print, and more importantly, they are already readily produced and available in great quantities. They are easy to use, completely straightforward, can be counted rapidly and very reliably, and leave a verifiable paper trail. So why not leverage existing public infrastructure and experience for a reliable automated~ voting method?
~ - Not to suggest that counting the votes by hand is perfectly adequate, but while the politicians are out to waste money, they might as well waste it well.
PS - an even simpler solution to tied results would of course be to get rid of the two party system and electoral voting crap and go with a parliamentary system like Canada's, but everyone knows they're a bunch of no-good commies.
The funny thing is I can't tell whether you're trolling (in which case you certainly got a laugh out of me!) or just contributing to the examples of really shitty code (in which case congratulations; I think you've won, and this was no easy task (I still can't believe some of the code posted elsewhere in the thread is actually real)).
Their driver itself may not be opensource but they have excellent driver and developer support under Linux and BSD, and the graphics card market is so cutthroat that if they were to divulge driver secrets, it would be suicide.
Linux and FreeBSD (not just any generic BSD variant!!) aren't the only two Free Software operating systems out there. The whole point of Free Software is that you can change and fork and develop new software that's useful to somebody. If it won't work with PC video cards, it's not useful or feasible for many people. Nvidia can claim to be Linux or FreeBSD "friendly" if they release drivers for the systems, but until they release Free Software drivers they are not making a particularly meaningful contribution to any Free Software system. The "driver secrets" is a widely held but totally unproven assumption on the part of Nvidia apologists. It's not unreasonable to ask that a standard interface be created to the video card, with the proprietary parts residing in the card's flash firmware, distributed as a binary with drivers (many wireless modems do exactly this). I know Nvidia back-ports some software features to older cards in their drivers (for example the TNT2 has limited OpenGL overlay support with newer drivers), but this only concerns legacy products. Another issue entirely is exactly how useful (or not) the source code for Nvidia's drivers will actually be to Nvidia's competition for undermining them (I imagine if it were, certain unscrupulous manufacturers would already be taking advantage by reverse-engineering the binaries, but I haven't seen any evidence of this actually happening).
Lets face it, life is really only a "good time" until you graduate college and gave to get a day job that sucks the life out of you just like everyone else. After that you're just a working stiff mindlessly going about your day exhausted, stressed, and boring.
That's only because everyone wants shiny things and is afraid of getting old. The ski bums I know are only ever afraid of getting too old to ski (and I've known some pretty old ski bums). Currently, somewhat less than 3% of the US population produces 3 times as much food as the US population can consume, and efficiency in shelter could be comparable if everyone weren't so busy erecting McMansion barns. It's not unrealistic to expect that more people would adopt a nomadic tradesman lifestyle if they weren't afraid of having nothing to retire on (hell, some people even manage to make a pretty good living that way already). The only problem would be all those damn RVs clogging the roads...
I was at a talk given by Jeremy Hall today, and he mentioned that the Suncor oil sands processing facilities are the single largest consumers of energy in Canada. When you factor in Syncrude and Shell's Albian venture, that adds up to a lot of pollution. He mentioned that the demand is so great that the government is considering building a nuclear reactor just for those sites (with waste to be dumped somewhere is Saskatchewan:)).
When the available technology converges at a certain performance threshold... consumers begin to base their choices on nontechnical considerations.
Yeah, and here I was thinking that consumers always base their consumption choices on rational decisions reached by deep introspective thinking. Face it, even when products have differing technical specifications (and how much do they differ really if those products are being sold to the same market?) the preference for some characteristics over others is almost always influenced by non-rational factors. This is especially so when the purchaser goes out of their way to claim a rational basis to justify the puchase. How do you think acquisitions committees really work?
Whoa, is this way off topic or what? But on to crash the party:
"Structure is nothing if it is all you've got. Skeletons spook people if they try to walk around on their own; I really wonder why XML does not." Erik Naggum (who did a lot of work on SGML)
XML may be fine as a markup language, but it doesn't solve anything relating to interoperability because it doesn't specify anything about the schema you should use. Whoop-de-do, XML made parsing a little easier. It still won't help things much because different companies, different applications, and different revisions of applications will have different XML schema. There is no solution for the interoperability problem, there are only ways to make it easier. XML is one such way. Don't overhype it lest it die from dashed expectations.
He ended up teaching computer graphics theory classes that have been discontinued at the university simply because there is no faculty member that is qualified to take his spot and teach the same subject.
Oh, the irony! Is no one else qualified to teach the course because they don't know the material, or, like the professor, because they have no formal qualifications?
If the 1993 WTC bombing would have went off as planned, we'd be blaming Clinton for the terrorism, and indeed he should be blamed for not taking enough action after the events to prevent future terror acts on the US. However, Bush should not be let go without blame, because his administration took an incredible number of stupid and counter-productive reactions to the terrorist threat, that from the current vantage point have not significantly diminished the risk of future attacks (but only history will actually show whether this will be true). In regards to the economy, I agree that Bush has no excuse - all the measures undertaken by his administration were done with full knowledge of their ultimately counter-productive results with the expectations that they would bring the appearance of short-term improvement, which in most cases did not even come about. He's screwed the US economy for decades to come.
Re:The language does not always matter
on
Quake2 Engine In Java
·
· Score: 2, Insightful
There is one thing that bothers me with Java though. You never know when the garbage collection will be performed.
Here's a hint: it happens after you've allocated too much memory. Even if you are so deprived that you can't even turn the garbage collector on and off, if you don't allocate in your inner loop, the garbage collector won't kick in! Who would have thought? In Java allocation is very easy to control (a big reason for this has to do with it's separation of built-in types and classes), and as long as you take care not allocate yourself and be aware which library functions do, you are fine. As well, you can always use object pools to safely do manual allocation/deallocation. Any half-decent VM will allow you to tweak the garbage collector at run-time, providing a functional interface for forcing full or partial collections, changing the amount of memory allocated before triggering collection, or even turning the collector on and off.
The thing to remember from all this is that the garbage collector doesn't work in a vacuum, and cannot be blamed for poor performance per se. You application and the garbage collector together form a system about which you can draw conclusions on performance. A well-written application can give hard real-time performance with a naive garbage collector, but any number of stupid things you can do while writing a program can bring even the best garbage collector to it's knees. (A fun thing to try in systems that support it - try re-defining a class to be it's own superclass. Makes a great practical joke!).
If you wanna impress me with how fast Java is, show me the Quake2 software renderer in Java, and compare *that* to the c++ version.
All fine and good, except for the fact that the Quake 2 software renderer was written in a mixture of C and assembly. Actually, I don't think any part of Quake 2 was written in C++.
What really bothers me is how rarely (if ever) a Java or C# program will release memory back to the system. It seems that they just take more and more resources away from the system and never release it back.
I suppose next you're going to complain that they mmap too much memory when they start up. The fact is this is done to get the best performance out of the VM systems of modern OSs. The vast majority of garbage-collected runtimes do not release memory given by the OS based on the very safe assumption that that memory will soon be re-used in a garbage collection/allocation cycle. Interacting with the VM system is generally expensive nowadays, so they simply avoid it - managing your own memory in your own address space is magnitudes faster. There's no reason that a compacting/releasing operation couldn't be built into the memory management runtime, and it is in many systems (for example, this is present in all the runtimes that can dump memory images). If/when your hypothetical scenario does start to become a problem, then I imagine that such an operation will be incorporated into the multi-process Java VMs (if it's not already there).
Even though mathematicians like to claim that all their proofs are "formal," there's really no such thing. The amount of background lemmas, axioms and facts needed to prove even elementary mathematical statements is so large that even 1st year maths students use arguments based on abstractions, previous results, and plain old assumptions ("it's trivial to see that..." is a favourite statement). As BrotherZeoff has recommended, take a look at GEB - you'll see pretty quickly that even the most obvious of facts takes pages to prove in a formal logic system. This is why it so frequently happens that proofs are rejected after peer review - the author neglected the validity of some lemma or made assumptions that were incorrect, and he missed them in proof-reading or their consequences didn't even occur to him. The amount of background knowledge needed to machine-verify this particular proof is immense, and would take many times longer to represent than it would for a committee of expert mathematicians to peer-review the proof (and as others pointed out, you'd need to verify that no mistakes in representing that knowledge were made!). Even though you can generate the knowledge from the axioms of topology, that would be akin to generating the proof, and as you pointed out this is far from feasible (it's basically a giant tree search - there's really no shortcut for these things). I guess someone could try to build a mathematical (or at least topological) version of Cyc - a giant ruleset of relevant mathematical theorems. But if even you could find enough mathematicians (and money to pay them) to do this, chances are it still wouldn't contain all the lemmas needed to prove this or that particular theorem.
However, this does bring an interesting idea to mind - a wikipedia-like, distributed theorem database and prover. Anyone can add theorems and their proofs to it, like wikipedia, which would be verified by distributed clients, like SETI, and then added to the database as lemmas for future proofs. If you start with enough true theorems, new ones can be accumulated pretty quickly, while the fact that all of it follows formal logic means that no false facts can ever be added (although the possibility for DOS attacks is pretty significant).
Actually, This is the original Space Cadet keyboard, and it makes the Symbolics one look like a Speak and Spell (even the whole damn APL character set is there!). They're both descended from Tom Knight's original "Knight" keyboard for MIT-AI's ITS system. I periodically wonder how much it would cost to do a small production run of a Space Cadet replica (the demand is there if the price is reasonable).
And for that matter, get rid of Caps Lock too. Those keys have really overstayed their welcome. And use some of those 29 extra keys as modifiers. It's time the impoverished Linux users discovered the joys of "Hyper" and "Super."
Since when is the PC games market shrinking? For whom? Is the half-million or so copies (already at more than 300,000) Doom 3 will sell make up for the 23% year to date drop? Who's counting the numbers, anyway? I know that a lot of PC gamers are playing independently published games, mostly because of lack of original games from big publishers (time is limited, and the indie games are by and large not very good either). I know Jeff Vogel says he sells about 20 to 30 thousands copies of each of Spiderweb's games, despite piracy (the games are downloaded in their entirety and then use an activation key to be unlocked - cracks are abundant).
Of course, the telling evidence of Starforce's carpetbaggery is the following quote (highlights mine):
"
We havent done any official studies, other than know for a fact we have protected many titles this year alone that are still not cracked. It is up to the developer to put forth as much effort as it takes to install a great protection and the payoff is obvious. I dont have any specific numbers to share, but economic advantages can be significant. Let me give an example..."
This looks to me to be the same arguments used by TV ad salesmen in the bad old days of Nielsen ratings, with one difference: at least the Nielsen people tried to make up numbers. The Starforce strategy seems to be to provide some alternative-universe scenario that may or may not occur in real life, and leave the rest as being "obvious." They don't even try to stereotype gamer demographics. There is absolutely no evidence for the success of their products (go to Megagames and check out how many Starforce-protected products have been cracked), and the above quote from the horse's mouth makes that pretty clear. This is the same scare tactic used by Macrovision and other copy protection businesses, and a reason why I have absolutely no respect for them. Pointing to BSA piracy numbers and yelling loudly isn't going to show their products work - they need to do their own damn effectiveness studies, but they're afraid of the results.
After the RISC non-revolution, it seems that everyone's forgotten that microprogramming is a really old concept. For an insightful read, try to find Ashok and Rauscher's Foundations of Microprogramming (New York : Academic Press, 1976). I did a few months ago, and it's pretty eye opening. You can see where the RISC ideas came from: the book discusses everything up from instruction decode strategies, to the issues posed by caches and pipelines, and even touches on instruction level parallelism! This really puts modern processor engineering in perspective, better than Hennesy and Patterson or for that matter any modern chip textbooks do.
It would be nice to see a breakdown of exactly how many transistors are spent where on Pentium IVs - I suspect (and have read as much) that most of the silicon space is used up in the parallel ALUs and the FPU, so the instruction decode logic is relatively small. What I'd really like to see though, is how Transmeta's processors handle the decoding and execution, and why their approach isn't microprogramming (everyone claims this but I've yet to hear an explanation).
Moderators, although I suggest that you take Eivind Eklund's advice into account, I can provide you with a shortcut to knowledge. Anyone who claims that proto[type]-based "object structures" (whatever those are) are "memory-efficient" is full of shit. I don't like to repeat myself, so I've dug up a past Slashdot post of mine (Slashdot makes this really hard to do - I think I would have saved time by re-stating my argument here) detailing the data requirements of an object in a prototype-based object system vs. an object in a traditional class-instance object system.
I still stand by Anthony Burgess' use of the term "cacotopia," originally coined by Jeremy Bentham and an inspiration for JS Mill's "dystopia." I find it both more concise and evocative than "negative utopia."
As I was saying, you may not like the way Java provides dynamic features, but it does provide lots of dynamic features.
Maybe read was a poor example. External representations aside, eval has nothing to do with interactivity or dynamic features, but everything to do with being able to construct and then execute programs with the regular abstract data structures and operators of the language, without any regard for it's implementation.
As for "the" Smalltalk approach, there is no such thing. The original Smalltalk used a stack-based bytecode interpreter, recent versions of Smalltalk (and Self) are using the same JIT approach as Java.
Well, you yourself just stated that the relationship between the generated code and the bytecode is one-to-one. JIT is nothing more than another way to interpret the intermediate code. The point I was trying to make was that Smalltalk was the first system to specify a common, platform-neutral binary representation for program and data and an interpretation mechanism for that representation.
I don't know of any Lisp system using a high-performnce JIT (other than those based on the JVM or CLR, of course), and I think that's a major problem with Lisp.
What's the point? To be popular? Cross-platform? High performance? Persistence? Lisp won't be any more popular if there's a bytecode JIT implementation. C is currently the most portable language available, so the cross-platform argument doesn't hold much water (especially considering that the CLR is controlled by Microsoft). Many Common Lisp implementations (Allegro, CMUCL, SBCL) come with native-code compilers that can match or beat G++, so going the JIT way will only be a penalty to performance. Neither Java nor.NET take advantage of the persistence possibilities of a VM like Smalltalk does, but most Common Lisp implementations can already dump a non-portable memory image executable.
There were several Lisp dialects based on virtual machines in the 70s and 80s, the most prominent being Lisp/370 from IBM and Interlisp. Both used the capabilities provided by the VM quite heavily (Lisp/370 for performance (there's a paper on the subject in the proceedings of the Lisp conference 80 or 82), Interlisp for most everything, especially the exploitation of the sphaghetti stack for control structures). Lisp/370 died for commercial reasons, but Interlisp lived well into the early 90s. It may have been that the system wasn't particularly well structured or architected (which is perfectly excusable considering that Interlisp continually evolved as a single system since the mid 60s), but Interlisp was not easy to port or high performance. The Orbit T compiler showed that source code transformations could produce a more portable, efficient compiler than the alternatives - it was written by four or five undergraduates over the course of two summers, but it was faster than many commercial implementations using either the traditional native-code or VM approaches. Starting with Lucid's Common Lisp, pretty much all the commercial and non-commercial Lisp systems have used the same approach. JIT may alleviate some of the performance penalties for using a VM, but as I've pointed out, there are other disadvantages to tying a language down to interpretation strategies.
Java's choice of "binary postfix program representation after canonicalization" instead of Lisp's "weakly parsed uncanonicalized symbols-plus-lists" seems to be a winning combination: manipulating code at that level is slightly less intuitive, but it avoids many of the complexities and limitations of Lisp code walkers. As a result, people have been able to implement things in bullet proof was in Java that ended up being at best flaky using code walkers.
The problem with doing manipulations at the intermediate representation is that the transformation between the high and mid-lev
Both Java and C# have full dynamic code generation... Lisp's dynamic code generation... [is] more limited.
This is BS. Neither Java nor C# have the equivalents of read, eval, compile, or even change-class as language primitives.
Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language. The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. It is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode. The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines. Guy Steele added 3 primitive constructs to the specification of Common Lisp to make Connection Machine Lisp, and those ideas are still the best approach for implementing an efficient data-driven parallel language.
Slashdot Mirror
It's not as bleak as it sounds though. There is at least one mom and pop game developer that's been successful making and selling games independently over the Internet for a number of years. Maybe some more operations can follow their formula successfuly.
I think the real problem is with people who can't be bothered to search the web for 5 minutes before opening their mouth to demonstrate their ignorance, because guess what? You know all those people who designed Common Lisp? Well, many of them went on to design a nice, clean infix Lisp, 10 years ago. Anyone who knows about Dylan and still complains about Lisp's syntax is just trolling.
The problem with the examples you listed is that you're confusing representation and evaluation. While bytecodes and text strings are data representing programs, they aren't actually programs themselves - the VM/interpreter is. Translate your representation to machine code, stuff it in memory, and there is your code.
Performance reasons aside, the stuff going on now with non-executable stacks and pages and whatnot with x86 is pretty stupid. Most people don't notice because most apps are programmed in C (which is the cause for all of these measures in the first place!), but when you need to do non-trivial things with stack manipulation and code generation this gets in the way (it also doesn't work very nice memory-wise on the x86 because you either get 4kb or obscenely humongous 2meg pages with nothing inbetween).
~ - Not to suggest that counting the votes by hand is perfectly adequate, but while the politicians are out to waste money, they might as well waste it well.
PS - an even simpler solution to tied results would of course be to get rid of the two party system and electoral voting crap and go with a parliamentary system like Canada's, but everyone knows they're a bunch of no-good commies.
The funny thing is I can't tell whether you're trolling (in which case you certainly got a laugh out of me!) or just contributing to the examples of really shitty code (in which case congratulations; I think you've won, and this was no easy task (I still can't believe some of the code posted elsewhere in the thread is actually real)).
I was at a talk given by Jeremy Hall today, and he mentioned that the Suncor oil sands processing facilities are the single largest consumers of energy in Canada. When you factor in Syncrude and Shell's Albian venture, that adds up to a lot of pollution. He mentioned that the demand is so great that the government is considering building a nuclear reactor just for those sites (with waste to be dumped somewhere is Saskatchewan :)).
"Structure is nothing if it is all you've got. Skeletons spook people if they try to walk around on their own; I really wonder why XML does not." Erik Naggum (who did a lot of work on SGML)
XML may be fine as a markup language, but it doesn't solve anything relating to interoperability because it doesn't specify anything about the schema you should use. Whoop-de-do, XML made parsing a little easier. It still won't help things much because different companies, different applications, and different revisions of applications will have different XML schema. There is no solution for the interoperability problem, there are only ways to make it easier. XML is one such way. Don't overhype it lest it die from dashed expectations.
If the 1993 WTC bombing would have went off as planned, we'd be blaming Clinton for the terrorism, and indeed he should be blamed for not taking enough action after the events to prevent future terror acts on the US. However, Bush should not be let go without blame, because his administration took an incredible number of stupid and counter-productive reactions to the terrorist threat, that from the current vantage point have not significantly diminished the risk of future attacks (but only history will actually show whether this will be true). In regards to the economy, I agree that Bush has no excuse - all the measures undertaken by his administration were done with full knowledge of their ultimately counter-productive results with the expectations that they would bring the appearance of short-term improvement, which in most cases did not even come about. He's screwed the US economy for decades to come.
The thing to remember from all this is that the garbage collector doesn't work in a vacuum, and cannot be blamed for poor performance per se. You application and the garbage collector together form a system about which you can draw conclusions on performance. A well-written application can give hard real-time performance with a naive garbage collector, but any number of stupid things you can do while writing a program can bring even the best garbage collector to it's knees. (A fun thing to try in systems that support it - try re-defining a class to be it's own superclass. Makes a great practical joke!).
However, this does bring an interesting idea to mind - a wikipedia-like, distributed theorem database and prover. Anyone can add theorems and their proofs to it, like wikipedia, which would be verified by distributed clients, like SETI, and then added to the database as lemmas for future proofs. If you start with enough true theorems, new ones can be accumulated pretty quickly, while the fact that all of it follows formal logic means that no false facts can ever be added (although the possibility for DOS attacks is pretty significant).
Actually, This is the original Space Cadet keyboard, and it makes the Symbolics one look like a Speak and Spell (even the whole damn APL character set is there!). They're both descended from Tom Knight's original "Knight" keyboard for MIT-AI's ITS system. I periodically wonder how much it would cost to do a small production run of a Space Cadet replica (the demand is there if the price is reasonable).
And for that matter, get rid of Caps Lock too. Those keys have really overstayed their welcome. And use some of those 29 extra keys as modifiers. It's time the impoverished Linux users discovered the joys of "Hyper" and "Super."
Of course, the telling evidence of Starforce's carpetbaggery is the following quote (highlights mine):
This looks to me to be the same arguments used by TV ad salesmen in the bad old days of Nielsen ratings, with one difference: at least the Nielsen people tried to make up numbers. The Starforce strategy seems to be to provide some alternative-universe scenario that may or may not occur in real life, and leave the rest as being "obvious." They don't even try to stereotype gamer demographics. There is absolutely no evidence for the success of their products (go to Megagames and check out how many Starforce-protected products have been cracked), and the above quote from the horse's mouth makes that pretty clear. This is the same scare tactic used by Macrovision and other copy protection businesses, and a reason why I have absolutely no respect for them. Pointing to BSA piracy numbers and yelling loudly isn't going to show their products work - they need to do their own damn effectiveness studies, but they're afraid of the results.It would be nice to see a breakdown of exactly how many transistors are spent where on Pentium IVs - I suspect (and have read as much) that most of the silicon space is used up in the parallel ALUs and the FPU, so the instruction decode logic is relatively small. What I'd really like to see though, is how Transmeta's processors handle the decoding and execution, and why their approach isn't microprogramming (everyone claims this but I've yet to hear an explanation).
Moderators, although I suggest that you take Eivind Eklund's advice into account, I can provide you with a shortcut to knowledge. Anyone who claims that proto[type]-based "object structures" (whatever those are) are "memory-efficient" is full of shit. I don't like to repeat myself, so I've dug up a past Slashdot post of mine (Slashdot makes this really hard to do - I think I would have saved time by re-stating my argument here) detailing the data requirements of an object in a prototype-based object system vs. an object in a traditional class-instance object system.
I still stand by Anthony Burgess' use of the term "cacotopia," originally coined by Jeremy Bentham and an inspiration for JS Mill's "dystopia." I find it both more concise and evocative than "negative utopia."
Maybe read was a poor example. External representations aside, eval has nothing to do with interactivity or dynamic features, but everything to do with being able to construct and then execute programs with the regular abstract data structures and operators of the language, without any regard for it's implementation.
Well, you yourself just stated that the relationship between the generated code and the bytecode is one-to-one. JIT is nothing more than another way to interpret the intermediate code. The point I was trying to make was that Smalltalk was the first system to specify a common, platform-neutral binary representation for program and data and an interpretation mechanism for that representation.
What's the point? To be popular? Cross-platform? High performance? Persistence? Lisp won't be any more popular if there's a bytecode JIT implementation. C is currently the most portable language available, so the cross-platform argument doesn't hold much water (especially considering that the CLR is controlled by Microsoft). Many Common Lisp implementations (Allegro, CMUCL, SBCL) come with native-code compilers that can match or beat G++, so going the JIT way will only be a penalty to performance. Neither Java nor .NET take advantage of the persistence possibilities of a VM like Smalltalk does, but most Common Lisp implementations can already dump a non-portable memory image executable.
There were several Lisp dialects based on virtual machines in the 70s and 80s, the most prominent being Lisp/370 from IBM and Interlisp. Both used the capabilities provided by the VM quite heavily (Lisp/370 for performance (there's a paper on the subject in the proceedings of the Lisp conference 80 or 82), Interlisp for most everything, especially the exploitation of the sphaghetti stack for control structures). Lisp/370 died for commercial reasons, but Interlisp lived well into the early 90s. It may have been that the system wasn't particularly well structured or architected (which is perfectly excusable considering that Interlisp continually evolved as a single system since the mid 60s), but Interlisp was not easy to port or high performance. The Orbit T compiler showed that source code transformations could produce a more portable, efficient compiler than the alternatives - it was written by four or five undergraduates over the course of two summers, but it was faster than many commercial implementations using either the traditional native-code or VM approaches. Starting with Lucid's Common Lisp, pretty much all the commercial and non-commercial Lisp systems have used the same approach. JIT may alleviate some of the performance penalties for using a VM, but as I've pointed out, there are other disadvantages to tying a language down to interpretation strategies.
The problem with doing manipulations at the intermediate representation is that the transformation between the high and mid-lev
Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language. The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. It is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode. The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines. Guy Steele added 3 primitive constructs to the specification of Common Lisp to make Connection Machine Lisp, and those ideas are still the best approach for implementing an efficient data-driven parallel language.