Eh..no I am not arguing that one should not know the definitions. I am not sure, but I think your example is at the wrong abstraction level.
If I didn't know the grammar, the application would not compile and you wouldn't understand me.
But I suppose that you mean that knowledge of algorithms supply the definition of how one should write programs?

Actually I do not agree there either, as that is more in the realms of coding convention rather than algorithm design.
Now that is if I have understood that sentence correctly. Anyway, I really have no idea of how you came to that conclusion.

And I don't understand what thesis you are referring to? I am just observing the current state of affairs, not much thesis there.

And to quote myself: "One should know algorithms. I am not saying one shouldn't."

By the way, it might taste a bit funny, it is wrapped in a $100 bill since it was all that I had laying around. I have earned so many of them from my evil work.

Wow.
You can really imply lots of stuff about me, impressive.
But I am really glad I got someone like you to allow to respond, there are so many of you anti-framework-types out there:

* performance issues:
No, most performance issues, to my experience, has absolutely nothing to do with bad algorithms. Most, even crappy, algorithms finish very quickly, so users will never notice. And yes, that is what is important.
Rather, it has almost always to do with databases unmanaged indexes, bad SQL queries, loading unnecessary data.
Also, badly configured servers are no fund.
Strange proprietary wrappings of old functionality is also a dear old friend that needs mentioning here.

* security issues
- Is usually when people DON'T use frameworks, and make their own crappy solution that no one else understand and forgets to sanitize data.
- When in frameworks, is not usually about about bad algorithms, but unchecked buffers and stuff like that.

* Mixing OO with....hibernate?
Actually, I have before, but do not use Java at all. Or C#. And I actually don't work on building a dog ass slow monstrosity.
I mix whatever I think mixes well. There is nothing wrong in combining different tools into a tool chain.

If no one realize there is a problem. Is there a problem?

And...relax, dude. You are making all of us feel like we all are doing something wrong, and that's not cool, man...here, take a puff.

Yep, in those workplaces there are many positions where algorithm design and optimization takes up much time.

But you are still wrong. Most programming jobs even in those places are exactly as I described. We should not kid ourselves here. Even if you work at Wolfram, you will find that most work is made within existing frameworks and that a large number of its employees work as I described. Mathematica has a huge amount of non-algorithmic stuff.

So rather it is the framework that is the programmers toolbox. Because therein lies the algorithms. If you don't know it, you will use the welder for everything, cut the wheel nuts and eventually not be able to put the wheel back on.

One should know algorithms. I am not saying one shouldn't. But on the job making a common business application, it may actually take YEARS between the algorithms you have to make because you haven't found a solution in the libraries and the framework.
Most of the common algorithm writing, which usually concerned data juggling, have been replaced by SQL and collection member functions.
There are just very few places where any advanced knowledge of algorithms are needed nowadays.
Advanced structuring, however, is a different story.

They are most certainly not just big algorithms since they are pretty far off from meeting the requirements of an algorithm.
So read up, Fool : http://en.wikipedia.org/wiki/Algorithm

They are frameworks(of algorithms). Or libraries. Or whatever. Just not algorithms fer Gods sakes.

Rather, my attitude is one of realism. And it is, which might surprise you, based on actual knowledge.

Unreliability is choice, just as crappines and hugeness is. I have found that people very seldom are unaware of the fact that they are making crap. Actually, some of the most ugly and sickening solutions I have seen have come from brilliant programmers that perfectly knowingly wrote them. Just because the had very little time and knew this super-fast way to deliver something that worked. Ugliness is not always bad, it can also be a creative way of thinking out-of-the box to use a strange behavior to save a situation from imminent disaster.

Anyway, reliability, performance and elegance costs. And elegant, reliable and high-performing system is usually *FAR* too expensive to make from scratch.
This is why we have frameworks, because in them, stuff has been sufficiently elegantly solved, creating a platform from where the customers demands can be met.

But yes, inherently frameworks, as they are not one big algoritm, but masses of likely unused algorithms, makes systems bigger.

But they sure as hell don't make systems using them unreliable, quite the opposite. That makes me suspect that you haven't really thought that position through.
I'd say that rather, unreliability usually comes when programmers do not know how to use the framework or go outside its beaten path.

This is true. Saying they are not important made me feel better.
What a minute, I didn't say that!
I probably only felt better because I looked a bit beyond the algorithms...

