Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Folk wisdom on visual programming

drossbucket.com

Post reply on HN
Print view View original

141–150 of 168 posts

Re: Folk wisdom on visual programming

#141

Post by DonHopkins »

protomyth wrote: post #26
lliamander wrote: post #23

Earlier quoted context omitted.

In my experience, there are three things that visual programming tools make difficult: * abstraction * version control * test automation Those are also (in my opinion) the three techniques which separate proper "software engineering" from coding/scripting, which is why visual programming tools are pretty much universally unsuited for complicated projects. The one asterisk I would put on that is tools in which the vis…

abstraction I do wonder why some concept likes building chips doesn't make it into visual environments? I should be able to pass a chip with inputs and outputs to others.

Snap! supports user defined blocks, first class functions, lexical closures, eval/apply, and even call-with-current-continuation. See the summary and description I posted in reply to the GP.

Re: Folk wisdom on visual programming

#143

Post by bena »

hutzlibu wrote: post #125
simonh wrote: post #123

Earlier quoted context omitted.

I listened to a podcast a while ago where someone was speculating why programs processing data can't just be connected together like devices in a water system. Pumps, sinks, boilers, showers, etc. Or like electrical devices, just channel the data between them. It occurred to me that data isn't like water, or electricity. Those are generic resources that can largely be easily standardised and treated consistently by a…

