[OT] We need a language

[Alaric B Snell]

James Michael DuPont wrote:
> --- PB <schizophonic@tiscali.it> wrote:
> 
>>"We need a language that lets us scribble and smudge and smear,
>>not a language where you have to sit with a teacup of types
>>balanced on your knee and make polite conversation with a
>>strict old aunt of a compiler."
>>
>>Paul Graham, "Hackers and painters".
> 
> 
> here here ! Finally a word of sensibility.

Oh, no!

> "True greatness is measured by how much freedom you give to others, not
> by how much you can coerce others to do what you want. "
> Larry Wall "Perl, the first postmodern computer language"
> http://www.wall.org/~larry/pm.html

Well, this is a fine quote, but quotes alone do not truth make.

"All propaganda must be so popular and on such an intellectual level, 
that even the most stupid of those toward whom it is directed will 
understand it... Through clever and constant application of propaganda, 
people can be made to see paradise as hell, and also the other way 
around, to consider the most wretched sort of life as paradise."

  - Adolf Hitler.
 
http://centre.telemanage.ca/quotes.nsf/quotes/c107c9d29f8faf5085256969005cee50

> "You can write beautiful Perl, ugly Perl, baby Perl, strict Perl.
> There's much more opportunity for distinctive style than you get in
> other languages. You can write it to be clean and maintainable or you
> can write it to be silly or sweet. You can write poetry in it.
> Obviously, from the perspective of a dedicated programmer who needs to
> create bug-free mission-critical code, this scores no points other than
> that it is a joy to code in."
> Yoz Grahames : Perl is Internet Yiddish
> http://cheerleader.yoz.com/archives/000019.html

Pay attention to Yoz's last sentence in that quote! Yoz himself at a 
party a few years back suggested that I look into Python - what a small 
world ;-)

Now, I see a lot of fighting between the strict typing people and the 
non-strict typing people; it's part of a large battle between "rigorous 
careful engineering" and "throw it together". This battle has come up in 
debates about schema languages on xml-dev, and in things like the 
Extreme Programming movement.

The engineer's arguments can include:

1) Software is important; just because people have got used to it being 
unreliable doesn't mean it should be. We ought to be pushing for 
programmers to do things the hard way and take time and effort to 
declare their intentions at every step, just as when electronic 
circuitry, bridges, cars, etc. are designed, in order to try to attain 
the levels of reliability seen in those other fields

2) People who want to just hack at code until it works are being stupid 
and lazy. Somebody intelligent enough to understand the big picture 
needs to do the requirements capture and design work to try to produce a 
structured roadmap for the design and implementation of the modules, 
because otherwise, costly mistakes will come up when people have to 
rewrite code because it turns out to be unsuitable in the long run, or 
when the resulting product has subtle bugs due to unforseen interactions 
between modules, or less subtle bugs caused by exceptional cases not 
being handled properly due to the lack of formally declared exceptions, 
type errors, etc.

3) It's very hard to split a large programming job up between teams of 
programmers without doing design work to begin with, to identify the 
seams along which the project can be split - and to define the 
interfaces so the teams on each side of the split can both get to work 
and expect their code to meet up when they start integrating.

4) Declaring everything isn't that hard. It doesn't really require much 
more thought - you know what type you intend a variable to be; you just 
need to take the time to write it down so that the compiler can check 
your intentions against your actions, and so that your intentions are 
documented in a human- and machine-processable form for others to see.

The thrower's arguments can include:

1) Programming isn't really like building bridges and cars - it's more 
like art. Trying to approach it like an engineer is just a waste of 
time; instead, you should take your development environment and build up 
from the basic tools provided towards a system that should perform the 
required task.

2) It's just not worth the effort of trying to plan everything in 
advance - the stakeholders will keep changing their minds; by making 
your software evolve towards a solution, it's easier to change the 
direction of that evolution in mid-stride, and to continue evolution 
after the software is officially 'finished'

3) People who want to declare and design and document everything are 
boring people who wear suits and have no sex lives. They were the 
unpopular kids at school and are trying to take it out on the world by 
forcing stupid rules on everyone - or variations on the theme.

4) Software engineering is boring - hacking Perl is fun!

5) <irrelevant comparison of software engineering with some metaphore 
for state or parental control, or enjoying being restrained - Code 
Police, B&D language, strict catholic aunt, etc>

6) Look! Hello World in Perl:

print "Hello World"

Hello World in Java:

public abstract class HelloWorld {
	public static void main (String[] args) {
		System.out.println ("Hello, world!");
	}
}

...ergo, Java wastes your time with irrelevant declarations, while Perl 
just lets you say what you want.

7) In C, you can't write polymorphic functions. In Java, anything 
polymorphic needs to use the type "Object" and then do runtime casts 
back to more precise types when necessary - which is just what Perl does 
anyway. Systems of declaring facts about programs are never expressive 
enough to cover everything, or even a generally useful subset; you often 
need to escape them and then you need loads of type casting / calling 
methods via reflection / etc.

8) Sometimes you're not writing a huge multi-person software project to 
control nuclear missiles - perhaps I'm trying to throw together a quick 
script to scan my mail folders for spam. Why must I be tripping over all 
this type checking and stuff when I will only run this script once, and 
if it doesn't work I'll see and fix it?

Now, to be fair, I think there are points on both sides. My take is:

1) Java, and languages like it, can be unweildy because they go for a 
simple model of the world - it's all classes, etc - and don't provide 
much syntactic sugar. I mean, given a macro system to express common 
structures more concisely, Hello World could become:

application {
	System.out.println ("Hello, World!");
}

In other words, it's possible to just improve the awkward and unweildy 
parts of using insufficiently expressive declaration languages to make 
it easier to declare things, rather than throwing out declaration 
entirely. For example, the ML / Haskell family of languages use a type 
system where polymorphic functions need to have their argument types 
declared - but you can declare that what it returns will be the same 
type as the second argument, rather than needing to fall back on 
"Object" as in Java and expect the user to cast back return values at 
run time.

2) Regarding the fact that declarations are never expressive enough - 
well, I think they can be made so... non-deterministic typing, anyone? 
I'd like to be able to declare a type as something like "Subtypes of X 
with constraint Y" where Y is an arbitrary function mapping an instance 
of X to boolean, if I want to. The compiler will sometimes have to defer 
typing decisions to runtime - that's fine, as long as it does as much as 
it can at compile time.

3) It can be made easier to escape the type system when needed. For 
example, when writing loosely-bound RPC software (loose binding meaning 
that it will handle interface evolution and forking and so on elegantly).

4) Sensible Defaults. Eg, make type declarations optional, and use a 
type inferencer if they're missing. That way, you can hammer out quick 
code without needing to worry about declaring stuff, and when you try to 
run it you'll be told if anything you've done violates the Sensible 
Defaults or if Sensible Defaults couldn't be inferred, so you can go 
back and guide the system towards the correct behaviour with declarations.

Fundamentally, I sit on the software engineer's side - we are here to 
write quality software, and static detection of potential bugs due to 
excess information supplied by the programmer is a real help. I do agree 
that declaring everything can be cumbersome, but I would suggest that we 
deal with this by improving the languages with more expressive type 
systems and Sensible Defaults and powerful macros for syntactic sugar, 
rather than promoting a culture of poorly-designed 'hacked together' 
software. I see a real danger in the counter-engineering movement (often 
spearheaded by Perl advocates with snappy quotes comparing Java to being 
tied up in leather); I think they're throwing the baby out with the 
bathwater and producing too much crap software.

> 
> Mike
> 

ABS