No, it can't be done with testing even for practical everyday programs, precisely because you never know how much your program is crossing into the "abstract general case" and which parts of it are more general than you think. Very often the cause of bugs is precisely this - that some part of a program behaves in a more general / less restricted way than the programmer thought.

It can be done with formal verification, but that's a whole another story.

Yes, it can, that's what the whole formally verified software branch is about. Of course, even with formally verified software, there can be failures caused by external factors such as faults in hardware etc. But some piece of software itself absolutely can be proved to be correct (ie. bug-free). It just takes special approaches such as programming languages amenable to formal proofs (eg. Idris).

Software is usually written in bug-inducing ways and using languages that hinder formal verification not because provably bug-free software is impossible but because it is typically too costly and difficult to write.

Of course this still leaves space for bugs outside the program itself which still may influence it, such as bugs in the operating system or firmware or the like. Which may be prevented by having a formally verified OS too :)

But even in such a case, there might still be hardware errors (electrical noise, for example). Which is why for example spacecrafts or critical industry machinery double or triple their whole architectures. In such case the formally verified software runs on eg. three instances simulatenously and these instances cross-check each other's results all the time. When a hardware fault occurs (a bit randomly flipped in memory for example), they find out they're not matching and re-calculate.

That's as close as you can get to zero bugs.

If an Electron "application" is decent, people typically like the features or the online service to which it's tied but its Electron base is something that people more or less tolerate, depending on the degree it irks them. It's just a huge tradeoff, that's all. It reminds me of some Java or Python desktop applications, it's a similar kind of tradeoff.

Hopefully it'll pass just like the previous fads.

Disclaimer: Not an Electron fanboy, I don't even develop Electron apps. I do enjoy using a Linux dev laptop, however, and am not a hardcore vim/emacs guy.

Which is why electron is so popular. I'm sure the whole "it's way easier to whip something together that kinda works" is correct in the short term. You whip something up and rely mostly on the hype and viral marketing to drive your app.

What surprised me reading that wiki page is that apparently the metric system was opposed in the US based on religious reasons. That is mind-boggling.

Metric is already used universally in science and engineering, which seem to be the main fields in which consistency across countries matters. I completely agree that in physics, chemistry, engineering, medicine, etc., it is important to use standard units. But what harm is it doing in practice if in everyday life, Americans say things like "I weigh 180 lbs" instead of 81 kg?

The argument that the metric system makes unit conversions easier (e.g., the fact that it's immediately obvious how many meters are in 20 km, but not how many feet are in 12 miles) is true, but not very compelling to me. I virtually never find myself wanting to do these conversions in a non-scientific or non-engineering context, and on the very rare occasions where I need to, I can always look them up on Google.

A good comparison is degrees Celsius, which are just as arbitrary/unscientific (the standard metric unit is the Kelvin). Somehow people around the world get along fine using Celsius.

Think about it not for the benefit of the current generation who would be forced to burden the switch, but for the next generation who could reap the benefits.

I think one issue is that by growing up with US units and then using a second system for science and engineering, it can make American students studying those topics feel like they are in an unfamiliar territory and interfere with their intuition. Most will eventually overcome this through practice and become fluent in both systems, but it's still a barrier. Science becomes a Special Discipline requiring Special Language different than what your family uses at home. Like if all science were still done in French or Latin, and you needed to study those to read a paper.

Until you have met people who grew up abroad measuring their height in cm and their weight in kg, preparing food from recipes listing ingredients in grams and mL, to whom those units are completely natural for daily life and are also the same ones they use at work when designing machines and filling test tubes, it's easy to feel that US units simply "are" the units suitable for daily life, as though that were a universal truth and not just a local cultural oddity.

Not to mention the massive net costs of having suppliers worldwide making extra sets of almost identically sized components that nonetheless aren't interoperable. Screws with 3 mm and 3.175 mm diameter, etc.

You realize this is still a problem for most of the world and needing to learn English, right? :P I'm hoping we can solve this in my lifetime with everyone knowing one standard language through education as a child, but as it stands the struggle is real for many of my fellow non native English speakers.

That said I agree with you, all these differences are a pain and I'm confronted with them way too often in my daily life.

It seems like this is rapidly becoming the case in the Western world, and that that language is English.

You don't realize how arbitrary Fahrenheit and Celsius are until you try cooking at altitude. When I make breakfast in a particular town I frequent, it takes almost an extra minute to boil an egg.

It seems safe to say it's a point of ongoing friction, especially on things like international trade.

[0]: https://space.stackexchange.com/questions/12391/iss-nuts-and... [1]: https://mars.jpl.nasa.gov/msp98/news/mco991110.html [2]: https://www.chihaklaw.com/Articles/Confusion-over-metric-mea...

I still stand by my argument that it does not matter much for everyday life.

As for "why" to have them, well there isn't a good reason intrinsically -- if there were a way to magically convert the US to metric overnight, it wouldn't bother me. It just seems very unlikely and difficult in a country as huge and culturally diverse in the US. Especially since, by the standards of the rich/developed world, the US is pretty poorly educated, and also very difficult to govern (Obamacare, a law that would have seemed like a moderate reform, relatively simple to pass in any parliamentary system, is the most radical change in any area of policy enacted by the US federal congress in the last decade).

The thing a lot of people miss about the ultra-gridlocked US system is that there's a huge gulf between it being obvious to most people that "we should enact some policy" and anything actually changing. The best answer to "why doesn't the US do this or that" is often just "its political institutions can't".

Since it's so unlikely to change, and given my argument that it isn't a big deal in practice, I guess my main point is that we rationally-minded people should stop worrying/complaining about it so much.

Celsius is literally the same scale as Kelvin, just shifted so that 0c = water freezing.

Fahrenheit is scaled such that 0 is about the coldest it gets where I live, and 100 is about the hottest. (Very approximately, but close enough). That strikes me as a lot nicer in practice (since 99% of the time people are talking about temperature, it’s related to weather) than something based on the physical properties of a particular substance.

Also water freezing at 0 and boiling at 100 is only valid for a specific, non-metric, air pressure.

So you end up needing negatives, and decimals.

So, for liquids,

2 tablespoon = 1 ounce 2 ounce = 1 jack 2 jack = 1 gill 2 gills = 1 cup 2 cup = 1 pint 2 pint = 1 quart 2 quart = 1 pottle ( ½ gallon) 2 pottle = 1 gallon

I find it much easier to switch units and do conversions in my head, especially when scaling recipes.

With respect to base-2 fractional length measurements, I just find it much easier to work with fractions than than with decimals. Half of ⅛ is ¹/₁₆ with next to no thought. I don't need to do division of 25 to get 12.5. It's a personal thing, but I find it nice.

The fractional system isn't perfect for all use cases by any means. (My understanding is that a lot of machining just deals with decimal inches directly.) I just find it convenient for many everyday tasks. I'm also weird, I guess, in that arithmetic on fractions feels easier than on decimals.

Thinking more about my original statement, a lot of it has to do with halving (e.g. finding a center) being a common operation for many tasks. It also helps that most things are sold in those fractional increments too :)

