Tony Payne wrote:
> The ability to have strong-typing (I don't trust Junior Engineers to get it
> right and I don't have time to check every line of code they write)
No. No no no no. This approach is fundamentally wrong. Bad programmers
can write bad code in *any* language. Your solution is to either pick
another language (preferably one with a BSDM flavour), hire better
engineers or train the ones you have so that they don't. Don't blame
perl for your development problems, and don't expect it to fix them
either. Remember the old adage 'A poor workman always blames his
tools...'
> Strong support for OO (including the ability to have compile-time method
> lookups)
Bit difficult when polymorphism enters the picture - I guess this is
more a request for intelligent optimisation, although I suspect an
easier fix is to make the overhead of calling a method cheap enough that
nobody notices the difference between that and a non-polymorphic call.
> Threading constructs built into the language
The majority of perl programs won't be threaded - beware of making
simple things harder.
> Binary compilation
Agreed - In fact I'd settle for just this on its own ;-)
> And many others
> None of these would force us to make Perl disgusting to the quick-n-dirty
> lovers, but they should by all means be available to those of us who want to
> do real work in the language.
I do real work in perl5 as it stands - I can't think that the language
has ever prevented me from doing what I wanted.
> One of the ideas I've heard mentioned that I really liked was to have only
> one kind of variable: a scalar. All the other types could be accessed via
> references. It also allows us to get rid of the $ symbol except for
> interpolation.
References to... err... hashes and arrays? How does that constitute an
improvement? Personally I like all the line noise characters, to
paraphrase Slartybartfast, I think they give perl a lovely baroque
feel...
Alan Burlison
