Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2021

Too many people think real coding is like html coding, but it isn't. Change a line of html 4 and the worst you've done, more likely than not, is mess up the display of one page. Change a line of Java or Visual Basic (yeah, yeah, "if you can call that real coding" har har har) and you may have trashed the whole application. You can't nickel and dime real programming like you can html; you can't endlessly tease the application to see if you prefer that button at the top left instead of the bottom right. That's a large part of why I think it's important to differentiate between coders who script and scripters who try to code; they're just different animals.

By the same token, I'm happy to see that Mozilla is shooting for a version 1.0. There's nothing like having a nearly robust application with enough major bugs out of the way that you know where the next great feature lies. Tying up loose ends is a pain, and when you're close to and familiar with the development of the program loose ends are easy to ignore. Eventually, though, if you want an application someone other than the programmers and familiar users can enjoy, you need to stop changing the application and start cleaning up the bugs that are there.

There are two types of application -- those that have great features that are nearly implemented but-not-quite-ready-for-grandma-to-use and those that aren't quite bleeding edge but work.The biggest problem is that app "designers", especially those with an html design background, have no idea why things have to be this way, and why there's a sizable investment required (and a corresponding sizable delay between "nearly implemented" and "an app ready to ship") to bug test and QA these apps every time the code is touched. In their minds, this delay is time better spent on developing their latest great, last-minute idea -- and then they're struck dumb with disbelief (oh if only "struck dumb" was the right phrase) when you tell them that fixing their beloved "foo" a week before you're scheduled to go live accidently broke "bar" and nobody planned time to test to make sure it didn't.

It's taken me a while to figure it out conceptually, but Visual Basic 6.0 really is analogous to those quick console applications "real" programmers like to make. When a traditional C++ programmer might slap together something without a user interface to accomplish a task that'd be quicker to code than to do with other tools, not worrying about whether his/her code is exactly to spec, Windows programmers will use VB.

VB hacks are weird things to see. Logic is tied to the GUI, a huge traditional taboo, and layout is about as ugly as it could get. Everything's named the default,Textbox1 and List3, making it more difficult for anyone to follow what's going on.

But the point is that it works, and works quickly. Click, drag, slap in a few lines of code, and you've made an app that's just as accessible to users addicted to GUIs as command-line apps are to "real power users".

Though VB support is going to start going away in a few years, it's still a great engine for creating useful, accessible, and horribly ugly applications that don't require typing "foo --help" to understand and get working.

You can still make "real" apps in VB, but it's difficult. Even more difficult is making a good "GUI + logic" app (where the two are separated) the right way with a team of true VB programmers. All these slapdash bad habits are going to make their way into your code, and at some point you're just going to have to throw your hands up and accept it. Remember, the idea of separating logic from UI, an essential programming point, is a completely foreign concept to the traditional VB programmer. Good luck. ;^)

Of course there's the option of creating all of your logic in one COM or .NET object and use VB solely for the UI. This is the right way to do things, even if managers don't always understand why. In .NET, the Windows Forms classes should be used to create UI and are basically supposed to fill the role VB 6.0 once provided for Windows programmers. But VB.NET isn't VB 6.0, and there are going to be some growing pains. Having separate logic/UI teams are one good way to avoid headaches.

title: Put the knife down and take a green herb, dude.	descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and, when you bike, always wear white. As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
x MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include... MarkUpDown Multiline Table & Bootstrap Grid support. Beautiful Easy Actions that keep the Markdown flowing. HTML paste to paste HTML source into your documents. You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now!

Friday, May 03, 2002
Remember that crazy McBLT or whatever at McDonalds that gave you your burger in two parts that you put together, one part with the meat and one part with all the rabbit food (lettuce, tomato, etc)? They had some slogan like, "Keep the hot side hot and the cool side cool. I'm not a big fan of McD burgers, but the concept is a good one. While posting to the "Review-Tools" listserv at aspfriends today, I had the following in an email wishing I could find an html editor -- and even better an ASP.NET editor -- that could keep the GUI RAD editing hot, and the text editing cool. Here's a quote from that email, shamelessly cut and pasted here: Any way you cut it, DreamWeaver, VS.NET, FrontPage, even UltraEdit and HTML-Kit -- when you want to edit the source directly you're back in an editor designed with mouseland in mind, which means your fingers are off the keyboard and not typing. I got real good at using "Alt" to access the menu in UltraEdit (Alt-f-a to save as, Alt-s-p to search and replace in files, etc) before I finally gave in and tried vim (thank heavens), and Alting around the menu simply isn't as good. I like to point and click in a RAD and use the keyboard sparingly. I like to type like mad and leave the mouse lonely when I'm editing code. I wish I could find a good integrated GUI RAD/text editing combination that allows me to seamlessly do both. Oh well, keep dreaming, right? If you're wondering how I can slam UltraEdit as a text editing tool, you haven't been keeping up with my newfound appreciation of vim. It's a shame I have this 40 hour/week job and bills to pay or I'd probably try and do something about the lack of vim integration with a good RAD [and make millions, or at least $30, when I buy a copy of my editor]. posted by ruffin at 5/03/2002 09:29:00 AM

