Emulating is a nice gimmick, but nothing more. MS needs to market their x-box as on par with the current generation of game consoles. Being compatible with a few obsolete platforms is not very relevant for them.
In addition they need to market their own platform, so they'll focus on marketing directX games. Unlike other game console platforms they will have a huge amount of existing directX games when this thing is launched (assuming it is relatively easy to port them). So the need to include support for obsolete platforms is not very high.
And finally, emulators could be ported to other game consoles as well. There is not much stopping Sony from porting mame to their platform, yet they are not doing it. The reason is simple, you don't buy a playstation 2 to play old nintendo games.
Interesting approach, this would really be nice to have in the form of a net nanny like application that block privacy intruding sites rather then porn. I once turned cookie notification (turning off is not an option for me becaus then I loose customization on a lot of sites), but after an hour or so I got fed up clicking OK/Cancel for each site so I turned them on again.
Another thing that would be nice is if you could choose which sites are allowed to store cookies and which not (and make the browser remember what you choose). E.g. I want slashdot to remember my settings but CNN.com has no business setting cookies in my browser (I hate their customized site so i don't use it anyway).
Those two things combined would solve some of the privacy intrusions. Of course, as soon as you fill in forms on e-commerce sites, you have no control so be carefull what information you provide. I generally use the need to know principle: only provide the information that you really have to provide. If you need to fill in three pages of information just to buy a book, buy it somewhere else. Also i use a special email address that I provide when untrusted sites require an email address (sometimes I just provide bla@bla.org if I'm annoyed). This helps preventing spam (works quite well for me).
In any case I think the solution for the problem mentioned in the article is that Truste sues the companies trading information (which I assume is not in line with what Truste allows). This would re-establish them as a good brand and may increase the trustworthyness of their other customers.
Companies like Baan and SAP do not make much profit from selling licenses but instead make most of their money by implementing and supporting their products on customer sites.
In a way this situation is similar to what redhat and VA Linux do. Rather then selling linux licenses they make money by packaging it and supporting it.
Unfortunately there are always lots of dependencies on non open source software (e.g. commercial database systems, messaging systems). So being open source would probably not lower the cost of deploying and maintaining erp packages significantly.
So my guess is that open sourcing Baan would probably work but would not provide any immediate advantages other than: being able to swap support companies without having to buy a new erp system, being able to fix the software (not very relevant for most companies since many companies do not have personal capable of doing the changes).
Any company buying Baan will probably do so to gain access to their customers (e.g. Boeing) and expertise in the first place. The software is probably second priority.
You are right, I didn't bother to read all of it (200+ pages is a bit much for me). However, do note I posted a little correction (does not cover all of your comments). I think we all know Java MS interoperability is not really an option since MS stopped developing Java years ago.
Of course MS claims that they will implement security. Also Outlook is the best and most secure email client in the world. Duh!
I'm willing to agree that there is some nice syntactic sugar, but that does not outweigh the disadvantages of having gotos, a preprocessor (I was wrong about that, stupid bastards), the ability to make the program unsafe by disabling the garbage collector, the lack of an explicit security model (obviously not part of the language).
This language will simultaneously offend Java developers (for lack of features) and C++ developers (for lack of features and freedom). It may appeal to VB developers (ignorance is bliss).
"Java doesn't let you use primitives (int, short, etc) as classes without wrapping them yourself (lots of overhead)."
Then either C# does the wrapping transparently (same overhead) or built in types are all objects (unlikely). BTW. you don't have to wrap built in types to use them. You only have to do this when you want to use them as an object (e.g. in a Collection implementing class).
"Java doesn't have a "foreach" statement"
True, but that's just syntactic sugar. Besides, you have the Enumerator class for Collections.
"Java doesn't have property-handlers (eg. write functions that are treated as member variables - eg: a.setName("MyName") would become: a.Name = "MyName" - but it would still go through a function."
Again, syntactic sugar. Nice though.
"Java doesn't have any versioning mechanism (other than the woefully inadequate @deprecated tag."
I'm not sure the C# implementation helps much. Having two active versions of the same class active screams for trouble.
"Java doesn't support indexers (methods on a class - say List, which allow you to take the object of type List, and use it like an array - eg:"
More syntactic sugar. Adds some confusion and complexity to the language.
"Need I continue?"
Please continue, but not before you read my other comments on this article. In short my conclusions are that C# manages to be both worse than C++ and Java, not a small achievement. Don't be fooled by syntactic sugar and pay attention to the real features.
More bad news: - It does have a preprocessor, eww! - It has goto's, I feel really sad now! - It has a delegate construct. This is actually cool. However, I can't help wondering about typechecking and security here. - Support for versioning. Usefull I suppose.
Excuses for inaccuracies but I cannot do more than briefly glance at 200+ pages of specification. I think this post and the previous one capture most of the shortcomings of the language.
Wow, they've done the impossible. I just took a brief glance at the introduction to C#.
Here are some impressions:
- Similar syntax to Java with some annoying, non functional differences (e.g. Uses instead of import) - No synchronized keyword or equivalent. This makes the language not very suitable for serverside development. - No dynamic binding (at least I didn't see it mentioned). This is a key advantage of Java over C++ and allows for run time loading of new classes that may not even have existed at compile time. - Non functional syntactic sugar. At least I don't see the advantage of having structs or enums when you can have inner classes or something similar. - No inner classes. Another usefull feature of Java. - No security model. Yet another feature that they forgot to implement. I guess you are stuck with whatever ActiveX does for you. - No templates. Java developers have been screaming for this feature and several third party variants of Java exist providing this highly usefull feature. It is lacking in C#. - Single inheritance. Glad to see that they adopted this limitation. - Transparent use of COM objects. I suppose that is usefull but what about CORBA or JavaBeans? - destructors, C++ syntax but Java semantics (i.e. finalize). - No preprocessor. Apart from memory management, the preprocessor is probably the largest source of maintenance headaches so Yay!
Compelling reasons not to use C#: - you gain little or nothing if moving from VB - you loose a lot if moving from either Java or C++ - All C# objects are com components, so they are usable from outside C#. Why bother using it then? - Vendor lock in. Do I need to explain this? - Immaturity of language. If Java is a good example of how fast language adoption goes. It will take several years for C# get mature. - It does not address the needs of Java users, C++ users or VB users. - It does not contain anything you can't find in another language.
I sincerely hope this will die quickly. I know that MS can do better. I'm waiting for news on their intentional programming project for instance. This looks like it was implemented by their marketing department.
I learned Gofer myself in the first year of university (very similar to haskell). Though it is a very fun language to learn and use, I don't think of it as essential material for programmers. The programming community for functional language is quite small (for various reasons), and unless you are actually going to use it I wouldn't recommend spending much time on it to beginning programmers.
I also think it is a mistake to think that programming is still about algorithms. I can't remember the last time I implemented something like quicksort. All these things are available in a reusable form these days. Although it doesn't hurt to about algorithms, I think things like program structure and design are much more important.
Needless to say that I think that CS students, who are not just code monkeys, should know how to work with other languages than just Java/C++. Haskell is a good choice, but also prolog, lisp, etc. might be sufficient. The idea is not to teach those students a particular language but to learn them different ways of solving problems. It is also a great way to learn to understand the limitations of certain programming languages (C for instance). The more languages, the better. Each language has particular features which are interesting to learn about.
Programming is about much more than a language. Haskell is indeed nice, but quite useless to learn if you don't intend to use it.
Assuming we have a complete newby at hand who wants to become a skilled computer programmer, there are several things we need to teach him: - What is a computer, how does it work in general. Toying around with assembly can be usefull at this stage. It's also important to learn about bits & bytes and other computer jargon. - As soon as you got a clear image of how a computer works, it is time to learn a language. Prerably, a simple language is chosen (e.g. basic) but if necessary you can also take something more advanced. - Standard libraries. This is the part that takes the longest. To avoid that you reinvent the wheel it is essential that you know your tools. If your are doing C++, knowledge of the STL is essential. When doing Java you need to be able to find usefull classes and components in the various frameworks
Of course you can do these things in parallel. A good programmer can switch languages easily. I know I can learn C++ pretty quick since I understand all of the underlying principles. I have programmed before in other languages (C, Java, Basic etc.) and know that my biggest obstacle in learning C++ won't be the language but learning to use the stl efficiently.
In addition to the above, it is also usefull to learn about different styles of programming. Most novice programmers start by learning how to do procedural programming. At this point in time, however, there is really no excuse for a good programmer not understanding OO. If you want to laugh, try examining the first Java code of people who used to code in C or basic. I had the privilege of doing so some time ago. The poor fellow had crammed his entire program into a single class. He used the class variables as global variables and was simply applying the tricks he had used in pascal before. Also he was mostly ignoring the classes provided by the Java API. Strangly enough his program sort of worked.
After mastering & understanding procedural and OO programming you might look a bit further: generative programming, functional programming and logic programming good starting points. Also it is usefull to learn about program design methods. If you are doing OO, look at "Design Patterns" and learn how to use UML (not just the class diagrams).
Further expertise can only be gained by practice. There's no way you can do all of the above in a few weeks or even months. Books such as discussed in this article are a nice starting point for anybody new to programming, to bad it is limited to C++.
Coding class IMAMonkey { public static void main(String ps[]) { System.out.println("I'm a coding monkey"); } }
can be done by pretty much anybody but fully understanding what it does and why it is written down like that takes a bit longer.
They do it in hardware, not in software: limited optimizations, no profiling of runtime system, fixed instruction set. There isn't a single transistor on the crusoe implementing a X86 instruction. It is all done in software. So, the crusoe doesn't have these limitations. The software that does the translation can be updated meaning that bugs in the translation can be fixed and bugs in the processor hardware can be worked around. New translations for new instruction sets can be added and most importantly it can do runtime optimizations using profiling information.
No doubt they have a nice product but a 30x improvement, as mentioned in one of the posts, in performance sounds like marketing crap to me. In any case, I don't believe it until I see it.
Also note that their VM is about personal java, which is a slimmed down version of Java for embedded machines. Probably the competition uses an interpreter rather than a JIT to save on memory usage (this would explain the performance difference). No doubt speed is usefull in some situations but the real bottleneck of embedded machines is usually memory size. The more memory you have available, the more features you can put into the tiny space.
In any case, thanks for drawing attention to an interesting virtual machine. Diversity is a good thing.
Don't believe everything they tell you. Since the introduction of hotspot there's nothing wrong with the execution speed of Java (check the recent story on Java performance, it's actually faster than C in some cases). The reason why java applications (graphical and multimedia in particular) are still slow is because of the way its libraries are implemented. Particularly Java2D and the swing classes are slow compared to their C/C++ counterparts. A faster interpreter does not help very much. In fact, the early swing implementations ran faster with the JIT disabled! So, unless tao completely reimplemented swing and other libraries, I'd be surprised if it performed significantly better than other JVMs.
I really liked the discussion in the article about obsolete and irrelevant. The real thing that has become obsolete is not the ISA but the static compiler that ties programs to it. The only reason x86 is still around is because there is no convenient way to convert an binary x86 program to, say an alpha binary, on the fly without performance loss. X86 will be around as long as people choose to statically compile their programs. The interesting question is not how long x86 will be around but how long hardware implementations of x86 will be around. Hardly anybody codes directly to an instruction set anymore. A simple recompile will port linux applications to other processors, often no changes are needed to the code. So, the dependency of the program to a specific ISA is not functional. In fact, as HP's dynamo shows, it is counter productive.
Transmeta's crusoe is the first of a generation of processors that can execute X86 efficiently without having a hardware implementation of it. My guess is that in five years or so, all major chip manufacturers will have stopped implementing instruction sets in hardware.
Java is ahead of its time in a way, since it is not dependent on specific instruction sets. The hotspot idea is not fundamentally different from what the crusoe does.
This really looks nice. I'm not sure how much berlin can be compared to apple's aqua but it looks like it has rather similar capabilities. For those who are wondering what to do with all this functionality: it makes it really easy to write graphical applications. Graphical applications generally display lots of 2D shapes which need to be manipulated in arbitrary ways. A GUI library like Berlin does all the difficult transformations for you. Since it's all integrated, it works fairly transparently too. I admit that rotated, translucent X-terms are not a particularly exciting example (I wouldn't want one on my desktop) but you have to realize that it is only an example of how easy it is to make such graphical objects (in any case, what would make a terminal window exciting?). Note that these transformations can also be applied to objects inside a window.
Having resolution independent graphics is a particular nice feature which can for instance be used to add high quality printing functionality to applications in a very straightforward way but also allows for zooming functionality etc.
I can't help noticing that there's a lot of news regarding nukes. (this article, the news on pakistan having loads of nukes). In my oppinion it is not a coincident that this happens at a time where the US tries to push Russia and other countries to accept their so called rocket shield.
This controversial, billion dollar project will require their support but also the support of the tax paying citizens in the USA. I'm cynical enough that the US is trying to convince their own people that such a shield is needed by 'leaking' this sort of news.
"Maybe I still am missing the boat on OO, but at least I'm in good company. =)"
Exactly, you just found another guy who missed the boat. This guy is smart enough to not completely dismiss python and java as useless but from the interview it is quite clear that you won't find him programming in either language (to put it mildly).
For me OO is also something of the past. But at least I'm not stuck in the procedural/machine oriented paradigm of thirty years ago (when OO was the hot new thing). Personally, I find modern ideas such as aspect oriented programming, subject oriented programming or even intentional programming much more interesting.
Perl is interesting in that sense because it is probably flexible enough to extend it to support either of those. On the other hand its syntax will probably always be a major obstacle for any serious adoption. Also performance is an issue (more than in Java) if you start doing serious development.
Java at the moment is a much more mature language, perhaps due to the rigorous control of SUN over it. However, I think institutions like ISO mover too slow to keep up with the rapid developments. A standardized version of Java of three years ago would be close to useless to me. I suspect the same goes for perl. Like it or not, SUNs control of the Java language has prevented fragmentation and effectively caused it to be an industry standard with support for a large number of platforms.
Finally a wise quote: "When you have a hammer, every problem seems a nail"
I think this applies equally to either perl, vb, c(++), java, fill in you're favorite language. When developing device drivers stay away from visual basic. When developing e-commerce websites: don't bother using c. Also beware that languages and their accompanying libraries are under development. Two years ago Java was not good to do anything, now it is rapidly becoming the language of choice for number of domains (most notably web development).
Don't use one hammer but educate yourself to be able to use the appropriate tools for the job at hand.
"there is always a default setup for a linux system."
That's the whole point: there is no such thing as a default setup for linux. First of all there are numerous different distributions who each are different (though compatible). Then it also matters how these distributions are installed (gnome/kde, etc.). The differences between for example Gnome and KDE are comparable to the differences between a mac and windows if you take a users perspective. Having local standards does not really help because that will cause you to invest in training cost each time you hire a new employee or decide to change/upgrade the local standard.
"He just made it clear that anyone who chose to use something else as their setup had to be able to admin their own boxes."
You unix/linux people simply don't get it. You take the administrator point of view that a system should be easy to administer. While that is useful for reducing cost, it is actually much more important that you have a system that is easy to use for the users.
In any case, from your comments I gather that you are not working in an ordinary office since you are all running linux. This thread is about how to use stuff like linux in a common office situation.
Microsoft did not become big because they were compatible with the rest out there. They got big because at some point they had a critical mass of software which integrated nicely. After that it became the default choice of software.
To achieve something similar on linux it is not enough to be compatible. Compatibility is of course important but I think it is more important to offer users a consistent environment to do their work in. Linux is just too customizable. It looks and feels different on nearly each desktop. That's not good if you have an office full of non techie people who need to work with the software.
The nice thing about operating systems like mac OS and windows is that after installation, both operating systems look fairly similar from machine to machine. That makes it easy to administer and use them.
It's not good enough to just copy the features available. Arguably most mac/windows features are already available on linux. They're just not organized enough.
intentional programming: see microsoft research and do a search on google (please open your mind, it's just bill gates pouring money into legitimate research). If they pull this of it will be one of the most interesting things to happen in computer programming since the invention of the compiler.
Self: a little outdated now but there are still some interesting ideas in it (many of them were used to develop Java). You can find it somewhere on sun's website.
Subject oriented programming: There's some very interesting research going on in this area. IBM is the place to look for SOP.
Aspect oriented programming: Also very interesting. Check Xerox' research site and be sure to give their compiler a try.
Anybody serious about exploring new paradigms should take a look at the above. There are several related research projects going on but these are the most important ones. All of them are driven by the realization that OO is just not good enough for modeling the entire world.
I checked out the Pike website briefly. I can't discover any exciting language features in it. It is yet another OO scripting language. Maybe it will find its niche like so many other languages do but there's nothing revolutionary to be found there. I'm not a language designer but what would interest me is a scripting language that supports one of the paradigms above. Especially AOP would seem very useful in a scripting language.
A universities job is not to learn students how to fix memory leaks (an activity that cannot be avoided by newby c programmers) but to learn them the basic concepts of programming. I started university in 94 (with ansi C), I had to learn the hard way about pointers. The year after me they used C++ (same problems). The year after that they started using Java (and they still use that as far as I know).
Java is good as a teaching language because it allows teachers to get to the point quickly (OO, how to properly design, etc.). Once you're a good programmer it is pretty easy to learn new languages. I learned quite a few different languages during my study and consider that to be very usefull. I'm a researcher now but if I were to go work in industry I would be up to speed programming whatever language used in that company in no time.
I should add some stuff to this: Servlets are usually more efficient than cgi scripts (such as perl scripts) because they are already running and don't require the overhead of spawning a new process to handle the request. That and jvms such as discussed in the article make that java servlets are a very good alternative for perl (and we are just talking performance here, not all the other nice features of java such as readable source code, OO features etc.).
Of course having multiple threads makes java programs really scalable. On a server you should use servlets. Servlets are actually quite efficient and have load balancing built in. You also avoid the non blocking IO problem this way since the webserver (apache for instance) takes care of the connections and passes the request to the servlet. Servlets are not spawned for each request but typically are reused for new requests. That and the ability to scale to multiple CPU's make that Java is very suitable for server side network programming.
In my opinion making a program complex for performance reasons only is a bad idea unless we're talking about long term usage of a program. Developers often forget that most of the cost of developing a product goes into maintenance. Java servlets provide you with a nice scalable architecture for serverside programming and it allows you to focus on the parts of the program that provide the functionality you need rather than performance related stuff.
"It would also help squash the myth that coding in Java requires using a VM at runtime"
It actually does if you intend to use dynamic loading. In any case, Java without all its interesting features is not very interesting to me. It's not just the language that makes it attractive but also that it is a very safe environment to program in: no crashing software, no memory leaks, array bounds checking, etc. In addition, the standard library coming with Java is very good for productivity since it provides a lot of well designed functionality.
Java as we know it is not really possible without the VM, and as the article points out quite clearly, there's not much to be gained anyway by compiling statically. I haven't seen any benchmarks where a static java compiler is much faster than a regular VM (not enough to justify accepting its limitations).
I think this article smashes one myth: Static compilers are slower than dynamic compilers. The C compilers were in a good position here: under development for decades and code they should be able to run well. Yet, despite the novelty of JVMs and despite the fact that the JVM has to do bounds checking on arrays, it delivers comparable performance. The only logical conclusion is that if a dynamic compiler for C were developed it might actually be faster than statically compiled C.
I agree that it would have been nice if he'd thrown in a static java compiler. My guess would be that there would be no surprises and that its performance would be mediocre compared to the c compilers and the JVMs. Even a static java compiler still has to do bounds checking and thus the static c compilers have an advantage (plus that their implementation can be assumed a little more mature).
Slashdot Mirror
Emulating is a nice gimmick, but nothing more. MS needs to market their x-box as on par with the current generation of game consoles. Being compatible with a few obsolete platforms is not very relevant for them.
In addition they need to market their own platform, so they'll focus on marketing directX games. Unlike other game console platforms they will have a huge amount of existing directX games when this thing is launched (assuming it is relatively easy to port them). So the need to include support for obsolete platforms is not very high.
And finally, emulators could be ported to other game consoles as well. There is not much stopping Sony from porting mame to their platform, yet they are not doing it. The reason is simple, you don't buy a playstation 2 to play old nintendo games.
I've had a print screen button on my keyboard for years!
Interesting approach, this would really be nice to have in the form of a net nanny like application that block privacy intruding sites rather then porn. I once turned cookie notification (turning off is not an option for me becaus then I loose customization on a lot of sites), but after an hour or so I got fed up clicking OK/Cancel for each site so I turned them on again.
Another thing that would be nice is if you could choose which sites are allowed to store cookies and which not (and make the browser remember what you choose). E.g. I want slashdot to remember my settings but CNN.com has no business setting cookies in my browser (I hate their customized site so i don't use it anyway).
Those two things combined would solve some of the privacy intrusions. Of course, as soon as you fill in forms on e-commerce sites, you have no control so be carefull what information you provide. I generally use the need to know principle: only provide the information that you really have to provide. If you need to fill in three pages of information just to buy a book, buy it somewhere else. Also i use a special email address that I provide when untrusted sites require an email address (sometimes I just provide bla@bla.org if I'm annoyed). This helps preventing spam (works quite well for me).
In any case I think the solution for the problem mentioned in the article is that Truste sues the companies trading information (which I assume is not in line with what Truste allows). This would re-establish them as a good brand and may increase the trustworthyness of their other customers.
Companies like Baan and SAP do not make much profit from selling licenses but instead make most of their money by implementing and supporting their products on customer sites.
In a way this situation is similar to what redhat and VA Linux do. Rather then selling linux licenses they make money by packaging it and supporting it.
Unfortunately there are always lots of dependencies on non open source software (e.g. commercial database systems, messaging systems). So being open source would probably not lower the cost of deploying and maintaining erp packages significantly.
So my guess is that open sourcing Baan would probably work but would not provide any immediate advantages other than: being able to swap support companies without having to buy a new erp system, being able to fix the software (not very relevant for most companies since many companies do not have personal capable of doing the changes).
Any company buying Baan will probably do so to gain access to their customers (e.g. Boeing) and expertise in the first place. The software is probably second priority.
You are right, I didn't bother to read all of it (200+ pages is a bit much for me). However, do note I posted a little correction (does not cover all of your comments). I think we all know Java MS interoperability is not really an option since MS stopped developing Java years ago.
Of course MS claims that they will implement security. Also Outlook is the best and most secure email client in the world. Duh!
I'm willing to agree that there is some nice syntactic sugar, but that does not outweigh the disadvantages of having gotos, a preprocessor (I was wrong about that, stupid bastards), the ability to make the program unsafe by disabling the garbage collector, the lack of an explicit security model (obviously not part of the language).
This language will simultaneously offend Java developers (for lack of features) and C++ developers (for lack of features and freedom). It may appeal to VB developers (ignorance is bliss).
"Java doesn't let you use primitives (int, short, etc) as classes without wrapping them yourself (lots of overhead)."
Then either C# does the wrapping transparently (same overhead) or built in types are all objects (unlikely). BTW. you don't have to wrap built in types to use them. You only have to do this when you want to use them as an object (e.g. in a Collection implementing class).
"Java doesn't have a "foreach" statement"
True, but that's just syntactic sugar. Besides, you have the Enumerator class for Collections.
"Java doesn't have property-handlers (eg. write functions that are treated as member variables - eg:
a.setName("MyName") would become: a.Name = "MyName" - but it would still go through a function."
Again, syntactic sugar. Nice though.
"Java doesn't have any versioning mechanism (other than the woefully inadequate @deprecated tag."
I'm not sure the C# implementation helps much. Having two active versions of the same class active screams for trouble.
"Java doesn't support indexers (methods on a class - say List, which allow you to take the object of type List, and use it like an array - eg:"
More syntactic sugar. Adds some confusion and complexity to the language.
"Need I continue?"
Please continue, but not before you read my other comments on this article. In short my conclusions are that C# manages to be both worse than C++ and Java, not a small achievement. Don't be fooled by syntactic sugar and pay attention to the real features.
More bad news:
- It does have a preprocessor, eww!
- It has goto's, I feel really sad now!
- It has a delegate construct. This is actually cool. However, I can't help wondering about typechecking and security here.
- Support for versioning. Usefull I suppose.
Excuses for inaccuracies but I cannot do more than briefly glance at 200+ pages of specification. I think this post and the previous one capture most of the shortcomings of the language.
Wow, they've done the impossible. I just took a brief glance at the introduction to C#.
Here are some impressions:
- Similar syntax to Java with some annoying, non functional differences (e.g. Uses instead of import)
- No synchronized keyword or equivalent. This makes the language not very suitable for serverside development.
- No dynamic binding (at least I didn't see it mentioned). This is a key advantage of Java over C++ and allows for run time loading of new classes that may not even have existed at compile time.
- Non functional syntactic sugar. At least I don't see the advantage of having structs or enums when you can have inner classes or something similar.
- No inner classes. Another usefull feature of Java.
- No security model. Yet another feature that they forgot to implement. I guess you are stuck with whatever ActiveX does for you.
- No templates. Java developers have been screaming for this feature and several third party variants of Java exist providing this highly usefull feature. It is lacking in C#.
- Single inheritance. Glad to see that they adopted this limitation.
- Transparent use of COM objects. I suppose that is usefull but what about CORBA or JavaBeans?
- destructors, C++ syntax but Java semantics (i.e. finalize).
- No preprocessor. Apart from memory management, the preprocessor is probably the largest source of maintenance headaches so Yay!
Compelling reasons not to use C#:
- you gain little or nothing if moving from VB
- you loose a lot if moving from either Java or C++
- All C# objects are com components, so they are usable from outside C#. Why bother using it then?
- Vendor lock in. Do I need to explain this?
- Immaturity of language. If Java is a good example of how fast language adoption goes. It will take several years for C# get mature.
- It does not address the needs of Java users, C++ users or VB users.
- It does not contain anything you can't find in another language.
I sincerely hope this will die quickly. I know that MS can do better. I'm waiting for news on their intentional programming project for instance. This looks like it was implemented by their marketing department.
I half agree,
I learned Gofer myself in the first year of university (very similar to haskell). Though it is a very fun language to learn and use, I don't think of it as essential material for programmers. The programming community for functional language is quite small (for various reasons), and unless you are actually going to use it I wouldn't recommend spending much time on it to beginning programmers.
I also think it is a mistake to think that programming is still about algorithms. I can't remember the last time I implemented something like quicksort. All these things are available in a reusable form these days. Although it doesn't hurt to about algorithms, I think things like program structure and design are much more important.
Needless to say that I think that CS students, who are not just code monkeys, should know how to work with other languages than just Java/C++. Haskell is a good choice, but also prolog, lisp, etc. might be sufficient. The idea is not to teach those students a particular language but to learn them different ways of solving problems. It is also a great way to learn to understand the limitations of certain programming languages (C for instance). The more languages, the better. Each language has particular features which are interesting to learn about.
Programming is about much more than a language. Haskell is indeed nice, but quite useless to learn if you don't intend to use it.
Assuming we have a complete newby at hand who wants to become a skilled computer programmer, there are several things we need to teach him:
- What is a computer, how does it work in general. Toying around with assembly can be usefull at this stage. It's also important to learn about bits & bytes and other computer jargon.
- As soon as you got a clear image of how a computer works, it is time to learn a language. Prerably, a simple language is chosen (e.g. basic) but if necessary you can also take something more advanced.
- Standard libraries. This is the part that takes the longest. To avoid that you reinvent the wheel it is essential that you know your tools. If your are doing C++, knowledge of the STL is essential. When doing Java you need to be able to find usefull classes and components in the various frameworks
Of course you can do these things in parallel. A good programmer can switch languages easily. I know I can learn C++ pretty quick since I understand all of the underlying principles. I have programmed before in other languages (C, Java, Basic etc.) and know that my biggest obstacle in learning C++ won't be the language but learning to use the stl efficiently.
In addition to the above, it is also usefull to learn about different styles of programming. Most novice programmers start by learning how to do procedural programming. At this point in time, however, there is really no excuse for a good programmer not understanding OO. If you want to laugh, try examining the first Java code of people who used to code in C or basic. I had the privilege of doing so some time ago. The poor fellow had crammed his entire program into a single class. He used the class variables as global variables and was simply applying the tricks he had used in pascal before. Also he was mostly ignoring the classes provided by the Java API. Strangly enough his program sort of worked.
After mastering & understanding procedural and OO programming you might look a bit further: generative programming, functional programming and logic programming good starting points. Also it is usefull to learn about program design methods. If you are doing OO, look at "Design Patterns" and learn how to use UML (not just the class diagrams).
Further expertise can only be gained by practice. There's no way you can do all of the above in a few weeks or even months. Books such as discussed in this article are a nice starting point for anybody new to programming, to bad it is limited to C++.
Coding
class IMAMonkey {
public static void main(String ps[])
{
System.out.println("I'm a coding monkey");
}
}
can be done by pretty much anybody but fully understanding what it does and why it is written down like that takes a bit longer.
They do it in hardware, not in software: limited optimizations, no profiling of runtime system, fixed instruction set. There isn't a single transistor on the crusoe implementing a X86 instruction. It is all done in software. So, the crusoe doesn't have these limitations. The software that does the translation can be updated meaning that bugs in the translation can be fixed and bugs in the processor hardware can be worked around. New translations for new instruction sets can be added and most importantly it can do runtime optimizations using profiling information.
No doubt they have a nice product but a 30x improvement, as mentioned in one of the posts, in performance sounds like marketing crap to me. In any case, I don't believe it until I see it.
Also note that their VM is about personal java, which is a slimmed down version of Java for embedded machines. Probably the competition uses an interpreter rather than a JIT to save on memory usage (this would explain the performance difference). No doubt speed is usefull in some situations but the real bottleneck of embedded machines is usually memory size. The more memory you have available, the more features you can put into the tiny space.
In any case, thanks for drawing attention to an interesting virtual machine. Diversity is a good thing.
"22x faster with Multimedia than any other JVM!"
Don't believe everything they tell you. Since the introduction of hotspot there's nothing wrong with the execution speed of Java (check the recent story on Java performance, it's actually faster than C in some cases). The reason why java applications (graphical and multimedia in particular) are still slow is because of the way its libraries are implemented. Particularly Java2D and the swing classes are slow compared to their C/C++ counterparts. A faster interpreter does not help very much. In fact, the early swing implementations ran faster with the JIT disabled! So, unless tao completely reimplemented swing and other libraries, I'd be surprised if it performed significantly better than other JVMs.
I really liked the discussion in the article about obsolete and irrelevant. The real thing that has become obsolete is not the ISA but the static compiler that ties programs to it. The only reason x86 is still around is because there is no convenient way to convert an binary x86 program to, say an alpha binary, on the fly without performance loss. X86 will be around as long as people choose to statically compile their programs. The interesting question is not how long x86 will be around but how long hardware implementations of x86 will be around. Hardly anybody codes directly to an instruction set anymore. A simple recompile will port linux applications to other processors, often no changes are needed to the code. So, the dependency of the program to a specific ISA is not functional. In fact, as HP's dynamo shows, it is counter productive.
Transmeta's crusoe is the first of a generation of processors that can execute X86 efficiently without having a hardware implementation of it. My guess is that in five years or so, all major chip manufacturers will have stopped implementing instruction sets in hardware.
Java is ahead of its time in a way, since it is not dependent on specific instruction sets. The hotspot idea is not fundamentally different from what the crusoe does.
This really looks nice. I'm not sure how much berlin can be compared to apple's aqua but it looks like it has rather similar capabilities. For those who are wondering what to do with all this functionality: it makes it really easy to write graphical applications. Graphical applications generally display lots of 2D shapes which need to be manipulated in arbitrary ways. A GUI library like Berlin does all the difficult transformations for you. Since it's all integrated, it works fairly transparently too. I admit that rotated, translucent X-terms are not a particularly exciting example (I wouldn't want one on my desktop) but you have to realize that it is only an example of how easy it is to make such graphical objects (in any case, what would make a terminal window exciting?). Note that these transformations can also be applied to objects inside a window.
Having resolution independent graphics is a particular nice feature which can for instance be used to add high quality printing functionality to applications in a very straightforward way but also allows for zooming functionality etc.
I can't help noticing that there's a lot of news regarding nukes. (this article, the news on pakistan having loads of nukes). In my oppinion it is not a coincident that this happens at a time where the US tries to push Russia and other countries to accept their so called rocket shield.
This controversial, billion dollar project will require their support but also the support of the tax paying citizens in the USA. I'm cynical enough that the US is trying to convince their own people that such a shield is needed by 'leaking' this sort of news.
Am I breaking any license if I install a non free package on debian?
Am I breaking any license if I put debian and some non free packages on the same CD?
Am I breaking any licenses if I modify the debian setup in such a way that it accessess and installs the non free packages?
If the answer to all of the above questions is NO, then please explain to me what this discussion is about. If the answer is YES, please explain.
"Maybe I still am missing the boat on OO, but at least I'm in good company. =)"
Exactly, you just found another guy who missed the boat. This guy is smart enough to not completely dismiss python and java as useless but from the interview it is quite clear that you won't find him programming in either language (to put it mildly).
For me OO is also something of the past. But at least I'm not stuck in the procedural/machine oriented paradigm of thirty years ago (when OO was the hot new thing). Personally, I find modern ideas such as aspect oriented programming, subject oriented programming or even intentional programming much more interesting.
Perl is interesting in that sense because it is probably flexible enough to extend it to support either of those. On the other hand its syntax will probably always be a major obstacle for any serious adoption. Also performance is an issue (more than in Java) if you start doing serious development.
Java at the moment is a much more mature language, perhaps due to the rigorous control of SUN over it. However, I think institutions like ISO mover too slow to keep up with the rapid developments. A standardized version of Java of three years ago would be close to useless to me. I suspect the same goes for perl. Like it or not, SUNs control of the Java language has prevented fragmentation and effectively caused it to be an industry standard with support for a large number of platforms.
Finally a wise quote:
"When you have a hammer, every problem seems a nail"
I think this applies equally to either perl, vb, c(++), java, fill in you're favorite language. When developing device drivers stay away from visual basic. When developing e-commerce websites: don't bother using c. Also beware that languages and their accompanying libraries are under development. Two years ago Java was not good to do anything, now it is rapidly becoming the language of choice for number of domains (most notably web development).
Don't use one hammer but educate yourself to be able to use the appropriate tools for the job at hand.
"there is always a default setup for a linux system."
That's the whole point: there is no such thing as a default setup for linux. First of all there are numerous different distributions who each are different (though compatible). Then it also matters how these distributions are installed (gnome/kde, etc.). The differences between for example Gnome and KDE are comparable to the differences between a mac and windows if you take a users perspective. Having local standards does not really help because that will cause you to invest in training cost each time you hire a new employee or decide to change/upgrade the local standard.
"He just made it clear that anyone who chose to use something else as their setup had to be able to admin their own boxes."
You unix/linux people simply don't get it. You take the administrator point of view that a system should be easy to administer. While that is useful for reducing cost, it is actually much more important that you have a system that is easy to use for the users.
In any case, from your comments I gather that you are not working in an ordinary office since you are all running linux. This thread is about how to use stuff like linux in a common office situation.
Microsoft did not become big because they were compatible with the rest out there. They got big because at some point they had a critical mass of software which integrated nicely. After that it became the default choice of software.
To achieve something similar on linux it is not enough to be compatible. Compatibility is of course important but I think it is more important to offer users a consistent environment to do their work in. Linux is just too customizable. It looks and feels different on nearly each desktop. That's not good if you have an office full of non techie people who need to work with the software.
The nice thing about operating systems like mac OS and windows is that after installation, both operating systems look fairly similar from machine to machine. That makes it easy to administer and use them.
It's not good enough to just copy the features available. Arguably most mac/windows features are already available on linux. They're just not organized enough.
some examples of other unexplored paradigms:
intentional programming: see microsoft research and do a search on google (please open your mind, it's just bill gates pouring money into legitimate research). If they pull this of it will be one of the most interesting things to happen in computer programming since the invention of the compiler.
Self: a little outdated now but there are still some interesting ideas in it (many of them were used to develop Java). You can find it somewhere on sun's website.
Subject oriented programming: There's some very interesting research going on in this area. IBM is the place to look for SOP.
Aspect oriented programming: Also very interesting. Check Xerox' research site and be sure to give their compiler a try.
Anybody serious about exploring new paradigms should take a look at the above. There are several related research projects going on but these are the most important ones. All of them are driven by the realization that OO is just not good enough for modeling the entire world.
I checked out the Pike website briefly. I can't discover any exciting language features in it. It is yet another OO scripting language. Maybe it will find its niche like so many other languages do but there's nothing revolutionary to be found there. I'm not a language designer but what would interest me is a scripting language that supports one of the paradigms above. Especially AOP would seem very useful in a scripting language.
A universities job is not to learn students how to fix memory leaks (an activity that cannot be avoided by newby c programmers) but to learn them the basic concepts of programming. I started university in 94 (with ansi C), I had to learn the hard way about pointers. The year after me they used C++ (same problems). The year after that they started using Java (and they still use that as far as I know).
Java is good as a teaching language because it allows teachers to get to the point quickly (OO, how to properly design, etc.). Once you're a good programmer it is pretty easy to learn new languages. I learned quite a few different languages during my study and consider that to be very usefull. I'm a researcher now but if I were to go work in industry I would be up to speed programming whatever language used in that company in no time.
I should add some stuff to this:
Servlets are usually more efficient than cgi scripts (such as perl scripts) because they are already running and don't require the overhead of spawning a new process to handle the request. That and jvms such as discussed in the article make that java servlets are a very good alternative for perl (and we are just talking performance here, not all the other nice features of java such as readable source code, OO features etc.).
Of course having multiple threads makes java programs really scalable. On a server you should use servlets. Servlets are actually quite efficient and have load balancing built in. You also avoid the non blocking IO problem this way since the webserver (apache for instance) takes care of the connections and passes the request to the servlet. Servlets are not spawned for each request but typically are reused for new requests. That and the ability to scale to multiple CPU's make that Java is very suitable for server side network programming.
In my opinion making a program complex for performance reasons only is a bad idea unless we're talking about long term usage of a program. Developers often forget that most of the cost of developing a product goes into maintenance. Java servlets provide you with a nice scalable architecture for serverside programming and it allows you to focus on the parts of the program that provide the functionality you need rather than performance related stuff.
"It would also help squash the myth that coding in Java requires using a VM at runtime"
It actually does if you intend to use dynamic loading. In any case, Java without all its interesting features is not very interesting to me. It's not just the language that makes it attractive but also that it is a very safe environment to program in: no crashing software, no memory leaks, array bounds checking, etc. In addition, the standard library coming with Java is very good for productivity since it provides a lot of well designed functionality.
Java as we know it is not really possible without the VM, and as the article points out quite clearly, there's not much to be gained anyway by compiling statically. I haven't seen any benchmarks where a static java compiler is much faster than a regular VM (not enough to justify accepting its limitations).
I think this article smashes one myth: Static compilers are slower than dynamic compilers. The C compilers were in a good position here: under development for decades and code they should be able to run well. Yet, despite the novelty of JVMs and despite the fact that the JVM has to do bounds checking on arrays, it delivers comparable performance. The only logical conclusion is that if a dynamic compiler for C were developed it might actually be faster than statically compiled C.
I agree that it would have been nice if he'd thrown in a static java compiler. My guess would be that there would be no surprises and that its performance would be mediocre compared to the c compilers and the JVMs. Even a static java compiler still has to do bounds checking and thus the static c compilers have an advantage (plus that their implementation can be assumed a little more mature).
It's a java program. It will run anywhere where there is a good JVM present (that includes Linux BTW :).