Live data from Hacker News

We need visual programming. No, not like that

blog.sbensu.com

281–290 of 505 posts

Re: We need visual programming. No, not like that

#281

Earlier quoted context omitted.

Just encode your business logic in types first! Coq, Idris, or F* will certainly get the job done for you! /s

Yes, you do if you want to make money on decades timescales instead of some grifter vc 2 year thingy.

Unfortunately you end up selling your stuff to people building missiles and bombs that way—witness CompCert and Frama-C.

Re: We need visual programming. No, not like that

#282

Earlier quoted context omitted.

Why does laying out code on a line not cause a problem with spatial reasoning but a plane would? Are we somehow incapable of applying spatial abstractions when we move up into a higher dimension than 1?

Text doesn't use spatial abstractions. The problem with spatializing complex relationsips becomes very apparent when one tries to lay out graphs (as in nodes-and-edges) graphically. Unless the relationships are somehow greatly restricted (e.g. a family tree), the layouts become a total mess, as the connectedness of the nodes can't be mapped to distances and the edges by necessity have to make a lot of crossings on to…

I think you are limiting visual programming to some sort of a single graph that has everything together, but similar to how we split code into modules and files, visual systems can do the same, here's an example I keep showing in this thread of a visual programming system that works pretty well: https://youtu.be/CTZeKQ1ypPI?si=DX3bQSiDLew5wvqF&t=953

Re: We need visual programming. No, not like that

#283

Far more important is instant feedback and that’s getting worse all the time: with lisp, smalltalk, Delphi, forth things were instant. With typescript or rust etc, if the project is larger than hello world, the feedback is well, far from instant. Bret victor talked about feedback, not necessarily visual programming and for some reason we are making things worse instead of better. When I show a Common Lisp dev session…

As projects get bigger, things might get sadder. I worked at a certain large SF company that uses a lot of ruby, so most development was repl-based too. But this wasn't a boon but a curse, as the total lack of data format guarantees on the very large, critical monorepo meant a lot of uncertainty. What does this method really do? I guess we have to run it! It worked for this specific input... but will it work for any…

I think that OOP done right can address this problem through encapsulation of the logic.

One can make the case that a function can do the same. I agree, but a class is just a container for a set of related functions and state.

The problem with OOP seems to be that as a whole, devs are not that great at encapsulation and isolating domain logic.

Re: We need visual programming. No, not like that

#284
As so often, it starts with the wrong term. The kind of "visual programming" the author says they want is not programming at all, it's visualizing what has already been programmed. So this whole thing is a straw man based on obvious misinterpretation of what "visual programming" may mean. Unsatisfactory and disappointing.

Re: We need visual programming. No, not like that

#285
post #265

Earlier quoted context omitted.

I've seen methods with names like "get_value()" have extensive side effects. No type system can fix bad programming.

Of course I think we have all seen horrors like that - what I remember was his completely exasperated response not the technical details of the bug.

Complexity is mostly exponentiellt worse in the unknowns and you can not graph what you already know.

The point in the article is that when we read code we need another visualization to change or mental model. I can scan code and find most bugs fast, but when you are stuck a complexity by row/column sure would be handy to find overloaded assignments.

Re: We need visual programming. No, not like that

#286

Earlier quoted context omitted.

Let’s see it. To not be a total gobshite, go download these things and see what ‘instant’ really doesn’t mean. Instant means not wait 1 second; it means when I type code, it has results in milliseconds. None of these have that. Or show me a non trivial open source ts project that’s instant; doesn’t exist and I have literally no clue why people keep defending this stuff; you didn’t make it right? I would be embarrasse…

While I totally agree with you, I'm looking for a counter example. The only one which comes to my mind, is non trivial and quite fast for js/ts is this : https://github.com/tsoding/raycasting An implementation of raycast in a 2D canvas The dev tried to implement hot reloading, and you can see all the process there https://www.youtube.com/playlist?list=PLpM-Dvs8t0VZ08cYW6yqN... Even though I didn't measured the loadin…

Even the simplest type inference can cause typescript to stall for minutes. The problem is in the inference. That problem goes away when you're actually specifying types. Tooling should add typing automatically (not implicitly)

Re: We need visual programming. No, not like that

#287
I've designed a data analytics/flow processing thingy with, what I call it, a visually assisted editor.

The idea was to let the user write the code (sometimes in the Intellij's smart template style, sometimes as a code) and to show them the code represented as a graph, with some hints regarding type inference, possible scheduling, optimizations, etc. Then the user can run in-browser simulations on small sample datasets either provided by the backend or typed ad-hoc and the graph will be coloured accordingly. And then the user can do real runs.

The language is t-incomplete, so the representations are really sleek. In fact, some of the graph nodes can carry t-complete snippets inside, but their contexts are isolated and purity is enforced.

Unfortunately, I don't think it'll ever become foss or even public.

Re: We need visual programming. No, not like that

#288
I build one of these visual frameworks too (https://www.ondiagram.com/) and I agree completely with the author.

People think it's a good idea because it will save them time and I get many messages about different questions, use cases and support but the reality is you trade convenience for risk that something will be missing. What most people really want is a boilerplate for the SaaS, some building blocks for their UI and to not think about deployments.

VCs love this too, and many reach out, especially a couple of years ago. Maybe they know something I don't, maybe it was just phase.

Re: We need visual programming. No, not like that

#289
post #147

Earlier quoted context omitted.

I still have to find somebody who worked with LabView that does not hate it. It is a total abomination.

I don't hate it, I feel it's pretty good for talking to hardware, (understanding) multi-threading, agent oriented programming, message cues, etc. It's also fairly good for making money: the oil and gass industry seems to like using it (note: n = 1, I only did one oil n gas project with it).

How does version control work with Labview?

Also, since you;ve done only one project with it, how hard was it to pick it up and learn?

Post reply on HN