nsm

I wrote a post about this as someone who only discovered it in 2020 - https://nikhilism.com/post/2021/experiencing-smalltalk/

In Iain M. Banks' Culture series, customarily, a ship Mind displaces (teleports) your body to the center of the nearest star on death. That way your atoms contribute to the star and will eventually rise to the surface and spread through the universe. Also takes care of prion diseases.

The author has plenty of experience with Bazel, as Sorbet, the Ruby type checker they helped create uses Bazel. I agree that Bazel is almost always the right solution beyond a certain scale or multi-language builds.

The unfortunate reality is that open source developers have decided that they don't want the state of the art because "it's written in Java and is like a 50mb binary". Yes, I know there are certain things about Bazel that don't fit certain open source projects, like it may not be easy to bootstrap a build environment for OSes that want everything to be built from scratch, or want to support 10 different architectures, and I agree that Bazel may not make sense there. At the same time, if you see comments from both HN and on the internet, "it's in Java" is often how FOSS projects are making these decisions :(

I'll always be bitter about this. In particular I feel like Cargo was new enough that Bazel existed and if they had at least built a Bazel compatible tool in Rust (so use Starlark etc.) it would have been very much in line with the Rust ethos of safety and speed.

The thing about LSP is that you really want to minimize latency for the user, which local is still the fastest at. Particularly with newer incremental completion engines that don't need to re-read the entire giant project.

While you do want your build to be as fast as possible, the constraint is often throughput and not latency.

Agreed. I've been really happy with Ikea's Tradfri line. It's all on Zigbee, works without internet and doesn't need an "Ikea account". However lights and blinds only for now, plus they have perpetual shortages.

I built a little PWA just for me that I can use to scan ISBN codes of physical books I read. It then looks up the book and adds it to my spreadsheet of "Books I've read". I wrote a bit about it here https://nikhilism.com/post/2021/tracking-books-i-read-using-...

It was partly just a way to try out Svelte and XState.

A part of Dan Wang's 2020 letter discusses this https://danwang.co/2020-letter/

This "industrial literacy" is dominated by Asia today.

Is there a software platform that more accurately tracks how software is actually developed?

(I'm using JIRA below, but sub any other tracker I've used)

Generally I'll start with a very rough idea of how something should work. At this stage, I may not even capture a task in JIRA, or perhaps not even tell anybody I'm trying something out, because it is an experiment very likely to fail.

If that works, I'll put together a document (Dropbox paper/Google docs etc.) laying out the basic idea and what needs to happen to fix the problem at production quality.

This will surface a multitude of open questions, some of which are more around code-reading and prototyping, than again, a deliverable that can be captured in JIRA.

In addition, as the project becomes more of a reality, other teams with dependencies or concerns are pulled in, and the scope of my document expands to capture how we are going to solve or work around those problems.

The difficulty I face is that it is really annoying or sometimes even incoherent to create JIRA tasks capturing things in this document. First, because I am now duplicating work that was already captured in the doc. Second, I'm losing the narrative structure that keeps it all coherent in my mind, as well as the minds of readers. Third, it is near impossible to reconcile tasks being closed in JIRA vs keeping the doc itself live. For example, something might come up that forces a change of design, and now I'd like to throw away all JIRA tasks related to a specific section of the doc. But creating that level of specificity while filing tasks is really hard, so now I need to run some kind of triage and manually read and filter those tasks I want to close. This means I'm either procrastinating on updating JIRA to reflect the real nature of the project, or I'm procrastinating on updating the narrative.

Instead, if the tasks were somehow inlined into my narrative structure, and manipulable within that structure, that would be really cool! Something along the lines of Tiddlywiki almost. That way everyone on the project could see what is done and what is pending _as part of the narrative_. I can very easily write sentences to capture a new requirement and do some markup or keyboard shortcut to assign it the semantics of a task.

I guess a related ask here is to make it very easy (thinking of something like Grafana) to create dashboards that show things like "number of open tasks left to finish feature X" and so on.

I hope I'm getting some of my ideas across.

Completely agree with you!

"Growing Object-Oriented Software, Guided by Tests" by Freeman and Pryce is a great book to get started learning how to test well.

Yes, I think more than "written in Rust", what is attractive about these tools (and other Unix replacements like Ripgrep, FZF) is more their attitude of "we have a lot more computing power and higher resolution/larger screens now. let's have saner defaults, intuitive UIs or larger search spaces (in case of FZF) to actually take advantage of that."

