Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:This should not be on the front page (Score 4, Interesting) 241

by dgatwood (#49178521) Attached to: Study: Refactoring Doesn't Improve Code Quality

About 5600 lines. However, because it was a glorified case statement, you were really only debugging a single case at a time, each of which was about the length of a sane function, so splitting it into functions would do little to improve readability. I like to trot out that example to terrify people, but the function itself was really quite sane and easy to maintain.

You did, however, have to fully understand the state machine as a whole, which in total was almost twenty kloc, had almost 200 instance variables in the state object, and leaned heavily on a tree object with about 30 instance variables. That's the point at which most people's heads exploded.

Either way, 4,500 lines is the size of a fairly straightforward iOS app. Most folks can dig into that and figure out enough to maintain it without spending a huge amount of time, even if the organization isn't ideal. When you hit tens of thousands of lines, that's where you have to start thinking about how you organize it and document it, because with such large projects, if you jump into the middle without a complete picture, you're likely to be hopelessly lost.

Comment: Re:This should not be on the front page (Score 1) 241

by dgatwood (#49177285) Attached to: Study: Refactoring Doesn't Improve Code Quality
Seriously. I've written single functions longer than that. If your code is so confusing that you can't maintain it without refactoring it by the time the entire app hits 4500 lines, either your code is some of the worst in the universe or you have insufficient working memory. Just saying.

Comment: Re:Should come with its own football team (Score 1) 102

You're confusing cause with effect. Programmer wages aren't high in the Silicon Valley because of having a lot of programmers. There are a lot of programmers because the wages are so high that CS majors come here in droves after college.

The reason the wages are so high here is because of basic supply and demand at work. Silicon Valley has only about a 3.6% unemployment rate among programmers, and a lot of the unemployed either want to be unemployed or are unemployed because their specific skills aren't in high demand. Programmers may be common in the Silicon Valley, but the demand in the Silicon Valley far exceeds the number of qualified programmers who are available and looking for jobs. Thus, the entire market is a zero-sum game, and the high wages are a result of the need to buy people away from other companies.

As a result, any sudden increase in the number of programmers drives down salaries for new hires, and fairly dramatically at that. For proof, you need only look at what happened to programmer salaries outside the Bay Area during the dot-com crash, when droves of people suddenly were looking for more affordable places to live. In some areas, salaries for programmers dropped almost in half because of that exodus.

Is it realistic to believe that there will ever be enough programmers to satisfy the Silicon Valley's voracious appetite? Hard to say. But that's a separate question.

Comment: Re:Should come with its own football team (Score 4, Insightful) 102

Yes, it is pretty silly for them to expect the government to educate people. It is not like an educated population is some kind of public good.

Well, it is a benefit to the public as a whole to a large degree, but there is a dark side, too. The main reason that companies want to increase enrollment in CS is to get a larger pool of people to draw from so that they won't have to pay employees as much.

Comment: Re:terminal illness (Score 1) 698

I'd also tell her about your illness, and tell her what you tried, just in case it is congenital. The more detail, the better. It might save her life someday.

Also, if you haven't already, you should check to see if you qualify for any of the immunotherapy trials going on. Search here if you haven't already.

Comment: Re:The system is mostly okay (Score 1) 183

by dgatwood (#49103445) Attached to: Ask Slashdot: How Can Technology Improve the Judicial System?

Fair enough. In cities with a sufficiently large pool of lawyers, randomly select the judges for each case from the pool of lawyers who specialize in that particular area of law. The goal of randomization isn't to eliminate specialization, but rather to take most of the politics out of the process by ensuring that all qualified individuals have an equal chance of taking a particular case.

Comment: Re:The system is mostly okay (Score 1) 183

by dgatwood (#49101493) Attached to: Ask Slashdot: How Can Technology Improve the Judicial System?

My proposal is rotating judgeship. Everyone who successfully passes the bar exam is put in a pool until they choose to retire (at which point they can no longer practice unless they rejoin the pool). Then the judge for a given case is chosen randomly out of everyone in the pool within a 25-mile radius, with an automatic redraw if the chosen judge is one of the attorneys involved in the case.

For the DA, have five of them in any given district working as equals, and require them to vote on whether to prosecute each case (i.e. if only one or two prosecutors want to "get that guy", the case doesn't move forward). From there, they can fight amongst themselves about who actually does the prosecution. Then require all the lawyers within a voting district to caucus once every two years to choose those five DAs from among their ranks. Enforce a strict two-term limit to ensure that people don't make a career out of being the DA.

Comment: Re:Don't be so hard on him... (Score 1) 323

Although you're correct about traps vs. interrupts, the reason I use the term "trap" is because the word "interrupt" is a much broader term. Most of the time, when we talk about interrupts, we're talking about some hardware device telling the CPU that it needs attention, rather than an application doing so. Thus, if you ask what an interrupt is, you'll probably get a very different answer from most programmers.

I'd expect anybody who has taken a basic OS course to have at least heard of traps and understand the basic concept at a high level—an application executes an instruction whose purpose is to tell the operating system to jump into the kernel and do something special. Anything beyond that is gravy. But if they stare at you looking confused, offer, "or you might also know it as an interrupt instruction".

As for JE... yes, you could ostensibly write code without ever checking to see if two values are equal, but it would likely involve very contrived, inefficient code (e.g. subtract the value, branch if zero, add it back). And if you don't recognize that jump or branch instructions typically start with J or B, and that EQ likely means "equal", chances are very good that you've never written a single line of assembly language for any major CPU architecture—not ARM, not MIPS, not i386/x86-64, not PPC, not even 6502.

Comment: Re:Don't be so hard on him... (Score 1) 323

Yes, there are exceptions to every rule. In fact, the ones I suggested are full of exceptions. They're not really meant to exclude people, but rather to counter the systemic bias that I've seen from lots of companies who tend to mostly hire new college grads from bigger schools, and then wonder why so many of them can't code their way out of a paper bag. :-)

And of course, as in any other field, the longer you've been out in the workforce, the less effect your college experience has on your abilities, or at least one would hope that this is the case. Otherwise, that person isn't learning, and will eventually hit a roadblock where he or she can't progress to a new job because nobody is hiring people to do what that person has always done.

Comment: Re:UX (Score 1) 323

You can only do it in one request if you provide a UI to let the user check a bunch of items and then tell it to delete everything that's checked. Frankly, I find that sort of UI design to be undesirable because it separates the action too far from what is being acted upon, but that's just my personal view.

Comment: Re:Don't be so hard on him... (Score 3, Informative) 323

I have worked with many CS guys would couldn't code for shit because they never bothered to actually learn the language they're coding in, because according to them it's all just syntax. And the ones with the masters in CS are some of the worst developers I've seen.

Apparently, you've never read code written by people with masters' degrees in physics.... Talk about people not taking the time to learn the language....

The thing is, a master's degree in CS doesn't necessarily give you any real-world coding experience, and doesn't necessarily give you any real-world engineering experience. And there's a wide range of undergrad degrees backing that master's degree. Remember that a master's degree usually gives you a lot of theoretical knowledge, and a lot less practical knowledge. Most of a candidate's practical experience is likely to come from his or her undergraduate degree.

Want to find someone who really understands how to write software? Hire someone whose undergrad degree came from a smaller college (which is more likely to be closer to a trade school, with less theory and more practice), and ideally someone whose background is in something other than Java. Why? Java hides way too much of how a computer works, so Java programmers often lack enough understanding of what's going on under the hood to write good code.

In your interview process, ask obscure low-level architecture questions, like "What is a trap?" or "What does the BEQ/JEQ/JE opcode do?" These questions will rule out anybody who hasn't ever worked with any form of assembly language. From there, try to ask questions about their learning style to try to figure out if they are self-teaching (which tends to be a sign of a good programmer, because it enables someone to rapidly adapt to working on code that he or she didn't write).

Or find somebody with a master's degree whose undergrad degree came from a small school, and just assume that the odds are good that he or she was serious enough about programming to figure it out on his or her own.

Comment: Re:why? (Score 1) 677

by dgatwood (#49053101) Attached to: Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"

I was talking about:

f(result==OhShit) {foo.unwind(); foo.cleanup(); foo.bar(); foo.close(); foo.dispose(); foo=null;}

Which is okay as long as it happens only once, but if you end up with several returns, and you need to add foo.releaseNetworkConnections() to all of them, odds are good that you'll miss one, and now you have a leak (at least).

Comment: Re:why? (Score 1) 677

by dgatwood (#49045511) Attached to: Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"

Your first approach is generally a very bad idea. The more copies you make of a block of code, the higher the probability that you'll miss one of them when you later have to modify that block of code. If you have more than about two statements that have to appear before every return statement, your odds of introducing bugs goes through the roof.

Functions are an acceptable way to handle complex cleanup, but they don't really buy you anything over a goto, and if you're cleaning up a lot of variables, the argument list can become unmanageable.

That's why the "goto fail" pattern is so common in kernel programming, where a single bug can be catastrophic.

Comment: Re:why? (Score 1) 677

by dgatwood (#49045433) Attached to: Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"

A better example:

char *dosomething() {
char *tempvar = malloc(...);
char *tempvar2 = malloc(...);

do something...

if (some error occurs) {
goto fail;
}

do something else...

if (some error occurs) {
goto fail;
}
...
free(tempvar2);
return tempvar;

fail:
if (tempvar) free(tempvar);
if (tempvar2) free(tempvar2);

return NULL;
}

Basically, it works well when you have a significant amount of cleanup to do upon failure, because the alternative is writing half a dozen free/delete/release/CFRelease calls right before every return statement.

Comment: Re:The answer is 42, er...I mean, encryption. (Score 5, Insightful) 239

by dgatwood (#49023613) Attached to: Ask Slashdot: What Will It Take To End Mass Surveillance?

Wide spread, end to end encryption would need to be implemented.

Nice in theory. Not so much in practice. With crypto, the devil's in the details. Here are just a few of the hard problems:

  • Initial key exchange: How do you know whether that public key really belongs to the person you want to talk to? Physical exchange of a key? Key signature? Web of trust? Or just trust a service provider and hope for the best?
  • Key updates: Periodically, you'll need to upgrade to a longer key and a new cert. How do things work during that interim period?
  • Expired certs: At some point, those keys are going to be crackable. How long do you trust the expired certs for messages that have already been received?
  • Key revocation: How do handle it in a way that ensures that it can't be readily blocked without also blocking the main data channel?
  • Key revocation: How do you handle the inevitable situation where someone's device dies and they don't have a copy of the original key at all?
  • Key storage: What sort of protection is in place to minimize the risk of the key leaking?
  • New devices: How do you migrate the key to new devices securely?
  • Ability to audit: How do you know that things really are being encrypted end-to-end? What about after the software gets updated?

If it were easy to do it properly, end-to-end crypto would be ubiquitous.

Breadth-first search is the bulldozer of science. -- Randy Goebel

Working...