SCOUG-Programming Mailing List Archives
Return to [ 06 |
August |
2003 ]
<< Previous Message <<
Content Type: text/plain
> Peter Skye said:
> > An excellent programming language would be English
>
Robert Blair wrote:
> English is too ambiguous a language to be used that way.
So you'll have a few bugs in your programs. Lynn isn't trying to design
a tool which creates bug-free code.
> A new language with features from some of the many
> programming languages that are now available. I say new
> only in the sense that it will include features from many
> languages as such it will not be something that has not
> already been done.
I'm not sure what Lynn's project goal is, and I'm worried that his
Warpstock audience won't understand it either.
If he wants to incorporate various already-in-use language features into
a new HLL, how will he accomplish this? Does he have a game plan, a
critical path, a copy of the language spec of every language he wants to
draw from? Will he start with a new language spec and then move on to a
compiler or is he more intrigued with the open typing and code
optimization and will first write the compiler, then write the language
specs based on what the working compiler can do? In other words:
What's going on?
> > On this list we use a "best-fit" communication tool:
> > English.
>
> And look at the confusion between ourselves trying to
> communicate in English.
But this is *good*. Better to be confused in an understandable way. I
just *hate* it when I write something in Rexx and get unanticipated
results and have to spend 30 minutes looking for an if-then-else group
that's outside the logic block I thought I'd created. At least in
English someone (or the compiler) can say, "did you mean _this_ or did
you mean _that_?"
> Lynn has an idea on how to improve programmer
> productivity we just need to agree on where
> to start, the goal has already been set.
Okay. What are the choices we need to agree on? My preliminary thought
is to write the language spec first.
> . . . Lynn's idea, design a new programmer interface.
> So far everyone has been arguing about the compiler
> where very little benefit will be obtained.
Hmm. Should the programmer interface be designed *before* writing the
HLL spec?
> > As for proving the code, good idea. I have no knowledge
> > at all in this field. I've seen it mentioned from time
> > to time in various articles but never defined or
> > explained. Anybody want to enlighten me?
>
> It is called logic programming. Look at Prolog.
Lynn: How will you cohesively bring PL/I and Prolog together in one
HLL? I have only a cursory understanding of Prolog, but nevertheless I
don't see a full overlap.
> We need to define the big picture of the project
> and then set priorities for the various parts.
>
> As I see it these are the parts.
>
> 1.programmer interface
>
> 2,3,4,5
> data base,completion logic,syntax/semantic checks,testing
>
> 6.compiler
I'll buy into this analysis. Thanks, Bob.
> To start to prove that this will work you need
> to start at the top and work your way down, in
> this case bottom up will not get you anything
> because the benefits occur at the top.
Okay, so the Programmer Interface is first.
> So what I see as the priorities are
> 1.programmer interface - which includes the language definition
> 4.syntax/semantic checks
> 3.completion logic
> 5.testing
> 2.data base
> 6.compiler
I don't yet have the concept of how the Programmer Interface (PI)
includes the language definition (your priority #1 above).
Here's my confusion:
-- Suppose you're designing a screen layout. The PI lets you drag
controls to where you want them, resize and label them, associate
actions with them. When you're done, the code is generated without you
having to do any coding (for the screen layout). Is this graphical
layout capability supposed to be a part of the language definition?
(Yes I know that such design tools just create tables which are
interpreted at run time, but the method of implementation doesn't impact
whether such a tool should be defined in the HLL.)
-- Suppose you're creating a typical match-merge program (read two
sorted files and create a single sequenced file). Do you use PL/I-ish
statements written in a text editor, or do you instead open a
boilerplate match-merge template, import the file formats for the two
source files, click on the fields to be matched, and let the PI do the
rest?
In short, what exactly is does the new PI encompass and is it, or is it
not, a front-end for generating a line-by-line source code file?
Or is this decision a part of the Open Source development cycle and
we're all supposed to chime in?
- Peter
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
Return to [ 06 |
August |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
|