Live data from Hacker News

Folk wisdom on visual programming

drossbucket.com

131–140 of 168 posts

Re: Folk wisdom on visual programming

#131
post #111

"A picture paints a thousand words, sure, but here's a thousand word essay. Try painting me a picture of it." I don't remember where I hard that, or close to it, but there's a lot of truth to it. There do seem to be some very useful visual logic and work flow tools, I hope that continues, but there's something magical about the ability of language to explain, describe and precisely define things. Maybe eventually we'…

What if the painting could change? What if you could touch the painting and explore it interactively? What if the painting engulfed all your senses, creating the illusion that you're in the painting? The journey of media from print to VR. While it'll certainly take more than 1000 words to program the painting in VR, if a million people see it, the value ratio is pretty good.

If you're starting from an essay, I doubt all those things together would he as helpful as adding a spoken-word audio track.

Or some text.

Re: Folk wisdom on visual programming

#132
post #119
post #110

I really like the node based workflow used by Blender for creating materials, compositing and now for generating geometry. This is where I think visual programming works best, realtime interactive tweaking of something actually visual. It's also generally kept simple and is powerful enough to get the job done. I've always hated LabView however, it grows too unwieldy quickly and the limited nature of its visual displa…

Arguably he's not wrong? I don't love LabVIEW but I make it work because their hardware is not bad compared with alternatives. Dragging two loops is pretty easy compared to figuring out threads and thread-safe communications in C++.

The point is that two empty loops should not be let run the CPU to 100%. But yes, the concept is nice at least.

I agree on NÍ hardware, it’s very solid. I’ve had good success using session based control with Matlab and also with Python.

Re: Folk wisdom on visual programming

#133

What I find interesting is that the human society and economy at large is able to function without there being any genius programmer who designed it all. If you look at roads, there is a road everywhere and still people don't get lost. But in a big chunk of source-code I do feel I get lost. I believe that may be because there are too few constraints when programming textually. Whereas when designing roads and bridges…

A city with streets is just a graph with 1-4 pointers per node. It is super simple in code, just a few lines, not sure how you could get lost in that. If you make code anything more complex than that then it isn't really equivalent to navigating the streets on a map.

> I believe that may be because there are too few constraints when programming textually

No that is not the issue, you can write extremely complex and useful programs in just 100 lines of code and you can translate those to visual programming easily with no improvement in comprehension. Code just takes long to read since it is so powerful.

Re: Folk wisdom on visual programming

#134

Yeah, this is going to be yet another "visual programming" topic. I sort of disagree with the intro to LabVIEW: > There are a large number of visual programming tools that are roughly in the paradigm of ‘boxes with some arrows between them’, like the LabVIEW example above. I think the technical term for these is ‘node-based’, so that’s what I’ll call them. There are NOT a "large number" of visual programming tools th…

Also, spreadsheets are certainly one of the most popular, widely used, easily accessible, and important visual programming languages. It's not an understatement to say that the economy would grind to a halt and civilization as we know it would collapse if spreadsheets suddenly disappeared tomorrow.

The article quoted one of my earlier posts on that subject, but I've written more about spreadsheets as visual programming, and cited Brad Myer's work and articles about visual programming languages, and there's more in the HN discussion of his classic 1989 paper "Visual Programming, Programming by Example, and Program Visualization; A Taxonomy," Proceedings SIGCHI '86: Human Factors in Computing Systems. Boston, MA. April 13-17, 1986. pp. 59-66:

https://news.ycombinator.com/item?id=26645253

DonHopkins 3 months ago | on: Spreadsheet is a software development paradigm

Spreadsheet certainly are visual programming languages: by any measure, by far one of the most common most widely used types of visual programming languages in the world.

HN discussion:

https://news.ycombinator.com/item?id=26057530

Taxonomies of Visual Programming (1990) [pdf] (cmu.edu)

https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf

https://news.ycombinator.com/item?id=26061576

Brad Myers' paper answers the age-old argument about whether or not spreadsheets are visual programming languages!

https://news.ycombinator.com/item?id=20425821

>DonHopkins on July 13, 2019 | on: I was wrong about spreadsheets (2017)

