jhrobert

I wonder what a "JavaScript JIT optimized C dialect" would be? Ie. what are the C mechanisms that are too expensive with today's JIT engines?

  def foo( often int n ):

Once all call sites stop using the dynamic version, one can move on to strict typing (and remove the "often" qualifier), if such is the goal.

Think of it like the old "register" hint in C code (now obsolete).

"SweetExpressions" is probably the best method so far to get rid of excessive parentheses in lisp. See http://readable.sourceforge.net/

I believe the mess with optional parentheses is mainly due to the left/righ associative rule. i.e. I have difficulties to properly group subexpressions.

My style: don't assume reader knows about associativity rules so much, prefer explicit parentheses when ambiguities about interpretation is solved by these associativity rules.

For language designers: maybe parentheses should be mandatory when sufficiently nested?

Humm...

I usually prefer "automatized system testing" where fewer "high level" tests involve a lot of code, preferably in a test environment that is close the actual production environment.

Of course, when a test fails, some more analysis is required to determine what went wrong. But it's usually related to recently modified code, hence easy to spot.

That way I get the benefits of automatized tests without the burden of tons of "micro" tests at the class/method level.

I.e. I suspect that those using 4 or tabs also use long lines.

And long lines are not considered very readable these days...

As a result, my personal conclusion is that two spaces indented code shows a stronger interest in readability.

But I don't have numbers to back this claim and I understand it is contreversial. Maybe the author of this nice tool can add info about long lines?

  var one = 1
  var two = 2

Long and weird enough. Well, too long sometimes. In those cases I revert to my "unix login name" ie jhrobert.

But, for twitter, where size matters, I got @jhr - I guess it must have been a long time ago.

There are a few other dimension to explore beside syntax. Like "are arrays 0 or 1 based?" etc

Apparently the author is now part of the opalang effort. They used to have a slightly weird syntax for their language and later changed that to have it look more like JavaScript. That's a strange move when concise syntaxes à la Ruby or CoffeeScript seem popular.

This great exageration makes no sense.

What would have been usefull is the amount of slaves working for me... full time (versus "involved" as described in their methodology).

Better than "strict" typing, sometimes "hints" about the type would be enough.

ie: "ii often integer" versus "ii" or "ii integer"

From then on, those who favor strict typing would be happy, those who favor dynamic typing would be happy and those who favor "efficiency" (whatever this means) would be happy.

Let's close this silly debate.

Active Listening is somehow ok with kids, with adults it smells manipulative to me. For women, as always, it's a different story (kidding).

When I was in my 2nd year as a CS student, one of the assignment was to reimplement the Unix's M4 preprocessor (a superset of C's preprocessor), based on its manual... It includes an expression evaluator, we were told that tools like lex and yacc would help...

Well... that was 25 years ago.

Yet it is particulary visible in computing. Why is that?

Side note: bullshit in marketing brochure is here to stay.

Another solution would be to include a C compiler in every browser, with some DOM thing binding and a convenient JavaScript bridge.

It will be interesting to see what optimizing interpretors can get, performance wise, when source code uses "performance friendly" features only.