× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: How about in INC opcode(how important is syntax in the learni ng curve?)
  • From: Joel Fritz <JFritz@xxxxxxxxxxxxxxxx>
  • Date: Fri, 10 Mar 2000 09:13:01 -0800

I think we don't disagree very much.  I tend to see most everything that
involves problem solving as a matter of finding the best language to state
the problem and then looking for a mechanical solution.  It could be
algebra, latin, SQL, RPG,........

I think a good example of the inseperability of grammar and syntax from the
underlying concepts of a computer language that most midrange people deal
with all the time is RPG vs. SQL.  If you want to do a simple file update,
it's pretty easy in RPG, but a generic update query will do the job so
easily it will make your head swim.  On the other hand, selecting the top
however many or assigning things to groups in some sort of heirarchy is
easier in RPG than SQL.   

Boy, this is more fun than work. <g>
> -----Original Message-----
> From: boldt@ca.ibm.com [mailto:boldt@ca.ibm.com]
> Sent: Friday, March 10, 2000 5:25 AM
> To: MIDRANGE-L@midrange.com
> Subject: RE: How about in INC opcode(how important is syntax in the
> learni ng curve?)
> 
> 
> 
> 
> Joel wrote:
> >I think it's a semantic issue and that I wasn't completly 
> clear on what I
> >meant.
> >
> >First, I should have said grammar and syntax.
> >
> >Second, my Whorf-Sapir analogy was that the grammar and syntax of a
> computer
> >language are products of the underlying concepts and provide 
> a way to make
> >inferences about the underlying concepts of the language.  I 
> don't think
> you
> >can really use the syntax correctly unless you understand 
> the underlying
> >concepts, and I think that understanding the syntax well 
> should lead to a
> >better understanding of the underlying concepts.
> >
> >In a procedural language when you want to print something 
> you invoke the
> >print verb in some way or other.  In an object oriented language you
> invoke
> >the print method of the object you want to print, or you get 
> some sort of
> >information(message) from an object and pass the results of 
> that to the
> >printing object.  To me this is a matter of grammar and 
> syntax, but I can
> >easily see how someone else wouldn't see it that way.  I think it's
> possible
> >to talk about inheritance and polymorphism from this point 
> of view too,
> but
> >it's getting a little late in the day for me for abstraction.
> 
> Well, maybe it's too early in the day for me to put together a
> cogent response, but...
> 
> Yes, basically it is a semantic issue.  But I think we're
> looking at this from different angles.  Yes, at one level, you
> could argue that at an operation level, most languages basically
> implement the same concepts.  For example, you could take a
> program written in a procedural language, like C, and translate
> it more or less word for word into a more sophisticated language
> like Java or Perl.  But, at a higher level, it wouldn't
> necessarily be a good Java or Perl program.  Java and Perl allow
> for different levels of abstraction.  A good program in Java
> involves breaking down the problem into its constituent objects.
> Perl is good if you can reduce the problem into a string
> manipulation exercise.  These higher levels of abstraction
> encourage the programmer to think about the problem differently.
> Not just in terms of stringing together a set of basic
> operations (which generally exist in most languages), but rather
> to transform the problem description at a higher level.  Look at
> the language Prolog for something that really gets away from the
> procedural model!
> 
> Look at this (simplistic) history of programming:  In the 40's,
> programming was done by hardwiring circuit boards.  In the 50's,
> it was assembly language.  The 60's brought structured
> statements. The 70's gave us data structures.  The 80's, modules.
> And the 90's made us learn objects.  Each decade made us think
> about our programming problems at a higher level of abstraction.
> The underlying hardware really hasn't changed much - it still
> does MOV and ADD and JMP instructions - but the way we think
> about programming has.
> 
> Perhaps that's what's wrong with the Whorf-Sapir hypothesis:
> There are simply too many levels of abstractions between human
> language and the underlying hardware.  But then, that discussion
> really belongs to philosophers and cognitive psychologists.
> 
> Cheers!  Hans
> 
> Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
> 
> 
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.