Misleading title. This has nothing to do with privacy and encryption. Just to quote a couple of recent Pavel Durov's tweets: "To media covering us this week: Telegram channels are public broadcasts. They are the opposite of private chats. Please don't mix the two."... "Our policy is simple: privacy is paramount. Public channels, however, have nothing to do with privacy. ISIS public channels will be blocked."

EU is not a state with a single national mindset and identity - it's a bag of different countries with different fragmented cultures and languages. China has its Baidu and Qzone, and Russia has its Yandex and VK. All this in spite of the obvious lack of Silicon Valley analogs.

the US is a group of states that often times adopt completely different opinions, not sure your first point translates well.

I believe the multi-millionaire publisher Felix Dennis (http://en.wikipedia.org/wiki/Felix_Dennis) in a certain sense would not quite agree...

In his book "How to Get Rich" he related his hint to pioneer PC-magazines publishing to his interest in early PC-games.

This seems to be the case PG wrote recently in his latest essay - when someone is experiencing a new thing purely as a user, not developer, and feeling and thinking about what's still missing that could be useful to others like him.

Well, maybe the way Danny Ocean (George Cloony) manages his team in Ocean's Twelve (the movie) - tight team, clear plan, known desirable end-result, exact subtasks and timing, confidence in the experts' abilities (proven before).. A sense of common purpose, unity, and perhaps friendship helps also.

And having a scriptwriter who can ensure a great outcome for you, that's a definite plus.

There is a book, "Freefall: America, Free Markets, and the Sinking of the World Economy"(2010), by Joseph Stiglitz - an economist of Nobel prize fame and former Chief Economist of the World Bank, who very early saw the coming of the global crisis and was laughed at in 2005-2006 for his opinion, esp. at a then held Davos summit.

In his book he elaborates deeply - but accessibly for "laymen" - what went wrong, how it could be fixed, but against whose interests in US the ideal public policy solution would have been, and so why just a dubious set of half-measures were taken, by whom, and how it might all worsen as situation in the near future.

So far, for the period from 2010 to 2012, what he claims and predicts seems right and rings true to me.

I did not see in the presentation the following code snippet:

"from twisted.internet import protocol, reactor"

Somehow I feel cheated... ;) :P

This is indeed very revealing on the interesting qualities/properties of the engine => "...and so I was watching how this game developed – Houdini sacrificed a pawn, two pawn, three pawns in a queen-less middle game, to end up winning the game in convincing fashion. During the game I wasn't sure at all that what we were seeing was a brilliant game – and not some obscure bugs I’d left in the engine… I don’t think any other engine could have played this game the way Houdini did..."

> During the game I wasn't sure at all that what we were seeing was a brilliant game – and not some obscure bugs I’d left in the engine

That reminds me of an interview I read many years ago with an author of one of the then leading chess engines. They were doing some last minute fiddling before a tournament, and they accidentally introduced a bug that effectively reversed the goal of the game. Their engine wanted to lose.

At first, you would think that this would readily become obvious. You might expect that once it got past the opening book, where it plays by rote, it would start leaving pieces undefended, not capturing enemy pieces that are open.

That is not what happened. Actually, it played well for most of the middle game. The reason is simple--when it evaluated the board in order to formulate a plan to lose, IT ASSUMED THE OPPONENT WAS ALSO TRYING TO LOSE!

To win a game of chess where the goal of both players is to lose, what you are going to have to aim for is a position where you have such a strong position that you can force the opponent into a situation where you can check him, and to get out of check he is forced to checkmate you. In short, you have to completely dominate the opponent in order to ensure you will lose--and this means you have to play a really really good middle game.

Interesting anecdote, but my guess is that your last sentence is an incorrect assessment of what was going on. Chess engines almost all perform a min/max search on the game tree to bounded depth with static evaluation used to evaluate the leaves of the search. My guess is that what was going on is that the really bad moves weren't noticed to be really bad because it assumed the opponent wasn't going to capitalize on the mistake. It seems implausible to me that the engine was somehow able to look ahead to the end game and figure out that the only way to win at misere chess is to be winning going in to the end game.

