drpixie

Well ... Name a language is which you categorically cannot "shoot yourself in the foot"!

While there are a few disagreeable points, I like the article.

I've always felt that C is unfairly maligned. Yes, it's very low level, it's meant to be. Yes, it lets you shoot yourself in the foot, but what language doesn't?

Most of the problems with C are really issues with the standard library, the Unix (now Posix) interfaces, and the string type.

None of these are actually part of C, but are part of how C is normally used. So those problems can be avoided, and use C for what it's good at.

You're right about the tape. Duh.

> But BB is an uncomputable function. You've not escaped undecidability at all. You cannot write a program that will compute BB(n) given n as an input.

I think you're going down the wrong path re "uncomputable". BB(n) is easily computable, just write a little program that enumerates (generates) and runs all n-state BB machines. BB(n) is the largest lifetime of any those n-state machines. BB(n) is known and easily computable for small n.

The problem is that the number of machines increases very quickly with n, and the time taken to evaluate each machine often increases quickly with n. So for even moderate n, it is completely impractical to brute-force compute BB(n). But impractical is not uncomputable.

Just because you don't wait to wait past the heat-death of the universe, doesn't mean that you wouldn't have got an answer eventually. And eventually = computable.

Personally, I enjoy these various "programmers fallacies" articles. I find those weird and obscure factoids about postcodes, names, addresses, numbers, and so on, to be fascinating. They remind me what a rich and diverse world we inhabit.

Now if "programmers" (analysts, designers, managers, etc) were more considerate, less rushed, more thoughtful, more experienced, considered their assumptions, and leapt to fewer conclusions, then our systems would run rather more smoothly.

See https://www.wired.com/story/google-antitrust-lawsuit-search-...

> Unicode the complete, total and utter clusterfuck that it is.

I'm inclined to agree - they took a big problem and made it into a big & complex problem.

I propose a fix - immediately depreciate all multi-codepoint graphemes and provide single codepoint alternatives. That we should need to normalise something a basic as our text leaves soooo much room for problems. And the idea that some graphemes encode magically colour (emojis) ... :rolling_eyes_emoji:

An Australian here.

"A couple" is exactly 2, excepting very specific downward exaggeration ("I'll only have a couple of beers.")

"Several" is always more than 2 but always a small number - say 3, 4, or 5.

"A few" is always more than 2 and probably more than several.

"Many" would normally exceed several, probably by quite a bit.

And of course "one" is always 1, excepting downwards exaggeration similar to a couple.

Three sitting around. They make very convenient small servers. One (a RPi4) has substantial mass storage and is a backup and media server. Another (an RPi3) is an RSS reader service and web proxy for some internal stuff. And the third (RPi3) servers for occasional experiments and what-ifs.

I'm inclined to agree. Articles that are uncomplimentary of the industry ethos are few, and comments the criticize that ethos often see antagonistic replies or downvotes.

There are plenty of people here who have their eyes open and maintain a broad view of tech and the world. But these people seem overwhelmed by those that have completely swallowed the industry koolaid.

It's sad. I remember the fundamental optimism of the early days of IT . That's largely been replaced by smallest-feasible-product and monification.

For me, the biggest problem is lack of meaningful feedback. Even a small keyboard lets you feel the edge & centre of each key, and feel when it's acted (the click).

And a physical keyboard does not require you to be looking at it, just to use it.

I accept your point that good mobile data is not universal.

But for those who have a personal mobile device and poor mobile data, an actual email client would likely be a good choice.

An actual email client uses much less data than webmail. For example the gmail webpage loads around 10MB just to show the web page, before any actual email content.

Also an email client functions with an intermittent network, only actual sending/receiving requires a data connection. Existing emails are accessed using the local mailbox, and outgoing emails are queued until the network becomes available. A webmail system provides no functionality in the absence of network data.

Web mail was great before mobile data became normal - when you used a work computer, and a home computer, and ...remember... internet cafes!

But now mobile data is normal. Your phone/tablet's email is a almost certainly a dedicated app - an actual email client.

Time to drop webmail, and gmail.

You sure about that. I was reading only yesterday (can't find the link - sorry) about how little each extra feature is used - that the vast majority of value & use is in the core.

I see the other way around. Additional features are people's special cases and hobby-horses, and unlikely to be used by other people. BUT each new feature/interface/etc adds the potential for (and really of) more bugs.

Perhaps it should be "features are where the security holes are"? :)

> Scrum is a cancer that will eat your development team. Scrum is not for developers; it's another tool for managers to feel they are in control.

