Slashdot Mirror

Seeing how Excel historically had its own compiler, that sounds about right.

"Nobody really buys hammers anymore. ... Everyone is using a general-purpose tool-building factory factory factory".

http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12&

1. 1. Rewrite your code
2. 2. Fix all the bugs you introduced that didn't exist in the original
3. 3. (and ongoing) Run into all the edge cases that were discovered and solved years ago in the original code.
4. 4. Spend tons of manhours and tie up your talent pool rewriting just to get where you are now instead of adding new features.
5. 5. Embrace your FAIL

Your QA/Build process is seriously broken if you don't have one person or one team in charge of the build at all times.

Everyone should be familiar with the build system, and a "you break it, you babysit it" rule means that everyone rotates through the responsibility, while also providing an incentive to double check their work. I got the idea from Joel Splotsky's blog post 12 Steps to Better Code.

Refactoring can eventually lead to an almost complete rewrite but the point is that you're keeping most of the logical structure. Complete rewrites often end up reinventing the wheel badly and missing edge cases which were accounted for in the original code. Rewrites make assumptions that often prove to be untrue.

Here's an oft linked article
http://www.joelonsoftware.com/...

It's never as simple as you think: http://www.joelonsoftware.com/...

The problem with Joel's "choices" article is that it is largely complete and utter bollocks. Yep, let's just merge a whole bunch of vaguely similar concepts into a single option, because they are vaguely similar and users quite often only use one or two of the options.

Yep, thinking like all adds to humanity's race to the bottom.

It's never as simple as you think: http://www.joelonsoftware.com/...

Thing is, people don't read, so anything that requires following instructions doesn't "just work", which Apple aspires to (and generally does a good job on). I'd say that having instructions to follow when doing something the average person wouldn't expect instructions for is making it hard.

So he starts off with stuff about how he's feeling old and the surest sign of it is bitching about "kids these days".

You need to have read more of Joel's writing. That's just his irreverent style.

Got to that point and decided that it's an obviously unsupportable premise. Read a little bit more, and my takeaway is that Joel doesn't know how to spot a good programmer unless they're working in C.

His premise is that, in order to be a good programmer, you need the right kind of metal aptitude which is a you-either-have-it-or-you-don't thing and not a skill that can be learned. While there may be other ways to test for that aptitude, his claim is that one sure-fire way to test for it is the ability to understand pointers. (He makes that point even more explicit here.) And, among today's languages that are in use, the only one that really requires you to understand pointers is C. (Many years ago, it might have been Pascal, but Pascal is pretty much a dead language.)

Apparently people have trouble going from Java to C...

You're not the first to notice this.

This is one of those questions that's going to keep being asked... Perhaps one day I'll be fast enough to get a first post on this that people actually read...

Link summary from last time:

• Stack Overflow's books every programmer must read question (locked since 2012).
• Top Programming Books a more diverse list.
• Top 100 Programming Books by sales stats.
• Top Programming Books a more diverse list than the above.
• Reddit has a Must Read Programming books thread.
• In this Stifflog 2006 interview with Yegge, Torvalds, Hansson, Norvig, Thomas, Van Rossum, Gosling, Stroustrup and Bray.
• One of the Kernel Hacker Bookshelf series on LWN recommends Unix Internals.
• Joel Spolsky's list of books programmers need to read.
• Your Favorite Tech / Eng. / CS Books Slashdot thread from 2008, my comment listing my favourite books.

General comments

• A few people have volumes of Knuth's Art of Programming on their shelves (but it's harder to find people who have read all of them).
• One of the consultants who taught at my University said that the Mythical Man Month and Peopleware were good. I've read these too and can also recommended them (although they are more about managing programmers rather than programming per se). The consultant also recommended Design Patterns (although he said not to read the book cover to cover but rather to just be aware of them so you could refer to them later).
• I've heard the "Dragon Book" (Compilers: Principles, Techniques, and Tools I think is the 2nd edition) being talked of favourably.
• Many people seem to recommend reading Godel, Escher, Bach (I'd say it's about mathematical thinking)...

