You are comparing a 1U rack optimized server(Sun) to a desktop case(Dell). If takes a lot more engineering(and money) to make a powerful server in a 1U form factor.
The exact same 1 CPU Dell configuration as a rack mounted server (yes, the PE1750)... $1,698
Still cheaper than Sun's crap, or? In fact, even cheaper than the desktop configuration.
If you had a reading comprehension above that of a 5 year old you might have been clued into the fact that they are comparing their servers to the Dell poweredge servers. Dell's 1750 server is cheaper than the Sun 60x, but the Sun65x is just several hundred off. I would bet that after corporate discounts the price diff would neg. and if Sun's servers perform better...). I can't stand Slashdot idiots making invalid comparisons.
Ah, a jolly good flame war. Count me in.
So lemme see. You can't even notice that the PE 1750 is even cheaper, and spew stuff like "If takes a lot more engineering(and money) to make a powerful server in a 1U form factor." Well, gee, Dell's price list says the exact opposite.
Or let's talk basic comprehension of numbers and economics. "is just several hundreds off". Well, guess what? The V60x is exactly $752 more expensive, or a whole 44.3% more expensive than the Dell. (752 * 100 / 1698, for the maths impaired.)
The v65x is even more expensive. It's $2,550 for the smallest config. So $852, or 50.2% more expensive than the Dell.
So you're advocating... what? Paying 50% extra for the _exact_ same machine, just to have Sun's logo on it? Lemming.
As for "if Sun's servers perform better...", that's a huge "if". I'd really like to see some benchmarks first. No, seriously. They're can use exactly the same CPU, motherboard and memory as any other Intel server manufacturer can use. So if you want me to believe that just a bit of marketing hocus pocus will make it run faster, you better show some numbers that prove that.
Actually, most of us don't think Sun is evil. Just that their whole product line is obsolete, underperforming, overpriced, and lacking any coherent strategy.
Dell: _exact_ same configuration, without an OS (since I'm gonna install Linux on it too), no network switch included... $1,746
No seriously, check out the Dell PowerEdge 1600SC and set it to 2.8 GHz, "512MB DDR SDRAM,1x512 ", No OS and None in the " Dell PowerConnect Network Switches" category.
Whoops, so Sun is full of s**t again. The Dell is, in fact, one helluva lot cheaper than Sun's bulls**t.
So basically the _only_ machines that Sun makes, and which can compete with an Intel box at all, are... Intel based. And they're servers.
You know how sad that is? Way sad.
Sun SPARCs used to be decent machines. Now they are a sick joke. They're about 3 years behind Intel, as CPU technology goes.
And not only CPU technology. They're invariably 1-2 years behind as memory bandwidth goes. (E.g., they were still having EDO RAM when Intel or AMD boxes had SDRAM, and had SDRAM when the rest of the world had moved to DDR.) More so if you realize that up to and including the Blade 150, they were on a 32 bit memory bus, when Intel had a 64 bit bus ever since the original Pentium.
And so on. Just about everything about Sun's own designs just screams "obsolete crap, sold for 10 times more than it's worth."
You seem to make a small confusion between "programmer", "tech support" and "marketroid". My job is to get that big corporate enterprise system to run. Not only that, but to run fast and reliable. (When you're doing business over that system, you don't want something which randomly crashes or losing data after a supplier clicked "OK".)
I.e., I'm there to solve a _technical_ problem, as part of a _team_. The parts I write must perfectly match the parts my coleagues write. If we didn't use very clear CS terms to define a problem, communication and coordination within the team would be impossible.
If I started using bogus non-scientific phrases like "uh, little internet-like pieces of data", another member of the team wouldn't know exactly what that means. Does that mean UDP datagrams? Or the IP packets as such? Or does "internet-like" mean they're embedded in HTML tags? Maybe SOAP? Or what?
See the problem yet?
You are right about another aspect, though. I do know very well that the current trend is to hire some clowns in a suit that are supposed to function interchangeably for either programming, or having dinners with the customer to sell snake oil.
The problem with that is that those skills are completely unrelated, and _extremely_ few people are actually any good at both. And those who are, are unlikely to be hired for a low wage.
I.e., what really happens, is that said boss hires someone who's _only_ a snake oil peddler. Good at marketing himself, but crap at writing code, and without any clue or experience about algorithms or security.
They'll write piss-poor code, riddled with bugs and major security holes. And then fall back to their marketing skill to basically sell an excuse to the boss. The project will drag for years, and cost someone many millions, before finally being scrapped.
"Most companies would much rather spend a couple million to make the license problem go away then have to release any intellectual property."
That is probably true, but then they should have used a different operating system instead. I mean, really, did anyone force them to use Linux? Did someone hold them at gunpoint to base their design on Linux in the first place? If they preferred to just throw some money at the problem, I'm sure Microsoft would have been perfectly happy to sell them Windows or Windows CE licenses.
Of course, then the device would have ended up costing a lot more than 129$. Not only because of the licenses, but also because of needing more hardware in that box. Much as KDE can out-bloat even XP, a non-GUI Linux installation can run happily on extremely underpowered hardware.
But the saddest thing is that they're probably the lowest form of clueless PHB. I doubt that they really needed to modify the kernel much. Even if they wanted to link some device drivers in the kernel, they could always just write them as separate.so files, and they're _not_ required to release the source for those. And whatever other applications they have on it (e.g., a management interface), could be just that too: separate applications. Which, again, don't need to be GPL'ed to run on Linux.
Basically with the tiniest ammount of brains, they could not be in this fix in the first place. They could be in a situation where they could say, "OK, get the standard 2.4.XY kernel, you already have the source for that. And we'll show you how we load these non-GPL'ed binary modules and applications on it, and obtain the exact configuration of our device."
No royalties and no proprietary code to release. End of story. Period.
But they just had to (A) be stupid, and then (B) whine about it to the press. It's just sad.
No, just on those with egos bigger than Africa. The kind who can't possibly ever admit that they don't know something.
Basically:
Correct way: You want to learn something? Fine, come ask. (And I mean, ask like a normal human being, not like an infatuated "I'm the boss, and I have no time for whatever unimportant crap you unwashed monkeys are doing there" baboon.)
E.g., you want to learn about how we use (or don't use) XML in the application? Fine, then come and say, "hi, could you clear a few things up for me? For example, what is XML and why do you use it here?" It's honest, straightforward, and not demeaning to any of the two people involved in the conversation. And you can bet that I'll do my best to explain.
Wrong way: Waltz in and start throwing around big words that you obviously don't even understand, trying to look smart. In practice, it will only make you look like a clown.
E.g., "Why don't you use an XSLT database? Change the design immediately to use an XSLT database." (Because there is no such thing, and can't possibly be. XML is the standard for data, XSLT is a language that processes XML.) "And the man from IBM said we should use IBM MQ Series. Change the design immediately. I have already assured our clients that we'll send the HTTP text to the browser over MQ Series." (Wrong. All browsers work over HTTP, not over MQ. A browser couldn't even connect to an MQ server, nor know what to do with the data. And, oh, you probably mean HTML text. HTTP is the protocol.) "Oh yeah, and we'll change the database from Oracle to Visual Fox Pro, 'cause it's more visual, and will reduce development time. We'll just put the database file on the file server, instead of having this expensive dabase server you requested." (Wrong. VFP is a single user database. It can't be used like that.)
If you ever act like that, _expect_ me to think you're a clown.
Wrong way: Acting like you're the master and I'm the slave, and I should obviously kiss your ass. In practice, I don't give a rat's ass if you have a bigger car or more money or whatnot. If you can't have a normal human conversation, than for all I care, you're the one lacking basic social skills, not I.
E.g., I actually meet a PHB from a customer who repeated about 4 times per hour, "The golden rule is: who has the gold makes the rules. And I have the gold." I initially thought he was the owner of the company or something. It turned out he was a sad clown of small PHB, probably worse paid than I was. They fired him about half a year later, after he drove all his programmers and most designers to quit en masse.
You give a good example with car mechanics. Guess what? They too use jargon. Their job too has very speciffic names for things. If, say, your injection is shot, they'll call it "injection", not "the thingy which squirts gas". If a spark plug needs replacing, they'll call it just that: "spark plug". Not, "the thingie which makes cute sparks and lights the gas".
See? They too have a very speciffic jargon, and will use it.
So then why would it be any different for CS? Just because you have no knowledge of what an "UDP datagram" is, doesn't mean I'll call it something else.
It's not about sounding smart. It's that for the last 50 years, computer science used very well defined names for very well defined things. That's why it's science and not small talk.
Wooing your customers or PHB is small talk. It is actually _supposed_ to be vague and fuzzy and emotional.
But science is precise. It must use speciffic words to convey very exact information. It's not supposed to woo bosses, it's supposed to accurately describe phenomena and solve problems. Plain and simple.
And I'm not gonna start calling them silly names like "uh, little internet-like pieces of information" just to avoid tripping your ego. If you don't understand those terms, then jolly well stick to what you do understand, and let me do my job.
And, no, I'm not against lack of knowledge. If your job isn't to program EJBs, yes, you don't really need to learn anything about EJBs. If your job isn't to program web services, yeah, you don't really need to learn anything about SOAP or parsing XML. Stick to doing _your_ job. We need people good at management or marketing, so there's no shame in being good at those.
But I _am_ against the infatuated monkeys who can't simply admit that they don't know something. The kind who'd rather belittle someone else's job than admit, plain and honest, that they don't know much about it.
Right... so you're telling me that a bunch of chronic freeloaders are a potential market. What a bunch of bull.
_The_ number one reason for downloading songs is merely the mentality that "hey, I can get it for free, and how are they going to catch me?" If they can just steal something paid for by other people (i.e., by the _actual_ customers), and it looks like no are risks involved, they'll steal it.
That's all. All the other bulls**t about exploited musicians is just that: bulls**t. Some piss poor attempt at justifying theft.
I have zero doubts that the same people would ride the train or bus without a ticket, if they thought noone's gonna catch them.
And then probably invent the same bulls**t as an excuse. "See, we're just rebelling against the way transport companies exploit bus drivers. If enough of us ride the bus without a ticket, then the driver can get recognition and earn more by doing live unplugged bus tours. And, oh, it's not really theft, because I didn't actually steal the physical chair off the bus or any other tangible property."
Only in practice, with music and software and busses alike, they're really just stealing from the paying customers. It's a _service_. It stays in business because someone still pays for it. (The _real_ customers.)
And I dare say that it must be obvious to those freeloaders too. Everyone knows that money has to come from somewhere. Only to some, being a thief comes naturally. They know the money comes from someone else, but they're more than happy to leech off someone else's money nevertheless.
I'm not sure if all people have come to accept it. Personally I think that the buggy untested releases are actually just a way for the publisher to shoot himself in the foot. I can't help noticing that well designed, well balanced and relatively bug-free games actually sell better.
Note that I don't only talk about bugs. A game where the engine is ready, but half the story has been cut out, the interface is still a sorry mess, and the difficulty curve throws random "bang, you're dead!" situations at the average gamer, well, still counts as released before being finished.
E.g., Diablo came pretty much out of nowhere, and it sold like hot cakes. Regardless of how some of us consider an arcade, not an RPG, it did have a very good and intutive interface, a very well balanced difficulty curve, and most importantly it was rock stable. Sure, it did have a problem with cheats in multiplayer, but single-player it was very much ready as released.
Worse yet, I think that this trend is shooting everyone in the foot. I actually know people who have given up on buying PC games because of a few nasty (read: buggy) surprises. And then there are those who don't even buy a game until it hits the bargain bin, hoping that in the meantime the most critical bugs will be fixed.
It sounds like you did your design work, and weighed all your options, and you know exactly what are the advantages for using XML, and what is the price to pay. My problem isn't with that, it's with the people who just go for the "golden hammer" approach. "Oooh, Sun says that it's a great tool, so we _must_ use it." Lemmings.
And you're dead right about SOAP.
SOAP in the end is just an extension of the same original XML idea. You have some _external_ data which gets imported and exported as XML. So you might as well have a standardized way to request that data from a third party server application. (E.g., in my travel agency example, I might as well have a standard way of getting the XML data from those hotels and airlines. As opposed to nagging them to send me that data by email.)
That's all that SOAP is supposed to be: a standard way to request a data export.
But then people come and use it _internally_ as a substitute for plain old calling a method in their own classes. Stupid, stupid, stupid fashion victims.
Is it that you didn't read the article or is it that you don't understand the purpose of a message queue? Just to clarify things for you, this is a way for your program to exchange data in a standard format with other programs. Programs not made by you, nor under your control.
I've read the article, and I understand the purpose of a message queue perfectly. However, in this case it's still a SFV case. In fact, it seems to me like the authors of that monstrosity don't understand it.
Just to clear things up for you: Those programs are far from being out of your control. They're using your API. That _is_ under your control.
It's that simple. If you want to write a program that runs in my GUI, it's my way or the highway. You either use my API, or you don't write programs for my GUI at all.
You may use third party wrappers around my API, but it doesn't change a thing. Somewhere down the line it either gets converted to _my_ standard, or it doesn't get executed at all.
That fundamental truth remains the same, regardless of whether the messages come in a well defined binary format, or in a well defined XML format. Either it's my way, or it's the highway.
If you had to import data from an existing old Cobol program running on a mainframe, _then_ it would qualify as interfacing with external programs out of your control.
Furthermore, it is an _internal_ issue anyway.
An application program does not (and should not) have to go through XML loops just to draw a line. They'll want to just call some function like "draw(X0, Y0, X1, Y1)", not build a whole XML file each time. They'll also want to just get an answer they immediately use, _not_ have to parse an XML file to see which colour a pixel is.
I.e., the whole XML fashion show just happens internally. In the best case it's between two components of the windowing system, in the worst case it's between the server and the client library. (Both being under your control.)
Can you say "internal data being passed around as XML"? Can you say "Stupid Fashion Victim"?
Still not convinced? Lemme point you at another idiocy from the article: they actually plan to do DTD validation on the fly. How's that for a waste of CPU cycles?
Actually, I can count easily more than 7 classes, once you start doing all the painful workarounds. Workarounds which just shouldn't be needed, if the EJB spec wasn't such an utterly retarded design.
E.g., you probably don't want to end up with the Remote interface out of sync with the EJB. The EJB does not directly implement the Remote interface, remember? So you end up writing another interface, which the EJB implements and the Remote extends. Whoop, that's an extra file.
E.g., you probably don't want to go through the loops of manually caching the Home, doing a JNDI lookup and/or the narrow() every single bloody time you just want to call a method. You'll probably want one function call to actually look like _one_ function call in the code. You'll probably also _don't_ want to change every single call in the program when you switch between Remote and Local.
So you write another class which hides all the EJB details. (It's called the "Business Delegate" pattern, btw.) Whoop, that's another file written.
Now let's assume that you have to also do programmatic login to access the EJBs. And you don't want to go through the loops of it all (including the Subject.doAS() and having a PrivilegedAction wrapper) each time you want to call an EJB. Whoop, more classes for you to write.
And so on and so forth. Just look through all the tricks and workarounds (many mis-named as "patterns") to get EJBs to work fast enough, or at all. About half of them make you write yet another class or two.
In some really sick cases, they even make you write another EJB. Like the Session facade pattern, to hide the piss-poor performance of remote calls to Entity Beans. Whoop, that's 7-8 files on top of what you already had.
Believe me, I'm speaking from experience. The whole thing balloons out of control. Add to that the whole wrestling with the vendor's bugs and problems and the ever changing specs, and in this project alone the EJB fashion has cost several man-years. (Compared to what the exact same thing would have taken to implement with plain servlets and JSP.)
Bingo. It never ceases to amaze me through how many loops people will go, just to stay "fashionable". One of them being the retarded use of XML on an _internal_ data pipeline.
Don't get me wrong. XML is great for its original purpose: a standard format for exchanging data with other programs. Programs not made by you, nor under your control.
XML was not designed to be fast, nor to take up little memory. It was supposed to just be easy to parse, in a standard way.
It's supposed to be used in situations like, "ok, we have this program, and have to import and use the data from 20 files from 20 other companies." (E.g., a travel agency wanting to be able to use data from completely unrelated companies, like hotels or airlines.) At which point, you don't care as much how fast it is to parse, you just consider yourself lucky to have only _one_ standard data format to parse. Even if it takes all night to get that data converted, you're still happy to have it in your computers at all.
Open Office using XML to save the files makes perfect sense, for example. It's _external_ data, and it's supposed to be readable by other program. That's exactly the intended use for XML. Again, the keyword is: external data.
But using XML _internally_? Gimme a break. If that's not a syndrom of being a SFV (Stupid Fashion Victim), I don't know what is.
I thought it was bad enough to see programs where perfectly good relational data isn't just printed to the screen as such. No siree, bub. They first convert it to XML, then run through an XSLT transformation to get the same data back. _Then_ they print it.
So I was thinking, "gee, surely nothing can be a more retarded waste of memory, CPU power and development funds." Well, now I'm proven wrong. There _are_ more retarded uses for it. This here X replacement has to take that crown.
Re:LOL, Struts is right on target.
on
Software Fashion
·
· Score: 2, Insightful
Actually, that's the whole thing that's wrong. When one of these "silver bullet" technologies creates more complexity and a steeper learning curves, that's my criterion that it's hype, buzzword and/or mis-used.
The whole _problem_ is that software projects are becoming more and more complex each year, and thus more likely to fail if tackled in the wrong fashion. (Even if they don't fail the first time around, they fail when someone has to maintain them. Whenever a whole enterprise system gets scrapped and rewritten from scratch, that's a failure.)
The whole goal is to reduce and manage this complexity, not to increase it even more. The driving force between inventing methodologies and patterns was precisely to manage and/or reduce complexity.
E.g., OO design was not invented just for the sake of writing extra code, it was suppose to make complex projects simpler and/or more manageable. The MVC idea itself was suppose to make complex GUIs (web based or not) simpler and more maintainable. Etc.
If you use framework which actually _increases_ complexity, makes you write 6 (SIX!) files for each button, and gives the developpers a steeper learning curve, you're doing it wrong. Worse yet, you're wasting your employers money. It's that simple. You're just wasting time and effort and money, to achieve something even harder to maintain than even the maligned monolythic JSP.
And I sure hope that one day the employers will wake up and start asking extra questions when they see purely buzzword technologies on a resume. Because someone in that team effectively cheated their employer of money and development time, just to get an extra buzzword on the resume. They spent extra time and maybe even caused a project to fail, just to make their own resume look better.
And it is about time that someone started kicking these leeches out of this industry. Well, I can only dream...
So in the same paragraph you say "I don't know or care precisely how fast the G5s are", but then you _know_ "they are worth the few hunder dollar premium."
Can you say... "Apple fanboy"? How do you decide if it's worth the money, if you don't even know what you get for that money?
And generally, it's this kind of messages (complete with the mandatory whining about Windows users) that gives the Mac community a bad name.
Let me spell it out for you. Maybe for you only one thing is important. (The Apple logo.) But the rest of the world base their purchase on an evaluation of _all_ the following factors:
- performance
- price
- usability (yes, including the number of buttons)
- application available for it
Etc.
So yes, the Mac may now be less of an underdog speed-wise. So now it's time to evaluate the other factors too. And for a lot of people it fails miserably. Especially when it comes to available applications.
Briefly: unlike you fanboys, normal people evaluate _all_ the aspects of a system, before buying it. Not only the logo. Even if it now passes one criterion, it may still miserably fail in other criteria.
Au contraire. I don't know about you, but I _don't_ need 90% of the bloat in KDE. And I definitely don't need a window manager which uses more RAM than the whole MS Windows OS does. (I'm talking about KDE again.)
No, I don't want an integrated HTML browser, I already have a perfectly good standalone one. No, I don't want yet another set of widgets. No, I definitely don't need yet another sound daemon in memory, there were already enough of those around. Etc.
Now XFce was not my favourite WM, either, but it was a pretty close second. It does its job, it does it well, and it does it without hogging up half the memory in the computer. That's perfectly good for me.
So, why dont you care about BeOS?
Lack of apps? hm?!
Bingo. I know that the official slashdot view is that the _only_ reason to have an OS is to brag about uptime. (Big deal. My old Windows 98 can stay up for months too, if I don't run anything on it.)
But for the rest of us, you see, it's the apps that matter. The _only_ reason to have a computer, and an OS on it, is to run the software I need or just want.
I suppose you are the kind of person that didnt care about Linux 3 years ago.
Yes, in fact, I'm exactly the kind of person who couldn't find much use in Linux 3 years ago. Nor around '93, when I first tried it. And I still can't.
And yes, I've tried. Had several versions of SuSE, RedHat and Mandrake installed so far.
Invariably, same issue: either it does not run the stuff I want to run, or the effort involved is completely disproportionate, compared to just booting up Windows. (No, recompiling half the libraries on the system, plus X and several kernel modules, just to get WineX to run... does _not_ qualify as "ready for the desktop.")
People should be able to choose the OS that fits them, even if nobody else "cares about it".
Fine by me. I'm not going to try to stop you from running anything you wish. For all I care, install GEM. Or Coherent. Or OS/2. (Now that was a good OS.) Or yeah, BeOS.
Still doesn't mean I have to take it seriously, though.
So says someone who likely never invented anything at all. Ever. Just made a living out of wholesale copying of other people's algorithms.
Do you even understand cryptography, for example? At all? Would you be able to invent a brand new encryption algorithm, overnight? One that actually works and is secure, I mean, not snake oil. Only _then_ are you entitled to bad mouth an encryption patent as "obvious idea."
Or since the GIF patent is the most maligned... Can you invent a brand new lossless compression algorithm over night? No, really. _That_ would make you qualified to judge it as "obvious idea."
It took, what? Over 3 decades of computing to come up with the LZW algorithm? If it's that obvious, how come all the "patents are bad" whiners didn't come up with a better one? No, PNG isn't a new compression algorithm. It just used another existing algoritm.
So you haven't ever invented anything. All your life you just copied algorithms wholesale from books and whatnot. And argue that you should be freely allowed to copy other people's inventions. And god forbid that you ever have to pay the original author anything for his work. Well, gee... Why am I not surprised?
No, really. I can also imagine how someone would like to produce pharmaceuticals without having to invest in research. Just get a few test tubes and start producing the exact same stuff that those big corporations produce.
Only in that kind of a plagiarists' world, what's the incentive to invest in research? Why bother paying big bucks to research something new, if then any unskilled monkey can come and copy it? Yes, that's your ideal world. A world where everyone just copies existing stuff, and new stuff appears maybe once or twice a century.
Re:What's up with AMD's model names lately?
on
Athlon 64 Debuts
·
· Score: 1
Well, the difference between an Athlon and a G5 is that you can actually run programs on an Athlon. If the Mac ever gets to run, say, 1/5 of the games and applications I can run on a PC, _then_ I might even start to consider a "Switch." Until then, I honestly couldn't care less what a G5's benchmark scores are, or how much it costs.
Benchmarks are good and fine, and price comparisons are good and fine. But noone sane buys a computer just to run benchmarks on it.
Thanks for illustrating my point perfectly. When you get to that kind of a code size, you start needing to actually know what's in a variable. Whether by strict coding standards, or by using a standard language feature, but you do need to make sure which one is a string and which one is an int and which one is neither.
_You_ obviously already understood this. At which point, yeah, I don't doubt that you can write a good program in PHP or any other language. (If not necessarily with the same ammount of effort.)
However, half the blogging monkeys out there who go on a "Java sucks, PHP rules" rant, _don't_ understand this. Their rants are based precisely on "PHP rules because it lets me never declare variables, use them uninitialized, and won't complain when I alternate assigning ints, strings and arrays to the same variable."
Unlike you, they're _not_ using any clever coding standards to overcome limitations. Au contraire, they're happy and proud that they can throw together an unstructured code disaster, without any design work or even without any basic forethought. _That_ is what they like about script languages.
_Your_ programs may well still work correctly at 600,000 lines of code. But try getting one of those monkeys to write a similarly sized program, with their unstructured weak-typed approach, that they're so proud of. I can guarantee that it won't work anywhere near correctly any more. In fact, chances are it won't even work at all.
_That_ is my problem with such blogs/rants. That in the end they're not even about Java vs PHP, they're really just about prototyping vs writing maintainable code. They're judging whole languages and paradigms based on little more experience than throwing together a 10,000 line unstructured spaghetti-code prototype. Out of which 6000..7000 lines are just HTML, anyway. And then extrapolate that experience as, "hey, look how quickly I threw those 5 pages together! This must be the One True Way to program anything. All that structured programming and type checking is just a sucky waste of time."
Which, as you discovered yourself, is just no longer true when you get in the hundreds of thousands of lines range.
Well, then blame the monkeys who had written the program in the first place. Because it was littered with stuff like that, and worse.
For starters, I'd really like to see how those operators save you when the wrong type variable is used in an expression. Because that was most of the cases where stuff like that happened.
Does PHP have also strict version for +, -, and generally every single numeric or string function or operator? No, I didn't think so. So the implicit type conversions will still bite you in the rear, sooner or later. Like it bit those guys. Hard.
Want another problem with it? Variables which, on certain code paths, were used uninitialized. Well, gee, another situation where the program only _sometimes_ malfunctions, in unexpected ways. Whereas Java would at least give a compile time warning.
Let me educate you on a point that you seem to completely miss. (And lots of people with lack of real life experience in large projects miss.) That is: the difference between prototyping and actually making a robust, scalable and (most importantly) maintainable product.
A prototype is something quick and dirty that just has to look right. Unfortunately, many people mistake it for the real thing. They claim to have written the program when they barely have a prototype.
Sure, it sorta works now, but it's piss-poorly documented and a nightmare to maintain. It's also already bursting at the seams, so when (not if) the requirements grow any larger, it'll be a flipping disaster. As the monster grows, it quickly becomes far more expensive to change anything in that spaghetti code mixture of logic, presentation and hard-coded values, than it would be to throw it all out the window and start again.
I've had the mis-fortune of having to maintain a project which had been thrown together by unskilled monkeys in PHP. Guess what? It was a fscking disaster.
One problem was precisely PHP's weak typing. Sure, it's neat if all you've ever made are small simple sites, but past a point it becomes a liability.
After having went through several maintenance and change cycles, obviously the programmers of that application had obviously lost track of when something is supposed to be a string and when it's supposed to be a value. The fact that in PHP if (x == 0) is true when x is "", or for that matter when X equals "OTHER", didn't help either.
In a strongly typed language, this just means gracefully getting a compile error, which is solved in 1 minute. In PHP it was just that the program sometimes mysteriously malfunctioned, even though most of the time it worked right. What would have been a few minutes of debugging in Java, was several days of debugging in PHP, on top of the cost of corrupted production data.
And that was only one of the many problems that that large application had. (A second one was the exact same mistake in reverse: if (x == "") is true when x = 0.)
Basically every single attempt they had made at reusing code was littered with this kind of mistakes. It was like it was the poster program for Murphy's Law: If it was possible to pass the wrong data type in a parameter, somewhere they had actually done so. And that weak typing just let them shoot themselves in the foot without any warning.
So you know what? I'm sick and tired of these blogging monkeys, making judgements they're simply not qualified to make. Just because any unskilled burger-flipper could quickly throw together a 3 page site in PHP, doesn't mean they have _any_ clue how to make a complex enterprise system, that can also be maintained and extended later.
Oh yeah, that kind of people piss me off no end. "It showed some kind of a message box, dunno what was written in it, I didn't read it. I clicked on OK, and now all my files are gone. *sob* *whine*"
I don't even work on tech support, but still have to recurringly deal with a family member who _never_ reads any message or dialog the computer shows. No ammount of "RTFDB (Read The F***ing Dialog Box) next time" can seem to convince them to actually do so. Next time it's "uh, it said something but I didn't read it" time, all over again.
Heck, I'm not even asking them to write it down. Just bloody read it and have some vague awareness of what was written there. Like maybe it was asking whether to delete a bunch of files or not? Or was it offering to install some ActiveX control or dialer, self-signed by someone called the "L33t Kr3w Corp"? You know, just have some fscking idea what they said "OK" to.
Well, there's this thing about _trademarks_. A trademark's sole purpose is to identify a product as being associated with a company. It's not supposed to be a guessing exercise as to whether it's "just a theme" or the real thing. It's supposed to always be the real thing, so the buyer can be sure of it.
That's why when you see "Playstation 2" on a DVD case you assume it's some game for the PS2, and not a "PS2 themed movie" or just a "PS2 themed round piece of plastic that's not even readable in a CD or DVD drive." That's why if you saw "Disneyland" or "Legoland" on a park you'd assume it's actually connected to Disney or Lego, and not just a knock-off that's only sorta themed after the original. Etc.
And how is that bad, anyway? If anyone could write "Intel Pentium 4" on a CPU, how would you know whether you've got a P4 or an el-cheapo Via CPU or something that's not even x86 compatible? If anyone could write "Apple Macintosh" on any box, regardless of whether it's even Mac compatible at all (or if it's even a computer), how would you know if you got the real thing or not? (Congrats, the PowerBook you've just bought was just a plastic sculpture "themed" after the real thing.)
Sure, you could do a lot of research, but would it be worth your time? Isn't it much better to just know what you're buying?
Basically I wish some slashotters could get over the knee-jerk reaction of posting "IP sucks" or "IP is evil" in any imaginable context. Whetever faults we might find with copyright or patents, the trademark concept actually works for the consumer too.
And it's not even like the poor hotel is being persecuted or anything. They deliberately used someone's trademark, and cheerfully ignored the warnings. They could have passed for a theme hotel just as well without using that trademark.
Slashdot Mirror
The exact same 1 CPU Dell configuration as a rack mounted server (yes, the PE1750) ... $1,698
Still cheaper than Sun's crap, or? In fact, even cheaper than the desktop configuration.
If you had a reading comprehension above that of a 5 year old you might have been clued into the fact that they are comparing their servers to the Dell poweredge servers. Dell's 1750 server is cheaper than the Sun 60x, but the Sun65x is just several hundred off. I would bet that after corporate discounts the price diff would neg. and if Sun's servers perform better...). I can't stand Slashdot idiots making invalid comparisons.
Ah, a jolly good flame war. Count me in.
So lemme see. You can't even notice that the PE 1750 is even cheaper, and spew stuff like "If takes a lot more engineering(and money) to make a powerful server in a 1U form factor." Well, gee, Dell's price list says the exact opposite.
Or let's talk basic comprehension of numbers and economics. "is just several hundreds off". Well, guess what? The V60x is exactly $752 more expensive, or a whole 44.3% more expensive than the Dell. (752 * 100 / 1698, for the maths impaired.)
The v65x is even more expensive. It's $2,550 for the smallest config. So $852, or 50.2% more expensive than the Dell.
So you're advocating... what? Paying 50% extra for the _exact_ same machine, just to have Sun's logo on it? Lemming.
As for "if Sun's servers perform better...", that's a huge "if". I'd really like to see some benchmarks first. No, seriously. They're can use exactly the same CPU, motherboard and memory as any other Intel server manufacturer can use. So if you want me to believe that just a bit of marketing hocus pocus will make it run faster, you better show some numbers that prove that.
Actually, most of us don't think Sun is evil. Just that their whole product line is obsolete, underperforming, overpriced, and lacking any coherent strategy.
Evil? No.
Yet another has-been? Yes. Most definitely.
But let's see if it's at least true.
Let's take the cheapest v60x.
Sun: 1 Xeon CPU 2.8 GHz, 512 MB RAM, 36 GB SCSI HDD (10K RPM), gigabit ethernet... $2,450
Dell: _exact_ same configuration, without an OS (since I'm gonna install Linux on it too), no network switch included... $1,746
No seriously, check out the Dell PowerEdge 1600SC and set it to 2.8 GHz, "512MB DDR SDRAM,1x512 ", No OS and None in the " Dell PowerConnect Network Switches" category.
Whoops, so Sun is full of s**t again. The Dell is, in fact, one helluva lot cheaper than Sun's bulls**t.
Let's try a dual CPU, then?
Sun: 2 Xeon CPU 2.8 GHz, 1 GB RAM, 36 GB SCSI HDD (10K RPM), gigabit ethernet... $3,395
Dell: we'll take the same as Dell server as above, and bring it on par with the Sun: second 2.8 GHz Xeon, and "1.0GB DDR SDRAM,2x512"... $2,844
Whoops, again, the Dell is actually cheaper. Reality is quite different from Sun's marketing bulls**t, isn't it?
You know how sad that is? Way sad.
Sun SPARCs used to be decent machines. Now they are a sick joke. They're about 3 years behind Intel, as CPU technology goes.
And not only CPU technology. They're invariably 1-2 years behind as memory bandwidth goes. (E.g., they were still having EDO RAM when Intel or AMD boxes had SDRAM, and had SDRAM when the rest of the world had moved to DDR.) More so if you realize that up to and including the Blade 150, they were on a 32 bit memory bus, when Intel had a 64 bit bus ever since the original Pentium.
And so on. Just about everything about Sun's own designs just screams "obsolete crap, sold for 10 times more than it's worth."
As I've said: it's sad. Way sad.
You seem to make a small confusion between "programmer", "tech support" and "marketroid". My job is to get that big corporate enterprise system to run. Not only that, but to run fast and reliable. (When you're doing business over that system, you don't want something which randomly crashes or losing data after a supplier clicked "OK".)
I.e., I'm there to solve a _technical_ problem, as part of a _team_. The parts I write must perfectly match the parts my coleagues write. If we didn't use very clear CS terms to define a problem, communication and coordination within the team would be impossible.
If I started using bogus non-scientific phrases like "uh, little internet-like pieces of data", another member of the team wouldn't know exactly what that means. Does that mean UDP datagrams? Or the IP packets as such? Or does "internet-like" mean they're embedded in HTML tags? Maybe SOAP? Or what?
See the problem yet?
You are right about another aspect, though. I do know very well that the current trend is to hire some clowns in a suit that are supposed to function interchangeably for either programming, or having dinners with the customer to sell snake oil.
The problem with that is that those skills are completely unrelated, and _extremely_ few people are actually any good at both. And those who are, are unlikely to be hired for a low wage.
I.e., what really happens, is that said boss hires someone who's _only_ a snake oil peddler. Good at marketing himself, but crap at writing code, and without any clue or experience about algorithms or security.
They'll write piss-poor code, riddled with bugs and major security holes. And then fall back to their marketing skill to basically sell an excuse to the boss. The project will drag for years, and cost someone many millions, before finally being scrapped.
I've seen enough of those already.
That is probably true, but then they should have used a different operating system instead. I mean, really, did anyone force them to use Linux? Did someone hold them at gunpoint to base their design on Linux in the first place? If they preferred to just throw some money at the problem, I'm sure Microsoft would have been perfectly happy to sell them Windows or Windows CE licenses.
Of course, then the device would have ended up costing a lot more than 129$. Not only because of the licenses, but also because of needing more hardware in that box. Much as KDE can out-bloat even XP, a non-GUI Linux installation can run happily on extremely underpowered hardware.
But the saddest thing is that they're probably the lowest form of clueless PHB. I doubt that they really needed to modify the kernel much. Even if they wanted to link some device drivers in the kernel, they could always just write them as separate .so files, and they're _not_ required to release the source for those. And whatever other applications they have on it (e.g., a management interface), could be just that too: separate applications. Which, again, don't need to be GPL'ed to run on Linux.
Basically with the tiniest ammount of brains, they could not be in this fix in the first place. They could be in a situation where they could say, "OK, get the standard 2.4.XY kernel, you already have the source for that. And we'll show you how we load these non-GPL'ed binary modules and applications on it, and obtain the exact configuration of our device."
No royalties and no proprietary code to release. End of story. Period.
But they just had to (A) be stupid, and then (B) whine about it to the press. It's just sad.
No, just on those with egos bigger than Africa. The kind who can't possibly ever admit that they don't know something.
Basically:
Correct way: You want to learn something? Fine, come ask. (And I mean, ask like a normal human being, not like an infatuated "I'm the boss, and I have no time for whatever unimportant crap you unwashed monkeys are doing there" baboon.)
E.g., you want to learn about how we use (or don't use) XML in the application? Fine, then come and say, "hi, could you clear a few things up for me? For example, what is XML and why do you use it here?" It's honest, straightforward, and not demeaning to any of the two people involved in the conversation. And you can bet that I'll do my best to explain.
Wrong way: Waltz in and start throwing around big words that you obviously don't even understand, trying to look smart. In practice, it will only make you look like a clown. E.g., "Why don't you use an XSLT database? Change the design immediately to use an XSLT database." (Because there is no such thing, and can't possibly be. XML is the standard for data, XSLT is a language that processes XML.) "And the man from IBM said we should use IBM MQ Series. Change the design immediately. I have already assured our clients that we'll send the HTTP text to the browser over MQ Series." (Wrong. All browsers work over HTTP, not over MQ. A browser couldn't even connect to an MQ server, nor know what to do with the data. And, oh, you probably mean HTML text. HTTP is the protocol.) "Oh yeah, and we'll change the database from Oracle to Visual Fox Pro, 'cause it's more visual, and will reduce development time. We'll just put the database file on the file server, instead of having this expensive dabase server you requested." (Wrong. VFP is a single user database. It can't be used like that.)
If you ever act like that, _expect_ me to think you're a clown.
Wrong way: Acting like you're the master and I'm the slave, and I should obviously kiss your ass. In practice, I don't give a rat's ass if you have a bigger car or more money or whatnot. If you can't have a normal human conversation, than for all I care, you're the one lacking basic social skills, not I.
E.g., I actually meet a PHB from a customer who repeated about 4 times per hour, "The golden rule is: who has the gold makes the rules. And I have the gold." I initially thought he was the owner of the company or something. It turned out he was a sad clown of small PHB, probably worse paid than I was. They fired him about half a year later, after he drove all his programmers and most designers to quit en masse.
See? They too have a very speciffic jargon, and will use it.
So then why would it be any different for CS? Just because you have no knowledge of what an "UDP datagram" is, doesn't mean I'll call it something else.
It's not about sounding smart. It's that for the last 50 years, computer science used very well defined names for very well defined things. That's why it's science and not small talk.
Wooing your customers or PHB is small talk. It is actually _supposed_ to be vague and fuzzy and emotional.
But science is precise. It must use speciffic words to convey very exact information. It's not supposed to woo bosses, it's supposed to accurately describe phenomena and solve problems. Plain and simple.
And I'm not gonna start calling them silly names like "uh, little internet-like pieces of information" just to avoid tripping your ego. If you don't understand those terms, then jolly well stick to what you do understand, and let me do my job.
And, no, I'm not against lack of knowledge. If your job isn't to program EJBs, yes, you don't really need to learn anything about EJBs. If your job isn't to program web services, yeah, you don't really need to learn anything about SOAP or parsing XML. Stick to doing _your_ job. We need people good at management or marketing, so there's no shame in being good at those.
But I _am_ against the infatuated monkeys who can't simply admit that they don't know something. The kind who'd rather belittle someone else's job than admit, plain and honest, that they don't know much about it.
Right... so you're telling me that a bunch of chronic freeloaders are a potential market. What a bunch of bull.
_The_ number one reason for downloading songs is merely the mentality that "hey, I can get it for free, and how are they going to catch me?" If they can just steal something paid for by other people (i.e., by the _actual_ customers), and it looks like no are risks involved, they'll steal it.
That's all. All the other bulls**t about exploited musicians is just that: bulls**t. Some piss poor attempt at justifying theft.
I have zero doubts that the same people would ride the train or bus without a ticket, if they thought noone's gonna catch them.
And then probably invent the same bulls**t as an excuse. "See, we're just rebelling against the way transport companies exploit bus drivers. If enough of us ride the bus without a ticket, then the driver can get recognition and earn more by doing live unplugged bus tours. And, oh, it's not really theft, because I didn't actually steal the physical chair off the bus or any other tangible property."
Only in practice, with music and software and busses alike, they're really just stealing from the paying customers. It's a _service_. It stays in business because someone still pays for it. (The _real_ customers.)
And I dare say that it must be obvious to those freeloaders too. Everyone knows that money has to come from somewhere. Only to some, being a thief comes naturally. They know the money comes from someone else, but they're more than happy to leech off someone else's money nevertheless.
I'm not sure if all people have come to accept it. Personally I think that the buggy untested releases are actually just a way for the publisher to shoot himself in the foot. I can't help noticing that well designed, well balanced and relatively bug-free games actually sell better.
Note that I don't only talk about bugs. A game where the engine is ready, but half the story has been cut out, the interface is still a sorry mess, and the difficulty curve throws random "bang, you're dead!" situations at the average gamer, well, still counts as released before being finished.
E.g., Diablo came pretty much out of nowhere, and it sold like hot cakes. Regardless of how some of us consider an arcade, not an RPG, it did have a very good and intutive interface, a very well balanced difficulty curve, and most importantly it was rock stable. Sure, it did have a problem with cheats in multiplayer, but single-player it was very much ready as released.
Worse yet, I think that this trend is shooting everyone in the foot. I actually know people who have given up on buying PC games because of a few nasty (read: buggy) surprises. And then there are those who don't even buy a game until it hits the bargain bin, hoping that in the meantime the most critical bugs will be fixed.
It sounds like you did your design work, and weighed all your options, and you know exactly what are the advantages for using XML, and what is the price to pay. My problem isn't with that, it's with the people who just go for the "golden hammer" approach. "Oooh, Sun says that it's a great tool, so we _must_ use it." Lemmings.
And you're dead right about SOAP.
SOAP in the end is just an extension of the same original XML idea. You have some _external_ data which gets imported and exported as XML. So you might as well have a standardized way to request that data from a third party server application. (E.g., in my travel agency example, I might as well have a standard way of getting the XML data from those hotels and airlines. As opposed to nagging them to send me that data by email.)
That's all that SOAP is supposed to be: a standard way to request a data export.
But then people come and use it _internally_ as a substitute for plain old calling a method in their own classes. Stupid, stupid, stupid fashion victims.
I've read the article, and I understand the purpose of a message queue perfectly. However, in this case it's still a SFV case. In fact, it seems to me like the authors of that monstrosity don't understand it.
Just to clear things up for you: Those programs are far from being out of your control. They're using your API. That _is_ under your control.
It's that simple. If you want to write a program that runs in my GUI, it's my way or the highway. You either use my API, or you don't write programs for my GUI at all.
You may use third party wrappers around my API, but it doesn't change a thing. Somewhere down the line it either gets converted to _my_ standard, or it doesn't get executed at all.
That fundamental truth remains the same, regardless of whether the messages come in a well defined binary format, or in a well defined XML format. Either it's my way, or it's the highway.
If you had to import data from an existing old Cobol program running on a mainframe, _then_ it would qualify as interfacing with external programs out of your control.
Furthermore, it is an _internal_ issue anyway.
An application program does not (and should not) have to go through XML loops just to draw a line. They'll want to just call some function like "draw(X0, Y0, X1, Y1)", not build a whole XML file each time. They'll also want to just get an answer they immediately use, _not_ have to parse an XML file to see which colour a pixel is.
I.e., the whole XML fashion show just happens internally. In the best case it's between two components of the windowing system, in the worst case it's between the server and the client library. (Both being under your control.)
Can you say "internal data being passed around as XML"? Can you say "Stupid Fashion Victim"?
Still not convinced? Lemme point you at another idiocy from the article: they actually plan to do DTD validation on the fly. How's that for a waste of CPU cycles?
Actually, I can count easily more than 7 classes, once you start doing all the painful workarounds. Workarounds which just shouldn't be needed, if the EJB spec wasn't such an utterly retarded design.
E.g., you probably don't want to end up with the Remote interface out of sync with the EJB. The EJB does not directly implement the Remote interface, remember? So you end up writing another interface, which the EJB implements and the Remote extends. Whoop, that's an extra file.
E.g., you probably don't want to go through the loops of manually caching the Home, doing a JNDI lookup and/or the narrow() every single bloody time you just want to call a method. You'll probably want one function call to actually look like _one_ function call in the code. You'll probably also _don't_ want to change every single call in the program when you switch between Remote and Local.
So you write another class which hides all the EJB details. (It's called the "Business Delegate" pattern, btw.) Whoop, that's another file written.
Now let's assume that you have to also do programmatic login to access the EJBs. And you don't want to go through the loops of it all (including the Subject.doAS() and having a PrivilegedAction wrapper) each time you want to call an EJB. Whoop, more classes for you to write.
And so on and so forth. Just look through all the tricks and workarounds (many mis-named as "patterns") to get EJBs to work fast enough, or at all. About half of them make you write yet another class or two.
In some really sick cases, they even make you write another EJB. Like the Session facade pattern, to hide the piss-poor performance of remote calls to Entity Beans. Whoop, that's 7-8 files on top of what you already had.
Believe me, I'm speaking from experience. The whole thing balloons out of control. Add to that the whole wrestling with the vendor's bugs and problems and the ever changing specs, and in this project alone the EJB fashion has cost several man-years. (Compared to what the exact same thing would have taken to implement with plain servlets and JSP.)
Bingo. It never ceases to amaze me through how many loops people will go, just to stay "fashionable". One of them being the retarded use of XML on an _internal_ data pipeline.
Don't get me wrong. XML is great for its original purpose: a standard format for exchanging data with other programs. Programs not made by you, nor under your control.
XML was not designed to be fast, nor to take up little memory. It was supposed to just be easy to parse, in a standard way.
It's supposed to be used in situations like, "ok, we have this program, and have to import and use the data from 20 files from 20 other companies." (E.g., a travel agency wanting to be able to use data from completely unrelated companies, like hotels or airlines.) At which point, you don't care as much how fast it is to parse, you just consider yourself lucky to have only _one_ standard data format to parse. Even if it takes all night to get that data converted, you're still happy to have it in your computers at all.
Open Office using XML to save the files makes perfect sense, for example. It's _external_ data, and it's supposed to be readable by other program. That's exactly the intended use for XML. Again, the keyword is: external data.
But using XML _internally_? Gimme a break. If that's not a syndrom of being a SFV (Stupid Fashion Victim), I don't know what is.
I thought it was bad enough to see programs where perfectly good relational data isn't just printed to the screen as such. No siree, bub. They first convert it to XML, then run through an XSLT transformation to get the same data back. _Then_ they print it.
So I was thinking, "gee, surely nothing can be a more retarded waste of memory, CPU power and development funds." Well, now I'm proven wrong. There _are_ more retarded uses for it. This here X replacement has to take that crown.
Actually, that's the whole thing that's wrong. When one of these "silver bullet" technologies creates more complexity and a steeper learning curves, that's my criterion that it's hype, buzzword and/or mis-used.
The whole _problem_ is that software projects are becoming more and more complex each year, and thus more likely to fail if tackled in the wrong fashion. (Even if they don't fail the first time around, they fail when someone has to maintain them. Whenever a whole enterprise system gets scrapped and rewritten from scratch, that's a failure.)
The whole goal is to reduce and manage this complexity, not to increase it even more. The driving force between inventing methodologies and patterns was precisely to manage and/or reduce complexity.
E.g., OO design was not invented just for the sake of writing extra code, it was suppose to make complex projects simpler and/or more manageable. The MVC idea itself was suppose to make complex GUIs (web based or not) simpler and more maintainable. Etc.
If you use framework which actually _increases_ complexity, makes you write 6 (SIX!) files for each button, and gives the developpers a steeper learning curve, you're doing it wrong. Worse yet, you're wasting your employers money. It's that simple. You're just wasting time and effort and money, to achieve something even harder to maintain than even the maligned monolythic JSP.
And I sure hope that one day the employers will wake up and start asking extra questions when they see purely buzzword technologies on a resume. Because someone in that team effectively cheated their employer of money and development time, just to get an extra buzzword on the resume. They spent extra time and maybe even caused a project to fail, just to make their own resume look better.
And it is about time that someone started kicking these leeches out of this industry. Well, I can only dream...
So in the same paragraph you say "I don't know or care precisely how fast the G5s are", but then you _know_ "they are worth the few hunder dollar premium."
Can you say... "Apple fanboy"? How do you decide if it's worth the money, if you don't even know what you get for that money?
And generally, it's this kind of messages (complete with the mandatory whining about Windows users) that gives the Mac community a bad name.
Let me spell it out for you. Maybe for you only one thing is important. (The Apple logo.) But the rest of the world base their purchase on an evaluation of _all_ the following factors:
- performance
- price
- usability (yes, including the number of buttons)
- application available for it
Etc.
So yes, the Mac may now be less of an underdog speed-wise. So now it's time to evaluate the other factors too. And for a lot of people it fails miserably. Especially when it comes to available applications.
Briefly: unlike you fanboys, normal people evaluate _all_ the aspects of a system, before buying it. Not only the logo. Even if it now passes one criterion, it may still miserably fail in other criteria.
Au contraire. I don't know about you, but I _don't_ need 90% of the bloat in KDE. And I definitely don't need a window manager which uses more RAM than the whole MS Windows OS does. (I'm talking about KDE again.)
No, I don't want an integrated HTML browser, I already have a perfectly good standalone one. No, I don't want yet another set of widgets. No, I definitely don't need yet another sound daemon in memory, there were already enough of those around. Etc.
Now XFce was not my favourite WM, either, but it was a pretty close second. It does its job, it does it well, and it does it without hogging up half the memory in the computer. That's perfectly good for me.
Lack of apps? hm?!
Bingo. I know that the official slashdot view is that the _only_ reason to have an OS is to brag about uptime. (Big deal. My old Windows 98 can stay up for months too, if I don't run anything on it.)
But for the rest of us, you see, it's the apps that matter. The _only_ reason to have a computer, and an OS on it, is to run the software I need or just want.
I suppose you are the kind of person that didnt care about Linux 3 years ago.
Yes, in fact, I'm exactly the kind of person who couldn't find much use in Linux 3 years ago. Nor around '93, when I first tried it. And I still can't.
And yes, I've tried. Had several versions of SuSE, RedHat and Mandrake installed so far.
Invariably, same issue: either it does not run the stuff I want to run, or the effort involved is completely disproportionate, compared to just booting up Windows. (No, recompiling half the libraries on the system, plus X and several kernel modules, just to get WineX to run... does _not_ qualify as "ready for the desktop.")
People should be able to choose the OS that fits them, even if nobody else "cares about it".
Fine by me. I'm not going to try to stop you from running anything you wish. For all I care, install GEM. Or Coherent. Or OS/2. (Now that was a good OS.) Or yeah, BeOS.
Still doesn't mean I have to take it seriously, though.
So says someone who likely never invented anything at all. Ever. Just made a living out of wholesale copying of other people's algorithms.
Do you even understand cryptography, for example? At all? Would you be able to invent a brand new encryption algorithm, overnight? One that actually works and is secure, I mean, not snake oil. Only _then_ are you entitled to bad mouth an encryption patent as "obvious idea."
Or since the GIF patent is the most maligned... Can you invent a brand new lossless compression algorithm over night? No, really. _That_ would make you qualified to judge it as "obvious idea."
It took, what? Over 3 decades of computing to come up with the LZW algorithm? If it's that obvious, how come all the "patents are bad" whiners didn't come up with a better one? No, PNG isn't a new compression algorithm. It just used another existing algoritm.
So you haven't ever invented anything. All your life you just copied algorithms wholesale from books and whatnot. And argue that you should be freely allowed to copy other people's inventions. And god forbid that you ever have to pay the original author anything for his work. Well, gee... Why am I not surprised?
No, really. I can also imagine how someone would like to produce pharmaceuticals without having to invest in research. Just get a few test tubes and start producing the exact same stuff that those big corporations produce.
Only in that kind of a plagiarists' world, what's the incentive to invest in research? Why bother paying big bucks to research something new, if then any unskilled monkey can come and copy it? Yes, that's your ideal world. A world where everyone just copies existing stuff, and new stuff appears maybe once or twice a century.
Well, the difference between an Athlon and a G5 is that you can actually run programs on an Athlon. If the Mac ever gets to run, say, 1/5 of the games and applications I can run on a PC, _then_ I might even start to consider a "Switch." Until then, I honestly couldn't care less what a G5's benchmark scores are, or how much it costs.
Benchmarks are good and fine, and price comparisons are good and fine. But noone sane buys a computer just to run benchmarks on it.
Thanks for illustrating my point perfectly. When you get to that kind of a code size, you start needing to actually know what's in a variable. Whether by strict coding standards, or by using a standard language feature, but you do need to make sure which one is a string and which one is an int and which one is neither.
_You_ obviously already understood this. At which point, yeah, I don't doubt that you can write a good program in PHP or any other language. (If not necessarily with the same ammount of effort.)
However, half the blogging monkeys out there who go on a "Java sucks, PHP rules" rant, _don't_ understand this. Their rants are based precisely on "PHP rules because it lets me never declare variables, use them uninitialized, and won't complain when I alternate assigning ints, strings and arrays to the same variable."
Unlike you, they're _not_ using any clever coding standards to overcome limitations. Au contraire, they're happy and proud that they can throw together an unstructured code disaster, without any design work or even without any basic forethought. _That_ is what they like about script languages.
_Your_ programs may well still work correctly at 600,000 lines of code. But try getting one of those monkeys to write a similarly sized program, with their unstructured weak-typed approach, that they're so proud of. I can guarantee that it won't work anywhere near correctly any more. In fact, chances are it won't even work at all.
_That_ is my problem with such blogs/rants. That in the end they're not even about Java vs PHP, they're really just about prototyping vs writing maintainable code. They're judging whole languages and paradigms based on little more experience than throwing together a 10,000 line unstructured spaghetti-code prototype. Out of which 6000..7000 lines are just HTML, anyway. And then extrapolate that experience as, "hey, look how quickly I threw those 5 pages together! This must be the One True Way to program anything. All that structured programming and type checking is just a sucky waste of time."
Which, as you discovered yourself, is just no longer true when you get in the hundreds of thousands of lines range.
Well, then blame the monkeys who had written the program in the first place. Because it was littered with stuff like that, and worse.
For starters, I'd really like to see how those operators save you when the wrong type variable is used in an expression. Because that was most of the cases where stuff like that happened.
Does PHP have also strict version for +, -, and generally every single numeric or string function or operator? No, I didn't think so. So the implicit type conversions will still bite you in the rear, sooner or later. Like it bit those guys. Hard.
Want another problem with it? Variables which, on certain code paths, were used uninitialized. Well, gee, another situation where the program only _sometimes_ malfunctions, in unexpected ways. Whereas Java would at least give a compile time warning.
A prototype is something quick and dirty that just has to look right. Unfortunately, many people mistake it for the real thing. They claim to have written the program when they barely have a prototype.
Sure, it sorta works now, but it's piss-poorly documented and a nightmare to maintain. It's also already bursting at the seams, so when (not if) the requirements grow any larger, it'll be a flipping disaster. As the monster grows, it quickly becomes far more expensive to change anything in that spaghetti code mixture of logic, presentation and hard-coded values, than it would be to throw it all out the window and start again.
I've had the mis-fortune of having to maintain a project which had been thrown together by unskilled monkeys in PHP. Guess what? It was a fscking disaster.
One problem was precisely PHP's weak typing. Sure, it's neat if all you've ever made are small simple sites, but past a point it becomes a liability.
After having went through several maintenance and change cycles, obviously the programmers of that application had obviously lost track of when something is supposed to be a string and when it's supposed to be a value. The fact that in PHP if (x == 0) is true when x is "", or for that matter when X equals "OTHER", didn't help either.
In a strongly typed language, this just means gracefully getting a compile error, which is solved in 1 minute. In PHP it was just that the program sometimes mysteriously malfunctioned, even though most of the time it worked right. What would have been a few minutes of debugging in Java, was several days of debugging in PHP, on top of the cost of corrupted production data.
And that was only one of the many problems that that large application had. (A second one was the exact same mistake in reverse: if (x == "") is true when x = 0.)
Basically every single attempt they had made at reusing code was littered with this kind of mistakes. It was like it was the poster program for Murphy's Law: If it was possible to pass the wrong data type in a parameter, somewhere they had actually done so. And that weak typing just let them shoot themselves in the foot without any warning.
So you know what? I'm sick and tired of these blogging monkeys, making judgements they're simply not qualified to make. Just because any unskilled burger-flipper could quickly throw together a 3 page site in PHP, doesn't mean they have _any_ clue how to make a complex enterprise system, that can also be maintained and extended later.
Oh yeah, that kind of people piss me off no end. "It showed some kind of a message box, dunno what was written in it, I didn't read it. I clicked on OK, and now all my files are gone. *sob* *whine*"
I don't even work on tech support, but still have to recurringly deal with a family member who _never_ reads any message or dialog the computer shows. No ammount of "RTFDB (Read The F***ing Dialog Box) next time" can seem to convince them to actually do so. Next time it's "uh, it said something but I didn't read it" time, all over again.
Heck, I'm not even asking them to write it down. Just bloody read it and have some vague awareness of what was written there. Like maybe it was asking whether to delete a bunch of files or not? Or was it offering to install some ActiveX control or dialer, self-signed by someone called the "L33t Kr3w Corp"? You know, just have some fscking idea what they said "OK" to.
Oh well...
Well, there's this thing about _trademarks_. A trademark's sole purpose is to identify a product as being associated with a company. It's not supposed to be a guessing exercise as to whether it's "just a theme" or the real thing. It's supposed to always be the real thing, so the buyer can be sure of it.
That's why when you see "Playstation 2" on a DVD case you assume it's some game for the PS2, and not a "PS2 themed movie" or just a "PS2 themed round piece of plastic that's not even readable in a CD or DVD drive." That's why if you saw "Disneyland" or "Legoland" on a park you'd assume it's actually connected to Disney or Lego, and not just a knock-off that's only sorta themed after the original. Etc.
And how is that bad, anyway? If anyone could write "Intel Pentium 4" on a CPU, how would you know whether you've got a P4 or an el-cheapo Via CPU or something that's not even x86 compatible? If anyone could write "Apple Macintosh" on any box, regardless of whether it's even Mac compatible at all (or if it's even a computer), how would you know if you got the real thing or not? (Congrats, the PowerBook you've just bought was just a plastic sculpture "themed" after the real thing.)
Sure, you could do a lot of research, but would it be worth your time? Isn't it much better to just know what you're buying?
Basically I wish some slashotters could get over the knee-jerk reaction of posting "IP sucks" or "IP is evil" in any imaginable context. Whetever faults we might find with copyright or patents, the trademark concept actually works for the consumer too.
And it's not even like the poor hotel is being persecuted or anything. They deliberately used someone's trademark, and cheerfully ignored the warnings. They could have passed for a theme hotel just as well without using that trademark.