flogic

The fundamental problem this argument has is that computers are in the world. Probably not to the degree required and certainly not up to AGI. But, self driving cars and Boston dynamics exist. The gap between "in the world" and not isn't some insurmountable barrier. It's an engineering problem that's been solved to varying degrees by engineers and hobbyists.

People deciding to stop working is a good thing. It means they have market power and potential employers need to take that into account.

I've written maps that I've regretted later. "map(+1, list)" isn't too bad. But as you chain things and/or put more in the lambda, it gets less comprehensible. Then, some cross cutting requirement comes in and you either need two map reduces or to just refactor to a loop.

Scripts are a subset of program focusing. The primary characteristic being they rely on another program to interpret the source at run time. Scripts also tend to be a problematic subset since libraries written in scripting languages tend to have poorly defined interfaces.

There are still 2 basic sources of benefit. First, power stations generally use turbines which are much more efficient than internal combustion engines. Even after accounting for inefficiencies electric often comes out better. The other benefit is that it decouples the vehicle from the energy source.

My keyboard is set up in a similar manner but it adds a point of complexity. Ctrl-Shift-Arrow is harder to use since the Fn key is trying to take up a thumb.

I'll give it points for the arrow keys. There just really isn't much in the way of good positions for arrow keys on a split layout. That said I don't like what it's doing with the thumbs. Thumbs want to move radially more than in and out.

Touch typing is one of those things it's easy to underestimate the importance of. I've been using computers heavily since the late 80's. But, I've only learned to touch type in the past couple of years. I'm going to be kicking myself over that for years to come. Programming isn't particularly better with touch typing. However, it's done wonders for my ability to communicate with others. It's really a must have skill.

Would say the best reason to try something weird is if the normal approach just isn't working. I never managed to touch type on a normal keyboard. Now that I'm using a split layout, I've learned to touch type. That makes it worth the weirdness for me.

Manufactured or pre-made split keyboards aren't cheap. However if you're making your own the costs aren't all that different. So it's easier to ignore the cost and effort if you're making a split keyboard. Also by definition, you're talking about someone willing to go down the less beaten paths.

I would love for split keyboard to become more mainstream. They're far superior to the traditional key layout. But if the sample set is customs, it's probably selection bias.

You can make a mechanical keyboards significantly quieter. Most of the noise isn't actually from the switches themselves but rather from the impact of the keys bottoming out into hard plastic. So a set or 2 of o-rings on the keys will really cut down on the noise.

When I get around to constructing my next custom. I'm going to use non-clicky switches with a thick acrylic plate and of course a set of o-rings. In theory, it should be very office acceptable.

Sadly, I use an Android and can't say if this is what I would want but it seems on a better path. Most things I've seen for Android are replicating a traditional graphing calculator. Which suffers from 2 major problems. One, graphing calculators already have confusing UIs. Two, the tiny buttons that work tolerably physically are much less tolerable on a touch screen.

This kinda captures one of my concerns. While I could care less about the particulars of how people interact with computers, I do find it concerning that modern devices seem to make general purpose computing less accessible. I love my phone but I haven't even found a decent calculator for it much less a tolerable equivalent of Excel, the shell, or programming environment. Part of me suspects it's an inherent limitation in touch IUs but that also seems like a cop out.

Personal experience tells me that size is probably a proxy for "this code is mathematically written". If you have even a vague idea of the math of the code you're writing, the code tends to be both shorter and have fewer bugs. But, I'd be wary of turning that around to a blanket endorsement of terseness. Terse code often needs to be restructured when requirements change. Restructuring takes more time and also risks adding new bugs. Then there are problems with readability during debugging and understanding interfaces.

It's been a while since I've used it but yum used to tie up my machine pretty badly on significant upgrades. After reboot it could take hours to finish applying the upgrade, during which time the machine was usable. Apt has never given me that sort of trouble.

