Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

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:WIMPs (Score 3, Interesting) 162

by lgw (#49359093) Attached to: Dark Matter Is Even More of a Mystery Than Expected

Dark energy is just the latest name for the Cosmological Constant - I guess it's a better name if it's not actually constant, but the cosmologists I've seen talking about it don't like the new name either (not that anyone has a better suggestion, really). The key thing about it is that the energy density of it is insanely low - I suspect that on the quantum scale it actually "rounds to 0" the way things can in QM, where no measurement is possible at that scale. I think even at the scale of our galaxy it's a very tiny effect. It's a testament to how sparse matter really is in the universe that dark matter is the dominant effect overall.

Comment: Re:It depends (Score 5, Insightful) 481

by lgw (#49337255) Attached to: No, It's Not Always Quicker To Do Things In Memory

How in the world? Trivially. They're doing it in an O(n^2) way - it's the only explanation.

If you use string concat library code naively, you can end up "copy the string, add one byte, repeat" easily enough in languages like Java. And it's not exactly breakthrough research to discover that O(n) disk can be faster than O(n^2) memory for large enough n.


A Bechdel Test For Programmers? 515

Posted by timothy
from the this-code-feels-different dept.
Nerval's Lobster writes In order for a movie or television show to pass the Bechdel Test (named after cartoonist and MacArthur genius Alison Bechdel), it must feature two female characters, have those two characters talk to one another, and have those characters talk to one another about something other than a man. A lot of movies and shows don't pass. How would programming culture fare if subjected to a similar test? One tech firm, 18F, decided to find out after seeing a tweet from Laurie Voss, CTO of npm, which explained the parameters of a modified Bechdel Test. According to Voss, a project that passes the test must feature at least one function written by a woman developer, that calls a function written by another woman developer. 'The conversation started with us quickly listing the projects that passed the Bechdel coding test, but then shifted after one of our devs then raised a good point,' read 18F's blog posting on the experiment. 'She said some of our projects had lots of female devs, but did not pass the test as defined.' For example, some custom languages don't have functions, which means a project built using those languages would fail even if written by women. Nonetheless, both startups and larger companies could find the modified Bechdel Test a useful tool for opening up a discussion about gender balance within engineering and development teams.

Comment: Re:Schneier got it right a decade and a half ago (Score 1) 119

by lgw (#49322509) Attached to: OS X Users: 13 Characters of Assyrian Can Crash Your Chrome Tab

Maybe I'm still not getting your point. Sure, if you need to understand the details of Unicode character composition and such because you're the one rendering the output glyphs, or you want to sort or search across different encodings of the same word, that's rough, but there's no excuse for a security failure while doing those tasks.

On your other point: the notion of "sanitizing input" is fundamentally flawed to begin with. You can never know what future framework that user data will be interacting with, and what might be interpreted as an escape sequence in that mysterious future, but you can assume that the guy doing that future work will just assume "the input was sanitized", and you're screwed. Instead, don't go there. If e.g. you need to store a user string in a SQL DB, do it in such a way that there's no possible problematic string (perhaps the DB has a way of doing queries that's guaranteed safe, for example). If e.g. you need to send a user sting inside an XML blob, just convert the user string to a hex/base64/whatever representation first - guaranteed safe.

What usecase were you thinking of that makes any of this hard at all?

Comment: Re:Would that be like the free market solution to (Score 1) 414

by lgw (#49316573) Attached to: How 'Virtual Water' Can Help Ease California's Drought

A contract would have prevented that just as well as a law, is the thing. Engineering a shortage in an attempt to corner a market is hardly a new idea - it's older than the idea of commodities markets, for sure. That's why commodities contracts are carefully written, backed up by especially brutal contract law, and market rules prevent any one entity from controlling too large a position.

All of this is centuries-old best practices, and none of it requires price-fixing.

Comment: Re:Would that be like the free market solution to (Score 1) 414

by lgw (#49315801) Attached to: How 'Virtual Water' Can Help Ease California's Drought

There are plenty of laws around modern markets. That's how they evolved. Trying to make some sort of anarchist strawman really doesn't make you look smart, you know.

What there aren't are prices fixed by law. It's really not that complicated a concept: government regulating product quality, fraud, and contracts: good; government setting prices or granting monopolies: bad.

Comment: Re:Would that be like the free market solution to (Score 4, Insightful) 414

by lgw (#49313453) Attached to: How 'Virtual Water' Can Help Ease California's Drought

You miss the point. The exact problem with retail price controls and a wholesale free market is that it's vulnerable to gaming, Enron-style. Proper markets expect every participant to be gaming the system as hard as they can. They're built on it from the start, have evolved for centuries to cope, and they work nicely for most commodities in the world - just a few government-granted monopolies left over causing problems.

Comment: Re:Having to move (Score 1) 211

Well, when a state school didn't come with a crushing debt burden, it was much less of an issue (compared to even 10 years ago it's nuts). My own solutions was to get that first job in my home city, paying peanuts, then once I had enough experience to be credible, move away. That first job wasn't so hard to get because everyone else was doing the same thing, so they were constantly hiring.

With you on the home economics. I was such a moron with money for almost the first 10 years.

Comment: Re:Maybe they should ... (Score 1) 211

Ha! That's been happening continuously since the beginning - better languages, better frameworks, etc. You almost never need to write a toolkit these days, or a script to refactor code in some simple way. I started with assembly, and for all Java's many problems, it's several times as productive. Turns out the need for programmers is mostly limited by budget, not by the universe of problems that need to be solved, and so more companies started hiring developers as the better tools made the payoff better.

Comment: Re:Schneier got it right a decade and a half ago (Score 1) 119

by lgw (#49312833) Attached to: OS X Users: 13 Characters of Assyrian Can Crash Your Chrome Tab

You might be right, but it's such an old problem - it was a big deal 10 years ago in the Windows world as UCS2 didn't handle it. C# was actually UTF from the start, like Java, of course.

Still, crashing because of, what, a null in the input? I could certainly understand truncation (just like other incorrect display problems), but a crash?

Comment: Re:Schneier got it right a decade and a half ago (Score 1) 119

by lgw (#49309643) Attached to: OS X Users: 13 Characters of Assyrian Can Crash Your Chrome Tab

UTF8 has nothing to do with it.

The problem commonly is: people try to "clean" input with some stupid regex, rather than treating all user-provided strings as permanently dirty. You can do anything you need to, risk-free, with this attitude. You have to understand the encoding you use for storage/transmission (if your framework doesn't provide a way to safely, blindly store/transmit any string, then just encode the string in some way first), but that's a much, much smaller world than the universe of possible user string.

As soon as you try to render, parse or even only compare anything besides standard ASCII, you are screwed.

Render? Displaying a glyph incorrectly is one thing, but crashing or leaving some exploit open is raw incompetence. Parse? If you need to parse user input, you likely have bigger issues (if you're running user scripts or whatever). Compare? Again, you might get the order wrong (is there even a defined order for pictographic languages?), but crashing is inexcusable.

They're just bytes for fuck's sake. What kind of moron can't process them safely in this day and age?

But then, this is Chrome we're talking about - the initial release would crash with a 2-character string (";=" was it?), due to an error that never should have made it past code review - subtracting 1 from an unsigned value, then using the result as a limit in a for loop IIRC. Might as well be checking your passwords into github.

Comment: Re:Excellent idea! (Score 1) 211

by lgw (#49308951) Attached to: Arkansas Is Now the First State To Require That High Schools Teach Coding

its an h1b market and will get worse and worse as time marches on. immigrants can and will work cheaper than americans, employers know this and employers know the reason for the h1b push.

Total bullshit in every way. It's like you can't think beyond your hatred of brown people. Programming is a world market, and you compete with the world for jobs. Every H1B is a person who is paid more than they would be to do the very same job in their home country! And they pay US taxes, besides. The tragedy of the H1B program is that we should just be giving them green cards instead - we surely need to tax revenue in the coming years!

The nice thing is: there are still plenty of jobs world-wide. There was a time when the labor pool in programming was increasing exponentially as every country with a CompSci program was opened to outsourcing for the first time, but that's all explored now. The world's supply of coders is expanding linearly now, as all the worlds universities crank out coders at a steady rate (plus the few like me who make it without the degree). The demand is growing faster.

The US economy just went through a long-ass downturn, nothing programming-specific about it (blame the banks and the politicians that enable them). But the big software companies are hiring like crazy now (my team has 9 open positions, it's nuts), and while you may have to move away from Arkansas to where the jobs are, that's pretty much win-win.

All the simple programs have been written.