rchao@well.UUCP (Robert Chao) (05/09/89)
After graduating from a university (and using C and Pascal all the time) I was surprised to find myself at a small software company that uses BASIC for everything. I was happy I found them because I'd been programming in BASIC since I was 15. Occasionally it was a cause for embarassment because my friends were all programming in C or something. But of course I know a lot of companies use BASIC, since I get the impression from ads and articles that BASIC is not just for educational use. So I was wondering, do you all know many companies or organizations that use BASIC, and what is their rationale? Just simpler to code? What about the generally chaotic nature of the language? Is is mostly "structured" BASICs that are used? -Thanks- R. Chao Oakland, CA
jkl@csli.Stanford.EDU (John Kallen) (05/10/89)
In article <11581@well.UUCP> rchao@well.UUCP writes: > >So I was wondering, do you all know many companies or organizations >that use BASIC, and what is their rationale? Just simpler to code? >What about the generally chaotic nature of the language? Is is mostly >"structured" BASICs that are used? > The company I've worked for every summer since 1983 has a large Economic software package written in BASIC. The reason why is simple: in the early 80's, the only languages available in CP/M were COBOL, PL/I, BASIC and assembler. COBOL and PL/I were ruled out because they were too big, and assembler was ruled out because it would have been such a pain to port it over to different machines. When the IBM PC was released, they could quickly move over to the MS-DOS environment, as Digital Research (who wrote the compiler they were using) had a 8086 BASIC compiler out. These days, they're still programming new code in BASIC for the IBM PC/XT/AT/386 clones, simply because the code's always been BASIC. However, they are in the process of translating their Mbytes of source code from BASIC to C as part of their motion towards UNIX. The BASIC they're using is Digital Research CBasic (CB80 or CB86, depending on the machine/OS). It is semi-structured, although in my opinion not structured enough. Their move to C has been a troubled one and is taking much more time than they originally thought. They tried using Minnow Bear's MB86 program to translate their BASIC to C but it failed. Their programs were simply too big for the MB86 translator. Now they are translating the code by hand, which not only is slow, but re-introduces heaps of new bugs.... BASIC is fine on toy machines like CP/M boxes and PC's, but it's not portable to UNIX and will cause you grief if you try to port it. Morale: Avoid BASIC like leprosy.... >R. Chao >Oakland, CA I couldn't mail this to you, so I posted instead. My apologies for wasted bandwidth. _______________________________________________________________________________ | | | | |\ | | /|\ | John Kallen | |\ \|/ \| * |/ | |/| | | PoBox 11215 "Life. Don't talk to me | |\ /|\ |\ * |\ | | | | Stanford CA 94309 about life." _|_|___|___|____|_\|___|__|__|_jkl@csli.stanford.edu___________________________
bensmith@bixpb (Ben Smith) (05/12/89)
I understand that all prototyping at Microsoft is done in a structured BASIC that is private to them. There has been a real growth (resurgance?) of BASIC as a result of the facilities and structure available in the "New Basics." I'll get references on this subject if anyone is interested. (Personally, I'd have a hard time going back to Pascal, let alone BASIC, but then I'm doing more textual writing than programming these days. -ben -- Ben Smith - technical editor | (603) 924-2575 | uunet!bixpb!bensmith BYTE Magazine | | uunet!bixpb!ronin!ben One Phoenix Mill Lane | | Peterborough, NH 03458 | | BIX: bensmith
skh@hpclskh.HP.COM (The Polar Bear) (05/13/89)
There are lots of companies that use BASIC for some or all of their work. Most of this is for commercial work (banking, insurance, etc), but some BASIC languages run quite well (and are popular) under UNIX systems. The main reason for using BASIC seems to be the interpreter. This is especially true if the BASIC can be compiled as well. I think the most popular ones have structured control statements, but many do not have fancy structures for support of records and pointers. The ability to interact with other languages always adds to the functionality of the language. To the person who said "Avoid it like the plague": You have missed out on the best features of BASIC. The better ones make great prototyping languages, especially if an interpreter is available. LISP and its derivatives may be better, but they tend to be more costly, and certainly are not for everyone. As for me, yes I write in BASIC, Pascal, and C. For "quick and dirty" programs, I'll take BASIC any day. I wouldn't use C for financial programs myself. Lack of support for fully accurate decimal arithmetic is a killer. But to sell and distribute a program...C and Pascal win out. skh
bothner@decwrl.dec.com (Per Bothner) (05/14/89)
In article <960017@hpclskh.HP.COM> skh@hpclskh.HP.COM (The Polar Bear) writes: >As for me, yes I write in BASIC, Pascal, and C. For "quick and dirty" programs, >I'll take BASIC any day. I wouldn't use C for financial programs myself. >Lack of support for fully accurate decimal arithmetic is a killer. I've never understood why this is such a big problem. Why cannot you just store dollars-and-cents as an integer number of cents? -- --Per Bothner Western Software Lab, Digital Equipment, 100 Hamilton Ave, Palo Alto CA 94301 bothner@wsl.dec.com ...!decwrl!bothner
jejones@mcrware.UUCP (James Jones) (05/14/89)
In article <248@bixpb> bensmith@bixpb.UUCP (Ben Smith) writes: >There has been a real >growth (resurgance?) of BASIC as a result of the facilities and >structure available in the "New Basics." I'll get references >on this subject if anyone is interested. One reference would be from a magazine that once called itself "The Small Systems Journal." I think it was either in April or October of 1984, and contained articles on, among other BASICs, True BASIC and BASIC09. True BASIC was new at the time; BASIC09 had been around for a few years (I've seen BASIC09 manuals copyrighted 1980) and had (and still has) most of the features touted in a more recent BYTE article about the "New" BASICs. James Jones
skh@hpclskh.HP.COM (The Polar Bear) (05/16/89)
>>skh writes: >>I'll take BASIC any day. I wouldn't use C for financial programs myself. >>Lack of support for fully accurate decimal arithmetic is a killer. > >I've never understood why this is such a big problem. >Why cannot you just store dollars-and-cents as an >integer number of cents? >-- > --Per Bothner Integer arithmetic is often of insufficient range for financial applications. When you start doing programs for multi-national companies and governments, you start needing exponents. Admittedly, many companies DO use integer arithmetic to get around this. But many are unwilling. The extra programming involved is a real headache. skh
toma@tekgvs.LABS.TEK.COM (Tom Almy) (05/17/89)
In article <960018@hpclskh.HP.COM> skh@hpclskh.HP.COM (The Polar Bear) writes: >>>skh writes: >>>I'll take BASIC any day. I wouldn't use C for financial programs myself. >>>Lack of support for fully accurate decimal arithmetic is a killer. >>I've never understood why this is such a big problem. >>Why cannot you just store dollars-and-cents as an >>integer number of cents? >Integer arithmetic is often of insufficient range for financial applications. >When you start doing programs for multi-national companies and governments, >you start needing exponents. Well, if those multi-national companies and governments need to handle billions of dollars accurate to the nearest cent, they still need integer arithmetic! Or at least 64bit floating point, in which case they might as well be using integers. >Admittedly, many companies DO use integer arithmetic to get around this. But >many are unwilling. The extra programming involved is a real headache. It all depends on the language you use. Languages that use packed decimal arithmetic (PL/1 or COBOL, some BASICs) can usually do the job. So can LISP (with "Bignums") or Smalltalk. I wrote and support a CAD program that does almost all arithmetic in integers to avoid rounding problems -- it is written in Forth, and the current version I use supports 32 and 64 bit integers. 64 bit gives enough digits for any country! C-lovers can switch to C++ and define a new class of big numbers. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
nevin1@cbnewsc.ATT.COM (nevin.j.liber) (05/17/89)
In article <960018@hpclskh.HP.COM> skh@hpclskh.HP.COM (The Polar Bear) writes: >Integer arithmetic is often of insufficient range for financial applications. >When you start doing programs for multi-national companies and governments, >you start needing exponents. But how do you get the needed PRECISION from floating point? Unless these mulit-national comanies and governments don't mind losing a few dollars when the numbers get too big. :-) Please elaborate. -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
res@ihlpb.ATT.COM (Rich Strebendt) (05/19/89)
In article <832@cbnewsc.ATT.COM>, nevin1@cbnewsc.ATT.COM (nevin.j.liber) writes: | In article <960018@hpclskh.HP.COM| skh@hpclskh.HP.COM (The Polar Bear) writes: | |Integer arithmetic is often of insufficient range for financial applications. | |When you start doing programs for multi-national companies and governments, | |you start needing exponents. | But how do you get the needed PRECISION from floating point? Unless | these mulit-national comanies and governments don't mind losing a few | dollars when the numbers get too big. :-) Please elaborate. It is clear to anyone who thinks about it that both answers alluded to above are wrong. Use of integers (even considering only the case of US money amounts) to scale money to cents (eg: $100 = 10000 cents) limits you to values less than about $43 million. If you have to keep track of more decimal places and scale accordingly (the value of stock shares to five decimal places, for example), the limit on the magnitude is correspondingly less. Floating point, of course, avoids the above problem, but suffers from loss of precision as the poster above points out. Loss of precision can be disastrous when dealing with other people's money!!! The way commercial data processing machines and languages solved this problem was through the use of (to use IBM terminology) packed decimal representations and arithmetic units. Unfortunately, C and other languages with scientific/engineering or systems programming origins (FORTRAN, PASCAL, BLISS, etc) do not support this data type. COBOL and PL/I do. In this representation the decimal digits are represented by BCD-encoded nibbles (1/2-bytes) with the number of digits and the location of the decimal point carried along in binary counters. One might be able to simulate this in C by using a structure consisting of the two counters and (a pointer to) a character string with two digits per character. Since most non-commercial machines do not have packed decimal arithmetic units, doing arithmetic with such structures would be very painful from the standpoint of CPU cycles per operation. Rich Strebendt ...!att!ihlpj!res
kers@otter.hpl.hp.com (Chris Dollin) (05/22/89)
Someone (damn, I deleted the header lines) said: (begin quote) It is clear to anyone who thinks about it that both answers alluded to above are wrong. Use of integers (even considering only the case of US money amounts) to scale money to cents (eg: $100 = 10000 cents) limits you to values less than about $43 million. If you have to keep track of more decimal places and scale accordingly (the value of stock shares to five decimal places, for example), the limit on the magnitude is correspondingly less. (end quote) You're restricted to $43M only if you restrict yourself to 32-bit (unsigned?) arithmetic. Multiple-precision arithmetic is hardly a big deal, especially when you're not likely to be doing big multiplications (quick - what's $35M * Y72M?) Regards, | "Baby Bear has had a busy day. What a big yawn! Baby Bear Kers. | is sleepy; it's nearly time for bed."
meissner@tiktok.dg.com (Michael Meissner) (05/22/89)
In article <832@cbnewsc.ATT.COM> nevin1@ihlpb.ATT.COM (nevin.j.liber) writes: | In article <960018@hpclskh.HP.COM> skh@hpclskh.HP.COM (The Polar Bear) writes: | | >Integer arithmetic is often of insufficient range for financial applications. | >When you start doing programs for multi-national companies and governments, | >you start needing exponents. | | But how do you get the needed PRECISION from floating point? Unless | these mulit-national comanies and governments don't mind losing a few | dollars when the numbers get too big. :-) Please elaborate. You use double precision, which most languages support directly. For example, with IEEE floating point, a double looks like: sign 1 bit exponent 11 bits mantissa 52 bits + 1 hidden bit for normalization As long the value is less than ~ 9e15 (ie, 12 full digits for dollars + 2 for cents), everything is fine (though if you use this scheme, you should take some pains to make sure division is rounded to an integral value after each division). -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?