cliffbean

If you implement a GC which runs on its own thread, doesn't pause the application, and achieves good overall performance on any real-world code, then it would be a terrific thing to mention in your big blog post announcing the system. We'd love to hear anything you'd like to say about it.

If you don't mention it, and if you also say numerous other things which give the impression that you may not have given the entire topic much thought, then even people who would otherwise prefer to be positive and supportive may struggle to take you seriously, and may react with frustration if you also make extraordinary claims.

This blog post is either spectacularly naive, or ridiculously over-hyped, or both.

"Consistent performance. (not like the V8 engine pausing the whole application for GC)"

Static complication doesn't get you out of having to worry about memory management. What's the alternative here? Reference counting? Leaking everything? Using a subset of JS that doesn't allocate anything? All of these things come with considerable costs.

I take issue with the "nobody is forcing you" part. If you want to use Linux, and there are good reasons for it, it will likely be increasingly difficult to avoid systemd. You can argue whether that's "forcing" or just "applying pressure", but it's real.

That said, your other comments resonated with me. I used to fear systemd, and worried that losing the ability to hack on init guts shell scripts meant loosing the power to make my system work for me. I've since discovered that with systemd I don't feel the need to hack on init guts shell scripts like I used to, because it actually manages services intelligently on its own.

On some pointers, for example function return types, restrict is defined to be meaningless. Also, restrict pointers can be copies of other pointers, and copies can be made of restrict pointers, subject to certain rules. So it's more involved than just "nothing aliases the pointer".

Here's another example:

  // C has pretty paltry array support, so it's common for 
  // people to build their own stuff like this:
  struct Array {
    float *data;
    size_t len;
  };

  // But then you use it:
  void foo(Array *a, Array *b) {
     for (i = ...)
       for (j = ...) 
         a->data[i] = b->data[j];
  }

and there's nowhere you can put restrict to declare that the two array references here are independent. The data pointer is one of the contexts where restrict is defined to be meaningless.

