Teckla

I disagree with both of these assertions.

No need to buy new, let some other sucker eat the depreciation. A 3-4 year old Corolla (or equivalent) shouldn't cost more than $10k.

According to edmunds.com, your typical 4 year old Toyota Corolla will cost closer to $15k+.

Say what? Tax rates in the U.S. have been trending down for decades, especially for the wealthy.

http://en.wikipedia.org/wiki/Income_tax_in_the_United_States

See the section titled "History of income tax rates adjusted for inflation".

I'm interrupted by my boss far, far more often than I'm interrupted by my kid. A dozen times a day isn't unusual.

Let's be very clear on this subject, though: Microsoft was doing it for their own benefit. It wasn't altruism.

People keep saying this, and it keeps not being true.

C has something like over 200 undefined and implementation defined behaviors. That alone makes it a minefield of complexity in practice.

It's not.

I've tried for days to login to Outlook.com, and verification text messages aren't coming through.

I finally had to start the email recovery procedure, which requires a mandatory 30 day waiting period. Sigh.

This whole "some words are BAD" thing is ridiculous. I allow my child to swear, but of course, with a warning that some adults will take offense, because those adults are overly sensitive about silly things. So my child knows what to avoid around those silly people, but that it's okay around me.

I teach my child that words are tools, and tools are not inherently bad, but we may use them in a bad way. Similar to steak knifes, which are neutral tools, and can be used by people for good or evil.

I cringe every time I hear a parent tell their children that a word is bad.

In the end, my child doesn't swear any more or less than any other child of the same age. Interesting, that.

For the record, I use both Chrome and Firefox, heavily. The Chrome UI is very rarely laggy. The Firefox UI is often laggy. It's maddening, and I wish Mozilla would fix it.

That's not the only reason, and perhaps not the primary reason.

My wife made the jump to Mac four years ago. Yes, we bought VMware Fusion so she could run her "must have" Windows apps, too.

Fast forward four years, and she's discovered those "must have" Windows apps aren't "must have" after all. We've found Mac replacements for ALL of them.

No more VMware Fusion. No more Windows.

I didn't claim it would be pretty, I was just demonstrating that it's possible.

This description doesn't tell the whole story, leading people to a false conclusion of simplicity.

When it comes to JavaScript arrays, a lot of magic is happening under the covers that doesn't happen with non-array objects. Good JavaScript developers need to know those details, and that counts as complexity.

You're doing people here a disservice by leaving out relevant information.

When done correctly, object oriented programming is a lot like the Unix philosophy.

The Unix philosophy (in part): Write programs that do one thing and do it well. Write programs to work together.

Correctly done object oriented programming: Write objects that do one thing and do it well. Write objects to work together.

There's a lot of very poorly written non-OO code out there. Don't blame OO because there's also a lot of poorly written OO code out there. OO is, in part, a tool to manage code complexity. Blaming OO for complexity is like blaming Unix for complexity because there are too many programs in the /bin directory.

And now it's too heavy to carry around all day every day.

I'm not a smartphone user at all, but I do have an iPad that I use frequently.

I find iOS 7 sterile, lifeless, joyless, and flat. I like colors and depth, and iOS 7 seems all about being colorless and flat.

That's just my opinion, though. Others, I'm sure, enjoy the iOS 7 look and feel.

When necessary, manually cast your floats to doubles, perform the calculation, then assign the result back to a float. It achieves the same thing, though it is, of course, verbose. For example:

  float result = (float) ((double) floatVar1 + (double) floatVar2);

C... boring? I don't think so. Not with 200+ undefined or implementation defined behaviors. Not when even something as simple as "a = b + c" can evoke nasal demons.

C is so loosely defined that it keeps you on your toes constantly. Every single line is like walking down a dark corridor with poisonous snakes... and your torch just guttered out.

There's nothing boring about C. It's pure thrill and danger. If you're not experiencing that, you're probably writing terribly non-portable, brittle code, ready to unexpectedly invoke undefined or implementation defined behavior.

Not if you want multiple independently color corrected displays... (unless they added that feature post Snow Leopard)

Google Chrome for iOS crashes on a regular basis. It also fails to start YouTube videos a lot. Again, I consider those major products with major failures.

Gchat-in-Gmail has issues on a regular basis.

