Slashdot Mirror

What I want to know is what apps are missing?
Not counting games I do not really see any big gaps in the app store for Android.

It's the 80/20 problem all over again. Maybe 98% of users only use 5 apps, but it's a different 5 apps for each person. You listed 10 apps there -- I've got an iPhone, and I've only used one of them ever (and that one I have installed still but haven't touched it in the past week). I don't carry an iPhone for network-based music systems (it's already an iPod, duh) or to play social-network (not my thing).

For example, half of my top-5 apps are Japanese. Does Android even come with a Japanese input method yet? I know there's a couple in the Android app store, depending on what Android version you have (!!), but if I was in the business of writing apps, I'd be much less inclined to write one for a platform that depended on users having installed a third-party keyboard on their phone to use it fully.

I think it's pretty clear that success for a mobile OS requires a lot more than simply getting the right 10 big-name apps. The "big gap" is called "stuff I want to do" (for X million values of "I").

What should I say to him when we talk about this again?

Here

That should at least give you:

• Private offices
• A good catering arrangement
• Decent computer stuff to work with

Since he likes Joel, point him to http://www.joelonsoftware.com/items/2007/10/26.html (especially item 3 under "while we're at it": "Don't let managers badger developers into shorter estimates").

For an elegant argument against crunch time, point him towards Peopleware by DeMarco and Lister. And if he want's to hear it from Joel, check out this article

If he still thinks 11 hour days are smart, you should probably be looking for a smarter boss.

See this article for some examples about the efforts Microsoft goes through in their regression testing (especially follow through the links to Raymond Chen's blog). When Microsoft has a patch, they run it through huge server farms of boxes with hundreds of thousands of different configurations and commercial software package installed, making sure none of it breaks. Their patches include all kinds of extra workarounds to ensure software that relies on undocumented interfaces continues working.

I'm as anti-microsoft as the next guy here, but the cases really aren't comparable, and you have to give them credit for their thoroughness.

Rewriting from scratch is almost always the wrong thing to do.

Things You Should Never Do, Part I

Yeah, it's an "appeal to authority" argument. But it's been my experience that he's absolutely correct.

The only ones who win in this scenario are the consultants who are getting paid by the hour. Well, and your competitors.

I totally understand the urge when you inherit code from someone else. Heck, a lot of times, I feel the same urge when I go back to look at code I wrote 6 months ago. There's a reason that snarled-up nightmare was written the way it was. Make sure you understand that reason before you just scrap it and decide to start over.

Otherwise, you're just going to wind up with a newer snarled-up nightmare. It'll just have a bunch of bugs that were fixed (and left uncommented) in the existing version.

Lost money can come from multiple places:

• Man power spent fixing bugs. This is perhaps the most obvious, but it is unpredictable since you, by definition, don't know how many bugs you're going to have. However, you should be able to look at your defect rate versus time to get some idea.
• Man power spent writing tests. This is completely under your control, since you can decide simply to not write tests. Or you can decide to write copious tests. Or, anything between.
• The cost of lost sales due to poor quality. If you ship a total turd, your existing customers will start shopping elsewhere, and they won't send new customers your way. If you ship high quality product, though, that too ought to spread via word of mouth.
• The opportunity cost of lost sales due to product delays. If you ship sooner, you may get some critical customers that you'd miss if you shipped later. Of course, this breaks two ways:
  • One is that you delayed your product by being stuck in the "infinite polishing" phase. You have to be careful to avoid gilding the lily.
  • The other is that the development process itself got bogged down under the weight of its own bugs. Joel Spoelsky mentions what Microsoft called the Infinite Defects Methodology in which coding to get features took precedence over fixing bugs, and the product was delayed significantly by the weight of its own bugginess.

As you can see, it's not really a simple "testing saves money". But, laying all the pieces out there and showing how what you propose affects all these aspects might go a long way to getting at least something in place for a testing methology.

From TFA (the original, not the haphazard rewrite):

A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.

And here I was just reading Joel Spolsky's 10-year-old article "Wasting Money on Cats" earlier today:

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

Why should I care about distributed source code control in a monolithic commercial development environment? I can see its value in a distributed open-source project, but I really don't understand the necessity otherwise.

Let's let Joel (the original Joel) explain why in his own words: http://www.joelonsoftware.com/items/2010/03/17.html

Did Joel think this was important? You be the judge:

In that podcast, I said, “To me, the fact that they make branching and merging easier just means that your coworkers are more likely to branch and merge, and you’re more likely to be confused.”

Well, you know, that podcast is not prepared carefully in advance; it’s just a couple of people shooting the breeze. So what usually happens is that we say things that are, to use the technical term, wrong. Usually they are wrong either in details or in spirit, or in details and in spirit, but this time, I was just plain wrong. Like strawberry pizza. Or jalapeño bagels. WRONG....

...And here is the most important point, indeed, the most important thing that we’ve learned about developer productivity in a decade. It’s so important that it merits a place as the very last opinion piece that I write, so if you only remember one thing, remember this:...

...This is too important to miss out on. This is possibly the biggest advance in software development technology in the ten years I’ve been writing articles here.

Or, to put it another way, I’d go back to C++ before I gave up on Mercurial.

If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now.

Schlemiel the painter would be proud. Rewriting this with a block of comments describing the problem with this code, though, might be a reasonable excuse for learning how to touch-type prose.

In general, quality and correctness have never been major concerns of the Ruby, and especially Rails, communities.

Is that why Rails won't even look at your patch unless you have a unit test proving it does what you say it does?

The Ruby and Rails communities consider things like monkey patching and duck typing to be acceptable in large-scale applications.

Duck typing yes, monkey patching no. It's awesome that monkey patching exists, but the Merb guys introduced the idea that if you couldn't write a Merb plugin you wanted to with the plugin API (that is, if you had to monkey-patch), it was a bug in Merb. Merb has since been merged into Rails, so the same should be true of Rails.

It's a horrible idea to change code at runtime, especially when that code is part of widely-used standard classes like String or even Object...

Define "at runtime." These modifications are made at the beginning of your program, and they're made in every Rails app. You know that if you're going to use Rails, you're going to have these things. (This being Rails, I bet there's a way to disable it, too.)

They also don't interfere with any other usage of those core classes, to the point where one or two have actually been adopted into the language. It is a good thing that Ruby allows you to fix problems with the core language.

And compare to pretty much any Java servlet environment. Oracle's WebLogic, for instance, entirely stripped out and replaced the (working) SSL stuff and replaced it with their own broken shit that couldn't handle wildcard certificates. The only mechanism they provide for undoing that is to write your own HostnameVerifier and sort of monkey-patch it back to working the way it did.

So, talking about just the core hacks:

Not only does it reduce the quality of your own code,

How so?

it can easily affect completely independent libraries your app may be using.

Name one which is affected by this.

Then there are the ActiveRecord shenanigans.

Not going to try to defend this too much, as I use DataMapper, but...

It makes Ruby developers think they don't need even a basic understanding of relational databases, so they have no idea what it's actually doing under the hood.

That's too bad, but that's not the point.

The fact that something enables shitty code is irrelevant. The question is, what can a good developer do with it? Does it enable awesome code, or does it actively discourage it, the way some platforms do?

Well, that'll happen when your ORM fucks up and pulls in 1.5 million records into memory just to do some filtering that could have easily been done in the database.

You can as easily do this with any decent ORM. The point is that you shouldn't ever do that, because you should have an understading of how the underlying technology works. As Joel Spolsky says, "the abstractions save us time working, but they don't save us time learning."

See, I know SQL, and ActiveRecord and DataMapper make me more productive than writing raw SQL. If I didn't know SQL, yeah, I'd probably write some ActiveRecord that'd really suck.

I'd rather have CPAN's thousands of modules, most of which are extremely high quality and reliable, versus a larger number of shitty Ruby "gems".

I'd rather have thousands of high quality modules in a language I like, even if I have to sort through which ones are shitty or not (I actually like being able to make that call myself), rather than a language which looks shitty on its best days (and can be made to look like line noise).

Basically, Sinatra, Nokogiri, an

I honestly don't think either is true.

Programming is not a production line, and trying to turn it into that leads to inefficient programmers, bad code, and maintenance nightmares. Programming is an art, a creative process, and a science, and there are definitely people who do it better than others, and platforms which make it easier than others.

That's important. Think about a typical ad agency, special effects company, or pretty much any design field where you can hire a contractor for a project. You hire them based on their work, because their work is recognizable and valuable. You also hire them based on prior experience working with them, how well you can communicate your ideas to them, and so on. You can pretend they're replaceable if you want, which is partly true -- there are always other design companies you can go to -- but you certainly don't think of them as cogs in an assembly line.

You sure as hell don't try to design your process so you can replace a single artist at any time.

However, ideas are valuable. I can't speak for other programmers, but I'm absolutely lost on the business side of things. From my perspective, sales, marketing, ideas, and so on are just some of the things I'm very glad other people do, all as part of the Development Abstraction Layer. I'm hopeless without them, to the point where on one-man projects, I usually end up asking every prospective customer, investor, or just friends and family, for advice on things like naming a price.

I'm not sure how I feel about idea people learning to program. They try anyway, with spreadsheets. Sometimes it ends well, but often it ends in disaster. It's usually not a good idea to hire a dedicated full-time programmer to work on spreadsheets, and the whole point of spreadsheets is to enable end-users to do these things. Still, a few basic programming concepts would go a long way, even if they are in spreadsheets.

(No, I don't mean VBA. Either program or don't, but to half-ass it by crawling up out of excel into VBA is only going to end in tears.)

And I do like to think I'm working on something really cool. I certainly want my "code poetry" to have a point. It's not that I can't appreciate idea people or their ideas, it's that I'm not much of an idea person myself -- or at least, my ideas don't tend to be the sort that are likely to make me money.

Ahhhh, it's amusing to hear weenies talking about bloat and arguing for software that does less, which is what is behind that word. Sadly, that isn't going to get free desktops competing with Windows and OS X.

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

I have no sympathy for these organisations. When you create web applications that are designed for one web browser then you're going to get burned. Maybe they will eventually learn that Microsoft lost the API war, but I doubt it:

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

And, more importantly, are we talking about a real nail gun or about a machine gun style "kill space aliens" type of nail gun, and can I get a discount of some type?

I'm sorry to report that nail guns, machine guns, or factories for either are not available for sale any more. However, you might be interested in a factory factory, which you can use to customize your gun factory.

For details, please see:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12

This is a fallacy. Lots of internet sites don't have a financial model at the outset; that was practically the defining trait for dot-coms during the bubble. That does not mean the people building and running those sites do not have a financial incentive in mind, it simply means they're following a get big fast, Amazon-style growth model.

Wow, you're condescending, ain't you? I'm half convinced you just want to troll, but I'll bite.

Although for the past couple of years my primary desktop has run a BSD, I solely used Linux (mostly Debian, but quite a few others, including some that don't exist anymore) for the twelve years before that (except where required by work). So I'm quite aware of the traditional distinction between "OS" versus "applications." I say traditional because when it comes to Linux—as from your post I'm sure you know—this distinction completely breaks down. Everything is an add-on, an "application," including coreutils, the compiler, awk, Emacs, vi, Firefox, an ftp client, Shotwell, whatever—everything except the kernel. This is, after all, the whole point of a Linux distribution in the first place (Linux from Scratch notwithstanding), to let somebody else assemble a whole system which they then "distribute" and you download. That's fine. That's good, even.

The issue is not that there are multiple distributions; that's fine and good for the software ecosystem. The issue is that, for example, Debian's page for the virtual www-browser package lists no less than twenty-six packages which satisfy installing it. This is what I meant by "being all things to all people." I, the user, should not have to choose between 26 different web browsers. That's simply absurd. (For those people that actually want or need for some reason to install Chimera (the latest date in the copyright notice, by the way, is 1997), well, they're certainly entitled to ./configure && make && make install.) But for most users, this is too much choice. They've already chosen Ubuntu or Debian or Mint or whatever. Why should they then have to decide what web browser, or text editor, or office suite they want? It is the responsibility of distributions to pick reasonable defaults. I'm painting in broad strokes, obviously, but it seems like instead, nobody wants to say "No" so everything just goes in, and then the user chooses. And making the user choose means that Linux distributions will never have the userbase (because people are put off by too many choices) or the polish (because developer effort is dispersed where it could be concentrated) of commercial operating systems. That's my opinion, for what it's worth. Notable counterexamples would be Ubuntu (on the shiny side) and Slackware (on the austere side). But note what both have in common: they both have somebody who can say "No." So I guess they're really not counterexamples at all.

Oh, and to address your strawman: nobody, least of all me, said that an OS should tell a user to "get stuffed" when they try to install something not included with the OS. As I mentioned above, a user can always install from source. Or get someone to. Or application authors can provide statically-linked binaries. Et cetera.

There are literally hundreds of reasons that the ribbon is superior to menus. Perhaps many of those reasons don't apply to you, or you are simply stubborn and don't want to learn something new. There are of course reasons why the menus are better than ribbons, but too many people act like it's all or nothing... That either Ribbons are better or menus are better, for everyone. Period. What's worse, most people argue reasons that aren't even true, like there being no keyboard shortcuts or that they're different keyboard shortcuts than they used to be. Or that the ribbon takes up more space (which it doesn't, especially if you auto-hide it)

I would be inclined to agree with your argument (well, not the "hundreds of reasons" part), if not for the fact that Office 2007 does not give users the choice. Any user interface programmer knows it would be trivially easy to allow switching between the ribbon and a menu bar. But Microsoft has deliberately kept that capability out. There used to be a Knowledge Base article that flat-out stated "you can't switch from the ribbon to a menu bar, and we did it that way on purpose." But I can't find the article anymore.

A good user interface satisfies all (major) user groups. It's usually not that difficult.

But, here's a few examples.

Menus are hard for people without fine motor control to use. If you are old, disabled, or simply not very well coordinated, ribbons will be much easier to use than trying to make your mouse follow the narrow paths that make submenus show up.

You have heard of the mile high menu bar, yes? It's true larger buttons are better than smaller buttons, especially for people with impaired motor skills. This actually suggests not that ribbons are easier to use than menus, but that they are easier to use than the tiny little toolbar buttons on the vast sea of Office toolbars.

The menus have become monstrous, with more and more features being added to apps, it's harder and harder to find the items you're looking for. The ribbon allows better organization, and "context sensitivity".

Yeah. That's not the fault of menus, that's the fault of the designers' inability to effectively organize the functions of the application. Rather than spend the effort to actually organize things, they tried "Personalized menus" (the visual equivalent of sweeping things under the rug) and when that failed, well, we got ribbons.

The ribbon is far more intuitive to new users.

The ribbon scales to your screen, making buttons smaller if you have less room and changing various other sizes.

I haven't seen any evidence, or even anecdotes, that suggests it's more intuitive. What I have seen is a few decades of accumulated observations that report that a consistent and stable user interface is crucial. Users can't build a pattern of behavior, much less muscle memory, if the controls are moving around all the time. It's like trying to become a touch-typist when the keyboard wants to rearrange itself based on the words you've recently entered.

I have also seen a few decades of accumulated observations that users should be able to list or otherwise examine all of the functionality available to them. That's why it's better to disable or gray out controls than to remove them. The user can't try out a function if he doesn't know it exists because he never saw it in passing while navigating for other functions.

In fact, it's counterintuitive, because it's trying to second-guess the user's wishes by "smartly" showing the "needed" controls. I would have thought Microsoft learned its lesson regarding second-guessing the user with an amateur attempt at AI, after the debacle that was automatic outline numbering in Word 97.

The ribbon provides live previews

...had to bludgeon Netscape to death to win

Wrong! Joel Spolsky had a different take: http://www.joelonsoftware.com/articles/fog0000000069.html

Great post, here are some more reasons why Microsoft Project is simply not on the critical path any more...and it does not stop with Microsoft Project...

Today with rapid development, testing and release that is Agile, I am unaware of a single software development shop that is wasting time putting up a Project Management project. Once you have a sustainable velocity, not only are your developer's happier, but your customers are seeing you fix problems more rapidly as well. Its smart and a win - win - win - win.

Years ago, thanks to Joel on Software I took a hard look at project management in general. It really opened my eyes to how much time can be wasted if you are not careful. When I looked at the differences between Microsoft Project and Open WorkBench, I found Open WorkBench to be superior. The fact that Open WorkBench saves a company significant money as compared to Microsoft Project, simply makes it better. The Savings vs Buying Microsoft Project as of Sept 19, 2010 are listed as $350,855,864 and that is for only 585,736 downloads.

Since most organizations are resource-constrained rather than time-constrained, the resource-based scheduling in Open Workbench typically provides a more realistic plan in less time. ~ that just makes sense to me and is obvious.

Even though Joel does not want you to read about Painless Software Scheduling and he wants you to read instead about Evidence Based Scheduling, from a KISS perspective I discovered that I was able to do rapid estimating of projects using a spreadsheet. In fact before I ever started putting a project in Microsoft Project (when a company required that tool) I would first use Joel's method using an Excel spreadsheet. Naturally when I moved from Windows to Linux I found that OpenOffice Calc did everything that Excel would do. I will freely admit that there are things that some people do with Excel and Macros in Excel specifically that I would never do and/or use. In fact I have programmed some of those Macros for small businesses that insisted using Excel as their tool. However I have always felt that it was smarter to pick the correct tool for the correct job. If it is honestly Microsoft, so be it. In most cases, Macros and Excel are NOT better than open source software dedicated to that business function. From a pure Macro standpoint, there is nothing that one can do in Office Excel, that can not be done in OpenOffice Calc. And the price is right. From my perspective, OOo Calc is far superior!

My lesson did not start there, nope, I learned along the way with other smart purchases after doing a feature by feature comparison of products.

Many years before I needed a Graphics package to create, edit and reduce the size of images for the web. At that time, PaintShop Pro could do everything that Adobe PhotoShop could do at about 1/10th of the Price. It was a no brainer...I bought PaintShop Pro. (PaintShop Pro should not be mistaken for Microsoft Paint.). When the company that produces PaintShop Pro mistakenly attempted to force me to update my Windows operating System before using their new version of PaintShop Pro, I borrowed a Laptop running the new version of XP and installed PaintShop Pro on a USB device (yes they did try to prevent that in the install process, however if you know what you are doing

Great post, here are some more reasons why Microsoft Project is simply not on the critical path any more...and it does not stop with Microsoft Project...

Today with rapid development, testing and release that is Agile, I am unaware of a single software development shop that is wasting time putting up a Project Management project. Once you have a sustainable velocity, not only are your developer's happier, but your customers are seeing you fix problems more rapidly as well. Its smart and a win - win - win - win.

Years ago, thanks to Joel on Software I took a hard look at project management in general. It really opened my eyes to how much time can be wasted if you are not careful. When I looked at the differences between Microsoft Project and Open WorkBench, I found Open WorkBench to be superior. The fact that Open WorkBench saves a company significant money as compared to Microsoft Project, simply makes it better. The Savings vs Buying Microsoft Project as of Sept 19, 2010 are listed as $350,855,864 and that is for only 585,736 downloads.

Since most organizations are resource-constrained rather than time-constrained, the resource-based scheduling in Open Workbench typically provides a more realistic plan in less time. ~ that just makes sense to me and is obvious.

Even though Joel does not want you to read about Painless Software Scheduling and he wants you to read instead about Evidence Based Scheduling, from a KISS perspective I discovered that I was able to do rapid estimating of projects using a spreadsheet. In fact before I ever started putting a project in Microsoft Project (when a company required that tool) I would first use Joel's method using an Excel spreadsheet. Naturally when I moved from Windows to Linux I found that OpenOffice Calc did everything that Excel would do. I will freely admit that there are things that some people do with Excel and Macros in Excel specifically that I would never do and/or use. In fact I have programmed some of those Macros for small businesses that insisted using Excel as their tool. However I have always felt that it was smarter to pick the correct tool for the correct job. If it is honestly Microsoft, so be it. In most cases, Macros and Excel are NOT better than open source software dedicated to that business function. From a pure Macro standpoint, there is nothing that one can do in Office Excel, that can not be done in OpenOffice Calc. And the price is right. From my perspective, OOo Calc is far superior!

My lesson did not start there, nope, I learned along the way with other smart purchases after doing a feature by feature comparison of products.

Many years before I needed a Graphics package to create, edit and reduce the size of images for the web. At that time, PaintShop Pro could do everything that Adobe PhotoShop could do at about 1/10th of the Price. It was a no brainer...I bought PaintShop Pro. (PaintShop Pro should not be mistaken for Microsoft Paint.). When the company that produces PaintShop Pro mistakenly attempted to force me to update my Windows operating System before using their new version of PaintShop Pro, I borrowed a Laptop running the new version of XP and installed PaintShop Pro on a USB device (yes they did try to prevent that in the install process, however if you know what you are doing

Check out Joel on Software blog. http://www.joelonsoftware.com/articles/BionicOffice.html He has a nice series of articles on designing his new office space for programmers. Much of it is not relevant to your exact situation, but you will find some good ideas (desks that can be lifted into a standing position for instance.)

though it still desperately needs a rewrite as TFA says

Arguably, a thing you should never do...

Another way older people can be great technically is to be like Bill Gates - MyFirst BillG review. Note the part where billg had read the entire spec.

He may be a rat business-wise, but he has been sharp and technically very fit.

Disclaimer: I've loyally used only free software for the past 3 years and it is much better than Microsoft products

Fun Google result:
I googled for "rich aged computer programmer" looking for the hotshot who runs an controls systems automation programming company, is in his 50s/60s and also codes daily. And guess the first result:

Richard Stallman - Wikipedia, the free encyclopedia
Richard Matthew Stallman (born March 16, 1953), often abbreviated "rms", is an American software freedom activist and computer programmer. ...

:-)

True - If being able to program isn't part of the job requirements, then of course you shouldn't test for this.

If it is - and in our case it is even for higher-level positions such as software architects - then using automated testing makes perfect sense as a first automated screening. Later on in the interviews you check for other abilities.

Another benefit of having candidates do screening tests first is that you already have base material to discuss with them to evaluate other aspects (and verify that they didn't actually 'cheat', that is, know the questions in advance) - you can have them parallelize the solution, change it based on new requirements, fix all the boundary cases they didn't have time to fix during the programming assignment, etc. Saves a lot of time having some code already instead of sitting there waiting for them to write the code in front of you, and going through problems like this together with the candidate gives you an idea of how they think, if they're smart ("gets it"), gives up easily, etc. We're big believers in Joel's Guerilla Guide to Interviewing, and automated tests fits perfectly with this way of interviewing.

I'm sure I'll get flamed for quoting him, but I've always loved Joel Spolsky's description of Netscape's "testing methodology":

This poor company did an almost supernatural amount of damage to its reputation through their "testing" methodology:

1) when the programmers are about halfway done, release the software on the web without any testing.
2) when the programmers say they are done, release the software on the web without any testing.
3) repeat six or seven times.
4) call one of those versions the "final version"
5) release .01, .02, .03 versions every time an embarrassing bug is mentioned on c|net.

