Earlier quoted context omitted.
Just encode your business logic in types first! Coq, Idris, or F* will certainly get the job done for you! /s
Yes, you do if you want to make money on decades timescales instead of some grifter vc 2 year thingy.
We need visual programming. No, not like that
281–290 of 505 posts
Re: We need visual programming. No, not like that
#282Earlier quoted context omitted.
Why does laying out code on a line not cause a problem with spatial reasoning but a plane would? Are we somehow incapable of applying spatial abstractions when we move up into a higher dimension than 1?
Text doesn't use spatial abstractions. The problem with spatializing complex relationsips becomes very apparent when one tries to lay out graphs (as in nodes-and-edges) graphically. Unless the relationships are somehow greatly restricted (e.g. a family tree), the layouts become a total mess, as the connectedness of the nodes can't be mapped to distances and the edges by necessity have to make a lot of crossings on to…
Re: We need visual programming. No, not like that
#283Far 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…
One can make the case that a function can do the same. I agree, but a class is just a container for a set of related functions and state.
The problem with OOP seems to be that as a whole, devs are not that great at encapsulation and isolating domain logic.
Re: We need visual programming. No, not like that
#284Re: We need visual programming. No, not like that
#285Earlier quoted context omitted.
I've seen methods with names like "get_value()" have extensive side effects. No type system can fix bad programming.
Of course I think we have all seen horrors like that - what I remember was his completely exasperated response not the technical details of the bug.
The point in the article is that when we read code we need another visualization to change or mental model. I can scan code and find most bugs fast, but when you are stuck a complexity by row/column sure would be handy to find overloaded assignments.
Re: We need visual programming. No, not like that
#286Earlier quoted context omitted.
Let’s see it. To not be a total gobshite, go download these things and see what ‘instant’ really doesn’t mean. Instant means not wait 1 second; it means when I type code, it has results in milliseconds. None of these have that. Or show me a non trivial open source ts project that’s instant; doesn’t exist and I have literally no clue why people keep defending this stuff; you didn’t make it right? I would be embarrasse…
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…
Re: We need visual programming. No, not like that
#287The idea was to let the user write the code (sometimes in the Intellij's smart template style, sometimes as a code) and to show them the code represented as a graph, with some hints regarding type inference, possible scheduling, optimizations, etc. Then the user can run in-browser simulations on small sample datasets either provided by the backend or typed ad-hoc and the graph will be coloured accordingly. And then the user can do real runs.
The language is t-incomplete, so the representations are really sleek. In fact, some of the graph nodes can carry t-complete snippets inside, but their contexts are isolated and purity is enforced.
Unfortunately, I don't think it'll ever become foss or even public.
Re: We need visual programming. No, not like that
#288People think it's a good idea because it will save them time and I get many messages about different questions, use cases and support but the reality is you trade convenience for risk that something will be missing. What most people really want is a boilerplate for the SaaS, some building blocks for their UI and to not think about deployments.
VCs love this too, and many reach out, especially a couple of years ago. Maybe they know something I don't, maybe it was just phase.
Re: We need visual programming. No, not like that
#289Earlier quoted context omitted.
I still have to find somebody who worked with LabView that does not hate it. It is a total abomination.
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).
Also, since you;ve done only one project with it, how hard was it to pick it up and learn?