skysight-inc/HackerNews huggingface dataset:
Microsoft's situation is indeed a common business trap but it's more than a conceptual trap. It's a strategic trap. MS has reached a local maximum in it's profit potential. Any change in course would impact it's "golden reputation for solid profits".

A company caught in a local maximum might really be unable to escape the situation, in that the purse holders are simply unwilling to open the purse for investments on a scale necessary to get into a different position. And they have a point.

"You want to take these golden goose eggs and invest in diamond mining? No, we keep the goose eggs, that's what they are there for!"

IE, companies don't exist a priori to grow and grow. A company exists to grow, become profitable and return the profits to the owners hot little hands.

"in the face of windows and Office, NOTHING is worth investing in." - that might indeed be true. And it might the case that the only thing MS really is throw enough money at different project to keep from seeming like the abusive rent-extractor that its market position makes it.
You would really like a GC that has
* Low GC overhead,
* Low GC pause times, and
* Good space efficiency

Unfortunately, you'll have to pick two (any two!)
I've found trying to squeeze my demo down really addictive.

My first version was about 990bytes, my second did the same stuff in 934. I then spent about 6 hours trying to squeeze a blur routine into the last 90 bytes. I've now got everything I want in and I've got 8 bytes to spare.

Of course, now I'm wondering what I can get into those last 8...

I've only just submitted the last verion (with blur) so it's not on yet but the previous one is here:
http://js1k.com/demo/59
Great post, Jon!

Saving Your Brain is a fantastic book by Jeff Victoroff, M.D. He reviewed 14,000 medical research studies to write that book. He's also the Chairman of the Scientific Advisory Board for Nolan Bushnell's new company, Anti-AgingGames.com.

I would add to your list above: not smoking; being within 5-10 lbs of your ideal weight; partnering with a doctor who is both proactive and focused on prevention; getting an annual checkup with tests that can spot if you have Vitamin D, E, B12, calcium, or iron deficiency; maintaining regular social contact with your friends; buying cars with a good safety rating (in one study the chance of getting Alzheimers was 4x higher in people who sustain head injuries after the age of 39; doing activities that are new and mentally engaging (helps keep the brain's plasticity). You said this but I wanted to stress that the activity should be new because that's what helps the most.
Northrop isn't a foreign company and as the party delivering the actual planes, a substantial amount of the money would have gone to them.
I agree with his argument for strong AI. However, I find his argument for its possibility pretty unsatisfying. He basically just says that since humans are incomplete (like any formal system), we should be able to simulate it in hardware or software. I do believe that, but I don't find it very persuasive. What if our minds are such a tangled hierarchy that our own minds can't ever untangle it? I don't think that's true, but I tend to cringe when he expresses such optimism, optimism which is still largely unrealized after 30 years of AI winter.

That said, I absolutely love the book.
I used to use Python for its flexibility during experimentation, interactive prompt (REPL), and conciseness.

Nowadays I use Haskell for the same reasons, and Haskell is as statically typed as they come.

The one single thing that really made dynamic typing obsolete for me was type inference.
I'm surprised by the amount of disagreement with the author. This will probably be voted down, but here are a few reasons I dislike large attachments:

1) I don't trust online email services to store/backup my email and like to back up my own email. These giant attachments make up 99.9% of the storage space and don't compress well. My email backup has increased 20-fold in size since gmail upped their attachment limit.

2) Desktop email clients often start to chug slower when the inbox gets large. Before I've had over 100,000 emails in my Outlook Express inbox since 2003. Sorting by subject, searching, etc. were instantaneous. With these attachments, I have to periodically sort by size and run my attachment cleaner script to scrub them out or Outlook Express will get slower.