I've noticed which book answers tend to fall a bunch of categories:

• Books that talk about software engineering/management/teams.
• Books that talk about programming languages.
• Books that talk about Computer Science.
• Books that improve your mathematical thinking.
• Books that programmers like but aren't programming/maths at all.

If you're going to ask someone "which book?" try limit the categories they should give you an answer for...

Anyone developing software needs a clue about names, and about unicode and text encodings.

http://www.kalzumeus.com/2010/...

http://www.joelonsoftware.com/...

(Then learn lots, lots more about text encodings).

Also, whether or not they use SQL directly, about metacharacter attacks and SQL injection:

http://bobby-tables.com/

http://watchguard.com/infocent...

http://www.joelonsoftware.com/...

There Ain't No Such Thing As Plain Text.

For the love of all that is holy, every person who ever writes a line of code anywhere, for any purpose, must read this! No exceptions!

There Ain't No Such Thing As Plain Text.

There Ain't No Such Thing As Plain Text.

For the love of all that is holy, every person who ever writes a line of code anywhere, for any purpose, must read this! No exceptions!

There Ain't No Such Thing As Plain Text.

There needs to be some sort of appeal or review process whereby the public can object to patents like this and many others that have been granted.

There is. Also see this for some more background information.

This reminds me of factory factory factories:

http://discuss.joelonsoftware....

Ironically, that's basically the same squeeze that Apple has traditionally profited by avoiding in the hardware market:

It's called "Commoditize your complements."

Apple wants media to be cheap so they can sell hardware.
Microsoft wants hardware to be cheap so they can sell software.

http://www.joelonsoftware.com/...

Option Strict is your friend.

In addition to Option Explicit. Friends indeed. But to the OP's behalf, Option Explicit is relatively new (2005 I think). There is still a lot of VB code out there that predates that feature.

But even then I think one should not need to rely on such things.

I used to be a QuickBasic and VB programmer back in Pre-(Internet)-Cambian times (and, oh, the horrror, PickBasic with numeric goto statements). We guarded ourselves (or I least I did) by using strict coding conventions and Hungarian notation on variable names and function names indicating the return values.

To a similar degree I did the same when I shifted from VB to FoxBase/FoxPro/VFP (what a nice product it was for its time). Anyways, it was obviously impossible to guarantee a type-mixing mistake would not occur, but software written this way tended to be very reliable and sufficiently type-safe.

Done this way, type mistakes were easy to spot by just looking at the code. At the end of the day, as Joel Spolsky once wrote, it is about making wrong code look wrong.

I don't disagree, but a lot of the problem with this is knowledgeable programmers shouting "Leaky Abstractions!". You can't guarantee that your concerns will be 100% separated, so the argument goes, so why bother to try in the first place? To actually program worth a darn, you need to know the ins and outs of everything you lay your hands on -- and since you know the ins and outs, why wouldn't you make everything super efficient by tightly coupling everything? I mean, you can shave off a function call/database query/twenty characters of typing by going around the "official" way and just calling the internals directly. That separation is just needless boilerplate, a hoop to jump through without tangible benefit. -- Is it going to bite us in the ass later on? Who cares? It's working now, durn it!

In my experience this is bullshit. Is there any evidence whatsoever that disproves my anecdotal evidence and shows that professional developers don't learn from their mistakes and even make a bigger hash of it the second time around?

It's not that they'll make a hash of it, so much as that a complete rewrite will take much longer than they think it will, because they've forgotten (or weren't around to experience) the thousands of niggling little corner cases whose correct handling is what makes the current codebase so, um, interesting to work with. Then when they do finally get the ground-up rewrite done (years later than they thought they would), they'll find that it is now a complicated mess too, for most of the same reasons the first codebase was.