Read Joel Splosky's "How Microsoft Lost The API War", particularly the "The Two Forces at Microsoft" section. http://www.joelonsoftware.com/articles/APIWar.html

That depends how "promptly" you really need, and how much you care about memory usage.

One common performance hack is to use an allocation pool specifically for your own application, so you can malloc/free in large chunks.

But garbage collection does exactly that, it just doesn't require you to manually track memory. It might even be faster at it -- you may shudder at the thought of stopping the world to collect garbage, but consider that while garbage collection is idle, you have very little memory-related code running at all, meaning your code is smaller and faster -- significantly so, when it means fewer cache misses. The garbage collector itself could likely fit into cache while it's running.

There is something garbage collection can't account for, and that's freeing an object as soon as you're done with it -- but people often override malloc/free with some sort of pool management system. I suppose you could make the point that it's useful to free memory back to the system as soon as possible, but then, malloc/free, at the system level, have garbage-collection-like performance characteristics.

About the only reasonable argument I can think of in favor of manual memory management is the same argument that's in favor of assembly language -- programmers are by definition better at deciding what should go into registers than compilers are, in that programmers could, at the very least, take the output of a compiler and hand-optimize it. People do still hand-tune performance-critical bits in assembly, and I think the ones who are doing it right are hand-tuning performance-critical bits in C, as is often the case in Perl, Python, and Ruby.

