lyudmil

Ah, but that's the issue. As currently constructed, the espionage act cannot be challenged in court.

Assange would want to argue that he isn't a spy, but a whistleblower. The argument would be that he willingly broke a law in order to expose more illegal behavior by the government. In order to make that argument, he has to be allowed to talk about what the government does.

Under the espionage act, though, the government can say that the details of their activities are classified, and therefore are not admissable evidence in a public trial. Therefore, their guilt cannot be proven because any claim of illegal behavior could not be backed by evidence.

It's perfectly okay to use inequality as a personal motivator like you do, but it doesn't follow that inequality is a good thing. What you may find gives you drive might crush others, who would otherwise lead a fulfilling life in which they grow into their innate talents and enrich the life of the people they interact with.

I personally strongly disagree that one wouldn't try to improve one's life unless forced to by difficult circumstances. I think we have sufficient evidence that humans are innately curious and creative, and find self-fulfillment in pursuing their curiosity, discovering new things, and otherwise "improving."

It's actually fascinating to me that you have the view of human nature that you do. I don't think this is the right thread to discuss this, but in general I'm very eager to explore that further.

Would you still view inequality as efficiency if you were the one whose work is deemed less valuable? It's strikes me as a very easy statement to make when you can afford not to live like the people depicted.

Efficiency is about producing more of what you like, while keeping as much of the stuff you like that has already been produced. Whenever it's brought up like you have done, it's always an ideological point to some extent, because "what we like" is not well-defined. If I define inequality as a "bad," and capital as "not necessarily a good," then an exchange of inequality for capital is not efficient.

I agree with you completely and I think this cannot be controversial. If we cannot agree that sort(my_list) is better than its inlined function, our profession truly is at square one.

The interesting part of this is that although you kind of know that positions with as little nuance as Brian's have to be wrong (because the world isn't simple), it's still important to think about why you hold your own positions instead of dismissing any challenge to them outright. I think it's good to think about why we use objects and whether we need to do it as much.

What we especially lack in programming is any evidence for our practices. The best we currently have is opinion and experience. That means a lot, but not as much as empirical evidence, and I think we tend to forget that too often.

This is a stimulating argument to think about.

One possible counter-argument is that the resulting procedural code is more difficult to unit test. In the video Brian acknowledges that he doesn't think much about cyclomatic complexity, but I think if you were to try to test one of these long functions with a lot of branches, the setup required for each case you want to test would dominate the amount of code devoted to the actual test. The solution to this isn't necessarily OOP, but I would not want to maintain Brian's code as it stands without refactoring it.

The more fundamental problem to me is that Brian's code requires you to read it fully in order to understand it. No part of the code is difficult to understand, but it demands that I understand it in detail before I can have a summary of it in my head. I prefer for code to read more like a newspaper article, where the further down you read, the more detail you're given, but you can stop at any point and have a decent understanding of what's going on. To me this makes it easier to reason about the system as a collection of sub-systems, which is often the level at which the really important decisions are made. Again, OOP isn't the only "solution" for this, but I think it's a good tool. It does have the potential, as Brian points out in one of his earlier videos, of devolving into philosophical exercises, but I don't think that's necessarily a drawback if your goal is to make it easier for humans to comprehend your system. In designing your system this way, you're simply taking advantage of people's natural ability to think in abstractions.

No, but in societies with more freedom like the US and the UK there generally tends to be more propaganda, because in those societies the government can't use force to coerce the population. They need people to agree with the official line, so they have to use the media to print stories like the Sunday Times'.

In general I think there is a case to be made for "slow" programming, but this article falls short for me. I happen to think that software development is a knowable discipline, that we're in the process of figuring out how to build the kinds of systems we need and struggling with a new kind of engineering where there are no physical constraints.

Therefore, I think we have a lot of exploring to do in order to come up with practices that reliably lead to better software and certainly the speed of the development process and the number of iterations is an important thing to experiment with.

However, the post is too wishy-washy to teach anything meaningful. What does "dot my i's and cross my t's" mean in the context of software development? What does "something like implementation-ready code" mean and why is it useful? How do I, as a person separate from the OP, get from where I am today as a developer to the super effective zen-master you're telling me I could be? I'd love to read that post, because the one I just read makes it seem like I should wait to get older and take up gardening.

I don't pretend to know the answer to this, but I can share when I've been tempted to do such things in Java.

You know how fairly often when writing OO code you want to have an object that takes a bunch of optional inputs in its constructor? That's trivial in Ruby because you can just stick those in a hash, merge the defaults with that hash and you have your options. In Java that won't work because you don't have syntactic sugar for default arguments and the syntax for creating maps is... complex. So you naturally think you need one place to handle all of the complexity of constructing the object and then you think of the factory pattern and you apply it.

Imagine, though, that some of the objects you use in order to construct the object you now have a factory for also become similarly difficult to construct. You don't want your existing factory to know about the complexity of how to construct those, so one idea would naturally be to offload their construction to something else, which passes them into your original factory. It's not a huge leap to then figure out you can put this in another factory and now you have a factory of factories. Repeat.

I'm sure there are other reasons why, but for me that's the most common one. When I used to write a lot of Java, I used to often have to resist the temptation to do that.

I hope what I wrote makes at least a little bit of sense...

I think the OP saw a lack of nuance in the argument and explaining was speculating about where that comes from. I don't think anyone suggested that the European way is better. In fact, your reading of the OP's argument is very "American" because you talk about "European" as if it's a thing. Drinking culture in Southern Europe is very different from drinking culture in Central Europe. Eastern Europe is another thing altogether. Hell, even the way Spaniards drink is vastly different from the way Italians do. Also, in general Europeans get really drunk occasionally, just like you do, so even if there was a "European" way of drinking it would include your behavior.

Basically, I think you're reading into it too much. I don't think the OP implied what you think he or she did.

>> I have noticed that, as I get older, I need to hydrate more and more to avoid a headache afterward. Annoying.

Drinking water only helps relieve one of the causes of a hangover (dehydration). There are many many others, so it may not be the amount of water you need to change, but your choice of drinks (clear, distilled beverages generally contain less congeners, which are one of the main causes of hangovers).

Why would comparing those two scores make any sense? The US has a good education system if you compare it to the world average. It's no surprise that people in that system would do better than wherever their ancestors are from because the US is virtually guaranteed to outperform a randomly chosen place in the world.