Re: A rant on an Ideal languages Was: Re: RNG Test: Code to
On Thu, 17 Feb 2000, you wrote:
> >%_At 08:16 PM 02/17/2000 -0500, you wrote:
> >On Thu, 17 Feb 2000, you wrote:
> >> Joel: if you ever get it(U4) figured out ... please share your insight.
> >> FRUSTRATED here also.
> >
> >It would be instructive to all of us if you would give an example of a
> >programming language you find _non-frustrating._
> >
> >I've been looking for one for a long time.
> >
> >Regards,
> >Irv
>
>
> We could all laugh out loud at the foolish guy who tries to answer this
> question. Ok I'll play the fool.
>
> Let's take Euphoria as a starting point.
>
> I want a language to write like I am instructing the machine how to do what I
> want it to do.
>
> Shorthand is ok but cryptic is not.
>
> I like the idea of :
>
> writeln(file1, "This is part of a test file entry")
>
> and the program writes the string: "This is part of a test file entry" into
> the
> text file with the \n \c
>
> already appended, and if I say
> write(file1, "This is part of a test file entry")
>
> it writes to the file without the linefeed and carrage return characters
>
> or
>
> write("Hello world" ) and it writes "hello world" to the
> screen
>
> Ok so that's pretty much pascal conventions.
Ok, I'll play along also ;)
I really prefer a dot . (as in FORTH)
Much simpler, quicker to type. Too bad the rest of the language is
backward.
>
> "puts" to me seems like a goyim spelling of putz and makes as much
> sense.
>
> C is a great language but it fails as much as it succeeds because the
> programmer is forced to begin to think like the compiler rather that the
> compiler helping the programmer to "execute" the programmer's ideas
All languages are that way. C is just more so than most.
> The types in U4 are fine and it has type creation extensibility this is good!
> But type declaration is odd and at times down right strange. I was originally
> left with the impression that type declaration in u4 were not required and
> types could be thown around at will -- not so. Hmmm. Gotta be the User! (HEY
> THATS'S ME!)
Types are a real failing - they exist, but then disappear just when you need
them most. A lot of the type checking is left up to the user in Euphoria -
meaning I am free to print a string as a series of numbers, or a series of
numbers as a string. That is not always a good thing. For one thing, it means
that there have to be at least two ways to print anything - one for when I
want it to look like a number, another if I want it to look like a string. I
have to choose one or the other each time I work with that variable. It would
be far better if I could specify what I wanted a variable to be when I declare
it. Then Euphoria would "know" how to print it whenever I wanted to print it.
(And we'd need only one print function)
> Then there is sequence thing... to me (sillyme!) writing:
> for i = 1 to 10 do
> ThisIsADataSequence[i]=0
> end for
>> makes sense to zero a one dimensional array
It will. But you have to declare the array and its size before you can zero it -
just as in most other languages. The above loop fails just the same in Pascal,
if your array is undefined or incorrectly dimensioned. A sequence (array) in
Euphoria has a dimension of zero until you tell it otherwise.
> who would have thought that:
> repeat(ThisIsADataSequence,10)
> is the only way it will initialize a zero'd sequence otherwise an error is
> thrown.
That's not quite correct syntax. What you're doing is making 10 copies of
ThisIsADataSequence. If it is an empty sequence, then you've got an array of
10 empty sequences. If it's not empty, then you've got 10 copies of whatever
was in there.
ThisIsADataSequence = repeat(0,10) will create an
array[1..10], initialized to all zeros. The fact that you can fill it with a
value at the time of declaration is a plus.
> and I'm still not sure that
> for i = 1 to 10 do
> ThisIsADataSequence[i]=i
> end for
>
> is a legal for operation.
Certainly it is, if you have 10 spaces available in "ThisIsADataSequence".
If you don't have 10 spaces, then you can always tack another one on.
Try that with a Pascal or Basic array.
> Support for 32 bit logical operators would be nice... Hey if I'm going to
> have
> to rewrite C functions into Euphoric-C the least I need is to have the same
> base types of operators
> I LIKE n dimensional arrays. Having to build sequences of sequences of
> sequences.... of sequences and then having to figure out how to insert data
> into them makes my foolish head hurt.
Then you haven't worked long enough with Euphoria. You can do a lot of things
that are nearly impossible with other languages, using those sequences. And,
if you want n dimensional arrays, declare some.
> While we're at it let's throw OOP on the fire as well. Ever found an EASY OOP
> language? Ever found OOP useful?
Yes. Writing GUI's is a place where OOP is actually useful. It's also not too
bad for writing a database engine. That's about all.
>What about Visual Interface coding?
Mostly a toy.
> Yikes! not fun at all!
> How about Code re-useability? forget it!!!!
> Originally that was the idea behind DLLs. Tell me how many times have you
> created dlls from scratch? How many times have you used SOMEBODY elses dll?
A few, and everyday.
> I like the togetherness of the u4 community and the helpfulness. The
> documentation is good but not having a written user guide is less that
> helpful.
Agreed. I have all the Euphoria manuals, and they are very helpful. It's a good
idea to print them out. Even better would be a book, but no one is going to
write one until Euphoria 3.0, at least.
> The problem I seem to see most often is folks making things too complex just
> for the sake of being complex. Why should a programming language HAVE to look
> esoteric? Darned if I know.
COBOL is pretty non-esoteric. It isn't attracting a lot of new converts as far
as I know.
Most of the complexity really comes from trying to work with other stuff, such
as Windows. Anyone who figures a way to communicate with Windows without the
complexity will be famous. (And make Micro$oft really mad. M$ doesn't want
anyone else writing Windows programs, you know.)
> Personal opinion: Programing languages should assist in solving problems and
> not creat new ones.
I could say the same thing about hammers, but the carpenters around here would
laugh at me.
Regards,
Irv
|
Not Categorized, Please Help
|
|