Also, non-major Google products have plenty of bugs. Google Groups digest emails have been broken forever. Once in a while one randomly trickles into my inbox, and I think for a second it may be fixed. Nope, still borked. Despite quite a bit of effort, I've never managed to communicate with any actual human Googler about it.

I've often had to authenticate twice, for unknown reasons, while getting into Gmail from Chrome, when trying to get in via their Gmail app icon.

I like plenty of Google products and services, and use them daily, but they seem to have their fair share of bugs.

You're not alone. I find checked exceptions to be an invaluable language feature.

How well does that work with tooling? For example, in Java, I frequently ask my tools, "Give me a list of classes that implement this interface," and I expect a fast and -- most important -- 100% accurate answer.

My instinct is that Go's approach makes it tooling-unfriendly (a good chance of false positives, especially in large systems), but perhaps I'm missing something.

In C, you can write code that doesn't overload errors and return values; e.g.,

err = someFunction(&returnValue, param1, param2, param3);

I'm not saying this is common -- and in fact the standard C library does a lot of the overloading you're talking about -- but for your own code and functions, you can separate out errors and return values, as shown above.

I find your requirements odd and vague (why big? why desktop?), but speaking just for myself: Eclipse, jEdit, CyberDuck -- all written in Java.

I use plenty of applications written in C and C++ too, of course; but I think that's largely due to (1) inertia in the application development industry, and (2) it took a while for runtime environments like the JVM to perform well, so they got a bad reputation early on that's no longer really deserved -- but the reputation persists in the minds of many developers.

Some of us would argue that JavaScript itself was that catastrophic event. No, really -- I'm not trolling. It's no longer reasonable for people to deny that JavaScript doesn't lend itself well to optimizing run-time performance.

These Herculean efforts are impressive, but perhaps it's time to fix the language, even if that breaks backwards compatibility.

How long will that continue to be true if Apple definitively loses the platform war?

It isn't about needs, it's about programming languages making it easier to write robust and reliable software. This benefits all developers, from inexperienced to masters. Even the best developers make mistakes and sometimes forget to check return codes.

Checked exceptions are just one useful tool in the toolbox. Another useful tool is dynamic strings (so that developers don't have to waste wetware cycles worrying about overflowing fixed size string buffers). Another useful tool is garbage collection (so that developers don't have to waste wetware cycles worrying about where and when to free memory).

These features lead to higher productivity and more reliable and robust software. Why wouldn't you want a tool that makes sure you check your return codes? Because it might force you to write "throws FooException" on your method signature, if you choose to handle that higher up the call stack? Oh, what a burden!

"You are never ever going to catch all possible exceptions anyway (runtime exceptions and errors are still there even if you'd prefer to have checked exceptions only)."

This is not a good argument against checked exceptions, this is an argument for using the appropriate type of exception for your current needs. Checked and unchecked exceptions are both useful tools.

Yes, sometimes developers use checked exceptions when they should use unchecked exceptions, and vice versa. And sometimes people use a big screwdriver when they should be using a hammer. Does that make screwdrivers or hammers useless?

"And you have to deal with them even if you use checked exceptions (again runtime exceptions and errors are still there). You have to have proper (unchecked) exception handling in the right places in your software."

I think you may simply be unfamiliar with when checked exceptions should be used, and when unchecked exceptions should be used.

Unchecked runtime exceptions represent conditions that, generally speaking, reflect errors in your program's logic and cannot be reasonably recovered from at run time; i.e., a bug in your program that will require code changes to fix. Generally speaking, you don't catch unchecked runtime exceptions, you allow them to bubble up to a high level handler. The high level handler will log the error and inform the administrator something went wrong, or display a (possibly localized) message to the user indicating that something went wrong, possibly requesting that they allow an error report to be sent to interested parties, etc.

Checked exceptions represent invalid conditions in areas outside the immediate control of the program (invalid user input, database problems, network outages, absent files). Generally speaking, you handle checked exceptions immediately (or almost immediately) and don't allow them to bubble up to a high level handler. These generally do not represent program bugs that require code fixes, it's just mundane but also important stuff your program logic should handle. By throwing checked exceptions in these cases, you eliminate a lot of burden on the caller to make sure they are handling all reasonable conditions.

"Are you actually properly producing tests for your code before deployment-time ? Otherwise I would not get it why it would be nightmare."

