mr3@ukc.ac.uk (M.Rizzo) (04/08/91)
In article <1523@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: >In article <7214@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >|In Miranda all you need is three lines: >| >|qsort :: [*] -> [*] >|qsort [] = [] >|qsort (a:X) = qsort [b|b<-X; b<=a] ++ [a] ++ qsort [b|b<-X; b>a] >| > If learning a high-level language means putting up with gibberish like >THAT, I think I'll switch to raw hex instead. I think you've made a very hasty comment there. You are obviously put off by the notation and confused by the totally different approach to imperative programming languages such as C that most people are used to. But if you know how the quick sort algorithm works (you'll find this in any decent algorithms book) you should be able to understand those three lines if you think about it. They're almost a specification of quick sort rather than an implementation ! Familiarity with set and function notation in Mathematics is also very useful. Just to help you along if you want to understand it better: [*] denotes a list of items of the same arbitrary type [] denotes the empty list [a] denotes the list containing only the item a [b|condition; condition; ... ] (called a List Comprehension) denotes the list of all b's which satisfy the ensuing conditions ++ is the operator which concatenates lists h:T is used for pattern matching on lists. It will match any non-empty list, and place the first element of the list in h (head), the remaining list in T (tail) (In the above, a:X was used) The third line is obviously using recursion. In my opinion this line captures the essence of the quick sort algorithm very elegantly. Again think of how many PASCAL or C statements you'd need to implement quicksort (more the so for assembler). I can assure you that languages such as Miranda, Hope and ML, do provide significant advantages over traditional programming languages. Their authors have analyzed the shortcomings of traditional languages and written new ones to overcome them. A very good introduction to such languages is given in "An Introduction to Functional Programming" by Bird & Wadler (published by Prentice-Hall) for anyone who's interested. Increasingly more universities are including functional programming in their undergraduate courses - there are even opinions that a functional language should replace Pascal as the traditional first language taught at university. Now all I want is a decent implementation of a functional language for the Amiga! Did I hear anyone say they'd done a version of ML ? Michael Rizzo
espie@flamingo.Stanford.EDU (Marc Espie) (04/08/91)
In article <7235@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >In article <1523@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: >>In article <7214@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >>|In Miranda all you need is three lines: >>| >>|qsort :: [*] -> [*] >>|qsort [] = [] >>|qsort (a:X) = qsort [b|b<-X; b<=a] ++ [a] ++ qsort [b|b<-X; b>a] >>| > >> If learning a high-level language means putting up with gibberish like >>THAT, I think I'll switch to raw hex instead. Well, Miranda is not incredibly readable. How about a nice factorial function ? fact(n) = n * fact(n-1) fact(0) = 1 There are languages around where you can specify it that way, and it will run. It won't even be especially slower than C or assembler... There are also languages where you can DO things you wouldn't even think of doing in assembler or C. Ever heard of lazy languages ? You can define lots of stuff, the language won't even bother about evaluating them... unless it NEEDS too. For instance, you can define the list of ALL the primes number, and do computations with it... The fact is, assembly programmers who don't give a damn about C or higher level language (C is still pretty much low level compared to recent developpement) haven't usually enough background to know why other languages do exist. Granted, it is possible to write games in assembly language, it may even be the choice method on the amiga, but that does not mean I'd try to write a very intricate scientific project with it... Other people in other communities have the same attitude about Fortran. Intellectual lazyness... not wanting to learn anything new because they are content with what they have. > >I think you've made a very hasty comment there. You are obviously put >off by the notation and confused by the totally different approach to >imperative programming languages such as C that most people are >used to. > >But if you know how the quick sort algorithm works (you'll find this in >any decent algorithms book) you should be able to understand those >three lines if you think about it. They're almost a specification of >quick sort rather than an implementation ! Familiarity with set and >function notation in Mathematics is also very useful. Just to help you >along if you want to understand it better: > >[*] denotes a list of items of the same arbitrary type >[] denotes the empty list >[a] denotes the list containing only the item a >[b|condition; condition; ... ] (called a List Comprehension) denotes > the list of all b's which satisfy the ensuing conditions >++ is the operator which concatenates lists >h:T is used for pattern matching on lists. It will match any non-empty > list, and place the first element of the list in h (head), the remaining > list in T (tail) (In the above, a:X was used) > >The third line is obviously using recursion. In my opinion this line >captures the essence of the quick sort algorithm very elegantly. Again >think of how many PASCAL or C statements you'd need to implement >quicksort (more the so for assembler). > Maybe quicksort is not always the right algorithm... it almost never is, in fact. The thing is, it won't take you much longer to rewrite your sort as a heapsort or anything else. >I can assure you that languages such as Miranda, Hope and ML, do >provide significant advantages over traditional programming languages. >Their authors have analyzed the shortcomings of traditional languages >and written new ones to overcome them. A very good introduction to >such languages is given in "An Introduction to Functional Programming" >by Bird & Wadler (published by Prentice-Hall) for anyone who's interested. >Increasingly more universities are including functional programming in >their undergraduate courses - there are even opinions that a functional >language should replace Pascal as the traditional first language taught >at university. > Anyway, Pascal is not a real world language. Niklaus Wirth advocated it as a language suitable for education. This is no wonder some people switch to assembler after an exposure to Pascal... >Now all I want is a decent implementation of a functional language >for the Amiga! Did I hear anyone say they'd done a version of ML ? > >Michael Rizzo As advanced bibliography, the Peyton-Jones' Compiling Functional Languages gives a good idea of how incredibly much ``higher-level'' some functional languages can be. Good compilers are able to catch things it would take forever for a gifted assembly-programmer it would take to write correctly. There seems to be a misconception creeping up that all you need to program is a machine and some brains. That's wrong. There are also a lot of researchers doing work. Most of it is not used in practice, but eventually their work comes to get implemented inside compilers or libraries function. Being one such researcher myself, I've got a good idea of the time spent devising some algorithms or some compilers. If you add up everything, you end up with hundred of man-years behind a reasonable C compiler... just look where the algorithms come from, then look at the references, then look at all the trials and errors. I'm just thinking right now of the work I'm doing, the algorithms I implement. They are already mind-taxing is simple ideas on sheets of paper, how would I ever be able to code them down in assembler ? It's already difficult enough in C that I would happily change to something better where it not for practical reasons... Matt Dillon said something very similar a while ago, about the fact that you also have to read books to be a good programmer (so long for the ``10 pages of the Hardware manual are enough for me'' idea). A pity I can't find back his posting... -- Marc (espie@flamingo.stanford.edu)
mr3@ukc.ac.uk (M.Rizzo) (04/08/91)
In article <1991Apr8.005252.8503@neon.Stanford.EDU> espie@flamingo.Stanford.EDU (Marc Espie) writes: >In article <7235@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >>In article <1523@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: >>>In article <7214@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >>>|qsort :: [*] -> [*] >>>|qsort [] = [] >>>|qsort (a:X) = qsort [b|b<-X; b<=a] ++ [a] ++ qsort [b|b<-X; b>a] >>> If learning a high-level language means putting up with gibberish like >>>THAT, I think I'll switch to raw hex instead. >Well, Miranda is not incredibly readable. Don't agree here. Its very easy to understand once you get used to the notation which isn't too difficult to get to grips with, especially if you're familiar with some elemenatary Math notation. The above qsort is much more readable than quick sort in Pascal. It captures the essence of the algorithm and relieves the programmer of having to deal with unimportant implementation details. >How about a nice factorial function ? >fact(n) = n * fact(n-1) >fact(0) = 1 >There are languages around where you can specify it that way, and it will run. This will work in Miranda if you swap the lines around, though the brackets around 0 and n aren't neccessary - spaces will do as well. >There are also languages where you can DO things you wouldn't even think of >doing in assembler or C. Ever heard of lazy languages ? You can define lots >of stuff, the language won't even bother about evaluating them... unless it >NEEDS too. For instance, you can define the list of ALL the primes number, >and do computations with it... Just for the record: there is nothing these languages can DO that assembler can't (follows from Church's thesis). They just make it more convenient and neater. BTW Miranda also uses lazy evaluation and is one of the languages you are talking about. >Maybe quicksort is not always the right algorithm... it almost never is, >in fact. The thing is, it won't take you much longer to rewrite your >sort as a heapsort or anything else. Agreed. Just for the record (again), I was not trying to imply anything about the "right" sorting algorithm. I was just demonstrating the expressive power of very high-level languages and IMHO quick sort is a very nice and easy-to-comprehend example. >As advanced bibliography, the Peyton-Jones' Compiling Functional Languages ... Are you referring to the Prentice-Hall book "Implementation of Functional Programming Languages" by P-J or another book of his ? > Marc (espie@flamingo.stanford.edu) Michael Rizzo
dfrancis@tronsbox.xei.com (Dennis Heffernan) (04/09/91)
In article <7235@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: |I think you've made a very hasty comment there. You are obviously put |off by the notation and confused by the totally different approach to |imperative programming languages such as C that most people are |used to. That's not a hasty comment; that's one based on all the code I've seen from such wonderful languages as C, C++ and SmallTalk that look like line noise. I'd rather learn assembly than spend my life pondering strings of non- alphanumeric symbols. | |But if you know how the quick sort algorithm works (you'll find this in |any decent algorithms book) you should be able to understand those |three lines if you think about it. They're almost a specification of |quick sort rather than an implementation ! Familiarity with set and |function notation in Mathematics is also very useful. Just to help you |along if you want to understand it better: | [...] |The third line is obviously using recursion. In my opinion this line |captures the essence of the quick sort algorithm very elegantly. Again |think of how many PASCAL or C statements you'd need to implement |quicksort (more the so for assembler). Don't care how many lines it takes. If there was a language with the power of C or assembler and the readability of Cobol, I'd marry it. As it stands, anything I write other than rexx scripts gets either flow charted or psudo-coded first, and THEN I worry about the assembler code. It'd be pointless for me to go through all that and then put all the real code on three lines. |I can assure you that languages such as Miranda, Hope and ML, do |provide significant advantages over traditional programming languages. |Their authors have analyzed the shortcomings of traditional languages |and written new ones to overcome them. A very good introduction to |such languages is given in "An Introduction to Functional Programming" |by Bird & Wadler (published by Prentice-Hall) for anyone who's interested. |Increasingly more universities are including functional programming in |their undergraduate courses - there are even opinions that a functional |language should replace Pascal as the traditional first language taught |at university. The book review collumn in the current Byte covers some books that take the opposite stance. dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 ------------------------------------------------------------------------------ "Using C will definitely cut your life expectancy by 10 years or more." --Carl Sassenrath, GURU'S GUIDE TO THE COMMODORE AMIGA #1
mr3@ukc.ac.uk (M.Rizzo) (04/11/91)
In article <1529@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: > That's not a hasty comment; that's one based on all the code I've seen >from such wonderful languages as C, C++ and SmallTalk that look like line noise. >I'd rather learn assembly than spend my life pondering strings of non- >alphanumeric symbols. Is this some kind of a joke or what ? Do you honestly believe that the thousands of people using the above-mentioned languages are a bunch of idiots and you are some supreme programmer because you use assembler ? Did you ever try to learn one of the above languages properly before making up your mind ? (By properly I mean using a language for at least three months and working on exercises and at least a small project, all with the help of at least one decent book). "Seeing code" as you put it is far from being enough. >|The third line is obviously using recursion. In my opinion this line >|captures the essence of the quick sort algorithm very elegantly. Again >|think of how many PASCAL or C statements you'd need to implement >|quicksort (more the so for assembler). > > Don't care how many lines it takes. Less lines = less redundancy & more conciseness The less code and unneccessary details you have, the easier it is to figure out what is going on. An assembler listing is full of unimportant details as far as an algorithm is concerned. An AVERAGE Miranda programmer could easily recognize a quicksort in Miranda in a few seconds. An EXPERT assembler programmer would take minutes to recognize a quicksort written in assembler (ignoring helpful identifiers in both cases of course). >If there was a language with the >power of C or assembler and the readability of Cobol, I'd marry it. Readability of Cobol ? What a joke ! Readability does not mean using long English sentences. Cobol is horrible to look at - its all cluttered and has no parameter passing mechanism. I'd like to see how readable quicksort would be in COBOL - it doesn't even allow recursion so you'll have to manage a stack as well, and all this using global variables - what a mess! The syntax of a language isn't the only factor when it comes to readability. The features provided by the language are important factors as well e.g. local environments, apart from being important for information hiding, make a program more readable because the variables are declared close to where they are used and not hundreds of lines further up in some global DATA DIVISION or whatever COBOL calls it. >As it >stands, anything I write other than rexx scripts gets either flow charted or >psudo-coded first, and THEN I worry about the assembler code. It'd be >pointless for me to go through all that and then put all the real code on >three lines. No it wouldn't be pointless - it would save you a lot of time and would allow you to try out your program as quickly as possible without having to think about all the niggly details of assembler. Gee - it seems that you ENJOY making work MORE TEDIOUS for yourself ! >|I can assure you that languages such as Miranda, Hope and ML, do >|provide significant advantages over traditional programming languages. >|Their authors have analyzed the shortcomings of traditional languages >|and written new ones to overcome them. A very good introduction to >|such languages is given in "An Introduction to Functional Programming" >|by Bird & Wadler (published by Prentice-Hall) for anyone who's interested. >|Increasingly more universities are including functional programming in >|their undergraduate courses - there are even opinions that a functional >|language should replace Pascal as the traditional first language taught >|at university. > > The book review collumn in the current Byte covers some books that >take the opposite stance. Don't have the latest BYTE yet (I assume you're referring to April) so I can't comment. However I'm pretty sure these books don't say anything like you're saying about high-level languages. >dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 >------------------------------------------------------------------------------ >"Using C will definitely cut your life expectancy by 10 years or more." > --Carl Sassenrath, GURU'S GUIDE TO THE COMMODORE AMIGA #1 Gee - if that's true I wonder how assembler programmers manage to live past 30 :-) Sorry, but as far as I'm concerned, you are living proof that assembler does not separate the men from the boys. Why don't you try reading a few good books like Grady Booch's "Object-Oriented Design" which will give you solid examples and reasoning about the advantages of OOP languages like C++ and Smalltalk. Follow-ups to comp.misc for those interested in continuing this thread - I'm not :-) Michael Rizzo
Jeff.Petkau@f90.n140.z1.FIDONET.ORG (Jeff Petkau) (04/11/91)
In a message dated 10 Apr 91 19:52:41, Dennis Heffernan wrote:
DH> Don't care how many lines it takes. If there was a language
DH> with the power of C or assembler and the readability of Cobol, I'd
DH> marry it.
Easy. Just use any C compiler, and include the file below into each of your C source files.
---cut here---
#define PLEASE
#define please
#define ADDED_TO +
#define WITH_THE_FOLLOWING_AMOUNT_SUBTRACTED -
#define PLUS_1_THATS_ONE_I_MEAN ++
#define WITH_ONE_THATS_1_I_MEAN_SUBRACTED --
#define DIVIDED_BY /
#define MULTIPLIED_BY *
#define BUT_THAT_WAS_JUST_A_POINTER_TO_A_STRUCTURE_WHAT_I_REALLY_WANT_IS_THE_STRUCTURE_MEMBER_NAMED ->
#define BUT_THAT_WAS_JUST_A_POINTER_WHAT_I_REALLY_WANT_IS_THE_OBJECT *
#define BUT_THAT_WAS_JUST_A_STRUCTURE_WHAT_I_REALLY_WANT_IS_THE_MEMBER_NAMED .
#define BUT_THAT_WAS_AN_ARRAY_NAME_I_WANTED_ELEMENT_NUMBER [
#define OKAY_I_GOT_THE_ELEMENT_NOW ]
#define I_THINK_I_WOULD_LIKE_TO_START_A_BLOCK_NOW {
#define I_THINK_I_WOULD_LIKE_TO_END_A_BLOCK_NOW_PLEASE }
#define PUT_A_LEFT_PAREN_HERE (
#define PUT_A_RIGHT_PAREN_HERE )
#define BEGIN_PROGRAM_SECTION int main(argc,argv) int argc; char **argv;
--
Jeff Petkau - via FidoNet node 1:140/22
UUCP: ...!herald!weyr!90!Jeff.Petkau
Domain: Jeff.Petkau@f90.n140.z1.FIDONET.ORG
Standard Disclaimers Apply...dfrancis@tronsbox.xei.com (Dennis Heffernan) (04/12/91)
In article <7256@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: |In article <1529@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: |> That's not a hasty comment; that's one based on all the code I've seen |>from such wonderful languages as C, C++ and SmallTalk that look like line noise. |>I'd rather learn assembly than spend my life pondering strings of non- |>alphanumeric symbols. | |Is this some kind of a joke or what ? Do you honestly believe that |the thousands of people using the above-mentioned languages are a |bunch of idiots and you are some supreme programmer because you use |assembler ? No, worm, it's a personal preference. (Oh, I'M sorry, you DIDN'T want to be insulted? Next time keep a civil tongue in your head.) Last time I looked, ten million programmers don't all live up the same street. | |Did you ever try to learn one of the above languages properly before |making up your mind ? (By properly I mean using a language for at |least three months and working on exercises and at least a small project, |all with the help of at least one decent book). "Seeing code" as you |put it is far from being enough. I spent the better part of a year wrestling with C. I spent most of that time tripping over stupid syntactical errors brought about by the hieroglyphic-like nature of the language. |>|The third line is obviously using recursion. In my opinion this line |>|captures the essence of the quick sort algorithm very elegantly. Again |>|think of how many PASCAL or C statements you'd need to implement |>|quicksort (more the so for assembler). |> |> Don't care how many lines it takes. | |Less lines = less redundancy & more conciseness |The less code and unneccessary details you have, the easier it is |to figure out what is going on. An assembler listing is full of |unimportant details as far as an algorithm is concerned. An |AVERAGE Miranda programmer could easily recognize a quicksort in |Miranda in a few seconds. An EXPERT assembler programmer would take |minutes to recognize a quicksort written in assembler (ignoring |helpful identifiers in both cases of course). Still don't care how many lines it takes. Since I don't code without extensive comments, I never have a problem looking at my old stuff. I've met C programmers who can't read code they wrote a year ago, too. | |>If there was a language with the |>power of C or assembler and the readability of Cobol, I'd marry it. | |Readability of Cobol ? What a joke ! Readability does not mean using |long English sentences. Cobol is horrible to look at - its all |cluttered and has no parameter passing mechanism. I'd like to see |how readable quicksort would be in COBOL - it doesn't even allow |recursion so you'll have to manage a stack as well, and all this |using global variables - what a mess! Read it again. 90% of what you object to is how Cobol works, not how readable it is. (A friend who works with Cobol and BAL once told me of an incident at work. He showed a piece written in Cobol to another programmer who only did BAL, and she said "It's nice pseudocode, but what about the real program?") | |The syntax of a language isn't the only factor when it comes to |readability. The features provided by the language are |important factors as well e.g. local environments, apart from |being important for information hiding, make a program more |readable because the variables are declared close to where they |are used and not hundreds of lines further up in some global |DATA DIVISION or whatever COBOL calls it. Which is why I didn't say I would use Cobol. Try working more with English instead of Miranda. :-) | |>As it |>stands, anything I write other than rexx scripts gets either flow charted or |>psudo-coded first, and THEN I worry about the assembler code. It'd be |>pointless for me to go through all that and then put all the real code on |>three lines. | |No it wouldn't be pointless - it would save you a lot of time and |would allow you to try out your program as quickly as possible |without having to think about all the niggly details of assembler. |Gee - it seems that you ENJOY making work MORE TEDIOUS for yourself ! That's what ARexx is for. | |>|I can assure you that languages such as Miranda, Hope and ML, do |>|provide significant advantages over traditional programming languages. |>|Their authors have analyzed the shortcomings of traditional languages |>|and written new ones to overcome them. A very good introduction to |>|such languages is given in "An Introduction to Functional Programming" |>|by Bird & Wadler (published by Prentice-Hall) for anyone who's interested. |>|Increasingly more universities are including functional programming in |>|their undergraduate courses - there are even opinions that a functional |>|language should replace Pascal as the traditional first language taught |>|at university. |> |> The book review collumn in the current Byte covers some books that |>take the opposite stance. | |Don't have the latest BYTE yet (I assume you're referring to April) so |I can't comment. However I'm pretty sure these books don't say anything |like you're saying about high-level languages. No, from the excerpts in the review, I'd say they're more critical. From what I saw, it looks like they take the position that functional languages are a total waste of time. I only said that I didn't like them. |Sorry, but as far as I'm concerned, you are living proof that assembler |does not separate the men from the boys. Why don't you try reading a |few good books like Grady Booch's "Object-Oriented Design" which will |give you solid examples and reasoning about the advantages of OOP |languages like C++ and Smalltalk. Follow-ups to comp.misc for |those interested in continuing this thread - I'm not :-) Because I don't give a damn about "Object Oriented Programming". I have never actually heard anyone give a clear, concise description of just what this is supposed to get me, as a programmer. That includes my sysadmin, who lives for C++. Last time I checked, Allah had yet to send a new prophet to hand down the One True Way to program. dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 ------------------------------------------------------------------------------ "I swear eternal hostility to all forms of tyranny over the Amiga OS." --me, with apologies to Thomas Jefferson and Alexander Addington :-)
ben@epmooch.UUCP (Rev. Ben A. Mesander) (04/13/91)
>In article <1535@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: [...] > Because I don't give a damn about "Object Oriented Programming". >I have never actually heard anyone give a clear, concise description of just >what this is supposed to get me, as a programmer. That includes my sysadmin, >who lives for C++. Note: I'm not taking sides in this debate. I program in HLL's and assembly languages, and even APL, which many people consider the worst excuse for a language there is. One reason I've wanted to try C++ is the ability to define new datatypes *and* the operators that work on them. For instance, say you're programming in C and you want to do some complex math. You have to define functions or macros to do +, -, *, and /. Now as I understand it, in C++, you could somehow tell +, -, *, and / to work on complex numbers. This is neat, and reminds me of how APL, or my HP-28 calculator works. I'd like to give it a try. > Last time I checked, Allah had yet to send a new prophet to hand down >the One True Way to program. Heh. >dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/14/91)
In article <1535@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: >In article <7256@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >|In article <1529@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: > No, worm, it's a personal preference. (Oh, I'M sorry, you DIDN'T want !!!!!!!!!!!!!!!!!!!!! Hey! We just *finished* a flame war, go to personal email with this please! !!!!!!!!!!!!!!!!!!!!! >dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (04/15/91)
From article <1535@tronsbox.xei.com>, by dfrancis@tronsbox.xei.com (Dennis Heffernan): > In article <7256@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: > |In article <1529@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: > |> That's not a hasty comment; that's one based on all the code I've seen > |>from such wonderful languages as C, C++ and SmallTalk that look like line noise. > |>I'd rather learn assembly than spend my life pondering strings of non- > |>alphanumeric symbols. > |Is this some kind of a joke or what ? Do you honestly believe that > |the thousands of people using the above-mentioned languages are a > |bunch of idiots and you are some supreme programmer because you use > |assembler ? > |Did you ever try to learn one of the above languages properly before > |making up your mind ? (By properly I mean using a language for at > I spent the better part of a year wrestling with C. I spent most of > that time tripping over stupid syntactical errors brought about by the > hieroglyphic-like nature of the language. Hmm. All I can ask is, "Are you suffering from major brain damage, or a simple case of the 'slows'?". If you've lived in "C" code for a year, you can eat, sleep, and drink "C". You can even read Matt Dillon's code, if you play with "C" long enough! > Still don't care how many lines it takes. Since I don't code without You should. I program assembler with extensive comments, too, and I still have to do a whole lot more page-flipping to trace my flow of control than I do in "C". There's a point where conciseness wins. When I can get my entire function, my entire algorithm, onto one page of my screen (albeit that I generally run a severely overscanned interlaced screen!), that function becomes a WHOLE lot easier to debug. Now, I don't know about you, but I have a whole lot of difficulty doing that with assembler. > |>If there was a language with the > |>power of C or assembler and the readability of Cobol, I'd marry it. Cobol? *COBOL*??? NO WONDER! (Use of Cobol for six or more months is guaranteed to cause baldness, impotence, and a few other plagues upon humanity... typical Cobol programmers think that EMACS is something sold at McDonald's, and think that UNIX is something to do with harems... MVS/CICS is their world, the whole world). I've programmed COBOL. I consider it to be a plague upon the world. It fits that you'd love Cobol, because "Hello_World" in COBOL is more lines of code than I particularly care for. The so-called "readability" is akin to the so-called "readability" of Ada... i.e., it consists of turning simple accepted computer science symbols into long sentences of words that mean not one more thing to a "real" programmer. > Read it again. 90% of what you object to is how Cobol works, not > how readable it is. (A friend who works with Cobol and BAL once told me of an > incident at work. He showed a piece written in Cobol to another programmer > who only did BAL, and she said "It's nice pseudocode, but what about the real > program?") Heheh. Just tells you about the mentality of people who program in BAL! If you want real "pseudocode", use Pascal. The Algol-like pseudocode used in most algorithms journals is extremely close to Pascal... can almost plug-and-play, many times. > |>|I can assure you that languages such as Miranda, Hope and ML, do > |>|provide significant advantages over traditional programming languages. > No, from the excerpts in the review, I'd say they're more critical. > From what I saw, it looks like they take the position that functional languages > are a total waste of time. I only said that I didn't like them. Interesting... if you're looking for opinion articles from obviously biased people. I suppose you agree with everything Bill Buckley or (hmm, who's a liberal columnist?) writes, too. I view such books as entertainment, mostly... few of them have much to say from a conceptual viewpoint. [My own personal opinion is that languages much higher level than C++ are impractical on common microcomputers due to their greater resource usage... or as Alan Perlis put it, "A Lisp programmer knows the value of everything and the cost of nothing."] > |Sorry, but as far as I'm concerned, you are living proof that assembler > |does not separate the men from the boys. Why don't you try reading a > |few good books like Grady Booch's "Object-Oriented Design" which will > Because I don't give a damn about "Object Oriented Programming". > I have never actually heard anyone give a clear, concise description of just > what this is supposed to get me, as a programmer. That includes my sysadmin, > who lives for C++. Gee, he gave you a book on it! Are you just some grumbling octogenarian afraid of change, or have you actually written a project in an object-oriented fashion and found it to be, indeed, inferior to the way you're currently doing things? The way I see it, you're just like those steelworkers who insisted, "Nope, I ain't gonna do it, this was good enough for my daddy, it's good enough for me" when asked to upgrade their skills to improve productivity... those same steelworkers are out the door, now, their companies bankrupted or fired all those workers to install new technology for which such workers refused to be retrained. I wonder what'll happen to you when the day comes that your claims of "Nope, I ain't gonna do it, this was good enough for me twenty [years/minutes/etc] ago, it's good enough for me today" reach unsympathetic ears? -- Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg
comeau@ditka.Chicago.COM (Greg Comeau) (04/15/91)
In article <1535@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: > Because I don't give a damn about "Object Oriented Programming". >I have never actually heard anyone give a clear, concise description of just >what this is supposed to get me, as a programmer. That includes my sysadmin, >who lives for C++. I would be more than happy to discuss any OOP concerns that you my have. As you appear to be an assembler programmer, you may not "go for it" as you probably don't go to HLL like C, but I'd be willing to give it a whirl. - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310
nsw@cbnewsm.att.com (Neil Weinstock) (04/16/91)
In article <00671693310@elgamy.RAIDERNET.COM> elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes: >From article <1535@tronsbox.xei.com>, by dfrancis@tronsbox.xei.com (Dennis Heffernan): [ ... ] >> Still don't care how many lines it takes. Since I don't code without > >You should. I program assembler with extensive comments, too, and I still >have to do a whole lot more page-flipping to trace my flow of control than >I do in "C". There's a point where conciseness wins. When I can get my >entire function, my entire algorithm, onto one page of my screen (albeit >that I generally run a severely overscanned interlaced screen!), that >function becomes a WHOLE lot easier to debug. Now, I don't know about you, >but I have a whole lot of difficulty doing that with assembler. [ ... and later, in an unrelated point, ... ] >[My own personal opinion is that languages much higher level than C++ are >impractical on common microcomputers due to their greater resource usage... >or as Alan Perlis put it, "A Lisp programmer knows the value of everything >and the cost of nothing."] To tie these together (sort of :-/), a bunch of us in his class found it amusing that the esteemed Dr. Perlis believed that APL was absolutely the most readable language. Why? Because programs were so absurdly compact that you could almost always see them all at once on a page. Yeeks! Anyway, we cut him some slack because he despised Pascal and was therefore OK in our books. [ Perlis actually could have made the above quote to characterize APL programmers. We routinely struggled to find new and bizarre ways of doing things in the fewest characters. This often entailed using things like 6 dimensional array transforms, and other such monstrosities. We shuddered at the thought of what contortions we were causing the computer with our 30 characters of code... ] An APL survivor, - Neil --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-- Neil Weinstock @ AT&T Bell Labs // What was sliced bread att!edsel!nsw or nsw@edsel.att.com \X/ the greatest thing since?
dfrancis@tronsbox.xei.com (Dennis Heffernan) (04/16/91)
In article <00671693310@elgamy.RAIDERNET.COM> elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes: |Hmm. All I can ask is, "Are you suffering from major brain damage, or a |simple case of the 'slows'?". If you've lived in "C" code for a year, you |can eat, sleep, and drink "C". You can even read Matt Dillon's code, if you |play with "C" long enough! Sez you. I am not the only student of computer programming who thinks C is overly cryptic. |You should. I program assembler with extensive comments, too, and I still |have to do a whole lot more page-flipping to trace my flow of control than |I do in "C". There's a point where conciseness wins. When I can get my |entire function, my entire algorithm, onto one page of my screen (albeit |that I generally run a severely overscanned interlaced screen!), that |function becomes a WHOLE lot easier to debug. Now, I don't know about you, |but I have a whole lot of difficulty doing that with assembler. I read in excess of 1600 words per minute, so volume just doesn't concern me. An overabundance of symbols DOES concern me- it's like hitting a roadblock. |Cobol? *COBOL*??? NO WONDER! (Use of Cobol for six or more months is |guaranteed to cause baldness, impotence, and a few other plagues upon |humanity... typical Cobol programmers think that EMACS is something sold at |McDonald's, and think that UNIX is something to do with harems... MVS/CICS |is their world, the whole world). I have never in my life written or even learned a single iota of Cobol. I've seen Cobol code, but that's it. | |I've programmed COBOL. I consider it to be a plague upon the world. It fits |that you'd love Cobol, because "Hello_World" in COBOL is more lines of code |than I particularly care for. The so-called "readability" is akin to the |so-called "readability" of Ada... i.e., it consists of turning simple |accepted computer science symbols into long sentences of words that mean |not one more thing to a "real" programmer. Speak for yourself. I've seen Ada code, too, and I liked the look of it a whole lot more than I liked C. I've got a book on it here that I keep meaning to read, but it's pushed way down on the stack- new books keep getting put on top of it, not all of them computer related. |Are you just some grumbling octogenarian afraid of change, or have you |actually written a project in an object-oriented fashion and found it to |be, indeed, inferior to the way you're currently doing things? The way I |see it, you're just like those steelworkers who insisted, "Nope, I ain't |gonna do it, this was good enough for my daddy, it's good enough for me" |when asked to upgrade their skills to improve productivity... those same |steelworkers are out the door, now, their companies bankrupted or fired all |those workers to install new technology for which such workers refused to |be retrained. NO, it means that NO ONE has ever given me a CLEAR, CONCISE description of just WHAT THE HELL 'object oriented programming' IS. That includes my local C++ junkie. |Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 |elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 ------------------------------------------------------------------------------ "I swear eternal hostility to all forms of tyranny over the Amiga OS." --me, with apologies to Thomas Jefferson and Alexander Addington :-)
cs450a03@uc780.umd.edu (04/16/91)
Neil Weinstock writes: >To tie these together (sort of :-/), a bunch of us in his class found >it amusing that the esteemed Dr. Perlis believed that APL was >absolutely the most readable language. Why? Because programs were >so absurdly compact that you could almost always see them all at once >on a page. Yeeks! I hope he had something of a sense of balance... programming for compactness instead of readability can just as easily destroy all readability as it can improve readability (witness many programs in the obfuscated C contest). Also, APLs have had nasty tendencies (like the editors eating all redundant whitespace) which do nothing good for readability. >Anyway, we cut him some slack because he despised Pascal and was therefore >OK in our books. >[ Perlis actually could have made the above quote [["A Lisp programmer knows the value of everything and the cost of nothing."]] to characterize APL >programmers. We routinely struggled to find new and bizarre ways of doing >things in the fewest characters. This often entailed using things like 6 >dimensional array transforms, and other such monstrosities. We shuddered at >the thought of what contortions we were causing the computer with our 30 >characters of code... ] Maybe he didn't teach you this (or maybe he did), but each of those functions you were using had well defined costs. Transposition, for example, is O(n) where n is the number of elements in the array. Raul Rockwell
angst@cs.uq.oz.au (Angst) (04/17/91)
In <1547@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: >In article <00671693310@elgamy.RAIDERNET.COM> elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes: >|Hmm. All I can ask is, "Are you suffering from major brain damage, or a >|simple case of the 'slows'?". If you've lived in "C" code for a year, you >|can eat, sleep, and drink "C". You can even read Matt Dillon's code, if you >|play with "C" long enough! > Sez you. I am not the only student of computer programming who thinks >C is overly cryptic. I agree, if you are reading a badly-written C program. Just because you use C, you don't have to produce obfuscated code every time. Using the s/w engineering techniques we all know and love, neat, concise and clear C code can be written. C is terse, but that alone doesn't make it cryptic. "C doesn't make cryptic code, people make cryptic code." "When C is outlawed, only outlaws will-", sorry, got carried away with the analogy. > NO, it means that NO ONE has ever given me a CLEAR, CONCISE description >of just WHAT THE HELL 'object oriented programming' IS. That includes my local >C++ junkie. That's probably because none exists. OOP is not yet as well defined as other older (some would say less powerful) programming paradigms. The academic community has yet to agree on a formal definition of inheritance, for example. This does not mean it is bollocks, however. Each of the object oriented languages around at the moment (and there are quite a few) has its own ways of dealing with the problem areas of the paradigm. Most cope quite well and the programmer can make use of the advantages of object oriented programming. It's simply a matter of having an open mind. Instead of recoiling with horror and steadfastly hanging on to first impressions (no flame intended), learn something about new languages/paradigms and see if they can't be of use to you. >dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 Angst ----------- "Hire you a horse? For ninepence? On Jewish New Year's Eve in the rain? A bare fortnight after the dreaded horse plague of Old London Town? With the blacksmith's strike in its fifteenth week and the Dorset Horse-Fetishists fair tomorrow?" -- Baldrick, dogsbody to the butler to the Prince Regent. ------------------
dege@cs.umn.edu (Dege Jeffrey Charles) (04/17/91)
In <1547@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: > NO, it means that NO ONE has ever given me a CLEAR, CONCISE description >of just WHAT THE HELL 'object oriented programming' IS. That includes my local >C++ junkie. That's because OO is primarily a design methodology, not a programming style. --------------- JMHO ;)
comeau@ditka.Chicago.COM (Greg Comeau) (04/17/91)
In article <ben.5890@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: > One reason I've wanted to try C++ is the ability to define new datatypes >*and* the operators that work on them ...as I understand it, in C++, you could >somehow tell +, -, *, and / to work on complex numbers. One part of C++ *does* offer that capability. As in all language features, it should only be used as appropriate though (yes, complex numbers are certainly appropriate!). - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310
peterk@cbmger.UUCP (Peter Kittel GERMANY) (04/17/91)
In article <16APR91.08223865@uc780.umd.edu> cs450a03@uc780.umd.edu writes: >Neil Weinstock writes: > >>To tie these together (sort of :-/), a bunch of us in his class found >>it amusing that the esteemed Dr. Perlis believed that APL was >>absolutely the most readable language. Why? Because programs were >>so absurdly compact that you could almost always see them all at once >>on a page. Yeeks! > >I hope he had something of a sense of balance... programming for >compactness instead of readability can just as easily destroy all >readability as it can improve readability (witness many programs in >the obfuscated C contest). This is an aspect also I find very important. Simply put: I really *HATE* languages where I'm only allowed for one statement per line. I remember colleagues of mine with those BIG lineprinter printouts (140 colums wide) and ALL their programs only covered the left 20 to 40 columns on this paper in Fortran, yuck. You must see, I learned programming in Algol 60 (Pascal not on the horizon back then), where I could write very structured but compact code. And the same can be done with C or modern BASIC dialects (and nearly all other modern languages). I really need to have a portion of the program as big as possible at one time in my view, be it on a printout or on screen. You lose so much of the thread when you have to page back and forth like wild. So, GFA Basic may be one of the fastest things on earth, but it has only one statement per line, nothing good for me, sorry. (They also tell me about lots of bugs...) Ok, assembler is a different story. There you normally use the rest of the line for comments which are really necessary in assembler. To tie this with another thread: I advocate also for the style to write the most of a program in a HLL and only do critical parts in assembler. I once (on the PET :-) had an example with a real big program in Basic plus a 20-byte assembler routine, where the latter speeded things up by factor 10 to 100. I found this adequate. But at the same time I knew it wouldn't give any further performance if I wrote also the big rest in assembler, so I didn't. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
comeau@ditka.Chicago.COM (Greg Comeau) (04/20/91)
In article <1991Apr17.023504.5023@cs.umn.edu> dege@cs.umn.edu (Dege Jeffrey Charles) writes: >In <1547@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: > >> NO, it means that NO ONE has ever given me a CLEAR, CONCISE description >>of just WHAT THE HELL 'object oriented programming' IS. That includes my local >>C++ junkie. > That's because OO is primarily a design methodology, not a programming >style. No, not really. I mean, yes, there is OO design, but there is also OO analysis, OO programming, etc, all of which are related but distince in their own rights as well. -- Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310