Using identifiers with more than 7 chars. #$%@

Mike Schloss mike at fluffy.UUCP
Sun Mar 9 03:23:04 AEST 1986


In article <47 at gilbbs.UUCP> mc68020 at gilbbs.UUCP (Tom Keller) writes:
>In article <408 at ucbjade.BERKELEY.EDU>, mwm at ucbopal.BERKELEY.EDU writes:
>> In article <29 at gilbbs.UUCP> mc68020 at gilbbs.UUCP (Tom Keller) writes:
>> >or some other form of UNIX!  If you are going to post software with major
>> >system dependencies (such as long identifier names) LABEL them in the
>> >summary, damn it!
>> 
>> Finally, System V now supports flexnames, and Ultrix has always had it. If
>> you're not running 4.2BSD or System V, it's your own fault (if you've got a
>> vendor still selling 4.1, System III or v7, you should change vendors!). If
>> your vendor hasn't upgraded to the latest version of System V, you should go
>> shout at them. If you're on a micro, you probably need to buy/should have
>> bought a better C compiler. But those are usually the compilers that are
>> going to have more serious problems than lack of long names.
>
>   ***SHIT***   Mike, what I *SHOULD* have done, it appears, is spend $50K or
>more on a bigger, better system!  There are 2 (count them two) versions of
>UNIX (XENIX) available for the hardware I can *AFFORD*:  2.3a (an unGhodly
>meld of V7 and SysIII), and SYS III.   There is 1 (count it, one!) C compiler
>available for this system/OS combination.   
>
>
>    I humbly apologize to the you, and to the net, for not having bothered
>to spend more money that I'll make in the next 4 years on my system!
>
>
>    Excuuuuuuuuuuuuuse me!
>

Quit your bitching.  I'm getting tired of hearing it.  If you don't want
someone's FREE software then dont take it.  Why should people with current
systems have to generate code that is harder to maintain so you can use it
as is.  Code with descriptive variable names are usually easier to debug,
maintain, and port then programs with all identifiers 6 chars or less.

Stop apologizing and write your own damn software if you don't like whats
available.

					Mike Schloss



More information about the Comp.sources.bugs mailing list