Apex is a proprietary language. Other than the foce.com Eclipse
plugin, there's little to no tooling available such as refactoring,
code analysis, etc.
True, but I could also argue that all languages are somewhat proprietary to some extent. WordPress and Joomla are both in PHP, but you can't easily port your modules and plugins between the two. Comparatively, if you're used to writing Java, you can write Apex Code fairly easily. Porting is still required, but I don't see that as a particular detractor.
Apex was modeled on Java 5, which is considered to be lagging behind
other languages, and without tooling (see #1), can be quite
Deployment is still fairly manual with lots of gotchas and manual
steps. This situation is slowly improving over time, but you'll be
disappointed if you're used to having automated deployments.
I could almost list the things you can't deploy automatically on one hand. The few minor annoyances that exist only affect projects that are doing very specific things. The only complaints one could likely still have is the trouble deploying Apex Code and Visualforce at once, when removing functions/members, and the block placed on scheduled classes.
Apex lacks packages/namespaces. All of your classes, interfaces, etc.
live in one folder on the server. This makes code much less organized
and class/interface names necessarily long to avoid name clashes and
to provide context. This is one of my biggest complaints, and I would
not freely choose to build on force.com for this reason alone.
You can use inner classes to simulate packages of sorts. While it's not as robust as true packaging, I've never found myself in a place where I absolutely need the organization. You're more likely to run into other limits, like the total code side limit (3,000,000 characters) before you run into other organizational problems.
The "force.com IDE", aka force.com eclipse plugin, is incredibly slow.
Saving any file, whether it be a class file, text file, etc., usually
takes at least 5 seconds and sometimes up to 30 seconds depending on
how many objects, data types, class files, etc. are in your org.
Saving is also a blocking action, requiring not only compilation, but
a full sync of your local project with the server. Orders of magnitude
slower than Java or .NET.
You're saving to a server. Sometimes the server gets busy. The new Force.com IDE that was open-sourced is much faster, and when the server isn't busy, saves can take a second or less. If saving is really a problem, you can also turn off automatic builds, and build at your leisure. Also, Ctrl-Shift-S to save all files at once triggers only one build/deploy when automatic builds are turned on, which saves time.
The online developer community does not seem very healthy. I've
noticed lots of forum posts go unanswered or unsolved. I think this
may have something to do with the forum software salesforce.com uses,
which seems to suck pretty hard.
SFSE hovers around 85% answered at the time of this answer. We are growing, and we are getting better. The developer forums were kind of chaotic, and I think they've been largely displaced by SFSE, which isn't a bad thing. There's a huge community on Twitter as well. Odds are, you'll get your answer.
The data access DSL in Apex leaves a lot to be desired. It's not even
remotely competitive with the likes of (N)Hibernate, JPA, etc.
I think inline queries and other natural queries are far better (on average), than most other languages. Part of it is a matter of preference, which seems to be the original author's nitpicking on minor nuances. I'd wager the original author probably doesn't like Java, either.
Developing an app on Apex/VisualForce is an exercise in governor
limits engineering. Easily half of programmer time is spent trying to
optimize to avoid the numerous governor limits and other gotchas like
visualforce view state limits. It could be argued that if you write
efficient code to begin with you won't have this problem, which is
true to an extent. However there are many times that you have valid
reasons to make more than x queries in a session, or loop through more
than x records, etc.
The limits have steadily increased over time, from 20 queries per transaction to 100, for example, and more DML limits, etc. The limits are there to protect the entire system. If you let a query gather up 1,000,000 records in a trigger, then that record will be locked for several minutes. That means more users getting more errors about concurrency locks. Yes, the governor limits are daunting sometimes, but usually you'll find that the page or transaction seems unresponsive (e.g. users will complain about how slow the system is) far before you'll hit a governor limit, in practice. And, over time, you'll naturally start to write more efficient code, making the entire system run faster for everyone. The same is true if you're a game programmer, application developer, etc. You want your users to be happy, and that means you want your code to be a lean, mean, processing machine. We're all on the same side.
The save->compile->run cycle is extremely slow, esp. when it involves
zipping and uploading the entire static resource bundle just to do
So, don't do that. Use one static resource per file, and you can edit them directly in MavensMate, Force.com IDE, etc. You should only package up the ZIP when you're finally done and want to upload a finished version.
In general, the pain of a young, fledgling platform without the
benefits of it being open source. You have no way to validate and/or
fix bugs in the platform. They say to post it to their IdeaExchange.
Yeah, good luck with that.
There's two types of bugs. Those you can fix, and those you can't. The salesforce.com application layer wouldn't benefit from being open source in any particular sense, and they do have an obligation to protect their intellectual property. And, before someone says, "well, open source projects get fixed faster because they have incentive to make it better", salesforce.com also has an incentive-- their jobs and their paychecks. They want to make it better for everyone, and not having chosen OSS isn't an automatic death indicator. Truth is, proprietary, closed-source code still tends to perform better than OSS on any given day. Compare the look and feel of Linux to Windows. I still prefer Windows for its aesthetics, even though I prefer Linux for its general security and power.
You can't package up your app and deliver it to users without
significant user intervention and configuration on the part of the
administrator of the org.
Most of the time, it's click on a link, next, all users, next, install. The post-setup stuff is usually related to the fact that salesforce won't willingly trample your settings (e.g. page layouts, etc) without administrator intervention. This is a Good Thing, and anyone that says otherwise is probably Crazy.
THERE IS NO DEBUGGER! If you want to debug, it's literally debug by
system.debug statements. This is probably the biggest problem I've
Checkpoints. They help. Also, the debugger in the Developer Console is greatly improving, including a timeline, profiler, etc. If you're not using the Developer Console, then I'd say you're not working most efficiently. Also, I don't test by debug statements, I test by unit testing. That's right. When something doesn't work, I write a test method, and simulate it. Takes all the guesswork out of what that debug statement means.
Also, with the Winter '16 release, there is a proper debugger available, but it does cost extra.
Even tho the language is java based, it's not java. You can't import
any external packages or libraries. Also the base libraries that are
available are severely limited so we've found ourselves implementing a
bunch of stuff externally and then exposing those bits as services
that are called by force.com
More language features added every release, even those that are pointless (String.equalsIgnoreCase comes to mind...). Of course, we still can't work in bytes (my biggest annoyance), nor zip/unzip natively, but barring these simple problems, I've never really came across a challenge (other than mentioned previously) that I couldn't handle. The language is competent. It doesn't need to be Java. It needs to do what it needs to do, and it does it.
There is no mention anywhere in even the most deep-dark technical
references of the common errors, or even the limitations of a given
api or feature
This is a problem still. Not a game-breaker, but I'd argue that it would greatly simplify my life if the documentation included limitations or caveats. Usually the documentation is all sunshine and rainbows, and there's not a cloud in the sky. This isn't the reality, and while their marketing literature should be this way, their documentation should not. The documentation isn't there to sell us something, it's there to help us use a system we've already bought.
Overall, I'd say that most of these "fears" are mostly unfounded, obsolete, or blown out of proportion. I've been coding on Apex Code since before the days when "bulk" was a keyword to indicate that a trigger could work on more than one record at a time. We've come a long ways since then, and it continues to evolve. The hardest part of coding salesforce.com is simply getting started.
There's a robust community to help you, increasingly better documentation, a versatile API, and a powerful, maintenance-free cluster of servers at your command to build The Next Great App, be it a blog, an ERP, an order system, license management, or almost anything else you can dream of.