>; (defun bred1 (x) (+ (car x) x))
>; (defun bred2 (x) (+ (car x) (cdr x)) %% впрочем, это может быть корректным для cons-пары из двух чисел
>;

Prelude> x <- return 1 -- вместо x=1
Prelude> twice <- return $ \x -> x*2 -- вместо twice x = x*2

gleb@gleb:~/src/crap> guile
guile> (define (avg x y) (+ x y)) ; черт, забыл поделить на 2!
guile> (define (foo x y u v) (+ (avg x y) (avg u v)))
guile> (foo 1 2 3 4)
10
guile> (define (avg x y) (/ (+ x y) 2))
guile> (foo 1 2 3 4)
5.0

К>А некоторые очень любят REPL, а его на статике врядли получишь

(defun bred1 (x) (+ (car x) x))
(defun bred2 (x) (+ (car x) (cdr x)) %% впрочем, это может быть корректным для cons-пары из двух чисел

GZ>>Но частично оно ведь может доказать неправильность программы?

FR>>>Питон и Руби точно не проигрывают по выразительности Эрлангу, разве для некторых специфичных задач, в более общих задачах эрланг сам им уступает. Nemerle конечно по выразительности во многом лучше, но по краткости до J ему как пешком до пекина

GZ>>Занятно. Это ты доказал утверждение Влада.

def fib(n):
    """Fibonachi series less than n"""
    a, b = 0, 1
    while b < n:
        print b
        a, b = b, a+b

fib(2000)
fib("2000")

GZ>>>>>>Но частично оно ведь может доказать неправильность программы?

FR>В программировании куда ни ткни везде есть потенциальные источники багов

FR>Нет. С классами не вижу разницы. Большинство современных динамических языков подерживают высокоуровневые примитивы такие как кортежи, списки, словари, поэтому часто то что для статики (мейнстримной ) требует конструирования достаточно сложных структур данных решается встроенными в динамический язык средствами.

def print_name(name,surname): # понятно, что скорее всего name и surname - это строки
 ...
 
def post_mail(address,message_body,pop3_server): # непонятно в каком формате address, body и server
    ...                                               
    # то есть конечно наверное где-то эти структуры описаны, но какие конкретно сразу непонятно

Advocates of strongly typed languages such as ML and Haskell have suggested that almost all bugs can be considered type errors, if the types used in a program are sufficiently well declared by the programmer or inferred by the compiler

int ComputeTime(int hours, int minutes, int seconds)
{
    return ((hours*60 + minutes)*60+seconds);
}

int main()
{
    int sec = ComputeTime(15,5,45);  // нормально
    int min = ComputeTime(15,5,45);  // перепутали что считает в минутах а не секундах - баг!
    int sec1 = ComputeTime(45,5,15); // перепутали местами часы и секунды - баг!
    int sec2 = ComputeTime(45,5,15); // при этом часы > 24 - но компилятор пропустил
    return 0;
}

#include <cassert>

typedef unsigned int uint;

template<uint Bound> class BoundedVal
{
        uint _val;
    public:        
        BoundedVal(uint val) : _val(val) { assert(_val < Bound); }
        uint operator()(){ return _val; }
};

namespace Time
{
    class Seconds : public BoundedVal<60>
    {
    public: Seconds(uint sec) : BoundedVal<60>(sec) {}
    };
    class Minutes : public BoundedVal<60>
    {
    public: Minutes(uint min) : BoundedVal<60>(min) {}
    };
  class Hours : public BoundedVal<24>
    {
    public: Hours(uint hrs) : BoundedVal<24>(hrs) {}
    };
}

Time::Seconds ComputeTime(Time::Hours hours, Time::Minutes minutes, Time::Seconds seconds)
{
    return Time::Seconds((hours()*60 + minutes())*60+seconds());
}

int main()
{
  using namespace Time;
  Seconds sec = ComputeTime( Hours(15), Minutes(5), Seconds(45) ); //ок
  //Minutes min = ComputeTime( Hours(15), Minutes(5), Seconds(45) ); //ошибка компиляции - несоответствие результата
  //Seconds sec1 = ComputeTime(Seconds(45),Minutes(5),Hours(15) ); // ошибка компиляции - несоответствие типов параметров
  Seconds sec2 = ComputeTime(Hours(45),Minutes(5),Seconds(15) ); // 1) вряд ли кто-то напишет Hours(45)
                                                                                                                             // 2) ошибка в рантайме - часы > 24.
  return 0;
}

GZ>>>>А это и есть полиморфизм. То бишь позднее связывание. Кроме того, есть еще делегаты, что практически аналогично. Может быть ты хотел сказать добавить новый метод?

4. Код на ДТЯП (динамически типизированные языки программирования) меньше и его легче держать в голове. Это откровенная лож. Но эта лож пожалуй чаще всего повторяется поклонниками ДТЯП. А чтобы эта лож не выглядила очень уж явно она всегда преподносится на фоне ЯП вроде С и С++ чья выразительность уже давно оставляет желать лучшего. Правда же заключается в том, что выразительность языка (а именно она определяет сколько кода нужно для выражения одной мысли) определяется не типом типизации, а количеством и качеством реализованных в них языковых конструкций (и/или средств расширения языка). Так ДТЯП чаще всего пиаримые на этом форуме — Питон и Руби существенно проигрывают как ДТ Эрлэнгу, так и СТ Nemerle-у просто потому, что в их арсенале нет таких мощных средств как алгебраические типы и сопоставление с образцом.

Так что, имхо, каждому своё, и, наверное, каждой задаче своё, т.к. нужная интерактивность может ею определяться.

1. могут быть не сильно нужны для конкретной задачи (хотя тут тоже не всё понятно, и это может определяться предпочтениями/предрассудками программиста/проектировщика)