>Google sheets (and other google docs) can be programmed in "serverless" JavaScript that runs in the cloud somewhere. It's hellishly slow making sheets API calls, though. Feels like some kind of remote procedure call. (Slower than driving Excel via OLE Automation even, and that's saying something!) Then it times out on a wall clock (not cpu time) limit, and breaks if you take too long.

>A CS grad student friend of mine was in a programming language class, and the instructor was lecturing about visual programming languages, and claimed that there weren't any widely used visual programming languages. (This was in the late 80's, but some people are still under the same impression.)

>He raised his hand and pointed out that spreadsheets qualified as visual programming languages, and were pretty darn common.

>They're quite visual and popular because of their 2D spatial nature, relative and absolute 2D addressing modes, declarative functions and constraints, visual presentation of live directly manipulatable data, fonts, text attributes, background and foreground colors, lines, patterns, etc. Some even support procedural scripting languages whose statements are written in columns of cells.

>Maybe "real programmers" would have accepted spreadsheets more readily had Lotus named their product "Lotus 012"? (But then normal people would have hated it!)

I Was Wrong About Spreadsheets And I'm Sorry:

https://www.reifyworks.com/writing/2017-01-25-i-was-wrong-ab...

HN Discussion:

https://news.ycombinator.com/item?id=26668885

Excerpt from "Taxonomies of Visual Programming and Program Visualization", by Brad A Myers, 1990/3/1, Journal of Visual Languages & Computing, Volume 1, Issue 1, pages 97-123:

Spreadsheets, such as those in VisiCalc or Lotus 1-2-3, were designed to help nonprogrammers manage finances. Spreadsheets incorporate programming features and can be made to do general purpose calculations [71] and therefore qualify as a very-high level Visual Programming Language. Some of the reasons that spreadsheets are so popular are (from [43] and [1]):

1. the graphics on the screen use familiar, concrete, and visible representation which directly maps to the user's natural model of the data,

2. they are nonmodal and interpretive and therefore provide immediate feedback,

3. they supply aggregate and high-level operations,

4. they avoid the notion of variables (all data is visible),

5. the inner world of computation is suppressed,

6. each cell typically has a single value throughout the computation,

7. they are nondeclarative and typeless,

8. consistency is automatically maintained, and

9. the order of evaluation (flow of control) is entirely derived from the declared cell dependencies.

The first point differentiates spreadsheets from many other Visual Programming Languages including flowcharts which are graphical representations derived from textual (linear) languages. With spreadsheets, the original representation in graphical and there is no natural textual language.

Action Graphics [41] uses ideas from spreadsheets to try to make it easier to program graphical animations. The 'Forms' system [43] uses a more conventional spreadsheet format, but adds sub-sheets (to provide procedural abstraction) which can have an unbounded size (to handle arbitrary parameters).

A different style of system is SIL-ICON [49], which allows the user to construct 'iconic sentences' consisting of graphics arranged in a meaningful two-dimensional fashion, as shown in Figure 5. The SIL-ICON interpreter then parses the picture to determine what it means. The interpreter itself is generated from a description of the legal pictures, in the same way that conventional compilers can be generated from BNF descriptions of the grammar.

10. Conclusions

Visual Programming and Program Visualization are interesting areas that show promise for improving the programming process, especially for non-programmers, but more work needs to be done. The success of spreadsheets demonstrates that if we find the appropriate paradigms, graphical techniques can revolutionize the way people interact with computers.

DonHopkins 3 months ago [–]

https://news.ycombinator.com/item?id=26112751

Here's an example of a thread where somebody was fruitlessly trying to argue that a spreadsheet isn't a visual programming language:

https://news.ycombinator.com/item?id=22984831

>lmm 9 months ago | on: Maybe visual programming is the answer, maybe not

>If there was a visual programming language with anywhere near the popularity of Ruby, I'd be willing to consider that maybe the idea has some merit.

>DonHopkins 9 months ago [–]

>Excel.

>I could turn your argument around: If Ruby were anywhere near as popular, widely used, and successful as Excel, I'd be willing to consider that maybe the idea that Ruby is a viable programming language has some merit.

>But I won't, because whether or not something is a visual programming language isn't up to a popularity contest.

