Например, стандартная функция strpos возвращает либо целочисленный индекс (если подстрока найдена), либо значение false (если не найдена) — значение true она не может вернуть ни при каких обстоятельствах. Таких функций в стандартной библиотеке много, да и в пользовательском коде такой подход нередко встречается. Так что указание того, что функция может вернуть не любое значение типа bool, а либо значение отличного от bool типа (нормальное завершение), либо false (действие не выполнено), безусловно улучшает надёжность и читабельность кода.
Nullable types — это когда значение либо единственного типа, либо null. А для тех случаев, когда значение может быть одного из нескольких типов или null, nullable types не применимы — необходимо явно прописывать null.
Нельзя написать:
?string|array
или
?string|?array
Надо:
string|array|null
А в стандартной библиотеке такие функции есть и если вводится типизация, то и библиотечные функции должны иметь типизированную сигнатуру.
Шёл 2022 год… О существовании современных механизмов AJAX в современном JavaScript автор, очевидно, не знает.
Но даже если используется jQuery, зачем публиковать тысяча первую малограмотную инструкцию, когда много лет существует сайт jquery.page2page.ru (работающее зеркало: page2page.lohmach.info)? И заглянув на page2page.lohmach.info/index.php5/Ajax.html можно узнать, например, что $.get и $.post имеют четыре параметра (а не три, как утверждает автор статьи), а сам jQuery-модуль работы с AJAX имеет куда больше возможностей, чем перечислено в статье.
И зачем в статье упоминания PHP? AJAX абсолютно фиолетово, на каком именно языке написан back-end.
Очевидно, вы не поняли смысл статьи. Речь не про то, чтобы не использовать в языках программирования слова «человеческого» языка — об этом в статье ни слова нет. Речь про то, что алгоритм, передаваемый вычислительной системе, должен записываться не посредством текста, созданного по правилам языка человеческого общения, а посредством специально разработанной для этого формальной системы. Именно такими формальными системами являются абсолютно все промышленные языки программирования — независимо от того, какие слова «человеческого» языка они используют в записи своих конструкций.
Вместо того, чтобы кидать демагогическое «существует мнение», вы бы ознакомились с реальной историей языков программирования, однозначно опровергающей ваш тезис о приближении ЯВУ к языкам человеческого общения. Ни один получивший распространение язык программирования не позволяет записать алгоритм текстом, близким по грамматике к языку человеческого общения.
P.S. Среди языков, ставших популярными, самым приближённым к «человеческому общению», является COBOL, но даже в нём текст программы, записываемый английскими словами, не имеет никакого отношения к грамматике английского языка.
это не наследование, а композиция. И ООП через композицию — не менее мощный механизм, чем ООП через наследование. В частности, на Хабре было несколько статей на тему «композиция vs наследование».
iota — это синтаксический сахар go для объявления числовой последовательности констант. Первая константа задается значением 0.
Либо ошибка, либо плохо сформулировано: iota — это индекс константы в наборе и первая константа имеет индекс 0. Но значения первой и последующих констант определяются выражением, включающим в себя iota, которое совсем не обязано быть равным 0.
Основная ошибка — забыть, что современный HTML позволяет задать для изображения несколько ссылок на картинки разного размера/формата из которых браузер сам выберет и загрузит одну наиболее подходящую.
Ориентация на мифический «самый популярный размер» сразу отсекает тех, кто сидит за большими настольными мониторами.
Ppi/dpi никакого отношения к оптимизации изображений на сайте не имеют: эти параметры реально нужны только для расчёта физического размера изображений в полиграфии. А для сайта важен только размер изображения в пикселах.
«Цыганочка» и «Яблочко» — это, прежде всего, танцевальные мелодии. Которые и без текста воспринимаются именно весёлыми.
Проблема абсолютизации значения музыкального ряда в том, что существует множество минорных мелодий, воспринимаемых как весёлые, и мажорных мелодий, воспринимаемых как грустные — независимо от наличия текстов. Причём воспринимаемых именно «европейцами», воспитанными на делении минор / мажор.
Музыкальный лад — лишь одна из составляющих эмоционального восприятия музыки. Да, безусловно важная, но далеко не всегда решающая.
В Go не существует классов. Мы можем создать методы не только для структур, но и для любого типа, производного от примитивного: хоть от bool, хоть от int. Соответственно, любой созданный нами тип может реализовывать любой интерфейс. А абсолютно все типы (включая изначально встроенные в язык) реализуют интерфейс interface{}.
Особенностью принятого в Go подхода является то, что мы можем совершенно корректно вызвать метод для типизированного nullable-указателя. Так что поведение интерфейса, равного nil, и интерфейса, содержащего указатель на nil, отличается не только при сравнении с nil, но и при вызове методов этого интерфейса.
Ссылку на тип содержат только переменные-интерфейсы. Все прочие переменные имеют тип, точно известный в момент компиляции, и компилятор просто подставляет информацию о типе в нужные места кода.
Объяснять алгоритм Дейкстры на примере лабиринта — очень плохая идея. На лабиринте хорошо изучать волновой алгоритм — в котором все расстояния между смежными узлами (соседними клетками) идентичны.
Собственно, это и произошло с автором: он крайне многословно и запутанно пытается объяснить именно волновой алгоритм, а не алгоритм Дейкстры. Зачем-то привлекая для этого Python-код.
К алгоритму Дейкстры в статье относятся: предложение «Получаем из списка открытых узлов тот узел, от которого нас отделяет наименьшее расстояние» и кусочек предложения «мы использовали бы для open_list не вектор, а очередь с приоритетами». Остальное — включая приведённые отрывки Python-кода — относится к волновому алгоритму.
N.B. Очевидно, статья рассчитана исключительно на пользователей Python, никогда не учившихся в ВУЗах, обучающих программистов (в которых алгоритмом Дейкстры решают задачи на занятиях математикой — не написанием программ, а ручкой на бумаге), но при этом настолько хорошо знающих алгоритмы, что они в состоянии сами понять, зачем к как нужно использовать очередь с приоритетами.
P.S. Алгоритм Дейкстры проще объяснять на карте дорог разной длины, соединяющих несколько городов. А для полного и понятного объяснения алгоритма достаточно нескольких картинок — без единой строчки кода. Как это сделано, например, в Википедии — статья в которой, посвящённая алгоритму Дейкстры, намного короче и несравнимо понятнее обсуждаемого творения.
Во многих случаях ограниченность области видимости переменной val не играет роли — т.к. используется эта переменная только в секции else оператора if. В тех же случаях, когда переменная val требуется вне if, лучше объявить её явно — через var. Но присваивание (вместо создания с инициализацией) оставить в инициализаторе оператора.
И нет — вызов функции в инициализаторе if является стандартной практикой даже если функция возвращает не только error. Другой же стандартной практикой является возврат error исключительно последним значением кортежа — и никак иначе.
Это не «шум», а иной подход к обработке ошибок: ошибка в Go — не состояние, а значение. С которым надо работать точно так же, как с другими значениями. Да, приходится писать чуть больше кода. Но качество кода — это не то, насколько быстро он пишется, а то, насколько хорошо он читается. И подход, принятый в Go, читается очень хорошо — часто лучше, чем более распространённые try-catch.
Go — функциональный язык, он не предоставляет стандартных средств ООП как таковых.
Нет, Go — не функциональный, а императивный компонентно-ориентированный язык. Обеспечивающий возможности, эквивалентные «страуструповскому» варианту ООП, на основе композиции — без присущих наследованию недостатков.
Горутины. В Python уже давно есть асинхронный код и корутины, так что особых проблем с горутинами не возникло
Нет, go-процедуры — это не сопрограммы. В первых версиях компилятора — да, go-процедуры реализовывались через кооперативную многозадачность. Но в последних версиях компилятора добавилась и вытесняющая многозадачность, так что сейчас go-процедуры ближе к полноценной многопоточности, чем к сопрограммам.
Вы ошибаетесь: в программировании / языках программирования русский термин «сопрограмма» в точности эквивалентен английском термину «coroutine».
Но с термином «сопрограмма» я познакомился в 1985 году — в учебнике по компиляции языков программирования, а бездумный транслит английского термина начался несколько лет назад — когда использование сопрограмм стало модной темой и рунет заполонил поток безграмотно переведённых англоязычных статей.
P.S. Кстати, одним из первых языков, в котором появились сопрограммы, был COBOL — более 60 лет назад.
Забыли упомянуть операции и сопрограммы — которые люди, не желающие изучать русскую IT-терминологию, регулярно именуют «операторами» и «корутинами».
И это встречается намного чаще, чем «партиции».
А как учитывалось то, что соискатели неоднократно публиковали эти задачи на мейлрушных «Ответах» — с тем, чтобы их решали другие? Или на это вообще внимания не обращали?
Нельзя написать: или
Надо:
А в стандартной библиотеке такие функции есть и если вводится типизация, то и библиотечные функции должны иметь типизированную сигнатуру.
Но даже если используется jQuery, зачем публиковать тысяча первую малограмотную инструкцию, когда много лет существует сайт jquery.page2page.ru (работающее зеркало: page2page.lohmach.info)? И заглянув на page2page.lohmach.info/index.php5/Ajax.html можно узнать, например, что $.get и $.post имеют четыре параметра (а не три, как утверждает автор статьи), а сам jQuery-модуль работы с AJAX имеет куда больше возможностей, чем перечислено в статье.
И зачем в статье упоминания PHP? AJAX абсолютно фиолетово, на каком именно языке написан back-end.
Вместо того, чтобы кидать демагогическое «существует мнение», вы бы ознакомились с реальной историей языков программирования, однозначно опровергающей ваш тезис о приближении ЯВУ к языкам человеческого общения. Ни один получивший распространение язык программирования не позволяет записать алгоритм текстом, близким по грамматике к языку человеческого общения.
P.S. Среди языков, ставших популярными, самым приближённым к «человеческому общению», является COBOL, но даже в нём текст программы, записываемый английскими словами, не имеет никакого отношения к грамматике английского языка.
Именно браузер и именно сам — без какого-либо фреймворка. В полном соответствии со стандартом HTML5.
Ориентация на мифический «самый популярный размер» сразу отсекает тех, кто сидит за большими настольными мониторами.
Ppi/dpi никакого отношения к оптимизации изображений на сайте не имеют: эти параметры реально нужны только для расчёта физического размера изображений в полиграфии. А для сайта важен только размер изображения в пикселах.
Проблема абсолютизации значения музыкального ряда в том, что существует множество минорных мелодий, воспринимаемых как весёлые, и мажорных мелодий, воспринимаемых как грустные — независимо от наличия текстов. Причём воспринимаемых именно «европейцами», воспитанными на делении минор / мажор.
Музыкальный лад — лишь одна из составляющих эмоционального восприятия музыки. Да, безусловно важная, но далеко не всегда решающая.
Особенностью принятого в Go подхода является то, что мы можем совершенно корректно вызвать метод для типизированного nullable-указателя. Так что поведение интерфейса, равного nil, и интерфейса, содержащего указатель на nil, отличается не только при сравнении с nil, но и при вызове методов этого интерфейса.
Ссылку на тип содержат только переменные-интерфейсы. Все прочие переменные имеют тип, точно известный в момент компиляции, и компилятор просто подставляет информацию о типе в нужные места кода.
Собственно, это и произошло с автором: он крайне многословно и запутанно пытается объяснить именно волновой алгоритм, а не алгоритм Дейкстры. Зачем-то привлекая для этого Python-код.
К алгоритму Дейкстры в статье относятся: предложение «Получаем из списка открытых узлов тот узел, от которого нас отделяет наименьшее расстояние» и кусочек предложения «мы использовали бы для open_list не вектор, а очередь с приоритетами». Остальное — включая приведённые отрывки Python-кода — относится к волновому алгоритму.
N.B. Очевидно, статья рассчитана исключительно на пользователей Python, никогда не учившихся в ВУЗах, обучающих программистов (в которых алгоритмом Дейкстры решают задачи на занятиях математикой — не написанием программ, а ручкой на бумаге), но при этом настолько хорошо знающих алгоритмы, что они в состоянии сами понять, зачем к как нужно использовать очередь с приоритетами.
P.S. Алгоритм Дейкстры проще объяснять на карте дорог разной длины, соединяющих несколько городов. А для полного и понятного объяснения алгоритма достаточно нескольких картинок — без единой строчки кода. Как это сделано, например, в Википедии — статья в которой, посвящённая алгоритму Дейкстры, намного короче и несравнимо понятнее обсуждаемого творения.
И нет — вызов функции в инициализаторе if является стандартной практикой даже если функция возвращает не только error. Другой же стандартной практикой является возврат error исключительно последним значением кортежа — и никак иначе.
Это не «шум», а иной подход к обработке ошибок: ошибка в Go — не состояние, а значение. С которым надо работать точно так же, как с другими значениями. Да, приходится писать чуть больше кода. Но качество кода — это не то, насколько быстро он пишется, а то, насколько хорошо он читается. И подход, принятый в Go, читается очень хорошо — часто лучше, чем более распространённые try-catch.
Нет, Go — не функциональный, а императивный компонентно-ориентированный язык. Обеспечивающий возможности, эквивалентные «страуструповскому» варианту ООП, на основе композиции — без присущих наследованию недостатков. Нет, go-процедуры — это не сопрограммы. В первых версиях компилятора — да, go-процедуры реализовывались через кооперативную многозадачность. Но в последних версиях компилятора добавилась и вытесняющая многозадачность, так что сейчас go-процедуры ближе к полноценной многопоточности, чем к сопрограммам.
Но с термином «сопрограмма» я познакомился в 1985 году — в учебнике по компиляции языков программирования, а бездумный транслит английского термина начался несколько лет назад — когда использование сопрограмм стало модной темой и рунет заполонил поток безграмотно переведённых англоязычных статей.
P.S. Кстати, одним из первых языков, в котором появились сопрограммы, был COBOL — более 60 лет назад.
И это встречается намного чаще, чем «партиции».