Even when tied to app servers.. Code written to run in Weblogic will run in it on Windows, or on Solaris, or on HP-UX.
It means you can still deploy on top-spec midrange servers without having to develop on them. You can test on cheap linux boxes while giving your developers the productivity tools offered by Windows (ack, am I really saying that?:)
Does it mean you can deploy straight into Websphere or JBoss or Oracle App Server? Nope, not without 'porting'.
If you don't use server specific capabilities (because you have a lightweight web-app) then the intention is that you'll be able to re-use in a different app server with ease. I haven't tried that myself though - I haven't tried to create products in Java, so support for multiple app servers hasn't been necessary, and thus it's been better to optimise to the server than retain portability.
Of course, whichever app server you use, you can still use struts, or log4j, or hibernate, whatever your OS, without recompilation - that's a big big advantage as it does drastically reduce the risks of using third party libraries, and that translates to a cost saving.
Not run anywhere. But it does run in plenty of places.
I must admit, not tried getting it onto a PPC linux setup. If you can get the VM to run though, everything else written in Java has a good chance of just working. That's nice. And lets face it, Linux didn't run on PPC until someone did a lot of work to port it.
Simple fact is, I can download a library from the net. I don't know whether it was compiled on linux, PPC linux, an IBM mainframe, Windows or HP-UX. I don't care. It will work anyway.
The code I write is equally portable. Usable as-is, with no modifications.
No, java portability isn't ubiquitous. But don't underestimate it either.
Enterprise developers deal with inadequacies in Java by doing what everyone else does: Writing their way around it. This is where struts, hibernate, ant, junit came from. Most enterprise shops use open source code extensively, in addition to the core language.
This doesn't make the language bad.
As a senior technical person in a large enterprise I too seek the holy grail of letting business people enter their business processes into a pretty front-end and getting a fully featured website with full supply chain integration automatically generated.
I also know that this just isn't yet possible. There have been many advances towards this, and certainly developer productivity has risen massively even in the last few years.
Does Ruby on Rails help? No. For a data driven system, it's great. For a complex system integrating with multiple other systems, it's no easier to use. And because it does so much magic under the skin, if that magic doesn't meet your needs, you struggle more to change it.
Java is not the answer. But I can happily recommend its use for server-side development, along with PHP or.NET or even Ruby, according to the situation, the skillsets, the other factors involved.
"I like open source because I think it makes *better* software that is more *useful* to me, not as part of some moral struggle. "
The point of many people posting here is that open sourcing java wouldn't necessarily make it better. There is even a viewpoint that it would make it worse.
The point of the person you replied to is that frankly it doesn't matter how good or bad it is, they wont use it because they don't agree with the restrictions it imposes upon them. That's a valid choice, and a more logical viewpoint than your own.
If you can demonstrate that making it open source will improve it then I'll concede the validity of your point. But even then, unless it's GPL, it still wont be acceptable to some people.
"I was once writing a serach engine in a language I didn't know how to use, and it took a gig of RAM to do something stupid that I told it to do"
Please, don't blame the language for your incompetence. I have this horrible feeling that the Flyweight pattern would have saved you much grief.
I haven't checked, so I could accept that Treemap is suboptimal for what you were trying to use it for. There's nothing that says you have to use it.
Disclaimer: I have in my possession (propriety commercial) code for a search engine that searches across over a gig of data. It takes up about 20MB of ram more than the data takes on disk in a flat file. It was written in a couple of hours.
Further disclaimer: I didn't write it. Although I did suggest a performance optimisation. It was returning results in under 10ms before the optimisation.
I completely agree that graphical UIs are not something I'd want to write in Java.
However, "embedding it into a webserver" describes a significant percentage of java development. You rarely see crashes on most corporate sites using it, and the standard APIs are freely available - most people use JSPs and Servlets, both APIs for which you can download the source code from Suns website, quite apart from the extensive documentation.
Most people also use struts, or JSF or Spring, or other frameworks that sit on top of the core Java platform. These tend to be less well documented. They also tend to be open source. Your point thus escapes me entirely.
Sorry, but when I'm dealing with code written offshore by developers of mixed ability in a system integrating my mainframe to my fulfilment systems with customer web access, online payments, content management and back office consolidation thrown in then I want a language that's immediately readable.
Perl is exceedingly brief to write. It's also very difficult to read. PHP/Python are better, but most code I see is frankly horrible.
With Java the APIs and libraries - even third party, even open source - have descriptive names. They make sense. You can figure out what's going on from the method and classnames, without having to go and read them.
This makes unfamiliar code easier to read. I've done Delphi/C/C++/perl/PHP programming, and none of them have as easy to read code as Java. I value that a lot.
That you have to type an extra 32 characters to open a file? Good! Hell, you're not typing enough already - 'in' is a bad name for a variable. How about making it descriptive, tell the reader what you're reading.
Modern IDEs do most of the typing for you. The clarity of the code that's written is more important than the extra two seconds you need to write it.
You had to recompile. With Java there's no need to recompile.
That makes a big difference in corporate environments. Write on windows. Build on linux. Deploy on solaris.
Mix and match according to the hardware you have.
This is particularly useful when re-using third party libraries. Many are commercial (IBM / BEA in particular) and many are open source. But you can download a jar file and use that straight off, on any OS. No need to find the source, build it.
This makes java quick and easy to use in a corporate environment. Linux has many strengths, but wont replace Java's portability in this regard.
Actually, Gnu is a good name. The recursive acronym isn't necessarily board member friendly, but it is not offensive, it's difficult to misinterpret, and it doesn't put anybody off anything.
Prepending other names with 'g' on the other hand works only when it's a good word (like Gopher, or Gnome).
Actually, people with years in HTML can just get a job at will.
If, of course, they've kept up. HTML, CSS, xHTML, Javascript, AJAX.. Not many people can create interfaces in those technologies, quickly, consistently, reliably, and looking good.
It's become a skillset all of its own - and most web applications are written to allow the people with that skillset to use it, and the people with programming language skills to write the underlying system that produces it.
I wish I had the same certainty as a building architect.
They know the weight bearing properties of the materials they use. They have centuries of good practice to learn and re-use. They can model exactly the forces and loads within buildings. They can predict how things will turn out.
They still design bridges that collapse, buildings that fail structurally, expensive follies.
I reckon software architects, working in a constantly changing environment with ill-defined technologies, integrating artefacts that don't exist yet (and have never existed before), with a constantly falling budget and constantly rising requirements.. I reckon they don't do too badly.
Different roles, different challenges. I'll agree they're not easily comparable. I don't think building architects are necessarily any better, more skilled, more professional. They're just different.
In theory someone could learn the theory and do architecture.
In practice it's better to have the experience first.
I interview people for architecture jobs. I expect them to be able to think on their feet, handle technologies that aren't familiar to them, and instinctively do the right thing.
As with any profession, people that can do the right thing when in a position of limited information do so because they've been there before. They know what works and what doesn't. They know when to compromise, and what the risks of that are.
Learning architecture from a book will lead to ivory tower designs. They'll lack real-world implementability. No scenario at any established company is free from constraint, no architecture easy to change at will - everything you do has a cost, and people that don't want to pay it, and those compromises are what makes the architecture work or fail.
In building plumbing works. You tell the plumber 'toilet goes here, washing machine there, bath up there'.
In software, the toilet exists but uses milk not water to flush. The bath exists but was used for a charity raising effort and is full of beans. The washing machine has non-standard fittings and the vendor lied about its dimensions so it wont fit into the kitchen.
Someone experienced can handle these issues. Good "Keyboard banger"s (as you put it) will be handling some of these issues in their day to day work. They're learning how to handle them. They're getting better at it.
Some people never learn.
Good architects are hard to find. This is because it's a tremendously diverse role. You do need good technical knowledge, you do need experience in delivering software projects, you do need good mentoring abilities, you do need good communications skills, you do need domain knowledge, you do need to manage your time (and know when and how to delegate and trust those you're delegating to), you do need to be able to man-manage (and that includes managing people senior to you) and you do need to pull it all together at once.
Get a PhD straight out of uni at 28 and give him an architecture job. If he's intelligent, sure, he can learn. Am I going to give him the chance? Not if I can promote a good software engineer first.
I think architecture and algorithms are very different beasts.
In architecture the algorithm can be dismissed as 'detail'.
Google has a search algorithm. They've grown big because everyone deems it to be good. However, they've also grown big because they have the software and hardware infrastructure needed to make it possible for millions of people to use that algorithm.
Architecture is obviously more than just infrastructure. But even software architecture covers far more ground than algorithms.
(Naturally poor algorithm choice will destroy even the greatest of architectures. If Google didn't return good results, no matter how great their data centres and network infrastructure is, people wouldn't use them)
My experience is that under hard braking (in a skid or with ABS - I've done both) the front of the car dips and stays dipped. There will be some bouncing, but I'd suggest the shift in weight front to back is inconsequential relative to the loading on the front of the car anyway.
Of course, I'm going on intelligent guesswork. And as you point out, it doesn't actually matter to me, because I'm never going to pump the brakes in unison with shifts in car weight under emergency conditions. I'm too busy reacting to the emergency;)
My driving instructor actually told me when I passed the test: If I want to drive fast, legally, find some good country roads and take them at 60.
Quite bluntly where I live there are curves that most people take at 20-30. Better yet, they're slightly downhill so you have great visibility of the next mile or so of road.
I know my car can get around those bends considerably faster. Perfectly legal, and I am actually pushing my car to the limit.
Irresponsible? Maybe. If a tyre blows, if there's (unusually) mud on the road, I may lose control. Since I slow down if there's oncoming traffic, or horses, or cyclists, or pedestrians, I'm only endangering myself. My choice, my car, my life.
Why "when you buy a sports car"? Why not "when you buy any car"?
First thing I do in any car I buy is take it to roads I know well when there's minimal traffic around and find out just what it can do.
My previous car lost traction at just over 65mph around a bend, but lost with all four wheels at once - flat slide, but releasing the throttle and the frictional loss of speed meant that I regained control fast.
The new car is the same, except it does this at over 70mph.
In the wet it wont do so well. There's a curve I can take at just over 80 in the dry, but when it's wet I drift across two lanes at 70.
Sharper curves at slower speeds, braking from 90 to 0 in as short a period as possible, straight line stability at speed.. I try them all in the first few hours I own a car.
Could I take the car beyond its limits? Easily. Do I? Rarely, and only intentionally, and only when I have damn good visibility of the road ahead.
Most times the car's capable of taking curves far faster than I can react if there's something in the way. So I don't go that fast. I don't want a horse in my passenger seat.. But I do know what the car can handle, and I know what I can handle in it. And it's not a sports car. It's a five door family saloon.
Voice of sanity here. Glasses definitely don't hurt social life.
Hearing loss on the other hand definitely does. Trust me, it's fucking terrible being in a social situation and only being able to pick up fragments of conversation.
Regular digital hearing aids work superbly in a defined environment - seminars, business meetings, small group conversations. Put them into a crowded noisy environment, like a pub, a club, even a busy cafe, and their benefit is vastly reduced.
Add to that the fact that hearing aids are a pain to carry around when you don't wear them all the time (because they're uncomfortable and they're giving minimal benefit) and having them built into the glasses does have a certain attraction. I take off my glasses when I'm reading, using a computer, sleeping (or dozing on a train). I put them on when I'm talking to people (it helps me hear them better). So I'd have hearing aids on at the right times, and off at other times.
So I'm interested in this. The directional capability may well assist in currently sub-optimal situations, and if the glasses look no worse than the ones I wear every day anyway then it could at worse be one less thing to carry around.
Oh please. If the police come into my house and find one person dead, a gun on the ground and three people stood around looking innocent, they'll find out who did the shooting pretty easily.
Firing a weapon leaves traces.
Unless your Al Qaeda operatives had time to strip off, shower, find clean clothes and comb their beards between shooting the US forces and their house being taken then modern forensic techniques provide ample proof useable in a court of law.
You're trying to excuse detention without trial, without proof, when often the scenario is nowhere near as clear-cut as your example. Most people being held are not captured in a warzone, let alone while taking part in actual armed conflict.
Slashdot Mirror
Even when tied to app servers.. Code written to run in Weblogic will run in it on Windows, or on Solaris, or on HP-UX.
It means you can still deploy on top-spec midrange servers without having to develop on them. You can test on cheap linux boxes while giving your developers the productivity tools offered by Windows (ack, am I really saying that?
Does it mean you can deploy straight into Websphere or JBoss or Oracle App Server? Nope, not without 'porting'.
If you don't use server specific capabilities (because you have a lightweight web-app) then the intention is that you'll be able to re-use in a different app server with ease. I haven't tried that myself though - I haven't tried to create products in Java, so support for multiple app servers hasn't been necessary, and thus it's been better to optimise to the server than retain portability.
Of course, whichever app server you use, you can still use struts, or log4j, or hibernate, whatever your OS, without recompilation - that's a big big advantage as it does drastically reduce the risks of using third party libraries, and that translates to a cost saving.
Not run anywhere. But it does run in plenty of places.
I must admit, not tried getting it onto a PPC linux setup. If you can get the VM to run though, everything else written in Java has a good chance of just working. That's nice. And lets face it, Linux didn't run on PPC until someone did a lot of work to port it.
Simple fact is, I can download a library from the net. I don't know whether it was compiled on linux, PPC linux, an IBM mainframe, Windows or HP-UX. I don't care. It will work anyway.
The code I write is equally portable. Usable as-is, with no modifications.
No, java portability isn't ubiquitous. But don't underestimate it either.
You can't write Ruby on Rails in Java? Oh. Best tell these guys: https://trails.dev.java.net/
Enterprise developers deal with inadequacies in Java by doing what everyone else does: Writing their way around it. This is where struts, hibernate, ant, junit came from. Most enterprise shops use open source code extensively, in addition to the core language.
This doesn't make the language bad.
As a senior technical person in a large enterprise I too seek the holy grail of letting business people enter their business processes into a pretty front-end and getting a fully featured website with full supply chain integration automatically generated.
I also know that this just isn't yet possible. There have been many advances towards this, and certainly developer productivity has risen massively even in the last few years.
Does Ruby on Rails help? No. For a data driven system, it's great. For a complex system integrating with multiple other systems, it's no easier to use. And because it does so much magic under the skin, if that magic doesn't meet your needs, you struggle more to change it.
Java is not the answer. But I can happily recommend its use for server-side development, along with PHP or
"I like open source because I think it makes *better* software that is more *useful* to me, not as part of some moral struggle. "
The point of many people posting here is that open sourcing java wouldn't necessarily make it better. There is even a viewpoint that it would make it worse.
The point of the person you replied to is that frankly it doesn't matter how good or bad it is, they wont use it because they don't agree with the restrictions it imposes upon them. That's a valid choice, and a more logical viewpoint than your own.
If you can demonstrate that making it open source will improve it then I'll concede the validity of your point. But even then, unless it's GPL, it still wont be acceptable to some people.
Me, I just wish I could program more.
Allow me to translate:
"I was once writing a serach engine in a language I didn't know how to use, and it took a gig of RAM to do something stupid that I told it to do"
Please, don't blame the language for your incompetence. I have this horrible feeling that the Flyweight pattern would have saved you much grief.
I haven't checked, so I could accept that Treemap is suboptimal for what you were trying to use it for. There's nothing that says you have to use it.
Disclaimer: I have in my possession (propriety commercial) code for a search engine that searches across over a gig of data. It takes up about 20MB of ram more than the data takes on disk in a flat file. It was written in a couple of hours.
Further disclaimer: I didn't write it. Although I did suggest a performance optimisation. It was returning results in under 10ms before the optimisation.
I completely agree that graphical UIs are not something I'd want to write in Java.
However, "embedding it into a webserver" describes a significant percentage of java development. You rarely see crashes on most corporate sites using it, and the standard APIs are freely available - most people use JSPs and Servlets, both APIs for which you can download the source code from Suns website, quite apart from the extensive documentation.
Most people also use struts, or JSF or Spring, or other frameworks that sit on top of the core Java platform. These tend to be less well documented. They also tend to be open source. Your point thus escapes me entirely.
Sorry, but when I'm dealing with code written offshore by developers of mixed ability in a system integrating my mainframe to my fulfilment systems with customer web access, online payments, content management and back office consolidation thrown in then I want a language that's immediately readable.
Perl is exceedingly brief to write. It's also very difficult to read.
PHP/Python are better, but most code I see is frankly horrible.
With Java the APIs and libraries - even third party, even open source - have descriptive names. They make sense. You can figure out what's going on from the method and classnames, without having to go and read them.
This makes unfamiliar code easier to read. I've done Delphi/C/C++/perl/PHP programming, and none of them have as easy to read code as Java. I value that a lot.
That you have to type an extra 32 characters to open a file? Good! Hell, you're not typing enough already - 'in' is a bad name for a variable. How about making it descriptive, tell the reader what you're reading.
Modern IDEs do most of the typing for you. The clarity of the code that's written is more important than the extra two seconds you need to write it.
You had to recompile. With Java there's no need to recompile.
That makes a big difference in corporate environments. Write on windows. Build on linux. Deploy on solaris.
Mix and match according to the hardware you have.
This is particularly useful when re-using third party libraries. Many are commercial (IBM / BEA in particular) and many are open source. But you can download a jar file and use that straight off, on any OS. No need to find the source, build it.
This makes java quick and easy to use in a corporate environment. Linux has many strengths, but wont replace Java's portability in this regard.
In around, oh, about 1996.
Oh, there's a coincidence. Look when the film was released..
Personally I want a full qwerty keyboard built into the device. So I've been waiting for the E70 for months.
Very similar specs to the N80, and looks small and discreet for normal use.
I visit a lot of travel sites on company time, and my boss thanks me for it.
Or is it different when you're architecting the web presence of a large travel company?
http://www.pixyland.org/peterpan/photo_closeups_p
Oh, my bad, that's pixie rather than elf..
Actually, Gnu is a good name. The recursive acronym isn't necessarily board member friendly, but it is not offensive, it's difficult to misinterpret, and it doesn't put anybody off anything.
Prepending other names with 'g' on the other hand works only when it's a good word (like Gopher, or Gnome).
Actually, people with years in HTML can just get a job at will.
If, of course, they've kept up. HTML, CSS, xHTML, Javascript, AJAX.. Not many people can create interfaces in those technologies, quickly, consistently, reliably, and looking good.
It's become a skillset all of its own - and most web applications are written to allow the people with that skillset to use it, and the people with programming language skills to write the underlying system that produces it.
I wish I had the same certainty as a building architect.
They know the weight bearing properties of the materials they use. They have centuries of good practice to learn and re-use. They can model exactly the forces and loads within buildings. They can predict how things will turn out.
They still design bridges that collapse, buildings that fail structurally, expensive follies.
I reckon software architects, working in a constantly changing environment with ill-defined technologies, integrating artefacts that don't exist yet (and have never existed before), with a constantly falling budget and constantly rising requirements.. I reckon they don't do too badly.
Different roles, different challenges. I'll agree they're not easily comparable. I don't think building architects are necessarily any better, more skilled, more professional. They're just different.
In theory someone could learn the theory and do architecture.
In practice it's better to have the experience first.
I interview people for architecture jobs. I expect them to be able to think on their feet, handle technologies that aren't familiar to them, and instinctively do the right thing.
As with any profession, people that can do the right thing when in a position of limited information do so because they've been there before. They know what works and what doesn't. They know when to compromise, and what the risks of that are.
Learning architecture from a book will lead to ivory tower designs. They'll lack real-world implementability. No scenario at any established company is free from constraint, no architecture easy to change at will - everything you do has a cost, and people that don't want to pay it, and those compromises are what makes the architecture work or fail.
In building plumbing works. You tell the plumber 'toilet goes here, washing machine there, bath up there'.
In software, the toilet exists but uses milk not water to flush. The bath exists but was used for a charity raising effort and is full of beans. The washing machine has non-standard fittings and the vendor lied about its dimensions so it wont fit into the kitchen.
Someone experienced can handle these issues. Good "Keyboard banger"s (as you put it) will be handling some of these issues in their day to day work. They're learning how to handle them. They're getting better at it.
Some people never learn.
Good architects are hard to find. This is because it's a tremendously diverse role. You do need good technical knowledge, you do need experience in delivering software projects, you do need good mentoring abilities, you do need good communications skills, you do need domain knowledge, you do need to manage your time (and know when and how to delegate and trust those you're delegating to), you do need to be able to man-manage (and that includes managing people senior to you) and you do need to pull it all together at once.
Get a PhD straight out of uni at 28 and give him an architecture job. If he's intelligent, sure, he can learn. Am I going to give him the chance? Not if I can promote a good software engineer first.
I think architecture and algorithms are very different beasts.
In architecture the algorithm can be dismissed as 'detail'.
Google has a search algorithm. They've grown big because everyone deems it to be good. However, they've also grown big because they have the software and hardware infrastructure needed to make it possible for millions of people to use that algorithm.
Architecture is obviously more than just infrastructure. But even software architecture covers far more ground than algorithms.
(Naturally poor algorithm choice will destroy even the greatest of architectures. If Google didn't return good results, no matter how great their data centres and network infrastructure is, people wouldn't use them)
Guess which t-shirt I'm wearing today.
http://www.ntkmart.co.uk/images/ungood.jpg
Wow! How do you drive with all that on?
My experience is that under hard braking (in a skid or with ABS - I've done both) the front of the car dips and stays dipped. There will be some bouncing, but I'd suggest the shift in weight front to back is inconsequential relative to the loading on the front of the car anyway.
Of course, I'm going on intelligent guesswork. And as you point out, it doesn't actually matter to me, because I'm never going to pump the brakes in unison with shifts in car weight under emergency conditions. I'm too busy reacting to the emergency
Sarcastically, the fastest way to stop is to hit something solid.
But more seriously, how does suspension change braking dynamics?
My driving instructor actually told me when I passed the test: If I want to drive fast, legally, find some good country roads and take them at 60.
Quite bluntly where I live there are curves that most people take at 20-30. Better yet, they're slightly downhill so you have great visibility of the next mile or so of road.
I know my car can get around those bends considerably faster. Perfectly legal, and I am actually pushing my car to the limit.
Irresponsible? Maybe. If a tyre blows, if there's (unusually) mud on the road, I may lose control. Since I slow down if there's oncoming traffic, or horses, or cyclists, or pedestrians, I'm only endangering myself. My choice, my car, my life.
Why "when you buy a sports car"? Why not "when you buy any car"?
First thing I do in any car I buy is take it to roads I know well when there's minimal traffic around and find out just what it can do.
My previous car lost traction at just over 65mph around a bend, but lost with all four wheels at once - flat slide, but releasing the throttle and the frictional loss of speed meant that I regained control fast.
The new car is the same, except it does this at over 70mph.
In the wet it wont do so well. There's a curve I can take at just over 80 in the dry, but when it's wet I drift across two lanes at 70.
Sharper curves at slower speeds, braking from 90 to 0 in as short a period as possible, straight line stability at speed.. I try them all in the first few hours I own a car.
Could I take the car beyond its limits? Easily. Do I? Rarely, and only intentionally, and only when I have damn good visibility of the road ahead.
Most times the car's capable of taking curves far faster than I can react if there's something in the way. So I don't go that fast. I don't want a horse in my passenger seat.. But I do know what the car can handle, and I know what I can handle in it. And it's not a sports car. It's a five door family saloon.
Voice of sanity here. Glasses definitely don't hurt social life.
Hearing loss on the other hand definitely does. Trust me, it's fucking terrible being in a social situation and only being able to pick up fragments of conversation.
Regular digital hearing aids work superbly in a defined environment - seminars, business meetings, small group conversations. Put them into a crowded noisy environment, like a pub, a club, even a busy cafe, and their benefit is vastly reduced.
Add to that the fact that hearing aids are a pain to carry around when you don't wear them all the time (because they're uncomfortable and they're giving minimal benefit) and having them built into the glasses does have a certain attraction. I take off my glasses when I'm reading, using a computer, sleeping (or dozing on a train). I put them on when I'm talking to people (it helps me hear them better). So I'd have hearing aids on at the right times, and off at other times.
So I'm interested in this. The directional capability may well assist in currently sub-optimal situations, and if the glasses look no worse than the ones I wear every day anyway then it could at worse be one less thing to carry around.
Oh please. If the police come into my house and find one person dead, a gun on the ground and three people stood around looking innocent, they'll find out who did the shooting pretty easily.
Firing a weapon leaves traces.
Unless your Al Qaeda operatives had time to strip off, shower, find clean clothes and comb their beards between shooting the US forces and their house being taken then modern forensic techniques provide ample proof useable in a court of law.
You're trying to excuse detention without trial, without proof, when often the scenario is nowhere near as clear-cut as your example. Most people being held are not captured in a warzone, let alone while taking part in actual armed conflict.
I'm not buying.