I'm not sure what Lisp you're referring to, but nowadays 'Lisp' is pretty much synonymous with the Common Lisp dialect. I'd have to lump that into object-oriented too (I don't think I've seen a single app written in the past couple of years that wasn't at least half based on multimethods and objects/structures).
You probably mean the PDP-10 (the DECSYSTEM-20 was just a renamed PDP-10). Here is an exhaustive list of resources for emulation. I recommend you try out ITS; it's probably the best environment ever made when it comes to assembly programming.
has been available for some time under the GNU Free Documentation License. I tried to use it a while back when I decided to learn assembler, but I found Paul Carter's PC Assembly Language to be a much better introduction.
The story is an apocryphal amalgamation of two unrelated incidents.
The original "stopped for GC" story actually happened*. In 1959, John McCarthy was demonstrating an early prototype of interactive computing with the one of the first Lisp implementations running on top of MIT's LCS's IBM 704, newly decked out with interrupt hardware and a teletype, to a meeting of the MIT Industrial Affiliates. In the middle of his presentation, the teletype printed out a line warning about "Garbage Collection," and started spewing page after page of memory addresses. MIT was at the time notorious for it's pranksters, so the audience immediately thought this was such a prank and burst into laughter.
As far as I know, the second incident is currently happening in a number of robotics shops all over the world. Lisp started getting used for robot planning in the late 70s, even at MIT. Before then, a number of specialized languages (such as PLANNER at MIT) had been used. By the time robot control hardware was powerful enough to run Lisp (the early 80s), real time systems were well understood, and a number of special dialects and techniques for real-time Lisp were developed and used successfuly for robot control, among other applications. All these approaches share one thing in common: they reduce the amount of memory allocated at run-time, either through pre-allocated pools or just avoiding making objects. As much as Sun's marketing insists that their revolutionary incremental garbage collection that they borrowed from someone else will solve all your problems, real-time Java programs will have to rely on the same mechanisms.
Of course, this does nothing to solve the dilemma of poorly built and programmed robots! Unfortunately, the AI charlatans of the 80s had to blame somebody after their bubble burst (look up "AI Winter"), and Lisp was the first thing to get the boot (which probably explains the source of the story, and many other things "heard" about Lisp and related technologies). Java will probably (and unfairly) end up as a similar scapegoat when the current robotics movement has it's own implosion (because I believe there is not much worthwhile going on there).
* - My source for this story is Mitchell Waldrop's "The Dream Machine." If I ever meet John McCarthy, I'll ask him about this (I suppose I could just email him, but what's the fun in that?). This Lisp system used the first garbage collection method invented, now known as mark-and-sweep.
Let me interject a third viewpoint into this discussion. I propose eliminating any guarantees about machine-level program representation in this hypothetical OS. Everything, and I mean all software would have to be distributed as source code. Then validating that source code for trustworthiness could be done by a simple search of the parse tree, and non-trusted software could be easily run in a protected environment. This, IMO, is the ultimate technical advantage of open-source (but not necessarily free) software.
Now this would require a sharp dividing line between executable code and data (at least for user programs - who knows what the OS is doing under the hood?). Data would then be serialized to UBF (mostly because XML is too fat). But this is actually a good thing - this would enable a painless move to the much more efficient Harvard architecture.
In practice, I think such system would probably suck in many ways; a lot of it would have to do with disallowing assembly. What is a much more realistic alternative (it's worked on some of the most successful systems ever built!) is to combine a powerful, interactive and unrestricted language and open-source software with technically sophisticated users. ITS is the paragon of this approach.
CLISP does this on 64-bit machines, and it's very slow. Here's a very informative post by Duane Rettig (one of the hackers of Franz's Allegro CL) explaining the optimal tag layout for Lisp on conventional byte-addressable machines.
Part of the power of C (as in Kernighan's "Why Pascal is not my favorite language") is the duality between pointer and array and the frequent lack of compile time restrictions on the array length. With a little pointer arithmetic, you can easily access subsections of arrays with whatever offset and length you feel like.
You can do this safer and faster using displaced arrays*. They first appeared in FORTRAN, but were most heavily exploited in the MIT Lisp Machines. They allow you to create "virtual" arrays that index onto an existing array in interesting ways, like changing the size and offset, or treating multi-dimensional arrays as vectors (and one of the most common application usually was to index byte-arrays onto word-arrays for hardware drivers). These can also be used in user-code to do very neat tricks with untyped arrays. Last but not least, there were also conformally displaced arrays (not to be confused with conformant arrays of Pascal or Modula), that displaced multi-dimensional arrays correctly with respect to dimension, so for example you could do in-place bit-blitting (which is how low-level screen drawing actually worked on some machines).
Sadly, I don't know of any other languages besides Common Lisp and FORTRAN that support them now. The byte-onto-word displacement is very much hardware dependent, and so is not mandated by Common Lisp. Neither are conformally displaced arrays, which is pretty aggravating considering how useful they are.
Since we are on the subject of tags, putting a tag on every scalar datum seems like a waste of memory and address space, but putting a few tags on an array doesn't seem like a big deal. Instead of an array being , an array could be , and this triple could be set 1) when you dynamically allocate an array, and 2) when you "cast" the array by taking a subslice of it. The bounds checking can be coded efficiently by an optimizer that knows about loop variables and such.
Yup, this is exactly how typed (displaced) arrays work in Lisp.
* - Actually, you can do things with displaced arrays that you can't do at all with pointer manipulation - fast, easy access to fractional addresses. You'd need this if you want to deal with bytes in a word-addressable architecture (such as the Lisp Machine), or for treating byte-arrays as bit-vectors.
A recent National Science Foundation Study reveals a 5 per cent decline in the overall doctoral candidates in the US over the last five years.
The India side story: India produces 3.1 million college graduates a year, which is expected to be doubled by 2010. The number of engineering colleges is slated to grow 50 per cent, to nearly 1,600, over the next four years.
How can they expect to compare the rate of growth of PhDs handed out in the states* to the number of college graduates* in India to the expected growth of engineering "colleges" in India and have it make any sense?
This is exactly the issue here. Despite what Microsoft says about interoperability of languages at the class level, interfaces between them will still have to be built up. To give.NET credit, this is a step up over ye olde Foreign Function Interface (although not in terms of performance). The big abstraction benefit one would probably get is with callbacks (although with the languages currently implemented on top of.NET I think it's still too early to tell).
There really isn't any such thing as a "C# class"...there is a CLR class that just happened to be compiled from C# code.
From my (admittedly far from complete) understanding of the CLR, it seems that most features of CLR classes are motivated primarily by C# implementation.
Sure, as long as your class looks just like a C# one. Need multimethods, dynamic class redefinition, method combination, a non-crippled model of multiple inheritance, or maybe even prototypes? You're out of luck, because for this interoperability to work, your classes will either have to be C# classes or you have to make them look like ones, and.NET doesn't give you a Meta Object Protocol to do it.
I'd argue that whiteboards are less legible than blackboards, particularly at a distance. But you should count yourself lucky - at my uni, we have a similar situation with gadget overload, and our professors have to bring their own chalk too!
"Have you ever used a large virtual desktop, such as is found in FVWM, Sawmill/Sawfish and the like?"
Yes, and this is mostly what I was ranting about. You make a strong distinction between "panes" and virtual desktops when in fact the differences are only superficial. The reason I especially dislike what FVWM and others like it do is that the geometric idiom is the only way to switch between virtual desktops. That, and I really must re-iterate that "flipping" is a worse than inadequate term to describe desktop change because of the confusion it introduces.
You are right about half-way windows, though. I think I saw that behavior in some older WM, but upon checking FVWM and Windowmaker (what I prefer), they both do the right thing.
In practice, the average CSci B.S. is going to end up writing database front ends for a business somewhere, so you could argue that all of these topics are academic and irrelevant.
Which is why I like Graham's (article posted elsewhere in this thread - but it's been proposed by others) idea of breaking up CS. Put all the chairwarmers who complain about "academic irrelevance" into the non-science, non-mathematics faculty. I even have an idea where - Communications needs a little more money and a little more formality.
Well, not only does "edge flipping" suck (more on that later), but it's acronym does as well. It doesn't describe what it does (change virtual desktops on mouse touching the real desktop's periphery - an obvious, descriptive phrase being "periphery desktop change"), but it also steals the meaning of the common 3d-graphics term (that does describe the function quite well, and predates the WM braindamage by a number of years).
Now, as to why periphery desktop change sucks (this is, of course, only my opinion). It's an annoying mis-feature that purports convenience, but only ends up breaking the concept of the desktop edge. If I put a window partially past the desktop edge, it shouldn't go away. It also introduces a confused notion of geometric relation between desktops, when in fact they're most productively viewed as distinct organizational entities (the whole purpose being that you only have to deal with geometry at the desktop level - the meta-desktop geometry only introduces an excess of unneded geometrical idioms). Finally, how hard is it to right-click send a window to some desktop? Then there's the problem dealing with high virtual resolutions in X (which may not be a good idea for productivity either, but it's a very good tool for people with sight disability).
Now, multiple-monitor set-ups are a different story (but I'd argue that they make virtual desktops unnecessary altogether).
Huzzah for market cycles! I hope IT won't matter..
on
Does IT Matter?
·
· Score: 2, Interesting
And here's why. I think the whole reason the article was written was because "IT" never really mattered - it was crushed by snake-oil salesmen and charlatans on both sides of the fence before it ever got off the ground. Just look at what happened with the AI boom and bust of the 80s - it's almost a direct parallel of the dot com spike.
Hopefully, Presidents and CEOs everywhere will take this article seriously, stop buying shit from Microsoft, Oracle, etc. and lay off as many "IT" middle managers and system babysitters as they can (friendly casualties will be inevitable, but they always are!). The throngs of chair-warmers streaming to university CS faculties will finally stop (because it sure as hell hasn't slowed down enough!)! While companies everywhere are starting to put real solutions to work and getting back the levels of database stability and utility others have enjoyed since the 70s, real CS research will resume at universities (hopefully the Homeland Security Department will channel some of it's money into this and not into the pockets of private "IT" solutions firms), and Free Software will become the dominant licensing paradigm. Because suddenly you can't milk money out of them anymore, people will abandon languages and tools that were hot in the 70s, and the state of the art of the 80s will be reborn and flourish. Hell, maybe even AI will resurface (it sure seems to be now with the natural-language search problems getting so much attention).
This is when the real productivity gains start. Businesses adopting these technologies will once again possess competitive advantage over those that don't. As more and more people start using it, overzealous reporters start hyping it, and all sorts of carpetbaggers leech on. The bubble inflates under their hot wind, and subsequently bursts. Most everybody realizes this was all a scam, someone or another finally gets the idea that "technology doesn't matter," everyone who was doing the real work is out of a job, and the unchangeable circle of market life goes on spinning!
Here's a very insightful Usenet post by Duane Rettig explaining the whole issue with tagging on 32 vs. 64 bit machines. It turns out smaller is better!
Even many experienced OO'ers will tell you that they use less inheritance and sub-typing than they used to, and instead use composition and aggregation, which are "less OO" concepts, and found in IBM's 1964 IMS database.
Inheritance is certainly not some intrinsic OO concept. It's actually a special case of delegation, where the object just shuffles unknown messages around. Hewitt's Actors and derived languages use this paradigm. See MIT AI Memo 410, Viewing Control Structures as Patterns of Passing Messages. I'd like to find out more about the IMS database - have you got any pointers?
Even in geometry with its stable rules, we have the ellipse-circle fights and the square-rectangle fights.
I swear I heard about a proposed/experimental object system where parent relationships were handled by constraints (so for example if some rectangular object had equal sides, it would automatically become a square), but I can't find anything on it!
Alan Borning proposed a neato object system where relationships among objects (it's prototype based) was handled by "inheritance constraints," a sort of super-flexible inheritance cum delegation scheme. See this page for Classes versus Prototypes in Object-Oriented Languages.
Someone already mentioned McCarthy's Recursive functions paper. I want to point out some papers building on his work (and I consider these to be some of the most important papers in programming language research):
SCHEME: An Interpreter For Extended Lambda Calculus, Gerald Jay Sussman and Guy Lewis Steele, Jr, 1975. This paper introduces the concept of the closure, unifying the concept of object-oriented programming with lambda-calculus inspired semantics. It also provides a very interesting interpretation strategy (and Steele's subsequent work on the Rabbit optimizing compiler goes even beyond this). Scheme is probably one of the most important languages ever devised (some claim it was "discovered").
LAMBDA: The Ultimate Imperative, Guy Lewis Steele, Jr. and Gerald Jay Sussman, 1976. Introduces Continuation Passing Style, and provides a (surprisingly clean, elegant) mechanism for expressing all primitive imperative operations in terms of pure lambda-calculus semantics (introducing the modern concept of functional programming languages). Also includes a very insightful section on various argument passing techniques.
A correspondence between ALGOL 60 and Church's Lambda-Notation, Peter J. Landin, 1965. This is one of the primary influences on the development of Scheme. The J-operator goes on to become call-with-current-continuation. ALGOL goes on to become the single most influential programming language ever (lexical scoping, Backus-Naur Form, and ALGOL's syntax are all widely used today).
Something more on the light side, I think Craig W. Reynold's Boids paper and mechanism was pretty important in computer graphics. Nowadays, most crowd mechanism (including Weta's Massive) use essentially the same approach.
Slashdot Mirror
I'm not sure what Lisp you're referring to, but nowadays 'Lisp' is pretty much synonymous with the Common Lisp dialect. I'd have to lump that into object-oriented too (I don't think I've seen a single app written in the past couple of years that wasn't at least half based on multimethods and objects/structures).
You probably mean the PDP-10 (the DECSYSTEM-20 was just a renamed PDP-10). Here is an exhaustive list of resources for emulation. I recommend you try out ITS; it's probably the best environment ever made when it comes to assembly programming.
has been available for some time under the GNU Free Documentation License. I tried to use it a while back when I decided to learn assembler, but I found Paul Carter's PC Assembly Language to be a much better introduction.
The original "stopped for GC" story actually happened*. In 1959, John McCarthy was demonstrating an early prototype of interactive computing with the one of the first Lisp implementations running on top of MIT's LCS's IBM 704, newly decked out with interrupt hardware and a teletype, to a meeting of the MIT Industrial Affiliates. In the middle of his presentation, the teletype printed out a line warning about "Garbage Collection," and started spewing page after page of memory addresses. MIT was at the time notorious for it's pranksters, so the audience immediately thought this was such a prank and burst into laughter.
As far as I know, the second incident is currently happening in a number of robotics shops all over the world. Lisp started getting used for robot planning in the late 70s, even at MIT. Before then, a number of specialized languages (such as PLANNER at MIT) had been used. By the time robot control hardware was powerful enough to run Lisp (the early 80s), real time systems were well understood, and a number of special dialects and techniques for real-time Lisp were developed and used successfuly for robot control, among other applications. All these approaches share one thing in common: they reduce the amount of memory allocated at run-time, either through pre-allocated pools or just avoiding making objects. As much as Sun's marketing insists that their revolutionary incremental garbage collection that they borrowed from someone else will solve all your problems, real-time Java programs will have to rely on the same mechanisms.
Of course, this does nothing to solve the dilemma of poorly built and programmed robots! Unfortunately, the AI charlatans of the 80s had to blame somebody after their bubble burst (look up "AI Winter"), and Lisp was the first thing to get the boot (which probably explains the source of the story, and many other things "heard" about Lisp and related technologies). Java will probably (and unfairly) end up as a similar scapegoat when the current robotics movement has it's own implosion (because I believe there is not much worthwhile going on there).
* - My source for this story is Mitchell Waldrop's "The Dream Machine." If I ever meet John McCarthy, I'll ask him about this (I suppose I could just email him, but what's the fun in that?). This Lisp system used the first garbage collection method invented, now known as mark-and-sweep.
Now this would require a sharp dividing line between executable code and data (at least for user programs - who knows what the OS is doing under the hood?). Data would then be serialized to UBF (mostly because XML is too fat). But this is actually a good thing - this would enable a painless move to the much more efficient Harvard architecture.
In practice, I think such system would probably suck in many ways; a lot of it would have to do with disallowing assembly. What is a much more realistic alternative (it's worked on some of the most successful systems ever built!) is to combine a powerful, interactive and unrestricted language and open-source software with technically sophisticated users. ITS is the paragon of this approach.
CLISP does this on 64-bit machines, and it's very slow. Here's a very informative post by Duane Rettig (one of the hackers of Franz's Allegro CL) explaining the optimal tag layout for Lisp on conventional byte-addressable machines.
Sadly, I don't know of any other languages besides Common Lisp and FORTRAN that support them now. The byte-onto-word displacement is very much hardware dependent, and so is not mandated by Common Lisp. Neither are conformally displaced arrays, which is pretty aggravating considering how useful they are.
Yup, this is exactly how typed (displaced) arrays work in Lisp.* - Actually, you can do things with displaced arrays that you can't do at all with pointer manipulation - fast, easy access to fractional addresses. You'd need this if you want to deal with bytes in a word-addressable architecture (such as the Lisp Machine), or for treating byte-arrays as bit-vectors.
* - Note that the degree major is unspecified.
I think he's referring to Viaweb.
This is exactly the issue here. Despite what Microsoft says about interoperability of languages at the class level, interfaces between them will still have to be built up. To give .NET credit, this is a step up over ye olde Foreign Function Interface (although not in terms of performance). The big abstraction benefit one would probably get is with callbacks (although with the languages currently implemented on top of .NET I think it's still too early to tell).
Sure, as long as your class looks just like a C# one. Need multimethods, dynamic class redefinition, method combination, a non-crippled model of multiple inheritance, or maybe even prototypes? You're out of luck, because for this interoperability to work, your classes will either have to be C# classes or you have to make them look like ones, and .NET doesn't give you a Meta Object Protocol to do it.
John McCarthy came up with the same idea (and invented a better XML before anyone had even heard of SGML) 30 years ago.
I'd argue that whiteboards are less legible than blackboards, particularly at a distance. But you should count yourself lucky - at my uni, we have a similar situation with gadget overload, and our professors have to bring their own chalk too!
You are right about half-way windows, though. I think I saw that behavior in some older WM, but upon checking FVWM and Windowmaker (what I prefer), they both do the right thing.
Now, as to why periphery desktop change sucks (this is, of course, only my opinion). It's an annoying mis-feature that purports convenience, but only ends up breaking the concept of the desktop edge. If I put a window partially past the desktop edge, it shouldn't go away. It also introduces a confused notion of geometric relation between desktops, when in fact they're most productively viewed as distinct organizational entities (the whole purpose being that you only have to deal with geometry at the desktop level - the meta-desktop geometry only introduces an excess of unneded geometrical idioms). Finally, how hard is it to right-click send a window to some desktop? Then there's the problem dealing with high virtual resolutions in X (which may not be a good idea for productivity either, but it's a very good tool for people with sight disability).
Now, multiple-monitor set-ups are a different story (but I'd argue that they make virtual desktops unnecessary altogether).
Hopefully, Presidents and CEOs everywhere will take this article seriously, stop buying shit from Microsoft, Oracle, etc. and lay off as many "IT" middle managers and system babysitters as they can (friendly casualties will be inevitable, but they always are!). The throngs of chair-warmers streaming to university CS faculties will finally stop (because it sure as hell hasn't slowed down enough!)! While companies everywhere are starting to put real solutions to work and getting back the levels of database stability and utility others have enjoyed since the 70s, real CS research will resume at universities (hopefully the Homeland Security Department will channel some of it's money into this and not into the pockets of private "IT" solutions firms), and Free Software will become the dominant licensing paradigm. Because suddenly you can't milk money out of them anymore, people will abandon languages and tools that were hot in the 70s, and the state of the art of the 80s will be reborn and flourish. Hell, maybe even AI will resurface (it sure seems to be now with the natural-language search problems getting so much attention).
This is when the real productivity gains start. Businesses adopting these technologies will once again possess competitive advantage over those that don't. As more and more people start using it, overzealous reporters start hyping it, and all sorts of carpetbaggers leech on. The bubble inflates under their hot wind, and subsequently bursts. Most everybody realizes this was all a scam, someone or another finally gets the idea that "technology doesn't matter," everyone who was doing the real work is out of a job, and the unchangeable circle of market life goes on spinning!
I thought the section "why not 8 bits for tag?" was pretty clear on that.
Here's a very insightful Usenet post by Duane Rettig explaining the whole issue with tagging on 32 vs. 64 bit machines. It turns out smaller is better!
Alan Borning proposed a neato object system where relationships among objects (it's prototype based) was handled by "inheritance constraints," a sort of super-flexible inheritance cum delegation scheme. See this page for Classes versus Prototypes in Object-Oriented Languages.
SCHEME: An Interpreter For Extended Lambda Calculus, Gerald Jay Sussman and Guy Lewis Steele, Jr, 1975. This paper introduces the concept of the closure, unifying the concept of object-oriented programming with lambda-calculus inspired semantics. It also provides a very interesting interpretation strategy (and Steele's subsequent work on the Rabbit optimizing compiler goes even beyond this). Scheme is probably one of the most important languages ever devised (some claim it was "discovered").
LAMBDA: The Ultimate Imperative, Guy Lewis Steele, Jr. and Gerald Jay Sussman, 1976. Introduces Continuation Passing Style, and provides a (surprisingly clean, elegant) mechanism for expressing all primitive imperative operations in terms of pure lambda-calculus semantics (introducing the modern concept of functional programming languages). Also includes a very insightful section on various argument passing techniques.
A correspondence between ALGOL 60 and Church's Lambda-Notation, Peter J. Landin, 1965. This is one of the primary influences on the development of Scheme. The J-operator goes on to become call-with-current-continuation. ALGOL goes on to become the single most influential programming language ever (lexical scoping, Backus-Naur Form, and ALGOL's syntax are all widely used today).
Something more on the light side, I think Craig W. Reynold's Boids paper and mechanism was pretty important in computer graphics. Nowadays, most crowd mechanism (including Weta's Massive) use essentially the same approach.
All the AI Lab tech reports going back to #9 (I'm not sure where 1-8 went).