Larry Wall представил Perl 6

Если так писать, то язык практически не важен. В том же Modern Perl код очень приятно выглядит, не вызывая проблем с чтением/сопровождением. При этом, тип данных не теряется из виду, как в случае с питоном.

А написать str(4) == «4» не так уж сложно, зато не нужен новый оператор на каждый тип данных.

это ты хорошо сузил преобразования типов только до сравнений. Но в том же перле, например, когда нужно обрабатывать много разнородного текста, то заколебёшься в каждой операции приводить типы.

Но в том же перле, например, когда нужно обрабатывать много разнородного текста, то заколебёшься в каждой операции приводить типы.

Что тут приводить, если речь идет о тексте?

Если речь идет о «разнородных» данных, то для того, чтобы их можно было обрабатывать, нужно иметь общий интерфейс над ними. В пистоне поэтому и популярен так называемый duck typing.

тип данных не теряется из виду

О каких типах идёт речь? Строки, цифры и массивы? Но я использую ООП во все поля, мне примитивных типов мало. Да и, как я уже сказал, грамотное именование переменных даёт гораздо больше.

обрабатывать много разнородного текста, то заколебёшься в каждой операции приводить типы.

У меня никогда не было проблем с «заколёбыванием». Можно пример где «питон сосёт»? И что за есть «разнородный текст»?

О каких типах идёт речь?

стандартные типы данных языка и стандартные операции над ними. Отличается от языка к языку, но есть и базовые: строка, число, массив, хэш.

Да и, как я уже сказал, грамотное именование переменных даёт гораздо больше.

но меньше, чем если бы и само их описание подсказывало тип.

Можно пример где «питон сосёт»?

там же где и хацкель, приводил в треде пример уже, глянь. Ну еще вот Prerl. Помогите разобрать строку. (комментарий)

Ну еще вот Prerl. Помогите разобрать строку. (комментарий)

Да, именно поэтому perl RIP. Даже в питонах это делается быстро и читаемо.

Ну или у меня есть namedtuple, оттуда можно вытаскивать как по номеру, так по имени. В перле как?

покажи пример.

Даже в питонах это делается быстро и читаемо.

но я не покажу, да? :-P

покажи пример.

from collections import namedtuple
Point = namedtuple('Point', ('x', 'y'))
a = Point(1, 2)
print(a.x == a[0])  # True
print(a.y == a[1])  # True

но я не покажу, да? :-P

from collections import defaultdict

def parse_url(source='param1=value1&param2=value2&param3=value3&param1=value11&param1=value111'):
    result = defaultdict(list)
    for param in source.split('&'):
        name, value = param.split('=')
        result[name].append(value)
    return result

print(parse_url())  # defaultdict(<type 'list'>, {'param3': ['value3'], 'param2': ['value2'], 'param1' : ['value1', 'value11', 'value111']})

Сравни с тем writeonly, что там было. Можно записать и короче с list comprehensions, не спорю, но нафиг если страдает читабельность?

Я покажу. Только не повторяйте это дома.

d = {}
[d.__setitem__(key, d.get(key, []) + [value]) for key,value in [pair.split("=") for pair in s.split("&")]]

In: s = 'param1=value1&param2=value2&param3=value3&param1=value11&param1=value111'
In: d
Out: 
{'param1': ['value1', 'value11', 'value111'],
 'param2': ['value2'],
 'param3': ['value3']}

Сравни с тем writeonly, что там было.

Где?

$s = 'param1=value1&param2=value2&param3=value3&param1=value11&param1=value111';

for (split /&/, $s) {
    ($name, $value) = split /=/;
    push @{ $result{ $name } }, $value;
}

:-D

postman_ Красавчик :-P Повторять не буду, пример оказался слишком лёгкий.

($name, $value) = split /=/;

Вот откуда тут берется второй операнд? Неявные зависимости - самое омерзительное, что только можно придумать.

Вот откуда тут берется второй операнд?

из (split /&/, $s). Для каждого элемента, это же легко. Можно написать всё явно:

for my $pair (split /&/, $s) {
    ($name, $value) = split /=/, $pair;
    push @{ $result{ $name } }, $value;
}

Контексты и переменные по умолчанию - очень классная вещь, которая сокращает код:

while (<STDIN>) {
    # обрезать \r\n, если только это не комментарий или пустая строка
    chomp unless /^#/ or not length;
    
    /parse condition/   && do {}
    /another condition/ && do {}

    /between range/ ... /parse/ && do {}

    # и т.д.
}

# прибавить всем зарплату
s/\d+/\1+500/e for @{ $office{21} }; 
# или озаглавить улицы, добавить сокращение "ул."
s/^./\U\1/, s/^.*/ул. \1/ for @adresses;

удобно.

очень классная вещь, которая сокращает код

и делает его writeonly.

Контексты и переменные по умолчанию - очень классная вещь, которая сокращает код:

и срок жизни нервной системы

postman_ всегда есть выбор. Можно писать в стиле однострочников, можно в стиле Modern Perl.

И это плохо. Хорошо, когда выбора нет, и всех насильно заставляют писать более-менее адекватно.

Плохо или хорошо кому?

Давай так: Во-первых, для perl-кодеров это не проблема. Даже самый обфусцированный код (с стандартным модулем Deparse) вызовет кратковременную запинку. Тот же патч Бармина прекрасно парсится через Deparse, и не вызывает после этого никаких осложнений. Чтоб сразу распарсить его глазами :-D нужно иметь некоторый опыт. Если об этом не знать - понимаю твою позицию, брэйнфак.

Во-вторых: в отличие от питона каждый может располагать код так, как ему вздумается. Для perl-кодера не проблема: с помощью perl::tidy он выровняет код так, как нужно его глазам. Если об этом не знать - проблема.

Для меня хорошо - когда язык позволяет мне выбирать самому что использовать и как. Мне нужен не строгий учитель, а лояльный.

P.S. Люблю питон, с него начинал (после паскаля, конечно) :) P.P.S. Ссорь за простыню.

Для тебя все хорошо. Только разработка ПО обычно проводится командой, где у каждого свои идеалы. В масштабах опенсорса все становится совсем плохо.

Проблема не сводится к одному лишь синтаксису, посмотри на крестухов. Сомневаюсь, что какой-то deparse выручит тебя, если один предпочитает писать в ФП-стиле, а другой долбится в фабрики и визиторы.

Только разработка ПО обычно проводится командой, где у каждого свои идеалы. В масштабах опенсорса все становится совсем плохо.

Синтаксис не проблема, code style + чекер на коммиты. Человек может и не напрягаться, всё сделает автомат.

Сомневаюсь, что какой-то deparse выручит тебя, если один предпочитает писать в ФП-стиле, а другой долбится в фабрики и визиторы.

В каком языке эта проблема решена? В ассемблере?

До конца - ни в каком. Но это не значит, что с ней не надо бороться.

Лучше, имхо, бороться с конкретными случаями, чем с общими. И в общем, многополярный мир, по мне лучше однополярного. Пусть будут языки свободные, пусть будут топорные, и всё что между ними. Некоторые мои знакомые-непрограммисты ворчат: - Зачем столько языков? Лучше бы был один, лучший!

А я, например, не хочу один лучший. В одних случаях недостаток питона - его достоинство. В других - перла.

Да ты же поднял руку на прешвятые жаповеди Unix.

багахульник!!!

Ларри тоже советовал: используйте текст где это возможно, текст - это хорошо.