jadero @ jadero @programming.dev

Fully retired now and one of the things I'd like to do is get back into hob

---

Read more

Posts

1

Comments

146

Joined

2 yr. ago

I'm not sure, but I think they were making a joke. Germany created the Enigma machine. Turing et al did some seminal work as a result of the need to quickly decrypt Enigma messages. Ergo, we wouldn't have computers without the Germans.

Reviews have to be balanced to circumstance. There is a big difference between putting out the sales brochure and the notice on the bulletin board. Likewise in coding a cryptographic framework for general consumption and that little script to create personal slideshows based on how you've tagged your photos.

As a general rule, wider distributions, public distributions, and long-lived distributions need more ambitious reviews. If the distribution is wide, public, and permanent, then everything needs very detailed scrutiny.

I have found some success in starting with and occasionally revisiting review goals. This helps create and maintain some consistency in a process that is scaled to the task at hand.

I'm going to offer something a bit different. I'll start by saying that I've never actually used it beyond a bit of tinkering and watching the presentation at the Strange Loop conference.a

https://www.hedycode.com/

The basic idea is that it's actually pretty hard to do things wrong at the start, mostly because you just can't do much. What you don't get right has very clear descriptions of what you've done wrong, where, and even suggestions for corrections.

As you progress, you can do more and you have a very gradual transition to the more restrictive environment that most programming languages have.

By the time you are done, you are basically programming in Python, so further learning can take place using the myriad of courses, tutorials, and documentation available for that language.

I have no real experience with it beyond some basic tinkering. It is designed for classroom use, or at least on the assumption that there is a teacher or instructor available. That may not translate well to someone learning on their own.

That only makes sense. We are having a conversation, not creating literature.

I would argue that "should of" is just a naive written rendition of the spoken contraction "should've". They are homophones, so it's a completely understandable error among those without the relevant education or background. I know only English and was in Grade 9 at a different school before someone corrected me.

In that spirit, I will call attention to your first sentence, specifically the comma. In my opinion, that can be improved. One of three other constructions would be more appropriate:

• I am really happy when people are quite strict in code reviews. It makes me feel safer and I get to learn more.
• I am really happy when people are quite strict in code reviews, because it makes me feel safer and I get to learn more.
• I am really happy when people are quite strict in code reviews; it makes me feel safer and I get to learn more.

The first of my suggested changes is favoured by those who follow the school of thought that argues that written sentences should be kept short and uncomplicated to make processing easier for those less fluent. To me, it sounds choppy or that you've omitted someone asking "Why?" after the first sentence.

Personally, I prefer the middle one, because it is the full expression of a complete state of mind. You have a feeling and a reason for that feeling. There is a sense in which they are inseparable, so not splitting them up seems like a good idea. The "because" explicitly links the feeling and reason.

The semicolon construction was favoured by my grade school teachers in the 1960s, but, as with the first suggestion, it just feels choppy. I tend to overuse semicolons, so I try to go back and either replace them with periods or restructure the sentences to eliminate them. In this particular case, I think the semicolon is preferable to both comma and period, but still inferior to the "because" construction.

I've clearly spent too much time hashing stuff out in writers' groups. :)

I have read more than is probably healthy about the Chinese room and variants since it was first published. I've gone back and forth on several ideas:

• There is no understanding
• The person in the room doesn't understand, but the system does
• We are all just Chinese rooms without knowing it (where either of the first 2 points might apply)

Since the advent of ChatGPT, or, more properly, my awareness of it, the confusion has only increased. My current thinking, which is by no means robust, is that humans may be little more than "meatGPT" systems. Admittedly, that is probably a cynical reaction to my sense that a lot of people seem to be running on automatic a lot of the time combined with an awareness that nearly everything new is built on top of or a variation on what came before.

I don't use ChatGPT for anything (yet) for the same reasons I don't depend too heavily on advice from others:

• I suspect that most people know a whole lot less than they think they do
• I very likely know little enough myself
• I definitely don't know enough to reliably distinguish between someone truly knowledgeable and a bullshitter.

I've not yet seen anything to suggest that ChatGPT is reliably any better than a bullshitter. Which is not nothing, I guess, but is at least a little dangerous.

Thanks for the tips! Especially the one about "human-scale" files.

But yeah, personally, it does excite me to see that the Unison authors thought differently. Even if it's just sheer curiosity what they do with it and whether that added consistency is nice to work with.

This is what attracted me. Before I sold out to VB and Access in the early 1990s, I was just a labourer and hobby programmer of the "language junkie" type. The same three programs written in every language I could find (Metaphone, Pong, and Rolodex).

Now I'm retired (but 10 years away from programming) and want to try to reboot that hobby. I thought I was just making a tiny little complaint about my aged brain, not opening up a whole thread!

Okay, now I want to write my own editor.

