[ale] On Programming and Programming Langauges

[Pat Regan]

On Fri, 17 Sep 2010 11:37:32 -0400
"Michael B. Trausch" <mike at trausch.us> wrote:

> I agree.  There are merits to every system.  One thing that I think is
> that any program is best written in small, human-brain-sized building
> blocks.  This is even more important when it comes to languages like
> Python or PHP, where implicit type coercions can be easily found.  At
> least for Python, it is nice that the expression:
> 
>   2 + 'x'
> 
> is invalid.  Contrast this to PHP, where it is not:
> 
> └─(11:33:%)── php   
> <?php echo 2 + 'x'; ?>
> 2
> 
> In JavaScript, I think the result would be the string "2x", but I
> can't remember for sure.  No matter, what, the bugs that can result
> from this whole thing are sometimes very nasty and hard to track
> down, especially if you have a whole large program that doesn't
> verify anything... you get that sort of verification "for free" in
> languages where you don't have implicit conversion.

I think the Perl style makes the most sense.  If I want to add numbers
I use the mathematical operator.  If I want to concatenate "things" I
use the concatenation operator.  I don't care if one of the things I am
concatenating is a string and the other is a float, I just want one
appended to the other.

You don't get that verification "for free."  You pay for it every time
you assign a very specific data type to a variable, every time you have
to implicitly cast a variable, and every time you have to call a
conversion function like atoi() to make a variable fit.

The extra verbosity is far from free.  It takes longer to write and
makes things harder to read.

> One other thing that I really like, but rarely find, is the ability to
> create restricted type domains.  For example, in Pascal, you can
> declare a variable that holds an integer value but only the values 1,
> 2, 3.  Or something along those lines.  You can then never assign a
> variable of that type of a general-purpose integer; that is a type
> error.  Oh, boy, is that nice.  Even two differently named types that

You can get a lot of that (possibly all of it) from Perl's Moose object
system.  Moose leaves you free to restrict your variables as tightly as
you like or leave them wide open.

Traits/Roles are a feature that I would sorely miss since I started
using them.

> have the same range aren't considered to be compatible for the
> purposes of the type system, you have to manually force a conversion
> between them.  That is something that I wish more modern languages
> would do, so that if you have two variables (of type empl_type_t and
> mgr_type_t, for example that have the same range of values) you can't
> comingle them.  While it would not be a programming error to do so,
> it would be a semantic error, and it's nice to have a programming
> langauge which could catch such a semantic error.

It is interesting that you don't think empl_type_t and mgr_type_t
aren't both very ugly things to type :)

A manager should be an employee.  I should be able to drop a manager
object in anywhere I can drop in an employee.  The opposite isn't
always true.  In a modern language that would have to be a runtime
error.  The compiler may not have any way to know that you pulled an
employee out of your object store at runtime instead of a manager.

You really should kick the tires on a modern object system like Moose.

Pat