Project Ace: Fast Development Applications

Post #48,140 by bluke 8/5/02 11:00:06 AM Reply	Project Ace: Fast Development Applications [link\|http://research.sun.com/features/ace/\|Project Ace: Fast Development of Flexible, High-Performance, Enterprise Applications] Anyone heard of this? What do you think of this? I don't see how this is different from Case tools and 4GL's which promised exactly the same thing and did not deliver.
Post #48,155 by wharris2 8/5/02 12:11:01 PM Reply	Sorry, sounds like YAMB: Yet Another Magic Bullet Ace is unique because it provides a natural way for developers to describe the "intent" of the application precisely, as opposed to manually writing the code that implements that intent. Oh, right. It may be a 4GL-like higher-level abstraction than bare Java or C, but "a natural way for developers to describe the intent of the application precisely"? GMAB. That still doesn't even touch the most common problem today, which is users either giving you spurious wish lists, not really being able to describe what they want, describing their current system when what they really want/need is a new and improved system, changing requirements, and half a dozen other of the fun things normal developers have to run through. The day I can get someone to tell me what the actual intent of an application is, and all the goals and hopes for a particular project, will probably be the day I die of a heart attack. The lawyers would mostly rather be what they are than get out of the way even if the cost was Hammerfall. - Jerry Pournelle
Post #48,282 by JayMehaffey 8/5/02 10:00:15 PM Reply	Looks like an old bullet to me I read over the white papers they had at the site, and this looks like a case tool. Back in the early 80's when everyone was talking about language and computer generations, case tools where one of the proposed 5th gen languages. The idea of the case tool was to create a language for specify a program at a high level, incorporating buisness logic and so on. The case tool would then build the code needed for the application, usually outputting source code that the developers then could touch up to add features the case tool didn't cover. Case tools where all the rage for a while in some industries, mostly heavily regulated ones, where every company needs similar applications and has similar internal process. Nobody could ever break out into the general buisness market though, and the idea eventually died off. Jay
Post #48,178 by tuberculosis 8/5/02 1:41:18 PM Reply	Sun's 5th Ace If traditional software development tools keep getting better, why does software development keep getting harder? The fact is, enterprise application development today is still characterized by frustration. Programmers feel it as they struggle to create dynamic applications using manual coding tools. You mean like the struggle of trying to create dynamic applications in static languages like Java? -tb IT managers feel it when senior executives suddenly change the core requirements of a software project that has been in the works for months. And executives feel it when they see the company miss a key business opportunity because the IT department couldn't build the needed software in the required time frame. Object-oriented development and code reuse techniques were supposed to increase the productivity of developers. But today, programmers still face huge and growing backlogs of development projects. Clearly, it's time for a better option. It's time for a technology that can cut development cycles, simplify transitions from one architecture to another, and improve application performance and scalability--all at the same time. Reads like an ad for Smalltalk. I agree there's a problem. But bandaids on Java aren't going to cut it. To create dynamic systems, you need dynamic languages. Funny how that hasn't sunk in at Sun though. Nothing will come of this. You can safely ignore it. I am out of the country for the duration of the Bush administration. Please leave a message and I'll get back to you when democracy returns.
Post #48,245 by ben_tilly 8/5/02 6:59:12 PM Reply	Agreed, and... a fundamental lesson that I see IT never learning is that languages that scale to 10x as many developers but require 10x the code for the same task are a loss. You need more people to get the same amount done. How stupid can you get? But it is good for the project manager who wants to increase the size of their personal fiefdom... Cheers, Ben "Perl is like vice grips. You can do anything with it, and it's the wrong tool for every job." --Unknown
Post #48,250 by deSitter 8/5/02 7:20:10 PM Reply	Re: Agreed, and... Funny, the image I had was a lot of captured slaves, with body shoppers as slave traders. -drl
Post #48,237 by tablizer 8/5/02 6:35:11 PM Reply	Pet Store benchmark The Java Pet Store application provides typical e-commerce functionality: various views of products and services, order taking, credit card processing, shipping information, and so on. Initially, the Java Pet Store application was created by a Sun developer as a means of displaying all the various features of J2EE technology. The first implementation contained 14,273 lines of code and took six months to develop. Following the successful deployment of the Java Pet Store application, Microsoft engineers decided to use the reference application to show off the capabilities of C# and .NET, and carefully rewrote the application using 3,484 lines of hand-crafted code. By contrast, a single developer has created an Ace specification of the Pet Store application consisting of just 224 lines of hand-written code--less than one tenth of the size of the Microsoft version. The Ace Pet Store application can be deployed using either a 2-tier or a 3-tier architecture. Best of all, the new Ace specification took Sun's developer only a week to complete. I wonder if this is not a case of fitting the chip to the benchmark. Further, they have shifted what could normally be in libraries into an IDE it seems. This is "hiding" lines of code, and may limit flexibility. At least with code, you can copy and change it if the generic version turns out not to be as generic as hoped. It is easy to make tools to generate typical add/change/delete/list screens. However, the devil is in sticky customizations and tuning UI naunces to fit finicky users or PHB's. Overall, the article is very brochuree. They promised the very same crap with the very stuff they are attacking here to justify their "new" solution. It is like MS bashing Windows 95 to justify Windows 98, and then bashing 98 with the very same claims to justify W2K, etc. (Faster, self-configuring, crash-proof, more toys, etc.) One part says something like, "This will finally deliver on the promise of write-once-run-everywhere and code reuse that Java originally promised." (paraphrased) The marketing treadmill never stops. ________________ oop.ismad.com

Welcome to IWETHEY!