4 ms·

Interesting. I wonder if this is the future of not only reducing the barrier to entry to software engineering, but setting up a new tier of software engineer f

Interesting. I wonder if this is the future of not only reducing the barrier to entry to software engineering, but setting up a new tier of software engineer for the unskilled. Rather, would software have lower barrier to entry positions that are driven by piecing together software components like they would a factory job. I'm sure for most software a team is only necessary,but as software dominates our future, perhaps this is the bridge to unlocking more opportunities outside of a higher skilled tier of manual coding. I'm just talking off the top of my head, so I may be totally off base. Either way looks interesting, and that futuristic interface is sweet.

stormbrew 9y ago
This is one of those things that always seems like it ought to be the future but for various reasons it doesn't take off. My high school computer class used a programming language called ProGraph[1] that looked a lot like this, but without the text representation, and it was neat but honestly it was more tedious to both read and write anything of even moderate complexity than a pure textual form. [1] https://en.wikipedia.org/wiki/Prograph https://en.wikipedia.org/wiki/Prograph
- indigo0086 9y ago
  For sure without the text representation, or manual code aspect a language would ultimately fail. I feel that languages that seek to "simplify" often oversimplify and leave those that require more granularity (most programmers) not to buy in. These languages can definitely offer a new paradigm on top of existing languages but it requires some fine control to get mind-share and ultimately take off. I'd say the real test of this, at least aligned with how I see it's future, is recruit not developers but non-devs and see how productive they can be in it, given they have a nice library of components to work from.
  - stormbrew 9y ago
    I fundamentally despise this concept of 'non-devs'. There's just a cyclical definition of non-devs as people who use non-dev tools and vice versa. It's extremely common to dismiss tools used by certain classes of people as non-programmer tools because of who's using them. Look at Excel, which is basically a visual programming language that probably more people know how to program in than know C. But because your boss or your project manager or your sales rep uses it it gets dismissed. Never mind that unlike these things that crop up every now and then people get real work done by programming their computer with it.
    - tentaTherapist 9y ago
      Excel's programmability is vastly underrated for some reason. It's easily one of the most high-level and successful languages ever, fulfilling a wide variety of roles for countless people, so simple that a child could use it, and so flexible that your boss probably does, too.
  - mch82 9y ago
    This got me wondering if the designers of the circuits that run software view textual programs as an oversimplification...
Skunkleton 9y ago
Visual programming languages lower the barrier of entry for _programming_ not software engineering. There are many mature and successful examples of visual programming languages that do just that (LabView, Scratch, etc...)
Paul-ish 9y ago
This is what I was thinking. Any critique of this approach may want to keep in mind this isn't necessarily going to replace what software engineers are doing now, but rather expand what is done by others by lowering barriers.

stormbrew 9y ago

This is one of those things that always seems like it ought to be the future but for various reasons it doesn't take off. My high school computer class used a programming language called ProGraph[1] that looked a lot like this, but without the text representation, and it was neat but honestly it was more tedious to both read and write anything of even moderate complexity than a pure textual form. [1] https://en.wikipedia.org/wiki/Prograph https://en.wikipedia.org/wiki/Prograph

indigo0086 9y ago
For sure without the text representation, or manual code aspect a language would ultimately fail. I feel that languages that seek to "simplify" often oversimplify and leave those that require more granularity (most programmers) not to buy in. These languages can definitely offer a new paradigm on top of existing languages but it requires some fine control to get mind-share and ultimately take off. I'd say the real test of this, at least aligned with how I see it's future, is recruit not developers but non-devs and see how productive they can be in it, given they have a nice library of components to work from.
- stormbrew 9y ago
  I fundamentally despise this concept of 'non-devs'. There's just a cyclical definition of non-devs as people who use non-dev tools and vice versa. It's extremely common to dismiss tools used by certain classes of people as non-programmer tools because of who's using them. Look at Excel, which is basically a visual programming language that probably more people know how to program in than know C. But because your boss or your project manager or your sales rep uses it it gets dismissed. Never mind that unlike these things that crop up every now and then people get real work done by programming their computer with it.
  - tentaTherapist 9y ago
    Excel's programmability is vastly underrated for some reason. It's easily one of the most high-level and successful languages ever, fulfilling a wide variety of roles for countless people, so simple that a child could use it, and so flexible that your boss probably does, too.
- mch82 9y ago
  This got me wondering if the designers of the circuits that run software view textual programs as an oversimplification...

Skunkleton 9y ago

Visual programming languages lower the barrier of entry for _programming_ not software engineering. There are many mature and successful examples of visual programming languages that do just that (LabView, Scratch, etc...)

Paul-ish 9y ago

This is what I was thinking. Any critique of this approach may want to keep in mind this isn't necessarily going to replace what software engineers are doing now, but rather expand what is done by others by lowering barriers.