What Google has faile to consider is whether structured languages such as XML will be able to lower the barrier to entry for search applications. XML is deliberately designed to simplify search by adding structure.
You do realize that XML isn't going to help anything when it comes to full-text searches, don't you? This was actually the great promise of SGML some decades ago, which actually (unlike XML) at least had the SGML user groups attempt to make some useful standards instead of BS "meta-markup." It didn't pan out very well (structured information retrieval in general has very limited applications compared to full-text searches).
Google already exploits structured data much better than XML can in the form of hyperlinks (XML's biggest failing - not providing some kind of standard for linking non-hierarchical documents). The reason they're not paying much attention to XML is exactly because they have "highly intelligent people" working there. Chances are pretty good that the whole XML bandwagon will fall apart (much like SGML) before any significant percentage of those documents that do benefit from structure (which is an insignificant amount compared to plain written text) are converted to XML. Then again, because XML is structured, it is not very difficult to add support for it on relatively short notice. You also have to consider that most data that benefits from structure is probably in the form of financial transactions and such, which are private and already have adequate search systems designed for them.
Exactly. The reason I mentioned that is that an awful lot of people seem to think that dynamic programming languages can't be compiled to native code (actually, the biggest confusion seems to surround dynamic linking). I think this is because the majority of dynamic/scripting languages are just written as interpreters/bytecode compilers for portability.
Or earlier in the articale; also related to doing arithmetic without a number datatype... Logically, you don't need to have a separate notion of numbers, because you can represent them as lists: the integer n could be represented as a list of n elements. You can do math this way. It's just unbearably inefficient.
Again he's describing Rexx, except that it is far from being unbearably inefficient.
He's describing Gregory Chaitin's demonstrations of Lisp as an elegant mathematical computer language (I highly recommend Chaitin's books). Believe it or not, numbers as true linked lists are unbrearably inefficient. But that also means you only need maybe 6 or 7 constructs to have a truly elegant Turing-compatible language.
I believe that programs should read like novels; there should be long paragraphs of text that describe what and how the code is working followed by short bursts of actual 'dialog' that is the actual source instruction to the computer.
Donald Knuth came up with a system like this in the late 70s, calling it "Literate Programming". Aside from him, I have never actually seen it used by anybody.
Not to start a language religion war, but this is probably the biggest disservice one can do to Lisp, considering the historical reasons behind Mathematica's development. I wasn't there and I don't know how it happened, but on this Usenet thread some people who were recount Wolfram's reasons for writing (what would later become) Mathematica (and also portray his infamous ego).
It's funny you mention that Mathematica feels like Lisp, since it was at one point widely considered to be the ultimate example of Greenspun's Tenth Rule of Programming. Of course by now everyone's forgotten about Macsyma, and Mathematica is pretty well ironed out. The commercial version of Macsyma was supposed to be a bit better in some respects than Mathematica while it was in development, but it hasn't been available for several years. You can download Maxima, a GPL branch of the original DOE Macsyma sources. Unfortunatly, it uses GCL (I think) on Windows, which is painfully slow. On Unix you can use CMUCL, where arrays with type declarations (I think Maxima uses nested lists for matrices as well unless you tell it not to) can produce native code as good as GCC's (not to mention it's a better Lisp system than GCL overall).
Getting in on the Negative Utopia vs. Dystopia debate, I think a much better term for the concept of the former (I didn't realize the latter was co-opted by science fiction) would be cacotopia. I first saw it in Burgess' 1985, where I think he claims to have made it up (I don't have a copy on hand, so I might be totally wrong, but if he did it's an entirely logical word to come up with). He likewise disliked dystopia for some connotation it had, but I forget the exact reason.
According to Wikipedia it was actually coined by John Stuart Mill's associate Jeremy Bentham. Anybody with access to the OED care to provide further details (it would be particularly interesting to see whether cacotopia inspired the coinage of dystopia or vice-versa)?
but I've been wondering for a few months now, is Sheldon Pacotti (the author of the article) a Scientologist? I've noticed that in several interviews (and in a couple of 'about the writer' sidelines) it's been mentioned that his novel, Demiurge, received a place in some sort of L. Ron Hubbard Writers of the Future Contest.
"The Jobs visit had been infuriating enough, he says. He'd been out of town at the time, which was regrettable, "because if I'd been in town, I would have told him [Jobs] to get out. And if he hadn't, I would have beat the shit out of him. I had no respect for him. Then they [Xerox] would have fired me - and it would have been good for me and for them.""
From an interview with Bob Taylor (who used to be director of the Computer Science Lab at PARC) in W. Mitchell Waldrop's _The Dream Machine_. The exchange happened when Jobs "allowed" (the book makes it sound like this was a privilige) Xerox to buy $1.05 million of Apple stock in a private (Apple hand't gone public yet) stock sale, for which he would get unlimited access to research at PARC.
Actually, Apple had been planning the Lisa over a year before Job's visit, bit-mapped screen and mouse included. The Apple people mainly wanted to look at Smalltalk (too bad Jobs didn't "steal" that). They weren't particularly impressed with the laser printer or ethernet (Jobs was supposed to have hated networks with a passion).
The quote above was probably largely motivated by the (realized) fear that the microcomputer manufacturers would bastardize the idea of personal computing (the general view seems to have been that they were bright ignoramuses who completely ignored what the rest of the computer community was doing).
and it's not as good an idea as you think. What it does is unfairly penalize dynamic programs (Lisp, Java, and several others (including believe it or not Ada)) in favor of supporting a broken programming paradigm from the 70s. Von Neumann left out the distinction between data and instructions in his EDVAC report for a good reason - the two are the same.
Specifically, on the architectures that support it, OpenBSD enforces write or execute permissions on memory. It is still entirely possible to run self-modyfying and dynamic programs, but now every time you need to perform either write or execute you must speficially make a call to switch that memory's permissions. Needless to say, this is not the end-all security solution, and ultimately ends up breaking a lot of things.
I think this goes way beyond just program correctness as a means of security (what used to be OpenBSD's stated goal), and is on the whole a bad thing. A much more sensible approach is to run untrusted applications in their own VMs, and write as much software as possible in languages that can guarantee correctness (this pretty much only means languages that automagically manage memory - C programs using Boehm's conservative GC and safe string functions and such fit this bill).
First of all, thanks for taking the time to respond to a Slashdot post. Not many authors of papers featured here do the same =]. I must also apologize for the "not reading the paper bit" - that was largely intended at some of the more misinformed posts here on/.
When I was talking about late-bound VMs, it was largely the ideal case VM, in which all the functions and data are nicely boxed and type-checking is done at every reference. This is of course not the case, especially for Common Lisp (but from what I know of the original Smalltalk VMs and Squeak they come pretty close to the ideal - if you know someone who knows Smalltalk, it would be interesting to see how well this attack will work against the latter).
Strictly speaking, there is really no Common Lisp implementation entirely contained inside a VM (mostly for speed reasons, but Clisp does come close - it's memory footprint is less than 2mb, and I think it also makes a good candidate to see how well this exploit works against late-bound VMs). Most implementations are native-code compilers - so this exploit certainly applies here, especially since the compilers inline heavily and will make use of optional type specifiers and inference.
Besides the reliance on native code by the VM and the inlining, I think there are two areas where this exploit might work. First is the way dynamic type information is encoded. I don't think anyone uses a whole extra word for that anymore. There are two popular strategies, one being the BIBOP (Big Bag of Pages) scheme, where certain pages are reserved for specific types, and the other is to encode the type information in the upper bits of a word (Clisp does this), and I've heard that the two are used in together in some combination. Second, conservative GCs make passes fairly often - I suspect there may be a small chance to exploit the garbage collector.
So it is entirely possible to exploit late-binding VMs with your method of attack, but I am guessing the success rate will be much lower. This may depend on how much external code is used and other factors (it would be interesting to see how well Python stands up compared to the JVM). This is really starting to pique my curiosity. Maybe if I have some time this summer I will perform a similar experiment on one of the CL systems.
But technically this isn't an attack on all sand-box virtual machines, just the early-binding ones like the JVM, which assume a program is safe to run after a single check at compile/link time. Late-bound (or dynamically typed) VM-based languages such as Smalltalk and Lisp aren't as vulnereable to this - only the memory allocation and other atomic system functions that are assumed "safe" are vulnereable, and typically there are only a couple of dozen of these (and a random cooking of which is very likely to crash the VM or the machine by their nature). Of course, randomly messing with the memory will cause program errors and undesired results, and compilers that do a lot of inlining and type assumption optimizations increase the risk.
Just because the ideas that surpassed Unix haven't become popular, doesn't mean that they are not there, or weren't even there when Unix was still 'young.'
You bring up the idea that the CLI hasn't improved or been integrated with the GUI, but you completely ignore Emacs and the UI development that has gone on in Smalltalk and Lisp systems. A particularly striking example are the constraints-based GUIs - Ivan Sutherland first had this idea all the way back in his Sketchpad paper, and there have been multiple UI systems built afterwards on the principle (and I know of a new one that is being built right now), yet when was the last time you've even heard of constraints?
I find it depressing that all the wonderful techniques developed aren't being utilized, and some users think that because the systems they work with are based on 30 and 20 (even 20 years ago the X approach was considered a poor man's window system) year old paradigms there isn't anything else out there.
More impressive still were the character models on display, which, although unfinished, bore more than a passing resemblance to the colorful, stylized units of Warcraft III: Reign of Chaos.
Ignoring the startingly strange opinion that half-done art with an "inspired" style (if you don't have lawyers, this is called "copyright theft") is "impressive," I as a fan of LOTR must take objection to to the "colorful, stylized" part. There are other, much more subtle ways to differentiate small units in a strategy game.
Now, to my original thought:
[WOTR] isn't being designed as a hard-core real-time strategy game, but... as an RTS that will be accessible and fun... fans of [LOTR] who might never have played a strategy game before... Liquid Entertainment
hopes to incorporate a variable difficulty level.. in which the strength of the enemy will be automatically determined by how well you are doing... how quickly you are managing to build units.
I think it is a monumental task to dumb down what today constitutes an RTS, but Liquid Entertainment is trying. God help us all - this game can't help but sell well, and whatever features it has are sure to be copied by future RTS clones. There go the last elements of strategy - don't worry if you can't even amass a tank rush, the game dumbs itself down! Of course, you have to consider that this thinking is implying that 'tank rushes' constitute strategy and are difficult to do. This is the reason why I switched to turn-based after Myth II.
Actually, if you go back to the good old days of 1998, you'll realize that the RTS bandwagon effect was at it's first peak right about then, and that this is only the second coming. Microsoft's AOE rode in pretty much on the tail end of the peak.
Now you may ask yourself, why did the trend suddenly decline for a few years? Remember such classic titles as Earth 2027, KKND, KKND expansions pack, Earth 2227 (or whatever), KKND 2, KKND 2 expansion pack, and of course C&C Red Alert: expansion packs 1, 2 and 3 (is there a fourth one I'm missing?)? I believe the phrase "C&C clone" first became popular during this time, and for good reason. Most of these games sucked and sold poorly.
Now the great cycle of life continues: the investors who got burned on the first crop have largely gone some other way, and Warcraft III (what the hell does AOE have to do with 'recently'?) is one of the top-selling games in recent memory, proving once again that if you're Blizzard, you can get away with making incremental changes to your games, slapping on a roman numeral on the box, and still make millions. Of course, to game publishers this means leeching season (never mind that most of the clone titles are guaranteed to flop miserably - they're investors! they take risks without thinking!).
Also, why exactly can't you reveal who your employer is? Do they chain you to the radiator and beat you for talking to strangers? Or do you use your exotic on-line identity to post internal memos on Fatbabies? In any which case, you could have at least posted anonymously.
Python will eventually get an optimizing native code compiler? It has many more useful constructs than does Java/C++ (anonymous functions (although I do hear they are somewhat neutered due to the expressions/statement dichotomy, but that can always (maybe it already has?) change), lexical scoping for those anonymous functions, continuations (for lightweight processes), and of course the might interactive REPL).
Will Pythoners suddenly jump from being "scripters" to "programmers", or are those priviliges reserved for the people that were brutalized by their Pascal/C/C++ education and think that freeing your own memory is some kind of sick initiation ritual?
Or how about Erlang? Or any other language that includes abstractions beyond classes (look mah! we're object-oriented! we don't have multiple inheritance or a real type system!).
As has been pointed out in other posts, the whole field of IT is more fickle than the fashion industry when it comes to choosing technologies, and particularly anything related to development. Sure, use Java because your boss said it's popular and everyone knows it and Sun says so etc. And when you come bitching on Slashdot about how your project can always find Java developers in the future, remember that you're part of the problem. Of course you're not going to find any programmers in language X when you're not offering jobs in language X.
The entire industry needs to place a higher priority on building trustworthy systems, even though this means building systems that have fewer features and that take longer to deploy because of increased development times.
So now we're supposed to waste our time fiddling our thumbs about broken trust and rights "management" crap? This is the same stunt MS pulled by claiming Windows met "Orange Book" (from the NSA Rainbow Series of books) "security" standards. Of course, Access Control Lists don't do much if your OS is full of buffer overflows and similar exploits, and this is ignoring the issue that ACLs don't do much at all and don't do it very well anyway. This seems like an overly expensive way of distracting customers from the real security issues (ha! like that one-month code review jerk-off session really accomplished anything).
I can see only two benefits coming from this. Likely the grants those professors are receiving from MS will trickle down to some poor, hungry grad students who actually deserve it. Also, if the quote above has any relevance to MS's own development plans (but I'm not holding my breath), maybe people forced to use MS software will have to suffer through less feature bloat and mandatory-upgrade new versions.
Scroll down a bit and you'll find a link to another article the guy wrote, about the "the benefits of using XML-RPC and SOAP" (emphasis mine). For god's sake, even if the CGI article wasn't a promotion for his company, anyone who thinks that XML-RPC and SOAP has any kind of benefits really can't be taken too seriously.
10 to 15 different languages? They can't even get an exact number, much less say what they are (and how closely they're related).
At the very least, they didn't even bother looking at Common Lisp - Franz took a look at the CLR several years ago and decided that it wasn't even worth the trouble. It is impractical to get CLOS (the Common Lisp Object System - multiple dispatch, multiple inheritance, generic functions, and completely dynamic (you can re-define a class at runtime, and all the instances, and subclasses, etc. will be converted according to either a default or user specified method the next time they are accessed)) implemented with any sort of efficiency. Closures and dynamically generated lambdas (anonymous functions that capture a lexical environment and plain vanilla anonymous functions, created at runtime, respectively) seem to present a similar sort of problem from what I know of the CLR (I understand that they'd have to be represented as objects, please correct me if I'm wrong).
I've heard other similar objections to the inadequacy of the CLR when it comes to dynamics languages, and overall I'm not terribly impressed with what Microsoft is doing or how it is going about it (the seemingly primary reason why.Net has/will have Scheme implementations from both Northwestern and PLT is because of rather large grants).
Same question I had, and particularly relevant since the giant infomercial (giant in number of pages vs. page length (somewhere around 5 to 1), only) promised to explain the term, but never did. It was also massively uninformative, scant of details, explanations, and relevant background information. I don't know a lot about anime, and this mess of an article didn't do anything to help that.
Not to flame, but the guy said he was processing hundreds of megabytes of scientific data. Depending on the structure of the data (likely it is either very simple or very complicated), regular expressions aren't the right tool for the job - if it's just reading in a bunch of vectors, RE's would add significant overhead. If the structure is complex, REs will likely get more complicated than they're worth, simply because expressing complicated structures in terms of recursion and iteration is much faster and simpler, and REs don't do either very well. And of course if the data is in a binary format, then the whole point is moot.
Now when it comes to scientific visualization, vector formats aren't exactly all the rage. Neither is XML, since those files tend to be rather large and there tend to be a lot of them - no one wants to waste bandwidth and space on closing tags.
That's how Squeak works - it's a fully dynamic, standalone Smalltalk VM. There were (and still are) quite a few standalone Smalltalk compilers that will let you build more traditional interfaces or interface with windowing toolkits.
that most of this code will be in rule-sets, which really don't qualify as part of the program but as a part of the program's data. Of course, as another poster pointed out, today it is pretty obvious that knowledge and rule-based style AI is only good for expert-systems style intelligence, largely due to the limitations of first order logic. Self-organizing agent based systems and neural networks seem to be the next approach to making a more useful, general-purpose AI, but those largely consist of dynamically created entities, and their code size can sometimes be surprisingly small. Of course, there is a limitation to those two, so if I can pull some speculation out of my ass (this seems to be a pretty safe thing to do when talking about AI), the two approaches of knowledge-based and agent-based systems will have to be combined to make something truly useful. Now, as to how (if) that's going to be achieved reliably and usefully is a whole other story.
Slashdot Mirror
You do realize that XML isn't going to help anything when it comes to full-text searches, don't you? This was actually the great promise of SGML some decades ago, which actually (unlike XML) at least had the SGML user groups attempt to make some useful standards instead of BS "meta-markup." It didn't pan out very well (structured information retrieval in general has very limited applications compared to full-text searches).
Google already exploits structured data much better than XML can in the form of hyperlinks (XML's biggest failing - not providing some kind of standard for linking non-hierarchical documents). The reason they're not paying much attention to XML is exactly because they have "highly intelligent people" working there. Chances are pretty good that the whole XML bandwagon will fall apart (much like SGML) before any significant percentage of those documents that do benefit from structure (which is an insignificant amount compared to plain written text) are converted to XML. Then again, because XML is structured, it is not very difficult to add support for it on relatively short notice. You also have to consider that most data that benefits from structure is probably in the form of financial transactions and such, which are private and already have adequate search systems designed for them.
Exactly. The reason I mentioned that is that an awful lot of people seem to think that dynamic programming languages can't be compiled to native code (actually, the biggest confusion seems to surround dynamic linking). I think this is because the majority of dynamic/scripting languages are just written as interpreters/bytecode compilers for portability.
He's describing Gregory Chaitin's demonstrations of Lisp as an elegant mathematical computer language (I highly recommend Chaitin's books). Believe it or not, numbers as true linked lists are unbrearably inefficient. But that also means you only need maybe 6 or 7 constructs to have a truly elegant Turing-compatible language.
Donald Knuth came up with a system like this in the late 70s, calling it "Literate Programming". Aside from him, I have never actually seen it used by anybody.
In most Common Lisp implementations, this is commonly done by the optimising, inlining native code compiler.
Not to start a language religion war, but this is probably the biggest disservice one can do to Lisp, considering the historical reasons behind Mathematica's development. I wasn't there and I don't know how it happened, but on this Usenet thread some people who were recount Wolfram's reasons for writing (what would later become) Mathematica (and also portray his infamous ego).
It's funny you mention that Mathematica feels like Lisp, since it was at one point widely considered to be the ultimate example of Greenspun's Tenth Rule of Programming. Of course by now everyone's forgotten about Macsyma, and Mathematica is pretty well ironed out. The commercial version of Macsyma was supposed to be a bit better in some respects than Mathematica while it was in development, but it hasn't been available for several years. You can download Maxima, a GPL branch of the original DOE Macsyma sources. Unfortunatly, it uses GCL (I think) on Windows, which is painfully slow. On Unix you can use CMUCL, where arrays with type declarations (I think Maxima uses nested lists for matrices as well unless you tell it not to) can produce native code as good as GCC's (not to mention it's a better Lisp system than GCL overall).
According to Wikipedia it was actually coined by John Stuart Mill's associate Jeremy Bentham. Anybody with access to the OED care to provide further details (it would be particularly interesting to see whether cacotopia inspired the coinage of dystopia or vice-versa)?
but I've been wondering for a few months now, is Sheldon Pacotti (the author of the article) a Scientologist? I've noticed that in several interviews (and in a couple of 'about the writer' sidelines) it's been mentioned that his novel, Demiurge, received a place in some sort of L. Ron Hubbard Writers of the Future Contest.
Actually, Apple had been planning the Lisa over a year before Job's visit, bit-mapped screen and mouse included. The Apple people mainly wanted to look at Smalltalk (too bad Jobs didn't "steal" that). They weren't particularly impressed with the laser printer or ethernet (Jobs was supposed to have hated networks with a passion).
The quote above was probably largely motivated by the (realized) fear that the microcomputer manufacturers would bastardize the idea of personal computing (the general view seems to have been that they were bright ignoramuses who completely ignored what the rest of the computer community was doing).
Specifically, on the architectures that support it, OpenBSD enforces write or execute permissions on memory. It is still entirely possible to run self-modyfying and dynamic programs, but now every time you need to perform either write or execute you must speficially make a call to switch that memory's permissions. Needless to say, this is not the end-all security solution, and ultimately ends up breaking a lot of things.
I think this goes way beyond just program correctness as a means of security (what used to be OpenBSD's stated goal), and is on the whole a bad thing. A much more sensible approach is to run untrusted applications in their own VMs, and write as much software as possible in languages that can guarantee correctness (this pretty much only means languages that automagically manage memory - C programs using Boehm's conservative GC and safe string functions and such fit this bill).
slave labor for the state that brought you Enron.
When I was talking about late-bound VMs, it was largely the ideal case VM, in which all the functions and data are nicely boxed and type-checking is done at every reference. This is of course not the case, especially for Common Lisp (but from what I know of the original Smalltalk VMs and Squeak they come pretty close to the ideal - if you know someone who knows Smalltalk, it would be interesting to see how well this attack will work against the latter).
Strictly speaking, there is really no Common Lisp implementation entirely contained inside a VM (mostly for speed reasons, but Clisp does come close - it's memory footprint is less than 2mb, and I think it also makes a good candidate to see how well this exploit works against late-bound VMs). Most implementations are native-code compilers - so this exploit certainly applies here, especially since the compilers inline heavily and will make use of optional type specifiers and inference.
Besides the reliance on native code by the VM and the inlining, I think there are two areas where this exploit might work. First is the way dynamic type information is encoded. I don't think anyone uses a whole extra word for that anymore. There are two popular strategies, one being the BIBOP (Big Bag of Pages) scheme, where certain pages are reserved for specific types, and the other is to encode the type information in the upper bits of a word (Clisp does this), and I've heard that the two are used in together in some combination. Second, conservative GCs make passes fairly often - I suspect there may be a small chance to exploit the garbage collector.
So it is entirely possible to exploit late-binding VMs with your method of attack, but I am guessing the success rate will be much lower. This may depend on how much external code is used and other factors (it would be interesting to see how well Python stands up compared to the JVM). This is really starting to pique my curiosity. Maybe if I have some time this summer I will perform a similar experiment on one of the CL systems.
But technically this isn't an attack on all sand-box virtual machines, just the early-binding ones like the JVM, which assume a program is safe to run after a single check at compile/link time. Late-bound (or dynamically typed) VM-based languages such as Smalltalk and Lisp aren't as vulnereable to this - only the memory allocation and other atomic system functions that are assumed "safe" are vulnereable, and typically there are only a couple of dozen of these (and a random cooking of which is very likely to crash the VM or the machine by their nature). Of course, randomly messing with the memory will cause program errors and undesired results, and compilers that do a lot of inlining and type assumption optimizations increase the risk.
You bring up the idea that the CLI hasn't improved or been integrated with the GUI, but you completely ignore Emacs and the UI development that has gone on in Smalltalk and Lisp systems. A particularly striking example are the constraints-based GUIs - Ivan Sutherland first had this idea all the way back in his Sketchpad paper, and there have been multiple UI systems built afterwards on the principle (and I know of a new one that is being built right now), yet when was the last time you've even heard of constraints?
I find it depressing that all the wonderful techniques developed aren't being utilized, and some users think that because the systems they work with are based on 30 and 20 (even 20 years ago the X approach was considered a poor man's window system) year old paradigms there isn't anything else out there.
Now, to my original thought:
I think it is a monumental task to dumb down what today constitutes an RTS, but Liquid Entertainment is trying. God help us all - this game can't help but sell well, and whatever features it has are sure to be copied by future RTS clones. There go the last elements of strategy - don't worry if you can't even amass a tank rush, the game dumbs itself down! Of course, you have to consider that this thinking is implying that 'tank rushes' constitute strategy and are difficult to do. This is the reason why I switched to turn-based after Myth II.Now you may ask yourself, why did the trend suddenly decline for a few years? Remember such classic titles as Earth 2027, KKND, KKND expansions pack, Earth 2227 (or whatever), KKND 2, KKND 2 expansion pack, and of course C&C Red Alert: expansion packs 1, 2 and 3 (is there a fourth one I'm missing?)? I believe the phrase "C&C clone" first became popular during this time, and for good reason. Most of these games sucked and sold poorly.
Now the great cycle of life continues: the investors who got burned on the first crop have largely gone some other way, and Warcraft III (what the hell does AOE have to do with 'recently'?) is one of the top-selling games in recent memory, proving once again that if you're Blizzard, you can get away with making incremental changes to your games, slapping on a roman numeral on the box, and still make millions. Of course, to game publishers this means leeching season (never mind that most of the clone titles are guaranteed to flop miserably - they're investors! they take risks without thinking!).
Also, why exactly can't you reveal who your employer is? Do they chain you to the radiator and beat you for talking to strangers? Or do you use your exotic on-line identity to post internal memos on Fatbabies? In any which case, you could have at least posted anonymously.
Will Pythoners suddenly jump from being "scripters" to "programmers", or are those priviliges reserved for the people that were brutalized by their Pascal/C/C++ education and think that freeing your own memory is some kind of sick initiation ritual?
Or how about Erlang? Or any other language that includes abstractions beyond classes (look mah! we're object-oriented! we don't have multiple inheritance or a real type system!).
As has been pointed out in other posts, the whole field of IT is more fickle than the fashion industry when it comes to choosing technologies, and particularly anything related to development. Sure, use Java because your boss said it's popular and everyone knows it and Sun says so etc. And when you come bitching on Slashdot about how your project can always find Java developers in the future, remember that you're part of the problem. Of course you're not going to find any programmers in language X when you're not offering jobs in language X.
Apologies for the rant.
So now we're supposed to waste our time fiddling our thumbs about broken trust and rights "management" crap? This is the same stunt MS pulled by claiming Windows met "Orange Book" (from the NSA Rainbow Series of books) "security" standards. Of course, Access Control Lists don't do much if your OS is full of buffer overflows and similar exploits, and this is ignoring the issue that ACLs don't do much at all and don't do it very well anyway. This seems like an overly expensive way of distracting customers from the real security issues (ha! like that one-month code review jerk-off session really accomplished anything).
I can see only two benefits coming from this. Likely the grants those professors are receiving from MS will trickle down to some poor, hungry grad students who actually deserve it. Also, if the quote above has any relevance to MS's own development plans (but I'm not holding my breath), maybe people forced to use MS software will have to suffer through less feature bloat and mandatory-upgrade new versions.
BTW, everyone seems to have forgotten about VRML (c'mon, it wasn't all bad!): "3d-web- thingies (there exists a browser plugin)"
Scroll down a bit and you'll find a link to another article the guy wrote, about the "the benefits of using XML-RPC and SOAP" (emphasis mine). For god's sake, even if the CGI article wasn't a promotion for his company, anyone who thinks that XML-RPC and SOAP has any kind of benefits really can't be taken too seriously.
At the very least, they didn't even bother looking at Common Lisp - Franz took a look at the CLR several years ago and decided that it wasn't even worth the trouble. It is impractical to get CLOS (the Common Lisp Object System - multiple dispatch, multiple inheritance, generic functions, and completely dynamic (you can re-define a class at runtime, and all the instances, and subclasses, etc. will be converted according to either a default or user specified method the next time they are accessed)) implemented with any sort of efficiency. Closures and dynamically generated lambdas (anonymous functions that capture a lexical environment and plain vanilla anonymous functions, created at runtime, respectively) seem to present a similar sort of problem from what I know of the CLR (I understand that they'd have to be represented as objects, please correct me if I'm wrong).
I've heard other similar objections to the inadequacy of the CLR when it comes to dynamics languages, and overall I'm not terribly impressed with what Microsoft is doing or how it is going about it (the seemingly primary reason why .Net has/will have Scheme implementations from both Northwestern and PLT is because of rather large grants).
Same question I had, and particularly relevant since the giant infomercial (giant in number of pages vs. page length (somewhere around 5 to 1), only) promised to explain the term, but never did. It was also massively uninformative, scant of details, explanations, and relevant background information. I don't know a lot about anime, and this mess of an article didn't do anything to help that.
Not to flame, but the guy said he was processing hundreds of megabytes of scientific data. Depending on the structure of the data (likely it is either very simple or very complicated), regular expressions aren't the right tool for the job - if it's just reading in a bunch of vectors, RE's would add significant overhead. If the structure is complex, REs will likely get more complicated than they're worth, simply because expressing complicated structures in terms of recursion and iteration is much faster and simpler, and REs don't do either very well. And of course if the data is in a binary format, then the whole point is moot.
Now when it comes to scientific visualization, vector formats aren't exactly all the rage. Neither is XML, since those files tend to be rather large and there tend to be a lot of them - no one wants to waste bandwidth and space on closing tags.
That's how Squeak works - it's a fully dynamic, standalone Smalltalk VM. There were (and still are) quite a few standalone Smalltalk compilers that will let you build more traditional interfaces or interface with windowing toolkits.
that most of this code will be in rule-sets, which really don't qualify as part of the program but as a part of the program's data. Of course, as another poster pointed out, today it is pretty obvious that knowledge and rule-based style AI is only good for expert-systems style intelligence, largely due to the limitations of first order logic. Self-organizing agent based systems and neural networks seem to be the next approach to making a more useful, general-purpose AI, but those largely consist of dynamically created entities, and their code size can sometimes be surprisingly small. Of course, there is a limitation to those two, so if I can pull some speculation out of my ass (this seems to be a pretty safe thing to do when talking about AI), the two approaches of knowledge-based and agent-based systems will have to be combined to make something truly useful. Now, as to how (if) that's going to be achieved reliably and usefully is a whole other story.