Not every code path is reasonably testable, plus tests are often the first thing to go during a crunch. Despite the best intentions, tests are not a cure-all. For best security, use multiple layers. For best software, use multiple layers. Checked exceptions are one of those layers: help your caller do the right thing, enforced by the compiler itself. Sure, tests are great, too.

"Bloat causes development drag and makes the code more difficult to understand (more scrolling, jumping to different locations in the same file, etc.)."

Since in real code you want to always handle return codes anyway, checked exceptions introduce no unnecessary bloat.

"I think you produce both. I'd compare here checked exceptions to unchecked exceptions like what staticlly typed languages are to dynamically typed languages. And I've seen a lot of developers "loving" statically typed languages because the compiler tells them all their errors (at least they think so)."

At this point I'm fairly certain your misunderstanding comes down to not knowing when and where to use checked exceptions, and when and where to use unchecked exceptions. You're conflating all exceptions into one gigantic indivisible entity and asking, "Why have both?" The answer is: because they're used for different things! I hope I've sufficiently answered that in more detail above.

I'm in favor of static typing over dynamic typing as well, but that's a whole other kettle of fish. However, I'm gratified to see that the wider developer community is finally accepting that static typing can be done in such a fashion that it's just as powerful and expressive as dynamic typing, but without what many consider unnecessary bloat or limitations. Languages will continue to evolve, and I'm confident static typing will win.

All of the above is colored by my application domain (I work on server applications that must run flawlessly for at least weeks, usually months, or even years at a time). Robustness and reliability is at or near the top of my list of requirements for a programming language. Different application domains may trade robustness and reliability for other things, which might make sense for those particular application domains.

Checked exceptions make my life much easier and result in more robust and reliable software, because I simply can't forget to check for things like "file not found" or "connection refused" or "invalid user input" -- my tools makes sure I do that. Thanks, tools!

(However, as a user as well as a developer, I wish all developers put robustness and reliability first.)

That was uncalled for. But, since you've decided to immediately call into question people's credentials, let me start with mine. I've done a little over 30 years of software development, and in that time I've programmed in no less than three assembly languages, several BASICs, Pascal, C, C++, JavaScript, dabbled with C#, dabbled with Go, dabbled with Python, been subjected to some Perl and PHP, etc. I'm not God's Gift to Software Development, but I think I have enough experience that my opinion on this matter shouldn't be discarded as uninformed.

"and starts with the antique assumption that the runtime/checked exception dichotomy is a good idea."

I hope you're aware that you're begging the question. In any case, I think checked exceptions are fantastic.

1. The "burden" of dealing with them is minuscule, especially when using modern IDEs. It takes just a few clicks or key presses to add try/catch blocks or re-throw exceptions as necessary. You don't even have to waste time looking up documentation (which may be wrong or even nonexistent). Your tool-chain (IDE and compiler) handles the mundane details for you.

2. It forces developers, who are often hurried, and who often make mistakes, to think about things that could go wrong, and deal with them (one way or another). Oh, sure, you see plenty of "catch (Exception e)" style abuses, but that particular "code smell" is so strong (i.e., easily identified) that it can make code reviews (personal and public) easier. Code reviews in languages with only unchecked exceptions are much more difficult and time consuming.

3. Checked exceptions speeds development. Much less time is spent reading and re-reading API documentation to make sure you've caught all the possible exceptions that might be thrown (so that you can do things like produce meaningful error messages or log entries based on the exception thrown).

4. Unchecked exceptions are a production run-time nightmare. My anecdotal but extensive experience is that languages with only unchecked exceptions cause far too many costly (in both time and money) production headaches. Never, ever defer until run-time, errors that can be caught at compile-time! Admittedly, it could be that my application domain colors my opinion here (I work on large systems, not small systems).

The best argument I've heard against checked exceptions is that they "bloat the code". It's true: checked exceptions requires more code. But I'm writing code, not poetry. My job is to get the implementation right (which checked exceptions help me do) and to write reliable and robust software. Developers who put more emphasis on writing pretty code (sorry, "highly expressive") might want to consider becoming artists instead, where they can fashion "pretty" creations to their heart's content.

What about people that prefer trading some battery life for some performance?

I've got some hard to access USB ports, too. I solved that problem by buying some USB extension cables (male on one end, female on the other). They are very inexpensive. Give them a try, you won't be disappointed. No more uncomfortable hunting for USB ports under the desk!