I used LISP back in the dark ages. Lighten up! Code is meant to be read by humans, and only incidentally for the computer to parse.
Actually, the quote is:
"Programs must be written for people to read, and only incidentally for machines to execute." - H. Abelson and G. Sussman (in "The Structure and Interpretation of Computer Programs)
For those not familiar with "The Structure and Interpretation of Computer Programs" it is one of the most famous introductory texts to computer science. All the code examples, of course, are written in Scheme...
Oh c'mon. The freshman CS class at our school (required for all majors except management) is taught in Scheme. People seem to have no problem picking up the syntax. Give it a good two-week try, and you'll like it. Its sure as hell a nicer syntax than C++
If you *really* can't get over the syntax, try Dylan. Its a Lisp-y language with a more traditional syntax. The infix syntax means that macros aren't as powerful, but the rest of the language has most of the power of Common Lisp.
Lisp code is hard to debug? What's *easier* to debug than Lisp code? An exception throws you up to the top-level, and you can look at what data structures are doing what. You can write code incrementally, testing bits and pieces of it as you go. Hell, you can edit code while you're running it! gdb is completely ancient in comparison.
Well, Haskell and Clean do lazy-evaluation. Cecil also has some very interesting ideas on class hierarchies in an dynamically typed language. And I'm not entirely sure Common Lisp has anything like Dylan's limited collections.
That said, I agree with you on the general sentiment:)
Actually, that's a bit off. The "trade" in this case is programming. Languages themselves are just like tools. You don't see a carpenter bragging "yeah, I'm a master --- I only use hammers."
Well, not necessarily. If the compiler can determine the "class" of an object statically, the methods can easily be inlined. You just need smarter compilers than what you usually see in the C/C++/C#/Java world.
Okay, in a class-based language, inheritence is statically decided at compile-time. In a prototype-based language, inheritience is just another operation that can be done at run time. You don't define classes statically, with each object having a predefined class. Rather, you copy an existing object (in the process copyings its existing members) and add new members to it.
Dude? Are you calling my iPod ugly? Its a fucking art piece! I shelled out an extra $100 for the damn thing, vs buying some Creative Labs knock-off because it looked so damn good.
How much does 15GB of memory for a PocketPC cost? The biggest CF card I can find is 2GB for $150, which is a pittance for an MP3 collection. Remember, the iPod isn't an MP3 player. Its an MP3 jukebox. People who buy those want all their music on it, or otherwise its a no-go.
Except that very few programs use GNOME-VFS. The same thing for Bonobo controls. GNOME has them, but the implementations aren't very good, and very few apps use them. Hell, the file selector doesn't even use them!
Eh? I'm on a 2.0GHz P4 with 640MB of RAM, and Konqueror takes less then a second to open a new window (CTRL-N). New tabs open instantly. My configuration isn't anything special --- KDE 3.2.1 on Debian.
Its not quite so rosy as you think. Before Apple fixed it up, people noticed significant rendering differences between Carbon and Cocoa applications. Eg: font rendering was subtly different. This indicates that there is not as much core integration as you'd believe. This makes sense, given that both OpenStep and the MacOS Toolbox already had that core code. This is in keeping with the design approach of the rest of OS X, where Apple didn't go out of their way to reconcile all the different components that they brought together (BSD and Mach, for example).
Commercial success isn't a very good measure of the quality of a system. Most of the commercially popular systems are greatly inferior to the ones that weren't very commercially successful.
Originally, it was a license holy war. GNOME was started because Qt wasn't GPL-compatible. By the time Qt was GPL'ed, GNOME had evolved to have a life of its own.
Today, the differences are very noticable:
- GNOME focuses on polish, ease of use, and adhering to classical HIG principles.
- KDE focuses on power and configurability. In general, the KDE framework is more high-tech and advanced then GNOME's, but that also causes the UI to sometimes feel mechanical.
Having redundant libraries is kind of a sad fact of life. No currently popular OS has been able to avoid it. At any given time, the average Windows machine is running several different toolkits (.NET, XP common controls, MS Office toolkit, etc). There is even redundency between Carbon and Cocoa in OS X.
Its interesting that nobody mentioned reconfigurable memory elements in this thread. They offer, IMHO, one of the most exciting potential advances in hardware.
Basically, the idea is that you put a bunch (from a few dozen to thousands) of very simple arithmatic units integrated right into memory. Inside memory, there is an enormous amount of bandwidth available at the sense amps --- several terabytes per second on current memory chips. These processors could all work in parallel, unfettered by memory bandwidth limitations.
The potential applications for such memory chips are very impressive. See here.
Oh yes. Because B2 bombers are awfully helpful in fighting Al Queda. Face it, there is a lot of pork in there that doesn't need to be, and a lot of things (particularly in the army, which doesn't seem to hold as high favor as the Air Force these days) that aren't getting properly funded.
Slashdot Mirror
I used LISP back in the dark ages. Lighten up! Code is meant to be read by humans, and only incidentally for the computer to parse.
Actually, the quote is:
"Programs must be written for people to read, and only incidentally for machines to execute."
- H. Abelson and G. Sussman (in "The Structure and Interpretation of Computer Programs)
For those not familiar with "The Structure and Interpretation of Computer Programs" it is one of the most famous introductory texts to computer science. All the code examples, of course, are written in Scheme...
PS: The full text is available here.
Oh c'mon. The freshman CS class at our school (required for all majors except management) is taught in Scheme. People seem to have no problem picking up the syntax. Give it a good two-week try, and you'll like it. Its sure as hell a nicer syntax than C++
If you *really* can't get over the syntax, try Dylan. Its a Lisp-y language with a more traditional syntax. The infix syntax means that macros aren't as powerful, but the rest of the language has most of the power of Common Lisp.
Lisp code is hard to debug? What's *easier* to debug than Lisp code? An exception throws you up to the top-level, and you can look at what data structures are doing what. You can write code incrementally, testing bits and pieces of it as you go. Hell, you can edit code while you're running it! gdb is completely ancient in comparison.
Well, if its Python, its like Lisp in a snake's skin (pun intended). A shadow of Lisp, to be sure, but similar in many ways.
Well, Haskell and Clean do lazy-evaluation. Cecil also has some very interesting ideas on class hierarchies in an dynamically typed language. And I'm not entirely sure Common Lisp has anything like Dylan's limited collections.
:)
That said, I agree with you on the general sentiment
Actually, that's a bit off. The "trade" in this case is programming. Languages themselves are just like tools. You don't see a carpenter bragging "yeah, I'm a master --- I only use hammers."
Well, not necessarily. If the compiler can determine the "class" of an object statically, the methods can easily be inlined. You just need smarter compilers than what you usually see in the C/C++/C#/Java world.
Okay, in a class-based language, inheritence is statically decided at compile-time. In a prototype-based language, inheritience is just another operation that can be done at run time. You don't define classes statically, with each object having a predefined class. Rather, you copy an existing object (in the process copyings its existing members) and add new members to it.
Dude? Are you calling my iPod ugly? Its a fucking art piece! I shelled out an extra $100 for the damn thing, vs buying some Creative Labs knock-off because it looked so damn good.
But the regular iPod is so sexy! /Lovingly strokes iPod.
How much does 15GB of memory for a PocketPC cost? The biggest CF card I can find is 2GB for $150, which is a pittance for an MP3 collection. Remember, the iPod isn't an MP3 player. Its an MP3 jukebox. People who buy those want all their music on it, or otherwise its a no-go.
This does not reflect well on your intelligence. Being easily fleeced is such a turn off...
Seriously, though. $250 for 4GB? You can get a 15GB iPod for $300! Just 1/5th more cash for almost 4x more hard drive space!
Did you see Chris Stone's talk? They're going with Qt for their application development, and KDE by logical consequence.
Not true. Its based on 4.4BSD-Lite2. Check the OpenDarwin FAQ if you don't believe me.
http://www.opendarwin.org/en/faq.php#lineage
Or Apple's history of darwin page
http://developer.apple.com/darwin/history.html
Or download a copy of darwin and 4.4BSD-Lite2 and see for yourself!
Because its based on an old version of UNIX. If you take a look at the kernel code, its *very* similar to the 4.4BSD-Lite2 that its based on.
The poster is right. GIMP-2 just came out today. That's the first version of Gimp with support for GTK-2, while GTK-2 has been around for years.
Except that very few programs use GNOME-VFS. The same thing for Bonobo controls. GNOME has them, but the implementations aren't very good, and very few apps use them. Hell, the file selector doesn't even use them!
Eh? I'm on a 2.0GHz P4 with 640MB of RAM, and Konqueror takes less then a second to open a new window (CTRL-N). New tabs open instantly. My configuration isn't anything special --- KDE 3.2.1 on Debian.
Its not quite so rosy as you think. Before Apple fixed it up, people noticed significant rendering differences between Carbon and Cocoa applications. Eg: font rendering was subtly different. This indicates that there is not as much core integration as you'd believe. This makes sense, given that both OpenStep and the MacOS Toolbox already had that core code. This is in keeping with the design approach of the rest of OS X, where Apple didn't go out of their way to reconcile all the different components that they brought together (BSD and Mach, for example).
Commercial success isn't a very good measure of the quality of a system. Most of the commercially popular systems are greatly inferior to the ones that weren't very commercially successful.
Originally, it was a license holy war. GNOME was started because Qt wasn't GPL-compatible. By the time Qt was GPL'ed, GNOME had evolved to have a life of its own.
Today, the differences are very noticable:
- GNOME focuses on polish, ease of use, and adhering to classical HIG principles.
- KDE focuses on power and configurability. In general, the KDE framework is more high-tech and advanced then GNOME's, but that also causes the UI to sometimes feel mechanical.
Having redundant libraries is kind of a sad fact of life. No currently popular OS has been able to avoid it. At any given time, the average Windows machine is running several different toolkits (.NET, XP common controls, MS Office toolkit, etc). There is even redundency between Carbon and Cocoa in OS X.
Its interesting that nobody mentioned reconfigurable memory elements in this thread. They offer, IMHO, one of the most exciting potential advances in hardware.
Basically, the idea is that you put a bunch (from a few dozen to thousands) of very simple arithmatic units integrated right into memory. Inside memory, there is an enormous amount of bandwidth available at the sense amps --- several terabytes per second on current memory chips. These processors could all work in parallel, unfettered by memory bandwidth limitations.
The potential applications for such memory chips are very impressive. See here.
Aside from the first French Empire, the second French Empire, France under Louis XIV, Napoleon, etc.
Oh yes. Because B2 bombers are awfully helpful in fighting Al Queda. Face it, there is a lot of pork in there that doesn't need to be, and a lot of things (particularly in the army, which doesn't seem to hold as high favor as the Air Force these days) that aren't getting properly funded.