I only get half of your post. You seem to be advocating XML-RPC/SOAP like things over CORBA because CORBA is blocking by nature. And so is XML-RPC right? What DO you recommend for doing distributed computing? Let's say you want to have your app deployed on a cluster of boxen for load balancing or failover protection. Surely you don't advocate creating sockets and marshalling stuff by hand every time you have to talk to another node on a cluster, do you?
Absurdly slow Java code usually means a very bad programmer. I've written plenty of Java UI code and I've yet to see 10 seconds for a menu to appear.
Nope. The guy who wrote the java version is at least as competent as I am (not that that's saying much really!). It's java, Swing in particular. It's reasonably responisive half of the time but when it enters one of its mood swings (pun intended) it can take up to ten seconds for the UI to 'wake up' again. I notice that with JBuilder too. It's not our programmers who are at fault it's the runtime.
Sun provides a JDBC spec which driver writers can support.
I know Sun don't make them. But I'm very happy with Sybase in general it's just the java side of things again. Sybase is a quality product and I don't understand why we have issues solely with the JDBC side of things.
If you want EJBs, look at Orion.
I haven't tried it. I may do so since you have good experiences with it. I've been looking into the expensive side of the market and was less than impressed with what I saw. I'd say that Borland is probably the best of that lot (at least it has corba under the hood so other languages can talk to it).
Thanks for the reply. Very calm and balanced (am I really on slashdot?) given my ranty and confrontational initial post:)
Two orders of magnitude. That's roughly how much faster a desktop app that I rewrote in C++ for my employer works these days. If you think that users don't care if menus take 10 seconds to unroll you obviously never talked to your customers directly.
XML parsing in java sucks. As soon as I add validation the bloody thing takes seconds(!) to build the DOM tree for even the simplest of documents! Fuck knows how they made is this slow. Must be full of O(n^2) algorithms.
UI code. I'll be humane and avoid discussing it. I think that Swing products speak for themselves...
I notice with some amusement that three of the four data sources you mention are MS databases. Now that's really a wide range of support!
I'll take that over half assed, broken JDBC drivers for Sybase any time. Does this language have a SINGLE API that's not broken?
I won't even mention the quality of other Java related prdoucts such as servlet containers (yes I evaluated a number of them and they are all buggy as shit) and don't get me started on the dubious benefits of EJB with it's $15000/CPU rates. Now that's competitive and antimonopolistic practice from SUNW!!! Fix the pricing at such exuberant rates that nobody except for the few select giants (hi IBM, hi BEA) can compete or SUN won't "authorise" your EJB container if you don't start charging an arm and a leg for it. Wake up buddy. If you're a Scott McNealy serf we're out there to get ya!!!
No more $150000 lame crappy servers. M$ with sane pricing is coming your way!!!
Wrong. I am one of the senior developers on my team and I loudly objected to code reviews as I consider them extremly harmful for the reasons mentioned in my original post. I think pair programming is a much better idea with a 'live' code review that happens in real time, is less boring to the parties involved and results in a code of much higher quality than any solitary code review can aspire to produce. Most code I write forms the foundation of the application and most of it is a template based framework (stl extensions). It's complex enough that nobody even tries reviewing it. They just take my word for it that it works:).
This is just vaguely on topic but I feel like ranting!
Code reviews are a terrible practice. They either turn into a week of web surfing and at the end everybody says all of the code is perfect or what's worse they are taken seriously and turn into a morale killer. People don't like having their competence questioned. Even if they are fairly junior they like to think their work is up to scratch. Senior people don't like being questioned about their particular programming style: they know they have a number of successful projects already behind them and don't want to be questioned on how they perform the work. If it does the job and is maintainable it should be good enough. Code reviews almost always end up turning into personal attacks. It's a sneaky management ploy to turn developers against one another. They cause harm, quarrel amongst seniors and intimidation for juniors. THEY SUCK!!!!!!
How to avoid the problems of lack of code reviews?
Number one is have good comprehensive unit tests. They tell you a lot more about code's correctness than any amount of code reviews you can think of. Pair programming eliminates the issue of "lonely wolves" where individual programmers hoard a piece of application and don't let anyone else near it. These two suggestions are the fundamental blocks of extreme programming.
It does not vary from one employer to another. It's always "do it on your own read about the things you need to know in your own time. We might pay for the books you need though if it's not too much.". That's as far as the idea of staff development stretches in 99.99% of software shops.
That slashdot and other OSDN sites bear the main responsibility for generating revenue. Slashdot in particular as it's frequented by so many people daily. One way to do it may be to insert some extra data (such as tags) into comments and help boost revenue and creating some subtle albeit effective advertising. Something akin to SmartTags should go a long way towards compensating for the cut revenue from hardware sales. How big a job would it be to implement that in slashcode?
It will reduce its work force by about 35% from the fiscal third quarter level of 436 employees. The majority of the layoffs will occur during the current fiscal quarter, with the remainder over the next several months.
Trading in VA Linux was halted for news. The issue last changed hands at $3.26
Why was trading suspended. Is it such bad news that they think investors may freak out?
The announcement you linked to is almost a year old... And as far as I know this was NOT an official statement just some more rumour mongering on slashdot. If it indeed came from the horse's mouth so to speak, then that just means it's yet another promise they failed to deliver on. That's even worse than making no promises in the first place.
It's all slashdot's fault that OSS and the GPL virus are considered synonymous. There are thousands of OSS projects that use the MIT license for instance but still get associated with the GPL zealotry. If slashdot (arguably the biggest OSS PR machine) was a bit more objective in its editorial practice the world would have a bit broader understanding of the OSS community.
There is a grain of truth in gates' ramblings too. The mess of the licensing issues that Richard Stalin^H^Hlman created is and should be of concern to any software company who isn't keen on going full GPL. Figuring out what you can and can't do with all those pieces that have strings attatched to them must be every lawyers nightmare. Even da man himself seems to be a bit baffled by all this licensing mess. He still can't tolerate KDE which is now decidedly GPL compatible while he gives his blessings to GNOME which uses Mozilla for the rendering engine in its up and coming albeit deceased (yeah, go figure how that works!) file manager. Mozilla being under the MPL license is decidedly GPL incompatible. Anyone else see the hipocricy here?
Right on! Lest we forget that Mozilla which is used as the rendering engine in GNOME is not GPLed or even GPL compatible. It takes more than logic it figure out GPL zealots. Take care.
Yeah, things took an interesting twist lately. Since KDE is now fully GPLd and uses the decidedly GPL compatible QT it should be the preferred choice of GPL zealots. On the other hand GNOME's up and coming albeit deceased file manager (go figure how that's possible) uses a decidedly GPL incompatible Mozilla for its rendering engine. Tables have turned but Richard Stalin^H^Hlman still stays in the same place. Sort of makes you question the man's integrity...
I think they threw away the CORBA baggage because they refused to live with the BigDesignUpfront. I think this was a big mental shift for the KDE team that day. See my other post for more detail.
When I'm talking about KDE being ahead I don't necessarily think of just feature sets. Both desktops offer various kinds of functionality. Some of it overlaps some of it doesn't. I'm talking about their respective philosophies of development and project management. I think that KDE developers are less prone to have such devastating flamewars because they don't have that sacred cow called the Big Design. They know that decisions made today may be overthrown tomorrow if the application requirements outgrow the present architecture. Hence they don't tend to sit and ponder what limitations their design may hit in three years time. This philosophy seems to be the exact opposite of GNOME who like to have the big design thrashed out before they proceed with coding (Look how long they took to implement Bonobo 1.0). Their design is therefore more brittle and changing it stirs more emotions. I believe this already gives KDE an edge and in the future I see them getting ahead even further. Your point about GNOME being later in the game is taken but you must remember there are far fewer KDE developers to GNOME developers. Once again a similarity between the KDE approach and the Extreme Programming methodology emerges...
I've watched this KDE/GNOME flamewar for the past couple of years. I came to the conclusion that GNOME is doomed to fail. Here's why.
GNOME folks took the approach of doing BigDesignUpfront while the KDE crowd concentrated on doing today's job today and leaving tomorrow's job for tomorrow. As a result their project progressed faster and they let their architecture emerge from the changing requirements. Hence they've changed the project management to a more agile model akin to that of ExtremeProgramming. I believe this approach is superior.
The prime example of the fundamental differences between the two project was the design of their component models where the GNOME team took eons to refine and polish Bonobo even though the didn't know upfornt what they'd use it for while the KDE team who admittedly took a similar approach with OpenParts they had the Courage to overthrow their flawed design and go with the SimplestThingThatCouldPossiblyWork. The situation with their widget toolkit was analogous: while the GNOME team made the politically correct decision at the time the KDE crew decided to go with the toolkit that gave them the highest productivity rate instead of sufffering from the NotInventedHere syndrome. If GNOME folks carry on like this making big (and often incorrect) decisions early in the project they will disintegrate just like many commercial projects do. And believe me I witnessed more than one Big Design that just crumbled and disintegrated under the pressure of everchanging requirements of a large software project.
KDE folk are definitely ahead of the game as they have a more agile development model. If only they paid more attention to UnitTests they would progress even faster IMNSHO.
Java as a learning language? Perhaps they should introduce Visual Basic or Visual Fox Pro? Why not? If we're bowing to commercial pressures let's do it all the way!
My opinion is that universities should stay away as much as possible from commercial bastardisations as humanely possible. There is a plethora of open languages that can be used in introductory courses. Python isn't a bad example. There is also something to be said for understanding pointer arithmetic in C. Most programmers bred on java have little understanding of underlying hardware architectures and it often bites them in the ass when it comes to real world problems. Java is also not as elegant as Sun Inc. Containers that just store Object(s) are a nightmare on larger projects for instance. Java's reliance on reflection is also a sign of bad OO design. C++ at least offers a partial solution to the problem in the form of templates and the language itself is not controlled by a single organization. Also its multiparadigm structure allows students to get grasp of concepts other than OO. It's not an easy language to learn and may not be the optimal choice for courses in a community college but all self respecting universities should think twice about picking Java as their teaching language. They should be training scientists not code monkeys.
I have yet to find another 'editor' that does what Emacs will do
One word: Codewright. Yeah not opensource but it does all that emacs can do and a lot more with greater flexibility.
Re:On track to be a bright shining star
on
Mozilla 0.9.1 Out
·
· Score: 2
Absolutely. Mozilla will shine long after JZW's club has gone bust or turned into a rednecks' hangout. Can you believe how much crap he gave the project after he left Netscape? I'm glad that mozilla developers proved JZW what an utter moron he is.
but it sounds like you are whoring open source for karma
You're a moron. After I moved countries last year while I was looking for work I toyed with the idea of founding my own software shop. I wanted to go into handheld programming. I thought about games or general purpose handhelds. The only realistic software market is in handheld games not apps but prohibitive pricing from nintendo prevented me from going ahead with the venture. I wanted to have a couple of GBA titles ready for this launch. I wanted to use my own money but I realised that all I had was pocket change compared to what the costs of dealing with Nintendo would be. That's why I'm pissed off with them.
If you sire think that quality software gets written in shops flooded with cash that use ISO9001 and UML and Rational Process you need your head seriously examined. Particularly 2d titles are still less "resource hungry" than 3d games and given the right conditions would open the market for lots more companies (and games as a result) some of which would no doubt be crap while others would be real gems.
Let's put it in context: do you still play some of your C64/Spectrum/ on an emulator? I sure do.
I've played with the "free" version of the GBA SDK. It's not endorsed or encouraged by Nintendo though. I'm not even sure if it's legal... What is Nintendo afraid of? I mean if I develop a game for GBA I still have to put it on a cartridge before I can distribute it en masse. So Nintendo could control the distribution of the cartridges while still allowing developers to dabble with the SDK. They would still be able to verify the quality of games being published. If they are worried about "rogue" distribution channels they can provide a certification programme akin to the "Designed for Windows 9X" from Microsoft. There is no reason for Nintendo to hoard the SDK other than to retain the effective monopoly on games for handhelds.
What I want is for nintendo to lower the barrier to entry for individual developers and small software shops. It's stil an extremely painful process to acquire a license for developing gb/gba games together with the SDK. If there was a handheld gaming console with a lower barrier to entry maybe we would see a lot more Open Source 2d games and lots more small game shops specialising in games for handhelds. I think Nintendo are stifling the market by making it so hard for enthusiasts to develop and distribute games on their platforms.
Slashdot Mirror
Is the Kompany profitable? If not, when do you expect it to be?
I only get half of your post. You seem to be advocating XML-RPC/SOAP like things over CORBA because CORBA is blocking by nature. And so is XML-RPC right? What DO you recommend for doing distributed computing? Let's say you want to have your app deployed on a cluster of boxen for load balancing or failover protection. Surely you don't advocate creating sockets and marshalling stuff by hand every time you have to talk to another node on a cluster, do you?
Nope. The guy who wrote the java version is at least as competent as I am (not that that's saying much really!). It's java, Swing in particular. It's reasonably responisive half of the time but when it enters one of its mood swings (pun intended) it can take up to ten seconds for the UI to 'wake up' again. I notice that with JBuilder too. It's not our programmers who are at fault it's the runtime.
Sun provides a JDBC spec which driver writers can support.
I know Sun don't make them. But I'm very happy with Sybase in general it's just the java side of things again. Sybase is a quality product and I don't understand why we have issues solely with the JDBC side of things.
If you want EJBs, look at Orion.
I haven't tried it. I may do so since you have good experiences with it. I've been looking into the expensive side of the market and was less than impressed with what I saw. I'd say that Borland is probably the best of that lot (at least it has corba under the hood so other languages can talk to it).
Thanks for the reply. Very calm and balanced (am I really on slashdot?) given my ranty and confrontational initial post :)
What does "a LOT faster than Java" mean?
Two orders of magnitude. That's roughly how much faster a desktop app that I rewrote in C++ for my employer works these days. If you think that users don't care if menus take 10 seconds to unroll you obviously never talked to your customers directly.
XML parsing in java sucks. As soon as I add validation the bloody thing takes seconds(!) to build the DOM tree for even the simplest of documents! Fuck knows how they made is this slow. Must be full of O(n^2) algorithms.
UI code. I'll be humane and avoid discussing it. I think that Swing products speak for themselves...
I notice with some amusement that three of the four data sources you mention are MS databases. Now that's really a wide range of support!
I'll take that over half assed, broken JDBC drivers for Sybase any time. Does this language have a SINGLE API that's not broken?
I won't even mention the quality of other Java related prdoucts such as servlet containers (yes I evaluated a number of them and they are all buggy as shit) and don't get me started on the dubious benefits of EJB with it's $15000/CPU rates. Now that's competitive and antimonopolistic practice from SUNW!!! Fix the pricing at such exuberant rates that nobody except for the few select giants (hi IBM, hi BEA) can compete or SUN won't "authorise" your EJB container if you don't start charging an arm and a leg for it. Wake up buddy. If you're a Scott McNealy serf we're out there to get ya!!!
No more $150000 lame crappy servers. M$ with sane pricing is coming your way!!!
Wrong. I am one of the senior developers on my team and I loudly objected to code reviews as I consider them extremly harmful for the reasons mentioned in my original post. I think pair programming is a much better idea with a 'live' code review that happens in real time, is less boring to the parties involved and results in a code of much higher quality than any solitary code review can aspire to produce. Most code I write forms the foundation of the application and most of it is a template based framework (stl extensions). It's complex enough that nobody even tries reviewing it. They just take my word for it that it works :).
Code reviews are a terrible practice. They either turn into a week of web surfing and at the end everybody says all of the code is perfect or what's worse they are taken seriously and turn into a morale killer. People don't like having their competence questioned. Even if they are fairly junior they like to think their work is up to scratch. Senior people don't like being questioned about their particular programming style: they know they have a number of successful projects already behind them and don't want to be questioned on how they perform the work. If it does the job and is maintainable it should be good enough. Code reviews almost always end up turning into personal attacks. It's a sneaky management ploy to turn developers against one another. They cause harm, quarrel amongst seniors and intimidation for juniors. THEY SUCK!!!!!!
How to avoid the problems of lack of code reviews? Number one is have good comprehensive unit tests. They tell you a lot more about code's correctness than any amount of code reviews you can think of. Pair programming eliminates the issue of "lonely wolves" where individual programmers hoard a piece of application and don't let anyone else near it. These two suggestions are the fundamental blocks of extreme programming.
It does not vary from one employer to another. It's always "do it on your own read about the things you need to know in your own time. We might pay for the books you need though if it's not too much.". That's as far as the idea of staff development stretches in 99.99% of software shops.
That slashdot and other OSDN sites bear the main responsibility for generating revenue. Slashdot in particular as it's frequented by so many people daily. One way to do it may be to insert some extra data (such as tags) into comments and help boost revenue and creating some subtle albeit effective advertising. Something akin to SmartTags should go a long way towards compensating for the cut revenue from hardware sales. How big a job would it be to implement that in slashcode?
Trading in VA Linux was halted for news. The issue last changed hands at $3.26
Why was trading suspended. Is it such bad news that they think investors may freak out?
The announcement you linked to is almost a year old... And as far as I know this was NOT an official statement just some more rumour mongering on slashdot. If it indeed came from the horse's mouth so to speak, then that just means it's yet another promise they failed to deliver on. That's even worse than making no promises in the first place.
There is a grain of truth in gates' ramblings too. The mess of the licensing issues that Richard Stalin^H^Hlman created is and should be of concern to any software company who isn't keen on going full GPL. Figuring out what you can and can't do with all those pieces that have strings attatched to them must be every lawyers nightmare. Even da man himself seems to be a bit baffled by all this licensing mess. He still can't tolerate KDE which is now decidedly GPL compatible while he gives his blessings to GNOME which uses Mozilla for the rendering engine in its up and coming albeit deceased (yeah, go figure how that works!) file manager. Mozilla being under the MPL license is decidedly GPL incompatible. Anyone else see the hipocricy here?
The site www.fuckedcompany.com is running Microsoft-IIS/4.0 on NT4/Windows 98.
Right on! Lest we forget that Mozilla which is used as the rendering engine in GNOME is not GPLed or even GPL compatible. It takes more than logic it figure out GPL zealots. Take care.
Yeah, things took an interesting twist lately. Since KDE is now fully GPLd and uses the decidedly GPL compatible QT it should be the preferred choice of GPL zealots. On the other hand GNOME's up and coming albeit deceased file manager (go figure how that's possible) uses a decidedly GPL incompatible Mozilla for its rendering engine. Tables have turned but Richard Stalin^H^Hlman still stays in the same place. Sort of makes you question the man's integrity...
I think they threw away the CORBA baggage because they refused to live with the BigDesignUpfront. I think this was a big mental shift for the KDE team that day. See my other post for more detail.
When I'm talking about KDE being ahead I don't necessarily think of just feature sets. Both desktops offer various kinds of functionality. Some of it overlaps some of it doesn't. I'm talking about their respective philosophies of development and project management. I think that KDE developers are less prone to have such devastating flamewars because they don't have that sacred cow called the Big Design. They know that decisions made today may be overthrown tomorrow if the application requirements outgrow the present architecture. Hence they don't tend to sit and ponder what limitations their design may hit in three years time. This philosophy seems to be the exact opposite of GNOME who like to have the big design thrashed out before they proceed with coding (Look how long they took to implement Bonobo 1.0). Their design is therefore more brittle and changing it stirs more emotions. I believe this already gives KDE an edge and in the future I see them getting ahead even further. Your point about GNOME being later in the game is taken but you must remember there are far fewer KDE developers to GNOME developers. Once again a similarity between the KDE approach and the Extreme Programming methodology emerges...
GNOME folks took the approach of doing BigDesignUpfront while the KDE crowd concentrated on doing today's job today and leaving tomorrow's job for tomorrow. As a result their project progressed faster and they let their architecture emerge from the changing requirements. Hence they've changed the project management to a more agile model akin to that of ExtremeProgramming. I believe this approach is superior.
The prime example of the fundamental differences between the two project was the design of their component models where the GNOME team took eons to refine and polish Bonobo even though the didn't know upfornt what they'd use it for while the KDE team who admittedly took a similar approach with OpenParts they had the Courage to overthrow their flawed design and go with the SimplestThingThatCouldPossiblyWork. The situation with their widget toolkit was analogous: while the GNOME team made the politically correct decision at the time the KDE crew decided to go with the toolkit that gave them the highest productivity rate instead of sufffering from the NotInventedHere syndrome. If GNOME folks carry on like this making big (and often incorrect) decisions early in the project they will disintegrate just like many commercial projects do. And believe me I witnessed more than one Big Design that just crumbled and disintegrated under the pressure of everchanging requirements of a large software project.
KDE folk are definitely ahead of the game as they have a more agile development model. If only they paid more attention to UnitTests they would progress even faster IMNSHO.
My opinion is that universities should stay away as much as possible from commercial bastardisations as humanely possible. There is a plethora of open languages that can be used in introductory courses. Python isn't a bad example. There is also something to be said for understanding pointer arithmetic in C. Most programmers bred on java have little understanding of underlying hardware architectures and it often bites them in the ass when it comes to real world problems. Java is also not as elegant as Sun Inc. Containers that just store Object(s) are a nightmare on larger projects for instance. Java's reliance on reflection is also a sign of bad OO design. C++ at least offers a partial solution to the problem in the form of templates and the language itself is not controlled by a single organization. Also its multiparadigm structure allows students to get grasp of concepts other than OO. It's not an easy language to learn and may not be the optimal choice for courses in a community college but all self respecting universities should think twice about picking Java as their teaching language. They should be training scientists not code monkeys.
One word: Codewright. Yeah not opensource but it does all that emacs can do and a lot more with greater flexibility.
Absolutely. Mozilla will shine long after JZW's club has gone bust or turned into a rednecks' hangout. Can you believe how much crap he gave the project after he left Netscape? I'm glad that mozilla developers proved JZW what an utter moron he is.
You're a moron. After I moved countries last year while I was looking for work I toyed with the idea of founding my own software shop. I wanted to go into handheld programming. I thought about games or general purpose handhelds. The only realistic software market is in handheld games not apps but prohibitive pricing from nintendo prevented me from going ahead with the venture. I wanted to have a couple of GBA titles ready for this launch. I wanted to use my own money but I realised that all I had was pocket change compared to what the costs of dealing with Nintendo would be. That's why I'm pissed off with them.
Then license distribution not development!
Let's put it in context: do you still play some of your C64/Spectrum/ on an emulator? I sure do.
I've played with the "free" version of the GBA SDK. It's not endorsed or encouraged by Nintendo though. I'm not even sure if it's legal... What is Nintendo afraid of? I mean if I develop a game for GBA I still have to put it on a cartridge before I can distribute it en masse. So Nintendo could control the distribution of the cartridges while still allowing developers to dabble with the SDK. They would still be able to verify the quality of games being published. If they are worried about "rogue" distribution channels they can provide a certification programme akin to the "Designed for Windows 9X" from Microsoft. There is no reason for Nintendo to hoard the SDK other than to retain the effective monopoly on games for handhelds.
What I want is for nintendo to lower the barrier to entry for individual developers and small software shops. It's stil an extremely painful process to acquire a license for developing gb/gba games together with the SDK. If there was a handheld gaming console with a lower barrier to entry maybe we would see a lot more Open Source 2d games and lots more small game shops specialising in games for handhelds. I think Nintendo are stifling the market by making it so hard for enthusiasts to develop and distribute games on their platforms.