procrastitron

I have to wonder why they chose C++ for writing the VM. Since their architecture is based on compiling Javascript, why not just write the compiler in Javascript to begin with?

The most likely reason I can think of is that it makes it easier to interface with the existing WebKit code, but this doesn't seem like a very strong reason to me.

Actually, the page loading is pretty good. The important thing about that is you show a loading icon, so I know to wait a bit.

Some of the slowness seems to be the initial loading, because the responsiveness improves after the first visit. Since the background images seem to mostly be eye-candy, you might want to think about removing them. They also make your first visit to the site more confusing (in my opinion).

I also see some slowness in the hover and zooming, and that seems to stick around so I don't think it is a loading issue. You might want to reconsider the amount of animation that is done by the hovering; I already know where my mouse is, and some of the actions seem to simply highlight that.

I hope this helps, and thanks for putting your stuff up for us to play with.

It's also incredibly slow, though. I think that is what axod was referring to. The UI gets in the way of what actions you want to perform.

This reminded my of the recent post by Paul Graham, where he mentioned enterprise software companies charging excessive rates for horrible software. Is anyone taking advantage of this to compete against SAP?

"They're a necessary workaround to do some stuff in pure functional languages"

This isn't actually true. You can still write imperative programs in a pure FP language. The most obvious way is to write your code in continuation passing style and pass the new state of the world to each continuation; taking the implicit state changes of an imperative language and making them explicit.

The real reason for using monads is that the scheme I just described is inhumanly complicated. Monads are a much more structured way of doing the same thing. Instead of writing these state passing CPS functions, you write functions that build them for you. A consequence of this is that monads perform much the same function as macros in Lisp; they are programs that build programs.

I'm well aware that hacker news is not limited to stories about technology or start ups. However, that is the origin of this site and those are still the topics where it shines.

This discussion, however, is pure fluff. I equate it to the videos of pratfalls and cute animal pictures that the guidelines admonish against.

"this thread shows why I'm so impressed with the YC community"

I was actually thinking the opposite. I come here for news and articles relating to technology start ups, and this thread shows how far off track hacker news has gotten.

Can someone with expertise in concrete construction clear up an issue for me?

