"Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022) 

in 50 years, people will look back at our time and laugh like how we laugh at fortran

professions are cultures

​@@DogeMultiverse No, totally disagree. We're still digging ourselves into a hole. We first need to get out of it. Watch: "The Mess We're In" by Joe Armstrong

You cant really know if the food tastes good until you have some. Thats what went through the customs officers mind i think.

I had a program to run remotely on lots of servers and something in the shell and terminal setup was eating a few of my characters. I added multiple lines of #### for a NOP slide to overcome that.

This is awesome. They could put throwaway code onto a few cards, like some superfluous OOP or Rust checkout checker border patrol or whatever they call it, and the rest of the program could still run in France.

My blood started to boil just reading this.

Actually kinda funny parallel to Docker and the whole "ship the whole machine that the code works on" meme

Watched it 2x… 😛

But it also trigger my silver bullet detector. While I agree C++ is a bloody mess, you can still write reliable real time programs in it. Of course, you can't use dynamic memory allocation (apart from the heap for function call) and you have to be careful about which standard libraries you use. And C++ is a pain syntactically. I wonder how python works in real time systems with digital and analog inputs?

"The best tool for the job" largely depends solely on what the most senior programmer in the company is familiar with. It rarely has anything to do with tech and more to do with politics. These guys have usually been with the company since the beginning and the executives know him and trust him, so he has carte blanche to do as he pleases, so if he thinks the best tool for the job is Cobol or Delphi then that's exactly what will be used as long as it delivers software that makes money for the company. Sorry to burst your tech utopia bubble but politics and profits are way more important than the "tools"... if management agrees that the latest and greatest tech needs to be used to write good software then thats what will happen, if they agree that the legacy code is working fine and doesnt neeed to be written in the latest tools then sorry for the 20 year old junior intern but you will need to learn the ancient tech to work there and it will look terrible on your CV but that's just how it is.

@@57thorns >And C++ is a pain syntactically. I love C++'s syntax, personally. It just feels natural and easy to understand.

I'm a big fan of "idea the right tool for the job," I hate when people try to force solutions into a system to reduce the total systems/languages in use. my current company does that, does everything in javascript when other frameworks or languages would be better.

You can do what he talks about in the video really quickly by just asking ChatGPT.

You had coal? We had to scavenge for firewood.

@Eleanor Bartle not in computer labs.

A week. wow!

😱