>Can you come up with a plausible definition of visual programming languages that excludes Excel, without being so hopelessly contrived and gerrymandered that it also arbitrarily excludes other visual programming languages?

[...] (TL;DR: he couldn't, since he was under the mistaken impression that Excel not programmable, and was less popular than Ruby...)

That thread was on an earlier discussion about a blog posting from 2020 about the same 1989 paper by Brad Myers that we're currently discussing.

https://news.ycombinator.com/item?id=22978454

https://blog.metaobject.com/2020/04/maybe-visual-programming...

>Maybe Visual Programming is The Answer. Maybe Not

>Whenever discussing problems with programming today and potential solutions, invariably someone will pop up and declare that the problem is obviously the fact that programs are linear text and if only programming were visual, all problems would immediately disappear in some unspecified way.

>I understand the attraction of visual programming, particularly for visual thinkers. However, it's not as if this hasn't been tried, with so far very limited success. Brad Myers, in his 1989 paper Taxonomies of Visual Programming gave, along with the titular taxonomy, a non-exhaustive summary of the problems, starting with visual languages in general:

[...]

Re: Folk wisdom on visual programming

#135

I worked on a visual programming tool from the late 90s to the early 2000s. The same problems apply then as they do now. There's an unwinnable war between keeping things simple and being complex-enough to do useful things. Visual stuff is great for simple things, but simple things aren't very useful. When you really need to do more complex things, you reach a limit very quickly. It becomes pretty unmaintainable very…

> But you can only go so far with Scratch vs other programming languages. A friend has built some pretty amazing stuff in Scratch, including a BBC Micro emulator (runs 60+ games), a few arcade game ports, and lots more [1]. As a developer myself, I find it quite surprising how far one can go with Scratch. (FWIW I've never coded with it myself) [1] https://scratch.mit.edu/users/RokCoder/

He seems to code an interpreter in scratch and then do the other stuff. Coding an interpreter is a lot easier than coding a game, and after that you really aren't coding in scratch anymore.

Complex minecraft works similarly, instead of working in redstone they make the logic gates and then the bit adders in redstone and then used programming as normal on those constructs.

Re: Folk wisdom on visual programming

#136
That was a good summary, was useful and really enjoyed reading it. The key takeaway for me, which really reified ideas I have about UI design tools, was this:

> At the opposite end of the spectrum is, say, an oil painting, which is also a visual medium but much more of an unconstrained, freeform one, where brushstrokes can swirl in any arbitrary pattern. This freedom is useful in artistic fields, where rich ambiguous associative meaning is the whole point, but becomes a nuisance in technical contexts...[elided]...Drag-n-drop editors arguably lose a lot of the features of ‘true’ languages by giving up structure, and more programmatic elements are likely to still use a constrained set of primitives.

That's the key problem afaics, and why UI design tools + codegen never works well outside of highly constrained situations. There are two conflicting practices: programming and visual design. And they overlap, obviously, but they don't properly mesh. The tool either goes in the programmatic direction, which makes codegen much easier but drastically curtails the ability to design properly. Or it goes in the design direction and makes codegen either very difficult or forces generation of absolute garbage code (for worst examples, see tools that generate enormous amounts of absolutely positioned HTML elements with inline styles on everything). And there's no real middle ground (not that this stops endless attempts to square the circle).

Re: Folk wisdom on visual programming

#137

Earlier quoted context omitted.

> But why did we bring it forward in the first place? Speculation: visual programming is a bit more beginner friendly, and more compatible with the brains of people designing stuff in UE. I wish blueprint was around when I was 13, messing around in UT’s version of UE and having no idea what unreal script could do. Visual language can break out all possible components into UI menus, just like everything else in UE. Vi…

Yeah let's ignore the cynical part. Whatever, it's already done and text scripting language is not coming back for UE.

Yes it is https://twitter.com/saji8k/status/1339709691564179464?s=20

Re: Folk wisdom on visual programming

#138
post #123

Earlier quoted context omitted.

I listened to a podcast a while ago where someone was speculating why programs processing data can't just be connected together like devices in a water system. Pumps, sinks, boilers, showers, etc. Or like electrical devices, just channel the data between them. It occurred to me that data isn't like water, or electricity. Those are generic resources that can largely be easily standardised and treated consistently by a…

"It occurred to me that data isn't like water, or electricity. Those are generic resources that can largely be easily standardised and treated consistently by any device." Well, electricity is not really easy either. There is a huge effort, to transform the current in the needed shape (voltage, current, frequency, DC vs. AC, smoothened... And water is also not just water, as it can be clean drinking water, or sewage…

That's exactly what I was thinking. Electrical engineering is a complex field and may seem easy from the outside simply because of its maturity, but I would argue is the hardest of the engineering disciplines to grasp as well as one of the most important.

Re: Folk wisdom on visual programming

#139

I worked on a visual programming tool from the late 90s to the early 2000s. The same problems apply then as they do now. There's an unwinnable war between keeping things simple and being complex-enough to do useful things. Visual stuff is great for simple things, but simple things aren't very useful. When you really need to do more complex things, you reach a limit very quickly. It becomes pretty unmaintainable very…

I posted this about Snap! recently:

https://news.ycombinator.com/item?id=27397375

Snap! is not simply all the usability and functionality of Logo, but also all the functionality and power of Scheme! Without any of the dumbing down of Scratch or Logo. Visual block programming. Turtle Graphics. Sprites. Lexical scoping. Lambda. Closures. Call/cc. Plus JavaScript integration and web stuff. With extensions for networking, AI, machine learning, speech synthesis and recognition, graph theory, robotics, Lego, Arduino, 3d graphics, 3d design, 3d fabrication, and 3d printing, embroidery, etc. ;)

https://dl.acm.org/doi/pdf/10.1145/3386329

History of Logo. Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 79. Publication date: June 2020.

6.2 Brian Harvey’s Personal Narrative on Snap!: Scheme Disguised as Scratch (pp. 49-50)

In 2009, the University of California, Berkeley, was one of several universities developing a new kind of introductory computer science course, meant for non-CS majors, to include aspects of the social implications of computing along with the programming content. Scratch wasn’t quite expressive enough to support such a course (it lacked the ability to write recursive functions), so Prof. Daniel Garcia and I thought "What’s the smallest change we could make to Scratch to make it usable in our course?" After 20 years teaching Structure and Interpretation of Computer Programs [Abelson et al. 1984], the best computer science text ever written, I knew that the answer to "what’s the smallest change" is generally "add lambda." I joined forces with German programmer Jens Mönig, who had developed BYOB (Build Your Own Blocks), an extension to Scratch with custom (user-defined) blocks, including reporters and predicates. At that time we were hoping to convince the Scratch Team to adopt our ideas, so we took "smallest change" very seriously. BYOB 3.0 [Harvey and Mönig 2010], with first class procedures and first class lists, added only eight blocks to Scratch’s palette. (The code is almost all Jens’s. My contribution was part of the user interface design, plus teaching Jens about lambda.) Version 3.1 added first class sprites with Object Logo-style inheritance. The Berkeley course, The Beauty and Joy of Computing (BJC) [Garcia et al. 2012], is also used by hundreds of high schools, especially since the College Board endorsed it as a curriculum for their new AP CS Principles exam. Unfortunately, some teachers have no sense of humor, and so BYOB version 4.0, a complete rewrite in JavaScript, was renamed Snap! [Harvey 2019]. [18]

Since Scratch seemed to be positioned as the successor to Logo, it was a goal for Snap! to restore the features from Logo that are missing in Scratch. The most important missing feature, the ability to define functions (and therefore to use recursive functions), is at the core of the new language. (Scratch introduced user-definable command blocks in version 2.0, but still doesn’t support user defined reporters.) Scratch had also replaced the structured text (word and sentence) functions with a flat text string data type. We wanted to be backward compatible with Scratch, so we implemented words and sentences as a library, defining first, last, butfirst, and so on. (Since block languages allow multi-word procedure names, and you don’t have to type the long name in order to use the procedure, the library names are, e.g., all but first letter of.)

Lists are first class and can be arbitrarily deep in sublists. The usual higher order functions on lists are provided; the graphical representation of lambda is built into the blocks representing higher order functions, and so beginning users can use higher order functions in simple cases without thinking hard about function-as-data at all, but the full power of lambda is available to more advanced programmers. It took us three tries to get the lambda design right, but we’re very proud of its pedagogic benefits.

Another of our goals for Snap! is to be a complete version of Scheme; it was largely as a way of planting that flag that we added call with current continuation, not taught in BJC (nor even in SICP) but used to implement tools such as catch and throw as library procedures written in Snap! itself. As of this writing, macros are only half-implemented; users can define procedures whose inputs are unevaluated (more precisely, thunked, since procedures are first class), but cannot yet inject code into the caller’s environment.

Snap! is lexically scoped, not least to allow the use of closures as objects, but a planned extension is "hybrid scope": variable names follow lexical scope, but instead of giving an error message when no binding is found in the lexical environment, the evaluator will instead look in the dynamic environment. So name capture is impossible, since the global environment is examined before the dynamic environment. (Only if a mistyped name matches another name can the user get the wrong variable rather than an error message. But mistyping can’t really happen in a block language.) This, too, is an effort to be a Logo as well as a Scheme.

Since Snap! is free software (AGPL), it has served as the starting point for at least a dozen significant extensions, including BeetleBlocks [Koschitz and Rosenbaum 2012; Rosenbaum et al. 2011] for 3-D graphics and 3-D printing; TurtleStitch [Mayr-Stalder and Aschauer 2016] for controlling sewing machines to do embroidery; Edgy [Bird et al. 2013] for studying graph theory; NetsBlox [Ledeczi and Broll 2016] for access to online data APIs and collaborative editing of projects; and others. The ability to write new Snap! blocks in Javascript, from the Snap! editor, has allowed many other user-level extension libraries, including support for robots and other hardware. Snap! features such as first class procedures help authors develop these extensions, even if the users of an extension don’t see that.

[18] For non-Anglophones, "BYOB" is used in party invitations as an abbreviation for "bring your own booze."

Also:

https://news.ycombinator.com/item?id=27396842

Brian Harvey's books are excellent! Definitely check out Brian Harvey's and Jens Mönig's latest masterpiece: Snap!, a block based visual programming language with the full power of Scheme, but ease of use of Scratch and Logo, written in JavaScript and tightly integrated with web browser technologies and libraries (including Ken Kahn's eCraftToLearn AI Programming for Kids extension using Tensorflow).

Snap:

https://snap.berkeley.edu/

AI For Kids with Snap!:

https://ecraft2learn.github.io/ai/

Snap! 6 is here, and it's all about scale (HN discussion of Snap! 6 announcement):

https://news.ycombinator.com/item?id=24781716

Brian and Jens earned the NTLS Educational Leadership Award for their work on Snap!:

https://ntls.info/ntls-educational-leadership-award/brian-ha...

>The National Technology Leadership Summit (NTLS) Educational Technology Leadership Award recognizes individuals who made a significant impact on the field of educational technology over the course of a lifetime. The NTLS consortium is a coalition of twelve national teacher education associations that collaborate to advance effective use of technology in schools. The NTLS Educational Technology Leadership Award is the coalition’s highest honor.

>Brian Harvey and Jens Möenig, working together, have had an impact on the field of educational technology that is as significant as any other. The origins of their work dates to development of the first computing language explicitly designed for children. In 1966 Seymour Papert, Wallace Feurzeig, Daniel Bobrow, and Cynthia Solomon created the programming language Logo. Logo, whose name is drawn from the Greek word for word, is both a technology and an educational philosophy. Its inception also resulted in the development of an educational community that exists to this day.

>Brian Harvey had the opportunity to learn from Lisp inventor John McCarthy and Scheme inventors Gerald Sussman and Guy Steele, among others, as a student at the MIT and Stanford Artificial Intelligence Labs. Throughout the 1970s he was a frequent visitor at the MIT Logo Group, and starting in 1981 he was part of design teams for microcomputer versions of Logo for the Apple II, the Atari 800, and the Apple Macintosh. A high point of his career was establishing the Computer Department at the Lincoln-Sudbury Regional High School, in Massachusetts, offering ungraded courses that attracted a community of kids with keys to the lab and the responsibility for making the facility meet everyone’s needs.

>In the 1980s he wrote the three-volume Computer Science Logo Style, published by MIT Press. These books showed that Logo could be used beyond elementary school to introduce serious computer science ideas to a broad and diverse audience. He subsequently taught at the University of California, Berkeley, where he was recognized with the Distinguished Teaching Award, the university’s most prestigious award for teaching. He was lead developer of Berkeley Logo, which because of its status as free software has become a de facto standard for Logo implementations. Since 2013 he has been Teaching Professor Emeritus.

>On a parallel track, Jens Möenig collaborated with Alan Kay, inventor of Smalltalk, and worked with colleagues from the Xerox Palo Alto Research Center (PARC) who invented personal computing. He subsequently contributed to development of the block programming language Scratch, one of the languages influenced by Logo.

>Brian Harvey and Jens Möenig then embarked upon one of the most productive collaborations in the history of educational computing, jointly developing the block programming language Snap! The Snap! reference manual notes, “The brilliant design of Scratch, from the Lifelong Kindergarten Group at the MIT Media Lab, is crucial to Snap!.”

>Snap! makes advanced computational concepts accessible to nonprogrammers. Brian Harvey notes, “Languages in the Logo family, including Scratch and Snap!, take the position that we’re not in the business of training professional computer programmers. Our mission is to bring programming to the masses.” The Beauty and Joy of Computing, tightly integrated with Snap!, does just that. This curriculum, developed at the University of California at Berkeley, is notable for attracting equal numbers of male and female students.

>The course is approved for Advanced Placement credit by the College Board. With support from the National Science Foundation, professional development has been provided to more than one thousand high school computer science teachers. One computer science teacher who introduced the curriculum in his high school reported that, “Before using Snap! and the Beauty and Joy of Computing curriculum, I had one section of computer science with 17 students. Three of the students were girls. Now I have three full sections of the course with equal numbers of male and female students.”

>Snap!, provided as free, open source software, has inspired development of many extensions. Among others, these include environments such as Snap4Arduino, which supports work with microcontrollers and robotics; mathematics microworlds for elementary children developed by Paul Goldenberg and his colleagues at the Educational Development Corporation; and iSnap, an extension developed by Thomas Price which suggests hints to students based on the work of other students. Another extension, TuneScope, designed to facilitate exploration of coding through music, is being developed by a collaborative team at the Society for Information Technology and Teacher Education (SITE).

>Snap! is a remarkable technological achievement. However, like Logo, its greatest achievement is arguably the educational philosophy that it draws upon and supports, and the associated community drawn together by this philosophy. In a very real sense, the Snap! community embodies the spirit of the early Logo community, extending it for the modern world. The NTLS Educational Technology Leadership Award, awarded to Brian Harvey and Jens Möenig, is presented in recognition of that accomplishment.

Re: Folk wisdom on visual programming

#140

I guess this is turning into another "visual programming" post. On my side I'd like to ask your opinion about Blueprint. It really turned me off back in the day and I always wonder why they couldn't optimize UnrealScript further instead of getting something totally new. Yeah for sure eventually everyone get used to it and it becomes the new standard ("How can I NOT do Blueprint? It's so splendid" type of posts will s…

I'm a programmer who does hobbyist gamedev and is a big fan of blueprints despite writing in text all day, for a few reasons.

* A lot of game engine functionality is extremely helpful but not discoverable. Visual scripting languages make the full spectrum of the engine's API more easily discovered

* Games are very stateful, and I find it is much easier to conceptualize this with blueprints than with code, which is better for functional stuff

* Collapsing nodes in blueprints is much more powerful as a documentation tool than collapsable lines of code. When you collapse nodes, you can show the execution running through long text high level descriptors of what hidden blocks are doing, and without needing to create a function for that task specifically.

e.g. code might do something like

def update_target():

target = find_new_target() # set target to nearest enemy unit

attack_pattern = choose_attack_pattern() # choose next attack pattern

execute_attack() # perform attack montage and execute effects

____________________

whereas the bp would be

Set next target to nearest enemy -> Choose next attack pattern -> Perform attack montage and execute effects

It becomes pseudocode that is bright and on the forefront of your attention, vs. most code editors which will highlight code and lowlight comments.

Post reply on HN