I would think this type of construction was not safe because concrete needs some sort of reinforcement to make up for its low tensile strength. The wikipedia page on rebar (http://en.wikipedia.org/wiki/Rebar) seems to support my concerns, so my question is am I missing something?

Is it possible to make up for a lack of steel reinforcement using special concrete mixtures, or is it perhaps unnecessary for small scale construction?

I found this article informative not for the information about the computers but rather for the glimpse at how clueless the analysts were.

It's amazing that someone whose only job is to know an industry inside and out can be so out of touch with its customers.

It's already been done:

http://www.techeblog.com/index.php/tech-gadget/feature-stude...

This part of the article really got to me:

"China was the largest economy for centuries because everyone had the same type of economy - subsistence - and so the country with the most people would be economically biggest. Then the Industrial Revolution sent the West on a more prosperous path. Now the world is returning to a common economy, this time technology- and information-based, so once again population triumphs."

The exuberance for Japan 20 years ago was a bubble, and as such it was based on a lot of irrational assumptions: The Japanese had better business models, more productive workers, better work culture, etc. However, the advocates for China's rise are just counting on one, objective indicator; they outnumber us.

All of Yoko Kanno's stuff is pretty good. I'm really partial to her songs from Cowboy Bebop.

That makes sense. Thanks.

That actually really surprises me. Is this just a limitation of the major implementations, or is there something fundamental about the design that slows it down? (I'm not familiar with the details of the protocol)

I appreciate the use of the tripwires for detecting the modifications, but the article also suggests using them to fight the practice. This is basically a man-in-the-middle attack, so wouldn't using secure http prove a better solution than tripwires? Anyone know why you would prefer to use the tripwires?

The problem (which you are right to point out) is that only top-level defines are dynamically scoped. That's why my first example doesn't return a 3 and why the binding from a nested define statement disappears.

The top-level defines do fit the description of "indefinite scope", since they can be accessed anywhere in the program (even before they are defined). I don't know of anyway to remove a top-level define without shadowing it with another top-level define, so it would seem that they also fit the definition of "dynamic extent".

Nested defines are very strange, so I think it is understandable that they don't quite fit in with either CLTL's definitions or with the classical definition of static scoping.

Well, dynamic scoping does allow a form of destructive update, but define statements are not just an assignment; they also allocate a new memory location. So in my example the two foo's could represent completely different memory locations and it would still work.

Now for your second example; nested define statements do not allocate a top-level memory location. Instead they allocate a local memory location. Consider the following example:

    > (define foo 1)
    > (let ((bar (lambda (n) (+ foo n))))
        (define foo 2)
        (bar 1))
    2
    > foo
    1
    > (let ((bar (lambda (n) (+ foo n))))
        (set! foo 2)
        (bar 1))
    3
    > foo
    2

Here we see that the define and set! methods operated on two different memory locations. When a reference has no matching local declaration, it defaults to looking for a top-level declaration. These top-level declarations are resolved at run time, which is what makes them dynamically scoped.

There's actually a common misconception about Scheme being lexically scoped only. You have to dig very deep into the Scheme literature to find it, but Scheme actually requires both dynamic and lexical scoping of variables depending upon the way they are defined.

Almost all variables in Scheme are lexically scoped, the exceptions are variables created by a "(define ...)" statement. The reason for this (which is spelled out in "The Art of the Interpreter") is to support defining recursive functions.

So, for instance, the following should work in pretty much any Scheme REPL:

    > (define foo 1)
    > (define (bar n) (+ foo n))
    > (bar 2)
    3
    > (define foo 2)
    > (bar 2)
    4

If "(define ...)" statements actually created lexical variables, then both calls to "bar" would return the same result.

I would suggest one of the new sub notebooks that comes with Linux pre-installed. The ultra mobility would make for a better companion to your MacBook than having another full sized notebook. And, as an added bonus, you don't have to worry about driver support.

Personally, I've been pretty pleased with my OLPC XO, but that's mostly because I use it as an ebook reader all the time. If I just wanted a laptop, then I would have gone with the EeePC.

But then how do you explain the popularity of this post? It was completely vacuous, but is still at 13 points as I write this.

I understand that, and appreciate it if it's done well, but it doesn't stand on its own. Trolls are like lies, the best ones have a hint of truth to them. Most of Fake Steve's posts that I have read miss that crucial element.

Hm... you're right. Those are very insightful. Unfortunately, the two examples you came up with are 3 months apart, and fake steve posts new blog entries all the time. My experience has been that every time I see a link to one of his posts, and I read it hoping that this time he'll impress me, I keep being disappointed.

However, I notice that the two posts you point out are much more business related than technology related. Since the real fake steve is a business reporter, perhaps he shines when he's in his element and falls flat when he strays out of it.

Fake Steve is a troll, and a bad one at that. His posts are childish, but that's not the real problem with them. They consistently lack any real insight. Any exposure he receives is just due to his immature writing.

Can we now accept that he only got people's attention using classic trolling techniques and go back to ignoring him?

Indeed, the difference here isn't the capabilities of the language, but rather the quality of support the tool chain offers for the task. None of the tool chains that I know of offer decent support for building operating systems, but the C portion of the gnu tool chain offers the least sucky support for it.

A sign of the flaws in the author's argument is that C++ clearly offers just as much control over the hardware as C. However, an order of magnitude more OSes are written in C than C++. Anyone who's tried to write one in C++ knows why; trying to bend the tool chain to support bare-hardware is a daunting task.

Unless my info is out of date (Checked this a couple years ago), the projectors use something like 2 orders of magnitude more energy. Over the long run this can lead to a significant cost difference.

Why would demand be static? Do you really think that demand for marketing doesn't increase? That would require having only a fixed number of people wanting to sell, and for them to only be willing to sell to a fixed number of customers.

In the mid 90's MTV did a salary survey of moderately successful bands and found that the average yearly salary was about 30k, putting it in the range of an entry level office job. These weren't the biggest names in music, but they were definitely on the high end. This was long before the rise of peer to peer downloads, and even then professional music was not a viable career path. Blaming technology advancements for artists not being able to make a living off of their art is just a scape goat.

The concept of a "starving artist" predates the rise of computers and transcends all media. The only difference between the music industry and painting, sculpting, writing, or any other form of art is that a myth of past profitability has been propagated in recent years. The (unchanged) reality is that artistic expression doesn't generate revenue streams except for the very few, lucky artists.

Interesting. If I were them I'd move to a state that didn't have a state capital gains tax before cashing out. Then again, I guess when you cash out 3.7 billion dollars in a single year, 380 million seems like pocket change.

The market seems to have already agreed that artist exposure is a fair return for online postings.

I don't think the author appreciates how valuable that world-wide, democratic exposure is. The artists may not receive any direct revenue from it, but it can greatly enhance real sources of revenue, like concerts and merchandising.

I think the problems with both readers is a symptom of the respective companies loosing focus on their target markets. These specific products are trying to satisfy too many industries at once. Instead of trying to address publishers, distribution, and customers all at once; these companies should have focused on doing one thing and doing it well.

A simple book reader that just handled pdf files and was priced competitively to books (less than $100), would stand on it's own. However, being priced at >$400 means that these products have to solve many problems at once (availability, distribution, and hardware), and if they don't do all three well, then they will fail.