Fortunately, I do get access to some journals through my university library's subscriptions. Unfortunately, those subscriptions are not the ones I need. Since the ACM requires that all submitters give up the copyright to their papers in exchange for $0.0, I don't have any choice but to pay their extortionary rates for back-issues (even though 99% of the authors I'm interested in give away their other papers for free on the Internet anyway). I could see the ACM having some value 20 years ago, when electronic distribution and archiving was not a reality, but today there really is no need for this commercial "scientific" society, since the aforementioned publishing is the only benefit it provides to researchers. As for conferences and SIGs, there are cheaper, better and more open ways to do them.
There's a little saying I came up with to try to explain these silly requirements to myself. It goes something like this:
"Sure, coding in Pascal is crippling, but at least everyone's crippled equally."
The statement is a little out of date (but a simple substitution will bring it right up to speed in these here modern techno-logical times of ours!). I think in some ways this is a valid rationale, but it makes completely no sense when you compare it to other competitive pursuits - no one requires professional athletes to wear lead shoes!
Anyway, if you really feel like competing in these things, I recommend you contact these folks. They (he? I think Antonio Leitao presented a paper on this at ILC 2002) are promising to release their automated LinJ (large subset of) Common Lisp to Java translator (pretty-prints, too!) real soon now. I'm sure they'll let you use it if you ask nicely.
PS - the ILC this year had a programming contest, all in CL (I got my ass kicked miserably).
I believe those were introduced by Shimano as the "Biospace" (or at least Bio-something) brand chainrings. Didn't catch on much because most people found the pedalling to feel jerky, or so I heard. I've also heard that they're still sold.
In LISP, macros became so bloated that Scheme had to be invented to strip the language down. But it was too late.
Before flaming, it helps to actually check who, what and why invented Scheme.
Sussman and Steele's compiler was first of all an implementation of Hewitt's ACTORS, and second of all an interpreter that re-wrote Scheme in CPS style (along the way inventing general tail-recursion) targeted at Maclisp. The only "bloat" that Scheme fixed was the "funarg problem" of early lisps by introducing full lexical scoping (along the way inventing the closure) and applicative order reduction/evaluation for function arguments, a convention that most later Lisps adopted (those that did not reportedly disappeared without a trace in the 1980s). The original Scheme did not include macros, and didn't have FEXPRS (ie - all functions evaluated their arguments, as mentioned above), but it did have quote, which is enough to build macros. I'm pretty sure they used some form of macros for transforming special forms to lambdas (off the top of my head, I think Steele mentions dirty macros in Compiler Optimization based on viewing LAMBDA as rename plus GOTO in Winston, ed, Artificial Intelligence - An MIT Perspective, Vol. 2). I know AI Memo 349 (Sussman, Steele, SCHEME an interpteter for extended lambda calculus) mentions something about AMACROs in the implementation.
But certainly neither of them disparaged macros (as a matter of fact, I do recall a not too old discussion on the Lighweight Languages mailing list where Steele defends macros against an attack using the same (lack of) arguments as yours).
PS - yes, it certainly was too late for Scheme, but luckily they added syntax-case back in somewhere around R4RS. Better late than never.
WTF is this supposed to mean? Are you endorsing the ACM? You do realize the ACM is basically one big (and with the web and open document publishing standards, totally unnecessary, like many other commercial "scientific" journals) scam of an organization?
Don't you realize that there is nothing right or wrong about either approach. It ends up as what is right or wrong for the current generation of technology, and this can soon enough change. The best thing we can do about it is producing modular software that can easily be changed to incorporate the advances in hardware.
Don't take me wrong - by equating the computer industry with the fashion industry, I'm not disparaging today's passe and unimaginative hardware designs, rather, I'm disparaging the computer industry itself. But you should really quantify that by "technology", you mean the price/performance ratio of hardware. The accelerated-subsystems approach never really disappeared when PCs started replacing "real" computers - PC companies just started selling SCSI controllers and fancy graphics accelerators. Regarding software, I agree with you completely. But it's very interesting to note that "modular" software won't come from any technological gain (or we'd all switch to programming languages from the 1970s - there's really no argument about the superiority of this approach), but rather from a sociological one - thank RMS for free software.
And pretty much every main-, mini- and real micro- computer design. I guess the computer industry is finally catching up to the 70s fashion mini-revival of a few years ago.
"You'd think they would have learned something from the failure of Symbolics, and ported to commodity (IA32) hardware. In computing, economies of scale will win every time."
Errr, Open Genera being a Symbolics product, it was written before Symbolics went bankrupt, obviously.
You're also not considering when Open Genera was designed (1992-1993). The 486 had only been around for a few years. At that time it was not at all clear that Intel would become the dominant computer architecture (which is one of the reasons why Symbolics produced Lisp Machine add-on boards for the Macintosh and Suns). Certainly if you looked at the high-end "workstation" computer market you couldn't tell. At the time, going with the Alpha was an obvious choice because it had a 64-bit word size (Symbolics machines had a 40-bit word size - maybe this would work acceptably on today's gigahertz Pentiums, but not on a 30Mhz 486), and it was one of the faster and more affordable (not to mention popular) systems available.
Aside from that, the Ivory chip (which was used in their machines and add-on boards) could easily match the performance of the 486 at 1/5th the clock speed.
"Have you used an Alpha workstation?"
Yes, but I've never owned one (I considered buying one in 1997 when prices really started going down, but I splurged on dirt-cheap dual PPro systems instead - I regret doing so now).
"... soon ordinary (relatively cheap) Unix boxes with general-purpose hardware could execute even Lisp code faster than Symbolics' special-purpose Lisp hardware."
Then why aren't we all using Open Genera, which has been available for about 10 years now for the Alpha? More to the point, why didn't Lisp "win" according to your reasoning? Obviously there is more to it than just the hardware.
I'm referring to type inference the compiler optimization. The jargon seems to be confused on this issue (although it is not surprising, since both techniques basically do the same thing, albeit one is weaker).
Yes, as if type-inferencing Lisp compilers weren't available for several decades now*. Look for this exciting new Sun(R) innovation to become available in the next couple of Java revisions (maybe they'll find this reason enough to jump all the way to Java 3.0!) as generics become popular^.
* - For the purpose of fair comparison, please disregard native code compilers - obviously Java is severely impeded by it's brain-damaged bytecode in this respect.
^ - Of course, by the time this happens, Sun could have saved itself all the trouble and made the language dynamically typed in the first place. But then it would automatically become 10 times as slow in the imaginations of what nowadays passes for "programmers."
Here's an interesting link that speculates why speculating execution and overabundance of ALUs on modern IA32 (and soon 64) processors makes dynamic typing (practically) free.
You can still buy Open Genera for $5000 (the price is fixed because of some long-term contractual obligations) from Symbolics Technologies* (well, David Schmidt in particular). If you're looking for a cheaper version, they might still have some MacIvory-II cards available (I think these are around $400, and come with Genera).
Unfortunately, they don't have any money for development, although they still contract out bug-fixes once in a while. Now that 64-bit x86 is available and the rest of the processor industry is surely going in the gutter (but what do I know?), it's entirely possible they'll make a VM for PCs if they get funding.
BTW, they also now offer the latest version of Macsyma for Windows (and Genera, I presume, but not for Unices - they lost(?) the the Linux version, and the ability to cut keys for the rest of the Unices) for $500.
* - Here's a link with the latest contact info I've been able to find.
The original Lisp Machine as developed at MIT was primarily designed to beat out the minicomputers of the times in terms of cost - and this it did very well. Let me quote a few excerpts from Artificial Intelligence: An MIT perspective, vol. 2, 1979 by Winston and Brown, ed. (pp. 350-251):
"The memory is typically 64k [32-bit words - two megabytes!]... 16 million word disk... The access time of the core memory is about one microsecond, and of the disk, about 25 milliseconds... The display is a raster scan TV driven by a 1/4 Mbit memory... The shared resources are accessed through a 10 million bit/sec packet switching network...
The complete LISP Machine, including processor, memory, disk, terminal, and connection to the shared file system... would be likely to cost about $80,000 if commercially produced today."
Recall the emphasis on the 1979 as the publication date! Not only did the Lisp Machine well outperform most minicomputers of the time, it was also considerably cheaper to manufacture and service due to it's simpler architecture (even the processor was microcoded RISC). The price is analogous to the comparatively underpowered PARC PCs of the time.
By the time the 80s rolled around, VLSI manufacturing dropped the costs of producing such computers by well over an order of magnitude (note that the original Lisp Machines had core memory). The $40k quoted by a ripped-off customer would have probably bought him a new Lisp Machine every year had it not been for the terrible mark-up introduced by a monopoly (LMI, inc. dropped out early in the game, and TI Explorers were priced closely to Symbolics machines).
I think a much better one on the subject is Valentin Pikul's Barbarossa. (ISBN 5-7838-0230-1 for the new printing, but I have not seen it translated to any language from Russian yet). It has a much deeper account of the political and military machinations leading up to the actual battle, recounting them mostly from the perspective of (as well as dealing with him as a man), Friedrich Paulus, and his contrast with Rommel. Despite being written in a rather informal style, it is very meticulously researched (I think Pikul claims close to 3,000 sources total, some of them first-hand), and some of his statistics really put the Russian front in perspective (something that seems to have been totally ignored by the current wave of rah-rah USA jingoism) - once he cites that just over 1% of the Wermacht forces were involved on the North African "front" in the years 1941-1942; the rest being almost entirely used in the Russian advance, underscoring Rommel's genius. The contrast he brings up in Rommel's inventiveness despite critical lack of reinforcements vs. the difficulties of the Eastern front (and the two conflict's political and strategic dependence on each other) is pretty unique.
What really sets his book apart is his meticulous reading into declassified Russian archives.* The blunders by Stalin and his henchmen turn out to be monumentally stupid at almost every strategic decision, and even worse the deliberate repressions they bring about, justified by party doctrine. Stalin's "incompetence" as described in Stalingrad pales in comparison to the actual events.
* Pikul's motivation for writing Barbarossa came after a series of Soviet documents were released that finally revealed the details of the fate of his father, who died defending Stalingrad.
A few software fashions that are doing too well:
on
Software Fashion
·
· Score: 0
Unix never really went out of style with the 60s, and for that matter neither did C. At least more and more people are turning away from C++. Too bad most of them seem to be switching to.Crap. For that matter, Java isn't too good either - "object orientation" as fancy structs is about as fashionably correct (for those "in-the-know," of course) as a bachelor driving a 4-ton SUV, and a byte-code VM is a waste if all you're going to do with it is hardware abstraction.
"Strong typing in the context of a "pointerfree" language, and appropriately used, only prevents you from doing things that make no sense."
What does strong typing have to do with static type analysis?
"Ever heard of premature optimisation?... the point is the internals of a class may reasonably change, but it's not reasonable to expect programmer's to optimise prematurely (or over-optimise all classes!) before they know how the profile will look. (You know, profilers - ever used one?)"
Was I ever arguing against well defined interfaces? Since you claim to be so familiar with Kiczales' work, you probably already know what he thinks about these, and you probably know what he thinks about reasonable component implementations, and you probably know what he thinks about stratified design, which probably means I really shouldn't have to tell you to actually learn what he talks about.
"You want to poke around in black boxes only to the extent necessary - and design your black boxes so that people don't need to do a lot of poking around in the internals!"
Well, this statement kind of contradicts your previous counter-argument, doesn't it now?
"It (the former) tells you the set of messages (or methods, whatever you wanna call them) that it is legal to send to the value in question. It tells you what kind of thing the value is supposed to be. How can that not be useful in analysis?"
Well, it doesn't help any in a language where anything and everything can be done at run-time. Most problems that benefit from this type of analysis are hard, and most hard problems are very dynamic. Besides which, what benefit would this have for analysis beyond the static type-checking already in the static (Java) compiler?
"Their most important purpose is to absolve developers of the responsibility of keeping backward compatibility for those members."
And also absolve them from the responsibility of designing their classes well the first time.
"Sometimes you want to hide your implementation so you can actually change it without breaking third-party code."
What if the third-party code needs to change some of the code you didn't design right the first time (or it may be impossible to do period)? Pure black-box abstractions break down pretty quickly for practical reasons (ever hear the term "glue code"?). See the Open Implementation concept.
I see a lot of posts pointing out the infexibility of software objects/components and the need for custom "wheels." I think the former can largely be blamed on the direction modern, statically-compiled programming languages took in their use of data hiding and mandatory encapsulation as "abstractions." Kiczales' Open Implementation group at PARC showed that this actually inhibits code reuse by preventing the customization of "the wheel." Open Implementation is supported by reflection and some aspects of the Meta-Object Protocol (although in most cases this is total overkill), and this is the central idea behind Kiczales' current work in Aspect-Oriented Programming. But in practice, I find relatively simple things, like function advising (and more recently Costanza's dynamically scoped functions), and CLOS's before, after, and around methods are enough to take care of almost all customization problems that arise. Sometimes, breaking data hiding rules can also be useful.
Dave Dyer wrote a photoshop plugin called LensDoc for this purpose for Andromeda Software. I haven't personally used it, but the sample results look pretty nice, and the guy definitely knows what he's doing. Check out some of his other stuff as well.
I suppose it's bad taste to re-post the same comment in the same thread, but since egarland doesn't seem to mind spamming his four-page manifesto, I might as well reply to this "roads don't take up space" argument he keeps bringing up:
"In a typical low density American suburb, more than 50 per cent of the land is covered with concrete or asphalt paving. In some areas, like downtown Los Angeles, it is more than 65 per cent."
"In a typical low density American suburb, more than 50 per cent of the land is covered with concrete or asphalt paving. In some areas, like downtown Los Angeles, it is more than 65 per cent."
How so? What exactly do you want to build? I suppose if you're expecting splines or some other hack like that, of course Wings 3d isn't going to have it. But polygons in a winged-edge data structure+subdivision surfaces is currently the best technique available for anything organic, and if it had a little more support for numerical input (like Mirai, for example) it would really kick ass at mechanical and architectural visualization.
"If the roads are too crouded [sic], build bigger roads."
Build them where? If you haven't noticed, that whole "impending food shortage" problem from the early 90s didn't disappear when they stopped making documentaries about it. Already, most cities are built on top of the best agricultural land. Urban sprawl and the suburbs are a real problem.
Besides that, the more fundamental problem with "big roads" is the fact that by increasing road size, you are only making traffic congestion worse. The more spread out a 2-dimensional suburb is, the greater distance you need to travel to get from point a to b. The problem is of course you live at point a, but several hundred people may need to get to point b at the same time. No one seems interested in differential schedules (which are a duct-tape solution to a small portion of the problem anyway), so this isn't likely to be fixed any other way.
Of course, the fundamental problem with your argument goes even deeper. Building bigger roads is only a temporary solution, and as long as it can keep up with traffic congestion, it only encourages urban sprawl. Your suggestion would only work if land and fuel were infinite commodities, and buildings could be moved and roads expanded with ease.
Slashdot Mirror
Fortunately, I do get access to some journals through my university library's subscriptions. Unfortunately, those subscriptions are not the ones I need. Since the ACM requires that all submitters give up the copyright to their papers in exchange for $0.0, I don't have any choice but to pay their extortionary rates for back-issues (even though 99% of the authors I'm interested in give away their other papers for free on the Internet anyway). I could see the ACM having some value 20 years ago, when electronic distribution and archiving was not a reality, but today there really is no need for this commercial "scientific" society, since the aforementioned publishing is the only benefit it provides to researchers. As for conferences and SIGs, there are cheaper, better and more open ways to do them.
He was also one of the founders of the modern field of artificial intelligence (and I believe it was him and Minsky that coined the term).
"Sure, coding in Pascal is crippling, but at least everyone's crippled equally."
The statement is a little out of date (but a simple substitution will bring it right up to speed in these here modern techno-logical times of ours!). I think in some ways this is a valid rationale, but it makes completely no sense when you compare it to other competitive pursuits - no one requires professional athletes to wear lead shoes!
Anyway, if you really feel like competing in these things, I recommend you contact these folks. They (he? I think Antonio Leitao presented a paper on this at ILC 2002) are promising to release their automated LinJ (large subset of) Common Lisp to Java translator (pretty-prints, too!) real soon now. I'm sure they'll let you use it if you ask nicely.
PS - the ILC this year had a programming contest, all in CL (I got my ass kicked miserably).
I believe those were introduced by Shimano as the "Biospace" (or at least Bio-something) brand chainrings. Didn't catch on much because most people found the pedalling to feel jerky, or so I heard. I've also heard that they're still sold.
Sussman and Steele's compiler was first of all an implementation of Hewitt's ACTORS, and second of all an interpreter that re-wrote Scheme in CPS style (along the way inventing general tail-recursion) targeted at Maclisp. The only "bloat" that Scheme fixed was the "funarg problem" of early lisps by introducing full lexical scoping (along the way inventing the closure) and applicative order reduction/evaluation for function arguments, a convention that most later Lisps adopted (those that did not reportedly disappeared without a trace in the 1980s). The original Scheme did not include macros, and didn't have FEXPRS (ie - all functions evaluated their arguments, as mentioned above), but it did have quote, which is enough to build macros. I'm pretty sure they used some form of macros for transforming special forms to lambdas (off the top of my head, I think Steele mentions dirty macros in Compiler Optimization based on viewing LAMBDA as rename plus GOTO in Winston, ed, Artificial Intelligence - An MIT Perspective, Vol. 2). I know AI Memo 349 (Sussman, Steele, SCHEME an interpteter for extended lambda calculus) mentions something about AMACROs in the implementation.
But certainly neither of them disparaged macros (as a matter of fact, I do recall a not too old discussion on the Lighweight Languages mailing list where Steele defends macros against an attack using the same (lack of) arguments as yours).
PS - yes, it certainly was too late for Scheme, but luckily they added syntax-case back in somewhere around R4RS. Better late than never.
You're also not considering when Open Genera was designed (1992-1993). The 486 had only been around for a few years. At that time it was not at all clear that Intel would become the dominant computer architecture (which is one of the reasons why Symbolics produced Lisp Machine add-on boards for the Macintosh and Suns). Certainly if you looked at the high-end "workstation" computer market you couldn't tell. At the time, going with the Alpha was an obvious choice because it had a 64-bit word size (Symbolics machines had a 40-bit word size - maybe this would work acceptably on today's gigahertz Pentiums, but not on a 30Mhz 486), and it was one of the faster and more affordable (not to mention popular) systems available.
Aside from that, the Ivory chip (which was used in their machines and add-on boards) could easily match the performance of the 486 at 1/5th the clock speed.
Yes, but I've never owned one (I considered buying one in 1997 when prices really started going down, but I splurged on dirt-cheap dual PPro systems instead - I regret doing so now). Yes (even several people besides myself!)I'm referring to type inference the compiler optimization. The jargon seems to be confused on this issue (although it is not surprising, since both techniques basically do the same thing, albeit one is weaker).
* - For the purpose of fair comparison, please disregard native code compilers - obviously Java is severely impeded by it's brain-damaged bytecode in this respect.
^ - Of course, by the time this happens, Sun could have saved itself all the trouble and made the language dynamically typed in the first place. But then it would automatically become 10 times as slow in the imaginations of what nowadays passes for "programmers."
Here's an interesting link that speculates why speculating execution and overabundance of ALUs on modern IA32 (and soon 64) processors makes dynamic typing (practically) free.
Unfortunately, they don't have any money for development, although they still contract out bug-fixes once in a while. Now that 64-bit x86 is available and the rest of the processor industry is surely going in the gutter (but what do I know?), it's entirely possible they'll make a VM for PCs if they get funding.
BTW, they also now offer the latest version of Macsyma for Windows (and Genera, I presume, but not for Unices - they lost(?) the the Linux version, and the ability to cut keys for the rest of the Unices) for $500.
* - Here's a link with the latest contact info I've been able to find.
This is another popular Lisp Machine myth that I've recently found out is not true. The sole reason for the Lisp Machines' outrageous prices was Symbolics' monopoly. Worse than their high mark up on the hardware was their support costs - "Like everyone outside the US, I was grossly overcharged by Symbolics UK (some $40,000 per annum in maintenance charges alone)." (emphasis mine)
The original Lisp Machine as developed at MIT was primarily designed to beat out the minicomputers of the times in terms of cost - and this it did very well. Let me quote a few excerpts from Artificial Intelligence: An MIT perspective, vol. 2, 1979 by Winston and Brown, ed. (pp. 350-251):
Recall the emphasis on the 1979 as the publication date! Not only did the Lisp Machine well outperform most minicomputers of the time, it was also considerably cheaper to manufacture and service due to it's simpler architecture (even the processor was microcoded RISC). The price is analogous to the comparatively underpowered PARC PCs of the time.
By the time the 80s rolled around, VLSI manufacturing dropped the costs of producing such computers by well over an order of magnitude (note that the original Lisp Machines had core memory). The $40k quoted by a ripped-off customer would have probably bought him a new Lisp Machine every year had it not been for the terrible mark-up introduced by a monopoly (LMI, inc. dropped out early in the game, and TI Explorers were priced closely to Symbolics machines).
What really sets his book apart is his meticulous reading into declassified Russian archives.* The blunders by Stalin and his henchmen turn out to be monumentally stupid at almost every strategic decision, and even worse the deliberate repressions they bring about, justified by party doctrine. Stalin's "incompetence" as described in Stalingrad pales in comparison to the actual events.
* Pikul's motivation for writing Barbarossa came after a series of Soviet documents were released that finally revealed the details of the fate of his father, who died defending Stalingrad.
Unix never really went out of style with the 60s, and for that matter neither did C. At least more and more people are turning away from C++. Too bad most of them seem to be switching to .Crap. For that matter, Java isn't too good either - "object orientation" as fancy structs is about as fashionably correct (for those "in-the-know," of course) as a bachelor driving a 4-ton SUV, and a byte-code VM is a waste if all you're going to do with it is hardware abstraction.
I see a lot of posts pointing out the infexibility of software objects/components and the need for custom "wheels." I think the former can largely be blamed on the direction modern, statically-compiled programming languages took in their use of data hiding and mandatory encapsulation as "abstractions." Kiczales' Open Implementation group at PARC showed that this actually inhibits code reuse by preventing the customization of "the wheel." Open Implementation is supported by reflection and some aspects of the Meta-Object Protocol (although in most cases this is total overkill), and this is the central idea behind Kiczales' current work in Aspect-Oriented Programming. But in practice, I find relatively simple things, like function advising (and more recently Costanza's dynamically scoped functions), and CLOS's before, after, and around methods are enough to take care of almost all customization problems that arise. Sometimes, breaking data hiding rules can also be useful.
Dave Dyer wrote a photoshop plugin called LensDoc for this purpose for Andromeda Software. I haven't personally used it, but the sample results look pretty nice, and the guy definitely knows what he's doing. Check out some of his other stuff as well.
Alexander et al, A Pattern Language, p. 267
Alexander et al, A Pattern Language, p. 267
How so? What exactly do you want to build? I suppose if you're expecting splines or some other hack like that, of course Wings 3d isn't going to have it. But polygons in a winged-edge data structure+subdivision surfaces is currently the best technique available for anything organic, and if it had a little more support for numerical input (like Mirai, for example) it would really kick ass at mechanical and architectural visualization.
Besides that, the more fundamental problem with "big roads" is the fact that by increasing road size, you are only making traffic congestion worse. The more spread out a 2-dimensional suburb is, the greater distance you need to travel to get from point a to b. The problem is of course you live at point a, but several hundred people may need to get to point b at the same time. No one seems interested in differential schedules (which are a duct-tape solution to a small portion of the problem anyway), so this isn't likely to be fixed any other way.
Of course, the fundamental problem with your argument goes even deeper. Building bigger roads is only a temporary solution, and as long as it can keep up with traffic congestion, it only encourages urban sprawl. Your suggestion would only work if land and fuel were infinite commodities, and buildings could be moved and roads expanded with ease.