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

341–350 of 505 posts

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

#341

Post by swsieber »

galdosdi wrote: post #335
anonzzzies wrote: post #182

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…

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 ConcurrentModificationException and data races (not dead-locks or race conditions generally though).

Though, IIUC, Rust made early decisions about module structure that have really hindered compile speed, not necessarily tied to the type system.

Another big factor that makes rust slow would be optimizations & slow system linkers; it doesn't have a JVM that can warm up to optimize stuff.

Source: work with both Rust and Java on a daily basis.

Edit: The way the type system works out in general makes me far less worried about making sweeping changes in a Rust codebase than in a Java codebase, but there are still logic bugs that I miss occasionally. Still, it moves quite a big bug finding from "run the program and see" to "make it pass typechecking", which is quite a bit faster than compiling; you can typecheck Rust without compiling it.

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

#342

Post by taeric »

ryandv wrote: post #192
anonzzzies wrote: post #182

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…

With strong, expressive type systems such as those offered by Haskell, Rust, TypeScript, etc... I find that you front-load all of your debugging to compile/typecheck time. Instead of needing to experiment with your code at runtime through either manual or automated (TDD) tests, you are instead having a conversation with the compiler/typechecker to statically guarantee its correctness. There's just as tight a feedback…

Where I see this fall down, is when you aren't able to learn from the partial code along the way. The sooner you get an end to end setup running where input to the system causes a change to the output from it, the better you are for this sort of feedback. Note, not the soonest you get code to output. The soonest you get users giving input to users getting output.

If you are able to internalize everything, you are constantly simulating expectations in your head on what you are coding. Seeing where your expectations fall down on outputs is a valuable thing.

So, yes. If you fully understand everything already, the "paying it upfront" cost of exhaustive types is good. Amazing, even. Until you get there, you are almost certainly pushing off the feedback of learning where you do not fully understand the system.

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

#343

Post by taeric »

bandrami wrote: post #308
anonzzzies wrote: post #182

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 a fellow ancient person my only consolation is that the browser-based development experience most people now learn on is (with some path-dependent ugliness) basically the experience Smalltalk promised us in the 1980s and never quite delivered.

I'm confused? Smalltalk promised image based development where you could change things on the fly. That is far from what I typically see in browser based development.

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

#344

Post by airstrike »

galdosdi wrote: post #335
anonzzzies wrote: post #182

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…

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…

In my experience Rust still compiles as fast as I need it to (other than for the very first fresh compilation) and using language servers / rust-analyze I get literal instant feedback in vscode as I hit save. Not to mention autocomplete...

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

#345

Post by tdbgamer »

ta_1138 wrote: post #186
anonzzzies wrote: post #182

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 guess the upside is that you end up with a "compiler" that checks the invariants of your project and that domain rather than strict type safety. I love static typing, but I did try Elixir w/ Phoenix recently and was impressed that they were able to implement compile time checks like verifying that all redirects are valid routes, etc. Depending on what you're building, having a few small domain specific checks like that could be more valuable than strict type safety.

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

#346

Post by ozim »

btbuildem wrote: post #323

The article mentions a couple of what I think are relevant examples: state machine diagrams and swimlane diagrams. The author makes a great point in the beginning, how programmers don't need to visualize iterator or branch logic code. Language structures are what they are, we all learn them and know them; they're the tools we're familiar with and don't need a diagram for. What changes all the time (and what made the…

Problem is that “those who pay developers” don’t care to do it on their own. Heck bunch of business analysts don’t care about going down into gritty details - so even if you standardize stuff it won’t shorten the loop.

Only thing it will do it will rob developers of flexibility and level of control they can fix up any “management business grand plan”. Just like all those low code platforms do.

For me low code and visual programming platforms are the same - good ideas for someone who doesn’t understand technical details.

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

#347

Post by ozim »

lukan wrote: post #326
btbuildem wrote: post #323

The article mentions a couple of what I think are relevant examples: state machine diagrams and swimlane diagrams. The author makes a great point in the beginning, how programmers don't need to visualize iterator or branch logic code. Language structures are what they are, we all learn them and know them; they're the tools we're familiar with and don't need a diagram for. What changes all the time (and what made the…

"Language structures are what they are, we all learn them and know them; they're the tools we're familiar with and don't need a diagram for" If I have a nested construct of various control flow together with some ternary operators, I do wish for something more visual. Or trapped in paranthese hell. Yes I can read that. But it takes energy to decode it. if while (x<y×2)?(((x...

So I don’t see problem with just doing quick rewrite of the code to make it cleaner.

With GIT you can commit it locally and never publish not to offend team mates :). With IDE I can reformat text and refactor it in matter of seconds. But you can rewrite it enough to understand it.

For graphical representation there are no tools that can help you and also graphical representation will most likely be only worse.

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

#348

Post by ryandrake »

ben_w wrote: post #279
nottorp wrote: post #216

Earlier quoted context omitted.

Haven't worked with the iOS interface builder but i worked with Delphi ages ago. Question: how well does the interface builder thingy mix with interface in code? Can you easily lay out the basics of an UI graphically and then add code where the builder is too limited for what you need? Or it's the kind where if you start with the graphical builder you're stuck with just what the graphical builder can do?

It mixes well. Apple has two UI frameworks, UIKit and SwiftUI, and Xcode's Interface Builder handles each differently. The Interface Builder for each is built into Xcode, but the UI they present when editing is quite different — I'm unclear if they're both officially called "Interface Builder" or if people like me stuck with the same name for the new one because it's a thing for building interfaces. The older system…

Mixes Well is an understatement. I couldn't imagine writing any more than a simple toy app without it. I've experimented with building an iOS UI purely in code, and while it is possible, it is a painful, masochistic, and slow way to develop.

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

#349

Post by taeric »

Great article! I was afraid it was going to be trying to formalize a lot of visual ideas similar to what UML tried to do back in the day. Instead, this is a very nice catalog of many good visualizations that can be used as aids to the task of programming.

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

#350

Post by roland35 »

taeric wrote: post #342
ryandv wrote: post #192

Earlier quoted context omitted.

With strong, expressive type systems such as those offered by Haskell, Rust, TypeScript, etc... I find that you front-load all of your debugging to compile/typecheck time. Instead of needing to experiment with your code at runtime through either manual or automated (TDD) tests, you are instead having a conversation with the compiler/typechecker to statically guarantee its correctness. There's just as tight a feedback…

Where I see this fall down, is when you aren't able to learn from the partial code along the way. The sooner you get an end to end setup running where input to the system causes a change to the output from it, the better you are for this sort of feedback. Note, not the soonest you get code to output. The soonest you get users giving input to users getting output. If you are able to internalize everything, you are con…

I feel like you can partly get around this by slowly increasing type specifically over time. With strong type checking the risk of refactoring is low.
Post reply on HN