Programming project

[Tanton Gibbs]

>>    Another problem with many programming languages(including Perl) is
>> that they try to please everybody.  I'm more in favor of a RISC like
>> programming language that provides a complete yet minimal set of
>> instructions.  Don't get me wrong.  I include += -= and so forth as
>> complete as well as for, while, do, etc...  The minimal part comes in
>> where there is 5 ways to write a do while loop, etc...  You don't 
need
>> repeat-until if you have do-while.
>
>A language can please everybody all it likes.  Features not many people
>will use can be put in the library.  
  I agree with this statement, but I think you missed my point later 
on...I'll get to it...

>As for your "repeat-until" example, I'll have to strongly disagree. 
>Syntactic sugar (or shorthand forms) is extremely important in
>programming languages, and the complexity it adds to them is vastly
>overrated.

Right here...I think you misunderstood my example.  First, I agree with 
the need for a prefix loop, postfix loop, etc...  I just said that you 
did not need two nearly identical ways to do a postfix loop.  For 
example, Perl allows both
do{ ... } while( ... ) and repeat{ ... } until( ... )
These are both so similar that it will be confusing to many programmers 
to see one when they are used to seeing the other.  Another example is 
the Perl statements
if( x ){ exit }
and 
exit if( x );

These are completely unnessary, they do the same thing in two different 
ways when one would suffice.  This is what I mean by a RISC programming 
language.  I agree with providing the programmer a large amount of 
freedom, but the freedom must not be such that it doesn't interfere with 
the ability to recognize common structures.

>Structured programming zealots don't like exit for some reason.  They
>forget that structured programming was invented to make programming
>easier.  It's a tool, not a religion.  In some places exit is just the
>best tool for the job,

I could extend this to the OO paradigm.  OO is a tool, not a religion 
and does not need to be forced on the programmer.  Structured design has 
been around for decades and it is known by almost every programmer.  
While OOAD and OOPS are just getting off the ground, SAD in structured 
languages is fairly formalized and many people are more comfortable in 
that language.  This, however, does not conflict with my minimal 
beliefs, because only allowing one paradigm does not make a programming 
language complete.  Both the structured and the OO paridigm have to be 
included for the language to be complete.  However, a language can be 
complete by having just a do while instead of a do while and a repeat 
until.

>For that matter why include for when you have while?
I know this is a rhetorical question, but for is justified, if only 
slightly because of the ability it gives the programmer to understand 
the code easier.  By glancing at the code, someone who is not familiar 
with the code can understand more about the code by seeing a for than if 
all fors were implemented with a while loop.  This does not conflict 
with the do.while and repeat.unitl example because you cannot glean any 
more information from looking at the words do while than you could 
repeat until.

>>   loop( int x = 0; x < y; x++ )  // this is a for loop
>>   ...
>>   endLoop;
>> 
>>   loop( x < y )  // this is a while loop
>>   ...
>>   endLoop;
>> 
>>   loop  // this is a do while loop
>>   ...
>>   endLoop( x < y );
>> 

>I'm not sure how this relates to functional programming.  

Just pointing out that functional programming was designed so that ALL 
facets of programming would look alike. My idea above was that this was 
not quite what should happen and that a more orthogonal approach should 
be implemented.

>Firstly, the use of higher order functions to the degree of functional
>languages (both higher order functions and procedures), which is 
largely
>possible at the language level but for some reason is not done at the
>library level (how many languages have a map function or procedure?)
>
>Secondly, the introduction of pure (deterministic and referentially
>transparent) functions AND procedures into languages.  Non pure
>submodules can stay, but they would have less rights - for example you
>couldn't use non pure functions in say a := b + c.  This makes programs
>easier to understand, and is a good help to the compiler in
>optimisation.  I believe some languages have tried this sort of thing,
>>The
>> integration of libraries and user code must be an important and well
>> designed feature of this language.

