April 22nd, 2013, 06:13 PM
Do software engineers take visual programming languages seriously???
Your opinion, please!!
I have been researching the use of a visual programming language (e.g. Limnor, Tersus, Lily) for rapid prototyping. Do serious software engineers consider this a valid approach?
April 22nd, 2013, 07:31 PM
Why wouldnt we? This is a great way to get rapid prototyping done. You can quickly get a concept up and running - and if you can modify the result without too much head-scratching involved then i can see it as a good way to get proof-of-concept of new development.
A weakness of this approach could be for anyone relying on this or using this in production capacity. There will always be an advantage to writing systems yourself. You will inevitibly need to correct/modify/maintain. But for simple things? Team building tools? Why not?
Bugs that go away by themselves come back by themselves
Beware - your loyalty will not be rewarded
April 22nd, 2013, 07:47 PM
To Recovering Intellectual (love that),
Thank you for the input. Seems like a general visual programming language (as opposed to those that are designed for a special application like music or games) would be good for a team project, because anyone on the team could quickly modify it. Does that make sense?
April 23rd, 2013, 06:50 AM
nice that you shared this and opened discussion about it. such posts leads to awareness . also checked these tools but have to still use it.
April 25th, 2013, 01:42 PM
There is nothing wrong in using tools for what they're meant to do. The problem is when people don't recognize that they're abusing their tools.
The biggest problem people have (myself included) is recognizing when it's time to stop patching the prototype (or the existing code) and take the effort needed to re-write, re-architect, or completely switch tools.
April 26th, 2013, 10:32 PM
Hmmm... Isn't that an operating system, not a programming language?
Visual Programming Languages are good at some things, but not larger software coding eg. operating systems. Laurence Peter Deutch formulated it this way:
The problem with VPL is that you canít have more than 50 visual primitives on the screen at the same time.
This is called Deutche Limit.
But to the question, does software developers take VPL seriously? As others replied, for rapid prototyping and proof-of-concept it is brilliant, but I think VPL are best when teaching kids to code and think as programmers.
Thank you. Hadn't heard of the Deutch limit. Useful concept.
In a word, No.
As soon as you try to tackle a non-trivial problem visual languages run out of acceptable ways of displaying the information you are trying to manage. The only way to reduce this is to rely on suitable abstractions -- and har har har, you wind up right back in the land of data/structural abstraction we've been trying for decades to make easier to deal with.
The best interface folks I know sometimes build dirty sample interfaces using visual builders to get widgets and things on the screen (think Qt Creator), and then write specific object handlers later to simulate the interface machine they imagine to be most suitable once they've got a solid lock on what they are really trying to achieve*.
The best software architects I know write functional pipelines without defining the details of the functions they are calling, then write some of the specific bottom-level utilities they know they will need as sort of a project-library, and then fill in the middle with the whole team. This doesn't fit OOP design, which pretty much excludes visual languages already -- as well as confounding visualization in general since most of a functional program is a series of orthogonal pipelines (that essentially map inputs to outputs).
There's just not much room in there for visual development outside of interface in any usefully complex program.
[*The bit about "what they are really trying to achieve" is probably the biggest conundrum in the real software development world. The thing is, no program would be that hard to write if you fully understood what you were trying to do when you start. That is a problem that no language, templating environment, or abstraction model can solve for you -- you simply have to explore the problem space thoroughly to know what you're after. So there is a cap on the utility of any particular tool that promises to make development rapid, because there is no tool in the world that can trvialize the comprehension of a previously unexplored problem space.]
August 19th, 2013, 01:24 AM
Visual Basic was designed to be easy to learn and use. The language not only allows programmers to create simple GUI applications, but can also develop complex applications.It is significant for software engineers to learn..