Thoughts from Dan Miser RSS 2.0
# Tuesday, April 13, 2004
I've seen some people bemoaning the "lack of innovation" from Borland. That got me thinking a bit, and that's never a good thing. :-)

The main argument people seem to make when arguing "lack of innovation" is something along the lines of "Delphi 7 isn't anything more than Delphi 6 with a bunch of 3rd party software packed with it" or "Even the MDA work Borland is doing was done via acquisition". While this is provably false, even if it were true, I don't see the problem. If a company looks at the develop vs. acquire decision (a logical extension to the build vs. buy decision) and comes to the conclusion that it is more cost-effective to acquire, then it is the smart thing to do. By recognizing that you are finite, and allocating your resources accordingly, you make wise business choices. To develop technology yourself despite a cost-effective alternative is nothing more than pride to the point of hubris.

Secondly, if one company - be it Borland of Microsoft - continually adds features to their product that are addressed by existing third parties, then they will cause a collapse in the third party market. After all, why should a third party innovate when they know that a company with deeper pockets will just come along and implement the same thing in their core product (more on this later). In addition, the same people that argue that Borland has just been acquiring technology argue that Borland should reinvent that exact same technology and bundle it into the core product. So they are effectively advocating that one company should address all needs for all developers. I would rather have choice and competition in the market to spur the industry to greater heights. Besides, making both of the first two arguments in the same post is illogical. Either you think a company should innovate everything, or it should innovate nothing. If you argue in between, then you are just arguing with which things got bundled in.

Lastly, innovation is only innovation in the short-term. In the long-term, the first product to market rarely gets a stranglehold on the market no matter how good it is. For examples look at Macintosh, IBM DOS, MIDAS, and countless other technologies. They were ahead of their time, but were not immediately accepted. Instead, they served as the thing that others wanted to "emulate". After the innovation had time to mature, another company came along and "borrowed" from that innovation. Typically, people who pish-poshed a technology (e.g. Delphi or MIDAS), come around and extoll the virtues of the new technology (e.g. .NET FCL or ADO.NET). So it isn't as much about innovation as it is about marketing or brand allegiance.

Tuesday, April 13, 2004 9:07:00 AM (Central Daylight Time, UTC-05:00)  #    Comments [5] -
Delphi
# Thursday, April 08, 2004
Interview with Clippy is a hilarious read. Great satire.
Thursday, April 08, 2004 2:05:00 PM (Central Daylight Time, UTC-05:00)  #    Comments [0] -

# Monday, March 29, 2004
Steve Trefethen just posted this little tidbit on how to have Windows Search find your Delphi files. While I seem to recall seeing this behavior some time ago, I didn't dig into it and kept using my trusty grep to find text in files. Maybe this is what I needed to start using a GUI instead!
Monday, March 29, 2004 2:28:00 PM (Central Standard Time, UTC-06:00)  #    Comments [1] -
Delphi
# Wednesday, March 24, 2004
I'm not sure which entry in Anders Ohlsson's blog is more interesting: Bill Gates stops by the Borland booth or C#Builder wins "Best Development Tool
Wednesday, March 24, 2004 2:26:00 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -

# Tuesday, March 23, 2004
Some posts in the Borland newsgroups have got me thinking about what a professional programmer's responsibility is when a bug occurs in code that is not theirs. The result is this list of guidelines and principles. The main thrust of this list assumes that a programmer is a technical person by nature. They do not need to be coddled and led by the hand.
  • Most bugs that are perceived to be bugs in a vendor's codebase, are usually not the vendor's fault. The first Maxim of Debugging is: The bug is most likely in your code.
  • Make the effort to work with the vendor of the bug to provide a clear, minimized, reproducible test case that demonstrates the bug. Expecting the vendor to fix a bug that they don't know about is just silly. If the bug is important to you, report it in a thorough manner.
  • If the bug is a true show-stopper (a term that is much over-used, in my opinion), then find a work-around. There are always other ways to express what a program should do. Rarely is a bug so serious that you can - in good faith - throw your hands up in the air and claim defeat. A professional programmer looks at this as an opportunity to distinguish themselves. If you code the work-around in a non-intrusive way, you can remove it easily when the vendor does fix the problem.
  • If you have source code for the library, debug it. It will help you understand exactly what the bug is, and hopefully, help you down the road by preventing you from making the same mistake. This can also help in bug reporting and finding a work around.
  • If you don't have source code, you can still make assumptions about what part of the black box isn't working and write a test case to prove that. If your assumptions are wrong, modify the test case.
While bugs are an inevitable fact of life, it's how you deal with them that truly defines what kind of programmer you are. Everyone has deadlines, but taking time out of your schedule to work with your vendors to resolve problems is part of your responsibility as a professional programmer.
Tuesday, March 23, 2004 9:30:00 AM (Central Standard Time, UTC-06:00)  #    Comments [6] -

# Wednesday, March 17, 2004
I've been playing with ObjectSpaces (OS) lately. I like the idea and the implementation is pretty good. The main limitations I see are:
  • For the foreseeable future, it will only talk to MSSQL (and it's various flavors). If they're writing an Object Persistence Framework (OPF), shouldn't someone have mentioned that they should probably abstract out the DB-specific stuff? I understand this is 1.0, but please, that is so limiting that it almost makes OS unusable. Do I really want to have DB lock-in to MSSQL? I don't think so.
  • It is tied to Whidbey. With the delay shipping Whidbey, this means that we won't see a production-capable version of ObjectSpaces until Q1 of 2005! That is a long time to wait to get OPF. Microsoft should find a way to unbundle certain pieces of the PDC preview - such as ASP.NET 2.0 and OS - and deliver them on a schedule that is independent of an IDE release.

At any rate, here is some good material to help get up to speed on OS:

I plan on writing some articles detailing my experiences (good and bad!) with OS, discuss alternative OPFs, including ECO (available in C#Builder and Delphi 8), and flesh out some best practices when using this kind of technology.

Wednesday, March 17, 2004 2:16:00 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
Delphi
# Monday, March 15, 2004
Scott Nonnenberg published some details on How to write custom visualizers for Whidbey. This seems like a very powerful capability for debugging.
Monday, March 15, 2004 10:44:00 AM (Central Standard Time, UTC-06:00)  #    Comments [1] -
.NET
# Friday, March 12, 2004
Here is another open source project worth checking out. If you want to do some VNC development using Delphi, check this project out.
Friday, March 12, 2004 10:38:00 AM (Central Standard Time, UTC-06:00)  #    Comments [5] -
Delphi
Navigation
Archive
<April 2004>
SunMonTueWedThuFriSat
28293031123
45678910
11121314151617
18192021222324
2526272829301
2345678
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2012
Dan Miser
Sign In
Statistics
Total Posts: 375
This Year: 3
This Month: 0
This Week: 0
Comments: 654
Themes
Pick a theme:
All Content © 2012, Dan Miser
DasBlog theme 'Business' created by Christoph De Baene (delarou)