If you're a hyperactive squirrel, you might try rewriting all your code everywhere to do stuff like this:

  void foo(Array *a, Array *b) {
     for (i = ...)
       for (j = ...) {
        float *restrict x = a->data;
        float *restrict y = b->data;
        x[i] = y[i];
      }

but then you'll just discover that most compilers ignore restrict in block scopes like this, because the semantics for that are tricky for compilers to deal with, so you still won't win.

Few people actually know Fortran anymore, but in reality, C99's restrict covers only a narrow subset of what Fortran's aliasing rules covered. restrict's numerous limitations substantially reduce its usefulness, which is one reason it's not as common knowledge as one might guess.

I meant the "Why Are There So Many Pythons" blog post that is the topic of this conversation.

Futamura projections are what PyPy is doing, as described in this blog post. PyPy uses the first and second projections. In fact, it's likely that the author is actually familiar with the Futamura projections, but wanted to describe PyPy in more detail instead of relying on jargon.

I think the all-or-nothing attitude is an attempt by many people to play against their own psychology.

For many people, "I'll just do whatever I feel like each day" is problematic, because the moment right before lunch isn't their brain's best time to make that decision. In that moment, the task at hand looms large in their attention, so they are disproportionately tempted to submit to it and keep working. The benefits of taking the break are somewhere out in the future, they're abstract, and even if you intellectually believe in the benefits, it can be easy to discount them, right there, in that moment. The task at hand is right there, right then, very concrete, no discount.

For such people, all-or-nothing is a way for them to make a decision ahead of time, in a moment of less stress and greater foresight, and perhaps commit themselves to it in a way that takes the decision out of their hands in their weaker moments. They may not come out ahead every day, but if the strategy works, they should come out ahead in the long run.

This sentiment, expressed collectively and somewhat unsympathetically, portrays the entire profession as prioritizing job security over true excellence.

> We do?

Yes, we do. We, as in many of us here on HN, do want Firefox OS to win. And by win, we don't mean that other platforms have to lose.

Spare us the lectures about "normal consumers" not caring. We know all that. But we, the technologists, the ones who write apps and web sites, do often care about platforms, and some of us think that mobile platforms arena would be more interesting with a web-based platform in the game. The world is diverse. There is room for a variety of mobile platforms to fill in a variety of spaces.

You're right. Git really isn't crypto, and this news blurb does sound a bit odd. Hopefully this is just a misunderstanding in the reporting. Matching hashes is probably a pretty good sanity check, but it isn't the kind of solid guarantee that a project like OpenSSL needs.

Fortunately, one great thing about decentralized source control systems is that everyone has a copy of everything. Hopefully someone has simply located a repository which hasn't been updated since before the breach, and done some direct comparisons.

Before the Internet arrived, very few people had a big need for it. It makes some things marginally harder, and it's more work to implement, so it makes sense that it got left off.

By the time the Internet generally arrived, and people generally realized what the Internet meant, we had accumulated enough backwards compatibility burden that sweeping architectural changes were difficult.

Because if it's a common pattern, then it's nice to put it in a common library anyway, instead of having everyone write it out by hand. It makes the code cleaner and more efficient. Win win!

Sure they do! Optimizing is more than just low-level efficiency. It's also about using appropriate data structures and algorithms, and using advantageous APIs (like buf_concat here) when they're applicable.

I guess it is at least useful to teach people that performance isn't one dimensional. Most people don't measure performance in MFLOPS, for example.

Relative to the amount of code in the world there are vanishingly few loops which have this kind of 10x speedup just waiting for the right tuning.

I think I get why some people rage against inheritance, but I don't understand one of your remarks here.

Human isa mammal (let's say). Human is a Liskov substitute in any context requiring a mammal. What's the problem here? Is it just the fact that Mammal brings to mind a classification system which happens to be hierarchical, and you're afraid people will become too accustomed to hierarchies?

Oh, I thought I was clearer than I was. I feel zero-based is more natural.

However, I do agree with you that in the vast majority of loops there aren't any interesting index tricks. For this reason, I actually think language constructs like "foreach" and iterators and so on are better than counting from either 0 or 1 in most cases. In high-level languages, use high-level looping constructs, and let the compiler figure out the indices for you :-).

I agree that we're having an educated and civil discussion.

And I agree with the sentiment of using the right tool for the job, in principle.

However, I disagree that we're in full agreement :). I actually do think that there is a choice here that is inherently more natural for the sufficient majority of general-purpose tasks. The main arguments I'm aware of against it are arguments purely from human convention, which I find are not always as "natural" as one might hope.

Read their explanation though:

"For example, the coefficients of a polynomial a0 + a1 x + a2 x2 + . . . + an xn clearly cry out for the zero-offset a[0..n], while a vector of N data points x i , i = 1 . . . N calls for a unit-offset x[1..N]"

The polynomial cries out for zero for a real mathematical reason. Zero really is more natural there. The vector of N data points "calls" for a unit-offset because, um, convention?

Using 0 as a special error value is a kind of a hack though. What you're really doing is returning "either an error or an index", which is a different type than "an index". Empirically, using one language type for two concepts like this, allowing errors to be silently dropped as values can be implicitly converted from one to the other, has been very error prone. See the discussions about nullable pointers for example.

WRT strings with metadata, if you construct your data structure so that the length and other metadata are at negative offsets from the pointer value that gets passed around, then the array data can be at offset zero again, so it's even more efficient. So zero still wins :).

But the arguments for 0-based indexing are also deeper than C arrays. C arrays are just one place where it's clearly visible.

The Pascal approach unfortunately doesn't solve the problem either. "Everyone can do what they like" is fine as long as no one ever has to read or interface with code written by other people.

I agree that it's not at the same level, but there certainly are developments.

It's true that humans hadn't discovered zero until relatively recently in mathematical history. Should we reject these "new" developments in numeracy, and go back to roman numerals? One could make a pretty strong case that roman numerals are more intuitive, more human.

You don't see yourself as evil, so no one should call you evil?

The best new technology in science fiction might be warp drive. However, that's currently thought to be physically impossible.

Fast consumer delivery is merely impractical. It's so impractical, that we often think of it as impossible. But this is where science fiction is at its best: if we think about how cool it would be if this actually worked, we may find it easier to justify the kinds of investment needed to make it practical.

He complains about message-passing being prone to races, when earlier in that same paragraph he complains about the lack of shared memory between tasks? It sounds like he has some legitimate concerns, but this blog post reads more like a rant than a considered criticism.

Ordinarily, unsigned left shift silently shifts bits off the end.

  0xffffffff <<  0 is 0xffffffff
  0xffffffff <<  1 is 0xfffffffe
  ..
  0xffffffff << 30 is 0xc0000000
  0xffffffff << 31 is 0x80000000

It is defined to ignore overflow. Therefore, I claim that there's enough consistency here that we can extend the pattern to this:

  0xffffffff << 32 is 0x00000000

I claim this really is the mathematically correct answer. It's consistent with the most obvious pattern, and there are no other relevant patterns.

C has chosen to call this undefined behavior instead of returning the correct answer here, and I call that choosing optimization over correctness.

PNaCL and asm.js are roughly the same in terms of "exposing" the code in this sense. Both can be easily disassembled/prettified using readily tools readily available today.

We've had other languages running in browsers for quite a while now. eg.:

http://mozakai.blogspot.com/2013/05/lua-in-javascript-runnin...

As a quick reality check, we're talking about boring old URL rewriting here. "Cool new invention mangled by legal paranoia" is a solid story, but other stories would probably fit the circumstances better.

This part is interesting:

> "If better precision, directed roundings, and exception handling capabilities latent in hardware but linguistically inaccessible remain unused, their mathematically provable necessity will not save them from atrophy. The new C9X proposal before ANSI X3J11 is a fragile attempt to insinuate their support into the C and C++ language standards. It deserves the informed consideration of the programmers it tries to serve, not indifference."

And it's now 2013 and directed roundings and exception handling largely remain linguistically inaccessible. C99 did add them, but they remain fragile. And most other languages haven't added them. It seems that the programming community has largely settled on indifference.