nene

Didn't really work out for me.

I listed my project[1] there, but for some reason it's detected as having 0 issues.

Additionally my project is listed under JavaScript repos, while in reality it's both JavaScript and Ruby project, it just happens to have slightly more JS than Ruby code.

[1] http://www.codetriage.com/senchalabs/jsduck

The same would happen with cars if the drivers didn't care of getting to their destination faster, just enjoying the ride for the ride's sake.

Maybe it's because you can write the latter also with plain grep:

    grep 'silver.*needle' haystack

Now that would take the gray comments a step further by making them completely invisible :)

I can't really see the benefit of hunting the comments from your code with cursor. It definitely would make it even more unlikely that comments aren't updated when code is changed.

Neat, but it's still a very linear narrative, with the addition of having to type in commands to be able to read the next section.

Would have been much better if the review was exposed as an API which you could explore freely. And maybe some embedded silly programming challenges to be able to more effectively read the review. e.g. the example paragraph API could have just .nextChar() and .hasMoreChars() methods, so one would have to write a loop to comfortably read the example.

Opportunities are endless, though the book itself looks interesting.

Just like you can't look at the sun directly - because it's too bright... and Hubble is constructed to mainly look at the faint objects far-far away.

I'm a bit disappointed, that the author didn't built a turing-complete interpreter. Frankly I've seen several of such articles which tell you how to build this kind of deterministic evaluator, but they all seem to stop before loops and branching.

And then there are articles about building compilers which do support loops etc, but the trick is that these constructs are implemented by some other already existing machine.

So I feel like there's some gap in my education. Pointers, anybody?

So what's the big difference of doing it on server side v/s client side? You can get it wrong on both sides.

Especially what's wrong with a templating system? A templating system on server side can help avoid casual escaping bugs by doing automatic escaping of everything by default. Exactly the same thing can be done on client side.

OK, I think I found the quote that is troubling you:

> It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers.

So basically we are talking about the case where users machine has been compromised? In such a case I don't really see how you can be sure of anything - that user is screwed.

At the same time the article suggests multiple ways of encoding the data on client side... I'm a bit puzzled.

Maybe what they really meant was that you shouldn't hope at server side that the client side correctly performed the encoding, like hoping the client will escape you database query arguments... but that's just basic everyday knowledge.

Maybe the author hasn't read it. He only included the ones he had read.

I'm more surprised that under the title "everyone should read" are three Joel Spolsky books.

I've been switching between 2 and 4 spaces through my whole programming career. Even now I'm switching daily between different languages and projects with different amount of indentation. And I for one have noticed no correlation between bugs and amount of indentation. But I might be wrong - I have done no actual measurements.

What I can say though, is that there is a correlation between a lousily indented code and bugs. Consistency is the key in indentation. Reading non-consistently indented code, that's what drives you insane... but two instead of four spaces... hardly.

What struck me most was having multiple-choice answers on a math test... WTF?

You shouldn't be able to just guess the answers one-out-of-four. When I was in school (not in US) there never was such a thing. You simply solve the problem and write an answer, which usually is a simple number.

It's not really automatic interpolation. You have to very explicitly place the variable name inside ${var}. I'm puzzled in how you would think this will happen accidentally, or more accidentally than writing "+var+".

I've used Ruby quite a while and never experienced any problems with the very same construct in there.

I would argue the contrary, that the very reason why HTML took off so fast was that any fool was able to craft a site, and it would work even if it had a few bugs in it. Failure tolerance is a great feature. Especially if you consider it in the context of document authoring - for which HTML was originally designed for - it's better to read a document that has one unclosed <b> tag in it, than to be completely unable to read it because there's a syntax error in markup.

You seem to suggest that money is a better motivator than reputation. Money is a motivator, but it's often the wrong kind of motivator. Money can bring in people who do it just for the money. Especially as the money that any site can pay for it's experts is usually much-much less than the expert earns in its daily job.

I applaud that you have created a site that tries to compensate the effort to its contributors... I just hope that you have managed to tailor the site to avoid the problems that money can bring.

The Wikipedia page doesn't really explain how the language works. The manual is a much better source: http://shakespearelang.sourceforge.net/report/shakespeare/

Care to explain how Linus got it wrong? I've never used Monotone, but searching the web I could't find a single thing in which Monotone was better than Git (although I did find information of the opposite kind).

3. For a limited time? 20 years is pretty much forever in the software industry. So sure you might start to look at alternative ways, but it can be quite hard when the obvious solution is patented. But often the patent attempts to cover the most general idea possible, so your entirely different implementation of the idea might still be infringing the patent.

