… что можно и не делать (разделять инструкции; ), что доказывают много современных языков. Но вы вроде писали о том как важно помогать парсеру… ценой своего удобства
Меня прежде всего интересует как оно в vscode, всё остальное вторично, если очень надо — надо в web-интерфейс запилить что-то типа плагина из vscode. Зачем дополнительно страдать ради тех кто копирует в чатах не могу понять, хотя большинство чатов уже нормально понимают
2+2
Хотя то, что отступы видны хуже, следует также из того факта, что люди с плохим зрением их не видят, в отличии от скобок.
Не видно отступы, при этом видно {}? странно, ну да ладно, так как я, человек с плохим зрением, не хочу их расставлять для кого-то кроме себя, а расставлять я их не хочу, хотя когда-то в плюсах я считал это обязательным.
А если нужно лочить не одно значение, а сразу два или три
withLock(mutex1, mutex2):
...
Какого типа должно быть значение val?
это невалидное выражение при данных сигнатурах, валидное должно быть drop(bar(x)), и это гораздо большая проблема если язык вообще позволяет писать такое, раст и не позволяет, но если считать что; это drop, то зачем мне делать drop на каждый вызов того что и так возвращает ()?
Нет никакого let mut, есть let PATTERN
я не очень понимаю как mut может относиться к части pattern
Про скобки и отступы:
Из-за древнего примера из си предлагается ещё последующие 100 лет дуть на воду. Опять же не надо забывать, что в современности мало кто программирует в notepad/nano, а отступ в vscode будет виден очень хорошо, за все годы я вспомнил что сделал такую ошибку только один раз, и то всё было найдено и исправлено меньше чем за минуту.
Про блоки: опять же блоки нет никакой нужды обозначать именно скобками, от этого они не перестанут быть блоками в других языках. А вот про область видимости — тут это растёт больше из проблем borrow-checker'а, и в примере с локом, в других языках это выглядит менее вербозно и без борров-чекера, что-то типа:
withLock(mutex): ...
Про;. Опять же нет никаких проблем сделать синтаксис без этого в компилируемом языке, если выражение возвращает (), то не надо ставить;, а если что-то возвращает и находится в конце функции — то это и есть её результат. Просто Раст очень пытался перетянуть на себя си-аудиторию, вот и получилась эдакая микс всего сразу.
Читая про постфиксную запись, я скорее склонен считать, что это попытка выдать желаемое за действительное, можно написать точно такой же текст о том почему это в плюсах удобнее, например auto a = fb() сразу сообщает пользователю об автовыведение типа — удобно как бы. Т.е. не то что это действительно так, но довольно спорный вопрос как удобнее на самом деле.
Опять же let mut избыточен, достаточно mut. Рассуждения о том какой синтаксис чтобы парсеру было удобно — вообще странные.
Не согласен с автором в том, что понимание как работает язык делает синтаксис лучше, скорее просто замыливает глаз, так как описанное в статье скорее из разряда о том как выкручиваются авторы самого раста, а не о горошком синтаксисе. Не смотря что Ява основной язык в моём резюме, но написание на этом вербозном языке, даже спустя десяток лет, не вызывает никаких положительных эмоций, а раст даже Яву переплюнул, правда не только из-за синтаксиса.
Но там ближе к J, в котором есть ранг объекта и он учитывается при операциях.
Вообще J намного ближе к APL, там сохранилось гораздо более уникальных концепций: комбинация операторов через форки и хуки, ранги данных, инверсные операции и тд и тп.
Тут скорее просто незнание словаря. Вероятно, если бы вы не знали значение английских слов, то и языки основной группы казались бы непонятной мешаниной. Хотя тут надо бы разделить — Q значительно проще чем J, в J довольно сложная композиция функций — хуки и форки
Это прежде всего перегрузка операций для работы с векторами и предпочтительное их использование, так как в этих интерпретаторах цикл довольно накладно вызывать
Q появился исключительно под давлением менеджмента, Артур не очень хотел это делал — и Kdb/Q накидали самым быстрым способом. Но, имхо, что намного хуже — Q заменил K. Он не выполняет никаких положительных дел, кроме как быть "красивым лицом для K", но значительно уступает K в выразительности, удобстве и лаконичности.
На Dyalog APL — я начал смотреть, но, к сожалению, далеко не копал. Меня больше заинтересовал IBM APL/2, в который тогда пытались добавить подобие толи статической типизации или просто кастомный типы, к сожалению что именно привлекло внимание к APL/2 я сейчас точно найти не могу.
J — сохранил APL-подобность языка. Довольно интересная академическая штука.
Форк K/Q — потерял большую часть APL, и стал больше напоминать что-то типа Scheme, о чём говорит упоминание fold, который не векторизуется в общем виде. Как язык — K/Q, к сожалению, застрял 30 лет назад.
Это у вас IT-софистика. Но намекну что вы будете делать тоже самое в расте, только руками делая clone или расставляя Rc
Осталось понять как то, что вы написали поможет не ставить бесполезный символ в конце каждой строки, никак не поможет
попробуйте Nim, в него уже кстати завезли borrow-checker, но не такой строгий как в Rust
… что можно и не делать (разделять инструкции; ), что доказывают много современных языков. Но вы вроде писали о том как важно помогать парсеру… ценой своего удобства
Ок. Признаться за всё время с растом ни разу не делал так. Однако всё равно не готов это сходу отнести маркер мутабельности к паттерн матчингу
Меня прежде всего интересует как оно в vscode, всё остальное вторично, если очень надо — надо в web-интерфейс запилить что-то типа плагина из vscode. Зачем дополнительно страдать ради тех кто копирует в чатах не могу понять, хотя большинство чатов уже нормально понимают
Не видно отступы, при этом видно {}? странно, ну да ладно, так как я, человек с плохим зрением, не хочу их расставлять для кого-то кроме себя, а расставлять я их не хочу, хотя когда-то в плюсах я считал это обязательным.
это невалидное выражение при данных сигнатурах, валидное должно быть drop(bar(x)), и это гораздо большая проблема если язык вообще позволяет писать такое, раст и не позволяет, но если считать что; это drop, то зачем мне делать drop на каждый вызов того что и так возвращает ()?
я не очень понимаю как mut может относиться к части pattern
withLock(mutex1, mutex2)
Про скобки и отступы:
Из-за древнего примера из си предлагается ещё последующие 100 лет дуть на воду. Опять же не надо забывать, что в современности мало кто программирует в notepad/nano, а отступ в vscode будет виден очень хорошо, за все годы я вспомнил что сделал такую ошибку только один раз, и то всё было найдено и исправлено меньше чем за минуту.
Про блоки: опять же блоки нет никакой нужды обозначать именно скобками, от этого они не перестанут быть блоками в других языках. А вот про область видимости — тут это растёт больше из проблем borrow-checker'а, и в примере с локом, в других языках это выглядит менее вербозно и без борров-чекера, что-то типа:
withLock(mutex): ...
Про;. Опять же нет никаких проблем сделать синтаксис без этого в компилируемом языке, если выражение возвращает (), то не надо ставить;, а если что-то возвращает и находится в конце функции — то это и есть её результат. Просто Раст очень пытался перетянуть на себя си-аудиторию, вот и получилась эдакая микс всего сразу.
Читая про постфиксную запись, я скорее склонен считать, что это попытка выдать желаемое за действительное, можно написать точно такой же текст о том почему это в плюсах удобнее, например auto a = fb() сразу сообщает пользователю об автовыведение типа — удобно как бы. Т.е. не то что это действительно так, но довольно спорный вопрос как удобнее на самом деле.
Опять же let mut избыточен, достаточно mut. Рассуждения о том какой синтаксис чтобы парсеру было удобно — вообще странные.
Не согласен с автором в том, что понимание как работает язык делает синтаксис лучше, скорее просто замыливает глаз, так как описанное в статье скорее из разряда о том как выкручиваются авторы самого раста, а не о горошком синтаксисе. Не смотря что Ява основной язык в моём резюме, но написание на этом вербозном языке, даже спустя десяток лет, не вызывает никаких положительных эмоций, а раст даже Яву переплюнул, правда не только из-за синтаксиса.
PS: всех с Новым Годом!
(+):: Int -> Int -> Int
(+):: Int -> [Int] -> [Int]
(+):: [Int] -> [Int] -> [Int]
это не перегрузка по типу параметра? Видимо у нас разное понимание этого слова
Как часто в APL коде? Постоянно. Самый простой пример: 1+vec — немного удобнее чем в хаскеле .map(+1)
Немного не понимаю что такое осмысленная перегрузка, но давайте попробую.
В данном случае > перегружена для вектора — она не делает сравнение числа, а генерирует булевый вектор, на основании которого потом выбираются числа.
Понятное дело что подобное можно изобразить практически в любом современном языке, однако мало кто будет сразу делать это через бинарый вектор.
Не думаю что стоит относиться к APL/K/Q/KDB как к языку программирования, это скорее некая альтернатива Excel
— добавление ---
Думаю может быть стоит сослаться на старую статью об APL: https://habr.com/ru/post/200084/
Но там ближе к J, в котором есть ранг объекта и он учитывается при операциях.
Вообще J намного ближе к APL, там сохранилось гораздо более уникальных концепций: комбинация операторов через форки и хуки, ранги данных, инверсные операции и тд и тп.
Тут скорее просто незнание словаря. Вероятно, если бы вы не знали значение английских слов, то и языки основной группы казались бы непонятной мешаниной. Хотя тут надо бы разделить — Q значительно проще чем J, в J довольно сложная композиция функций — хуки и форки
Это прежде всего перегрузка операций для работы с векторами и предпочтительное их использование, так как в этих интерпретаторах цикл довольно накладно вызывать
Q появился исключительно под давлением менеджмента, Артур не очень хотел это делал — и Kdb/Q накидали самым быстрым способом. Но, имхо, что намного хуже — Q заменил K. Он не выполняет никаких положительных дел, кроме как быть "красивым лицом для K", но значительно уступает K в выразительности, удобстве и лаконичности.
На Dyalog APL — я начал смотреть, но, к сожалению, далеко не копал. Меня больше заинтересовал IBM APL/2, в который тогда пытались добавить подобие толи статической типизации или просто кастомный типы, к сожалению что именно привлекло внимание к APL/2 я сейчас точно найти не могу.
J — сохранил APL-подобность языка. Довольно интересная академическая штука.
Форк K/Q — потерял большую часть APL, и стал больше напоминать что-то типа Scheme, о чём говорит упоминание fold, который не векторизуется в общем виде. Как язык — K/Q, к сожалению, застрял 30 лет назад.
Такое ощущение что менеджер писал
Я два раза перечитал, в статье написано "за исключением C", собственно это "что-то" + C и интересно сравнить
Включить Zig, но не включить Nim? Странная выборка.
Вот бы ссылку на алиэспресс.
Хабр иногда удивляет в хорошем смысле, как и в этот раз — ребёнок неделю назад заговорил о микроскопе, а вот и статья, и так не первый раз