Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×
User Journal

Journal Journal: Vista Sucks

Okay, I have now officially used Vista enough to say IT SUCKS.
Things that Suck Large:

1. UAC. User Access Control. You just clicked on a file. Are you sure you wanted to do that? You just tried to install a program, did you really want to do that? UAC gives you the feeling that you're using a computer that's already full of spyware and viruses before you even are. You are at Checkpoint Bravo, and you're losing the war, you're overrun by enemy forces, and all you can do is check ID while watching as you inevitably lose to an enemy you never really saw. But you did check a lot of badges of regular staff as they are coming and going. Hey, sounds like the worlds worst IT department itself has infected my PC. Okay, so I turned it off, which, like the Apple TV commercial points out, kind of defeats the purpose of having it in the first place. You are coming to a sad realization. Allow?

2. Drag & Drop File Copying Slow. Much discussed here on Slashdot, and on the Microsoft Technet discussion forums. Automatic thumbnail generation slows down file copies to a crawl. "Estimating time left" takes more time than the damn copy, you idiots. When will you learn not to lie to users, Microsoft. "Estimating time left", how about "Generating thumbnails so we can show you a shiny preview of stuff you're copying. What would be really funny (I should check) is if it generates thumbnails just so they can be deleted. Vista is perhaps the best Rube Goldberg machine ever invented.

3. Windows Explorer (shell) crashes on me five times a day. This might be related to TortoiseSVN, which is an explorer plugin, but still, it should be possible to plug in a right-click menu into Windows Explorer without bringing "your whole computer" crashing down, which is of course how your average user will feel, if the whole Windows Shell including the Start Menu, and any open file windows (explorer.exe) die.

4. The built-in backup sucks. You can't even specify what files you want to back up. You can say "everything" or filter by file types. You can click or unclick entire drives. You can't select folders on that drive to skip. Stupid vista garbage backup is a worse piece of crap than the Microsoft Backup built into Windows XP, which is also crap, but at least capable of backing up the folders I want backed up.

5. It comes with a Stupid Kiddie Game Pre-installed. Purple Town or something like that. What can I say? I have little kids, and they thought it was lame. So, what does that mean? Look, Vista has a little-kid game, that even little kids hate. Nice.

User Journal

Journal Journal: Real Programmers don't Use Visual Basic.

I think I'll write a book with the title "Real Programmers don't Use Visual Basic". Whenever I see a resume where the applicant says "I'm an MCSE and I have ten years experience writing Enterprise Class applications with Visual Basic" on his or her resume, or whenever I see a job advertisment where they say "X years of experience writing mission critical enterprise apps using Visual Basic", I know that the person, or company in question, has no credibility, questionable technical skills, and generally exhibits lemming-like behaviour that is common in the IT sector.

What do I mean by that? I mean only that Visual Basic is a path of least resistance, for both management and trainees. It gets in the door by claiming ease of use, or rapid development cycles (compared to Visual C++, this is true, but I'll save my Anti-Visual-C++/MFC/ATL/.NET-rant for another day), gets away with claiming to be Object Oriented, or even claims to be compiled, something which has never been strictly true of VB, and which is still not entirely true of VB.Net.

In essence, VB is the ongoing development of one of Microsoft's first products. Their basic interpreters were first delivered as ROM code for popular 8 bit home computers of the 1980s, like the Atari 400/800, the Commodore Pet, the VIC-20 and, my own first computer, the Commodore 64.

These languages contained in a mere 8 or 16K of ROM, a Basic with mandatory line numbers, simple Integer (16 bit) and single-precision Floating Point arithmetic, simple string handling, were built in. For/Next loops were the only loops. Goto and gosub were the *only* looping constructs. Instead of calling a utility function, you would GOSUB to a line number. Procedures? What are those? Functions? Yes, you could write functions, but only if they would fit into one line, and were only composed of simple mathematical operators. This was the Old Days, before Structured Programming was common on microcomputers. There were no Editor programs, and source code didn't come from a file, it was all resident in memory at once. You typed a line of code, with a line number, and you hit enter, and that line was added (or replaced) in-situ, in RAM. This was optimal if you had only a tape drive (no floppy disk), and workable if you had only a floppy-drive. Almost nobody ever had a hard drive on one of these machines. You could type LIST to see what was in memory, SAVE to save the program to disk, or LOAD to reload a previous program. RUN made the whole thing run, and if you wanted to debug, you would hit the BREAK key, or put a line of code into your program with the STOP keyword, so you could stop the program, print out some variables, and type CONT to continue it. Programs in multiple source code files (includes, libraries, etc) were not possible. Subroutines were not yet heard of in BASIC.

Fast forward to the late 1980s and the rise of the PC and MS-DOS. Included with MS-DOS was GW-Basic, Microsoft's improved version of BASIC for the IBM PC. This basic version became ubiquitous because it shipped with DOS. Like the 8-bit micro versions, this 16 bit DOS application had nothing like an "IDE". It added primitive capabilities to define functions (subroutines), and even had some DOS graphics primitives. Compared to the ROM basic that came with my Commodore 64, this was a very deluxe Basic language. It was still a primitive piece of crap by modern standards. You still only had two significant letters to name your variables (THIS and THAT would be the same effective variable name, TH). Most programs written in GWBASIC were strictly of the homebrew/hobby variety.

Microsoft made another incremental improvement to GWBASIC, called QuickBasic (QBASIC.EXE). QuickBasic was a stripped down version of their Basic Compiler, originally a standalone package, which never achieved widespread use, until the stripped down QUickBasic was shipped along with DOS. Once it was shipped with DOS, QuickBasic quickly relegated GWBASIC to the scrap heap. It had a simple text editor, the beginnings of an IDE, the ability to set breakpoints visually and to visually step through code. Quite a few DOS games and other kinds of DOS programs were written in Quick Basic. The language had added another set of quirky constructs, some semi-obsolete, like the LET keyword, which still existed for example, but was essentially useless. LET X=Y and X=Y did exactly the same thing.

Your other choice at the time was Microsoft's C Compiler Version 6. This was also the only way to write a Windows apps when Windows 3.0 shipped. And while straight C programming for DOS wasn't that difficult, if you got the classic K&R book and worked your way through it, the change from BASIC to C required a lot of trial and error, and the absorbing of several books worth of information in order to proceed. As someone who sidestepped QuickBasic in favour of TurboPascal, and later learned C syntax as an exercise in comparison to Pascal, I remember feeling very sorry for people who limited themselves to the choice between Microsoft C, and Microsoft QuickBasic as their programming tools. Working in TurboPascal was as fast as working in QuickBasic, and the language was far more full-featured and powerful than Microsoft's C tools were at the time, and were also capable of all the same low level hacks as C programmers were used to, such as the ability to hook interrupts, write DOS pop-ups, known as TSRs, and to handle complex data structures, using a rich, expressive, structured programming language. In short, Borland kicked Microsoft's @$$ all around the block, but still some people insisted on using the two lame tools that came from Redmond. I began to suspect in 1989, that many people chose their tools because of the the name on the box, not what actually came inside the box. Borland had object oriented programming, very nice Modula-2 style interface/implementation separation, and other things that were lightyears ahead of C, and did I mention, it compiled 20 times faster than C did and produced smaller executables?

Now when it came to learning Windows programming there was no avoiding the pain. Programming on Windows was an order of magnitude more complex than DOS programming. A 'Hello World' program went from one line to about 100 lines. It was event-oriented, with message handlers, and a bizarre API, especially for a former DOS programmer, that could only have been invented by Microsoft, and could only be understood if your name was Petzold, or if you had bought a book by someone with that name, and spent many months tearing your hair out trying to learn all the options for WinCreateWindow. The complexity of writing imperative code to control an event driven architecture was what prompted the creation of Visual Basic 1.0, which was nothing more than a GUI forms builder with the ability to draw a form, with a button control, click the button, and an editor window would open, and you would only have to writen a a few lines of code that would be executed when that button was clicked. Then you would click Run, and you had a windows application. The nice touch was the VBX control, a way of plugging in controls, like spreadsheets (grids) and charts, that were more exotic and more visually varied than the simple ones that were built into windows (buttons, checkboxes, etcetera). VBX controls could be written by a moderately clever C programmer, and then reused in an almost no-brainer fashion by the growing horde of people who fell in love with VB, so to speak, because of the ease of use. As they grew more experienced, they began to hit one limitation after another in VB's architecture. Microsoft gradually expanded the walls outward with each version, usually by adding some new ugly item to the syntax. The worst example is the SET/LET duality.

Fast forward to today, and you have Visual Basic 6.0 being used in enterprises around the world, mostly because someone in 1989 didn't want to shelve their knowledge of GOSUB and LET statements, they didn't want to learn to use braces or begin/end statements, or where to put semicolons. Because of what started as an effort to stay with the weak, and broken, albeit simple syntax of Basic, we have n-Tier enterprise applications being written with Visual basic. Was it done because it was the best thing possible at the time? No, it was done because it was the path of least resistance.

What can we learn from this? We can learn that basically, most of the time, people do what comes easiest, what we felt we had time to do, and we paid the price for it. If a wiser developer emerges at the end, one who realizes that a bad choice of language can doom a project, or at least curtail it's useful life, then perhaps we can say we have learned a lesson.

next time, a brief rant about .NET.

Slashdot Top Deals

The aim of science is to seek the simplest explanations of complex facts. Seek simplicity and distrust it. -- Whitehead.