51–60 of 131 posts
Google cache for those who hit the "pageview limit exceeded" nonsense: http://www.google.com/url?sa=t&source=web&ct=clnk...
A bad programmer won't understand or take into consideration the limits of the target platform.
A good example is posting an article to a host with limited bandwidth.
Earlier quoted context omitted.
It's fairly ironic--Google is restricting the page views (to limit bandwidth usage), but at that same time they're hosting a copy in cache of that same page, with no limits.
No kidding. That's so moronically un-Google, it's got to be a bug rather than a genuine quota issue. Because otherwise, Google 2009 == GeoCities 1999, and that would be unthinkable.
Empires rise and fall fast on the net. Google is now a mish-mash of offerings which get uneven attention from their internal talent. 'Sites' itself is a successor to the soon-to-be-shuttered Google Page Creator (which unlike Sites allowed custom CSS and JS). A few key people leave, a couple bad quarters -- 'Sites' could get the axe too.
Earlier quoted context omitted.
"It's very sweet for MIT types to make these declarations from mount olympus, but lisp is something that can take time to acquire." Don't worry. In the Valley, people from MIT don't have a good reputation as great programmers. For some reason, their education is a lot of 'theory' and less practice. Apart from Standford\Caltech, Some of the best schools that produce great programmers are your average state school. I h…
While I'm not an MIT student, I think the school puts a huge emphasis on being pragmatic ( see http://news.ycombinator.com/item?id=530659 ). Also, given the huge disparities in abilities of the freshmen there, I'd reckon that, more often than not, an MIT education would be a humbling experience.
I'm skeptical of these lists because people can work through things. For example, the stuff listed under "Inability to determine the order of program execution" is something that many people will get jammed on eary on as they try to take their brains (which is honed on the syntax of school level maths) into the programing world (where equals is an instruction rather than an assumptions). Another one is "Lisp is opaqu…
"It's very sweet for MIT types to make these declarations from mount olympus, but lisp is something that can take time to acquire." Don't worry. In the Valley, people from MIT don't have a good reputation as great programmers. For some reason, their education is a lot of 'theory' and less practice. Apart from Standford\Caltech, Some of the best schools that produce great programmers are your average state school. I h…
While I have great respect for these institutions and the aptitude required to succeed within a difficult program, it's not a guarantee of quality.
The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…
Earlier quoted context omitted.
ouch... I love the 'stop making this so complicated bit'. While some people really don't get it I'm pretty sure that most people could learn how to program with some competence. The only metric I've found to measure programmer competence reliably is how big a project you can manage to complete. Some people get stuck at around 100 lines, others in the thousands or tens of thousands, some can keep their rudder straight…
LOC is a horrible metric for this, given the degree to which morons can get comfortable with copy-paste and IDE-generated boilerplate. Gzip-bytes of source FTW.
Implicit in the notion of completing a project is the certainty that the project manager will change their mind, usually after you have written 95% of it. If you copied & pasted those hundred thousand lines, you will have to change something in at least 100 different places. At that point, you'll give up in despair, proclaim the change impossible, and have the PM cancel the project in a fit of frustration. Thus, not complete.
LOC actually sorta makes sense in this context.
This is one of the best arguments for why anyone should bother to learn Haskell (or likewise language)
The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…
I thought this as well when I was reading it. I think what the article is suggesting, though, is not just that the subroutines would be "reusable" as in useful if called from another part of the program. He's suggesting that the contents of each subroutine should be decoupled from each other - so not sharing global state, depending on strange changes made in other seemingly unrelated methods, etc. The property of "I…
I do agree that you should not (depending on language) write sub of everything. ex int add(int a, int b) {return a+b;} //Junior model
This is spot on: 5. Lisp is opaque to you
I can't learn LISP. I can get reasonable work done in imperative functional/OO languages like Perl, C, Java, etc. and took the time to learn Erlang to get a look at functional programming and I can drop the SQL bomb like nothing else (so I can do declarative too) but every time I've sat down to learn LISP because people say it will make me a better programmer, I've gotten distracted and haven't finished. I don't thin…
I don't think you're a bad programmer-- but if you're making a distinction between "building things people use" and "writing elegant code", prepare to have your mind blown by SICP.
I get worried when I see someone take a mainstream language (C#, Java, Python) and try and twist its idioms into whatever their favorite language is (lisp, the ML family, Perl, etc). Or if someone wants to be on the bleeding edge and use the latest language syntax/library trick. This is a pain because
- Someone new to the codebase may not have as much familiarity with all these nuances of the language. For example, I've seen crazy things done with C++ templates. I don't think there was ever a justifiable reason for doing any of them.
- The esoteric, cutting edge features often have bugs and/or don't have great tool support. Fact of life is that the more some feature gets used, the more the bugs found and fixed. If you're on the bleeding edge, you're going to hit weird language/runtime bugs which you need not have inflicted on everyone.
- Debugging. Often, the only thing you have after a weird bug is a crash dump and caffeine. You want to give yourself all the chances you can of tracking down that issue. Esoteric language features rarely lead themselves to great crash dump debugging. I'm not suggesting writing C code but the closer the mapping from code you write to x86/64 code, the easier it is for you