I've been doing a lot of coding lately on CMUD and TeSSH, trying to get it ready for the next beta release.
Some days, programming is fun. You get to solve challenging problems in creative ways. You get to build something from scratch that didn't exist before, and you have almost total control over it. If you want a cool new feature, you work hard at it until the problem is solved and that gives me a great amount of personal satisfaction and motivation.
Then there are the "other" days. Days like today. When all you want to do is fix a bug or add a new feature, but instead of spending time on your actual code challenge, you deal with weird, flaky, random, annoying problems that seem completely out of your control. Suddenly, something you expected to take five minutes ends up taking four hours. Some stupid, trivial little problem that just won't go away that really has nothing to do with the core work you were trying to get done.
Today was like that. I was working on the "jerky" mapper panning, and the mysterious appearing/disappearing horizontal scrollbar. Resize the map so that the horizontal scrollbar isn't needed and it disappears. Well, almost. A blank bar still remains where the scrollbar used to be. Tweak the window size just a bit and it magically disappears. Now resize the window smaller to make the horizontal scrollbar appear again. It doesn't. But again, if you tweak the window size just a bit, it will suddenly appear.
What the heck is going on here. The code for this is really simple:
Code:
if (WindowSize > MapSize) then Scrollbar.Visible := false
else Scrollbar.Visible := true;
How can something this simple go so terribly wrong?? Then, just when you are in the middle of trying to solve this problem and are working in the debugger, you come across a block of code like this:
Code:
v := somevalue;
if (v <> nil) then begin
// do stuff here
end
else begin
// do other stuff here
end;
And when you debug this code, the Delphi debugger skips *both* sections and doesn't execute either of them!! How in the world is this possible?? Isn't the whole idea of an if-then-else statement that you will execute *one* of the blocks? How can the debugger skip both blocks completely?
It's usually about this time that Chiara goes into the other room because she is tired of hearing me swearing at my computer. The cats all run away, and I'm left alone with my problems. I scream at the computer until my face is red, and contemplate the wisdom of throwing my computer though the window of my office. At this point, the neighbors are probably ready to call 911 thinking I'm about to murder someone (yes, my computer, I'm talking about you!).
It's days like these that I wish I wasn't a programmer. I wish I had never seen a computer. I wish that I was on some tropical island where they have never heard about computers.
Instead, I just keep yelling at the computer and keep trying random stuff until the gremlins go away and leave me alone and everything magically starts working again.
In the above cases, the scrollbar issue was caused by some screwy Windows messages that were still in the queue when the window was being resized. I was responding to one of the resize messages and toggling the Visible property of the scrollbar, but during the message I was handling, toggling the Visible property doesn't work in Windows properly. The solution was to post my own user-defined message into the Windows message queue telling the scrollbar to enable/disable after the rest of the messages were processed. One of those times that Windows messages will drive you crazy because of all their weird undocumented side effects.
The other case turned out to be a simple problem (BUG!) with the Delphi debugger. It only *looked* like it was skipping the code. In reality, the proper code block was being executed, but the debugger just wasn't stopping in the middle to show it to me. In fact, if I told it to single-step a few more times, it would magically bounce up to the block being executed and show me the lines being executed. It would start toggling between showing the line being executed, then popping to the line after the block, then popping back to the line being executed, etc. It had nothing to do with my code at all. It was just some weird Delphi debugger behavior that I had never seen before. After I rebooted my computer, the problem was gone. Blame Delphi, Blame Windows Vista, or just blame the gremlins that decided to make my day hell.
So, the next time you wonder why bug fixes take so long, or wonder why I don't promise specific release dates, now you'll know why. Some days the universe just doesn't want me to get anything useful done. If you ever plan to become a programmer, you have now been fore-warned.
Joined: 18 Oct 2000 Posts: 2733 Location: Atlanta, USA
Posted: Sat Feb 21, 2009 8:01 pm Re: Life of a Programmer
Zugg wrote:
And when you debug this code, the Delphi debugger skips *both* sections and doesn't execute either of them!! How in the world is this possible?? Isn't the whole idea of an if-then-else statement that you will execute *one* of the blocks? How can the debugger skip both blocks completely?
I literally laughed out loud when I read this... I can only imagine the fustration.. and sad to say, I've been there as well.
I'll glad you solved it... Here's to killing those damned bugs..
I really hate those kinds of delayed bug bombs. The latest one I had to deal with was storing some stuff into a dynamically allocated array. After rewriting with different portions of the code 5 times I was using the variable "i" as my array size and "j" as my position counter in the loop. I missed one reference, from when "i" was the counter, and had 'array[i]=value' in the loop. This meant I wasn't only storing the information in the wrong spot, I also had a buffer overrun.
The crash appeared quite sometime later and only when running the program with a debugger. To make it even odder my debugger would completely ignore the error when I stepped through the code line by line, but would report it when I ran the entire function as one step. I finally spotted the error after an hour of saying WTMHS is going on here.
As much as my work demands of me, I am glad I kept programming a hobby instead of making it my profession.
_________________ The only good questions are the ones we have never answered before.
Search the Forums
Joined: 26 Jan 2004 Posts: 5155 Location: United Kingdom
Posted: Sun Feb 22, 2009 8:03 am
This is why I never, ever use short names for variables (except when they're standardised, like k, i and v in pairs() and ipairs() loops in Lua). You think it'll save you some time typing, but then this sort of thing happens and you lose half a weekend trying to fix it because you wrote "t2" instead of "t1" - I'm looking at you, timeDiff() function mentioned in another thread.
Joined: 04 Jan 2006 Posts: 1279 Location: Portland, Oregon
Posted: Sat Oct 17, 2009 3:04 pm
Well if its any consolation, electrical engineering work is fairly similar. 10% of the time spent thinking and solving challenging issues, and 90% of the time spent fighting with tools, waiting for simulations to finish, etc.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Sat Oct 17, 2009 4:53 pm
Quote:
you use Delphi for this? awesome!
Yes! Delphi is still the best, even with the frustrations that I get sometimes. If I was forced to stop using Delphi, then I'd probably stop programming completely.
Joined: 10 Oct 2000 Posts: 1551 Location: Australia
Posted: Sun Oct 18, 2009 10:20 am
All languages have their ups and downs, I used to swear by Borland until Visual Studio 2005 was out. Coding in C# .NET is very very nice (except ASP.NET blergh!) but that's to be expected because Microsoft essentially poached the Borland team.
Has Delphi kept evolving?
I wouldn't want to fathom the job of converting CMUD to C# - I'm sure theoretically it could be done and keep the same level of performance but not without driving you completely nuts! :)
I found converting my custom controls over wasn't too bad, but there's definitely some gotchas moving to the .NET platform.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Mon Oct 19, 2009 3:53 pm
The main problem involved in moving platforms (or porting to any other system, such as Linux, Mac, etc) isn't the actual Delphi code itself, but it is all of the 3rd party components that I use for various UI elements. Although I do use Developer Express components, their .NET and VCL components are still a bit different. And then there are other components that do not have .NET equivalents.
It would be roughly the same job that I had when I wrote CMUD from scratch and moved from Delphi 5 to Delphi 7. This required new components, getting rid of some old components (like the old zMUD window docking system that was no longer available), and rewriting much of the code. And that process took over two years. Given the decline in the MUD market, there is no way it would make any business sense for me to convert.
Yes, Delphi has kept evolving. They just released a new version a couple of months ago. It contains the new Unicode version, which is potentially useful for CMUD but it requires that I rewrite parts of CMUD to make it Unicode compatible myself, so upgrading to this new version of Delphi may be more difficult than normal. It's something I'm putting off until next year.
And yes, I like tell people that ".NET is essentially Delphi for Microsoft Visual Studio developers". As you said, the main Delphi developers were hired from Microsoft and essentially responsible for much of .NET. A lot of what people like about .NET has already been in Delphi for many many years.
Joined: 10 Oct 2000 Posts: 1551 Location: Australia
Posted: Mon Oct 19, 2009 9:54 pm
I would say syntax-wise java and C# are fairly similar, but .NET has a huge library of controls and components and the drag/drop form design that we came to love from the Borland suite. I haven't played with java in a long time, so I assume they have made some progress toward that drag/drop design too?
Unicode still bugs me, I mean... I understand the necessity for it when dealing with multi-lingual stuff, but most of my work is done on Windows Mobile devices where system resources are limited. Using double-byte strings everywhere seems such a waste of space when 100% of my customers only ever use English. It's especially bad when you've got several megs of string data coming down via a web service!
Still, hopefully Unicode CMUD will expand the market into other languages and you'll pick up some more sales :)
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Tue Oct 20, 2009 4:15 pm
There is a huge difference between just looking at language "syntax" and looking at a full development system. As Rainchild mentioned, Delphi and .NET provide huge libraries of drag/drop user interface controls. You design the user interface of an application by dropping visual components on a form and hooking up events and then writing code for the events.
Java is still a long way from comparable user interface design. Swing provides basic UI components, and NetBeans attempts to provide an IDE for drag/drop user interface components, but both are still lightyears behind both Delphi and .NET. So while the underlying languages are similar, and while I personally love Java, it's still a ways behind on high-end user interface design. It's getting better, and quickly. In fact, my experience with Java and NetBeans is several months old, so maybe it's already better. But at the same time Java is advancing, so are Delphi and .NET. I personally think that Java is better suited to back-end development of network services rather than front-end desktop applications.
Rainchild: I feel the exact same way about Unicode, which is why it hasn't been a big priority. Also, in the case of CMUD, the "markets" that would benefit from Unicode are not the markets that typically pay for software. So I'm not sure how much Unicode support would actually translate into real sales. Those markets tend to buy time in Internet Cafes and don't pay for software and install it on their own computers. CMUD doesn't really work in that business model.
Hi, I understand all the works of a programmer. However, I think , this career would need a lot of challenging moments to be able to attain goal and success. In such case, the life of a programmer is typically a dedication of works in front of a computer but if you are interested in it, then, you would realized that it is rewarding and essential overall:)
Life of programmer is tough, that's why you get paid well for doing that kind of work. I know it can be annoying, but try to find answer on the internet, ask someone for help, Google it. I know its wasting of time but I'm always doing sketch step by step. 1 step : bla blabla 2. step babla bla and if something is no working I will know in which step there is a mistake.
You cannot post new entries in this Blog You cannot reply to entries in this Blog You cannot edit your posts in this Blog You cannot delete your posts in this Blog