And then you learn that there was a FORTRAN available for the ][s UCSD system and weep. I once wrote a punched card Pascal program (for a uni course before terminals became available for those) by first developing in UCSD, then going to the card punch with the resultant listing. (I'm not sure, it might have been the 7 billionth implementation of Life.)

@@KaiHenningsen Also people often hate on fortran because they had to use 78 version and practices. Modern Fortran is OK in my opinion.

@@TheAntoine191 I think deeming it "OK" is valid for those who still must maintain programs in it, but there are still too many leftover - or even new - oddities that prevent it from being used in the ways that C is still useful. Some of these being: if you want an array of pointers to some data type, you have to use a structure; the lack of a true way to define/typedef custom data types; the intense duplication and verbosity required when declaring methods on classes; the syntax for declaring subroutine/function arguments; and the lack of a literal syntax for nested data structures (like assigning a value to an array that exists as a field inside of a structure, all at once). However, other old, largely forgotten languages like Ada, Modula-2/3 and modern variants of Pascal (Free Pascal and Delphi), certainly do have many redeeming qualities and are still very usable to this day, sometimes more so than mainstream/popular solutions even, Ada being the biggest tragedy out of the ones mentioned, in my opinion.

SPF Editor! Now, _THAT_ brings back memories.

I feel like Dark Lang is pretty close to what you're describing, and it seems really cool, but I'm not quite ready to have so little ownership of the tech stack

Then it may please you that _informatics started with such tools,_ like the Sketchpad from Ivan Sutherland (but it's better to learn about it from Alan Kay because the original demos don't really explain the difference between "before" and "after") or the NLS from Douglas Engelbart (look up the Mother of All Demos, pay some attention to the date or the hint at the end that ARPANet "will start next year"...) Unfortunately, Engelbart's Augmenting Human Intellect Report is a very hard read, the whole field lost the point and the result is what we have today.

And not for the lack of trying. I've watched oir read pretty much this talk at least five times in the last 30 years.

Results like that we have the ultimate communication infrastructure, but people don't feel pain to - limit themselves to a single bit, "Like" and think that any number of likes can ever worth a single statement. - repeat the same statements picked up here and there without processing and pretend that it is the same as a dialog. - rip off and descope the "Stop drawing dead fish" lecture (Bret Victor, 2013) in 2022. It's not about coding and punch cards but our very relationship with information systems (in machines, libraries, human communities and within our own brain). _"Why do my eyes hurt? You have never used them before."_ (Matrix, 1999)

Domain modelling is bunch of graphs.. cqrs, ddd and so on. All is just processes and workflows.

It was a revalation...

Yeah, it makes VI look logical. When I first saw VI, I could never understand how people accomplished anything, but my boss [i.e.: my uncle] kept pressuring me to use it.

@@eugenetswong But the fact that a subculture of people is using, for decades, ~ IBM-compatible keyboards, with editor software that's totally mismatched to that, is kinda hilarious.

@@tinkerwithstuff it really is, as I started learning computers when I was 8yo on DOS6.22. edit_com just felt natural for the IBM PC keyboard. When I came to the unix world, their stupid editors always felt "wrong" anachronistic. Why can't I have "edit_com" ? every sane editor I ever used on PCs with Windows or OS/2Warp was always like that. (and yes, I installed OS2/Warp when I was 10yo on my PC) Linux/Unix always felt like going to the past, to a museum. That can't be true, why would anyone ever want to use "vi/vim" ? Emacs, it at least made sense, you call anything with "command", which is `ctrl`, like every modern keyboard shortcut ever in any GUI program like qbasic or edit_com or msword. Then I found "nano", well that solves the problem. But the more I studied Unix/C, the more at a museum I felt. Like why ? why must I program my supercomputer x86 from 2007 like a freaking PDP11. Let not get me started on how brain damaged is writing shell scripts. I HATE IT, Why can't you "unixy/linuxy" guys just use Perl or Python. And the top of my unix journey was "autotools" , FSCK IT ! no, I had enough, even CMake is better than that, even ".bat" and "nmake", I'll never, ever, ever use it, just reading the docs give me headaches, why, why do you have 3 abstraction levels of text-generation, its absurd, it literally easier to write the command manually (in `nano`) and ctrl-c ctrl-v them to get the freaking binary. And when I'm choosing libraries for "C++", I chose those NOT use any that only provides build script for autotools. Lets also ignore how all code that has the "GNU" is basically horribly written, from 2010 perspective, and I've read a lot, A LOT of C/C++ code. Its just amateur code, not professional, by modern standards. It baffles me that people think they are good. If its from a GNU project, the code is basically a "bodge", example is "screen", not only the code is really bad, the user interface of the tool is really, really bad, like a circular saw plugged to a angle grinder that hangs from the ceiling by its cable, no wonder you keep losing your arms. And those horrible, horrible things are worshiped like if they were the holy grail of the `Church of C`, or must I say the `Church of PDP11`. I understand the historical importance of such things, but they are super anachronist, its like driving day-to-day in a Ford Model-T, its not good, it was good for the time, but I prefer my modern 2019 peugeut. I wanted to do computing, not archeology of old computing systems. That's what unix always felt like. I like knowing it, and experimenting with it, but I don't want to use it on my day-to-day job, but is there any other option.

The one thing i don't get is his hate on "fixed width" tho. Whenever I program in a new invironment that uses proportional fonts, I switch to something with fixed width, because without it, numbers don't line up any more. A 1 takes less screen space than a 2 without fixed width, and the code looks ugly. Even worse if you depend on white space, like Python...

agreed

Can you explain for me please

@@pleonexia4772 You load the large dataset once and edit/rerun the code on it over and over instead of reloading the dataset every time you want to make a change to the code.

@@DanH-lx1jj and then you still rerun everything if you ran cells in wrong order at some point

Make sure you also get familiar with breakpoint debugging and stopping through running code. Absolutely essential for a self-taught programmer in the "popular" languages.

@@pleonexia4772 look up Don Knuth and literate programming. Pretty common in Emacs circles to write executable code in blocks in org-mode (a kind of "markdown"), a precursor of these notebooks.

Yeah its a peek to the future, if people decide to pick it up. Hope it comes to fruition, because bringing a coder closer to their code will only make it easier to see what actually goes on, past the abstraction of language syntax, semantics and language specific quirks.

@Curls Check out this talk: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-yY1FSsUV-8c.html

I still haven't used it myself but you might be interested in Sonic Pi

Supercollider is an advanced audio synthesis tool. Faust is a nice DSL for audio.

Yeah SuperCollider, TidalCycles, Max MSP and PureData are great examples of this

Indeed, that's the same point that game devs John Carmack and Jon Blow make. The debugger is the most useful environment there is. Also note that regex is amusingly not the same thing as formal language theory's regular language. After I learned that I started to forgive myself for having a hard time with them. en.m.wikipedia.org/wiki/Regular_expression#Patterns_for_non-regular_languages

Yeah I open up Regexr website every time I need to write a regex. Would be great if IDEs at least tried to help you with the visualization.

Debugging in a live environment is very problematic. Just imagine a order process of a web shop and you debug it in execution and mess things up accidentally and as you stopped the process it's not executed and also other orders are not coming through. There is a much better way. Write tests. I sometimes don't even try out my changes manually. It's tested and if I would have broken something the changes are high, that some test will find that. Some testing frameworks have even watchers, that execute the tests every time you safe your file, so you immediately see if your changes work. If you have proper tests, there isn't much in production that can cause it to fail. So instead of debugging a live server I would rather set up the development process in a way, that you find bugs before they reach live. That at least works really well for me.

@@Duconi Nobody intentionally writes bugs. Prevention is good but not perfect. Don't you still need a minimally disruptive way to fix the live environment?

@@brunodantasm It depends on which kind of regex you are dealing with. Regexes from SQL or grep are real regexes. The ones in many scripting languages that use the perl syntax are fake regexes and can be six orders of magnitude slower on hard inputs

Yeah this exact exchange is what I was thinking about while listening to him. Compiling isn't a bad thing, it's an optimization. I use python for rapid prototyping, for instance, but when I'm done playing and ready to do some work, I write my final in C++, because it's fast. Yes I've spent days compiling libraries before, but once they were compiled, I didn't have to worry about them, didn't have to wait for my computer to chug and choke on the complex human readable parsing. Computers are not humans, don't feed them human. This whole mentality is an offshoot of the "just throw more hardware at it." camp, one I find regrettable.

@@Nesetalis The problem is that most languages don't have both an optimized and unoptimized (introspectable) version. I want to be able to do both without changing language. I expect he does as well.

@@jrdougan Then use Haskell 😈 (admittedly, GHCi is nowhere near LISP levels of interactivity. But, it's better than nothing)

@@jrdougan I don't think that would be enough to him. It seems like he wants introspection on production. I don't see how this is possible without making some major tradeoffs like globally turning off optimizations or annotating things that can be introspected. In fact it seems like he even wants to make the code modifiable at runtime (not necessarily the production code though).

@@gamekiller0123 I mean, why not. Basically we already doing it, just in a slow way. In bigger projects, usually you don't just deploy and overwrite your previous version, you deploy it, let it running through staging/production pipeline and then make it first available in addition to the existing code via an internal route for the programmers and integration testing pipeline, then you'll canary make it available to a small part of users, monitor it, if nothing fails, you make it available to a significant part of users (let it route to the new version, while still keeping the old version), then if you don't monitor something wrong, you'll make it the default and then you stop serving the previous version and finally make a deployment some time later to get rid of the deprecated functionality. So, what happens as effect is that we are changing the runtime without really switching it off (if we regard the executed distributed environment as one unit execution). But the whole process is slow (we are talking about hours to see first changes and days till everything is finished -> very punch card like) and hard to debug and monitor (even with tools like distributed tracing or kafka or w/e). There wouldn't be anything wrong or scarier if the programming model just would allow to do these changes directly in the runtime (probably still keeping different versions) and not do it on microservice level with the help of container runtimes and routing services and complicated tools for introspection. Just doing what the language should do for us involves in the end knowing Docker, Kubernetes, API gateways, Prometheus, DataDog, Kafka, a CI/CD pipeline, and many things I might have missed on the fly now. In the end, most companies are now in high demand for DevOps engineers to optimize this process (-> punch card operators are back) as the complexity is too high to really expect the programmers to handle while they are trying to solve a complete different problem (the business case).

tbh, C or even asm is still obfuscating stuff from you. i would say it's more a matter of knowing the hardware you're running on and knowing the quirks of the language and the compiler. (which would naturally take years.) blaming the language is not entirely correct imo.

I've been chasing live system programming for years. Dart provides a lot of what I am looking for, as well as Python with hot reloading (see a project called Reloadium). One of my ideas for my own system (that has yet to be written) is a little similar to the last example in this video. There are nodes which represent your program and there are "sparks" of execution so you can see data flow through the system.

And before that the predecessors of punchcards were used to "program" weaving looms.

woah cool to see u here lol. seems like some core tenets of the philosophy that underpins your work is well represented here

@@seismicdna I think we share a lot of similar ideas, I was fortunate to stay with Jack in Berlin a few years back, and meet Szymon Kaliski too. I was sad to hear that Strange Loop was stopping after this year, I've been dreaming of attending.

@@DevineLuLinvega There will be one more next year. You should give a talk!

I'll need to watch again to digest further. Working with a data team as their engineer is both a blessing and a curse. I've seen some of the benefits of the interactivity that Jack talks about. Particularly with data pipelines sometimes the easiest way to debug it is to pull open the notebook and run it until it breaks and inspect. It's also easy for analysts with little programming experience to write things and get started and explore. It's a curse because it does make it so easy that I'm often tasked with fixing and maintaining a heap of poorly designed programs written by many times the people than myself, with little to no consistency. Many of the perks that Jack mentions are useful for scientists/analysts for whom programming is merely a means to the end of getting their analysis done. Not having to worry about types is nice if you just want it to work. As an engineer, working with typed systems means I _don't_ have to keep the mental "working memory" whenever I jump in to make a change down the line to remember what I nuances of my interface I have dynamically programmed. Like I said, will have to watch again to really understand.

@@JackRusher I'd love to! I'll try to get in touch with the event's team.

it’s up to us to create the solution.

I know a lot of people love APL, but it seems too terse to really be readable to me

@@thoperSought APL is part of the "fun thought experiment but the next guy will just want to shoot himself while reading your code" languages. No sane person would use it for large software (or at least I hope so).

​@@thoperSought It is easy, all you need is a keyboard with 200 buttons

@@thoperSought What if your reading speed is reduced by 80% but the amount of code is only 10% of the alternative?

@@thoperSought The “expert-oriented” terseness of APL/J/K is scary at first, but it soon pays off, because the core languages are so tiny that you can become an expert surprisingly quickly. There are only ~5 syntax rules and ~30 symbols to learn, depending on how you count. Beyond that, basically all of the problem-solving skills are transferable to other languages, especially to APL alternatives like numpy/R/Julia/Excel.

Unfortunately, those two are a lot more stateful than the average non-visual languages, because every function has been turned into some kind of object class that, if it has more than 1 argument, every non-first argument is an instance variable that has to be set before sending the 1st argument. And if ever you want to set the 1st argument without running the function, or running the operation without setting the 1st argument, you have to use special cases like "set $1" and "bang", IF they happen to be supported by that given class. Then to manage all of this, you have to sprinkle a lot of [t b a] and [route stuff] objects and connect them with lines that quickly get hard to follow. The DSP subsystem (~) is the exception to this, but that's only because it has a fixed data rate, and then when you try to control that subsystem at runtime you have to use non-DSP objects I described above.

Imagine a craftsman complaining that one needs to know metalwork to craft woodworking tools. Or a soldier moaning that all those logistics officers are not contributing because they don't fight. You'd just laugh at them. Creating tools has always been an investment, spending effort on one task to make another task easier. Teamwork has always required coordination. IT is no exception. If you become able multiply your workforce by 50 and spend 10% of that on the "actual problem", you have quintupled your progress. If you don't want to coordinate a team, your only other choice is to work solo. And while it sounds intriguing not to deal with 49 other lunatics and their code that conflicts with everything, including your sanity, it will really slow you down, more than team coordination ever could.

I think your argument applies to just reducing LoC, but better abstractions can also eliminate certain types of mistakes. For example, a hash function builder reduces the chance that some hash function is written incorrectly and produced collisions.

docker's imperative config and uninspectable (possibly even malware-ridden?) root containers to me is already part of that legacy mentality, people just slap it in because everyone else is doing it, not because it gets the job done the best. imperative config and orchestration is the way to go to eliminate most of the issues you mentioned in "technical bureaucracy" as you call it. "corporate bureaucracy" is just capitalist problems. and incompetence has nothing to do with this discussion. neither of these will be solved with better programming tools.

Have you ever led a team where you were free to remove that technical bureaucracy? I am. I haven't. For each of those items you list I asked how we could shrink the footprint but removing entirely would have gone badly. Certificates, hosting: Be maximally unoriginal in cloud provider setup. Source control: Yes. Have you tried scp on text files instead? Branches: trunk only except for shortlived ones just to hold pull requests. Pull requests, code review: So much more powerful than merely quality assurance. But yes, very expensive so always good to figure out when and where to skip.

@@LC-hd5dc I guess you meant to say declarative config is the solution?

Suddenly I think... Was there a method for making backup cards? Sure, read the cards and punch them. But did anybody do this?

Hmm, sounds like its better to design this kind of programming language with ui/ux designer together.

Yeah this is my experience too. Graphical programming looks greak only with simple small problems. They are incredibly harder to use and a waste of time when you need to solve real-wold complex problems.

The issue with this kind of presentation is exactly that, this convinces the management that the new shiny language is the solution to all the company problems but the sad reality is complex problems are complex in any language and learning the new shiny language takes longer than solving them. Create tools in your language that solve your problems is the current solution.

@@nifftbatuff676 Automate for Android comes to mind. Fantastic app, I use it for a bunch of stuff I can't be bothered to write Java for and browse through Google's API docs. But large programs are an absolute nightmare when everything is drag and drop.

Agree with this. You need the right tool for the job but a specialized graphical tool is really only good for solving problems that can be modeled graphically. I have wasted many hours with new tools that are supposed to bring about a new paradigm in how we program and in the end we always end up abandoning them because they never quite fit the problem at hand. The seemingly small gap between the cool demo example and what you actually need to accomplish ends up becoming an impassable chasm. In the end, tools are built by biased people who are thinking in terms of how to solve problems A, B and C but I'm stuck trying to solve problems X, Y, and Z or else a whole new class of problems, #, % and ^ that no one has ever considered before.

They have a potential to be much better in some important aspects like debuggability and prototyping. But most scripting languages did not go very far from static in these aspects, which does not make very much sense. Why sacrifice performance and stability for practically nothing? That's why dynamic interpreted languages are often perceived as inferior to static. It's either because most of them initially were either a replacement for shell scripting or developed to solve a very specific task (like JavaScript) and then accidentally grow bigger and become more significant. It's no wonder that the most advanced languages in that matter are Lisps, because they were designed as an AI research tool from the start.

1960 Lisp I called, wants its compiler back.

For understanding, debugging, and visualizing your program in real time? Yes, absolutely.

Yeah, It might be interesting if we can develop a language that runtimes during development (for interactivity, visualization, etc) but can compile for deployment. Because there are instances when interactivity just isn;t necessary and the required abstraction and overhead is nothing but dead weight.

I don't think those are properties of the programming language. Visualization and interactive visualization are features of a code editor or integrated development environment. Development tools for a lot of existing programming languages could do that if they just implemented those features. Those features would also be more useful for some languages than others. The features would be more difficult to implement for some than others too. The video makes it sound like the language and its development tools are completely tied together. If you're choosing a language to learn or use in a project, you might as well group the language and its tools together. If you're tempted to invent a new programming language because you want to use lots of visualization, the distinction is important. You can always make new tools and new features for an old language without changing the old language. Inventing a new language that no one uses doesn't help anyone else. Inventing tools for popular existing languages will much more likely cause others to benefit from your creation.

@@IARRCSim yeah, like sure all the ASM boilerplate is annoying, but people could write tools to automate that boilerplate as you're typing and fold it away for visual convenience. as an example. i'm sure someone's already done it and i just haven't really looked myself.

On the other hand printing out values is a lot more productive than that nonsense single-step debugging. Give me a printout of two runs of the program and a diff tool any time over stepping through it for hours trying to remember what the debugger displayed 1000 steps ago in the last program execution.

💯

finally some sense in these comments lol. i'm curious, what other options would you suggest for runtime introspection? usually what i've seen is slapping in logging statements everywhere, but i have to assume there's a better way

Logging, metrics, and tracing are the only things I can think of, but it would be nice if you could clone a running container stick it in a mock environment and step through the process.

Also even if JIT comes close to native compilation (at least as long as the latter does not use make use of profiling and other advanced optimizations) in either responsiveness or throughput, you typically pay for it in higher RAM usage, which is unfortunately the most limited resource in shared computing in multiple ways. Contemporary Java comes to mind there, even though on-flight editing is obviously not a thing there, I'm already grateful for a REPL.

how about this - JIT while you're working on the code, and then AOT when you want a prod release? i definitely don't agree with his suggestion that we want JIT in production.

As of Visual Studio 2022, you can use Hot Reload to change C++ applications while they're running. I'm actually quite surprised he didn't bring this up.

One Solution of combining heavy optimizations of Rust/C++ & capabilities of Smalltalk is to use twin softwares (or simulation). Works fairly well, recent smalltalk distributions have worked using such an approach for more than two decades now. They code their VM in Smalltalk (OpenSmalltal-VM/Pharo) and generate C code from it. There's also RPython that does similar things. This approach is loved by some, hated by others. Is this an example you consider to be a performance-dependent software?

@@pierremisse1046 I guess I'll try Pharo after learning some Smalltalk. But from reading about it a little, it still sounds like it'll bring some runtime overhead that might be difficult for the compiler to optimize. But I'll give it a go. If transpiled C will be faster than native JS, I'd consider it a win for Pharo.

yeah as far as i can tell, most of them were just showing nesting levels... ultimately they seem more like teaching tools than daily programming tools.

Wouldn't that be because most devs use 'traditional' code representation? In a world where programming is cannonically done in brightly-colored ballons connected by lines, trying to put it in a single sequential file might be the "hard to interpret". I think there's something to be gained here using visual&spatial&interactive programming, although I have not yet seen a version that sparks joy. Maybe functions as code in a bubble, and jump points (function call, return, goto) as a line between bubbles? It would visualize program flow without giving up the details you need to actually program. IDK, but it's an interesting problem.

@@rv8891 The problem with graphical representations is that they are bad at abstraction and that they are hard to process by tools. Code is all about abstraction and tools to help you work with it.

The issue is how to do product development with a team of developers on the same code base for testing and releases.

Would the team be working with a CI server?

Was it an issue of it being unclear how to address the server in question? I’m also curious how you feel it compares to today’s approach of using containers/images

Agreed. "Hard in a dumb way" is a concept that deserves broader awareness. Dealing with new problems created by the tool meant to solve the original problem is common. What ends up happening is that people either take false pride in making those symptoms the focus of their work, rather than the cause. Or an odd sense of envy leads them to force others to suffer through outdated and avoidable symptoms even when there's a better tool at hand.

I agree about a better notebook-like system modeling tool for business people. As a developer, whenever I have to do any spreadsheet work, I'm also struck by how immediate & fluid it is compared to "batch" programming ... but ... also clunky and inflexible to lay out or organize. I'd love to see a boxes-and-wires interface where boxes could be everything from single values to mini-spreadsheets and other boxes could be UI controls or script/logic or graphical outputs, etc. Now that I think about, I'm surprised Jack didn't mention Tableau which provides a lot of the immediate & responsive interaction he wants to see in future IDEs.

Most of his examples are about tools, not programming languages themselves. He shows the issues as programming language's issues, but in reality, most of them, are lack of tooling around programming languages. Game engine editors (not game engines) are made exactly to address most of these issues. I agree with him that the language's ecosystems lack some basic tools, but these are also completely program specific. For games you will need a 4 floats type to store colors, should the language know about this and have a way to visualize the colors in its own editor, even though the majority of developer might be using this same language to code CLI/deamon programs? Does keeping the state of a program makes sense when you're shipping a game to players? It totally makes sense when you're developing, for fast iteration and debugging, but when you need to release the game and publish it, you need to compile, disable hot reloading, disable debug asserts, etc, since the client (the player) won't need any of this and all of this adds a performance cost.

@@naumazeredo6448 its because a lot of programming language communities (at the encouragement of their developers) think of these things as language issues, because they have yet to ever witness the beauty of a programming language getting out of a better tools way and sitting on the side lines for a play or two. If there is a job to be done in software development, its something to do with a programming language, and specifically MY programming language.

Check out GOAL, the lisp that they made Jak and Daxter with and your mind will be blown.

Not a rust guy, but rust is a great example of how he missed the point of static typing. It's feedback at compile time. Run time errors are errors caught by the end user if you are not careful.

All that "types slow devs" sounds like dynamically typed languages are better. Maybe they are... until your fancy no-explicit-types JS or Python or whatever app crashes in the middle of logic because, for example, you forgot to parse string into number. Languages with static types (even as limited as C) just won't allow you to run such nonsense at all. Types are helpful for reliability, TypeScript, Python typing, etc. confirm this. Better slow down 1 developer team than have 1000 customers with "oh no, I made an oopsie" crashes.

Thank you. Way too many people who don't actually work on real systems completely ignore performance and maintainability and focus way too much on writing code 'quickly'.

Ad 1. And how being low-level, manually memory managed for peak performance stops you from having nice things like runtime modifiable code and introspection into live system? Those are orthogonal concepts and they aren't mutually exclusive. C++ approach is 'pay only for what you use', but there doesn't seem to be much to 'buy' when you actually would like to pay for those niceties. Ad 2. It's not that devs can afford the compile time, it's that they have to in some of the languages. E.g. you can run Haskell or Ocaml in interactive shell while developing, but compile to get better performance for release. JIT compilers do exist for various languages, so it's not like you cannot have a runtime modifiable system that performs well. C# has garbage collector, but you can use manual memory management to some extent when you really need to (high perf or interoperability with C/C++). It's an attitude problem, designers of the language(s) decided that's it's not of enough value. The point of this talk as I see it is to highlight the value of presented things and get language designers to think about such use cases. Ad 3. This is only an improvement in an environment with forced compile/run cycles. You type something, launch the compiler (or your IDE launches it the background) wait between 0.5s and 60 minutes for it to compile, you get an error about wrong type. You fix it, compile again, run it, spend between a second to a minute to verify that it works as expected (i.e. rule out problems that weren't caught by type system). Now compare it to: you type something while your program is running, you see clearly incorrect results on screen and on top of that you get an error. You modify the code while the system is still running and you see correct results on screen. IMO the second workflow is much better and more efficient. Also, look at TypeScript or Python - you can rapidly prototype your code omitting the types or add type annotations for additional safety. TLDR: compiled/statically typed vs interpreted/dynamically typed - you could have both and achieve high efficiency in development as well as high performance in runtime, there's no need to limit yourself.

Those high level tools look so fragile, they'd never make back the time invested into them.

😹 I prefer Scheme myself! I used SBCL in these examples because it is a very strong programming environment (compiler, tooling, &c).

Eliminating an entire class of exploitable bugs? That would be amazing

@@SgtMacska also probably eliminating multiple classes of machines due to performance

@@SgtMacska Haskell definitely has its uses in low level application though. In relation to security, it's a lot easier to prove Haskell code and compiler are mathematically correct (which is a requirement for some security standards), proving therefore that runtime is secure, than proving the same for another language. In general Haskell's clear separation of pure parts is very good for security, as that's a large part of codebase where you have no side effects

Performance-critical applications should be written in something like C or Rust (but not C++, f**k C++). When you know what you need to do beforehand and optimization and fitness of the code to the hardware is of the most concern, not modelling, getting insights about things or experiments. The talk was mostly about development environments and it doesn't make much sense for a kernel to be wrapped up in this notebook-like environment, because by definition kernel is running on a bare metal. But even there OS devs can benefit by modeling OS kernel routines in a more interactive environment using something like a VM before going to the hardware directly. Well, they are already using VMs, developing a bare metal program from scratch and not using a VM is an insane idea. What I'm talking about not a traditional VM but a VM-like development tool that trades the VM strictness for interactivity and debuggability. Of course a code produced in a such environment should be modified before going to the production, if not rewritten entirely, but we kinda doing that already, by firstly writing a working program and only then optimizing it.

we should eschew the kettle, for how desirable is it to make chilli in a kettle?

That's an issue with managers, and not coding methodology. Not that I agree much with what he says in this talk, but heard some horror stories of managers. And I suppose debugging in production means attaching a debugger to the currently working server or client on the customer's machine?

Debugging code in production is where you buy a system that promisses it because when a program crashes, it just falls back to the interpreter prompt so you look at all your variables and code, and then you write an entire point-of-sale system in said system and deploy to 100 stores only to discover that you can't dial into the stores to connect to the crashed system because they have just one phone line and they need that for credit card machines.

I do not know anything about Smalltalk, so you were producing what kind of applications? Who were the customers? What computers were running those applications? What years? Why Smalltalk did not became popular for corporate/business applications as C,C++, Java, C# ?

Smalltalk still exists, Squeak, Pharo, VirtualWorks are just a few examples !

you're not entirely wrong, but i think the reason why people use it is because the abstractions are easier to grok at first glance. and the limitations of the languages and tools mean that you can't get completely lost. i still don't agree about the "liveness" of the system being key necessarily though. the whole "compile" vs "run" notion is just an abstraction; i'm not gonna get into the whole "compiled" sql statements topic, but what i will say is that you're going from "i'm waiting hours for code to compile" vs "i'm waiting hours for this statement to run" i don't really see much benefit there. the approachability benefits come from decent tooling imo (like having a small sample of data and seeing how it flows through your query), which programming tools can also implement.

Interesting points there. I cut my teeth in a naive environment where all backend code was in the RDBMS server. It was very productive and carried a lot of the efficiency and elegance you not. But it was also cowboyish, error prone and felt more like jazz improv than crafting a great symphony. When I then went and studied proper software engineering I ate up every sanity restoring technique greedily.

Every time I work in R I feel like I'm back in the era of magtapes and getting your printout from the operator at the computer center. I reflexively look down to check my pocket for a pocket protector. ;-)

it is also an array language at heart after all

Rather, let me clarify by addressing specifically the "visual cortex" thought. It's absolutely true that we should explore graphics and pictures and how they can be useful - but it's not by any means obvious to me that it's actually worth dismissing 80 columns for being antiquated until and unless graphical systems actually supplant conventional linear representations.