Hacker Newsnew | past | comments | ask | show | jobs | submit | nene's commentslogin

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 queue just got backed up. Issues are there now.


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


That assumes that "silver" will appear before "needle", which may not always be the case. `grep needle file | grep silver` gets you lines containing both "silver" and "needle" but not necessarily in that order.


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?


I'm not sure I'd be so quick to say it's not turing complete--the language includes building functions (not first-class functions though), but it might be possible that they can be used to emulate conditionals and branching.

Anyway, I'm pretty sure it wouldn't be that hard to extend the language to add some looping and branching constructs to the language, there's nothing really special there to add, it's just another simple type of construct to evaluate.

In my understanding, loops are implemented at the lowest level with jump instructions, but I've never really done much low-lever programming so maybe someone else can explain that better.


There is no conditional, and without a conditional you can't get a conditional.

However modifying it to support conditionals is easy. Just add a built-in function if(condition, expr1, expr2). Now you can build if's. Since the language already properly supports recursive function calls, now it is possible to implement loops through recursion, and you're off and running.


If you have function application, then you don't truly need a primitive conditional. You can represent Boolean values and conditional functions with the Church encoding [1]. This is how conditionals are represented in, for instance, the lambda calculus.

[1] http://en.wikipedia.org/wiki/Church_encoding#Church_booleans


Good point. But you need to have first class functions for that. This toy language does not. And converting from "this native number equals that native number" to your encoding of "true" is going to be an interesting trick.


> There is no conditional, and without a conditional you can't get a conditional.

A two element array of function pointers (or code addresses) and an operator that turns true/false into 0/1 is enough to do conditionals.


There is a slight snag that arguments to a function are eagerly evaluated. A built-in if function would be more useful as a special form.


All loops and branching logic has to ultimately come down to machine language instructions that your computer chip interprets as conditional, if this do that.

To get an example of what can be done at the lowest level, see http://zsmith.co/intel.html for the instructions that a Pentium chip accepts. In particular look at http://zsmith.co/intel_j.html and http://zsmith.co/intel_l.html#loop.


A classic, "Let's Build a Compiler," by Jack Crenshaw:

http://compilers.iecc.com/crenshaw/

edit: BTW, https://www.coursera.org/course/compilers just started...


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.


This isn't about 2 spaces vs 4 spaces. It's about 2 spaces in a language where blocks are defined only by indentation. That's a HUGE difference.

I have no problem with 2 spaces in C/C++. I have no problems with Pythons use of white-space to define blocks. But the combination is deadly.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: