Functional programming

[BartC]

"Steven D'Aprano" <steve at pearwood.info> wrote in message
news:53159540$0$2923$c3e8da3$76491128 at news.astraweb.com...

> It's that "explicitly" part that doesn't follow. Having to manage types
> is the most tedious, boring, annoying, *unproductive* part of languages
> like Java, C and Pascal. Almost always, you're telling the compiler stuff
> that it can work out for itself.

Isn't creating classes in Python similar to creating types elsewhere?

> In the same way that managing jumps for GOTO has been automated with for
> loops, while, etc., and managing memory has been automated, there's no
> good reason not to allow the compiler to manage types. Dynamically typed
> languages like Python do so at runtime. Type inference simply allows
> statically typed languages to do the same only at compile time.

Eliminating 'goto' is simple code-generation logic; type inference is more
of an art.

But declaring variables is not just about specifying a type; it registers
the name too so that misspelled names can be picked up very early rather
than at runtime (and that's if you're lucky).

> # Yes
> [1, 3, 4, 2, 5, 9]
> (1, "hello", None, 3.5)
>
> # No
> [1, "hello", None, 3.5]
>
>
> That is, lists are for collections of data of arbitrary length, tuples
> are for records or structs with dedicated fields.
>
> That convention is a bit weaker these days than it used to be. Tuples now
> have list-like methods, and we have namedtuple for record/struct-like
> objects with named fields.

(Aren't tuples immutable? They wouldn't work well for records then, because 
it would be impossible to change a field of a record.)

-- 
Bartc