How can a man who's about the size of an ant next to these beasts do such a thing armed with only a sword and a bow and arrow? That's for you to find out."
I don't know, but it probably involves lots of skeleton keys and switches.
If you program uses a GUI then you are pretty much out of luck. Sure you could use a cross platform gui library but even that is not as clean of a solution as Java.
Actually, several existing cross-platform GUI toolkits for C++ are far better and more predictable foundations on which to build cross-platform apps than Java. Furthermore, they give you the choice of writing a tiny bit of conditionalized platform specific code, resulting in a great improvement in quality.
Java's cross-platform capabilities were nice when it first came out in the mid-90's and there were no good C++ GUI toolkits for UNIX. That's why UNIX users flocked to it. Today, Java is not a good cross-platform solution anymore in comparison.
No you don't. Recent Linpack benchmarks have shown Java can match C/C++ in terms of math performance in many benchmarks. There is no speed disadvantage for this kind of work.
No, there is no speed disadvantage, there is, however, a programming disadvantage: in order to get speed in Java, you can't use any abstractions. Java is a less convenient language for numerical programming than C or Fortran 66.
And (surprise) that's why Sun has been working on Fortress.
On the contrary, almost everything about the development of Java has been handed over to the Java Community Process.
Yes, they handed over almost everything, except for their ownership of Java. Worse, almost everything new that comes out of the JCP ends up effectively being owned by Sun. So, yes, you do have a bunch of dopes that are working for free for Sun and getting less out of it than even your typical corporate researcher; at least those still get paid.
(1) You give up speed for a marginal increase in features. (1b) If speed is not a factor, languages such as OCaml have many more features suitable for high-level programming. OCaml is also slightly faster than Java in general. Thus Java is both more primitive and slower than a language that came out in a similar time frame.
Yes, OCAML is a much nicer language. As a middle ground, C# does offer lexical closures and parameterized types. OCAML, unfortunately, really dropped the ball on the compilation of parameterized types (which is as broken as it is in Java).
(2) You give up source portability for binary portability. Almost every platform has an ansi-C compiler, yet only a handful support Java, especially if you use a recent library. There are more platforms that support OpenGL than Java3D, for example.
I'm not sure that really matters; no new compiler is going to run everywhere instantly.
(3) A company controls your language. The future of Java is at the whim of a single for-profit entity. Furthermore, this entity has displayed that it wants to control the Java language and the Java platform to the greatest extent possible.
Yes, this is a huge problem. So far, it looks like the C# language and standard library are going to be open; they are also ISO/ECMA standards. It's unfortunate that Microsoft is making noises about keeping the.NET platform proprietary, and anything coming out of Microsoft is cause for concern, but this may still work out.
(4) It's one of the most difficult languages to interface with C, and it pushes 100% of the glue required to the native language. It is easier to interface Lisp and Haskell with C than Java to C through JNI. Given the large difference between the former pairs, and the small differences between the latter pair, this is pretty ironic,
Again, fully agreed. C#'s native interface is much simpler, much more efficient, and actually gives you built-in language constructs for accessing native data structures (points, layout, etc.).
Thursday, DeMeo said that Alexander had put his hand on DeMeo's knee
You know, when one drunk guy puts his hand on the knee of another drunk guy, it usually means that there is something else going on than GTA phantasies...
As per Microsoft giving away code, I think it's great if it's relevant. At least the mac platform-specific open source code is in some ways useful.
The code Microsoft gives away is also "in some ways useful".
I think that Apple is clever if they are using arguments like
Apple is doubtlessly clever in all sorts of ways. But it isn't their cleverness that's at issue, at issue is their claims:
As the first major computer company to make Open Source development a key part of its ongoing software strategy, Apple remains committed to the Open Source development model.
They aren't using an open source development model, they are throwing out patches every now and then. (They would also not be first even if they were using an OS development model.)
I don't care what Apple does, I just want them to be honest about what they are doing.
Os X powers a lot of desktops... But then again, I only roughly follow the stats.
Nobody knows for certain, but my impression is they are about equal. OSX has largely disappeared from Europe, and Linux is common on the desktop in university and business environments. Overall, both seem to be around 2-3%.
Sun is not to be trusted when it comes to programming languages as far as I'm concerned. They had promised to have Java standardized by a standards body and instead withdrew and are keeping tight control of the language. They will likely do the same thing again, all in the name of "ensuring compatibility", of course.
Whose comment were you replying to? I'd think you were trolling, but I can't even figure out what point you're trying to make.
Your argument was something like: "Apple did what they were legally required to under open source licenses, and they did the minimum they could legally get away with, so what are you complaining about?". That argument is wrong on two counts.
But Apple is not legally required to return source code under open source licenses. They are opening up the source code in order to augment their limited engineering staff with outside contributions. But, violating the spirit of open source development, they do it in such a way that it isn't useful to others.
Um, yeah, they're in BUSINESS! They try to capture market share, sell products and make money.
That's fine, as long as they don't advertise themselves as open source friendly.
As per them being an open source contributor, at least they give some code back. There are not all that many people who contribute anything at all.
Microsoft has been giving away platform specific source code since long before Apple.
As per Apple marketing itself 'against' Linux... HAHAHA ROFLOL. So you're saying they're trying to steal linux users?
No, they are trying to convert some of the buzz surrounding Linux into OS X sales. The argument is something like "why consider Linux if you could use OS X".
The tiny linux desktop market?
It may be tiny, but it's apparently about the same size as the OS X desktop market.
Have you tried using Os X?
I have been using OS X on and off for several years and have an OS X machine sitting right here. I'm unimpressed.
So, in your opinion, which for-profit corporations are doing a better job, and why? I'm genuinely curious who you would select as providing a better example, and what others would think of your selection(s).
Redhat (numerous contributions), Novell/SuSE (Mono, among many others), and IBM (Eclipse, GCC, kernel, Jikes, etc.) have contributed enormously. A true open source contributor doesn't view software as a zero-sum game. When IBM donates code to Linux or Java, they know that they help lots of "competitors" with that as well, but they also know that everybody, including themselves, wins overall.
Apple, on the other hand, still seems to view everything in terms of "us vs. the world" (an attitude shared with Sun and Microsoft). Apple is out to beat everybody and show that their technology is supposedly the best (in reality: not even close).
But I don't really care about Jobs's delusions, all I care about is that Apple keeps lying publicly about their innovation and about their support for open source. The fact is that the company doesn't pay for research and the company does not support open source, and to represent themselves as if they did is evil.
*blink* Okay, I'm intrigued. You were involved in the Common Lisp standardisation process? Or something related?
I was a customer and fairly heavy user of Lisp. I also contributed to several Lisp implementations and developed two Lisp interpreters myself.
I guess all the people like me just aren't very bright. Unlike you:).
It has nothing to do with being "bright"; as a serious user of a language and tool, you know whether it's working for you or not, and as someone who has worked on implementations, you know what is possible.
I wasn't exactly alone in my unhappiness with CommonLisp, which is why you got so many "alternative" Lisp efforts (Scheme, extended Scheme, Dylan, ISO Lisp, etc.), and why lots of people stopped using Lisp in the decade from the mid-80's to the mid-90's.
Part of the problem was that Lisp was designed for AI, but AI had moved on and Lisp hadn't changed and adapted to support its new needs. At this point, Python and C++ are actually far better languages for modern AI than Lisp.
Look, I know it's tempting to think that you had the answer and everything would be good if they'd just listened to you... but have you ever considered that there might be more than one reason for the so-called "demise" of Lisp?
Saying "if you don't do X, you will fail" is not equivalent to saying "if you do X, you will succeed". Better engineering would have been necessary, not necessarily sufficient.
Ah good. Always nice to get in a little snipe, isn't it? [...] might be slightly less horrifying if I knew there were some Lispy features being added to the language.
It's not a "snipe", the features are just so blatantly obvious, and they have been there for more than half a dozen years. That's no coincidence either: a lot of ex-Lisp, ex-Smalltalk, and ex-Self people have contributed to Java:
REPL: beanshell.org (used by DrJava and other IDEs), Jython, or a bunch of other interpreted languages
incremental development: standard feature in many IDEs (modify the running program), supported via standardized debugging APIs
dynamic typing: cast to/from Object, class attribute, etc.
reflection: java.lang.reflect
dynamic code generation: via class loaders (excellent support libraries)
functional programming: notationally less convenient, but effectively available via nested classes and used in new collection classes
macros: hygienic macros have been proposed for Java and a design has been worked out (maybe even an implementation) but deliberately left out
continuations: not part of CommonLisp and not part of Java either
So, here is where we are today: there are some people still fanatically devoted to CommonLisp; as long as they are vocal and as long as the CommonLisp standard is perceived as "the" Lisp standard by the outside world, no Lisp is going to make it. Scheme is good for what it is, and there are some excellent implementations, but it is too limited for real-world development, although an extended Scheme standard might have a chance. ISO Lisp is what CommonLisp should have been in the 1980's, but it is in serious need of updating (ISO Lisp might be the best starting point for a modern Lisp).
OTOH, the JVM and CLR are excellent runtimes, well defined, with multiple implementations, languages that many programmers feel comfortable with, and lots of dynamic language implementations running on top of them (e.g., Python, Smalltalk, and Scheme) that interoperate with those languages.
What we need is for the CommonLisp and Scheme folks to shut up about their old standards and for a bunch of credible language designers to create a new Lisp. But that will probably take another 20 years, when the people who inflicted CommonLisp on us are finally retired. And by that time, programming will hopefully neither consist of pointer manipulation, nor of recursive functions over conses anymore, at least if I have anything to do with it. I would have much rather used a good standard Lisp than the JVM as the basis for my work, but Lisp just wasn't up to it.
I'm not sure about that. From what I understand, open source doesn't mean you have to give other people everything verbatim, and explain the changes. You have to make available the source you based your code on.
False. You don't even have to make the sources available under many open source licenses. For example, Apple is under no obligation to make any of the BSD-licensed code that they ship available, but they do (but for KHTML, which is LGPL, they are required to).
Apple seems to make very few generally useful contributions to open source projects as far as I can tell. Most of the stuff they put out open source is stuff that enhances the value of their platform and only their platform. That's self-serving and doesn't make Apple "the good guys".
That would be fine, but Apple is trying to present itself as a contributor and supporter of open source, not just a user. And that seems like a misrepresentation. And it's not just that, Apple actively tries to market OS X against Linux, claiming (incorrectly) things like that OS X is "the better Linux".
As the first major computer company to make Open Source development a key part of its ongoing software strategy, Apple remains committed to the Open Source development model.
While it is doubtlessly good for Apple customers that Apple uses standard and high-quality open source components, they seem to have forgotten about the "contributing useful stuff back to the community" part that goes along with it. Oh, they put out a lot of code, but it's usually not useful: their gcc hacks haven't been useful, their KHTML hacks haven't been, Darwin isn't used much or very useful, etc.
So, we people understand that Apple is a business and doesn't want to help other companies. Now, if only they could be more honest about it in their marketing materials.
Yeah, it's a terrible shame that all those incredibly intelligent mathematicians and engineers behind Lisp didn't have cahiha to advise them about the concept of engineering tradeoffs.
They did, actually. I told them (as did lots of other people) even back when Lisp was more hyped up than Java has ever been and people were dropping $100k for a single Lisp-based workstation. They just weren't listening. The result of their lack of good engineering sense and arrogance was the demise of Lisp and the predictable (and predicted) 20 years of dark ages of C/C++ programming. It just boggles the mind that 20 years later, people like you still don't get it. I guess hindsight isn't 20/20 after all.
I won't even say anything more about Java, since I don't like the language, other than that you seem to know very little about its actual capabilities. For Python vs. Lisp, read Norvig's article.
There are lots of PoE-powered computers: switches, access points, etc. Many of them have processors running at over 100MHz and many megabyte of RAM--more than powerful enough to run software satisfying the computing needs of most people.
So, the only reason why a PoE-powered computer is "amazing" is because what is sold as a PC these days requires a lot of power, and it requires a lot of power because Windows requires a lot of memory, disk space, and CPU.
Based on his past record and interests, I wouldn't get my hopes up. Graham represents the attitudes and narrow focus that has turned off so many people from Lisp in the first place. And for a language designer to comment that he "intends it to be a hundred-year language" is just moronic and show a complete lack of long-term perspective.
The best attempt at a new Lisp I have seen is the Lisp Universal Shell (lush), which, despite the name, is actually a high-performance Lisp implementation.
Everything else is just now catching up. Evidence all the effort to fold in Lispy features into Python, Perl, Ruby, etc., etc.
Engineering is about making tradeoffs--something that the designers of Lisp did not understand. If you try to create a completely general language with completely general language constructs, you try to standardize it, and you try to also make it fast, something has to give. And the thing that gives is development time.
Python, Perl, and Ruby can afford to implement lots of Lispy things because they aren't also trying to create a language standard and efficient, natively compiled implementations. Java is also implementing lots of Lisp things, but it makes other tradeoffs (which result in it being more cumbersome in some ways).
While Lisp Just Works.
That's a stupid statement: nothing "just works" for everybody. And CommonLisp had lots of problems: scoping, naming, reflection, and code generation are all pretty shaky in CommonLisp. Its standard library also had lots of important omissions. If CommonLisp "just works" for you, consider yourself lucky. Frankly, I think the number of people for whom, say, Python "just works" is considerably larger than the number of people for whom CommonLisp "just works".
If he had managed to get bacteria to arrange themselves in a bulls-eye or heart pattern, that would be sort of neat. Not really science, and not really useful, but sort of neat.
However, what he has actually done is arrange bacteria in a bulls-eye or heart pattern around some sort of preexisting central source(s). The difference may seem slight to a computer scientist, but it is completely different from a biological point of view. Arrangement around a source is a much easier problem.
someone ought to update and simplify the language
on
Practical Common Lisp
·
· Score: 1
CommonLisp has acquired lots of warts and problems over the last two decades. There is a lot of cumbersome stuff in it that isn't needed anymore (e.g., completely general floating point and character set support). There is a lot of stuff that is missing from the standard library: threads, sockets, a foreign function interface, etc. And then there is some stuff that is just poorly designed (e.g., function cells, arrays).
Unfortunately, CommonLisp is likely to be the last big Lisp standard for a long time, simply because the number of people who still bother is so smarll.
It's not that the PDF license lacks teeth, its that the implementations done by open source projects are explicitly permitted, IIRC in a way that can't be arbitrarily revoked by Adobe.
If the license is not explicitly transferable, it's no good. Is Adobe's license transferable?
PDF's umbiquity across platforms, OS versions, and types of device is a critical part of its appeal.
Unfortunately, PDF also has serious problems, legal, practical and technical. The real answer is to develop an alternative open format. SVG is actually a good starting point and probably doesn't require too much effort.
Just a few days ago, there was another breakthrough in fusion. I distinctly remember seeing it on Slashdot. With not one, but two such methods, who knows how far we can go...
Whatever... quite a few open source products implement PDF, and there haven't been any problems with it.
Just because Adobe's license doesn't have teeth or they don't choose to enforce it doesn't mean Microsoft won't. FOSS is not much of a threat to Adobe, but it is to Microsoft.
More to the point, I suspect MS would need to release royalty-free, patent-free, BSD-licensed, cross-platform code libraries to work with their format
Microsoft will likely make the license non-transferable, as they have in the past with other "free" and "open" releases, which means that they can discontinue the "free" version whenever they want.
Google scans those books for business purposes, libraries scan them for library purposes. There are differences between the two.
Now, it is possible (I don't know) that when Google works with libraries, the libraries get copies of the images as if they had scanned the books themselves. In that case, when Google offers to work with a library, it makes sense to accept the offer.
But if Google doesn't actually offer to work with a particular library, or if they aren't interested in the same books as the library, or if there are restrictions on the use of the scanned images that are stricter than if the library scanned the documents themselves, then it makes sense for that library to scan the books themselves.
GPL and especially new BSD code is not "licensed". You don't sign anything.
You enter legally binding agreements all the time without signing anything.
All they are are code that comes with at "you can violate the copyright if you do this" exception to US and international copyright laws.
That kind of "exception" is what we call a "license".
If copyright laws were repealed tomorrow the GPL would be meaningless because nobody at all agreed to any "license".
We should be so lucky. In any case, if copyright laws were repealed tomorrow, the GPL would be meaningless simply because it doesn't impose any conditions unrelated to your use and distribution of the code on you. However, provisions of other software licenses would likely remain enforceable.
Globally, the more people use the same tools that I use, the better the tools I use get. Conversely, if fewer and fewer people use the same tools I use, the more they are going to deteriorate.
That's not theoretical: I have been through the death of several platforms that I had invested lots of time and energy in, and it's not a good experience (the fact that they were commercial platforms only made it worse, because when those are gone, they are really gone, no matter how many users there may have been). And people intuitively know that: zealotry grows with how threatened a platform is, and shrinks the larger its user community becomes.
Locally, if people send me Microsoft Word attachments or create IE-only web pages, that's a hassle for me, so convincing them to use the same tools I use makes my life easier (and, hopefully, theirs as well).
Slashdot Mirror
How can a man who's about the size of an ant next to these beasts do such a thing armed with only a sword and a bow and arrow? That's for you to find out."
I don't know, but it probably involves lots of skeleton keys and switches.
If you program uses a GUI then you are pretty much out of luck. Sure you could use a cross platform gui library but even that is not as clean of a solution as Java.
Actually, several existing cross-platform GUI toolkits for C++ are far better and more predictable foundations on which to build cross-platform apps than Java. Furthermore, they give you the choice of writing a tiny bit of conditionalized platform specific code, resulting in a great improvement in quality.
Java's cross-platform capabilities were nice when it first came out in the mid-90's and there were no good C++ GUI toolkits for UNIX. That's why UNIX users flocked to it. Today, Java is not a good cross-platform solution anymore in comparison.
No you don't. Recent Linpack benchmarks have shown Java can match C/C++ in terms of math performance in many benchmarks. There is no speed disadvantage for this kind of work.
No, there is no speed disadvantage, there is, however, a programming disadvantage: in order to get speed in Java, you can't use any abstractions. Java is a less convenient language for numerical programming than C or Fortran 66.
And (surprise) that's why Sun has been working on Fortress.
On the contrary, almost everything about the development of Java has been handed over to the Java Community Process.
Yes, they handed over almost everything, except for their ownership of Java. Worse, almost everything new that comes out of the JCP ends up effectively being owned by Sun. So, yes, you do have a bunch of dopes that are working for free for Sun and getting less out of it than even your typical corporate researcher; at least those still get paid.
(1) You give up speed for a marginal increase in features. (1b) If speed is not a factor, languages such as OCaml have many more features suitable for high-level programming. OCaml is also slightly faster than Java in general. Thus Java is both more primitive and slower than a language that came out in a similar time frame.
.NET platform proprietary, and anything coming out of Microsoft is cause for concern, but this may still work out.
Yes, OCAML is a much nicer language. As a middle ground, C# does offer lexical closures and parameterized types. OCAML, unfortunately, really dropped the ball on the compilation of parameterized types (which is as broken as it is in Java).
(2) You give up source portability for binary portability. Almost every platform has an ansi-C compiler, yet only a handful support Java, especially if you use a recent library. There are more platforms that support OpenGL than Java3D, for example.
I'm not sure that really matters; no new compiler is going to run everywhere instantly.
(3) A company controls your language. The future of Java is at the whim of a single for-profit entity. Furthermore, this entity has displayed that it wants to control the Java language and the Java platform to the greatest extent possible.
Yes, this is a huge problem. So far, it looks like the C# language and standard library are going to be open; they are also ISO/ECMA standards. It's unfortunate that Microsoft is making noises about keeping the
(4) It's one of the most difficult languages to interface with C, and it pushes 100% of the glue required to the native language. It is easier to interface Lisp and Haskell with C than Java to C through JNI. Given the large difference between the former pairs, and the small differences between the latter pair, this is pretty ironic,
Again, fully agreed. C#'s native interface is much simpler, much more efficient, and actually gives you built-in language constructs for accessing native data structures (points, layout, etc.).
Thursday, DeMeo said that Alexander had put his hand on DeMeo's knee
You know, when one drunk guy puts his hand on the knee of another drunk guy, it usually means that there is something else going on than GTA phantasies...
The code Microsoft gives away is also "in some ways useful".
I think that Apple is clever if they are using arguments like
Apple is doubtlessly clever in all sorts of ways. But it isn't their cleverness that's at issue, at issue is their claims:
They aren't using an open source development model, they are throwing out patches every now and then. (They would also not be first even if they were using an OS development model.)
I don't care what Apple does, I just want them to be honest about what they are doing.
Os X powers a lot of desktops... But then again, I only roughly follow the stats.
Nobody knows for certain, but my impression is they are about equal. OSX has largely disappeared from Europe, and Linux is common on the desktop in university and business environments. Overall, both seem to be around 2-3%.
Sun is not to be trusted when it comes to programming languages as far as I'm concerned. They had promised to have Java standardized by a standards body and instead withdrew and are keeping tight control of the language. They will likely do the same thing again, all in the name of "ensuring compatibility", of course.
Whose comment were you replying to? I'd think you were trolling, but I can't even figure out what point you're trying to make.
Your argument was something like: "Apple did what they were legally required to under open source licenses, and they did the minimum they could legally get away with, so what are you complaining about?". That argument is wrong on two counts.
But Apple is not legally required to return source code under open source licenses. They are opening up the source code in order to augment their limited engineering staff with outside contributions. But, violating the spirit of open source development, they do it in such a way that it isn't useful to others.
Um, yeah, they're in BUSINESS! They try to capture market share, sell products and make money.
That's fine, as long as they don't advertise themselves as open source friendly.
As per them being an open source contributor, at least they give some code back. There are not all that many people who contribute anything at all.
Microsoft has been giving away platform specific source code since long before Apple.
As per Apple marketing itself 'against' Linux... HAHAHA ROFLOL. So you're saying they're trying to steal linux users?
No, they are trying to convert some of the buzz surrounding Linux into OS X sales. The argument is something like "why consider Linux if you could use OS X".
The tiny linux desktop market?
It may be tiny, but it's apparently about the same size as the OS X desktop market.
Have you tried using Os X?
I have been using OS X on and off for several years and have an OS X machine sitting right here. I'm unimpressed.
So, in your opinion, which for-profit corporations are doing a better job, and why? I'm genuinely curious who you would select as providing a better example, and what others would think of your selection(s).
Redhat (numerous contributions), Novell/SuSE (Mono, among many others), and IBM (Eclipse, GCC, kernel, Jikes, etc.) have contributed enormously. A true open source contributor doesn't view software as a zero-sum game. When IBM donates code to Linux or Java, they know that they help lots of "competitors" with that as well, but they also know that everybody, including themselves, wins overall.
Apple, on the other hand, still seems to view everything in terms of "us vs. the world" (an attitude shared with Sun and Microsoft). Apple is out to beat everybody and show that their technology is supposedly the best (in reality: not even close).
But I don't really care about Jobs's delusions, all I care about is that Apple keeps lying publicly about their innovation and about their support for open source. The fact is that the company doesn't pay for research and the company does not support open source, and to represent themselves as if they did is evil.
I was a customer and fairly heavy user of Lisp. I also contributed to several Lisp implementations and developed two Lisp interpreters myself.
I guess all the people like me just aren't very bright. Unlike you
It has nothing to do with being "bright"; as a serious user of a language and tool, you know whether it's working for you or not, and as someone who has worked on implementations, you know what is possible.
I wasn't exactly alone in my unhappiness with CommonLisp, which is why you got so many "alternative" Lisp efforts (Scheme, extended Scheme, Dylan, ISO Lisp, etc.), and why lots of people stopped using Lisp in the decade from the mid-80's to the mid-90's.
Part of the problem was that Lisp was designed for AI, but AI had moved on and Lisp hadn't changed and adapted to support its new needs. At this point, Python and C++ are actually far better languages for modern AI than Lisp.
Look, I know it's tempting to think that you had the answer and everything would be good if they'd just listened to you... but have you ever considered that there might be more than one reason for the so-called "demise" of Lisp?
Saying "if you don't do X, you will fail" is not equivalent to saying "if you do X, you will succeed". Better engineering would have been necessary, not necessarily sufficient.
Ah good. Always nice to get in a little snipe, isn't it? [...] might be slightly less horrifying if I knew there were some Lispy features being added to the language.
It's not a "snipe", the features are just so blatantly obvious, and they have been there for more than half a dozen years. That's no coincidence either: a lot of ex-Lisp, ex-Smalltalk, and ex-Self people have contributed to Java:
- REPL: beanshell.org (used by DrJava and other IDEs), Jython, or a bunch of other interpreted languages
- incremental development: standard feature in many IDEs (modify the running program), supported via standardized debugging APIs
- dynamic typing: cast to/from Object, class attribute, etc.
- reflection: java.lang.reflect
- dynamic code generation: via class loaders (excellent support libraries)
- functional programming: notationally less convenient, but effectively available via nested classes and used in new collection classes
- macros: hygienic macros have been proposed for Java and a design has been worked out (maybe even an implementation) but deliberately left out
- continuations: not part of CommonLisp and not part of Java either
So, here is where we are today: there are some people still fanatically devoted to CommonLisp; as long as they are vocal and as long as the CommonLisp standard is perceived as "the" Lisp standard by the outside world, no Lisp is going to make it. Scheme is good for what it is, and there are some excellent implementations, but it is too limited for real-world development, although an extended Scheme standard might have a chance. ISO Lisp is what CommonLisp should have been in the 1980's, but it is in serious need of updating (ISO Lisp might be the best starting point for a modern Lisp).OTOH, the JVM and CLR are excellent runtimes, well defined, with multiple implementations, languages that many programmers feel comfortable with, and lots of dynamic language implementations running on top of them (e.g., Python, Smalltalk, and Scheme) that interoperate with those languages.
What we need is for the CommonLisp and Scheme folks to shut up about their old standards and for a bunch of credible language designers to create a new Lisp. But that will probably take another 20 years, when the people who inflicted CommonLisp on us are finally retired. And by that time, programming will hopefully neither consist of pointer manipulation, nor of recursive functions over conses anymore, at least if I have anything to do with it. I would have much rather used a good standard Lisp than the JVM as the basis for my work, but Lisp just wasn't up to it.
I'm not sure about that. From what I understand, open source doesn't mean you have to give other people everything verbatim, and explain the changes. You have to make available the source you based your code on.
False. You don't even have to make the sources available under many open source licenses. For example, Apple is under no obligation to make any of the BSD-licensed code that they ship available, but they do (but for KHTML, which is LGPL, they are required to).
Apple seems to make very few generally useful contributions to open source projects as far as I can tell. Most of the stuff they put out open source is stuff that enhances the value of their platform and only their platform. That's self-serving and doesn't make Apple "the good guys".
That would be fine, but Apple is trying to present itself as a contributor and supporter of open source, not just a user. And that seems like a misrepresentation. And it's not just that, Apple actively tries to market OS X against Linux, claiming (incorrectly) things like that OS X is "the better Linux".
Well, confusion on this point is probably the result of Apple using open source as a marketing gimmick:
While it is doubtlessly good for Apple customers that Apple uses standard and high-quality open source components, they seem to have forgotten about the "contributing useful stuff back to the community" part that goes along with it. Oh, they put out a lot of code, but it's usually not useful: their gcc hacks haven't been useful, their KHTML hacks haven't been, Darwin isn't used much or very useful, etc.
So, we people understand that Apple is a business and doesn't want to help other companies. Now, if only they could be more honest about it in their marketing materials.
Yeah, it's a terrible shame that all those incredibly intelligent mathematicians and engineers behind Lisp didn't have cahiha to advise them about the concept of engineering tradeoffs.
They did, actually. I told them (as did lots of other people) even back when Lisp was more hyped up than Java has ever been and people were dropping $100k for a single Lisp-based workstation. They just weren't listening. The result of their lack of good engineering sense and arrogance was the demise of Lisp and the predictable (and predicted) 20 years of dark ages of C/C++ programming. It just boggles the mind that 20 years later, people like you still don't get it. I guess hindsight isn't 20/20 after all.
I won't even say anything more about Java, since I don't like the language, other than that you seem to know very little about its actual capabilities. For Python vs. Lisp, read Norvig's article.
There are lots of PoE-powered computers: switches, access points, etc. Many of them have processors running at over 100MHz and many megabyte of RAM--more than powerful enough to run software satisfying the computing needs of most people.
So, the only reason why a PoE-powered computer is "amazing" is because what is sold as a PC these days requires a lot of power, and it requires a lot of power because Windows requires a lot of memory, disk space, and CPU.
Based on his past record and interests, I wouldn't get my hopes up. Graham represents the attitudes and narrow focus that has turned off so many people from Lisp in the first place. And for a language designer to comment that he "intends it to be a hundred-year language" is just moronic and show a complete lack of long-term perspective.
The best attempt at a new Lisp I have seen is the Lisp Universal Shell (lush), which, despite the name, is actually a high-performance Lisp implementation.
Everything else is just now catching up. Evidence all the effort to fold in Lispy features into Python, Perl, Ruby, etc., etc.
Engineering is about making tradeoffs--something that the designers of Lisp did not understand. If you try to create a completely general language with completely general language constructs, you try to standardize it, and you try to also make it fast, something has to give. And the thing that gives is development time.
Python, Perl, and Ruby can afford to implement lots of Lispy things because they aren't also trying to create a language standard and efficient, natively compiled implementations. Java is also implementing lots of Lisp things, but it makes other tradeoffs (which result in it being more cumbersome in some ways).
While Lisp Just Works.
That's a stupid statement: nothing "just works" for everybody. And CommonLisp had lots of problems: scoping, naming, reflection, and code generation are all pretty shaky in CommonLisp. Its standard library also had lots of important omissions. If CommonLisp "just works" for you, consider yourself lucky. Frankly, I think the number of people for whom, say, Python "just works" is considerably larger than the number of people for whom CommonLisp "just works".
If he had managed to get bacteria to arrange themselves in a bulls-eye or heart pattern, that would be sort of neat. Not really science, and not really useful, but sort of neat.
However, what he has actually done is arrange bacteria in a bulls-eye or heart pattern around some sort of preexisting central source(s). The difference may seem slight to a computer scientist, but it is completely different from a biological point of view. Arrangement around a source is a much easier problem.
CommonLisp has acquired lots of warts and problems over the last two decades. There is a lot of cumbersome stuff in it that isn't needed anymore (e.g., completely general floating point and character set support). There is a lot of stuff that is missing from the standard library: threads, sockets, a foreign function interface, etc. And then there is some stuff that is just poorly designed (e.g., function cells, arrays).
Unfortunately, CommonLisp is likely to be the last big Lisp standard for a long time, simply because the number of people who still bother is so smarll.
Why would they sue Mac Mall and Club Mac? Those are primarily Apple Macintosh dealers. Tiger Direct isn't.
Apple has a history of (1) encroaching on other people's trademarks and (2) being litigeous. Tiger Direct had reason to be worried.
It's not that the PDF license lacks teeth, its that the implementations done by open source projects are explicitly permitted, IIRC in a way that can't be arbitrarily revoked by Adobe.
If the license is not explicitly transferable, it's no good. Is Adobe's license transferable?
PDF's umbiquity across platforms, OS versions, and types of device is a critical part of its appeal.
Unfortunately, PDF also has serious problems, legal, practical and technical. The real answer is to develop an alternative open format. SVG is actually a good starting point and probably doesn't require too much effort.
Just a few days ago, there was another breakthrough in fusion. I distinctly remember seeing it on Slashdot. With not one, but two such methods, who knows how far we can go...
PDF follows much the same model
Yes, another reason to replace it.
Whatever... quite a few open source products implement PDF, and there haven't been any problems with it.
Just because Adobe's license doesn't have teeth or they don't choose to enforce it doesn't mean Microsoft won't. FOSS is not much of a threat to Adobe, but it is to Microsoft.
More to the point, I suspect MS would need to release royalty-free, patent-free, BSD-licensed, cross-platform code libraries to work with their format
Microsoft will likely make the license non-transferable, as they have in the past with other "free" and "open" releases, which means that they can discontinue the "free" version whenever they want.
Google scans those books for business purposes, libraries scan them for library purposes. There are differences between the two.
Now, it is possible (I don't know) that when Google works with libraries, the libraries get copies of the images as if they had scanned the books themselves. In that case, when Google offers to work with a library, it makes sense to accept the offer.
But if Google doesn't actually offer to work with a particular library, or if they aren't interested in the same books as the library, or if there are restrictions on the use of the scanned images that are stricter than if the library scanned the documents themselves, then it makes sense for that library to scan the books themselves.
GPL and especially new BSD code is not "licensed". You don't sign anything.
You enter legally binding agreements all the time without signing anything.
All they are are code that comes with at "you can violate the copyright if you do this" exception to US and international copyright laws.
That kind of "exception" is what we call a "license".
If copyright laws were repealed tomorrow the GPL would be meaningless because nobody at all agreed to any "license".
We should be so lucky. In any case, if copyright laws were repealed tomorrow, the GPL would be meaningless simply because it doesn't impose any conditions unrelated to your use and distribution of the code on you. However, provisions of other software licenses would likely remain enforceable.
Globally, the more people use the same tools that I use, the better the tools I use get. Conversely, if fewer and fewer people use the same tools I use, the more they are going to deteriorate.
That's not theoretical: I have been through the death of several platforms that I had invested lots of time and energy in, and it's not a good experience (the fact that they were commercial platforms only made it worse, because when those are gone, they are really gone, no matter how many users there may have been). And people intuitively know that: zealotry grows with how threatened a platform is, and shrinks the larger its user community becomes.
Locally, if people send me Microsoft Word attachments or create IE-only web pages, that's a hassle for me, so convincing them to use the same tools I use makes my life easier (and, hopefully, theirs as well).