But so far, I'm only comparing which gives you a faster system, in terms of either memory or CPU. I think GC is close enough, and often faster than manual memory management -- but even if it was a 2x or 4x performance hit, I'd much rather have a program even ten times slower that never segfaults or leaks memory.

I just hire people that are smart, good problem solvers, and seem to have a personality.

This sounds a lot like Joel Spolsky's "smart and gets things done" test.

Yes - perhaps the slashcoders should read http://www.joelonsoftware.com/articles/Unicode.html ?

Developer licensing and sales of Macs to developers that don't have them don't even show up in Apple's bottom line in any meaningful way. Sales of iPhones, however, are a huge part of their profit. Apple is about making money, but they're not idiots that want to nickel and dime people in ways that will lose them larger amounts of money in the long run.

But I didn't mention only the SDK fee and computers. There is also the bit about the revenues generated from the application in terms of Apple's cut of the sale price of the applications and/or any cut they get from integrated ads in those applications. That revenue is significant. Again, as a profit maximizing firm, there is little compelling reason for them to turn away that revenue.

Apple makes a lot of money selling Macs as well as phones. By promoting HTML5 (which you can compile into an app in the iPhone store, by the way) they push Web standards that helps their Mac business greatly by decreasing the amount of lock-in and the number of users tied to Microsoft.

