4 ms·

This and I would go one step further: visual programming tools are like GUIs and they are the main reason that people can't code nowadays. When I switched back

This and I would go one step further: visual programming tools are like GUIs and they are the main reason that people can't code nowadays. When I switched back to a shell after 20 years I realized how much a GUI hurts, how much I unlearned to work with computers. After decades of Windows and OSX, I got Arch with i3 (so no desktop environment). I am mainly using text-based software like the shell, bash, tmux and vim every single day. Then, it's a very small step to program or to get a programmer because you are already programming in little steps here and there and every day (bash scripts, vim macros, etc.) and you deal all the time with text. Visual tools don't teach you to code, they introduce an unnecessary layer and create an even bigger insecurity when dealing with real code. Real coding with text is quite easy—and this should be the actual message. A very good example for an educative text-based coding environment which is even functional is Logo. But again, the best way to get into coding is to get an OS on your personal computer which focuses on the shell.

murukesh_s 9y ago
Coding with text is easy, but then why we there is a gap between getting a prototype/design done and the actual implementation? Text based coding is certainly more efficient in representing logic in a concise way, but the current set of frameworks and tooling on text based environments requires an exhorbitant amount of learning to produce a working application(e.g React), that's where the rapid application development tools like bubble comes in. In my opinion a combination of text and GUI should work together to provide the best possible efficiency for developers and other members of a team..
- waytogo 9y ago
  > why we there is a gap between getting a prototype/design done and the actual implementation? I think this has rather psychological reasons. There is a good book from Seth Godin called 'The Dip' which deals with the problem why most are fast in prototyping but not able to transform a prototype to an actual implementation ('to stick to the end'). However, I think there is nothing wrong with a prototype to fully-implement rate of 100 to 1. Prototyping is how people learn as well. Moreover, I am not saying that GUIs are per se bad. If I create vector-based graphics I need a GUI, when I browse the web I prefer HTML/CSS and a GUI's smooth scrolling over a text-based Lynx. Some programming languages like Java are better with GUI-IDEs but my main point was another one: That too much GUI in your daily life creates an unnecessary intimidation towards programming (if you are not a programmer yet).
  - murukesh_s 9y ago
    That's could be because we are accustomed to coding through text. Imagine asking a designer to use code for vector editing?
- bitwize 9y ago
  > Coding with text is easy, but then why we there is a gap between getting a prototype/design done and the actual implementation? The solution for this is simple, really: simply declare the prototype the working implementation, and put devs on the hook for maintaining it.
  - murukesh_s 9y ago
    By prototype, I meant static prototype or the visual design in tools like Balsamiq.
  - collyw 9y ago
    Don't see why you are being down voted. That always seems to end up happening.
- flukus 9y ago
  > Text based coding is certainly more efficient in representing logic in a concise way, but the current set of frameworks and tooling on text based environments requires an exhorbitant amount of learning to produce a working application(e.g React) That's a problem with this particular set of tooling then. In the past we've had drag'n'drop tools like visual basic which made rapid prototyping easy and you'd use the same tools for the final version. On the text side you've got similar tools like Qt and Gtk which allow you to slap together a prototype quickly and then use them for the final application. I always assumed react was quite similar.
flukus 9y ago
I'd go a step further again and say that GUI's are why people have no idea how to use computers anymore. A file is a concept the average user is becoming less familiar with, directories of files have almost disappeared entirely for them. The idea that you could manipulate an image in a paint program and have it updated in your word document is black magic, so tools like word and excel have to do everything they need. A story I've told before is my mum and the software that comes with her digital camera. This software is everything to her, if she want to back up the pictures she uses this software, if she want to print them she uses this software, she has no idea that the individual photos are just files on a disk. So what happens when she get's a new camera from a different manufacturer? Her knowledge is back to square one and she has to relearn all over again, this is what infantalising users has lead to.
- DonaldFisk 9y ago
  People know how to use computers just fine. Very few people need to know how the programs they use are implemented, or even the data structures they use. For most people nowadays, computers are for playing games, sending and receiving mail, watching videos, reading the news, shopping, and organizing your photograph collection. You don't need to know how to program to use a modern computer. Also, whether photographs or anything else use files stored in hierarchical directories is a historical accident. There are alternatives to file systems. For example, Squeak doesn't have files, hierarchically organized or otherwise, just persistent objects. EROS also took that approach.
- collyw 9y ago
  A file is just an abstraction at the end of the day. The hardware knows little more about a file than an ignorant iPhone user.
erikbye 9y ago
GUI or no GUI, apparently, people can either program or not, and it's been this way since the '60s, at least. https://blog.codinghorror.com/separating-programming-sheep-from-non-programming-goats/ https://blog.codinghorror.com/separating-programming-sheep-f...
- regularfry 9y ago
  The paper that post was based on was famously retracted: http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-two-humps-programming-aptitude-test-canned-for-overzealous-conclusion/ http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-...
  - erikbye 9y ago
    I see. I'd still posit that I don't think GUI usage and programming aptitude correlates. But, all the data I have is anecdotal.
