It makes absolutely no sense for MS and Apple to follow suit, google originally introduced the combined bar to increase their search revenue. Now, when someone asks “Can I get a separate search box?” without exception the reply is “Why do you want a separate search box?” as if you just need more convincing this thing is AWESOME.

It’s probably something that will get reintroduced to major browsers in a few years as a special feature once the novelty wears off, and no end-user feels idiotically proud of their integrated search box anymore.

Probably the biggest thing I miss about having a separate search box is the ability to choose from several search providers from the list. Google’s way of typing a letter then space for a certain engine is just not as good as CTRL + up or down to scroll through the list.

Upon leaving this great blog I would like to take the time to discuss a EMS (yes you may google it)
I recently designed and implemented in little over 3 months from ground up. An EMS is a highly sophisticated and advanced piece of software that is pretty fucking far from the day-to-day programs that mostly never does anything more important than fetching rows in a database based on some key.
If someone had told me that they designed such a system AND delivered it to production in less than 4 months I would definetely call them a liar, because it simply cant be done.

But I and two more guys did it.

On the first day, when I met the team I told them the basics: This system is gonna be a straight procedural system, simply because we have no time to wonder about what kind of objects we should use to represent real-world entitys. If I see a class definition anywhere I will delete it.

You see, most ‘modern’ day programmers have gone completely bananas over all the patterns that exists that they actually forgot that it is possible to create really great apps with really little code.

If you want to that is…Just have a look at the app-industri. These guys that dont have access to the big supermotor that a pc is, and actually have to household with what they got wouldnt get far if the tried to build some of the monsters that is the result of a pattern such as MVC.

In my opinion if you use MVC you are an idiot.

Because you are writing code that never had to be written in the first place. And that statement is also true for any other pattern that exists out there like OO and multi-tier etc. And I am probably the biggest idiot of all for having believed in these patterns and actually built a whole lot of systems in them.

They are wrong and dont work and thats it. No need to cry about it, just forget them

My 0.02$

Best wishes

/A

You also touch on one of the comments that prompted me to write this a while ago – that someone asserted “this isn’t SOAP, therefore it’s bad” – as you rightly point out, what they really mean is “this isn’t written in the flavour of the month, or isn’t written how I would choose to do it today”, and lacks any understanding of why it is written the way it’s written.

Where I disagree is that a straight procedural system is always better… It’s often very clear, but then, MVC has its uses, functional programs are often significantly clearer in their intention (though often not in their runtime characteristics).

First, I would like to give some input on my background so you can understand my background. Having spent spent some 15 years as a developer (consultant) I have had ample opportunity to look at some really bad and some really good systems.

It depresses me a lot to see, too often that a system is chucked in the bin and replaced by an almost exactly twin. The system that prevails over time and thus honors its creators are often the simple system. The more ‘advanced’ systems…well no one has the inclination the expand on them as they are too tedious to maintain and often you will have to rewrite so much of it anyway.

When I say simple, I indeed support the idea of ‘writing down’ to the reader and fully enforcing the KISS rule. Who am I to believe that the next developer is competent in the language/environment?

Therefore I conclude that ‘Good’ code is, roughly speaking, an expansion of a few lines of the aforementioned compressed oneliner.

This is especially true in an SQL statement where the readability of the code is tenfold if you divide your composed statement into several small parts.

This discussion, as refreshing as it is, merely scratches the surface of the issues of building good systems. The make or break factor is never about the syntax but of the complexity of the system itself.

Therefore a lot of idiots buy into whatever pattern is popular for the day, OO, multi-tier or the most recent one MVC. With that kind of arsenal at your disposal you can get into a lot of trouble. Just to explain a little on what I mean I would like to state an example.

Imagine a new technology that is coming, you are excited about building some system in it. This is your first time. Do you think it will be good? No, probably not. You actually wont build it ‘good’ until you build it for the third or fourth time. The nature of most programmers however is to constantly improve and therefore the are constantly moving on to the next pattern instead of excelling in one pattern.

