Re: commabominations
Chris,
<snip>
What about recursive routines? How is the interpretter or compiler for that
matter supposed to know how many times it needs to declare a specific
variable? This is why I thought it is dynamic.
</snip>
It IS dynamic, but it involves no additional overhead, over/above the
overhead of calling the function. What difference does it make if I say,
"Allocate 2 bytes for the local stack frame," or "Allocate 200 bytes?" In
either case you are moving the stack pointer, which is to say, changing the
value in a memory location; you are just changing it to one value as opposed
to another. There is no difference.
<snip> I had said, that I felt it would be a great Idea if one of the gurus
put together a tutorial on code structuring. For all the novices out here.
It could be added to ABGTE even. or possibly even the EU docs. Coding
conventions. Standardizations for code readability and maintainability.
</snip>
Ah, but I got my head bitten off, more or less, for writing about the
importance of writing clear code. I have some ideas on the subject, but I am
not prone to casting yet more pearls before the unappreciative.
<snip>
EI.
</snip>
You mean, i.e., id est, that is? of e.g., for example?
<snip>
I TRY to use lower-case names for all routines. I TRY to use UPPER-CASE
names for constants. and Vars all start with a capital. Simple things like
these that make code more readable.
</snip>
Unfortunately, what makes code more readable for you is not going to be 100%
identical to what makes it more readable for someone else. There are lots of
conventions out there, and most of them make a certain degree of sense, even
in my well-delineated opinion.
[I can name one popular idea that I basically disagree with, and that is
Hungarian notation. Looking at Micro$oft's Hungarianized BS-crap code still
makes me somewhat ill, although I have gotten somewhat acclimated to it. But
I digress, while at the same time probably undermining my credibility with
some folks. You know who you are.]
See, I don't like all that case-oversensitivity. I use either underbar
separators (Euphoria style) or intercapping (the Win32Lib style). I'll
happily use whatever constant names are provided, but I find vanishingly
little benefit in distinguishing constants from variables by the way I write
their names. If I have any doubt whether an identifier represents a constant
or a variable, I can usually find its definition in 2 seconds, and after
that I'll remember the answer for a while.
Now, if EVERY OTHER Euphoria programmer (or practially so) used strictly
uppercase for constants, I might feel motivated to follow suit. But unless
the language requires it, people won't do it across the board, and it's too
late now to make that sort of change to Euphoria.
<snip>
I probably spent more time re-writing my code when I first started. Than I
actually did creating productive source material. I would get so lost in my
code that I wouldn't know where to even look for the numerous bugs that were
plaguing me. Let alone actually fix them!! I could see many
newbies getting very frustrated and giving up on this basis alone.
</snip>
I sympathize. Been there / done that.
<snip>
For all the guides and rules there are out there. There aren't any that
require standard structure conventions. I just think that for all the effort
spent on code readability, there should be standard methods of structure. If
we had at least some sort of guide to how the code should be structured.
Like utilizing the powerful feature of libraries. (Actually for that I think
we need a better form of an editor/IDE).
Many people don't understand the purpose these serve, and never end up using
them. what a Shame!
</snip>
Well, folks need to read a good book or two. The best I can recommend,
without bringing object orientation into the picture (which is a superfluous
"++" [ha ha ha] as far as Euphoria is concerned anyway), is Code Complete: A
Practical Handbook of Software Construction, by Steve McConnell. This book
comes as close as I can conceivably imagine to telling you literally
*everything* you need to know about procedural programming, to do the job
right the first time, as far as possible. Code Complete was published in
1993, which means it's somewhat "obsolete" now. Maybe one could pick a copy
for cheap somewhere.
<snip>
Personally I don't see the problem with the comma deal. I would like it far
less if I had to declare an END statement to the finish of my list.
</snip>
Part of the deal is that on one has to do anything different. I argue for an
additional OPTION.
<snip>
There are already too many end statements. That's why we have a debugger.
Those are caught immediately when you try to run your prog. I don't think
it's very often that you go and modify 100 lines of your code to find out
you need to add 100 commas. If you do, it's your own durn fool fault! :)
</snip>
There are already too many end statements? Let's see, "end if", "end
function", "end procedure", "end for" (that's in there isn't it? rather than
"next"...), "end while". You could include "}" as an end statement as well,
equivalent to "end sequence". Looks like just about everything that needs
ending, everything of variable length, has an end statement - EXCEPT lists
of items separated by commas (other than sequences, for some reason).
I could (and would actually like to) argue for the complete elimination of
commas, but I don't think that's appropriate in the context of Euphoria.
Anyway, currently the way to end a list of items separated by commas is to
omit the last comma. That makes the syntax for the last item irregular,
different from all the other items. I disagree with enforcing such a rule.
To be perfectly consistent, Rob wouldn't have stopped with eliminating
semicolons. He could have gone ahead and gotten rid of commas too, and a lot
of grief and inconvenience along with them, IMO. But he didn't. The language
being what it is, the most I would expect would be to have the OPTION of
writing
fish,
heads,
are,
tasty,
end
instead of
fish,
heads,
are,
tasty -- ack, irregular syntax!
<snip>
You shouldn't be making such drastic changes!
</snip>
I am not making, just suggesting. And the change I suggest isn't drastic.
Not a single line of existing Euphoria code would stop working if Rob
implemented my suggestion.
<snip>
If anything you have to go back and spend 10 secs adding ONE comma at the
end or wherever you may have inserted/removed code. No big deal.
</snip>
Well, it IS a big deal when I have to keep playing stupid games with commas
in order to get my program to run. Let's design languages so that
programmers can concentrate on the important things.
The situation that brought this to mind was a very real one. I was recetnly
coding up a window that now contains, oh I don't know - 40? 50? buttons,
arranged in groups. Not too surprisingly, I didn't want to put all the
buttons on the window at once and then write the event procedures for them
in one feel swoop. I implemented a few buttons - anywhere from maybe two to
ten - at a time. And yes, I ran into several (frequent) instances where, as
a result of adding or subtracting or moving code, a missing or extraneous
comma caused ex to refuse to run my program.
Making the change I suggest would have probably enabled my program to run a
couple dozen more times than it actually did, relieving me of tracking down
and correcting what the interpreter deemed an error - a stupid meaningless
unnecessary "syntax error" having no effect or impact on the logical
correctness of my program.
"*It is as if the language were designed to TRICK programmers into
committing syntax errors."*
If you like, I can design a programming language with practically an
infinitude of idiotic rules that you have to follow just to get a program to
be accepted by the compiler, translator, or interpreter. On the other hand,
I can design a language that is absolutely as simple and straightforward
(and yeah, prolly "boring") as you can imagine syntactically, that lets you
concentrate almost 100% on the LOGIC of the problem you're solving and the
algorithm you're using to solve it. Which, I ask, would you rather have?
That is the principle behind my concern about this matter.
Okay, this is getting just a bit out of hand - too much writing about too
little substance, IMO. That's about all I have to say on the subject. If you
and others still disagree, fine. Thanks for giving me the opportunity and
motivation to (I hope) fully and adequately explain my thinking.
Best regards,
George
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
|
Not Categorized, Please Help
|
|