dahauns 9y ago
I think this is a big case of cognitive bias (and get-off-my-lawn-ism ;) ). It's only a small step for you between using a text-based Linux and coding because you've already taken the huge frontload of internalizing the mountains of cognitive load and neccessary, but ungeneralizable knowledge that bash, vim & co. bring with them.
fsloth 9y ago
"Visual tools don't teach you to code, they introduce an unnecessary layer" I disagree. The main benefit of a visual tool (if implemented correctly) is that it exposes the constraints and the tool grammar to the user when implementing and not only when compiling. The difference is more or less of that with clay, and lego blocks. Yes, you can design a house with both (Lego house). Clay offers an infinite shape grammar, but if all you want is a lego house, then Lego blocks are much faster. Now, is the visual tool a cognitive crutch, or a bicycle for the mind, is another matter entirely.
DonaldFisk 9y ago
> visual programming tools are like GUIs and they are the main reason that people can't code nowadays. Lots of people can't code, and most programmers can't code well, yet very few people have been exposed to visual programming tools. I'd look elsewhere for explanations: (1) If those with more aptitude for programming are more likely to become programmers, and the demand for programmers increases, programmers with less aptitude have to be hired. (And the problem is made worse by excluding experienced older people when hiring.) (2) Whatever the reason, very few women become programmers now compared to the past, so almost half the population is being excluded. (3) There's less diversity in software now. There's only two operating systems (with the same user interface), and only imperative languages augmented with object orientation, mostly with C syntax, so programmers only learn to think in one way. (4) Personal computers nowadays are basically appliances which you can just use without programming, and that's what most people do. When they first became available, there was very little software on them and a far greater incentive to learn to program so that you could make them usable. For many people back then, programming became an end in itself. > Visual tools don't teach you to code, they introduce an unnecessary layer and create an even bigger insecurity when dealing with real code. There are different kinds of visual tools. Some visual tools (like, if I'm not mistaken, Bubble) are code generators so aren't designed to teach you how to code. Others are programming languages in their own right with no textual substrate, so there's no extra layer. It isn't as if you need visual tools to introduce unnecessary layers anyway. There are now frameworks and other unnecessary layers, which of course mean you need more programmers to handle the additional complexity, and then you have problem (1). If the software industry designed aircraft or bicycles, you'd never be able to rotate your plane or ride your bike uphill. > Real coding with text is quite easy No it is not. Programming is hard however it's done, even visually. Concurrent, type-safe programming is even harder, and it's here that visual dataflow programming would help. MIMD programming is problematic in textual languages because there's an explicit ordering of operations, and there are synchronization issues which have to be addressed. Switching to the dataflow paradigm avoids this, but dataflow is difficult to express in text. Also, textual languages make type inference and code optimization harder. > A very good example for an educative text-based coding environment which is even functional is Logo. But again, the best way to get into coding is to get an OS on your personal computer which focuses on the shell. I agree with you about Logo. But Logo originated and was closely associated with the Lisp community centred around MIT, which had a very different way of doing things from Unix approach you seem to favour: a listener instead of a shell, multiple windows, and a programming language very closely integrated with the operating system.

murukesh_s 9y ago

Coding with text is easy, but then why we there is a gap between getting a prototype/design done and the actual implementation? Text based coding is certainly more efficient in representing logic in a concise way, but the current set of frameworks and tooling on text based environments requires an exhorbitant amount of learning to produce a working application(e.g React), that's where the rapid application development tools like bubble comes in. In my opinion a combination of text and GUI should work together to provide the best possible efficiency for developers and other members of a team..

waytogo 9y ago
> why we there is a gap between getting a prototype/design done and the actual implementation? I think this has rather psychological reasons. There is a good book from Seth Godin called 'The Dip' which deals with the problem why most are fast in prototyping but not able to transform a prototype to an actual implementation ('to stick to the end'). However, I think there is nothing wrong with a prototype to fully-implement rate of 100 to 1. Prototyping is how people learn as well. Moreover, I am not saying that GUIs are per se bad. If I create vector-based graphics I need a GUI, when I browse the web I prefer HTML/CSS and a GUI's smooth scrolling over a text-based Lynx. Some programming languages like Java are better with GUI-IDEs but my main point was another one: That too much GUI in your daily life creates an unnecessary intimidation towards programming (if you are not a programmer yet).
- murukesh_s 9y ago
  That's could be because we are accustomed to coding through text. Imagine asking a designer to use code for vector editing?
bitwize 9y ago
> Coding with text is easy, but then why we there is a gap between getting a prototype/design done and the actual implementation? The solution for this is simple, really: simply declare the prototype the working implementation, and put devs on the hook for maintaining it.
- murukesh_s 9y ago
  By prototype, I meant static prototype or the visual design in tools like Balsamiq.
- collyw 9y ago
  Don't see why you are being down voted. That always seems to end up happening.
flukus 9y ago
> Text based coding is certainly more efficient in representing logic in a concise way, but the current set of frameworks and tooling on text based environments requires an exhorbitant amount of learning to produce a working application(e.g React) That's a problem with this particular set of tooling then. In the past we've had drag'n'drop tools like visual basic which made rapid prototyping easy and you'd use the same tools for the final version. On the text side you've got similar tools like Qt and Gtk which allow you to slap together a prototype quickly and then use them for the final application. I always assumed react was quite similar.

flukus 9y ago

I'd go a step further again and say that GUI's are why people have no idea how to use computers anymore. A file is a concept the average user is becoming less familiar with, directories of files have almost disappeared entirely for them. The idea that you could manipulate an image in a paint program and have it updated in your word document is black magic, so tools like word and excel have to do everything they need. A story I've told before is my mum and the software that comes with her digital camera. This software is everything to her, if she want to back up the pictures she uses this software, if she want to print them she uses this software, she has no idea that the individual photos are just files on a disk. So what happens when she get's a new camera from a different manufacturer? Her knowledge is back to square one and she has to relearn all over again, this is what infantalising users has lead to.

DonaldFisk 9y ago
People know how to use computers just fine. Very few people need to know how the programs they use are implemented, or even the data structures they use. For most people nowadays, computers are for playing games, sending and receiving mail, watching videos, reading the news, shopping, and organizing your photograph collection. You don't need to know how to program to use a modern computer. Also, whether photographs or anything else use files stored in hierarchical directories is a historical accident. There are alternatives to file systems. For example, Squeak doesn't have files, hierarchically organized or otherwise, just persistent objects. EROS also took that approach.
collyw 9y ago
A file is just an abstraction at the end of the day. The hardware knows little more about a file than an ignorant iPhone user.

erikbye 9y ago

GUI or no GUI, apparently, people can either program or not, and it's been this way since the '60s, at least. https://blog.codinghorror.com/separating-programming-sheep-from-non-programming-goats/ https://blog.codinghorror.com/separating-programming-sheep-f...

regularfry 9y ago
The paper that post was based on was famously retracted: http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-two-humps-programming-aptitude-test-canned-for-overzealous-conclusion/ http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-...
- erikbye 9y ago
  I see. I'd still posit that I don't think GUI usage and programming aptitude correlates. But, all the data I have is anecdotal.

dahauns 9y ago

I think this is a big case of cognitive bias (and get-off-my-lawn-ism ;) ). It's only a small step for you between using a text-based Linux and coding because you've already taken the huge frontload of internalizing the mountains of cognitive load and neccessary, but ungeneralizable knowledge that bash, vim & co. bring with them.

