I just want to be able to embed diagrams in my code files.
https://www.flyde.dev allows you to do that!
We need visual programming. No, not like that
461–470 of 505 posts
Re: We need visual programming. No, not like that
#462Ill tell from my world of react/rn/node/serverlerss - Many of my colleagues shared this concern as well - we can't have enough visualization on the codebases/states/data-flows.
There are three benefits - Understanding the codebase (even to plug in a new feature), Findings issues easier and I can't emphasize this enough - We can/need reach into newer complexities that we thought twice about maintainability. In summary, We can reduce threshold for developer expertise to onboard into complex codebases - freeing up, developers on the other side to tackle far greater problems.
Re: We need visual programming. No, not like that
#463Earlier quoted context omitted.
> Schematix provides diagrams as a dynamic resource using its API. They aren't images you export, they don't end up in My Documents. This isn't Corel Draw. In Schematix, you specify part of your model using a graph expression, and the system automatically generates a diagram of the objects and relations that match. As your Schematix model changes, the results of the graph expression may change, and thus the visual di…
Schematix is somewhat unique. Direct competitors? -- not exactly, but IT asset managers, DCIM, BC/DR tools, and CMDBs are all competitors to some degree. Some of our best users are professional consultants who use us for a project which often introduces us to a new customer. A Show HN would certainly be in order. Thanks for the thoughts!
Do your blog posts have individual URLs? I would like to share a specific post, rather than the cumulative log.
Re: We need visual programming. No, not like that
#464I really miss ObjecTime ROOM. We used it a lot for embedded software development and it basically allowed to model the "big picture" of your application in (extended) UML and add C / C++ for the details. The generated code for the rest was usually very efficient, the runtime was pretty portable and slim as well. It became IBM Rational Rose Realtime (! the last word makes a big difference) and then it kind of disappea…
Have you used the QP framework ( https://www.state-machine.com/ )? It supports UML hierarchal state machines with code generation. One embedded dev I know shipped a couple products with it and still likes it.
Thank you, never heard of it but I'll take a look at it. Looks promising on a first glance.
Re: We need visual programming. No, not like that
#465As someone with a hardware background, I'll throw in my $0.02. The schematic capture elements to connect up large blocks of HDL with a ton of I/O going everywhere are one of the few applications of visual programming that I like. Once you get past defining the block behaviors in HDL, instantiation can become tedious and error-prone in text, since the tools all kinda suck with very little hinting or argument checking,…
As much as I prefer to do everything in a text editor and use open-source EDA tools/linters/language servers, Xilinx's Vivado deserves major credit from me for its block editor, schematic view, and implementation view. For complex tasks like connecting AXI, SoC, memory, and custom IP components together, things like bussed wires and ports, as well as GUI configurators, make the process of getting something up and run…
> Also, a free idea (or I don't know if it's out there yet): an open-source HDL/FPGA editor or editor extension with something like the Vivado block editor that works with all the open source EDA tools with all the same bells
"Free idea: do all this work that it takes hundreds of people to do. Free! It's even free! And easy!"
Lol you must be one of those "the idea is worth more than the implementation types.
Re: We need visual programming. No, not like that
#466I've fallen in absolute love with the visual programming of Rivet, which compiles to JavaScript and can be run with Node. It's absolutely amazing, and it incorporates AI logic directly into it. I highly recommend it.
Re: We need visual programming. No, not like that
#467Great blog. What framework did you use to setup your blog?
Re: We need visual programming. No, not like that
#468Earlier quoted context omitted.
Ok, when can we meet? I have never seen it work, and, as said, I review 100s of project a year; everything ts is super slow so far. Maybe you have something.
Their hot reload cycle is fast because esbuild doesn't type check the code, it just removes types from Typescript so it turns into JS (it may do minification and tree shaking but in dev, they probably remove that). I've written some esbuild plugins and can confirm that on incremental builds, esbuild will probably never take more than a few ms even on larger projects (because it doesn't matter how big your project is,…
No one wants to show me though. Is that not weird? Fanbois say it is, but not one person even sends an open source project that demonstrates it. I don’t understand that? Please show me a non trivial project on GitHub that does this in ms like you say. All I try are slow af. Emacs is notoriously slow as a lisp; it is always faster, for me, than anything ts and definitely not trivial. Sbcl/cl blows it all away. Please an example in ts or it didn’t happen.
Download some horror show like Unkey and show a video of its millisecond hot reload…
Re: We need visual programming. No, not like that
#469Earlier quoted context omitted.
Yes, you do if you want to make money on decades timescales instead of some grifter vc 2 year thingy.
Unfortunately you end up selling your stuff to people building missiles and bombs that way—witness CompCert and Frama-C.
Not us, but yes, you have a point.
Re: We need visual programming. No, not like that
#470Far 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…
So far, no examples of an instant typescript while a lot of fans for some reason. Come on people; 1 non trivial (few 100k LoC) ts project on GitHub that hot reloads instantly. If no one can produce even one, something is off no? Making claims is easy; not cl but emacs is non trivial and notoriously slow, still ‘instant’ compared to whatever ts (not hello world, but including hello world; it’s super slow) that I found so far on the same hardware. Sbcl is cl and it’s very fast, almost always instant, obviously depending on what you are doing. CLOG is a frontend joy to work in unlike ts. But many people here say ts is instant (we use the same tooling as peeps here for ts); one non trivial example please. No one produced one and all I try is dog slow. Not even comparatively, just spinning balls on a modern laptop. Some of the most popular devs make projects that ‘hot reload’ on my and my colleagues laptops in 20 or so seconds.