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

05.11.2019      33875

Гвидо ван Россум, «великодушный пожизненный диктатор» 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    18935    user1015646    2       

2

Новость GitHub Языки программирования

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

20.03.2020    53001    user1015646    18       

3

Новость Образование Цифровая экономика Языки программирования

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

14.02.2020    38897    AnastasiaKl    95       

1

Новость Образование Языки программирования

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

04.09.2019    22587    user1015646    14       

12
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. пользователь 05.11.19 11:29
Сообщение было скрыто модератором.
...
2. herfis 513 05.11.19 11:52 Сейчас в теме
Что тут сказать. Человек-эпоха...
(1) С чего бы? Процесс развития языка давно отлажен и регламентирован. Гвидо просто оставлял за собой право последнего слова до некоторых пор.
3. Gureev 05.11.19 12:20 Сейчас в теме
Фирме 1С сильно не хватает своего Гвидо...
zqzq; protexprotex; maxopik2; Boyborodin; frkbvfnjh; Darklight; +6 Ответить
4. Darklight 32 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 513 05.11.19 14:17 Сейчас в теме
(4) Это вкусовщина. Конек питона - лаконичность и одновременно выразительность. К отсутствию операторных скобок можно быстро привыкнуть. Идея использовать форматирование вместо операторных скобок - как по мне, гениальна и убивает трех зайцев одним выстрелом.
Использование посредника - явно разграничивает пространства имен. Мне очень не нравится что в 1С такого нет в контексте УФ. Если бы обращение к реквизитам формы шло через посредника а не напрямую, это бы страховало от конфликтов и добавляло бы ясности в код.
В питоне не сделали детских ошибок JS и сразу заложили сильную типизацию.
Так что такое... Как по мне, в качестве универсального скриптового языка питон ближе к идеалу чем все остальное. И рынок голосует за это мнение сложившимися практиками.
Куда можно еще проще и универсальнее - я не очень понимаю. Количество "магии" в питоне, как по мне, отмерено довольно разумно. А добавлять интеллектуальности и декларативности не терпя ущерба в простоте и универсальности - невозможно.
Сравнивать же между собой языки с динамической и статической типизацией - это сравнивать теплое с мягким.
7. Darklight 32 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 513 05.11.19 14:31 Сейчас в теме
Если не путаю, то this в java реализован точно также, как пресловутый self. Только параметр передается в функцию неявно.
Ну а философия Гвидо - "явное лучше неявного" :)
Оставьте свое сообщение