Re: Been a slice...
From: Bjørge Sæther (bjorge_at_hahaha_itte.no)
Date: 10/31/04
- Next message: Duncan Murdoch: "Re: Been a slice..."
- Previous message: Maarten Wiltink: "Re: Program terminating"
- In reply to:(deleted message) L D Blake: "Re: Been a slice..."
- Next in thread: Diane Arons: "Re: Been a slice..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 31 Oct 2004 19:33:53 +0100
L D Blake wrote:
> On Sat, 30 Oct 2004 19:21:14 +0000 (UTC), erewhon@nowhere.uk (J
> French) wrote:
>>>> It would be interesting if someone put together a brief summary of
>>>> the SEH debate and its implications.
[...]
> And there are 3 kinds of programming.
>
> The first, and the oldest, is linear programming, like MSBasic, where
> you just keep railing along until you need to branch off into
> something else. This produced tiny, fast and surprisingly reliable
> code on older processors.
>
> The second it procedural programming, like TP 1 through 5. Here you
> build procedures to do tasks for you and call them in what is
> generally a sensible order and the program does it's job.
>
> The third is Object Oriented Program where the distinction between
> code and data gets blurred so that everything as all part of a Class
> or an Object and the methods of the Class operate on the Properties
> of the same class... producing an unordered and hopefully coherent
> result.
The 2nd and 3rd aren't that different. They're both synchroneous, and they
both encapsulate functionality within routines. Purposes are the same;
Detials hiding and code reuse. Classes may hide more, and has a potential of
more blurring. This is a normal concequence of information hiding - but also
a must when tasks grow large.
> Ok fine, these are the perspectives of a fast aging programmer who's
> entire career has been spent producing little bitty programs that
> mostly no other programmers would touch. The kind of stuff where a
> big programming house would lose it's shirt has made me a reasonable
> living over the years. I write diagnostics, utilities, single
> purpose applications, things like that. In all my work I've created
> only two really large applications and they are presently being
> phased out because of their age; one is more than 15 years old the
> other is just over 8. So except for the "tiny code" stuff, I've been
> hooking my customers up with other products and helping them get
> settled into the new systems. I am hoping to retire into a pleasant
> little hobby of producing freeware and shareware applications and
> occasionally helping my business partner with his hardware business.
For small applications, structure isn't very important.
> It is also correct to observe that I am perhaps one of few remaining
> people who worries much about program size. This is necessary in my
> niche of the trade since some of the stuff has to work in very tight
> places; sometimes even on floppy disks. When cramped quarters aren't
> the issue, smaller code amounts to better, more stable programs and
> often it can produce interesting leaps in speed as well. However
> this is not the huge concern some people seem to perceive. Realizing
> I have hundreds of megabytes to play in does take the pressure for
> size away but still it's a good idea to produce code that doesn't
> suck up half a user's machine to play a music file. You could
> observe, correctly, that I prefer substance over form... As anyone
> who's tried my two little freeware appies knows, my stuff doesn't
> look fancy or have whiz-bang new features in it but it does get the
> job done.
There are interesting things here:
*If* you are about to create an application in the shortest possible time,
every little bit that you won't need to deal with is precious. Even if you
know that you could probably create far better code snippets than the
pre-built components, you go for the components. This is to me the "basic
idea" of component-based programming.
It has obvious downsides, much like that of using a calculator: If you don't
use one, you'll be good at "brain maths". But - calculating a square root is
slower. It's obvious that to be able to handle a calculator without
necessarily forgetting how to add 114 to 265, is the best. But the
calculator will probably reduce your math skills.
Another point is that the chosen components may very well have inherent
weaknesses, or be hard to use due to a poorly designed surface. Then what
you gained through a quick start may easily be lost before you finish. Being
a programmer in 2004 requires you to be good at concidering what to use and
what to write. Networks like this NG may be helpful to you here.
I *do* agree with you that dropping components on a form doesn't improve
your programming capabilities. Because theses components don't exist that
may save you the work of being able to do it for yourself. Only the skilled
programmer is able to make sound judgements on concepts and components.
> Then along came Delphi...
>
> When I made the jump from hardware back into software a couple of
> years ago I'd been away from programming for about 5 years. My life
> had changed rather a lot. For one thing I was on disability, working
> part time as a repair tech and not exactly thriving financially.
> During these times I was doing my best to maintain some POS systems
> I'd written before my injury and trying my best to keep half a dozen
> customers happy. My current business partner took quite the risk
> bringing me into a partnership but fortunately it's worked out well
> for both of us. He was struggling to keep a profit from hardware and
> I was just plain struggling. Being able to sell his customers those
> "small things you've always wanted..." gave the business quite a
> boost.
>
> To say that programming languages had moved on *considerably* during
> my absense is to grossly understand the case. I went directly from
> TP5 to Delphi
> 7... YIKES, talk about an eye opener! Two weeks of that and I was
> off looking for something that at least resembled programming... I
> first went to Free Pascal, not wanting to throw away good money after
> bad and found it to be buggy and incomplete. Next Virtual Pascal,
> which turns out to be abandonware with certain crucial features
> missing... so back to Delphi...
...about the same as I feel when I get presented to an old
TP-application...I find the structure hard to grasp, but I also get charmed
by the share innocense of the thing...a few thousand lines and that's it ;-)
> I will *never* be a drag and drop programmer and I use objects or
> classes sparingly because they really don't fit in well with the way
> my mind works as a programmer. Additionally the whole Delphi concept
> stikes me as a hideously complicated way of doing some very basic
> things. No offense to anyone on this list but Delphi's RAD tools
> strike me as "programming for dummies"... you get to produce code
> without even really knowing what you've written! (Of course there
> are some very smart people using Delphi... but the philosophy of the
> IDE seems to be that of giving access to programming tasks to people
> who have no programming skills.)
There are ways of Delphi programming that don't involve Drag'n drop, or
where Drag'n drop is reduced to form design. The IDE features used then is
mostly connected to editor tools and debugging. It's OOP.
The RAD stuff is a show killer. Made specially for up-to-4-hours
presentation. A pity Borland puts so much into this phase of application
development, for sure.
> So I climbs into the guts of it and wonders what can be done to
> salvage this $1200 investment. A friend of mine cued me in on the
> RTL and suggested I try using that directly, programming WinApi
> style. This evolved into the subset of Delphi using only the
> underlying Object Pascal you saw on my website.
>
> Unfortunately it hasn't been quite that simple. Certain parts of the
> OP underpinnings were "bent" to play nicely with RAD and VCL
> developement. These are fairly minor... mostly involving the
> creation of objects in places where I would not normally consider
> using them.
>
> Ok... back to the beginning... In the world of errors the most
> meaningful descriptor of an error is it's Code number. "Error 666"
> means a lot more and provides a ton more information than "Error
> EDemonicPosession" One can argue that both convey the same
> information, but one does so in a simple D word and the other carries
> a ton of baggage along with it. Also if you look at the base
> definition of the Exception Class you will discover the error code
> isn't even stored! This struck me as totally ridiculous...
> abstraction to the degree of meaningless...
>
> So I began looking into how this was done and why. The only real
> reason I could find for it was that someone decided to do it that
> way. I am left with the impression that whoever did it was less
> concerned with concisely relaying information than with creating
> something worthy of a paycheck.
>
> So it's about this time I joined this newsgroup...
>
> My first entry here was to ask for help sorting out the underlying
> mechanism of Delphi error handling... Windows exception handling.
> Several of you were surprisingly helpful in this regard and I did
> manage to come up with a modification for the exception handlers that
> did what I wanted... it allowed me to get an error code from the
> exception handlers and it corrected the problem of OS Exceptions not
> working without SysUtils loaded.
>
> I was, in fact, very grateful for all the help you'd given me and
> decided to settle in and see if I couldn't return the favour.
>
> Then Diane Lask showed up...
>
> This person took it upon herself to bring my personal life into the
> debate, exposing this newsgroup to more than a little of the strife
> I've suffered as a result of her constant harassment and lies.
>
> From there, things have been going badly. The attitudes of people
> here changed very pronouncedly. Suddenly I find myself constantly
> challenged. Nothing I say is left to stand. One writer here called
> it "Kicking in the shins" and I gotta tell you, that's excactly what
> it feels like. Overnight I went from an interesting person to
> someone to be opposed at all costs and several people here have gone
> out of their way to shoot me down at every opportunity... Everything
> I was doing was wrong in some way, everything I suggested was silly,
> everything I offered was unworthy. Interesting conversations became
> pissing matches.
>
> So, I waited for a while and then asked about the second half of
> Delphi's exception handling, the Try/Finally construct. I wasn't
> really determined to change it all around. I was mostly interested
> in learning how people would improve it, if they could... thinking
> that perhaps I could find a way to incorporate those changes without
> causing too much havoc with the basic Delphi functions... like I did
> with try/except.
>
> Next thing I know my professional qualifications and business
> practices are being ripped apart --apparently by Borland employees--
> and somehow the notion that I might change Delphi is offensive and
> dangerous to everyone here.
>
> Ultimately... I really don't think any of what happened in the last
> few days had a damned thing to do with programming or Delphi. A
> couple of you did eventually settle in and we had a very good
> conversation about several aspects of SEH and it's inner workings...
> but mostly I was simply challenged, because it was felt that I had to
> be challenged.
>
> So there you have it... That's what I think all this was about.
>
>
> -----
> Laura
-- Regards, Bjørge Sæther bjorge@haha_itte.no ------------------------------------- I'll not spend any money on American Software products until armed forces are out of Iraq.
- Next message: Duncan Murdoch: "Re: Been a slice..."
- Previous message: Maarten Wiltink: "Re: Program terminating"
- In reply to:(deleted message) L D Blake: "Re: Been a slice..."
- Next in thread: Diane Arons: "Re: Been a slice..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
