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

311–320 of 505 posts

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

#311

Post by pjmlp »

frou_dh wrote: post #269
jampekka wrote: post #260

Earlier quoted context omitted.

The spatial (usually largely 2D in IC) constraints are a huge limitation for circuit design. I'm quite sure chips (or breadboards) wouldn't be designed like this if the physical world wouldn't force the geometry.

I meant more that the very concept of an IC is a good idea, and like a good abstraction in programming. I think pjmlp was getting at is that when using visual programming, a lot of people seem to turn off (or not cultivate) the part of the thought process concerned with creating good abstractions, despite it at least being possible to do so.

Exactly, packaging transitors into IC Modules, so to speak.

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

#312

Post by mapcars »

Nathanba wrote: post #31
SonOfLilit wrote: post #15

Earlier quoted context omitted.

Code is 1d with named links. Visual languages trade named links for global wiring, which is very cluttered for serious problem solving.

Code is not 1d, a single if() already creates another line that makes it 2d

How is `if` related with creating a new line? And how does new line make something 2D? If code was 2D you could write code anywhere in your document without juggling around spaces and newlines

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

#313

Post by sbensu »

tripzilch wrote: post #193

> Notice that the original code hasn't changed. The only information transmitted in the answer is the corrected diagram. That is because to the person asking the question, the diagram is a better representation of their mental model. As such, getting an corrected diagram has an effect on their mental model but looking at the code doesn't. This argument (that he tries to make several times in the article) does not hol…

[post author] You are right. Any "language" visual or other wise used for communication has to include the level of detail trying to be communicated. In the Rust memory layout example, Rust syntax doesn't spell out its memory layout in Rc definitions.

The point though is that the two users of the language _decide_ to communicate in a visual representation! Why is that?

They could spell it out in text, adding that lower level to the text, and yet they don't. That is a sign the users are thinking about it visually and the visual representation maps better to what they hold in their head.

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

#314

Post by sbensu »

classified wrote: post #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.

The distinction you are making is right. All those examples are examples of visualization, not of direct programming.

But why can't we use what today are visual representations of the programs as the actual programs? Can't we have the state transition diagram that today is a visualization of the code _be_ the definition of the state transitions? That is the question the post is asking

In other words, elevate the visualizations that we already use into programming, instead of programming with visualizations we don't use.

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

#315

Post by amadeuspagel »

amai wrote: post #299

Merging source code line by line is a solved problem. Merging visual code/graphs/graphics is often simply impossible. Also versioning and simply showing diffs become difficult problems with visual programming. That is why visual programming will never scale beyond small toy projects maintained by a single developer. That said, I agree that visualising your code base might give additional insights. However that is not…
Version control is not solved, and that it works line by line is part of the problem.

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

#316

Post by KronisLV »

bad_username wrote: post #179
KronisLV wrote: post #134

I really liked SourceTrail when it was a thing, as mentioned in the article. It's surprising that we don't have something like that for every language as a mainstream tool, to explore how bits of code relate to one another in a visual way. There are dependency graphs, e.g. in JetBrains IDEs, but none are as easy to use as SourceTrail. You know where visual programming really excels, though? In game development and wh…

I love the idea of SourceTrail, and there seem to be active forks of it. Do you happen to know which one is good/trustworthy?

This appears to be the only fork that's at least somewhat active: https://github.com/OpenSourceSourceTrail/Sourcetrail

But overall, there is little activity in any of the forks, without anyone necessarily spearheading the effort: https://github.com/CoatiSoftware/Sourcetrail/forks?include=a...

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

#317

Post by skydhash »

mharig wrote: post #303

My 2 €cents from a limited and outdated experience with visual programming tools: 1. Screens have limited size and resolution, and the limits get hit rather fast. The problem can be pushed away by zooming, by maybe an order of magnitude, but for a long living project growing in size and complexity, it will not be enough. 2. In text, near everything is just a grep (fzf,...) away. With the power of regex, if needed. Do…

There’s areas it’s good for: Beaten paths, modeling time-independent structures and things that are naturally 2D. Not so great for the final solution, but handy when you need to do quick iterations. Ex. the interface builder in xcode, the node system in blender, sound synthesis…

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

#318

Post by sbensu »

charleslmunger wrote: post #176
sbensu wrote: post #130

Earlier quoted context omitted.

That sounds super interesting! Did I understand correctly that the additional complexity came because you needed to emit optimal assembly? Or was implementing the logic from the state machine complicated enough?

Designing the state machine was hard. The implementation of that state machine was not that bad, because I'd spent so much time thinking through the algorithm that I was able to implement it pretty quickly. The implementation difficulty was optimizing the uncontended case - I had to do things like duplicate code outside the main CAS loop to allow that to be inlined separately from the main body, structure functions s…

That last point is super interesting: these diagrams never tell you much about the implementation or how it would perform.

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

#319

Post by snarfy »

jayd16 wrote: post #68

Anyone who mentions visual scripting without mentioning the game industry just hasn't done enough research at all. Its actually a really elegant way to handle transforming data. Look up Unreal blueprints, shader graphs, procedural model generation in blender or Houdini. Visual programming is already here and quite popular.

I used blueprint's predecessor 'kismet' quite extensively. I absolutely hated it. Give me unrealscript any day. Blueprint is popular because that's all you have. They removed unrealscript. To do anything even slightly complex you have to use C++ now.

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

#320

Post by WillAdams »

lioeters wrote: post #309
WillAdams wrote: post #278

Earlier quoted context omitted.

A quick overview of Interface Builder is Steve Job's demo for NeXT --- perhaps: https://www.youtube.com/watch?v=dl0CbKYUFTY where they discuss how dragging/drawing allows one to make 80% of the app, and the balance of 20% is one's own code.

> What we found a long time ago was, the line of code that a developer can write the fastest, can maintain the cheapest, that never breaks for the user, is a line of code the developer never had to write. > The goal here is to literally eliminate 80% of the code that every developer has to write for their app - because it's in common with every other app. And let them focus on just the 20% of their code that's unique…

I'd give a lot to have a graphical development environment which:

- allowed drawing a user interface as naturally as I used to use Altsys Virtuoso (or Macromedia Freehand which I moved to when my Cube stopped working)

- allowed programming the UI as naturally as HyperCard (and to a lesser extent Lisp) "clicked" for me

- was as visual as Google's Blockly (which as BlockSCAD: https://www.blockscad3d.com/editor/ I've used a fair bit)

- exposed variables in a mechanism like to OpenSCAD's Customizer: https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Customize...

Currently plugging away with OpenSCAD Graph Editor: https://github.com/derkork/openscad-graph-editor but hoping that: http://nodezator.com/ will become a viable option (still a bit bummed that I rolled and crashed w/ https://ryven.org/ though in retrospect, maybe I should try to tie that latter in to: https://pythonscad.org/ )

Post reply on HN