excepttheweasel's comments

How do twin studies separate those children from the culture they're raised in?

Can you link any evidence of federal agents pulling occupy protestors off the streets into unmarked cars? I cannot find any and the linked article does not discuss them.

Right, but in Typescript you can't match on the type at compile time, you have to add a "type" field with a string tag and match on it at runtime.

Rust can compile to WASM, and I would assume would outperform vanilla JS.

I think the go language has taken a position along the lines of "re usability and abstraction are overrated". I certainly think there is some truth to that, I am really enjoying working with go on smaller projects and it is this philosophy that has made understanding the code much easier.

But I wonder how it really scales on a large code base like this? Some of the best projects I've worked on leverage usability more effectively to create a sort of vocabulary. They're far more concise, there is rarely more than one source of truth, they're far easier to change and improve. Does this hold true for 540,000 lines of go code?

I have had the most success with a keto based diet. There is a good outline here: http://josepharcita.blogspot.com/2011/03/guide-to-ketosis.ht...

Importantly for me, this diet drastically reduces cravings and reduces the impact of hunger, making it far easier to keep to vs other diets. But it can be quite restrictive, you'll likely find that eating out severely limits your options and it is tricky to keep to if you're traveling.

The main downside to using Rust for web apps - at least in my opinion: is having to learn and use a type system which includes affine types: lifetimes, borrowing etc. But if you've already put in the effort to get to grips with this part of the language, that's not as big a drawback. Then you get all the other positives of the language, like its strong type system, fast speed, sensible package manager, lack of GC pauses etc.

> In many cases, that up-front cost is paid back many fold later, when other programmers (or you yourself, after you’ve forgotten the details of the code) come and try to read and work with the code. Go optimizes more for understanding the code later than for building big things quickly.

I believe this sounds attractive in part because programmers are so excited by the idea of solving problems, and it's true that a specialized implementation can always beat a general one. But it does not sound particularly sustainable.

A language that doesn't provide adequate abstractions often results in requiring its users to develop those missing abstractions over and over again. With the requisite possibility of bugs or implementation naivety. As both a Rust and Go user, I do find the talk of generics a little over played. Go has great facilities for code reuse that often mean you won't miss generics as much as you might think. But I also see Go projects growing in size quicker than I can appreciate. The increased volume of code, each piece being specialized for its particular purpose - harder to fit in my head at one time. The cost of changing the code becomes more severe, each instance of an abstraction in the code being different enough to warrant specialized attention, rather than fixing code in a single place.

In every organization I've worked at, as the size of a code base grows, so does the cost of change. A language that doesn't scale well is only going to exacerbate that problem. Perhaps Go seems great now because we've yet to really see any projects written in it at this scale.

> The reality is, that when OOP is correctly executed

Can you find anyone who agrees on what "correctly executed OOP" is? I don't think there is a consensus on this idea, nor any particularly objective criteria for how to achieve good OOP.

> For example, primitive types are not objects (no, auto-boxing doesn't make them objects).

Does the presence of inline assembler make C++ a machine language? I don't think so. Similarly I don't think the presence of primitives in Java make it less of an OO language. They're a leaky abstraction meant to improve the language's performance, which arguably make the language less ergonomic to use.

Until working at Pivotal I had been working for about 5 years in various non-app industries: transport, signals monitoring, databases etc. Libraries? Not really, we mostly wrote everything ourselves - at one position, even an entire operating system.

Author here, FWIW this article was one of many posts some colleagues and I wrote at Pivotal during a "blog writing tontine" to encourage us all to write more and develop our skills, written hastily and intended to be part of a series I didn't finish before leaving.

My intention was to point readers to some of the good ideas that were emerging (more accurately: had emerged some time ago) from alternative paradigms and how they could be used to make OOP programs better. Agreed that its certainly more about the team than what syntax you use to push bytes around, but tools do matter.

It's unfortunate that such a lovely document seems to have produced a terrible subway system. Having regularly taken the subway in Beijing, London, Washington D.C., Tokyo. The New York subway seems almost deliberately difficult to navigate at times. Subway signs are often misleading. Lacking in places or just outright missing. Perhaps they focused too much on the appearance without considering usability.

New York, Amplify

We're building an Android education platform for K through 12 which includes mobile device management, interactive tools and classroom content. We live and breathe agile development, we test drive, we pair and we continuously deliver. Our technology stack includes Android applications (Java) a rich Coffeescript and AngularJS front end and a service oriented architecture using the Play framework (Java / Scala).

We're growing fast and we're looking for developers with an eye for elegance and simplicity, who appreciate good software design and who want to get involved in solving lots of challenging problems. If you're interested, send me an email: [email protected] or take a look at our careers page: http://amplify.com/careers

"Perhaps, because we always had autoloading as a crutch, our existing knowledge has atrophied – or never even developed – putting us at an even greater disadvantage."

I think the same can be said of any abstraction. The Ruby programming language as an abstraction over C. C as an abstraction over assembler. etc. Yet few people write code in assembler. I don't find this a very compelling argument.

Inspections are mentioned a lot. This is not a word I hear a lot of developers use, so I'm guessing this article is not written by one.

The cost of these has been completely externalized. Does the 85% reduction in defects come from a casual code review? Or are 3 senior developers doing Fagan inspections?

When an inspection reveals bugs, do we take into account the increased time to fix the bug because developers are informed about them after having forgotten some context?

Is static analysis incompatible with pairing?

Where does the 1.5 vs 1.6 defect rate come from? What about the rest of the numbers?

If a pair produces less LoC than someone soloing, couldn't this actually be a good thing? I know that the most productive coders I work with actually tend to delete more lines of code than they introduce.