Sure. A lot of the younger programmers (like myself at the time) were excited about it. But many of the old timers were very resistant to it. A lot of people complained that if it just compiled to C, why not just write it in C and save a step. And there was much bitching about how everything was so indirect and hard to figure out exactly what was going on. Of course, this was before there were good debuggers and direct compilers.

But it's like so many other things. Old folks get set in their ways. Young people want to change everything. I find myself starting to get the "get off my lawn" attitude now that I'm past my prime. But I do go out of my way to learn new things and try new ideas.

At this point, almost every other car on the road is full of safety features. Every place you could run into anything has a big impact absorbing safety barricades. Why worry about it? You are my crumple zone.

"They" are all of the programmers who have come before you. The computer engineers bemoaned COBOL because it let non engineers make programs to run on computers without knowing what was going on under the hood. Same with FORTRAN.

As languages have progressed, each generation provided more abstraction and let people get farther away from the hardware without having to understand what was going on at lower levels. And every time a language provided a new abstraction, the old guard pissed and moaned about how it was destroying programming by making it so the next generation wouldn't have to know all of the lower level details they knew. Object oriented languages were yet another in a long line of language advances that were decried by the previous generation who didn't want to learn the high level abstractions and were mad that the low level details they know well were no longer important. They claimed that the people who just wanted to program at a high level were "incompetent" and how it was leading to a "general cretinization of programming, and consequentially programmers."

Funny thing though. Most modern day programmers have no real clue what's really going on behind the scenes and they're pretty clueless about what happens once their source code goes through the compiler. And that's my definition of "incompetent". So when you say "Swift is for the incompetent", I say that incompetent people can write code in pretty much any language because I've seen them do it for decades over many generations of languages well before anyone knew what Object Orientation was.

Not only that, the old-timer "get off my lawn" types have been spouting the same nonsense since the 50's when it comes to newer technology. Sure, some languages are targeted at making tasks simple so they're easier for simpletons to use. And, of course, some languages are more poorly designed than others (*cough* *cough* C++ *cough* *cough*). And there are many languages that are more difficult to learn and master than others for no good reason. But people have been deriding next generation languages since the first generation. And that's why I laugh at your characterization of Swift.

That's what they've been saying about every new generation of languages since COBOL. They even said it about C++ and Objective-C when they came out and all the C programmers didn't want to learn it.

It's a condition of his bail. If he violates it he gets to wait for his trial inside a nice cozy 8x8 cell instead.

It's always interesting hearing the stories of people trying to fly into Meacham in Fort Worth, TX getting off by a couple miles to the west and starting an approach into what was Carswel AFB (now NAS Joint Reserve Base). The runways are only off from each other by a couple of degrees and only a couple miles apart so if you're flying VFR, it's not as hard as you think to confuse them. Fortunately, the controllers are good about making sure you get it straight before you get too far.

I've spent over 20 years building and maintaining all kinds of real-time systems, both safety-critical and not. And were they talking about a generic non-safety-critical system, I would fully agree with you. A lot of real-time systems out there are built with the same carelessness as every other system out there. But the whole game changes when you have to build a system that is as close to error-proof as you can make it and you have to be able to prove it. The amount of planning, reviewing, documenting, and testing required to make a safety-critical real-time system pass certification is astronomical compared to what's done in a "normal" project. Partitioning, I/O validation and well defined error handling are the rule, not the exception in a safety-critical system. And you have to prove that you handle errors by performing extensive testing on the system. Orders of magnitude more testing than you find on a typical commercial system. This is done because lives are at stake. Literally.

I suppose if you can get into the network you can do some kind of DOS attack. But the ARINC 664/AFDX network standard that they use has a few things to guarantee bandwidth allocation. I'm a little fuzzy on this end of it but I do believe the spec was designed so that if a box goes stupid and starts flooding the network it won't be able to bring down everyone else with it. Again, more things designed in for the purpose of safety that by happenstance cause the system to resist the effect of certain types of hacking.

As someone who has spent a great deal of his career in avionics design, both civilian and military, I fully agree.

Avionics computers are not PCs running linux or windows. They don't have generic user level applications. They are custom designed, custom built hardware with very specifically chosen components to do the specific job at hand. The application software is pretty much entirely custom. As far as operating systems, many still run home grown schedulers that provide a bare minimum of services. Only in the last 15 years or so have they even started using off the shelf operating systems and so forth. Even then, it's usually something like VxWorks or Green Hills Integrity or some other RTOS like that. But they have to use versions of the operating systems that conform to ARINC 653. And while ethernet has started appearing on modern systems, it's use is highly specialized. They may put an IP stack on the box to facilitate getting packets from one box to another but the content of the packets are very highly specialized and they are carefully scrutinized before they are accepted and acted upon. Not to prevent hacking but to prevent "undefined behavior". Safety requirements mandate that they carefully inspect packets coming in and drop out of spec packets according to the rules established long before the first line of code got written. Not because they're trying to prevent hacking. It's because accepting unexpected and out-of-spec data can lead to problems that make the plane hit the ground. The anti-hacking capabilities are a side effect of that scrutiny.

But even if you could get your packets into these specialized computers, how do you think you're going to hijack the box and spawn your malicious task that takes over? Like I said before, these computers aren't just PCs running Linux. They're custom built computers with an RTOS that very carefully and very deliberately partition the box to prevent tasks from corrupting each other or the operating system. And each task very specifically inspects every packet coming in before using the data so things like buffer overruns and what not simply won't work. So crafting the right kind of packet to allow you to insert your malicious code is more difficult by many orders of magnitude. Beyond that, you are extraordinarily unlikely to find a random port being open that gives you access to the OS core. That's a safety issue so it's checked before the computer can get FAA certification. The only ports available to be used are the ones that are needed and specified.

Is it 100% provable that you can't hack into the systems? No. But it's so monumentally unlikely as to be effectively impossible. Are there some systems out there that had vulnerable code make it through certification? More than likely. But even so, the threshold for making it through FAA certification is high enough that even bad code that slips through is far less vulnerable than most everything out on the commercial market.

Ah. I see where you are confused. That's not what I'm arguing at all. I'm saying that walking a couple of miles isn't that big of a deal for most people. And while a Segway may be useful, it's not essential. I may like to use one but I don't need to use one. 6 miles is a reasonable morning walk for most people of even slightly below average fitness.

You started amending your case to add more distance and multiple days, along with summer heat. And sure, those would affect one's desire to use a Segway. But it doesn't change the fact that many people can reasonably expect to do 6 miles in an average morning walk in and of itself. Thing about Rome is that it's a big city with plenty of cabs, buses, scooter rentals, and even car rentals. It probably has even more ways of making that 6 mile walk easier. I don't have to choose only between a Segway and walking. I have many choices. And while you may really be excited about using a Segway, it's not the only way to avoid walking long distances. It is one way of avoiding long walks. But not the only way.

Funny. I was thinking the same about you.

If I'm on a vacation that has sights which require me to walk for miles, I prep for the vacation ahead of time and don't go in the heat of the summer. If I'm on a vacation where the things I want to see are miles apart, I take a cab or other public transportation.

10km is only 6 miles. And at an average pace of 3 mi/hr walking, I can do that in 2 hours. Hell, if I stroll along at half that I can still do it easily in 4 hours before the mid day heat gets to 90.

10km in a morning? Hell, I can do that easily and I'm an out-of-shape middle age guy.

Well, I know for certain that I can get that service but I have to pay extra. It would be great if I could get it for free.