13 Apr 2013 @ 3:55 AM 

Integrated Development Environments. These are the programming tools that most of us have come to almost take for granted. They provide the ability to write, debug, edit, and otherwise develop our software within a cohesive software product. You can find Development Environments for nearly every language platform. Microsoft Visual Studio can handle C#, VB.NET, F#, and C++ out of the Box, while also providing a wealth of other language capabilities through aftermarket software. Java has Eclipse and Netbeans, just to name two- the list goes on.

However, for every IDE user, there is a person who ‘looks down’ on the lowly IDE user; “they aren’t actually writing code” they grumble into their bag of cheetos- they are simply selecting things from an autocomplete list. These types of people are, perhaps in a statistically significant way, usually users of *nix based systems. They extoll the virtues of their favourite text editor- emacs, vim, nano, and look down on IDEs, which they will sometimes refer to as “glorified text editors”.

If my patronizing tone in the previous paragraph was not obvious- or if you’ve never read one of my programming-oriented blog entries, I’m firmly on the side that supports and uses IDEs, wherever they are available. The arguments against them are often lame; arguing that getting used to a feature like autocomplete or parameter lists, or dynamic help windows, and tips and whatnot make us “soft” is absurd- the same could be said of keyboards- by extension it just makes inputting data easier, so clearly we should be flipping switches manually. My point is that IDE software aims to make the task of software development easier, and more productive. And IMO it does this is spades.

There are even add-ins for many IDEs that basically provide all sorts of world-class capabilities in the IDE. Resharper is one exceptional such plugin that is available for Visual Studio- at this point, if it’s missing, it’s like I’m missing an appendage. It has made my work in Visual Studio so much more enjoyable and productive, that I almost feel it’s a crime not to have it installed. Similar addons are available for all sorts of IDEs; even Visual Basic 6 has things like MZTools(Free) or AxTools CodeSMART(Commercial).

Of course, IDEs lose a lot of their edge in certain languages, particularly those that lean towards the dynamic end of the spectrum. So much information about the program relies on run-time, that it’s a tricky proposition for a piece of software to try to figure out what is going on and provide any sort of tips or suggestions. Unsurprisingly, most of those that find IDEs childish use languages such as Python, Perl, Ruby, and PHP; I myself do not use an IDE for these languages either; primarily because I couldn’t find one (VS 2012 has an add-in available called “PHP Tools” that apparently brings support for PHP, though I do not know the extent of it’s assistance). However, if there was a software product available that provided the same level of assistance to languages like Ruby and Python as I currently get from Visual Studio or Eclipse, I would jump on it like Mario on a Goomba.

We ought to think of the software as not only our tools, but our own assistants. Most people wouldn’t raise any objections about being given a personal assistant for their work or daily tasks. In the case of Resharper specifically, that assistant is also an 11.

Posted By: BC_Programming
Last Edit: 15 Apr 2013 @ 03:49 AM

EmailPermalinkComments Off on On IDEs
Tags: , , , , ,
Categories: Programming
 23 Nov 2010 @ 7:09 PM 

Alright, so, I had finally gotten sound to work. it was wonderful. Sure, things ran a bit slow.

And then poof, out of nowhere- Quite literally, I made NO code change whatsoever, the program is now crashing with an OutOfMemory error. From- where else? the god damned GDI-Plus/Cairo. Who the fuck wrote that thing? Every single problem I’ve had has been related to that Piece of shit. If you’re going to write a compatible library, do it properly.

Another tidbit: I love how everybody who uses Linux says “Linux is more stable” perhaps the OS is, but when it comes to Mono you may as well leave any stability, mental or otherwise, at the door.

“MonoDevelop, please show me the contents of this variable in the locals window”

“naw, I’ll crash instead”

“MonoDevelop, please show me the locals window”

“sorry my window has gone dark again.”


It’s DRIVING ME INSANE. I finally get the thing working and then out of nowhere (again, I made absolutely no change to the code) it decides, “hey, you know what, I’m broken again, just for shits and giggles”.

