azov

If your python script sticks around for 30 years constantly being used by millions of people - I bet it will be rock solid as well. All other things [1] being equal [2], a program written in a higher-level language will likely be more reliable - simply because it will likely be shorter. C has many properties conductive to great longevity of software written in it, but error handling is not one of them.

Now, to the rant about not knowing the exact number of exceptions a function can throw. Most sane languages [3] give you exception hierarchy. You know that every function can throw an Exception (or Throwable, or whatever the root of all things evil is called in your language), and you either handle it or let in propagate. The important bit is you catch exceptions based on what you can handle in a current context, not on what the functions you call can throw [4]. As long as you realize that every call can potentially throw, it is not important what exactly is thrown - letting you abstract away the exact nature of an error is a feature, not a bug, that's what exceptions are there for! Let's say some function deep below changed and now throws a new exception type. So what? It didn't change what you can handle, so there's no reason to modify calling function - just let the exception propagate. What if nothing in your program can handle that exception? You let it crash (hopefully to the debugger, and no, it's not ironic that I suggest it in a topic about reliable programs - crashing is a reliability feature invented to expose problems that would be hidden and hard to debug otherwise). Of course you may also put a few catch-all clauses in a very limited number of strategic places.

If you approach exceptions this way they are vastly superior to error codes.

[1] Scope of the problem, amount of effort spent on development, programmer skills

[2] Or at least on the same order of magnitude

[3] With a notable exception of C++ - I'm not sure what they were smoking when they decided that throwing arbitrary values is a good idea

[4] And this, by the way, is what's wrong with checked exceptions in Java

PS. Didn't mean that having no exceptions is insane - but that if a language has exceptions, the sane thing to do is to organize them in a hierarchy with a single root.

If you assume that system time is a continuum I have some bad news for you: system time is actually a user preference. Users can change it any moment to whatever they feel like, no time machine required. Given that, leap seconds are small potatoes. If you propose we change this and take away user's ability to set system time... well, there might be some merit in this from purely theoretical point of view, but in real world where batteries die, clocks get out of sync, and tons of software already rely on existing behavior - I don't think your proposal is likely to get very far :-)

Now, if you want a continuum, it's already there: look up CLOCK_MONOTONIC.

FSMs are often used when modelling physical devices - think microwaves, elevators, CD-players, something with buttons or sensors, something event-driven, embedded controllers, also network protocols, text parsers, etc. Basically, whenever we must ensure correct behavior having few constraints on sequence or timing of inputs.

How can you actually apply it in your everyday programming? Look at your class. Every method call is an event that can cause a transition. Member variables are the state. Theoretically changing any bit of any member variable gives you a different state. In practice you only care about the bits that affect your control flow. Figuring out how variables map to states is the tricky part. Sometimes one variable corresponds to several states (say, when airspeed goes over V1 a plane transitions from can abort to must takeoff state), sometimes several variables define one state (say, when ignition=on and door=closed car is ready to drive), sometimes you'll need to add an extra variable to distinguish between states. Then you draw a table with events on one side and states on another and look at each cell. This is when you have all those precious "oh, crap, what if the user hits play when the song is already playing" moments. And voila - now you know that your class behaves correctly because you've systematically considered every possible scenario. It takes enough effort that you probably don't want to do it for each and every class, but when you do it - it's magic :-)

[1] Any computation with finite memory, to be pedantic

You don't literally have to start with one function. If you've solved a similar problem before you may have a good idea of what the code structure is going to be (this is what design patterns are all about). Frameworks may force a structure on you. There are shortcuts. But even then, I've been bitten more then once by the problems that looked awfully similar to what I've done before only to turn out to be very different at the end.

No, it doesn't mean that OOP is awful - it just means that this particular way of modeling a problem is a recipe for over-engineering.

Start with the simplest thing that works. That thing will probably be just a function. Grow it from there. If it gets too big, split it. If you find that you pass the same 12 parameters to a bunch of functions - factor out a class. If you do the same thing in a bunch of classes - abstract it out. Keep it DRY [3]. Keep it SOLID [4]. Rinse and repeat. This way you end up with a useful class hierarchy - and OOP won't be awful.

[1] http://en.wikipedia.org/wiki/Tower_of_Hanoi

[2] http://rosettacode.org/wiki/Towers_of_Hanoi

[3] http://en.wikipedia.org/wiki/Don't_repeat_yourself

[4] http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

PS. From Wikipedia article: In principle it [ActiveX] is not dependent on Microsoft Windows, but in practice, most ActiveX controls require either Microsoft Windows or a Windows emulator

PPS. I'm not really trying to compare them, just pointing out that obsessive idea to run Photoshop in browser is almost as old as browser and photoshop themselves. And so is the idea for a grand platform that will let us "write once, run everywhere". Uncountable attempts were made, yet somehow they all fall short of expectations. Is the idea itself flawed? Perhaps we have different operating systems for a reason?..

