::scr usability, languages and apis

[simon wistow]

On Thu, Nov 15, 2001 at 06:31:18PM -0000, Simon Kinahan said:
> Your examples above are good examples of this: the second class for each
> thing ends in "-able", which is a sure sign of an interface.

So veering wildly back to my (semi) original point - what makes a language
good to program. Ignoring 'power' for the moment are natural languages better
than ones which constrain you? Is OO a better paradigm than procedural?


Perl lets you do :

do { something } unless ($condition);

Java makes you do :


if (!$condition)
{
	something;
}


is it better to say 

$object.grow();

rather than 

grow ($object);


Should a language try and be 'useable' or is that just introducing a layer of
complexity in the compiler that's unnecessary and generally making it
difficult to maintain stuff?


On a final, similar note, from http://www.jwz.org/doc/worse-is-better.html

"Two famous people, one from MIT and another from Berkeley (but working on
Unix) once met to discuss operating system issues. The person from MIT was
knowledgeable about ITS (the MIT AI Lab operating system) and had been reading
the Unix sources. He was interested in how Unix solved the PC loser-ing
problem. The PC loser-ing problem occurs when a user program invokes a system
routine to perform a lengthy operation that might have significant state, such
as IO buffers. If an interrupt occurs during the operation, the state of the
user program must be saved. Because the invocation of the system routine is
usually a single instruction, the PC of the user program does not adequately
capture the state of the process. The system routine must either back out or
press forward. The right thing is to back out and restore the user program PC
to the instruction that invoked the system routine so that resumption of the
user program after the interrupt, for example, re-enters the system routine.
It is called ``PC loser-ing'' because the PC is being coerced into ``loser
mode,'' where ``loser'' is the affectionate name for ``user'' at MIT.

The MIT guy did not see any code that handled this case and asked the New
Jersey guy how the problem was handled. The New Jersey guy said that the Unix
folks were aware of the problem, but the solution was for the system routine
to always finish, but sometimes an error code would be returned that signaled
that the system routine had failed to complete its action. A correct user
program, then, had to check the error code to determine whether to simply try
the system routine again. The MIT guy did not like this solution because it
was not the right thing.

The New Jersey guy said that the Unix solution was right because the design
philosophy of Unix was simplicity and that the right thing was too complex.
Besides, programmers could easily insert this extra test and loop. The MIT guy
pointed out that the implementation was simple but the interface to the
functionality was complex. The New Jersey guy said that the right tradeoff has
been selected in Unix-namely, implementation simplicity was more important
than interface simplicity.

The MIT guy then muttered that sometimes it takes a tough man to make a tender
chicken, but the New Jersey guy didn't understand (I'm not sure I do either)."





-- 
:  everything after here is irrelevant