Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:Wow this is the best handwaving I've seen in a (Score 1) 199

without looking at the conditions that the code was written in, it is impossible to make judgements that you are making.

That's the point the bulk of my post is making. Though I would also claim that such judgments as still impossible even if you include the conditions under which the code was written.

Once the system is running, some relationships become clear and reductions are possible.

I couldn't agree more. Yet another reason that arrogant / insecure developers think everyone around them writes nothing but crap code. A friend of mine likes to say "There are no good writers, only good re-writers." That seems to apply to computer programming as well.

I hate these smart/competent tags that people like to put on other people.

Me too. I think it's perfectly ridiculous.

Comment Re:Wow this is the best handwaving I've seen in a (Score 3, Insightful) 199

Competent programmers are a dime a dozen.

Programming is the easiest damn thing in the world. It's so easy that children can and do easily teach themselves!

Sure, some problems are hard. Luckily, you can sometimes avoid them altogether. Go read some of Chuck Moore's work.

Anyhow, how do you judge the quality of a programmer? There's only one way that I know: by the quality of their output. But that can't be right, can it? Some of the most incompetent code I've ever seen has been written by programmers generally considered to be brilliant.

Take a chunk of code known to work correctly. It won't take you long to find one developer to say that it's brilliant, and another to say that it's total garbage. Why? The first developer either doesn't understand it or sees some clever or interesting tricks. The second developer sees it as unnecessarily complicated, the same problem being solvable with a much smaller, faster, and simpler solution.

If you'd rather: Perhaps the code is fine and solves the problem well, but the second developer would have approached the problem differently. Maybe they disliked the use of a specific language feature or technique, choice of brace style, or selected language.

Programmers usually aren't well versed in the humanities and tend to think in absurd black-and-white terms. They constantly mistake completely subjective judgments for objective conclusions. They're also prone to believe absurd myths (mistaking common wisdom for objective fact) and tend to buy in to the latest industry fads. You'll frequently find them defending statements that they obviously don't understand. They've simply never questioned their favorite meme. How could it be anything other than pure fact? Programming is like math, right?

Code quality is highly subjective, obviously. I understand that there are objective metrics like size, speed, and memory use. However, we can only use those to compare two solutions to the same problem! Even then, subjective measures (like readability) will quickly come in to play, which some people will consider to trump this or that objective measure -- particularly when two solutions are close on objective terms.

That absurd black-and-white / right-wrong thinking makes each person think that their subjective opinion is objectively correct, and thus irrefutable. What else can they assume but that they're surrounded by incompetent morons?

Do you know who writes bad code? Everyone. The best developer you know wrote crap code last week. You wrote crap code last week. I wrote crap code last week. Not you, you say? You used the latest set of buzzwords? Remember this: Yesterdays best-practices are today's obvious mistakes. Sometimes they oscillate between bad and good. Pick damn near any topic and dig through both current and old articles and blogs to get a sense of how the common wisdom changed over time. (Nonsense "design patterns" are an easy mark. You'll find lots of back and forth on many of those.)

There are other reasons, of course. A big problem seems to be developers over-complicating problems. Sometimes going so far as to write an interesting problem that solves the problem they've been tasked with as a side-benefit. I replaced an 81k (1700 line) component with an 8k (300 line) component a couple weeks ago. Was the developer of the old component incompetent? Not at all. He just made the problem significantly harder than it was. I'd guess that it was to keep the otherwise dull project interesting -- or because he found the problem space interesting and wanted to explore it.

When I see stuff like this I can't tell if it's arrogance or just insecurity.

Comment Re:But... but (Score 5, Insightful) 442

Locking "Metro" apps to their store was their biggest mistake. You'd think that after Ballmer's "Developers, developers, developers" chant, that they would have known that ahead of time! Imposing artificial barriers like this would have killed them in the early 90's.

Apple gets away with calling that sort of nonsense "good for consumers", sure, but they're a special case.

Comment Re:Misleading crap (Score 1) 121

There's no reason to worry. Computational approaches are all doomed to failure. We can only assume that the researchers are well aware of this well-established fact and that headlines like these are little more than a gag to land some free press.

As for the singularity nuts, well, they might as well be writing about the pending war between the grays and the lizard men in the hollow earth. It's just as silly.

