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.
This is plainly false. The judge is the one who decides if the actions of the government bare relevant. If the judge believes they are, they will be admitted, and parts of the trial will be closed, but other parts will remain open.
I would urge you to do research to confirm your assertion here. What I described is not a fringe view, it's literally a summary of the Criticism section in the Wikipedia entry for the law in question:
No one is saying that civil disobedience should be consequence-less. We’re arguing over the legality of the laws one would be breaking and whether they’re just.
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 view inequality as providing a visceral drive to improve my lot in life. I want the things that the billionaires have, so I'm going to try my darnedest to work smart and hard and get there.
If there were no billionaires to look up to, that's a signal that I can't really improve my life much, so why try hard?
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.
I agree that humans have an innate drive for self-improvement, and adding an economic motivator (and therefore inequality, by definition) helps focus and amplify that drive toward improvements that also efficiently increase quality of life for others. Because of the economic motivator, I want to build things that people are willing to exchange resources for -- if they're not willing to exchange resources, it's honestly hard to argue that the item was ultimately very valuable to them.
As long as there is value to humans in exchanging different types of resources, I fail to see how economic inequality is unavoidable. We can argue over the appropriate degree, but some level of inequality seems fundamental to the nature of our universe.
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.
To me, the idea of inlining functions that are otherwise called only once is complete garbage. Yes, you reduce number of functions in your program but the program doesn't get easier to read, test, develop and maintain as the functions that you leave get longer... I stopped watching when I learned that that's presenter's idea of improving the original program. And it has _nothing_ to do with OOP and its flaws, you could as well "improve" this way well written functional programs... It's just wrong. Inlining functions is something your compiler is supposed to do for the programmer, a programmer is better off breaking his problem into small functions instead.
I thought it was interesting. I've carried a "no long functions" rule in my head for so long it was really challenging to have that questioned.
I get the logic behind why he likes long functions that have the meat of the program in them. I've hit code bases before that have broken out bits of logic into separate functions that are badly named and defined and I ended up hopping around the program trying to work out wtf is going on.
As long as we keep the subroutines nice and tight and well-named they're an aid to understanding the program: I can guess what `writeTextToFile(text,filename)` does, and I'd rather see that in the main logic routine than 50 lines of the code that writes text to files.
I will carry on writing short functions, but it's good to know that I'm doing that for a reason, having challenged it.
It boils down to the fact that it's very easy to have unexpected state dependencies/constraints in those smaller functions, that is non-obvious by just reading them. If they're called when those constraints are not met, it is a bug.
I couldn't agree more. When I read your enormous procedures full of inlined functions, I still have to break it down into discrete, logical chunks in my brain. This is work, and there's a real chance I'll get it wrong. If you do it for me, I'm much more likely to understand your program in the way you intended.
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.
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).
Heh, funny, I actually almost included "southern" before "European" (as the parent did) when writing that, but didn't think the distinction mattered all that much and left it out. I stand corrected.
As for the parent's suggestion or lack of suggestion of his way being "better"... sure, perhaps I'm reading too much into it, but whenever I hear a comment like that in person, it is, without fail, accompanied by a condescending tone. But I suppose it's a bit unfair of me to assume that's the case here as well, given that I don't know the guy and text is terrible at conveying tone.
However, given that you point out that Europeans of all stripes do occasionally get really drunk, that leads me further to believe that when someone mentions drinking as "a typical southern European", it's hard for me to avoid reading some implication that that way is somehow better.
Drinking water only helps relieve one of the causes of a hangover (dehydration).
Sure. That just tends to be the main, and usually only, cause that really affects me, it turns out. I can predict with near 100% accuracy the presence or absence of a hangover (in me) by how much water I've had to drink. I guess the other factors don't affect me quite as much, but everyone's mileage of course varies.
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.
> 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.
Because that says that Finnish-Americans do better than Finnish people in Finland?
>This is a double standard. To have its “great” hardware support, a given release of OS X has to support a few dozen hardware configurations.
Agreed. Linux and Windows, as operating systems, are solving a much different and more difficult problem than OS X is. You can get them to run on a wide variety of hardware relatively easily. By that metric, both Windows and Linux have "better hardware support" than OS X.
The problem is this metric is completely useless to me. When I turn on my machine, I do it in order to get work done. This means I need to be able to go online for project management and responding to emails, I need to be able to call my clients using their preferred VoIP service, I need to run text editors, IDEs, and various virtual machines, interpreters, compilers, and servers, I need to be able to hook into an iPhone or Android phone and load software onto it, I need to be able to quickly and painlessly install libraries, software, and developer tools, I need to be able to edit video and audio, and I need to have the confidence that if I had to learn a new skill or assumed a new responsibility, I'll spend most of my time learning rather than setting my system up.
I care about my system's hardware support as far as it allows me to do these things quickly and painlessly. I've had Linux and Windows machines before and I've done all I've needed to do on them, but I've never accomplished my work as effortlessly as on a Mac. I think that's what geeks mean when they say "better hardware support". They mean "fewer unforeseen setup-related problems". That's a metric I care deeply about.
1) go online for project management and responding to emails
check
2) call my clients using their preferred VoIP service
Skype, GoogleTalk maybe? Go2Meeting crashed like a bi-atch on OSX for me.
3) run text editors, IDEs, and various virtual machines, interpreters, compilers, and servers
complete nonsense if you're insinuating that OSX has better support for the above than Linux (you guys just got a non-archaic JDK for example, curious which compilers you're using, the Ruby "compiler" ;-))
4) hook into an iPhone or Android phone and load software onto it
Can certainly do that with Android; OSX VM for iPhone
5) quickly and painlessly install libraries, software, and developer tools
yum, apt, and so on
6) edit video and audio
Macs are great for artists and musicians; case in point, my dad's had a Mac since the early 90s, he does video editing and audio editing (producer and drummer)
7) if I had to learn a new skill or assumed a new responsibility, I'll spend most of my time learning rather than setting my system up.
I mentioned passive non-learning in regard to the OSX experience in another comment. I'd argue that, on the contrary, Linux users, having an understanding of their system beyond the GUI, are actually better suited toward learning new skills, assuming that skill is systems-based of course; if it involves click-click-clicking things, that's another "skill"
No, they're solving the exact same problem: to provide a good computing experience.
Now, how they go about solving that same problem is radically different. Windows and Linux tries to support as much hardware as possible and be general. OS X tries to limit scope to own MacBook hardware only, and benefit from the advantages of that approach as much as it can (clearly, it has some disadvantages it suffers from too).
I'm not sure it's easy to say which approach is more difficult overall. Linux and Windows approach is clearly much more difficult on the software side. However, OS X has to have is own hardware made by the same company. If Apple falls behind in hardware, OS X is screwed. So there's a lot more importance and difficulty in making sure the hardware is great (if a Dell makes bad hardware, Linux and Windows can be okay as long as any other hardware company makes something good).
Everyone's natural tendency in situations such as this (ones where valid moral principles are in conflict) is to try to look for the easy solution. We want to determine who's right and who's wrong by determining which should take precedence - one's right to privately hold and express (even unwelcome) views, or one's reasonable expectation not to be bombarded with offensive language in a setting where they cannot get away from it. In order to resolve this conflict we try to order, add, and/or refine rules, hoping that we can make a clear distinction between right and wrong that will be accepted by a near consensus. This is an empty exercise and denies the nature of complex matters.
Clearly, the men involved (unknowingly) imposed speech that was deeply offensive and uncomfortable for Adria in a situation where she couldn't get away. She reacted, which she has the right to do, and as a consequence one of the men is paying a price that is obviously too steep. It is clear that the pain caused by Adria's tweet isn't proportional to the harm the initial language caused, so what could have been constructive criticism has spun out of control. So, it's unfair to Adria that she had to hear language she found offensive, but it's also unfair that anyone got fired over a comment that most of us would agree wasn't intended to offend and could've been rectified with a simple apology.
We should acknowledge that no heuristic we can come up with will tell us how to behave in the future in order to avoid this sort of thing. As a person who, embarrassingly, finds toilet humor frequently hilarious and fully supports free speech, I don't see nor want to see it go away. As a rational person I also acknowledge this sort of thing has the potential to offend.
What we should realize is that, if we expect to progress in such matters, we have to let go of the notion that punishment is the tool to move us forward, and engage in conversation instead. The fact that our impulse is so frequently to oversimplify behavior by labeling it "right" or "wrong", seeking to penalize the "wrong" should trouble us. It denies both parties (both the offender and the offended) the opportunity to exhibit empathy, compassion, remorse, and forgiveness, which are at the base of anyone's morality. Thus, the blindness to the complexity of moral dilemmas, and our aversion to the necessary discussions deprive us of our humanity.
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.