Hacker Newsnew | comments | show | ask | jobs | submit | jaen's comments login

A low-level safe VM? That exists with PNaCl (Portable Native Client), which of course everybody dislikes as a web technology.

-----


Explicit stack-based interfaces are used for good reason: This allows simple accurate garbage collection (see eg. the Ruby API which requires somewhat error-prone conservative GC, Python which requires refcounts all over the place, or OCaml which requires annotating all local variables in a special block). A custom frame stack is also needed to have coroutines in pure ANSI C (two of the reasons Lua is popular).

-----


I don't believe non-stack based APIs prevent the implementation of the features you just mentioned. You don't necessarily have to expose the underlying stack manipulation routines as your defacto API although it is easier to do so. My gripe with this technique is that it makes it much harder for the compiler to catch errors. Personally, I think it would be better to expose the API as helper functions that compose (and hide) the underlying stack routines.

-----


Does not actually measure the main overhead (especially on mobile) - loading and parsing JavaScript frameworks and templates, therefore not really a valid comparison.

-----


A little more verbose? Lets see, Scala vs Java in a promise-based async server:

Java (real code - this is a mild example, imagine this 8 indents deep):

  return users.verifyAccess(userId, oldPassword).flatMap(
    new Callable1<Promise<DataObject>, UserProfile>() {
      @Override
      public Promise<DataObject> call(UserProfile profile) {
        return replyProfile(profile.setPassword(newPassword));
     }
  });
Scala (translated):

  for {
    profile <- users.verifyAccess(userId, oldPassword)
  } replyProfile(profile.setPassword(newPassword))
(observe how you can actually read the code)

Oh man, I wish we started with Scala (or wrote everything sync)... My conclusion from all of this was that Java makes certain abstractions impractical from a readability standpoint.

-----


The article indicates everyone gave their permission for using their name. Sometimes you stand up for people even though it might harm you personally.

-----


A project similar to the one you described: http://code.google.com/p/hotwire-shell/

-----


Previous discussion about the (awesome) GC: http://news.ycombinator.com/item?id=2022723

-----


Each CUDA "core" is actually a lane in a 16-wide SIMD processor, so it has 20 CPUs in the traditional sense. (Intel CPUs have 4-way SIMD with SSE) Only one "program" (kernel) could run on the older GPUs in parallel, on newer GPUs you can have have all the "CPUs" running different programs, but instruction cache space is quite limited.

-----


You can use ElementTree's iterparse() function (also available for lxml) to do incremental parsing while still having XPath-like functionality available for the elements you like (manually calling the .clear() method to release memory).

http://effbot.org/zone/element-iterparse.htm

-----


Buddhism figured this out a long time ago - instead of "self-discipline" there is "mindfulness", a permanent understanding of what is going on with you and around you. Focusing not on the self but on the truth will avoid many of the faults mentioned in the article. The ego should not be controlled - it should be dissolved.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: