Size: a a a

Compiler Development

2020 February 06

KR

K R in Compiler Development
И генерируют большое количество рабочих мест, конечно.
источник

МБ

Михаил Бахтерев in Compiler Development
K R
Питон, кстати, имеет крайне неочевидную семантику. И вообще непрост. Хотя и распеарен.

А устойчивость к ошибкам там потому, что делать с его помощью можно лишь пирамиды, а не ажурные конструкции.
Ну. Внутренние механизмы, может быть, не столь важны. А внешние таковы, что можно легко копипастнуть нечто, внести "творческие" искажения, и оно продолжит работать.

Про пирамиду не понятно. Можете пояснить?
источник

KR

K R in Compiler Development
Михаил Бахтерев
Ну. Внутренние механизмы, может быть, не столь важны. А внешние таковы, что можно легко копипастнуть нечто, внести "творческие" искажения, и оно продолжит работать.

Про пирамиду не понятно. Можете пояснить?
Очень быстрый рост количества кода от количества функций после выхода за границы оптимальной рабочей области П (небольших программ без особых ветвлений)
источник

KR

K R in Compiler Development
Там, где ветвлений мало, то есть, программа тестирует себя при одном прогоне, П очень хорош.
источник

DP

Dmitry Ponyatov in Compiler Development
питону не хватает опциональной "заплаточной" типизации которую можно применять местами (соответственно и автоматического вывода типов), рантайм-контроля на уровне ассертов по типам и значениям, и pattern machingа
источник

DP

Dmitry Ponyatov in Compiler Development
причем не сторонними средствами, а в ядре языка
источник

KR

K R in Compiler Development
Dmitry Ponyatov
причем не сторонними средствами, а в ядре языка
Во-первых, она есть.
источник

KR

K R in Compiler Development
Во-вторых, вы её примените, а потом окажется, что какие-нибудь math.sqrt и coollib.pow без type hints. И, в результате, вы опять складываете строки с числами в программе, в которой вы все сигнатуры описали.
источник

KR

K R in Compiler Development
А, в третьих, даже дурацкие методы, а-ля возвращения значений разных типов из одной функции, в определённых местах удобны и полезны.

Программирование очень разнообразно.
источник

KR

K R in Compiler Development
Это хороший язык в своей рабочей области. Просто его пихают куда не следует.
источник

KR

K R in Compiler Development
«Если в руках микроскоп, всё на свете кажется гвоздями»
источник

KR

K R in Compiler Development
Но интересно - когда доработают gradual typing, нужно будет сделать процесс «отлива в гранит» - фиксации типов библиотек. Чтобы компилятор ругался, если полностью типизированная функция использует нетипизированные библиотечные.

То есть, там нужна будет иерархия библиотек. Что ли?
источник

VK

Val Krylov in Compiler Development
Михаил Бахтерев
IMHO, это важный момент. Народ пишет на том, на чём писать быстрее. Есть же ещё биологический и социальный аспект во всей этой деятельности. Чем быстрее написал, тем больше шансов обойти конкурентов и забрать себе ресурсы. Жизнь - это вообще куча автокаталитических реакций: чем больше успеваем молекул в свой процесс включить, тем выше шансы что другие не разовьются. Поэтому, одним из свойств чудесного языка, должна быть скорость написания кода и скорость его изменения. А статический анализ в любом случае приложится. В случае Питона этот анализ превратился в неплохой такой бизнес.

Вопрос, поэтому, надо ставить так: можем ли мы сделать статический язык такой, на котором можно будет писать хотя бы с той же скоростью, что и на Питон? Лично я думаю, что это крайне проблематично, потому что у такого языка должны быть мощные средства абстрагирования, и люди будут проваливаться в интеллектуальные игры на уровне типов: типа, я круче, потому что у меня вот типы тут вычурнее и категорнее. Это не плохо, тоже своего рода социальная иерархия, но проблематично, потому что типы стираются в runtime, и никому они за пределами языкового сообщества не интересны. То есть, на языке-то, может быть, и будет писаться проще и быстрее, чем на Питоне, но социальная динамика будет такова, что библиотеки в итоге превратятся в гиперасбтрагированную систему, с которой будет весьма сложно начать быстро работать быстро. При чём, само абстрагирование станет целью, потому как люди хотят мерятся уровнем IQ, а это прекрасный метод.

Поэтому Питон с ЯваСкрипт и будут рулить. А оптимизации и стат. анализ будут завозить по мере необходимости. Линты для ЯваСкрипта, например, уже очень мощные. И, повторюсь, они формируют новый рынок, а это только способствует пропаганде языка.

В общем, как всегда, люди сами себе злобные чебурашки :)
На C# можно, с тех пор как завезли Roslyn (нормальный REPL) и кроссплатформу (.NET Core). Но у Python хороший задел библиотек, как начинавшихся в культурные времена Python 2, так и под современные ниши вроде ML, что тоже влияет.
источник

AK

Andrei Kurosh in Compiler Development
Михаил Бахтерев
IMHO, это важный момент. Народ пишет на том, на чём писать быстрее. Есть же ещё биологический и социальный аспект во всей этой деятельности. Чем быстрее написал, тем больше шансов обойти конкурентов и забрать себе ресурсы. Жизнь - это вообще куча автокаталитических реакций: чем больше успеваем молекул в свой процесс включить, тем выше шансы что другие не разовьются. Поэтому, одним из свойств чудесного языка, должна быть скорость написания кода и скорость его изменения. А статический анализ в любом случае приложится. В случае Питона этот анализ превратился в неплохой такой бизнес.

Вопрос, поэтому, надо ставить так: можем ли мы сделать статический язык такой, на котором можно будет писать хотя бы с той же скоростью, что и на Питон? Лично я думаю, что это крайне проблематично, потому что у такого языка должны быть мощные средства абстрагирования, и люди будут проваливаться в интеллектуальные игры на уровне типов: типа, я круче, потому что у меня вот типы тут вычурнее и категорнее. Это не плохо, тоже своего рода социальная иерархия, но проблематично, потому что типы стираются в runtime, и никому они за пределами языкового сообщества не интересны. То есть, на языке-то, может быть, и будет писаться проще и быстрее, чем на Питоне, но социальная динамика будет такова, что библиотеки в итоге превратятся в гиперасбтрагированную систему, с которой будет весьма сложно начать быстро работать быстро. При чём, само абстрагирование станет целью, потому как люди хотят мерятся уровнем IQ, а это прекрасный метод.

Поэтому Питон с ЯваСкрипт и будут рулить. А оптимизации и стат. анализ будут завозить по мере необходимости. Линты для ЯваСкрипта, например, уже очень мощные. И, повторюсь, они формируют новый рынок, а это только способствует пропаганде языка.

В общем, как всегда, люди сами себе злобные чебурашки :)
"Вопрос, поэтому, надо ставить так: можем ли мы сделать статический язык такой, на котором можно будет писать хотя бы с той же скоростью, что и на Питон?"

Без привязки к конкретным задачам этот вопрос не имеет смысла. Если брать сферические задачи в вакууме, типа "чистая функция, которая что-то считает", то практически любой современный язык справится. Если мы говорим про ML - Python скорее всего выигрывает, но не за счет динамизма языка, а за счет популярных библиотек. Если мы хотим мобильное приложение - тут Python со свистом просасывает статически типизированным Kotlin и Swift. Ну и так далее. А если учесть, что у конкретного человека всегда есть background и быстрее всего писать на том, что он лучше знает, точность сравнения вообще уходит под границу статистической погрешности
источник

AK

Andrei Kurosh in Compiler Development
Ну и да, согласен с @val_krylov по поводу C# - в современных версиях практически нет "трения" при работе с языком
источник

AT

Alexander Tchitchigin in Compiler Development
Andrei Kurosh
"Вопрос, поэтому, надо ставить так: можем ли мы сделать статический язык такой, на котором можно будет писать хотя бы с той же скоростью, что и на Питон?"

Без привязки к конкретным задачам этот вопрос не имеет смысла. Если брать сферические задачи в вакууме, типа "чистая функция, которая что-то считает", то практически любой современный язык справится. Если мы говорим про ML - Python скорее всего выигрывает, но не за счет динамизма языка, а за счет популярных библиотек. Если мы хотим мобильное приложение - тут Python со свистом просасывает статически типизированным Kotlin и Swift. Ну и так далее. А если учесть, что у конкретного человека всегда есть background и быстрее всего писать на том, что он лучше знает, точность сравнения вообще уходит под границу статистической погрешности
Python не так прост, как Вам кажется: https://kivy.org/ 😂
источник

FO

FORTRAN ONE LOVE in Compiler Development
Andrei Kurosh
"Вопрос, поэтому, надо ставить так: можем ли мы сделать статический язык такой, на котором можно будет писать хотя бы с той же скоростью, что и на Питон?"

Без привязки к конкретным задачам этот вопрос не имеет смысла. Если брать сферические задачи в вакууме, типа "чистая функция, которая что-то считает", то практически любой современный язык справится. Если мы говорим про ML - Python скорее всего выигрывает, но не за счет динамизма языка, а за счет популярных библиотек. Если мы хотим мобильное приложение - тут Python со свистом просасывает статически типизированным Kotlin и Swift. Ну и так далее. А если учесть, что у конкретного человека всегда есть background и быстрее всего писать на том, что он лучше знает, точность сравнения вообще уходит под границу статистической погрешности
Мне в принципе без разницы, на чем писать... Только если это что-то быстро надо накатать: то выбор у меня между bash и Python, просто потому что я могу сделать chmod +x file.extension; ./file.extension и не париться по поводу dotnet build (пусть это и автоматизируемо, но писанины больше, чем хотелось бы)
источник

AT

Alexander Tchitchigin in Compiler Development
Мои ощущения говорят, что "традиционные" (unsound) системы типов a-la Java/C#/C++ по сравнению с динамическими ограничения накладывают, а преимуществ дают недостаточно чтобы перевесить 100%. Системы типов OCaml, Haskell, PureScript - дают и перевешивают, но "слишкам сложна..."
Посмотрим как себя покажут "промежуточные" системы типа Rust и Swift.
источник

AK

Andrei Kurosh in Compiler Development
FORTRAN ONE LOVE
Мне в принципе без разницы, на чем писать... Только если это что-то быстро надо накатать: то выбор у меня между bash и Python, просто потому что я могу сделать chmod +x file.extension; ./file.extension и не париться по поводу dotnet build (пусть это и автоматизируемо, но писанины больше, чем хотелось бы)
Опять же, это специфика вашей работы. Я у себя использую LINQPad, который тоже позволяет выполнить выражение на C# / F# одним нажатием, вывести результат в виде таблицы\графика, а также подключиться к БД. Покрывает значительный процент задач и никакой волокиты с dotnet build
источник

EM

Evgenii Moiseenko in Compiler Development
Alexander Tchitchigin
Мои ощущения говорят, что "традиционные" (unsound) системы типов a-la Java/C#/C++ по сравнению с динамическими ограничения накладывают, а преимуществ дают недостаточно чтобы перевесить 100%. Системы типов OCaml, Haskell, PureScript - дают и перевешивают, но "слишкам сложна..."
Посмотрим как себя покажут "промежуточные" системы типа Rust и Swift.
По-вашему у Rust система типов проще чем в OCaml?)
источник