A small but growing software company is rolling out a major upgrade that lets developers build standards-based Java and .Net applications with no coding. Kinzan Inc. this week will release Kinzan Studio & Server 4.0, a development and deployment environment that lets developers build enterprise applications through an assembly model by simply linking components in a drag-and-drop format.
Building Java, .Net Apps Sans Coding
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
ya – it’s like magic. no coding – EVER. lol – does it work with Frontpage?
All over again. (how many times did it ever succeed.. yep, none so far)
They are simply the next step in technologies that I have been using for some time now. 3 tier client server systems need quality code and there are very few programmers capable of writing that code.
At my last project we autogenerated a large amount of the application. Our database back end even did it on the fly. The front end work consisted of laying out our forms and setting up navigation. Changes were generally a matter of changing the model in our modelling tool and clicking a button.
Event the form layout can be autogenerated, there is a tool available now that does it.
Database code has been like this for some time now.
The only real coding work we did was coding the actual business rules that the business wanted. And frankly businesses don’t have complicated coding requirements.
What they do have is a need for application that are developed quickly and don’t suffer from stupid coding mistakes time and time again.
Cheers
David
Of course they work, but don’t tell that to the slashdweebs who cry every night because they can’t find jobs writing C code.
They only work when you are doing A, and you need to have B, and you don’t need C, or D.
In other words, very specific situations. These tools will never (at least not in the next 10 years) take work away from real programmers.
I would love to see the code churned out by that process. Maintainers anyone?
This looks to be half a step away from the Softwire (http://www.softwire.com/) technology you can use to build applications in Visual Studio. Softwire lets you build applications by dragging objects onto a grid and connecting I/O points of these objects to build the application, essentially wiring the appliction together like a schematic. Kinzan looks likt it simply takes this a step further making it even easier to build a web application with little programming experience.
Of course they work, the only problem is the claim “no code”. Better would be “no text”. Just because you have lines and symbols instead of words and characters it’s not less code.
The main problem with these things is that complex things can easily get overwhelming. Especially good error handling is what makes the difference between bad and good code, and when you have many conditionals and different code paths graphical tools don’t work at all, at least for me. Maybe there are people who find it helpful, but they should not expect any wonders…
These things tend to demo well, but then become Hell in the Real World. The Real World is much more difficult both from abstraction point of view and from the detail point of view. Walk in to any marketing department and you’ll find a huge list of unwritten and contradictory rules. Makes “Fizbin” rules look simple.
It all boils down to this (from the article):
Kinzan’s approach focuses on an MVC (Model-View-Controller) methodology, Wong said. MVC separates the application into business logic, presentation and data parts, which makes for more maintainable and reusable applications, Wong said.
“It’s easier to architect and build complex applications by sticking to MVC; it’s easier to maintain applications built using MVC, and it’s easier to enhance [them] built using MVC,” said Chris Hanson, bDistributed.com Inc. founder and president, in Hoffman Estates, Ill.
Yes. Of course. “Duh”.
The detail is all in the M’s, the V’s, and the C’s. And that’s where these things break down. If their granularity is too coarse, their not flexible enough for “real” applications. If their granualarity is too fine, then you may as well be writing Java dragging “for” blocks and “if” blocks on the screen..umm..no thanks.
And every business of any complexity can probably be modeled 70% with generic out of the box components, 20% of lightly tweaked components, and 10% of code that breaks pretty much any model I’ve seen yet and thereby becomes a necessary hack.
Take any large financial or manufacturing package, they all hit about 85-90% of a customers need and the consultants selling them know that once they get their foot in the door, they’ll get another boatload of work to get that last 10-15%.
This is how companies like IBM makes money. “Consulting” and “Integration”. IBM is well motivated to make this process efficient for its team to pull this off, IBM has $$$$$ to put into these kinds of technologies (anyone remember San Francisco?), IBM has been working this problem for DECADES, and the technologies haven’t changed that much over the years…yet…we’re still throwing man years at getting these kinds of applications barely right.
So, call me a sceptic, but this is Yet Another Wheel that’s been made before, and they don’t work for a reason.
It may well be a good tool, especially if for some bizarre reason you Java <-> .Net portabilit (yea, whatever), but the glossy lit is simply that, glossy lit.
No silver bullet here. Move along.
>They only work when you are doing A, and you need to have >B, and you don’t need C, or D.
>
>In other words, very specific situations. These tools will >never (at least not in the next 10 years) take work away >from real programmers.
The current state of the art does not create your application for you. But leveraging what they can do is extremly powerfull.
A relational persistence engine will handle all your object to database needs.
A good framework will give you logging, security and many other standard application requirements.
Programmers can then concentrate on what the business needs to be successfull.
>I would love to see the code churned out by that process. >Maintainers anyone?
The code does not require maintenance. It is the model that you maintain.
If the generated code is buggy you fix the generator. Generators are a difficult area to program but once they are done right they require very little maintenance.
>Of course they work, the only problem is the claim “no >code”. Better would be “no text”. Just because you have >lines and symbols instead of words and characters it’s not >less code.
It is a step above the code. You develop a model, the code is an expression of that model.
>The main problem with these things is that complex things >can easily get overwhelming. Especially good error >handling is what makes the difference between bad and good >code, and when you have many conditionals and different >code paths graphical tools don’t work at all, at least for >me. Maybe there are people who find it helpful, but they >should not expect any wonders…
I think you are looking too low level here. You are not drawing your code.
This type of programming ‘language’ per say can work in certain instances. Take a look at Labview by National Instruments http://www.ni.com/labview/ . It’s main purpose is for creating data acquisition and analysis app’s but can be used for lots more with a little creativity with the VI’s. It’s been around for a while and works great for its purpose (especially when used with NI hardware, fancy that). If Kinzan can be used in a niche business segment to increase app development productivity, all the better, just stick to that niche.
Why don’t you do yourself a favor and request an evaluation copy before posting comments?. It is not a code generation machine as some of you have suggested. I tried it myself and have to admit it is something I haven’t seen anywhere before!