nevin1@ihlpf.ATT.COM (00704A-Liber) (01/09/88)
In article <2582@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes: > >On type conversions: (Explicit or not?) > The key word here for me is data abstraction. Even integer to integer >may be wrong. >(Using Pascal here) > SIA_range : (some interval); (* Index in the IA *) > DIL_range : (some interval); (* Index in a block *) >Assignment from type to the other does seem like a error. Logically, it is an error. C does not provide data abstraction on this level; if you want it, use a language like C++. Looking at Pascal (the other extreme :-)), if I define two arrays of two different sizes I must use two different routines to manipulate them. This makes things like string processing nearly impossible (most uses of strings are with variable length). >It is these kinds of logical mistakes I talk about. Not the risk >of losing some accuracy. (But allowing reals to integer without >explicit conversion was something I thought only Fortran did. >C does also?) C does do type conversion automatically but in a well-defined way. (See K&R section 2.7) > >Array-index checking: > >If you write checks yourself, that seems like a source of error to me. > >Another comments on range checking in loops: It's only safe to leave >them out if the index can't be altered while in the loop. Don't >know about C, but this is certainly possible in Pascal. Ada, on other >regards the loop index as a constant. In C, there is no real concept of a loop index; 'for' statements are much more general in C than in Pascal. (I will not describe the mechanism here; look at K&R section 1.3) Also, arrays in C are not necessarily indexed; pointers may be used insted (abstractly, these are equivalent, however). >Generally, a good compiler should give you the possiblity to surpress >checking, either for the entire program, or just a part of it. So you >can always the remove the checks on delivery. The quetsion is just: Dare >you? The hostile user's may provide data you've never dreamt of. What actually happens when a program gets an out of range error? Usually, the program just dies. If you don't dare remove the checks, you shouldn't be programming! I would rather put the checks in myself so that I may be able to perform a more graceful handling of possible bugs. These types of runtime checks do not in any way insure that my code is more correct; they only provide a way of stopping badly written programs. The only thing that these checks might do is help someone find an error in their code (although as an experienced C programmer this information would not usually help me). In an earlier article you mentioned that we should all buy faster hardware to compensate for run-time checks. I'm sorry, but when I am sorting 100,000 + records I do NOT want the execution time to be tripled just to perform checks on each operation. Faster hardware should NOT be an excuse for badly-written software! >Yes. But he should get as much support as possible from the language. Thus, >the compiler should suspect any input. Most compilers I know of do this on a syntactic level. You are proposing that this should be done on a semantic level. Very few languages are this well-defined. Pascal, for example, at the end of a FOR loop, the index is undefined. Are you stopped from using it again before assigning it a value? I think not. Should I be stopped from using it, or should the value of an index be defined at the end of a FOR loop? I prefer the latter, but that's just my opinion. >> A programmer is simply a >>person who translates concepts from one language (that of the application) to >>concepts in another language (that of the programming model). It is very >>similar to natural language interpreters. If I were to hire a Russian >>to interpret for me, I would want one who understood both Russian and English. > >Not really. Your Russian interpreter doesn't need to have a full notion >of what you are talking of as long as he gets the words right. This just isn't true. If it were, why isn't there a computer program available that will do this? David Letterman tried this type of language translation once. He took the Beatle's song "A Hard Day's Night", had it translated into six different languages (English -> Russian, Russian -> French, ...) and back into English. Funny, the meaning wasn't quite the same as the original song. >What have this to with C? Well, a powerful language with good possibilities >abstracting the data is a help here to see: "What is to be done?". >Does C have the good devices for this? I doubt. Strong type checking is >a must here, I believe. First of all, if you want C to become Pascal why don't you use Pascal instead? Strong type checking only helps you find more errors at compile time, that's all. The function of English is not to stop me from expressing myself badly, so why should the function of C be to stop me from programming badly? USE THE RIGHT LANGUAGE FOR THE RIGHT PURPOSE!! If I need strong type checking, I would pick a language like C++. Can we discuss modern languages now? I'm tired of the 'which language is best' argument. My favorite language is Icon :-) :-); this language is VERY loosely typed. My problems usually don't come about because of type differences (Note: since it is an interpretive language it does provide the equivalent of runtime checks). This language helps me find my logic bugs (I don't have to worry about silly little things like stacks and lists; they are built into the language. One of the philosophies of Icon is that every function should either return a useful value or fail (i.e., x < y returns y if true; otherwise fails). Another thing is that functions can return more than one value (generators; i.e., find(s1,s2) returns all the positions of s1 in s2, and fails when it can't find any more). I love these concepts; what do others' think? BTW, Icon is relatively modern (it was created in the late '70s), and is the successor to SNOBOL4 and SL5. What I would like to know are interesting concepts people have found in other languages, and from these discussions try to decide what we think would belong in (to coin a phrase from the Icon Newsletter) 'the Perfect Programming Language'. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
mic@hpesrgd.HP.COM (Marc Clarke) (01/10/88)
> What other language is available on everything from a PC up to a Cray?
Ada?gore@nucsrl.UUCP (Jacob Gore) (01/11/88)
/ nucsrl:comp.lang.misc / pase@ogcvax.UUCP (Douglas M. Pase) / Jan 8, 1988 / >If you* wait for the compiler or runtime system to tell you when you make a >mistake, that's lazy, perhaps even irresponsible programming to me. If you >understood what you were doing, you would have reasonable confidence in your >code. My code? What makes you think I wrote the original code? This type of reasoning may apply to a shorter, "one owner" program, but it cannot be applied to a larger system which multiple people have worked on over the period of its existence. Besides, even if it's my own little program, why shouldn't I expect the routine checks to be done for me? I always thought that the computer should be doing routine things whenever possible. I do have reasonable confidence in my code. Yet, I've been around long enough to have reasonable lack of confidence in it. Of course I'll make my best effort not to make any mistakes, and to avoid short-sighted assumptions. But I know that I won't always succeed, so I'd like my supporting software to help me catch problems when they arize. Jacob Gore gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {gargoyle,ihnp4,chinet}!nucsrl!gore
pmk@hall.cray.com (Peter Klausler) (01/12/88)
In article <2200002@hpesrgd.HP.COM>, mic@hpesrgd.HP.COM (Marc Clarke) writes: > > What other language is available on everything from a PC up to a Cray? > > Ada? FORTRAN 77 Pascal C LISP (PSL, at least) Prolog but *not* Ada, not yet. All little languages that run under UN*X are common, too: sh, csh, awk, sno's subset of SNOBOL, etc.
rgr@m10ux.UUCP (Duke Robillard) (01/13/88)
In article <2200002@hpesrgd.HP.COM> mic@hpesrgd.HP.COM (Marc Clarke) writes: >> What other language is available on everything from a PC up to a Cray? > >Ada? FORTRAN? LISP? Maybe we ought to list those which aren't instead... -- + | Duke Robillard, novice pagan. | AT&T Bell Labs m10ux!rgr@ihnp4.UUCP | Murray Hill, NJ {any biggy}!ihnp4!m10ux!rgr
nevin1@ihlpf.ATT.COM (00704A-Liber) (01/13/88)
Since my last request for this was buried at the bottom of a rebuttal, I shall post this again. I would like to start a discussion on features that make programming languages interesting. I have already posted what I like about Icon, but what about other languages like CLU and Smalltalk? If you were designing the 'Perfect Programming Language', what features would you put in (and what features would you leave out)? Do these features limit the ease of use or applicability of the languages they come from? Let's get some dicussion in this newsgroup!! :-) :-) -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
mac3n@babbage.acc.virginia.edu (Alex Colvin) (01/13/88)
> > What other language is available on everything from a PC up to a Cray? > > Ada? for $50?
peter@sugar.UUCP (01/24/88)
In article <485@m10ux.UUCP>, rgr@m10ux.UUCP (Duke Robillard) writes: > In article <2200002@hpesrgd.HP.COM> mic@hpesrgd.HP.COM (Marc Clarke) writes: > >> What other language is available on everything from a PC up to a Cray? > >Ada? > FORTRAN? > LISP? > Maybe we ought to list those which aren't instead... Maybe we should ask a more resonable question: What other language provides a reasonably efficient O/S interface that's applicable to just about any operating system for everything from a PC up to a Cray? Writing system software in Fortran involves encapsulating ALL the system calls and changing them every time you switch to a new O/S, or putting up with the slowness of Fortran's I/O library. The Software Tools package does the former but provides a slow version that uses the latter approach to get the first cut working quickly. Other, more recent, languages avoid the problem of inefficient I/O libraries by underspecifying the O/S interface. C specifies an interface (stream character files) that can be implemented fairly painlessly on a wide variety of machines, provides most of the stuff that high level system software (compilers, filters, editors, etc...) need, and is efficient enough that only extremely weird systems encourage programmers to roll their own. Could microEmacs have been written in (say) Fortran and still have as much performance and portability? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
mwm@eris (Mike (My watch has windows) Meyer) (01/25/88)
In article <1416@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
<Writing system software in Fortran involves encapsulating ALL the system
<calls and changing them every time you switch to a new O/S, or putting up
<with the slowness of Fortran's I/O library. The Software Tools package
<does the former but provides a slow version that uses the latter approach
<to get the first cut working quickly.
You can get fast IO through a FORTRAN IO library. You just have to do
more work than doing "normal" FORTRAN IO, and have a well-written
compiler/library system.
<C specifies an interface (stream character files) that can be implemented
<fairly painlessly on a wide variety of machines, provides most of the stuff
<that high level system software (compilers, filters, editors, etc...) need,
<and is efficient enough that only extremely weird systems encourage programmers
<to roll their own. Could microEmacs have been written in (say) Fortran and
<still have as much performance and portability?
While the streams abstraction in C is a win, it's not the only
language that has it. And that's not what makes microEmacs portable.
MicroEmacs has an abstract IO level internal to itself - for taking
care of things like OS-dependent file names, error conditions,
end-of-file and end-of-line markers. The same things would work in
FORTRAN. The C stream abstraction merely makes doing a port easier -
there's more likely to be a version you can crib from. On the other
hand, doing all those linked lists in FORTRAN would be a *real* pain.
<mike
--
When all our dreams lay deformed and dead Mike Meyer
We'll be two radioactive dancers mwm@berkeley.edu
Spinning in different directions ucbvax!mwm
And my love for you will be reduced to powder mwm@ucbjade.BITNETpokey@well.UUCP (Jef Poskanzer) (01/27/88)
In the referenced message, peter@sugar.UUCP (Peter da Silva) wrote: } Could microEmacs have been written in (say) Fortran and }still have as much performance and portability? Of course. Don't be silly. In 1980 I wrote a non-extensible EMACS clone in Ratfor. Performance was pretty good, considering it was originally running on a Modcomp -- ~0.1 sec to update the screen. Almost as soon as I got it working, I ported it to VMS and Unix with no problems at all. A few years later I ported it to TOPS-20 in only two days, and that included getting the Software Tools bootstrapped. The reason it was so easily ported is that I used modular design / information hiding. It was structured as a collection of library packages, each depending on lower-level packages. For instance, at the lowest level of the I/O tree was a simple raw character I/O package. On top of that I layered a cursor-control package (which also used a termcap-file-reading package), and using the cursor-control package I wrote an optimal screen-update package. Porting that entire tree to a new OS meant re-writing three routines in the raw I/O package. Buffer management was handled similarly, so that only the lowest level was machine-dependent. A language that enforces information hiding is nice -- it gives an added sense of security -- but it's not necessary. Languages don't make good programs, good programmers make good programs. --- Jef Jef Poskanzer jef@lbl-rtsg.arpa ...well!pokey When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.