Live data from Hacker News

Portrait of a Noob

steve-yegge.blogspot.com

31–40 of 43 posts

Re: Portrait of a Noob

#31
post #21

I'm suprised no one mentions this, good code does not need comments, because it clearly speaks with variable names and function names. The Lisp function Yegge gives, is horrible in that aspect. for example this piece of code: (if (or (= tt js2-LB) (= tt js2-LC)) should really be more like (if (matches-js2-line-ending current_token)) No matter "how good you are" code reading is faster if what you read matches with wha…

By leaving out the definition of that long function name you mask the increased cognitive load of your change. If you include the definition of your new function it doesn't look like an improvement anymore.

We've also left out the new code that also has to match things against js2 line endings.

That said, this does require some taste. It is horrible to spread a single logical operation across multiple functions, classes, and files just for the sake of "object orientation" or "self documentation", but judicious application of bottom-up FP really helps code size and readability.

Re: Portrait of a Noob

#32

He's spot-on about Java being a safe-haven for "data modeling" geeks who are afraid of doing real work. Writing a whole bunch of getters and setters in a freshly minted Java class certainly feels like work. However, I think he gets it wrong when he puts OCaml on the extreme "for you to model everything" end of the spectrum: And Haskell, OCaml and their ilk are part of a 45-year-old static-typing movement within acade…

Haskell also uses type inference. It does have a lot of type system stuff, but because of how the language works the types are not just metadata. The types are often just as important as the rest of your code.

Re: Portrait of a Noob

#33
post #23
post #21

I'm suprised no one mentions this, good code does not need comments, because it clearly speaks with variable names and function names. The Lisp function Yegge gives, is horrible in that aspect. for example this piece of code: (if (or (= tt js2-LB) (= tt js2-LC)) should really be more like (if (matches-js2-line-ending current_token)) No matter "how good you are" code reading is faster if what you read matches with wha…

A nice reminder that skill and raw brainpower are two different things, and the latter can retard development of the former. I worked with many pieces of code written by one particular coworker of mine who was way too smart for his own good. His code was littered with little formulae like that, repeated again and again throughout a file, and to him it was obvious at a glance what they meant. It was also easy for him…

1) That's not a multi-dimensional array, that's a one-dimensional array simulating a multi-dimensional array.

2) Why not

    arr[n1 + i][n2 + j][n3 + j] = calc_foo(i,j,k)
? It's a bit more work to write the proxy classes, but a Sufficiently Smart Compiler(TM) can make that all go away for you.

Re: Portrait of a Noob

#34

Yet again, the title of reposts needs to be dated. I was bittersweet hopeful this was one of the final 3 posts he has promised us since May.

Just pointing this out, but if you're that eager for a new post, and you didn't know this is an older post, then the end result you desire has been realized, no?

Re: Portrait of a Noob

#36

Yet again, the title of reposts needs to be dated. I was bittersweet hopeful this was one of the final 3 posts he has promised us since May.

Just pointing this out, but if you're that eager for a new post, and you didn't know this is an older post, then the end result you desire has been realized, no?

you didn't know this is an older post .... until I started reading it. I don't always recognize these posts by their title.

Re: Portrait of a Noob

#37
post #27

Earlier quoted context omitted.

Surely Yegge would tell you that he would rather maintain the concise code with sparse comments. That's the whole point of the post.

But he would be lying. Yegge would rather maintain the concise code with sparse comments if and only if it were Yegge's concise code with sparse comments. If it were someone else's, he'd rather it were in fact rather heavily commented.

To the point where you need to rewrite 10 lines of comments when you change one increment operator? I doubt it.

Re: Portrait of a Noob

#38

I've shared Yegge's disdain for static typing for quite some time. One of the best examples of how awful it can be is type hinting (optional type constraints on parameters) in PHP. Many times I've explained to people why type hints are awful thing deserving banishment to hell — along with Facebook suggestions and Microsoft product recommendations — but so many PHP programmers seem to love them! Now that I read this I…

The difference is, as you say, that the type system in Haskell is a tool that helps you write concise and correct code, whereas the type system in a language like Java (it is hardly the only offender) feels arbitrary and capricious.

I too once thought static typing was nothing more than useless bloat, but then I started using Haskell. Haskell's type classes are actually a useful means of handling abstraction (know something that acts like a monoid? then save yourself some effort and use foldMap). The one thing I did like about Java's class system was interfaces, and Haskell's typeclasses handle that exceptionally well.

Re: Portrait of a Noob

#39

He's spot-on about Java being a safe-haven for "data modeling" geeks who are afraid of doing real work. Writing a whole bunch of getters and setters in a freshly minted Java class certainly feels like work. However, I think he gets it wrong when he puts OCaml on the extreme "for you to model everything" end of the spectrum: And Haskell, OCaml and their ilk are part of a 45-year-old static-typing movement within acade…

OCaml does type checking at compile-time and therefore is statically typed. It often can infer what those types are, but it doesn't wait until runtime to do so.

Re: Portrait of a Noob

#40
post #27

Earlier quoted context omitted.

Surely Yegge would tell you that he would rather maintain the concise code with sparse comments. That's the whole point of the post.

But he would be lying. Yegge would rather maintain the concise code with sparse comments if and only if it were Yegge's concise code with sparse comments. If it were someone else's, he'd rather it were in fact rather heavily commented.

You would be wrong. I have encountered all sorts of code written by others that I have to maintain.

My favorite code has consistently been sparsely commented (though effectively heavily commented with good variable names and appropriate functions) while the absolute worst I've maintained was code that was so heavily commented that it was virtually impossible to see the flow of the program.

Post reply on HN