Visual Program - A response to "Why it's a bad Idea" by Mike Hadlow


After reading Mike Hadlow’s post on his blog titled “Code Rant: Visual Programming - Why it’s a Bad Idea” I feel I need to respond. Mike references block based coding such as the education tool “Scratch” from MIT. He points out three reasons why he thinks block based coding is bad. "1. Textual programming languages obfuscate what is essentially a simple process. 2. Abstraction and decoupling play a small and peripheral part in programming. 3. The tools that have been developed to support programming are unimportant."

What he doesn’t take into account is how we learn to code and think computationally. There is a process of learning how to identify a problem, pull a problem a part, break it down into abstract representational ideas, and build a step by step procedure to solve the problem. These parts can be looked at using a design thinking flow where we continually reconsider what we are doing and if out solution works. As we teach young students how to think computationally it’s helpful to have a system which can give immediate results. Block-based/visual coding is intended for the novice programmer. It’s there to give quick results without concern for syntax. The blocks don’t allow for syntax errors. 

I'm guilty of spending hours staring at code and going through debugging steps only to learn I spelled something wrong. When you start with code this sort of bug is enough to made you never want to code again. Perseverance does not happen over night. It's built incrementally. Block-based code allows for quick success of code without the headache.

Coding is very different from math but has similarities in how we grasp the concepts. Teaching coding requires giving the code concept to start. Allowing the student to modify the given code to see what happens. Then tasking the student to create something using the code and any other code or creative tools they can bring in. This iterative education process works best with visual code when there is no concern about syntax errors. The only errors are in how the code is put together. 

Do specifically address Mike's points:

1. Textual programming languages obfuscate what is essentially a simple process.
To a seasoned programmer this is very true. After I learned how to code with interpreted languages like JavaScript I've had that question of, "How does it really do that?". Even text-based code can obfuscate a simple process. Many languages have text functions build in, ie Left(data, count of characters). The function is slicer of the data inputed. This is not a concept a novice needs to know as they use the Left function. The real mechanics are hidden. Visual code also hides the actual functions. 

2. Abstraction and decoupling play a small and peripheral part in programming.
I firmly disagree with this. When building a realistic game you need to provide gravity. Well, how do you give an accurate representation of gravity? How do you designate where the floor is? How high can your character jump? These are abstract concepts which can be represented by an algorithm. Students can't figure it out unless they explore the abstraction of gravity. Yes things get complex but part of coding is creating efficient code which interacts seamlessly and simply with other code. Gravity can become a function with quick inputs making it fairly universal for each character. Complexity can increase by adding more features but well built functions help to Make sense of it. 

3. The tools that have been developed to support programming are unimportant.
The tools that have been developed to support programing are what make it accessible to others. I've programmed in a raw text editor for years. I torture myself so I memorize code functionality. For a novice the tools to support programming are what make the difference. I spend a lot of time playing with Google Apps Script. The intelligent suggesting of options support my exploration and make me more efficient. Google provides suggestions to code; intelligent suggestions. I know my variable is not initialized because of the color signifier. It's a pleasure to program with Google and it's the coding environment which keeps me coding there. I promote Google Apps Script because it's easy to code in. 

I will say block based coding can be improved by providing tools to transition from the visual code to a syntactical base. Allow me to pull in the code in visual format. But give me the ability to pull back the visual curtain. Block based code makes it accessible to those that may have previously been intimidated. And let's face it, we can type faster than we can drag in code. once we start getting the hang of it we lean to typing the code. 

Non-technical people need to have access to coding. It's up there with learning math, language, science, history and arts. our lives are split between our digital life and our physical life. I can cook and make a basic meal in my physical life. Coding is relative. People need to know how to craft some basic code to help them solve a problem in their digital life. 


And just for fun here's a Scratch project I did in 10 minutes to teach about conditionals.






4 comments:

  1. Hi Clay,

    While I essentially agree with what you're saying, unfortunately I think you have misunderstood Mike's key argument.

    Mike lists three things not as "reasons why block based coding is bad" but as misconceptions - incorrect beliefs which he attributes as the mistaken motivation for the development of visual programming languages. The three things are:

    1. Textual programming languages obfuscate what is essentially a simple process.
    2. Abstraction and decoupling play a small and peripheral part in programming.
    3. The tools that have been developed to support programming are unimportant.

    You and Mike both agree that 2 and 3 are incorrect beliefs.

    But are they really the only motivations of visual programming language designers?

    As you say, visual programming languages can be a great way to teach kids and novices how to start coding without being scared away or bored stupid fighting syntax errors and compiler warnings and there's evidence that this was the motivation behind scratch.

    One of Professor Alan Kay's life-long motivations as he developed etoys and Squeak smalltalk - precursors to the work on Scratch - was empowerment of the youngest of would-be programmers. Mike updated his blog post to acknowledge the role of this pedagogic purpose and its apparent success as best exemplified by Scratch.

    Now as for item number 1, you address it as being a claim about the amount of obfuscation that goes on in both visual and textual programming. I read his meaning differently; that the developers of visual programming languages believe that the complexity common in textual code is separable from the essence of programming, hence his phrase "essentially simple". The mistaken belief he describes is this: programming isn't complex but it's made complex by textual programming language. If visual programming language designers believe this, then, Mike claims, they misunderstand the true origin of the complexity. In his view, a visual language cannot avoid this complexity, either the visual programmer must manage it visually, resort to text or remain confined to a shallow solution space away from this essential complexity

    If you're interested in this famous subject, I recommend the original source on accidental vs essential complexity in programming: Fred Brooks' 1986 paper "No Silver Bullet". https://en.wikipedia.org/wiki/No_Silver_Bullet

    Visual programming tools are demonstraby good for teaching kids and I think Mike has subsequently agreed. Nevertheless Mike's statements about the motivation of visual programming designers serves as an attempt to explain why decades of grand predictions by certain advocates that text-based programming will be replaced by visual programming and the fact that this has not happened deserves some analysis.

    I'm also interested in the space of possibility for visual programming language design and I'm quite optimistic about the potential for tools that belong under this title today. Data flow lines and boxes ("pipes and filters") and Scratch-style lego blocks are common paradigms, but I think we can expand on these for purposes including and beyond educational and domain-expert tooling. Other names like "nocode" and "locode" seem to be in vogue now so who knows what future examples will be called nor exactly what form they will take.

    ReplyDelete
  2. Here's my Scratch projects: https://scratch.mit.edu/users/christo/

    ReplyDelete
  3. Does your business require reliable and experienced Hire Microsoft Dynamics Developers? We are ready to provide you with the best specialists on the market! Hire our company and get high quality outsourcing services. We work with companies from all over the world and have an excellent reputation!

    ReplyDelete
  4. Dive into the world of professional web development with "Angular JS Developer Wanted: Best Angular Developer Jobs". This platform connects skilled AngularJS developers with exciting job opportunities. Whether you're a seasoned professional seeking a new challenge, or a budding developer looking to kickstart your career, our extensive job listings offer a range of opportunities in various sectors. Discover the perfect role that aligns with your expertise and career goals, and take the next step in your professional journey today!

    ReplyDelete

Social Emotional Well-Being During Online Teaching and Learning

The world is a bit nutty right now because of the COVID-19 pandemic. Schools are switching to online learning and parents are working from...