I doubt very seriously that Apple intends to commoditize the operating system when the exclusivity of that operating system is a major selling point of the hardware with which they make the bulk of their money. Joel Spolsky did a write up of how this strategy wound up being a problem for Sun's hardware sales with Java. But recall that prior to the release of the iPhone SDK, HTML was presented as the way to develop applications for the iPhone. Just because they promote HTML5 now does not mean they intend for that to be the preferred way to develop simple applications in the future.

Of course, guessing the intentions of Apple and what their future plans are is just speculation, but since there is lost revenue at stake in terms of the App Store and advertising, the possibility of commoditizing their operating systems, and a specifically relevant history of changing the recommended development path from HTML and to their own development ecosystem, I see little incentive for them to continue pushing HTML5 as the development platform of choice from simple but useful applications. Also, since HTML5 cannot interact with the device specifically (e.g. sensors, contacts, etc.) in any meaningful way, some useful but simple applications requiring that level of interaction will not otherwise be created. But that is just my speculation.

I don't agree with everything Joel Spolsky writes, but he understands Microsoft fairly well (since he's an ex-Microsoftie) and explains this exact problem fairly well:
How Microsoft Lost the API War

heh, seems it was the win3.x version, not the dos version, but still:
http://www.joelonsoftware.com/articles/fog0000000054.html

