Yes it was, mods merged the text link with the video link.
Images as illustrations in the code:
Yeah, sure, it would be nice to have the Vitruvian Man in the code, but it's also nice to be able to re-open your text file in 5 years, when development on the IDE has stopped and it no longer runs on current operating systems. Also, animations would be hugely distracting.
Code cells:
With jupyter and spyder I have been bitten by lingering obsolete state from re-running cells or code blocks various time. I find the program much easier to debug if it runs on a clean slate and builds all the state from scratch. If building state takes long, I try to cache, save it to disk, and go from there.
Nonetheless, an interesting perspective.
I imagine this as an Emacs package that recognizes tree-like code patterns (like what he showed in the video) and replaces those patterns inline when you toggle it. Your code is still the same plaintext. But your editor can display chunks of it as graphs.
Emacs does this already in latex-mode and org-mode for math formulas.[1] It shouldn't be a stretch to do this for other types of code, too.
[1] See this example in markdown-mode: https://external-preview.redd.it/ETo2U5C7vh5o4482sMcnYbkZ6Lx...
https://www.youtube.com/watch?v=uknEhXyZgsg
This is where it all started and it's truly amazing what they achieved on such limited hardware.
> I'm going to ask you for some feedback at some different places, so first off – by applause – how many of you know what this is? Okay, okay, that's actually more than I expected. Now, how many of you actually used one of these? Okay, so what I can say is that I am part of the last generation of people who were forced to use punch cards at school.
...that makes me think I'm probably better off watching the video.
Ideally, there'd be a simple text only version if the intention is for people to read as opposed to be an index for the video.
Would be interesting to see reading engagement with that change.
Hm, reading this just made my brain connect the reasons I don't like Jupyter with the reason I am baffled by people who like Smalltalk. An image that you can't fully restart just... doesn't seem like a pleasant development environment.
I kid, but I also wish there was some understanding that once state goes bad (as it very often does during program development) you really do want to restart that program from scratch. Or at least a part of it, I guess - an Erlang process will do.
(Unless you have very good time-traveling tools for the entire program state. Which can be prohibitively expensive).
It's not inserting images into the code. It's a structured editor presenting an alternative view of the code. It's just code. That's all there is to this. Man, frustrating.
JavaScript has had basically this several times (though not after the extreme flexibility of Racket’s #lang).
• In the context of HTML, there was <script language="…">, with a variety of unstandardised values for the language attribute, e.g. javascript1.0, javascript1.4. I think there were also unofficial MIME types that worked too (something like <script type="text/javascript;…">), but it’s hard finding documentation for this ancient history and I haven’t tried for more than half a minute. In the end, it died for lack of utility and because in practice new versions didn’t break anything worth mentioning so it was all just the one thing under the hood.
• Strict mode <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...>, via the "use strict" statement at the start of files and functions. Also "use asm" as another pragma that opted out of most of the language for performance reasons.
• And ECMAScript Modules are to some extent a new file format, and a module’s contents are automatically in strict mode.
Suffice it to say: they can remove stuff if there is any will too. But there is not.
Here are some things that I've done/found out manually that I want my IDE to do for me:
1. General inter-procedural analysis queries: - Does anyone pass in null? - Is X set in each path that can be taken? - Take a theory, for example numerical ranges, what can you tell me about this function? - Is this probably a hot function? - Are any of these sum type ctrs unused?
2. Show me counter-examples of things I believe about the code, don't force me to find them myself.
3. Predictable, but non-standard (not pre-rolled by IDE), refactoring. I had to grep and do an Emacs macro that went through the list of matches, one execution at a time. Why can't the IDE record my actions, show me the AST transformation that I did, and let me apply them for some qualifying criteria across the whole codebase?
4. Let me apply semantically equivalent code refactorings within a function by picking cost-based heuristics. For example, "flatten indentation levels".
5. Do coarse-grained semantic analysis for me, "are these the same on a type-level? OK, now apply this theory, still the same? Aah, I'm about to go for lunch, just run the whole analysis".
6. Let me save any thing I've done, so that I can use it in the future
Something like that, that'd be great. I have 128GB of RAM and like 64 CPU cores and I'm using my brain on this 1M+LoC codebase while they sit idle. Lazy bums, I tell ya!
Okay terminal emulators need to go. And there are replacements these days. Some are better than others. But dang it they just don’t seem to catch on.
I don’t value debug-ability as highly as he does. I find that once you have a program with shared mutable state and concurrent or parallel threads, debugging loses its utility. I much prefer being able to reason about my programs in a principled way than trying to figure out how my program failed by piecing things together from debugger output. I’ve also had a pretty long career and have done both and arrived at almost the opposite conclusion: both are good but I prefer correct by construction, static type systems, and proofs.
I guess that makes us necromancers? Raising and keeping dead languages moving and doing out bidding?
It would be neat to have an image-based runtime like Commmon Lisp or Pharo (SmallTalk) while the language is statically typed in a rich system like Lean that can generate optimal native machine code and GPU shaders, etc. A fast, interactive theorem prover is also a must. If I’m gonna have my cake and eat it too might as well go all in.
Is that what you really want or is that a tradeoff point short of ideal that you’ve selected as acceptable?
To put it more concretely, if you could have alive programs and alive tools, would that not be the pinnacle? Well categorically yes because an alive program has every capability a dead one has, including the ability to mimic “dead” one.
The problem as we all know is it appears to be impossible to write maximally alive tooling in the presence of alive programs because there’s no way to analyse them sufficiently with the compute available to us.
And so we select a trade off.
Aiming for the tradeoff point as the ultimate solution does us all a disservice though. We should call out that it’s a trade off (and a reasonable one at that) but what we really want is alive/alive!
And for the "sequential" part of the program, I would have loved a debugger on par with what's in my browser's dev tool, but it goes against the Erlang philosophy, or something.
Still, I can't wait to try smalltalk when it becomes relevant again thirty years in the past ; and if it's strangeloop video season _again_, and since I still can't write native clojure, I guess I'll try to install sbcl _again_ and set up slime _again_ and see if I get it, this time ?
Number of total objects
Size of objects
Number of methods
Avg size of method
Etc
What is stopping you from working on this?
Speaking of SBCL and Clojure, I have used Stumpwm and the Nyxt browser for a while and they both seem to run very well; I wonder if CLJ has any nice desktop applications that show off how it runs.
If devs became aware of how fun and fast their workflow COULD be we'd get these features in more mainstream frameworks.
For example, about half the memory of the Alto was just used for the bitmap display, which makes the system even more remarkable for what it could achieve with an economy of code. From what I've read, they had a plan to design a new system in the mid-70s (that would again look 15 yrs into the future) but at that point they got enough pushback from Xerox that they were not able to get the funding for that.
I'm guessing you have never tried these things but image based Smalltalk implementations have supported VCS for decades now, literally. In Pharo this is with git using Iceberg:
https://github.com/pharo-vcs/iceberg
They even wrote a tutorial to make it easier: https://github.com/pharo-vcs/iceberg/wiki/Tutorial
It's not magic, it's not even a problem, because the problem you're imagining doesn't actually exist. So long as the user of the system has at least half a brain (and maybe less) they will be capable of distributing their code with git these days.
Do you have a short list for the better of these replacements?
On Plan9 Sam and acme... heck most programs didn't have to emulate character-based terminal emulators. They could drop into a graphical mode if they wanted to.
Amiga OS applications were similar.
One I've been using more often is built into emacs, eshell. It can quite handily use emacs functions to create windows, draw graphics, evaluate elisp I type in or interpret shell commands, pipe shell command results into buffers, etc. But it doesn't emulate VT100 consoles... if you use a program that tries to use those escape sequences to control the output device it won't work well (or at all) in eshell.
Which is why I don't think they catch on. Too many useful programs or libraries programs depend on are built around termios and VT100 escape sequences to control a character-based interface. Coming up with a standard for graphical interfaces would just add another standard to the pile. And would probably have to be VT100 compatible for people to adopt it anyway. There'd be a lot of uphill battles to fight.
update: my knowledge of Console is pretty hazy though, take with a grain of salt. Maybe someone with win32 experience remembers better than I.
Mutating state in a live program shouldn't be done carelessly (any more than a schema migration on a live database), but removing it completely from the toolbox is overly restrictive, especially since that also involves removing it from the toolbox while testing and developing.
I will not agree, and I hope you will understand why after I give some evidence. Here's what Pharo advocates typically point people towards:
https://mooc.pharo.org/#week1 - I've linked to the week1 anchor so you can see that Iceberg makes it in pretty early. I hope you understand that despite your hopes for me I cannot agree. Sorry to crush your hopes, I hope you can forgive me.
The better way is tools like Iceberg and its various predecessors (Iceberg is nice because it works with git which has become the industry standard at this point for version control). There, you select down to the individual method what you want to commit and you can push it to other git repos on services like Github.
> it's also nice to be able to re-open your text file in 5 years, when development on the IDE has stopped and it no longer runs on current operating systems
Export the code to normal text, manually translate the images to ASCII or just keep them as Markdown-style links to images.
The cognitive benefit from having actual images in your code will massively outweigh the expected small one-time cost of having to perform a one-time task to migrate them a fraction of the time (and it's more likely that a particular software project will die than an editor that it's written in).
> I have been bitten by lingering obsolete state from re-running cells or code blocks
Make cells explicitly show you what state/inputs they use.
If you're not using purely functional programming languages or design patterns, then having the ability to re-use state will also massively outweigh the occasional transient issues from accidentally doing so.
The upsides of both of these techniques massively outweigh the downsides. Not to say that you have to use them, of course - there are still people trying to implement large software projects using UNIX shell scripts.
Stop Writing Dead Programs [video] - https://news.ycombinator.com/item?id=33251799 - Oct 2022 (215 comments)
Honestly, I don't have the slightest idea what's going on with you.
I agree with him on nearly everything else, as well as how people should understand at least the big picture stuff about Erlang better (and Go would have been a much better language by embracing crash-first design and not boilerplate error checking literally everywhere).
I don't know how you get fast feedback from a highly type checked language, but fully dynamic YOLO languages certainly aren't the answer I'm looking for.
I was having fun with the word "hope" which I find to be a weird sentiment because it expresses a lack of agency or control over a situation. But you didn't lack agency or control, you had an opportunity to persuade. An opportunity to convince me of your position and to try and bring me into agreement, but you didn't use that opportunity. It would have made more sense to me to express a hope for agreement if you had at least taken the chance to provide evidence for your claim.
>> I hope you will agree that this is not how Smalltalk is usually advocated.
You offered no evidence, you just hoped (asserted a lack of control in persuading) that I would agree with a bald assertion. I offered evidence to the contrary, the Pharo MOOC, which turns up in most discussions I've seen, here and elsewhere, about Pharo in particular and Smalltalk in general. Interestingly, to me, you didn't even engage with my evidence, which is unsatisfying.
You could have responded to it. You could have provided your own counter-evidence. But you didn't.
My personal goal here is to be able to write my programs by synthesizing them from proofs that I write by hand. Whether that is on a special device like an eInk reader or on a whiteboard; my work carries around with me where I choose to take it. I would love a world where my physical attention isn't focused on a glowing box with graphics designed by some company in Palo Alto or Cupertino who is designing for mass audiences with profits motivating every decision (and change). Why even hard-wire ourselves to the physical legacy of terminals?
There are plenty of humans who aren't even afforded access to modern computers in manners that are convenient to them and respect their abilities and capacities! The entire design of modern computing is centred around able-bodied, able-minded "mass-market" people -- whatever that is.
It's frustrating that any other mode of computing is an after-thought, an inconvenience, and attached to these machines in order to meet people where they are. Often times the answer is simply, "Nope, sorry."
Particularly inspired by: DynamicLand, https://screenl.es etc
DynamicLand reminds me of early Logo where there was a physical "turtle" robot that kids programmed to draw on paper!
No, they do not. What they are lacking isn't in what they can or cannot execute, it's what we can say about them. If your PL has eval, then you don't know if foo is ever called or not, for example.
I'm not interested in talking about the currently running instance of a program, but all possible running instances of it.
> As a sibling comment points out, by definition a live system can do everything a dead system can and more.
"Can do" is not the same as "we can say about", see my response to sibling.
To be fair, clojure was designed with long lived servers in mind, so the "JVM takes ages to start and load the class path" tradeoff makes sense. A downside is that any GUI built in clojure will either has to jump through some AOT compilation hoops (graalvm, etc), or accept being slow as hell to boot.
This alone has been enough to dissuade me to write anything with a UI in clojure. Maybe the space has changed since last time I tried, though.
It's still the same issue; consider the halting problem. There are times when we can say a call does not return in a turing complete language (the bottom type, e.g. never in TS or ! in Rust), but the reverse is not true. We cannot be sure a given call will return in a turing complete language even without eval.
You could avoid this for a definition of dead that equates with non-turing complete i suppose but that's not particularly interesting since it's not a general programming language in that case.