I think I've grown a little tired of coder catchphrases.

There are three that drive me nuts:

1. Anything with the word "semantics" in it
2. Anything talking about "syntactic sugar"
3. Anything involving the necessity of a power language/tool (C++, for example) to code anything more than the "most trivial application."

The first two are just a bit irritating. They lend a pseudoscientific jargon to coding. Coding at the applications-level is anything but scientific, and I wish that most applications developers would admit this to themselves.

The other problem is that these phrases have become conversational crutches. I've seen the first two phrases put to so many different uses, that I'm not entirely certain I still know what "semantics" are, or what constitutes "syntactic sugar."

It seems to me that "semantics" is the word that is used when a coder wants to sound more intelligent. It's a pretty impressive word. It sounds serious, and makes you feel like you're talking about something really important (like changing the world through XML and billing systems <yawn>).

"Syntactic sugar" has been used in such a way that it makes perfect sense to me (for example, the overloading of an operator to provide functionality that already exists somewhere else, such as: == vs. String.Equals()).

Other times, it just gets thrown in, and I can't figure out what the coder is trying to say.

"Well, yes, but the semantics of the derivation are purely syntactic sugar that is of no use except in the most trivial of applications."

Does anybody know what this means? I don't. I just made it up. At a glance, it seems to be grammatically correctish, but that's as far as I can get.

I understand that there's a desire to feel that storing customer names and addresses in a database is somehow really important and world-changing, but the satisfaction should be derived from the knowledge that X business would just flop if al of us coders just walked out. That's all the validation you need. Forget about all this namby-pamby wannabe intellectual snobbery. Applications development is the ditch-digging of the tech world - As far as IT goes, it's very blue collar.

Then, for the third item:

3) Anything involving the necessity of a power language/tool to do anything more than the "most trivial application."

This one gets me every time.

An "inch" - This is a standard unit of measurement, and I know what it means.

A "centimeter" - Again, this is a standard unit of measurement, and I get it.

A "trivial application" - I'm sorry? What does this mean?

What is a trivial application? How can we speak about them so generally? Is there a ratings system I don't know about?

As far as I can tell by the way the phrase is used, a trivial application must be one that does what I want, but which isn't unnecessarily complex.

For example, consider the following dialogue:

Coder One: I'm going to code the final version of my mass mailer in C#.

Coder Two: In C#? Just against the .NET framework?

Coder One: Yup.

Coder Two: I'm sorry, but you can only code the most trivial applications in C# against the .NET framework. To do anything serious, you're going to have to get out a pair of tweezers and move the bits by hand.

Coder One: But the prototype is working.

Coder Two: How trivial.

I think the only thing trivial here is Coder Two's imagination.

When I was a lot younger and skipping school on a regular basis, I stayed home and coded little things that delighted me. Although I had C (MS QuickC 2.5) and Assembly (TASM 4.0) at my disposal, I rarely played with them. I was most interested in getting my apps written, and so avoided anything that might unnecessarily complicate the experience. Productivity is very important - If you're skipping school to code, then you should be done before your parents get home, 'cause you're not going to get a lot of work done when you're getting busted after they find out that you've skipped school 39 days in a row.

My tool of choice? QuickBasic 4.5.

And I coded everything in it. I did my own terminals, windowing systems (OK - those weren't very good, but they bloody well worked), snazzy little word processors with home-grown graphical menuing systems, drawing programs, animation programs, games, etc..

There were only a few occasions when I chose to dip into other languages. For example, it was a lot easier to bust out TASM and code a little (crappy) graphical scrolling routine than it was to do it in any other language with which I was familiar. However, 99% of the time, the lower-level languages were useless to me.

I suppose it could be said that my applications were trivial, but they did perfectly neat things. My painting programs had mouse support (hey - this was really cool back then), the ability to edit the available palette (this was in the days of EGA), and supported loading/saving to a binary format (hello-duh). What C or Assembly would have brought to the table is beyond me, since this was all entirely possible in QuickBasic.

Now, over a decade later, I have C# and .NET available for my coding (when I'm not having to use other languages/frameworks, anyway...). My mind absolutely reels at the thought of what could have been done with this combination when I was younger. I would have taken C, Assembly, and QuickBasic, and left them at the eGoodwill.

It's possible that with .NET closing the gap between the "good" developers and the "bad" developers (hey - we have C++ guys and VB guys sharing the same development platform now), the "good" developers (the ones who only code non-trivial apps) need a way to maintain the sense of superiority that was enjoyed in the VC++ vs. VB crowd.

I don't know. Maybe there are those who would argue that what I'm coding now is entirely trivial, but I would have a hard time believing it. The code I'm putting out is helping a business with over 600,000 customers get through the day more easily.

Is that trivial?