babarock

The way I look at it the problem is a bit more subtle than that. In the interest of full disclosure, I'm not a US-citizen either.

Recent technology is making several business models (of which the RIAA is a great example) obsolete. These businesses are powerful enough not to die the way the typewriter or the analog photo film did. These laws (like the DMCA) are a cry for help, a last resort from a dying industry. This is why their side of the argument has always appealed to emotions and not reason. ("How would the world be without movies?" - a complete straw man).

I don't believe it's a conspiracy to make the rich even richer, it has more to do with the difficulty of renewing oneself when technology makes you obsolete. The problem is that a few (or more) innocent casualties are going to get hurt as the Hollywood Titanic (yay, a metaphor!) goes down, but ultimately this whole "technological protection measures" shenanigan is going to disappear. Hollywood is doomed and it knows it.

That being said, I think the US is ahead of other countries when it comes to finding a solution to this problem. The effects of the SOPA/PIPA protests had on Congress is the obvious example, but more broadly, the constant ongoing debate looks promising. This debate is always avoided or dismissed as nonesense in France (where I currently live) and it cannot possibly be held in the Middle East (where I'm from).

I just wished the judiciary system wasn't so harsh on the scapegoats of this whole mess. Because let's face it, the victims (again, obvious one is Schwartz, but there are many others) are scapegoats and everybody knows it.

And maybe, just maybe, programming is more than "typical crud apps". A recurring bias here on HN is to believe that all programmers are web devs, stacking simple business logic on top of a database.

What you call "many (or even most) projects" is alien to a lot of programmers.

Keep in mind that functional isn't better or worse than OOP. What you see on HN is merely a reaction to the trend in the past decade (a trend still going on today) to teach OOP as the only de facto paradigm to use.

If Functional Programming was mainstream, everyone here would be raving about OOP and its benefits.

Ultimately what you want is to borrow the good ideas of different paradigms to create elegant and practical code.

I completely agree that age-based classes is stupid. But what's the alternative?

The idea of classifying 5 year old kids based on any kind of factor scares the hell out of me.

I'm a programmer, albeit not a game one. I have an honest question: How difficult is it to write a game whose source code is portable?

I understand that Carmack and Id work on the kind of game which needs very strong optimizations, and I can imagine they need OS-specific system calls or to manipulate the hardware immediately. Porting a game like Quake to Linux is obviously a lot of work, and the reward seems low compared to the investment.

However, I doubt most game programmers need the same level of optimization. Is it that difficult for them to write their code once and compile it separately for each platform?

For what it's worth, it won't work on my Linux Debian box either...

Again bad example, Iran is not an Arab country. They don't speak the same language, they don't share the same culture, they consider themselves the descendants of the Persian Empire, not the Caliphate (the big Arab Empire a few hundred years ago).

Also, I'm not sure I get your last sentence either. An awful lot of revolutions in the world (Arab and otherwise) have been fueled by religion. Even in the US, religion might not have been a motivation for the War of Independance, but it had a major impact on the relationship between government and religion.

Arabs also know how to do revolutions without involving religion:

- Lebanon went through something extremely similar to the Arab Spring back in 2005. The revolution against the oppressors of the time succeeded by putting religion aside and having most parties unite. (Lebanon is a segregated mosaic of approximately 17 religions, each having more or less political power).

- Syrian resistance (or rebels, depending on your point of view) are not, despite what the media is telling you, an Islamist resistance. The leaders of the resistance have clearly repeated over and over again that they're not after the minorities, they're not trying to put Islam forward, they're simply against the Assad regime.

I'm confused... What's the relationship between Arabs and Pakistan/Afghanistan?

There's a difference between being Arab and being Muslim. The greatest Muslim countries are not Arab (Indonesia, Turkey, Iran, Pakistan).

"Islamic unification" is by definition the opposite of "nationalist movements", and is very unlikely to happen. I can guarantee that Saudis, Pakistanis, Morrocans and Turks have way too little in common to even consider unification.

Source: I'm a non-Muslim from the Middle East.

Very good points!

>> it does not see a line between NGOs, the NYT/WSJ, and the US government.

Aren't we all doing the same mistake when we refer to them? All we know is that the attacks came from China, so we safely assume it came from the Government? Why is it that each time something comes from China (a country with approximately 5 time more people than the US - source Wikipedia) we blame their government and treat it as a declaration of war (or, with less exaggeration, a political move)? Is it possible that this enormous gigantic human honeycomb has, say, organizations, corporations, competitors, God-knows-what-which-isn't-their-government?

The western media have created this weird image of China and ... something doesn't add up. I've never been there and I hope I'll get the chance some day, but I can't help but feel that "someone" (feel free to replace this word with the antagonists of your favorite conspiracy theory) is trying to shove down our throat that China is a menace.

That being said, I agree with your analysis. The Chinese government has seen what happened in the Arab world and it knows that the US constantly needs an enemy. It probably does feel threatened.

I've been using apt-get on this laptop for 2 years. If I start running aptitude, what should I know?

I work in the IT department of a major European investment bank. I can assure you that they're willing to pay high salaries to hire experts in said old technologies.

Mainframes are still in use, COBOL devs are in very high demand and finding experts in technologies as young as CORBA is becoming more and more difficult.

Never understimate the cash power of big financial institutions with old legacy systems.

I'd even argue that the best time to deploy is during the best engineers' working hours. At least you guarantee they're around when/if things go bad.

And by "best", I don't mean all stars (a la Fitzpatrick, Norvig, Pike or other Google celebs), but the engineer who actually followed the whole project/patch from dev environment to production.

I don't disagree with you but there's a fine limit between asking questions and asking to be hand held.

And it also works the other way around: I cannot stand when a member of the team is too afraid/shy/... to say "I don't understand". (I'm not blaming the team mate as much as the work environment. Nevertheless it's still a very real problem).

When I get out of a meeting with coworkers and they said they understood (or implied it by not asking questions or saying "I don't understand") I really need to trust they do, or else major problems lie ahead.

I don't like the way `find` is being criticized, both in the article and in your comment. I won't go into pointless bickering on why it's a wonderful tool and "my stuff is better than yours". Let's keep using the tool we're each comfortable with. But do I really need to point out that, once you go through the initial learning curve, `find` is probably (one of the, if not) the most powerful tool in the Unix toolbox? If Unix's shell power comes from piping commands for streams to flow through, I find that in the vast majority of the cases `find` is the best way to initiate this stream.

And the reason is that it's reliable (unlike `ls`) and isn't wasteful (unlike the most-misused-tool-of-all `cat`). I don't understand why similarly newbie-unfriendly tools (like `sed` or `awk` for instance) never get as much heat as `find` does from people unfamiliar with it. Is it because the name implies that it should be a simple tool?

As for what's wrong with the `ls ... | grep -v ...`. It can break in so many ways like for instance, if a filename contains a newline character. If you think that never happens, you're making the same mistake me and a thousand of newcomers before me made once and never repeated again.

As a rule of thumb, never parse the output of ls (http://mywiki.wooledge.org/ParsingLs).

I was a Vim exclusive for several years before shifting cold turkey to emacs on the 01/01/2012 (first new year resolution I keep in my life!). My impression is still the same as day one: I will never reach the same raw speeds in emacs as I used to (and still do) in Vim, but I've never had as much fun exploring the inner workings of any system as I have with emacs.

The functions described in the article are crucial. You should rewire your brain to type them every time you ask yourself a question.

Generally speaking, Unix is very good at self documenting. Whether it's text editors (vim/emacs), shells (bash, zsh, ksh) or just plain man pages (did I mention the info pages for GNU tools?), the systems are great at holding their own full documentations.

I cannot recommend enough adopting the reflex of checking the local documentation before opening your web browser and hitting Google.

I agree with you that it's poorly worded, however keep in mind that they're giving red flags. The way I understand it they mean "clues that the speaker might be engaging in pseudo-science" and not a definitive arbitrary rejection.

Experience can teach you certain things, even if not 100% politically correct. What they're doing is simply passing on their experience to other TEDx organizers.

I highly recommend "Hackers: Heroes of the Computer Revolution" by Steven Levy

Thank you for the explanation.

Am I the only one who thinks that SSD are useless since most of the time the processing will be bottlenecked by the network overhead?

Does everything have to be about mainstream audience? I don't know if DDG's goal is to take over Google's market share, but I can say that, as a (wannabe) hacker, I've been using it as my default search engine for the past year or so.

What seduced me was the reasons stated by my grandparent comment (and the fact that good ol' Google search is a "!g" away).

Not everything has to please the mainstream. Discussing whether DuckDuckGo is a good name is one thing. But to questions the features of the engine on account that it's not "mainstream" misses the point. I think.

Because you trusted the wrong people, and this has consequences.

The customer has to suffer from the mistakes of the companies so that:

1. She stops trusting any company blindly with her data.

2. The market demands improvements from the service providers (and no, sacrificing a scapegoat in court is not an "improvement").

3. Service companies react. Unless there's a major scandal, companies are slow to react to vulnerabilities.

About that last point, it's a bit unfair to assume that the activist tried to contact AT&T and they didn't react. I honestly don't know if that's what happened in this case, and I hope it is. However there are several cases of companies "turning a blind eye" on the issue.

As a customer, the only entity to blame when such a breach occur, is the provider that you entrusted with your data. Not the activists (regardless of their intents) nor the hackers or whatever monster you heard about in the media.

If I entrust (and pay) someone with my bike and it gets stolen on his watch, who's to blame? The thief or the guardian?

I noticed something weird in the programming community: We all seem to want really hard to believe that programming is easy.

I know I got definitely caught up in this whole idea, and attempted to teach programming to everyone around me (girlfriend, sister, dad, coworker). Of course that didn't go very long, because, let's face it programming is difficult. It hit me recently that I've been obsessing about programming and practicing like a maniac every day for years now, and I still suck. Something easy shouldn't take this much effort to learn, right?

Dijkstra wrote in "How do we tell truth that might hurt?" (EWD 498) that "Programming is one of the most difficult branches of applied mathematics". Regardless of whether he's wrong or right in 2012, I have one question: Why is it a truth that hurts?

There are two things I can think of:

1. Static typing can help in reducing the function name.

2. Programming Languages give us means of combinations and abstractions in order to avoid that exact problem.

For example:

class RMG_Serialize inherits Serializor:

    router_msg_header rmg

    xml_utf8 utf8() {
        ...
        super(this.rmg)
        ...
    }

}

The example is not perfect, the function is not exactly globally visible, but I could argue that instanciation of the class is available globally. Or you could get by, by making it static. Also, it's true that I'm adding more characters than any other function name, but no single word I wrote has more than 13 character keeping it easy to read. Every subsequent call to this function will be nothing more than `RMG_Serialize().utf8()`.

Imho, if you feel you're forced to give this kind of name to your variables, there's something wrong either with the design or with the specs.

The choice of programming language counts as well. I mentioned static typing as the obvious example, but isn't a language nothing more than a framework to name your variables?

But I agree with you that maintaining your names short is difficult. I think this has less to do with technical limitations and more to do with project management issues. Generally, I think that a team that understands the value of refactoring (and manage to afford it) will always be better at avoiding this crippling problem.

I may be going out on a limb here, but I don't think he's actually suggesting using `reduce(operator.add, ...)` instead of `sum()`. He argues himself a few slides later that short functions are always better than long ones. If you look at the title of the slides, I think he's simply presenting what FP is: a chain of maps, filters and folds.

It's true that Python will use a list comprehension or a generator expression where you would normally do this, but Python 3 still includes map() and filter(). (Despite Guido not being a big fan of these functions - http://www.artima.com/weblogs/viewpost.jsp?thread=98196).

My point is simply that the presentation does a good job at exposing what FP is and how to implement it in Python. Moving from maps to comprehensions comes naturally, once you get the hang of the idea.

PS: I have the same question about functools.partial. Can somebody answer this?

What? No! He's not pushing for a move to the cloud. He actually did criticize the way we're building the cloud today:

> "This is 2012 and we're still stitching together little microcomputers with HTTPS and ssh and calling it revolutionary. I sorely miss the unified system view of the world we had at Bell Labs, and the way things are going that seems unlikely to come back any time soon."

To understand what he's talking about, keep in mind that Pike was a lead engineer on Plan9, a project aiming at creating the exact environment he's describing. And although the project never left the lab, it did affect the lives of the scientists working there. There are many reasons why Plan9 never went mainstream, but one thing is sure it was not technical inferiority.

I don't think Pike is pushing for any agenda. I tried Plan9, and I see what he's talking about. Lack of widespread support and the relatively small number of available apps make it difficult to be the "primary" OS I use, but the design concepts like "everything is a file", union mounts or 9P are amazing and work like he describes.

When a world renown OS scientist is asked about his "ideal setup", what answer would you expect? "I wish I could get the latest version of MacOSX and the newest chip by Nvidia"??

It's a matter of muscle memory. I used Vim exclusively for several years, and used vi-mode on my shells. Now that I've switched to emacs, my fingers are more comfortable using Ctrl-<key> for commands.

And who says it's a problem? I only say it's, in my opinion, a subtle obstacle to developing a truely startup-friendly environment.

Is society better off that way? probably. I actually like it here. But it's also probably one of the reasons why HN spent all morning debating the state of startup-land in France.

Unfortunately, that's not what the corporate filter I'm stuck behind says.

I agree with what you say, but it doesn't really contradict what I'm saying:

- the "wanting to be rich" is a bit of a cliche, but it's still a major social taboo. As a foreigner who came to France, that was a major culture shock. True, people want to be rich, but politicians don't say it out loud. From what I see, much more efforts are put into helping poor people become middle class, than helping middle class become rich.

- I agree with you on the taxes thing. After all, I'm living here by my own will and I like these social securities. Nevertheless, while it may work out well on the personal level, it doesn't encourage people to start companies. It's great that my kids' schooling is afforded by the government, but these high corporate taxes are still heavy on entrepreneurs.

- I completely agree with the bias towards being a manager at a big company. Point in case, I work for a major investment bank. It's also true that failure is not easily accepted here. I know relatively few entrepreneurs (I'd say less than 5% of my graduating class 2 years ago) and those who "failed" (whatever that means) are having a hard time going back to the "regular" corporate path.

I live in France, I work in the IT sector. I can completely agree with what you say.

From my point of view here are the biggest problems entrepreneurs have to face here:

- French labor law gives much more power to the employee over the business owner. 35 hours weeks may not be applicable for IT employees, but there are high compensations. Where I work, a 50 hour week is considered "way too much". We get 35 days of paid vacation per year, my manager gets 50, I'm not even counting the myriad of public holidays. Everything from parenting leaves, to medical leaves can last weeks and cost a ton to the employwer. Did I mention that once the "trial" period (usually 3 months renewable once) is over, there are no cheap ways to fire an employee unless she screws up big time? This may all seem nice and righteous, but it's not very motivating to start your own company.

- Taxes are so high it's not even funny. For every euro I earn, my employer has to pay a euro in social charges, and this isn't counting the exhorbitant taxes you pay on top of it. It's true that startups do get a grace period of 3 years, but from experience (and talking to other entrepreneurs), this is barely enough. The sickest part is that there's a market developed here where expert accountants teach young entrepreneurs how to "game" the system to minimize "tax-damage". I was shocked when I first discovered this. Until I found out how high taxes are.

- Finally, and this one is the most powerful and less obvious one, there's a strong social taboo in France about being rich or even wanting to be. One thing that drives most startups I've encountered, is the drive to become insanely rich. In the US, or at least that's the impression I got there, there's no shame related to wealth. In France it is completely different. Having money, or desiring it, is bad. The rich are the "enemy" (look at recent taxation laws by our government) and the rest of us would be content with very little. Of course this is a bad generalization, but this point of view is prevalent. And this is why, I believe, the proper environment for startups is not a priority for most French people out there.