But the main problem with software patents in particular is that you can never be sure if you're infringing something. You can only hope that you don't.

Do you know anybody who acquires new knowledge by reading patents?

1. Because of the legalese language in which patents are written it's pretty damn hard to even understand what is patented.

2. Even if you understand what the patent is about, it's probably of little help in implementing the thing by yourself, as the patent just describes the general idea.

3. If you indeed understand the idea, you might then come up with an improvement, but there's no benefit for you in publishing it, as the underlying idea is patented, the only one to gain from it is the patent holder.

4. You are encouraged by the system to not read patents, because if you happen to infringe one, your knowledge of the existence of patent can be used against you.

Well... you can do all these things when there's no DRM at all. It's like counting up all the things you can do in a new modern prison, but it's still a prison.

IMHO Github code search totally sucks. It's better than nothing, but it feels like the bare minimum - just a normal fulltext index applied to source code.

- It's not case-sensitive, which sucks for searching code.

- It's unable to search for any punctuation characters (searching for "foo()" is the same as searching for "foo"), which totally sucks for searching source code.

- The search finds lots and lots of duplicates. Even multiple matches in one file are listed as completely separate results.

- You can limit the search to one of the languages in dropdown menu, but if your language of choice doesn't happen to be in there, you're out of luck. For example you can't limit your search only to C header files.

Simply by adding package:github.com to Google Code Search search box one can apply a better tool for code in github, but unfortunately the good times seem to be over soon.

Really sad to see it go...

But the thing is, they are not primitives:

> Although you might expect int and double to be primitive types, they're actually interfaces that extend the num interface. This means that int and double variables are also nums.

My hopes were high, but the more read about it, the more it started to look like Java:

    class Foo implements Comparable Observable Deniable ...

    Collection<E>
    HashMap<K,V>
    HashSet<E>
    LinkedHashMap<K,V>
    List<E>
    Map<K,V>
    Set<E>

    int
    bool
    String
    Object

    square(n) => n + n;
    square(5); // returns 25
    square2(n) { n + n; }
    square2(5); // returns null

I could go just on and on...

Well, in PHP you already have a mandatory '()' at the end of function call - so it's pretty hard to confuse the two.

Additionally if your language has first class functions, it would feel kind of strange if names of some functions started with $ and others without it.

> Remind me to call my wife before I leave work

Might be implemented as:

while (get_location() == work) { sleep(1min); }

go_back_in_time(10min);

trigger_reminder();

And you are assuming that there never will be a need for parallel development?

Further more, having that kind of naming scheme might actually hold you back from doing parallel development - aka using git to its full potential. I regularly make use of branching even in my personal projects. For example starting the development of new experimental feature while still continuing fixing bugs in the master branch.

The larger the commit numbers grow the smaller will be difference between a number 1935 and git hash af23cc. Besides, git provides easy means for referring to the most recent commits using HEAD, HEAD^, HEAD^^ and so on. There's also --since option for going further back in time.

As a result your commits now have two revision numbers: the hash used and maintained by git and the number used and maintained by you. But there's no escaping from hashes. You're forced to use them anyway. So why supplement them with your own revision numbers? That's like having a digital library system and maintaining a perfo-cards archive at parallel.

In short term yes, but if we got rid of patents then Google wouldn't have to spend billion dollars on patents each year. I don't think Google is so short-sighted.

I already have hard time parsing this code. The main problem I see, is that to read the code I have to know every single keywords in the language.

For example I was wondering if "new" is a keyword. If it is, then "new string ()" might be something interesting, otherwise it's just a function call.

Similarly this raises a question of whether I can write the following code:

  if end of line (str)

  if end_of_line (str)

Well, use Whitespace then:

http://en.wikipedia.org/wiki/Whitespace_(programming_languag...

Comparing with === does not perform type coercion, while == does and the rules for type coercion in JavaScript are even more funky than for semicolon insertion.

For me the reason to always use semicolons is the same reason I always use ===. There are just too many rules to remember and I've got more important things to keep in my mind.

It's also good to have your JavaScript look like the JavaScript most other people write. I have practiced many different coding conventions in my life, and I don't really hate none of them, but the thing I do dislike is context-switching between different conventions in different projects. We already have tabs v/s spaces and several other possible differences. It would be nice to exclude the choice for semicolon placement from that list.

I do agree with the author in one point: you should understand how automatic semicolon insertion works. And then make up your mind about it. Don't just blindly follow anybodys advice.