In my scholastic chess days I used to play a lot of suicide chess between rounds. What continually amazed me is how very few players could grasp the basics of how to play suicide. The nature of suicide chess strategy was too conter-intuitive I guess. I'd be capturing be after piece after piece and they'd get their hopes up only to have them crushed near the end when my superior force proved decisive. To lose at chess, one must first win.

I don't know about the internals of the chess engine you are talking about but it would be interesting to read about it.

Basically most engines are minimax (or proof-number search) and alpha-beta pruning based. I guess that in the game you describe the algorithms are the same but it choses the worst scores instead of the best ones. It's commonly called "suicide chess" and when two suicide-chess AI confronts, there are always strange results.

Big problems - sometimes before even to be formulated and asked - require big fundamental and applicative science research programmes and the respective advancement.

These are not something to be expected from venture capital. They are something resulting from deliberate state scientific and industrial policy, longterm goals, and adequate funding.

Examples from 1950s-1970s: DARPA/USA, and the resp. space and rocketry programmes in the former USSR.

Private capital - be it venture or not - comes later (and this is not a bad thing) when the new technologies are relatively well understood , "tameable", and can be applied to mass human consumers' or corporate needs (perceived or not, new or old) yet to be satisfied.

Private capital doesn't like fundamental scientific research risks - even in the pharmacy industry. It tries to bear mostly the market-related and implementational risks.

A thought experiment: Think on what funds and in what conditions happened the development of packet switching, TCP/IP protocols suite, HTTP, (examples of fundamental breakthrough). Then think the same about Facebook, for example.

My point summarized => States/Governments shouldn't worry about entrepreneurship programmes, clusters, tech-business climat, etc.

If adequate funding is provided for breakthrough scientific research and to the universities in general (so there are also the high-quality scientists to do it), breakthrough technology business solving big problems will happen inevitably.

On the pharmaceutical industry: part of the problem is the government and the enormous number of regulations and necessary steps to bring a drug (which still could harm people regardless of how many trials are done) to market. As such, while someone may want to research some new but unproven idea, the time and cost and risk involved would be far too great as a result of regulations.

I do agree with your point though. The government should invest in research, not companies.

The title of the submission is a bit misleading.

PG explicitly states in the essay that it's not that much on Java itself but rather on the way hackers judge technologies (the "hacker radar" in his expression).

And these are not quite predictions but statements on how Java is (or was then back in 2001) perceived.

And I think, IMHO, a substantial part of the Java success today should be attributed to the JVM, not so much to Java, the language. Clojure/Scala/etc. are kind of clues for this.

No hard numbers, but I'm sure most Java implementations are still running Java the language. IMHO Java's success today is more because of corporate inertia than anything else. Kinda like how COBOL still has users in this day and age.

It also helps that it's one of the languages being taught in CS classes.

I work in a very large company that has primarily Java for web apps and back end processes in COBOL/Mainframe environments. I've been steering things towards Groovy or Ruby for new projects, largely using productivity as the justification. Top push backs from upper management have been: 1) Universities we recruit from teach Java & most prospective employees already know Java 2) Costs of retraining workforce 3) They don't understand those langs can be utilized with our current JVM ecosystem

I feel pretty much all those reasons are specious and really shouldn't be holding things back. We've got a foothold established with success of some smaller projects using Groovy and Ruby to "prove" their viability. I'd like to try Scala next to see how it would fit for some of our other projects.

TLDR: At least one large company is making efforts to evolve beyond just Java in the JVM.

"IMHO Java's success today is more because of corporate inertia than anything else."

I don't think so. Java as a platform is a lot easier to manage than most other platforms, including Ruby and Python. Jars, in my experience, are much easier to deal with than Gems. Java has a set of advantages that aren't really replicated elsewhere. It's garbage collected and portable, but executes much faster than other garbage collected and portable languages.