What do you see as the unique strengths and weaknesses of Lisp?
What strengths does it specifically have over other functional languages (such as ML), over structured languages (such as C, Algol, etc), over object oriented languages (such as C++, smalltalk, simula, etc), and over scripting languages (such as TCL, perl, etc)? Can these other languages or classes of languages be enhanced to include these strengths? If so, how, and if not, why?
What about weaknesses? What do you see as the weaknesses of Lisp, both in general and in comparison to the above classes of languages? Can these weaknesses be eliminated? If so, how and if not, why?
I mean strengths and weaknesses not only in the formal sense of the language itself, but also in terms of its usability in today's world. For example, difficulty in delivering binaries or lack of accessibility of system libraries from within common implementations of a language would be considered weaknesses.
The more nodes you have, the more likely it is that a node is going to crash during a computation. This yields a maximum cluster size for parallel applications which aren't fault tolerant. What are you doing to address this?
In particular, on the cluster reliability side, what are you doing to maximize node MTBF? What are you doing to minimize node downtime? How long does it take you to diagnose & replace/bring up a crashed node? How many nodes are currently down? How long can the cluster be expected to run before a node crashes?
On the application side, with MPI one needs to use complicated event loops with timeouts and/or are-you-there? pings to detect node outages. This makes doing parallel fault tolerant programming very complex. Are you doing anything to reduce this complexity? For example, what about a parallel programming API with fault tolerance built in? What about using PVM, where you can at least request notification of program crashes & computer outages. Have you explored other possibilities?
Finally, although a year ago alpha price/performance #s were much better than intel's, today intel's #s are so much better that they remain higher than the alpha's even when factoring in the large fixed cost of the internal cluster high speed networking. Also, linux tends to be more stable on intel than on alpha. Not to mention the question of how much longer alphas will continue to be produced. Given these issues, how happy are you with the choice of using alphas instead of intels?
Regarding linux/alpha robustness, what are you doing to make the alphas behave more robustly? What Linux distro, distro version, kernel version, libs versions, etc. are you using? What kernel patches, system patches, internally developed tweaks/patches are you using to make the alpha systems more robust?
Bruce Perens writes "Be is violating the GPL on my software. While it's something they can easily fix, it's a good example of why people need to keep track of where the software they are using came from, and what license is applied to it."
This brings up in my mind some fundamental GPL enforcement issues. No one can spend all his time checking that his GPL released software isn't being used in proprietary code - there're too many proprietary programs. For that matter, how could someone even verify it given access only to the binaries?
For example, suppose some company released a product which links in the GNU gmp library for bignum handling. How would the FSF realize this is occurring?
I tried to order one from Dell's web site. I couldn't find a Linux choice anywhere, so I called them. Here's the low down: 1. You have to order over the phone. The web site doesn't support choosing Linux. 2. They won't do a dual boot setup.
Microsoft is not hypocritical. They're doing what they always do. When something comes up that they don't control they develop a competing product. If necessary they fight for an open standard to do this. Then they keep "enhancing" their product so that their competitors have to play catchup. See Java for a recent example. See the MS Windows API for that matter. See the Halloween documents for detailed descriptions of this practice.
In this particular case this would probably mean supplying the client, then putting up their own servers & then changing the protocol.
I'm not surprised that AOL would keep trying to lock out the Microsoft client. If Microsoft wins then expect Microsoft to eventually own the Instant Messenger service.
It's true that entrenchment can prevent this from happening, but I don't see entrenchment occurring in this example in the same way that it has occurred for Internet protocols. With Internet protocols there's a large mix of equipment and operating systems. This prevents Microsoft from being able to change things by caveat. But, IM is an app level protocol with lots of clients mostly running on MS Windows & only 1 server - AOL's. In this case MS can easily put out their own server & then change the protocol.
Slashdot Mirror
What do you see as the unique strengths and weaknesses of Lisp?
What strengths does it specifically have over other functional languages (such as ML), over structured languages (such as C, Algol, etc), over object oriented languages (such as C++, smalltalk, simula, etc), and over scripting languages (such as TCL, perl, etc)? Can these other languages or classes of languages be enhanced to include these strengths? If so, how, and if not, why?
What about weaknesses? What do you see as the weaknesses of Lisp, both in general and in comparison to the above classes of languages? Can these weaknesses be eliminated? If so, how and if not, why?
I mean strengths and weaknesses not only in the formal sense of the language itself, but also in terms of its usability in today's world. For example, difficulty in delivering binaries or lack of accessibility of system libraries from within common implementations of a language would be considered weaknesses.
The more nodes you have, the more likely it is that a node is going to crash during a computation. This yields a maximum cluster size for parallel applications which aren't fault tolerant. What are you doing to address this?
In particular, on the cluster reliability side, what are you doing to maximize node MTBF? What are you doing to minimize node downtime? How long does it take you to diagnose & replace/bring up a crashed node? How many nodes are currently down? How long can the cluster be expected to run before a node crashes?
On the application side, with MPI one needs to use complicated event loops with timeouts and/or are-you-there? pings to detect node outages. This makes doing parallel fault tolerant programming very complex. Are you doing anything to reduce this complexity? For example, what about a parallel programming API with fault tolerance built in? What about using PVM, where you can at least request notification of program crashes & computer outages. Have you explored other possibilities?
Finally, although a year ago alpha price/performance #s were much better than intel's, today intel's #s are so much better that they remain higher than the alpha's even when factoring in the large fixed cost of the internal cluster high speed networking. Also, linux tends to be more stable on intel than on alpha. Not to mention the question of how much longer alphas will continue to be produced. Given these issues, how happy are you with the choice of using alphas instead of intels?
Regarding linux/alpha robustness, what are you doing to make the alphas behave more robustly? What Linux distro, distro version, kernel version, libs versions, etc. are you using? What kernel patches, system patches, internally developed tweaks/patches are you using to make the alpha systems more robust?
This just in on Slashdot:
Bruce Perens writes "Be is violating the GPL on my software. While it's something they can easily fix, it's a good example of why people need to keep track of where the software they are using came from, and what license is applied to it."
This brings up in my mind some fundamental GPL enforcement issues. No one can spend all his time checking that his GPL released software isn't being used in proprietary code - there're too many proprietary programs. For that matter, how could someone even verify it given access only to the binaries?
For example, suppose some company released a product which links in the GNU gmp library for bignum handling. How would the FSF realize this is occurring?
I tried to order one from Dell's web site. I
couldn't find a Linux choice anywhere, so I called
them. Here's the low down:
1. You have to order over the phone. The web
site doesn't support choosing Linux.
2. They won't do a dual boot setup.
The window manager scwm is sufficently powerful that one can write a configuration file for it making the mouse superfluous.
Microsoft is not hypocritical. They're doing what they always do. When something comes up that they don't control they develop a competing product. If necessary they fight for an open standard to do this. Then they keep "enhancing" their product so that their competitors have to play catchup. See Java for a recent example. See the MS Windows API for that matter. See the Halloween documents for detailed descriptions of this practice.
In this particular case this would probably mean supplying the client, then putting up their own servers & then changing the protocol.
I'm not surprised that AOL would keep trying to lock out the Microsoft client. If Microsoft wins then expect Microsoft to eventually own the Instant Messenger service.
It's true that entrenchment can prevent this from happening, but I don't see entrenchment occurring in this example in the same way that it has occurred for Internet protocols. With Internet protocols there's a large mix of equipment and operating systems. This prevents Microsoft from being able to change things by caveat. But, IM is an app level protocol with lots of clients mostly running on MS Windows & only 1 server - AOL's. In this case MS can easily put out their own server & then change the protocol.