The negative momentum associated with this stock is so overwhleming that it may only find support once it hits single digits. As it stands, a number of analysts stand to lose their reputations by maintaining their buy recommendations - not that H&Q really had a reputation to begin with in my book (most other brokers don't even want to cover this stock because it is such a dog).
Lets get one thing straight - we are entering a bear market. A huge number of companies are about to go bye-bye, some of them will be names you have come to think of as permanent fixtures. LNUX is clearly at the top of the list, by virtue of its incredible negative momentum. Lets face it - by rights they probably had no business going public for at least another two years. They went public as a glorified chop shop and used their stock as currency to buy up companies that might give them a better chance than the other countless PC chop shops in any strip mall out there. But the companies they bought really only made their prospects even riskier. Andover is not the type of company you acquire to shore up an already ridiculous stock price.
Of course, its not VA's fault that investors chose to chase LNUX up so high, and I hope thatin their board meetings, H&Q were advising them to look for a sub-billion valuation in the future. If expectations continue to be high, LNUX management will slowly move on in the next few months as expectations fall apart.
LNUX and CALD can't cite the greater market downturn for their woes - their charts are without any significant sustained upside whatsoever. In other words, they fell like a brick from the points where they were released from.
For CALD, the reason is simepl - they simply aren't a significant player, and they were late to IPO.
For LNUX, it departed from reality the moment the price got above $60. Anyone who got involved in buying that stock over $100 wasn't even gambling - at least in gambling there is a small chance you will win - over $100, LNUX was assured of tanking, 100% assured with no chance of doing anything else.
Seriously, marketing to the BeOS/Linux crowd will never make anyone a dime.
Its amusing to see these companies try to bolster yet-another anti-microsoft tactic, but frankly, any multimedia technology that isn't supported by Microsoft is probably a non-starter. Just ask Real or Apple...who have both had their streaming technologies run out of town by Windows Media technology.
Re:Java will find a limited niche
on
Swing
·
· Score: 1
In what way does Java reduce the degree of freedom for a programmer?
Let me count the ways:
Firstly, Java is a monoparadigm language. If you don't like OO, or it falls out of stule, you're SOL. C++ is multi-paradigm, by comparison.
Java does not support optional polymorphism - virtual is implied for all functions. In C++, you don't pay for vtables unless you explicitly want to.
Most Java class libraries are excessively synchronized. Once again, you pay for safety in performance.
others....
You may actually see each of these as features that enhance your experience, but nonethless they are limiting factors that constrain many programmers, who are sticking to C++ instead.
Re:Java will find a limited niche
on
Swing
·
· Score: 1
There are far more valuable factors than performance
If that were true, we'd all be using Lisp machines. We aren't, so I'll stick to my premise that in any market for software (even internal), performance always wins.
Re:Java will find a limited niche
on
Swing
·
· Score: 1
Oh I love the superior tone "Java isn't for hardcore people"
C is a crap language
Whether C is better or not is up to debate - firstly, you're comparing apples and oranges. C is a platform language, Java is an application language. Platform lanugages will always be more demanding than application languages, as platform languages cannot sacrifice performance for any ease-of-use issues.
That said, a highly skilled C programmer will always be able to deliver a superior product - all other things considered equal (features, debug cycle, etc), the C programmer's product will always be better performing.
Java will find a limited niche
on
Swing
·
· Score: 1
Firstly, everyone understands that Sun's massive PR effort nothwithstanding, Java's actual success is and will be considerably less than the hype would have supported.
On the other hand, the lot of us should have known better than to fall for the easy promises Sun was offering.
Java is just another language, with its own niches. These niches are primarily in the enterprise application logic market. Thats my fancy term for "people who aren't hardcore programmers and who would be using VB otherwise".
For these people, Java is probably just what the doctor ordered:
there are scads of training materials cheaply/freely available
there are development kits available for most platforms
java reduces the degrees of freedom for the programmer, and makes programming more pedantic and verbose...but for less advanced programmers, this is likely beneficial
sun works fairly aggresively to integrate java in with new technologies, which satisifes IT directors
the list goes on...needless to say there is a market for this tool. Of course if you are a crack C programmer, Java is probably a joke - just as much as VB, and you'd be silly to bother with it unless required to. Unfortunately, Sun has not marketed Java as a niche tool but as the be-all-and-end-all programming language, and hence this spurns a great deal of hostility from folks who know better.
The basic premise of security is that some rights simply must be made exclusive and unavailable to certain users. I find his justification laughable. Every now and then RMS goes right off the deep end. This is one of those cases.
Yes, and that the distinction that I, and everyone else are using. I did not confuse strong typing and static typing. I consider Smalltalk strongly and dynamically typed. I consider C++ strongly and statically typed. Those are the defintions I am working with.
What is this point that you claim repeatedly that I fail to address?
Your arguments regarding coupling have very little to do with OO itself. Encapsulation, at least, existed in many languages before OO came onto the scene, and encapsulation is the primary concern when deriving interfaces that determine how strongly coupled modules are. Read Parnas, Meyer, for more info.
If Java is an idiot language then the poster of all people should immediately use it!
Oh hardy har! Geez, you really nailed me on that one, oh, how biting!
Adding stong typing just makes the problem of productively using the language worse for many OO languages.
Do you have ANY CLUE what you are talking about? There is no such this as objects if you don't have strong typing. All OO langs are descended from the Algol family. Even weakly typed languages add strong typing-like facilities in order to use OO (i.e., perl's OO additions). If you can't name a type, you can't name an object. If you can't name an object, you have no OO!
OO languages do not constrain programmers to write good programs or produce good designs, but they do encourage OO design, which is beneficial when done well.
Another assumption that has not held up well to critical inquiry.
The important thing is to encourage high module coherence and low coupling between modules. This enables developers to think in termsThe important thing is to encourage high module coherence and low coupling between modules. This enables developers to think in terms of natural abstractions and make changes with a good understanding of what they're doing. You're more likely to get reusable, maintainable code that way.
No, no, no. Read Alexander's Patterns books. Read Gabriel. Abstraction is more often than not the stick that beats most programs to death. Most programmers completely destroy useful reuse by implementing abstractions that are far too general. Once again, you're trumpeting assumptions about OO that once critically challenged, often fall short.
Everything about C++ that is not also in C makes the language more object orriented (typical OO languages either have generics or weak typing
Generic programming is a independent paradigm from OO...repeat this three times. The STL was created because OO was determined to be a bust by its author, A. Stapanov. This is why C++ is considered multi-paradigm - you can use generic programming over OO if you wish.
C++ classes actually have to be designed to be subclassed, and the developer must guess which methods and features the client will need to use of override.
This is the strength of C++, not the weakness!!!! You don't pay for vtables if you don't want them. Yes, this requires that you actually know what you are doing, but the payoff is in performance.
Also, if I have two type hierarchies and I want to implement a conversion between the two in the 'natural' C++ way (using implicit constructors or cast operators) I *must* contaminate one hierarchy or the other with knowledge of the other's existence.
Right - and Java lets you cast from Object, right? Unfortunately, you lost strong typing along the way of the cast. Enjoy.
Not true. If you use C and malloc rather than Java and "new", you have more memory management work to do. More possibility for mistakes - for something which, in many applications, just isn't worth manually coding.
Ultimately the Java new is simply doing a malloc anyway - its just wrapping extra safety around it.
There is no difference between C allocating memory and Java allocating memory - in both cases, there is a request for a chunk of memory of finite and predetermined size. You will either get it or you won't. There is nothing "OO" about this. You are confusing the syntax of the different languages with what is actually happening underneath. There is no such thing as "OO memory allocation".
>> Paradigms per se have zilch to do with memory mangement. A fully garbage-collecting, memory-safe environment can be implemented beneath any language.
That's debatable.
No it isn't - perl and Tcl are not OO languages and they are fully garbage collected and memory managed.
Procedural interpreted languages have existed for two decades or more. Once again, the OO paradigm has zilch, nada, to do with the actual implementation of memory management beneath it - its just a syntax.
The keywords "new" and "delete" could just as simply draw you a slice of memory in a completely different way on different computing platforms. You're tying syntax to implementation.
Hahahaha! Really? Show me one case where this has ever been done successfully for C, without implementing a full-blown virtual machine. And if it's so good, why aren't more people using it?
My point was not to say that this has been done for C - but it has been done for perl and Tcl, which are not OO languages.
This notion has its roots in philosophy where "true freedom" is actually a misnomer: we require some constraints in order to make sense of the world and to be productive in it.
I agree, but most computing environments already enforce the most common-sense constraints:
don't use memory that doesn't belong to you
don't modify system facilities/properties unless you have permission
It is certainly an improvement upon top-down, procedural design in terms of flexibility and maintainability.
The jury is out on that.
HOWEVER, I would say that the constraints imposed on an OO language like Java or Smalltalk would result in a program that is less shoddy in the area of memory leaks and segmentation faults.
Paradigms per se have zilch to do with memory mangement. A fully garbage-collecting, memory-safe environment can be implemented beneath any language.
I continue to be amazed at the people who have swallowed the OO koolaid. C++ and Python folks too. Unfortunately, Java appears to subscribe more fervently to OO than any other language, in that you are forced into this paradigm whether it makes sense for you or not.
This coercian is what leads me to conlude that Java is ultimately an idiot language. Don't get me wrong - there is a place for a "dumb" language - its good and right that more and more people be able to code, but ultimately I can't see a seasoned programmer being satisfied with being bound to one paradigm till death do us part.
Smart programmers want choice. C++ may shoot you in the foot and blow your brains out at the first chance, but at least it gives you freedom. Don't like objects? Don't use them. Don't want a vtable? Don't cause one to be created. Ultimately I see paradigm-agnostic languages as being the winners, once programmers start thinking.
As it stands, I also think that we are within five years of OO being laughed out of the office as a general development menthod. Forward looking writers have already lambasted or severely lambasted OO (see Gabriel's Patterns of Software).
There is no indication that OO improves programmer performance or reduces errors. Most studies that seek to validate OO as a method do so by studying superstar programmers. These folks would do well if forced to use an abacus. The everyday programmer typically misuses OO features, and the resulting hairball is anything but a advance in design.
We don't have the perfect paradigm/language yet, but I know Java and OO aren't it.
Excessively poor performance put Tcl out of the running long ago. Scrptics is fighting an uphill battle - the perl mindshare is at least 10x the Tcl mindshare right now, and job ads show this.
Sorry, this is just not true. I work on a team implementing a Java2 JVM and JRE. We were pleasantly surprised at the performance gains we saw when using HotSpot. It really does dramatically increase Java execution speed. We commonly see Java applications executing only 25-50% slower than their C++ counterparts.
This is such a loaded statement. Without calling into question your C++ skills, I have seen unbiased tests that indicate that Hotspot is still twice as slow as C++.
Anecdotal information regarding Java's supposed performance gains are so numerous (and spurious) in/. that they are almost useless. How did you measure the performance gain? What features of C++ (templates, MI) were you using that Java does not support?
Until I see some concrete proof otherwise, I'll just have to judge Java apps as I continue to rate them - fat and slow.
A decent, modern JIT (Symantec, Borland and even MS have *very* good ones) will run Java with a similar, or even better, performance than C++.
I'm sorry, but this is categorically false. Even fudged results from the most skewed tests put JIT Java code at least twice as slow as C++. I'm not saying you shouldn't use Java - there are times when it is the correct tool - but users should realize that they are going to take a significant performance hit.
Any competent programmer will be aware of the facility perl gives you to shoot yourself in the foot, and don't make use of it.
Bravo. I'm so tired of hearing people bellyache about perl being obfuscated and error-prone. This is simply nonsense. Any literate twelve year-old can read and digest Programming Perl. That fact alone should shame the moaners and groaners in here who simply aren't up to the challenge of a truly different language.
The Windows platform will continue to lose mindshare.
Bravo Twice. The web is the only platform that matters. Shrink-wrap is dead insofar that MS owns any aspect of the shrink-wrap market worth pursuing.
No, it is not. Java has no parametric polymorphism, multiple inheritance, or optional virtual methods.
I'm not saying Java is good or bad per se by saying this, I'm simply saying that Java does not support more object-oriented featues than C++.
Object orientation allows large projects to be arranged and managed in a logical manner.
Yeah right. Reading Booch does not an expert make. Most real-world studies of large projects indicate that OO methods can significantly complicate and delay projects.
As for your argument against scripting languages...Well, your best bet would probably be TCL for the front-end of an app. It has a nice toolkit,
Tk has been bound to numerous languages - you need not use Tcl to enjoy Tk.
But the bigger point here is that linux/unix users SHOULD strive to write cross-platform code, whenever possible. When you write applications this way, you meet you PHB's requirement that it work under windows. The application can be sold
Sorry, but now you've just gone off the deep end. The entire shrink-wrap market is dead (Microsoft owns any part of it worth owning), so I have to dismiss your advice categorically. Program for the web. Where would you rather be - Ebay or Corel?
Slashdot Mirror
Lets get one thing straight - we are entering a bear market. A huge number of companies are about to go bye-bye, some of them will be names you have come to think of as permanent fixtures. LNUX is clearly at the top of the list, by virtue of its incredible negative momentum. Lets face it - by rights they probably had no business going public for at least another two years. They went public as a glorified chop shop and used their stock as currency to buy up companies that might give them a better chance than the other countless PC chop shops in any strip mall out there. But the companies they bought really only made their prospects even riskier. Andover is not the type of company you acquire to shore up an already ridiculous stock price.
Of course, its not VA's fault that investors chose to chase LNUX up so high, and I hope thatin their board meetings, H&Q were advising them to look for a sub-billion valuation in the future. If expectations continue to be high, LNUX management will slowly move on in the next few months as expectations fall apart.
For CALD, the reason is simepl - they simply aren't a significant player, and they were late to IPO.
For LNUX, it departed from reality the moment the price got above $60. Anyone who got involved in buying that stock over $100 wasn't even gambling - at least in gambling there is a small chance you will win - over $100, LNUX was assured of tanking, 100% assured with no chance of doing anything else.
Its amusing to see these companies try to bolster yet-another anti-microsoft tactic, but frankly, any multimedia technology that isn't supported by Microsoft is probably a non-starter. Just ask Real or Apple...who have both had their streaming technologies run out of town by Windows Media technology.
Let me count the ways:
- Firstly, Java is a monoparadigm language. If you don't like OO, or it falls out of stule, you're SOL. C++ is multi-paradigm, by comparison.
- Java does not support optional polymorphism - virtual is implied for all functions. In C++, you don't pay for vtables unless you explicitly want to.
- Most Java class libraries are excessively synchronized. Once again, you pay for safety in performance.
- others....
You may actually see each of these as features that enhance your experience, but nonethless they are limiting factors that constrain many programmers, who are sticking to C++ instead.If that were true, we'd all be using Lisp machines. We aren't, so I'll stick to my premise that in any market for software (even internal), performance always wins.
C is a crap language
Whether C is better or not is up to debate - firstly, you're comparing apples and oranges. C is a platform language, Java is an application language. Platform lanugages will always be more demanding than application languages, as platform languages cannot sacrifice performance for any ease-of-use issues.
That said, a highly skilled C programmer will always be able to deliver a superior product - all other things considered equal (features, debug cycle, etc), the C programmer's product will always be better performing.
On the other hand, the lot of us should have known better than to fall for the easy promises Sun was offering.
Java is just another language, with its own niches. These niches are primarily in the enterprise application logic market. Thats my fancy term for "people who aren't hardcore programmers and who would be using VB otherwise".
For these people, Java is probably just what the doctor ordered:
- there are scads of training materials cheaply/freely available
- there are development kits available for most platforms
- java reduces the degrees of freedom for the programmer, and makes programming more pedantic and verbose...but for less advanced programmers, this is likely beneficial
- sun works fairly aggresively to integrate java in with new technologies, which satisifes IT directors
the list goes on...needless to say there is a market for this tool. Of course if you are a crack C programmer, Java is probably a joke - just as much as VB, and you'd be silly to bother with it unless required to. Unfortunately, Sun has not marketed Java as a niche tool but as the be-all-and-end-all programming language, and hence this spurns a great deal of hostility from folks who know better.C++ is a full-on multi-paradigm language. None of my comments should be construed as a knock on it.
BZZZT! OO has had twenty-fove years to get something, anything right. Too late. Next paradigm please. Generic programming anyone?
Ooops, there they go again, counting JDK downloads as representing active developers.
And its faster, too.
Neither anecdotal nor measured benchmarks supports your conjecture.
The basic premise of security is that some rights simply must be made exclusive and unavailable to certain users. I find his justification laughable. Every now and then RMS goes right off the deep end. This is one of those cases.
Yes, and that the distinction that I, and everyone else are using. I did not confuse strong typing and static typing. I consider Smalltalk strongly and dynamically typed. I consider C++ strongly and statically typed. Those are the defintions I am working with.
Your arguments regarding coupling have very little to do with OO itself. Encapsulation, at least, existed in many languages before OO came onto the scene, and encapsulation is the primary concern when deriving interfaces that determine how strongly coupled modules are. Read Parnas, Meyer, for more info.
Oh hardy har! Geez, you really nailed me on that one, oh, how biting!
Adding stong typing just makes the problem of productively using the language worse for many OO languages.
Do you have ANY CLUE what you are talking about? There is no such this as objects if you don't have strong typing. All OO langs are descended from the Algol family. Even weakly typed languages add strong typing-like facilities in order to use OO (i.e., perl's OO additions). If you can't name a type, you can't name an object. If you can't name an object, you have no OO!
Another assumption that has not held up well to critical inquiry.
The important thing is to encourage high module coherence and low coupling between modules. This enables developers to think in termsThe important thing is to encourage high module coherence and low coupling between modules. This enables developers to think in terms of natural abstractions and make changes with a good understanding of what they're doing. You're more likely to get reusable, maintainable code that way.
No, no, no. Read Alexander's Patterns books. Read Gabriel. Abstraction is more often than not the stick that beats most programs to death. Most programmers completely destroy useful reuse by implementing abstractions that are far too general. Once again, you're trumpeting assumptions about OO that once critically challenged, often fall short.
Everything about C++ that is not also in C makes the language more object orriented (typical OO languages either have generics or weak typing
Generic programming is a independent paradigm from OO...repeat this three times. The STL was created because OO was determined to be a bust by its author, A. Stapanov. This is why C++ is considered multi-paradigm - you can use generic programming over OO if you wish.
C++ classes actually have to be designed to be subclassed, and the developer must guess which methods and features the client will need to use of override.
This is the strength of C++, not the weakness!!!! You don't pay for vtables if you don't want them. Yes, this requires that you actually know what you are doing, but the payoff is in performance.
Also, if I have two type hierarchies and I want to implement a conversion between the two in the 'natural' C++ way (using implicit constructors or cast operators) I *must* contaminate one hierarchy or the other with knowledge of the other's existence.
Right - and Java lets you cast from Object, right? Unfortunately, you lost strong typing along the way of the cast. Enjoy.
Ultimately the Java new is simply doing a malloc anyway - its just wrapping extra safety around it.
There is no difference between C allocating memory and Java allocating memory - in both cases, there is a request for a chunk of memory of finite and predetermined size. You will either get it or you won't. There is nothing "OO" about this. You are confusing the syntax of the different languages with what is actually happening underneath. There is no such thing as "OO memory allocation".
That's debatable.
No it isn't - perl and Tcl are not OO languages and they are fully garbage collected and memory managed.
Procedural interpreted languages have existed for two decades or more. Once again, the OO paradigm has zilch, nada, to do with the actual implementation of memory management beneath it - its just a syntax.
The keywords "new" and "delete" could just as simply draw you a slice of memory in a completely different way on different computing platforms. You're tying syntax to implementation.
My point was not to say that this has been done for C - but it has been done for perl and Tcl, which are not OO languages.
I agree, but most computing environments already enforce the most common-sense constraints:
It is certainly an improvement upon top-down, procedural design in terms of flexibility and maintainability.
The jury is out on that.
HOWEVER, I would say that the constraints imposed on an OO language like Java or Smalltalk would result in a program that is less shoddy in the area of memory leaks and segmentation faults.
Paradigms per se have zilch to do with memory mangement. A fully garbage-collecting, memory-safe environment can be implemented beneath any language.
This coercian is what leads me to conlude that Java is ultimately an idiot language. Don't get me wrong - there is a place for a "dumb" language - its good and right that more and more people be able to code, but ultimately I can't see a seasoned programmer being satisfied with being bound to one paradigm till death do us part.
Smart programmers want choice. C++ may shoot you in the foot and blow your brains out at the first chance, but at least it gives you freedom. Don't like objects? Don't use them. Don't want a vtable? Don't cause one to be created. Ultimately I see paradigm-agnostic languages as being the winners, once programmers start thinking.
As it stands, I also think that we are within five years of OO being laughed out of the office as a general development menthod. Forward looking writers have already lambasted or severely lambasted OO (see Gabriel's Patterns of Software).
There is no indication that OO improves programmer performance or reduces errors. Most studies that seek to validate OO as a method do so by studying superstar programmers. These folks would do well if forced to use an abacus. The everyday programmer typically misuses OO features, and the resulting hairball is anything but a advance in design.
We don't have the perfect paradigm/language yet, but I know Java and OO aren't it.
Excessively poor performance put Tcl out of the running long ago. Scrptics is fighting an uphill battle - the perl mindshare is at least 10x the Tcl mindshare right now, and job ads show this.
This is such a loaded statement. Without calling into question your C++ skills, I have seen unbiased tests that indicate that Hotspot is still twice as slow as C++.
Anecdotal information regarding Java's supposed performance gains are so numerous (and spurious) in /. that they are almost useless. How did you measure the performance gain? What features of C++ (templates, MI) were you using that Java does not support?
Until I see some concrete proof otherwise, I'll just have to judge Java apps as I continue to rate them - fat and slow.
I'm sorry, but this is categorically false. Even fudged results from the most skewed tests put JIT Java code at least twice as slow as C++. I'm not saying you shouldn't use Java - there are times when it is the correct tool - but users should realize that they are going to take a significant performance hit.
Any competent programmer will be aware of the facility perl gives you to shoot yourself in the foot, and don't make use of it.
Bravo. I'm so tired of hearing people bellyache about perl being obfuscated and error-prone. This is simply nonsense. Any literate twelve year-old can read and digest Programming Perl. That fact alone should shame the moaners and groaners in here who simply aren't up to the challenge of a truly different language.
The Windows platform will continue to lose mindshare.
Bravo Twice. The web is the only platform that matters. Shrink-wrap is dead insofar that MS owns any aspect of the shrink-wrap market worth pursuing.
No, it is not. Java has no parametric polymorphism, multiple inheritance, or optional virtual methods.
I'm not saying Java is good or bad per se by saying this, I'm simply saying that Java does not support more object-oriented featues than C++.
Object orientation allows large projects to be arranged and managed in a logical manner.
Yeah right. Reading Booch does not an expert make. Most real-world studies of large projects indicate that OO methods can significantly complicate and delay projects.
As for your argument against scripting languages...Well, your best bet would probably be TCL for the front-end of an app. It has a nice toolkit,
Tk has been bound to numerous languages - you need not use Tcl to enjoy Tk.
But the bigger point here is that linux/unix users SHOULD strive to write cross-platform code, whenever possible. When you write applications this way, you meet you PHB's requirement that it work under windows. The application can be sold
Sorry, but now you've just gone off the deep end. The entire shrink-wrap market is dead (Microsoft owns any part of it worth owning), so I have to dismiss your advice categorically. Program for the web. Where would you rather be - Ebay or Corel?
Its a dead market folks.
Corel is not the future, Yahoo and Amazon are.