Видимо расчет на логистику. Не из любой же точки можно успеть за сутки обернуться туда и обратно. А если прогревать будут в одном регионе, а использовать в другом, тут снова может прилететь каптча - ни кто же не обещает, что механизм проверки будет сугубо одноразовым.
Ну если с момента появления в сети и до ввода каптчи оно смогло переместиться на приличное расстояние, то это может быть сигналом. Хотя любой другой транспорт будет в той же категории, здесь круг ложноположительных срабатываний сильно сужается. Плюс тайминги для прохождения квеста играют не в пользу, ведь кожаного юзера можно мурыжить каптчами/смсками на протяжении некоторого времени, без особого вреда для типичных юзкейсов. В отличие от роботов, которым нужно успевать пока их не вычислили.
Я так понимаю, они могут довольно долго лететь без интернета "по звездам". Интернет им больше нужен на последней миле, где могут потребоваться корректировки. Поэтому "просыпаться" симки могут в любой удобной точке.
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, и прочими прелестями, которые обычно зашиты в дебрях компиляторов и доступны в ощущениях разве что через дисассемблер. Синтаксис, правда, местами своеобразный.
Для чего вообще в языке программирования высокого уровня нужны два разных типа целых? Выглядит как решение проблемы, которой в принципе не должно существовать.
В бизесовых приложениях чаще делают ошибки другого рода. Например, когда пользователь вводит невалидный номер телефона, или пытается списать с баланса склада больше, чем там лежит.
Видимо расчет на логистику. Не из любой же точки можно успеть за сутки обернуться туда и обратно. А если прогревать будут в одном регионе, а использовать в другом, тут снова может прилететь каптча - ни кто же не обещает, что механизм проверки будет сугубо одноразовым.
Ну если с момента появления в сети и до ввода каптчи оно смогло переместиться на приличное расстояние, то это может быть сигналом. Хотя любой другой транспорт будет в той же категории, здесь круг ложноположительных срабатываний сильно сужается. Плюс тайминги для прохождения квеста играют не в пользу, ведь кожаного юзера можно мурыжить каптчами/смсками на протяжении некоторого времени, без особого вреда для типичных юзкейсов. В отличие от роботов, которым нужно успевать пока их не вычислили.
Если они научатся писать жизнеспособные мутации, иначе всей популяции быстро придёт конец. Так же проблема, что и у биологических вирусов.
Я так понимаю, они могут довольно долго лететь без интернета "по звездам". Интернет им больше нужен на последней миле, где могут потребоваться корректировки. Поэтому "просыпаться" симки могут в любой удобной точке.
Насколько я понял, эта блокировка срабатывает на территории РФ.
Если их договорные отношения были установлены с бодишопом, а не напрямую с банком, то претензия может быть не по адресу.
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, и прочими прелестями, которые обычно зашиты в дебрях компиляторов и доступны в ощущениях разве что через дисассемблер. Синтаксис, правда, местами своеобразный.
Для чего вообще в языке программирования высокого уровня нужны два разных типа целых? Выглядит как решение проблемы, которой в принципе не должно существовать.
В бизесовых приложениях чаще делают ошибки другого рода. Например, когда пользователь вводит невалидный номер телефона, или пытается списать с баланса склада больше, чем там лежит.