Hacker News Reader

I agree on some of your points but not all of them, and some examples are downright wrong ("Unix to OSX" has nothing to do with visualization and all to do with reliability). We are talking about visual programming, not generic interaction.

One thing that your examples tend to have in common is that they deal with describing states (documents), not modelling processes. Maybe that has something to do with it. Describing actions ends up effectively requiring flowcharts, which is what visual programming typically ends up being, and that gets painful and slow tremendously quickly. That's why visual programming tools do not endure: because once you get skilled enough, you will find them annoyingly constrained.

I can just point out that my niche (accounting) is arguably one of the oldest in computing. Visual programming to address accounting challenges has been tried over, and over, and over, and it failed. every. single. time. It's a massive target that everyone hopes to hit, because the jackpot is massive, but I would argue that it will never happen. Excel keeps winning because it doesn't even try to play that game: if you want to do anything beyond instant calculation, it gives you VBA and off you go. That's what people really want: if they are smart enough to want advanced process modelling, they are smart enough to learn how to write an "if" block.

> it is difficult to get a man to understand something when his salary depends on his not understanding it.

Believe me, there is also a large industry of programmers invested in visual paradigms; and their salary depends directly on not understanding the lessons of the past.

You make a good point re: states vs processes being more difficult. But on the other hand, I work with a team of marketers who set up fairly complex processes for dealing with inbound leads with no code marketing tools, so I don’t think it’s as far off as you think.

Just because your particular niche has certain complexities that make it more resistant to visual representation with current methods, doesn’t mean we throw out the whole no code movement.

After 20+ years of various companies trying to create a good no-code tool for html/css (eg dreamweaver, frontpage, etc), Webflow finally solved it IMO. So it can take a long time.

But I see no reason why this won’t travel further down the software stack eventually. And we shouldn’t be afraid of it like it’s a threat to us.

To be clear, Excel is a prominent and notable example of a visual programming tool. It uses a functional programming paradigm across a 2 dimensional data structure and has obviously been remarkably successful in it’s domain.

I understand your point, and I also see where toyg comes from. Let me try to phrase it another way:

Some tasks are inherently complex. Take data modelling as an example. Properly designing a database requires formal training. There's no way around it, and when you mask database design with a UI, you get the worst of both worlds. The complexity is there, unskilled users won't be able to tackle it, and the UI gets in the way of professionals with formal training.

Naturally, there is a continuum of tasks to be done, some can be solved with a poorly designed solution. If a user is empowered to generate a subpar solution, it is still better than no solution at all. That's the secret for Excel being the second best tool for any data manipulation task (for each task there is a better tool, but excel gets the job done in all of them).

The error here is selling visual programming tools as the next evolution step, which will phase out text UIs. It's not. It's a different tool, for a different use case, to be used by a different cohort of users.

> Some tasks are inherently complex.

My point isn’t that no code tools remove complexity. My point is that they make complexity easier to learn and deal with.

For example, Webflow, which is a no code tool for front end development of static sites, doesn’t eliminate any of the complexity of HTML and CSS.

It’s not easy or dumbed down at all. Most users need to watch tons of video tutorials to get started (if they don’t already know html/css).

But what the UI does do, is make it easier to learn those complexities.

It’s not offering a simplified set of dumbed down options. It’s offering a visual way to deal with all the complexities of HTML/CSS.

Personally, I’ve transitioned to building all marketing sites on webflow, not because it removes complexity (I want complexity!) but because dealing with the complexity is faster and easier with the tool.

> It’s offering a visual way to deal with all the complexities of HTML/CSS.

Uhm, a visual HTML designer, a field where we've not had any tool before (/sarcasm). But this is different! And you're totally not going to drop it once you've learnt the complexity and discovered all limitations. But hold on...

> to building all marketing sites

Ah yes. So the really complex stuff you'll still do with text. Got it.

It’s a tool for building static (what HN would call “marketing”) sites, why would I use it for something more complex?

There’s other no code tools for things like mobile apps and CRUD.

Ultimately, I think there’s a lot of fear in these comment threads when no code is mentioned, and it’s misplaced.

A rising tide raises all boats. The more we can empower people to create things and solve problems for people, the better off we’ll all be.

> There’s other no code tools for things like mobile apps and CRUD.

You're joking, right? There are loads. They all suck to various degrees, which is why they are not popular.

> Ultimately, I think there’s a lot of fear

Mine is not fear as much as frustration for having to waste cycles on stuff that will not endure.

Take Power Automation (aka MSFlow): it's very powerful, but not because it's a graphical environment; it's because we have an environment with a lot of APIs available without having to do anything. If MS gave me a blank editor with all those APIs preloaded, I would be 1000000x more productive than I am fighting with this goddamn half-broken flowcharty thingie. Meanwhile, nobody else in my team (all non-devs) want to even consider look at it. They'd rather brush up on VBA if they really need to do complex stuff. And it's a shame, because the API wiring is amazing and when things eventually run it's magical.

