Apparently, that StackOverflow page is the source for the article. Even many of the comments that are in the article come from that page.

Recently, as in 1995 (it was introduced in VB4)? Having a distinct string concatenation operator has been a strength if VB for a very long time, however it does the same type coercion that JavaScript does. But, at least you don't look at it and assume it's doing addition.

At least they followed it. The trend today seems to be to break convention to stand out.

You can't make UX the documentation because it doesn't cover all of the use cases. UX is great for answering the question "What does this button do?". You need independent documentation to answer questions like "How do I mail-merge?". This goes double for processes where the industry standard term is trademarked, so you can't actually use it in your product.

Some of that is intentional. For example, they make using a debit card as a credit card difficult because it saves them money. Walmart is the only store I know that labels the button to do so. Sometimes I ask how to do it just to give back a little of the frustration.

It's much more Web 2.0 to create a user interface that's minimal to the point of being cryptic, and to call users that can't figure it out idiots. It also helps to have a complete lack of standards.

There's a lot of room for improvement in programming languages. New features aren't just novelty. The database/language impedance mismatch is still pretty big, language feature to support multithreading are still weak, strongly typed languages still need to handle "dynamic-ness" better. Microsoft has done a great job of introducing new features that people actually want while still maintaining backwards compatibility. Oracle is being way too conservative here and it does matter to their customers - even the big ones.

I spent a lot of time recently working at a fortune 20 company. Java was the official programming language of the company, but the Enterprise Architecture group was starting to lean closer to .Net when I left.

Java has been playing catch up with C# for almost ten years. Attributes, generics, and lambdas were all added to Java long after they were added to C#. Also, Microsoft made them part of the runtime, while Java only made them part of the compiler (for the most part), so the features work a lot better in C#.

The point of this article is that Oracle has been slowing down the pace of innovation to an even slower pace than Sun was at, and Sun had already lost a five year head start to Microsoft very quickly.

"runtime and a language with a huge install base" describes a future where Java just coasts. By contrast, Python, Ruby, and .Net are all runtimes and languages (several languages in the case of .Net) with a huge install base that are actively introducing new frameworks, development tools, and feature on a regular basis. I'm calling an interpreter a runtime for the purposes of this conversation.

The number of possible valid credit card numbers is so small that any hashing solution can be brute forced very quickly, even if each record has its own salt. The only protection would be to make the algorithm secret, but then you've just reduced your system to security by obscurity and as soon as someone figures out the algorithm, you're toast.

I wouldn't recommend Office Automation on a server if there is any alternative. For beginners, there's too many gotchas and for advanced users, there's plenty of alternatives that will do what you want without too much difficulty. Office with .Net is especially problematic because the COM components run as out-of-process servers and due to .Net's garbage collection and COM interoperability, they are difficult to get to shut down properly.

In the payment card industry, this is called a token, not a hash. The difference is that a hash can be algorithmically generated from the source material, while a token cannot. Because there is no forward link outside the entity that generated the token to go from card to token, the tokens can be different at each merchant, making a loss of token much less of a problem than a loss of hashes would be. It's also 100% infeasible to break the token generating algorithm since there isn't one. In my experience, tokens are simply generated sequentially (skipping those that don't pass Luhn check). Another beauty of tokens is that they can pass validity checks for credit card numbers, so they can be handed to third-party software and treated just like card numbers, but without the risk of breach.

They implemented it the way they did so they can sell it as a drop-in solution that requires no coding changes. Unfortunately, a security technologies don't matter as much as processes do, so this product, like all other silver-bullet products, will never be all that good.

You mean regular DBAs like the next Edward Snowden? Inside threats are important and are one of the reasons this feature exists. LitchField did what he does best; he showed that the product doesn't quite live up to the marketing material.

How would a hashed credit card number ever be useful? You would have a really hard time sending a request for payment to a payment processor if you did.