Why don't you tell us what you think is a good language and/or what makes Java so bad. Compare and contrast them if you want people to get any value out of your statement.
See Rational XDE. (OK, you will need a Cray on that one:(, but that babe has some serious code and model generating capabilites. And I don't work for IBM.)... I am from academia and fed up with People Bashing UML Without Knowing What It Really Is.
Funny. I actually have real-world experience, four years of which was at Rational, and I've used Rose on many occasions. I found it to be "feature rich" in the wrong places (aka bloated) and too thin where I actually wanted some functionality. Also, since you mention it, I found it to be a serious a resource hog.
I know UML is merely a specification language, and that how you use it it more important than any specific tool implementation. Also I believe 100% that if someone wants to spend the time to flesh out their system in UML, in extreme detail, that some day they will be able to fully code-generate a working system from it. Additionally I believe that the time required to do all the modeling and annotation that will be necessary for this will not be an improvement over just writing the code by hand in any other language.
In the real world (at least the one I've worked in) it's usually much more important to get working (even if incomplete) software out there NOW than it is to have perfect software much later. You need to change the design every time you turn around, and wrestling with updating diagrams and round-trip modeling/coding tools is madenningly tedious and slow.
How I *actually use* UML is as a mechanism for communicating ideas "live" on a whiteboard to others who are trying to think through solutions in a team setting. And then I use less than 10% of UML's capacity -- mostly just class diagrams, and occasionally interaction diagrams.
I do NOT use it as long-lived documentation, because it goes immediately out of date. The only guaranteed-accurate documentation is the code itself (and not even code comments). Sometimes a high-level diagram can be meaningful for a while, and I'll make one for posterity sake, but mostly not.
How I *WOULD* (like to) use UML is for the visualization of existing code -- to analyze it from a 10KF view; to make pictures that'll help me understand the code and figure out how to improve/extend it. And then I'd throw it away when I was done. Unfortunately this is how I would LIKE TO use it, because pretty much all reverse engineering tools seem to fall short of accurate, or at least "sane" interpretations of what's going on.
I'm glad sombody's already posted this obvious counterpoint - I was about to.
So... it's OK for people to use amimal parts to keep themselves alive, but not OK to put people parts IN animals -- even if it's to help us better understand how to keep people alive and healthy.
Duh.
Eric Giguere wrote:
There goes the "LAM" part of "LAMP".... So really, you're comparing the Java-based J2EE framework against similar Perl/PHP/Python frameworks.
The bottom is that if PHP can be directly compared to anything in the Java world, then it ought to be a comparison against JSP (without beans), because that's all it is -- a server side, page-level scripting language. Sure, you can do more with PHP if you write extensions in C or whatever, but then you're writing in C and not PHP!
"Swift is built to be agile, to swiftly turn and point its instruments at the burst and relay burst locations within seconds. No satellite turns faster. Swift, in fact, is not an acronym; it is named for the small, nimble bird."
The first page of the PDF is actually an artsy image of the satellite superimposed with a swift.
Agreed on that point - the business logic belongs in the application / business object whenever you can.
Personally I DO in fact prefer to use stored procedures, but not the way most do, as a place to write programs with flow control statements, etc. I use SPs as a means to provide "canned queries" (and of course updates etc).
This approach gives you the advantage of being able to persistence your data from any language, and the benefit of pre-compiled speed, and also control over transactions and authorization -- all good things.
The only time I readily put business logic in a SP is when a join won't do -- when doing it in the app would mean too many round trips (to look up and cross ref and look up and cross ref). Too inefficient.
Many people say the other time to put logic in SPs is when you want the exact same complex logic to be runnable from all platforms, such as with order placement. I disagree -- things like that should be made into service interfaces through SOAP, cgi, CORBA, or whatever floats your boat (just set a standard).
Yes, DB SPs can be trated like a service, but that approach is generally only suitable for internal apps, whereas true service interfaces can be invoked from outside more easily (and platform independently).
I thought I knew where Joel was going with the article, but was surprised when he didn't get there. I expected him to explain MS's loss of the Win32 API as the high-level.NET APIs (and VM) making the low-level Win32 API irrelevant.
And once everyone was developing against the new, high-level APIs of.NET, and MS no longer "needed" to support Win32 apps, that would open the door for others on other platforms to develop.NET compatible VMs for those, NON-MS systems.
And it's at that point that MS has totally lost control. Their former OS lock will have become irrelevant, and even the apps created by die-hard MS loyalists, for deployment only on MS, would suddenly be able to run on anything. (more or less not unlike Java)
I'm disinclined to agree with Joel about the future belonging to browsers. Sure, they'll still be very important and there will be many more web-based apps out there. But for rich client apps (which will surely still exist) they will not be locked to MS or any other os, as long as high-level, memory-managing VMs have become the norm.
I was also going to suggest spire if nobody had yet. GOOD STUFF.
I personally own one of the backpack-style computer bags, which is great for carrying your laptop safely, plus is has a LOT of cargo space for other goods. When I'm just going to/from the car I do the "single shoulder sling" approach, but in airports, longer walks, or when I need my hands free I wear it like a regular backpack. One could easily bicycle to work with this one.
Getting back to the bbspot article (oh yeah, that old thing at the beginning of the thread) I personally found the review of walmart's service to be incomplete. It fails to point out in any substantial way that the service was clearly launched (less than one week ago) as a "test phase" prior to a full launch planned for the spring.
The author could have either tried to make a more apples-to-apples comparison by measuring the service against that other other sites on their first week out, or at least summarized at the end of the walmart review making the callout and saying "I should review it again in a few months".
Personally, I'm taking a wait and see approach -- I suspect their catalog and feature set will both grow substantially over the next few months. Yeah, sure, the explicit lyrics will still be edited out, but since I don't listen to much music like that it won't really affect me much.
Why don't you tell us what you think is a good language and/or what makes Java so bad. Compare and contrast them if you want people to get any value out of your statement.
Funny. I actually have real-world experience, four years of which was at Rational, and I've used Rose on many occasions. I found it to be "feature rich" in the wrong places (aka bloated) and too thin where I actually wanted some functionality. Also, since you mention it, I found it to be a serious a resource hog.
I know UML is merely a specification language, and that how you use it it more important than any specific tool implementation. Also I believe 100% that if someone wants to spend the time to flesh out their system in UML, in extreme detail, that some day they will be able to fully code-generate a working system from it. Additionally I believe that the time required to do all the modeling and annotation that will be necessary for this will not be an improvement over just writing the code by hand in any other language.
In the real world (at least the one I've worked in) it's usually much more important to get working (even if incomplete) software out there NOW than it is to have perfect software much later. You need to change the design every time you turn around, and wrestling with updating diagrams and round-trip modeling/coding tools is madenningly tedious and slow.
Of course that's just my simple view on things.How I *actually use* UML is as a mechanism for communicating ideas "live" on a whiteboard to others who are trying to think through solutions in a team setting. And then I use less than 10% of UML's capacity -- mostly just class diagrams, and occasionally interaction diagrams.
I do NOT use it as long-lived documentation, because it goes immediately out of date. The only guaranteed-accurate documentation is the code itself (and not even code comments). Sometimes a high-level diagram can be meaningful for a while, and I'll make one for posterity sake, but mostly not.
How I *WOULD* (like to) use UML is for the visualization of existing code -- to analyze it from a 10KF view; to make pictures that'll help me understand the code and figure out how to improve/extend it. And then I'd throw it away when I was done. Unfortunately this is how I would LIKE TO use it, because pretty much all reverse engineering tools seem to fall short of accurate, or at least "sane" interpretations of what's going on.
I'm glad sombody's already posted this obvious counterpoint - I was about to. So... it's OK for people to use amimal parts to keep themselves alive, but not OK to put people parts IN animals -- even if it's to help us better understand how to keep people alive and healthy. Duh.
Hear, hear! Spot on! I've been distressed about this nonsensical treatment of PHP as an application language for some time now. It's past time for people to wake up and start treating the language for what it is...
The bottom is that if PHP can be directly compared to anything in the Java world, then it ought to be a comparison against JSP (without beans), because that's all it is -- a server side, page-level scripting language. Sure, you can do more with PHP if you write extensions in C or whatever, but then you're writing in C and not PHP!
Clicking the Swift Brochure link to a PDF (or the text only link right below it) on the main page cited above takes you to texts which state:
"Swift is built to be agile, to swiftly turn and point its instruments at the burst and relay burst locations within seconds. No satellite turns faster. Swift, in fact, is not an acronym; it is named for the small, nimble bird."
The first page of the PDF is actually an artsy image of the satellite superimposed with a swift.
That's mot in my experience with it on XP, so maybe it's a bug in the Linux edition. I'm on CNN all the time (well, slightly less than /.)
Agreed on that point - the business logic belongs in the application / business object whenever you can.
Personally I DO in fact prefer to use stored procedures, but not the way most do, as a place to write programs with flow control statements, etc. I use SPs as a means to provide "canned queries" (and of course updates etc).
This approach gives you the advantage of being able to persistence your data from any language, and the benefit of pre-compiled speed, and also control over transactions and authorization -- all good things.
The only time I readily put business logic in a SP is when a join won't do -- when doing it in the app would mean too many round trips (to look up and cross ref and look up and cross ref). Too inefficient.
Many people say the other time to put logic in SPs is when you want the exact same complex logic to be runnable from all platforms, such as with order placement. I disagree -- things like that should be made into service interfaces through SOAP, cgi, CORBA, or whatever floats your boat (just set a standard).
Yes, DB SPs can be trated like a service, but that approach is generally only suitable for internal apps, whereas true service interfaces can be invoked from outside more easily (and platform independently).
I thought I knew where Joel was going with the article, but was surprised when he didn't get there. I expected him to explain MS's loss of the Win32 API as the high-level .NET APIs (and VM) making the low-level Win32 API irrelevant.
And once everyone was developing against the new, high-level APIs of .NET, and MS no longer "needed" to support Win32 apps, that would open the door for others on other platforms to develop .NET compatible VMs for those, NON-MS systems.
And it's at that point that MS has totally lost control. Their former OS lock will have become irrelevant, and even the apps created by die-hard MS loyalists, for deployment only on MS, would suddenly be able to run on anything. (more or less not unlike Java)
I'm disinclined to agree with Joel about the future belonging to browsers. Sure, they'll still be very important and there will be many more web-based apps out there. But for rich client apps (which will surely still exist) they will not be locked to MS or any other os, as long as high-level, memory-managing VMs have become the norm.
MS puts patent restrictions on their XML interface so nobody can legally support it.
I personally own one of the backpack-style computer bags, which is great for carrying your laptop safely, plus is has a LOT of cargo space for other goods. When I'm just going to/from the car I do the "single shoulder sling" approach, but in airports, longer walks, or when I need my hands free I wear it like a regular backpack. One could easily bicycle to work with this one.
The author could have either tried to make a more apples-to-apples comparison by measuring the service against that other other sites on their first week out, or at least summarized at the end of the walmart review making the callout and saying "I should review it again in a few months".
Personally, I'm taking a wait and see approach -- I suspect their catalog and feature set will both grow substantially over the next few months. Yeah, sure, the explicit lyrics will still be edited out, but since I don't listen to much music like that it won't really affect me much.