melling@cs.psu.edu (Michael D Mellinger) (05/28/91)
In article <14750@ucrmath.ucr.edu> trout@ucrmath.ucr.edu (michael griffith) writes:
This theory only holds if you are a screw-up. Assembly is much faster
and smaller than anything a complier or interpreter could ever write.
Is this written in stone somewhere? How much faster is assembly
machine language than C given that you have a good machine language
programmer(is this a must?)?
HLLs, on the other hand, provide abstraction, ease of programming, and
portablility. There really is a decision that needs to be made before
If assembler is so great, why don't we just stick with the 68K series
forever? Moto. will surely oblige us.
you start any project. That decision is a choice of a language. Don't
be lulled into thinking that a language is an automatic one -- it isn't.
ALWAYS use the language that is right for the job.
ALWAYS take your vitamins and get plenty of sleep. Get real. I'll
name the language and you name the "right" job.
C
Ada
C++
Eiffel
Smalltalk
Icon
Perl
Rexx
Lisp (CL, Scheme, etc.)
Prolog
Objective C
Self
AWK(nawk)
Snobol
APL
Cobol
Fortran
Assembler -- 68K, 80x86, 6502, SPARC, MIPS, 88K...
Simula
There are dozens more. I have a list with probably a hundred
languages(wouldn't be surprised if it's more like a few hundred).
"My computer is better than your computer." -- Amiga and NeXT junkies.
But it is :-). I say: "ALWAYS use the right computer for the job."
:-) I'm under the impression that you will do anything to avoid an
argument. Sorry pal, if you read the net, you are required to think a
little.
-Mikejbickers@templar.actrix.gen.nz (John Bickers) (05/28/91)
Quoted from <8_4Ha8!f@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > If assembler is so great, why don't we just stick with the 68K series > forever? Moto. will surely oblige us. You think we use C because we want to be ready for a CPU change? You think C is automatically going to provide some sort of readiness for such things? The assembler folks will switch over easily enough. Look how many are supposed to be ex-C= 64, for example. > -Mike -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jpc@fct.unl.pt (Jose Pina Coelho) (05/28/91)
In article <8_4Ha8!f@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > If assembler is so great, why don't we just stick with the 68K series > forever? Moto. will surely oblige us. Because, that would kill competition, and once competition is dead motorola will stop innovation. > ALWAYS take your vitamins and get plenty of sleep. Get real. I'll > name the language and you name the "right" job. Can you smell the smoke comming ? :-) C - Operating systems, small programs. Ada - Can this be used ? I remmember fifteen lines to say hello world. C++ - For situations that call for C's advantages but have good separation between object classes. Smalltalk - For fast prototyping of applications, but then it should generate RTL and be fed into the GNU compiler. Rexx - Like common shell scripts across machines. Lisp - American AI Prolog - European AI (Actualy we need a mix of both, but try tell that to the AI people on both sides of the pond) AWK(nawk) - Processing text files (databases). Generaly complemented with sed and m4. Cobol - Shoot the programmers. Fortran - Shoot the grannys. Assembler - Breaking games protections, patching OS holes (when you don't have the OS source) the code where the program spends 99% of the time. > "My computer is better than your computer." -- Amiga and NeXT junkies. > > But it is :-). I say: "ALWAYS use the right computer for the job." > :-) I'm under the impression that you will do anything to avoid an > argument. Sorry pal, if you read the net, you are required to think a > little. Besides, it's a fellony to duck a flame war in comp.sys.amiga.advocacy :-) -- Jose Pedro T. Pina Coelho | BITNET/Internet: jpc@fct.unl.pt Rua Jau N 1, 2 Dto | UUCP: ...!mcsun!unl!jpc 1300 Lisboa, PORTUGAL | Home phone: (+351) (1) 640767 - If all men were brothers, would you let one marry your sister ?
peter@sugar.hackercorp.com (Peter da Silva) (05/28/91)
In article <4006.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > The assembler folks will switch over easily enough. Look how many > are supposed to be ex-C= 64, for example. Yes, and look at the code they write. A lot of it won't run on my 3000 because it's 68000-specific. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
judd@wilkinson.Colorado.EDU (Xenu Galactic-Conqueror) (05/29/91)
I didn't REALLY want to get involved in this one, but both Ada and Fortran are under attack once again, and somebody has to defend them. In article <JPC.91May28115646@terra.fct.unl.pt> jpc@fct.unl.pt (Jose Pina Coelho) writes: > >In article <8_4Ha8!f@cs.psu.edu> melling@cs.psu.edu (Michael D >Mellinger) writes: >> If assembler is so great, why don't we just stick with the 68K series >> forever? Moto. will surely oblige us. Because, as has been said before: Use the right tool for the right job. But I think you knew that. >> ALWAYS take your vitamins and get plenty of sleep. Get real. I'll Whatever... >> name the language and you name the "right" job. >Can you smell the smoke comming ? :-) > >C - Operating systems, small programs. >Ada - Can this be used ? I remmember fifteen lines to say hello world. Sigh... with TEXT_IO use TEXT_IO procedure HELLO_WORLD is begin put("Hello World"); put_line(" "); end HELLO_WORLD; Significantly less than fifteen lines. Ada is a neat language. Proper design will produce a program that is extrememly portable (usually little to no modification is necessary), easy to read, easy to maintain, easy to develop, and you have a tendency to have code with fewer bugs, quite important for things such as a guidance system on a missile, for instance. Ada supports all sorts of neat things, like overloaded operators, separate compilation, unconstrained arrays, derived types, and on and on and on. I am surprised that it hasn't made a strong showing on the Amiga, with it's TASK structure I would think it would fit right in. I would love to just talk about the language, but that would take far too much time and bandwidth - read a book on Ada. It's cool. So, what would you use it for? It lends itself to very portable packages, so scientific software that needs to go between ten different platforms is an excellent application. It also works well for real time applications. Ada fits in really nicely with a Cray as well. So much so, in fact, that Ada may become the language of choice on a Cray. Now, as I said earlier, the Amiga would seem to be an ideal Ada platform. If someone wrote a good Ada copmiler for a couple hundred bucks and marketed it well, stressing the Amiga development environment... assuming Cray survives the onslaught of multi-processor machines, one could probably sell a lot of Amigas into the scientific community. By way of reference, the scaled down Ada compiler on an IBM costs $600. The full version costs $900. Ada on a Sun will fetch $18000.... >Cobol - Shoot the programmers. >Fortran - Shoot the grannys. Double sigh... CS weenies strike again. For many business applications Cobol used to beat the snot out of everything, especially on a machine built around it (like some of the old Borroughs machines). There is more to life than databases and O(1) sorts, you know. Fortran is designed for high-powered scientific applications. Get on a Cray sometime - You are vain and silly if you intend to use any other language for that purpose. >> "My computer is better than your computer." -- Amiga and NeXT junkies. >> >> But it is :-). I say: "ALWAYS use the right computer for the job." >> :-) I'm under the impression that you will do anything to avoid an >> argument. Sorry pal, if you read the net, you are required to think a >> little. To quote a message from a while back (Larry Phillips, perhaps?)... "Gee, what an oxy>>>MORON<<<." -Steve >-- >Jose Pedro T. Pina Coelho | BITNET/Internet: jpc@fct.unl.pt >Rua Jau N 1, 2 Dto | UUCP: ...!mcsun!unl!jpc >1300 Lisboa, PORTUGAL | Home phone: (+351) (1) 640767 -- judd@sgt-york.lanl.gov ...!ncar!boulder!tramp!judd Los Alamos National Laboratory // Univ. of Colo at Boulder A-3 Systems Analysis \X/ Applied Mathematics Women and men (both dong and ding) summer autumn winter spring reaped their sowing and went their came sun moon stars rain -e.e. cummings
jbickers@templar.actrix.gen.nz (John Bickers) (05/29/91)
Quoted from <1991May28.122620.9020@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > In article <4006.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > The assembler folks will switch over easily enough. Look how many > > are supposed to be ex-C= 64, for example. > > Yes, and look at the code they write. A lot of it won't run on my 3000 because > it's 68000-specific. Sure. These kinds of assembler folks also write primarily for themselves, so it doesn't matter if their software won't run on your machine (well, doesn't matter to you. Small dent in their sales, if they are selling their stuff). They'll switch over to 68030s etc rapidly enough when they have to. Some already are, since more and more coder demos seem to be working ok on an A2630. > Peter da Silva. `-_-' -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
sschaem@starnet.uucp (Stephan Schaem) (05/29/91)
Come on... Somebody showed me 5 demos the all 5 worked on the 3000. even a year ago I had hard time finding demos that would work on a A2630. People learn from their mistake! dont you think? I have CBM software that dont work on my A2000, and other software that go wild on 2.0... That problem is not that true anymore, well their are alway newcomers... But agrea that OS friendlyness is not really here in their software:-) But I dont mind after a 30minuts show of wild and interesting programing/art reboting... Stephan
peter@sugar.hackercorp.com (Peter da Silva) (05/30/91)
In article <4032.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > Quoted from <1991May28.122620.9020@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > > In article <4006.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > > The assembler folks will switch over easily enough. Look how many > > > are supposed to be ex-C= 64, for example. > > Yes, and look at the code they write. A lot of it won't run on my 3000 because > > it's 68000-specific. > Sure. These kinds of assembler folks also write primarily for > themselves, so it doesn't matter if their software won't run on your > machine (well, doesn't matter to you. Small dent in their sales, if > they are selling their stuff). I'm not talking about demos. I have a shelf full of software that screws up on my 3000, whether I'm running under 1.3 or 2.0. Things like DigiPaint, Photon Paint, and so on. The core of the Amiga's software base. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peterk@cbmger.UUCP (Peter Kittel GERMANY) (05/31/91)
In article <1991May28.173812.4183@colorado.edu> judd@wilkinson.Colorado.EDU (Xenu Galactic-Conqueror) writes: > >. Fortran is designed for high-powered scientific applications. >Get on a Cray sometime - You are vain and silly if you intend to >use any other language for that purpose. Please, can you tell me, what on earth in Fortran is "designed for high-powered scientific applications"? I don't see any evidence for this (you know, I also had to program Fortran back at university.) The only reason to still use Fortran is, in my eyes, the existence of great software packages, including subroutine libraries, that are specialized for this area and have evolved for decades into really bullet-proof and usable good stuff. With them, you don't have to re-invent the wheel all the time. But still I wonder that it should be possible to translate all this stuff into something more modern, like Modula (or C), without losing any feature, but gaining much from the more modern structures of these languages. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
riley@theory.TC.Cornell.EDU (Daniel S. Riley) (06/01/91)
In article <1258@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1991May28.173812.4183@colorado.edu> judd@wilkinson.Colorado.EDU (Xenu Galactic-Conqueror) writes: >>. Fortran is designed for high-powered scientific applications. >>Get on a Cray sometime - You are vain and silly if you intend to >>use any other language for that purpose. > >Please, can you tell me, what on earth in Fortran is "designed for >high-powered scientific applications"? I don't see any evidence for >this (you know, I also had to program Fortran back at university.) Sure. It doesn't support recursion. It assumes that subroutine arguments are not aliased. It doesn't have pointers. It doesn't have dynamic memory allocation. And so on... That probably doesn't sound like a list of features, does it? But it is, for high-powered scientific applications, because it makes it many optimizations possible that are difficult or impossible in languages like Modula or C. Fortran optimizers are among the best in the world at producing fast, reliable code. This is partly because fortran compiler writers have been at it for a long time, and there is a big premium for speed in scientific applications, but it also because the language is designed for speed. And if you're working on something so compute intensive that you need a Cray to run it, speed and correctness are everything. How awful the language you have to write the code in is secondary, as long as it is portable. Also, there are severe limits on how much a Fortran compiler can reorder expressions. Writing numeric code in C is a pain, because the C compiler is free to use algebraic identies to rearrange expressions. That means that expressions that are sensitive to the order of evaluation have to be broken into many separate expressions to force the order of evaluation. In Fortran, you can put a few parentheses in and be assured that the expression will be evaluated in the order you expect. Fortran certainly is not my favorite language, but there are reasons besides inertia why it is still the language of choice for heavy-duty numeric computation. -- -Dan Riley (riley@theory.tc.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
eachus@largo.mitre.org (Robert I. Eachus) (06/01/91)
In article <1991May31.181153.584@batcomputer.tn.cornell.edu> riley@theory.TC.Cornell.EDU (Daniel S. Riley) writes: >In article <1991May28.173812.4183@colorado.edu> judd@wilkinson.Colorado.EDU (Xenu Galactic-Conqueror) writes: >>. Fortran is designed for high-powered scientific applications. >>Get on a Cray sometime - You are vain and silly if you intend to >>use any other language for that purpose. Since judd did get this right elsewhere in his post, I'll just point out that many supercomputer users are stating to switch to Ada for, among other things, its support for multiple processors. But it will be a while before the compilers are as good some of the FORTRAN compilers at "intrinsics," etc. > Fortran certainly is not my favorite language, but there are > reasons besides inertia why it is still the language of choice > for heavy-duty numeric computation. Ada is catching up, but at different rates in different markets. There is probably more Ada used in Europe, and much more FORTRAN currently on the vector machines. Incidently the "correct" hello world program in Ada is: with TEXT_IO; procedure HELLO_WORLD is begin TEXT_IO.PUT_LINE(" Hello World!"); end HELLO_WORLD; Five lines using standard formatting, and it can easily be srunk to two without loss of clarity: with TEXT_IO; use TEXT_IO; procedure HELLO_WORLD is begin PUT_LINE(" Hello World!"); end; Ada has an undeserved reputation for source code bloat from people who haven't used it, or who have used it only on very small programs. A few years ago I used to figure that Pascal was smaller for programs under 1000 lines, and Ada was better above that. I soon realized that I didn't need to keep a searate language around just to save ten minutes when writing a program in an afternoon, especially since a few personal libraries kept around wiped out even that advantage. Incidently, from experience, a 100,000 line program in Ada is a 300,000 line C monstrosity (or a 1,000,000 line COBOL monster). When you get to large programs, Ada is a necessity. -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
s8922967@ipc05.mqcs.mq.oz.au (Murray John GILBERT) (06/01/91)
In article <1258@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > The only reason to still use Fortran is, in my eyes, the existence >of great software packages, including subroutine libraries, that are >specialized for this area and have evolved for decades into really >bullet-proof and usable good stuff. With them, you don't have to >re-invent the wheel all the time. But still I wonder that it should >be possible to translate all this stuff into something more modern, >like Modula (or C), without losing any feature, but gaining much >from the more modern structures of these languages. > >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk It is about time all that stuff should be translated into something more modern, and fortran itself be buried and left in peace. I'd much rather be able to use C or maybe Modula2 for the programming in the Numeric Analysis course that I am doing. The Linpack, Eispack, et.al packages do a really fine job but it is a real pain having to dredge the sludge out of my brain to find my scarce fortran programming skills. I could see my self using these wonderful routines more often and not just in NA courses if they were in something less painful than fortran is. Any one willing to take up the effort/challenge ? Murray ============================================================================= Murray Gilbert s8922967@ipc01.mqcs.mq.oz.au -----------------------------------------------------------------------------
alex@bilver.uucp (Alex Matulich) (06/01/91)
In article <1258@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >Please, can you tell me, what on earth in Fortran is "designed for >high-powered scientific applications"? I don't see any evidence for this >[...] >But still I wonder that it should >be possible to translate all this stuff into something more modern, >like Modula (or C), without losing any feature, but gaining much >from the more modern structures of these languages. I can think of one reason: complex math. Complex arithmetic in C is clumsy at best. C++ does a little better with overloaded operator definitions but it still has problems with mixed-type expressions such as a=b*c where only c is complex. Much as I dislike Fortran, I don't think C or C++ can yet be considered to be "designed for high-powered scientific applications" because of the complex math limitation. -- _ |__ Alex Matulich /(+__> Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817 //| \ UUCP: alex@bilver.uucp <or> ...uunet!tarpit!bilver!alex ///__) bitnet: IN%"bilver!alex@uunet.uu.net"
ronald@ecl014.UUCP (Ronald van Eijck) (06/02/91)
In article <1991May30.142542.23133@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >I'm not talking about demos. I have a shelf full of software that screws up >on my 3000, whether I'm running under 1.3 or 2.0. Things like DigiPaint, >Photon Paint, and so on. The core of the Amiga's software base. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. Photon Paint 2.0 works ok on an A3000 running 2.04. (developers release) -- +-------------------------------------------------------------------------+ | Ronald van Eijck {eunet!}hp4nl!cbmnlux!ecl014!ronald | | | | We do the impossible at once for a miracle we need a little more time | +-------------------------------------------------------------------------+
daveh@cbmvax.commodore.com (Dave Haynie) (06/04/91)
In article <EACHUS.91May31175822@largo.mitre.org> eachus@largo.mitre.org (Robert I. Eachus) writes: > Incidently, from experience, a 100,000 line program in Ada is a >300,000 line C monstrosity (or a 1,000,000 line COBOL monster). When >you get to large programs, Ada is a necessity. I think it's more correct to say that a truely modular language is necessary when writing large programs. The better the modularization, the easier it gets to write and maintain large programs. Certainly Ada or Modula2 are better suited to this than C, which provides very little in the way of hard encapsulation, etc. But going to a true object oriented language like C++ is an even better alternative when building large systems. And probably a little more natural for the average hardcore C programmer. The only problem with C++ itself is that, in many cases, it lets you be as sloppy as C does, since most C programs will compile in C++. You have to design in C++ to get any of its advantages. Ada or M2 will force the issue, certainly a boon to the undisciplined. Though I think any decent programmer can adapt to the verbosity of Ada or any of the Wirth languages without too much pain. It usually takes me a day or two of working in a language to get all my mental processes switched over (assuming I know the language already and just haven't used it in some time). -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "This is my mistake. Let me make it good." -R.E.M.
macdonaldk@watt.ccs.tuns.ca (06/05/91)
Theoretically, Ada should win the language war. However, because of its immense size, it is difficult to say that any particular Ada compiler will compile code correctly, and efficiently. The standard only requires the program to compile; whether it runs correctly is up to the user to prove. Some of the planners of the next version of Ada have suggested allowing a subset to exist, which would be able to operate efficiently on microcomputers.
schweige@aldebaran.cs.nps.navy.mil (Jeffrey M. Schweiger) (06/05/91)
In article <1991Jun5.075305.1@watt.ccs.tuns.ca> macdonaldk@watt.ccs.tuns.ca writes: >Theoretically, Ada should win the language war. However, because of its >immense size, it is difficult to say that any particular Ada compiler will >compile code correctly, and efficiently. The standard only requires the >program to compile; whether it runs correctly is up to the user to prove. This isn't really different from other modern languages. What compilers for commonly used languages have been proven correct? Ada at least has a validation procedure that checks many features of the language for consistency across various compilers. >Some of the planners of the next version of Ada have suggested allowing a >subset to exist, which would be able to operate efficiently on microcomputers. Actually, reasonable Ada compilers already exist on microcomputers. There are several choices of Ada compilers in the MS-DOS and Macintosh worlds. Meridian's OpenAda series bears investigation. (And yes, I do want an Ada compiler for the Amiga!!). Jeff Schweiger -- ******************************************************************************* Jeff Schweiger Standard Disclaimer CompuServe: 74236,1645 Internet (Milnet): schweige@taurus.cs.nps.navy.mil *******************************************************************************
eachus@largo.mitre.org (Robert I. Eachus) (06/13/91)
In article <22127@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
I think it's more correct to say that a truely modular language is
necessary when writing large programs. The better the
modularization, the easier it gets to write and maintain large
programs...But going to a true object oriented language like C++ is
an even better alternative when building large systems...The only
problem with C++ itself is that, in many cases, it lets you be as
sloppy as C does, since most C programs will compile in C++. You
have to design in C++ to get any of its advantages. Ada or M2 will
force the issue, certainly a boon to the undisciplined.
I think that in a way we are really saying the same thing. There
are lots of good programmers who can write well structured maintanable
code in any high-level language, but working on large projects with
more than 10 programmers or so has taught me that there will always be
some programmer who breaks abstractions to get his boss off his back,
or to get to the ball game. Then two years down the road, the project
needs to take a one year slip to fix his "clever" workaround.
In Ada it still is possible to do such things, but the lanaguage
was intentionally designed so that such things stand out. In fact, I
have a filter program which runs thorough Ada source to find them.
(Not too hard, the smoking guns are "UNCHECKED_CONVERSION", 'ADDRESS",
and "pragma INTERFACE".) There are cases where these are
needed--that's why they are in the language--but in a well written
program the are only two or three modules which should be allowed to
use them.
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...