Why "nope"? Stackexchange seems like a great (crowdsourced) medium for exactly this. Already a patent application has been struck down thanks to prior art discovered via that site.

Okay; I'm reading the beta now, on my tablet. Trying to give it a chance. The fact is that, I tried it before and it is better than the puke making state it was in before. However the sad fact is that this just gives me the chance to see how awful the changes really are.

In posting mode I can't see the comments in the article. There isn't even a button to quote the parent which I normally have. In the end the main thing ends up being the thought that the "fuck the beta" people are right.

However I'm a positive, creative kind of guy so let me instead say something about where they should go. The most insightful article to explain what they are doing wrong is Joel Spolsky's Things You Should Never Do, Part I. Fundamentally this project needs what Joel calls "adult supervision".

Where to go from here? A fundamental is the need to learn from both new and old

• The old code is clearly achieving the business aims of running Slashdot better than the new. Start with that as the base of the future Slashdot.
• Make automated tests for all features.
• if there is a need for a new format, restructure the code so that both can be supported indefinitely from the same code base
• make the decision to shut down only at the point where almost all old members have moved voluntarily because the new site is better

The parent post is right. Comment density on screen is what makes Slashdot more readable than the average newspaper comments section. intelligent comments which actually reply to their parent are also crucial. The Beta seems to be ready to wipe out both.

I just realised; there isn't even a preview button. All errors are beta's responsibility.

It's not just the hipsters, it's also people like Joel Spolsky - the god of hipster programmers.

eg. I've lost count of the number of times I've seen this article referenced on the web and every time I see it I want to bash his head against something solid.

"Making Wrong Code Look Wrong"? Really? How about making wrong code *be* wrong? How about not having it compile at all? How about an SQL library that doesn't accept unsafe strings as parameters?

If you really want to, you could get the compiler to convert unsafe strings to safe strings on the fly ("implicit type conversion") to avoid having to educate the junior programmers.

All SQL injection problems could be eliminated at a stroke, now and forever. How is possible that people aren't doing it?

They're not though, because that would require a strongly typed language...and that's not fashionable.

