RE: Assembler vs C vs Flowcode ..3..2..1..Fight!

johnbeetem — Sat, 08 Feb 2014 21:35:15 GMT

There's an interesting discussion going on at Slashdot on this topic: Ask Slashdot: Why Are We Still Writing Text-Based Code?

Usually Slashdot has an interesting topic followed by pages of inane comments, but in this case many of the comments are worth reading. I've been interested in this topic for decades, and here's my general opinion: Graphical methods are terrific for illustrating programming concepts like conditions and loops, and they are IMO vitally important for helping people get started programming. When I was a student, we were required to draw flowcharts. (This was back when you could buy an IBM flowcharting template for US$1.) Most students found flowcharts a tedious burden and only did them at the end. I found flowcharts very valuable when I got started with assembly language, since it was easier to fix problems at the flowchart level, and writing correct ASM was much easier with a flowchart to base it on.

However, as pointed out by some of the comments chez Slashdot, while graphical methods are good for simple programs, when a program gets large the graphics quickly get too complex to be useful. In this case the conciseness of a textual programming language that's suited to the task is a huge advantage. In my case, this meant graduating from flowcharts to pseudo-code.

One commenter at Slashdot pointed out that people use graphics (schematics) to design hardware. Someone responded that this was true in the past, but nowadays complex digital design (ASICs and FPGAs) are almost always done in Verilog or VHDL, both of which look like programming languages. Again, logic diagrams and Karnaugh maps are IMO essential tools for learning logic design, but once you've mastered the basics I think writing Boolean equations in textual form is a lot more concise and a lot more productive.

The history of programming languages and hardware descriptions is littered with graphical methods that have been proposed and fizzled out. They tend to work well for small designs -- e.g., USB state machine diagrams -- but once you get beyond what you can fit on a few pages they tend to break down and text wins.

Maybe Flowcode will have better luck and be the first to overcome history. You never know.

JMO/YMMV a lot

RE: Assembler vs C vs Flowcode ..3..2..1..Fight!

DAB — Fri, 07 Feb 2014 21:53:45 GMT

Hi Ben,

Good post.

A little bit of history, the assembly coding was standard when I began programming and every computer was slightly different. It kept us on our toes.

C was created as a portable language so that you could write an algorithm and run it on another computer after compiling it on your target machine. Very useful in its day, but it still a pretty low level language.

I look upon Flowcode as a good modern object oriented language aimed at separating the user from programing details. For the average person I think this is an excellent approach to quickly allow novice programmers to implement their ideas regardless of the computer they are working on.

Granted, C would be faster, but I do not believe that speed is as important as it used to be (each assembly instruction taking several microseconds to execute) and the whole promise of computers were that they could be used by anyone.

From what I have seen, I find Flowcode very interesting. So I look forward to seeing additional posts showing its use.

I really like the infinity table. You did a very good job and it looks awesome.

DAB