Repl.it with all those APIs preloaded would be so much more popular than PA, which I fully expect will eventually die a slow death like Yahoo! Pipes and friends.

> and when you mask database design with a UI, you get the worst of both worlds

Visual tools don't inherently mask complexity. They can do, and many do, which is useful for some use cases. And they can also make things visible that CLI or text based tools generally don't. In that regard, they can support developers to complete higher complexity tasks.

I'm one of those people who gets paid writing B2B CRUD apps, so I certainly have economic incentives to keep CRUD in the hands of professionals. However, back in academia I spent a few years working on two different no-code platforms whose target users were PhD researchers, ie smart people with a professional interest in learning how to leverage no-code platforms.

Both projects followed the exact same trajectory: users ultimately rejected the no-code platforms and sent all of the programming work back to professional developers. Now the professional developers were hamstrung by layers of abstraction designed for non-developers and both parties were miserable.

Excel is the shining example of no-code enabling non-professionals to create powerful tools on their own, but it may be the exception and not the rule. Ultimately the challenges of programming are not the code, but thinking abstractly about data, and that's a real skill that developers have trained and non-developers have not, and I don't think it is solvable with tooling.

What caused them to reject the platforms? Any specifics you can give?

Good question, I'd have to say the pay off per effort simply was not there for them. It didn't help that they had the option of simply dictating the work back to us lower status grad students.

So one might say the issues were more largely organizational. But these weren't lazy people, they were always looking at new tools and techniques. And they were struggling to get any payoff with the tools we had. Sadly the focus of the project was not visual programming, so we were not focusing on the users issues.

I guess that's also "no code" from their perspective!

The incentives might line up better for departments that can't get tech's attention.

>Every time we transitioned from a blank, text-command driven UI, to a visual one, we dramatically increased the percentage of the general population able to use something.

Is there an upper bound to the benefits of visual information in comparison to textual information when handling complex tasks so that when a task reaches a certain level of complexity it becomes easier to represent it in text as opposed to visually? The history of human communication would strongly suggest that there is.

Well, one could imagine a purely visual phone book, which contains a photograph of every person in town, as compared to a text-based phone book, which has every person in town listed by name.

The photo-based system would no doubt work great if the town had only a dozen people (all of whom know each other by sight), and probably work acceptably well for up to a few dozen. It's going to suck for a town with a thousand people, though, and be utterly unusable for a city of a hundred thousand.

From history, I’d say it’s actually the exact opposite.

Textual information reaches its upper bound far before visual information.

Think reading a recipe from a cookbook vs following along with a well done YouTube recipe.

The density of information delivered via video (visually) in addition to the word messaging (via audio) is roughly 10-100X that of an all text recipe.

...and with zero added effort from the human receiving the information, because our brain natively does the visual processing.

A recipe takes a minute to read, and then you can easily look up the steps as you need them. Following along a youtube video will be way more frustrating and require you to jump between parts of the video, replay parts you missed etc. I don't think anyone would prefer the youtube video unless they were complete beginners who don't understand cooking basics.

That’s the point though. Just as with programming, most people don’t understand the basics!

Sure, it’s faster to follow a recipe if you’ve spent ten years learning everything about cooking and food science.

Just as it’s easier to just code something if you’ve spent years learning how to code!

The point is to lower the barrier of entry, and deliver people a higher density of information faster and easier.

You learn how to code in a couple of weeks, learning all the non-coding knowledge required to actually write useful programs is what takes years.

For example, you can't write most useful programs without knowing what a pointer/reference is. Doesn't matter if you use visual programming or textual code.

>The density of information delivered via video (visually) in addition to the word messaging (via audio) is roughly 10-100X that of an all text recipe.

I think you need to show your work on that calculation - because I'm worried it's going to be one of those 'a video has so many bytes of information per frame etc. etc.' claims at which point I would have to wonder why I care what color Julia Child's blouse is when preparing an omelet.

I think this is overlooking how faster is to develop for command line interfaces, as well as to how widespread command line software is.

What are the numbers considered when making these assessments? With visual software, we got way more adoption, but this doesn't mean the amount of software necessary increased. I'm pretty sure the majority of the software out there is made of command line tools. The amount of software a developer uses is very large and entirely made of small command line tools, there are entire O. S. made purely for command line usage (any server distribution really).

Finally, there is another giant elephant being overlooked. Software is written in text because in the hands of a skilled professional, text can be VERY visual. I don't have to prove this, there is extensive amount of poetry written to confirm this. Effectively a piece of software written by a skilled professional will greatly benefit every reader, and readers of software are way more than writers of software even in the software development world.

Your example about HTML and CSS is also a very special example. Effectively HTML and CSS are tools to build UIs, not "generic software". There is a lot of software out there that doesn't involves humans at all. I mean, cron is on the majority of the servers out there, it has no UI.