Joel also rants endlessly against languages with exceptions (there's some of in that article), fails to grok very basic C++ concepts every time they're mentioned (eg. stack unwinding), but the hipsters worship him as some sort of a guru. /rant over

Back when Joel could write, he penned this on what he called the Law of Leaky Abstractions. Related, his rant on Java Schools

Joel's writing was always flawed, never perfect, but usually made you think some.

Back when Joel could write, he penned this on what he called the Law of Leaky Abstractions. Related, his rant on Java Schools

Joel's writing was always flawed, never perfect, but usually made you think some.

Joels Spolsky wrote this article years ago:

http://www.joelonsoftware.com/items/2009/03/09.html

He said a (program) manager should:
1. Design UIs
2. Write functional specs
3. Coordinate teams
4. Serve as the customer advocate, and
5. Wear Banana Republic chinos

You don't need to be deeply technical to do any of these things, but you do need to have some skills that are not "generic" for other areas, like knowing usability.
And most importantly he must be a peer to the developers, not a boss. Otherwise when they say anything unfeasible (or stupid) the devs can't disagree because it will be bad for their careers. And here lies the problem, after a century of corporate culture evolution managers can't be anything other than bosses in most companies. Most career paths in companies make the senior members into managers.

The AARD never worked in a shipped version of Windows. Stop getting worked up.
And Netscape made plenty of big mistakes, including this one http://www.joelonsoftware.com/articles/fog0000000069.html
Not to mention that the code was hugely bloated, that Mozilla Firefox is still trying to fix, after ~15 years. An OS that didn't ship with a browser would be laughed out of the market.

There are plenty of such stories about Apple or Google too, but they're not pushed like the MS ones seem to be.

For example, see how Google squashed Skyhook
http://www.theverge.com/2011/05/12/google-android-skyhook-lawsuit-motorola-samsung/

Aliyun and Acer prevented from launching a phone because of the secret rules of the "Open" Handset Alliance.
http://www.zdnet.com/cn/report-google-stops-acer-from-launching-aliyun-phone-in-china-7000004246/

Apple and the famed 30% cut of even sales from Apps, an example of how they used someone's OSS code in Safari and then banned them from the app store:
http://blog.readability.com/2011/02/an-open-letter-to-apple/

Yet you hate on MS and think of Google as a savior. Tell us, what is YOUR interest against Microsoft that you're spreading lies and FUD? The fact that your posts are modded up is the reason that Slashdot is losing readership as even the circlejerk echochamber gets bored with the same hating posts and posters.

Yes, you can enable SSH on ESXi. There are also varying levels of support from third parties, most of which are easier to deal with than Microsoft.

Perhaps I should clarify what I mean when I say I'm a "Windows sysadmin"... For the past two years, I've been doing systems work with Windows. For the first year, it was mostly in a bog-standard admin capacity, but for the past year I've been working exclusively on a project in Windows Server 2012, using PowerShell heavily. I'm now in charge of maintaining and improving about 10k lines of PowerShell scripts.

Powershell is the second-worst language I've encountered in almost two decades of programming. Here's a few reasons why:

• It's supposedly all based around objects, but you can't natively define your own classes. You have to embed C# for that.
• The "pipeline" passes objects from one command to the next, but there is no standard for what semantics a passed object must support.
• Opaque objects can't easily be manipulated or constructed for debugging.
• Commands are loaded modularly, but there are no namespaces. Collisions are inevitable.
• No include-like functionality for scripts. You can import (with .) a modular script multiple times, but it'll run multiple times.
• Multiple overlapping APIs. In addition to the PowerShell native commands, there are interfaces to .NET, WMI, COM, and command-line executables, any one of which may be the expected (or only) way to accomplish a given task, and of course the available features change with every revision of Windows.
• Context-sensitive errors. Assign several kinds of Get-* results to variables, and you can check that variable safely in an IF condition. Checking the Get-* directly in the condition will throw an error if the Get-* operation returns an empty set.
• Moving to an inner scope is copy-on-write.
• Far too much boilerplate to declare constants (38 characters) or globals (27 characters).
• Symbol aliases like "%" and "?" are not obvious when reading old code, and text aliases are also rarely intuitive unless you use them frequently.
• No cross-platform support whatsoever.
• Incomplete support in older OS versions, and no upgrades.
• No unified documentation (due mainly to aforementioned modularity hell and split APIs)
• Whitespace sensitive.
• No native support for test-driven development.
• No support for multiple entry points.
• Worse multithreading support than Perl.
• Little control over command output. Either you nitpick each command to accommodate its error, warning, and output streams, or you change the global error-handling variables
• As with all Microsoft products, absolutely no guarantee of support beyond the current version. As soon as Microsoft decides that SuperShell is the next big thing, PowerShell will go join other abandoned systems like COM, WSH, and VBScript.

My theory is that PowerShell started as a way to tack .NET support onto batch files, but then some brain-dead executive thought it'd be a suitable competitor to Bash, so they had to add pipes, but it's just gotta use objects, because Windows is all about the objects! Then somebody actually tried to use it for something productive, and realized it was still limited, so they added half-assed module support so it could be more useful later. Executives saw the progress, and declared that it had to be integrated into all the new 2012 stuff, so that meant that each team had to figure out their own way to make PowerShell make sense. Of course, in typical Microsoft fashion, nobody thought to look over a

Possibly relevant to your experience.

It was also created to boost chip and disk sales, too.
And frameworks. Don't forget frameworks.

Big mistake. Starting from scratch is rarely the best course of action.

For example:
"Netscape made the "single worst strategic mistake that any software company can make" by deciding to rewrite their code from scratch."
http://www.joelonsoftware.com/articles/fog0000000027.html

People say that, yet immediately turn around and say you should not expect a program written for Windows 95, or Linux in 1995, to run on a modern computer.

There is a difference between incremental upgrades and wholesale rewrites. Windows 7 (to take one example) isn't a new OS written from scratch, but an incremental improvement on NT, which dates back to 1993. Rewriting from scratch is almost always a bad idea.

... He actually worked on Excel leading to funny anecdotes like this one

http://www.joelonsoftware.com/items/2006/06/16.html

Ha, good reference -- ...Later I had it explained to me. "Bill doesn't really want to review your spec, he just wants to make sure you've got it under control. His standard M.O. is to ask harder and harder questions until you admit that you don't know, and then he can yell at you for being unprepared. Nobody was really sure what happens if you answer the hardest question he can come up with because it's never happened before."

I do the same thing as a design judge for Formula SAE, where students build race cars and the judges are from the motorsports industry.

Joel Spolsky has an excellent write up on why the Office file formats suck. A must read.

http://www.joelonsoftware.com/items/2008/02/19.html

He actually worked on Excel leading to funny anecdotes like this one

http://www.joelonsoftware.com/items/2006/06/16.html

Joel Spolsky has an excellent write up on why the Office file formats suck. A must read.

http://www.joelonsoftware.com/items/2008/02/19.html

He actually worked on Excel leading to funny anecdotes like this one

http://www.joelonsoftware.com/items/2006/06/16.html

No, I agree that the Java language itself is not over-engineered. I said that the frameworks and community that have grown around it, have a tendency to over-engineer (especially in the enterprise). That is not to say there are no efforts within the community to overcome that, but having shifted from enterprise Java to C/Python and also having worked a fair bit with C#, I do have some experience with the general ethos in each of the communities.

RE: "Which factory e.g. did annoy you in particular, and why?" Joel explains it better: http://discuss.joelonsoftware.com/?joel.3.219431.12

As much as I disagree with his business tactics over the years, Gates is a freaking genius.

I'm not sure whether he's a genius, but I had a lot more respect for him once I read this, which is Joel Spolsky's first-hand account of working for the man. He wasn't necessarily a genius, but he was a very effective combination of ruthless businessman and smart technical guy.

At a time when most people weren't technical at all. His first exposure to computers was in 1968 at age 13. The world had yet to see a "Walkman," much less a desktop computer (or any computer at all). That right there put him ahead of 95% of the world in terms of understanding computers. He simply crossed that line that many academics would not, i.e, trying to monetize their research. He took advantage of many who didn't know what they had (DOS was bought to 75K and the guy who own DR-DOS didn't want t deal with him).

As much as I disagree with his business tactics over the years, Gates is a freaking genius.

I'm not sure whether he's a genius, but I had a lot more respect for him once I read this, which is Joel Spolsky's first-hand account of working for the man. He wasn't necessarily a genius, but he was a very effective combination of ruthless businessman and smart technical guy.

Microsoft used to be all about preserving backwards compatibility, even resorting to crazy hacks in Windows 95 to make sure games like Sim City would run despite bugs in the game. But that Microsoft doesn't exist anymore.

It started with VB.net not being compatible with VB6, and continued with other products too. Microsoft obviously doesn't care about making sure IE10 works with old web apps targeted to IE6, Vista broke the old crappy XP apps that didn't understand non-admin users, and Office often has problems getting the formatting right for documents created in older versions. Those are the obvious examples, but there are many more smaller and more obscure ones.

http://www.joelonsoftware.com/articles/APIWar.html

Not saying I disagree with all of the decisions - e.g. the old insecure XP apps were broken anyway. But Sim City was also undeniably broken, and yet the old Microsoft took ownership of the issue and fixed it anyway.

And in Apple's defence, they did bring out Rosetta when they started making Intel Macs, and supported it for about 5 or 6 years. Microsoft did no such thing with Windows RT.

When I have been part of interviewing new hires, I've tended to ask this question: "what do you find frustrating about C++?"

If you really know C++, there are bound to be at least a few things that you find frustrating. The lack of standardisation on binary interfaces, the continued drive for flexibility at all costs (resulting in a million ways to do one simple thing) and the way they have ALWAYS emphasised pattern clutches over improving the language. Despite (or perhaps because of) the near-complete lack of ABI compatibility between versions, they nearly never remove or depricate anything in the the standard or the STL API, meaning any new "simplification" always comes in addition to the old way, it never replaces it. Sadly this means the standard is never actually simplified, they just add yet another layer of abstraction, which always leaks. Lots of the STL and the standard patterns used by C++ developers are really clever and I'm sure they were intensily satisfying to develop. But satisfying cleverness is not necessarily something to build a programming language on.

The worst part is that the patterns and algorithms which were developed to work around gaps in the core language actually become arguments not to improve the core language. Let's face it; as much as I've used std::for_each, it should never have existed. Instead, range-based for-loops should have been in way before C++11.

The c++ FQA sums up some of my own frustrations.

That said. There is no other language with such easy access to such a myriad of great libraries out there, especially for science/engineering/visualisation, and for this reason I cannot agree with the FQA's notion that there are no reason to start new projects in C++. By using these libraries, your own code could well become quite elegant and you would shoot yourself in the foot if you decided to avoid C++ on principle for a situation where C++ and its large set of libraries would solve your problem.

Given that patents cost $1,000-$10,000 each just in fees to the USPTO and their multi-year backlog, why don't they just offer up bounties? They could assign them semi-randomly so that by the time a patent reaches an actual examiner, they would have plenty of independent reviews of the material. Given that it took Joel Joel Spolsky 10 minutes to kill a Microsoft patent, I would spend an hour or two for a cut on the fees.

Although Joel Spolsky doesn't use the term Rock Star, he has AFAIK the best insight into the subject why "Rock Stars" (great developers) matter. He does not say all your organisation needs to be made up of outstanding tallent, but it helps to have some around.

Maybe you should give your team the Joel Test. I think you want source code control. Maybe subversion or git?

Some people don't like Joel (probably the J2EE guys) but he really does have some good things to say about software development. The project framework factory sounds like something that only the Architecture Astronauts could love.

They haven't started on the project framework factory project.
When that one completes, the Eschaton shall surely be immanentized.

If they went to the kind of effort to find workaround to make an old version of nutscrape work on 98 they would be dumb as a bag of rocks.

What they DID do was rather amazing:

http://www.joelonsoftware.com/articles/fog0000000054.html

Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity wasn't working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn't free memory right away. That's the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.

That kind of thing made me love 95, I had a lot of software that ran just fine on it, and I didn't have dodgy hardware that made it crashy for some people...

Anyway, you should porbably come up with a better counter-example than "outdated browser that was arguably worse than the horrible IE that came with 98".

Well, you have to instantiate a BigDecimaFactory in the inversion-of-control container and pull in a lot of org.apache.whizbang.dont.we.love.us.some.nested.hierarchies code, plus update your ant scripts to maven, and don't forget to feed the Tomcat, but, with sufficient struggle, you can still get to "Hello World 1.0" in Java.

And just to follow up, if you read the article, Joel talks a fair bit about unnecessary obfuscation, starting with:

The first technique is to try to make the language of the patent as confusing and obfuscated as possible. That actually makes it harder for a patent examiner to identify prior art or evaluate if the invention is obvious.

and an example from the patent in question:

This patent was, typically, obfuscated, and it used terms like "pixel density" for something that every other programmer in the world would call "resolution," either accidentally (because Microsoft's lawyers were not programmers), or, more likely, because the obfuscation makes it that much harder to search.

Joel Spolsky had this article on Gladwell the expresses very well what has been annoying me about Gladwell and his books.