pbohun

I have an old printer, maybe 15 years old or so. Linux still prints and Windows doesn't!

There also is an unofficial mirror which has updates.

https://github.com/TinyCC/tinycc

I'm not. I'm learning a little bit each day, making my brain better and myself more productive as I go.

It feels like everything is falling apart and getting worse. Yet somehow people are racing to produce AI slop faster. If software eventually collapses under its own weight, things might be so borked we have to bootstrap everything from scratch, staring with assembly.

It sounds weird to say, but Steve Ballmer was probably the best CEO of Microsoft.

Not quite. Erlang uses the Actor model which delivers messages asynchronously to named processes. In Go, messages are passed between goroutines via channels, which provide a synchronization mechanism (when un-buffered). The ability to synchronize allow one to setup a "rhythm" to computation that the Actor model is explicitly not designed to do. Also, note that a process must know its consumer in the Actor model, but goroutines do not need to know their consumer in the CSP model. Channels can even be passed around to other goroutines!

Each have their own pros and cons. You can see some of the legends who invented different methods of concurrency here: https://www.youtube.com/watch?v=37wFVVVZlVU

There's also a nice talk Rob Pike gave that illustrated some very useful concurrency patterns that can be built using the CSP model: https://www.youtube.com/watch?v=f6kdp27TYZs

They're not using the dangerous way because of syntax, they're using it because they think they're "optimizing" their code. They should write correct code first, measure, and then optimize if necessary.

The first Go proverb Rob Pike listed in his talk "Go Proverbs" was, "Don't communicate by sharing memory, share memory by communicating."

Go was designed from the beginning to use Tony Hoare's idea of communicating sequential processes for designing concurrent programs.

However, like any professional tool, Go allows you to do the dangerous thing when you absolutely need to, but it's disappointing when people insist on using the dangerous way and then blame it on the language.

https://www.youtube.com/watch?v=PAAkCSZUG1c

That's not what the comment said. It said, "How about a Rust to C converter?..." The idea was that using a converter could eliminate the problem of not having a rust compiler for certain platforms.

Haha! You know, I think this is a perfect illustration between something being mathematically beautiful verses pragmatically beautiful. The beauty of one often looks ugly by the standards of the other.

Whoah! That's so cool!

What's cool about this is that computers are so fast that you could probably make a decent 2D game using only this software-rendered OpenGL 1.1 library.

The Principle of Least Privilege is one of the foundational aspects of security. Governments should be enforcing that not requiring companies to collect very sensitive information like they are currently doing. Things like "prove your age", digital ID, and Chat Control are actively malicious when it comes to safety, security, and privacy.

I know right now there are some privacy-focused distros of Android, but it might be time to just have a fork that moves off in a different direction. I think the only way to have success is create a distro that is very friendly to developers. If you get enough devs creating software for the fork, you can start to get users. I imagine the fork would only be popular with enthusiasts and devs at first.

This is cool! I like how you can toggle the pixel effect. A lot of great attention to detail.

Is there any fundamental reason for TLD price increases? I can't imagine it would take much infrastructure to just keep a registry of domain name entries.

I don't understand why the whole thing isn't local. A comprehensive Chinese dictionary has less than 400k words. Even at 1k per word that's less than 400MB.

It's just poor design to make something require a network connection when it could work offline locally.

This was also the point of COBOL. I think one thing we've learned is non-specialists don't like thinking/problem solving, and there's no meeting them halfway on that. Asking some people to think is asking too much.

Looking through the code a bit. This is quite impressive for such a short time working on it.

This looks very interesting. I'm hoping there will be more documentation. For example, docs for the standard library/packages and explanation about the design of the language (does it use garbage collection? how does the type system work? how does the foreign function interface work? etc.).

Technically I could find all these things out by reading all the source code, but that's a lot of work just to see if the language meets my needs.

The whole point of canvas is to get away from the awful kludge that is HTML and CSS. I'd much rather see a new simple UI library that's developed for canvas.

I'm old enough to remember when people had to invent and write about the time cube, un-assisted.

I've had a couple incidents now where I'll lock my computer and when I come back to it (after lunch or a meeting) all my programs are closed. Is Windows really restarting with auto-updates when I lock my computer?

I haven't seen enough history to know if that's normal or not, but I can tell you that the center of each of those blue "clouds" is a nexrad radar station. It's view is a wide cone from the ground upwards (technically a set of cones from each of the radar's tilt angles).

It's quite possible there is some lower altitude fog/precipitation/something that is only visible to the radar at it's lower tilt angles. But that's just speculation.

It's interesting how more "amateur approachable" both old cars and old computers are. Old cars can be worked on by anyone with some basic tools and know-how, and old computers could be understood and programmed the same way. MacPaint was made by one employee.

I think this is partially why people want these types of objects. You can actually own them. You can understand them. You can mod them.

Modern cars, games, computers, etc. aren't owned anymore. They always have updates, and could be bricked at any moment if the manufacturer wishes, gets bought or goes out of business.

There's nothing preventing this from being the golden age of computers. The capabilities of the hardware are near magical. We just need to bring back the concept of ownership.

The Z80 is a legend, and even though it's not powerful by today's standards one of the things I think makes it great is it was a "standard". There's something very powerful about a platform that doesn't change.

I'm really hoping raspberry pis can fill the roll of a "standard computer". Currently, they have pretty rapidly changing CPUs, etc. I would like to see a pi that settles down as "The Pi" that doesn't change for decades. This would allow all kinds of software (and OSs) to be written for it that stands the test of time. Download a binary and it just works. No need for updates/changes etc.

I recently started using Janet and enjoy it too. I think Rich Hickey got it right when he created a single set of functions to operate on all collections, which fixes most of what's mentioned in the article. Janet does a great job of copying what Clojure got correct.

I've found the documentation for Janet to be fairly adequate. What are some parts where the documentation could be better?

Was it joining on some columns or just concatenating the files?

I'm going to laugh pretty hard if it could just be done with: cat file1.csv file2.csv > combined.csv

Michaelmas Term was the only phrase I didn't know. Apparently it's still used in the UK (and I'm not from there).

Proper nouns are trivia though. The more important part of the document is that students couldn't tell the difference between what was literal and what was metaphor. For students that were in their 3rd year of university as English majors, that's quite a problem. By that point they should have read hundreds of passages from books written in the 19th and 20th centuries.

This is how I feel about Janet too, absolutely practical. So far it's been a breeze to write the little experiments I've done so far.