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

We need visual programming. No, not like that

blog.sbensu.com

Post reply on HN
Print view View original

401–410 of 505 posts

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

#401

Post by galaxyLogic »

bryananderson wrote: post #387
PaulHoule wrote: post #355

What about all the flavors of UML? https://en.wikipedia.org/wiki/Unified_Modeling_Language#Diag... Note "executable UML" is not just about diagramming classes and filling in the behaviors but also activity diagrams, state diagrams, etc. My frustration with it is that the standards don't quite give you enough to make the revolution happen. For instance you should be able to construct a model for all of UML 2 based on…

Sometime in the early 2000s they generated all the flight code for the James Webb Space Telescope from UML diagrams with Rational Rose. Over a decade later they were still trying to unfuck all of it.

Any link for that? I think it's a good real-life example

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

#402

Post by reddit_clone »

twelvechairs wrote: post #20

Most of this isn't visual "programming" just good explanatory diagrams. I think it gets to a core issue which is a dichotomy between: - trying to understand existing programs - for which visuals are wanted by most but they usually need concious input to be their best - programming (creating new code) itself - where the efficiency of the keyboard (with its 1d input that goes straight to spaghetti code) has never been…

I forget its name, but there was an IBM graphical tool , with which you create UML diagrams and it in turn created code (Java IIRRC).

The intermediate representation was in sexp !

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

#403

Post by learn_more »

transpute wrote: post #150
learn_more wrote: post #92

Earlier quoted context omitted.

You might be interested in: https://schematix.com/video/depmap I'm the founder. It's a tool for interacting with deployment diagrams like you mentioned in your article. We have customers who also model state machines and generate code from the diagrams.

> Schematix provides diagrams as a dynamic resource using its API. They aren't images you export, they don't end up in My Documents. This isn't Corel Draw. In Schematix, you specify part of your model using a graph expression, and the system automatically generates a diagram of the objects and relations that match. As your Schematix model changes, the results of the graph expression may change, and thus the visual di…

Schematix is somewhat unique. Direct competitors? -- not exactly, but IT asset managers, DCIM, BC/DR tools, and CMDBs are all competitors to some degree.

Some of our best users are professional consultants who use us for a project which often introduces us to a new customer.

A Show HN would certainly be in order. Thanks for the thoughts!

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

#404

Post by buescher »

ar_lan wrote: post #365

I genuinely have no idea how to read the first diagram presented. Maybe I'm not the target audience - I'm significantly NOT a visual learner, but that first diagram is far more confusing to me than code/pseudocode.

That system, Unit, was on the front page here about a week ago: https://news.ycombinator.com/item?id=40900029

It's got a certain aesthetic appeal but I don't find it self-explanatory either.

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

#405

Post by douglee650 »

Perhaps some readers are traveled enough to have actually used this site owner's fortuitous product: Yahoo! Stores. You would pick commands from a button nav at the top, and then enter values. I came to realize, this was probably pretty heavily LISP based, but at the time the people I knew were creating these "visit data" like recursive structures in Java. Good times.

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

#406

Post by galaxyLogic »

When you look at a visual model of a program it should be easy to trivially understand what each visual element does. If that is the case it becomes a great tool for debugging why your program is wrong because in a visual model you could spot an element and say: Why is this element here?. Perhaps simple as "Why is this element so much bigger than others?"

If a tool provides just a view of some aspect of the code it is easy. If you require that the model be editable and will synchronize the changes from code to visuals and vice versa I think it is an order of magnitude bigger problem, less likely to scale.

Should you replace all the features of your favorite programming language with a tool for building visual models which don't really support the advanced language-features at all?

Consider that there are a myriad of different programming languages each claiming to be better than the others. But if you program by creating visuals first then of course you cannot do everything with it that you can in your favorite best programming language.

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

#407

Post by topspin »

sbensu wrote: post #49
chacham15 wrote: post #5

I think the difficulty here is addressing: who is your target audience? Depending on that answer, you have different existing relatively succesful visual programming languages. For example, game designers have managed to make good use of Unreals' blueprints to great effect. Hobbists use Comfy UIs node language to wire up generative AI components to great effect. As far as generic computing goes, Scratch has managed t…

[post author] I agree. On many domains you can find a great mapping between some visual representation and how the developer (beginner or not) wants to think about the problem. I personally don't see any one pictorial representation that maps to a general programming language. But if someone does find one, in the large and in the small, that'd be great!

> I personally don't see any one pictorial representation that maps to a general programming language.

I agree. What I've had in mind for a while now is very different from this.

What I envision is "text" in the sense that it's not a diagram, but more advanced textual representation. Over hundreds of years mathematicians have evolved a concise, unambiguous, symbolic notation for formulae, yet programmers are still using tools that are backward compatible with dot matrix terminals from the 60's: simple characters used to write lines in files.

Blocks, conditions, iteration, exits (return, exception, etc.,) pipelines, assignment, type and other common concepts could be represented symbolically. The interface would still be text-like, but the textual representation would be similar to mathematical notation, where the basic constructs of code are depicted as common, well understood, dynamically drawn symbols that programmers deeply inculcate.

Key properties include extreme concision and clarity of the "instruction pointer." Concision is crucial to reduce the cognitive cost of large amounts of logic. The latter is a thing that is entirely obscured in most visual programming schemes and also absent from conventional mathematical notation: the location of the current instruction is absolutely crucial to understanding logic.

I wish I had more time to elaborate what I have in mind, much less actually work on it.

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

#408

Post by Hunpeter »

doctorpangloss wrote: post #361
markus_zhang wrote: post #338

Earlier quoted context omitted.

TBH I think Blueprints gets used because it is forced upon the UE developers.

Blueprints gets used because the only alternative in UE, writing decade-old paradigm C++ code with 2 decades old macro DSL on top of it, is a lot worse. Unity has had multiple visual programming packages and people don't really care. Writing 2017 era C# paradigm code with an API resembling 2004 Macromedia Flash is not nearly as bad.

Its important to note that some successful Unity games were still made with visual scripting tools e.g. Hollow Knight used Playmaker.

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

#410

Post by roland35 »

swsieber wrote: post #341
galdosdi wrote: post #335

Earlier quoted context omitted.

Honest question as a java lover-- do rust and TS have slow compile times or something? Because java has a robust type system and yet I've never had any issue with it's compile times. And the parsing in the IDEs is so fast and good I can pretty much get all the feedback in real time. Ah, that's the luxury of using a battle tested language that other people have invested billions of dollars of effort into optimizing. D…

Yes - Rust has pretty slow compile times. It is perhaps my biggest gripe with it. You might define java as having a robust type system, but I would rate Rust's as significantly better. Several things in Rust I miss when working in Java: * Monomorphized types * Sum type and product types. Think sealed classes in java, but with better ergonomics * A really clever type system that prevents things like ConcurrentModifica…

I find using cargo watch really helps with my perceived compile times - it runs a check then build on every file save. By the time I open a new terminal to test things out it is ready to go!
Post reply on HN