Wednesday, May 01, 2002
Too many people think real coding is like html coding, but it isn't. Change a line of html 4 and the worst you've done, more likely than not, is mess up the display of one page. Change a line of Java or Visual Basic (yeah, yeah, "if you can call that real coding" har har har) and you may have trashed the whole application. You can't nickel and dime real programming like you can html; you can't endlessly tease the application to see if you prefer that button at the top left instead of the bottom right. That's a large part of why I think it's important to differentiate between coders who script and scripters who try to code; they're just different animals. By the same token, I'm happy to see that Mozilla is shooting for a version 1.0. There's nothing like having a nearly robust application with enough major bugs out of the way that you know where the next great feature lies. Tying up loose ends is a pain, and when you're close to and familiar with the development of the program loose ends are easy to ignore. Eventually, though, if you want an application someone other than the programmers and familiar users can enjoy, you need to stop changing the application and start cleaning up the bugs that are there. There are two types of application -- those that have great features that are nearly implemented but-not-quite-ready-for-grandma-to-use and those that aren't quite bleeding edge but work.The biggest problem is that app "designers", especially those with an html design background, have no idea why things have to be this way, and why there's a sizable investment required (and a corresponding sizable delay between "nearly implemented" and "an app ready to ship") to bug test and QA these apps every time the code is touched. In their minds, this delay is time better spent on developing their latest great, last-minute idea -- and then they're struck dumb with disbelief (oh if only "struck dumb" was the right phrase) when you tell them that fixing their beloved "foo" a week before you're scheduled to go live accidently broke "bar" and nobody planned time to test to make sure it didn't. posted by ruffin at 5/01/2002 10:10:00 AM

Thursday, April 25, 2002
It's taken me a while to figure it out conceptually, but Visual Basic 6.0 really is analogous to those quick console applications "real" programmers like to make. When a traditional C++ programmer might slap together something without a user interface to accomplish a task that'd be quicker to code than to do with other tools, not worrying about whether his/her code is exactly to spec, Windows programmers will use VB. VB hacks are weird things to see. Logic is tied to the GUI, a huge traditional taboo, and layout is about as ugly as it could get. Everything's named the default,Textbox1 and List3, making it more difficult for anyone to follow what's going on. But the point is that it works, and works quickly. Click, drag, slap in a few lines of code, and you've made an app that's just as accessible to users addicted to GUIs as command-line apps are to "real power users". Though VB support is going to start going away in a few years, it's still a great engine for creating useful, accessible, and horribly ugly applications that don't require typing "foo --help" to understand and get working. You can still make "real" apps in VB, but it's difficult. Even more difficult is making a good "GUI + logic" app (where the two are separated) the right way with a team of true VB programmers. All these slapdash bad habits are going to make their way into your code, and at some point you're just going to have to throw your hands up and accept it. Remember, the idea of separating logic from UI, an essential programming point, is a completely foreign concept to the traditional VB programmer. Good luck. ;^) Of course there's the option of creating all of your logic in one COM or .NET object and use VB solely for the UI. This is the right way to do things, even if managers don't always understand why. In .NET, the Windows Forms classes should be used to create UI and are basically supposed to fill the role VB 6.0 once provided for Windows programmers. But VB.NET isn't VB 6.0, and there are going to be some growing pains. Having separate logic/UI teams are one good way to avoid headaches. posted by ruffin at 4/25/2002 10:38:00 AM

Wednesday, April 24, 2002
Quick! Before they learn that there's more than one browser in the world! Check out this demo from the kinda, capitalistic folk at richtextbox.com using a browser like Mozilla, or even Netscape 6, or how about the browser engine being used in the latest AOL beta? Once again, I emailed the offending .NET fellers. Speaking of, let's see how dotnetjunkies is doing with Moz and it's dynamic menus. Whaddya know? It's the exact same slack problem they had before. I hope AOL/Gecko catches like wildfire. True html programmers will be as in demand as COBOL guys in Q4 [calendar] 1999. posted by ruffin at 4/24/2002 02:51:00 PM

