LLM-ки фактически перекладывают работу с автора на ревьюера. Часто вайбкодеры, создающие PR, не понимают предложенного LLM решения и не могут потом адекватно реагировать на замечания и вносить нужные правки. Сложности добавляет еще тот факт, что LLM могут генерировать фактически мусор, который выглядит крайне правдоподобно. Копаться в этом тоже мало удовольствия.
Так для этого и передавали бы в сортировку функцию сравнения, как нормальные люди, а не заставляли решать на порядок более сложную и, главное, не относящуюся к делу задачу генерации ключа.
В питоне ходить вглубь структур это относительно дорогое удовольствие. Компаратор приходится дергать на каждом шаге сортировки. Если при этом он ещё ходит вглубь элементов - чтобы доставать значения по которым нужно сортировать (а иначе зачем он вообще был бы нужен), - то получается накладно.
Когда методы разбиты по классам на логически связанные группы, как в таблице по ссылке, то в голове вместо россыпи непонимания сразу появляется вполне чёткая система. В изучении можно идти от простого к сложному, постепенно добавляя новые методы и получая коллекции с новыми уникальными свойствами (совсем как в математике).
Итератор это вообще простая штука, которая понимает всего лишь одно слово "следующий" (__next__), а когда следующего нет, то кричит "расчет окончен" (StopIteration). Можете привести ситуации из жизни, где вы сталкивались с таким протоколом? Обычно все без труда вспоминают несколько примеров.
Ни и тут кстати нюанс. Когда говорят, что в MIT теперь изучают питон, то это не совсем валидно. Программы обучения MIT по-прежнему выстроены вокруг ATD, приучая студентов видеть принципы и использовать подходящие абстракции. Но они действительно теперь проводятся с примерами на питоне. Хотя, вместо него может быть любой другой язык - он здесь абсолютно вторичен. В этом, на мой взгляд, состоит ключевое отличие от "советской" школы программирования, которая старается научить видеть за любой абстракцией уровень реализации - технику. Причем чем ниже это уровень, тем считается "круче".
Зачем вам числа в языке только одного типа? От языка требуется возможность определять свои domain-specific абстракции, а не спотыкаться постоянно о встроенные машино-специфичные типы.
Если работаешь с цветами, то практичнее определить тип Color с нужным набором операций, оставив нюансы низкоуровневого представления за кадром. Среди этих операций наверняка будет работа с цветовыми пространствами, масками, отдельными компонентами. А вот деления или взятия корня n-й степени быть не должно, поскольку они здесь не имеют смысла.
Как находить и строить подходящие абстракции для предметной области, - вот этому искусству нужно учиться, - а не таскать специфику упаковки данных в памяти через все приложение. Я серьёзно не вижу повода для гордости от того, что в языке высокого уровня, машино-специфичные типы выставлены наружу на уровне языка. Все это может и должно жить в библиотеке.
Я считаю, что вы могли бы здесь показать сильные аргументы с позиций обучения. Однако в качестве примеров почему-то приводите задачи ввода-вывода, где статическая типизация не имеет существенного значения. Вы же не предлагаете на самом деле раскидывать нюансы работы с внешним миром по всей программе, вместо того чтобы обучать отрабатывать сериализацию/десериализацию данных на границах слоев?
База, кстати, здесь не самый удачный пример: на границе слоев должен быть полноценный парсинг входящих данных, в рантайме, а не статический тайпчекинг. Мы же не знаем что там снаружи к нам прилетит.
Часто так и есть. Навороты, типа LINQ, могут скрывать от работчика подобные нюансы, реализуя парсинг за сценой - показывая в коде лишь переменные да типы. Это удобно, не спорю. Но у новичка такие неявности могут создать обманчивое впечатление, будто за него все ошибки ловит компилятор.
PABS это PascalABC на сленге в официальных каналах telegram разработчиков языка.
Подсветка синтаксиса и проверка ошибок в IDE, на минималках, требуют реализовать токенайзер, парсер и тайпчекер. Но делать сборку "объектника" (или 'экзешника", в зависимости от дизайна), чем обычно заниматся компилятор, после ввода каждого очередного символа в редакторе, согласитесь, это как бы против здравого смысла.
Получается, что в некоторых случаях проверка типов должна работать не зависимо от процессов сборки. Поэтому выдавать за благо тайпчекинг, прибитый гвоздями к компилятору, ну такое.
В Python или TypeScript тайпчекинг сделан отдельными проектами (pyright, mypy и т.п.), и я считаю это нормально. Такой подход позволил минимальными усилиями реализовать Langserver, предоставив разработчикам быструю обратную связь в практически любой современной IDE. У PABS, насколько мне известно, здесь были большие проблемы именно из-за выбранной изначально архитектуры.
Как минимум для того, что один тип требует для хранения в два раза меньше памяти, чем другой.
Думаю, что эта тема была близка каждому во времена Вирта, где всем должно было хватать 640Кб . Но сейчас она мне кажется скорее специфичной.
Ни в коем случае не умоляю важности понимания того как информация кодируется и представляется в компьютере, и откуда в программах берутся ошибки переполнения. Но это вряд-ли то, обо что нужно вынуждать каждый раз спотыкаться на протяжении всего курса обучения.
Это действительно нужно для учёного языка? По-моему важнее интерактивность, релевантный набор абстракций изучаемым темам. Доступный API, интроспекция, чтобы абстракцию можно было крутить и разбирать на части как игрушку. А также адекватные, объясняющие сообщения об ошибках.
Я не фанат, но в том же питоне есть целые в смысле математики, и ctypes для работы с С-подобными структурами. В этом конструкторе подкупает возможность интерактивно "пощупать" и арифметику с фиксированной разряднотстью, и размеры структур и их отдельных полей, и работу с указателями и т.п. Можно поиграться с выравниванием, endian, и прочими прелестями, которые обычно зашиты в дебрях компиляторов и доступны в ощущениях разве что через дисассемблер. Синтаксис, правда, местами своеобразный.
Для чего вообще в языке программирования высокого уровня нужны два разных типа целых? Выглядит как решение проблемы, которой в принципе не должно существовать.
В бизесовых приложениях чаще делают ошибки другого рода. Например, когда пользователь вводит невалидный номер телефона, или пытается списать с баланса склада больше, чем там лежит.
У PascalABC.NET, кстати похожие проблемы из-за того, что он является надстройкой примерно такого же уровня над .NET, как Kotlin над Java. Вроде бы самостоятельный язык, но в то же время кишки базовой платформы то там то здесь пролезают наружу.
Статическая типизация не имеет прямого отношения к компиляции. Это всего лишь один из многих способов статического анализа (проверки) исходного кода.
Статический код анализ не сводится к одним лишь к проверкам типов. Сюда так же входит код стайл (нейминг, форматирование и т.п), ограничения по зависимостям между модулями (clean architecture, например), секьюрити проверки SAST, композиционный анализ SCA и т.д. Подсветка синтаксиса и ошибок в IDE (в том числе связаных с типами, но не ограничиваясь ими), в конце-концов, это все тоже элементы статического код анализа.
В ситуации, когда проверка типов прибита гвоздями к компиляции, реализовать такое без ущерба для UX в плане производительности может быть довольно нетривильной задачей (в том числе и для мейтейнеров PABS, насколько мне известно).
Люди, по сути, приспособлены эволюцией всеми силами выживать при изменении внешних факторов. Внешняя среда, действуя как принуждающая сила, является отличным мотиватором. С этой стороны все отлично работает. Может за исключением моментов, когда такие измения воспринимаются несущественными, встречая сопротивление со стороны психики для включения адаптационных выживальческих механизмов.
Внутренняя мотивация включается на волевых больше тогда, когда трешака снаружи уже недостаточно - это пресловутое "выйти из зоны комфорта".
Проблему нужно воспринимать не как наказание, а как проект.
Можно ещё воспринимать как весёлое приключение. Это разгружает психику, превращая решение в удовольствие. Другой вариант - вообще никак не воспринимать. Многие вещи, которые кажутся нам важными, не стоят того, чтобы на них в принципе нужно было бы обращать внимание. Но понимаешь это только лет через 10.
Здесь выше есть комментарий про плоский тор. В 2d это выглядит как старая аркада - когда добравшись до любого из краев экрана монитора, фигурка не упирается в него как в стену, и не уезжает за пределы в никуда, а появляется с противоположной стороны.
Насколько я понял, эта блокировка срабатывает на территории РФ.
Если их договорные отношения были установлены с бодишопом, а не напрямую с банком, то претензия может быть не по адресу.
LLM-ки фактически перекладывают работу с автора на ревьюера. Часто вайбкодеры, создающие PR, не понимают предложенного LLM решения и не могут потом адекватно реагировать на замечания и вносить нужные правки. Сложности добавляет еще тот факт, что LLM могут генерировать фактически мусор, который выглядит крайне правдоподобно. Копаться в этом тоже мало удовольствия.
Для чего в принципе нужна SD во флагмансих устройствах, где терабайт быстрой и надёжной встроенной памяти уже давно не является экзотикой?
Технически это сделано не совсем так, но суть вы уловили верно. У них есть статья, где довольно подробно описан подход https://docs.python.org/3/howto/sorting.html.
Определить компаратор), и превратить в key: https://docs.python.org/3/library/functools.html#functools.cmp_to_key.
В питоне ходить вглубь структур это относительно дорогое удовольствие. Компаратор приходится дергать на каждом шаге сортировки. Если при этом он ещё ходит вглубь элементов - чтобы доставать значения по которым нужно сортировать (а иначе зачем он вообще был бы нужен), - то получается накладно.
Гораздо эффективнее сначала достать все значения за один проход, а уже потом сортировать получившийся "плоский" список. Для этого и нужна key func https://en.wikipedia.org/wiki/Schwartzian_transform .
В py2 функции сортировки принимали компаратор, но в py3 опцию выпилили, чтобы народ использовал более эффективный паттерн.
Итераторы легко объяснить, если отталкиваться не от фич языка, а от абстрактных типов данных (стандартных "коллекций" в терминах питона) - https://docs.python.org/3/library/collections.abc.html .
Когда методы разбиты по классам на логически связанные группы, как в таблице по ссылке, то в голове вместо россыпи непонимания сразу появляется вполне чёткая система. В изучении можно идти от простого к сложному, постепенно добавляя новые методы и получая коллекции с новыми уникальными свойствами (совсем как в математике).
Итератор это вообще простая штука, которая понимает всего лишь одно слово "следующий" (__next__), а когда следующего нет, то кричит "расчет окончен" (StopIteration). Можете привести ситуации из жизни, где вы сталкивались с таким протоколом? Обычно все без труда вспоминают несколько примеров.
Ни и тут кстати нюанс. Когда говорят, что в MIT теперь изучают питон, то это не совсем валидно. Программы обучения MIT по-прежнему выстроены вокруг ATD, приучая студентов видеть принципы и использовать подходящие абстракции. Но они действительно теперь проводятся с примерами на питоне. Хотя, вместо него может быть любой другой язык - он здесь абсолютно вторичен. В этом, на мой взгляд, состоит ключевое отличие от "советской" школы программирования, которая старается научить видеть за любой абстракцией уровень реализации - технику. Причем чем ниже это уровень, тем считается "круче".
Зачем вам числа в языке только одного типа? От языка требуется возможность определять свои domain-specific абстракции, а не спотыкаться постоянно о встроенные машино-специфичные типы.
Если работаешь с цветами, то практичнее определить тип Color с нужным набором операций, оставив нюансы низкоуровневого представления за кадром. Среди этих операций наверняка будет работа с цветовыми пространствами, масками, отдельными компонентами. А вот деления или взятия корня n-й степени быть не должно, поскольку они здесь не имеют смысла.
Как находить и строить подходящие абстракции для предметной области, - вот этому искусству нужно учиться, - а не таскать специфику упаковки данных в памяти через все приложение. Я серьёзно не вижу повода для гордости от того, что в языке высокого уровня, машино-специфичные типы выставлены наружу на уровне языка. Все это может и должно жить в библиотеке.
Я считаю, что вы могли бы здесь показать сильные аргументы с позиций обучения. Однако в качестве примеров почему-то приводите задачи ввода-вывода, где статическая типизация не имеет существенного значения. Вы же не предлагаете на самом деле раскидывать нюансы работы с внешним миром по всей программе, вместо того чтобы обучать отрабатывать сериализацию/десериализацию данных на границах слоев?
Ну мы вообще довольно далеко ушли от начальногой темы).
База, кстати, здесь не самый удачный пример: на границе слоев должен быть полноценный парсинг входящих данных, в рантайме, а не статический тайпчекинг. Мы же не знаем что там снаружи к нам прилетит.
Часто так и есть. Навороты, типа LINQ, могут скрывать от работчика подобные нюансы, реализуя парсинг за сценой - показывая в коде лишь переменные да типы. Это удобно, не спорю. Но у новичка такие неявности могут создать обманчивое впечатление, будто за него все ошибки ловит компилятор.
PABS это PascalABC на сленге в официальных каналах telegram разработчиков языка.
Подсветка синтаксиса и проверка ошибок в IDE, на минималках, требуют реализовать токенайзер, парсер и тайпчекер. Но делать сборку "объектника" (или 'экзешника", в зависимости от дизайна), чем обычно заниматся компилятор, после ввода каждого очередного символа в редакторе, согласитесь, это как бы против здравого смысла.
Получается, что в некоторых случаях проверка типов должна работать не зависимо от процессов сборки. Поэтому выдавать за благо тайпчекинг, прибитый гвоздями к компилятору, ну такое.
В Python или TypeScript тайпчекинг сделан отдельными проектами (pyright, mypy и т.п.), и я считаю это нормально. Такой подход позволил минимальными усилиями реализовать Langserver, предоставив разработчикам быструю обратную связь в практически любой современной IDE. У PABS, насколько мне известно, здесь были большие проблемы именно из-за выбранной изначально архитектуры.
Думаю, что эта тема была близка каждому во времена Вирта, где всем должно было хватать 640Кб . Но сейчас она мне кажется скорее специфичной.
Ни в коем случае не умоляю важности понимания того как информация кодируется и представляется в компьютере, и откуда в программах берутся ошибки переполнения. Но это вряд-ли то, обо что нужно вынуждать каждый раз спотыкаться на протяжении всего курса обучения.
Это действительно нужно для учёного языка? По-моему важнее интерактивность, релевантный набор абстракций изучаемым темам. Доступный API, интроспекция, чтобы абстракцию можно было крутить и разбирать на части как игрушку. А также адекватные, объясняющие сообщения об ошибках.
Я не фанат, но в том же питоне есть целые в смысле математики, и ctypes для работы с С-подобными структурами. В этом конструкторе подкупает возможность интерактивно "пощупать" и арифметику с фиксированной разряднотстью, и размеры структур и их отдельных полей, и работу с указателями и т.п. Можно поиграться с выравниванием, endian, и прочими прелестями, которые обычно зашиты в дебрях компиляторов и доступны в ощущениях разве что через дисассемблер. Синтаксис, правда, местами своеобразный.
Для чего вообще в языке программирования высокого уровня нужны два разных типа целых? Выглядит как решение проблемы, которой в принципе не должно существовать.
В бизесовых приложениях чаще делают ошибки другого рода. Например, когда пользователь вводит невалидный номер телефона, или пытается списать с баланса склада больше, чем там лежит.
У PascalABC.NET, кстати похожие проблемы из-за того, что он является надстройкой примерно такого же уровня над .NET, как Kotlin над Java. Вроде бы самостоятельный язык, но в то же время кишки базовой платформы то там то здесь пролезают наружу.
Статическая типизация не имеет прямого отношения к компиляции. Это всего лишь один из многих способов статического анализа (проверки) исходного кода.
Статический код анализ не сводится к одним лишь к проверкам типов. Сюда так же входит код стайл (нейминг, форматирование и т.п), ограничения по зависимостям между модулями (clean architecture, например), секьюрити проверки SAST, композиционный анализ SCA и т.д. Подсветка синтаксиса и ошибок в IDE (в том числе связаных с типами, но не ограничиваясь ими), в конце-концов, это все тоже элементы статического код анализа.
В ситуации, когда проверка типов прибита гвоздями к компиляции, реализовать такое без ущерба для UX в плане производительности может быть довольно нетривильной задачей (в том числе и для мейтейнеров PABS, насколько мне известно).
Люди, по сути, приспособлены эволюцией всеми силами выживать при изменении внешних факторов. Внешняя среда, действуя как принуждающая сила, является отличным мотиватором. С этой стороны все отлично работает. Может за исключением моментов, когда такие измения воспринимаются несущественными, встречая сопротивление со стороны психики для включения адаптационных выживальческих механизмов.
Внутренняя мотивация включается на волевых больше тогда, когда трешака снаружи уже недостаточно - это пресловутое "выйти из зоны комфорта".
Можно ещё воспринимать как весёлое приключение. Это разгружает психику, превращая решение в удовольствие. Другой вариант - вообще никак не воспринимать. Многие вещи, которые кажутся нам важными, не стоят того, чтобы на них в принципе нужно было бы обращать внимание. Но понимаешь это только лет через 10.
Здесь выше есть комментарий про плоский тор. В 2d это выглядит как старая аркада - когда добравшись до любого из краев экрана монитора, фигурка не упирается в него как в стену, и не уезжает за пределы в никуда, а появляется с противоположной стороны.