Maybe I'm using antiquated technologies but if others want better control of their own email, they might agree too.
Gödel, Escher, Bach is a prog rock concept album: 70s, deeply focused on consciousness, indulgent, holistic/synthetic, great displays of technical virtuosity, three-letter acronym, umlaut. Even if you love it, were changed by it, hear selections from it in your head, you keep it a little on the down low because it is so far from the mainstream notion of cool, acceptable. Occasionally, you find a fellow traveller and you share some guilty passion for its awesomeness, like you would for Rush's Hemispheres or Genesis' Lamb Lays Down... Back at the farm you've got to fall in line, claim allegiance to the essentialist raw power of K&R, the baroque symphonies of Don Knuth, and the chart-topping successes on Tim O'Reilly's Top 40. When you're alone, lounging in your earth chair, you slip on your headphones, crank-up your stereo hi-fi, pop in your GEB 8-track, and you're gone...
Definitely not for the exhaustive quality of the article! My interest is mainly in the resulting discussion that this department of subject matter might generate here.

One of the things about HN, sociologically, that gives it a distinctive flavour is that the people here are mostly technocrats, and, as such, very wont to believe that large-scale, systemic problems facing mankind (resource depletion, peak oil, economic decline, war, hunger, cancer, etc.) are genuinely solvable. There's an inexorable kind of optimism coupled with studious attention to detail that one doesn't see from the more sensational and superficial discursive space surrounding these issues in the world at large.

As a Russian immigrant, I find that this idealistic tendency of Americans (distilled and concentrated here) is simultaneously their biggest asset and their principal liability. Americans are often given to pronouncements of childlike problem-solving optimism about things for which it is all but certifiable that there is no solution, or at any rate, things for which the notion of an identifiable, apprehensible, and discrete solution is not intelligible. Sometimes, it is as if they have an almost ontological inability to understand that not all problems can just be "solved" like that. It leads to a lot of blind alleys, dark holes, and red herrings--in a word, boondoggles.

And yet, to the extent that human progress has triumphed a tremendous amount of obstacles in seemingly improbable ways, this attitude is very necessary to sustain it, psychologically. It underlies much of the American Century
s revolutionary contributions to enhance the quality of life and the basis for hope in the world. In other words, if we are going to fix reality and make it better, this general disposition is utterly prerequisite, even if at times the formulations to which it gives rise are naive, simplistic and facile.

So, it is with that in mind that I read the comments here on such topics with enthusiasm.
Sadly this is a common direct-mail tactic. I get these a few times a year, usually from domain name registrars or for technical magazine subscriptions.

There's a lot in the direct-mail industry that just smells, like the fake handwritten addresses and signatures, or the letters that look like they were written Just For You!, and the general creepiness of the standard direct mail sales letter, with its GRATUITOUS BOLD TEXT scattered throughout, and the fun little 'YES' stickers. Publishers' Clearing House is an excellent compendium of annoying direct-mail tactics.
The same could be sade for outside code, it just needs to be documented properly and be well-designed.
Thanks! These are all great tips.

I actually do have a blog, but you made me notice that I don't have it linked anywhere on my HN bio. I've added blog and github links. Much appreciated!
I like to daydream about a scenario like yours, but by and large it's an exception to the rule, and one that is even most frustrating in light of high education costs.
This is a pretty interesting proposal, and I must say, on first impression I think that implementing a Python-base solution would be a massive improvement to our current state of affairs, to a solution that might be the best 'good enough' solution implementable soon.
They could have held their own against MySpace and Facebook if they'd been focused on solving actual technical problems and adding features people wanted to use, instead of solving theoretical technical problems.

When Friendster finally hired Joyce Park to lead a reimplementation of the site (in PHP instead of Java) there was so much conflict over this inside the company that they fired her immediately after she finished, ostensibly for blogging. Imagine what Friendster could have done if user-focused, practical people like Joyce were honored and listened to, instead of tossed out like trash.

