Hacker News Reader

Comment by VyseofArcadia | Hacker News Reader

Most definitely, but my point was to my programmer-brain, nearly any text-based modeling language would be better than some sort of awkward graphical diagram. And since the same company makes MATLAB, why not?

It turns out non-programmers actually like graphical tools. Go figure.

View on HN

I once wrote a linear programming optimal solver for a business problem.

But because it was all equations and logical reasoning, it was hard to understand, and boring to non-enthusiasts.

So my manager had me make a visual simulation instead, which we could then present to his managers.

This isn't as stupid as it sounds - we humans have huge visual processing networks. It makes sense to tap into that when interfacing with other humans.

I think to learn programming or math, you actually end up learning to use this visual wiring to think about written symbols. But this process of rewiring - while valuable - is very hard and slow, and only a tiny fraction of humans have gone through it.

Related to the visual simulations, one of Alan Kay's favorite demos over the years has been to show folks Sketchpad,

https://www.youtube.com/watch?v=495nCzxM9PI

partly as a "this is what we were doing in 1962, you are now as far removed from that demo as that demo was removed from the year 1900 -- do you really feel like you've made the analogous/concomitant progress in programming?" ... and one of his points there was that a lot of programming acts as a "pop music" where you are trying to replicate the latest new sounds and marginally iterate on those, rather than study the classics and the greats and the legacy of awesome things that had been done in the past.

I'm not sure what you're trying to say here.

That specialist interfaces make you productive?

Sketchpad was just a cad tool, one of the first ones to be sure, but still a design tool.

We have substantially better ones today: https://www.youtube.com/watch?v=CIa4LpqI2EI

So in 62 years have we improved the state of the art in design by as much as between 1900 to 1962?

Yes. I'd say we have and more.

I'm just putting this Alan Kay question (from Stack Overflow) here because of relevance.

In that question, he's considered not with implementation or how good the execution of an idea is (which is certainly one type of progress), but in genuinely new ideas.

I don't think I personally am qualified to say yes or no. There are new data structures since then for example, but those tend to be improvements over existing ideas rather than "fundamental new ideas" which I understand him (perhaps wrongly) to be asking for.

https://stackoverflow.com/questions/432922/significant-new-i...

this is awfully manual, does autocad have parametric topology tools ?

programs like houdini are more reactive and mathematical (no need to create width/volume by hand and trim intersections by hand), i think mech engineering tools (memory fail here) have options like this

No idea, I mostly use freecad and I've been told autocad has more tools.

In freecard there are parametric tools which are very much like what was shown in the demo but in 3d.

I tend to use script which render to openscad for the parts that I want to be parametric.

One thing that I think diagrams are better at than common text-base PLs is that with diagrams (when the blocks are placed nicely) you can _very quickly_ tell what is going into something (both directly and indirectly).

Of course you can abstract away a bit with functions or intermediate values in programming, but at one point if you do that too much you now have a bunch of indirection that harms overall readability.

All a balance of course, but "what takes part in this calculation" often feels more valuable than "what is the calculation itself".

> It turns out non-programmers actually like graphical tools. Go figure.

I'd rather say that visual tools are better abstractions than what text based tools can provide for those specific scenarios. Some problems are easier solved with diagrams.

text is bad with cross reference and impact.. every time your problem grows too many of them you end up charting a diagram

I've linked this thread from HN in the article about visual programming, if you find it useful or insightful,

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

Programmers just don't like switching between representations - it's the same reason that "printf debugging" will still be widespread after all of us are gone.

Printf debugging will exist for as long as access to logs is easier than direct access to memory.

Sure, that's just one use case. And logs can be useful for history as well as current state. But I think it's the mode shift to "do I set a breakpoint here, and then inspect the program state" as opposed to just continuing to sling code to print the state out.

What's funny is that I learned to debug with breakpoints, stepping, and inspectors. I use printf debugging now because the more experience you get, the easier and faster it becomes. There's a point where it's just a faster tool to validate your mental model than watching values churn in memory.

Another thing is the ability to actually have a breakpoint in the program. There is a lot of distributed systems (especially embedded ones) where just stoping the program and inspecting the state will cause the rest of the system to enter some kind of failure state.

I use printf debugging locally as well. Interactive debuggers and I just don't get on, and my test cases are built to start fast enough that it works out for me. Usually I have a 'debug_stderr' function of some sort that serialises + writes its argument and then returns it so I can stick it in the middle of expressions.

(I do make sure that anybody learning from me understands that debuggers are not evil, they're just not my thing, and that shouldn't stop everybody else at least trying to learn to use them)

Printf debugging is actually a very primitive case of predicate reasoning. Hopefully in the not too distant future instead of using prints to check our assumptions about the code we will instead statically check them as SMT solvable assertions.

Reply on news.ycombinator.com