I bet if they rewrite the whole thing, they could finally get rid of all the crashing and memory leak problems! ..oh, wait...

Never ever do business in China? Ever? Can you be certain that strategy won’t change next year? Or even tomorrow? This king of lazy thinking is how we got the Y2K nonsense in the last century. You're not one of those people with an allergy to unicode, are you? ( http://www.joelonsoftware.com/articles/Unicode.html )

Have a numeral in your name? Too bad.

Why? What do you gain by not letting someone enter a numeral as part of a name?

Need some names to be case sensitive, and others case insensitive? Sucks to be you.

This is more reasonable, since it would take some effort to accommodate (How do you determine which names are case sensitive? A flag just for that purpose? Ick.)

Have a 200 character name that doesn't fit in the 100 characters the designers thought no crazy person would ever have? Tough.

Dynamic memory allocation should be used as a matter of course for any strings whose sizes do not have a preset limit. In SQL, it should be ntext; though I dislike hard-coded limits on principle, one billion characters should be enough for anybody.

But assuming the worst and trying to design a system that'll allow people's names to be Chinese characters when you don't do business in China, have presence in China, or ever ever plan to? That's ridiculous,

Because that means you'll never do business with Chinese people. Ever. Or Japanese. Or Bulgarian. Or Russian. Or Arabic. Or... Proper Unicode handling is not that difficult and should be standard routine whenever your program handles strings. It enables your program to handle not just Chinese but *any* non-English character set. And you should NOT be assuming your program will handle only the English alphabet. See this.