PS. One of my biggest gripes with C++ is the lack of uniformity. Not only the language itself has insane learning curve, every project does so many trivial and not-so-trivial things differently that it's like learning another language each time you dive into a new codebase. From code formatting, documentation, and source tree layout to error handling, libraries and build system - for something so huge and complicated as C++ there's an amazing number of batteries not included. Even the things that are supposed to be standard in theory are often not so in practice. Damn, there's still custom string classes in the APIs of many popular libraries - almost two decades after std::string and STL!

PPS. And yes, there's a difference between having consistent conventions and trying to be perfect for everybody and everything.

However the axiomatic systems we happen to use most have one important property: they are useful for acquiring new knowledge via scientific method. I.e. they serve as a foundation for theories that make correct predictions as verified by experiment.

That's the main difference.

Any particular companies you can recommend?

Called them today about a refund - they told me I might not be eligible because I did the repair myself and not through an authorized repair center, but they will try to get it approved. We'll see how it works :)

It isn't.

All public APIs should have documentation, even if you believe it's obvious what they do. This documentation never goes out of date because once you release your API it tells you what you cannot change. If you changed the code so that your documentation is now wrong - this code change is a bug and you should fix it. Because there's other code in the wild that relies on the behavior that you promised.

Of course in practice you do have to change that behavior every once in a while. But this should be a big deal (that usually includes bumping up version numbers, mentioning it in release notes, etc). If you're changing it so often that updating the damn comment is an issue you either document implementation details that don't belong in API documentation or your API is unstable crap and nobody should be using it.

PS. Complaining that API documentation gets out of sync with the code is like complaining that unit tests break when you change the code. Duh - that's what they are there for!

Oh, really?.. Your smart employees suddenly stop comprehending basic math when it comes to their future compensation?

Or maybe - just a guess - when the CEO was recruiting engineers (who, perhaps, don't have much experience with the business side of startups) he told them they would have 0.75% of the company but forgot to mention dilution?.. Could that be the "nuance" employees struggle with?

How many people know what amber alert is? Of those people, how many know what to do about it? Of those people, how many know what Nissan Versa looks like?

How much harder would it be to change the text to something like "Child abduction alert: if you see <car color/model/license plate> call 911" (and, perhaps, include a silhouette of the car model they are looking for)

If your files are important to you - you need a back up. If not - just get rid of them in the name of simplicity :)

PS. Also, uploading many gigabytes over a typical ADSL connection is just painfully slow... even local NAS is too slow over WiFi for my taste, and if I have to have a wire - I can just as well connect an external drive.

^ - which he probably didn't need to begin with

This. Fixing broken economy takes years. Fixing broken civil liberties takes decades, if not centuries.

The decline in number/quality of editors is alarming, but what does it have to do with taxonomy? And how do the links fit into the picture?

TL;DR A random set of barely coherent assertions followed by OMG, Wikipedia is over

What I do find useful is to have a good variety of skills on the review team. Different people tend to check for different things. Some are just naturally good at spotting, say, concurrency problems, others have a pet peeve with names that aren't clear, etc. But someone who doesn't have an eye for concurrency problems won't magically start noticing them in a pile of code because there's a box saying "check for race conditions" somewhere on the list.

Really? I mean, tests might be overhyped, but so far it looks like the author draws incredibly general conclusions from some isolated incident. Why did the tests become irrelevant? Is their scoring algorithm now doing something completely different? Do they now have different use cases? Were they hard-coding scores when the actual thing that matters was, say, the ordering of the things they score?

> Only test what needs to be tested

well, thanks for the helpful advice :) Care to share what, in your opinion, needs to be tested?

Given the attention span of the folks who circulated the news in the first place, I would mention that no transaction data was leaked somewhere in the first paragraph.

I think IDEs hurt innovation in development tools more than almost anything else. They are like crack for your workflow - easy to get started with, but once you're on them you're stuck. Plugging in better tools into existing IDE is a big PIA if possible at all, and rewriting the whole IDE is a huge undertaking for any company who wants to make your life better.

Ironic, isn't it? :)

PS. Don't get me wrong - a Manager, or Util, or Helper is not the greatest crime against software design. The intention here is clear, functionality - no, not really. However engineering is about tradeoffs, and it is sometimes practical to have a dumping place for miscellaneous stuff. Just keep in mind that it is a "be careful" territory, those places do tend to turn into ugly and hairy mess over time.

ThingManager is a bad metaphor for a class that follows single responsibility principle (http://en.wikipedia.org/wiki/Single_responsibility_principle). It encourages you to stuff too much into a class because managers do many things, and it's not always clear what exactly they do - almost anything can be thought of as some sort of "management". The real reason is mentioned two paragraphs from the end - the name is simply too ambiguous.