Создатель языка Python Гвидо ван Россум прекратил работу над Dropbox

Создатель языка Python Гвидо ван Россум прекратил работу над Dropbox
05.11.2019
34084

Гвидо ван Россум, «великодушный пожизненный диктатор» Python, больше не работает в Dropbox. Разработчик не планирует оставаться в ИТ-сфере и уходит на пенсию. 

Работать в облачном файловом хранилище ван Россум начал шесть лет назад, покинув в декабре 2012 года компанию Google. Он занимался сразу нескольким направлениями, в том числе помогал наладить процесс тестирования и изменил подход команды к написанию кода, поставив во главу угла читаемость и простоту поддержки. 

Работа в Dropbox

В блоге Dropbox представители компании отмечают, что стартап в принципе не мог бы существовать без ван Россума, потому что весь код проекта написан на Python. Дрю Хьюстон, основатель облачного хранилища, рассказал, что выбрал этот язык программирования из-за того, что он интуитивен и красив. Во время разработки Dropbox соучредители стартапа вдохновились в том числе и дизайном Python.

Более тесное сотрудничество ван Россума с Хьюстоном началось в 2011 году, когда их познакомил общий знакомый. После этого основатель Python подготовил несколько докладов для сотрудников Dropbox, в которых объяснял свои взгляды на программирование.

Официально работником облачного сервиса ван Россум стал в 2013 году. Он сразу же столкнулся с проблемой: в компании разработчики использовали «умный» код, который был написан красиво и правильно, но понять его могли только сами авторы. Когда компания перестала быть небольшим стартапом и начала активно нанимать новых сотрудников, такая ситуация сильно осложняла поддержу кода и обучение новичков. 

«Если меня спросят, я отвечу, что лёгкий в поддержке код важнее, чем “умный”. Если бы я столкнулся с «умным» кодом, коротким и загадочным, и мне пришлось бы заниматься его поддержкой, я скорее всего переписал его», – рассказал ван Россум. 

Достижения в проекте

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

Ван Россум начал работу с командой тестировщиков. Благодаря его усилиям неработающие тесты были переписаны, а те, которые исправить было невозможно, удалены. Основатель Python создал набор внутренних инструментов, которые упрощали процесс тестирования, позволяли разработчикам найти источник проблем, а QA-команде помогали вовремя замечать тесты, которые не давали полезных результатов. 

Другое важное достижение ван Россума во время работы в Dropbox – создание mypy, системы проверки статических типов Python. Она была разработана совместно с Юккой Лехтосало, инженером Dropbox. Изначально он занимался этим проектом как исследовательской работой, однако встреча с ван Россумом помогла перевести инициативу на более качественный уровень. 

Заслуженный отдых

Гвидо ван Россум создал язык программирования Python в 1989 году, во время работы в Центре математики и информатики Амстердамского университета. За ним закрепилось звание «великодушного пожизненного диктатора»: он имел право принимать окончательные решения, касающиеся развития языка. 

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

Автор:
Аналитик

См. также

В Минцифры подготовили второй пакет мер поддержки ИТ-отрасли. В их числе – увеличение лимита доходов для самозанятых разработчиков с 2,4 млн рублей до 5 млн рублей в год.

31.03.2021    19005    user1015646    2       

2

Сервис для хранения репозиториев кода GitHub (принадлежит Microsoft) купил компанию npm. Она создала одноименный сервис для разработки на JavaScript – один из крупнейших в мире менеджеров пакетов для этого языка. 

20.03.2020    53208    user1015646    18       

3

На основании данных, опубликованных международной рекрутинговой компанией Hays в «Исследовании рынка труда России в 2019 году», уровень заработной платы ИТ-специалистов вырос в среднем на 5-10% за 2019 год. Рост зарплаты в этой сфере отмечался и в предыдущих годах, что указывает на уже сложившуюся тенденцию.

14.02.2020    39023    AnastasiaKl    95       

1

CodeCombat – платформа по программированию, которая в игровой форме учит детей кодить и разрабатывать приложения. Задачи в игровой форме можно решать на JavaScript или Python.

04.09.2019    22795    user1015646    14       

12

Комментарии