Since this was the first post asking the question on how to inject sql when paramters are used. When the statment that parameters do not protect the person who is making the statement wants to beable to pass table names into the select statement, in the FROM portion, and you cannot paramaterize table names. Yes they are missing the point. The other example I have been given is they want to pass generate a complete where string pass that through a parameter and expect that the parameter will provide protection.

Except for the very extreme edge cases that need them, what sort of a deviant, over-engineering architectural astronaut code monkey designs a system with pass table names in the general type of web-facing systems?

Assuming one really needs to pass table names, I doubt they would be passed directly as parameters (but instead be computed from them through internal means not derived from their string representations.) And if we really want to push the envelop and indeed want to somehow expose table names that way, just wrap the hole thing in a stored procedure that constructs the SQL statement internally after successful validation and sanitation of parameters (which should be happening no matter what).

All that complexity to protect against attacks to a feature (passing a table name as a parameter) that no sane developer would ever expose in a web-facing system. Oh boy.

One thing for certain is that even when using prepared statements, one still has to validate and sanitize all parameters. More importantly, one has to structure code so as to be able to spot security issues during code inspections (which should also occur no matter what.) Joel Spolsky wrote something to that effect a while ago. People should read that and learn how to code properly rather than trying to find silver clutches : http://www.joelonsoftware.com/articles/Wrong.html

