Clearly one of the biggest concerns is the degree of compatability between.NET and Mono & the lack of many of the API's that exist on Windows - which face it will be the primary development environment.
You are operating under the assumption that the main use of Mono is going to be to allow people to write.NET software. If it were, that would be a serious concern.
But most Mono software will likely be developed using OSS libraries for OSS platforms. It makes no difference to that kind of development what Microsoft does with.NET. Mono is simply a good implementation of a good language that allows them to reuse vast amounts of OSS software with less hassle than if they were writing C/C++ code.
The fact that Mono can also be used to easily port.NET software to Linux is an added bonus.
I'm sure someone will point out that MS will extend.NET beyond the standards thus marginalising Mono
There is no "standard" for.NET; the only standard there is is ECMA C#. Mono's effort to re-implement the.NET APIs is analogous to the Wine/Willows efforts to re-implement the Win32 APIs: it's tracking a moving target. Everybody working on, and using, Mono knows that, and it just is not a problem for the uses people put Mono to.
Will they be concerned enough that Linux and OS X users are worthwhile supporting to make sure it is cross-platform?
Unlike Java, Mono doesn't try to shove cross-platform development down people's throats. If developers want to use Mono to develop Windows-specific applications, that's cool. If developers want to use Mono to develope Linux-specific applications, that's cool, too. If developers want to develop cross-platform applications with Mono, that's cool, too, and Mono supports that, too.
I suspect the biggest use of Mono will be the development of Linux desktop apps using Gnome/Gtk+. Many of those applications will be difficult to port over to Windows because they will rely on Linux-specific features. But that's no different from Gtk+ applications written in C or C++; Mono simply makes it easier to develop such applications by giving developers a choice of using C#.
The second biggest use of Mono will likely be the deployment of applications and libraries developed for Windows on Linux machines. Those applications were not originally written with cross-platform portability in mind, but by supporting Microsoft's APIs well enough, those applications will either work out of the box, or port over easily.
So, Mono gives the programmer the choice between writing cross-platform apps or taking advantage of platform-specific features. That's where the choice belongs, IMO.
There is no reason at all that IM needs to rely on few corporate giants installing centralized IM hubs. The problem is self-created (out of an attempt to tie users into proprietary services).
The solution is simple: corporations wanting to use IM should take control of their IM infrastructure and install one of the open source IM systems (Jabber, IRC, etc.) on an external server, just like they install their own mail servers. Or they can outsource it to one of many hosting companies that support those services.
This is BS. Neither Java nor C# have the equivalents of read, eval, compile,
No, they don't have them "as primitives", but they have the primitives that let you implement those. For example, if you want Lisp-like read and eval functionality, you can use Beanshell.
As I was saying, you may not like the way Java provides dynamic features, but it does provide lots of dynamic features.
or even change-class as language primitives.
I believe the Java debugging interface specifies that, and it works about as well (take that as you like).
Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language.
Well, neither does Java, really. Java specifies an intermediate level representation, somewhat below the source, but way above machine code.
The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. [...] t is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode.
Well, the situation is a little more complex. You don't reflect over machine code, but the VM dynamically maintains a one-to-one correspondence between VM code and machine code.
The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines.
Sorry, but that's not how the JVM or CLR work. They are not arbitrary stack machines, they impose restrictions that make them basically just binary representations of the macro-expanded and canonicalized source code using postfix notation. You compile them using the same high-performance compilation strategies you might use with a C, Fortran, or Lisp source compiler. They are no harder and no easier to parallelize than any other representation of an imperative language.
As for "the" Smalltalk approach, there is no such thing. The original Smalltalk used a stack-based bytecode interpreter, recent versions of Smalltalk (and Self) are using the same JIT approach as Java. I don't know of any Lisp system using a high-performnce JIT (other than those based on the JVM or CLR, of course), and I think that's a major problem with Lisp.
Java's choice of "binary postfix program representation after canonicalization" instead of Lisp's "weakly parsed uncanonicalized symbols-plus-lists" seems to be a winning combination: manipulating code at that level is slightly less intuitive, but it avoids many of the complexities and limitations of Lisp code walkers. As a result, people have been able to implement things in bullet proof was in Java that ended up being at best flaky using code walkers.
Let me just be clear again: I'm not saying that Java is "better" than Lisp, or worse than Lisp, In fact, I'm pretty neutral on the matter: I think both systems have some brilliant ideas, and both systems have some absolutely awful design flaws. Neither language meets my standards for careful language design or good taste. But I do appreciate the good points each has to offer and I believe both languages and systems have contributed significantly to progress in the state of the art.
All Common Lisp implementations have structures, arrays, hashtables, and CLOS objects as part of the standard.
I didn't say CommonLisp lacked data structures. I said that I think Lisp syntax is a compromise for representing data structures.
The days of Lisps using lists as their main data structures (in anything but the prototyping phases of coding) are long gone.
Yes, and that's why Lisp syntax has also become somewhat less important. Lisp syntax is a huge advantage as long as almost everything is lists. But the more diverse and complicated the set of data structures you use becomes, the more Lisp syntax loses its advantage.
Lisp is and will always be a better functional language than Java/C#
I agree, and I prefer Lisp syntax myself. I hope one can eventually come up with a Lisp-like system that combines the advantages of Lisp syntax with the practicality and completeness of the C# runtime, libraries, and specification. Since Lisp syntax has been used even for C-like languages, it seems like it should be fairly easy. Also, I believe Microsoft is even thinking about improving support for fully dynamically typed languages (like Scheme and Smalltalk), so then one would really have the best of both worlds: full support for Lisp styles with full acess to C#-like syntax and semantics.
Could you elaborate on that? It doesn't seem correct to me. Java/C# (at least in C# 1.0, the current version) do not have closures. Neither C# or java will ever have the code/data unity that Lisp has.
Well, just telegraphically...
Java has a pretty close approximation to closures (nested classes).
Both Java and C# can be extended with closures without changes to the runtime.
I think support for lexical closures is planned for the CLR (I don't know about C#).
Closures are probably not a necessary part of being a dynamic language (PHP doesn't have them, neither did many versions of Lisp).
Both Java and C# have full dynamic type information and full reflection; the reflection system of standard CommonLisp has some limitations in comparison (although individual CommonLisp implementations often provided implementation-specific workarounds).
Both Java and C# have full dynamic code generation and full reflection of existing, compiled code (you can analyze code from other methods/classes); Lisp's dynamic code generation and code reflection are more limited.
Lisp syntax is nice, and you can program the JVM and CLR with Lisp syntax. But while I fully believe that Lisp syntax is great for programming, I think for data structures, it is a compromise, and XML and similar standard representations fulfill similar functions for other languages.
So, Java and C# aren't exactly like Lisp--they have made different choices, and you may or may not like the overall package. They are clearly not "dynamic" in the important sense of being "interactive" by default (although bsh helps). But in some ways (reflection, dynamic code generation, etc.), I think they are arguably better dynamic languages than Lisp ever was.
If the Lisp community ever got its act together and actually learned from Java/C#, they could produce a great response, something that combines the best of Java/C# and Lisp. But I doubt that's going to happen any time soon.
Yes, we know that from economics. However, just because there are some languages that may each be optimal under different circumstances doesn't mean that every language is optimal for something.
Perl can be difficult to debug. It's one of those "wide or deep" questions: you can have an extremely simple syntax, and require a ton of code to describe what you mean to do, or you can have a rich syntax and say it more succinctly (even more descriptively, given skill on the part of the writer and the reader).
Perl's syntactic problems go beyond having an expressive and complex syntax: there are a number of syntactic misfeatures in Perl that only cause problems but don't make Perl code any more succinct. The good thing is that Perl6 is addressing many of them, which in itself tells you that Perl5's syntax could benefit from improvement.
and all that the eye can see is a nearly-identical syntax to Java.
The fact that PHP has the same bracket-and-semicolons style as Java and the C family doesn't mean that the languages are all that similar.
why not just switch to Java? It's all that PHP5 has and more.
It's the "and more" part that is a problem: PHP is a much simpler language to learn and use, and for most people who create web applications, that's important.
Another problem with Java is the license; PHP not only has an unrestricted and open specification, it also has a good, open source implementation, both things that Java lacks.
exceptions (albeit weak ones)
Good. In addition to being more cumbersome for simple tasks, Java has a number of design problems, its exception system being one of them.
Benchmarks say that performance is pretty good. Is this another sign that dynamic languages are the future?"
No more and no less so than they have ever been: dynamic languages are a good choice for many, but not all applications. And dynamic languages have been enormously popular for decades, with far programmers using them than using static languages; PHP just follows in that tradition.
What is more interesting is the emergence of dynamic languages which use static type systems by default: in their runtimes, Java and C# have more complete and better defined dynamic features than Lisp, but they still give the user a simple static type system by default. It remains to be seen whether that gives you the best of both worlds or the worst. Fortunately, their runtimes are well-defined enough that one isn't limited to the specific choices that the currently popular languages running on top of them have made.
Well, if the crux of your argument is that these third-party developers are encouraged to act irresponsibly by Microsoft's ability to encode "ignorance" into Windows APIs, libraries, coding styles, frameworks... then why is Mono being developed based on a direct translation of the Microsoft.NET framework??
Microsoft has done many things. Microsoft's poorly thought out, corner-cutting APIs are their historical APIs, what made them grow fast and successful initially. Since then, they have hired a lot of smart people and they have gotten better. Of course, Microsoft's costs and time-to-market have skyrocketed correspondingly, so they are now as slow as everybody else. Microsoft is now at grave risk of being eliminated by a new, fast-moving, corner-cutting competitor without backwards compatibility woes, just like they themselves used to be. And there is nothing they can do about it.
Note, incidentally, that Mono's implementation of the.NET framework is mostly for compatibility and easy migration. Most open source use of Mono is based primarily on Gnome and other OSS APIs, which are, in my opinion, superior to.NET.
Or let's talk about NIS and NFS. Are these representative of high security? Pulease. This system believes you are who you say you are just because you say so!
First of all, you have to separate APIs and implementation. NFS was quite clearly a poorly designed system, but it didn't introduce any new APIs that application developers had to deal with. Furthermore, NFS's poor design is a testament to Sun's incompetence; the UNIX designers didn't have anything to do with it and they seemed by and large pretty annoyed at what Sun and Berkeley had done to UNIX in general. But the fact that NFS's poor design didn't affect UNIX application programmers significantly in the long run remains a testament to the soundness of the UNIX design philosophy.
Well fine. I'll challenge you on the Kernel too. Ah yes, lets start with the "setuid bit". Now there's a fine security model. [...] But here we are 20 years down the road, and security Access Control mechanisms are a shambles in Linux.
I'm sure lots of people at Microsoft think the same way, and that's just fine as far as I'm concerned.
But what do you do with links to external schemes? Whitelisting means the user has to jump through hoops to get new protocols working.
And I think that is as it should be: new protocols shouldn't just sprout up overnight. When a new protocol is on its way to being standardized, then the next release of Mozilla can incorporate preliminary support for it. It can even be part of an automatic update.
IMO they should have done something similar to the file download dialog: You're about to open "scheme:something". () open with default application, () choose application, () don't open. [] remember my choice for this scheme.
I think that would have been an acceptable solution from a security point of view, although, frankly, most users would probably choose "open with default application" anyway, since they are so used to it.
In terms of web standards, however, I think that the user should have to "jump through hoops" to get new protocols working.
To wit -- Here's a little history lesson on why you're wrong. And when Linux starts to get the number and volume of enterprise-level applications that Windows has, these types of history lessons will prove useful. But don't just take the easy way out and say "Yeah Windows sucks" and not try to learn about the mistakes that might just be made again without some perspective.
UNIX has had a clean and simple separation between administrator and user privileges since the 1970's, and Linux uses the same mechanisms. UNIX and Linux have faced the most formidable opponent trying to break down that barrier over decades: the college student, who can spend hours a day trying to break into university systems. And they did. And UNIX developers fixed the bugs and adapted the security models.
The people who need a history lesson are Microsoft developers. They just started hacking some time in the 1980's, giving a damn about security or any of the other hard stuff. That kind of ignorance got hardcoded into Windows APIs, libraries, documentation, coding styles, frameworks, and instructional materials. That's why most third party developers for Windows put files all over the place and don't pay any attention to security either.
It's not surprising Microsoft and Microsoft developers managed to grind out popular GUI apps quickly--they cut corners on all the hard stuff and didn't even know it. The UNIX nerds at the same time were saying "this isn't the right way of doing it": they were looking 10-20 years down the road with the experience they already had, but because they were thinking long-term, Microsoft beat them on time to market and price. That's why Windows, and not UNIX, rules the desktop today. But ignorance and backwards-compatibility issues are catching up with Microsoft, and it seems quite likely to me that their fall is going to be just as spectacular as their rise.
Unlike most of those, he's implemented those ideas, and has been spent implementing those- in real, live, usable code- for the last 30-some years
Kay has done more than a lot of visionaries implementing his ideas. But have you actually tried to use Squeak or any of his other projects? They make neat demos. They demonstrate ideas very nicely. But I haven't found the "real, live, usable".
Sadly, I find Squeak not even to be very useful for purposes where it should actually excel: user interface research and prototyping. While it has some nifty features, many parts of the system are quite messy, integration with standard desktop functionality is sadly lacking, and a lot of standard GUI functionality is either not there at all, or it is poorly documented and flaky.
Kay makes good points, and he shows good demos. But he is still stuck in the "visionary" stage, and we really need more work to bring visions to real people. If he cared more about that, he'd implement his ideas closer to where people are working. Python/Gnome or C#/Windows or OSX/Quartz are powerful and easy enough to use that he could do everything in them. I'm wondering whether some visionaries aren't just afraid of putting their ideas into practice: too much work, and users might not actually like it.
If you develop for Windows, you have to develop for it as it is. That is, you have to expect that things aren't secure in the way you like them to be or don't work the way you might like them to work.
The attitude Mozilla should have that they should only call library and OS interfaces on each OS that they can have a reasonable expectation to be safe and secure in practice. That is, they need to orient themselves not only based on what they think an API ought to do or how the API ought to behave, but what it actually does. If they don't, then some of the blame for security holes will fall on Mozilla.
In this case, the Mozilla developers knew what the API they were calling did. As I understand it, they had even known of the possibility of the shell: exploit for quite some time. Furthermore, the security hole could have been fixed in Mozilla, yet the Mozilla chose not to do anything about it. The secure thing for Mozilla to have done would have been only to hand over a few known protocols to the OS for handling (mailto: and maybe ftp:), and only if Mozilla first verified that the entire URI was, in fact, valid and harmless.
In this case, it appears that the Mozilla developers had known about the shell: exploit for a couple of years but, instead of protecting users from it, just decided it was Microsoft's problem and left it at that.
Maybe that's better in some academic sense than people accidentally creating security holes they don't know about, but it isn't all that impressive either.
"The only areas where we are big are the desktop and Office, but the perception is that those are saturated markets. Therefore, our stock price has stopped growing and we need to give the market an excuse to pump up our price a little more."
As for the desktop usage percentages, without detailed statements of methodology and definitions of terms (what exactly is a "desktop user"?), Gartner's nubers are meaningless even if they collected their numbers correctly (which, itself, seems doubtful).
I agree with Kay. I also think Kay has made enormous contributions in the past. And I think that Squeak, his main project, is an enormously valuable tool. But, sadly,for all the great ideas that have gone into Squeak (and Kay's other work), I have not found the implementations he or others have produced to be very useful. Having great ideas is no good if you don't manage to implement them in ways that people can actually use.
So, we have those who do the work implementing things that real people actually use (Gnome, KDE, Sun, Microsoft, Apple, etc.), and then we have those who talk about great ideas and grand schemes, but whose implementations aren't all that useful (Kay, the various "usability gurus", etc.). The first group doesn't do enough background research and/or just likes to pretend for PR reasons that they are "innovative". The second group likes to complain about how awful things are but then just doesn't quite get their act together producing something more useful than they do.
How can we improve things? Things get better the more like Kay take actual implementations a little more seriously and people in "industry" stop reinventing the wheel. And software developers and end users need to become a bit more informed about the products they use and make better choices, instead of just buying what's popular or hip.
If the brand new voting machines don't work, who do you think has to deal with it? The "government officials". They probably also get part of the blame, even though the selection of these machines was probably ultimately made by politicians for "political" reasons.
The traditional way of creating this kind of government-related technology is through long term, well-funded government efforts. In different words, voting machines should be developed by an agency, they should be given time to get lots of input, and the software should be public and free afterwards. Unfortunately, even though those shouldn't be ideological issues, they are in the current climate: to many politicians, it is axiomatic that private enterprise is more efficient, and for government to do anything substantial amount to communism in their view.
However, a more baisc question is and remains: why do we need this at all? Paper and pen ballots work just fine and they are easy to audit. If we want technology in there, we can scan those ballots and put the scanned images on-line for everybody to recount at their leisure.
So, let me get this straight: in four years, we'll be able to jump on the Windows upgrade treadmill and run Linux code on servers costing thousands of dollars in Microsoft licensing fees, requiring at least 1Gbyte of RAM, and still be forced to deal with Microsoft's system admin tools. And why would I want to do that?
The problem with Windows isn't the lack of features, it is that it already has far too many. Adding Linux into the mix makes the problem with Windows worse, not better.
Before people go all gaga over this rash of new features from Apple and Sun, do some research. Transparency, shadows, overlays, desktops on 3D virtual presences, portals, 3D environments, etc. go back years and years, and many researchers have contributed to them. (You can find many of these features demonstrated in Squeak.)
This stuff is being shipped commercially now because you can now run it on PC hardware costing $1000-2000, instead of requiring high-end SGI workstations, as it did just a decade ago.
Apple does have a short-term advantage in this area: as part of their deal with NeXT, they got a Postscript/PDF-based window system, which happens to do these sorts of things already. But they don't have any long-term technical advantage: Microsoft has added similar APIs to Windows, and X11 also is moving towards full support of transparency and blending throughout the entire window system. Whose system will end up being the best long-term choice remains for the market to decide; personally, I think Apple's PDF-based system is the most cumbersome of the bunch.
Windows has had the ability to draw transparent windows since 2000. However, there's a limit to how far they can go.
Transparency in window systems is an idea that goes back almost as long as window systems have been around. People were even asking for it in the earliest versions of X11.
The only reason it hasn't been implemented more widely is because hardware hasn't really been up to it and applications didn't need it. Those applications that really did need it just used special graphics and visualization libraries.
Apple has this feature not because they had some great new insight, but they actually just got it essentially for free with the PostScript-based window system they acquired from NeXT, which was designed some time in the early 1980's and is based on stuff from Adobe. And now that hardware is up to handling it, it will just be a standard component of desktop window systems.
There's actually quite a bit of data about the danger of ingesting, inhaling, or otherwise coming into contact with plutonium.
The only level of toxicity we can determine with any degree of reliability is whether an animal falls over dead quickly if it is exposed to enough of something. That's not just true for plutonium, it's actually true for most substances. That's why drugs have to get withdrawn from the market regularly because they turn out to be dangerous despite having been studied previously for years in careful trials. And substances other than drugs don't even receive anywhere near the same level of safety testing.
Safety data like the one you refer to is useful to warn people about things that are known to have a high probability of resulting in injury or death. It is idiotic to think, however, as you seem to, that the things they don't list are therefore known to be safe.
Slashdot Mirror
Clearly one of the biggest concerns is the degree of compatability between .NET and Mono & the lack of many of the API's that exist on Windows - which face it will be the primary development environment.
.NET software. If it were, that would be a serious concern.
.NET. Mono is simply a good implementation of a good language that allows them to reuse vast amounts of OSS software with less hassle than if they were writing C/C++ code.
.NET software to Linux is an added bonus.
.NET beyond the standards thus marginalising Mono
.NET; the only standard there is is ECMA C#. Mono's effort to re-implement the .NET APIs is analogous to the Wine/Willows efforts to re-implement the Win32 APIs: it's tracking a moving target. Everybody working on, and using, Mono knows that, and it just is not a problem for the uses people put Mono to.
You are operating under the assumption that the main use of Mono is going to be to allow people to write
But most Mono software will likely be developed using OSS libraries for OSS platforms. It makes no difference to that kind of development what Microsoft does with
The fact that Mono can also be used to easily port
I'm sure someone will point out that MS will extend
There is no "standard" for
Will they be concerned enough that Linux and OS X users are worthwhile supporting to make sure it is cross-platform?
Unlike Java, Mono doesn't try to shove cross-platform development down people's throats. If developers want to use Mono to develop Windows-specific applications, that's cool. If developers want to use Mono to develope Linux-specific applications, that's cool, too. If developers want to develop cross-platform applications with Mono, that's cool, too, and Mono supports that, too.
I suspect the biggest use of Mono will be the development of Linux desktop apps using Gnome/Gtk+. Many of those applications will be difficult to port over to Windows because they will rely on Linux-specific features. But that's no different from Gtk+ applications written in C or C++; Mono simply makes it easier to develop such applications by giving developers a choice of using C#.
The second biggest use of Mono will likely be the deployment of applications and libraries developed for Windows on Linux machines. Those applications were not originally written with cross-platform portability in mind, but by supporting Microsoft's APIs well enough, those applications will either work out of the box, or port over easily.
So, Mono gives the programmer the choice between writing cross-platform apps or taking advantage of platform-specific features. That's where the choice belongs, IMO.
After all, we found meteorites from Mars that contained fossilized bacteria.
I think the scientific community is pretty divided pretty significantly on that.
There is no reason at all that IM needs to rely on few corporate giants installing centralized IM hubs. The problem is self-created (out of an attempt to tie users into proprietary services).
The solution is simple: corporations wanting to use IM should take control of their IM infrastructure and install one of the open source IM systems (Jabber, IRC, etc.) on an external server, just like they install their own mail servers. Or they can outsource it to one of many hosting companies that support those services.
And that's why we use XML?
XML seems to be largely a more cumbersome form of Lisp syntax, and both have many of the same strengths and weaknesses.
Fortunately, "we" have lots of other choices for representing data. "We" should use the best syntax and tools for each job.
This is BS. Neither Java nor C# have the equivalents of read, eval, compile,
No, they don't have them "as primitives", but they have the primitives that let you implement those. For example, if you want Lisp-like read and eval functionality, you can use Beanshell.
As I was saying, you may not like the way Java provides dynamic features, but it does provide lots of dynamic features.
or even change-class as language primitives.
I believe the Java debugging interface specifies that, and it works about as well (take that as you like).
Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language.
Well, neither does Java, really. Java specifies an intermediate level representation, somewhat below the source, but way above machine code.
The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. [...] t is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode.
Well, the situation is a little more complex. You don't reflect over machine code, but the VM dynamically maintains a one-to-one correspondence between VM code and machine code.
The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines.
Sorry, but that's not how the JVM or CLR work. They are not arbitrary stack machines, they impose restrictions that make them basically just binary representations of the macro-expanded and canonicalized source code using postfix notation. You compile them using the same high-performance compilation strategies you might use with a C, Fortran, or Lisp source compiler. They are no harder and no easier to parallelize than any other representation of an imperative language.
As for "the" Smalltalk approach, there is no such thing. The original Smalltalk used a stack-based bytecode interpreter, recent versions of Smalltalk (and Self) are using the same JIT approach as Java. I don't know of any Lisp system using a high-performnce JIT (other than those based on the JVM or CLR, of course), and I think that's a major problem with Lisp.
Java's choice of "binary postfix program representation after canonicalization" instead of Lisp's "weakly parsed uncanonicalized symbols-plus-lists" seems to be a winning combination: manipulating code at that level is slightly less intuitive, but it avoids many of the complexities and limitations of Lisp code walkers. As a result, people have been able to implement things in bullet proof was in Java that ended up being at best flaky using code walkers.
Let me just be clear again: I'm not saying that Java is "better" than Lisp, or worse than Lisp, In fact, I'm pretty neutral on the matter: I think both systems have some brilliant ideas, and both systems have some absolutely awful design flaws. Neither language meets my standards for careful language design or good taste. But I do appreciate the good points each has to offer and I believe both languages and systems have contributed significantly to progress in the state of the art.
All Common Lisp implementations have structures, arrays, hashtables, and CLOS objects as part of the standard.
I didn't say CommonLisp lacked data structures. I said that I think Lisp syntax is a compromise for representing data structures.
The days of Lisps using lists as their main data structures (in anything but the prototyping phases of coding) are long gone.
Yes, and that's why Lisp syntax has also become somewhat less important. Lisp syntax is a huge advantage as long as almost everything is lists. But the more diverse and complicated the set of data structures you use becomes, the more Lisp syntax loses its advantage.
Lisp is and will always be a better functional language than Java/C#
I agree, and I prefer Lisp syntax myself. I hope one can eventually come up with a Lisp-like system that combines the advantages of Lisp syntax with the practicality and completeness of the C# runtime, libraries, and specification. Since Lisp syntax has been used even for C-like languages, it seems like it should be fairly easy. Also, I believe Microsoft is even thinking about improving support for fully dynamically typed languages (like Scheme and Smalltalk), so then one would really have the best of both worlds: full support for Lisp styles with full acess to C#-like syntax and semantics.
Could you elaborate on that? It doesn't seem correct to me. Java/C# (at least in C# 1.0, the current version) do not have closures. Neither C# or java will ever have the code/data unity that Lisp has.
Well, just telegraphically...
Java has a pretty close approximation to closures (nested classes).
Both Java and C# can be extended with closures without changes to the runtime.
I think support for lexical closures is planned for the CLR (I don't know about C#).
Closures are probably not a necessary part of being a dynamic language (PHP doesn't have them, neither did many versions of Lisp).
Both Java and C# have full dynamic type information and full reflection; the reflection system of standard CommonLisp has some limitations in comparison (although individual CommonLisp implementations often provided implementation-specific workarounds).
Both Java and C# have full dynamic code generation and full reflection of existing, compiled code (you can analyze code from other methods/classes); Lisp's dynamic code generation and code reflection are more limited.
Lisp syntax is nice, and you can program the JVM and CLR with Lisp syntax. But while I fully believe that Lisp syntax is great for programming, I think for data structures, it is a compromise, and XML and similar standard representations fulfill similar functions for other languages.
So, Java and C# aren't exactly like Lisp--they have made different choices, and you may or may not like the overall package. They are clearly not "dynamic" in the important sense of being "interactive" by default (although bsh helps). But in some ways (reflection, dynamic code generation, etc.), I think they are arguably better dynamic languages than Lisp ever was.
If the Lisp community ever got its act together and actually learned from Java/C#, they could produce a great response, something that combines the best of Java/C# and Lisp. But I doubt that's going to happen any time soon.
All languages are a tradeoff.
Yes, we know that from economics. However, just because there are some languages that may each be optimal under different circumstances doesn't mean that every language is optimal for something.
Perl can be difficult to debug. It's one of those "wide or deep" questions: you can have an extremely simple syntax, and require a ton of code to describe what you mean to do, or you can have a rich syntax and say it more succinctly (even more descriptively, given skill on the part of the writer and the reader).
Perl's syntactic problems go beyond having an expressive and complex syntax: there are a number of syntactic misfeatures in Perl that only cause problems but don't make Perl code any more succinct. The good thing is that Perl6 is addressing many of them, which in itself tells you that Perl5's syntax could benefit from improvement.
and all that the eye can see is a nearly-identical syntax to Java.
The fact that PHP has the same bracket-and-semicolons style as Java and the C family doesn't mean that the languages are all that similar.
why not just switch to Java? It's all that PHP5 has and more.
It's the "and more" part that is a problem: PHP is a much simpler language to learn and use, and for most people who create web applications, that's important.
Another problem with Java is the license; PHP not only has an unrestricted and open specification, it also has a good, open source implementation, both things that Java lacks.
exceptions (albeit weak ones)
Good. In addition to being more cumbersome for simple tasks, Java has a number of design problems, its exception system being one of them.
Benchmarks say that performance is pretty good. Is this another sign that dynamic languages are the future?"
No more and no less so than they have ever been: dynamic languages are a good choice for many, but not all applications. And dynamic languages have been enormously popular for decades, with far programmers using them than using static languages; PHP just follows in that tradition.
What is more interesting is the emergence of dynamic languages which use static type systems by default: in their runtimes, Java and C# have more complete and better defined dynamic features than Lisp, but they still give the user a simple static type system by default. It remains to be seen whether that gives you the best of both worlds or the worst. Fortunately, their runtimes are well-defined enough that one isn't limited to the specific choices that the currently popular languages running on top of them have made.
Well, if the crux of your argument is that these third-party developers are encouraged to act irresponsibly by Microsoft's ability to encode "ignorance" into Windows APIs, libraries, coding styles, frameworks... then why is Mono being developed based on a direct translation of the Microsoft .NET framework??
.NET framework is mostly for compatibility and easy migration. Most open source use of Mono is based primarily on Gnome and other OSS APIs, which are, in my opinion, superior to .NET.
Microsoft has done many things. Microsoft's poorly thought out, corner-cutting APIs are their historical APIs, what made them grow fast and successful initially. Since then, they have hired a lot of smart people and they have gotten better. Of course, Microsoft's costs and time-to-market have skyrocketed correspondingly, so they are now as slow as everybody else. Microsoft is now at grave risk of being eliminated by a new, fast-moving, corner-cutting competitor without backwards compatibility woes, just like they themselves used to be. And there is nothing they can do about it.
Note, incidentally, that Mono's implementation of the
Or let's talk about NIS and NFS. Are these representative of high security? Pulease. This system believes you are who you say you are just because you say so!
First of all, you have to separate APIs and implementation. NFS was quite clearly a poorly designed system, but it didn't introduce any new APIs that application developers had to deal with. Furthermore, NFS's poor design is a testament to Sun's incompetence; the UNIX designers didn't have anything to do with it and they seemed by and large pretty annoyed at what Sun and Berkeley had done to UNIX in general. But the fact that NFS's poor design didn't affect UNIX application programmers significantly in the long run remains a testament to the soundness of the UNIX design philosophy.
Well fine. I'll challenge you on the Kernel too. Ah yes, lets start with the "setuid bit". Now there's a fine security model. [...] But here we are 20 years down the road, and security Access Control mechanisms are a shambles in Linux.
I'm sure lots of people at Microsoft think the same way, and that's just fine as far as I'm concerned.
But what do you do with links to external schemes? Whitelisting means the user has to jump through hoops to get new protocols working.
And I think that is as it should be: new protocols shouldn't just sprout up overnight. When a new protocol is on its way to being standardized, then the next release of Mozilla can incorporate preliminary support for it. It can even be part of an automatic update.
IMO they should have done something similar to the file download dialog: You're about to open "scheme:something". () open with default application, () choose application, () don't open. [] remember my choice for this scheme.
I think that would have been an acceptable solution from a security point of view, although, frankly, most users would probably choose "open with default application" anyway, since they are so used to it.
In terms of web standards, however, I think that the user should have to "jump through hoops" to get new protocols working.
To wit -- Here's a little history lesson on why you're wrong. And when Linux starts to get the number and volume of enterprise-level applications that Windows has, these types of history lessons will prove useful. But don't just take the easy way out and say "Yeah Windows sucks" and not try to learn about the mistakes that might just be made again without some perspective.
UNIX has had a clean and simple separation between administrator and user privileges since the 1970's, and Linux uses the same mechanisms. UNIX and Linux have faced the most formidable opponent trying to break down that barrier over decades: the college student, who can spend hours a day trying to break into university systems. And they did. And UNIX developers fixed the bugs and adapted the security models.
The people who need a history lesson are Microsoft developers. They just started hacking some time in the 1980's, giving a damn about security or any of the other hard stuff. That kind of ignorance got hardcoded into Windows APIs, libraries, documentation, coding styles, frameworks, and instructional materials. That's why most third party developers for Windows put files all over the place and don't pay any attention to security either.
It's not surprising Microsoft and Microsoft developers managed to grind out popular GUI apps quickly--they cut corners on all the hard stuff and didn't even know it. The UNIX nerds at the same time were saying "this isn't the right way of doing it": they were looking 10-20 years down the road with the experience they already had, but because they were thinking long-term, Microsoft beat them on time to market and price. That's why Windows, and not UNIX, rules the desktop today. But ignorance and backwards-compatibility issues are catching up with Microsoft, and it seems quite likely to me that their fall is going to be just as spectacular as their rise.
Unlike most of those, he's implemented those ideas, and has been spent implementing those- in real, live, usable code- for the last 30-some years
Kay has done more than a lot of visionaries implementing his ideas. But have you actually tried to use Squeak or any of his other projects? They make neat demos. They demonstrate ideas very nicely. But I haven't found the "real, live, usable".
Sadly, I find Squeak not even to be very useful for purposes where it should actually excel: user interface research and prototyping. While it has some nifty features, many parts of the system are quite messy, integration with standard desktop functionality is sadly lacking, and a lot of standard GUI functionality is either not there at all, or it is poorly documented and flaky.
Kay makes good points, and he shows good demos. But he is still stuck in the "visionary" stage, and we really need more work to bring visions to real people. If he cared more about that, he'd implement his ideas closer to where people are working. Python/Gnome or C#/Windows or OSX/Quartz are powerful and easy enough to use that he could do everything in them. I'm wondering whether some visionaries aren't just afraid of putting their ideas into practice: too much work, and users might not actually like it.
If you develop for Windows, you have to develop for it as it is. That is, you have to expect that things aren't secure in the way you like them to be or don't work the way you might like them to work.
The attitude Mozilla should have that they should only call library and OS interfaces on each OS that they can have a reasonable expectation to be safe and secure in practice. That is, they need to orient themselves not only based on what they think an API ought to do or how the API ought to behave, but what it actually does. If they don't, then some of the blame for security holes will fall on Mozilla.
In this case, the Mozilla developers knew what the API they were calling did. As I understand it, they had even known of the possibility of the shell: exploit for quite some time. Furthermore, the security hole could have been fixed in Mozilla, yet the Mozilla chose not to do anything about it. The secure thing for Mozilla to have done would have been only to hand over a few known protocols to the OS for handling (mailto: and maybe ftp:), and only if Mozilla first verified that the entire URI was, in fact, valid and harmless.
In this case, it appears that the Mozilla developers had known about the shell: exploit for a couple of years but, instead of protecting users from it, just decided it was Microsoft's problem and left it at that.
Maybe that's better in some academic sense than people accidentally creating security holes they don't know about, but it isn't all that impressive either.
The translation of that "expectation" is:
"The only areas where we are big are the desktop and Office, but the perception is that those are saturated markets. Therefore, our stock price has stopped growing and we need to give the market an excuse to pump up our price a little more."
As for the desktop usage percentages, without detailed statements of methodology and definitions of terms (what exactly is a "desktop user"?), Gartner's nubers are meaningless even if they collected their numbers correctly (which, itself, seems doubtful).
I agree with Kay. I also think Kay has made enormous contributions in the past. And I think that Squeak, his main project, is an enormously valuable tool. But, sadly,for all the great ideas that have gone into Squeak (and Kay's other work), I have not found the implementations he or others have produced to be very useful. Having great ideas is no good if you don't manage to implement them in ways that people can actually use.
So, we have those who do the work implementing things that real people actually use (Gnome, KDE, Sun, Microsoft, Apple, etc.), and then we have those who talk about great ideas and grand schemes, but whose implementations aren't all that useful (Kay, the various "usability gurus", etc.). The first group doesn't do enough background research and/or just likes to pretend for PR reasons that they are "innovative". The second group likes to complain about how awful things are but then just doesn't quite get their act together producing something more useful than they do.
How can we improve things? Things get better the more like Kay take actual implementations a little more seriously and people in "industry" stop reinventing the wheel. And software developers and end users need to become a bit more informed about the products they use and make better choices, instead of just buying what's popular or hip.
If the brand new voting machines don't work, who do you think has to deal with it? The "government officials". They probably also get part of the blame, even though the selection of these machines was probably ultimately made by politicians for "political" reasons.
The traditional way of creating this kind of government-related technology is through long term, well-funded government efforts. In different words, voting machines should be developed by an agency, they should be given time to get lots of input, and the software should be public and free afterwards. Unfortunately, even though those shouldn't be ideological issues, they are in the current climate: to many politicians, it is axiomatic that private enterprise is more efficient, and for government to do anything substantial amount to communism in their view.
However, a more baisc question is and remains: why do we need this at all? Paper and pen ballots work just fine and they are easy to audit. If we want technology in there, we can scan those ballots and put the scanned images on-line for everybody to recount at their leisure.
So, let me get this straight: in four years, we'll be able to jump on the Windows upgrade treadmill and run Linux code on servers costing thousands of dollars in Microsoft licensing fees, requiring at least 1Gbyte of RAM, and still be forced to deal with Microsoft's system admin tools. And why would I want to do that?
The problem with Windows isn't the lack of features, it is that it already has far too many. Adding Linux into the mix makes the problem with Windows worse, not better.
Before people go all gaga over this rash of new features from Apple and Sun, do some research. Transparency, shadows, overlays, desktops on 3D virtual presences, portals, 3D environments, etc. go back years and years, and many researchers have contributed to them. (You can find many of these features demonstrated in Squeak.)
This stuff is being shipped commercially now because you can now run it on PC hardware costing $1000-2000, instead of requiring high-end SGI workstations, as it did just a decade ago.
Apple does have a short-term advantage in this area: as part of their deal with NeXT, they got a Postscript/PDF-based window system, which happens to do these sorts of things already. But they don't have any long-term technical advantage: Microsoft has added similar APIs to Windows, and X11 also is moving towards full support of transparency and blending throughout the entire window system. Whose system will end up being the best long-term choice remains for the market to decide; personally, I think Apple's PDF-based system is the most cumbersome of the bunch.
Windows has had the ability to draw transparent windows since 2000. However, there's a limit to how far they can go.
Transparency in window systems is an idea that goes back almost as long as window systems have been around. People were even asking for it in the earliest versions of X11.
The only reason it hasn't been implemented more widely is because hardware hasn't really been up to it and applications didn't need it. Those applications that really did need it just used special graphics and visualization libraries.
Apple has this feature not because they had some great new insight, but they actually just got it essentially for free with the PostScript-based window system they acquired from NeXT, which was designed some time in the early 1980's and is based on stuff from Adobe. And now that hardware is up to handling it, it will just be a standard component of desktop window systems.
There's actually quite a bit of data about the danger of ingesting, inhaling, or otherwise coming into contact with plutonium.
The only level of toxicity we can determine with any degree of reliability is whether an animal falls over dead quickly if it is exposed to enough of something. That's not just true for plutonium, it's actually true for most substances. That's why drugs have to get withdrawn from the market regularly because they turn out to be dangerous despite having been studied previously for years in careful trials. And substances other than drugs don't even receive anywhere near the same level of safety testing.
Safety data like the one you refer to is useful to warn people about things that are known to have a high probability of resulting in injury or death. It is idiotic to think, however, as you seem to, that the things they don't list are therefore known to be safe.