What makes even less sense is it only crashes in certain locations. It still draws the sidebar just fine. the background is drawn. and so forth. Why the hell does it refuse to properly draw some items? I finally, after struggling for far too long to get the bloody IDE to allow me to set a bloody breakpoint (you know, those things that worked perfectly fine in Turbo Pascal 25 years ago?) I threw in a few try catches because the error was not being handled in the right place (of course it would have been easier to discover this if I had been able to set breakpoints or had a clue where the Trace.WriteLine output was going), so I discover the problem was in cBall, when it tries to draw. Somehow drawing a god damned Solid Ellipse is just so taxing that it runs out of memory. Because that makes sense.

And then I made a few changes, and the error was now a NullReferenceException in DrawSideBar, so I thought, good! Maybe I’m finding out where the problem is.

So, silly me, I believed that MonoDevelop wasn’t being a huge steaming pile and tried to use the debugging features, you know, the ones that programmers might use, like say, placing a breakpoint in said routine in a crazy attempt to determine what was null.

OH! but that is not going to fly! I try to run the program in Debug, as one might, and the poor thing refuses to start! Mono Essentially crashes! Oh the JOY of this IDE, it simply screams “please, don’t use me the way you might expect, most of my features are written by illegitimate children of famous actors, and are therefore unusable except from a distance using bad glasses”.

So I try again, and this time mono really does crash. This is bordering on psychotic folks.

So, I’ve decided that if somebody wants a Linux version of, at least, this program they can either figure it out themselves or look elsewhere.

I tried to make a small java test version but I couldn’t figure out how to use swing. By which I mean I couldn’t import the library. But that’s another story.