IE on Windows has a neat feature that allows you to pop open a page you're looking at and hack on the source in the editor of your choice. Sorta. Most of MS's tools automatically register in the "Tools \| Internet Options \| Programs \| HTML Editor" drop down, but vim's a little outta luck. Luckily all your problems are solved for integrating vim as your HTML editor in IE on Windows here. I just wish visvim did what it sounds like it should do -- provide an alternative, truly integrated editor for VS. I'd like to have vim pop up in Visual Basic 6.0. I hate taking the hands from the keys. Mice. Crimminy. :^) posted by ruffin at 4/24/2002 11:47:00 AM

VB.NET is entirely different from VB6. The only similarities are skin deep. For heaven's sake, yes, he's got it. Just read a horrible article in aspnet Pro magazine (or something similar; I'm bad with names) purporting to help you decide which language to use in your .NET coding. "If you like C#, use C#; if you like VB.NET, use VB.NET." It makes me sick. :^) This article is much quicker and, surprise, more useful. The above article does a great job very quickly showing why you should [probably] use C#. In brief [imo] the points are that the .NET team uses C# to build .NET, the example apps from MS are C# first and VB.NET rewrites when there's time, and that VB.NET is nothing more than a thinly veiled syntax rewrite lain on top of C#'s structure. "Upgrade" a VB 6.0 app to VB.NET using Visual Studio.NET and see for yourself. posted by ruffin at 4/24/2002 09:48:00 AM

Friday, April 19, 2002
What's best about .NET? MS is bringing the same "paradigm" from the client to their web services. This might give MS a leg up on the server side, but well programmed replacements for their "uplevel-specific" controls that aim for alternative OS browsers [as well as Windows browsers] mean that you're only one .NET server from bringing MS sellouts into an alternative OS world. One of the reasons MS is so successful is b/c it has so many programmers. Now, thanks to .NET, those programmers aren't tied in to MS clients to get across expected functionality. posted by ruffin at 4/19/2002 04:56:00 PM

Thursday, April 18, 2002
Know how to program? Want to learn C# ASAP? Go here. Okay, okay, it's not quite as nice as I'd've liked, and it brags about not having many comments even though a few well-placed comments would have made this much more useful, but if you already program this one file will show you how to port your console-app logic to C# in a minimum of time. And it's cheaper than buying a book. posted by ruffin at 4/18/2002 10:15:00 AM

Wednesday, April 17, 2002
Why is writing less code something to brag about when it comes to new technologies? IBM fights Microsoft on who can write a pet store with the fewest lines (1 to none, depending on who you believe), ASP.NET trainers brag about how .NET is misunderstood and you can write whole apps with tiny amounts of code... Are there really that many apps out there that are prototypes that are never updated? Sure, you can make a WordPad replacement in VB 6.0 by hitting "Next" in a Wizard until you get to the "Finish" button, but does that make VB a better langauge than C? Sheesh. posted by ruffin at 4/17/2002 11:16:00 AM

Tuesday, April 16, 2002
BLOGSPAM DAY!!! Been using vim as my main text editor (on Windows, even -- well, gvim) for a while now, and I think I oughta write an article for somewhere entitled, "How the mouse destroyed productivity". Oh, I know, all the graphics designers and spatial data people will pitch a fit, but when it comes to programming for the web and just in general, the mouse is a productivity killer. Kinda like web logs. Anyhow, I suppose now is when I mention Cream for Windows, which is self-styled as... ... a configuration [read: "incarnation" -R] of the famous Vim text editor to make it easier to use, like Apple or Windows software you already know. At first it sounds like a neat enough idea, but it ain't. Here's a goal that shows as much, from the Things [the cream dude] hates about vim: We've all heard this fabrication that GUIs are slower than text entry, but this simply isn't true for anyone other than a developer level expert. Who else does text entry with a text editor? And if you want a text editor with groovy features that make it a cinch to learn, why are you using Vim? If you're stuck on a dial-up and simply must edit text, try the "PIne COmposer", or "pico" (ignore the bit about using emacs in that doc). Admittedly, when I started using gVim I wished that I had more of the commands at my fingertips like I usually do when I have a drop-down menu -- often all through keyboard transversal (eg, alt-f-s to save). But after you finally get what the keys mean in your head, you're much better off and working much more quickly (with less carpal as well). If you're thinking about using Cream, use a well-tested, well engineered project that's quite similar and already finsihed, UltraEdit. If you want vim, you don't want Cream. posted by ruffin at 4/16/2002 10:56:00 AM

<< Older \| Newer >>