Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment Re:Hire a music major as CIO... (Score 1) 127

The worst code I've ever seen came from some clown I never met, no idea what his schooling was. There was some really strange shit in his code, like declaring a global array of a hundred ints called "constants", filling it with the values from 0 to 99, and then using "constants[whatever]" anytime he needed a constant value in the code.

I asked my customer what happened to the guy (he was long gone by the time I got there), and found out that he'd been shitcanned for getting drunk at the office christmas party and punching a girl out.


Comment Re: Hire a music major as CIO... (Score 1) 127

One of them has composition and conducting degrees from Juliard, and a BA in computer science from Rutgers. One of my early mentors was an organist, with a music degree from some very small college whose name I don't recall, and he leaned what he knew about writing code entirely on the job.


Comment One anecdote.. (Score 4, Interesting) 456

One of my assignments at Apple was cleaning up a framework that had thirty or more coders over the previous ten years. The first time I ran it through the static analyzer, there were over six hundred issues identified. I tracked down and fixed all of them over the next couple of months in the process of cleaning up the code to build under LLVM and pass the App Store rules.

Most of the easier cases were things like parameters of the wrong type being passed to methods, which caused no problem at runtime and hadn't been spotted before for that reason. The more difficult ones were mistakes in memory handling, and in a lot of cases, I found myself saying "holy shit, GCC lets you do THAT?"

Comparing Obj-C to Swift, I would say that easily 90% or more of those bugs can't be written in Swift at all unless you resort to the UnsafeMutablePointer types, which put it right in your face that you're doing something dicey.

I was a huge fan of loose coupling for all the years I was an Obj-c developer, but today I spend almost no time in LLDB, since almost all of the mistakes I make writing Swift are caught at compile time.


Comment Re:You have to look at the source (Score 1) 456

Since I have programmed in many different languages I have personally discovered that strongly statically typed languages do solve a lot of problems because the problems are encountered already at compile time, not during runtime. The problems are also less elusive.

What a lot of this commentary—not just yours—seems to be eliding over is the motivation to move away from strong typing. It's not merely—or rather, not only—convenience. There are a number of data-mangling jobs that are better handled outside of the strictures (and structures) of strong typing.

I don't want this to devolve into a relitigation of the relative dangers of buffer overflows vs type spoofing as attack vectors, but it is fair to say that programming is as programming does, and there will never be a world with only strong typing; and there will never be a world without it, too.

There are benefits to both, and though it's perfectly fair to say that the convenience factor of untyped languages is used more often out of laziness than because it's the right tool for the job, sometimes it actually is the right tool for the job.

Slashdot Top Deals

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken