Трудно однозначно сказать. Просто подтверждено экспериментально. Либ больше? Да нет, скорее они лучше продуманы. Меньше на клаве набирать? Для _абсолютно_ такого же алгоритма - скорее нет. Для _абсолютно_ такого же, это важно. Питон здорово сокращает количество текста за счёт ненужности писать end или закрывающую фигурную скобку. С другой стороны, этот end или фигурную скобку тебе нормальный редактор или IDE поставит автоматически.Зато Питон требует явный return. И явный this, что не только добавляет текста, ещё и усложняет рефакторинг. Вот, например, есть у меня несколько функций, который друг друга вызывают. И я решил их оформить в класс. В Руби я просто допишу "class MyClass ... end" вокруг тех функций. И проиндетирую. Да, и мне редактор поможет проиндентировать, потому что парсинг кода не зависит от whitespace. А в Питоне мне мучительно придётся дописывать для каждой функции this. И не только в заголовках функций, но и в их вызовах. А если что-то пропущу - то узнаю от это только в рантайме. Или, ну ладно, будем считать что мне редаткор подстветит. Питон - наверное, единственный язык, который требует явный this.
Возвращаясь к "_абсолютно_ такому же алгоритму". _Абсолютно_ такой же алгоритм как на Питоне, программист на Руби вряд ли напишет, а скорее всего напишет проще. Просто в Руби как-то всё продуманней. Гармоничная связка ФП и ООП. А в Питоне ФП загнано подальше, в угоду list/dict comprehension. При этом list/dict comprehension как таковое - это не плохо, это очень даже хороший инструмент, когда используется в рамках своей области применения. Но он не подразумевает chaining и вложенность. Если вложить один list comprehension в другой - будет очень нечитабельно. А если each block в другой each block - нормально.
Ну и напоследок история одного маленького эксперимента. Основано на реальных событиях, как говорится. Мне периодически нужно складывать время из временных отрезков. Например, из входных данных
9:00-13:30, 14:30 - 16:00, 16:30-19:00
должно получиться 8.5.
Я написал для этого однострочник на Руби:
ruby -rtime -e 'p STDIN.read.chomp.split(",").map { |period| a=period.split("-"); Time.parse(a[1]) - Time.parse(a[0]) }.sum / 3600
Потом решил, негоже его хранить в истории шелла, надо записать в файл и разбить на строки:
require 'time'
p STDIN.read.chomp.split(",").map { |period|
start, finish = period.split("-", 2)
Time.parse(finish) - Time.parse(start)
}.sum / 3600
Потом подумал, надо написать то же самое на Питон и сравнить, наверное получится так же легко, быстро и непринуждённо. Получилось вот такое вот:
import sys
from datetime import datetime, date, time, timedelta
def calc_duration(period):
start_str, finish_str = period.split("-", 1)
start_time = time.fromisoformat(start_str.strip())
finish_time = time.fromisoformat(finish_str.strip())
return datetime.combine(date.min, finish_time) - datetime.combine(date.min, start_time)
periods = sys.stdin.read().rstrip().split(',')
durations = map(calc_duration, periods)
print(sum(durations, timedelta()))
Для варианта на Питоне нужен минимум Python 3.7. В более ранних Питонах не было функции datetime.time.fromisoformat(). То есть пару лет назад, до Python 3.7, мне ещё пришлось бы и парсингом повозиться. И ещё вариант на Питоне не поддерживает часы в одно разряде, например "9:30", надо добавлять второй разряд, "09:30". Ну да ладно, добавим.
Можно ли написать вариант на Питоне попроще? Попробуйте, с удовольствием посмотрю.
Почему код на Руби оказался короче и яснее? Я вижу здесь лучшую поддержку chaining и ФП, более удобные функции стандартной библиотеки. Будет ли так и для других задач? Для прям абсолютно всех задач - вряд ли, но по моему опыту, в большинстве случаев код на Руби пишется быстрее, проще и непринуждёнее.