fsloth 9y ago

"Visual tools don't teach you to code, they introduce an unnecessary layer" I disagree. The main benefit of a visual tool (if implemented correctly) is that it exposes the constraints and the tool grammar to the user when implementing and not only when compiling. The difference is more or less of that with clay, and lego blocks. Yes, you can design a house with both (Lego house). Clay offers an infinite shape grammar, but if all you want is a lego house, then Lego blocks are much faster. Now, is the visual tool a cognitive crutch, or a bicycle for the mind, is another matter entirely.

DonaldFisk 9y ago

> visual programming tools are like GUIs and they are the main reason that people can't code nowadays. Lots of people can't code, and most programmers can't code well, yet very few people have been exposed to visual programming tools. I'd look elsewhere for explanations: (1) If those with more aptitude for programming are more likely to become programmers, and the demand for programmers increases, programmers with less aptitude have to be hired. (And the problem is made worse by excluding experienced older people when hiring.) (2) Whatever the reason, very few women become programmers now compared to the past, so almost half the population is being excluded. (3) There's less diversity in software now. There's only two operating systems (with the same user interface), and only imperative languages augmented with object orientation, mostly with C syntax, so programmers only learn to think in one way. (4) Personal computers nowadays are basically appliances which you can just use without programming, and that's what most people do. When they first became available, there was very little software on them and a far greater incentive to learn to program so that you could make them usable. For many people back then, programming became an end in itself. > Visual tools don't teach you to code, they introduce an unnecessary layer and create an even bigger insecurity when dealing with real code. There are different kinds of visual tools. Some visual tools (like, if I'm not mistaken, Bubble) are code generators so aren't designed to teach you how to code. Others are programming languages in their own right with no textual substrate, so there's no extra layer. It isn't as if you need visual tools to introduce unnecessary layers anyway. There are now frameworks and other unnecessary layers, which of course mean you need more programmers to handle the additional complexity, and then you have problem (1). If the software industry designed aircraft or bicycles, you'd never be able to rotate your plane or ride your bike uphill. > Real coding with text is quite easy No it is not. Programming is hard however it's done, even visually. Concurrent, type-safe programming is even harder, and it's here that visual dataflow programming would help. MIMD programming is problematic in textual languages because there's an explicit ordering of operations, and there are synchronization issues which have to be addressed. Switching to the dataflow paradigm avoids this, but dataflow is difficult to express in text. Also, textual languages make type inference and code optimization harder. > A very good example for an educative text-based coding environment which is even functional is Logo. But again, the best way to get into coding is to get an OS on your personal computer which focuses on the shell. I agree with you about Logo. But Logo originated and was closely associated with the Lisp community centred around MIT, which had a very different way of doing things from Unix approach you seem to favour: a listener instead of a shell, multiple windows, and a programming language very closely integrated with the operating system.