"It occurred to me that data isn't like water, or electricity. Those are generic resources that can largely be easily standardised and treated consistently by any device." Well, electricity is not really easy either. There is a huge effort, to transform the current in the needed shape (voltage, current, frequency, DC vs. AC, smoothened... And water is also not just water, as it can be clean drinking water, or sewage…

I don't think he was trying to imply that coding was the only thing that's complicated.

I think it comes back to "No Silver Bullet" and what it has to say about accidental and essential difficulties.

There may be impurities in water, yes, and it can be several temperatures, but water is water is water. It's still chemically two hydrogen atoms connected to a single oxygen. We can define what pure water is. Having that definition allows us to define tolerances for how much "not-water" is in the water. What kind of pipe is necessary to deal with the not-water, etc. The essential difficulties of plumbing and water management are never really about the water, it's about how to deal with not-water.

Same with electricity, the way it moves may be differing, but it's still just electrons. There's no special electricity that will conduct through rubber. Again, we can define what electricity is. And again, having those definitions, we've moved our essential difficulties to the not-electricity part of the problem.

There is no standard "data". We cannot define what data is. Because it kind of is everything. It's a nebulous, abstract concept. It doesn't mean anything on its own. What we really want to do is process subsets of that data. And filtering to that subset is the essential difficulty. And then you have the issue that two consumers of data could want similar data, but not quite. So data's essentially difficulties come sooner and once you've transformed your data into water, you still have more essential difficulties to handle.

Re: Folk wisdom on visual programming

#144

Post by snidane »

The benefits of visual programming are usually that it captures the domain model better than using general programming languages without any guidance. Lot of the value is in well maintained integrations to other systems. Often, if the components of the visual language were released as a library or a framework, it would provide more benefit than having to drag and drop visual boxes and arrows which don't ever make it to version control or in some very clunky way.

Releasing the composable parts as text based library will not happen, because of economics. There is little money in creating libraries for the creators. All generated value would be captured by infrastructure, cloud platform providers.

With visual languages, the value can be captured by selling a no-code idea to non-programming folks and especially to enterprise with deep pockets wishing to get rid of expensive engineers.

Visual programming languages are an economical problem, not a technical one.

Re: Folk wisdom on visual programming

#145

Post by bena »

ping_pong wrote: post #4

I worked on a visual programming tool from the late 90s to the early 2000s. The same problems apply then as they do now. There's an unwinnable war between keeping things simple and being complex-enough to do useful things. Visual stuff is great for simple things, but simple things aren't very useful. When you really need to do more complex things, you reach a limit very quickly. It becomes pretty unmaintainable very…

Yeah, I think the endgame of visual programming tools is to just eliminate syntax errors.

You could probably conceive of C as a visual programming language if you spent long enough time. All of your keywords can be reduced to blocks, forcing people to insert the appropriate parameters. And once you allow people to define their own blocks, you're like a good portion of the way there.

The problem is that after a while, it is simply faster to type. The breadth of options available becomes too much to manage from menus and drag and drop interfaces. Already you're probably typing in some values and names. So you're constantly switching between keyboard and mouse.

At some point, the benefit of perfect syntax doesn't outweigh the loss of productivity from not being able to immediately use any construct the language makes available to you.

Re: Folk wisdom on visual programming

#146

Post by ianhorn »

What a fantastic post.

> Is ‘folk wisdom from internet forums’ worth exploring as a genre of blog post?

I’d add another yes here, if they’re all as thorough as this post.

I’ll add something that I didn’t see directly addressed in here: input methods strongly affect the medium.

Last year I struggled intensely with RSI. I got to the point where I couldn’t type for months. I tried some voice coding tools (caster and talon). Some aspects of this were actually better than keyboard coding. Unfortunately speech recognition is still at a point where it drove me insane with inaccuracies.

It also made me realize that with a keyboard, text code is incredibly natural. With keyboard+mouse, some new modes open up. With voice alone, I wanted to code a very different way.

I won’t go into detail, because this is already a long comment, but I believe that when we get speech recognition as reliable as typing, we’ll see an explosion of new programming paradigms.

Re: Folk wisdom on visual programming

#147

Post by mikewarot »

high_byte wrote: post #77
vvanders wrote: post #76

Earlier quoted context omitted.

Yeah, it's a pretty neat ecosystem. PLCs are kinda like the Legos of automation, incredibly easy to mix and match with a fair number of (insecure) standard protocols. I briefly toyed with the idea of building out some open source hardware/software but I didn't really seem like there was enough of a userbase to make it viable. Anyone using it professionally wants support and 10+ years of parts, most maker/hobby projec…

if you show them how insecure their current hardware is, it will sell. if it supports the old protocol but secure it should be transparent to them

You don't understand how industry works. If it works, you don't replace it, you get it fixed when it breaks. Nobody is going to willingly risk their factory, plant, etc. on some new supposedly better hardware. They'll keep what works going for 100+ years if they can.

It is totally logical for them to do so. The "security" threat can be band-aided over with a new firewall at the internet access. Replacing any component of the control system introduces an element of risk. Downtime is horrendously expensive, and can ruin a business. Only a fool would do anything to introduce the risk of downtime in the name of "efficiency".

Re: Folk wisdom on visual programming

#148

Post by jimsmart »

username90 wrote: post #135
jimsmart wrote: post #21

Earlier quoted context omitted.

> But you can only go so far with Scratch vs other programming languages. A friend has built some pretty amazing stuff in Scratch, including a BBC Micro emulator (runs 60+ games), a few arcade game ports, and lots more [1]. As a developer myself, I find it quite surprising how far one can go with Scratch. (FWIW I've never coded with it myself) [1] https://scratch.mit.edu/users/RokCoder/

He seems to code an interpreter in scratch and then do the other stuff. Coding an interpreter is a lot easier than coding a game, and after that you really aren't coding in scratch anymore. Complex minecraft works similarly, instead of working in redstone they make the logic gates and then the bit adders in redstone and then used programming as normal on those constructs.

In the case of his Beeb project, the 'interpreter' you speak of here is in fact a fairly full featured emulator. Although yes, the z-machine (Zork) is an interpreter of sorts.

But all of his other games - including the clones of arcade games - aren't emulators nor interpreters. They're just games, written from scratch (pun unintended), from the ground up, in pure Scratch.

After all, his day job is in fact games dev - and with 25+ years experience (I worked with him mid-90s), one could say he's a veteran in that field.

In reality, it depends on the what the game actually is, as to whether it is harder to implement than an emulator or an interpreter. e.g. I strongly suspect that Battleships was much easier to implement than the Beeb emulator was.

Re: Folk wisdom on visual programming

#149

Post by username90 »

hutzlibu wrote: post #125
simonh wrote: post #123

Earlier quoted context omitted.

I listened to a podcast a while ago where someone was speculating why programs processing data can't just be connected together like devices in a water system. Pumps, sinks, boilers, showers, etc. Or like electrical devices, just channel the data between them. It occurred to me that data isn't like water, or electricity. Those are generic resources that can largely be easily standardised and treated consistently by a…

"It occurred to me that data isn't like water, or electricity. Those are generic resources that can largely be easily standardised and treated consistently by any device." Well, electricity is not really easy either. There is a huge effort, to transform the current in the needed shape (voltage, current, frequency, DC vs. AC, smoothened... And water is also not just water, as it can be clean drinking water, or sewage…

Coding includes things like simulating water and electricity, hence it is more complicated.

For example, lets say you want to code to check that your electric setup is right. Then you implement the concepts voltage, current, frequency, DC AC etc, and run it to see what the end result looks like. Coding this is of course more complicated than learning about the concepts in the first place. And as have been said many times before, coding this system is often the easiest part of the job, then you have to add all the helper systems, the UI etc, and that is the really hard part that often is the reason projects fails.

Of course taking electrical engineering in college is way harder than software engineering or computer science, but that is because the software engineering and computer science tracks in college are usually a joke. If you had to be able to code systems as described above then it wouldn't be easier at all.

Re: Folk wisdom on visual programming

#150

Post by Lichtso »

Overall a really good essay.

I would have split the "Types of visual programming" in two main categories: Visual and graphical.

E.g. scratch is only visual because it is an over-the-top syntax highlighting but still has an AST like textual programming (they are based on hierarchies and sequences).

Spreadsheets are also sequential but in multiple dimensions.

Dataflow- / node- based systems on the other hand are actually graphical (graph-based) and can not be mapped to hierarchies in text directly.

Post reply on HN