Comment Re:Compatibility? (Score 0) 107

They understand, they just choose to ignore that uncomfortable fact. See, bashing popular languages makes them feel smart and important. Repeating the most common complaints, right or wrong, is easy and they're not likely to get called out if they're wrong. Even if they do, they're very likely to get the "its' a common misconception" response. No big deal.

Finding and articulating actual problems is very difficult -- and they risk real criticism if they're wrong. They know better than to risk their ego!

Comment Re:That's just not a viable option. (Score 1) 407

Then can the browser vendors at least look at the fucked up work arounds they had to do to get jquery to even work and fix them?

The problem is that jQuery is so poorly implemented -- and so badly broken that there no value can be gained from its examination!

It's pretty obvious that Resig et al. don't have a clue. The "work arounds" are "fucked up" because they were written by rank amateurs who *still* don't know what they're doing!

As far consistency between browsers, I agree that things have improved. Even IE. So much so, in fact, that a few polyfills is often more than adequate to take care of the differences between browsers. (Just be careful with them. Some are great, while others are total garbage.)

Read the links I posted and dig around comp.lang.javascript for a little bit. If you're still advocating the use of jQuery after that, I don't know what to tell you!

My view on the matter is anyone who is criticizing Jquery / Dojo / and is suggesting vanilla javascript is completely ignoring the fact that the reason allot of these frameworks exists is the base implementations are horribly, horribly broken and the effects of a piece of javascript can be inconsistent even within the same browser.

But neither jQuery or Dojo actually solved the problem! (Sometimes they'd even make the problem worse...) The myth from years ago was that jQuery took care of all your cross-browser concerns. That was never even a little bit true. jQuery was, and still is, inconsistent across even the few browsers it claims to support. That's to say nothing of it's ever-shifting API!

Things are not nearly as broken as you seem to think they are. The differences between browsers can easily be managed by knowing what features to avoid -- and you don't need to avoid very much at all! Usually a small and simple polyfill or two will take care of any features you need -- even if you need to support antique versions of IE.

Comment Re:That's just not a viable option. (Score 1) 407

Yes, that's correct. Now ask yourself why JavaScript need enter in to it at all? (Are you going to advocate browser detection? You'll find more than enough on comp.lang.javascript about that bad practice!)

I don't know, dynamically change the element's CSS depending on the resolution and orientation?

If that becomes a need, chances are you've already failed. When it makes sense, which is rare, you'll find mobile browsers more than capable thanks to long-standing and broad CSS3 support across the major platforms.

As for the handheld media type, your article is woefully out-of-date. CSS3 Media Queries are far from "non-standard" in case you didn't know. (I should also point out that for mobile devices, in virtually all cases, it's not necessary to change your CSS at all. If you found some bizarre case where that was necessary, using the outdated handheld media type wouldn't make sense anyway!)

And you want to use a heavy-weight JavaScript library to "fill in the gaps" (that likely don't exist) on a subset of antique devices where you might find a minor layout problem? That's insane. I'll take it a step farther and guarantee that you'll find more "gaps" using JavaScript for layout on old mobile devices than you will with CSS.

Anyhow, I'm not going to argue with you about this. It's clearly going to be a huge a waste of my time. Unless your incompetent, you'll figure this out on your own eventually.

Good luck.

Comment Re:That's just not a viable option. (Score 0) 407

Do you actually need to ask? I don't even know where to begin! Do a google search, you'll find much more that I could possibly jam in to a forum post.

(Other users who are not completely floored by the question: feel free to chime in.)

Learn to use CSS. In the context of this discussion, pay particular attention to @media

I wonder if you use tables for layout as well...

Comment Re:That's just not a viable option. (Score 0) 407

I don't think there is a competent programmer alive who does not use libraries.

Read my post again. I'm not arguing against all libraries, just their unnecessary use. In the case of jQuery, jQuery Mobile, and jQuery UI their use is not only unnecessary it's actually harmful -- particularly on mobile.

What if you're developing a website that needs to be responsive for all orientations, both desktop and mobile?

If you're using JavaScript for layout, you've already failed.

Slashdot Top Deals

Your program is sick! Shoot it and put it out of its memory.