That's not really what tends to happen with deer. The situation starts with them on one side of the road deciding to cross. Then the partway through they freeze. There's often not time to react. Deer are very poorly adapted to dealing with roads. They're camouflaged which makes them hard to see. And while freeze is a perfectly good strategy against wolves, it absolutely sucks against a Buick.

The thing is that it doesn't really matter. There are only 2 options here. Either, the car should have seen the woman and taken corrective action or it was driving faster than it can see. Just because the speed limit says X doesn't mean that's the speed you should be going. Often, actual conditions require driving slower.

Personally, I don't find it all that bad. The digitizer on our tablet our tablet crapped out a few months back. I found a YouTube video on how to replace it. The tools cost like $7 off of Amazon and the digitizer was about $20. A few minutes of fooling around and viola working touchscreen again. Overtime basic electronics tools are very cheap.

I think they're planning for 100% automated. So hopefully, poor behavior should not be an issue.

I'm not sure Apollo is the best benchmark. The primary goal was to send the astronauts there and bring them back. Just changing the primary goal should result in a huge reduction in the cost per gram. You'd just send a tiny excavation rover and have it fill bins for the return trip. Followup trips might even skip the rover and just use the one already there. There is a huge amount of room for efficiency and cost savings especially if you leave the humans home.

Though, Moon rocks are a bit of an outlier. They don't have much value outside of science and as a curiosity. You might want to focus on something with more predictable demand. In which case, it may get more complicated than "shovel stuff into a bin".

That's some wells. When I was growing up, my parents' well was pretty much untreated. The water was a acidic so that first morning drink of water tasted of copper. I suspect most of the safety came from arranging the conditions so the water would be safe by default. There is a minimum depth for the well and it needs to be a certain distance from the septic system.

I think the general problem with any automated solution is that there is so much room to game them. For instance, I could selectively replace a few visible ASCII characters with non-ASCII look a likes. Then, the investigators just need to see which characters are missing. Even with the OCR option you could selectively add typos.

I once did a thought experiment on what it would take to replace the paper scoring sheets for horse competition. It was fairly daunting. It needs to be simple enough for a lay person to use well. Recording, corrections, and commenting all needed to seamless. Since there are multiple riders on course, the user needs to be able to react quickly and potentially out of order. Paper is really hard to beat in that case. Corrections are just using the pencil eraser or crossing out. Field selection is just where you have the pen at that moment. Communication sucks in that the sheets are picked up by a runner. But even on that count going digital adds it's own complications. I assume that someone will do it eventually but for such a seemingly simple case the constraints are deceptively tight.

At what point do you call someone a programmer? They seem to be using "knowing how to code in a traditional programming language". However, I would not use that definition. Most of what we do though is thinking about a problem and how that relates to what computers do. My take would be that everyone actually using this tool either is a programmer or by the nature of what they're doing soon will be.

Cigarettes are literally dried up leaves. Their customers light the product on fire and then buy more the next day. Given that as a viable business model, how do you not make ridiculous quantities of money?

It's a bit of an unfair comparison though. The problem and tool set were predefined before Knuth started. Also it's a problem that's particularly suited to Unix tools. There are many problems where Web might have resulted in the better solution. As a kid, I saw a program that computed the position of Moon in the sky given a location and time. That would probably be better solved with WEB than Unix pipes.

Static types and tests check different things. Tests are for making things function as desired. Types are for making sure they actually connect sensibly where desired. Sometimes you can use them for the other purposes though that often produces ugly tests/types.

Capitalism is more about a few controlling the means of production than it is about market activity. People tend to think of it as a market economy but it's really about who has power and reaps it's rewards.

Kite power is one of my pet hopes. I keep hoping it will gain some significant traction. Looks like there may be a a test power installation going up in Scotland https://www.independent.co.uk/environment/kite-power-station...

Should this issue be addressed at a technical level or a policy level? No matter how they manage the distro, so stuff is going to come down to policy and process. To me it seems like the sort of thing that should be handled with package audits.