Digitizing "The Famous Computer Cafe" radio show
Help digitize 54 episodes of The Famous Computer Cafe, a 1980s radio show about computers that featured many notable interviews.
đź“ť Donate to Digitizing "The Famous Computer Cafe" radio show, organized by Kay Savetz
TLDR: Help digitize 54 episodes of The Famous Computer Cafe, a 1980s radio… Kay Savetz needs your support for Digitizing "The Famous Computer Cafe" radio show
Two related questions:
My intuition would tend to say that messy call graphs indicate a worse architecture, but I haven't visualized many and I'm not sure how well that idea holds up in the "real world". Maybe call graphs end up being too messy in real programs.
I think a call graph could indicate both the connection between functions, but also the “size” of the parameter list in those calls. Like state charts, it seems like this could be a nested sort of thing. I bet someone has already done all this.
As for measuring software quality (which is deceptively subjective), there's a list of metrics here that might be a good starting point.
Yeah, I know it's terribly subjective. I perhaps was thinking something along the lines of measuring complexity or coupling?
Hmm…I think I want less of a metric and more just a visualization . If I'm solving a simple problem, the solution should look simple when visualized.
Does your repo of visual programming languages also include program visualization, Ivan Reese?
@David Alan Hjelle No, my repo doesn't really include that, but it is adjacent / related.
Tom Larkworthy Yeah, that wiki link I shared was the result of me thinking "this sounds like cyclomatic complexity — I wonder if there's a whole category of these", haha.
Isn't cyclomatic complexity more about control flow (i.e., according to Wikipedia, if the program contained no conditionals, the cyclomatic complexity would be 1)?
I'm thinking more about when you organize a imperative program into functions, and measuring more the relationships and coupling between those functions. (I bet some of those other measures get into that sort of thing…I'll have to do some reading,)
Right, that's the subjectivity. What does one care about when assessing quality? By some criteria, if two programs perform the same job but one of them has lower cyclomatic complexity, that's the superior program.
Yeah, totally. I think that's where I wondered about call graphs explicitly — my 20 seconds of experience yesterday making one hinted to me that, given a particular problem, a "cleaner" (again subjective) call graph is the better program (to me).
I think I really don't care about a metric so much as some sort of tool to help me help other developers write better organized code. A call graph might be one — if there was a good, reliable tool for such a thing — but maybe there are others? In general, I'm surprised that program visualization—for our existing programming languages—isn't a more common thing? Or am I just not in the right circles?
You're 100% right — program visualization is not nearly as common as it ought to be.
yeah cyclomatic is supposed to measure the underlying computational complexity, not source code organisation. There is another one for code organization... I am not sure now, maybe LCOM4? But then I remembered SOLID and feel like those are quite good principles that should and probably do have metrics (?). I dunno why we do not visualize code more, can't say I have used it since leaving university 🤷‍♂️ Maybe the value is too indirect for the business people that prioritise (?)
I recall a cool trick to find bad code organization based on git commits. It went roughly like that: (starting assumption) When you do an incremental change in a system, in a well-organized system you would only have to change the source of one function - the function responsible for the thing you want to change. Also many different changes shouldn't all concentrate on the same function because it hurts code reuse. This sounds pretty ambitious and doesn't really hold in any real system BUT it can be used as a proxy to find problematic areas. Take a look at a git log. If there are groups of functions that are usually changed together (in the same commit) - then it means that they share something that could be extracted into a common location. Also any place which is a hotspot of changes (almost every commit touches it) then it probably could be split out. All of this can be formalized as counting bigrams of functions changed in the same commit. I've done some stats like that on a large-ish project at work and the hotspots (functions which were changed in commits) followed something similar to the zipf distribution. It didn't made sense to split everything but it showed some very interesting correlations that nobody had idea about (even the people working on the system).
@Marek Rogalski There’s a book called Your Code as a Crime Scene that I think covers what you’re talking about (here’s a blog post by the author that later was expanded into the book) There’s an open source tool called codemaat that does a lot of the analytics (and the book covers how to make the visualizations of the data codemaat spits out.)
Come gush about the Connection Machine with me. Share your anecdotes. Tell me what *Lisp was actually like. Marvel at a time when computers still looked futuristic.
I have a "wasted talent" feel about this thread, Ivan - it's brilliant, not just because I'm an old fart that this content resonates with, but because you've got a brilliant style aligned with technical /and/ stylistic understanding. I think you need to do more like this somehow.
(It's easy for me to nope out of this one because I have already spent 5 hours today editing less than half a podcast.)
I was once a professional Lisp programmer, since you ask, at the time when OO was taking off and Lisp had to keep up with the times (CLOS).
That was around the time of the Transputer, Occam and the Japanese 5th Generation initiative with Prolog. Wow, exciting times. Sadly C++ came along and... well
Marvel at a time when computers still looked futuristic.
I take the stance that using a function-based paradigm is only one possible way to program.
From this vantage point, programming of Reprogrammable Electronic Machines (mis-named "compute-ers") in 2024 presents a cornucopia of futuristic possibilities, much like in the 1950s when (the royal) "we" had to figure out how to deal with the problem space of programming CPUs. We need, yet, to satisfactorily solve the transition from CPUs (Central Processing Units) to DPUs (Distributed Processing Units) and to address the problem space of true asynchronicity for problems like robotics, internet, gaming, etc, etc. I acquired a one-chip Arduino that was on sale for $5 and could have built myself a better-than-connection-machine with 1,000s of such devices, yet, I, also, knew that the current crop of programming languages couldn't be used to handle such a task. To me, it currently feels just like it did in the early 1970s when I rolled my own Lisp, wire-wrapped my own CPU, hollowed out a Radio Shack calculator to scrounge it's meagre display and keypad, and, finger-poked into an IBM Selectric typewriter to write an article for DDJ.
I vote that the next time you suffer from insomnia, please, also, bless us with a thread about Chuck Moore's Green Arrays, or Dave Ackley's stuff, or Sassenrath's Rebol, or Pong, or the Yamaha WX7, or the Apple Newton, or ...
Oooh. I'll bite! What's neat about Pong, the WX7, or the Newton? I've got a good sense of what makes Moore's stuff cool, I'm all over Ackley, I'm passingly familiar with Rebol… but I don't know much of anything about the programming behind those last three, or even that there's something deep and cool there.
Pong, 1972, used a notation called "schematics", wherein every component was fully async. The whole game was expressed on one piece of paper and could be understood and afforded and built by a poor student. I haven't seen any programming language today that competes with that kind of succincticity. My gut says that the Pong schematic is succinct because of fundamental asynchronicity, unlike modern programming languages which are all the same - synchronous at the core. (Aside: Q: why am I interested in 0D, and, true message-passing???). My gut says that we've gone sideways, but, not forward. The WX7 (wind controller - looked like a clarinet) was just outside-of-the-box strange use of hardware. You could control a synth by blowing into the WX7. Probably programmed in assembler. Even my Apple Watch 9 doesn't do anything when I blow on it (I think 🙂). The Newton did stylus-based hand-writing recognition - only in B&W - decades ago, before Jobs pulled the plug (and put the downtown Newton Store out of business). The Palm Pilot was still a going concern at the time. This was decades before the emergence of so-called "smart" phones.
FYI - IIRC, I first saw a WX7 when Bill Buxton played it on stage during the OOPSLA Ottawa (1990?) keynote. [Are you aware of Buxton? If not, you might wish to become aware]. Later at the reception, we discussed theremins and he mentioned the idea of hooking a theremin into a Pitchrider [my '59 Strat still has stains on the pickguard where I'd attached a Pitchrider pickup (I was able to play blues harp with my guitar (a good use for what is now called auto-tune))].
