20 ms·

Stop Writing Dead Programs [video]

208 points by grzm 4y ago

grzm 4y ago
Video from Strangeloop 2022: https://www.youtube.com/watch?v=8Ab3ArE8W3s https://www.youtube.com/watch?v=8Ab3ArE8W3s
skybrian 4y ago
It's not very skimmable. Some headings would help a lot here.
- grzm 4y ago
  The presentation is great. Jack Rusher has a lot of energy. I recommend the video if you have time. The notes in the transcript are useful, too; both expansion of what he said as well as references to material.
- williamcotton 4y ago
  The basic gist is that our tooling has stagnated (and even regressed) but that there is some great work happening outside of the mainstream.
williamcotton 4y ago
The problem is that most people love their tools more than they love to build things. “You’ll have to pry vim from my cold, dead hands!”
- galoisscobi 4y ago
  These two things don’t necessarily have to be conflated. I rarely touch my vim config but at the same time during development, I write mini-programs (using macros, reflexes and buffer operations) in vim on the fly, that can write code for me or perform refactor stuff in ways that IDEs can’t typically do. I spend little to no time updating my vim tooling.
  - williamcotton 4y ago
    Jack is looking towards the inevitable paradigm shift away from a primarily text-based programming to whatever the future may hold. It's to be expected that most people will say they are perfectly productive with how things are thank you very much.
    - kibwen 4y ago
      I'll be happy to use a better paradigm than text when someone comes up with one. In the meantime, all the attempts to replace programs-as-text have failed to result in any actual improvement, save for niches like e.g. StarLogo that cater to beginners.
    - qu4z-2 4y ago
      I'm sure it's inevitable, but I'd like to point out it's been inevitable for at least 50 years.
    - AnimalMuppet 4y ago
      Yeah, well, "whatever the future may hold" isn't enough to get people to switch. I'm at least somewhat productive with how things are. You want me to switch? Show me how to be more productive with something that is concretely available today. You have something that may be revolutionary sometime in the future? Then I'll care sometime in the future, if it turns out to be actually revolutionary. I can't be productive on vaporware and dreams.
- Ologn 4y ago
  I started using vi in 1989. I still use vi, almost every day. I've had to learn my way around I don't know how many text editors, IDEs and so forth over time, often to throw that away when the new thing comes out. Not so with vi - most of what I was doing in 1989 in vi I am still doing in vi.