>I'm not sure what you mean by "integration of libraries and user code"
>here.
For example, to include a library in C++ you must #include the header 
and also add it to the make file.  I think that a more user friendly 
system should be implemented once again much like Java's import 
statement.  This way, functions that are not used do not get compiled 
and headers cannot be included more than once( thus eliminating the need 
for the #ifndef and #define )

>>   I don't like Java because it forces you to program in one paradigm.
>> Even if it is an object oriented one, the notion that I "have" to do
>> things a particular way upsets me.  I'm a big fan of C and C++
>> especially.  I think that there are a number of things that could be
>> improved, but for the most part, I enjoy the languages.
>
>But you just said above you thought a language shouldn't try to appeal
>to everyone.  But what is a paradigm if not appealing to the style of
>writing of different people (to the group of people for who it would be
>the best paradigm?)

I think I covered this above.  A language shouldn't appeal to everyone 
by means of syntactic sugar, but it should be complete.

...( look at original doc for prev. discussion )

>Thirdly, that value (1 in the previous case), might not be statically
>determinable.  This is where we start running into trouble.  Say the
>value we want to add to each member on the list is entered by the user
>or obtained from elsewhere in the program or some such.
>
>What to do?  We can't write:
>
>increment: procedure(a: integer) -> integer := add(a, b)

If you want to increment the node by a user defined value, then I would 
either do one of two things, either input the value in the function, or 
use a global variable( perhaps in a C++ namespace ) I think a true class 
is overkill in this situation.
I think the problem is trying to simplify the function to a "thunk"-like 
state.  You should define a more complex procedure that will either 
input your value each time, or calculate it, or whatever.  The only time 
that you would want multiple values at the same time is with parallel 
processing and that is a different ball game entirely.

Well,
>define "free methods" as a shorthand for a class definition, and you 
can
>get the smaller code size, plus retain the ability to extend the class
>if necessary.

I find this hard to swallow.  BETA tried something similar to this and 
died a horrible death in a sea of syntactic troubles.  Allowing users to 
"extend" "free methods" sounds like trouble to me.

>>   As for string handling, I enjoy the way C does string handling( 
much
>> to the chagrin of the other members :)  The problem with built in 
string
>> handling is that it is too restrictive.  Lets look at two 
alternatives
>>   String s;
>> First, what does this do?  Is it like Pascal and take up 256 
characters,
>> or is it more like the string class in C++ and dynamic.  If it takes 
up
>> 256 characters and the string is "HI", then there is a severe memory
>> loss, enough to make the language not practical for embedded systems 
and
>> many other memory critical areas.  On the other hand, dynamic 
allocation
>> is much slower and will require a lot of compiler overhead and is 
often
>> Machine dependent.  Furthermore, which memory allocation scheme 
should
>> we use since most schemes don't work for everyone.  Either way it is 
a
>> mess.  The C++ alternative provides a clean way to create a string 
that
>> can be extended by classes to provide a nice solution.
>
>You're tickling my personal language design beliefs today.  =)  There
>are various kinds of strings - fixed size, bounded (maximum) size and
>unbounded size.  Ada 95 manages to provide all three in a library. 
>You're concerned here with the efficiency of string implementation
>
>Programming languages have for too long confused the notions of
>interface and implementation.  Why do you have a class which has one
>implementation?  What languages should do is provide an interface for
>strings, and several implementations, whereupon the programmer simply
>chooses the best one.

I don't believe that I have ever seen this proposal for strings.  The 
reason being is such:  How do you do the underlying implementation of 
the string interface?  I would guess through a vector of characters or 
char* thereby we are back to the C way...my personal favorite :)

>True, but we are human, and we should still try to protect against
>error.  

We should try to protect against error, but not at the cost of 
functionality.

>That's what strong typing is, after all.  

Strong typing is not in the same boat because weak typing does not 
increase functionality in a way that it could not be done before.  
However, MI is hard to implement effectively and easily if it is not 
included in the language.  Strong typing can use typecasts and functions 
to easily emulate weak typing.

>Yes, but I don't believe JVM is a good level for optimising at, at 
least
>from what I've heard.  

I don't know, I haven't looked at it, but I wouldn't imagine optimizing 
at the compiled level anyway, naturally an intermediate language should 
be formed, either a trinary or quatranary stack language to easily 
optimize similar statements and then an AST to handle data flow and 
larger structures.


Tanton

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com