The thing is, I know quite a lot about algorithms, and still I say these..these heretic things.

I also know many programmers that many times have come to me, bursting with pride over a fantastic algorithm that solved a problem with never before seen elegance, only to be brutally let down when I show them that this problem has already been solved, O(n), somewhere in the framework, or some utility library.

Rather, it is my experience that most people that say that algorithms are very important don't understand frameworks or how to apply them. Since they aren't good at it. Those of us that has been around since algorithms basically was the only thing there was and sorting meant implementing it yourself have actually had to learn this the hard way.
There are extremely few difficult algorithmical problems in day-to-day programming that haven't already been generically solved by the frameworks.
Of course, it depends on what you do for a living. It isn't black or white. Or Black or Scholes, as shown. :-)

After the outright slackers, the worst thing there is are the overthinkers and do-it-yourselfers. The waste vast amount of resources that could have been put to better use elsewhere than on stuff that is just another way to enable them to show off to themselves. They tend to create unnecessarily generalized and deep object structures that, while they can be tested completely and are academical perfection are simply too smart, meaning that they are very expensive to use.

When in doubt #1:
Keep it simple.

When in doubt #2:
Do you really have to do it your own way, are you f#"ing SURE the solution in the framework doesn't work for you? Remember, you have to maintain your crappy solution forever for the likely reward of later realising that you just didn't understand the framework.

I agree, and that is, as evidenced by my post, near the definition of "top coder" for me as well.
However, the "top coders" as described above are the not that way, the "top"-iness is quite obviously measured by algorithmic ability and knowledge alone.

Except that so very little of programming these days is about algorithms.
Rather, it is about elegantly solving businesses problems and to know one's way around huge frameworks.
Being a "top coder" is in it self a very good thing of course, but there are very few companies that actually work with technical details like implementing a better hash algorithm and so forth.

Rather, in most developers jobs, it is very valuable to;
* be good at being able to understand, handle and especially change large systems.
* be good at producing solutions that at a reasonable rate balances cost and customer demands versus simplicity, performance, structure and other technical values.
* being able to foresee the usages of the solutions in different time frames, and through this make systems cheaper and easier to evolve. Sometime, a super quick and butt-ugly solution is a really good thing to get the customer going while it figures out what it really wants. As long as all parties are aware of the situation and knows that a complete rewrite will have to be paid for next.
* not act like a stubborn child when ones pet solution or technology gets scrapped or unaccepted or that the rest of the company think it is risky to invest time in going down that road. But to just keep pushing.
* to be professional and keep on working even though the current thing is really boring.

Hm. What index would that be? There are many of them, but I just can't see Sweden at the highest places anywhere? Or even high? Or even not low?
I would also like to remind you that there are huge problems with the reliability of many of those indexes.

Also, why would poverty NOT be a reason for crime?

Does it run linux?

Hm.
I would like to apologize for really sloppy writing in the parent article..strange grammar all over, there was.
A bit tired there.

Actually, the problem is not singularly the calculation of the payroll which usually is nothing more than some reports. Of course, they might be heavy and all but database engines nowadays can really push data. It is about the fact that there are lots of similar stuff. Like when someone changes something historically, handling "tainting" and generate new accounting instructions. There are soo many use cases.
And you will do most of it in the database. Why? Because to not use set-based logic a la SQL when you handle huge amounts of data is not very smart.
If you wouldn't, you would have to dump ALL the data to the business layer structure and do advanced data operations like joins and so forth there.
Which, while obviously being possible, sucks and kills your mind. Also database client libraries consume lots of memory, and usually they are not the smartest memory allocators(because they don't have to be).
You will probably want to store states during execution and do it in parts, a huge batch either locks up the entire system for an unacceptable duration or makes you end up with a possibly corrupt dataset. Or at least not one you can always trust. So you cannot really do it in total isolation.
It is all in the little horrible details. Details that dawn on you when a system grow. Because it is all about detail.

No, really, there is nowhere else there are as many parameters and settings as in those cases where law is the logic.
The problem is also not their number, but the fact that they cut through abstraction levels the way they do.
Therefore problems often occurs just because you accidentally tried to do good. :-)
You really have to work with this kind of development for a while to realize its specifik set of problems.
On the contrary, the CAD example is one where you kan make beautifully generic code.

