[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Apr 10 13:42:15 2000 
Subject:Re: List of Possible Poplog Projects 
From:steve 
Volume-ID:1000410.04 

Hi,

I'll pick up on three comments made by both Jason Handby and Jonathan
Cunningham.

>  > I would like proper typed variables in poplog. Yes, truly.
>>
>>  I've got used to using typed languages, and I no see no advantage
>>  whatever in pop11's untyped variables. (Ditto for lisp, incidentally.)
>>
>  > If there are any advantages, someone remind me.
>
>I entirely agree.

Well, since you both asked here is my favourite example.  Let us suppose
we want to write a generalisation of -pdcomp- as follows.

     define pdcomp_list( L );    ;;; takes a list of funcs
         applist(% L, apply %)
     enddefine;

Obviously, this is the sort of thing that we might wish to do when we
are comfortable using higher-order functions.  There's nothing peculiar
or dangerous about this beast when writing
    [ ^length ^negate ].pdcomp_list
for example.  OK, so what type does it have?  See the problem?  Here
it is in Standard ML

- fun pdcomp_list [] x = x
= |   pdcomp_list ( h :: t ) x = pdcomp_list t (h x);
   val pdcomp_list = fn : ('a -> 'a) list -> 'a -> 'a

- pdcomp_list [ length, op ~ ];  

Error: in expression
         [length, ~]
Not all the list members have the same type:
         length : 'A list -> int
         ~ : 'A list -> 'A list


Of course, the typical reply to examples of this kind can be paraphrased
as "it doesn't count because no one wants to do that."  This is rather
daft because (a) we can all agree that strongly typed languages are
both popular and practical (b) so there is bound to be some sensible
alternative way of getting the effect you want (c) hence we are debating
whether or not the alternative is such a direct expression of intent and
(d) there are lots of people who _do_ want to program that way.  Like me.

If you still find yourself wanting to argue about how obscure it is, I
have some simpler examples.  Such an example arose the other day - when
someone decided to write an algorithm that employed fgetc, which returns
an int which represents a character or end-of-file.  Their code failed to
detect EOF at the right point and, by indexing with this value, clobbered
the bookkeeping information used by malloc destroying the integrity of
of the run-time system at a much, much later time.

The usual problem with these simpler examples is that everyone want to
pile in and explain how it isn't the fault of strong typing but the fools
that use it.  I anticipate remarks along the lines of -fgetc- is "broken"
and no one writes interfaces like this anymore .... and I offer in
return the following -- straight off the Javasoft site.

public int indexOf(int ch)

	Returns the index within this string of the first
	occurrence of the specified character. If a character with
	value ch occurs in the character sequence represented by
	this String object, then the index of the first such occurrence
	is returned -- that is, the smallest value k such that:

		this.charAt(k) == ch
                     

	is true. If no such character occurs in this string, then
	-1 is returned.

Just in case it is not obvious why this is a poor interface, let us
suppose that we forgot to check the -1 result when we were checking
out the successor character.  We might write something daft like this ...

     s[ max( s.indexOf( ch ) + 1, s.length ) ]

So, to spell out the entire argument, strong typing is a restriction on
the language that (despite undoubted benefits) occasionally leads to
awkward situations.  The temptation to fudge the solution remains
irresistible to even very good language designers, such as the Java folks,
and makes the relevant code more vulnerable to error than the dynamically
typed equivalent.  In these cases _both_ clarity and safety are compromised.
In addition, the restrictions entailed by strong typing can be very
problematic when working with collections of cooperating functions.
And although the strongly typed languages have won hands-down in terms of
popularity, there is nevertheless a considerable demand for dynamically
typed languages.

Hey, you did ask.


>  > (And the ability to
>>  use a variable without declaring it is a DISadvantage, not an advantage.)
>
>Absolutely. As an undergraduate learning pop11, I switched this off as soon
>as I knew how. As a more experienced programmer, I'm, er, "surprised" that
>such a rich and fertile source of novice bugs is touted as a feature :-)))

I've never heard anyone call it an advantage.  It is a feature that, to
the best of my knowledge, is there to help novices learn interactive
programming.  Unfortunately, because Poplog does not make a distinction
between interactive programming (where it is arguably the correct
behaviour) and non-interactive programming, it has become established
as the default.

Let's establish a distinction between interactive and non-interactive
contexts and have different defaults for each.



I have broken up the comments about CGI into several sections and
replied to each individually.

>  > Too late, IMHO. CGI is the past. Servlets and server-side scripting
>>  languages are the way to go; or at the very least some kind of server
>>  process, accessed directly from the web-server. (We are talking at
>>  least 3-tier, in that case.)
>
>CGI as a web technology would be waaaay too late now.

As someone who is actively engaged in e-commerce on a serious scale, I
beg to differ.  While I agree that CGI is likely to be phased out
eventually, I'd put the the timescale in decades.  The alternative
solutions are mostly very immature and have real scalability issues.


>  And I'm not sure why
>anyone would even want to do server-side scripting in pop11.

I have found that server-side scripting in pop11 is sometimes the preferred
solution for reasons of productivity, efficiency, and reliability.
[But to make sense of this question and answer you need to be explicit
about the alternatives you considered.  In the organization I work with,
we make use of mod_perl, PHP, CGI, and java servlets routinely.  And
I still find best practice use for Poplog.]


>Although for efficiency reasons you'd be better off implementing it as a
>separate entity which served requests from the webserver.

This is a mild over-generalization.  While generally true, sometimes
the most efficient solution is a CGI - and for a very large web site with
lots of functionality such as the one I work on, this has proved to be
the case.  [Measured against mod_perl, PHP, fCGI, and Java servlets as a
baseline.  Roughly speaking, they all suffer from complex store
management issues.]


>  (Remind me: does
>poplog make much use of multi-threading? Simple multi-threading extensions
>would be a really neat addition if not.)

It does not have pre-emptive threads as such, it has cooperating
ones called (bizarrely) processes.  Unfortunately they suffer from
a serious bug (type-3 variables are not copied) and so are only
suitable for very experienced programmers.  In addition, a great
deal of library code has been "optimised" and made unsafe to with
processes.  [Further details on request.]

Steve