Инфостарт бот
1. пользователь 05.11.19 11:29
Сообщение было скрыто модератором.
...
2. herfis 05.11.19 11:52 Сейчас в теме
Что тут сказать. Человек-эпоха...
(1) С чего бы? Процесс развития языка давно отлажен и регламентирован. Гвидо просто оставлял за собой право последнего слова до некоторых пор.
3. Gureev 05.11.19 12:20 Сейчас в теме
Фирме 1С сильно не хватает своего Гвидо...
zqzq; protexprotex; maxopik2; Boyborodin; frkbvfnjh; Darklight; +6 Ответить
4. Darklight 05.11.19 12:51 Сейчас в теме
Python - язык неплохой, но отсутствие явно формализованных блоков кода - меня очень и очень сильно смущает!
Очень не нравится, что внутри методов объекта для обращения к самому объекту нужно всегда использовать посредника - первый аргумент функции (по принятому соглашению, называемый "self"); хорошо хоть не надо его туда передавать в месте вызова метода у самого объекта.
Ну и система декораторов в python далека от идеальной (и больше тяготеет к реализации оной в Java, а мне больше нравятся атрибуты в C#; но всё равно, эти декораторы куда мощнее - чем тупые ограниченные аннотации в 1С8).

А в остальном - для скриптовых языков неплохой вариант - вроде даже компания 1С в своём продукте (вероятно "1С: Сценарное тестирование" но точно уже не помню) хотела использовать язык Python как язык сценариев (уже не знаю как в итоге вышло).
Да и ВК для 1С есть, позволяющие запускать Python скрипты.

Но, на мой взгляд, как язык учетных систем и бизнес процессов будущего - Python не лучший выбор (но и не худший) - тут нужен ещё более простой, более интеллектуальный (самостоятельно а-ка "смарт"), более декларативный и более универсальный язык - таково моё мнение!
Несмотря на это Python - активно применяется в системах машинного обучения, и на web-серверах.

Но если сравнивать Python и 1С - Python конечно на голову 1С превосходит... а с поддержкой легкого подключения библиотек на других языках (в частности на Си), и с возможностью компилирования в LLVM - аж "на три головы" Python будет круче, чем язык платформы 1С: Предприятие 8 :-]

Но языки Scala, Kotlin, C#, Rust лично мне нравятся гораздо больше! Как семантически, так и по встроенным библиотекам и возможным паттернам применения
5. herfis 05.11.19 14:17 Сейчас в теме
(4) Это вкусовщина. Конек питона - лаконичность и одновременно выразительность. К отсутствию операторных скобок можно быстро привыкнуть. Идея использовать форматирование вместо операторных скобок - как по мне, гениальна и убивает трех зайцев одним выстрелом.
Использование посредника - явно разграничивает пространства имен. Мне очень не нравится что в 1С такого нет в контексте УФ. Если бы обращение к реквизитам формы шло через посредника а не напрямую, это бы страховало от конфликтов и добавляло бы ясности в код.
В питоне не сделали детских ошибок JS и сразу заложили сильную типизацию.
Так что такое... Как по мне, в качестве универсального скриптового языка питон ближе к идеалу чем все остальное. И рынок голосует за это мнение сложившимися практиками.
Куда можно еще проще и универсальнее - я не очень понимаю. Количество "магии" в питоне, как по мне, отмерено довольно разумно. А добавлять интеллектуальности и декларативности не терпя ущерба в простоте и универсальности - невозможно.
Сравнивать же между собой языки с динамической и статической типизацией - это сравнивать теплое с мягким.
7. Darklight 05.11.19 15:37 Сейчас в теме
(5)Отношение к языкам - всегда бесовщина - кто-то прётся от С++, кто-то фанатеет от ObjectiveC, кто-то без ума от JavaScript, чёй-то разум пленил Visual Basic.... у всех языков есть свои плюсы и недостатки в дизайне - и они всем нравятся/не нравятся по-разному. Поэтому я сразу написал - что это только моё мнение и я его не навязываю.

