The advice I would give to new programmers is learn C++ and learn how to use proxies allocated in the stack frame, and learn how to determine object lifetime correctly. *Then* move on to Java and.NET and things like that. The greatest chefs all learned how to season their dishes, but once perfected, they just bung in a dollop of brown sauce.
I'd probably agree for anyone that I wanted to see become a good programmer. Though I've been very interested in getting my wife to do some simple programming.. And believe me, I have no interest in scaring her off by making her go through the entire drill routine.. In fact, I'd prefer if we had a billion bad programmers than only a couple thousand good ones.
If you have been involved in developmnent for any reasonable amount of time or worked on projects of reasonable size, you know that *good* programmers are hard to come by.
I'll come back to this.
If schools actually learned to produce good programmers, and HR departments learned how to identify them, and job interviews verified them, we wouldn't be having this discussion.
Ah.. there's the bullshit.. Right where I can find it.
Guess what.. I've tutored people in collage.. Their dumb as a brick, some of them... I can't see how the school could possibly turn people of the wrong mind-set into good programmers. The only possible way of reconsiling your two statements that I've outlined is to outsource almost ALL of our programming to Russia and China.. Two places w/ strong math carriculum (a core requirement of being a good programmer). Their sheer number of citizens subjected to painful degrees of mathmatics has a weeding-out process that leaves a large number of highly qualified logicians (a better name for a *good* programer).
That being said. Do you blame the consumer for not being able to program their VCR? Not if your the Venture capitalist. You identify a market where VCRs and Microwaves are not being properly used.. Likewise w/ digital walk-men.. The iPod is a testiment to the idiocy of Americana. It's "easy to use". Who gives a crap? The people that can't figure out complicated devices do.
What we want is a world of advancement.. Where people recognize the value of directed automation.. I want a consumer to be able to see the value in programatically configuring the lights in their house, the temperature of water, the TV schedule, etc. Then people will market to that techno-involved consumer.. Then they'll have economies of scale for the geek-toys that I'd love to have but aren't currently manufactured. We were shown all sorts of really cool stuff in the 60's that were never created, mostly because there was no market for them.
Back to the more specific topic at hand. GIVEN that programmers are not all geniouses.. That when you're a business and you have more work than you can handle on time, you HAVE to hire people.. And you can't afford a $120K/yr salary (and even if you did, you couldn't be sure that someone deserved that salary). What can you do? The answer is to adopt good management skills.
When you have good management, you can work with less skilled/qualified workers and still produce high quality code. Management involves the choice of tools that facilitate good quality end products. It involes a series of other things that don't relate to the topic at hand, so I'll stop here.
The end result for this discussion is that screw the argument that a "good" programmer could write in C++ as well as a crappy programmer in VB or Java.. Guess what.. As a manager, I'd hire the crappy one and throw VB at him. I'd save more money that way and get the project done quicker.
Though thankfully I'm not a manager.. I just write Java.
Java and C/C++ are platform independent languages. But Java isn't == C/C++. You'd have to say Java/Swing/jboss == C++/KDE or C/GNOME
Then you find that C++/KDE and C/GNOME are NOT cross-platform. Or at least, supported on very few platforms.
We're not in CISC lab anymore, so we don't write little hello world apps that don't need a UI. When you write a C++ these days, you're talking about the full enchilada.. The end-to-end app.. And I'm not aware of non-geek tools that dont' require something more than a CLI. And I know of very few UI's that are cross-platform.
THIS is where Java excels. Of course due to market conditions, Java hasn't taken off in this areana.. The horrific HTML + CSS + javascript world has taken Java's place here... But we're back to the early 80's days of C where you couldn't recompile the same app on a different platform (e.g. I.E. only or firefox only apps).
Did you seriously miss the irony of what you just said?
How dare programmers make me.. umm.. what's the word? "Upgrade" my hardware?
So memory is a religious point of conservation, but you're probably pissed that you can't afford that new 4000+ AMD-64x2????????? w.t.f?
What's the difference between needing more memory and more CPU speed?
People use to write in assembly inside of 64KB of RAM through a serial bus on 8bit processors.. They had to emulate real numbers for god's sake. We could still be doing this if we actually cared about keeping the consumers from having to upgrade their hardware.
The fact of the matter is that the cost of hardware is nothing compared to the cost of programming time.
And these days the biggest problem w/ programs are BUGS. So anything that reduces the amount of bugs is a GOOD thing for consumers. And if that means using a different programming language (like perl, python, java or C#) which doesn't produce core dumps or memory leaks (well, some better than others'), then hey, that's what the industry has learned.. The fact that you don't recognize the value of platform v.s. your existing platform doesn't mean that's going to disuade the developers.. They're using their language of choice for a reason.. Either they are super-proficient in their platform of choice and are able to regularly produce reliable code, OR they recognize that they have to outsource a lot of their work and they don't trust the quality of their hiries or they know that the level of complexity is going to overwhelm the managearial process. The result in all cases is the a appropriate platform is chosen given the current demographics of hardware.
So the reason you see 300Meg memory frames in IDE's like "idea" is because people that are willing to shell out $700 like myself for some software are willing to shell out a whoping $70 for the memory to run it. People that make little task-bar icons KNOW the demographic of their end user, so they don't create a tool that will consume 60Meg just to let them configure their graphics card.
I want my computer to respond as fast as possible every time and there is no comparison.
So it's a good thing you don't write web applications then. As this philosphy requires either using something like inetd to efficiently delegate web requests to your propiretary web servers, or using a thin shell script which does nothing but invoke OS applications like "sort" and "grep". Welcome to 1993.
The response time of a java application (w/ NIO support) is as fast as ANY c application (using UNIX select). Because the two applications are binarily equivalent. They both perform the same operations under the hood; just w/ different arrangements of code.
The difference is that java is much easier to debug extend, and overlay than a c application. Yes, PHP, ASP, VBScript, Perl-Mason, etc are more easy to extend/deploy than a servlet. BUt JSP's are a middle-ground; you can attach a person's "public_html" directory to your tomcat instance and thus provide arbitrary JSP support in just a useable environment as a mod_perl directory.
I assume that most people are complaining about java applications that are launched by the client.. But there's a reason why java applets are almost dead (replaced by flash). That's because script-kiddie web programmers want press-button-build application environments.. We call them RAD prototypers, but to each his/her own. Since Flash is easier to create, and prettier out of the box, flash overtook java.. But I don't hear ANYONE complaining about flash in this thread. Have you seen the load time of a flash app recently? It definitely isn't the bandwidth latency.
We accept this unreasonable load-time of flash because we think of it differently than say notepad or "vi". And that's precisely the point. We interact with these tools in a different way. Slowly desktop applications are being replaced by online services. Will the transfer be complete? Doubtful; not unless viruses have their way.
The irony is that the fastest growing application environment right now is javascript (e.g. AJAX). We've turned full circle back to the days GWBasic being the coolest thing on TV (think back to Richard Prior in Superman 3).
Don't forget he's talking about java 1.4 and you're talking about java 1.5. One of the design features of 1.5 was to have the startup process pre-JIT'd specific to a target platform; though SUN only supports like 10 environments including Linux x86-32, Linux x86-64, windows and solaris.
So running a hello-world app is pretty darn fast in 1.5. But this doesn't do boo for a tomcat loading of 20 different app-contexts, each with 5 different explicitly defined servlets. And yeah, like you said, stock tomcat comes w/ like 6 application contexts including webdav and examples. My sys-admin never seems to remove them, so there's like a second or two of my startup time wasted.
Ugh, that's one of the things I don't miss from C++.
Look at java's "toString" function.. It's identical in inception to a 1'st class operator.. Something defined for all objects and can be overloaded. But Java documentation says NEVER USE THIS FOR PRODUCTION CODE. In other words, it's intended for debugging purposes.. Though "stringBuffer.toString()" does use this as it's main purpose, but that's forgivable since it's obvious that it's it's sole purpose.
Java could have had operator overloading if they merely implemented in the Object class something called:
Those are the overloadables that I remember from c++ at any rate.
So I ask you. Why didn't they put them into the Object class? You could easily create a base interface for all your worker objects.
interface Mathable { E add(E); E sub(E);... }
Then you'd have identical functionality to operator overloading (except for 3'rd party libraries, but you could easily use bytecode enhancement even there).
So why don't we do this?
What the hell does "Object result = myInputStream.add(myGraphicalWidget);" produce?
It doesn't make any bloody sense? And that's the point. It makes sense to add NUMBERS, but not generic widgets. If it DOES make sense to add something to an object (being mutable) or to combine two objects and return a 3'rd (being immutable), then great.. Put them together accordingly.
And guess what:
Integer i = 5; Double d = 7.0; Long l = d % i; Works just fine in java 5, thank you very much.
Otherwise, I'll keep my readibility of java over the following:/**
* comment, I don't remember what this does, but isn't it cool?
* I'm using operator overloading for no good reason
*/ void foo(BusinessObject1 bo1, BusinessObject2 bo2) {
return bo1 + bo2[bo1(0)]; }
Perl doesn't use any bytecode at call. Perl executes scripts simply by 'walking' the syntax tree its yacc parser has built. Just like (n)awk or gawk (and unlike mawk).
I've looked at both the JVM environment and the perl environment internals, and I have to dissagree.
Java compiles to a stack-machine 1 byte op-code interlaced w/ 0 or more bytes of opt-code arguments. The op codes refer implictly or explicitly to an external set of local-variables or to an evaluation stack in an interesting combination of load-store and stack execution, utilizing some of the more interesting aspects of RISC.
Perl compiles down to an AST-tree, where each node has a custom set of associated data-structures; generated directly from the compilation.
Perl makes an attempt to run through the AST tree to optimize it, replacing "for my $x (0.. 10)" with a c-style optimized "for (int x = 0; x = 10; x++)" as an example. Perl also removes redundant or unreachable code.
Since function calls are symbolicly invoked, it's easy at run-time to replace (even temporarily) one AST sub-tree with another.. And the "eval" statement facilitates this.
The fact that the JVM runs machine instructions which on most platforms has to be emulated isn't much different than the fact that the AST nodes are very similar to machine instructions.
The big difference of course is that parrot instuctions (perl 6), python instructions, and java instructions are directly serializable, while perl 5 instructions are not. The perl5 distillers that I have seen create c-code which re-initializes the AST tree from a set of constants.
But this is a mere oversite on perl5's part; mainly because it was rarely ever desired. I don't think that the fact that an instruction stream is directly serializable is what makes it byte-code or not.. Perl AST nodes have unique identifiers (the op-codes), and executing one op-code directly returns a pointer to the next node in the true. Parrot is very similar; the "byte code" node returns an offset of the instruction-stream to the beginning of the next byte-code (since there are variable number of args per instruction).
But the key is that perl is NOT like TCL which does not even maintain an AST; instead it takes as an argument to a block the raw text. It then compiles that text to determine what the block does... Thus in a for loop, you recompile the body block each and every time. It's been a while since I've played w/ TCL, but I believe this allowed it to do some interesting tricks thanks to this highly dynamic execution environment. I think you could pass text as an argument to a function and it would run as code (but I'm too fuzy at this point). In perl, you either explictly pass a function pointer, or you explicitly call "eval". In java you have to have a standardized interface, so you can't pass arbitrary code around (though some nasty reflection mechnisms will look for the first function in a object's definition and invoke it; I've seen this in webwork).
So if you want to play symantics, then no perl isn't byte-coded.. But what I think is more intersting is what the performance is like. And perl beats java's regular expression package, hands down.. Because there is a single op-code in perl to handle this (via a native optimized c-function) v.s. java running the entire re in bytecode land. Though java can do simple arithmetic significantly faster than perl. And the wheel goes round.
No cell phone games written in Java do this. I can quite confidently state this, as Sun says it will take more than that just for the JRE. See any number of other comments around this post. Go read teh J2ME docs.
Except that J2ME is already loaded in many/most cell phones / PDAs. The space a game takes up is only as large as the game library and it's associate heap.. And most cell phone libraries make HEAVY use of cell-phone specific libraries. Most of your graphics, event handling, and persistance are mere function calls away. Thus, if all you are writing is a checkbook program.. You're talking about maybe 5 files compressed in a zip-format (and unzipped temporarily to convert it into whatever native format the cell phone hardware uses. Everything else is already accounted for in the cell phone's OS (which may or may not be Java itself).
What you guys aren't understanding about Java is that it doesn't work the same way as c programs.. The closest comparison you could make would be CORBA, DCOM or RPC based applications where you don't deal w/ directly loading the libraries for code. Even if you're invoking a constructor directly in Java, you have no garuntee that it's even executing in your local memory model (thanks to aspect-oriented code an runtime bytecode enhansers). The actual Java could could have been swapped out and replaced w/ a JNI native "C" function call by the cell phone manufacturer. This is only possible because the only linkage between java classes are the symbolic names. W/in the same running JVM you can have segregated namespaces (by way of class-loaders), so you could have java.lang.String have 5 different implementations all in the same executing memory frame. This is how tomcat and jboss work. Each application context has a separate class-loader, so you can have different versions of the same named libraries kept seperately.. Thus you can have 10 different applications all running under the same executable, each w/ completely different sets of library dependencies. As the system administrator, you can choose to move common libraries together so you don't redundantly load libraries into memory (but you have to be sure that there is only one version needed by applications).
This is somewhat similar to.so libraries in UNIX or.dll in windows. But the point is that the amount of memory consumed by a "c" application and the amount consumed by a java applications are not directly related. Ignoring the fact that JVM's themselves use.so libraries to operate, java is really designed to be a monolithic operating system.
So no, JVM's don't work well below 32KB of RAM or ROM. But neither does windows or even Linux for that matter. But memory is cheap. What's the excuse for not having 16Meg of RAM available to an embedded device anymore? I'm sure there are reason's, but it certainly isn't money.
GC is a memory leak. refcounting is the only non-leaky way to automatically free unused memory, and refcounting is really, really *hard* to do right without GC.
I'm slightly confused.. You sound like you know what you're talking about, but I feel this statement can be misleading to the uninformed.. ref-counting does NOT resolve memory leaks at all.. In fact it has a horrible memory leak built into it's design.. Namely self-referencing.
a = new A b = new B a.child = b b.parent = a a = null b = null
You'll never reclaim neither a nor b.
Linked lists, trees, XML representations, etc. None of these are efficiently handled in Perl.. You have to perform explicit object destruction in perl (i.e. setting all refs to undef) which takes a LOT of overhead (you not have an interpreted garbage collector).
So the problem w/ ref-counting is two fold:
1'st as in the above, you suddenly have to be VERY conscious of the data structures you use, and more importantly inadvertant circular references.. Perl gets around this by making HEAVY use of symbolic references (those which don't affect the ref-counts). But this is very error prone.
2'nd the mere process of assinging "a = c" in a behind-the-scenes ref-counting scheme can take over a second to complete. Why? Because if "a" was the only pointer to a deep tree of data nodes, then you have to physically perform a gc desctructor on each instance... BUT, you can't do them in a batch, because you don't yet know that the child nodes are about to be freed.. You have several round trips into the garbage collector.
Compare issue 2 w/ a copying collector.. "a=c" will never cause a GC.. Depending on the GC implementation, it may still trigger a cleanup, but it will only be to get a stale reference of "b" from "a" to now point to null. Moreoever once you've orphaned the entire tree of nodes originated from "a" you perform zero work in "freeing" them.. You get free's for free (except when you explicitly delcare a finalizer; and even that can be completely ignored by the JVM).
The main problem w/ copying GCs are that periodically you'll have to touch every allocation in your heap. This is very cache unfriendly, and very swapped-memory destructive.. It's painful to watch two competing JVM's that have each taxed more than 50% of system memory bring the machine to a state of uselessness (thanks to competing garbage collection).
Alternatively incremental "train" mark-and-sweep collectors have to do almost as much work to free up objects as ref-counting (though they don't do it at the reference assignment; they do it at the malloc stage). Though mark-and-sweep can optimize the process by potentially using aggregated bit vectors instead of dispersed bits on each object scattered throughout the heap. Don't know which SUN's low-latency collector uses.
Or has incremental collection on the heap become as fast as malloc/free?
Sun's JVM is rather nice w/ incremental collections (called low-latency GC). It definitely has an overall performance penalty w.r.t. the stop-the-world copying-collector, but if you have multiple CPU's then the bulk of the work can occur in parallel, with only a small portion actually stopping the world.
Even if you don't have parallel CPU's if you can properly schedule the GC thread to run only when the CPU load is low (or memory is getting full), it can take advantage of pauses in work-load.
Theoretically you have to spend 5 30% of your time in memory management no matter what architecture you use. Thus you need that overhead in CPU performance anyway.. Thus a background GC running on a single CPU should still not degrade performance below the performance requirement of the application. It's just a minor added cost when there's no second CPU to offload work to.
That being said, you never GC until you've used up your free-allocation stack in Java.. Thus if you are worried about real-time, then it's entirely like that your main work-flow will not be allocating and deallocating large amounts of material mid work-flow. Instead of constructing a new StringBuffer, you can reuse a thread-local StringBuffer and call sb.setSize(0) or some such thing.. I've seen this done in JDBC drivers. I rarely see GC times in excess of 0.01 seconds (except when the entire system is heavily loaded and normal response time already exceeds a second).
Granted, you have no control over how 3'rd party libraries (including the standard SUN libraries) handle memory allocation; though I'm sure J2ME is more sensitive to overt allocation.
ONLY THE FIRST TIME A PERSON CLICKS THE LINK Hehe.. You mean you don't have ant/maven pre-compile your JSP's? Or don't have servlets load-on-startup?
Prior to convinient precompilation scripts I'd use a jython recorded script to hit all of my web pages in succession after each servlet restart.
Granted, it takes me something like 10 seconds on a quad-processor to get tomcat up and running w/ spring, hibernate, etc. But the cool thing is that w/ clustering, I can firewall off one worker-node while I'm upgrading it; leaving another node running the old version. Course that only works if there are backwardly compatible DB changes (e.g. adding a new nullable column).
Even w/ a heavily loaded, highly generalized (multiple layers of generic filtering w/ database accessees, XSLT transforms) system I easily achieve 30 100 pages / second on a modern single core machine. And guess what, it's trivial to have a J2EE app cluster to a dozen or more machines; thereby almost linearly scaling. W/ the performance scaling you also get fail-over (assuming your DB and firewall don't die).
It is very hard to write enterprise level applications in C or even perl/PHP that can cluster across multiple machines. There are enterprise-level concurrency considerations that are non trivial to solve, but are standard practice in J2EE environments... Yes there are enterprise libraries in perl and C, but most perl and C programmers don't know about them (I'm only aware of a few; and most of the time I keep my C/Perl apps stateless and non-transactional).
So, now in comparison, your multi-second page load somehow seems out of sync w/ my 1/30th second page load.
haha.. I assume you're referring to GNORBA (the core of the GNOME task bar). Well, Gnorba came more from CORBA than COM/DCOM. And CORBA/DCOM were just Object Oriented reworks of RPC (which is how old?). The only thing that made COM great is that Business school junkies could whip out a VB-app that used COM. Not nearly as easy to make a CORBA or RPC application.
The "task bar" isn't really new w/ 95, though it might not have been pieced together in exactly the same way. Mac had a task bar for ages, though it was on top and didn't show all the tasks at the same time.
The "start button" was innovative I guess. It was great for absolute beginners. But the only reason it's innovative is because you are verbally directed to do something. The gnome equivalent absolutely does not copy this, as it's only one of about a dozen icons on the screen. A newbie that had never worked w/ win95 would not have any greater inclination that this is where to "start" than if the start button wasn't there at all. I'm sure the "Start" wording is patented in some fashion or another which is why we have the foot-print instead in GNOME. Or maybe it's simply too repulsive to so blatently copy the win95 UI.
But having items accessible from Menus is by no means created initiated in win95. Right-click on X-windows desktop has always presented the same capabilities as a "start" menu.
My understanding of GUI development (and we have to only be talking about GUI, not actual technology as MS is only barely able to keep up w/ the rest of the world technology wise) is difficult to master. It's easy to put information out there, but you need end-user psychology to make it work well for large cross-sections of people. Standardization is critical for cross-platform adoption, so I'm sure Gnome and KDE were very interested in minimizing the UI-shock of X-Windows to current windows/MAC users, and that's why there aren't any drastic differences in the default layout of these platforms.
So that my comments on the lack of technological progress inside of windows isn't considered baseless.. The security model, the driver model, the inter-machine networking model, the multi-user-per-machine model, the configuration-model, the backup model, error-reporting model, the inter-process model (specifically COM/DCOM) are CRAP in windows. They've ALWAYS been behind the technology curve.
The NTFS file-system was good when it came out, so I'll give them credit there. Their office applications have suited most people's needs (except for interpolibility w/ 3'rd party tools which EVERY UNIX application does exceptionally well in comparison). The games on windows are so-so compared to the user-experience of console gameing platforms.. A fact that MS is recognizing in their migration to X-Box. The only advantage PC-games still have is a more advanced UI and the ability to network w/o repurchasing the software.. But within a few years, these advantages will be gone as HDTV will become the standard display and all games will be pay-per-play (or periodic subscription); keyboard will be missed.
But MS didn't invent anything in NTFS, all the features were taken from existing competing platforms. And MS made very few games; they merely applied the console model of standardized API to the PC (again not invention, but duplication).
So when it's all said and done, the only thing I can credit them for is Office. But once again, just about every aspect of office has existed in one form or another in other places.. change-tracking == version-control. spell-checker (try aspell, ispell, etc). Grammer checker.. Ok maybe, don't know the history here. Spread-sheet? Definitely not. Annoying paper-click? Yeah, I'll let them have that one (it actually is useful to certain demograhics I'm sure).
I don't mean to MS bash here.. They are a great company, in that they focus one what drives revenue. And that's user-interest.. Office is the most important thing to most people [with money]. But
Don't blame it on dogma, blame it on human nature.
I hate the phrase "Human nature". It's nature period. Dogs and even roaches have the same tactics that we commonly deamonize in our war-mongering leaders.
If anything the only distinctly human elements are those that require at least 2 orders of abstraction. Namely the concepts of civil disobediance and "turning the other cheeck". This constitutes a direct passive aggressive response to an aggressive act. It's very hard to do, and the motiviations required to accomplish it are too complex for a 1'st order thinking creature like a dog. I'm defining 0'th order being directly stimulus reflexive, 1'st order being memory-based-pattern stimulus induced reaction. 2'nd order being able to apply memorized patterns to new contexts as a response. (The concept of abstraction)
Very little in our daily lives require 2'nd order thinking. Most of it, in fact is mere directly learned association (1'st order thinking), so we're not that much higher evolved than the animal kingdom.
I completely agree w/ the economic synopsis you give. I'll just add my small bit of extra info.
My wife is Armenian, and her countrymen claim [at least partial] responsibility for the fall of the CCCP. Basically the satelite states were in financial distress, and receiving less and less prioritized resources from the Kremlin. Armenia and a few other Soviet blocks were land-locked. The CCCP made use of distributated manufacturing. When building a widget, each member state was responsible for making some part of the widget; thereby forcing inter-reliance. But when some member states had feuds (like the Chrisitian Armenia v.s. the Muslim Azerbaijan), the central government didn't have the time nor the resources to reconcile the differences.
There was a massive Earth Quake in Armenia in the late 80's, and Gorbachev made a token visit (much like Bush to La). But no money or resources accompanied the visit.
Poor states, just like poor people, tend to fight more. So many of the states became more nationalistic and less supportive of the CCCP. As if California said f*u to Bush's Federal Gov and succeeded.
West Germany went through some very bizzar political changes. A governor accidently made a public statement providing extra freedoms to the locals, and there was fear amongst the local and central commands as to what would happen if those freedoms were revoked. Gorbachev later made a public statement supporting the East German changes, thereby facilitating the fall of the Berlin wall.
Poland had been slowly having their own set of political changes in the late 80's, also as a result of Gorbachev's reluctant approval.
The common denominator of these 3 states was an absent-handed Gorbachev. He could very well have come down like a Stalin or even Breshnev. I'm not quite sure of the reasonings, but it seemed to be Russian policy to be Russia-first, and screw the member states. Most likely the cost-over-runs were too much to manage by the 80s, and the "buffer states" were of decreasing value; they certainly didn't have any natural resources. It was only a matter of time before that policy collapsed the CCCP.
Our new weapons are percise GPS guided small tactical missles.
The problem is two fold:
1) A weapon used is a useless weapon. If you have to use a weapon, it obvously is not a strong enough deterrent to a war.
2) Targeted weapon systems rely on continuous communication back to home base. Yes there are backup systems (such as geographical pattern matching), but this is only on a subset of arsonal, and these systems are less reliable and easier to fool.
While a terrorist group isn't a major strategic threat outside of their home environment, there are still rogue nations, most of which are within grasp of the power to knock out our GPS satellites one way or another.
Once you knock out our eyes, then conventional warfare makes us no better suited than the 1950s (simple jammable radio-based communication).
The key to being a super-power is a credible threat. A death-star, or a ready-to-string special forces that can take out any town over night.
The more we bumble about w/ these wimpy targeted missiles that demonstrate what we are likely to use against rogue nations, they are better able to assess our weaknesses and weigh in the liklihood of successful resistance against us.
#1: $50 vs downloading the latest open source distro- gee, which do you think is cheaper?
Others' have addressed this. TCO isn't the purchase price.
#5 the commie bashing MicroSoft- probably has something to do with the fact that their CEO is paid very highly, and if minimum wage had risen the way CEO wages had in the United States in the last 20 years, the minimum wage would be $23.20/hr.
This is actually incorrect.. If min. wage grew at the same rate as CEOs then their salary would actually stay exactly the same, while CEO's would continue to have their massive rates of increase. It's economics and is why pure communism never existed and those varients that are still around are slowly becoming capitalistic.
The reason is that whatever political affiliation you have, there are certain laws of the universe that can't be changed.. You can't create or destroy matter, only move it around. Likewise, you can't create or destroy scarce resources; merely be less wasteful in the allocation of it.
50 years ago, people generally considered communism to be superior to capitalism in terms of efficient public welfare allocation. The problem is that the cost of information is too high. A government agency (assuming it is perfectly benevolent, which is another failing of communism) can not know who best to allocate scarce resources to. The US and other countries use graduated/targeted taxation, so that supply/demand is still in place, but the burden of public services falls more onto the sholders of those that are least troubled by it.
So how "much" someone makes is almost completely irrelevant because the dollar is a useless commodity except for purchases.. (fiat money)
So lets say we had a sudden increase in the min wage. Well, 1'st, the shock would be such that almost nobody would be willing or able to afford paying higher than min wage.. So you'd have 3 classes of people.. Min-wage, rich, and the scant few who are in between. (shifting from a diamond shaped economy to a pyramid)
As a result, every scarse resource is now equally available to everybody (except the few people above min wage). So for a short while, we're in communism.. Everybody wants the best doctor in town, everybody wants the house on the hill.. Everybody wants the red car. So commodities that are desirable to us are suddently as innaccessible as the lottery.
Think of a parking lot.. Everybody wants the spot closest to the door. It's 1'st come first serve by shere physics (The only exception being the segregated handicap population). Most people that have driven me around waste a lot of time searching for the closest possible spot.. They then fight over it.. One friend of mine is very aggressive and has almost gotten into accidents, just to assert himself as dominant so as to get the coveted spot. Then there are those w/ other priorities.. People w/ shiny cars that don't want to be scratched.. They park very far away. But this category is as rare as the wealthy population itself. Finally there are a few like me that recognize that on average you spend more time searching for a spot than a the fair amount of healthy excercize would take. So I take a 1'st spot seen approach.
Likewise in this brief period of consolidated purchasing-power equality, most people will be fighting for their newly acquirable scarce commodities. And violence will erupt.. We'll blame our politicians because we're too spoiled to be willing to accept personal responsibility for the hell we're causing ourselves.
Then a funny thing will happen. We will achieve equalization.. When the shock has run it's course, scarce items will have adjusted prices (just like oil is doing). The non-scarce items will have higher operating costs (higher wages, higher cost of scarce items required for manufacturing/processing).
Then we'll see the self-interest factor. If an individual sees that they're unlikely to get a pay-raise, they're less motivated to work harder.. We tell people "you don't want
"stored procedures" implies a user-defined/custom. What we're discussing are deviations from standards-based SQL features.. Things that can be abstracted by middle-tier systems such as ruby, java's hibernate, etc. The standardized SQL is layered with a standardized middle-tier (which builds apon the standard and accounts for minor variations by different vendors). Then you have a layer of pure logic, independent of performance or mangled by the particulars of a language... You can choose the language that best suites the problem-space; beit mathmatical, logical (prolog, or forward-chained), heirarchical (XML-based constructed logic), etc.
The key is to have as little an impeedence mismatch between the problem and the solution as possible.. The DB is used here as a tool, no more or less impressive than the "prolog" language.
When them problem is solved elegantly, you then revisit performance issues, weighing the cost of higher-end equipment to that of maintainance time spent optimizing the hell out of some piece of code.
A system designed to scale to a billion rows of data often will not perform quickly on only a couple thousand rows.
With the above system-engineering philosophy in mind, the "triggers" are hidden mechanisms to apply the standards. The "indexes" are hidden mechnaims to performance tune. The "user-defined" types are necessarly hidden from the problem space (in OR-mapping tools, literally indistinguishable from simple rectangles from primitives), the constrants are hidden situations which become occasional SQL-error-condition until the system is fully debugged, never-again thereafter to be actuated.
So while these mechanisms are important from a theoretical and a layer-of-protection stand-point, they are irrelevant from the black-box tool stand-point.
You forgot to mention security boundaries between tiers. I hate dealing with these moron dev who try to implement all their data logic in the business logic layer.
I worked in database-design around the transition from thick-client to web-based design. The most interesting thing for me was the futility of the "db-login-user". Previously there were advanced heirarchies of access permissions. DBA's monitored who was logged in to the DB, how much CPU time they were consuming, how much memory etc.. Then all of a sudden, we were designing monolothic sign-on users called "webguy". There'd be dozens of simultaneous connections performing roughly the same tasks. We had to scratch our heads to determine how our "50 licenses" would work with this single login user fullfulling the needs of 150 employees.
Classicly, you only give the read or write access to the tables that the application needs.. That's all fine and good. But a given application-tier performs 95% of what a user could require do.
SQL injection is going to affect everything that makes the application functional. The only thing DB-ACL provides is isolation between applications.. And if you're sys-admin has a common login for all your applications, you have other problems.
If you have other processes connecting straight to the database and changing data directly, you have serious issues.
Forget separate processes.. Think multiple threads.. e.g. concurrency. While it is the "job" of the application to test-first, update-later, and synchronize all along the way, the fact of life is that bugs live inside our code, and when we miss a concurrency test somewhere, and then one day you're happily making a purchase order and wamo, a race-condition has corrupted your data....
While I agree with the general thread that applications should be responsible for work-flow and should enforce business-rules, the particular example was a bad one because it represents a trivial constraint. Moreover, if it is a fundamental business rule, the data can be structured in such a way as to re-inforce it.
e.g.
instead of:
item (id int pk, name varchar, num_in_stock int) purchase_order (id int pk, item_id int references item(id))
you could have:
item_type (id int pk, name varchar)
item (id int pk, item_type_id int references item_type(id)) purchase_request (id int pk, item_id int references item(id) unique)
Or even better
item_type... purchase_request (id int pk, sale_date datetime) item(id int pk, item_type_id int refs item_type(id), purchase_request_id int refs p_r(id))
I often structure my data to represent their associativity. It isn't difficult to migrate the data if that business rule changes (1:1 v.s. 1:n v.s. m:n).
Now if you have a more complex example (must have entity A only when there are at least 5 entity B's AND and an entity C), then it's up to you whether that lives in semi-custom "constraint" logic or in the application-layer.
I think one of the problems here is how you actually define a dimension.
It's a linear algebra thing. A vector-space can be thought of as a universal coordinate system with n-dimensions.. A multi-dimensional array in programming languages represents a multi-variet coordinate system. The letter, v.s. the word, v.s. the sentense, v.s. the paragraph. v.s. the page v.s. the chapter are also all legitimate dimensions in such a defined vector-space. But many vector-spaces can be translated into other vector spaces.
For example, a multi-dimensional array is always flattened out to a 1 dimensional index into a memory-space (e.g. the offset from the beginning of memory starting at address 0). The coordinate for the letter can be represented by either the "n'th letter in a document" or a 3D geometric coordinate into a stack of paper.
We usually use mathmetical transformations to relate one vector space to another. Though sometimes there isn't a simple uniform transformation (such as the n'th letter v.s. the 3D geometric coordinates into a page).
Even in geometric vector spaces, we have many representations.. Rectangular is best known. Go one block forward, two blocks to the right, and go up 5 stories; or a relative coordinate of (1,2,5). Spherical is often more useful in quantum physics. Outward of a radius of 2 nano-meters, down 30 degrees from top-dead-center, and rotated 90 degrees (2nm, 30deg, 90deg). Of course the frame of reference is just as important with rectangular and spherical.
rectangular, cylindrical, and spherical are all I've ever directly worked with, but there are many more useful coordinate systems and thereby vector spaces.
Another concept in linear algebra that might help here is the concept of linear-independence. Since you can define an arbitrary vector-space (such as the (letter,word,sentence,paragraph, page, chapter) coordinate system. It's possible that there is a high degree of redundance. It can often be mathmaticlly proved that a vector space has linear dependence between two of the dimensions.. Such as (letter,odd-words, even-words, sentense, paragraph). odd-words, and even-words would be directly related to each other. And thus the dimensionality would of this vector-space would have to be reduced by 1. It is sometimes still useful to maintain the redundance.. Especially if you're regularly asking questions where that dimension would answer w/o further calculation. But the true dimensionality of the vector-space is less.
We call a "basis" a fundamental mathmatical description of a vector space which is linearly independent between it's dimensions (and also has demension descriptors with effective length 1). It can't be optimized any further for a given descript of a vector-space.
So if the question is whether left-right, up-down, forward-backward, and time represents 4 dimensions.. The answer is absolutely "yes". Just like (letter,odd-word,even-word,sentense,paragraph) is a 5D system. or: int[5][5][5] 3darray; is a 3D system.
But whether (x,y,z,t) is a 4D basis is really the interesting question.. And for string-theory and this dark-matter theory, whether 6D, 11D, or 26D basis's exist is key.
So you can define basis vector-spaces however you want.. So long as you can truely represent a useful coordinate system, and you don't have any redundancy in the definition.
Here is another useful artifact of interchangeable vector-spaces. Something I picked out of Brian Greens' "Elegant Universe". Often a particular theoretical geometric configuration of the universe would provide for anomolies (divide-by-zero, or infinite) results when constructing potential cosmological situations. But when you use a different gemoetric configuration (a different vector-space) the anomoly no longer exists, in fact, you see a continuous progression from sample-point 1 to sample-point2.
Take for example rectangular v.s. spherical coordinates. W/ spherical you have a length and 2 directions (radius of a ba
I don't care about depth.. Weight is a non-trivial issue for me.. I move often enough that the one-time cost and danger of moving a multi-thousand dollar piece of equipment is worrisome. A 30" CRT therefore worries, me, but a 40" LCD I can lift single-handidly.
Additionally, I don't know about why other people buy LCD's (looks perhaps?), but I get it for the lack of flicker.. Why else haven't we fully migrated to flourescet lighting.. It's smaller, lasts longer, brighter, cheaper... Because it gives me head-aches. You can sit inches away from an LCD screen, but not in front of a CRT.. Moreoever, the flicker most dramatically affects your side viewing angle... More and more people are getting dual monitors; even if nothing more than to hook a bigger screen up to their laptop.. When you look away from the CRT, the corner of your eye will pick up the flicker. Upping the refresh rate helps, but it is still a factor in your general health.
LCDs have no flicker. Though, ironically, they're often powered by something akin to flourescent lighting.
The flicker was also one of my main reasons for not going w/ plasma for an HDTV. If you're close enough, you can definitively see the flicker. Due to my migraines, I didn't want to spend big money on something that would still produce the same pain from watching for several hours at a time as my CRT.
DLP has a similar flashing effect (except w/ certain higher priced models w/ tri-guns).
I think ideally I'd like an LED display. I don't know anythin about the SED that you speak of.
brightness and quickness of response have always been a positive of plasma.. But I always thought it wierd to put a plasma on a laptop, because plasma generally requires higher power drain than LCD. That plus plamas are generally heavier.
Moroever, the viewing angle, brightness levels/control and refresh rates of LCD has caught up, and even in many respects outdone plasma these days.. There is simply too much momentum in the LCD market. I'm sure if similar levels of research were pushed into the plasma market, they could catch back up to LCD, but LCD has the advantage of being used in the high volume PC market, where the same break-throughs on 17" screens can be applied to 60" screens. Plasma simply can't get much smaller than 32" - at least not w/o serious resolution sacrifice. I'm sitting on a laptop made 3 years ago w/ a 16" display and 1600x1200 resolution. This is physically impossible w/ plasma today. Thus plasma are low volume units. Now because of competition (especially w/ LCD), the plasma profit margin is being squeezed, which means even less available R&D.
If you were a company choosing what R&D money to spend, LCD or Plamsa, I don't know that you'd choose plasma anymore.
Slashdot Mirror
The advice I would give to new programmers is learn C++ and learn how to use proxies allocated in the stack frame, and learn how to determine object lifetime correctly. *Then* move on to Java and .NET and things like that. The greatest chefs all learned how to season their dishes, but once perfected, they just bung in a dollop of brown sauce.
I'd probably agree for anyone that I wanted to see become a good programmer. Though I've been very interested in getting my wife to do some simple programming.. And believe me, I have no interest in scaring her off by making her go through the entire drill routine.. In fact, I'd prefer if we had a billion bad programmers than only a couple thousand good ones.
If you have been involved in developmnent for any reasonable amount of time or worked on projects of reasonable size, you know that *good* programmers are hard to come by.
I'll come back to this.
If schools actually learned to produce good programmers, and HR departments learned how to identify them, and job interviews verified them, we wouldn't be having this discussion.
Ah.. there's the bullshit.. Right where I can find it.
Guess what.. I've tutored people in collage.. Their dumb as a brick, some of them... I can't see how the school could possibly turn people of the wrong mind-set into good programmers. The only possible way of reconsiling your two statements that I've outlined is to outsource almost ALL of our programming to Russia and China.. Two places w/ strong math carriculum (a core requirement of being a good programmer). Their sheer number of citizens subjected to painful degrees of mathmatics has a weeding-out process that leaves a large number of highly qualified logicians (a better name for a *good* programer).
That being said. Do you blame the consumer for not being able to program their VCR? Not if your the Venture capitalist. You identify a market where VCRs and Microwaves are not being properly used.. Likewise w/ digital walk-men.. The iPod is a testiment to the idiocy of Americana. It's "easy to use". Who gives a crap? The people that can't figure out complicated devices do.
What we want is a world of advancement.. Where people recognize the value of directed automation.. I want a consumer to be able to see the value in programatically configuring the lights in their house, the temperature of water, the TV schedule, etc. Then people will market to that techno-involved consumer.. Then they'll have economies of scale for the geek-toys that I'd love to have but aren't currently manufactured. We were shown all sorts of really cool stuff in the 60's that were never created, mostly because there was no market for them.
Back to the more specific topic at hand. GIVEN that programmers are not all geniouses.. That when you're a business and you have more work than you can handle on time, you HAVE to hire people.. And you can't afford a $120K/yr salary (and even if you did, you couldn't be sure that someone deserved that salary). What can you do? The answer is to adopt good management skills.
When you have good management, you can work with less skilled/qualified workers and still produce high quality code. Management involves the choice of tools that facilitate good quality end products. It involes a series of other things that don't relate to the topic at hand, so I'll stop here.
The end result for this discussion is that screw the argument that a "good" programmer could write in C++ as well as a crappy programmer in VB or Java.. Guess what.. As a manager, I'd hire the crappy one and throw VB at him. I'd save more money that way and get the project done quicker.
Though thankfully I'm not a manager.. I just write Java.
Not seeing how a card shuffling game is a good benchmark. Nor am I seeing how something that runs in less than a minute is a good benchmark.
That's like the classic "how fast can I copy memory" benchmark which isn't even a good memory benchmark or the adding two numbers a billion times.
minor nit-pick.
Java and C/C++ are platform independent languages.
But Java isn't == C/C++. You'd have to say
Java/Swing/jboss == C++/KDE or C/GNOME
Then you find that C++/KDE and C/GNOME are NOT cross-platform. Or at least, supported on very few platforms.
We're not in CISC lab anymore, so we don't write little hello world apps that don't need a UI. When you write a C++ these days, you're talking about the full enchilada.. The end-to-end app.. And I'm not aware of non-geek tools that dont' require something more than a CLI. And I know of very few UI's that are cross-platform.
THIS is where Java excels. Of course due to market conditions, Java hasn't taken off in this areana.. The horrific HTML + CSS + javascript world has taken Java's place here... But we're back to the early 80's days of C where you couldn't recompile the same app on a different platform (e.g. I.E. only or firefox only apps).
Holy shit you're funny.
Did you seriously miss the irony of what you just said?
How dare programmers make me.. umm.. what's the word? "Upgrade" my hardware?
So memory is a religious point of conservation, but you're probably pissed that you can't afford that new 4000+ AMD-64x2????????? w.t.f?
What's the difference between needing more memory and more CPU speed?
People use to write in assembly inside of 64KB of RAM through a serial bus on 8bit processors.. They had to emulate real numbers for god's sake. We could still be doing this if we actually cared about keeping the consumers from having to upgrade their hardware.
The fact of the matter is that the cost of hardware is nothing compared to the cost of programming time.
And these days the biggest problem w/ programs are BUGS. So anything that reduces the amount of bugs is a GOOD thing for consumers. And if that means using a different programming language (like perl, python, java or C#) which doesn't produce core dumps or memory leaks (well, some better than others'), then hey, that's what the industry has learned.. The fact that you don't recognize the value of platform v.s. your existing platform doesn't mean that's going to disuade the developers.. They're using their language of choice for a reason.. Either they are super-proficient in their platform of choice and are able to regularly produce reliable code, OR they recognize that they have to outsource a lot of their work and they don't trust the quality of their hiries or they know that the level of complexity is going to overwhelm the managearial process. The result in all cases is the a appropriate platform is chosen given the current demographics of hardware.
So the reason you see 300Meg memory frames in IDE's like "idea" is because people that are willing to shell out $700 like myself for some software are willing to shell out a whoping $70 for the memory to run it. People that make little task-bar icons KNOW the demographic of their end user, so they don't create a tool that will consume 60Meg just to let them configure their graphics card.
I want my computer to respond as fast as possible every time and there is no comparison.
So it's a good thing you don't write web applications then. As this philosphy requires either using something like inetd to efficiently delegate web requests to your propiretary web servers, or using a thin shell script which does nothing but invoke OS applications like "sort" and "grep". Welcome to 1993.
The response time of a java application (w/ NIO support) is as fast as ANY c application (using UNIX select). Because the two applications are binarily equivalent. They both perform the same operations under the hood; just w/ different arrangements of code.
The difference is that java is much easier to debug extend, and overlay than a c application. Yes, PHP, ASP, VBScript, Perl-Mason, etc are more easy to extend/deploy than a servlet. BUt JSP's are a middle-ground; you can attach a person's "public_html" directory to your tomcat instance and thus provide arbitrary JSP support in just a useable environment as a mod_perl directory.
I assume that most people are complaining about java applications that are launched by the client.. But there's a reason why java applets are almost dead (replaced by flash). That's because script-kiddie web programmers want press-button-build application environments.. We call them RAD prototypers, but to each his/her own. Since Flash is easier to create, and prettier out of the box, flash overtook java.. But I don't hear ANYONE complaining about flash in this thread. Have you seen the load time of a flash app recently? It definitely isn't the bandwidth latency.
We accept this unreasonable load-time of flash because we think of it differently than say notepad or "vi". And that's precisely the point. We interact with these tools in a different way. Slowly desktop applications are being replaced by online services. Will the transfer be complete? Doubtful; not unless viruses have their way.
The irony is that the fastest growing application environment right now is javascript (e.g. AJAX). We've turned full circle back to the days GWBasic being the coolest thing on TV (think back to Richard Prior in Superman 3).
Don't forget he's talking about java 1.4 and you're talking about java 1.5. One of the design features of 1.5 was to have the startup process pre-JIT'd specific to a target platform; though SUN only supports like 10 environments including Linux x86-32, Linux x86-64, windows and solaris.
So running a hello-world app is pretty darn fast in 1.5. But this doesn't do boo for a tomcat loading of 20 different app-contexts, each with 5 different explicitly defined servlets. And yeah, like you said, stock tomcat comes w/ like 6 application contexts including webdav and examples. My sys-admin never seems to remove them, so there's like a second or two of my startup time wasted.
(Operator Overloading being a prime example.)
... }
/**
Ugh, that's one of the things I don't miss from C++.
Look at java's "toString" function.. It's identical in inception to a 1'st class operator.. Something defined for all objects and can be overloaded. But Java documentation says NEVER USE THIS FOR PRODUCTION CODE. In other words, it's intended for debugging purposes.. Though "stringBuffer.toString()" does use this as it's main purpose, but that's forgivable since it's obvious that it's it's sole purpose.
Java could have had operator overloading if they merely implemented in the Object class something called:
Object.add(Object o);
likewise w/ sub, mul, div, mod, minus, index, invoke.
Those are the overloadables that I remember from c++ at any rate.
So I ask you. Why didn't they put them into the Object class? You could easily create a base interface for all your worker objects.
interface Mathable { E add(E); E sub(E);
Then you'd have identical functionality to operator overloading (except for 3'rd party libraries, but you could easily use bytecode enhancement even there).
So why don't we do this?
What the hell does "Object result = myInputStream.add(myGraphicalWidget);" produce?
It doesn't make any bloody sense? And that's the point. It makes sense to add NUMBERS, but not generic widgets. If it DOES make sense to add something to an object (being mutable) or to combine two objects and return a 3'rd (being immutable), then great.. Put them together accordingly.
And guess what:
Integer i = 5;
Double d = 7.0;
Long l = d % i;
Works just fine in java 5, thank you very much.
Otherwise, I'll keep my readibility of java over the following:
* comment, I don't remember what this does, but isn't it cool?
* I'm using operator overloading for no good reason
*/
void foo(BusinessObject1 bo1, BusinessObject2 bo2)
{
return bo1 + bo2[bo1(0)];
}
Perl doesn't use any bytecode at call. Perl executes scripts simply by 'walking' the syntax tree its yacc parser has built. Just like (n)awk or gawk (and unlike mawk).
.. 10)" with a c-style optimized "for (int x = 0; x = 10; x++)" as an example. Perl also removes redundant or unreachable code.
I've looked at both the JVM environment and the perl environment internals, and I have to dissagree.
Java compiles to a stack-machine 1 byte op-code interlaced w/ 0 or more bytes of opt-code arguments. The op codes refer implictly or explicitly to an external set of local-variables or to an evaluation stack in an interesting combination of load-store and stack execution, utilizing some of the more interesting aspects of RISC.
Perl compiles down to an AST-tree, where each node has a custom set of associated data-structures; generated directly from the compilation.
Perl makes an attempt to run through the AST tree to optimize it, replacing "for my $x (0
Since function calls are symbolicly invoked, it's easy at run-time to replace (even temporarily) one AST sub-tree with another.. And the "eval" statement facilitates this.
The fact that the JVM runs machine instructions which on most platforms has to be emulated isn't much different than the fact that the AST nodes are very similar to machine instructions.
The big difference of course is that parrot instuctions (perl 6), python instructions, and java instructions are directly serializable, while perl 5 instructions are not. The perl5 distillers that I have seen create c-code which re-initializes the AST tree from a set of constants.
But this is a mere oversite on perl5's part; mainly because it was rarely ever desired. I don't think that the fact that an instruction stream is directly serializable is what makes it byte-code or not.. Perl AST nodes have unique identifiers (the op-codes), and executing one op-code directly returns a pointer to the next node in the true. Parrot is very similar; the "byte code" node returns an offset of the instruction-stream to the beginning of the next byte-code (since there are variable number of args per instruction).
But the key is that perl is NOT like TCL which does not even maintain an AST; instead it takes as an argument to a block the raw text. It then compiles that text to determine what the block does... Thus in a for loop, you recompile the body block each and every time. It's been a while since I've played w/ TCL, but I believe this allowed it to do some interesting tricks thanks to this highly dynamic execution environment. I think you could pass text as an argument to a function and it would run as code (but I'm too fuzy at this point). In perl, you either explictly pass a function pointer, or you explicitly call "eval". In java you have to have a standardized interface, so you can't pass arbitrary code around (though some nasty reflection mechnisms will look for the first function in a object's definition and invoke it; I've seen this in webwork).
So if you want to play symantics, then no perl isn't byte-coded.. But what I think is more intersting is what the performance is like. And perl beats java's regular expression package, hands down.. Because there is a single op-code in perl to handle this (via a native optimized c-function) v.s. java running the entire re in bytecode land. Though java can do simple arithmetic significantly faster than perl. And the wheel goes round.
No cell phone games written in Java do this. I can quite confidently state this, as Sun says it will take more than that just for the JRE. See any number of other comments around this post. Go read teh J2ME docs.
.so libraries in UNIX or .dll in windows. But the point is that the amount of memory consumed by a "c" application and the amount consumed by a java applications are not directly related. Ignoring the fact that JVM's themselves use .so libraries to operate, java is really designed to be a monolithic operating system.
Except that J2ME is already loaded in many/most cell phones / PDAs. The space a game takes up is only as large as the game library and it's associate heap.. And most cell phone libraries make HEAVY use of cell-phone specific libraries. Most of your graphics, event handling, and persistance are mere function calls away. Thus, if all you are writing is a checkbook program.. You're talking about maybe 5 files compressed in a zip-format (and unzipped temporarily to convert it into whatever native format the cell phone hardware uses. Everything else is already accounted for in the cell phone's OS (which may or may not be Java itself).
What you guys aren't understanding about Java is that it doesn't work the same way as c programs.. The closest comparison you could make would be CORBA, DCOM or RPC based applications where you don't deal w/ directly loading the libraries for code. Even if you're invoking a constructor directly in Java, you have no garuntee that it's even executing in your local memory model (thanks to aspect-oriented code an runtime bytecode enhansers). The actual Java could could have been swapped out and replaced w/ a JNI native "C" function call by the cell phone manufacturer. This is only possible because the only linkage between java classes are the symbolic names. W/in the same running JVM you can have segregated namespaces (by way of class-loaders), so you could have java.lang.String have 5 different implementations all in the same executing memory frame. This is how tomcat and jboss work. Each application context has a separate class-loader, so you can have different versions of the same named libraries kept seperately.. Thus you can have 10 different applications all running under the same executable, each w/ completely different sets of library dependencies. As the system administrator, you can choose to move common libraries together so you don't redundantly load libraries into memory (but you have to be sure that there is only one version needed by applications).
This is somewhat similar to
So no, JVM's don't work well below 32KB of RAM or ROM. But neither does windows or even Linux for that matter. But memory is cheap. What's the excuse for not having 16Meg of RAM available to an embedded device anymore? I'm sure there are reason's, but it certainly isn't money.
GC is a memory leak. refcounting is the only non-leaky way to automatically free unused memory, and refcounting is really, really *hard* to do right without GC.
I'm slightly confused.. You sound like you know what you're talking about, but I feel this statement can be misleading to the uninformed.. ref-counting does NOT resolve memory leaks at all.. In fact it has a horrible memory leak built into it's design.. Namely self-referencing.
a = new A
b = new B
a.child = b
b.parent = a
a = null
b = null
You'll never reclaim neither a nor b.
Linked lists, trees, XML representations, etc. None of these are efficiently handled in Perl.. You have to perform explicit object destruction in perl (i.e. setting all refs to undef) which takes a LOT of overhead (you not have an interpreted garbage collector).
So the problem w/ ref-counting is two fold:
1'st as in the above, you suddenly have to be VERY conscious of the data structures you use, and more importantly inadvertant circular references.. Perl gets around this by making HEAVY use of symbolic references (those which don't affect the ref-counts). But this is very error prone.
2'nd the mere process of assinging "a = c" in a behind-the-scenes ref-counting scheme can take over a second to complete. Why? Because if "a" was the only pointer to a deep tree of data nodes, then you have to physically perform a gc desctructor on each instance... BUT, you can't do them in a batch, because you don't yet know that the child nodes are about to be freed.. You have several round trips into the garbage collector.
Compare issue 2 w/ a copying collector.. "a=c" will never cause a GC.. Depending on the GC implementation, it may still trigger a cleanup, but it will only be to get a stale reference of "b" from "a" to now point to null. Moreoever once you've orphaned the entire tree of nodes originated from "a" you perform zero work in "freeing" them.. You get free's for free (except when you explicitly delcare a finalizer; and even that can be completely ignored by the JVM).
The main problem w/ copying GCs are that periodically you'll have to touch every allocation in your heap. This is very cache unfriendly, and very swapped-memory destructive.. It's painful to watch two competing JVM's that have each taxed more than 50% of system memory bring the machine to a state of uselessness (thanks to competing garbage collection).
Alternatively incremental "train" mark-and-sweep collectors have to do almost as much work to free up objects as ref-counting (though they don't do it at the reference assignment; they do it at the malloc stage). Though mark-and-sweep can optimize the process by potentially using aggregated bit vectors instead of dispersed bits on each object scattered throughout the heap. Don't know which SUN's low-latency collector uses.
Or has incremental collection on the heap become as fast as malloc/free?
Sun's JVM is rather nice w/ incremental collections (called low-latency GC). It definitely has an overall performance penalty w.r.t. the stop-the-world copying-collector, but if you have multiple CPU's then the bulk of the work can occur in parallel, with only a small portion actually stopping the world.
Even if you don't have parallel CPU's if you can properly schedule the GC thread to run only when the CPU load is low (or memory is getting full), it can take advantage of pauses in work-load.
Theoretically you have to spend 5 30% of your time in memory management no matter what architecture you use. Thus you need that overhead in CPU performance anyway.. Thus a background GC running on a single CPU should still not degrade performance below the performance requirement of the application. It's just a minor added cost when there's no second CPU to offload work to.
That being said, you never GC until you've used up your free-allocation stack in Java.. Thus if you are worried about real-time, then it's entirely like that your main work-flow will not be allocating and deallocating large amounts of material mid work-flow. Instead of constructing a new StringBuffer, you can reuse a thread-local StringBuffer and call sb.setSize(0) or some such thing.. I've seen this done in JDBC drivers. I rarely see GC times in excess of 0.01 seconds (except when the entire system is heavily loaded and normal response time already exceeds a second).
Granted, you have no control over how 3'rd party libraries (including the standard SUN libraries) handle memory allocation; though I'm sure J2ME is more sensitive to overt allocation.
ONLY THE FIRST TIME A PERSON CLICKS THE LINK
Hehe.. You mean you don't have ant/maven pre-compile your JSP's? Or don't have servlets load-on-startup?
Prior to convinient precompilation scripts I'd use a jython recorded script to hit all of my web pages in succession after each servlet restart.
Granted, it takes me something like 10 seconds on a quad-processor to get tomcat up and running w/ spring, hibernate, etc. But the cool thing is that w/ clustering, I can firewall off one worker-node while I'm upgrading it; leaving another node running the old version. Course that only works if there are backwardly compatible DB changes (e.g. adding a new nullable column).
Even w/ a heavily loaded, highly generalized (multiple layers of generic filtering w/ database accessees, XSLT transforms) system I easily achieve 30 100 pages / second on a modern single core machine. And guess what, it's trivial to have a J2EE app cluster to a dozen or more machines; thereby almost linearly scaling. W/ the performance scaling you also get fail-over (assuming your DB and firewall don't die).
It is very hard to write enterprise level applications in C or even perl/PHP that can cluster across multiple machines. There are enterprise-level concurrency considerations that are non trivial to solve, but are standard practice in J2EE environments... Yes there are enterprise libraries in perl and C, but most perl and C programmers don't know about them (I'm only aware of a few; and most of the time I keep my C/Perl apps stateless and non-transactional).
So, now in comparison, your multi-second page load somehow seems out of sync w/ my 1/30th second page load.
Just look at GNOME.
haha.. I assume you're referring to GNORBA (the core of the GNOME task bar). Well, Gnorba came more from CORBA than COM/DCOM. And CORBA/DCOM were just Object Oriented reworks of RPC (which is how old?). The only thing that made COM great is that Business school junkies could whip out a VB-app that used COM. Not nearly as easy to make a CORBA or RPC application.
The "task bar" isn't really new w/ 95, though it might not have been pieced together in exactly the same way. Mac had a task bar for ages, though it was on top and didn't show all the tasks at the same time.
The "start button" was innovative I guess. It was great for absolute beginners. But the only reason it's innovative is because you are verbally directed to do something. The gnome equivalent absolutely does not copy this, as it's only one of about a dozen icons on the screen. A newbie that had never worked w/ win95 would not have any greater inclination that this is where to "start" than if the start button wasn't there at all. I'm sure the "Start" wording is patented in some fashion or another which is why we have the foot-print instead in GNOME. Or maybe it's simply too repulsive to so blatently copy the win95 UI.
But having items accessible from Menus is by no means created initiated in win95. Right-click on X-windows desktop has always presented the same capabilities as a "start" menu.
My understanding of GUI development (and we have to only be talking about GUI, not actual technology as MS is only barely able to keep up w/ the rest of the world technology wise) is difficult to master. It's easy to put information out there, but you need end-user psychology to make it work well for large cross-sections of people. Standardization is critical for cross-platform adoption, so I'm sure Gnome and KDE were very interested in minimizing the UI-shock of X-Windows to current windows/MAC users, and that's why there aren't any drastic differences in the default layout of these platforms.
So that my comments on the lack of technological progress inside of windows isn't considered baseless.. The security model, the driver model, the inter-machine networking model, the multi-user-per-machine model, the configuration-model, the backup model, error-reporting model, the inter-process model (specifically COM/DCOM) are CRAP in windows. They've ALWAYS been behind the technology curve.
The NTFS file-system was good when it came out, so I'll give them credit there. Their office applications have suited most people's needs (except for interpolibility w/ 3'rd party tools which EVERY UNIX application does exceptionally well in comparison). The games on windows are so-so compared to the user-experience of console gameing platforms.. A fact that MS is recognizing in their migration to X-Box. The only advantage PC-games still have is a more advanced UI and the ability to network w/o repurchasing the software.. But within a few years, these advantages will be gone as HDTV will become the standard display and all games will be pay-per-play (or periodic subscription); keyboard will be missed.
But MS didn't invent anything in NTFS, all the features were taken from existing competing platforms. And MS made very few games; they merely applied the console model of standardized API to the PC (again not invention, but duplication).
So when it's all said and done, the only thing I can credit them for is Office. But once again, just about every aspect of office has existed in one form or another in other places.. change-tracking == version-control. spell-checker (try aspell, ispell, etc). Grammer checker.. Ok maybe, don't know the history here. Spread-sheet? Definitely not. Annoying paper-click? Yeah, I'll let them have that one (it actually is useful to certain demograhics I'm sure).
I don't mean to MS bash here.. They are a great company, in that they focus one what drives revenue. And that's user-interest.. Office is the most important thing to most people [with money]. But
Don't blame it on dogma, blame it on human nature.
I hate the phrase "Human nature". It's nature period. Dogs and even roaches have the same tactics that we commonly deamonize in our war-mongering leaders.
If anything the only distinctly human elements are those that require at least 2 orders of abstraction. Namely the concepts of civil disobediance and "turning the other cheeck". This constitutes a direct passive aggressive response to an aggressive act. It's very hard to do, and the motiviations required to accomplish it are too complex for a 1'st order thinking creature like a dog. I'm defining 0'th order being directly stimulus reflexive, 1'st order being memory-based-pattern stimulus induced reaction. 2'nd order being able to apply memorized patterns to new contexts as a response. (The concept of abstraction)
Very little in our daily lives require 2'nd order thinking. Most of it, in fact is mere directly learned association (1'st order thinking), so we're not that much higher evolved than the animal kingdom.
I completely agree w/ the economic synopsis you give. I'll just add my small bit of extra info.
My wife is Armenian, and her countrymen claim [at least partial] responsibility for the fall of the CCCP. Basically the satelite states were in financial distress, and receiving less and less prioritized resources from the Kremlin. Armenia and a few other Soviet blocks were land-locked. The CCCP made use of distributated manufacturing. When building a widget, each member state was responsible for making some part of the widget; thereby forcing inter-reliance. But when some member states had feuds (like the Chrisitian Armenia v.s. the Muslim Azerbaijan), the central government didn't have the time nor the resources to reconcile the differences.
There was a massive Earth Quake in Armenia in the late 80's, and Gorbachev made a token visit (much like Bush to La). But no money or resources accompanied the visit.
Poor states, just like poor people, tend to fight more. So many of the states became more nationalistic and less supportive of the CCCP. As if California said f*u to Bush's Federal Gov and succeeded.
West Germany went through some very bizzar political changes. A governor accidently made a public statement providing extra freedoms to the locals, and there was fear amongst the local and central commands as to what would happen if those freedoms were revoked. Gorbachev later made a public statement supporting the East German changes, thereby facilitating the fall of the Berlin wall.
Poland had been slowly having their own set of political changes in the late 80's, also as a result of Gorbachev's reluctant approval.
The common denominator of these 3 states was an absent-handed Gorbachev. He could very well have come down like a Stalin or even Breshnev. I'm not quite sure of the reasonings, but it seemed to be Russian policy to be Russia-first, and screw the member states. Most likely the cost-over-runs were too much to manage by the 80s, and the "buffer states" were of decreasing value; they certainly didn't have any natural resources. It was only a matter of time before that policy collapsed the CCCP.
Our new weapons are percise GPS guided small tactical missles.
The problem is two fold:
1) A weapon used is a useless weapon. If you have to use a weapon, it obvously is not a strong enough deterrent to a war.
2) Targeted weapon systems rely on continuous communication back to home base. Yes there are backup systems (such as geographical pattern matching), but this is only on a subset of arsonal, and these systems are less reliable and easier to fool.
While a terrorist group isn't a major strategic threat outside of their home environment, there are still rogue nations, most of which are within grasp of the power to knock out our GPS satellites one way or another.
Once you knock out our eyes, then conventional warfare makes us no better suited than the 1950s (simple jammable radio-based communication).
The key to being a super-power is a credible threat. A death-star, or a ready-to-string special forces that can take out any town over night.
The more we bumble about w/ these wimpy targeted missiles that demonstrate what we are likely to use against rogue nations, they are better able to assess our weaknesses and weigh in the liklihood of successful resistance against us.
#1: $50 vs downloading the latest open source distro- gee, which do you think is cheaper?
Others' have addressed this. TCO isn't the purchase price.
#5 the commie bashing MicroSoft- probably has something to do with the fact that their CEO is paid very highly, and if minimum wage had risen the way CEO wages had in the United States in the last 20 years, the minimum wage would be $23.20/hr.
This is actually incorrect.. If min. wage grew at the same rate as CEOs then their salary would actually stay exactly the same, while CEO's would continue to have their massive rates of increase. It's economics and is why pure communism never existed and those varients that are still around are slowly becoming capitalistic.
The reason is that whatever political affiliation you have, there are certain laws of the universe that can't be changed.. You can't create or destroy matter, only move it around. Likewise, you can't create or destroy scarce resources; merely be less wasteful in the allocation of it.
50 years ago, people generally considered communism to be superior to capitalism in terms of efficient public welfare allocation. The problem is that the cost of information is too high. A government agency (assuming it is perfectly benevolent, which is another failing of communism) can not know who best to allocate scarce resources to. The US and other countries use graduated/targeted taxation, so that supply/demand is still in place, but the burden of public services falls more onto the sholders of those that are least troubled by it.
So how "much" someone makes is almost completely irrelevant because the dollar is a useless commodity except for purchases.. (fiat money)
So lets say we had a sudden increase in the min wage. Well, 1'st, the shock would be such that almost nobody would be willing or able to afford paying higher than min wage.. So you'd have 3 classes of people.. Min-wage, rich, and the scant few who are in between. (shifting from a diamond shaped economy to a pyramid)
As a result, every scarse resource is now equally available to everybody (except the few people above min wage). So for a short while, we're in communism.. Everybody wants the best doctor in town, everybody wants the house on the hill.. Everybody wants the red car. So commodities that are desirable to us are suddently as innaccessible as the lottery.
Think of a parking lot.. Everybody wants the spot closest to the door. It's 1'st come first serve by shere physics (The only exception being the segregated handicap population). Most people that have driven me around waste a lot of time searching for the closest possible spot.. They then fight over it.. One friend of mine is very aggressive and has almost gotten into accidents, just to assert himself as dominant so as to get the coveted spot. Then there are those w/ other priorities.. People w/ shiny cars that don't want to be scratched.. They park very far away. But this category is as rare as the wealthy population itself. Finally there are a few like me that recognize that on average you spend more time searching for a spot than a the fair amount of healthy excercize would take. So I take a 1'st spot seen approach.
Likewise in this brief period of consolidated purchasing-power equality, most people will be fighting for their newly acquirable scarce commodities. And violence will erupt.. We'll blame our politicians because we're too spoiled to be willing to accept personal responsibility for the hell we're causing ourselves.
Then a funny thing will happen. We will achieve equalization.. When the shock has run it's course, scarce items will have adjusted prices (just like oil is doing). The non-scarce items will have higher operating costs (higher wages, higher cost of scarce items required for manufacturing/processing).
Then we'll see the self-interest factor. If an individual sees that they're unlikely to get a pay-raise, they're less motivated to work harder.. We tell people "you don't want
I think that's a bit disengenuous.
"stored procedures" implies a user-defined/custom. What we're discussing are deviations from standards-based SQL features.. Things that can be abstracted by middle-tier systems such as ruby, java's hibernate, etc. The standardized SQL is layered with a standardized middle-tier (which builds apon the standard and accounts for minor variations by different vendors). Then you have a layer of pure logic, independent of performance or mangled by the particulars of a language... You can choose the language that best suites the problem-space; beit mathmatical, logical (prolog, or forward-chained), heirarchical (XML-based constructed logic), etc.
The key is to have as little an impeedence mismatch between the problem and the solution as possible.. The DB is used here as a tool, no more or less impressive than the "prolog" language.
When them problem is solved elegantly, you then revisit performance issues, weighing the cost of higher-end equipment to that of maintainance time spent optimizing the hell out of some piece of code.
A system designed to scale to a billion rows of data often will not perform quickly on only a couple thousand rows.
With the above system-engineering philosophy in mind, the "triggers" are hidden mechanisms to apply the standards. The "indexes" are hidden mechnaims to performance tune. The "user-defined" types are necessarly hidden from the problem space (in OR-mapping tools, literally indistinguishable from simple rectangles from primitives), the constrants are hidden situations which become occasional SQL-error-condition until the system is fully debugged, never-again thereafter to be actuated.
So while these mechanisms are important from a theoretical and a layer-of-protection stand-point, they are irrelevant from the black-box tool stand-point.
You forgot to mention security boundaries between tiers. I hate dealing with these moron dev who try to implement all their data logic in the business logic layer.
I worked in database-design around the transition from thick-client to web-based design. The most interesting thing for me was the futility of the "db-login-user". Previously there were advanced heirarchies of access permissions. DBA's monitored who was logged in to the DB, how much CPU time they were consuming, how much memory etc.. Then all of a sudden, we were designing monolothic sign-on users called "webguy". There'd be dozens of simultaneous connections performing roughly the same tasks. We had to scratch our heads to determine how our "50 licenses" would work with this single login user fullfulling the needs of 150 employees.
Classicly, you only give the read or write access to the tables that the application needs.. That's all fine and good. But a given application-tier performs 95% of what a user could require do.
SQL injection is going to affect everything that makes the application functional. The only thing DB-ACL provides is isolation between applications.. And if you're sys-admin has a common login for all your applications, you have other problems.
If you have other processes connecting straight to the database and changing data directly, you have serious issues.
...
Forget separate processes.. Think multiple threads.. e.g. concurrency. While it is the "job" of the application to test-first, update-later, and synchronize all along the way, the fact of life is that bugs live inside our code, and when we miss a concurrency test somewhere, and then one day you're happily making a purchase order and wamo, a race-condition has corrupted your data....
While I agree with the general thread that applications should be responsible for work-flow and should enforce business-rules, the particular example was a bad one because it represents a trivial constraint. Moreover, if it is a fundamental business rule, the data can be structured in such a way as to re-inforce it.
e.g.
instead of:
item (id int pk, name varchar, num_in_stock int)
purchase_order (id int pk, item_id int references item(id))
you could have:
item_type (id int pk, name varchar)
item (id int pk, item_type_id int references item_type(id))
purchase_request (id int pk, item_id int references item(id) unique)
Or even better
item_type
purchase_request (id int pk, sale_date datetime)
item(id int pk, item_type_id int refs item_type(id), purchase_request_id int refs p_r(id))
I often structure my data to represent their associativity. It isn't difficult to migrate the data if that business rule changes (1:1 v.s. 1:n v.s. m:n).
Now if you have a more complex example (must have entity A only when there are at least 5 entity B's AND and an entity C), then it's up to you whether that lives in semi-custom "constraint" logic or in the application-layer.
I think one of the problems here is how you actually define a dimension.
It's a linear algebra thing. A vector-space can be thought of as a universal coordinate system with n-dimensions.. A multi-dimensional array in programming languages represents a multi-variet coordinate system. The letter, v.s. the word, v.s. the sentense, v.s. the paragraph. v.s. the page v.s. the chapter are also all legitimate dimensions in such a defined vector-space. But many vector-spaces can be translated into other vector spaces.
For example, a multi-dimensional array is always flattened out to a 1 dimensional index into a memory-space (e.g. the offset from the beginning of memory starting at address 0). The coordinate for the letter can be represented by either the "n'th letter in a document" or a 3D geometric coordinate into a stack of paper.
We usually use mathmetical transformations to relate one vector space to another. Though sometimes there isn't a simple uniform transformation (such as the n'th letter v.s. the 3D geometric coordinates into a page).
Even in geometric vector spaces, we have many representations.. Rectangular is best known. Go one block forward, two blocks to the right, and go up 5 stories; or a relative coordinate of (1,2,5). Spherical is often more useful in quantum physics. Outward of a radius of 2 nano-meters, down 30 degrees from top-dead-center, and rotated 90 degrees (2nm, 30deg, 90deg). Of course the frame of reference is just as important with rectangular and spherical.
rectangular, cylindrical, and spherical are all I've ever directly worked with, but there are many more useful coordinate systems and thereby vector spaces.
Another concept in linear algebra that might help here is the concept of linear-independence. Since you can define an arbitrary vector-space (such as the (letter,word,sentence,paragraph, page, chapter) coordinate system. It's possible that there is a high degree of redundance. It can often be mathmaticlly proved that a vector space has linear dependence between two of the dimensions.. Such as (letter,odd-words, even-words, sentense, paragraph). odd-words, and even-words would be directly related to each other. And thus the dimensionality would of this vector-space would have to be reduced by 1. It is sometimes still useful to maintain the redundance.. Especially if you're regularly asking questions where that dimension would answer w/o further calculation. But the true dimensionality of the vector-space is less.
We call a "basis" a fundamental mathmatical description of a vector space which is linearly independent between it's dimensions (and also has demension descriptors with effective length 1). It can't be optimized any further for a given descript of a vector-space.
So if the question is whether left-right, up-down, forward-backward, and time represents 4 dimensions.. The answer is absolutely "yes". Just like (letter,odd-word,even-word,sentense,paragraph) is a 5D system. or:
int[5][5][5] 3darray;
is a 3D system.
But whether (x,y,z,t) is a 4D basis is really the interesting question.. And for string-theory and this dark-matter theory, whether 6D, 11D, or 26D basis's exist is key.
So you can define basis vector-spaces however you want.. So long as you can truely represent a useful coordinate system, and you don't have any redundancy in the definition.
Here is another useful artifact of interchangeable vector-spaces. Something I picked out of Brian Greens' "Elegant Universe". Often a particular theoretical geometric configuration of the universe would provide for anomolies (divide-by-zero, or infinite) results when constructing potential cosmological situations. But when you use a different gemoetric configuration (a different vector-space) the anomoly no longer exists, in fact, you see a continuous progression from sample-point 1 to sample-point2.
Take for example rectangular v.s. spherical coordinates. W/ spherical you have a length and 2 directions (radius of a ba
I don't care about depth.. Weight is a non-trivial issue for me.. I move often enough that the one-time cost and danger of moving a multi-thousand dollar piece of equipment is worrisome. A 30" CRT therefore worries, me, but a 40" LCD I can lift single-handidly.
Additionally, I don't know about why other people buy LCD's (looks perhaps?), but I get it for the lack of flicker.. Why else haven't we fully migrated to flourescet lighting.. It's smaller, lasts longer, brighter, cheaper... Because it gives me head-aches. You can sit inches away from an LCD screen, but not in front of a CRT.. Moreoever, the flicker most dramatically affects your side viewing angle... More and more people are getting dual monitors; even if nothing more than to hook a bigger screen up to their laptop.. When you look away from the CRT, the corner of your eye will pick up the flicker. Upping the refresh rate helps, but it is still a factor in your general health.
LCDs have no flicker. Though, ironically, they're often powered by something akin to flourescent lighting.
The flicker was also one of my main reasons for not going w/ plasma for an HDTV. If you're close enough, you can definitively see the flicker. Due to my migraines, I didn't want to spend big money on something that would still produce the same pain from watching for several hours at a time as my CRT.
DLP has a similar flashing effect (except w/ certain higher priced models w/ tri-guns).
I think ideally I'd like an LED display. I don't know anythin about the SED that you speak of.
brightness and quickness of response have always been a positive of plasma.. But I always thought it wierd to put a plasma on a laptop, because plasma generally requires higher power drain than LCD. That plus plamas are generally heavier.
Moroever, the viewing angle, brightness levels/control and refresh rates of LCD has caught up, and even in many respects outdone plasma these days.. There is simply too much momentum in the LCD market. I'm sure if similar levels of research were pushed into the plasma market, they could catch back up to LCD, but LCD has the advantage of being used in the high volume PC market, where the same break-throughs on 17" screens can be applied to 60" screens. Plasma simply can't get much smaller than 32" - at least not w/o serious resolution sacrifice. I'm sitting on a laptop made 3 years ago w/ a 16" display and 1600x1200 resolution. This is physically impossible w/ plasma today. Thus plasma are low volume units. Now because of competition (especially w/ LCD), the plasma profit margin is being squeezed, which means even less available R&D.
If you were a company choosing what R&D money to spend, LCD or Plamsa, I don't know that you'd choose plasma anymore.