People hate Java because it's a language that was born of an advertising campaign and not a specific need in the technology field.
People hate Java because the technology has been caught in the middle of several commercial interests and platform wars, which has crippled the promise of Java's stability and reliability.
It's a language similar to cobol in purpose, w/o a lot of the features of cobol that make it harder to work with. One of the main purposes of java is to provide a more OOP like language, though it does fail in some resepects in comparisons to true OOP languages like python and ruby. It's very clear to read vs something like perl due to the simple language rules.
Over the years, the 10 or so years, the language has become quite stable and what not. Scalability is an issue due to the garbage collector, but just like any language, you learn not to do things in an odd/bad way, you can work with it well.
People hate Java because it's a lie. Java promised a new generation language that was to be cross-platform compatible, but it's actually less cross-platform compatible than C/C++.
It's cross platform on the largely used platforms. Not as an excuse for sun. It's just so. It does suck. Uh.. the end:)
People hate Java because it's slow as molasses. Need an example? Take a look at Puzzle Pirates, a very clever multiplayer online game, that because the developers were foolish enough to use Java, runs ten times slower than it should and is painful to use as a result.
Don't go looking at the graphics aspect. It's an anomoly of slowness among the things it does fast. It's also slow in object creation. But it is fast on execution of code. Stuff like the HotSpot feature in JVM can optimize on the fly..
People hate Java because it sucks. I'm sorry to those of you who are Java programmers and are finding less jobs, but no sane company wants to use this technology when there are other systems available that offer better performance, reliability and longevity.
While I appreciate the value of Python, I would hate having to use it. I'm not fond of indent based block languages. Space-to-tab conversions would drive me nuts.:) But hey, if you like it, more power to you.
People hate java 'cause it's overly verbose, but complain that languages like perl look like line noise.
People hate OOP, but complain about organization of code.
People hate writing the same things over an dover again themselves, but java has APIs for lots of things, so you don't have to do so.
So php is being pushed into an OOP direction, not a clean implementation, the APIs are being provided, ugly as they may be, and things were never unverbose/cryptic... so what's the problem again?
Then my singleton would be just some static (java) method that just reads in a configuraiton object or writes it out. That's not the singleton pattern. Also, having a class that manages doing one thing with the object and prevents me from seeing the object as I should prevents me from doing dynamic things with it, like cloning, or writing it to other data sources. Singletons are good for two things. Globals and single ever existing things (Boolean.True.getInstance(), Boolean.False.getInstance()....)
Sure. A system I am working on allows for multiple people to log into it in tandem. It is convenient to have configuration files for each user. I *could* start a second JVM and let life happen with singletons. To save headaches, and simplicity, I have one class that servers as the kernel for this system and a configuration file object that works with that kernel class and classes it works with.
In short, now I can have two, three, four copies of my softare running, each with a different config file, each with a different config object.
Make sure there is some level of monoculture in your.. culture. You want everyone to be comfortable and to some degree, even a small one, interchangable. You want skill level to be similar, style to be similar, documentation to be similar. Heck, even the same for some things. Of course, there needs to be some level of difference to allow freedom, to allow people to be people and not cookie cutters.
Just use a configuration object. I would argue NOT to use a singleton. Come the day you need to migrate away from the singleton pattern, you will have a bit of work. Why migrate away? What if you wished to work with two configuration files at once? I know, it's not normal for all applications, but I've had an instance where one was the old config and one was the new. Short version, config object, no singleton.
Not to burst your bubble, but they already skew their results. When they bought the adwords thing from about.com, part of the deal was to push about's rankings higher.
Why not? If it's fast enough, and it works, it'd be good for java embeded applications and/or stuff that uses a database for scratch-work. It could also be used instead of complex data structures in memory that require massaging to get anything out of.
Hold on a sec. Why is such an intense library for javascript written IN javascript. This should be part of the browser. The same happens in perl... the underlying lib is written in c, but the interfaces are perl using XS.
A parser for plain xml is fairly easy as is the language. Why do you think HTML is so easy to pick up? XML is as easy, with minor tweaks to the rules.
As for the parser, since the rules are completely recursive, basic xml using a dtd is fairly easy. Schema requires a more intelligent parser. Using XLink and XPointer are more addons. Parsers for other languages, like perl, python and a few others are far more difficult.
Then what you need is something like XPath for selecting nodes in JS, not an entirely different language. If DOM really was the problem, then it wouldn't be just JS, since DOM is DOM in every language. It's a common interface.
Also, the JSON takes one line of code to parse and access natively in our defacto web browser language 'JavaScript'.
The second requires a bloated JavaScript XML parser (as this is not built in to many browsers) and CPU intensive processing and a cumbersome API to get the data out.
Give us a CPU speed, amount of memory available, amount of memory used, number of cycles used and code for each parser. I want to know the features of these parsers, and why they were chosen (SAX vs XML-Pull vs DOM). I'd like to be able to reproduce your "numbers" on my machine, and if I can, optimize the XML parser used, 'cause 100RPC calls a second vs 10ms round trip using different softwares isn't a fair test.
Otherwise, anyone (I) can say, "nuh uh" and be done with it.:)
XML is not faster than a byte position oriented language. What is being provided is not byte oritented. All data is not at a fixed position nor is it hinted by the data format. i.e. when a { is at spot 1, } can be expected at one or a few places distant from it. This language nor XML can do this. They both lose equaly in this department. TCP/IP is a perfect example of compromise for speed. The entire packet except for the data portion is more or less fixed. You know how many bytes you need to read to find things. In JSON AND XML, you can't.
How much more performance are you expecting using this over something like XML? If the packets are throw-away after you get the data, and you are stretching the limits, ala google, how MUCH are you saving and is it really worht it to diverge from something that is clearer, more of a standard, and easier to read/write.
This is a lot of junk except in exceptional cases.
We have machines that are now in the gigahertz. Even a 0.5 ghz machine can process XML with some speed.
We have machines that have tons of memory, so even an inefficient DOM parser which loves using memory, can handle a large XML packet (use sax for that).
We have parsers that are a bit smarter than the slow ones, namely XML-Pull parsers and SAX.
When implementing someone else's protocol, something that is readable is awesome, because documentation isn't always there. Using XSLT, you can also port one XML type to another.
We have land lines that can transmit compressed data easily at 11kb/s (based on a 56k modem).
All json provides, is a way to eek out a few less cycles, a little less memory depending on how you parse it, and a few less bytes per second over XML. It's less readable and it isn't as widely used. What problem are we solving again?
If a random community crops up and does it, I have nothing to say about that. We've all seen great things come out of OSS and the developers of them.
But for a company to randomly OSS their engine, that is least likely to happen. As for the OS, FS and graphical systems.. time/money are valuable to a company. Waiting around for an OSS group to deliver an engine instead of paying developers to do it is less likely going to happen. But if you pay developers, you probably aren't going to open what you produce, especially if it is your money maker.
Companies who open their software don't usually open their cash cow. Companies who have opened up, have either done so in a limited, less damaging way, or completely because they can't make any more money from the product. Look at Id. Didn't they open Doom or some other game? A fairly old game that isn't sold like their cash cows?
40 hours a week, 5 days a week, let's skip over time. What will these people do for money?
Let's assume you do pay them. What do you need, 5 people to develop it? You can't assume throwing a lot of people will make it go faster indefinitely; Read mythical man month if you do. 5 * what, $50k a year minimum, that's about $250k a year skipping office costs and what not.
Then they would give away the engine for free for anyone to develop games, including their competitor? A game company is more likely to keep the engine, tweak it during its lifetime, release new games based on the engine, license it out and more easily make back in what they spent.
Engines that do specific things are hard to build. Operating systems, file systems, graphical systems.. they take time and/or money. Apple comes close by co-developing darwin and osx. But even then, they had a jump start by using FreeBSD and Mach. General engines are even harder as you have more people to please.
Freeing the engines will probably not happen as the engines are complex and are licensed becuase they aren't easy to reproduce. Look at software like AbiWord and KOffice. They are fairly complex. Look at the time it took for them to mature.
Video games and office suites are not the same by any means, but it is the same reason you don't see 100 different full featured word processors or game engines. Unless enough is made to recoup the loss of many programmers time to make the engine in sales and what not.. it ain't gonna happen.
They stay as sperate products unless they pick up enough steam.
Java2D got integrated as anyone who uses swing will want it. I think jini is included, but i'm not sure. Java mail, i'm sure will be in a j2ee implementation soon enough.
Instead of flat out bloating the API by adding stuff, ala php, they incubate it out in the wild.
Slashdot Mirror
People hate Java because it's a language that was born of an advertising campaign and not a specific need in the technology field.
People hate Java because the technology has been caught in the middle of several commercial interests and platform wars, which has crippled the promise of Java's stability and reliability.
It's a language similar to cobol in purpose, w/o a lot of the features of cobol that make it harder to work with. One of the main purposes of java is to provide a more OOP like language, though it does fail in some resepects in comparisons to true OOP languages like python and ruby. It's very clear to read vs something like perl due to the simple language rules.
Over the years, the 10 or so years, the language has become quite stable and what not. Scalability is an issue due to the garbage collector, but just like any language, you learn not to do things in an odd/bad way, you can work with it well.
It's cross platform on the largely used platforms. Not as an excuse for sun. It's just so. It does suck. Uh.. the end
Don't go looking at the graphics aspect. It's an anomoly of slowness among the things it does fast. It's also slow in object creation. But it is fast on execution of code. Stuff like the HotSpot feature in JVM can optimize on the fly..
People hate Java because it sucks. I'm sorry to those of you who are Java programmers and are finding less jobs, but no sane company wants to use this technology when there are other systems available that offer better performance, reliability and longevity.
osCommerce has some ugly code if you are hunting.
Ruby all the way. Or perl. Or java.
People hate OOP, but complain about organization of code.
People hate writing the same things over an dover again themselves, but java has APIs for lots of things, so you don't have to do so.
So php is being pushed into an OOP direction, not a clean implementation, the APIs are being provided, ugly as they may be, and things were never unverbose/cryptic... so what's the problem again?
Then my singleton would be just some static (java) method that just reads in a configuraiton object or writes it out. That's not the singleton pattern. Also, having a class that manages doing one thing with the object and prevents me from seeing the object as I should prevents me from doing dynamic things with it, like cloning, or writing it to other data sources. Singletons are good for two things. Globals and single ever existing things (Boolean.True.getInstance(), Boolean.False.getInstance()....)
In short, now I can have two, three, four copies of my softare running, each with a different config file, each with a different config object.
Make sure there is some level of monoculture in your .. culture. You want everyone to be comfortable and to some degree, even a small one, interchangable. You want skill level to be similar, style to be similar, documentation to be similar. Heck, even the same for some things. Of course, there needs to be some level of difference to allow freedom, to allow people to be people and not cookie cutters.
Just use a configuration object. I would argue NOT to use a singleton. Come the day you need to migrate away from the singleton pattern, you will have a bit of work. Why migrate away? What if you wished to work with two configuration files at once? I know, it's not normal for all applications, but I've had an instance where one was the old config and one was the new. Short version, config object, no singleton.
-s
How often do you go behind your computer?
Not to burst your bubble, but they already skew their results. When they bought the adwords thing from about.com, part of the deal was to push about's rankings higher.
Why not? If it's fast enough, and it works, it'd be good for java embeded applications and/or stuff that uses a database for scratch-work. It could also be used instead of complex data structures in memory that require massaging to get anything out of.
Hold on a sec. Why is such an intense library for javascript written IN javascript. This should be part of the browser. The same happens in perl... the underlying lib is written in c, but the interfaces are perl using XS.
A parser for plain xml is fairly easy as is the language. Why do you think HTML is so easy to pick up? XML is as easy, with minor tweaks to the rules.
As for the parser, since the rules are completely recursive, basic xml using a dtd is fairly easy. Schema requires a more intelligent parser. Using XLink and XPointer are more addons. Parsers for other languages, like perl, python and a few others are far more difficult.
-s
Then what you need is something like XPath for selecting nodes in JS, not an entirely different language. If DOM really was the problem, then it wouldn't be just JS, since DOM is DOM in every language. It's a common interface.
Of course it has to be parsed. It's not automatically put into memory addresses via magic.
Next.
That's odd. I have a 500mhz machine that works with it just fine. Also claiming that it's that much faster is malarky.
Next.
Give us a CPU speed, amount of memory available, amount of memory used, number of cycles used and code for each parser. I want to know the features of these parsers, and why they were chosen (SAX vs XML-Pull vs DOM). I'd like to be able to reproduce your "numbers" on my machine, and if I can, optimize the XML parser used, 'cause 100RPC calls a second vs 10ms round trip using different softwares isn't a fair test.
Otherwise, anyone (I) can say, "nuh uh" and be done with it.
XML is not faster than a byte position oriented language. What is being provided is not byte oritented. All data is not at a fixed position nor is it hinted by the data format. i.e. when a { is at spot 1, } can be expected at one or a few places distant from it. This language nor XML can do this. They both lose equaly in this department. TCP/IP is a perfect example of compromise for speed. The entire packet except for the data portion is more or less fixed. You know how many bytes you need to read to find things. In JSON AND XML, you can't.
How much more performance are you expecting using this over something like XML? If the packets are throw-away after you get the data, and you are stretching the limits, ala google, how MUCH are you saving and is it really worht it to diverge from something that is clearer, more of a standard, and easier to read/write.
We have machines that are now in the gigahertz. Even a 0.5 ghz machine can process XML with some speed.
We have machines that have tons of memory, so even an inefficient DOM parser which loves using memory, can handle a large XML packet (use sax for that).
We have parsers that are a bit smarter than the slow ones, namely XML-Pull parsers and SAX.
When implementing someone else's protocol, something that is readable is awesome, because documentation isn't always there. Using XSLT, you can also port one XML type to another.
We have land lines that can transmit compressed data easily at 11kb/s (based on a 56k modem).
All json provides, is a way to eek out a few less cycles, a little less memory depending on how you parse it, and a few less bytes per second over XML. It's less readable and it isn't as widely used. What problem are we solving again?
When something needs maintenance or what have you, this is INVALUABLE. If you use a cryptic protocol from the getgo, we go into a state of screwed.
I don't believe it does. If it did, then you could DoS the cache by spamming random crap at it..
Most people do the middle of the road stuff. PhD's go a step further. MSs are on the way there.
If a random community crops up and does it, I have nothing to say about that. We've all seen great things come out of OSS and the developers of them.
But for a company to randomly OSS their engine, that is least likely to happen. As for the OS, FS and graphical systems.. time/money are valuable to a company. Waiting around for an OSS group to deliver an engine instead of paying developers to do it is less likely going to happen. But if you pay developers, you probably aren't going to open what you produce, especially if it is your money maker.
Companies who open their software don't usually open their cash cow. Companies who have opened up, have either done so in a limited, less damaging way, or completely because they can't make any more money from the product. Look at Id. Didn't they open Doom or some other game? A fairly old game that isn't sold like their cash cows?
Let's assume you do pay them. What do you need, 5 people to develop it? You can't assume throwing a lot of people will make it go faster indefinitely; Read mythical man month if you do. 5 * what, $50k a year minimum, that's about $250k a year skipping office costs and what not.
Then they would give away the engine for free for anyone to develop games, including their competitor? A game company is more likely to keep the engine, tweak it during its lifetime, release new games based on the engine, license it out and more easily make back in what they spent.
Engines that do specific things are hard to build. Operating systems, file systems, graphical systems.. they take time and/or money. Apple comes close by co-developing darwin and osx. But even then, they had a jump start by using FreeBSD and Mach. General engines are even harder as you have more people to please.
Video games and office suites are not the same by any means, but it is the same reason you don't see 100 different full featured word processors or game engines. Unless enough is made to recoup the loss of many programmers time to make the engine in sales and what not.. it ain't gonna happen.
Java2D got integrated as anyone who uses swing will want it. I think jini is included, but i'm not sure. Java mail, i'm sure will be in a j2ee implementation soon enough.
Instead of flat out bloating the API by adding stuff, ala php, they incubate it out in the wild.