Slashdot Mirror

← Back to Stories (view on slashdot.org)

Sun Plans VB-Like Tools For Java

Posted by timothy on from the click-move-done dept.

CokoBWare writes "Sun apparently is trying to create a more VB-like experience for developer. This article from E-Week explains Sun's strategy in providing more VBesque tools for the Java developer. Can anyone say "Good luck Sun, and all the best"?"

3 of 52 comments (clear)

  1. Good idea. by WasterDave · · Score: 3, Insightful

    About four years too late, but hey.

    Dave

    --
    I write a blog now, you should be afraid.
  2. Re:Umm... why? by a+hollow+voice · · Score: 5, Insightful
    Having worked in a VB shop during college while studying Java in class, I'd say one of the big reasons people use VB in a business environment is because of the relatively quick turnaround for GUI apps. There are lots of apps that get developed in certain business environments solely as simple data front-ends because the people working with the data are non-technical and need a nice interface, but the app is only expected to be needed for a few months, or maybe even weeks, so a full development cycle in a more robust language really isn't practical. What you toss together in VB may not be as efficient or elegant as it could have been, but it generally does what it needs to do and gets done fast.

    Sure Java can do a nice flexible cross-platform (in theory, anyway) GUI front end, but even setting aside the performance issues of Swing, it generally takes a good bit more time to set up than a comparable VB interface.

  3. yart, anybody? by kungfoobar · · Score: 3, Insightful

    Does the world really need Yet Another RAD Tool? I can't speak fully for the Swing/Awt world, but the medium-sized Java projects I've been on was developed with textpad and apache ant.

    One of the beautiful things about Java/C++/SmallTalk is that you just can't start coding in it. For most people, it takes time to learn. But when you do learn it, and learn it correctly, you'll start to think in terms of coding for the sake of the interface, instead of coding for the hell of it.

    With RAD tools, it's super easy to start coding what's in your head at the time being, making up classes and methods as you go. Why not global variables? You may start out coding for a prototype. This prototype doesn't get redesigned, let alone refactored for the actual implementation ('cause hey, we already have it 50% done). Then the next thing you know, you have bloatware. Then you leave your job, and some poor schmuck has to maintain your 'code'.

    I didn't fully understand why you had to do so much in Swing to do so little until I read the GOF Patterns book. Most everything in the Swing API is an abstract pattern of some sort. When you create prototypes in Swing, you can't take a lot of things for granted. You actually have to think things through. And that, you just cannot rapidly do, initially.

    But when you do understand the fundamentals, prototypes can be refactored or easily redesigned to fit the implementation. Of course, this means that the software engineer that develops the prototype must have some working knowledge of the API or framework. It means that you just can't have your average "learn XXXX in 24 hours" code monkey start the software process. It means RAD is not a tool, but a way of thinking. I professionally build prototypes for projects using textpad and ant. Much of which can be extended for the actual implementation.