(I know Joyce. I'd even say she's a friend of mine, and I hope she'd agree.)
> The dimension of the configuration space of the juggling pin is six: the minimum number of parameters that specify the position in space is three, and the minimum number of parameters that specify an orientation is also three.

Can somebody explain this? Isn't the number of parameters that specify an orientation two, totaling five?

Pick two atoms in the pin and specify the location of one atom. Now the other atom can only be located on a sphere around the first atom. The sphere is a 2d surface for which you need two parameters.

Another problem is that you can encode two real numbers into one, for example by interleaving digits. So you could specify the entire pin with one real number. What exactly is the problem here and how can you eliminate it? You need to impose more conditions than simply continuity, because you can make a continuous bijection [0,1] <-> [0,1]^2?

I really like the approach of this book. I often don't feel like I understand (or even know what there is to understand) something until I code a program for it. For example you understand collisions if you can write a program that given an initial configuration of polygons at t=0, gives the configuration at later time. If you don't do this then you don't know exactly what you understand. Perhaps you understand collisions of point masses, but not general collisions.
For scalability, not performance exactly.
"you should listen to a bunch of academics, and use Erlang for securities, which will lead to less tricky programs from financial engineers."

The article purports roughly this with sincerity.
Your math is right, but there's more to the story here, specifically to understand why the switching argument is wrong - this is commonly misunderstood, and has more to do with the implied "fairness" of the putting-numbers-in-the-envelope process than the calculation of the odds afterwards.

The super quick version: the number drawing process can't be fair, and that makes those .5/.5 hi/low probabilities wrong in general.

The real impossibility is the idea that we can "pick a random number" such that all numbers are equally probable, with no constraints on the size of that number. If this isn't intuitively obvious, then just try to normalize a uniform probability distribution over the positive real line, you'll see the problem.

In order to select the two amounts, the original problem statement implies that we need to randomly pick A (which we can take as the bigger envelope) in exactly such a way, so basically, the "paradox" is dead-on-arrival, because the true prior distribution that A was picked from must be different - for example, there might be an upper bound, say $100, in which case if we see that our envelope has any number over $50 on it, we are 100% sure that we hold the larger envelope. Otherwise, without some bounds or tapering of the distribution, we can't normalize it, and we can't use it to draw numbers from, so we have no numbers in envelopes to even discuss.

tl;dr version: If you can write me an algorithm that "randomly selects a number" (let's even make it an integer to make it even simpler - of course I mean an Actual Integer, not those short bit sequences that we pretend are integers when we program), such that no integer is more likely to be chosen than any other, then I've got two envelopes that I'd like to show you. :)

On another note, the truly insane might notice that in the same way that we can formally sum series like 1+2+3+... = -1/12 (http://en.wikipedia.org/wiki/1_%2B_2_%2B_3_%2B_4_%2B_%C2%B7%...), and 1+1+1+... = -1/2 (http://en.wikipedia.org/wiki/1_%2B_1_%2B_1_%2B_1_%2B_%C2%B7_...), we might consider the probabilistic analogues of these formulas, and "formally normalize" a PDF that is uniform over the positive integers, with a constant probability of -2 for every integer (whatever that means). Similar things could be tried over the real numbers, though it gets messier because the integral analogues of those formal sums tend to come out to zero (for instance, for any integer n, the integral of x^n from 0 to infinity, in a very specific sense, is zero - perhaps I'll do a layman's post on this phenomenon at some point, it's quite useful in some cases), so normalization doesn't really work out so well.

Of course, probabilities can't be negative under the usual rule set, so all of that would be pointless, wouldn't it? :)
This. If licensing your patent costs more than having each participant in the industry independently recreate the invention, your patent served only as a tax on the industry rather than a contribution.
Your question was:

What are your reasons for choosing a dynamic language?

And my answer was, to get a productivity boost over C. At the time, there was no strongly-typed language that it was feasible to use that offered as much leverage. Now there is, and one of the reasons for that is the new crop of functional type-inferred languages that "play nicely" with existing estates by deploying as compiled code (native, or .NET, or JVM).

Very few people have the luxury of coding in a vacuum. Language choice is very rarely a purely technical one.
I know, right!?
Because you can iterate, and you always have an REPL. Also you can change on the fly function definitions, reevaluate vars, and even more stuff - for example change the classes on the fly for Common Lisp (and I'm sure for others).
http://foodporndaily.com/
I like this site and I'm not even a foodie :)

this line "Build the ingredients you hate functionality" got me thinking...
I suppose a website about social cooking might work, where you get recipes recommended based on previous recipes you tried and liked.

If a person submits a few recipes he tried and liked you can start recommending recipes to him that other users who liked similar recipes liked.

It might even be possible to 'follow' cooks you like etc...
This kind of site would have to be offered for free though, social and market norms don't mix well.

just my 0.02 cents
"Five of the "Best" Worst Comic Villains
Everyone also loves absurdly bad villains because you know the waddling man in the top hat isn’t going to beat Batman but dammit, he’s giving it his all. Isn’t that all that really matters?
You've assumed that statically typed languages are somehow "better" than dynamically typed languages and then asked "Why doesn't everyone use the better languages?" Dynamically typed vs. statically typed is still an open question and is a lot more complicated than "which is better?"

> And on the plus side, you get all the benefits of compiler type checking, better IDE support, and great refactoring support.

Since when? Compile time type checking is only a benefit if you're worried about type errors and in my experience the people that are most concerned with type errors are the proponents of statically typed languages. With respect to IDEs and refactoring support, my experience has been more along the lines of "C# and Java have good IDEs and refactoring tools, everything else not so much." I personally find Scala and Haskell's tool support to be far behind Python's, just for example. Also, Smalltalk has, arguably, far better tools available than any statically typed language (or any other language for that matter).

Nobody has proven that statically typed languages are better than dynamically typed ones, nor that applications built with them are less error pronen. I would argue that the amazingly widespread use of Ruby and Python and the average quality of projects written in those languages is evidence to the contrary.
Totally agree about GEB. But I never understood what I was supposed to get out of Pirsig's Zen and the Art of... I always felt like I was missing something that everyone else connected with. Do you remember what you connected with in it?
As far as I remember, Microsoft moved continued development of Seadragon AJAX from the Live Labs team to the ASP.NET team last year. It's interesting to see Live Labs continuing on the consumer side.
He addressed this by saying that requiring a version would leave you unable to fix bugs when they were found, which could then be exploited.
I suppose that's true, I took computer engineering so a great deal of time was spent understanding the guts of the computer.

Also realistically understand cache organization is pretty handy for optimizing software execution.
to sum it up very quickly

statically typed: is-a, has-a
dynamically typed: is-like-a, has-like-a

Read the introduction from
Dynamic Typing in a Statically Typed Language
http://lucacardelli.name/Papers/Dyn.ps
"Even in a statically typed language there is often the need to deal with data
whose type cannot be determined at compile time"

much more other interesting papers
http://lucacardelli.name/indexPapers.html#Types and Semantics

If you find that today's C# can be more concise, it's simply because since C# 1.0 to C# 4.0 they added a lot of extensions that can make the language more dynamic
(see http://en.wikipedia.org/wiki/C_Sharp_4.0 with the use of 'dynamic').

In comparaison, if you look at the ActionScript language which have its roots based on ECMA-262(ECMAScript), from AS 1.0 to AS 3.0 they evolved the language to make it statically typed, but you still keep dynamic functionalities like the * (any) type or the option to declare a class dynamic and add members to the prototype.

After it can be a long debate to try to prove which one is "better".

For example, combine unit tests and a dynamic language and you don;t really feel you're missing anything with type checking.
Counter example, you can have a statically type checked language that compile and can still throw errors at runtime.
Okay, now that we have established that the Visitor pattern is actually about mapping, as Tim said, we can give an example:

Given nodes of a tree, with data and children.

(defstruct node d c)

We can define a map function:

(defun mapt (n f s k) (when n (funcall f (funcall k n)) (mapc (lambda (n) (mapt n f s k)) (funcall s n))))

The mapt function takes a start node, a function to apply on each node's data, the successor function and a key function that extracts the data from the node.

Then we can call it, printing all node contents:

(mapt #S(NODE :D 1 :C (#S(NODE :D 2 :C NIL) #S(NODE :D 3 :C NIL))) #'print #'node-c #'node-d))

With generic functions we can provide content specific behavior. Here eventually PRINT-OBJECT will do the right thing.

Usually Lisp provides these mapping functions. For example in LispWorks CAPI:MAP-PANE-CHILDREN walks over the sub panes of a pane.

That's what he was talking about, there is no special Visitor pattern implementation, just mapping over the object structure. The mapping function depends on what it is, a tree, a cyclic graph, ...

I found Tim's post not really that painful...
Why does everyone seem to assume/know that these guys actually did send fake invoices? I've not seen any evidence for that.
Memory Models: A Case for Rethinking Parallel Languages and Hardware
This probably uniquely identifies Rob, actually; there probably weren't more than three or four seven-year-olds on the internet in 1990, and the chance that more than one of them was named "Robert" is quite small indeed.
Man cannot understand the perfection and imperfections of his chosen art if he cannot see the value in other arts. Following rules only permits development up to a point in technique and then the student and artist has to learn more and seek further. It makes sense to study other arts as well as those of strategy.

Who has not learned something more about themselves by watching the activities of others? To learn the sword study the guitar. To learn the fist study commerce. To just study the sword will make you narrow-minded and will not permit you to grow outward.

-- Miyamoto Musashi, "A Book of Five Rings"
"if"s in Haskell work exactly like the ternary operators, just as I said. I was using the article's differentiation of "branching" and "microbranching" and stating that I haven't seen the former in functional languages.

The link provided doesn't contradict any of this, actually it does quite the opposite.
I'm excited by the possibility that these languages will make functional programming mainstream. Clojure's another exciting language. But I had to choose, there're only so many hours in the day, and for better or worse, Haskell is where I am focussing my efforts.
>For example, if you know Java, you won't get a lot out of learning Java

Sound advice.
After not seeing what Uno is like on xboxlive, I have no idea what you're saying. Is there a lot of Uno nudity?
> I see no reason to use a language that eliminates run-time types

euh... even if a language is considered dynamically typed and/or using weak types, the language still have types.
Yes, pattern matching fits the bill, thanks.
Your claim that F# or even C# are as concise as a dynamically typed language is the crux of your argument, and is the weakest part of your post.

I haven't worked with F#, but I have read a share of C# code. A non-trivial program is likely to need some methods to respond to many types; in this circumstance C# lets you write many methods, use generics, or (now I believe) use dynamically typed variables. Writing many methods is hard to maintain, and not at all concise. Using generics is theoretically great, but the syntax in C++/C# is just awkward and writing type-agnostic code with generics is nigh unreadable.

In Ruby or Python you have duck-typing, and you can easily be type-agnostic and concise; in fact if you are writing code in one of these languages, you /should/ be both of these things.

Duck typing is fantastic for true object orientation: "If it walks like and duck and it quacks like a duck, we can safely treat it like a duck." This reliance upon support for response to messages instead of reliance upon types is often the key to being concise and readable.

In ruby, for example, I can use object.responds_to?(:method_name) and be assured that the object will support this piece of the interface before I attempt use. This is an elegant solution to keeping code type-agnostic, and it emphasizes the best sort of object oriented methodology.

This is why I love Ruby.
Question: isn't "uses the same programming language" a pretty weak value of "like-minded"?
The article conveniently ignores every other game that does not have the same restrictions on user generated content, and then claims the "death of content freedom." Starcraft 2 is one datapoint.

Where was the article trumpeting the "renewal of content freedom" when Alien Swarm came out?