With regards to O calculations, they are not very useful in larger systems, they are great for evaluate algorithms. Systems are systems, and delays are far less about optimizing algorithms but knowing how databases indexing, database queries and their client libraries work, how memory is managed and doing stuff in the right order. Normally there are actually very few places where you do anything very advanced, algorithmically or mathematically(if we are talking about accounting).

Believe it or not, I have actually studied computer science and sorry, there are so many times one has to sidestep design principles in these cases.

To translate a syntax into logical constructs is really easy(ANTLR kicks aass, yay) . And actually, the language itself could be considered a programming language.
The problem is that all that haven't gotten you *anywhere* because law is about interpretation and systems about customer demands.
At some point, the law is interpreted, applied to your customers and translated into if...then...else.. . And you and your system will usually not be the ones that interprets it.
The driver is regulations and customer demand, and that often that translates into designing the system in such a way that it, for example generates the least taxation within the applicable legal constraints.
And here you just can't go wild with Monte Carlo simulations, but have to follow the usually very specific methods the certified accountant has specified as being OK. Compliance issues. And every larger customer has their own model...it is really problematic sometimes to try and cram them into the same system.

Building business systems is less about programming and more about system design, designing a system that can survive and even thrive containing with the madness it contains. Because it is by law required to contain it.

Let me guess..you haven't done much in the way in developing of large financial/business applications, have you?

It is certainly more complex than you think, and likely in a different way from what you think.

The problem is that it has to apply an insane amount of rules and exceptions to all calculations, which make the programming quite difficult and unclean.
For example, a pretty simple calculation may have 50 or 60 parameters or more, most of which are completely illogical and difficult to understand because they stem from law. Law is an utter mess of compromise, shortcuts and exceptions and as such very, very badly suited to provide the logical framework for an application. Still, it has to be applied when it is supposed to. Or incarceration will ensue.

For example, writing large functions is a definite no-no everywhere in development. It reduces unit testability and so much more.
However, in a financial applications, there are so many parameters and exceptions for everything that code becomes completely impossible to follow if you break if up like that.
However, that doesn't matter anyway since the complexity and fantastic amount of exceptions makes unit testing, though used of course, somewhat less effective. Most testing instead happens in the integration level.
It is very hard to optimize, and writing it in machine language would be quite insanely difficult. And off-the-charts silly.
Especially considering the efficiency of compilators of today.

In the old days systems were way simpler, had way less features(more of calculator replacements than systems) and was allowed to cost fortunes.

And juggling critical data in RAM is not something I'd suggest doing, the system has to keed serving clients and you need transactional support.
Even though such database engines exists, they are not normally used for these kinds of applications.

And NOTHING is inherently safe and productive. I assure you.

That's very, very strange.
However, http://blog.zimbra.com/ has stuff from november 2011 and they are obiously hiring : http://jobs.vmware.com/search?q=zimbra.com%2Fcareers
But still, it is owned by VMWare, I mean they must be aware of the impression a 2 year old "latest news" item gives to a visitor.

No, it is your argument that is fundamentally flawed, for several reasons:
1. The possibility to accumulate wealth isn't, luckily, the only incentive in society. If that was the case, we would have no other values or considerations, have no friends, and harvest each others corpses for organs to sell. Just the fact the emergency of social security systems has been proven incredibly important for the development of society as we know it, proves that it isn't.
2. It is VERY EASY to agree on a minimum cost of living. Usually it boils down to pretty small stuff, like if a cell phone and internet is considered basic(it usually is, since it would be a serious impediment in the current society to not have them). It has very little to do with desires.

Either, you have a society. Or you don't. A society inherently designed to accentuate income differences eventually create class structures and immobility. The United States has been very lucky in this regards, as there has been a constant availability of natural resources, influx of talent, room and war elsewhere, it has worked anyway. Now that many of these factors has been taken away, the U.S. cannot continue with the same model, as it depended on them. The current economic situation is obviously a symptom of this. The U.S. society has to modernize. And as much as that may hurt, that means more social security. It can be done right, or it can be done wrong.
Done wrong it sucks, done right, it is great. And I suppose that is the real problem.

I can't see how this matches anything else you have written? Your reasoning seems rather to be based on the everyone for themselves-attitude.