LINUX.ORG.RU

Гвидо Ван Россум уходит на пенсию

 


2

3

Создатель языка Python, последние шесть с половиной лет работавший в компании Dropbox, уходит на пенсию.

Эти 6,5 лет Гвидо работал над Python и развивал культуру разработки Dropbox, которая переживала стадию перехода от стартапа в крупную компанию: был ментором, наставлял разработчиков писать понятный код и покрывать его хорошими тестами. Он также составил план перевода кодовой базы на python3 и начал воплощать его в жизнь.

Также занимался развитием mypy — статического анализатора Python-кода, который был изначально разработан другим сотрудником Dropbox, нанятым Гвидо.

Помимо этого был активным участником движения за привлечение женщин в IT.

>>> Подробности

anonymous

Проверено: a1batross ()
Последнее исправление: Deleted (всего исправлений: 5)
Ответ на: комментарий от Deleted

Сидит там как сыч в игрушки свои играет. Лучше бы линфану помог :)

Хех. Я в этом не шарю. sK1 же ориентирован на печать, а я векторный редактор открываю только порисовать что-то, например, для openshot-а. И в основном это Inkscape (потому что интегрирован в openshot, и есть в репах).

К тому же, если и помогать, надо же выяснить как писать: со статической типизацией или динамической.

На мелких простых задачах понятно, что динамика проще. А если задача посложнее? Как проверить? Переписать sk1 на С++ или Inkskape на javascript? Это долго, скучно, и не понятно как оценить результат.

А Screeps — это отличный тест, можно написать так, написать иначе, и посмотреть где дальше продвинешься. Причём проверять быстро, весело, и наглядно.

И это хороший симулятор — заливка на сервер эквивалентна релизу в продакшн. А расстроенный клиент — дохлой колонии. То есть подход из screeps переносится и на другие проекты. Надо только найти хороший подход к разработке.

А вот с этим у меня и плохо. Динамика (т.е. JS) ­— это было весело и интересно, но отлов эксепшнов в рантайме бесит. Статика — это куча лишнего кода, и куча времени на изменение архитектуры вместо работы над самим решением. В целом на статике получилось продвинуться дальше, но достало — жуть, даже возвращаться к тому коду не хочется.

Надо ещё подход с тестами попробовать, придумать бы только, как тестить такой код... И найти бы язык, который проверяет полноту покрытия кода тестами.

anonymous
()
Ответ на: комментарий от anonymous

Надо ещё подход с тестами попробовать, придумать бы только, как тестить такой код… И найти бы язык, который проверяет полноту покрытия кода тестами.

Тебе для этого не нужен другой язык. Гугли test coverage tools для своего языка.

anonymous
()
Ответ на: комментарий от anonymous

придумать бы только, как тестить такой код

Надо ещё подход с тестами попробовать, придумать бы только, как тестить такой код... И найти бы язык, который проверяет полноту покрытия кода тестами.

почитай на adacore.com/books > EmbeddedSPARKandAda-web.pdf про тетрис на SPARK, может натолкнёт на какие-то мысли

anonymous
()
Ответ на: комментарий от anonymous

Тебе для этого не нужен другой язык. Гугли test coverage tools для своего языка.

Будто это так просто...

Мы в питонотеме, возьмём пример на питоне:

f = lambda x: 1 if x else garbage
g = lambda x: x or garbage

# tests
assert f(5) == 1
assert g(2) == 2

Переменная garbage нигде не объявлена, то есть вызов f(0) или g(0) упадёт, но тесты этот вариант не проверяют.

Посоветуй утилиту, которая покажет, что такие тесты не покрывают на 100% эти две функции.

Или переведи этот пример на свой любимый язык и найди утилиту для него.

anonymous
()
Ответ на: комментарий от anonymous

Test coverage меряется строками, бранчами и функциями. Тут покрыто 100% строк и 50% бранчей, все утилиты это показывают.

anonymous
()
Ответ на: комментарий от anonymous

Тут покрыто 100% строк и 50% бранчей, все утилиты это показывают.

«Все» — это, например, какие? «Имя, сестра!»

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.