As you will discover people often use religion as an excuse for things they anyway want to do. Usually they are people who only pay lip service to their religion.

Someone didn't want to use Metric. Religion doesn't actually have anything to do with it.

> That is mind-boggling.

It shouldn't be. I assume you are surprised that religion is involved in this, but actually it is not. If they were Atheist they would have the same objection, just using different words.

Basically you need to distinguish between people being people, and people acting in a certain way because of religion. This is an example of the former.

JS has its overhead in terms of data and, more severly, performance. Many people tend to put unecessary JS stuff like custom scrolling, needless animations and needless interactivity, etc. This stuff more often than not just ends up getting in the way of normal browser function and is of questionable benefit or none at all.

> I am building a website that relies heavily on JS. What should I be aware to steer away from the JS hate?

Don't add any JS interactivity that only makes a website "look cooler"* and that's not actually critical to your website's functioning. For example, stuff like google maps needs javascript. Stuff like blog most likely doesn't.

Remember to try out how your website works on a device with weak hardware and slow connection. This will not only make it far more accessible for people with older hardware, it will make better for recent hardware as well.

*) today's expression would probably be "rich user experince" or somesuch, but the meaning is the same - it's just vanity

I am building a web based chat bot, so it is essential as without animation, it kind of look bland and uninteresting. Although, I will try to check in weak hardware and slow connection. Although not IE previous versions though.

Have a look at either the `trash-cli` package by Andrea Francia.

Yes, I agree, but that's not the full picture. People want a language in which they can be productive quickly, but once they master it, they, or at least some of them, will then look into quality and performance. Languages like JavaScript or Python (and even Go to some extent) are popular and easy to pick up, but there's not much room for further progress. JavaScript is already stretched to its absolute limits when it comes to performance and it's still not performing very well. And when it comes to quality, well, TypeScript is a thing for a reason.

I don't believe Rust will ever be as much of a language for the masses as JS, but it has a good chance to become a niche language for those who need or want more performance and/or quality than they can get with langs like JS or Python.

Well there's stuff like error-chain to take care of the boilerplate...

Also, I believe you could define the equivalent of Go error in Rust as a trait and box it (ie. a trait object). It could be used much the same way as in Go with the additional benefit of Result being a sum type. I'm personally not a big fan of this approach but I guess it might work...

I know this basically how Go's error handling works (Put error data on heap and pass the reference), but I'm not fan of it (the put data on heap part of it) too :(

I will try out the error-chain, thank you for reminding me that.

True, but the same is true of Go, which may be surprising to people. Despite its claims, Go didn't solve this problem.

One reason is that larger projects typically start to invent their own abstractions on top of the base language and Go is no exception here, in fact, what with its lack of some common abstractions, built-in support for code generation, frequent use of external add-ons (like go vet etc.), Go very much encourages this. And so you're going to have to learn specifics of larger projects just like with "complex" languages. The solution to this problem is meticulous and somewhat restricted code style standard, but that's a solution that works with "complex" languages just as well, in fact, I'd argue that even better.

The other reason is that the Go language is not just the Go language. That is, what with the lack of abstractions for error handling, code re-use, etc., people end up following a bunch of conventions, styles, patterns and using external tools (like the already mentioned go vet). And so in effect the language becomes "the base" + "lore". This is of course true of any language. With Go and early Java, for example, this becomes more pronounced, since the base part is very small, larger parts need to be taken care of by the "lore". This is why Design Patterns become so popular in the Java world. And this why it's not good to have the base part too small, which is the problem of Go. Of course, the other extreme is equally bad - that is, when the base part is too large, which is the problem of C++, where now "lore" has to take care of deprecating/removing language features.

I feel like the authors of Go decided to do the opposite of what C++ does and thought that since C++ is horrendous, doing the opposite would yield a great result. But unfortunatelly that's not the way things work. You can't just negate someone's bad approach and expect great results.

With such an internet infrastracture, is the country even capable of maintaining an up-to-date connection to the bitcoin network?

Ecuador moved to the US dollar in 2000 because their handling of their own currency wasn't working (and maybe because oil is often traded in USD?). Whether Venezuela uses BTC or some other currency sounds like a good idea at this point. The corrupt actors in their monetary system probably want people to keep using their bolivar though, because that's what the corrupt people stole, are holding, and printing.