As much as I like good code, people like that are not doing their job. Clean up code as much as you have time for while doing your own job, but when you start missing deadlines you visibly cost the company money. Best course of action would be to note down dirty code for after release so that your manager can give you time to write a patch for important issues.

Like it says in this entertaining article:
http://www.joelonsoftware.com/items/2009/09/23.html

"Shipping is a feature"

It also looks like an implementation of what Joel Spolsky recommended a while back (search for the stuff about hungarian notation):
    http://www.joelonsoftware.com/articles/Wrong.html

I couldn't agree more, but that's very expensive and very very dangerous. Why? Two factors:
1. Rewriting means rethinking; most legacy code is functional and is usually rebuilt in OOP. Whenever you rethink how something works it tends to change the entire behavior to say nothing of all the new bugs you'll have to hunt down. You're customers will definitely notice this.

2. Scope creep!! Rebuilding it? Why not throw in all that cool functionality we've been talking about for the past 10 years but couldn't implement because the architecture couldn't handle it. You get the idea.

Want an example? Netscape 5

Dinky company, perhaps, but quite successful at a personal level. In less than ten years, Joel took his company from zero to seven million dollars per year by my accounting.

http://joelonsoftware.com/articles/BionicOffice.html
$700 per employee in the original office

http://joelonsoftware.com/items/2008/12/29.html
"built for 18 employees" = about $12,600/month

http://www.inc.com/magazine/20080601/how-hard-could-it-be-adventures-in-office-space.html

"When we moved into our current offices, our rent had been equal to 15 percent of revenue, which was high. But the company grew, and today our rent is only about 2 percent of revenue."

So revenue was $84,000/mo ($1,008,000/yr) and is now about $7,500,000/year.

