NSA-tapped undersea cables, North Pacific Ocean, 2016 - <AUTHOR> https://link.springer.com/article/10.1057/s42984-020-00014-x <comment><USER2> _'over 95% of global communications traffic is handled by just 1 million km of undersea fiber-optic cable.'_

'Just'? 1 million km is a lot of wire, you could wrap that length around the earth over 25 times. I can't imagine what the author of that sentence thought would be a more reasonable length of undersea cable...

<comment><USER3> Personally, I read it more as "95% of it is over a single medium", and that it's less about the actual length.

But, for the sake of comparison, the US has 6,853,024km of roads and 95,932km of expressways according to Wikipedia [0] (far and away the most of any country in the world, interestingly). Broadband penetration for the US is >50% for any demographic [1], so extrapolating there's millions of kilometers of internet cable just to support the US's internet needs. So maybe that number is pretty amazing after all...

[0] [https://en.wikipedia.org/wiki/List_of_countries_by_road_netw...](https://en.wikipedia.org/wiki/List_of_countries_by_road_network_size)

[1] [https://www.statista.com/statistics/710877/adult-home- broadb...](https://www.statista.com/statistics/710877/adult-home-broadband- users-in-the-us-by-age/)

<comment><USER4> I don't know that I would compare miles of road to miles of undersea internet cables. I think undersea internet cables are more akin to interstates in that they connect hubs from which local traffic can branch off. For sake of comparison, there are 46,876 miles of interstate road in the US.

<comment><USER3> I realize I didn't make my point well — I intended to use the roads comparison as infrastructure is typically roadside on poles, or underground in a roadway. I thought it would be a relatively good analog for how many miles of cable we have to wire the US.

</comment></comment></comment></comment><comment><AUTHOR> Original Title is: "Postdigital war beneath the sea? The Stack's underwater cable insecurity".

I've made a decision to editorialize the title to highlight the NSA involvement. But unfortunately the "2016" is a copy paste error (the "2016" is part of the caption of the image: [https://link.springer.com/article/10.1057/s42984-020-00014-x...](https://link.springer.com/article/10.1057/s42984-020-00014-x/figures/1) and shouldn't be part of the post headline)

</comment><comment><USER5> This isn't really new info is it? US NSA, UK GCHQ and German BND have been using this intel for years.

The article was published recently but the title says 2016 so I'm slightly confused.

<comment><USER6> Yeah I know we learned GCHQ _definitely_ wiretaps their undersea cables and allows the NSA to query the data without restraints.

[https://en.wikipedia.org/wiki/Tempora](https://en.wikipedia.org/wiki/Tempora)</comment></comment>


How to Parse Ruby - <AUTHOR> http://programmingisterrible.com/post/42432568185/how-to-parse-ruby <comment><USER2> Even lexing ruby for highlighting is really hard. I had to use so many lookahead hacks to get the lexer in rouge working: [https://github.com/jayferd/rouge/blob/master/lib/rouge/lexer...](https://github.com/jayferd/rouge/blob/master/lib/rouge/lexers/ruby.rb)

I learned a ton about ruby when implementing that. Did you know that this totally works:

        my_method <<-ONE, <<-TWO, <<-THREE
           text of one
        ONE
           text of two
        TWO
           text of three
        THREE

And all the % delimited strings are super hard.

(also note that pygments chokes on my perfectly valid ruby file, at `%r(\\\\\\\\)`)

<comment><USER3> For non-rubyists, what does this example do? Are those labels?

<comment><USER4> That's ruby's heredoc syntax: <http://en.wikipedia.org/wiki/Here_document>

I had no idea it could be nested like that and I've been using ruby for 8 years. Crazy!

<comment><USER5> Holy cow, 10 years for me and I've never even thought of nesting heredocs.

Some days I wish Matz would formalize the grammar so it is sane.

</comment></comment></comment></comment><comment><USER6> Well, even C has this requirement. Code like

      foo * bar;

Could either mean "multiply foo by bar and drop it on the floor", or "declare bar as a pointer to a foo". C++ makes it worse, of course. Either way, you need to be aware of what symbols are in scope at any given point.

<comment><USER7> An other fun one:

        (a) - (b)

which in statically typed C-like languages can mean either "cast the value -(b) to type a" or "subtract the value (b) from the value (a)"

<comment><USER8> These two are great examples of why i think "overloading" syntax symbols sucks. Problem is, nearly _every_ language does that, and in many cases it makes some expressions ambiguous (not to the parsers, as they have those corner-cases defined, but ambiguous to the programmers):

\- in JavaScript braces are used both as block delimiters and object literal delimiters \- in CoffeeScript, which prevents that particular grammar ambiguity from JS, whitespace is used for many different things: scope/block delimiting, object literals, even function calls (optional parentheses) \- Python uses parentheses both for expression grouping (precedence), function calls AND tuples \- square brackets are used in many languages to both denote literal lists/arrays and element access ([] operator) \- etc, etc, etc

There are very few languages that i know about don't do this kind of lexical- token overloading. Smalltalk is an example: square brackets are always blocks, parentheses are only used to group expressions, dots are always statement terminators, etc. I think Haskell is another example of a straightforward syntax, but don't quote me on that.

Is there any formal name for these kinds of non-overloaded/simple syntaxes? If there is a formalism for those, why is it that "overloaded" syntaxes are preferred most of the time, or why are they so prevalent?

<comment><USER7> Note that "overloaded" operators does not mean the grammar is context- sensitive (let alone ambiguous). For instance, the parens as grouping and tuple operators in Python are indeed ambiguous (you have to parse to the first comma or end parens to know which is which), but they're not ambiguous with funcalls: a function call opening paren an infix, it can't be the start of a new expression. Same with square brackets for both array literal and element access, one is a prefix, the other one is an infix. Similarly, there is no ambiguity to e.g. the `+` or `-` operator being both infix (addition and subtraction) and prefix (positive and negate)

<comment><USER8> Totally right. I was aware that this "overloading" does not imply ambiguity for the parser; it's just that i find it confusing to read in some cases (like the tuples in Python, or the {} in JS), and i think it's curious that language designers deliberately choose to use the same symbol for totally different things when they could use something else, or keep the grammar simpler.

I guess it's always a trade-off between simplicity at the grammar level and ease of use, but i'm not so sure about that either. Smalltalk has a very simple grammar, yet that doesn't make it harder to use than other languages with similar semantics; e.g. Ruby, which prefers to be "programmer friendly" by having multiple syntactic forms for denoting blocks, even a special syntax for calling function whose last parameter is a block, and much much more.

<comment><USER7> > i think it's curious that language designers deliberately choose to use the > same symbol for totally different things when they could use something else, > or keep the grammar simpler.

The problems is that there's only a limited number of symbols available in ASCII, especially "matching"/"paired" symbols where you've got all of three pairs to work with (`{}`, `[]` and `()`), with one pair having a lot of immutable baggage (`()`) and one being coopted by C's inheritance (`{}`). (I'm not counting `<`/`>` as they have even more historical baggage as comparison operators)

Now of course we could use non-paired symbols even for paired situations, but I guess these symbol pairs look... right? Especially for situations where we're defining a "section" or "grouping" rather than a coherent block (such as a string)

</comment></comment></comment></comment></comment></comment><comment><USER9> I'm interested in how this compares to other languages with reference implementations. Is ruby the odd one out here, not providing a formal grammar, or is that the norm?

Ruby has a stated design goal of making developers happy. As far as I'm aware, it hasn't been designed to be easily parsed.

I, as an end user (i.e. programmer), prefer it this way. If ease of parsing is important for you, maybe you should use something like LISP.

<comment><USER10> Python, Haskell, Java, Go have formal and even context-free grammars. It makes me as a developer happy since it's much easier to predict how the language will parse something.

<comment><USER11> Python is not context free.

<comment><USER12> Indentation is handled by the lexer, not the parser.

The parser is context free-- LL(1), actually.

The lexer maintains one extra stack to track indentations, meaning it's more of a PDA than a DFA, but the actual complication is mild.

<comment><USER11> The _language_ is not context free, although I agree there is a parsing solution which is not terribly complex.

<comment><USER10> It _is_ context free. INDENT and OUTDENT are directly equivalent to { and } in other grammars.

<comment><USER11> The difference is that INDENT and OUTDENT have to be defined by context- sensitive productions. _Even if this occurs in what would otherwise be the "lexing" stage of the parser_.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Use Ripper in 1.9.3. It's part of the distribution and it works well.

[http://www.rubyinside.com/using-ripper-to-see-how-ruby-is- pa...](http://www.rubyinside.com/using-ripper-to-see-how-ruby-is-parsing-your- code-5270.html)

<https://gist.github.com/michaelfeathers/4704833>

</comment><comment><USER14> _"Nobody really knows what the Bourne shell's grammar is. Even examination of the source code is little help."_

\-- Tom Duff, "Rc — A Shell for Plan 9 and UNIX Systems"[1]

[1] [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.3287&rep=rep1&type=pdf)

</comment><comment><USER15> I found the Rubinius source code to be quite readable. For example, here are the AST node definitions: [https://github.com/rubinius/rubinius/tree/master/lib/compile...](https://github.com/rubinius/rubinius/tree/master/lib/compiler/ast)

</comment><comment><USER16> A different approach, which has served me well, is to study and understand Perl's parser/lexer, which are more intertwined than your grandmother's Friday night challah. Once you get that, understanding the MRI parser is a snap.

<comment><USER17> Perl cannot be parsed in the traditional sense of the word. The parse tree is unknowable until you're actually running.

<http://www.perlmonks.org/?node_id=663393>

<comment><USER18> This one is also a good read,

<http://www.perlmonks.org/index.pl?node_id=44722>

</comment></comment></comment><comment><USER19> Remember that a yacc file builds an AST tree and paying attention to the AST tree goes a long way in understanding yacc file.

Language ambiguity due to context is pretty common. The way to deal with them is with nested scope symbol tables. And determine the semantic of a symbol usage based on previous declaration of the symbol, tracked in the symbol tables.

In the article's example, x + 3, it confuses the stages of the lexer and the parser. The lexer only knows x as a symbol. Its output is symbol('x') op('+') num(3). It doesn't know it's a function call or a variable reference. It is the parser's job to figure out the semantic of x based on context and to build the AST.

In this case if x has been declared as a variable before, its symbol and type info are recorded in the symbol table. When x + 3 is encountered, it's a simple lookup on the symbol table to see if it's a declared variable and generate the AST node with op('+', var('x'), num(3)).

If x has been declared as function in the symbol table, the lookup will generate the funcall AST node.

For special declaration rule like usage before declaration (as in Ruby), the lack of definition in the symbol table can be defaulted to a funcall.

</comment><comment><USER20> I came across this issue when looking to build a stripped down Ruby interpreter in JS last summer. A few attempts have been made at defining its grammar, though with each new version the task becomes more and more challenging.

If anyone's interested, this definition of Ruby 1.4 is pretty good: <http://www.cse.buffalo.edu/~regan/cse305/RubyBNF.pdf>

<comment><USER7> > If anyone's interested, this definition of Ruby 1.4 is pretty good

The question is whether what it defines corresponds to Ruby. It's easy enough to define an unambiguous subset of the language and declare you're done, but it's irrelevant if the grammar does not match what the language actually is.

<comment><USER20> You'll never reduce Ruby to a pure grammar, there are too many ambiguous cases - my point was simply that it covers a subset which incorporates almost all common idioms. As far as I am aware it is one of the few openly available, non-trivial attempts to do so and thought it might be of interest.

</comment></comment></comment><comment><USER21> How to parse XL: [http://xlr.git.sourceforge.net/git/gitweb.cgi?p=xlr/xlr;a=bl...](http://xlr.git.sourceforge.net/git/gitweb.cgi?p=xlr/xlr;a=blob;f=xlr/scanner.cpp) and [http://xlr.git.sourceforge.net/git/gitweb.cgi?p=xlr/xlr;a=bl...](http://xlr.git.sourceforge.net/git/gitweb.cgi?p=xlr/xlr;a=blob;f=xlr/parser.cpp). 676 + 747 lines of non-hacky C++ code.

</comment><comment><USER22> Does it come with decent tests?

<comment><USER23> <http://rubyspec.org>

</comment></comment><comment><USER24> fwiw, I find the syntax definition in the ruby_parser gem at [https://github.com/seattlerb/ruby_parser/blob/master/lib/rub...](https://github.com/seattlerb/ruby_parser/blob/master/lib/ruby19_parser.y) to be much easier reading, as it's written for racc (the ruby equivalent of yacc), although as the readme warns, it's not perfect.

</comment><comment><USER25> Here I note that while JRuby and IronRuby ported parse.y, CPython, Jython, and IronPython use totally different parsing (CPython rolls its own parser generator, Jython uses ANTLR, IronPython does handwritten recursive descent parsing) but are still comatible with each other.

</comment><comment><USER26> I wrote something similar here: [http://pineapple.io/discussion/just-learned- about-ripper-in-...](http://pineapple.io/discussion/just-learned-about-ripper- in-ruby)

</comment><comment><USER27> "By luck and various cabal like connections" - wasn't the Topaz link on hackernews or lobsters like 2 days ago?

</comment><comment><USER28> You can also gaze at <http://rubyspec.org/>

</comment><comment><USER29> [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_...](http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59579) ?

<comment><AUTHOR> The ISO standard is based on Ruby 1.8.7, by the way.

That said, 1.8.7 still has these issues. You absolutely _can_ parse Ruby, that doesn't mean it's not incredibly difficult.</comment></comment>


F-35 radar system has bug that requires hard reboot in flight - <AUTHOR> http://arstechnica.com/information-technology/2016/03/f-35-radar-system-has-bug-that-requires-hard-reboot-in-flight/ <comment><USER2> I read elsewhere, from a reliable source that I can't find right now. that the mean time between reboots on 'mature' fighter planes is 8 hours and the F-35 is at around 4 hours so far with plans to improve it.

It was the first number that shocked me the most.

EDIT: I found it:

[http://breakingdefense.com/2016/02/bogdan- predicts-f-35s-for...](http://breakingdefense.com/2016/02/bogdan- predicts-f-35s-for-less-than-80m-engines-included/)

 _The toughest problem the program is having is matching the timing of the aircraft's fusion software with its sensors' software. "As we add different radar modes and as we add different and capabilities to the DAS system and to the EOTS system, the timing is misaligned," and then you have to reboot it. Bogdan said he's aiming for eight to nine hours between such software failures when a radar or DAS or EOTS needs to be rebooted, which is what legacy aircraft boast. Right now they are at four to five hours between such events. "That's not a good metric."_

I don't understand a lot of that, but I think the fusion softwre refers to a unified UI for the pilot that merges information from the plane's very many sensors and presents it in a comprehensible way on one screen. Apparently pilots in older planes suffer from data overload and from watching many different screens at once - all while trying to fly a plane in combat. UI is reported to be a highly consequential improvement for the new plane.

<comment><USER3> > The toughest problem the program is having is matching the timing of the > aircraft's fusion software with its sensors' software

I don't know if I'm interpreting that correctly but what I'm getting out of it is clock skew between sensors and the fusion system, which I assume to be referring to sensor fusion.

That makes sense, analogous to a typical distributed systems issue. I would imagine the skew needed for the type of sensing they do is quite small. I doubt they can just toss an atomic clock on the plane :)

<comment><USER4> > I doubt they can just toss an atomic clock on the plane :)

They totally could. Some atomic clocks are quite small. The one pictured on the below wiki page doesn't look that much bigger than a 3.5" hard drive.

[https://en.wikipedia.org/wiki/Rubidium_standard](https://en.wikipedia.org/wiki/Rubidium_standard)

<comment><USER3> > They totally could. Some atomic clocks are quite small.

Are they mil spec? In other words do they operate correctly over a very large temperature range, with large input voltage variance, under high G-forces, in high vibration environments, etc?

I don't know anything about atomic clocks past what I can read on wikipedia but, I can say there is generally a large difference between mil spec ICs and commercial or industrial grade ICs, I would assume this would extend to atomic clock scale devices as well, but just a guess.

<comment><USER5> Who needs atomic clocks on individual planes when the US government has spent billions of dollars to place a fleet of atomic clocks in orbit?

<comment><USER3> Someone whom wants their planes to work when the enemy jams GPS and/or shoots the satellites down. We're talking about war here after all.

<comment><USER5> So you freewheel once GPS goes down. You might drift a few microseconds. This is not necessarily a problem.

<comment><USER6> If you're traveling at high speeds and relying on this timing to adjust flight control surfaces, or trying to use radar to get position of combatants and/or the ground, a few microseconds clock skew would be a major issue.

<comment><USER5> I didn't say clock skew. I said drift. As in, you lose GPS timing signals so your own internal master clock freewheels. That has nothing to do with clock skew (different components within the jet 'seeing' different time due to delays or other issues). The jets are designed to function with degraded or no GPS functionality. But, if it's there, they will take full advantage of it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I am getting a little tired of the "F-35 is bad" headlines. There should be more context that tells us how common such problems are in general. I remember listening to a podcast where they said that SR-71 pilots had to restart their engine every so often. Same for the Concorde. Sounds really bad but neither of these problems hurt the airplanes' usability and were not really a problem.

I firmly believe that military procurement is a mess but the discussion reminds me of the political discussion where Republicans jump on anything that goes wrong under Democrats and vice versa.

<comment><USER8> To be fair, the SR-71 was a highly specialized, and ultimately, highly experimental aircraft at its time.

The Concorde was similar. Only a few were ever made, and they were never expected to be the ubiquitous aircraft of their time or even their type (reconnaissance and passenger transport).

The F-35 is intended to replace several aircraft models which currently satisfy more specialized roles. It _was_ intended to be the ubiquitous (in various configurations) fighter aircraft for the US military (and some allies). This problem may not be the worst of its issues, it may not even be a major issue or really (from the pilots' perspective) an issue at all since similar reboots (but less frequent) are the norm for them in other aircraft.

But many other issues are demonstrating, and the reduced production numbers and increased production and development costs reveal, that there are numerous problems with this project in particular. It shows failings within the US political structure (that's essentially forced this project to continue), DoD procurement (that allowed many of these issues to occur initially), defense contractor procedures (LM, IIRC, doubling or tripling the number of engineers on the software side to "speed things up").

Really, it's going to be a classic for future engineers, computer scientists, MBAs and others to study. So I guess that's a good thing.

<comment><USER7> I totally agree that the F-35 project is a mess. But I would like to see a real analysis of the problems and not just jumping on any problem that sounds bad on the surface. Maybe a hard reboot is a problem, maybe not. I don't know.

<comment><USER8> [http://www.dote.osd.mil/pub/reports/FY2015/pdf/dod/2015f35js...](http://www.dote.osd.mil/pub/reports/FY2015/pdf/dod/2015f35jsf.pdf)

Haven't read it all, but started reading it. At least this is more "from the horse's mouth" rather than outside commentary like the Ars article.

</comment></comment></comment></comment><comment> sean-duffy According to a lot of people in this thread[0], it is pretty much expected that the radar in any fighter jet will need rebooting from time to time.

[0] [https://www.reddit.com/r/technology/comments/49iegx/radar_gl...](https://www.reddit.com/r/technology/comments/49iegx/radar_glitch_requires_f35_fighter_jet_pilots_to/)

<comment><USER9> This is correct. A radar or mission avionics system reset isn't a critical emergency. It may force a mission abort, but the jet is still flyable.

A reset event would be more worrying if it was a FCS (Flight Control System) computer reset in flight. Air Asia 8501 did something similar and the jet crashed into the sea. An F-22 pilot failed to properly reset his FCS before takeoff, and destroyed a $150m+ aircraft at Nellis AFB.

</comment></comment><comment><USER10> I assume that bugs requiring reboots to resolve is part of the design of the failure model. When a software fault is detected, its consequences are unknowable. Those consequences could include killing the pilot and destroying his $100M aircraft. Therefore, the default response is to reset everything and get to a known-good state ASAP.

This is not a bad general-purpose failure strategy: It's been believed for decades that most software faults encountered in production are Heisenbugs[1], and disappear rather than reproduce.

[1] [http://research.microsoft.com/en- us/um/people/gray/papers/Ta...](http://research.microsoft.com/en- us/um/people/gray/papers/TandemTR85.7_WhyDoComputersStop.pdf)

<comment><USER11> Indeed. Hence Tandem's success with hardware and Erlang's with software.

Crashing doesn't have to be crashing.

</comment></comment><comment> awinter-py Though to be fair, the software isn't due to reach 1.0 until 2050 (assuming the pentagon can scrape up another billion dollars to train ada programmers). No surprise that alpha software is bug-ridden.

<comment><USER12> According to this Stackoverflow answer the aircraft is mostly C/C++, no wonder they're having so many issues:

[https://stackoverflow.com/questions/9827176/what-is-the- pred...](https://stackoverflow.com/questions/9827176/what-is-the-predominant- programming-language-used-for-the-f35-lightning-ii-aircr)

I'm not sure there is anything I'd build with such insecure languages in 2016, let alone an aircraft or flight system.

<comment><USER13> Developing avionics software is quite different from what almost everyone on this site does. Check out JPL's 10 rules to get a taste of how it works, then consider coding within a bureaucratic process where not a single character of the source or supporting documents changes without multiple approval and confirmation steps.

It's a painful and expensive process, but it _can_ work, as demonstrated by the handful of teams that have reached the ~1 bug per 1e6 opportunities defect rate _all_ using variations of the above (tho some of them use Ada).

Let's check ourselves a bit and realize developing flight software is a different world from web services and mobile apps.

<comment><USER12> Smug condescension aside you didn't actually say why using a less secure/quantifiable language is a benefit to avionics software? I read JPL's 10 rules, they're pretty common sense stuff that I'd hope any C/C++ project would take advantage of, but they too don't address the reason why C/C++ would be better than Ada for this specific use-case? Or functional for that matter?

> Let's check ourselves a bit and realize developing flight software is a > different world from web services and mobile apps.

I agree, it is far more important in avionics to be provably correct and to eliminate as many bugs as possible. It is exactly BECAUSE these aren't web services or mobile apps that C/C++ shouldn't even be a candidate.

You've made exactly zero arguments to support C/C++ here. Just acted smug and condescending to all of us lowly other developers. Do you yourself work in avionics?

</comment></comment></comment></comment><comment><USER14> > F-35 radar system has bug that requires hard reboot [of the radar] in flight

<comment><USER15> To be fair, a 4-hour reboot on the radar is pretty bad to have in-flight.

<comment><USER16> I don't understand, why are people downvoting comments like yours without any explanation for those without the background on this :\

<comment><USER17> Because it was a simple reading comprehension fail, not specifically related to the subject at hand.

<comment><USER18> If downvotes only affected the specific comment, that would make complete sense, but they also affect karma. I guess it's not irrational to punish people who consistently misunderstand things, but is that a purposeful decision or an unfortunate byproduct of the karma system?

<comment><USER2> The idea isn't to punish people, IMHO, but to improve content for others reading the conversation. That comment doesn't contribute to the conversation, and in fact it confuses it, so it gets downvoted to where few will read it.

Voting is about the readers, not the commenters. Personally, other than for determining specific capabilities such as downvoting, I think tracking karma per user does little good. Karma per comment - a bit of feedback on your comment - is useful.

</comment></comment></comment></comment></comment></comment><comment><USER19> Had a bug. Everywhere I read said they already delivered a fix for this but I've noticed some news outlets not mentioning it.

Though I gotta say this damn jet has been a nightmare. Since they'll never stop working towards newer and newer jets I'm curious if lessons learned here will apply to the next one. After doing government contracting for many years where we don't get the "lessons learned" from the previous contractors or much of anything (I've had to FIGHT to get source code for a product we were supposed to update; ended up having to rewrite the damn thing) I'm curious how it works when they contract out to have a jet built.

</comment><comment><USER20> 'Have you tried turning it off and on?'

<comment><USER5> You joke, but for so many things in aviation, this is the answer. There are also a lot of problems where the answer is "re-poll all your interrupts, that problem you (the computer) think is a problem shouldn't be anymore".

</comment></comment><comment><USER21> Judging by reddit comments this type of thing is pretty common with fighter jets which is kinda surprising to me. I would have thought that this is one area where reliability is highly prized. Along with space shuttle software & other life/death stuff etc.

Instead "bash it with a hammer and maybe reset it" seems widely accepted. Weird.

</comment><comment><USER22> So, how fast does it reboot, and how much does this affect the other software components and operating the plane?

Not that I expect it, but this could be a minor issue, if this 'radar system' is as good as stateless (and not, for example, a component that tracks friends and foes over time) and if it reboots in milliseconds.

</comment><comment><USER23> So? The SR-71 has (had?) a bug that required both engines to restart in flight. Frequently.

<comment><USER24> Do you have a reference for this?

<comment><USER25> It wasn't really a "bug" but more that the computers could not keep up with changes in the flight conditions so if the engine spikes were not in the correct position for the speed and altitude it could cause a blow back which would extinguish the engines which will require the pilots to restart them.

[https://en.wikipedia.org/wiki/Lockheed_SR-71_Blackbird#Air_i...](https://en.wikipedia.org/wiki/Lockheed_SR-71_Blackbird#Air_inlets)

<comment><USER4> It also looks like they later mitigated it as technology improved:

> Lockheed later installed an electronic control to detect unstart conditions > and perform this reset action without pilot intervention. Beginning in 1980, > the analog inlet control system was replaced by a digital system, which > reduced unstart instances.

</comment></comment></comment></comment><comment><USER26> Looks like they need to add a "Turn Radar Off and On Again" to their FENCE IN.

</comment><comment><USER27> > Lockheed Martin has discovered the cause of the problem and has diverted > developers who were working on the next increment of the F-35's code to fix > it. A patch is expected by the end of March.

Much ado about nothing.

<comment><USER28> Seriously, isn't this to be expected? I know a lot of people have a massive hate boner for the f-35 because they read a lot of shitty war blogs but for a bunch of coders to act incredulous towards this information is absolutely ridiculous.

How many bugs have any of you introduced and fixed in the past week?

<comment><USER18> Most of us are working on things that are several orders of magnitude _less_ likely to get someone killed than the F-35 radar code. The goal for safety- critical embedded flight code is 0 hard reboots mid-flight. Is that controversial, in your opinion?

Edit: "standard for safety-critical embedded flight" was a bad word choice and wasn't what I meant. s/standard/goal

<comment><USER29> They found a bug in testing and are fixing it. That's literally why you test critical code, in case you didn't get it right.

<comment><USER18> I realize this. But bugs are sometimes worth talking about. Many people feel that a bug requiring a hard reboot mid-flight in a 5th generation fighter, a problem apparently not able to be overcome through multiple generations of fighters, is worth talking about. If you, or the original complainer, disagree, you're free to not participate in the conversation, but complaining about the rest of us talking about this bug is annoying.

Quoting from Boeing: _The F-35 has the most robust communications suite of any fighter aircraft built, to date. Components include the AESA radar, EOTS targeting system, Distributed Aperture System (DAS), Helmet Mounted Display (HMD), and the Communications, Navigation and Identification (CNI) Avionics._

If by _robust_ they mean "you can go 8 hours instead of 4 hours between hard reboots", I think that's worth talking about.

</comment></comment></comment></comment></comment><comment><USER30> How much you want to bet that simply running Valgrind would have caught it?

<comment><USER31> Everything... valgrind can not and does not fix GIGO.

</comment></comment><comment><USER32> Anybody know how long the reboot takes? That seems like important information. Especially if e.g. your AAMs need directions from the master system (?) in order to take over tracking by themselves.

<comment> bra-ket 3hr and 55 min

</comment></comment><comment><USER33> I bet the Chinese read about the F-35 fiasco and just laugh at us. The amount of money we're throwing down the hole here is staggering.

</comment><comment><USER34> "Have you tried turning it off and on again?"

</comment><comment><USER35> this doesn't surprise me one bit. I interviewed at one of the major defense contractors for a programming job last year and the technical interviewer had never heard of C#

this was for a java position

<comment><USER36> What use would a major defense contractor have with C#? And on what basis do you assume their code base is poor?

<comment><USER37> It doesn't matter if they're using it or not. If you haven't _heard_ of C#, you are very unlikely to be a competent software engineer.

<comment><USER36> There is so much more to software engineering than choice of language. I think it's entirely possible that defense contractors have more knowledge of the software development lifecycle than you are giving them credit for.

<comment><USER38> I believe parent's point is that one should _know_ that C# is a choice, not that they have to use it. How can one make an informed choice if one doesn't know what the choices are? If all you have is a hammer, and all that.

<comment><USER8> One of the best programmers I ever worked with would probably not know of C# beyond that it exists, maybe that MS makes it.

But I'd hire him over nearly anyone else for embedded work. He did absolutely no programming or engineering work after hours. He played his guitar, went to music festivals, and ran a club (a couple different times in his life, don't know what he's doing these days or if he's still alive, he'd be past 70 now). C# doesn't enter into the discussion when developing embedded software, and his lack of knowledge of it indicates nothing about his character or ability.

</comment></comment></comment></comment></comment></comment><comment><USER39> Do they initiate the reboot with CTRL-ALT-DEL sequence?</comment>


Exploring the mythical weekend project - <AUTHOR> http://www.informit.com/articles/article.aspx?p=1829420

<comment><USER2> Good effort! It looks neat but please can you do away with a twitter sign-in ? Some of us do not have or wish to use a twitter account to log in. Why not have a guest login for demos. Thanks.</comment>


V.S. Naipaul has died - <AUTHOR> https://www.nytimes.com/2018/08/11/obituaries/vs-naipaul-dead-author-nobel-prize.html <comment><USER2> I got interested in V.S. Naipaul after reading this essay-- well technically a book review of a Naipaul biography-- by Christopher Hitchens-- Cruel and Unusual [0]. It explains and summarizes Naipaul's literary significance as well as the fascinating fact that he acted very badly in his personal life. I read his Middle Passage travelogue after that after I read that and it did not disappoint as far as callousness goes. Although I wouldn't exactly say that it is what we should aspire to I did like it in its own way.

[0] [https://www.theatlantic.com/magazine/archive/2008/11/cruel-a...](https://www.theatlantic.com/magazine/archive/2008/11/cruel- and-unusual/307073/)

<comment><USER3> One that becomes clear is that V. S. Naipaul is probably the least sympathetic literary figure ever.

<comment><USER4> Good authors write good literature. An adult should not look for more in a writer. Give me Celine, Houellebecq and Naipaul one million times before the well-behaved, PC, generic , boring writer who tend to populate current prizes and recommended lists.

<comment><USER5> Is "well-behaved, PC, generic, and boring" really the central alternative to "entirely unsympathetic"?

<comment><USER6> Frequently, yes. Theoretically, you can have an artist that is well-behaved and interesting. But we don't get to make that choice and you can't custom order creativity to take the good bits and leave the bad bits (although crispr gets better and better).

Especially since if you start blocking out the unsympathetic artists early in their career due to being jerks and criminals and whatnot, this would have prevented many of the great artists.

For example a letter in 1968 shows John Lennon as a wife beater amongst other deplorable things [0]. Stopping him at this point would have deprived the world of many creations.

[0] [https://www.thetimes.co.uk/article/lennon-was-a-bully-and- ch...](https://www.thetimes.co.uk/article/lennon-was-a-bully-and-cheat- housekeeper-told-lawyers-kjctffw0chf)

<comment><USER5> Would it have deprived the world, or would the world have turned its attention to another artist? What reason do we have to think no one else would've stepped into Lennon's niche?

<comment><USER6> I think it's impossible to know, but 50 years later and there's no Lennon. If you don't care about art or beauty being uniquely special,it doesn't matter.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Another article today (although actually an interview from 1998) with more focus on his work & what it's about:

[https://www.newstatesman.com/culture/books/2018/08/vs- naipau...](https://www.newstatesman.com/culture/books/2018/08/vs- naipaul-1932-2018-king-literary-rootlessness)

A sad day. It seems to me that his themes of displacement, and cultural mismatches & how they affect people, keep becoming more important. We do a lot of shouting about these issues now, in the Western world in 2018 I mean; but he was never shouting, just digging into people's varied stories, and especially their disappointments, and trying to make sense of them.

<comment><USER8> > Racial equality and assimilation are attractive but only underline the loss, > since to accept assimilation is in a way to accept permanent inferiority.

Interesting. Anyone got details (background and context) on this quote?

<comment><USER7> Not this exact quote. But something like this is a theme in many of his books, often applied to himself, and to other people who've moved to western countries (or, into western-derived cultures).

It's also close to a theme of _Among the Believers_ etc, where (to paraphrase crudely!) he comes to view non-arab muslims as being in some sense immigrants to an Arab-centred culture, with some of the same feelings of loss.

</comment></comment></comment><comment><USER9> Fun fact: A song from a musical adaptation of Naipaul's novel "A House for Mr. Biswas" was re-adapted and used as the theme for James Bond movies.

[https://www.youtube.com/watch?v=g6EuzGhIyRQ](https://www.youtube.com/watch?v=g6EuzGhIyRQ)

</comment><comment><USER10> Does anyone else feel that V.S. Naipaul dropped off the radar as soon as he won the Nobel Prize? I heard his name constantly in the 1990s and very early millennium, but after he won the Nobel it feels like there was not only a decline in his output, but in his cultural presence in general.

<comment><USER11> His output had gone down by the late 70s, he got the Nobel in 2001 at age 68, past the age many people retire. It's not like he collected the prize and Salingered out.

<comment><USER12> What did Salinger do?

<comment><USER13> Salinger became a recluse, more or less, because he hated the publicity and attention that came with his literary success.

[https://en.wikipedia.org/wiki/J._D._Salinger](https://en.wikipedia.org/wiki/J._D._Salinger)

<comment><USER11> Well, he did come back to create the game popular TV game show _Hollywoo Stars and Celebrities: What Do They Know? Do They Know Things?? Let 's Find Out!_

</comment></comment></comment></comment></comment><comment><USER14> "The Nightwatchman's Occurrence Book" remains one of my favourite short stories ever since I read it in high school lit class. A truly curious author.

</comment><comment><USER15> Naipual=Nepal. He found out where his ancestors originated from and mentioned that during his speech.</comment>


HireArt (YC W12) Helps employers screen job applicants through work samples - <AUTHOR> http://hireart.com

<comment><USER2> I've gone through a few hireart applications and I find them rather irritating. They allow the hirer to ask an ENORMOUS amount of work for an application. The last one I did took over 3 hours to complete, 7 essays and two videos, one a rather long screencast.

I think hire art gets in the way of finding talent, but a lot of people looking to make a good connection dont have hours to complete a long list of questions created at the whim of a founder or HR rep.

<comment><USER3> Seems like a good thing. If you can fire off 100 resumes at no cost, while a company has to spend time reading each one and filtering out the junk, doesn't that seem asymmetrical? Large companies often have screening tests, or let hr people phone-screen candidates before moving on, but smaller companies don't have the resources.

If you want the job, you'll put in the time. In the process you'll also learn about he skills and culture the company expects, and they'll also be trying to present themselves as an interesting place to work.

It's the same dance, but now you need to be involved from the start.

<comment><USER4> Yes, but what if you still have to fire off 100 applications at 3hrs apiece? Effectively equivalent to 2.5 months of working full-time, and you may not even get an interview.

It makes sense for the company to invest more in finding the employee than the employee invests to find the company; the company has more to gain.

<comment><USER3> How much time did you spend on your college applications? Why should applying for a good job be easier?

Say it takes 3 hrs to do the application (probably not, but I haven't done one). The resulting candidate pool will be smaller, and consist of more dedicated applicants, who aren't just firing off blanks. I think both the employer and the applicant might get a higher "hit ratio".

If a recruiter has to sift through thousands of resumes, then good talent gets missed, bad talent gets interviews, and 2.5 months later you'll still be unemployed.

Maybe companies could still accept resumes and "regular applications" in addition to the HireArt channel. I think applicants going the HireArt route would be more likely to get consideration/interviews.

<comment><USER2> I think you're right, the hire art method may filter out people who are just fishing and help a person looking to hire someone to find people who are focused on doing the work to make it.

This is far more fair for workers in a non-recession than in a recession though -- where desperation will drive large numbers of workers to put in the extra time to get the job.

</comment></comment></comment></comment></comment><comment><USER5> It's interesting that HireHive (YC S10) did a similar thing with video interviews during YC[1] but pivoted to Hack Recruiter[2] and now Hacker School[3]. Will be interesting to see how HireArt tackles the challenges that caused Nick and Dave to move away from making the interview process to improving the candidate pool.

[1] [http://techcrunch.com/2010/08/02/good-on-video-is-the-new- go...](http://techcrunch.com/2010/08/02/good-on-video-is-the-new-good-on- paper-with-ycombinators-hirehive-and-ycommonapp/) [2] <http://www.hackruiter.com/> [3] <http://www.hackerschool.com/>

</comment><comment><USER6> Just went through the process. I'm glad that you can take a few cracks at the video before you choose to upload it. Overall, people's opinions will be colored by how employers use the process.

If a company wants a bunch of work done for free then maybe it's a signal to move on. If the company uses the tool to respect the time of the applicants and make hiring more efficient, it's good for everyone. Perhaps HireArt can guide employers here on the best way to use the tool.

</comment><comment><USER7> I think this is a great idea. Especially because it is so easy to submit a resume, and it takes so much time to weed out good ones from the bad ones. In addition, resumes tell me nothing about how passionate a given candidate is about company/job. Passion is a big deal and someone who is passionate about company/product/position WILL jump through the hoops necessary to get in the door. A+ folks apply to great colleges and go through long applications for start-up accelerators too. Why wouldn't they do it if they are passionate about a company/job? I think onus is on company to make sure they write job posting in a way that attracts passionate candidates who are willing to go through this - and it's customizable, so you don't have to use predefined template - you can just build one for yourself and go with it.

Resumes really are bullshit, and I am glad someone's trying to solve the problem. Great idea guys - congrats!

</comment><comment><USER8> Seems like an interesting product, but please don't use Lobster for your logo… You can honestly pick any one of MyFont's bestseller fonts (<http://myfonts.us/td-AErAU5>) at random and it'll look more profesional than using a free font that's over-used all over the web.

<comment><USER9> This was my first impression as well - the custom work on the 'A' in art is a good start, but Lobster's way too common to be the backbone of a unique and memorable logo.

</comment></comment><comment><USER10> Interestingly a YC company with no tech co-founders, the team looks like one Business Analyst from the real estate sector, one ex-quant from Goldman Sachs and one ex-McKinsey consultant.

Does this reflect a shift in the type of applicants YC is accepting ? - It'd be interesting to know how far along they were before they applied to YC.

As for the startup itself, I think they're making the mistake that other startups in the same space are making (at least from my experience in hiring at investment banks) in that they're presenting themselves as an alternative to CVs.

Pre-recorded video interviews, etc. are way too time consuming compared to CVs to be the first stage in candidate screening. I think the post-CV screening and pre-interview stage is probably the most effective place for this type of solution to live.

<comment><AUTHOR> Nick from HireArt here. I definitely agree with you that video interviews tend to be very time-consuming. One of the services we offer to employers is the grading of the interviews. We also keep the video portion very short (~2 1-minute clips per interview).

I'm the tech co-founder on our team. I do all of the development for our web app.

<comment><USER10> Isn't that going to be hard to scale ?

<comment><AUTHOR> The grading is not automatable, but I suspect it's scalable. We're finding lots of quite talented people willing to work part-time as graders, and we streamline their grading process as much as possible. We also try to provide very very rigorous rubrics and use multiple graders for the same interview to ensure standardization of the grades.

<comment><USER11> How do you qualify the graders? Is it on a case-by-case basis, reviewing their resumes & speaking with them? I could imagine that aspect of the process requiring some creativity to scale without losing quality.

<comment><AUTHOR> We've been bootstrapping the process by using our own app to hire graders. We administer work sample interviews on our site (i.e. we give the applicants dummy interview responses to evaluate) and use our current graders to evaluate them.

<comment><USER12> Wow that's really cool. Using your own product to solve your business' problem in true startup fashion.

</comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> By the way, we're specifically focused on non-technical hires right now. There are a few great tools out there for assessing coders (coding tests, Github), the likes of which the non-technical hiring process mostly lacks.

So far, we've designed a bunch of questions in marketing, customer service, sales, writing, etc., by getting input from people in those fields. But in the long term, we'd love to measure the correlation of our questions with actual job performance, and use that info to tune our interviews to be maximally predictive.

<comment><USER13> Hmm, that actually makes sense (I was about to complain that you were the fifth start-up to do the same) but you should properly consider dropping the video -- it is too easy to get sued for discrimination and it forces people who don't look good but are great writers (as an example) to operate under a disadvantage.

<comment><USER14> People form early impressions based solely on looks. If this became common I'd expect a companion industry to spring up styling candidates, and the only real result would be even more homologous teams.

<comment><USER15> that's true if candidates are just talking about themselves or answering easy questions (which is what some video resume companies do). But if you're answering really tough questions about a job (how to drive conversion, how to craft an email marketing campaign) it's pretty clear very quickly whether you know what you are talking about.

by the way, most candidates will eventually have to do an in-person job interview, so if looks are driving hiring decisions, this doesn't really change it.

</comment></comment></comment></comment><comment><USER16> What are the EEOC (Equal Employment Opportunity Commission) ramifications of employment screening via video?

Somehow I suspect that this is a non-trivial concern, just like pictures on resumes, for U.S. compliant HR departments.

<comment><AUTHOR> See an EEOC opinion letter on video interviewing here: [http://www.eeoc.gov/eeoc/foia/letters/2004/titlevii_ada_reco...](http://www.eeoc.gov/eeoc/foia/letters/2004/titlevii_ada_recordkeeping_video.html)

There are a few rules that need to be followed, but in short, the EEOC says it's okay.

<comment><USER4> Unsurprising, considering you generally interview them face to face eventually anyway.

</comment></comment></comment><comment><USER17> What I'm digging about HireArt is that companies using it seem to be more organized. They think more about the position they are hiring for at the start, submit interview questions to HireArt, write better job descriptions… If companies have a clearer idea of what they want, and they can communicate that to applicants, less time will be wasted all around. Here's an article from someone who has used HireArt, and makes this statement better than I: <http://bit.ly/Abh6rj>

</comment><comment><USER18> This is really helpful & efficient for the companies. We spend hours interviewing candidates and checking their portfolio & prior work in order to get to few great candidates. The current process for us is spread out. HireArt brings it in one place and focuses on what really matters.

In our experience, the candidates who are really passionate about what they do and like the company consistently shine out. HireArt process should help filtering them easier.

</comment><comment><USER19> We used hireArt to screen writers and got a ton of really good responses. the site still needs some work in automating the work sample process and I think we need to societally normalize/figure out the trial process (how do you build trust that I'm not looking for freebie work) but the premise is good - I'm done hiring people on the faith that they wont turn in complete shit. ::cough cough:: elance.

</comment><comment><USER20> Interesting, It's kind of like a FizzBuzz Test. One thing I noticed, you have something on your front page that says "See sample interview" I wanted to watch it but instead I get a "how it works/get more info" page. I felt like it was a bait and switch.

I would like to see a sample interview in that space.

Anyway, good work guys I hope everything works out great for you!

</comment><comment><USER15> This is Elli, one of the co-founders. We also launched on TC: [http://techcrunch.com/2012/03/09/resumes-are-bullshit- hirear...](http://techcrunch.com/2012/03/09/resumes-are-bullshit-hireart-is- better/)

I'd love to hear from any of you guys who are hiring non-technical people -- what are the biggest things you wish were different?

</comment><comment><USER21> I like the basic goal. The resume system is so suboptimal, it's nuts.

It incentivizes potential employees to focus so much energy on signaling and leads employers to unwittingly filter out otherwise great employees who just can't play the game well.

No idea if this solution is the answer to the problem, but good luck to them.

</comment><comment><USER22> This is a fantastic idea! The resume has seen it's demise as this approach will certainly pave the way for all future job hirings. Very impressive website as well!

</comment><comment><USER23> This is a great idea! I've been working with a bunch of freelancers, for some marketing work, and would like to hire someone full-time soon.

</comment><comment><USER24> We are trying HireArt right now and I really like it. If you are hiring anyone who is non-technical, you should give it a shot.

</comment><comment><USER3> Great idea. I've interviewed hundreds of candidates (mainly technical) and it's often easy to tell within a few minutes if a candidate's resume is inflated or skills are exaggerated. A short video or test that helps filter out candidates that would fail an interview or call within the first 10 minutes call seems like a huge timesaver.

</comment><comment><USER25> Great job. It's time for a revolution in the hiring process. Traditional résumé: RIP!</comment>


Remembering Radio Shack - <AUTHOR> http://www.cringely.com/2015/02/11/remembering-radio-shack/

<comment><USER2> I just remembered radioshack by buying 200 bucks worth of electronics that would have cost 2k retail before the sale, that I could have bought on amazon for about 200 bucks.</comment>


The Most Important Road Trip in American History - <AUTHOR> https://www.nytimes.com/2019/07/07/opinion/the-most-important-road-trip-in-american-history.html <comment><AUTHOR> Sixty two days to cross the US by truck! Thirty five years later thanks to Eisenhower it could be done in five days.</comment>


Android Emulators: 10 Best to Run Apps and Play Games on PC - <AUTHOR> http://noeticforce.com/best-android-emulator-for-pc-run-apps-play-games <comment><USER2> Great article.

I found two online Android OS emulators.

Manymo

"""

Manymo takes a different approach and brings apps in the browser. It is light weight program that is more like an android emulator online and allows you to run android apps in web browser. You can add fully functional android apps to websites with as much ease as you would embed YouTube videos.

"""

appetize.io

"""

Stream iOS & Android Native Apps in the Browser For embedding apps in websites, development, client demos, testing and more

"""

They could be light weight.

Upload and play.

How would you think?

<comment><USER2> What technology do they use to have Android/iOS emulator in web browser?</comment></comment>


Show HN: Fauxcli – mocks a command line client from a given YAML file - <AUTHOR> https://github.com/nextrevision/fauxcli <comment><USER2> That's nice, I like it, but I really want to understand the use case.

<comment><AUTHOR> Thanks, and that's a good question. I see two use cases primarily:

1\. Experimenting with the feel of a CLI application when designing one. This was the initial use case that started me down this path. I wanted to play with designing CLI without going through all the mess of actually coding it, especially when I wasn't sure what it should look like. It's a lot easier for me to edit a YAML file with relatively static data and see how I like the feel of it rather than updating a code base with "live" data.

2\. If you have scripts/programs you want to test that call CLI commands on live services and you want to mock the output from each (especially on create, update, destroy operations). Just symlink it somewhere in your PATH before the real application.

Hope this answers your question, I'll look at adding to the README in the repo.

<comment><USER2> This answers my question.

In fact I just wanted to know what was your motivation for writing it.

I can see another use case: tricking non-dev people with hardcoded CLI outputs without having to write the whole CLI.</comment></comment></comment>


Why should I have written ZeroMQ in C, not C++ (2012) - <AUTHOR> http://250bpm.com/blog:4 <comment><USER4> 1\. That "C equivalent" for error handling is not an equivalent at all. If one could handle the error in the same function then there is no reason to throw. The "C equivalent" is returning an error code, which has other problems.

2\. One can handle errors in initialization without exceptions and half- initialized objects: Make your constructor private and expose a static member function that returns an optional<T> (where T is the given class).

3\. Throwing in destructors is not a C++ problem, it's a general semantic problem around resources that aren't guaranteed to be freed up successfully. They are a pain in any language and you can only do best-effort approaches for not leaking them.

<comment><USER5> > 2\. One can handle errors in initialization without exceptions and half- > initialized objects: Make your constructor private and expose a static > member function that returns an optional<T> (where T is the given class).

This comment criticizes an article written in 2012 about a project developed starting in 2007 for not using a technique that debuted in the 2017 edition of ISO C++. For projects that could force all consumers to use C++11 or later, it'd be straightforward to add your own.

The idea of doing so in a cross-compiler way when you need to support the original ISO standard or C++0x in the late 2000s sounds very problematic.

<comment><USER6> It's not hard to write an optional<T> in C++ 2003, and likely can be done in C++ 98.

If you don't like that, return a T*, null if not created correctly.

<comment><USER5> I didn't mean to suggest the language spec would have made it hard so much as that I'd have really not wanted to approach it in a way that was going to work with VC6/2002/2005/gcc 2.95/sunpro/ibm/hp compilers of the era. (I think it was 2009 before I got to push VC6 off the raft.) ISO support in C++ compilers was __really bad __for a long time.

Our typical pattern was to return T*. But that fits well with the "I should have just written it in C" argument IMO.

</comment></comment></comment></comment><comment><USER7> Author asserts that "The decoupling between raising of the exception and handling it, that makes avoiding failures so easy in C++, makes it virtually impossible to guarantee that the program never runs info undefined behaviour." (and all the woes he encounters afterwards stems from trying to avoid exceptions due to that assertion). But that is not my experience at all. Exceptions are much more reliable than error codes - there will always be a case where you forget to propagate an error you got, but you cannot "forget" to propagate an exception... (and if you do, you can always run a debugger post-mortem to get a nice stacktrace of where the exception was thrown - `coredumpctl gdb` is a super nice tool for that on Linux systems with systemd). And languages without exceptions just end up with a galore of `if err != nil { panic(err); }` or similar horrors...

Also, regarding "compiler is likely to produce more efficient code.", benchmarks have shown that exceptions are generally faster : [http://nibblestew.blogspot.com/2017/01/measuring- execution-p...](http://nibblestew.blogspot.com/2017/01/measuring-execution- performance-of-c.html)

<comment><USER8> > you cannot "forget" to propagate an exception

Not only that, but you don't have to write a ton of boilerplate to manually propagate errors back up the stack since the compiler will do that for you. And it will do it in a consistent, well-defined manner.

<comment><USER9> Furthermore, properly structured C++ applications with RAII use the same path for normal cleanup for exceptional cleanup meaning that you're always covering that code. You don't have an entirely separate error handling path that only gets executed for errors.

</comment></comment></comment><comment><USER10> This article is simultaneously both obsolete and completely current.

Obsolete in that the C++ committee has addressed almost all of the issues raised (e.g. constructor semantics, xception semantics et al) though the discussion of site-of-error/handling-of-error continues unabated.

Later versions of C++ (17and 20) are powerful and expressive systems programming languages that aren't like the object-oriented messes of old.

The reason that this article remains completely current is that I suspect the majority, and likely vast majority, of C++ is still written in C++03/C++11 and full of dreadful issues like the ones in the article.

<comment><USER11> I haven't written anything nontrivial in C++ for many years and so far have only learned and used a couple minor features newer than C++11. Would you be kind enough to point to some resources on why C++17/20 are "powerful and expressive systems programming languages that aren't like the object-oriented messes of old"?

<comment><USER10> I wrtote a reply to this question in a comment parallel to yours.

In addition:

I don't write many classes in the sense of the Gang of Four book. I do write classes that are really just ways to speak with the type system, e.g. a "class" that has one instance variable that is an integer, so takes up only as much space as a native int, yet perhaps acts a special kind of table index.

Sequence manipulation, auto, and destructuring bind provide clearer ways to express algorithms without getting hung up in towers of class abstraction (an evil fetish) yet not lots of low-level manipulation and boilerplate like you'd see with C.

In c++20 generics and templating are almost unified which makes expression so much clearer (most of the old templating syntax is unnecessary in most cases). It lets you manipulate the type system much more clearly. You can do a lot more at compiler time -- you'll never get the expressive power of the Lisp macro system, but it's a lot closer with a lot of the old syntactic junk discarded.

Auto declaration has transformed the use of the type system and genericity.

In terms of resources to learn this stuff: I haven't found any single good source of info for these revisions.

I once wrote a comment on this but it took a while and of course vanished into the whirlwind of YC comments. So instead I'll suggest a web search for "new in c++17" and "new in c++20". I know that's kind of lame, but that's the best high level answer I can suggest.

I will say www.cppreference.com is excellent, but when it comes to newer features you often need something a little higher level to really grok what it says. It might answer your specific question though.

I follow the trip reports from committee meetings and read proposals that happen to interest me which often give context to a design decision.

I started a new project (blank editor buffer) using C++-17 in 2016. I hadn't written c++ since around 2000 (though I'd previously been involved in g++ development since around '87.* So I treated it as if it were a brand new language I'd never seen before. The only book I bought was Stroustroup's "tour of C++" which introduced c++14, then used searches like the ones above to keep up with developments in C++.

If you're in the same boat I'd say choose C++20, even though the full language isn't available yet, which is what I did with C++17. Some features I was able to bring in from Boost (which is where many new features begin) and some I just couldn't use until it was time to refactor something anyway. Still, this really made a difference.

* yes before g++ was released by the FSF -- tiemann and I both worked at MCC at the time and used to have dinner at 3AM to discuss what each of us was working on, which is how we later came to start Cygnus.

<comment><USER11> Thanks!

</comment></comment></comment></comment><comment><USER12> I don't get it. Exceptions are bad -> don't use exceptions. Constructors can fail with exceptions -> use a factory pattern and handle errors explicitly. Destructors can't fail: right, so don't, and yes, if you need to do finalization that could fail then that has to be explicit (as in C) and you can handle errors there, and yes, that leaves you with half-destructed objects, but so what.

No, I think high-level static data typing is very important. Today Rust would be a better language than C++ for this, but C++ is still better than C.

</comment><comment><USER13> It seems like the author's main complaints are avoided if one follows the Google C++ style guide, which says:

\- Don't use C++ exceptions

\- Don't do work in constructors (prefer "Init" or factory functions instead)

[https://google.github.io/styleguide/cppguide.html](https://google.github.io/styleguide/cppguide.html)

There may be other reasons to prefer C over C++, but if you don't like exceptions, you don't have to use them.

<comment><USER14> > Don't use C++ exceptions

That's not what Google's C++ style guide says at all. They only argue that Google's old C++ code base is not exception-tolerant, thus as they don't want to waste time and they don't want risk adding bugs by refactoring their legacy code then they just decided to not use exceptions.

That's it.

<comment><USER13> You're right. My point wasn't that one should blindly follow Google's style guide and avoid using C++ exceptions, only that there is an alternative to the C/C++ dichotomy that the author presents. It's possible to write millions of lines of C++ without using exceptions. There's a trade-off, which is described in more detail in the style guide, and the choice depends on the specifics of one's project.

</comment></comment></comment><comment><USER15> I've always felt that object-oriented programming as a concept (that is, define structures and then define functions to operate on them together) is useful: object-oriented programming as a language design is not. Once you understand what encapsulation, inheritance and polymorphism _are_ , you're much better off using them as guidance to structure your program in an otherwise procedural language like C than wrestling with a few dozen new keywords and an opaque specification.

<comment><USER16> C++ is a multi-paradigm language, and programming in it does not force you into the object orientation. Sure, there is a lot of encapsulation going on in the standard library, but it does not mean that you have to follow the same approach in code you write (although I find that it is the ability to specify destructors that separates C++ from the plain old C, and you cannot do that if you do not write classes).

</comment></comment><comment><USER17> Oh, the irony of preferring to use C in order to avoid undefined behavior. C is every bit as much a minefield of undefined behavior as C++ is.

[https://www.i-programmer.info/news/184-cc/11862-c-undefined-...](https://www.i-programmer.info/news/184-cc/11862-c-undefined- behavior-depressing-and-terrifying.html)

</comment><comment><USER18> A thread from 2018: [https://news.ycombinator.com/item?id=18668669](https://news.ycombinator.com/item?id=18668669)

2015: [https://news.ycombinator.com/item?id=9577988](https://news.ycombinator.com/item?id=9577988)

2013: [https://news.ycombinator.com/item?id=6220049](https://news.ycombinator.com/item?id=6220049)

2012: [https://news.ycombinator.com/item?id=4455225](https://news.ycombinator.com/item?id=4455225)

[https://news.ycombinator.com/item?id=3953434](https://news.ycombinator.com/item?id=3953434)

</comment><comment><USER19> I was trying to figure out if this was satire.

C++ gives you strictly more tools, particularly for guaranteeing reliability, and they're all optional.

What particularly laughable here is the split ctor/init pattern is allegedly driving them towards C, whereas C doesn't even give you dtors! If you're forgetting your init calls, are you really telling me you're not going to forget your destructor call? There are plenty of approaches besides split-init anyway, but it feels like the author feels pulled towards C for other reasons, and is looking for reasoning after the fact. C is not a magic bullet for simpler code!

C is useful for solving social problems with deciding what features and patterns of C++ to use, if you've given up on code review and style guidelines. If you decide that's you, good luck! You'll need it.

<comment><USER20> > C++ gives you strictly more tools, particularly for guaranteeing > reliability, and they're all optional.

You are right. But it doesn't help. When I used C++, I constantly shot myself in the foot by using its features. It did not feel like overusing, but I just wanted type-safety and to replace macros. It was impossible to restrict to useful features, because they are all useful in their way, only they come at the price of spreading everywhere until you don't understanding what is going on. Typing rules are insanely complex. Overloaded template error messages and hilarious amounts of boiler plate member functions just to satisfy the constructor rules and to catch the best overload for every integer type were the result.

I went back to C. It's a relief.

<comment><USER21> this is ridiculous. Every remotely powerful programming language gives you an opportunity to shoot yourself in the foot. c++ is so simple, and with every new standard it becomes even better and easier to use. How can anybody possibly complain is beyond me.

<comment><USER22> A language with four different pointer metatypes for memory management and (unrelatedly) four different pointer type meta-casts is not "simple".

The subdialect of features that you have settled on may be simple, but the language itself is a nightmare of random feature archaeology and creeping throw-it-against-the-wall-and-see-if-sticks extensions, which somehow still fails to provide clean simple tools for polymorphism.

</comment></comment></comment></comment><comment><USER23> I'm a bit confused about the current state of ZeroMQ and its relatives. There's nanomessage, which for some reason didn't pan out and is superseded by nng(?), but ZMQ still seem to be the most popular option. If I were to pick a broker-less message queue today, what should I pick?

<comment><USER24> My understanding: Pick zmq if you want something safe and battle-tested with good client library support. Pick nng if you want to be at the forefront of new tech or need some of its unique features over zmq ([https://nanomsg.org/documentation- zeromq.html](https://nanomsg.org/documentation-zeromq.html)). Performance-wise nng still seems like it's inferior to zmq because it's not as heavily optimized. There are lots of performance-related unresolved Github issues.

nanomsg is not an option because it's essentially abandoned.

I've been using nng for a project of mine and I'm happy with it so far.

<comment><USER25> Would you say either is something you would put in a decently scaled production system?

<comment><USER26> Using ZMQ (from C) at high volume, we found it dropped data, so we abandoned it.

<comment><USER27> What did you replace it with?

<comment><USER26> Direct writes locally to ebs and then stream to S3 and async collation after.

</comment></comment></comment></comment></comment></comment><comment><USER28> I believe the placement new operator does exactly what is needed here. It'll take a self-allocated block of memory and run the constructor on it, thereby avoiding the risk of system generated exceptions as execution stays purely in user code. Basically, it allows you to use a C++ constructor like a C init function.

</comment><comment><USER29> Are there any good resources (websites/books) to learn some of the new ways of doing things in C++ 20 vs older. Eg something that shows the old patterns with pitfalls and what replaces them in C++ 20?

<comment><USER30> Bjarne Strsoustroup's short book "A Tour of Modern c++" fits the bill, and was written for the same purpose.

<comment><USER31> Has it been updated for C++20?

<comment><USER32> "It covers C++17 plus a few likely features of C++20.", from [http://www.stroustrup.com/tour2.html](http://www.stroustrup.com/tour2.html)

</comment></comment></comment></comment><comment><USER33> From Java pro view:

In Java it's a sin to do anything complex in constructors. You only assign fields and maybe, maybe, call some pure static function to assign a computed field.

That mainly comes from unit-testing perspective -- so you can mock the parameters for a unit object _before_ the object does anything.

If you really need to do something complex to initialize those fields, it's better to extract them to different service class (and call it, ahem, Factory).

So the code looks more like his C example, but wrapped in classes.

</comment><comment><USER34> This has become one of those "classic" articles. Worth a read if you haven't. The bits about exceptions reminded me of an article on Nim's "goto" exceptions implementation [1]. The implementation appears to be a combo of error codes and goto's to automatically propagate the exception. It performs well and works on embedded devices, although I've only done a smaller project in Nim on an Arduino based board. It's odd having a serial port print stack traces. Careful a slow serial line can lead to a slow printout though!

Nim with the new ARC GC and move semantics seems to make a nice language for embedded development or for creating re-useable libraries. Rust seems promising but so much embedded work is still C/C++ only at some level, while Nim compiles to C/C++ nicely.

1: [https://nim-lang.org/araq/gotobased_exceptions.html](https://nim- lang.org/araq/gotobased_exceptions.html)

</comment><comment><USER35> ZeroMQ is a behemoth; for something that just handles communication, it compiles to like 660KB of i386 machine code. Is there an OS kernel with networking, virtual memory, USB and a file system hiding in there?

</comment><comment><USER36> This is a complete straw man argument against C++ based on exceptions vs return codes. C++ can handle C return codes, and the compiler comment needs some data to back it up. I would give this more than a grain of salt if the author had an 'alternatives considered' section or some other legitimate arguments like "I'm OCD and I just can't handle the fact that if I want to alphabetize the methods in the declaration for a base class it's a breaking change in terms of binary compatibility for a shared library."

</comment><comment><USER37> Given the article's age, the issues brought up are reasonable.

Now that it's 8 years later, I'd summarize it as:

\- exceptions were a bad idea (in any language); don't use them.

\- implementation inheritance and constructors / destructors that contain non- trivial logic were a bad idea; don't use them.

This basically means you shouldn't be writing idiomatic object oriented code.

Fortunately, C++ supports other programming paradigms, and in current C++, you can avoid both these historical warts; they shouldn't affect day-to-day systems programming or error handling.

</comment><comment><USER38> I think there's a lot of merit to this post, but it really shows its age. Modern C++ typically suffers from only the last point raised - <USER2> during destruction, but that goes against the all good C++ practices.

Overall, the author's approach to exception use is flawed. It's bad form to use exceptions for code flow purposes, as per their example. If you throw an exception in the same block that catches the exception, you've wasted a whole lot of time doing something an IF-statement could solve trivially.

All projects that I have worked on that use C++ has declared that exceptions should be used in exceptional circumstances only - that is, when you cannot handle the error in the current code block and the function interface does not support returning enough information to the caller to detail what went wrong. An exception is more than just throwing your hands in the air and saying "I can't do that" \- it has context, purpose, history. Getting rid of exceptions breaks some of the fundamental design concepts of the language.

2-step initialisation is the only way around errors during construction whilst forbidding exceptions. But 2-step init breaks a fundamental rule of RAII - <USER3> constructor acquires the resource and establishes all class invariants or throws an exception if that cannot be done. If the constructor is not allowed to throw exceptions, as per the language's standardised interface for constructors, then my library or application needs to be modified to support whatever process a third party library has defined as appropriate. There is a wide surface for bugs to creep in, let alone costing me time, money and effort in supporting whatever interface they've come up with.

If an object has been constructed, it should be in a valid state unless an exception has been thrown, in which case I'm told what went wrong. If I can fix it before the stack is fully unwound, I can save the day. but if there's nothing I can do, the exception has to roll to the top as that's the only other option. That then begs the question; should I catch all exceptions at the top level and prevent crashing, or should I crash and allow whatever system I'm running under to restart me? That depends on the project, but typically I'd let it go. systemd should bring me back, docker should restart me, kubernetes should restart my pod, etc etc. If I focus on what is within my control, and delegate everything else, the system will be cleaner and much more maintainable.

I've never come across a situation where exceptions during destruction is a problem, but am very interested in any examples. C++ standards define that you _can_ throw exceptions, but you shouldn't for the exact reason raised in the article - the process will be terminated as there's nothing else that can be done. If there aren't any destructors containing the throw keyword, it's not likely to throw an exception - OOM or other system exceptions are still possible, but why are you allocating memory in a destructor? destructors just need to release resources and clear down the object, it shouldn't be requesting more resources. Thinking about saving the object state before exit? wrong place to do it.

<comment><USER39> A problem is if you use RAII for other resources than memory, for example files. You want to put the close function in the destructor then, but close can throw an exception. [http://www.cplusplus.com/reference/fstream/ofstream/close/](http://www.cplusplus.com/reference/fstream/ofstream/close/) (Of course the solution is easy, you wrap close in a try catch block, but as alwaya all the solutions are easy in c++ but this is one of the surprising corners, which might be done more often wrong then not)

<comment><USER38> Interesting corner case that I can't say I've ever seen before.

fstream is a bit of a mess. Even the documentation for close is a bit contradictory. Its exception safety states that an exception is caught and rethrown after closing the file if one is thrown by an internal operation. That to me sounds like the actual resource being managed will be closed (assuming the fd is valid), but any data may not be flushed out of the write buffer.

sounds to me like iostream needs some serious attention in future specs, but that's unlikely to happen unfortunately. Creating new toys > fixing old ones.

</comment></comment></comment><comment><USER40> Writing in C++ means that the C++ library you are using becomes a dependency. Probably not an issue, if you have the source code to all libraries that you use, but maybe an issue if you are vendor and try to support not only all possible modern compilers, but what they target to (platforms, runtimes, models, etc.)

With just "C", not "C" only at the interface part, you can avoid that. Even to the point that your binary artifact (library) can be reused safely between DEBUG and RELEASE. Alternatively you need to ship this as shared statically linked to CRT library (which lots of vendors do), but it's general pain in the ass... for all platforms.

So that is the hidden cost of C++, even if your interface is still "C".

<comment><USER40> Not sure why this got downvoted? Anyone to comment? I use C++ daily on my job, and I'm very happy with its developments - especially C++11, C++14, C++17 and what's coming in C++20 - but statically linking problems are real, and pain to solve (long term). We do mostly MSVC, where some teams are still in VS2017, others VS2019 - and while they are compatible - the compatibility works only if your final app is compiled with the latest compiler from each version, which puts our team (doing mostly libraries, and providing precompiled ones) that we should use the lowest version, but then our CI infrastructure might use even earlier.

With "C" there is less to care there, as most is set in stone (unless you use some really compiler vendor specific extensions, that appear during link time).

Just an example - [https://devblogs.microsoft.com/cppblog/making-cpp- exception-...](https://devblogs.microsoft.com/cppblog/making-cpp-exception- handling-smaller-x64/) \- this is great improvement, but also means that if you've compiled your lib with VS2019, and it throws an exception under application that uses VS017 - it'll not work.

<comment><USER41> That exact same problem exists in C in the exact same way. It's somewhat less of an issue just because C is essentially frozen in time, but it has the same inherent problems & design issues.

But if you statically link your C++ runtime & only expose C interfaces then you're fine. You can be "just like C" only at the ABI boundary, that's well supported and works great. It's a quite common setup even.

Like for your particular example I don't think the solution to "in some situations I can't throw exceptions across an ABI boundary" is "switch to a language where exceptions don't exist at all and error handling is 'good luck'". It'd be nice if there was a way to flag an exported symbol as being ABI sensitive & letting the compiler patch up differences, that'd be a nice feature. Nuking it entirely seems like the opposite of a solution though? But you're still free to do that in C++ if you want. noexcept all your exported symbols & use error returns, just like C. Or even just compile with exceptions disabled entirely.

<comment><USER40> "But if you statically link your C++ runtime" \- you need to take careful measures your symbols not to leak as visible. Doable, but takes some time. Also might be easier with gcc/clang - e.g. -fvisibility=hidden, but nothing like this in msvc AFAIK.

<comment><USER7> Msvc symbols aee hidden by default, but why would symbols be visible be a problem ?

<comment><USER40> That's not true at all. Sorry they are completely visible, unless all of them are "static". Most of all it also leaks what imports need to be done - as in I require this from MSVCP140.dll or MSVCP140_1.dll - like "_CxxFrameHandler4"

Again I'm talking about statically linked libraries, linked to the dynamic CRT (MSVCRT - e.g. /MD, not /MT)

</comment></comment></comment></comment></comment></comment><comment><USER42> @mods can we change the title to "Why I should have" instead of "why should I have"?

The current title reads like a question with the question mark omitted ("Why should I have used C, not C++?") which, at least to me, implies that it's saying C++ was the right decision. The thesis of the post looks like the opposite.

</comment><comment> bra-ket previous discussion: [https://news.ycombinator.com/item?id=3953434](https://news.ycombinator.com/item?id=3953434)

<comment><USER18> A few others listed here: [https://news.ycombinator.com/item?id=22937991](https://news.ycombinator.com/item?id=22937991)

</comment></comment><comment><USER43> The only thing I dislike about C++ is that I can't declare private fields privately, I can use private: but it is there in header... in C I can just declare struct Foo; in header then implement it without expose its gusts.

<comment><USER44> Is that a security concern, an obscurity concern, or a readability concern?

<comment><USER43> usability, say I use external library Bar, then I declare

private: Bar bar;

the end use will have install Bar library as well to use my library despise Bar being embedded in my static library, I dislike that.

</comment></comment></comment><comment><USER45> Somehow it reads like a love letter to Go, but I bet he wouldn't like the Garbage Collector ;-)

</comment><comment><USER46> When I did C++ I always ended up using a very small subset of it. No exceptions, no inheritance besides a few interfaces. But in general I agree with his point. There are a few things C could improve though.

One would be a way to automatically clean up resources. Maybe something like "defer" in Go.

I wonder if templates would fit into C. STL is super useful.

A real string type would be good too.

<comment> anand-bala All the things you mentioned can be found in Zig! [1]

It's exception semantics are very similar to Go, but unlike Go, you have to handle the error. It has constructs like `defer` and `errdefer` which allow you do clean up at the end of the scope or on exception respectively. It has support for Generics and Metaprogramming without having to resort to preprocessor macros.

It just released v0.6.0 and is actively in development with an engaging and helpful community.[2]

[1]: [https://ziglang.org/](https://ziglang.org/) [2]: [https://github.com/ziglang/zig/wiki/Community](https://github.com/ziglang/zig/wiki/Community)

<comment><USER46> Zig definitely looks interesting. I may use it in a smaller project to try out.

</comment></comment></comment><comment><USER47> By now he probably realizes that the Java version is what he was looking for all along: [https://github.com/zeromq/jeromq](https://github.com/zeromq/jeromq)

Why C/C++ coders don't even write "Hello World" in Java SE before drifting away into rewriting the ball bearing (1907) part of the wheel is beyond me.

The Throwable class is exceptional in every way, it wastes almost nothing and gives the programmer the ability to catch all problems that occur in the VM.

      public static void main(String[] args) {
        while(1) {
          try {
            // do everything, and always throw unchecked
            // Exceptions unless you need the programmer to
            // handle the problem
          }
          catch(Custom c) {
            // here we can react to the exact problem the
            // parent programmer devised
          }
          catch(Exception e1) {
            // something "normal" happened that would have
            // generated completely random behavior with
            // machine code
          }
          catch(Error e2) {
            // something "critical" happened that would have
            // generated a segfault with machine code!!!
          }
          finally {
            Thread.sleep(10);
          }
        }
      }

The above code will never cause you to loose sleep. You can pretend there is a way to do this in any other programming language, but only C# would be able to and it is lackluster in so many other domains.

C will not help you with exceptions or concurrency, it will punish you into believing Rust is the solution.

C++ Exceptions are complete garbage, the only good part of C++ are std API (not implementation apparently) and Objects for structure, not for data (cache-misses).

Java does not crash and has the same performance as machine code, that is why it is the leading server language in the world.

Goodbye karma! Xo

Edit: that was fast!

Edit2: Please comment if you downvote.

<comment><USER41> > Why C/C++ coders don't even write "Hello World" in Java SE before drifting > away into rewriting the ball bearing (1907) part of the wheel is beyond me.

I write C++ & Java on a daily basis.

I don't know why I would _ever_ willingly choose Java for a personal project. It's not fun & it's inflexible. And the C++ side of me cringes with how inefficient & slow "simple" things are. Especially for anything that doesn't last long enough for the JIT to come along and make it not horrendous.

If I want to pay for a JVM I'd at least go with Kotlin. But I'd take C# over Java if I had a choice.

And I don't know why you think C++ means "rewriting the ball bearing"? There's a pretty decent standard library these days, and no shortage of libraries to add anything else. Depending on what you're doing there's a richer set of available libraries for C/C++ than there are for Java even (such as anything to do with graphics).

> Java [..] has the same performance as machine code

It so incredibly doesn't. Maybe when value types are added then Java can regain some ground on the performance front, but right now you're absolutely paying a price for Java. Often a price well worth paying, but still a price.

<comment><USER48> I find Java a lot more fun if you don't use getters/setters for everything.</comment></comment></comment>


Chromebooks are now available starting $349 - <AUTHOR> http://www.google.com/chromebook/#buynow

<comment><USER2> I lost my Chromebook in an accident some 6 weeks ago. When I got around to replacing it I got an Android tablet instead. I hate to say it, because I respect all the work that went into the Chromebook, but the tablet is sooo much better.

<comment><USER3> I was wondering about this. It seems that the netbook has given way to the tablet. Is ChromeOS still relevant or, as with many things Google, just a foray into an area that will become something bigger, later.

<comment><USER2> _Is ChromeOS still relevant_

IMHO, no. Chrome needs to be migrated over to Android (something which appears to be in process, but which is not very stable at present), and the two platforms should merge. Sorry to be a bit handwavey about such a complex topic, but at bottom I see them as two different Linux distributions and think the hardware-specific differences are a sideshow to that. Mind you, we could be looking at another generation or two of tablets (about a year each on current form) for that transition to occur, Microsoft has the right idea with a single cross-platform brand identity.</comment></comment></comment>