There is now a good parser/interpreter already written for a proper configuration DSL in Rust - https://github.com/facebookexperimental/starlark-rust

If your Rust program needs a more complicated configuration (conditionals, access to APIs and so on), also look at Facebook's Starlark parser and tooling[1]. Starlark is a subset of Python used by Bazel, Buck and a few other projects.

[1]: https://github.com/facebookexperimental/starlark-rust

This post actually suggests cloning John von Neumann as one of the options if we ever have adversarial AGI :) https://fantasticanachronism.com/2021/03/23/two-paths-to-the...

Individuals in the Culture are free to state whatever they want, that doesn't mean the civilization executes it. Taking the thought (not action) of one individual in a civilization that has on the order of trillions of individuals is hardly being fair to your representation of the Culture. In addition, whereas in our world, such a person would likely be Twitter shamed into oblivion, even if they had such a thought as teenager, in the Culture they would have a reasonable argument with other humans and Minds that would attempt to convince them of the foolishness of pursuing a genocidal agenda. The Culture tries to preserve life as much as possible. For context, what actually ends up happening is that Earth is left to its own devices. The Culture is dedicated to doing the right thing, but that right thing isn't always easy to figure out. To quote the State of the Art: [Diziet Sma asking the Ship Mind] "How certain do we have to be? How long must we make them wait? Who elected us God?" [The ship] "Diziet... that question is being asked all the time, and put in as many different ways we have the wit to devise (...) and that moral equation is being re-assessed every nanosecond of every day of every year, and every time we find some place like Earth -- no matter what way the decision [to interfere or not] goes -- we come closer to knowing the truth. But we can never be absolutely certain... I'm the smartest thing for a hundred light years' radius, and by a factor of about a million (...) but even I can't predict where a snooker ball's going to end up after more than six collisions."

For fans of Banks, who are looking for a analysis of the Culture books through the utopian lens, I highly recommend "The Culture Series of Iain M. Banks: A Critical Introduction" by Simone Caroti. To quote Fal N'geestra from Consider Phlebas:

"Everything about us, everything around us, everything we know and can know of is composed ultimately of patterns of nothing; that’s the bottom line, the final truth. So where we find we have any control over those patterns, why not make the most elegant ones, the most enjoyable and good ones, in our own terms?"

Airtable (airtable.com) is doing something like that. It’s less Excel and more a souped up relational database, so a slightly different angle where you surface the CRUD of a CRUD app to the user.

As someone who already knows how to program, I've really liked https://r4ds.had.co.nz/index.html.

It jumps right into visualization from the very beginning, which is great as a feedback mechanism, and also highlights R's strengths (ggplot2).

It is possible to have a programming language with well defined semantics, the ability to have libraries and utility functions and other nice things, while not requiring Turing completeness or the need to always expose file I/O etc. This allows reproducibility and not hitting things like the halting problem in your config file.

See Starlark, which is a subset of Python used by the Bazel build system - https://github.com/bazelbuild/starlark

Haha! My very first thought on reading the parent comment was "Hillel Wayne would be all over this!"

I am really glad they mentioned Smalltalk! I recently had a chance to experience Smalltalk and it was just mind blowing. Check out a video demo of the code introspection and visualization at minute 17 in https://m.youtube.com/watch?v=baxtyeFVn3w

If you are using open source packages in a corporate setting you really should be a) pinning versions b) maintaining secure, internal mirrors instead of always pulling from Github etc. That would prevent breaking your builds without being intentional about it, regardless of what changes upstream introduces.

A lot of ideas here are present in Bazel (where the Starlark configuration language is intentionally very declarative and not-entirely-turing-complete).

I also encourage anyone interested in build systems to read this paper https://www.microsoft.com/en-us/research/publication/build-s..., that provides a strong theoretical foundation to analyze build systems.

I really like Dorian Taylor's analogy of software to movie production: https://doriantaylor.com/softwares-ailing-mythology Their point is that software is a refinement of a process to the point where it can be executed by a computer (in a generally bug-free manner). Just like a movie spends a lot of time in pre-production and writing the script, we must spend a lot of time on refining our own understanding of our processes, before trying to explain them to computer via code. The faster one jumps to code, the more likely one is to have to go back and fix things, delaying the delivery of software.

So software is more similar to writing novels or movies, than construction, where a lot of time is spent just thinking through things, and going through the ups and downs of "writer's block". Perhaps one way out is to loosen the delineation between making software and using software (a la spreadsheets, Smalltalk) and moving towards more programmable environments, so one doesn't deliver software, but rather allow users to build their own as part of refining their processes.