Agile and Scrum are for managers who don't know what they want, but they'll "know it when they see it". (Or more likely, they'll declare that they wanted is what they've got when the money runs out.)

Just stay away from it, if at all possible.

> I personally have been against developing mobile apps for years now for the exact same reasons described in here and other similar articles — as soon as you decide to develop mobile apps then you give control of your product/service away to a third party

Hard to disagree with that.

When "support" is hoping that HN or Twitter attracts helpful attention, we're going down the wrong path.

Didn't mean to come across judgy :(

Apparently the ancient Greeks didn't have much, if anything, in the way of symbolic algebra or calculus - what we mostly think of as "maths".

Instead their normal tool for mathematical logic was geometry. An educated Greek would have used geometry much like we use algebra.

For most of us, given a non-maths problem (eg physics, chemistry, almost anything in real life...) the first thing we do is express it as an algebra problem, and solve that. The ancient Greeks used geometry in a similar way.

Unless the sun was VERY close, the actual distance doesn't matter. What matters is that the sun (or a star, or whatever you use as a reference) is so far away that there is no practical difference between "far away" and "even further".

For practical purposes, we treat the sun as being an infinite distance away, and the error caused by it being ONLY 93,000,000 miles away is much smaller than Eratosthenes could measure :)

It's similar to drawing perspectives, you draw perspective lines to join at the distant horizon. You don't care how far to the distance horizon.

(Those ancient Greeks had amazing understanding of geometry. Much better than most of us.)

Sure, share the documents, but running apps over the net - ha!

I despise every time I open an MS Doc or gmail. Just now gmail loaded almost 13MB of "app" - just to show an almost empty inbox, what a waste! And (behind the scenes) it's still loading stuff after almost 30 secs.

Cloud apps are the IT version of supersizing. Morgan Spurlock showed what happens when you use capacity just because it's available - obesity.

Daily. It has its faults but its WAY more usable than the MS trash. And it lives on my computer - no "cloud" garbage if I can avoid it.

I find it intriguing that memory is not just A bottleneck these days, but that memory is SO much slower than CPU. A big part of the performance difference must be the move off the main chip, but it just seems that when cache can be so quick, memory should be faster than it is.

You're right there. As transistors got cheaper, we've got into the habit of using them en-mass to prop up horrible architectures with weird (but effective) tricks like enormous look-ahead, stupendous pipelines, and gigantic caches.

I recall with considerable fondness those ISAs that could be understood in ultimate detail by a simple human - the monolithic supercomputers like the Cray 1.

Remember the Cray-1. It had no division instruction but could perform reciprocals. Division was performed as 1 reciprocal and 2 or 3 multiplications (depending on the precision needed). Thus division was only a little more complex than multiplication. (A reciprocal instruction took about twice the time of a multiply.)

See https://www.ed-thelen.org/comp-hist/CRAY-1-HardRefMan/CRAY-1...

So really, it's tradition that division (which is needed relatively rarely) is not performed quickly in hardware. The old time versus silicon tradeoff strikes again - you can have it quick but it will be expensive, how much do you want it?

Re the original question - (almost) anything can be done in enough silicon. Both multiplication and division could be done as very fast "ROM" lookups, but that would use an enormous amount of silicon.

Very impressive - but it would be terrible if they have to move house!

I find that it is often difficult/immpossible to get a sense of scale.

The width and detail of streets is adjusted such that it is not obvious if I'm looking at things a few hundred metres apart, or a few kilometers! And there is no scale indication on the screen! I guess they want a "clean" look but it's not so helpful.

Take a look at Garmin aviation maps. You're offered only a specific set of scales (not an infinitely adjustable range), there is always an indication of scale, and the detail appropriately hints at the scale.

> Google or any other Browser vendor do not have a say on how websites use or misuse features.

Seriously? Would you give the kiddies sharp knives and loaded guns, and then be shocked when someone is injured?

If we let this become available, we will all have to live with the consequences. We can see clearly what those consequences will be. Let's not be stupid.

This is DRM for browsers. Would you buy a computer from John Deer ... ?

Ah yes. This is one of the marvels of having browser APIs that want to give you (almost) complete control over the machine, and let you do (almost) anything...

Upside: You can do almost anything.

Downside: You have to manage (almost) everything yourself.

Downside: It lets other people do real dumb/annoying/inconvenient/stupid things, and you get to deal with the result.

This would be, de facto, DRM for whole browsers. It would have all the advantages (to incumbents) of DRM. And for users, all the disadvantages of DRM.

If you think the John Deer tractor maintenance thing is terrible and disgusting ...

Same, in firefox (current version) but not in chrome.

But the manifesto is good enough to deserve 2 downloads :)