Лично против того чтобы формат написания текста кода влиял на его логику - на логику должны влиять только синтаксические конструкции (и ключевых слов должно быть как можно меньше)! А в идеале - эти синтаксические конструкции должны чётко, легок и однозначно разделять блоки кода. А как программист будет размещать сами инструкции - это его личное дело - главное, чтобы код был читаемым (а IDE должна помогать ему соблюдать подходящее ему форматирование - современные IDE от известных производителей с этим отлично и ненавязчиво справляются и настраиваются).

По поводу посредника "Self" - это бред и унылое наследие некоторого неудачного дизайна других ООП языков. Но ладно, если бы членам собственного экземпляра объекта внутри метода нужно было бы обращаться через встроенную инструкцию "Self" (на в Java или C#, и многих других языках можно обращаться к своим членам через неявно присутствующую переменную "this", хоть и можно её опускать, как и в 1С - тоже в формах или модулях объектах можно использовать "ЭтаФорма" и/или "ЭтотОбъект"). Но нет - эту переменную нужно явно (и формально под любым именем) указывать первым аргументом такого метода. Некрасиво, неудобно, архаично!

Да и не вижу я проблем с неявным обращением к членам как в формах и модулях объектов 1С. Вся проблем тут в другом:
1. В наличии неявного определения переменных (простым присвоением, без ключевых слов)
2. В отсутствие подсказок со стороны IDE - когда локальная переменная (метода) переопределяет имя одноимённой переменной более высокого контекста (аргумента функции, члена класса - он же формы).

Другие языки так сильно не страдают от наличия неявного this - как 1С с их неявными переменными!

Ну а в УФ как раз разделили контекст объекта (вынеся его в реквизит - чаще всего имеющий имя "Объект" или от "Отчет"), к членом которого можно обращаться только явно через указание этого имени. Это решение вполне оправдано, ведь форма - это не есть этот объект - это лишь член этого объекта, имеющий (но не обязательно) встроенную ссылку на владельца.


Сильная типизация в Python появилась, вроде бы, только с революционной версии Python 3, да и реализована кривенько - через громоздкие конструкции декораторов! И это совсем не статическая типизация - что, впрочем, для скриптового языка не требуется.
Более универсально и красиво типизация, реализована в Scala (несмотря на то, что Scala - это статический типизированный язык - там есть описания общих типов, от которых производятся все другие и их можно задавать как типы членов - получается динамическая типизация; ну а дженерики это всё отлично расширяют, когда о конкретных типах при определении члена или типа можно не думать). Так вот, в Scala для таких обобщённых типов есть прекрасный механизм - статического частичного ограничения (верхнее ограничение типа и нижнее ограничение типа) когда более общее определение типа по месту его использования можно конкретизировать другими - типом, потребовав чтобы конкретный класс был, например, от него производным, или наоборот.
Даже можно создавать составные типы - которые могут принимать значения только заданных типов (как составные типы в реквизитах 1С).

А по поводу достижения большей универсальности и интеллектуальности - я имею в виду повышение уровня абстракции, унификации и декларативности. Кода язык становится больше описательным для списка действий которые нужно сделать, а компилятор сам решает - как это сделать наиболее эффективным способом (включая возможность распараллеливания). Соответственно допустимые действия между разными объектами - унифицируются друг относительно друга (статически или "динамически" - перед выполнением - вернее компиляцией по заданным общим или частным правилами унификации).
А типы данных "динамически" модифицируются по мере надобности (опять же, при компиляции).
И всё оптимизируется интеллектуальным компилятором.
Более декларативное описание алгоритма даёт больше ясности в его понимании, и даёт больше возможностей среды исполнения к его оптимизации. Простой пример - язык SQL, или LINQ.

Своё виденье такого языка я как-нибудь тут опишу более детально.

А насчёт падения в универсальности и гибкости - как раз наоборот - она должна повышаться. Всё что не оптимально сделать на самом языке - как и у Python - должно реализовываться в виде подключаемых библиотек и просто вызываться из данного языка как подпрограмма
6. herfis 05.11.19 14:31 Сейчас в теме
Если не путаю, то this в java реализован точно также, как пресловутый self. Только параметр передается в функцию неявно.
Ну а философия Гвидо - "явное лучше неявного" :)

Оставьте свое сообщение