

Meet The Startup That's Going To Make Programming A Thing Of The Past - seminatore
http://www.sfgate.com/cgi-bin/article.cgi?f=/g/a/2012/04/27/businessinsidermeet-the-startup-tha.DTL

======
greenyoda
Hasn't "making programming a thing of the past" been the Holy Grail of
business managers since the 1970s? And yet, there are now more of us
programmers than ever before.

~~~
gm
Anyone who's old enough will remember several waves of "eliminate the
programmer". What was the first technology aimed to do that? COBOL?

Anyone have a good guess?

In any case, _yawn_ to the eliminate the programmer stuff. Been there, done
that, history repeating itself for the n+1 time.

here's what's always happened and what will happen again: the framework being
presented as a programmer antidote will come up short to business
requirements. then there will be a scripting layer built on top (if not
already). And _boom_ , you will need a programmer to implement these scripts
for customizations. So in reality you are just adding an abstraction layer to
the mix. Those layers are why we don't program in assembly anymore, they are
why we don't manage our own memory anymore (yeah lots of unmanaged tech out
there, etc). That's also why we don't compile stuff anymore (see previous
disclaimer). Etc. Just more of the same stuff, one more abstraction layer.

------
yzhengyu
I really wish them all the best, since I have seen the 4GL movement sputter
and grind to a halt and only remaining in enterprise software dedicated to
BPM, ERP, etc...

And as greenyoda pointed out, the last time this was done, it was driven by
business managers who thought they get get rid of the last link and make it
accessible to every employee.

All they did was to make things more complicated and get ensnared into the
trap laid by SAP, Oracle, et, al.

Of course, no one got fired for purchasing from big name vendors.

------
gte910h
So there is a visual programming language called LabView:

<http://www.ni.com/labview/>

As a person who really programs, what enevitably happened is systems grew to a
complexity (as all systems do that do real work) where real debugging became
an issue. So these labview programs made by people who don't program would
need debugging...and programmers couldn't really apply 90% of their debugging
toolkit to fix the programs, and the non-programmers couldn't fix the programs
either.

LabWindows ( a C extention to LabView) was a solution that SOMETIMES allowed
programmers to make components that would tie in and work in a fine grained
manner for the non-programmers to use in LabView, but in the end, the system
usually broke down repeatedly.

Having programmers make the LV programs wasn't any better, it was very slow,
and still suffered from inability to easily spot and fix mis-specification
errors, or to gently refine processes.

The _strangest_ part about the whole thing is that very small python scripts
EASILY replaced all of the LabWindows programs whenever we did that. So we
just taught a couple of the engineers a bit of python, had some interns
convert the rest, or really moved away from LV as a platform.

------
WalterSear
"Grump developer reading hacker news sorely wants to make bullshit article
headlines a thing of the past."