In my opinion therefore a straight procedural system is always better over any other pattern, giving you ample time to reflect on what problem to solve instead of the inner workings of an architecure that goes sideways from the the organization from day 1 it is implemented.

This is not my humble opinion it is the facts of how it works in reality.

Thank you for your time and Godspeed with your next system.

/A

I don’t agree with this statement. It all depends on context. There are many times when using a particular concise expression is more readable — for someone who is competent in the language/environment. Who is doing the reading matters: a beginner or a professional. Just because something is difficult to learn does not mean it isn’t good. Here’s a simple example:

char* strcpy( char* to, const char* from )
{
while( *to++ = *from++ )
;
return to;
}

This is much easier to understand for an experienced programmer than the expanded “simpler” equivalent code.

I do agree that compressing lines just because you can isn’t good. For example:

if( (answer = myfunction( x, y, z ) )
…
should probably be written on two lines as:
answer = myfunction( x, y, z );
if( answer )
…
especially if myfunction has a longer or more complex list of arguments.

In programming, as in writing, say what you mean directly and simply. Don’t intentionally try to be clever, but don’t “write down” to your audience either. Assume the maintainer is competent in the tool set being using.

You and your friends are totally wrong, it’s not your arguments, its your attitude. Debating over which code-monkey is the better is a losing game. As for oneliners I can honestly say that I have never seen a oneliner that was maintainable. It’s like you said, take a piece of code and compress it. Well for many reasons that is not an good idea, but for readability fewer lines is never a good thing.

Stop sissying about with your comments and come clean about one key element of development: Simplicity is everything. Now all you have to do is ask yourself which is the simpler: One line of regular expression or the 20 or so lines of procedural code.

I disagree. Usually I can figure out what code does. What I want from comments is WHY the programmer chose to do something a particular non-obvious way.

thanks and best regards from Vienna
Dietmar

Case in point: all the graphics packages. Instead of getting some tools to manipulate abstract geometry you end up depending on gtk2hs, gtk, cairo, the whole f**king gnome distribution etc. which adds up to a few GIGABYTES worth of crap totally unrelated to the problem you were trying to solve. And surely it will not compile on OS X without days of tweaking. And if it did, it would look like totally out of place and it would be inoperable with whatever native libraries you might have. Or other Haskell libraries you’re already using.

Not to mention the issues of combining several incompatible licenses and company policies.

Separation of concerns comes to mind. Fist step could be for Cabal to list external dependencies in some way, as depending on another Haskell package might only be 5% of the story.

Freedom means the ability to do as one wishes without restraints. True, they are always restraints, the physical ones at the very least. But if we forget the restraints forced upon us by the laws of physics, we can consider ourselves free if there are no other restraints.

As for the software licenses, the BSD license may be considered relatively free. Relatively because there are tiny restrictions such as the one saying that you have to retain the disclaimer. Otherwise, the license does not restrict you in any noticable way and thus it may be considered free. Moreover it gives you the right to use it in any way you see fit, and this is not implied by law unless explicitly stated (!). This is freedom. There are no social obligations that bind you if you decide to use the code. It’s almost as if you found the code magically written on a piece of rock in nature. Your’re free to use it in any way you naturally can. (When I say “no obligations” I consider the obligation to retain the disclaimer as a negligible one).

On the other hand, using code licensed under the GPL gives you obligations that you would not normally expect if you used a piece of code you’d had found laying around in nature not attributed to anyone. That’s not freedom. You are restricted, and you are restricted by something more than physical laws. What restricts you here is the copyright law. The author does not waive his copyright freely but in exchange for an obligation.

As for “any right is mandatory”, I beg to differ. Rights are never mandatory* (*never mandatory towards the holder of the right– they are mandatory from the point of view of a judicial authority–a court has to respect somebody’s right ) You can always choose to exercise your right, but you never have to. Licences do not have to be mandatory either. Licences that grant rights to someone (it is implied by the law that copyright remain with the author) are not mandatory toward the person they grant rights to. Such person is always free to ignore the existence of such a right without having to face consequences.