Re: The War On HLA
From: Randall Hyde (randyhyde_at_earthlink.net)
Date: 10/30/03
- Next message: Randall Hyde: "Re: The War On HLA"
- Previous message: Beth: "Re: HLA features"
- In reply to: The Half A Wannabee: "Re: The War On HLA"
- Next in thread: The Half A Wannabee: "Re: The War On HLA"
- Reply: The Half A Wannabee: "Re: The War On HLA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 30 Oct 2003 17:05:16 GMT
"The Half A Wannabee" <ShakainZulu@hotmail.com> wrote in message news:3fa0fa7c$1@news.broadpark.no...
>
> >
> > No macro facilities, for example.
>
> I guess not. I never had any need for it either. You know, its the same as
> inserting code into the place you place the macro name. You dont need to
> jump. It makes the code longer and thus the compiler cannot optimize as
> well. Best code in delphi is a few lines at most. It helps the optimizer
> makeing better use of registers.
As macros expand in-line and are the same as simply writing the code
in-place, clearly the use of macros has no impact whatsoever on optimization.
If you're assuming that macros' only purpose is for "in-line" functions, I
can understand why you might come to this conclusion. However, macros
do have other purposes. The macro facilities in the Dylan, Lisp, and Haskell
languages demonstrate the ability of using macros to extend the language.
Oh, I forgot, the macro system in HLA *also* demonstrates how to extend
the language with macros :-).
> In sections of code where you need real raw speed, you dont need macros
> either, you need hands on optimizations, no time to waste on macros there.
In sections of code where you need raw speed, you need to be careful
about using black boxes (e.g., macros). However, if speed is that important,
I would ask why you're using Delphi in the first place. Delphi's okay, but the
optimizer is *far* from great. Macros in Delphi would be nice because they
would allow you to *extend* the language to produce shorter (lines of source
code) programs and, if done carefully, easier to read programs.
> You need MAbrash, patience, willingness to rewrite, and rewrite and rewrite
> and do it over again and over again. Macros is not a big loss. Hardware (New
> CPUs) have made jumps far less expensive than previously.
Again, the desire for macros has nothing to do with in-line functions.
> > The only facility for initialized static variables is via structure
> constants (a
> > bit of a kludge).
>
> const
> ListOfSomeUnsignedIntegers = array[0..2] of Longint = (100, 30000,
> MaxLongint);
>
> That was hard. Const are writeable in Delphi (optional).
Therein lies the kludge.
Writeable constants :-) Just as bad as the use of the const keyword in C++.
> Also. Real
> programmers use code to initialize variables. It saves time, and its much
> easier to produse diffrent initializations.
?????
What on earth makes you say this?
Ignoring languages, like C, that let you initialize static objects at compile-time,
just consider assembly language programmers (i.e., the people who
frequent this group). They statically initialize data all the time. Are you saying
that assembly language programmers "aren't real programmers"?
Note that if you initialize "constant" objects with code, you pay for
that initializing three times: 1: the memory that holds the actual object,
2: the embedded constants in the instructions (or other section of
memory) that holds the data you're copying to the memory object, and
3: the machine instructions needed to copy the data.
If you've got a table of strings, records, whatever, initializing this
by code is very expensive, space-wise.
I would really like to see your justification that code is easier to
maintain.
> But for a class of student
> learing HLA it might be more suitable to hardcode. But it Never is in real
> life.What you need in real life is a 3d editor to edit your data.
And it would be nice to have the loader preinitialize that data so you
don't have to waste code and time doing it once the program starts up.
As the stuff is not "constant" data, it doesn't seem write to declare
such variables in Pascal's "const" section.
> >It would also be *really* nice if it supported thunks or
>
> What are thunks ? Abilty to talk to 16 bit code ? thats supported by the
> API, and thus by Delphi, am I wrong ?
Microsoft's "thunks" are a small category of the general concept of
a thunk. A thunk is a piece of code and its execution environment
rolled into a variable. One way to think of a thunk is as a variable that
can hold a statement (or sequence of statements) for later execution.
This allows you to treat statements as "first-class" objects in a
programming language (i.e., you can assign them to variables,
return them as function results, do various operations on them, etc.).
Note that a procedure does not qualify because it doesn't carry
the execution environment around from where the thunk was
created.
> Why would anyone would want to do that is beyond me, but I see there would
> be a need 10 years ago. But its a bad idea, and very lazy. I reworte my code
> for 32 bit rather than using the thunk mechanism. Many years ago. The code
> got cleaner for it too. You dont need 16-bit code in windows, you need a
> service.
This has nothing to do with 16-bit vs. 32-bit code.
It has to do with deferred (eager vs. lazy) execution which is *very*
important in AI and in certain algorithms.
> > pass by name parameters.
>
> Pass by name parameters? I dont even know what you are talking about. Pass
> by name parameters? If I knew what it was I could show you the code. What is
> it that you want to pass by name in parameters. And how would it not be
> supported ?
Take a look at the following chapters in the on-line version of AoA
at http://webster.cs.ucr.edu/Page_AoAWin/PDFs/0_PDFIndexWin.html
Vol 5, Ch1: thunks,
Vol 5, Ch2: Iterators,
Vol 5, Ch3: Coroutines
Vol 5, Ch4: Low Level Parameter Implementation
These chapters nicely cover topics like thunks, pass by name,
iterators, coroutines, and other nice features that would be
nice to have in Delphi.
> >32-bit unsigned integers would be nice, too.
>
> ???
Delphi currently supports only 31-bit unsigned integers.
>
> > Iterators and a foreach loop would be great.
>
> This was supported earlier, but was removed from the RTL. Thats because
> there are much better ways to handle such situations. I write my own foreach
> loops quite easily.
No, you don't. Unless you're calling assembly code from Delphi.
See the aforementioned chapter on Iterators in AoA. The things
that Delphi and C++ users call "iterators" are not truly iterators.
They are better known as "cursors". To learn more about what
a real iterator is, check out the CLU programming language
(which is the first place I'm aware of where iterators were
created). Also look at iterators in HLA.
> Procedure TSZSkinTable.ForEach(AProcedure : TItemProcedure);
>
> var
>
> j : integer;
>
> begin
>
> for j := 0 to MaxLines -1 do
>
> AProcedure(self, j);
>
> //We call one more time to tell that we are done
>
> AProcedure(self, -1);
>
> end;
This is a cursor, not an iterator. Check out the
chapter on Iterators in AoA to see the difference.
>
> > The list could go on and on.
>
> No it couldnt. Thats a very poor statement from a man like you.
Really?
I've taught programming language design for the better part of
a decade at UC Riverside. Perhaps it's not unreasonable for me
to claim that I could come up with a lot of language features that
Delphi should have, but doesn't? The truth is, no matter how long
the list gets, I can still make this claim. Delphi is far from perfect
(from a language design point of view); I just chose to cut the list
short for space reasons. If you believe that Delphi is the be-all,
end-all, of programming languages, I strongly suggest that you
take a course on programming language design. There's quite
a bit more that could be added to Delphi. For example, I haven't
even discussed dynamic language features, advanced data structures,
non-imperative programming facilities, and so on.
I'm sorry I don't have the time to write you a 500 page book
explaining all the nice language features Delphi *could* have but
doesn't. However, such books already exist (not to mention lots
of journal papers), so there really is no need to repeat that information
here. Go grab one of those books and read about it for yourself
if you're interested. Making statements like "No, it couldn't" is a very
weak statement, even from someone like you :-)
> > Then, of course (bringing this discussion back on-topic), Delphi's support
> > for linking with external assembly code is asbysmal.
>
> I stopped linking in .obj code i wrote in tasm, when I saw how easy I could
> avoid the pain by just pasting it into the editor and rewriting it pascal
> style syntax in BASM. So I couldnt say. I dont complain about support for
> something that isnt needed anymore.
The fact that *you* don't use it doesn't mean it isn't needed.
> BASM is pretty good
> > for a built-in assembler, but it's nothing compared with MASM or HLA.
>
> How so. It support ALL contructs in the Object Pascal language. It supports
> accessing types like this :
> asm
> mov eax, [ebx].TPoint.X
> mov edx, [ebx].TPoint.Y
> end;
>
> This kind of asm, doesnt even need an explanation for an HLL programmer,
> familiar with windows, to understand what is going on. Can you do this in
> HLA ? I guess you could. Only it would look like this :
>
> mov (([(ebx)].TPoint).(X)(eax), )
> mov (([(ebx)].TPoint).(X)(eax), )
>
> Sorry if that was wrong, but I got confused by all the extra padded
> parantesis :-) Lol
If all you need is MOV instructions, BASM is fine :-)
I hate to be condescending here (something I get accused of
frequently), but if you think that BASM is just great -- stick with it.
Those of us that do a bit more advanced work in assembly find BASM
a little, well, limiting.
BTW, in HLA you'd probably use statements like the following:
mov( thePoint.X, eax );
mov( thePoint.Y, ebx );
If you were actually using these two statements all over the place.
You'd set up a text object to do the coercion for you. If you were
only using these two MOV instructions, then you'd probably just
stick with BASM -- That's what it's good for. I thought I made it
clear that BASM is great for simple stuff, you need a better assembler
for advanced assembly code. You didn't give an example of advanced
assembly code, I'm afraid. So your example doesn't do a good job
of demonstrating where BASM fails.
>
> > The ability to only really work with TASM-assembled code is somewhat
> > sad. Also, it would be really nice if you could produce object files you
> could
> > link with other languages.
>
> Never did that so cant tell. I bet its supported if you look deep enough, at
> least in one of the former versions. Like the former BP7.0 which as far as I
> remember supported lots of nice stuff like that, but this I cannot really be
> sure of at the moment. But the current version supports interfaces, and
> writing of comservers to let C++ and VB user use you code is easy. A bit
> pain with the bloated interface editor, but not at all difficult to
> accomplish with the tougue kept straight in mouth.
> >
> > This is not to say that Delphi is a bad language. It is one of my favorite
> > HLLs out there. But every HLL is crippled in one way or another.
>
> This is such a strange thing to say. EVERY HLL is crippled. Its like saying
> everyone but me is stupid. I say that a lot when I am frustrated, but I know
> it isnt true.
Let me rephrase that. *EVERY* language (HLL or LLL) is crippled in
one way or another. If this weren't the case, we'd all be using the one
perfect language out there.
Cheers,
Randy Hyde
- Next message: Randall Hyde: "Re: The War On HLA"
- Previous message: Beth: "Re: HLA features"
- In reply to: The Half A Wannabee: "Re: The War On HLA"
- Next in thread: The Half A Wannabee: "Re: The War On HLA"
- Reply: The Half A Wannabee: "Re: The War On HLA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