Thanks for the inspiration.

For me, Unison is basically inscrutable. I know that part of it is that functional programming is 100% completely brand new to me, so there is just too much to take in all at once.

One of my retirement projects is to learn functional programming. I'm hoping that will be enough to get me far enough along to be able to figure out the other parts.

Good article that I think does a pretty good job of outlining the problems of "Computer time is less expensive than programmer time."

I was "raised" on the idea that end-user time is more valuable than programmer time and nobody really talked about computer time except in the case of unattended-by-design systems like batch processing. Even those were developed to save end-user time by, for example, preparing standard reports overnight so that they would be ready for use in the morning.

I think that one place we went off the rails was the discovery that one way to manage efficiency was by creating different classes of end-user: internal and external. Why would management care about efficiency when the cost of inefficiency is paid by someone else?

So much software is created explicitly for the purpose of getting someone else to do the work. That means the quicker you get something out there, the quicker you start benefiting, almost without regard to how bad the system is. And why bother improving it if it's not chasing customers away?

I found that starting with a "critical path" analysis was very useful. Basically, identify which components or activities need to be at least somewhat functional in order to deal with a different component or activity.

This gives you a list of problems you have to solve in the order they need to be solved. That is, there is no point spending time on writing to disk until you've figured out what you're writing to disk and how your going to collect whatever needs to be written.

Virtually every critical path will have some easy stuff on it that needs to be in place before the hard stuff. That gets you (or at least me!) in the right frame of mind and builds momentum towards the goal. I've often found that doing the work leading up to the hard part made the hard part easier, at least partly because there is now a concrete problem ready to solve instead of a nebulous wondering how to approach it.

Note that if you try this approach, make sure that you avoid the common practice of building "placeholder" stubs for anything other than components further along the critical path than your current position. Even with that, I found little value in stubbing something in before I was actually getting close to the point of needing it in order to continue working.

Note that this process doesn't mean it's not appropriate to go ahead and identify where the dragons are and check to see if you have what it takes to slay them. Back to my example of writing to disk, if you've never written anything to disk before and it looks scary, it might be a good idea to create a completely unrelated toy project to learn and practice that specific skill. After all, if it turns out to be impossible to write to disk, there is no point starting a project that requires it. I find that these toy projects are simple in the sense that there is only one thing to worry about, so you're already doing the easiest thing available.

The left side (linear) looks like the code I write while I'm trying to figure out whether I understand the problem or I'm not quite sure what all I need to do prove that I can (or cannot!) solve the problem.

The code on the right, with all the "abstractions" looks like the code I end up with after I've got everything sorted out and want to make things easier to read, find, and maintain.

I actually find the code on the right easier to read. I treat it like a well written technical manual. For me, understanding starts with time spent on the table of contents just to get a sense of the domain. That is followed by reading the opening and closing sections of each chapter, and finally digging into the details. I stop at any level that meets my needs, including just picking and choosing based on the table of contents if there is no clear need to understand the entire domain in order to accomplish my goal.

I've preferred code written in that "abstracted" style since discovering the joy of GOSUB and JSR on my VIC-20.

Ok, thanks! That looks like a good start for me.

We're getting closer to winter. I've got most of those preparations done. "Just" have to finish building the heater for my shop. My programming based project list is coming together: learn me some Rust, contribute some documentation to a project I'm following, look deeper into the potential of the Accessibility tree. That should keep me busy for a while!

Looks kind of simple to me at first glance...

Well, it has been a decade since I've done anything other than dig holes (literally), drive school buses, and work in my shop. :)

Thanks for the jump start. I'll add this to my ever growing list of tech stuff I'd like to tackle in my retirement.

Nice! That Vlab software looks very interesting. Way back when, I built some primitive tools to help me play with L-systems, but I'd never have dreamed of taking it that far.

Have fun!

Thanks. This is the first I've heard of the Accessibility tree. A quick look kind of spooked me, but I'll dig deeper.

Track down a copy of "The Algorithmic Beauty of Plants". The last time I looked, it was available as a free PDF, too. I think it's a great introduction to L-systems.

I got it when it was first released and spent way too much time poring over it and generating imagery on my decrepit old computers.

I've never looked at plants the same since.

Old fart warning!

Presentation is left to the reader's client. Do you want dark mode? Get a markdown editor/reader that supports it. Do you want serif font? Again, that's client's choice and not part of the document.

I remember when that is how the web worked. All that markup was to define the structure of the document and the client rendered it as set by the user.

Some clients were better than others. My favourite was the default browser in OS/2 Warp, which allowed me to easily set the display characteristics of every tag. The end result was that every site looked (approximately) the same, which made browsing so much nicer, in my opinion.

Then someone decided that website creation should be part of the desktop publishing class (at least at the school I taught at). The world (wide web) has never recovered.