Java is dying. This does not mean that fewer people are using it - the decline will be long, just as it was for COBOL. But it IS past it's peak, simply because it's so bloated that, like the dinosaurs, it can't maneuver as quickly. It's no longer the "cool kid on the block." It's become boring.
It doesn't help that both Sun and Oracle hindered the development of more flexible alternative. Java could have been MUCH better.
Just adding multiple inheritance would have avoided a lot of the current bloat. And not restricting it to "everything is a class", but rather "classes if necessary, but not necessarily classes", would have taken away 90% of the beefs I have with it.
Why do people feel that these two things are such a threat? Or such a "bad thing"? We criticize c++ devs who go class-crazy.. (been there, done that, learned my lesson:-). And multiple inheritance - everyone can use a friend (class) or two.
It's not like I'm asking for operator overloading (though Java DOES overload the "+" operator, so it can be done).
And enums would be nice (though I obtain the same effect by using the c pre-processor when I do write java code, just like I get back my #include and #define - maybe I should write a custom pre-processor that would give me everything I want, fork the java library, and call it good. After all, as long as it's not java, what can Oracle say?:-).
The JIT still has to do a lookup into it's own opcode cache each time. It's not magic pixie dust.
Frequently-accessed code is optimized. That optimized code is saved - otherwise it would have to be re-interpreted. Where do you think it saves it - in Neverland? You might not call it a cache - yuo may prefer the term lookup table, or whatever. A smarter way to do it would be to replace the un-optimized code directly, but that would lead to problems with size when the optimized version doesn't fit in the same space. It's called caching. It's (part of) what JITs do.
JIT compilers represent a hybrid approach, with translation occurring continuously, as with interpreters, but with caching of translated code to minimize performance degradation. It also offers other advantages over statically compiled code at development time, such as handling of late-bound data types and the ability to enforce security guarantees.
I don't consider them BSD because they AREN'T bsd. Neither is OSX.
XNU is the computer operating system kernel that Apple Inc. acquired and developed for use in the Mac OS X operating system and released as free and open source software as part of the Darwin operating system. XNU is an acronym for X is Not Unix.[1]
BSD
The Berkeley Software Distribution (BSD) portion of the kernel provides the POSIX API (BSD system calls), the Unix process model atop Mach tasks, basic security policies, user and group ids, permissions, the network stack, the virtual file system code (including a filesystem independent journalling layer), several local file systems such as HFS/HFS+, the Network File System (NFS) client and server, cryptographic framework, UNIX System V inter-process communication (IPC), Audit subsystem, mandatory access control, and some of the locking primitives. The BSD code present in XNU came from the FreeBSD kernel. Although much of it has been significantly modified, code sharing still occurs between Apple and the FreeBSD Project
Code sharing also goes on between BSD and linux - is linux BSD? Windows has some BSD code. Is Windows BSD? If you're running cygwin to get all the linux stuff on Windows, does Windows then become linux?
Neither OSX nor the iStuff OS are BSD. Different kernels.
No, what I said is that you have to have a large enough heat source to not only heat a sufficient quantity up, but maintain the temperature for long enough for it to actually burn. Think of laser pulses used for hair removal. They certainly are intense, but because they're of such short duration, you couldn't set anything on fire if you wanted to. Tar is hard to start burning - the usual way in industrial accidents is with an oxy-acetylene torch. But you can safely play that torch over the surface and the tar won't catch. You need to keep it there for a few seconds.
Solids don't burn. Liquids don't burn. You need to have sufficient heat to volatize enough to not only burn, but be self-sustaining (think of trying to light a birthday candle - even when lit, some of them go out and you have to do it again). So unless your heat source is large enough, long enough duration, and hot enough, you won't burn anything - it'll just liquify and flow away - carrying the heat with it and stopping any possibility of a fire.
Don't bother with RAID5 if you want a speed-up - partition your data among different drives instead. You'll avoid all the overhead of raid5, and you'll benefit from having more usable cache on each drive, and being able to do a read on one and a write on the other at the same time.
I have the latest and greatest c2j, so I "compiled" some of my java code.
I put "compiled" in quotes because a quick look with a hex editor into the resulting a.out shows that it is not "compiled native binary code" - it's a list of my classes, along with the java code that the runtime will further interpret - which the "compiled" code calls when you run it. So you not only don't have a stand-alone binary - you only have a wrapper around the gcj equivalent of java.class files. Same as when, back in the old days, we'd "compile" dbase programs by merging the dbase runtime with our.dbo files. The runtime still interprets them. Changing to Clipper made a huge difference in speed.
Now, back to compatibility - it's STILL garbage. My stupid demo program, which works perfectly when I run the class files, generates LOTS of errors with the c2j version. LOTS. It's garbage, and it's not even "compiled" garbage.
So the next step is to see just how big it would get with static linking.
gcj doesn't like that - it tells me "gcj: Java programs cannot be linked statically". I kind of expected as much, since it's not REALLY putting out native code.
Nice try. A real compiler would have first translated the classes into a series of native function calls, not just served as a wrapper to the java class files. There would have been NO trace of, and no need for, my original class files in a true compiled program. And you'd have the option of statically linking any libs used.
Bottom line: Your buggy "compiled" program is for the birds. It doesn't work! And even if it did, it doesn't really do what you claim it does - it does not produce native binaries. It calls an external library which interprets the code embedded in the file, same as the JVM does.
So, can we stop with the "gcj compiles java programs!" BS?
It's not "oil" - its more like tar. It's only self-sustaining under certain conditions - like you need to be able to enclose it with a chimney-like chamber so that the heat of combustion isn't dissipated too quickly, but heats up the rest of the lump. Otherwise you get very incomplete combustion, your mat turns into a lump of asphalt-like glop, and you need to incinerate it to get the tar out. Look at how the ships that burn it off are set up.
My point was that three are only 3 main BSD distros after all these years, and the near-universal favorite is FreeBSD. We don't see anywhere near that level of consolidation in linux. No linux distro has the majority of the market, unlike FreeBSD.
Let me guess - you're in the southern US or a similar warm climate, where they only sell #1 diesel. #2 diesel (also sold as home heating oil - its the same thing, which is why they add dye to diesel sold at the pumps) will put out the match every time. Crude oil is a LOT harder to light. You need a blowtorch. A spark just won't do it. It's like trying to set a cold lump of tar on fire with a spark.
Try queuing your database calls. Collect 20, 50, 100, 1000, then issue them all as one huge statement, grab and parse out the individual resultsets. By doing this with mysql (using the c api), I found that it wasn't disk access, but setting up individual connections to the database, that was the bottleneck. You'll see a performance gain of at least 20 to 1 (the optimum was between 10,000 and 20,000 requests pooled into one, but you may not have enough data coming in each second to do this large a number of requests. Does it sound insane? Yes. But it works. We could get away with it because every incoming request on one port generated the need for ~150 database hits, so 15,000 db hits was only 100 requests/sec). PostgreSQL should have the same functionality. Just keep in mind that you do have a limit to the size of the data you send in a request.
You won't be able to do this with a conventional server - you need to have your own server intercept the incoming requests, pool them, generate the one big db hit, strip off the individual results and send them back. In other words, you'll need to write your own threaded server - but if you do, you'll see that the query optimizer can do wonders with large queries (things like reading multiple records that are on the same physical page, etc.) and that there's a LOT of overhead associated with making each request on its own.
In my day to day, methodX is often written by one of my coworkers a hour before I need to use it
Sounds like a formula for generating LOTS of bug fix work, unless they write perfect code the first time out every time. but hey, it it keeps you employed:-)
Of course, if the code is just mostly cut-n-paste with a variable name changed, you have a bigger problem on your hands. But that will also guarantee future employment managing all those lines of code.
Or maybe you simplified it, and they really did test it properly, knew how you were going to use it, etc. This is not to say that IDEs are bad in and of themselves, but that they do tend to get people to think less about the "why" of the code they write, and more about just cranking out lines.
Sure you can. NoSQL can be fully ACID-compliant - map-reduce is just the way to spread it across a whole herd of machines simultaneously. RDBMS are great, but ACID is a function of both the underlying implementation (OS, hardware, etc) and the skill of the people using it.
There's no reason you *can't* use an rdbms as part of the back end, but you have to look beyond the partitioning offered at the rdbms level. For example, by distributing your data across many machines, and using a mechanism to know which data lives on which machine (for example, the last 4 bytes of the 64-bit hash of the customer account gives the host machine id), you can now make sure that your data is not only partitioned fairly efficiently, but also limit your queries to only one particular host.
Similarly, if you need an extra speed boost, use raw partitions instead of running an rdbms atop the file system.
Any query can be made to be played back multiple times without data corruption, but it depends on the person writing it not to be brain-dead, same as any other system. Doing a "update customer set balance=balance-$10 where customer_id=foo9999" is not safely repeatable, but using this as an example of how systems corrupt data is silly. Doing a "set balance=balance-$10 where customer_id=foo9999 and hash(balance)='b7dd0fd9338947dc6de445e0deadbeef'" can be executed 1000 times. Obviously, you wouldn't do an update - you'd do an append (you want a history of all transactions) but the concept remains the same.
This doesn't need an rdbms or even sql to implement. After all, you have access to the same locking mechanisms as any rdbms - they don't have "magic pixie dust" in their code. Make almost every operation an append and most of your problems become much easier, because the real issue is updates to row. If an update that is just an append to 10 different tables fails, you can roll it back by just appending reversing records to those tables where the update succeeded. If instead you want to repeat the transaction, just play it again - those that already have the appended record won't append a second one (in the above example, the hash for the balance won't match in that particular table, so the replay is safely ignored). This works with rdbms, and it works with nosql.
There's nothing magic about this - these problems were first solved before the rdbms ever existed. The problems of dirty reads, etc., are all implementation details that apply to all solutions.
You could pick a better metric, like hosting costs paid or requests processed, and Java would come out way significantly ahead of PHP
Dream on.
php serves up more page views than java. You might want to try again.
Facebook srve up 1% of all internet traffic, and they use a customized version of php. youtube? No java. Google? Don't make me laugh. Yahoo? Yahoo converted to php years ago.
The fact is that php does scale at least as well as java, and requires less hardware to do it. You just have to know what you're doing.
Also, your argument is the one that is disingenuous. It is not machine code. Even the picojava chip can't execute it directly. It's an intermediate representation of the program. But keep telling yourself that java is the be-all and end-all. It's not. It *could* have been, but between the mistakes in the original design, and Sun's refusal to allow people to ship variants that could have addressed some of those problems, it's not.
This is more a testament to why Sun eventually went bye-bye than it is a criticism of Java per se. The reason that c has so much staying power is two-fold - the committee in charge makes sure that it stays as simple as possible, and anyone is free to add to it.
So no such stupidity as "everything is a class." Anyone using c++ learned that is a mistake within a few months - a lesson I learned the hard way back in 1991. Classes when necessary, but not necessarily classes, because theory and practice are not the same.
The other mistakes were the single-inheritance model (really dumb move there - all single-inheritance models end up with either duplicate code or weird work-arounds - or both), and the lack of a pre-processor.
The idea was good. The implementation is flawed. If they had addressed these issues, instead of bolting on more and more garbage to patch over their earlier mistakes, it would be a different story. This was an opportunity lost. Someone else will eventually come up with a better alternative.
And which part of "It isn't that easy to burn" don't yu get?
Why isn't the gulf a sea of flames? Because you can't just toss a match on crude and expect it to burn - you need enough heat to vaporize a portion of the oil - your 100 watt PV array isn't going to give you enough energy to start a fire - all that will happen is that you'll liquify a small (very small) portion, which will then flow away, conducting the heat with it.
Try this - take a puddle of diesel fuel (a LOT easier to burn than crude) and throw a match on it. It'll put out the match.
Waterlogged? Did you miss the part about the breakthrough material that absorbs oil but not water? Also igniting oil doesn't require power, just a spark.
Did you miss all those videos of the red oil foam? As well as the fact that there's still going to be mechanical mixing of the two?
Also, you can't even light refined diesel fuel with a spark. Make a puddle of diesel on the ground and throw a lit match on it. The match will go out. Room-temperature crude is a lot harder to burn than refined diesel.
No. The original poster said that the gpl forced him to "Hand over the source, plus your patches, to whatever programs you are distributing. That, or lose your inventory in default judgment, a la Westinghouse Digital."
The gpl doesn't force anyone to do that. You're free not to use gpl'd code. The gpl is not some mobster at gunpoint saying "you have to use the gpl and you have to abide by these terms. Or else!" There's no forcing anyone to use gpl code.
Now if gpl code use was mandatory, he would have had a point. But since nobody's forcing him to use gpl'd code, nobody's forcing him to do any of the other stuff.
Yes, the gpl is restrictive. Yes, the gpl is viral to a certain extent. So what. You can always non-gpl code, or write your own, or pay someone to write the code for you. Nobody is "forced."
Sun signed licensing deals with other manufacturers to produce "java chips" to run picoJava, not Java. picoJava doesn't pass Sun's own Java conformance tests. Nice try, though. I'll give you 1 point for the attempt, and take away 2 for being wrong with the facts.
No, it's 33 barrels a day to arrive at the 5,000 robots can clean up 5,000,000 barrels in one month. Do the math. It's not hard - unless you're an MIT "scientist".
Otherwise, each robot would have to collect 1,000 barrels at one time. That would represent a layer 45 feet high on their 16'x7' fabric. Do you really believe that a 1/8 hp electric motor could tow that much?
The GPL doesn't force you to do anything. You're entirely free to not use the code. If you use it, that is your choice, freely made (nobody's going to believe the Underpants Gnomes team up with the GNAA to install firefox on your pc).
As with any software, you're free to either (1) use the code, or (2) not use the code.
If you pick (1), abide by the licensing terms to the extent required by law.
If you pick (2), you need no longer abide by the license.
Note that if you pick (2), you still have to abide by copyright, etc., so I'm *not* saying that not using the code gives you an unlimited license to copy and redistribute in the case of proprietary code (only being pedantic in making the distinction because someone else will be a nazi:-)
include games in the maps served up - games are big. You can then sell them swords and nukes when they are looking at their neighbors cat
offer people an "unlisted address" option - "we'll remove your section of the street if you pay us $5 a month. Works for the phone co "pay more, get less service"
road sponsorship - it works for highway trash cleanup "this section of road is loving memory of Snuffles the Dog"
bring out their own version of MonopolyCityStreets
"Risk, the neighborhood edition"
Really, either hire some coders to produce a game, or come to some sort of partnership/sponsorship agreement for developing a game, where they promote the game (say, on every 100th map served) and handle sales.
1- You seem to think less qualified people can easily update and extend code that would have been too hard for them to think up in the first place. I'm doubtful.
When someone else has done the hard work, it makes it easier for everyone else who follows to extend it, esp. if they use good variable names, etc. There's a lot less work, for example, in adding one more parameter to a thread structure than in writing the original thread-handling code.
3- I'm not sure re-use rate for code people don't feel confident they can understand, edit, maintain, is going to be much better than for so-so code they feel more confident with ?
Then maybe either someone else should be looking at the code (not all coders are equal), or better yet, managers should acknowledge that people shouldn't just be expected to quickly modify code with stuff that "looks right, hopefully it won't blow up in a month". Of the two, I'd say the latter is the best solution, the one that programmers would prefer, but also the less likely of the two. We both know why...
4- Ten years ago, there were much fewer programmers, working on much fewer programs with much smaller feature sets on much fewer platforms. It's like saying 50 years ago, airplane pilots knew how to care for and fix their airplanes, not just fly them, and with much assistance. Yes, things have moved ahead since then. Your point is ?
Operating systems were a lot simpler 10 years ago as well. You don't see them shifting to "managed code" for their cores. The performance just isn't there. Even the JVM is written in c, and the Java spec has gotten a LOT bigger.
If the developers of Java had admitted early on that their approach was off on a few things (no macro pre-processor, no first-class functions, no pointer math, single class inheritance, the option to allow the coder to manage memory, everythingIsAClassItis) we wouldn't be having this discussion. It *could* have even been a "better c++". It would have been relatively easy to offer both an interpreted and an emit native binary code option. It would even have been easier to link java object code with c++ code.
Chalk it up to another missed opportunity. The industry is full of them. Much as I've tried countless times over the years to like Java, for me it just combines the worst of all worlds.
Ahh, shifting the goalposts when you're wrong... truly the mark of a sophisticated mind.
The AWT was part of the original , very first, public Java release - then called Oak - back in January of 1996. 14 years later, the gcj faq states that gcj still doesn't support the AWT. In other words, gcj doesn't support ANY version of Java. The only "moving of goalposts" is by you. No AWT support means it's not Java, same as if I write a compiler that can only process printf statements, I can't call it a c compiler.
Lying about it when you're caught at being wrong - truly the mark of a Java-damaged mind. You should run your garbage-collector.
Java has its place, but it's not a silver bullet - in fact, it's quite the opposite. It has led to a lost decade in terms of programmers with robust skillsets.
They (MIT) state in their video a spill of 5,000,000 barrels. I'm using MIT's own figures. So no, the only bad math is theirs, not mine. Just like they think that it would be easy to heat the collected crude to the point of combustion. It's not, and they only have 100 watts (300 btu) to play with. You can't even light up a puddle of refined #2 diesel by throwing a lit match on it. How much worse a waterlogged mat? All you'll do is liquify a small area, which will then flow, and dissipate the heat.
If it would burn on its own, there wouldn't have been a problem - the entire gulf would have burned off instead of spreading in a widening slick.
Slashdot Mirror
Java is dying. This does not mean that fewer people are using it - the decline will be long, just as it was for COBOL. But it IS past it's peak, simply because it's so bloated that, like the dinosaurs, it can't maneuver as quickly. It's no longer the "cool kid on the block." It's become boring.
It doesn't help that both Sun and Oracle hindered the development of more flexible alternative. Java could have been MUCH better.
Just adding multiple inheritance would have avoided a lot of the current bloat. And not restricting it to "everything is a class", but rather "classes if necessary, but not necessarily classes", would have taken away 90% of the beefs I have with it.
Why do people feel that these two things are such a threat? Or such a "bad thing"? We criticize c++ devs who go class-crazy .. (been there, done that, learned my lesson :-). And multiple inheritance - everyone can use a friend (class) or two.
It's not like I'm asking for operator overloading (though Java DOES overload the "+" operator, so it can be done).
And enums would be nice (though I obtain the same effect by using the c pre-processor when I do write java code, just like I get back my #include and #define - maybe I should write a custom pre-processor that would give me everything I want, fork the java library, and call it good. After all, as long as it's not java, what can Oracle say? :-).
Frequently-accessed code is optimized. That optimized code is saved - otherwise it would have to be re-interpreted. Where do you think it saves it - in Neverland? You might not call it a cache - yuo may prefer the term lookup table, or whatever. A smarter way to do it would be to replace the un-optimized code directly, but that would lead to problems with size when the optimized version doesn't fit in the same space. It's called caching. It's (part of) what JITs do.
Want to try it without a cache?
I don't consider them BSD because they AREN'T bsd. Neither is OSX.
Code sharing also goes on between BSD and linux - is linux BSD? Windows has some BSD code. Is Windows BSD? If you're running cygwin to get all the linux stuff on Windows, does Windows then become linux?
Neither OSX nor the iStuff OS are BSD. Different kernels.
No, what I said is that you have to have a large enough heat source to not only heat a sufficient quantity up, but maintain the temperature for long enough for it to actually burn. Think of laser pulses used for hair removal. They certainly are intense, but because they're of such short duration, you couldn't set anything on fire if you wanted to. Tar is hard to start burning - the usual way in industrial accidents is with an oxy-acetylene torch. But you can safely play that torch over the surface and the tar won't catch. You need to keep it there for a few seconds.
Solids don't burn. Liquids don't burn. You need to have sufficient heat to volatize enough to not only burn, but be self-sustaining (think of trying to light a birthday candle - even when lit, some of them go out and you have to do it again). So unless your heat source is large enough, long enough duration, and hot enough, you won't burn anything - it'll just liquify and flow away - carrying the heat with it and stopping any possibility of a fire.
Don't bother with RAID5 if you want a speed-up - partition your data among different drives instead. You'll avoid all the overhead of raid5, and you'll benefit from having more usable cache on each drive, and being able to do a read on one and a write on the other at the same time.
I have the latest and greatest c2j, so I "compiled" some of my java code.
I put "compiled" in quotes because a quick look with a hex editor into the resulting a.out shows that it is not "compiled native binary code" - it's a list of my classes, along with the java code that the runtime will further interpret - which the "compiled" code calls when you run it. So you not only don't have a stand-alone binary - you only have a wrapper around the gcj equivalent of java.class files. Same as when, back in the old days, we'd "compile" dbase programs by merging the dbase runtime with our .dbo files. The runtime still interprets them. Changing to Clipper made a huge difference in speed.
Now, back to compatibility - it's STILL garbage. My stupid demo program, which works perfectly when I run the class files, generates LOTS of errors with the c2j version. LOTS. It's garbage, and it's not even "compiled" garbage.
So the next step is to see just how big it would get with static linking.
gcj doesn't like that - it tells me "gcj: Java programs cannot be linked statically". I kind of expected as much, since it's not REALLY putting out native code.
Nice try. A real compiler would have first translated the classes into a series of native function calls, not just served as a wrapper to the java class files. There would have been NO trace of, and no need for, my original class files in a true compiled program. And you'd have the option of statically linking any libs used.
Bottom line: Your buggy "compiled" program is for the birds. It doesn't work! And even if it did, it doesn't really do what you claim it does - it does not produce native binaries. It calls an external library which interprets the code embedded in the file, same as the JVM does.
So, can we stop with the "gcj compiles java programs!" BS?
Not "the surface".
The video also makes the claim - that 5,000 could clean up a 5,000,000 barrel spill in one month. Not "the surface" of a 5,000,000 barrel spill.
Stop getting your information from other mis-informed comments - read the mis-informed MIT article instead :-p
It's not "oil" - its more like tar. It's only self-sustaining under certain conditions - like you need to be able to enclose it with a chimney-like chamber so that the heat of combustion isn't dissipated too quickly, but heats up the rest of the lump. Otherwise you get very incomplete combustion, your mat turns into a lump of asphalt-like glop, and you need to incinerate it to get the tar out. Look at how the ships that burn it off are set up.
My point was that three are only 3 main BSD distros after all these years, and the near-universal favorite is FreeBSD. We don't see anywhere near that level of consolidation in linux. No linux distro has the majority of the market, unlike FreeBSD.
Let me guess - you're in the southern US or a similar warm climate, where they only sell #1 diesel. #2 diesel (also sold as home heating oil - its the same thing, which is why they add dye to diesel sold at the pumps) will put out the match every time. Crude oil is a LOT harder to light. You need a blowtorch. A spark just won't do it. It's like trying to set a cold lump of tar on fire with a spark.
You won't be able to do this with a conventional server - you need to have your own server intercept the incoming requests, pool them, generate the one big db hit, strip off the individual results and send them back. In other words, you'll need to write your own threaded server - but if you do, you'll see that the query optimizer can do wonders with large queries (things like reading multiple records that are on the same physical page, etc.) and that there's a LOT of overhead associated with making each request on its own.
Sounds like a formula for generating LOTS of bug fix work, unless they write perfect code the first time out every time. but hey, it it keeps you employed :-)
Of course, if the code is just mostly cut-n-paste with a variable name changed, you have a bigger problem on your hands. But that will also guarantee future employment managing all those lines of code.
Or maybe you simplified it, and they really did test it properly, knew how you were going to use it, etc. This is not to say that IDEs are bad in and of themselves, but that they do tend to get people to think less about the "why" of the code they write, and more about just cranking out lines.
There's no reason you *can't* use an rdbms as part of the back end, but you have to look beyond the partitioning offered at the rdbms level. For example, by distributing your data across many machines, and using a mechanism to know which data lives on which machine (for example, the last 4 bytes of the 64-bit hash of the customer account gives the host machine id), you can now make sure that your data is not only partitioned fairly efficiently, but also limit your queries to only one particular host.
Similarly, if you need an extra speed boost, use raw partitions instead of running an rdbms atop the file system.
Any query can be made to be played back multiple times without data corruption, but it depends on the person writing it not to be brain-dead, same as any other system. Doing a "update customer set balance=balance-$10 where customer_id=foo9999" is not safely repeatable, but using this as an example of how systems corrupt data is silly. Doing a "set balance=balance-$10 where customer_id=foo9999 and hash(balance)='b7dd0fd9338947dc6de445e0deadbeef'" can be executed 1000 times. Obviously, you wouldn't do an update - you'd do an append (you want a history of all transactions) but the concept remains the same.
This doesn't need an rdbms or even sql to implement. After all, you have access to the same locking mechanisms as any rdbms - they don't have "magic pixie dust" in their code. Make almost every operation an append and most of your problems become much easier, because the real issue is updates to row. If an update that is just an append to 10 different tables fails, you can roll it back by just appending reversing records to those tables where the update succeeded. If instead you want to repeat the transaction, just play it again - those that already have the appended record won't append a second one (in the above example, the hash for the balance won't match in that particular table, so the replay is safely ignored). This works with rdbms, and it works with nosql.
There's nothing magic about this - these problems were first solved before the rdbms ever existed. The problems of dirty reads, etc., are all implementation details that apply to all solutions.
Dream on. php serves up more page views than java. You might want to try again.
Facebook srve up 1% of all internet traffic, and they use a customized version of php. youtube? No java. Google? Don't make me laugh. Yahoo? Yahoo converted to php years ago.
The fact is that php does scale at least as well as java, and requires less hardware to do it. You just have to know what you're doing.
Also, your argument is the one that is disingenuous. It is not machine code. Even the picojava chip can't execute it directly. It's an intermediate representation of the program. But keep telling yourself that java is the be-all and end-all. It's not. It *could* have been, but between the mistakes in the original design, and Sun's refusal to allow people to ship variants that could have addressed some of those problems, it's not.
This is more a testament to why Sun eventually went bye-bye than it is a criticism of Java per se. The reason that c has so much staying power is two-fold - the committee in charge makes sure that it stays as simple as possible, and anyone is free to add to it. So no such stupidity as "everything is a class." Anyone using c++ learned that is a mistake within a few months - a lesson I learned the hard way back in 1991. Classes when necessary, but not necessarily classes, because theory and practice are not the same.
The other mistakes were the single-inheritance model (really dumb move there - all single-inheritance models end up with either duplicate code or weird work-arounds - or both), and the lack of a pre-processor.
The idea was good. The implementation is flawed. If they had addressed these issues, instead of bolting on more and more garbage to patch over their earlier mistakes, it would be a different story. This was an opportunity lost. Someone else will eventually come up with a better alternative.
Why isn't the gulf a sea of flames? Because you can't just toss a match on crude and expect it to burn - you need enough heat to vaporize a portion of the oil - your 100 watt PV array isn't going to give you enough energy to start a fire - all that will happen is that you'll liquify a small (very small) portion, which will then flow away, conducting the heat with it.
Try this - take a puddle of diesel fuel (a LOT easier to burn than crude) and throw a match on it. It'll put out the match.
Crude is a LOT harder to burn than diesel.
So this idea is dumb.
Did you miss all those videos of the red oil foam? As well as the fact that there's still going to be mechanical mixing of the two?
Also, you can't even light refined diesel fuel with a spark. Make a puddle of diesel on the ground and throw a lit match on it. The match will go out. Room-temperature crude is a lot harder to burn than refined diesel.
No. The original poster said that the gpl forced him to "Hand over the source, plus your patches, to whatever programs you are distributing. That, or lose your inventory in default judgment, a la Westinghouse Digital."
The gpl doesn't force anyone to do that. You're free not to use gpl'd code. The gpl is not some mobster at gunpoint saying "you have to use the gpl and you have to abide by these terms. Or else!" There's no forcing anyone to use gpl code.
Now if gpl code use was mandatory, he would have had a point. But since nobody's forcing him to use gpl'd code, nobody's forcing him to do any of the other stuff.
Yes, the gpl is restrictive. Yes, the gpl is viral to a certain extent. So what. You can always non-gpl code, or write your own, or pay someone to write the code for you. Nobody is "forced."
No, they didn't.
Sun signed licensing deals with other manufacturers to produce "java chips" to run picoJava, not Java. picoJava doesn't pass Sun's own Java conformance tests. Nice try, though. I'll give you 1 point for the attempt, and take away 2 for being wrong with the facts.
No, it's 33 barrels a day to arrive at the 5,000 robots can clean up 5,000,000 barrels in one month. Do the math. It's not hard - unless you're an MIT "scientist".
Otherwise, each robot would have to collect 1,000 barrels at one time. That would represent a layer 45 feet high on their 16'x7' fabric. Do you really believe that a 1/8 hp electric motor could tow that much?
Their math sucks. Their thinking does too,
And yet ond BSD disto, FreeBSD, has 5 of the top 10 places on Netcraft including the Top 4.
The 4 linux distros in the top 10 are much more fragmented. CentOS, Fedora, a couple that aren't so easily identified ...
When I think BSD, I think of only 3 - FreeBSD, OpenBSD, and NetBSD. When I think linux, on the other hand ...
The GPL doesn't force you to do anything. You're entirely free to not use the code. If you use it, that is your choice, freely made (nobody's going to believe the Underpants Gnomes team up with the GNAA to install firefox on your pc).
As with any software, you're free to either (1) use the code, or (2) not use the code.
If you pick (1), abide by the licensing terms to the extent required by law.
If you pick (2), you need no longer abide by the license.
Note that if you pick (2), you still have to abide by copyright, etc., so I'm *not* saying that not using the code gives you an unlimited license to copy and redistribute in the case of proprietary code (only being pedantic in making the distinction because someone else will be a nazi :-)
Really, either hire some coders to produce a game, or come to some sort of partnership/sponsorship agreement for developing a game, where they promote the game (say, on every 100th map served) and handle sales.
When someone else has done the hard work, it makes it easier for everyone else who follows to extend it, esp. if they use good variable names, etc. There's a lot less work, for example, in adding one more parameter to a thread structure than in writing the original thread-handling code.
Then maybe either someone else should be looking at the code (not all coders are equal), or better yet, managers should acknowledge that people shouldn't just be expected to quickly modify code with stuff that "looks right, hopefully it won't blow up in a month". Of the two, I'd say the latter is the best solution, the one that programmers would prefer, but also the less likely of the two. We both know why ...
Operating systems were a lot simpler 10 years ago as well. You don't see them shifting to "managed code" for their cores. The performance just isn't there. Even the JVM is written in c, and the Java spec has gotten a LOT bigger.
If the developers of Java had admitted early on that their approach was off on a few things (no macro pre-processor, no first-class functions, no pointer math, single class inheritance, the option to allow the coder to manage memory, everythingIsAClassItis) we wouldn't be having this discussion. It *could* have even been a "better c++". It would have been relatively easy to offer both an interpreted and an emit native binary code option. It would even have been easier to link java object code with c++ code.
Chalk it up to another missed opportunity. The industry is full of them. Much as I've tried countless times over the years to like Java, for me it just combines the worst of all worlds.
The AWT was part of the original , very first, public Java release - then called Oak - back in January of 1996. 14 years later, the gcj faq states that gcj still doesn't support the AWT. In other words, gcj doesn't support ANY version of Java. The only "moving of goalposts" is by you. No AWT support means it's not Java, same as if I write a compiler that can only process printf statements, I can't call it a c compiler.
Lying about it when you're caught at being wrong - truly the mark of a Java-damaged mind. You should run your garbage-collector.
Java has its place, but it's not a silver bullet - in fact, it's quite the opposite. It has led to a lost decade in terms of programmers with robust skillsets.
If it would burn on its own, there wouldn't have been a problem - the entire gulf would have burned off instead of spreading in a widening slick.