291–300 of 505 posts
I'd say that's because drawing diagrams, especially in a non-fugly way, requires concentration on the action of drawing, and is slow, whilst typing requires almost no concentration, nor even looking at the keyboard, so it's much faster, even if less pretty.
Earlier quoted context omitted.
While I totally agree with you, I'm looking for a counter example. The only one which comes to my mind, is non trivial and quite fast for js/ts is this : https://github.com/tsoding/raycasting An implementation of raycast in a 2D canvas The dev tried to implement hot reloading, and you can see all the process there https://www.youtube.com/playlist?list=PLpM-Dvs8t0VZ08cYW6yqN... Even though I didn't measured the loadin…
Even the simplest type inference can cause typescript to stall for minutes. The problem is in the inference. That problem goes away when you're actually specifying types. Tooling should add typing automatically (not implicitly)
I am not sure that "We need visual programming". Just a couple of arguments against: visual programming struggles with scalability, introduces performance overhead, and lacks the flexibility of text-based programming. For me is a no-no. Maybe it helps beginners but for me it's just an additional layer of (unnecessary) complexity. The purpose of software engineering is to control complexity, not to create it.
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…
Are most people somehow working on giant repos?
I am not sure that "We need visual programming". Just a couple of arguments against: visual programming struggles with scalability, introduces performance overhead, and lacks the flexibility of text-based programming. For me is a no-no. Maybe it helps beginners but for me it's just an additional layer of (unnecessary) complexity. The purpose of software engineering is to control complexity, not to create it.
That said, I agree that visualising your code base might give additional insights. However that is not visual programming, that is code visualisation.
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…