MBCook 4y ago
What is a dead program? The talk never says.
- peterkelly 4y ago
  A dead program is one that can't be changed after it's running. In the talk he discusses what are called "live programming" environments, as exemplified by Smalltalk and some implementations of Lisp. Instead of restricting programmers to writing code and then compiling/running it, live programming environments let you modify the program after it has started running. If you want to make a change, you just modify the relevant bits of code and the program will immediately start using them. There is no need for a build step and no need to restart the program (which would involve losing any state that's in memory).
  - bgm1975 4y ago
    And who needs version control anyway.
    - vanjajaja1 4y ago
      Version control can be built into the system. One click to deploy the change, one click to revert it. (You could even have automatic one-box/A-B deployment of a change within code)
      - lmm 4y ago
        You end up building an ad-hoc, informally specified, slow implementation of half of a regular development environment "inside" your system. These "closed world" systems can do some amazing things, but it's very rarely enough to make up for not being able to work with standard tools from outside the ecosystem.
  - ouid 4y ago
    any property that you would make about the possible state of the program by looking at the program itself has now been completely eliminated. Losing the state that is in memory is not universally desirable, but it is almost universally desirable.
50 4y ago
Like Wittgenstein, I sometimes think of our [scientific and] technological age as a bedazzlement. Jack Rusher, on the other hand, seems to point toward making technology transparent (an end in itself) and is incredibily inspiring for it. I love his Vector Field III (2017)[1] generative art piece. 1. https://ello.co/jackrusher/post/t1n-uy-wghymnohgpygxhw https://ello.co/jackrusher/post/t1n-uy-wghymnohgpygxhw
alexeldeib 4y ago
anyone know how the timestamps in this article were produced? format isn't great on desktop but the timestamps are interesting and I can't imagine those were done by hand...I guess the line width must be fixed so they are always correct (?) which probably also borks desktop viewing
- duncan-donuts 4y ago
  Zoom does a similar thing with it’s closed captioning feature. Not sure if this was generated from zoom or something else but I’ve seen these sort of scripts come from automated closed captioning features.
- jackrusher 4y ago
  I downloaded the automatic transcript from the YouTube video and wrote some code to reformat it in this way to make referencing the position in the video easier. I should probably have linked each time code to open the video at that point, but I'm a bit time constrained this week.
  - sfink 4y ago
    Yep, I've done this too. I had a video with a live youtube transcript for a talk, but in addition I had a manually written transcript from one of the attendees. She wasn't trying to make it word-for-word perfect, but it was reasonably close and obviously had better formatting. The automatic transcript was fairly poor quality but had fairly precise timestamps. The manual transcript lacked timestamps but was high quality. So I used an approximate matching algorithm to combine them and produce a clickable version of the manual transcript where every group of words was a direct link to that portion of the youtube video. It all worked out surprisingly well. (The other piece was that I hand-inserted annotations to produce an index of various topics and concepts that I thought were significant.) I don't know how common of a situation this is, since it requires having a high-fidelity human-created transcript. I could clean up the tools and release them, I suppose. I did this for a birthday present. (I don't have a demo because it's a private video, sadly, and I have rights to neither the video nor the manual transcript.)
jmartin2683 4y ago
Watched the video of this on YouTube. Overall a great talk, though I don’t agree with many of his conclusions. He seems to argue that ‘move fast and break things’ is the way forward, and that big dynamic runtimes allow for this with great runtime debugging etc. I prefer to catch my bugs at compile time, and have found this to be a far more reliable path to actually finishing a software project.
- kibwen 4y ago
  It's also just the wrong place in the stack to add these features. It's not a language concern, it's a platform concern. If I'm running a program in a web browser, it doesn't matter what language it's written in, I can pause the program and interactively explore it via the browser console. We should have the same thing for native apps on operating systems in general, and they should be native to the OS (provided by the OS vendor themselves) and not require any modification to the program (or any special programming language) in order to use.
  - mwcampbell 4y ago
    To what extent can native-code debuggers, like lldb, fill this need?
  - jmartin2683 4y ago
    I agree this would be very cool. I can’t count the number of times I wish I had runtime interactive debugging in a repl along the lines of pry in Ruby in just about every language that doesn’t have it. That said, gdb etc are pretty awesome too if it’s an option
  - none_to_remain 4y ago
    This pretty much means debugging a running process' assembly code You can already do this but it is a difficult way to play
  - pjmlp 4y ago
    History has proven it only works on language platforms, and as Dan Ingals asserts, the OS shouldn't be there. Anyway a modern OS where this is partially there, is Android.
verisimilitudes 4y ago
It's a shame he doesn't mention Ada, which is static but oh so nice about it. Right, but the problem is – as Peter Harkins mentions here – that programmers have this tendency to, once they master something hard (often pointlessly hard), rather than then making it easy they feel proud of themselves for having done it and just perpetuate the hard nonsense. Yes, see the entire history of UNIX. I convinced someone programming was a bad choice for his major because of this stupid attitude. I'm still reading, but I like how he takes issue with what currently passes for machine text. Some of my work covers the same problem. I should send him an e-mail.
- bioemerl 4y ago
  If you ever want a fun time, suggest a common sense usability improvement for Linux in a Linux community and watch them explode.
  - verisimilitudes 4y ago
    I like pointing out that millions of lines of code in the Linux kernel have no real memory exhaustion strategy beyond randomly killing a process. Those are millions of lines of code, few of which are reusable, and they do so very little.
  - theamk 4y ago
    Well, there are lots of replacements for common commands like "ls", "grep", "find", even "cd", and some of them are pretty popular. And there is a wide variety of shells and terminals. No one is complaining about them and the worst you get is "I don't care/not my cup of tea" attitude. Of course the key idea is to keep compatibility with existing world, for example by choosing a new command name ("rg"? "ack"?). If you just take over the existing name that has been used for years and break existing scripts, people will be unhappy.
- moonchild 4y ago
  In what respect is ada nicer about its staticness than, say, an ml?
tomcam 4y ago
My sincere compliments to anyone who managed to read past the first paragraph or two. And no, reader mode did not help.
- fallat 4y ago
  Glad I'm not the only one who thought this was extremely difficult to read. There's too much horizontal eye movement.
pie_flavor 4y ago
People are still using the same screwdrivers and screws they used a hundred years ago. Phillips head isn't even that good - you can easily strip the head over a few uses, or even one, if you don't know what you're doing. There have been innovations in big machines (analogy parallel would be Hadoop or whatever). But at the small level, people are still using the basic hand implements they've always used because they always work, they work everywhere, everyone else knows them, and it's pretty hard to get the design for new ones wrong. Like the author says, his ideas don't mean you should use Smalltalk or Lisp. Just that you should demand features, like how it took until Rust for sum types to escape functional. But the reason you shouldn't use Smalltalk is also the reason why languages like Smalltalk aren't going to get made: because when you're making a general-purpose language, it is extraordinarily hard to paradigmatically improve on what came before, and it's very easy to just get it all wrong and make a pile of trash that makes developers at the few companies that adopt it mad at you. Even Rust is not that amazing in this regard; its wild and new data model is in fact the exact same one you were supposed to be using in C++, just minus the ability to refuse. Everyone smart who was able to make these things has been snapped up by big data where their talents produce the most direct value.
- koyanisqatsi 4y ago
  What kind of direct value are you thinking of? I don't think most data scientists and ML engineers could write compilers or tensor algebra frameworks and gradient based optimizers.
  - lasfter 4y ago
    I think OP is saying the people who can write compilers or tensor algebra frameworks and gradient based optimizers get snapped up by big companies, not that every one who works in big companies is so capable.
    - koyanisqatsi 4y ago
      That makes sense. Thanks.
- 4y ago
apienx 4y ago
"Docker shouldn't exist. It exists only because everything else is so terribly complicated that they added another layer of complexity to make it work. It's like they thought: if deployment is bad, we should make development bad too. It's just... it's not good." Jack's not wrong. But better to look at it as throwing (increasingly cheaper) compute at the it-runs-on-my-machine problem.
- doctor_eval 4y ago
  When I lived in the Java world, Docker solved a heap of problems because Java has so many external dependencies - you needed the JVM, all its libraries, and all sorts of configuration files for those libraries. But how is a docker image different from, for example, a statically compiled single-binary Go executable? Because when I work with Go, I tend to think that if what I'm working on requires something defined from outside the binary, I'm doing it wrong. So is Docker a solution to problems that are inevitable, or is it just a solution to problems caused by other solutions? These days I tend to think that something like Firecracker is more likely to be a solution to deployment problems than Docker is, but I haven't tried it yet...
  - vbezhenar 4y ago
    I live in Java world and docker solves exactly 0 problems for me. Maven or Gradle deals with assembling all the necessary jars into a single directory (or uberjar if you want, I don't like it). JVM is another directory. Running application is a shell script of 2-3 lines. So my Java application is: directory with JVM, directory with jars and start.sh. It works almost everywhere. It's simpler than docker. I can replace JVM with windows version and start.sh with start.bat and it'll run on Windows. Natively. Can't do that with Docker. To build my application one would need to have maven (one directory), JVM (another directory) and project sources. Set up two env vars (JAVA_HOME, PATH) and run mvn verify. That's about it. Windows, Linux, macOS, doesn't matter. Single binary is simpler than a directory with some files. But not much simpler. I use docker, because that's the way things are done nowadays. I think that for personal project which does not need Kubernetes, I wouldn't use it.
HankB99 4y ago
My first exposure to computers was using punched cards to write Fortran. I wonder if the author was a classmate (at Purdue Calumet.) Otherwise I did not have the patience to read much past that.
beefman 4y ago
Some interesting links from this talk: Maria https://www.maria.cloud/ https://www.maria.cloud/ Glamorous Toolkit https://gtoolkit.com/ https://gtoolkit.com/ Data Rabbit https://datarabbit.com/ https://datarabbit.com/ Nextjournal https://nextjournal.com/ https://nextjournal.com/ Clerk https://github.com/nextjournal/clerk https://github.com/nextjournal/clerk Enso https://enso.org/ https://enso.org/
- 0x445442 4y ago
  The enso link is interesting because there was another Enso project over a decade ago by Aza Raskin. That project, ironically, asserted the superiority of natural language and thereby text as a user interface.
  - d0mine 4y ago
    text is superior (as in programming languages, not natural language) in the general case but there may be exceptions GUI builders, mock-ups, diagrams, tricking non-programmers into programming (iOS shortcuts(yahoo pipes), Scratch/Alice).
- nudpiedo 4y ago
  I wonder how many of them are in use for people beyond its creators/contributors, and in case of having actual users and customers, who are those (not theoretical profiles, but existing ones). This is an actual question, if someone has an answer I will gladly like to learn more about it.
helf 4y ago
Ok, I want to read this. I hate watching videos of talks. But holy fuck, what the hell is with this transcription output? I do not think I could read this post like this because it would make me brain hurt and also this is the worst layout I've ever seen from even an automagic transcription jeez
- Arainach 4y ago
  Amen. If the timestamps were hotlinked to the video for reference, that might be clever, but the overall format is awful. For reference, this is what it looks like on my screen: https://i.imgur.com/0VZEldv.png https://i.imgur.com/0VZEldv.png
  - helf 4y ago
    Yep. Same. But let's not complain any more. Apparently that is faux pas
- deleted 4y ago
  [deleted]
- dang 4y ago
  "Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
systematical 4y ago
unreadable.
tomrod 4y ago
Fantastic talk. Loved it! Thanks for the post and the commenters who recommended it. Formatting was terrible -- even when viewing source! This made it somewhat readable import requests from bs4 import BeautifulSoup url = 'https://jackrusher.com/strange-loop-2022/' bs = BeautifulSoup(requests.get(url).text) muh_text = ' '.join([x for x in bs.stripped_strings if not x.startswith('00')]) print(muh_text)
- remram 4y ago
  I went with this JavaScript: let c; for (let p of document.querySelectorAll('body>p, body>div')) { if (p.classList.contains('aside')) { c = undefined; continue; } p.querySelector('span.time').remove(); if (c) { c.innerHTML += ' ' + p.innerHTML; p.remove(); } else { c = p; } } And this CSS: body p { width: 100%; } body div.aside { width: 100%; border: 1px solid black; } I'm thinking maybe that page was supposed to be embedded somewhere, next to a video maybe? It wasn't meant to be read like this right?
  - tomrod 4y ago
    Really shoddy DRM maybe?
    - jackrusher 4y ago
      Definitely not! Sorry you hated the formatting. The transcript is meant to be an assistive technology for the video, and a place to put extra notes I couldn't fit into the time I had. Ideally, the transcript would scroll as the video advances and the timestamps would move the playhead to that part of the talk, but I haven't time this week to do as much hacking on that as I'd like.
      - tomrod 4y ago
        Absolutely no issue! I've only just come across your work and am astounded at both its breadth and depth. I thought perhaps the page wasn't owned by you, and that someone had ripped it from subtitles or something similar. The link for the article looks to have changed; before it was to a website that had text next to timestamps.
dang 4y ago
I've changed the top URL to the video, in the hope of reducing the tedious complaints about webpage formatting that the transcript was generating. The transcript is here: https://jackrusher.com/strange-loop-2022/ https://jackrusher.com/strange-loop-2022/. Please let's talk about the ideas now.
- kragen 4y ago
  I'm glad I happened across the item before you made the change! The transcript is the best transcript I've ever seen of a talk. I think the ideas are very interesting. I don't agree with his condemnation of Docker and single-threaded programming, but he's certainly right about the value of being able to kill threads in Erlang, and about the importance of being able to fix things that are broken, and about our computers cosplaying as PDP-11s (and the consequent teletype fetishism). I hadn't made the connection between Sussman's propagators and VisiCalc before. I mean I don't think Bricklin and Frankston were exposed to Sussman, were they? They were business students? But if not, it's certainly a hell of a coincidence. My defense of single-threaded code and aborting is that the simplest way we've found so far to write highly concurrent systems is with transactions. A transaction executes and makes some changes to mutable state based on, ideally, a snapshot of mutable state, and if it has any error in the middle, none of those changes happen. So it executes from beginning to end, starting from a blank (internal) state, and runs through to termination, unless halted by a failure, just like the "dead programs" Rusher is complaining about. You put a lot of these transactions together, executing concurrently, and you have a magnificent live system, and one that's much easier to reason about than RCU stuff or even Erlang stuff. This is what the STM he praises in Clojure is doing, and it's also how OLTP systems have been built for half a century. Its biggest problem is that it has a huge impedance mismatch with the rest of the software world. I've said before that to get anything done you need some Dijkstra and some Alan Kay. If you don't have any Dijkstra in you, you'll thrash around making changes that empirically seem to work, your progress will be slow, and your code will be too buggy to use for anything crucial. If you don't have any Alan Kay in you, you'll never actually put any code into a computer, and so you won't get anything done either except to prove theorems. Alan Kay always had a fair bit of Dijkstra in him, and Dijkstra had some Kay in him in his early years before he gave up programming. Ideologically, Rusher is way over on the Kay end of the spectrum, but he may not be aware of the degree to which the inner Dijkstra he developed in his keypunch days allows him to get away with that. The number of programmers who are ridiculously unproductive with Forth (i.e., almost all of us) is some kind of evidence of that. Interestingly he doesn't talk about observability at all, and I suspect that observability may be a more useful kind of liveness for today's systems than setting breakpoints and inspecting variables, even with Clouseau. Data Rabbit, Maria.cloud, Hazel, livelits, and Clerk sound really interesting. I think it's unfortunate that you switched the URL; even for people without hearing impairment, transcripts are far preferable to videos, and this is a really excellent transcript. With a couple of screenshots, it would be better than the video in almost every way, though a few of the demos would lose something. (The demos start at 14'40".) The sort of people who were making worthless comments because they were confronted with a webpage formatted in an unfamiliar way won't suddenly start making insightful comments because there's a video link; they won't make any comments at all. So it's a mistake to cater to them and damage the experience for people who might have something to contribute. Video links make for shallow conversations.
mwcampbell 4y ago
> The reason I disagree with this position is because the visual cortex exists. [...] There's no reason to eschew [graphics] when it comes to program representation. Not everyone can take advantage of the visual cortex. Please don't take away one area where we're on a fairly level playing field.
- akkartik 4y ago
  https://en.wikipedia.org/wiki/Harrison_Bergeron https://en.wikipedia.org/wiki/Harrison_Bergeron
  - mwcampbell 4y ago
    That story is clearly absurd. But in the real world, it might not always be such a bad thing to hold back the runaway feedback loop where the people with the most advantages gain even more. If non-textual program representations do catch on, based on the unchecked assumption (as in this talk) that everyone has normal vision, then figuring out accessibility for future non-textual program representations will be good job security for someone, if that work gets funded. I just hope that no blind programmers lose their jobs in the meantime. (Personally, I could probably muddle through with my limited vision, albeit possibly with lower productivity.) I should be used to people like me and some of my friends being routinely overlooked, as if we don't exist or can be relegated to a footnote, but sometimes it gets to me.
    - akkartik 4y ago
      I'm sorry to hear it :/ I've been trying harder to provide alt texts in images, for what that's worth..
- switchbak 4y ago
  So don't leverage a powerful capability because a small number of people can't use it? That's like saying don't build sidewalks because some people can't walk. We already lean heavily on the language centers, I don't see why we shouldn't lean on the visual and spatial ones.
noobermin 4y ago
I made my way through part of the talk on youtube, it was interesting but far too much for me to stomach. It really drove it home when he flashed slides of graphic organizations of complex data. While some parts might be better than a textual description, graphic representation of data needs to be useful, that is, you need to be able to look at a graph and glean information from it. At the section where he flashes an image of a re-imagined periodic table[0], he immediately exclaimed "look how beautiful it is!" and I was immediately instead confused. What does this image show? If it is a periodic table, can I see the periodicity? For example, can I tell two elements have electrons in the same shell by just looking at it? Can I see if two elements have the same filling of the subshell, and thus will covalently bind in similar ways? Can I tell which elements are more electronegative? I can glean all that from the "boring periodic table," which yes is a graphic representation and cannot easily be written in sequential text, but this new representation doesn't give me any of that at least as far as I can tell. The desire to represent an already existing set of data in a new graphic representation that seems to give no value apart from being novel is not helpful. I can extrapolate this down. A lot of things in life are the result of historical evolution; that is just how things are. While that history can lead to problems, it is just the way things are. And yet, it should be beyond obvious that not everything new is good. For example, while sure the examples he gave were clunky, I can say with absolute certainty that there are times where playing games on my NES is more enjoyable sometimes than playing games on my "supercomputer," because on my NES I can play until I'm blue in the mouth, whereas on my phone, I have to stop every 2 minutes and watch an ad that makes my phone even hotter than the console. When what I value is "having fun" instead of "newness" or "shiny graphics with anime girls" I can see that an older device is better. Should I conclude that "advancement in technology is bad for enjoyment and for my sanity"? No, because I am not that shallow in my reasoning here. It's clear that "old" vs "new" for my NES vs. mobile game comparison is really a complaint about the change in monetization models, and thus a different user experience for the gamer. In fact, the "old" vs. "new" argument obscures the real difference worth consideration, substituting the argument for a fight between nostalgia and novelty. "Old" and "new" should never be what anyone focuses on because more often than not, such labels obscure the true conflict. Really, certain people like the presenter value things other than "familiarity," things like "introspection" and "graphical representation" and "concurrency," and he's mad people resist what he likes. Thus, he chalks it up to others stuck in their ways, clinging to "history." The thing is "familiarity" isn't the only argument people have for why they don't use clojure or reactive graphical displays: "familiarity" is often a stand in for other things that the people he critiques value, things like their time and latitude to learn new things, or the fact that indeed, some things are actually better expressed in text and as a sequential program than visually or concurrently, or that there are cases where those models are still infeasible on a computer even today (none of my electromagnetic simulations other than the most simplest will work in a reactive notebook because while computers are much faster, being much faster means I just do larger simulations that can no longer actually run in a reactive setting well). That to me is the more (pun not intended) valuable discussion, a discussion of the actual "innovations" and the values you have in mind when you evaluate them. Like, sell me on why I even care about introspection in a computational physics simulation code when I think I'm doing fine without it. That to me is the more interesting discussion, a discussion of values. But that's the problem, just making another talk about how modern lispy introspection or something is cool is just another technical talk, and it certainly feels much less cathartic than painting everyone else who hasn't adopted your reactive notebooks as being luddites clinging to their VT100 emulating terminal windows. But that to me feels like where the actual meat is, a discussion of boring technical topics because there I can respond with actual concerns or reasons I can't use this or that, and such a discussion would actually be more interesting and productive for me and for people who want to sell newer paradigms. [0] https://youtu.be/8Ab3ArE8W3s?t=1359 https://youtu.be/8Ab3ArE8W3s?t=1359
groos 4y ago
"There are only two kinds of languages: the ones people bitch about and the ones nobody uses" -- Bjarne Stroustrup, whom Jack disses in the video.
- hayley-patton 4y ago
  Well, Bjarne did make C++.
- nigerianbrince 4y ago
yazzku 4y ago
The "it works on my machine" meme killed me.
1letterunixname 4y ago
Yep. Erlang/BEAM PIDs, processes, supervision trees, supervisor strategies, supervisors are underrated. They should be built into the OS. Honestly, every "program" should be a function, return structured data, and callable from anywhere. Logs also should be structured rather than deserialized lines. Lines requires parsing. Parsing is a waste of electricity and time because it discards boundaries between values. The current paradigm is unwise because it's slow and inefficient unless you actually need lines. Rarely do you need just lines. Look at how nasty bash, grep, awk, sed, cut, head, tail, tr scripts will become. Also, debugging and profiling, I still can't believe many programming environments / IDEs lack the features and debugging integration that ancient Borland Pascal and MSVC had.
- koyanisqatsi 4y ago
  I'd settle for software that could reasonably save and restore its own state. Half the time when I close the laptop lid I have no idea what will happen when I open it again. More often than not some application and its state just disappears into the computational ether. One of Alan Kay's slogans is "The computer revolution hasn't happened yet" and he's mostly right. What we have are glorified calculators and media players instead of programmable devices that can augment intelligence and it's because the main runtimes/operating systems on these devices are not dynamic enough. Great deal of effort is required to extend and modify them to fit personal use cases. If you're not a programmer then you might as well just give up because the technical barrier is too high. So it's not surprising that most people have a negative view of personal computers and would rather let Apple and friends manage things for them even if that means giving up a great deal of control and privacy to a 3rd party which is mostly interested in making as much money as possible. The larger implications of all this is that a great deal of potentially innovative use cases are not feasible because the required effort is too high. Every innovative application has to essentially re-invent its own dynamic runtime and shoehorn it into the existing non-dynamic setup.
  - 1letterunixname 4y ago
    macOS AND iOS flavor these fairly well with the defaults systems and prefs, but software developers have to understand how to save and restore state properly, and not fight it. Also, I think complete process state (secured by a kernel decryption key) should be able to be saved and restored. Open I/O file descriptors would probably drop if they represent remote resources, but code should be made resilient enough to reconnect and retry in the event of errors.
agentultra 4y ago
I think his take on “debug-ability > correct by construction,” has to assume that you can understand the problem or can understand the problem. In my experience this works fine when you have a mostly procedural process on a single machine. Set some watchers, step through execution, pause to inspect state. It is much harder to do with concurrency. And damn near impossible with distributed systems. As someone who has claimed to use these kinds of tools to verify protocols, I’m curious what cases he would break this preference for debugging over reasoning. Or is the contradiction intentional? I was big into Common Lisp for years and mostly into Haskell and Lean now. I still think debugging is fine and useful to do but I get the most bang out of being able to reason about my program before I run it. Once you have the definitions and proofs in place running the code is fine I guess but all the work is done. Whereas with more dynamic systems the work has barely begun: now I need to bump into all of the errors in my code while it is running. There are times when I want both and I don’t think the computing world needs to pick one and only one.
drewcoo 4y ago
The problem is not the programs. The problem is not the tools. The problem is that the tradespeople and craftsfolk who make them are, whether intentionally or not, wage slaves. They do not make for the joy and art of making, but constrained by monetary need. They do not seek to grow as makers and share what it is to make because . . . no one would pay them for that. If we want better tech and better ways of doing tech, we need to start being paid like smart people who can not only do what management can't, but also we insist on doing it in a way that's creative. In a way not managed as a commodity. Here on HN, we see hacker (at best) as commodity. This is not the right community for the message, imo.
- sfink 4y ago
  It's a persuasive argument, but most of the "dead" tools mentioned in the talk were created in the era where the creators were inspired more by the beauty of their creations than their relevance to some bottom line. C C++ Pascal Python Go .NET ML Docker etc. were all made by people who saw a niche and sculpted something new for the joy of it. (Not just for the joy, but still.) The current "...but does it monetize?" culture is a recent thing. For most of the history of computing, nearly everything was done by starry-eyed idealists and outcasts who were in love with exploring the new conceptual frontiers opened up by technology. Sure, even then there were Larry Ellisons out to skin the selkies and sell their pelts to the highest bidder, but they weren't driving the field. The vast majority of developments came from people on BBSes or MUDs or just in their private basement rooms, who delighted in coming up with working demonstrations of crazy new ideas and showing them off. Silicon Valley was the Kingdom of the Geek, before the Geek had been tempted to crawl into the gilt cage and be locked inside by the army of MBAs and VCs. But we did it to ourselves—where once we might show off a live coding hack or a self-modifying set of scenes in a MUSH, now we show off our new Tesla or whatever the latest variant of a giant cell phone on wheels is. (I don't disagree with what we should be moving towards.)
fermigier 4y ago
There is a strawman argument in the talk, about the limitation (or now, default) to 80 characters wide consoles which is presented as a "proof" that we're still living in the past. 80 characters (plus or minus 10) has a justification outside the history of teletypes and VT100s: that's the optimum for readability. Otherwise, there are good ideas, in the talk, but this particular one rubbed me in the wrong way.
- hoseja 4y ago
  Optimum for whom? Nineteenth century teletype operators? I never got that argument.
  - goto11 4y ago
    Optimal for reading prose texts. I believe experiments have shown the optimal line width for reading speed and comprehension to be about 50-60 characters. But as far as I known this have only been researched for reading prose. I doubt the result will translate directly to reading source code, which is read in a completely different way.
    - fermigier 4y ago
      Yes, experiments are lacking for code, but I believe the physiological principles (eye fixation, etc) still stand. Also: the optimal line width for prose seems to be 50-75 characters (including whitespace). Source: https://baymard.com/blog/line-length-readability https://baymard.com/blog/line-length-readability Assuming you're using a language where indentation is either mandated (e.g. Python) or recommended (e.g. C with "One True Braces"), with 4-spaces indentation (here again, no experimental evidence, but this seems to be the norm nowadays), and you don't abuse cyclomatic complexity in your functions / methods, you have let's say between 2 and 4 indents on the left so 80 is close to the optimum. Note: up to 100 is probably still OK from a readability POW. But this assumes that all readers are able to increase their window size from the default 80. That's probably true for people using GUIs, but may still be problematic for people with sight issues (e.g. people over 50 or with more serious medical conditions...).
DeathArrow 4y ago
I will probably get down voted, but I feel like I waisted 45 minutes, keeping watching the video and waiting for something interesting. I think that a two minute video about live coding and visual representation, for those that don't know such things exist would have been enough.
- bilekas 4y ago
  I have to agree, a lot of his points where just pointing out bad/inefficient practices and calling it 'bizzare' behavior.
- marcus_holmes 4y ago
  video is a really bad format for this kind of content, imho. I can read faster than the video can explain. Even at 2x or 3x speed, it's still faster to read, especially if I'm only skim-reading to find interesting bits.
globalreset 4y ago
I enjoyed watching it, but plenty of this talk is completely misguided. Had some ideas from there were so much better, surely by now people sharing them would show people not sharing them how much better they can do and overtake the industry. Not to waste my time - most of the ideas expressed there lack in composability, and composability trumps almost everything else in the long run. Something that enthusiast of VMs, dynamic typing and runtimes don't want to understand. That's why stuff like live coding and interactive programming is always ever employed for small scope, throw-away things. Visual programming is harder to automate, operate on, reproduce and compose and so on.
axilmar 4y ago
While I understand that an interactive environment could be useful in a lot of cases, in other cases it might just be in the way...for example, when I am designing an API, usually I don't need any sort of visualization...on the other hand, if I want to explore data, then I do need visualization. Also, his critique for my favorite language, C++, is unfair. C++ is born out of the necessity to take advantage of the hardware in the best way possible. And while it might be a mix of different ideas, it does work well in a lot of cases, and testament to that is the software we are using to communicate, the browsers, the web etc, the infrastructure of which is basically done almost exclusively in C++. Furthermore, static typing helps in complex programs a lot. There are concrete examples around where static typing greatly helps solves complex problems. And complexity is not about algorithms only, it's also about change over time. A piece of code that does not have type annotations can become an ugly spaghetti mess really quickly, and that must be multiplied by ten each time a new developer is added to a team. Very entertaining talk, by the way. At no point it was a drag. The presenter has a real talent for it.

208 points by grzm 4y ago

grzm 4y ago

Video from Strangeloop 2022: https://www.youtube.com/watch?v=8Ab3ArE8W3s https://www.youtube.com/watch?v=8Ab3ArE8W3s

skybrian 4y ago

It's not very skimmable. Some headings would help a lot here.

grzm 4y ago
The presentation is great. Jack Rusher has a lot of energy. I recommend the video if you have time. The notes in the transcript are useful, too; both expansion of what he said as well as references to material.
williamcotton 4y ago
The basic gist is that our tooling has stagnated (and even regressed) but that there is some great work happening outside of the mainstream.

williamcotton 4y ago

The problem is that most people love their tools more than they love to build things. “You’ll have to pry vim from my cold, dead hands!”

galoisscobi 4y ago
These two things don’t necessarily have to be conflated. I rarely touch my vim config but at the same time during development, I write mini-programs (using macros, reflexes and buffer operations) in vim on the fly, that can write code for me or perform refactor stuff in ways that IDEs can’t typically do. I spend little to no time updating my vim tooling.
- williamcotton 4y ago
  Jack is looking towards the inevitable paradigm shift away from a primarily text-based programming to whatever the future may hold. It's to be expected that most people will say they are perfectly productive with how things are thank you very much.
  - kibwen 4y ago
    I'll be happy to use a better paradigm than text when someone comes up with one. In the meantime, all the attempts to replace programs-as-text have failed to result in any actual improvement, save for niches like e.g. StarLogo that cater to beginners.
  - qu4z-2 4y ago
    I'm sure it's inevitable, but I'd like to point out it's been inevitable for at least 50 years.
  - AnimalMuppet 4y ago
    Yeah, well, "whatever the future may hold" isn't enough to get people to switch. I'm at least somewhat productive with how things are. You want me to switch? Show me how to be more productive with something that is concretely available today. You have something that may be revolutionary sometime in the future? Then I'll care sometime in the future, if it turns out to be actually revolutionary. I can't be productive on vaporware and dreams.
Ologn 4y ago
I started using vi in 1989. I still use vi, almost every day. I've had to learn my way around I don't know how many text editors, IDEs and so forth over time, often to throw that away when the new thing comes out. Not so with vi - most of what I was doing in 1989 in vi I am still doing in vi.

MBCook 4y ago

What is a dead program? The talk never says.

peterkelly 4y ago
A dead program is one that can't be changed after it's running. In the talk he discusses what are called "live programming" environments, as exemplified by Smalltalk and some implementations of Lisp. Instead of restricting programmers to writing code and then compiling/running it, live programming environments let you modify the program after it has started running. If you want to make a change, you just modify the relevant bits of code and the program will immediately start using them. There is no need for a build step and no need to restart the program (which would involve losing any state that's in memory).
- bgm1975 4y ago
  And who needs version control anyway.
  - vanjajaja1 4y ago
    Version control can be built into the system. One click to deploy the change, one click to revert it. (You could even have automatic one-box/A-B deployment of a change within code)
    - lmm 4y ago
      You end up building an ad-hoc, informally specified, slow implementation of half of a regular development environment "inside" your system. These "closed world" systems can do some amazing things, but it's very rarely enough to make up for not being able to work with standard tools from outside the ecosystem.
- ouid 4y ago
  any property that you would make about the possible state of the program by looking at the program itself has now been completely eliminated. Losing the state that is in memory is not universally desirable, but it is almost universally desirable.

50 4y ago

Like Wittgenstein, I sometimes think of our [scientific and] technological age as a bedazzlement. Jack Rusher, on the other hand, seems to point toward making technology transparent (an end in itself) and is incredibily inspiring for it. I love his Vector Field III (2017)[1] generative art piece. 1. https://ello.co/jackrusher/post/t1n-uy-wghymnohgpygxhw https://ello.co/jackrusher/post/t1n-uy-wghymnohgpygxhw

alexeldeib 4y ago

anyone know how the timestamps in this article were produced? format isn't great on desktop but the timestamps are interesting and I can't imagine those were done by hand...I guess the line width must be fixed so they are always correct (?) which probably also borks desktop viewing

duncan-donuts 4y ago
Zoom does a similar thing with it’s closed captioning feature. Not sure if this was generated from zoom or something else but I’ve seen these sort of scripts come from automated closed captioning features.
jackrusher 4y ago
I downloaded the automatic transcript from the YouTube video and wrote some code to reformat it in this way to make referencing the position in the video easier. I should probably have linked each time code to open the video at that point, but I'm a bit time constrained this week.
- sfink 4y ago
  Yep, I've done this too. I had a video with a live youtube transcript for a talk, but in addition I had a manually written transcript from one of the attendees. She wasn't trying to make it word-for-word perfect, but it was reasonably close and obviously had better formatting. The automatic transcript was fairly poor quality but had fairly precise timestamps. The manual transcript lacked timestamps but was high quality. So I used an approximate matching algorithm to combine them and produce a clickable version of the manual transcript where every group of words was a direct link to that portion of the youtube video. It all worked out surprisingly well. (The other piece was that I hand-inserted annotations to produce an index of various topics and concepts that I thought were significant.) I don't know how common of a situation this is, since it requires having a high-fidelity human-created transcript. I could clean up the tools and release them, I suppose. I did this for a birthday present. (I don't have a demo because it's a private video, sadly, and I have rights to neither the video nor the manual transcript.)

jmartin2683 4y ago

Watched the video of this on YouTube. Overall a great talk, though I don’t agree with many of his conclusions. He seems to argue that ‘move fast and break things’ is the way forward, and that big dynamic runtimes allow for this with great runtime debugging etc. I prefer to catch my bugs at compile time, and have found this to be a far more reliable path to actually finishing a software project.

kibwen 4y ago
It's also just the wrong place in the stack to add these features. It's not a language concern, it's a platform concern. If I'm running a program in a web browser, it doesn't matter what language it's written in, I can pause the program and interactively explore it via the browser console. We should have the same thing for native apps on operating systems in general, and they should be native to the OS (provided by the OS vendor themselves) and not require any modification to the program (or any special programming language) in order to use.
- mwcampbell 4y ago
  To what extent can native-code debuggers, like lldb, fill this need?
- jmartin2683 4y ago
  I agree this would be very cool. I can’t count the number of times I wish I had runtime interactive debugging in a repl along the lines of pry in Ruby in just about every language that doesn’t have it. That said, gdb etc are pretty awesome too if it’s an option
- none_to_remain 4y ago
  This pretty much means debugging a running process' assembly code You can already do this but it is a difficult way to play
- pjmlp 4y ago
  History has proven it only works on language platforms, and as Dan Ingals asserts, the OS shouldn't be there. Anyway a modern OS where this is partially there, is Android.

verisimilitudes 4y ago

It's a shame he doesn't mention Ada, which is static but oh so nice about it. Right, but the problem is – as Peter Harkins mentions here – that programmers have this tendency to, once they master something hard (often pointlessly hard), rather than then making it easy they feel proud of themselves for having done it and just perpetuate the hard nonsense. Yes, see the entire history of UNIX. I convinced someone programming was a bad choice for his major because of this stupid attitude. I'm still reading, but I like how he takes issue with what currently passes for machine text. Some of my work covers the same problem. I should send him an e-mail.

bioemerl 4y ago
If you ever want a fun time, suggest a common sense usability improvement for Linux in a Linux community and watch them explode.
- verisimilitudes 4y ago
  I like pointing out that millions of lines of code in the Linux kernel have no real memory exhaustion strategy beyond randomly killing a process. Those are millions of lines of code, few of which are reusable, and they do so very little.
- theamk 4y ago
  Well, there are lots of replacements for common commands like "ls", "grep", "find", even "cd", and some of them are pretty popular. And there is a wide variety of shells and terminals. No one is complaining about them and the worst you get is "I don't care/not my cup of tea" attitude. Of course the key idea is to keep compatibility with existing world, for example by choosing a new command name ("rg"? "ack"?). If you just take over the existing name that has been used for years and break existing scripts, people will be unhappy.
moonchild 4y ago
In what respect is ada nicer about its staticness than, say, an ml?

tomcam 4y ago

My sincere compliments to anyone who managed to read past the first paragraph or two. And no, reader mode did not help.

fallat 4y ago
Glad I'm not the only one who thought this was extremely difficult to read. There's too much horizontal eye movement.

pie_flavor 4y ago

People are still using the same screwdrivers and screws they used a hundred years ago. Phillips head isn't even that good - you can easily strip the head over a few uses, or even one, if you don't know what you're doing. There have been innovations in big machines (analogy parallel would be Hadoop or whatever). But at the small level, people are still using the basic hand implements they've always used because they always work, they work everywhere, everyone else knows them, and it's pretty hard to get the design for new ones wrong. Like the author says, his ideas don't mean you should use Smalltalk or Lisp. Just that you should demand features, like how it took until Rust for sum types to escape functional. But the reason you shouldn't use Smalltalk is also the reason why languages like Smalltalk aren't going to get made: because when you're making a general-purpose language, it is extraordinarily hard to paradigmatically improve on what came before, and it's very easy to just get it all wrong and make a pile of trash that makes developers at the few companies that adopt it mad at you. Even Rust is not that amazing in this regard; its wild and new data model is in fact the exact same one you were supposed to be using in C++, just minus the ability to refuse. Everyone smart who was able to make these things has been snapped up by big data where their talents produce the most direct value.

koyanisqatsi 4y ago
What kind of direct value are you thinking of? I don't think most data scientists and ML engineers could write compilers or tensor algebra frameworks and gradient based optimizers.
- lasfter 4y ago
  I think OP is saying the people who can write compilers or tensor algebra frameworks and gradient based optimizers get snapped up by big companies, not that every one who works in big companies is so capable.
  - koyanisqatsi 4y ago
    That makes sense. Thanks.
4y ago

apienx 4y ago

"Docker shouldn't exist. It exists only because everything else is so terribly complicated that they added another layer of complexity to make it work. It's like they thought: if deployment is bad, we should make development bad too. It's just... it's not good." Jack's not wrong. But better to look at it as throwing (increasingly cheaper) compute at the it-runs-on-my-machine problem.

doctor_eval 4y ago
When I lived in the Java world, Docker solved a heap of problems because Java has so many external dependencies - you needed the JVM, all its libraries, and all sorts of configuration files for those libraries. But how is a docker image different from, for example, a statically compiled single-binary Go executable? Because when I work with Go, I tend to think that if what I'm working on requires something defined from outside the binary, I'm doing it wrong. So is Docker a solution to problems that are inevitable, or is it just a solution to problems caused by other solutions? These days I tend to think that something like Firecracker is more likely to be a solution to deployment problems than Docker is, but I haven't tried it yet...
- vbezhenar 4y ago
  I live in Java world and docker solves exactly 0 problems for me. Maven or Gradle deals with assembling all the necessary jars into a single directory (or uberjar if you want, I don't like it). JVM is another directory. Running application is a shell script of 2-3 lines. So my Java application is: directory with JVM, directory with jars and start.sh. It works almost everywhere. It's simpler than docker. I can replace JVM with windows version and start.sh with start.bat and it'll run on Windows. Natively. Can't do that with Docker. To build my application one would need to have maven (one directory), JVM (another directory) and project sources. Set up two env vars (JAVA_HOME, PATH) and run mvn verify. That's about it. Windows, Linux, macOS, doesn't matter. Single binary is simpler than a directory with some files. But not much simpler. I use docker, because that's the way things are done nowadays. I think that for personal project which does not need Kubernetes, I wouldn't use it.

HankB99 4y ago

My first exposure to computers was using punched cards to write Fortran. I wonder if the author was a classmate (at Purdue Calumet.) Otherwise I did not have the patience to read much past that.

beefman 4y ago

Some interesting links from this talk: Maria https://www.maria.cloud/ https://www.maria.cloud/ Glamorous Toolkit https://gtoolkit.com/ https://gtoolkit.com/ Data Rabbit https://datarabbit.com/ https://datarabbit.com/ Nextjournal https://nextjournal.com/ https://nextjournal.com/ Clerk https://github.com/nextjournal/clerk https://github.com/nextjournal/clerk Enso https://enso.org/ https://enso.org/

0x445442 4y ago
The enso link is interesting because there was another Enso project over a decade ago by Aza Raskin. That project, ironically, asserted the superiority of natural language and thereby text as a user interface.
- d0mine 4y ago
  text is superior (as in programming languages, not natural language) in the general case but there may be exceptions GUI builders, mock-ups, diagrams, tricking non-programmers into programming (iOS shortcuts(yahoo pipes), Scratch/Alice).
nudpiedo 4y ago
I wonder how many of them are in use for people beyond its creators/contributors, and in case of having actual users and customers, who are those (not theoretical profiles, but existing ones). This is an actual question, if someone has an answer I will gladly like to learn more about it.

helf 4y ago

Ok, I want to read this. I hate watching videos of talks. But holy fuck, what the hell is with this transcription output? I do not think I could read this post like this because it would make me brain hurt and also this is the worst layout I've ever seen from even an automagic transcription jeez

Arainach 4y ago
Amen. If the timestamps were hotlinked to the video for reference, that might be clever, but the overall format is awful. For reference, this is what it looks like on my screen: https://i.imgur.com/0VZEldv.png https://i.imgur.com/0VZEldv.png
- helf 4y ago
  Yep. Same. But let's not complain any more. Apparently that is faux pas
deleted 4y ago
[deleted]
dang 4y ago
"Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

systematical 4y ago

unreadable.

tomrod 4y ago

Fantastic talk. Loved it! Thanks for the post and the commenters who recommended it. Formatting was terrible -- even when viewing source! This made it somewhat readable import requests from bs4 import BeautifulSoup url = 'https://jackrusher.com/strange-loop-2022/' bs = BeautifulSoup(requests.get(url).text) muh_text = ' '.join([x for x in bs.stripped_strings if not x.startswith('00')]) print(muh_text)

remram 4y ago
I went with this JavaScript: let c; for (let p of document.querySelectorAll('body>p, body>div')) { if (p.classList.contains('aside')) { c = undefined; continue; } p.querySelector('span.time').remove(); if (c) { c.innerHTML += ' ' + p.innerHTML; p.remove(); } else { c = p; } } And this CSS: body p { width: 100%; } body div.aside { width: 100%; border: 1px solid black; } I'm thinking maybe that page was supposed to be embedded somewhere, next to a video maybe? It wasn't meant to be read like this right?
- tomrod 4y ago
  Really shoddy DRM maybe?
  - jackrusher 4y ago
    Definitely not! Sorry you hated the formatting. The transcript is meant to be an assistive technology for the video, and a place to put extra notes I couldn't fit into the time I had. Ideally, the transcript would scroll as the video advances and the timestamps would move the playhead to that part of the talk, but I haven't time this week to do as much hacking on that as I'd like.
    - tomrod 4y ago
      Absolutely no issue! I've only just come across your work and am astounded at both its breadth and depth. I thought perhaps the page wasn't owned by you, and that someone had ripped it from subtitles or something similar. The link for the article looks to have changed; before it was to a website that had text next to timestamps.

dang 4y ago

I've changed the top URL to the video, in the hope of reducing the tedious complaints about webpage formatting that the transcript was generating. The transcript is here: https://jackrusher.com/strange-loop-2022/ https://jackrusher.com/strange-loop-2022/. Please let's talk about the ideas now.

kragen 4y ago
I'm glad I happened across the item before you made the change! The transcript is the best transcript I've ever seen of a talk. I think the ideas are very interesting. I don't agree with his condemnation of Docker and single-threaded programming, but he's certainly right about the value of being able to kill threads in Erlang, and about the importance of being able to fix things that are broken, and about our computers cosplaying as PDP-11s (and the consequent teletype fetishism). I hadn't made the connection between Sussman's propagators and VisiCalc before. I mean I don't think Bricklin and Frankston were exposed to Sussman, were they? They were business students? But if not, it's certainly a hell of a coincidence. My defense of single-threaded code and aborting is that the simplest way we've found so far to write highly concurrent systems is with transactions. A transaction executes and makes some changes to mutable state based on, ideally, a snapshot of mutable state, and if it has any error in the middle, none of those changes happen. So it executes from beginning to end, starting from a blank (internal) state, and runs through to termination, unless halted by a failure, just like the "dead programs" Rusher is complaining about. You put a lot of these transactions together, executing concurrently, and you have a magnificent live system, and one that's much easier to reason about than RCU stuff or even Erlang stuff. This is what the STM he praises in Clojure is doing, and it's also how OLTP systems have been built for half a century. Its biggest problem is that it has a huge impedance mismatch with the rest of the software world. I've said before that to get anything done you need some Dijkstra and some Alan Kay. If you don't have any Dijkstra in you, you'll thrash around making changes that empirically seem to work, your progress will be slow, and your code will be too buggy to use for anything crucial. If you don't have any Alan Kay in you, you'll never actually put any code into a computer, and so you won't get anything done either except to prove theorems. Alan Kay always had a fair bit of Dijkstra in him, and Dijkstra had some Kay in him in his early years before he gave up programming. Ideologically, Rusher is way over on the Kay end of the spectrum, but he may not be aware of the degree to which the inner Dijkstra he developed in his keypunch days allows him to get away with that. The number of programmers who are ridiculously unproductive with Forth (i.e., almost all of us) is some kind of evidence of that. Interestingly he doesn't talk about observability at all, and I suspect that observability may be a more useful kind of liveness for today's systems than setting breakpoints and inspecting variables, even with Clouseau. Data Rabbit, Maria.cloud, Hazel, livelits, and Clerk sound really interesting. I think it's unfortunate that you switched the URL; even for people without hearing impairment, transcripts are far preferable to videos, and this is a really excellent transcript. With a couple of screenshots, it would be better than the video in almost every way, though a few of the demos would lose something. (The demos start at 14'40".) The sort of people who were making worthless comments because they were confronted with a webpage formatted in an unfamiliar way won't suddenly start making insightful comments because there's a video link; they won't make any comments at all. So it's a mistake to cater to them and damage the experience for people who might have something to contribute. Video links make for shallow conversations.

mwcampbell 4y ago

> The reason I disagree with this position is because the visual cortex exists. [...] There's no reason to eschew [graphics] when it comes to program representation. Not everyone can take advantage of the visual cortex. Please don't take away one area where we're on a fairly level playing field.

akkartik 4y ago
https://en.wikipedia.org/wiki/Harrison_Bergeron https://en.wikipedia.org/wiki/Harrison_Bergeron
- mwcampbell 4y ago
  That story is clearly absurd. But in the real world, it might not always be such a bad thing to hold back the runaway feedback loop where the people with the most advantages gain even more. If non-textual program representations do catch on, based on the unchecked assumption (as in this talk) that everyone has normal vision, then figuring out accessibility for future non-textual program representations will be good job security for someone, if that work gets funded. I just hope that no blind programmers lose their jobs in the meantime. (Personally, I could probably muddle through with my limited vision, albeit possibly with lower productivity.) I should be used to people like me and some of my friends being routinely overlooked, as if we don't exist or can be relegated to a footnote, but sometimes it gets to me.
  - akkartik 4y ago
    I'm sorry to hear it :/ I've been trying harder to provide alt texts in images, for what that's worth..
switchbak 4y ago
So don't leverage a powerful capability because a small number of people can't use it? That's like saying don't build sidewalks because some people can't walk. We already lean heavily on the language centers, I don't see why we shouldn't lean on the visual and spatial ones.

noobermin 4y ago

I made my way through part of the talk on youtube, it was interesting but far too much for me to stomach. It really drove it home when he flashed slides of graphic organizations of complex data. While some parts might be better than a textual description, graphic representation of data needs to be useful, that is, you need to be able to look at a graph and glean information from it. At the section where he flashes an image of a re-imagined periodic table[0], he immediately exclaimed "look how beautiful it is!" and I was immediately instead confused. What does this image show? If it is a periodic table, can I see the periodicity? For example, can I tell two elements have electrons in the same shell by just looking at it? Can I see if two elements have the same filling of the subshell, and thus will covalently bind in similar ways? Can I tell which elements are more electronegative? I can glean all that from the "boring periodic table," which yes is a graphic representation and cannot easily be written in sequential text, but this new representation doesn't give me any of that at least as far as I can tell. The desire to represent an already existing set of data in a new graphic representation that seems to give no value apart from being novel is not helpful. I can extrapolate this down. A lot of things in life are the result of historical evolution; that is just how things are. While that history can lead to problems, it is just the way things are. And yet, it should be beyond obvious that not everything new is good. For example, while sure the examples he gave were clunky, I can say with absolute certainty that there are times where playing games on my NES is more enjoyable sometimes than playing games on my "supercomputer," because on my NES I can play until I'm blue in the mouth, whereas on my phone, I have to stop every 2 minutes and watch an ad that makes my phone even hotter than the console. When what I value is "having fun" instead of "newness" or "shiny graphics with anime girls" I can see that an older device is better. Should I conclude that "advancement in technology is bad for enjoyment and for my sanity"? No, because I am not that shallow in my reasoning here. It's clear that "old" vs "new" for my NES vs. mobile game comparison is really a complaint about the change in monetization models, and thus a different user experience for the gamer. In fact, the "old" vs. "new" argument obscures the real difference worth consideration, substituting the argument for a fight between nostalgia and novelty. "Old" and "new" should never be what anyone focuses on because more often than not, such labels obscure the true conflict. Really, certain people like the presenter value things other than "familiarity," things like "introspection" and "graphical representation" and "concurrency," and he's mad people resist what he likes. Thus, he chalks it up to others stuck in their ways, clinging to "history." The thing is "familiarity" isn't the only argument people have for why they don't use clojure or reactive graphical displays: "familiarity" is often a stand in for other things that the people he critiques value, things like their time and latitude to learn new things, or the fact that indeed, some things are actually better expressed in text and as a sequential program than visually or concurrently, or that there are cases where those models are still infeasible on a computer even today (none of my electromagnetic simulations other than the most simplest will work in a reactive notebook because while computers are much faster, being much faster means I just do larger simulations that can no longer actually run in a reactive setting well). That to me is the more (pun not intended) valuable discussion, a discussion of the actual "innovations" and the values you have in mind when you evaluate them. Like, sell me on why I even care about introspection in a computational physics simulation code when I think I'm doing fine without it. That to me is the more interesting discussion, a discussion of values. But that's the problem, just making another talk about how modern lispy introspection or something is cool is just another technical talk, and it certainly feels much less cathartic than painting everyone else who hasn't adopted your reactive notebooks as being luddites clinging to their VT100 emulating terminal windows. But that to me feels like where the actual meat is, a discussion of boring technical topics because there I can respond with actual concerns or reasons I can't use this or that, and such a discussion would actually be more interesting and productive for me and for people who want to sell newer paradigms. [0] https://youtu.be/8Ab3ArE8W3s?t=1359 https://youtu.be/8Ab3ArE8W3s?t=1359

groos 4y ago

"There are only two kinds of languages: the ones people bitch about and the ones nobody uses" -- Bjarne Stroustrup, whom Jack disses in the video.

hayley-patton 4y ago
Well, Bjarne did make C++.
nigerianbrince 4y ago

yazzku 4y ago

The "it works on my machine" meme killed me.

1letterunixname 4y ago

Yep. Erlang/BEAM PIDs, processes, supervision trees, supervisor strategies, supervisors are underrated. They should be built into the OS. Honestly, every "program" should be a function, return structured data, and callable from anywhere. Logs also should be structured rather than deserialized lines. Lines requires parsing. Parsing is a waste of electricity and time because it discards boundaries between values. The current paradigm is unwise because it's slow and inefficient unless you actually need lines. Rarely do you need just lines. Look at how nasty bash, grep, awk, sed, cut, head, tail, tr scripts will become. Also, debugging and profiling, I still can't believe many programming environments / IDEs lack the features and debugging integration that ancient Borland Pascal and MSVC had.

koyanisqatsi 4y ago
I'd settle for software that could reasonably save and restore its own state. Half the time when I close the laptop lid I have no idea what will happen when I open it again. More often than not some application and its state just disappears into the computational ether. One of Alan Kay's slogans is "The computer revolution hasn't happened yet" and he's mostly right. What we have are glorified calculators and media players instead of programmable devices that can augment intelligence and it's because the main runtimes/operating systems on these devices are not dynamic enough. Great deal of effort is required to extend and modify them to fit personal use cases. If you're not a programmer then you might as well just give up because the technical barrier is too high. So it's not surprising that most people have a negative view of personal computers and would rather let Apple and friends manage things for them even if that means giving up a great deal of control and privacy to a 3rd party which is mostly interested in making as much money as possible. The larger implications of all this is that a great deal of potentially innovative use cases are not feasible because the required effort is too high. Every innovative application has to essentially re-invent its own dynamic runtime and shoehorn it into the existing non-dynamic setup.
- 1letterunixname 4y ago
  macOS AND iOS flavor these fairly well with the defaults systems and prefs, but software developers have to understand how to save and restore state properly, and not fight it. Also, I think complete process state (secured by a kernel decryption key) should be able to be saved and restored. Open I/O file descriptors would probably drop if they represent remote resources, but code should be made resilient enough to reconnect and retry in the event of errors.

agentultra 4y ago

I think his take on “debug-ability > correct by construction,” has to assume that you can understand the problem or can understand the problem. In my experience this works fine when you have a mostly procedural process on a single machine. Set some watchers, step through execution, pause to inspect state. It is much harder to do with concurrency. And damn near impossible with distributed systems. As someone who has claimed to use these kinds of tools to verify protocols, I’m curious what cases he would break this preference for debugging over reasoning. Or is the contradiction intentional? I was big into Common Lisp for years and mostly into Haskell and Lean now. I still think debugging is fine and useful to do but I get the most bang out of being able to reason about my program before I run it. Once you have the definitions and proofs in place running the code is fine I guess but all the work is done. Whereas with more dynamic systems the work has barely begun: now I need to bump into all of the errors in my code while it is running. There are times when I want both and I don’t think the computing world needs to pick one and only one.

drewcoo 4y ago

The problem is not the programs. The problem is not the tools. The problem is that the tradespeople and craftsfolk who make them are, whether intentionally or not, wage slaves. They do not make for the joy and art of making, but constrained by monetary need. They do not seek to grow as makers and share what it is to make because . . . no one would pay them for that. If we want better tech and better ways of doing tech, we need to start being paid like smart people who can not only do what management can't, but also we insist on doing it in a way that's creative. In a way not managed as a commodity. Here on HN, we see hacker (at best) as commodity. This is not the right community for the message, imo.

sfink 4y ago
It's a persuasive argument, but most of the "dead" tools mentioned in the talk were created in the era where the creators were inspired more by the beauty of their creations than their relevance to some bottom line. C C++ Pascal Python Go .NET ML Docker etc. were all made by people who saw a niche and sculpted something new for the joy of it. (Not just for the joy, but still.) The current "...but does it monetize?" culture is a recent thing. For most of the history of computing, nearly everything was done by starry-eyed idealists and outcasts who were in love with exploring the new conceptual frontiers opened up by technology. Sure, even then there were Larry Ellisons out to skin the selkies and sell their pelts to the highest bidder, but they weren't driving the field. The vast majority of developments came from people on BBSes or MUDs or just in their private basement rooms, who delighted in coming up with working demonstrations of crazy new ideas and showing them off. Silicon Valley was the Kingdom of the Geek, before the Geek had been tempted to crawl into the gilt cage and be locked inside by the army of MBAs and VCs. But we did it to ourselves—where once we might show off a live coding hack or a self-modifying set of scenes in a MUSH, now we show off our new Tesla or whatever the latest variant of a giant cell phone on wheels is. (I don't disagree with what we should be moving towards.)

fermigier 4y ago

There is a strawman argument in the talk, about the limitation (or now, default) to 80 characters wide consoles which is presented as a "proof" that we're still living in the past. 80 characters (plus or minus 10) has a justification outside the history of teletypes and VT100s: that's the optimum for readability. Otherwise, there are good ideas, in the talk, but this particular one rubbed me in the wrong way.

hoseja 4y ago
Optimum for whom? Nineteenth century teletype operators? I never got that argument.
- goto11 4y ago
  Optimal for reading prose texts. I believe experiments have shown the optimal line width for reading speed and comprehension to be about 50-60 characters. But as far as I known this have only been researched for reading prose. I doubt the result will translate directly to reading source code, which is read in a completely different way.
  - fermigier 4y ago
    Yes, experiments are lacking for code, but I believe the physiological principles (eye fixation, etc) still stand. Also: the optimal line width for prose seems to be 50-75 characters (including whitespace). Source: https://baymard.com/blog/line-length-readability https://baymard.com/blog/line-length-readability Assuming you're using a language where indentation is either mandated (e.g. Python) or recommended (e.g. C with "One True Braces"), with 4-spaces indentation (here again, no experimental evidence, but this seems to be the norm nowadays), and you don't abuse cyclomatic complexity in your functions / methods, you have let's say between 2 and 4 indents on the left so 80 is close to the optimum. Note: up to 100 is probably still OK from a readability POW. But this assumes that all readers are able to increase their window size from the default 80. That's probably true for people using GUIs, but may still be problematic for people with sight issues (e.g. people over 50 or with more serious medical conditions...).

DeathArrow 4y ago

I will probably get down voted, but I feel like I waisted 45 minutes, keeping watching the video and waiting for something interesting. I think that a two minute video about live coding and visual representation, for those that don't know such things exist would have been enough.

bilekas 4y ago
I have to agree, a lot of his points where just pointing out bad/inefficient practices and calling it 'bizzare' behavior.
marcus_holmes 4y ago
video is a really bad format for this kind of content, imho. I can read faster than the video can explain. Even at 2x or 3x speed, it's still faster to read, especially if I'm only skim-reading to find interesting bits.

globalreset 4y ago

I enjoyed watching it, but plenty of this talk is completely misguided. Had some ideas from there were so much better, surely by now people sharing them would show people not sharing them how much better they can do and overtake the industry. Not to waste my time - most of the ideas expressed there lack in composability, and composability trumps almost everything else in the long run. Something that enthusiast of VMs, dynamic typing and runtimes don't want to understand. That's why stuff like live coding and interactive programming is always ever employed for small scope, throw-away things. Visual programming is harder to automate, operate on, reproduce and compose and so on.

axilmar 4y ago

While I understand that an interactive environment could be useful in a lot of cases, in other cases it might just be in the way...for example, when I am designing an API, usually I don't need any sort of visualization...on the other hand, if I want to explore data, then I do need visualization. Also, his critique for my favorite language, C++, is unfair. C++ is born out of the necessity to take advantage of the hardware in the best way possible. And while it might be a mix of different ideas, it does work well in a lot of cases, and testament to that is the software we are using to communicate, the browsers, the web etc, the infrastructure of which is basically done almost exclusively in C++. Furthermore, static typing helps in complex programs a lot. There are concrete examples around where static typing greatly helps solves complex problems. And complexity is not about algorithms only, it's also about change over time. A piece of code that does not have type annotations can become an ugly spaghetti mess really quickly, and that must be multiplied by ten each time a new developer is added to a team. Very entertaining talk, by the way. At no point it was a drag. The presenter has a real talent for it.