So he's not a complete waste of space. And he may not be God but that doesn't mean he's never right and/or never worth listening to. READ THE F ARTICLE about rewrites--plenty of Slashdotters (you included) have been here long enough to know that at least, his example about Netscape/Mozilla is 100% accurate. They lost YEARS because they chose to rewrite everything.

And judging by the comments here, I think a lot of people are reading the title and thinking he's saying "never make any changes." That is 10000% NOT what he is saying. He's saying "never throw away 100% of your code and start over from scratch." If you actually read his original article (I know, I'm new here) you'll see a lot of really good points.

Joel isn't God, but he isn't just some stumbling moron either. There IS a continuum between those two extremes, you know.

Here is a article by Joel, a former MS manager: http://www.joelonsoftware.com/items/2006/06/16.html

It's not about being too difficult. It's about being way too overcomplicated.

Let's look at the code.

        config = boto.config

okay here. We need config.

        bucket_name = "dogs"

remote dir. So they made a half-assed directories system. Can't be nested, data can't be outside them. Piss-poor but let's say "okay" here.

        name = "poodle.jpg"
        dir_name = "pets"

so far so good.

      src_uri = boto.storage_uri(bucket_name + "/" + name, "gs")
      dst_uri = boto.storage_uri(dir_name, "file")

seems logical if slightly redundant. So we need some objects instead of plaintext names...

        dst_key_name = dst_uri.object_name + os.sep + src_uri.object_name ...wtf... oh, we are trying to create a local filename... that's some convoluted way to do it.

      new_dst_uri = dst_uri.clone_replace_name(dst_key_name)

err... so our local disk file needs to be placed at... "pets/dogs/poodle.jpg". Now that's some way to get there!

      dst_key = new_dst_uri.new_key()

oh, that was just the NAME of the new key... so we need the actual "key"... again, what for?

      src_key = src_uri.get_key()

again, if we have the URI object, why do we need some "key" object? Isn't the dedicated URI object good enough?

      tmp = tempfile.TemporaryFile()
      src_key.get_file(tmp)
      tmp.seek(0) ...can't we read directly from a file instead of creating temporary one? So the "uri" of a file is not good enough, the "key" of a file is not good enough, we need a "tempfile" object extra?

      dst_key.set_contents_from_file(tmp)

I recommend a reading about a hammer factory factory factory. This one doesn't overdo factories, just abstraction layers. I can spot four: filename (string), URI, key, file handle within the key. WHO needs that???

Everyone knows about the log off button design team now surely? Overstaffing is the root of many problems. Once someone has a team, they have to keep feeding the team, and grow its responsibilities, or they lose manager status. So you fight with other parts of the company to keep your own job. Not healthy.

http://www.joelonsoftware.com/items/2006/11/21.html
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html
http://www.joelonsoftware.com/items/2006/11/24.html

Everyone knows about the log off button design team now surely? Overstaffing is the root of many problems. Once someone has a team, they have to keep feeding the team, and grow its responsibilities, or they lose manager status. So you fight with other parts of the company to keep your own job. Not healthy.

http://www.joelonsoftware.com/items/2006/11/21.html
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html
http://www.joelonsoftware.com/items/2006/11/24.html

Everyone who agrees with parent, please read this article NOW.

You don't learn C for the syntax, you learn it for the side effects.

And you learn Haskell to avoid the side effects...

But just because some exhibit great programming skills w/o having been exposed (at least cursorily) to C, that does not mean that extends to the rest.

On a related note, some people think the real value of early exposure to C is that it weeds out the chaff.

TL;DR:

Well, others would argue that Scheme is an even better language for this purpose.

But just because some exhibit great programming skills w/o having been exposed (at least cursorily) to C, that does not mean that extends to the rest.

On a related note, some people think the real value of early exposure to C is that it weeds out the chaff.

TL;DR:

But beyond the prima-facie importance of pointers and recursion, their real value is that building big systems requires the kind of mental flexibility you get from learning about them, and the mental aptitude you need to avoid being weeded out of the courses in which they are taught. Pointers and recursion require a certain ability to reason, to think in abstractions, and, most importantly, to view a problem at several levels of abstraction simultaneously. And thus, the ability to understand pointers and recursion is directly correlated with the ability to be a great programmer.

Nothing about an all-Java CS degree really weeds out the students who lack the mental agility to deal with these concepts.

Serious,

All those novels / movies based on the premise that technology advances to the stage where we no longer know how to create or fix things starts with forgetting about C.

Read that article for a very brief and informative lecture on why C is critical to the progress of technology.

- Dan.