It isn't that it is hard, it's that it is a thing that has to be done, and so your brain cycles + interruptions are dedicated to these things.

Cooking is generally taken care of by parents, which means ancillary things like grocery shopping are too. You don't even have to dedicate brainwidth to "what groceries do we need to buy". There are so many tiny interruptions and bureaucratic overhead that keeps the brain slightly stressed as an adult that simply don't exist as a child, it is marvelous.

In his book Oxygen, Nick Lane argues that most age related diseases are a function of cumulative oxidative stress, particularly in the mitochodria. He suggests that vigorous exercise is actually more stressful than lower intensity exercise, as well as the effects of calorie restriction etc on how the body handles the longevity vs reproduction balance. I think this may have a part to play in hunter gatherer societies, which were calorie restricted, and also relaxing most of the day :)

Vim/emacs key bindings for the browser like Vimium.

Prevent me from quitting the browser accidentally - Ctrl + Q

Tree Style Tabs which I would happily pay for.

Third party bookmark service like Pinboard, although this could be accomplished by an app as well.

Note that modern Smalltalks allow exporting code out to plain text files so one can use Git and code review tools just like any other language.

Writing unit tests _is_ part of the interactive development style in Smalltalk. In fact TDD arose out of a lot of (ex)-Smalltalk developers. When you have an environment as mikelevins describes, where the debugger allows you to author-as-you-go, you can start by writing a test and fill in the implementation and have your test go green, all in one very tight loop.

You actually can run a bunch of unit tests in Smalltalk with a single-click, get results, and be dropped into a full authoring environment when tests fail, with the bonus that you can just fix the code and resume execution to have the test go green. Modern Java IDEs can probably do this (I've no experience with Java), but you've to understand that this was possible in Smalltalk several decades ago.

I'd also add this talk "Lambda World 2018 - What FP can learn from Smalltalk by Aditya Siram " https://www.youtube.com/watch?v=baxtyeFVn3w

as well as the whole series of things that Tudor Girba & co. are doing with Glamorous Toolkit https://www.youtube.com/channel/UClLZHVq_-2D2-iI4rA2O8Ug

I'd still recommend folks use Pharo over GToolkit for most things, as GToolkit lacks a bunch of polish and documentation (not to say that even Pharo documentation approaches anything of the quality of the Rust and Python ecosystems).

> At the end of the day, you quit your environment and shut down. How do you ensure your interactive work is not lost and the environment is still what you expect it to be when you start again the next day. How would you compile such a program?

Modern Smalltalks have solved this problem. Smalltalk has the concept of Packages just like Java, and as you go along building your environment, even though you are modifying the Smalltalk image, you can export these packages to plain-text files, and put them in Git, just like any other language. The environment itself supports Git integration (called Iceberg in Pharo).

> Also, if significant parts of the source code are written inside the REPL, wouldn't the lack of modern IDE features be a hassle? No syntax highlighting, no code completion, no code inspections etc. Or are there tools that offer those?

The command-line REPLs that other languages have are NOT what you get in Smalltalk. I believe the author means the entire interactive environment, and the "style" of development is REPL, not the actual UI. The Smalltalk "IDE" is just as powerful as any other IDE, including code completion, automatic generation of certain getters/setters, renaming methods/classes, finding uses, jumping to declarations and even refactoring within methods. The difference between a normal IDE for Java is that this "IDE" is pervasively available, including in breakloops and the debugger. Since the system is live, there is no separate notion of debugging, the debugger is always there, and you can use all the editor IDE features when stopped in a debugger. You no longer have to deal with a crippled debugging environment way different from your authoring environment. It truly is mind-blowing!

I highly recommend giving Pharo Smalltalk a spin (by following their MOOC or similar). This video is also worth a watch - https://www.youtube.com/watch/baxtyeFVn3w

I did most of this year's Advent Of Code in Smalltalk and saved it in Git just like any other language. Someone else can then import it into their image. https://github.com/nikhilm/AdventOfCode2020.

Note that the source code looks very verbose, but you never actually interact with the source like that. The source is just a serialization. Your actual environment only ever shows you UI elements and entire IDE windows describing your classes and individual methods.

The only thing I miss in Pharo is that it doesn't have Vim keybindings :) Apart from that there is a significant lack of OS integration and polish, but these are due to the small community and priorities than fundamental deficiencies.