michal necasek

From my own experience, I can say that a big advantage of C is that
it's ********. The compiler isn't trying to be too clever and isn't
hiding anything or doing things behind your back. That becomes a major
plus if you have to dig into a large project, especially one that
someone else wrote. If it was written in C, everything is right there in
front of you. If it's C++ (for instance), you have absolutely no idea
what a line of code might be doing - operator overloading, inheritance,
etc. etc. means that 'a + b' might do absolutely anything.


Michal

ilya zakharevich

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek


When this is true, it is very helpful indeed.

Unfortunately, this is not entirely true. Witness -fno-strict-aliasing,
and other voodoo is sometimes required to make things more ********...

Hope this helps,
Ilya

michal necasek

The language standard knows no such thing as -fno-strict-aliasing. If
you find you need to specify such custom flags to a tool of your choice,
that is a problem with the tool of your choice, not the language.


Michal

steven levine

In <qnirqrrmrrbet.iwj6mm0.pminews@news.aaisp.net.uk>, on 03/22/2006
at 08:25 AM, "Dave Saville" <dave@deezee-nospam.org> said:

Interesting POV, but not one I would agree with. Both languages were
designed to solve very different problems and in different eras. REXX
clearly shows its mainframe heritage while C shows its small machine,
limited resources heritage.

See

http://www.redbooks.ibm.com/redbooks/GG244199.html

and

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

for what the respective language authors of the languages have to say.

Steven

--
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net> MR2/ICE 2.67 #10183
Warp/eCS/DIY/14.103a_W4 http://www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

rony

Hardly either (at those times even mainframe resources were scarce and "small machines", even if
there were even smaller machines). Today a Linux watch has more horse power and resources than a
mainframe 25 years ago, let alone a Windows Smartphone ... ;-)


For Rexx probably Mike F. Cowlishaw would be the most authorative source, e.g. <The Early History of
REXX>, e.g. <http://www.computinghistorymuseum.org/ieee/af_forum/read.cfm?forum=10&id=21&thread=7>.


---rony

ilya zakharevich

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek

LOL! (Compare this with what you wrote above: "The compiler isn't
trying to be too clever".)

Hope this helps,
Ilya

steven levine

In <dvska4$chl$1@trane.wu-wien.ac.at>, on 03/22/2006
at 11:49 PM, rony <Rony.Flatscher@wu-wien.ac.at> said:


It's all relative.

The first 360 I had direct access to was a 360/30 which max'ed out 64KB of
core. This was back in the early '70s. I pretty much had it to myself,
which was fun, but unusual. My brother worked on a 360/20 which was even
smaller.

When did the first versions of REXX appear? My recollection is it was
mostly IBM internal until somewhere in the mid to late 80's. By then the
mainframes I came across typically had several MB or RAM. This was orders
of magnitude more than the typical micro or mini systems where I did most
of my work at the time, not to mention the embedded boxes.

Steven

--
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net> MR2/ICE 2.67 #10183
Warp/eCS/DIY/14.103a_W4 http://www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

@tin.it

I know what a stem is (that is a sort of array whose elements are accessed
by keys rather than numeric indexes)


one of the greater inconsistencies is that it is case insensitive in
most instances, but in some instances it yelds inexpected results
unless you uppercase variable names

besides that, being an high level language REXX should make programming
easier and more productive, but with its odd logic it often causes
more troubles than it solves

the problem is that it was born as a command shell scripting language
and all the new features which have been added during the years do not
always fit well with the original purpose of the language

e.g. dealing with hexadecimal numbers is a nightmare (as the format is not
endian-agnostic)

having to use CALL, when a procedure return value is not used, is another
of the most boring 'features' and is one of the most typical hint of the
original purpose of the REXX language (they had to use CALL
to avoid passing the procedure result to the command shell)

the only good REXX feature is its full integration with the OS...

--
bye
Alessandro

steven levine

In <T7NIEJzxPvaD092yn@tin.it>, on 03/22/2006
at 06:21 AM, @tin.it (Alessandro) said:


You may think so. However, there more to stems that just this. They have
some special properties. In an expression, the label A. is not a stem, it
is a variable name which may or may not happen to be the member of a stem.
This is easy to see with

say a.
a. ='really'
a.1 = 'one'
say a.
say a.1
say a.2

I and many others don't find this to be case. IMO, the key to working
with any language is to understand how it was intended to be used and work
within the paradigm.

You will need to provide examples. The language definition has not
changed in something like 15 years. I am excluding Object REXX here
because it is not the same language.


There are simple solutions for all of this. This what reverse is for.


I would not call it boring. It's the way I prefer to call function to let
readers know that the return value is unused. REXX is hardly unique in
this kind of feature.

It's not integrated with the OS. It is integrated with the command shell
and EPM and dfsee and mesa and DB2 and many other applications that choose
to use it as the basis of an application macro language. As Mike states,
this was one of the design goals.

IAC, there's no reason to use REXX when it is not the proper choice for
the problem at hand. For example, REXX stems are a handy associative data
store, but quickly fall over when the stems get too large. When I know
I'm going to have large numbers of entries in the stem, I write the code
in Perl, which for a large class of problems, can run as fast as compiled
code.

Also, it's not may nature to complain about a language that has not had
any significant new development in over 10 years.

Regards,

Steven

--
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net> MR2/ICE 2.67 #10183
Warp/eCS/DIY/14.103a_W4 http://www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

michal necasek

Okay, I feel sorry for you that you're using a compiler that's trying
to be too clever but isn't quite clever enough. Happy now?


Michal