Barely Legal Substance

« Pleasing Information Design | Main | Jotspot Beta »

November 11, 2004

New Flame War Weapon: Photoshopped Menu Screenshots

Recalling the roflol Clippy debacle, it seems another flame war between VB.NET and C# developers has sprung up over at Panopticon. Which leads, as always, to name-calling and comments about whom carries the real set of geek-cajones, played out over a funny exchange of photoshopped menu screenshots. I for one will refactor myself to welcome our new C# overlords.

Trackback Pings

TrackBack URL for this entry:
http://chattablogs.com/mt/mt-tb.cgi/16290

Listed below are links to weblogs that reference New Flame War Weapon: Photoshopped Menu Screenshots:

Comments

should I point out that neither VB.NET nor C# developers have the real set of geek-cajones? oh, I just did.

Posted by: JosiahQ at November 11, 2004 05:43 PM

Oh, come now. Once you admit that _any_ OO-Language is "true geek", it's a simple argument to admit that the .NET languages count too.

Dissing .NET is *so* '99.

Posted by: barelylegalprogrammer at November 12, 2004 08:59 AM

.NET exists because of understandbly bad "short-cut" programming philosophies started back when processor speed and memory were huge issues, that is the short-cut approach bypassing the file-system and kernel. Its completely unecessary now as we've got more speed and more memory than we need. Its faster, cleander, and more efficient to write programs on the file-system/kernel level.

But there exists a culture gap 'tween the MS world and, well, everything else. You yuppies.

Posted by: JosiahQ at November 12, 2004 02:16 PM

Its faster, cleander, and more efficient to write programs on the file-system/kernel level.

As I said before, Oh, come now. That's just ridiculous! You can't be seriously advocating a return to:

(a) Programming on an platform-implementation-dependant level (which is what we used to call Assembly)

(b) That speed is a serious issue for 90% of all applications created

(c) That Real Programs are better off written on a non-object, prodecural level (eg C or below) than on the highest possible level of abstraction (eg any OO language whether it be imperative or declarative).

(d) That gains in speed and memory mean that we should be *more concerned* with speed and memory.

It's faster, cleaner, and more efficient to write in the human-centric manner possible, not in the most computer-centric manner! The job of translating my code to the specific hardware of whatever machine my code runs on is the job of the VM (Java), the IL (.NET), the interpreter (Perl, LISP, etc.), or the compiler (FOSS stuff). The march of programming has been from code written on the hardware -> kernel -> file-system & memory manager -> API -> virtual machine/interpreter.

You need to reverse the flow of your implications, eg, "programs on the file-system/kernel level" were " programming philosophies started back when processor speed and memory were huge issues" but now "Its faster, cleander, and more efficient to write programs" because ".NET [and of that ilk] exists".

Posted by: barelylegalprogrammer at November 12, 2004 02:35 PM

alrighty, I'll bite.

It's not a matter of speed or memory as much as a matter of writing code -- experience has lead me to beleive that OO makes it easy for programmers to make dumb mistakes.

The portability issue is kind of a non-starter, around here at least. The work we do is all aimed at the internet, so if it's networked it's portable -- and I in particular am interested in getting more of your desktop on the internet (which is also most (all?) of the point of .NET).

So, if we don't need to be portable, we have pre-existing frameworks for objects, state, and shared variables -- the process stack and the filesystem.

JosiahQ's comment about how more processing chops makes this work better I think comes from an idea we were discussing the other day.

Processes and files are more effective than OO programming, if you rely on small files, and small processes. Traditionally, programs have gotten monolithic because there was a high penalty for process forks, and for small files.

So, I'm posting because JosiahQ asked me to -- not really interested in a religious (every OO v. non-OO argument is a little religious) war. There is a good, practical case to be made that OO creates more problems than it solves, and I'm (usually, mind you) satisfied with that. OO has it's place, but in my world, it's only when I have to use somebody else's code.

Posted by: Lang at November 15, 2004 02:54 PM

Thanks for elaborating, Lang. I think I'm understanding where you & Josiah are coming from. Why write a big internet app when you can write twenty small ones that interact together using the filesystem as a sort of schema and the processes as a kind of services.

I like that approach. It is proprietary, and it is non-portable (to the extent that the services will only run on one platoform), but it will be fast and it will be useful cross-platform. It fits well with where digital stuff seems to be going--loosely coupled, service-oriented, internet exposes the app api.

However, this is not a ginsu knife approach. It won't slice and dice every computing need (at least not yet--once we overthrow M$ then we can start talking). The client-server model can only take us so far: there was a reason we went to the PC. And for that reason, there needs to be a paradigm that lets you think of things in a different way.

Here's where your approach gets me: for most software, the truely difficult stuff lies not in the writing of the code, but in generating the requirements. That's what makes OO so useful--objects in code map directly to objects (conceptual or physical) outside the computer. When the requirements change, I can swap objects in and out. Can't do the same for processes and files--unless they are approached as objects...But that's a religious discussion.

Not to bait, but how does the filesystem & processes approach keep programers from making dumb mistakes? I can see it keeping them (by which I mean me) from making the *same* mistakes, but it seems like I can just as easily make different ones (eg Oops, two of my little services just deadlocked a file. How the heck did that happen?? Would using a RieserFS solve this?).

Posted by: barelylegalprogrammer at November 15, 2004 05:33 PM

Post a comment