We need visual programming. No, not like that • Hacker News Board

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

#501

Post by tengwar2 » Fri, Jul 19, 2024, 8:53 AM UTC

ambyra wrote: post #208

d--b wrote: post #199

> One reason is because we think that other, more inexperienced, programmers might have an easier time with visual programming. If only code wasn't as scary! If only it was visual! Excel Formula is the most popular programming language by a few orders of magnitude and it can look like this: > =INDEX(A1:A4,SMALL(IF(Active[A1:A4]=E$1,ROW(A1:A4)-1),ROW(1:1)),2) Ahem. Excel is one of the most visual programming environme…

Excel could do this so much better though (and I think excel is the best candidate for visual scripting overhaul). The cell could have two parts; top parts is the function signature (other cells could reference by signature, or by cell number), bottom part is the code. Each cell is a function. People put huge unreadable basic functions in that tiny box. It's such an obvious pain point, surprised it's never been addre…

Most people don't seem to realise that you can put line breaks and leading spaces for indentation into formulae. Also while by default the edit line at the top of the window only shows one line, you can drag the divider down to show multiple lines.

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

#502

Post by wpm » Fri, Jul 19, 2024, 8:23 PM UTC

pstric wrote: post #492

wpm wrote: post #427

Earlier quoted context omitted.

Yes, most diagrams are frustratingly static, even those that over lay step by step information on top. I've found "diagrams" in my head, the mental models I use to reason about a problem, are not static. They are abstract machines, with cogs and gears and clutches and input shafts and output shafts, colors and arrows and action and movement, that work like a map for finding the solution, either directly, or at least…

> Yes, most diagrams are frustratingly static Most source code is static. In case you want to show a diff, you normally do this with a side-by-side view, regardless of whether you show the diff as textual source code, or as two diagrams. The transformations you sometime see in Youtube videos of moving and removing small bits of code to e.g. show the differences between a piece of functionality in an object oriented v…

Source code is of course a static thing. It's text. It only changes during commits.

Code is dynamic. It runs. The abstractions in the machine are doing things, which are changing things over time, in many different places, and it can be difficult to keep those movements all in your head without either a ton of practice, or lots of practice and some decent foundation to build off of.

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

#503

Post by roshankhan28 » Thu, Jul 25, 2024, 10:43 AM UTC

dhosek wrote: post #442

yoelhacks wrote: post #391

Earlier quoted context omitted.

I think there's a very important real-world nuance here. What you want with a programming language is to handle granular logic in a very explicit way (business requirements, precise calculations, etc.). What this article posits, and what I agree with, is that existing languages offer a more concise way of doing that. If I wanted to program in a visual way, I'd probably still want / need the ability to do specific ope…

My son who started programming at 7 pretty quickly moved on from languages like Scratch and Tinker. To the extent to which he uses them at all, it’s mostly to play games that are available in them. I’m not entirely convinced that he couldn’t have just started with Javascript or Python. It’s not like learning the syntax for a for loop¹ is that much harder than arranging the blocks in one of those block languages. ⸻ 1.…

tbh its pretty much a big thing when 7 year old is intrested in any programming language. i am not a parent but in this age of ipad kids , that is really impressive as a parent.

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

#504

Post by bboygravity » Thu, Jul 25, 2024, 2:06 PM UTC

duckmysick wrote: post #289

bboygravity wrote: post #163

Earlier quoted context omitted.

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?

I used Labview as part of a course in my degree (EE), so I already knew it.

If you know other languages I would say it's very easy to pick up. Probably the easiest out of any language out there. Instead of heaving to guess/learn the syntax, you just pick functionality from icons/lists and drag and drop.

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

#505

Post by reddit_clone » Thu, Jul 25, 2024, 9:59 PM UTC

reddit_clone wrote: post #402

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 !

Replying to my own comment.

The tool was called "Rational Rose" !