EDIT: cleaned up my swearing here 😛 it was a lot even for me. Also, in the meantime I was able to create a small working application but couldn’t find the motivation to bother trying to figure out where swing paints. (having to look up in the documentation for exactly what routines to override, as opposed to being able simply type “override” in C# and see what I can override? No thanks. (also, I am probably clouded by my past attempts to work with java back in the “golden days” of the standard Java.AWT classes, which had the magical ability to provide sub-standard, barely OS-oriented controls for each Operating System.

Posted By: BC_Programming
Last Edit: 29 Nov 2010 @ 01:33 AM

EmailPermalinkComments Off on Mono nonsense
 03 Nov 2009 @ 12:31 PM 

I have been using Visual Basic 6 for many years; I have come to the point where using it is effortless; nearly any problem I have I can design and program with Visual Basic 6.

However. Visual Basic six is over 10 years old. Mainstream support ended a few years ago, and after Vista Microsoft makes no promises that programs designed with Visual Basic 6 will work. Even creating programs that support the various UI features of XP could be a chore. With Vista, Not only does one need to include the proper manifest resource or file  to force their VB6 applications to link with the newer version of comctl32, but it is almost always necessary to include an additional set of directives in the manifest to make the program request administrator permissions. I have yet to determine why some of my less trivial programs crash before they even start when run with the same security as the user, but I imagine it’s directly related to COM components, their usage, and the permissions surrounding them.

Another area of concern is with the use of proper icons; Visual Basic complains when you try to use a icon with a alpha channel. However, through a few API techniques and some resource editor trickery, it’s possible to have your application use 32-bit icons both as the program file icon as well as the icon for your forms. Rather then repeat the material here, I will point you in the right direction if this type of this piques your interest. www.vbaccelerator.com- I cannot praise that site and it’s creator enough. While many of the projects and controls he has on-line I have personally attempted before finding the site (I had a somewhat working toolbar control and a control I called “menuctl” that allowed moving the main menu around as a toolbar), the sheer number of completed, documented, and well written controls on his site is simply mind-blowing. There is also a .NET section to his site as well, which brings me to my next point.

There are only a few reasons why a programmer would choose to use Visual Basic 6 for a new project today. The main reason is simply because we are stubborn, for the most part. The fact that .NET is better in many ways then VB6 does not sway us to use it. The fact is, we all feel “betrayed” in a way, but the shift to .NET. Millions of lines of code that were dutifully compatible through all 6 versions of Visual Basic 6 now break when loaded in VB.NET. But I believe, that the majority of VB6 programmers have simply been blinded to the number of problems Microsoft would have faced to continue using the same COM oriented framework that VB4 and higher have used.

COM,or, Component Object Model,(sometimes referred to as “Common Object Model” which is dead-wrong) is a Binary compatible method of providing interoperability between applications. COM was essentially designed to prevent what was known as “DLL hell”, since at that point in time DLLs provided their functionality through exposed functions, some versions not compatible with previous versions, meaning it might be necessary to, for example, have 5 different versions of MFC41.dll on ones PC. The idea was, each version of a COM component would be Binary compatible with the previous version, which means, for example, that a program designed for version 1 of “foocomponent” could still run and use version 4, but without the new features of version 4. This functionality was implemented by the creation of Interfaces. Each version of a component would add a new interface- for example, IFooComponent, IFooComponent2,IFooComponent3, etc, and client applications who want to use FooComponent would use the interface appropriate to the version they wish to use.

There was, however, one problem. Most of the maintenance between versions was left to the programmer of the component- they had to create the new interface, make sure previous interfaces worked, that old clients could still instantiate their objects, etc. Basically, it made the critical mistake of putting the user of the technology (in this case, the programmer) in a critical position and with a number of responsibilities to get things to work properly.

Microsoft, of all companies, should know that putting the programmer in a position of such responsibility is prone to failure; hell, many of them can’t even be bothered to follow standard API documentation; for example, actually reading the documentation; this resulted in hundreds of man-hours of programmer time being consumed by the creation of “compatibility shims” to let these programs work. (otherwise, installing a new windows OS would break these programs; they worked before, so as far as the user sees the new Operating System is to blame). Anyway- this failed miserably. Programmers would sometimes simply change their interfaces rather then implement new and old ones, meaning, like with the DLLs of before, new DLL versions were incompatible with the old ones.

It was clear that COM, or, at least, COM as it was presently designed, was far to dependent on the programmer to “do the right thing” then was reasonable. So, Microsoft, at some point, decided they needed a new object framework architecture.

VB6, as a COM-based language, would have required extensive changes to support this new architecture. the prospect of such a huge revision probably made them take a second glance at the language itself, and the cruft it still has from previous iterations of the basic language. aside from retaining such archaic constructs as the “GoSub…Return”, VB6 also “failed” in a sense on a number of other areas. Error-Handling, for example, was still done using “On Error” statements, which redirected flow to another segment of code. It was up to that block of code to evaluated the error, using the “Err” object (In VB1-3 there was only Err which was the error number and Error$, which was the description), and then either resuming that same statement that caused the error (Resume) skipping that line, and continuing with the next, (Resume Next) or even raising the error again, causing the error to cascade up through the call stack.

This Error architecture had a critical flaw- by using this form of error handling, flow could change to the error block for any reason, at any time. This meant that if the procedure dealt with resources, such as file handles or memory blocks, it would have to keep track of what needs to be undone so that the error code could also double as partial cleanup code. Another critical flaw was simply that it was ugly; it looked and functioned nothing like the Try…Catch statements in many other languages. Also, it could become impossible to trace exactly where an error occured when errors cascaded; and error handler might be forced to handle an error from three levels down in the call-stack, so even if it understood the error in the context of the procedure, the context that the original error occured in and exactly what it means was lost.

My main language is Visual Basic 6, but I am not so blind as to reject VB.NET, or .NET as a whole, merely because it essentially replaced VB6. The truth is- we, as VB programmers, have made a large number of requests to the VB developers. VB .NET answered and fixed a huge number of those requests, and yet it is still shunned; it is clear to me that it is not merely the loss of backwards compatibility that causes such antagonism with VB6 programmers, but also the human element of resistance to change.

With previous versions of Visual Basic, one could migrate all their code to the new version with little or no difficulty.

This, however, had a price- since the new version made few, if any, requirements for conversion, old antique code would often be upgraded and imported into the new environment. Since backwards compatibility was the rule, old elements such as line numbers gotos, and gosubs remained in the language. Antiquated concepts such as type declaration characters remained in the language. Such visages of a forgotten era had no place in a modern language.

All the above being said, VB6 is still a language capable of creating modern applications; however it is important for the programmers who still use it to realize that they aren’t using it because it is superior or because .NET or any other language “sucks” by comparison, but rather as a result of their own stubborness and unwillingness to learn new programming concepts.

A anecdote, if I may, can be found in my introduction to the use of “class modules” within Visual Basic. at first, I had no idea what they were- I simply shied away from them, and stuck to Forms and code modules. I used all sorts of excuses- Class modules are slower, they bloat the code, etc. All of which were, almost universally fabricated or found on the web written by grade 8 students who barely understood the meaning of the word “class” in the context of programming or objects.

After, however, creating ActiveX Controls using the “userControl” Object, I realized the similarities, and the possibilities that could arise. My first conversion attempt was on my Current “flagship” program, the game I called “Poing”. At that time, the entire game was designed using User defined types as functions that operated on them. I understood the concept of encapsulation and managed to convert the entire architecture to a Class based object heirarchy- and it worked. My concepts still contained flaws, such as including critical game logic in down-level objects, but for the most part my udnerstanding was sound.

As my understanding of the concepts involved improved, so too did my antagonism disappear. It was clear to me that the fact that I didn’t understand classes at the time lent itself to a distaste for them- basically, the old adage that one is “afraid” of what one doesn’t understand was at least partly true. This, I feel, is at the very core of the antagonism against .NET. the main detractors of the framework are often people that neither understand the concepts involved nor do they realize how said concepts add increased possiblities and easier maintenance.

Even so- .NET has, in my opinion, one critical flaw. the IDE is slow. even on my quad core machine I see huge delays as intellisense is populated or any number of other operations. Perhaps it is a result of a mere 7200RPM hard drive? I don’t know. perhaps I need more then my current 8GB of RAM? who knows. I think, that using a 10 year old program and expecting and recieving quick responses from it have perhaps jaded me in terms of what the extra features of the new IDE actually cost in terms of performance; the delays feel like minutes, but in general it is only a few seconds. On the other hand- a few seconds is a lot longer then necessary to make one lose their train of thought. At the same time, this same argument was used against the initial usage of Intellisense; and there is no denying that although the initial display of a number of said intellisense lists can take some time, subsequent usage is nearly instantaneous, and the lists provide far more in terms of function information then the VB6 OR C++ 6 IDE could provide; this, in addition to the ease of use of assemblies between multiple .NET languages is not something that should be passed up because of an ego-centric desire to prevent change. The IT industry changes constantly. The fact that VB6 is now a “past item” should not dissuade us from moving forward because of a snobbish desire or fictitious affection for the corridor of our programming efforts for many years; the complaints about VB6 when it was introduced were very vocal. This is, no different with VB.NET, however the very complaints made about VB6 that have been remedied with .NET are now being passed off as inconsequential (since in many cases programmers have devised ways of working around limitations or even forcing behaviour that VB6 was not designed for, such as, for example the creation of Command-line programs.

The mistake Microsoft made was not the creation of .NET, but rather the belief that any sane person would move to a new platform if it was superior. They forgot the take account of the psychological factors involved.

Posted By: BC_Programming
Last Edit: 03 Nov 2009 @ 12:31 PM

EmailPermalinkComments Off on Thoughts on VB6

 Last 50 Posts
Change Theme...
  • Users » 47469
  • Posts/Pages » 397
  • Comments » 105


    No Child Pages.

Windows optimization tips

    No Child Pages.

Soft. Picks

    No Child Pages.

VS Fixes

    No Child Pages.

PC Build 1: “FASTLORD”

    No Child Pages.