Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Comment Re:But We Didn't (Score 1) 341

The Republican National Convention. Apparently they'd rather not dwell on who owned who, or who had syphilis, or who handed out smallpox blankets or who detonated "devices." They say that those who don't learn from history are doomed to repeat it. What I've learned from history is that given any nifty new toy, we'll use it and use it without regard for the consequences and we'll fuck anyone over for a buck. A brief list of everyone we've fucked over in the past: Everyone. And now we're fucking over future generations who aren't going to have a very nice planet to live on, so a few energy barons can own an even larger percentage of the world than they already do.

Comment Re:But We Didn't (Score 2) 341

"Safe" is a relative term with those things. Underground tests well away from populated areas would at least mitigate the fallout. There are very few places on earth you can explode a nuclear device where it won't affect a civilian population, but we seemed to go out of our way to explode them near populated areas. We'd also invite reporters or the army to witness the explosion from a "safe" distance away -- two or three miles from ground zero for the blast. We shamelessly experimented on our own people and anyone else. You know, shit they'd rather the high schools didn't teach you in AP History.

Comment But We Didn't (Score 5, Insightful) 341

We didn't stop at 2 nuclear bombs. We exploded them and exploded them like they were goddamn tic-tacs. We didn't even do that safely -- we exploded them near our own civilian populations, telling the people that it was harmless and not to worry about that fallout. Judging from our track record with the things, some politician in Washington had read too many comic books and was hoping that some of the civilians would develop super powers. Instead, they just got lymphoma and birth defects. We made those goddamn things and put them in the hands of the least responsible people on the planet and stopped only after irreparable harm was done to thousands of lives. So yeah, you can draw that analogy if you want to but I don't think it points to as rosy a future as you might think it does.

Comment Re:About time... (Score 1) 158

Funnily enough a lot of the time I'm talking about Ruby on Rails and Ruby's Active Record. They're a very good example of a project that says "Oh look how easy it is to build a web page with our thing!" with a trivial example. Last time I looked at it, I started having to look at implementation-level details of the packages almost immediately. I also remember it being an awful lot of code for what I needed. I really only needed about 10% of the functionality Rails provided, and had no way to scale down to just that.

Funnily enough I went through that phase where liked ruby, but am now back to the point where I'd rather just use perl with "use strict;". If I'm going to do OO development, I'm going to do it in C++ or Java.

Comment Re:Not-Good-Enough Syndrome (Score 1) 158

Yeah, the quality of the open source programs that I look at is usually far superior than anything I've ever seen inside a corporation. Although... at one company I worked for, I had to audit the source code for the original AT&T C standard library. That was obviously done by people who knew what they were doing. I also recently submitted a pull request to the gnu flex maintainer on github. Flex seems to generate some pretty decent code, but the code it uses to do it is a maze of global variables. I did manage to tweak it to generate a C++ class that works for me without the #include fuckery that flex typically requires, but I don't know if the maintainer is going to actually like that change. Doesn't matter to me, I can just use my version from now on.

Comment Re:About time... (Score 1) 158

I'd be happy to just go into a company and write unit tests for their code, but in most cases that would require dictating huge design changes to a lot of their code. If I take over a code base, I like to start writing unit tests for new development and bug fixes (Write the test prior to fixing the bug.) Last project I worked on was an old C code base with hundreds or possibly thousands of global variables. In some cases there were multiple global variables for the same value, and they got used in different places and often had to be set to different values in order for the code to work correctly. It might not have been too bad to go through and make sure it was just passing everything it used, but it was a lot of code and it kind of all needed to be changed at the same time. Much too much of an effort for the team that was working on it.

Comment Re:About time... (Score 4, Insightful) 158

Or is just complex and unfamiliar. The problem with these frameworks is they work great when they work, but you only ever see them working because they've been published with the most trivial example. When you actually start trying to do things with them, you have to know implementation-level details of the framework in order to make it work for you. By the time you've invested all that time, you may as well have written something less generic that actually does what you want.

Oh and when I say they work great, I was kind of lying. I have a favorite example. A while back a developer I was working with wrote some Spring/Hibernate code to pull records in from the database and print a billing report. Soon as he handed it off to me, I thought "What happens if I throw 100000 records at this?" Well what happened is that it crashed. So I cut the number in half and it still crashed. Down around 30000 records, it started taking about half an hour and THEN crashing.

Turns out he was using the framework to pull all the records from a couple of different tables and doing the join in Java. The SQL join I wrote to test the code took a couple of minutes to run on a million records and returned the correct output. On a hundred thousand it was neighborhood of 10 seconds.

Now the Spring/Hibernate people will be quick to point out that you can edit some XML file or something and make the framework do a join for you, thus solving that problem. And that is true, if you know a fair bit about the framework. And you'd have to know a fair bit about all the other frameworks they used on that project, too. By the time you got done learning all the frameworks they were using to the level of detail where you could actually be that effective with them, you could have written the application they'd built 10 times over.

Fortunately this story has a happy ending. The team ended up deciding to run the original developer's code against the billing database several times a day so that it would never have so many records to process that it would crash, thus solving the problem once and for all!

Slashdot Top Deals

Remember to say hello to your bank teller.

Working...