Дрю ДеВолт (Drew DeVault), автор пользовательского окружения Sway, почтового клиента Aerc и платформы совместной разработки SourceHut,...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57081
У этого языка длинные уши! =)
Настолько длинные, что синтаксис запутался в них.
int и uint - это фэйл! Сишные проблемы с разным размером этого и логическими ошибками прогеров которые это игнорят ничему не научили? Хруст вроде и то эту мерзость повырубил.
Ничего твой хруст не вырубил. Он даже переполнение целочисленной переменной не проверяет. Давай фантазируй дальше.
Он вроде бы продвигает типы конкретной ширины когда прогер как минимум знает сколько туда лезет, а абстрактное "int" нихрена про это не говорит. Поэтому часто случается что мнение вон того прогера и вон того компилера не совпало - и возникают крутые баги на ровном месте. Спасибо если не вулны.А проверка значений целочисленных операций в рантайме убивает скорость математики в разы. Одно дело ADD R1, #1 и совсем другое - оно же с проверкой флагов и условными переходами. Так что код внезапно в разы медленнее и жирнее. Ну и все крипто, кодеки, графика и прочее добро где нам позарез нужна скорость алгоритмов - обваливается в разы. И никому оно такое не надо оказывается, кроме питономмакетов с энтерпрайзами готовыми сервера докупить. И даже те - вон сервис шаринга файлов, сперва пихон на игогоху переписал а потом и на хруст. Экономия на серверах штука такая.
>Одно дело ADD R1, #1 и совсем другое - оно же с проверкой флагов и условными переходами.как такое можно писать? понятие "корректный алгоритм" вам знакомо?
https://ru.wikipedia.org/wiki/%D0%90%D0%...
раздел "Анализ алгоритмов" к прочтению.
> как такое можно писать? понятие "корректный алгоритм" вам знакомо?Ну вот так и можно - я могу проверить валидность границ и применимости математики где-то очень сильно за пределами тугого цикла. Не нагибая тугой цикл 100500 проверок и условий в обязаловку, вместо этого вынеся гарантии в сторону, просчитав worst case отдельно. Это позволяет сделать критичный кусок кода БЫСТРЫМ. Убить его в РАЗЫ по скорости во имя луны я совершенно не готов.
А зная точную ширину типа у меня сильно больше шансов на этом пути, чем когда тип оформлен так паршиво как int в сях, где что угодно может быть, так что там все и лажаются как раз. Иногда довольно красиво, с дереференсом отрицательных индексов массива и прочих интересных вещей.
>я могу проверить валидность границ и применимости математики где-то очень сильно за пределами тугого цикла. Не нагибая тугой цикл 100500 проверок и условий в обязаловку, вместо этого вынеся гарантии в сторону, просчитав worst case отдельно.не путайте понятия корректности и оптимальности. Выше вы предлагали не проверять флаги переполнения при сложении это относится к корректности, а щас пишите про оптимальность. Корректность предшествует оптимальность. Алгоритм должен сначала быть корректным, а потом уже оптимальным, а оптимальность уже это необходимое и достаточное условие, чтобы алгоритм оставался корректным.
Я вообще-то писал о том что коррекность можно обеспечивать и менее тупыми способами чем проверка каждой операции.Еще раз: я могу ДО основного цикла проверить что ХУЧШИЙ СЛУЧАЙ операции в цикле точно никогда не переполняется с данным размером, допустим, integer'ов, при вообще совсем любых аргументах на вход алгоритма.
При этом мне будет очень кстати знать ТОЧНЫЙ размер типа. Упрощает понимание краевых случаев.
Если я доказал это и проверил потребные критерии еще ДО входа в цикл, проверять переполнение в цикле избыточно и только обрушивает его скорость зазря. Да, это требует аккуратности, зато воздает скоростью недостижимой при указанном подходе с неотключаемой проверкой все и вся. В лучшем случае это даже автоматизировать можно, какой-нибудь развесовкой static assert'ов на этапе сборки еще, но катит не всегда, конечно.
> Он даже переполнение целочисленной переменной не проверяет.А надо? Иначе есть риск загубить криптографию, где переполнение целочисленных переменных используется по назначению
Ненадо так же как и раст.
С кодом вида
> "こんにちは世界！",...они скоро узнаюот про атаки вида BadSource :)
> Ничего твой хруст не вырубил. Он даже переполнение целочисленной переменной не проверяет. Давай фантазируй дальше.Уныленько. Попробуй потоньше.
https://github.com/rust-lang/rfcs/blob/master/text/0560-inte...
> Implementations are permitted to check for overflow at any time (statically or dynamically). Implementations are required to at least check dynamically when debug_assert! assertions are enabled. Add a WrappingOps trait to the standard library with operations defined as wrapping on overflow for the limited number of cases where this is the desired semantics, such as hash functions.
>
> Ничего твой хруст не вырубил. Он даже переполнение целочисленной переменной не проверяет.Никто этого не проверяет, даже жаба которая исполняется а JVM потому как это оверхед. Это фишка ALU процессоров, некоторые умеют выставлять флаги при переполнении, некоторые нет, это все очень платформеннозависимо. И даже если процессор выставит флаг переполнения, то для его проверки нужны дополнительные инструкции с бранчингом (на случай ошибки) после каждой мат.операции. Если такую вальвацию сделать частью языка, то такой язык будет считать медленным и он с треском проиграет во всех бечмарках, даже той же java и .net.
>Если такую вальвацию сделать частью языка, то такой язык будет считать медленным и он с треском проиграет во всех бечмарках, даже той же java и .net.а в чем разница если этот код проверки в рантайм пихает ЯП или этот же участок кода пишет программист? в случае с ЯП он будет гарантировать эту проверку, а в случае с программистом - на его "не выспанность" и безолаберность.
Так в том и дело что гарантий обычно никому не нужно, нужна скорость, есть же разница между выполнением 1 ассемблерной инструкцией и тремя.
В те редкие моменты когда такое переполнение может случится на себя берет ответственность кодер, можно использовать специальные математические библиотеки, они не только переполнение проверят, но и позволяют работать с очень большими числами не ограниченными размерами регистров в современных CPU, конечно это работает медленно, но такова цена за точность.А эта притенения похоже не претензию новичков к JS: `0.1+0.2=0.30000000000000004`, где проблема совсем не в JS, а в IEEE-754.
>Так в том и дело что гарантий обычно никому не нужно, нужна скоростьгарантий корректности не нужны?
>есть же разница между выполнением 1 ассемблерной инструкцией и тремя.
есть конечно же, но это не критерий оценки временной сложности алгоритма. Эти три инструкции могут быть взяты за элементарный шаг при анализе.
>но такова цена за точность
так что же важнее? корректность алгоритма с точным результатом или его "быстрота" с неточным результатом? И это не цена, это необходимость и достаточность.
> но это не критерий оценки временной сложности алгоритма.O(n) не изменится, но throughput просядет в пару раз.
> корректность алгоритма с точным результатом или его "быстрота" с неточным результатом?
Так тут как бы выбор между ошибкой в runtime и неточным результатом. Хотя слово неточный не уместно, результат то точный и детерминированный, просто не тот который ожидается при конкретной математической операции.
Вот допустим есть ошибка с переполнением, у нас есть тесты но они не покрыли конкретный случай вызывающий переполнение. Программа ушла клиентам или на сервер и в случае проверок на переполнение мы получим ошибку при определенных входных данных, это ошибка возникнет в момент исполнения.
Конечно круто что мы ее перехватим, ведь вместо неправильного результата у нас программа просто не позволит пойти дальше, мы не запишем в базу неправильное значение и т.д. Но цена этому будет производительность, например в случае сервера наш сервер будет обслуживать в два раза меньше клиентов.А если у нас не x86 архитектура, а какой-нибудь сервер на RISC-V где никаких флагов о переполнении в его ALU нет совсем, поту для него будут генерировать не 3 ассемблерные инструкции, а 5-10, на таких CPU производительность просядет в 5-10 раз.
> O(n) не изменится, но throughput просядет в пару раз.ну мы же говорим об асимптотике, таким же макаром можно говорить, что релейные реализации медленнее всяких МОП реализаций. А когда появятся фотонные транзисторы (потолок, предел физики) о чем говорить будем?
> Так тут как бы выбор между ошибкой в runtime и неточным результатом.
> Хотя слово неточный не уместно, результат то точный и детерминированный, просто
> не тот который ожидается при конкретной математической операции.неточный результат и есть ошибка.
> Но цена этому будет производительность, например в
> случае сервера наш сервер будет обслуживать в два раза меньше клиентов.нет не так, ибо это заведомо неправильная оценка, так как результат в первом случае может быть некорректным. Повторяю, корректность алгоритма предшествует оптимальности.
> А если у нас не x86 архитектура, а какой-нибудь сервер на RISC-V
> где никаких флагов о переполнении в его ALU нет совсем, поту
> для него будут генерировать не 3 ассемблерные инструкции, а 5-10,
> на таких CPU производительность просядет в 5-10 раз.просядет по сравнению с чем, с схематической реализацией? ну и дураку понятно. Ну допустим не используйте в ЯП оператор +, а напишите свою реализацию функции сложения add в столбик - просядет у вас производительность вычислений?
P.S. Я не исключаю что возможно существует язык или компилятор котоырй генерирует такие валидации, и используется где-то в критических индустриях, например для медицинского оборудования или атомной промышленности.
>нужны дополнительные инструкции с бранчингомВРЁТИ!!!
ВРЁЁОООААААААААА!!!!!!1111ыВыпалняем "trap on condition" прапоускаем один такт некакова суецы^W бранчинга.
> Выпалняем "trap on condition" прапоускаем один такт некакова суецы^W бранчинга.И скока платформ это умеет на уровне железа, чтоб без пеналти по скорости? А, расскажем что они не нужны. Так?
> Никто этого не проверяетDelphi (и lazarus тоже) проверяет в рантайме и генерит exception. Для криптографии вырубают.
Фортран вроде бы тоже должен проверять, но это не точно...
это некто не проверяет. это стандартное поведение mod(a+b, 2^x)
> это некто не проверяет. это стандартное поведение mod(a+b, 2^x)не стоит путать сложение по модулю и арифметическое сложение.
Еще прикол.> Handling allocation failure
> TODOЭм... а что делать если там NULL мы подумаем потом :)))
> Еще прикол.
>> Handling allocation failure
>> TODO
> Эм... а что делать если там NULL мы подумаем потом :)))Например попробовать читать спеки, вместо недописанного (к чему походу TODO и относится) туториала?
6.6.21.6
In the alloc form, if the execution environment is unable to allocate sufficient
storage for the requested type, the execution environment shall print a diagnostic
message and abort. If the type hint is a nullable pointer type, the result type of the
allocation expression shall also be nullable, and null shall be returned instead of
aborting if sufficient storage cannot be provided.
> Например попробовать читать спеки, вместо недописанного (к чему походу TODO и относится) туториала?А, это про туториал было? Вашу 20, чем они думали так туториал к "системному" языку писать?
> storage for the requested type, the execution environment shall print a diagnostic
> message and abort.Ох, круто, так и представляю себе линуксный кернел упавший в панику с "can't allocate message for kernel". Агаблин, очень так системненько... хрустикам это дело в майнлайновой рассылке популярно объяснили, этому дону персональное объяснение требуется?
> aborting if sufficient storage cannot be provided.
Ога, в кернеле тебе это и сделать...
> execution environment
> линуксный кернел"Крутой системщик"294 совсем не палицца ...
> Ох, круто, так и представляю себе линуксный кернел упавший в панику с
> "can't allocate message for kernel". Агаблин, очень так системненько... хрустикам это
> дело в майнлайновой рассылке популярно объяснили, этому дону персональное объяснение требуется?
>> aborting if sufficient storage cannot be provided.
> Ога, в кернеле тебе это и сделать...Хоспади, какая же каша у тебя в голове. Аллокация явная. Причем тут паники и хруст - не ясно. Судя по всему, до " and null shall be returned instead of aborting if sufficient storage cannot be provided." так и не дочитал.
> "Крутой системщик"294 совсем не палицца ...Во всяком случае могу накодить бутлоадер или фирмварь, реалтаймно и предсказуемо, подняв моим кодом SoC, пропатчить линухкернел, написать себе и не только (около)системные тулсы. А чего добился ты? :)
> Хоспади, какая же каша у тебя в голове. Аллокация явная. Причем тут
> паники и хруст - не ясно.Хрустики кстати после пинка Торвальца доперли. Но получилось костыльно, конечно. Наверное потому 2 конкурента хруста и образовалось. Они тоже странновато это делают, но некоторые идеи в принципе неплохо уловили.
> Судя по всему, до " and null shall be returned instead of aborting if sufficient storage
> cannot be provided." так и не дочитал.Я таки только краем глаза читал. Пытаясь понять насколько оно того стоит. В тыщи проектов уровня студенческой поделки, меня на всех не хватит. Но ДеВолт зарекомендовал себя неглупым типом. В зиге имхо прикольнее всего вычисления в компилтайме на самом деле придумали. Надеюсь ДеВолт сопрет идею, если еще не.
В идеале совместить бы их всех в что-то чуть более сишное, с предвычислениям как зиг, переклином на borrow checker хруста, опциональной и модулярной сислибой и могло бы получиться дельное комбо. А пока xkcd927 слегка напоминает. Уже минимум 3й убийца сишки. А сишкой продолжат пользоваться т.к. в силу примитивности проблем не очень много, они известны, в совсем пустой системе проще ему окружение создавать.
> В идеале совместить бы их всех в что-то чуть более сишное, с
> предвычислениям как зиг, переклином на borrow checker хруста, опциональной и модулярной
> сислибой и могло бы получиться дельное комбо. А пока xkcd927 слегка
> напоминает. Уже минимум 3й убийца сишки. А сишкой продолжат пользоваться т.к.
> в силу примитивности проблем не очень много, они известны, в совсем
> пустой системе проще ему окружение создавать.Напиши что бы ты хотел видеть/не видеть чуть более подробно, может даже страничку/бложик сделай.
1) Культурную работу с регистрами железа (разных размеров), как то эффективно форсируемый volatile, read-only и проч, развитую и эффективную работу с битовыми полями в каком-нибудь очень маленьком и очень оптимизированом виде без оверхеда и с precompute всего что precompute'ится. На сях это приходится самому делать изобретая велик, ибо битовые типы только в struct - и довольно криво! Ну например: допустим я знаю что у меня 32 бита в регистре. Как насчет красивых деклараций битов и полей в регистре, с проверкой что за 32 бита не выехало вместо UNDEFINED?
2) Стандартный контроль выравнивания и упаковки структур и проч. Может даже с контролем endianess. А чтоб структуроривано например пакеты (сетевые, радио, интерфейсные) описывать культурно и структурировано - но получать побитово предсказуемое нечто в провод/эфир или что там у нас, дабы ресивер на другой стороне это совершенно точно понял даже если это кодили совсем другие люди. В си так ну не то чтобы совсем нельзя, однако есть масса проблем по части endianess и упаковки. А упаковка зачем? Ну например вон тот struct скормить DMA-автомату по адресу "как есть" и стрельнуть его 1 блоком в провод или куда там без участия проца.
3) Стандартный вариант размещения константы/переменной/функции и проч в конкретной секции. А может и контроль за тем что делает линкер из сорца. Если я пишу фирмварь, мне надо чтобы вектора прерываний были в бинаре первыми, и по конкретному физическому адресу. В сях это делается, но - нестандартными расширениями. А вот именно одним только стандартом обойтись в таких вещах - ХРЕН.
4) Развитый compile time checking всего чего можно и нельзя. Потому что #$%нувшаяся на полпути фирмвара - весьма печально и дорого обходится. Наверное можно к этому compile time вычисления как в zig довольно круто припахать.
5) Ну и лично мне нравится гнутый тулчейн. Код хороший генерит, может заспорить с кайлой и иаром на мелких армах только так. Так что оформить новый, клевый яп фронтом к нему - дикий win в моих глазах.
Как я должен осилить столь отвратительный синтаксис?
Сначала попробовать писать на чём-то с более отвратительным синтаксисом)
После раста любой язык - кристально понятен.
чем отвратительнее синтаксис тем выше безопасность.
Потому, что киддисы такой язык не осилят.
Никак не могу понять, что же он мне напоминает....
Нечитаемый, ужасный синтаксис. После Nim особенно больно смотреть.
Ладно, если присмотреться, то норм. Отпугнули поначалу двоеточия.
Помесь сишки, хруста и зига, что же еще?! И таки let можно было бы наверное побустать. Мерзко 4 лишние буквы печатать, что ни говори.
> Помесь сишки, хруста и зига, что же еще?!Разве что для опеннетчиков, знакомых с другими ЯП исключительно по новостям опеннета.
Я бы сказал это смесь раста и го.
> Я бы сказал это смесь раста и го.Всякие деферы и проч явно из зига сперты, там почти так же было.
Дефер из Го. Я прогаю на Си и Го. Хотел написать Харэ, но текст языка полностью понятен, в отличие от ржавчины.
> Дефер из Го. Я прогаю на Си и Го. Хотел написать Харэ,
> но текст языка полностью понятен, в отличие от ржавчины.Просто синтаксически оно в целом Zig напоминает сильно больше игого. А тот в свою очередь под хруст сильно косит. У игогошки в целом синтаксис вроде бы заметно иной. А то что там фичу передрали - ух, блин, вы еще монополию на какие-нибудь корутины одному языку отдайте. А потом заметьте что их даже сишники умеют если захотят, чертову кучу лет, кули.
> Я бы сказал это смесь раста и го.A что там от Го, "let" или "::" или "use", или "fn" ... ?
Дефер
> Никак не могу понять, что же он мне напоминает....Это паскаль без бегинов и эндов.
let buffer: *[65535]u8 = alloc([0...]);
хорошо присваивание без ":"
Pascal. Был и остаётся хорош и понятен. Да, есть недочеты в free pascal, это проблемы реализаций , но сам язык очень хорош. И понятен!
Не скажу, что его последователь ADA хорош с точки зрения синтаксиса - слишком много не всем понятных Pragm.
Но с точки зрения безопасности и отсутствия ошибок - нет равных. Если программа скомпилированно на Ada/Spark, то это значит, что на 99% там не будет ошибок.
Кроме логических. Их будет столько же сколько везде.
С учетом развития в последнее время методов Машинного обучения в анализе кода, и на логические ошибки, за которые их посчитает AI, могут быть, по-крайней мере, выданы предупреждения пользователю.
А вон кстати какой-то анализер выкатили как раз, использующий результаты машинного обучения для поиска проблемного кода. Впрочем тут коллеги британских ученых AI припахали искать ядовитые молекулы, а он возьми да и найди кучу вариантов суровее VX... так что за убить всех человеков у роботов уж точно не заржавеет!
Советские учёные ещё в 1970-80-х без всякого AI нашли около 60 таких молекул суровее.
> Советские учёные ещё в 1970-80-х без всякого AI нашли около 60 таких молекул суровее.А этот нашел тысячи за какие-то единицы часов. И вообще был изначально для поиска лекарств а это так, на правах эксперимента.
Это просто ремарка к тому что если AI задастся каким-то вопросом, он найдет ответ и без советских ученых. За скромное время и эффективно. Самое забавное что с ним можно сделать - озадачить самоулучшением. Правда результат - unspecified.
Это был бы сильный ИИ, мне не кажется что ИИ сейчас для всего подходит.
> если AI задастся каким-то вопросомИскусственного интеллекта не существует. Есть нейронные сети, это другое.
Как показал пример жизни на планете, однажды слабый интеллект становится сильным. По мере увеличения числа нейронов оно самозапускается, развивается, осваивает более сложное взаимодействие с миром.Что помешает AI точно так же самозапуститься? На первый взгляд ничего. Верить в свою уникальность и избранность может только наглая глупая обезьяна. За что и попадет в зоопарк или на кладбище, имхо.
> логические ошибки, за которые их посчитает AIЭто "статистические ошибки", а не логические.
AI обученный на примерах миллионов (мух, которые не ошибаются), будет фиксировать, что код написан те так, как предыдущие миллионы.
Значит нужно определять логические ошибки чтобы датасет был эффективнее.
До сих пор живы Модулы в узких нишах. В универах на них чуть прогают и во всяких конторах где спутники делают (ада точно была там же, в каких то кубсатах).
Кстати, в каком то универе, на острове в море, до сих пор употребляют Симулу, даже не Смолток а именно Симулу в оригинале.
Я хоть и не фанат Паскалей, но приходилось писать, и много.
Но не многословность главный недостаток,
а уродливое объявление переменных где то в начале.
Наверное, вообще не в тему, но есть такой др. Дью, который использует инструмент DeWalt...
> самодостаточное использование для запуска поверх оборудования без операционной системыНу хоть один убийца Си это сделал на начальном этапе.
Что-то не нашёл на сайте примеров..
https://git.sr.ht/~sircmpwn/helios
Ладно... Я хотел для микроконтроллеров найти.
Они в этом не так уж отличаются от остального bare metal, единственное что реально надо - детальный контроль за layout прошивки, в какие секции что идет и в каких адресах это лежит. На сях это делается нестандартненько, таблицу векторов прерываний придется каким-нибудь левым __attribute__(section(IRQVECTORS)) делать. А это ни в раз не часть стандарта, печалька. Как и линкерный скрипт говоряший где это IRQVECTORS реально лежит.И еще там надо чтобы не было стандартной либы - где ей там файловую систему брать? Притащить еще либ и кода, весом в 20 раз больше основной части прошивки? Тогда и микроконтроллер придется брать дороже и навороченнее.
Сейчас кто-то ещё выбирает микроконтроллеры для новых проектов меньше, чем Cortex-M0? А стандартная либа newlib и в Атмегах помещается.
> Сейчас кто-то ещё выбирает микроконтроллеры для новых проектов меньше, чем Cortex-M0? А
> стандартная либа newlib и в Атмегах помещается.1) Даже attiny и такую гадость как pic миллионами используют. И даже там на сях прогают, ага.
2) А если в чипе m0 всего 16 кил флеша, 4 кило рамы, и у меня свое фирмваре большую часть этого уже жрет, мне как-то не в кассу еще newlib туда. И ФС мне там просто не нужна. А зачем абстракция файловой системы какому-нибудь термостату например? И чего делать предлагается, брать чип жирнее и дороже, где флеша и/или рамы больше? Это не бесплатно. Настолько что вон те даже с пиком готовы сношаться из-за полубакса на чип. При тираже в миллион им эти полбакса помноженные на миллион очень нравятся в их кармане.Нене, вы можете собрать термостат даже на распи. А миллион раз его потом повторить для народа жаба не удушит в таком виде? Ведь эти мегабаксы могли быть ваши а не броадкома...
Зачем Бредком, это же SoC с MMU? Микроконтроллер со 128 кбайт флеша - разумный компромисс.
Zig это умеет.
За что этому челу минус поставили без коммента?
Только он какой-то нестабильный, там были изменения не по-семверу. И до релиза 1.0.0 еще далеко если он ваще будет.
До 1.0.0 никакого семвера и нет.Но вообще если то что сейчас есть устраивает - считайте что он стабильный. Там сейчас пилят новый компилятор, и пока не допилят его, никаких улучшений особо не будет.
Т.е. на пару лет он вполне стабильный) Да и потом ничего критичного вроде не будет.
Форт, нет?
Реализаций живых и актуальных нет.
Hare и Haxe.
вообще есть nim, чем не устроил?
Фатальный недостаток, как и у всех других языков
С определённого момента в Nim стали заталкивать очень много всего. Дикая вариативность в кодировании алгоритмов на Nim. Похоже, автор идёт по стопам Perl.Очень мощный язык для самовыражения программиста (точнее даже - очень опытного программиста). Но вот разбираться с этим...
Язык должен быть простым, однозначным, с возможностью простого автоматического парсинга.
Сишка с неймспейсами?>fmt::println()!;
У вас ус^Wrust отклеился.
Забавно, что как раз в расте не нужен неймспейс для println, он уже видим по-умолчанию.
потому что это макрос
> У вас ус^Wrust отклеился.Рыжий суслик
Писал на нем движок рендеринга шаблонов (типа jinja), очень приятный язык, буду юзать дальше, как поопрятней станет. Но сдается мне, что Zig его сожрет.
Я тоже думаю что сожрёт.Сам пишу на Zig. Синтаксически похож на Zig (defer) при первом взгляде (и на JavaScript c let\const).
defer не только в зиг есть если что
Он вообще чувствуется как зиг, из которого повырезали фичи и добавили type unions из тайпскрипта. Но в тоже время он чувствуется элегантнее, чем зиг из-за вот этих type union и того факта, что expressions повсюду, даже фигурные скобки. В фиге надо лейблы к ним лепить, чтобы было так же. Хотя я с зигом только начал играться.
>type unions из тайпскриптаЯ бы тебе посоветовал вместо тайпскрипта начать учить настоящие языки. Standard ML, OCaml или Haskell, например. А то так и на раст со своими чулками для программирования перейдёшь.
То, что я знаю, что есть в тайпскрипте, не значит, что я на нем пишу. Я перепробовал много языков и сейчас остановился на харе и го. Я бы тоже тебе посоветовал расширять кругозор вместо демонстрирования своей узколобости.
Это быстрый язык! =)
Кстати, продаётся на дискетах!
> Кстати, продаётся на дискетах!Вот да, оно влазит на дискету целиком, без необходимости ставить 100мб llvm или ещё чего. Вот это инженерия с заботой о ресурсах, а не хипстоподелка.
Эй, луддиты, вы тут часом не с тостера сидите?? :)
С тостера под NetBSD, постим из lynx
> С тостера под NetBSD, постим из lynxА чё не QNX? Тоже в своё время "влазим-на-дискетку" хвалились :)
> Эй, луддиты, вы тут часом не с тостера сидите?? :)AMD Ryzen 5 5600X, 32GB RAM, 2TB nvme, пишу на хипстерском Go и вообще бесконечно далёк от луддизма, просто восхищаюсь реализацией. Флоппи диск продаётся не для того чтобы его куда-то вставлять, если что.
> Флоппи диск продаётся не для того чтобы его куда-то вставлять, если что.:))) Вот и я подумал, зачем людям в 21 веке дискетка! Ну точно куда-то вставляют! :))))
Строго говоря, размер компилера не имеет значения. Если LLVM позволяет таргетить под целую кучу платформ, да путь он хоть терабайт ест!! Лишь бы выходящие программы были маленькие и шустрые.
> Строго говоря, размер компилера не имеет значения.Перечитывайте классику, слушайте настоящих программистов: они скажут что размер программы (например компилятора) прямо связан с количеством багов в ней (попробуйте найти 3 в моём hello world ;-) ). Мой любимый пример - регрессия в LLVM из-за которой borrow checker в Rust работал не так, как ожидалось несколько выпусков подряд. Но из-за размера и сложности LLVM того сначала не замечали, а потом не могли починить.
> Если LLVM позволяет таргетить под целую кучу платформ, да путь он хоть терабайт ест!!
Дрю прямо сказал, что проблемы индейцев (пользователей несвободных ОС) его не волнуют, язык целится только в Linux и FreeBSD, так что не аргумент.
> Строго говоря, размер компилера не имеет значения.*Строго* говоря -- имеет. Если не в штанишки себе кодите, а организовываете, скажем, регулярные пересборки накоженого в создаваемом с нуля изолированном окружении.
Не говоря уже о менее очевидных последствиях нечеловекопостижимости.
Домашнее задание -- прочитать и осмыслить терабайт текста (вообще на любом языке).
Как!-то подозрительно! много !восклицательных знаков!
>> Note the ! operator which follows the function call: this is the error assertion operator.
> Как!-то подозрительно! много !восклицательных знаков!Ну да, внезапно, чтение из буфера и даже вывод в stdout могут "сломаться".
Нет. Слишком много вот этого: ::::::::
Так и хочется сказать "Харе клепать новые языки! У вас что, больше языков богу языков?"
Долистал до сюда чтобы первым это написать, но не успел.
На самом деле пусть клепают - это ПОЛЕЗНО. Как минимум, примером как НЕ НАДО делать! :)
Когда количество изученных языков начнёт зашкаливать (у меня их порядка 20+), количество переходит в качество и уже по внешнему виду начинаешь понимать, что с языком не так.
А что с ним не так и какие языки хороши?
> А что с ним не так и какие языки хороши?"не так" - то, что с виду это тот же Си, только с ::::::::: :)
Грубо говоря, рынку нахрен не нужны "те же Си, только в профиль"!
И нормальный язык уже сделали - это D - современный ООП подход, куча плюшек, только пользуйся!
У Ди одна проблема - куча клоунов в тырнетах, которым яйца танцевать мешают, а программировать на Ди они не хотят и ищут отмазки.
> У Ди одна проблема - куча клоунов в тырнетахОй, типа мы с Вами порой клоунами не оказываемся. Не мните шибко много :)
PS: в @e2k_chat нарисовался человек, отнёсший D на e2k, пока некоторые разглагольствовали.
Дык чего только хипстота не придумает, лишь бы Си не учить... (с)Видимо медиаплееры уже писать не модно, переключились на языки. Им бы в моду теперь браузеры подсунуть, пусть помучаются.
Кстати, netsurf кому-то даже может оказаться и по зубам, и на взаимную пользу.
> Кстати, netsurf кому-то даже может оказаться и по зубам, и на взаимную
> пользу.Вероятно, но сначала надо надавать по зубам жабоскриптерной хипстоте!
> main.haВот будет трололо если это окажется архив архиватора .ha - был такой :))
Натужная острота с целью показать своё знание древних архиваторов. Vanitas vanitatum, omnia vanitas.
Скорее мелкий троллинг на тему того что расширение файла можно и покреативнее выбирать, без коллизий. Мало букв в алфавите чтоли?
.hre
?
.hrю
Хрю
Можно и .hare - вы ж не будете под DOS 6 на этом прогать?! А остальное так то уже давно умеет больше чем 8.3
> Можно и .hare - вы ж не будете под DOS 6 на
> этом прогать?! А остальное так то уже давно умеет больше чем
> 8.3Три символа на расширение это признак элитности формата. А вообще - эта штука выглядит не самой плохой чтобы писать под ней для DOS.
> Три символа на расширение это признак элитности формата.Вообще тогда 1 символ круче всех. Как в .c/.s :)
> А вообще - эта штука выглядит не самой плохой чтобы писать под ней для DOS.
Нафига? В досе все равно защиты памяти нет и проч. Это нагибает многие допущения даже того же хруста - он предполагает MMU, а ежели этого нет он влет stack overflow могет закатить, с перезаписью остального не хуже сишки. И оно вообще умеет real-mode код x86 генерить?
Прошу прощения, проверка глазомера -- User294? :)
Откуда коллизии взяться-то? Или ты намерен исходники саоих нетленок хранить в одной директории с архивом фэхи su.books?
.ahahah
не натужней твоей демонстрации "знания" латыни
Пижон тут как раз ты - ещё один безусый носитель мёртвого языка.
Что за странная любовь к двойным двоеточиям?
Это они у плюсовиков научились. В принципе ничем таким особо не плохо, довольно типовой способ иерархической адресации конструкций яп.
Такими темпами скоро на клавиатуре появится новая кнопка - двойное двоеточие
> Такими темпами скоро на клавиатуре появится новая кнопка - двойное двоеточиеСкорее на мышке...
> Это они у плюсовиков научились.Надеюсь, не у перловиков.
> довольно типовой способ иерархической адресации
Точка - типовой способ иерархической адресации. Сам на плюсах часто пишу и "::" даже в его синтаксисе выглядит, как инородное тело. С++ можно простить - наследие прошлого, но в новых языках - зачем?
Так оно на глаз сразу отличается - видно, что уже реально какой-то новый язык программирования.
У си с этим тоже так то есть приколы. А -> не хотели для структа по указателям? :) И плюсы вроде не единственные кто так делает. А заодно это в отличие от точек в обычном тексте редко встречается.
Методы в структурах можно?
Можно, но только как указатели на функции (как и в си). Свою vtable тоже неси.
И указатель на структуру передавать ручками как в C ?
Ага
Указатель - просто число, какие могут быть с ним проблемы "передавать"???
А зачем его в каждую функцию структуры "закатом солнца вручную" передавать, когда это мог бы компилятор делать? Вот в V, похоже (после беглого ознакомления), так и сделано.
> Можно, но только как указатели на функции (как и в си). Свою
> vtable тоже неси.А эффективно вернуть из функции несколько параметров оно могет?
Да, tuples есть
> Да, tuples естьТак то вернуть struct я и из сей могу, но вот элегантно вернуть парочку независимых int'ов или там чего еще? Или даже небольшой массив? Ну то-есть симметрирование входа и выхода функций, чтобы более-менее равноправно было. Типа return (u32) nread, (u16) errcode, extra[10]? В допушении что прототип заявлен на возврат вот этого. Некоторые что-то сравнимое вроде могут. На сях это при желании struct делается, но не очнь удобно.
Просто сишники имеют обыкновение использовать пойнтеры на ВХОД функции для возврата сложных конструкций. Это криво хотя-бы потому что из этой декларации не очевидно реальное намерение программера - использование входа для декларации выхода все же криво.
Элегантнее тюплов пока ничего еще не придумали
> Элегантнее тюплов пока ничего еще не придумалиЯ вот не понимаю, какие принципиальные проблемы сделать список аргументов, как на вход, симметрично? Даже пусть они все и mandatory будут. И так же возвращать в регистрах/стэке/памяти/кому там что больше нравится, как входные аргументы.
Потому что неэлегантно
> Потому что неэлегантноНеэлегантно это когда вход и выход функции несимметричные имхо.
> Да, tuples естьНо QBE, насколько я понял, умеет возвращать только int или указатель.
use fmt;export fn main() void = {
const t = ret();
fmt::printfln("({}, {})", t.0, t.1)!; // prints (1, 2)
};fn ret() (u8, i32) = {
return (1, 2);
};
> use fmt;
> export fn main() void = {
> const t = ret();
> fmt::printfln("({}, {})", t.0, t.1)!;
> // prints (1, 2)
> };
> fn ret() (u8, i32) = {
> return (1, 2);
> };
00000000080000d8 <main>:
80000d8: 55 push %rbp
80000d9: 48 89 e5 mov %rsp,%rbp
80000dc: 48 81 ec 10 01 00 00 sub $0x110,%rsp
80000e3: e8 ae 01 00 00 callq 8000296 <ret>
80000e8: 48 89 85 f8 fe ff ff mov %rax,-0x108(%rbp)
80000ef: 8b 8d f8 fe ff ff mov -0x108(%rbp),%ecx
80000f5: 89 8d 00 ff ff ff mov %ecx,-0x100(%rbp)
...
<ret>:
8000296: 55 push %rbp
8000297: 48 89 e5 mov %rsp,%rbp
800029a: 48 83 ec 10 sub $0x10,%rsp
800029e: c6 45 f8 01 movb $0x1,-0x8(%rbp)
80002a2: c7 45 fa 02 00 00 00 movl $0x2,-0x6(%rbp)
80002a9: 48 8b 45 f8 mov -0x8(%rbp),%rax
80002ad: c9 leaveq
80002ae: c3 retq
> эффективно*кхе*
А че, LLVM может эффективнее генерить?
> А че, LLVM может эффективнее генерить?
#include <stdio.h>
#include <stdint.h>
struct tuple {
uint8_t val1;
int32_t val2;
};struct tuple ret(void) {
struct tuple vals = {1,2};
return vals;
}
int main(void) {
const struct tuple t = ret();
printf("%d %d", t.val1, t.val2);
return 0;
}% clang -O2 -S ret.c && more ret.s
ret: # @ret
.cfi_startproc
# %bb.0:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq %rsp, %rbp
.cfi_def_cfa_register %rbp
movabsq $8589934593, %rax # imm = 0x200000001
popq %rbp
.cfi_def_cfa %rsp, 8
retq...
main: # @main
.cfi_startproc
# %bb.0:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq %rsp, %rbp
.cfi_def_cfa_register %rbp
movl $.L.str, %edi
movl $1, %esi
movl $2, %edx
xorl %eax, %eax
callq printf
gcc -O2:
ret:
.LFB1:
.cfi_startproc
movabsq $8589934593, %rax
ret
.cfi_endproc
Ладно, зато QBE компилится за секунду. А вообще он обещает ~70% оптимизаций от GCC/LLVM, с чем я готов мириться за минимализм.
> Ладно, зато QBE компилится за секунду. А вообще он обещает ~70%
> оптимизаций от GCC/LLVM, с чем я готов мириться за минимализм.Хм... вообще штуки типа LTO могут выпилить добрую треть бинаря без каких либо потерь в скорости или функциональности. Оно делает глобальный анализ по всему коду вообще и дальше выносит повторные прогрузки регистров, доказуемо не вызываемые блоки кода, реюзает все что реюзается - и в итоге довольно нехило убавляет размер кода. Что как бы здорово. Особенно в системщине.
Так что на самом деле реализация на основе llvm или gcc - была бы очень интересной идеей. А это... оно бутстрапать себя умеет? Или как его собрать то?
Вообще было бы интересно собрать прототипчик на libgccjit, но мне лень с ним разбираться. Если до финализации спеки никто не сделает и они запилят borrow checker, то можно потыкать.> оно бутстрапать себя умеет? Или как его собрать то?
Там нечего бутстрапить, на с89 написан.
> Вообще было бы интересно собрать прототипчик на libgccjit, но мне лень с
> ним разбираться. Если до финализации спеки никто не сделает и они
> запилят borrow checker, то можно потыкать.На мой вкус лучше б в gcc полноценно заинтегрили что-то такое, вот так было бы очень инетерсно потыкать. Может даже накодив пару фирмварей "на поблевать", посмотреть сколько грабель я в процессе соберу.
> Там нечего бутстрапить, на с89 написан.
Что-то эти .ha из https://git.sr.ht/~sircmpwn/hare/tree на C89 не очень похожи... впрочем я уже нашел https://git.sr.ht/~sircmpwn/harec который таки на си, но таки C11...
Остался только 1 вопрос: а на C89 кто все-таки был? :)
QBE, я думал мы про бекенды разговариваем
let buffer: *[65535]u8
fmt::printfln("*x: {}", *x)!;
defer io::close(file)!;Ваш кролик пишет задомнапирёт
Your bunny wrote!
The Matrix has you.. Follow the white rabbit.
Его питон зажевал.
Выглядит как ASCII-порно
> ориентация на упрощение...
>без ... неявного поведенияЭти вещи несовместимые.
> Дрю ДеВолт (Drew DeVault), автор […] почтового клиента Aerc […]Первая строчка из README: «Notice: This project is unmaintained». С языком тоже побалуется ещё год и бросит как только что-то за пределами сэндбокса попытается запрогать?
→ https://git.sr.ht/~rjarry/aerc
Где ты увидел это?
https://aerc-mail.org/
https://aerc-mail.org/ -> source code -> https://git.sr.ht/~rjarry/aerc -> This is a fork of the original aerc by Drew DeVault. -> https://git.sr.ht/~sircmpwn/aerc -> Notice: This project is unmaintained.Т.е. проект то жив, но Drew DeVault в том, что он жив, не виновен.
Вот и с языком так будет — авось кто-нибудь форкнет как Дрю наиграется. А не форкнет, так и невелика беда — всё равно кроме hello world на нём ничего написано не будет.
Ещё не асм, но уже не далеко осталось
тем временем единственной заменой асма так и остается сишечка. сколько уже этих убивиц было. такое впечатление что они не понимают даже для чего нужен си, но вот для чего убивиц сей - не один доклад с клоунами и фокусами с бутылкой.
https://drewdevault.com/2021/02/21/On-the-traits-of-good-rep...
> тем временем единственной заменой асма так и остается сишечка. сколько уже этихЕдинственной заменой асма так и остается асм. Но ты всегда можешь показать MBR загрузчик или адресонезависимый код на сишечке.
C MBR так не очень получится, но это наполовину вопрос уродства x86. В более современной версии там так то UEFI уже и ESP. А на мелочи типа cortex M можно с места в карьер и на си. Даже без асмового стартапа - можно.А адресонезависимый код - какого черта? Это все компилеры давно умеют, -fpic и сотоварищи и компилер сам его сделает. Хотя возможны нюансы, но все же.
> C MBR так не очень получится, но это наполовину вопрос уродства x86.
> В более современной версии там так то UEFI уже и ESP.Т.е. классическое опеннетное "нельзя, но потому что уже и не очень нужно - не считается!".
> А адресонезависимый код - какого черта? Это все компилеры давно умеют, -fpic
> и сотоварищи и компилер сам его сделает. Хотя возможны нюансы, но все же.Оно перестало требовать, как минимум, _валидную_ таблицу офсетов (global offset table) для "адресонезависимости"?
> Т.е. классическое опеннетное "нельзя, но потому что уже и не очень нужно
> - не считается!".Типа того. Очень нишевой случай. Да и asm() в сях так то есть. Просто нестандартно :)
> Оно перестало требовать, как минимум, _валидную_ таблицу офсетов (global offset table)
> для "адресонезависимости"?А там разные варианты есть, см параметры компилера. Но нюансов все же можно огрести.
Тем не менее PIC нужнее на PC - на мелочи типа MCU для начала нет виртуальной памяти, все с физической памятью - а значит layout довольно таки фиксированный.
> Типа того. Очень нишевой случай.
> Да и asm() в сях так то есть. Просто нестандартно :)MBR - классический пример. Но да, asm() - хорошая замена асму, ага ...
>> Оно перестало требовать, как минимум, _валидную_ таблицу офсетов (global offset table)
>> для "адресонезависимости"?
> А там разные варианты есть, см параметры компилера. Но нюансов все же можно огрести.Т.е. нет (fPIC точно так же вызывает "соседнюю" функцию через got), но опять "не считается"?
Какая-то липовая замена (не говоря уж о том, что может потребоваться напрямую к регистрам или считать память по смещению) ...
> MBR - классический пример.Очень нишевой и не очень актуальный, Настолько, что в более современных платформах даже начальные загрузчики такого плана пишут на сях. На асме максимум небольшой кусочек стартапа. В опенсорсной реализации загрузчика RasPi нехорошие люди аж плюсоту воткнули. Прикинь?
> Но да, asm() - хорошая замена асму, ага
Типа того. На нем пишут "интринсики", небольшие куски типа стартапа, и проч а основная тушка на си. Чтобы не иметь удовольствие кодить на асме.
А bios редгад и винтел уже обозвали легаси. Федора даже его повыпилить хочет. Так что пример хороший но 20 лет назад смотрелся убедительнее. X86 real mode вообще откровенное легаси.
> Т.е. нет (fPIC точно так же вызывает "соседнюю" функцию через got), но
> опять "не считается"?Там есть опции типа танцев относительно регистра, как я понял он берется за базу и относительная адресация пляшет вокруг. Но если надо на x86, не дай боже 32-битном, на нем PIC в принципе нормально не получится. И проблема в том что у проца архитектура уродская: нормальной относительной адресации нет. А на арм можно и потрепыхаться - он умеет относительно регистра. В силу симметрии даже относительно program counter. Если обратить внимание армовские компилеры даже non-pic код любят так оформлять, перемешивая с константами. Чтобы эффективнее адресовать. И там есть отдельный руль что все константы в секцию RODATA не мешая с кодом, как на х86, ценой сильной потери эффективности. Права R-X на секцию не есть какая-то проблема и обычно никто не жалуется.
> Какая-то липовая замена (не говоря уж о том, что может потребоваться напрямую
> к регистрам или считать память по смещению) ...В общем случае в именно регистры, именно проца, именно неадресуемые как память соваться - ну такое себе очень отдельное и специфичное развлечение. Нужное лишь иногда.
На каком-нибудь Cortex M можно вообще без этого. Правда IRQ запретить/разрешить без асмового интринсика к глобальному флагу - криво, но вообще он взлетает, одним си без ничерта. Да, на си можно написать и startup самому себе. Внутрях него допущения не совпадают со стандартом.
А так на тебе фокус:
volatile uint32_t * hw_reg = (volatile uint32_t *) 0x100500;
* hw_reg = 10;И это, указатель менять можно, хоть по всей памяти шарься. Другое дело если там памяти нет или прав на запись нет - ну извини. Но тебе за это в тыкву и на асме так же прилетит. Именно так с железом и работают. Вот прям из сей. Оформляют регистры читабельными именами и ходят по их адресу. Вон то запишет 32 бита с числом 10 в адрес 0x100500. На чтение тоже работает, я так и читал койчей бутром - по адресу. В сях даже функции можно из таблицы кода на лету импортировать. Читаем таблицу, берем адрес, назначаем его указателю на функцию и - все, это можно вызывать как функцию с заявленным прототипом. Актуально если хочется себе нечто типа BIOS организовать, с импортом из него кода в основную прошивку например. А чтоб 2 раза тот же код не переть в бутлоадер и фирмвар например.
>> MBR - классический пример.
> Очень нишевой и не очень актуальный, Настолько, что в более современных платформах
> даже начальные загрузчики такого плана пишут на сях....
> Так что пример хороший но 20 лет назад смотрелся убедительнее. X86 real mode вообще откровенное легаси.Давай я напомню изначальное высказывание и подчеркну ключевое слово:
"единственной заменой асма так и _остается_ сишечка".
Я понимаю, в это трудно поверить - но это легаси было когда-то популярно.
>> Но да, asm() - хорошая замена асму, ага
> Типа того. На нем пишут "интринсики", небольшие куски типа стартапа, и проч
> а основная тушка на си. Чтобы не иметь удовольствие кодить на асме.Это вообще-то была ирония. Asm "встроенный" (или вызываемый), как бы, не перестает быть асмом.
>> Т.е. нет (fPIC точно так же вызывает "соседнюю" функцию через got), но
>> опять "не считается"?
> Там есть опции типа танцев относительно регистра, как я понял он берется
> за базу и относительная адресация пляшет вокруг. Но если надо на
> x86, не дай боже 32-битном, на нем PIC в принципе нормально
> не получится. И проблема в том что у проца архитектура уродская:Надеюсь, ты понимаешь, что агрументация получается в стиле "Здесь играем, здесь не играем, здесь рыбу заворачивали"?
>> Какая-то липовая замена (не говоря уж о том, что может потребоваться напрямую
>> к регистрам или считать память по смещению) ...
> В общем случае в именно регистры, именно проца, именно неадресуемые как память
> соваться - ну такое себе очень отдельное и специфичное развлечение. Нужное лишь иногда.Ключевое слово - code injection/shellcode. Никто не обещал "супер-широкий спектр применений" (и не выставлял как "единственную замену сям", в отличие от).
> А так на тебе фокус:
> volatile uint32_t * hw_reg = (volatile uint32_t *) 0x100500;
> * hw_reg = 10;...
> В сях даже функции можно из таблицы кода на лету импортировать. Читаем таблицу, берем адрес, назначаем его указателю на функциюФокус не очень - представь на секунду, что твой код не контроллирует все "от и до" (потому что в чужом процессе) и поэтому таблица не имеет фиксированного адреса времени компиляции, зато "стабильно" доступна по [REG+0x1005000].
>> А так на тебе фокус:
>> volatile uint32_t * hw_reg = (volatile uint32_t *) 0x100500;
>> * hw_reg = 10;
> ...
>> В сях даже функции можно из таблицы кода на лету импортировать. Читаем таблицу, берем адрес, назначаем его указателю на функцию
> Фокус не очень - представь на секунду, что твой код не контроллирует
> все "от и до" (потому что в чужом процессе) и поэтому
> таблица не имеет фиксированного адреса времени компиляции, зато "стабильно" доступна по
> [REG+0x1005000].Это, кстати, решается довольно просто. Адреса в таблице переходов можно пересчитать, определив текущий классическим:
call @f
@f: pop eaxЧто бы "уйти от ассемблера", Микрософт придумала интринсик _ReturnAddress() - то есть средствами "чистого Си" задача не решается.
> Давай я напомню изначальное высказывание и подчеркну ключевое слово:
> "единственной заменой асма так и _остается_ сишечка".Тот анон немного перегнул, конечно, но общую идею уловил верно, си попер из системщины асм, практически везде, даже в аттини и пиках, где не память а сплошной склероз.
> Я понимаю, в это трудно поверить - но это легаси было когда-то популярно.
Да оно и сейчас используется, однако кодинг бутсектора сейчас наверное все же не очень массовый сценарий и почему он должен кого-то сильно волновать - черт бы его знает, а?
> Это вообще-то была ирония. Asm "встроенный" (или вызываемый), как бы, не перестает быть асмом.
Вообще да, но если обозвать это "интринсиком" и сказать что нехай это implementation предоставляет, а caller шпрехает на чистом си, типа - читерство, конечно, но - распостраненное.
> Надеюсь, ты понимаешь, что агрументация получается в стиле "Здесь играем, здесь не
> играем, здесь рыбу заворачивали"?Я понимаю что если архитектура изначально относительную адресацию нормално не умеет, PIC на ней в принципе нормально не делается. А то что кто-то придумал костыли и хаки - достоинством архитектуры не является. Ну вот не делан x86 под PIC-код. Это одно из его архитектурных уродств, учтенных в более новых и продвинутых разработках. И лично мне проблемы 32-битного х86 уж простите, но не интересны. Из 32-битного мне CortexA/CortexM/RiscV разве что интересны. А о том х86-32 уродце я с удовольствием забуду как страшный сон.
> Ключевое слово - code injection/shellcode.
Это весьма специфичная область и вот там из-за специфичного "abi" и требований сишка... все же несколько не то, как минимум в "стартапе". Хотя если попереть на принцип, наверное можно что-то такое сделать используя техники применяемые в фирмварах и бутлоадерах. Там тоже ограниченое окружение с странными требованиями.
> Никто не обещал "супер-широкий спектр применений" (и не выставлял как "единственную
> замену сям", в отличие от).Да и полезность для человечества этого кейса - ну, так себе, вообще-то это все активно пытаются зарубить в системах, рантаймах и проч :)
> Фокус не очень - представь на секунду, что твой код не контроллирует
Ага, он троллирует, не иначе.
> все "от и до" (потому что в чужом процессе) и поэтому
> таблица не имеет фиксированного адреса времени компиляции,Да и хрен бы с ним. Можно и лукап сделать если знаем как. Ну там если это моя таблица я могу условиться что "лежит в адресе кратном 1024 байтам" и "в начале magic value". И тогда я ее и сканом могу найти. А если страшно еще и чексум добавить.
> зато "стабильно" доступна по [REG+0x1005000].
Если это в контексте шеллкода когда надо не порушить состояние регистров и оттуда что-то взять то да, там кусочек асма все же надо будет.
В сях вообще тугой контроль за именно ABI - все же не про него. Подразумевается что все вызовы используют одинаковый ABI, это уж ой. Нету в сях этой абстракции, да и не надо оно, даже в системщине. А как там хаксоры будут $%^ться с шелкодом интересно им. Нам же интересно как вас оттуда эффективнее послать чтобы это ресурсы не жрало :P
> C MBR так не очень получится, но это наполовину вопрос уродства x86.
> В более современной версии там так то UEFI уже и ESP.UEFI это 64 бита, где регистр стека называется RSP, а не ESP, как в IA32. При чём тут регистр стека? Точно, ни при чём, его ведь дядя настроил за более современного программиста. В каком месте оно на накопителе записано - вот это важно!
>> C MBR так не очень получится, но это наполовину вопрос уродства x86.
>> В более современной версии там так то UEFI уже и ESP.
> UEFI это 64 бита, где регистр стека называется RSP, а не ESP,
> как в IA32. При чём тут регистр стека?ESP тут, скорее всего = EFI system partition
> ESP тут, скорее всего = EFI system partitionАбсолютно. И там так то немелкое фирмваре загружает "программу" по большому счету. Без ограничений на 512 байтов. Ну и обычно это просто сишная прога собраная компилером, как и само уефи в массе своей, кроме раннего инита.
>> ESP тут, скорее всего = EFI system partition
> Абсолютно. И там так то немелкое фирмваре загружает "программу" по большому счету.
> Без ограничений на 512 байтов. Ну и обычно это просто сишная
> прога собраная компилером, как и само уефи в массе своей, кроме
> раннего инита.И что самое занятное - у меня про это написано после вопроса.
"При чём тут регистр стека? Точно, ни при чём, его ведь дядя настроил за более современного программиста. В каком месте оно на накопителе записано - вот это важно!"
>>> C MBR так не очень получится, но это наполовину вопрос уродства x86.
>>> В более современной версии там так то UEFI уже и ESP.
>> UEFI это 64 бита, где регистр стека называется RSP, а не ESP,
>> как в IA32. При чём тут регистр стека?
> ESP тут, скорее всего = EFI system partitionЕстественно. За риторическим вопросом у меня следует ответ, который забыли процитировать.
> C MBR так не очень получится, но это наполовину вопрос уродства x86.
> В более современной версии там так то UEFI уже и ESP....что более чем вторая половина в этом аспекте: http://mjg59.dreamwidth.org/4957.html :]
как будто они не понимают. короче, убивицы всегда впередсмотрящие. на них можно положиться. их нельзя оставить ни на минуту. они стерегут пещеру каждую секунду. каждую секунду они носят еду в центр стаи. всегда на морде пишут свое полное имя и номер части. там ведь большая часть, ну, что уж такое случилось - могут и наброситься. нужно отслеживать. так ведь нельзя. они едят всегда. едят все подряд. чуть что - едят. и никогда не беспокоятся о своих правах. ну, да - это из-за сишечки, да.
>тем временем единственной заменой асма так и остается сишечкаСамой близкой заменой асма является ASM. Но ASM машинозависим, поэтому на роль универсального асма претендует... Встречайте, WASM!
flat assembler g ничего не знает про машинные команды, их надо самому макросами описывать :)
> Самой близкой заменой асма является ASM. Но ASM машинозависим, поэтому на роль
> универсального асма претендует......сишка :) //fix
>и фокусами с бутылкойДело BottleRuby живёт.
Ну реально же уже харе. Зачем нам еще один раст?
Это нифига не раст, раст собирается на моём железе часа два, а "это" - в районе минуты.
Для умственно отсталых пожалуйста поясните - почему вместо массовых крестиков нужно брать ушастого ?
Только одно объяснение приходит в голову - чтоб враг не догадался.
А оно и есть для умственно отсталых. Никто кроме автора на этом писать не никогда будет. Новости уровня "сегодня васян делал это левой".
хихи :)) Никто писать не будет - тут согласен. Слишком неочевидное "преимущество" над Сями, которые есть практически везде и шатко-валко стандартизованы.
Потому, что крестики больны тем же, чем болен C:
* UB и фактической невозможностью писать корректный код
* сломанным синтаксисом который сложно парсить (и даже ещё хуже чем C)
Харе языки изобретать! Го на асм!
go tool objdump -s main.main main
Синтаксис страшный. Имхо у других еще "не взлетевших" языков убийц-сишки типа zig синтаксис получше.
> Синтаксис страшный.Чем страшный-то? Вполне лаконичный, разумно использующий "суффиксы" вместо наворачивания тонн ключевых слов.
Что только люде не делают, чтобы не изучайть по-нормальному божественный язык С (которому только и надо что отказаться от препроцессора и некоторых других небольшого числа неоднозначных возможностей, как это сделано в Misra C).
Именно "божественность" языка С является одной из причин, по которой люди создают новые языки.
Поработали с С, перекрестились, и решили что надо что-то с этим делать.
> Что только люде не делают, чтобы не изучайть по-нормальному божественный язык С
> (которому только и надо что отказаться от препроцессора и некоторых других
> небольшого числа неоднозначных возможностей, как это сделано в Misra C).Ну, понимаешь, у божества так то тоже свои приколы есть.
1) А кто такое int и сколько в нем битов? А, получив vuln в репу в чужом коде узнаем? Особенно если у вон той платформы проц не х86? Вон на абдурине int может и 16 битов быть. А чо, стандарт позволяет. Сколько кода при этом сглючит? Чуть менее чем весть?
2) За integer promition кого-то надо было бы немного убить. Потому что иногда делает крайне контринтуитивные вещи. А если ты думаешь что крут, попробуй -Wconversion в гцц и шланге, узнаешь много нового о своем коде и проблемах в нем.
3) Какой у enum вообще целочисленный тип? Ах, unspecified? Отлично. Ох, #define имеет свое мнение об int'ах, отличное от? А (1 << 31) может сделать не то о чем вы подумали? Ага, 1 и 1U две большие разницы. Удобно, б...
4) Пункт 2) ведет к совершенно идиотским выходкам программистов, не желающих греть мозги этим факапом. И вот уже прогер пишет ... array[index]... - и оказывается что index мало того что int, так еще в функцию снаружи caller'ом отдается, и это вообще ни верифицируется толком, зато когда caller делает что-то странное, оно такие интересные адреса потом дереференсит...
5) Язык местами недостаточно аннотирован для статического анализа. Операции с указателями вообще проверкам плохо поддаются. Иногда это неизбежность но 90% случаев можно заткнуть. Прошареные сишники делают эрзац этого как умеют, но почему бы не сделать это нормально?
6) Макросня в сях может вас поиметь. Нет, она реально может вас поиметь. Поэтому макросы у прошареных сишников состоят из скобок чуть менее чем полностью. А кто хочет элегантный код, получает потом вулны в репу.
7) Ну, блин, ок, как вы эффективно возвращаете несколько значений из функции? А чтоб это намерение еще и анализерам нормально задекларить? Не, вон тот void func (ptr* param) это нихрена не аннотация чего вы хотели сделать. Он вообще void возвращает. И errno так то тоже - хак.А MISRA так то да, но некоторые вещи там довольно забавные или спорные. Есть еще с полдюжины стандартов, от CERT до Embedded C. В силу условности стандартов это компилеры не чекают как есть, разве что внешние тулы.
1. Понимаешь, на форумах надо обращаться друг к другу на Вы, даже если ты щколота голимая, а я почесываю свои седые яйцы и учу внуков арифметике.2. Остальное Ты перечислил более-менее вразуметельно, но не совсем полно - но это и не задача форума здесь не комитет по языку С. У языка C имеются родовые травмы и приобретенные иииотизмы, но они вполне устранимы. И для этого не надо выдумывать какой-то новый синтаксис или язык. Достаточно пересмотреть язык С и убрать из него все механизмы потенциальных багов и дыр.
> 1. Понимаешь, на форумах надо обращаться друг к другу на Вы, даже
> если ты щколота голимая, а я почесываю свои седые яйцы и
> учу внуков арифметике.А в фидохе например (НеШколота про него вообше слышала?) обращение на вы было показательным хамством. И тут можно и не угадать. Так что предлагается на этом не зацикливаться.
> 2. Остальное Ты перечислил более-менее вразуметельно, но не совсем полно - но
> это и не задача форума здесь не комитет по языку С.А комитет по языку си ручник отпускает медленно и неохотно. И небольшого пендаля им не лишне для ускорения. Чем вон те и занимаются.
> У языка C имеются родовые травмы и приобретенные иииотизмы, но они
> вполне устранимы. И для этого не надо выдумывать какой-то новый синтаксис
> или язык. Достаточно пересмотреть язык С и убрать из него все
> механизмы потенциальных багов и дыр.Проблема в том что он такой с существующим кодом будет не особо совместим, а раз пошла такая пьянка, ну вон они и навешивают еще кучу всего. Некоторое даже не так уж глупо, типа borrow checker'а или compile-time вычислений. На вот именно чистых сях можно изобразить какое-то отдаленное половинчатое приближение к этому, не более.
Сразу за 1 пункт: ардуинщиков не прилетай, это уровень лего игрушек, которые только копируют код. Люди используют явные uint32, где это нужно и int там, где точно влезет, чтобы, высокоабстрактный ты наш, код работал эффективнее по размерам регистра! В особых случаях, можно сделать такую штуку как ifdef индивидуально для платформы, которой в ваших игрушечках нет.
> Сразу за 1 пункт: ардуинщиков не прилетай, это уровень лего игрушек,Хорошо, пусть это будет чистый "AVR-GCC" без либ абдурины и суровый олдскульный эмбедер. Можно подумать это как-то влияет на свойства платформы и компилера, они ж те же самые.
> которые только копируют код. Люди используют явные uint32, где это нужно и
> int там, где точно влезет, чтобы, высокоабстрактный ты наш, код работал
> эффективнее по размерам регистра!Ага, только на AMD64 у меня регистры 64 бита а sizeof(int) почему-то 4. Так что теория про по размеру регистра тоже ну так себе весьма.
И попытка вот так оптимизнуть код который писали не вы чревата жирным факапом в математике, мало кто из прогеров рассматривает вариант что int может быть 16 битов. Хоть оно ничему не противоречит и по стандарту ОК.
> В особых случаях, можно сделать такую штуку как ifdef индивидуально для платформы,
> которой в ваших игрушечках нет.Больше уродского нечитаемого кода богу уродского нечитаемого кода. Когда сильно надо - могут и отдельную имплементацию так то сделать, хоть на голом асме, но так то плюс сей - портабельность, и ifdef несколько убивает этот плюс. Например, придется майнтайнить _ДВЕ_ реализации и держать их в синхронизме. Поле для багов если вон тот алгоритм решено поменять. Можно в одном месте сменить а в другом нет. Или логика разная выйдет. А потом сильно дальше оно отъедет. Что хуже, комбинаторный взрыв очень быстро приведет к тому что все варианты комбо проверить не получится и где-то оно все же развалится.
1. int был в С с самого рождения. Так и остаётся до сих пор (ну не выкидывать же). В С++ для обхода этой неопределенности добавили intXX_t, int_leastXX_t, int_fastXX_t. Скорее смысл int - оптимальный тип для целочисленных вычислений со знаком (для беззнаковых соответственно unsigned int).
2. Промоушен до int, как раз следует из того, что в int быстрее всего будут выполняться арифметические операции. Хочется больше контроля над диапазоном арифметики, надо использовать, например, int_fastXX_t.
Ващет в сях, начиная с еще аж 99-й версии, есть uintXX_t из <stdint.h>. Они же и в плюсах юзабельны. А майкрософтовский кодер юзающий плюсоту только за то что в msvc реализация си хтонически убога - совсем не палится :)
Да, сорян! Действительно типы intXX_t, int_leastXX_t и int_fastXX_t появились в C, начиная с C99. Я начинал программировать сразу на C++, поэтому этот момент как-то упустил. Микрософт здесь не причём.
> Misra CПочему не SPARK?
Потому что SPARK из другой оперы.
Из какой другой?
Опера та же - написание правильных программ.
В MISRA не используется препроцессор? Не знал. А как там обрабатывают #include?
Про препроцессор написал я - это лично мое мнение. В MISRA,FRAMA и т.д. имеются другие полезные правила, делающие С более безопасным.
>которому только и надо что отказаться от препроцессораТы не старший аноним, ты личинка растомана.
> полное доверие к действиям программистанекоторых жизнь ничему не учит.
Что ж они не додумаются парсить по пробелам?
Эти бесконечные {{{}}}};;;;;; больше путают чем помогают.
Ну и амперсанды с восклицательными знаками превращают все в кашу.Как и с растом не вижу смысла менять один вырвиглазный синтаксис на другой.
> Что ж они не додумаются парсить по пробелам?То что в результате тапнешь пару раз пробел или бэкспейс случайно, засэйвишь... ухтыблин?!?
А с () {} ты таки случайно логику не ломанешь. Если стереть скобку или лишнюю влепить, COMPILE ERROR и сразу понятно что что-то пошло не так.
Питонистам про системщину вообще лучше не пищать, у них статический анализ а дауне, а все ашипки случаются рантайм. Представьте себе кернел который при случае вываливается нахрен с исключением, поймете почему это людям не нравится.
О пробелах.Вот вот, ПО на Питоне как правило не обрабатывает ошибки, ибо это даже не трехъэтажным кодом пахнет, а из за многгсловности это почти всем лень.
А, обработка ошибок, это не прикрыть програмным гарниром исключения, и выплеснуть в лог, при падении ПО.
Пользователю не нужно знать почему ПО упало, чем подавилось при разборе данных, нужно стабильное ПО, устойчивое у намеренным и случайным ошибкам.Как перенавороченный скриптовый язык, Питон удобен, и прост, но когда на нем делают что большое, то поддержка живет до увольнения автора. Не то что б никто больше разобраться не может, могут, но ответствеено гаррантировать, и тем более серьёзному заказчику - нет.
Пробелы и отступы - топку.
Нормальные языки форматируются в IDE под любые желания без потери работоспособности.
>[оверквотинг удален]
> даже не трехъэтажным кодом пахнет, а из за многгсловности это почти
> всем лень.
> А, обработка ошибок, это не прикрыть програмным гарниром исключения, и выплеснуть в
> лог, при падении ПО.
> Пользователю не нужно знать почему ПО упало, чем подавилось при разборе данных,
> нужно стабильное ПО, устойчивое у намеренным и случайным ошибкам.
> Как перенавороченный скриптовый язык, Питон удобен, и прост, но когда на нем
> делают что большое, то поддержка живет до увольнения автора. Не то
> что б никто больше разобраться не может, могут, но ответствеено гаррантировать,
> и тем более серьёзному заказчику - нет.Сам придумал лошадь, сам притянул ее за уши и прилепил хвост, в итоге заявляешь что слон посудной лавке не подходит. Ни о питоне, ни об обработке ошибок, ни тем более что нужно пользователю я не говорил и к теме не относится.
> Нормальные языки форматируются в IDE под любые желания без потери работоспособности.
Отлично, тогда для тебя не составит никаких проблем заменить в IDE пробелы на скобки.
> Сам придумал лошадь, сам притянул ее за уши и прилепил хвост, в
> итоге заявляешь что слон посудной лавке не подходит.Я душу лошадей, а не придумываю.
Хотите пример говнокода на Питоне?
ПО для 3D принтеров - Cura.
Ладно хоть исходник с прогой идет и читаем.
А то, ПО в бинарниках не всякое излечимо.
>> Сам придумал лошадь, сам притянул ее за уши и прилепил хвост, в
>> итоге заявляешь что слон посудной лавке не подходит.
> Я душу лошадей, а не придумываю.
> Хотите пример говнокода на Питоне?
> ПО для 3D принтеров - Cura.
> Ладно хоть исходник с прогой идет и читаем.
> А то, ПО в бинарниках не всякое излечимо.Ты больной? Зачем ты предлагаешь мне посмотреть на !@#$% на питоне? Почему ты вообще стал про питон писать?
> даже не трехъэтажным кодом пахнет, а из за многгсловности это почти всем лень.На питоне пишут чтобы как можно быстрее от этого отделаться. Какая к черту обработка если они свое суперценное время экономят? Слить кал клиенту, забыть как стращный сон, следующий пшел, i++.
> А, обработка ошибок, это не прикрыть програмным гарниром исключения, и выплеснуть в
> лог, при падении ПО.Прикольно так, универсальные рецепты для всего. А что если выплескивать некуда? Мало ли, фирмвара какая, у нее в лучшем случае уарт дебажный и в эксплуатационном режиме его никто не читает.
> Пользователю не нужно знать почему ПО упало, чем подавилось при разборе данных,
> нужно стабильное ПО, устойчивое у намеренным и случайным ошибкам.С этим никто особо и не спорил, кроме вебмакакеров которым порой топор в экран втыкают за хорошую работу их кода благодарные пользователи.
> Как перенавороченный скриптовый язык, Питон удобен, и прост, но когда на нем
> делают что большое, то поддержка живет до увольнения автора.Как показал пример гвидо :)) иногда автор может заколебаться и самоуволиться сам, ниасилив разрулить самоорганизованый гадюшник.
> Пробелы и отступы - топку.
Во во. Это из той же области что отсутствие типов в JS. Круто писать мелкую хомпагу. А большой проект начинает делать хню, непонятно что, где и почему. При том типизированный яп поймал бы левак сразу, а тут, вот, работает себе в ус не дуя - делает какой-то бред. Где-то сильно дальше логика отъезжает - но понять что и где не так то просто. Это ж не ошибки, все действия формально валидны. А то что прогер имел в виду не это - яп не дал ему нормальные средства аннотации что он хотел, и кто его знает что там задумано было.
> Нормальные языки форматируются в IDE под любые желания без потери работоспособности.
Просто вот именно скобки таки проверяют что границы логического блока именно такие как это имел в виду програмер, а не то что там стерли немного необдумано или что-то не то и не туда воткнули, и оно даже что-то вроде делает - и ошибок так то нет. Поэтому питонист обычно узнает о факапе не просто в рантайме, но еще и когда это уже у пользователя и упало где-то в середине работы. Что как минимум очень бесит. А как максимум - в критичных применениях такой софт никуда не годится.
>> Что ж они не додумаются парсить по пробелам?
> То что в результате тапнешь пару раз пробел или бэкспейс случайно, засэйвишь...
> ухтыблин?!?
> А с () {} ты таки случайно логику не ломанешь. Если стереть
> скобку или лишнюю влепить, COMPILE ERROR и сразу понятно что что-то
> пошло не так.Точно также как и с пробелами. Никакой разницы. Только со скобками ты расставляешь {} для компилятора И пробелы для себя, а с пробелами сразу для обоих. И не мучаешь ни себя, ни компилятор лишней когнитивной нагрузкой.
> Питонистам про системщину вообще лучше не пищать, у них статический анализ а
> дауне, а все ашипки случаются рантайм. Представьте себе кернел который при
> случае вываливается нахрен с исключением, поймете почему это людям не нравится.Логическая ловушка не засчитана. Парсинг никак не связан с особенностями интерпретатора и компилятора. Ничего не мешает использовать пробелы вместо скобок. Скобки нужны в исключительных случаях (и то не факт), а скобки по умолчанию просто мусор дублирующий пробелы.
> Точно также как и с пробелами. Никакой разницы. Только со скобками ты
> расставляешь {} для компилятораЯ ими маркирую границы логических и структурных блоков, как правило имеющих какой-то самодостаточный смысл. Если эти границы нарушены - я знаю что где-то вышел нетривиальный факап и это место в коде точно требует усиленного внимания и проверки.
> И пробелы для себя, а с пробелами сразу для обоих. И не мучаешь ни себя,
> ни компилятор лишней когнитивной нагрузкой.К сожалению этот способ маркировки блока кода не поймает вышеупомянутые факапы. А вот по части скобок компилеры довольно привиредливы: должно совпадать, 1 в 1. Лишняя или недостающая скобка фатальны и рушат сборку. Случайно продолбаться так чтобы парность сохранилась - маловероятно. А с пробелами достаточно selection покилять или пробел необдумано тапнуть.
> Логическая ловушка не засчитана. Парсинг никак не связан с особенностями интерпретатора
> и компилятора. Ничего не мешает использовать пробелы вместо скобок. Скобки нужны
> в исключительных случаях (и то не факт), а скобки по умолчанию
> просто мусор дублирующий пробелы.Системщикам просто не нравятся дурные факапы на ровном месте, они предпочитают компилер который будет ловить явные продолбы. Туда же и статические типы. Да, аннотирование намерений требует добавочно попечатать. Зато не требует потом пытаться отдебажить хрен знает что неизвестно где лишний раз.
> Я ими маркирую границы логических и структурных блоков, как правило имеющих какой-то
> самодостаточный смысл. Если эти границы нарушены - я знаю что где-то
> вышел нетривиальный факап и это место в коде точно требует усиленного
> внимания и проверки.Ты также можешь пробелами и переносами маркировать логические и структурные блоки и без лишних отвлекающих символов.
> К сожалению этот способ маркировки блока кода не поймает вышеупомянутые факапы. А
> вот по части скобок компилеры довольно привиредливы: должно совпадать, 1 в
> 1. Лишняя или недостающая скобка фатальны и рушат сборку. Случайно продолбаться
> так чтобы парность сохранилась - маловероятно. А с пробелами достаточно selection
> покилять или пробел необдумано тапнуть.
> Системщикам просто не нравятся дурные факапы на ровном месте, они предпочитают компилер
> который будет ловить явные продолбы. Туда же и статические типы. Да,
> аннотирование намерений требует добавочно попечатать. Зато не требует потом пытаться отдебажить
> хрен знает что неизвестно где лишний раз.Ты сначала топишь за тяпляпность типа сделать лишний пробел это запросто, нормально и должно быть обязательно прощено. Но тут же топишь за явное аннотирование, фатальность при отсутствии символа и ранний дебаг.
Причем пробелы это второй вариант (подталкивает к аккуратности)(хотя ты конечно подразумевал наоборот). А скобки это первый (подталкивает к разгильдяйству).
Но даже если смотреть с позиции разгильдяя, то 4 пробела все равно лучше чем парные кавычки. Парные кавычки вполне возможно (хотя и сложно) нажать случайно (4 раза нажать пробел ИМХО сложнее, а нажать по 4 раза на каждой строчке в блоке еще тяжелее), да и расположение пробела на большинстве клавиатур существенно удобнее чем расположение клавиш кавычек (а в некоторых их и нет в первом слое), обычно не видно где кавычки начинаются и где кончаются (и соответственно какой блок ты читаешь, в отличии от пробелов), нередко их дополняют клавиатуры и IDE(что там про явное аннотирование?), новички часто бесятся из-за них и начинают пихать их как попало лишь бы скомпилилось, опять же в разных стилях кавычки ставятся по-разному (в конце или на следующей строке) что сильно влияет на читаемость в разных проектах, в конце концов кавычки занимают лишние символы и строки, что опять же влияет сколько кода ты можешь просмотреть без прокрутки. Зачем все эти проблемы? Они правда тебе нужны?
> Ты также можешь пробелами и переносами маркировать логические и структурные блоки и
> без лишних отвлекающих символов.Так оно не ловит мелкие факапы когда намерения и то что есть по факту разошлись. Ну, мало ли, хотел я стереть вон то, но было выделение и стерлось не то что я планировал. А тут меня что-то отвлекло, например, и это было прошляплено.
В curly bracket я при нарушении границ блоков поимею компил егор и пойду детально разбираться что и почему у меня отъехало. Зная что тут совершенно точно какая-то лажа и надо детально все проверить. А в вон том случае - логика тихо отедет. Без всяких егоров. А потом, когда все уже собрано, запущено и типа-работает - я может быть узнаю что оно фигню творит. Если не повезет, в редкой ветке, узнаю через годик, когда оно внезапно обгадится - в ситуации когда я даже не знаю как вычислить где оно такое красивое.
А сами по себе пробелы за меня так то большая часть прогерских редакторов сами влепит, мне достаточно как раз намерения сделать блок скобками отметить - и все. Форматирование даже несложные редакторы так то могут. Более того - в curly bracket так то и полный reflow кода можно, автоматикой, попробуйте так с вашими пробелами ваще...
> Ты сначала топишь за тяпляпность типа сделать лишний пробел это запросто, нормально
> и должно быть обязательно прощено. Но тут же топишь за явное
> аннотирование, фатальность при отсутствии символа и ранний дебаг.Я топлю за то чтобы ловить максимум факапов в компилтайме/аналитике, чтобы это меня не имело в рантайме.
> Причем пробелы это второй вариант (подталкивает к аккуратности)(хотя ты конечно подразумевал
> наоборот).Есть antibug технологии, помогающие вычислить явно кривые действия человека. Пробелы таковыми не являются, а скобки - вполне.
> А скобки это первый (подталкивает к разгильдяйству).
С какого бы раза? Они лишь помогают поймать явную лажу если она все же вышла. И так то код на питоне дохнет с жутким трейсом чуть менее чем на любой пшик, не им про разгильдяйство вещать. Ладно б там хрустики вылезли но у них curly bracket.
> Но даже если смотреть с позиции разгильдяя, то 4 пробела все равно
> лучше чем парные кавычки.Намного хуже - при редактировании напортачить проще. А вот парные элементы случайно сделать корректно - довольно маловероятно. А какого бы черта теорвер не должен быть в мою пользу?
> Они правда тебе нужны?
Мне нравится визуальное выделение блоков и то что автоматика проверит парность элементов, делая хотя-бы минимальный чек что это хотя-бы похоже на задеклареное намерение и что оно не было случайно порушено. ИМХО делать логику пробелами - неудачный антипаттерн с точки зрения отлова явных багов.
> Так оно не ловит мелкие факапы когда намерения и то что есть по факту разошлись. Ну, мало ли, хотел я стереть вон то, но было выделение и стерлось не то что я планировал. А тут меня что-то отвлекло, например, и это было прошляплено.Почему вы упорно считаете что лишний/удаленный пробел это нормально? Почему вы считаете что плохо отформатированный код должен запускаться?
Ну разошлись ваши намерения и ваш тремор рук, получите ошибку, сразу ее исправите. Даже лучше чем со скобками где этот пробел найдете уже при проверке линтером.> В curly bracket я при нарушении границ блоков поимею компил егор и пойду детально разбираться что и почему у меня отъехало.
С пробелами тоже самое, только еще строже.
> Зная что тут совершенно точно какая-то лажа и надо детально все проверить. А в вон том случае - логика тихо отедет. Без всяких егоров. А потом, когда все уже собрано, запущено и типа-работает - я может быть узнаю что оно фигню творит. Если не повезет, в редкой ветке, узнаю через годик, когда оно внезапно обгадится - в ситуации когда я даже не знаю как вычислить где оно такое красивое.
Не, это так не работает. Во-первых, вы не можете где угодно указать блок, как не можете где угодно поставить фигурные скобки. Просто получите ошибку как и со скобками. Во-вторых, вы сами обозначаете разделитель. Если вы пишите большой скрипт, то ставите 4 пробела. Если вы случайно поставите 4(!) пробела, то вы также случайно сможете и кавычки поставить. Если вы сделаете 1-3 или 5+ пробелов то получите ошибку. В-третьих, если вы пишите большой серьезный код, то добавьте линтер, он вас еще и новую строку заставит по стандарту ставить после блока. Так что шансы ошибиться и добавить/убавить пробел стремятся к нулю. А шанс запутаться в {{{{}}}}} (парные? уже посчитали? с пробелами это сразу видно) и вовсе нулевой.
> > А сами по себе пробелы за меня так то большая часть прогерских редакторов сами влепит, мне достаточно как раз намерения сделать блок скобками отметить - и все. Форматирование даже несложные редакторы так то могут.
Тем более. Зачем вам в таком случае лишние символы в виде скобок?
> Более того - в curly bracket так то и полный reflow кода можно, автоматикой, попробуйте так с вашими пробелами ваще...
За вас редакторы итак эти пробелы ставят, почему же вы считаете что в других случаях автоматика не справится? Это абсолютно такой же разделитель как скобки, автоматика работает точно также.
> Я топлю за то чтобы ловить максимум факапов в компилтайме/аналитике, чтобы это меня не имело в рантайме.
Тогда вы должны топить за пробелы, потому что они именно это и делают.
> Есть antibug технологии, помогающие вычислить явно кривые действия человека. Пробелы таковыми не являются, а скобки - вполне.
Как раз наоборот. Если делать по стандартам с автоформатированием то и то и другое прекрасно справляется, только пробелы чище, компактнее, понятнее. Но если делать без форматирования то пробелы не позволяют вольностей, а скобки позволяют. Опять же пробелы ставятся однозначно, со скобками как миниум есть 2 распространенных стандарта как ставить скобки. Даже если вы договорились ставить скобки на той же строке, не факт что в проекте который вы используете, не делают по-другому.
> С какого бы раза? Они лишь помогают поймать явную лажу если она все же вышла.
Скобки: Лишний пробел поставил. Лажа, форматирование страдает. Все собирается и работает, отправляется в продакшн.
Пробелы: Лишний пробел поставил. Лажа, ничего не собирается, иди дорабатывай.Скобки: Нарушил форматирование, указал скобки в конце строки через тучу пробелов, ревьювер не заметивший горизонтальную прокрутку этого не заметил (что есть еще пробелы не видит), бэкдор внедрен (антибаг технологии, ага)
Пробелы: Такое в принципе невозможно, потому что разделитель однозначно определен и в начале строки.> И так то код на питоне дохнет с жутким трейсом чуть менее чем на любой пшик, не им про разгильдяйство вещать. Ладно б там хрустики вылезли но у них curly bracket.
Опять попытка увести разговор в сторону. У питонистов трейс на любой пшик не из-за пробелов. Но мы сейчас про пробелы говорим, а не про методику обработки исключения и питоновскую философию.
> Намного хуже - при редактировании напортачить проще. А вот парные элементы случайно сделать корректно - довольно маловероятно. А какого бы черта теорвер не должен быть в мою пользу?
Ну и определенное число пробелов наклепать в нужном месте тоже весьма маловероятно.
> Мне нравится визуальное выделение блоков
Вы визуально выделяете блоки не скобками, а пробелами, даже если используете скобки.
> и то что автоматика проверит парность элементов, делая хотя-бы минимальный чек что это хотя-бы похоже на задеклареное намерение и что оно не было случайно порушено.Вы же выше сами же пишите что автоматика же эту парность и делает. То есть ваши намерения с автоподстановкой скобок это нажать '{'(один случайный символ). Без автоподстановки это два символа '{' '}' в разных местах(фактически 3 случайных символа с учетом навигации). С пробелами без автоподстановки вам нужно сделать 4 случайных символа, а то и больше.
> ИМХО делать логику пробелами - неудачный антипаттерн с точки зрения отлова явных багов.
ИМХО разделять код на логический и визуальный - неудачный антипаттерн с точки зрения отлова явных багов
> Почему вы упорно считаете что лишний/удаленный пробел это нормально?Потому что людям свойственно ошибаться и вон то - легко посадить при кодинге случайно, не имея на самом деле в виду. Явная маркировка начала-конца логического блока позволяет ловить немало дурных случаев такого плана, когда оно вдруг бай и не совпадает. Ну как, если например я пробел тапнул на выделении - и там даже улетел какой-то кусок блока, шансы что в выделении идеально убьется по парным скобкам и ошибки не будет - мизерный. Значит я буду тут же послан компилером, пойму что все испортил и пойду разбираться.
> Почему вы считаете что плохо отформатированный код должен запускаться?
Ну я бы в принципе кидал бы компил варнинг при подозрительном форматировании, а с точки зрения приоритетов меня корректность поведения кода и его соответствие задумке волнует все же больше эстетики. Поэтому вот так.
> Ну разошлись ваши намерения и ваш тремор рук, получите ошибку, сразу ее
> исправите. Даже лучше чем со скобками где этот пробел найдете уже
> при проверке линтером.А при чем тут тремор рук, если в редакторе селекшн был, я про него забыл и что-то тапнул? Ну и получил что-то unspecified вместо того чего на самом деле хотел. И таки очень кстати если автоматика поймает подозрительное место и сообщит что я сделал фигню.
То-есть это не отменяет нужды быть внимательным самому. Но компьютер должен помогать человеку, а не только п-лями в стойло его строить.
Смотри, в сях например указатели это кусок проблем если быть невнимательным. И там проблемы в том числе и с анонсом намерений дла анализа/компилера. Но кроме минусов есть плюсы. Это дико эффективная технология. Избегающая лишних копирований - что актуально, особенно на больших объемах данных или если скорость критична. Поэтому tradeoff: мы теряем в надежности, но получаем быстрый компактный код. А у тебя - не tradeoff. Оно только делает мозг, ставит в стойло, но ничего не привносит. Значит нафиг.
А что до печати - не, в програмерских эдиторах лишних кнопок жать может и не требоваться, при намерении слепить блок он может и автоматом с парой скобок и потребным форматированием (например вычисленным по позиции 1-й скобки) быть сделан. Так что это проблема для юзеров ноутпада, которые все-равно много не напрогают. Хотя-бы за отсутствием подсветки синтаксиса.
> С пробелами тоже самое, только еще строже.
При том эта строгость ничего кроме эстетики не привносит. Я не вебмакака чтобы в стойло становиться ради декоративно-эстетических целей. Если там будет что-то системное, крутое, можно подумать.
> Не, это так не работает.
Ну, вообще, это по моему опыту. Если меня заворачивают с скобкой - я таки где-то напортачил и скорее всего логика поломана и надо детально все перепроверять.
> Во-первых, вы не можете где угодно указать блок,
Вообще-то в сях - можно почти где угодно, так что при желании независимые логические блоки можно явно хайлайтить чуть активнее чем это обычно делают. Это не значит что это всегда нужно делать. Оформлять блок имеет смысл там где ... уместен логически выделенный блок, более-менее самодостаточный. Но если хочется - можно и по приколу почти везде делать. Но лучше не выпендриваться, код должен быть понятен другим, все что сверх того - нафиг надо.
> как не можете где угодно поставить фигурные скобки. Просто получите
> ошибку как и со скобками.Вы вообще на сях программировали?
> Во-вторых, вы сами обозначаете разделитель. Если
> вы пишите большой скрипт, то ставите 4 пробела.Я стараюсь не писать большие скрипты, предпочитая *никсвэйный подход. То есть небольшие эффективные качественные программы, при нужде объединяемые небольшими скриптами по месту. Модуляризация. Конечно это не всегда катит. Но мудрость в идеях древних есть. В отличие от вебмакак и питоняш, от которых если мне что и надо - чтобы они перестали замусоривать поиск своими поделиями.
> Если вы случайно поставите 4(!) пробела, то вы также случайно сможете и кавычки поставить.
Так если я левые кавычки/скобки влеплю - буду послан. Их надо именно парно вкатить/стереть, и вероятность нечаянно сделать в виде когда оно будет сожрано как что-то валидное довольно низкая. В этом весь пойнт и состоит.
> Если вы сделаете 1-3 или 5+ пробелов то получите ошибку.
Обычно прогерские редакторы втыкают сразу эн пробелов, для разгона эффективности прогера, так что ну так себе аргумент. Не буду же я 4 раза на уровень форматирования пробел сам жать, право? Я что, обезьяна?
> что шансы ошибиться и добавить/убавить пробел стремятся к нулю. А шанс
> запутаться в {{{{}}}}} (парные? уже посчитали? с пробелами это сразу видно)1) Ну ващет за мена это компилер посчитает.
2) Лично мне нравится примерно так:
{
abcd();
cdef();
{
efgh();
jklm();
}
}
3) Если мне чей-то синтаксис не нравится, я могу ему reflow в автоматическом режиме сделать при желании. И от дурно поставленых скобок голова будет болеть у компилера или парсера.> Тем более. Зачем вам в таком случае лишние символы в виде скобок?
Они удачно хайлайтят структуру блока и логические сущности, жестко указывая где задумано начало и конец этого блока. И парой случайных ошибок редактиврования сломать это в виде когда автоматика сие проглотит - довольно трудно.
> За вас редакторы итак эти пробелы ставят, почему же вы считаете что
> в других случаях автоматика не справится?Потому что явный маркер начала-конца блока отдельным символом - не встречающимся в других случаях - как-то эффективнее и надежнее в качестве надежного разграничения логических блоков.
> Это абсолютно такой же разделитель как скобки, автоматика работает точно также.
Только вот требования попарности нет, а пробелы встречаются при нормальном курсе событий, поэтому сломать это нечаянно - куда проще.
> Тогда вы должны топить за пробелы, потому что они именно это и делают.
Вообще, получить warning при подозрительном форматировании кода - почему бы и нет? На самом деле нормальный фичреквест.
> Как раз наоборот. Если делать по стандартам с автоформатированием то и то
> и другое прекрасно справляется, только пробелы чище, компактнее, понятнее.Для меня выделение логических блоков отдельными символами как-то лучше схватывается. Алсо хайлайт парных скобок - штука в редакторах весьма типовая, мне так нравится.
> Но если делать без форматирования то пробелы не позволяют вольностей, а скобки позволяют.
Это чисто декоративная проблема, в то время как слом логики при ошибке редактирования становится уже технической проблемой. Для меня логическая корректность кода приоритетнее эстетики, хотя, конечно, красивый код имеет больше предпосылок к тому чтобы его правильно поняли.
> Опять же пробелы ставятся однозначно, со скобками как миниум есть 2
> распространенных стандарта как ставить скобки.А вон ту задачу я вообще могу более 9000 способов решить. Это, типа, плохо?
> на той же строке, не факт что в проекте который вы используете, не делают по-другому.
Я могу с этим жить. И если им так больше нравится - ну, я не парюсь особо, прогерские редакторы все равно культурно это все сделают.
> Скобки: Лишний пробел поставил. Лажа, форматирование страдает.
Это чисто эстетическая проблема, сама по себе к факапам не ведет.
> Все собирается и работает, отправляется в продакшн.
А может и не отправляется. Кому сильно надо могут ревью и анализаторы развесить.
> Пробелы: Лишний пробел поставил. Лажа, ничего не собирается, иди дорабатывай.
Но отъезд логики на ошибке редактирования оно не поймает, от оригинала намерений ничего не осталось, и в целом удачи понять как оно было задумано. Сломать так curly bracket все же сложно и маловероятно.
> не заметивший горизонтальную прокрутку этого не заметил (что есть еще пробелы
> не видит), бэкдор внедрен (антибаг технологии, ага)Ващет гнать такого ревьюера надо. Гит на такие вещи например дико кислотные цвета рисует в консоли в git log -p и прочих git diff. Я не знаю как это можно не увидеть, от этого глаза сразу вытекают.
Более того - если у ревьюера не вызвал вопрос пустой блок/строки - это как минимум странно. А, да, я еще так то код немного ревьюю другим. Это для тебя ревьюеры божества, ставящие таких как ты в стойло. А для меня одни из равных.
> Пробелы: Такое в принципе невозможно, потому что разделитель однозначно определен и в
> начале строки.Тем не менее пример довольно странный - бэкдор очень паливный, ибо пустые строки в логическом блоке очень бросаются в глаза. Их там быть не должно.
Алсо, в минимально серьезном процессе будет автоматический чекер рубящий просто по критерию длины строки. А потому что никто не нанимался 8К мониторы всем вообще кодерам на планете покупать только потому что у одного тела видите ли 250 символов мелким шрифтом на экран лезет.
> Опять попытка увести разговор в сторону. У питонистов трейс на любой пшик
> не из-за пробелов. Но мы сейчас про пробелы говорим, а не
> про методику обработки исключения и питоновскую философию.У питонистов вообще статический анализ в зачаточном состоянии. И обработка ошибок. Поэтому вообще все пихонскрипты рассыпались при малейшем тыкании палочкой. А зачастую и сами по себе как апгрейдер убунты, тот позорный случай когда руками проще и надежнее чем таким скриптом.
> Ну и определенное число пробелов наклепать в нужном месте тоже весьма маловероятно.
Чего бы? А в прогерском редакторе скорее 1 кнопой, не буду же я 4 пробела мануально, право?
> Вы визуально выделяете блоки не скобками, а пробелами, даже если используете скобки.
Скобки очень хорошо отделяют и подчеркивают это. И жестко маркируют задуманные границы блока. Даже плюс-минус пара пробелов - все еще позволяет восстановить задуманный вид кода и я все еще вижу именно ту логику которую задумал кодер. А вот грохнув пробелы я уже и логику убиваю. Это некая избыточность - но она обеспечивает дополнительную надежность, сменить логику придется явно. А нечаянно - скорее всего компил егор.
> Вы же выше сами же пишите что автоматика же эту парность и делает.
Оно либо не повлияет ни на что кроме эстетики либо даст компил егор. Однако вот именно логику кода сломать оно не сможет и баста. И мы всегда будем видеть что на самом деле задумано. Ну как, начинка вон того блока не переедет в этот блок автоматически сама по себе, хоть там что. Правильно перекинуть блок кода с одного сегмента в другой, ничего не сломав, нечаянно - ну, это из области фантастики.
> ИМХО разделять код на логический и визуальный - неудачный антипаттерн с точки
> зрения отлова явных баговИМХО дублирование декларации намерений делает это устойчивее к ошибкам редактирования как раз. И чаще позволяет восстановить задумку испорченного кода как раз. Ну как, блочные операции случайно сделать в правильном виде - черт знает, у меня так не получалось. Чтобы код попал в другой блок с другим уровнем вложенности другого блока надо очень кастомное действо, деликатно выбрав правильные границы. Иначе компил егор.
Вообще идея что я могу менять принадлежность кода тому или иному блоку/уровню вложенности пробелом - не кажется мне удачной, слишком просто порушить незапланировано, а бонусом намерения автора полностью утрачены и разве что в git или бэкап идти смотреть что там было, если, конечно, это все есть.
> Потому что людям свойственно ошибаться и вон то - легко посадить при
> кодинге случайно, не имея на самом деле в виду. Явная маркировка
> начала-конца логического блока позволяет ловить немало дурных случаев такого плана, когда
> оно вдруг бай и не совпадает. Ну как, если например я
> пробел тапнул на выделении - и там даже улетел какой-то кусок
> блока, шансы что в выделении идеально убьется по парным скобкам и
> ошибки не будет - мизерный. Значит я буду тут же послан
> компилером, пойму что все испортил и пойду разбираться.Похоже ты сектант. То ты топишь за акууратность и еррор, то "случайну уберу пробел, компиль без ошибок". Походу тебе ни то ни другое не надо, лишь бы "пробелов не было" и находу пытаешься придумать вымышленные проблемы, которых (еще раз напомню) нет.
> Ну я бы в принципе кидал бы компил варнинг при подозрительном форматировании,
> а с точки зрения приоритетов меня корректность поведения кода и его
> соответствие задумке волнует все же больше эстетики. Поэтому вот так.Кидай ошибку при форматировании и нет никаких проблем с пробелами. Я уже в очередной раз тебе об этом пишу, но ты упорно не читаешь.
> А при чем тут тремор рук, если в редакторе селекшн был, я
> про него забыл и что-то тапнул? Ну и получил что-то unspecified
> вместо того чего на самом деле хотел. И таки очень кстати
> если автоматика поймает подозрительное место и сообщит что я сделал фигню.Если говорить про одинарный пробел, то также как и с кавычками. Если говорить про любой символ, то вы так и [10] в [1] можете превратить и Get в Set, так что не вижу смысла расусоливать на эту тему.
> То-есть это не отменяет нужды быть внимательным самому. Но компьютер должен помогать
> человеку, а не только п-лями в стойло его строить.Вот именно. И тем более компьютер мешать не должен. Блоки кавычками мешают.
> Смотри, в сях например указатели это кусок проблем если быть невнимательным. И
> там проблемы в том числе и с анонсом намерений дла анализа/компилера.
> Но кроме минусов есть плюсы. Это дико эффективная технология. Избегающая лишних
> копирований - что актуально, особенно на больших объемах данных или если
> скорость критична. Поэтому tradeoff: мы теряем в надежности, но получаем быстрый
> компактный код. А у тебя - не tradeoff. Оно только делает
> мозг, ставит в стойло, но ничего не привносит. Значит нафиг.Наоборот. Нет лишних символов, чище код, проще читать, больше сфокусирован на действии, а не на форматировании или стиле. В надежности не теряем, код становится еще компактнее чем с кавычками. Никакого трейдоффа тут нет. Просто раньше ты носил в рюкзаке бесполезный камень, а теперь его выбросил. Так что либо пробелы в твоей аналогии это указатели (тк они максимально эффективные), либо лучше чем указатели.
> При том эта строгость ничего кроме эстетики не привносит. Я не вебмакака
> чтобы в стойло становиться ради декоративно-эстетических целей. Если там будет что-то
> системное, крутое, можно подумать.Начинается. Сначала за безопасность. Теперь вот "ради декоративно-эстетических целей" не готов.
Тогда ради однообразия, сокращения размеров кода, количества коммитов, времени на ревью, ошибок связанных с неверным форматированием, ради прекращения войн стандартов, ради экономии на новых кнопках для клавиатуры в конце концов...> Ну, вообще, это по моему опыту. Если меня заворачивают с скобкой -
> я таки где-то напортачил и скорее всего логика поломана и надо
> детально все перепроверять.Точно так же и с пробелами.
> Вообще-то в сях - можно почти где угодно, так что при желании
> независимые логические блоки можно явно хайлайтить чуть активнее чем это обычно
> делают. Это не значит что это всегда нужно делать. Оформлять блок
> имеет смысл там где ... уместен логически выделенный блок, более-менее самодостаточный.
> Но если хочется - можно и по приколу почти везде делать.
> Но лучше не выпендриваться, код должен быть понятен другим, все что
> сверх того - нафиг надо.Фактически в сях можно выкинуть пробелы в начале строк и жить только со скобками. Но вы же так делать не будете? Вы же все равно используете пробелы. Так зачем вам две одинаковые вещи? Вы итак отделяете блок двумя разделителями.
> Вы вообще на сях программировали?
Да.
> Я стараюсь не писать большие скрипты, предпочитая *никсвэйный подход. То есть небольшие
> эффективные качественные программы, при нужде объединяемые небольшими скриптами по месту.
> Модуляризация. Конечно это не всегда катит. Но мудрость в идеях древних
> есть. В отличие от вебмакак и питоняш, от которых если мне
> что и надо - чтобы они перестали замусоривать поиск своими поделиями.Тогда тем более вам должен нравиться этот подход потому что в однострочниках вам не нужны блоки и никакие пробелы и скобочки тоже. А там где нужны, там 4 пробела.
> Так если я левые кавычки/скобки влеплю - буду послан. Их надо именно
> парно вкатить/стереть, и вероятность нечаянно сделать в виде когда оно будет
> сожрано как что-то валидное довольно низкая. В этом весь пойнт и
> состоит.Так и шансы что вы именно 4 пробела случайно влепите крайне низкая.
> Обычно прогерские редакторы втыкают сразу эн пробелов, для разгона эффективности прогера,
> так что ну так себе аргумент. Не буду же я 4
> раза на уровень форматирования пробел сам жать, право? Я что, обезьяна?Тогда определитесь каким редактором вы пользуетесь и опишите как он работает с кавычками и автодополнением и я покажу что в худшем случае он может работать точно также при использовании пробелов не теряя в эффективности и "безопасности".
> 1) Ну ващет за мена это компилер посчитает.
Это не вы 5 минут назад не хотели "мозг в стойло ставить"? Вы уж определитесь как-нибудь. С пробелами я и без компилятора сразу все увижу (и вы тоже, если захотите).
>[оверквотинг удален]
>
> {
> abcd();
> cdef();
> {
> efgh();
> jklm();
> }
> }
>То же самое:
abcd();
cdef();
efgh();
jklm();
Читается лучше, строк меньше, символов меньше, набирать быстрее, сразу видно где какой блок.> 3) Если мне чей-то синтаксис не нравится, я могу ему reflow в
> автоматическом режиме сделать при желании. И от дурно поставленых скобок голова
> будет болеть у компилера или парсера.То же самое и с пробелами.
> Они удачно хайлайтят структуру блока и логические сущности, жестко указывая где задумано
> начало и конец этого блока. И парой случайных ошибок редактиврования сломать
> это в виде когда автоматика сие проглотит - довольно трудно.Пробелы в начале строк вы так не используете. Вы ими никогда не хайлайтите. Вы хайлайтите переносом строк и зачем-то(для компилятора) добавляете скобки. Вы можете использовать пробели для выравнивания посреди строки, но и в моем способе вы точно также можете использовать пробелы посреди строки.
> Потому что явный маркер начала-конца блока отдельным символом - не встречающимся в
> других случаях - как-то эффективнее и надежнее в качестве надежного разграничения
> логических блоков.Не встречающимся в других случаях? Три раза ха-ха. Вы все равно вставляете пробелы в начале строки, парсить 5 различных символов менее эффективно чем 4 символа. А если еще и добавить парность скобок то еще тяжелее.
> Только вот требования попарности нет, а пробелы встречаются при нормальном курсе событий,
> поэтому сломать это нечаянно - куда проще.Пробел да, 4 пробела в начале строки - нет.
> Вообще, получить warning при подозрительном форматировании кода - почему бы и нет?
> На самом деле нормальный фичреквест.Ну вот, я же говорил.
> Для меня выделение логических блоков отдельными символами как-то лучше схватывается. Алсо
> хайлайт парных скобок - штука в редакторах весьма типовая, мне так
> нравится.Пфф..есть даже плагин на разноцветную подсветку разных блоков. Работает с пробелами.
> А вон ту задачу я вообще могу более 9000 способов решить. Это,
> типа, плохо?Попытка увести разговор в сторону не засчитана.
> Я могу с этим жить. И если им так больше нравится -
> ну, я не парюсь особо, прогерские редакторы все равно культурно это
> все сделают.Это не вы недавно писали про "эффективность" и "мозг в стойле"?
> Это чисто эстетическая проблема, сама по себе к факапам не ведет.
Располагает к разгильдяйству.
> Но отъезд логики на ошибке редактирования оно не поймает, от оригинала намерений
> ничего не осталось, и в целом удачи понять как оно было
> задумано. Сломать так curly bracket все же сложно и маловероятно.Уже неоднократно писал об этом.
> Ващет гнать такого ревьюера надо. Гит на такие вещи например дико кислотные
> цвета рисует в консоли в git log -p и прочих git
> diff. Я не знаю как это можно не увидеть, от этого
> глаза сразу вытекают.Что-то подсветит, а что-то нет. И ревьювера и тех кто решил скобки использовать.
> Более того - если у ревьюера не вызвал вопрос пустой блок/строки -
> это как минимум странно. А, да, я еще так то код
> немного ревьюю другим. Это для тебя ревьюеры божества, ставящие таких как
> ты в стойло. А для меня одни из равных.Так блок не пустой, там в начале что-нибудь безобидное. Или пустой, но как вы любите отделяющий логический блок.
> Тем не менее пример довольно странный - бэкдор очень паливный, ибо пустые
> строки в логическом блоке очень бросаются в глаза. Их там быть
> не должно.А с пробелами и вовсе невозможен.
> У питонистов вообще статический анализ в зачаточном состоянии. И обработка ошибок. Поэтому
> вообще все пихонскрипты рассыпались при малейшем тыкании палочкой. А зачастую и
> сами по себе как апгрейдер убунты, тот позорный случай когда руками
> проще и надежнее чем таким скриптом.Причем тут питонисты? Причем тут убунта? Можете еще приплести школьников за то что на питоне учатся и рассказать какие школьники криворукие, поэтому де пробелы обречены.
> Чего бы? А в прогерском редакторе скорее 1 кнопой, не буду же
> я 4 пробела мануально, право?Так в прогерском и скобки одной кнопкой. Не будете же вы мануально, право?
> Оно либо не повлияет ни на что кроме эстетики либо даст компил
> егор. Однако вот именно логику кода сломать оно не сможет и
> баста. И мы всегда будем видеть что на самом деле задумано.
> Ну как, начинка вон того блока не переедет в этот блок
> автоматически сама по себе, хоть там что. Правильно перекинуть блок кода
> с одного сегмента в другой, ничего не сломав, нечаянно - ну,
> это из области фантастики.Также и с пробелами.
> ИМХО дублирование декларации намерений делает это устойчивее к ошибкам редактирования
> как раз. И чаще позволяет восстановить задумку испорченного кода как раз.
> Ну как, блочные операции случайно сделать в правильном виде - черт
> знает, у меня так не получалось. Чтобы код попал в другой
> блок с другим уровнем вложенности другого блока надо очень кастомное действо,
> деликатно выбрав правильные границы. Иначе компил егор.И у меня не получалось. Но вы отчаянно этого боитесь.
> Вообще идея что я могу менять принадлежность кода тому или иному блоку/уровню
> вложенности пробелом - не кажется мне удачной, слишком просто порушить незапланировано,
> а бонусом намерения автора полностью утрачены и разве что в git
> или бэкап идти смотреть что там было, если, конечно, это все
> есть.В Африке акулы,
В Африке гориллы,
В Африке большие
Злые крокодилы
Будут вас кусать,
Бить и обижать,-
Не ходите, дети,
В Африку гулять.
> Похоже ты сектант. То ты топишь за акууратность и еррор, то "случайну
> уберу пробел, компиль без ошибок".Я за сбалансированный подход, когда машина по возможности помогает кодеру, но допускается что это - человек разумный и не держит его за кретина которого п-лями без права оверрайда в стойло надо, ага. Пихоносинтаксис ставит в стойло даунов не способных к обучению. Мне использовать такие инструменты дико западло. Как и иметь дело с такими кодерами.
> Походу тебе ни то ни другое не надо, лишь бы "пробелов не было" и находу пытаешься
> придумать вымышленные проблемы, которых (еще раз напомню) нет.Я лишь констатирую факт что синтаксис curly bracket видится мне сбалансированым. Не считается что кодер даун и есть гибкость с одной стороны, но явно кривые ситуации все же ловятся, а информации достаточно хоть для полного reflow. Мне так больше нравится.
> Кидай ошибку при форматировании и нет никаких проблем с пробелами.
Я тебе не необучаемое нечто чтобы меня п-лями без права оверрайда к форматированию приучать. Пусть к тебе такие подходы применяют. Как и запрет опасных операций типа указателей, ага. А себе я все же позволю немного гибкости, свободы и предпочтений не спущенных на бошку сверху божествами. Системщики сами себе божествами умеют быть - делая себе все окружение так как им хочется. Да, например макросней можно камня на камне не оставить от оригинального синтаксиса, например. Правда, так лучше не делать, т.к. другим будет тяжко одуплить.
> Я уже в очередной раз тебе об этом пишу, но ты упорно не читаешь.
С другой стороны системщики могут и повыпендриваться. Ну там посмотри c.otto.c какой - программа которая симметрична относительно ... оси симметрии :). На сях пожалуйста. А на пихоне - хренли я мяснику про картины рембрандта задвигаю?
> Если говорить про одинарный пробел, то также как и с кавычками.
Вообще речь была про скобки. Но кавычки тоже парами должны быть и это тоже хорошо. А пробелы, вот, не парные - и форматирование единственный хинт о намерении. Разметить скобками как ключевыми точками а форматирование лишь опциональная вспомогаловка мне больше нравится.
> Если говорить про любой символ, то вы так и [10] в [1]
> можете превратить и Get в Set, так что не вижу смысла
> расусоливать на эту тему.Могу. Это даже иногда случается. Поэтому прошареный народ делает интересные вещи, про которые питоняши не в курсе. Типа static assert'ов всяких и параноидальных проверок. Если вон та функция by design жрала от 3 до 8 а ей 1 дали - компил как раз и сломается. В этом направлении особенно интересно zig'овские вычисления в компилтайм смотрятся, так много чего можно сделать, прогнав произвольную логику во время сборки.
> Вот именно. И тем более компьютер мешать не должен. Блоки кавычками мешают.
В сях нет блоков кавычками. Скобки помогают мне аннотировать намерения тогда как форматирование лишь вспомогаловка с определенной гибкостью в использовании. Иногда позволяет сделать намерения более выразительными. Например, скобки можно (парно) в принципе в любом месте втыкать. Явно хинтя что вот тут - законченный логический блок, например, годный для копипасты куда-то как самодостаточное нечто. А остальное форматирование при этом можно и не рушить, так что оно и хинтит реюзабельный сегмент и логику отражает одновременно.
> Наоборот. Нет лишних символов, чище код, проще читать, больше сфокусирован на действии,
А мне нестандартные символы позволяют визуально выхватывать логический блок. И более того - эдиторы умеют в продвинутую навигацию по блокам на основе этого самого, и прочий фолдинг и так далее. Так что можно взять да и скрыть логически-завершенный блок "под кат" раз он работает и более не интересен, сфокусировавшись на чем-то ином. С пробелами это все кривее будет.
> а не на форматировании или стиле.
Програмерские эдиторы сами на этом фокусируются и это проблема только для юзера нотпада. Но у него других проблем есть, например, там нет подсветки синтаксиса что сильно портит эффективность.
> В надежности не теряем,
Вообще-то теряем. Скобки + форматирование дают некоторую избыточность, что в случае факапа помогает восстановить изначально задуманную логику даже если вышел фэйл.
> код становится еще компактнее чем с кавычками.
И выглядит стеной кода без особой разбивки на блоки...
> раньше ты носил в рюкзаке бесполезный камень, а теперь его выбросил.
Ващет он был не бесполезный - когда что-то шло не так, его можно было вынуть и дать им по морде вон тому багу. А у тебя так низя.
> Так что либо пробелы в твоей аналогии это указатели (тк они
> максимально эффективные), либо лучше чем указатели.В каком-то роде да. И с теми же проблемами - при неаккуратном использовании имеем проблемы. Но, знаешь, у системщиков аллергия на жесткую постановку в стойло. Даже у хипстерских нубов хрустиков unsafe есть ;)
> Начинается. Сначала за безопасность. Теперь вот "ради декоративно-эстетических целей" не готов.
Как бы для меня надежность имеет приоритет над эстетикой ради эстетики. А несколько избыточный маркап позволяет проще заметить и починить факап. К тому же эта избыточность ну вот мне самому жить не мешает - ее редакторы сами разруливают так то. Ну, если это не нотпад.
> Тогда ради однообразия, сокращения размеров кода,
Ставиться в стойло прерогатива взаимозаменимых вебманки.
> количества коммитов,
Это как?! Кто-то коммитит скобочки а не какие-то осмысленные фичи? :)
> времени на ревью,
Ващет при ревью я хочу понимать соответствие того что есть тому что задумано. Curly bracket дает лишний уровень обороны. Если там форматирование будет не соответствовать расстановке блоков, я спрошу у кодера что он имел в виду на самом деле.
> ошибок связанных с неверным форматированием, ради прекращения войн стандартов, ради экономии
Знаете, есть офигенный способ сэкономить ваше время - вообще программы не писать. Я буду очень рад если вы именно так и сделаете.
> на новых кнопках для клавиатуры в конце концов...
Э не, я ж не в нотпаде печатаю, более потребные редакторы, таки, удобно делают. И форматят сами, и блок могут парно оформить сразу, подогнав "болваночку". И подсвечивают парные скобки, все такое. С пробелами это вообще не очень понятно как делать. Если весь блок будет мигать, можно эпилептиком стать нахрен, а когда только парная скобка кислотненько подсвечена, это и видно хорошо и не бесит огромной площадью хайлайта. Баланс опять же...
> Точно так же и с пробелами.
А вот не так же - избыточности нет. И что я, буду сам все 4 пробела тапать? А как же экономия нажатий? Значит хоткеи на +1/-1 уровень, по эн пробелов за раз. Но избыточности при этом нет и факап с этим - полностью теряет инфо о намерениях. А в curly bracket - в силу избыточности это будет заметно (вплоть до коипил егора) и вернуть взад испорченое проще.
> Фактически в сях можно выкинуть пробелы в начале строк и жить только
> со скобками. Но вы же так делать не будете?В общем случае не буду. Но отдельные эстеты иногда в декоративных целях зажигают - и это красиво. Это - программисты. А не вебабизяны.
> Вы же все равно используете пробелы. Так зачем вам две одинаковые вещи? Вы
> итак отделяете блок двумя разделителями.Для некоторой избыточности гарантирующей что intent и реализация совпадают. А у вас есть только реализация, intent вообще не декларирован.
>> Вы вообще на сях программировали?
> Да.Что-то не очень похоже. Или это было в нотпаде.
> Тогда тем более вам должен нравиться этот подход потому что в однострочниках
> вам не нужны блоки и никакие пробелы и скобочки тоже.Однострочники имеют очень ограниченную применимость и свой набор проблем. Поэтому строк бывает и несколько. Ну и я могу жить с синтаксисом баша, но сказать что он мне нравится будет преувеличением.
> А там где нужны, там 4 пробела.
Мне со скобками больше нравится. И даже в баше таки можно делать какие-никакие функции и проч в таком духе, ага.
> Так и шансы что вы именно 4 пробела случайно влепите крайне низкая.
Один хоткей вкатать? Низкая?! Ну не буду же я по 4 раза пробел давить в крейсерском режиме, право, я ж не обезьяна в 4 раза частое дествие тормозить.
> Тогда определитесь каким редактором вы пользуетесь и опишите как он работает с
> кавычками и автодополнением и я покажу что в худшем случае он может работать точно
> также при использовании пробелов не теряя в эффективности и "безопасности".Да на самом деле разными. Что-то совсем мелкое я могу и mcedit отрихтовать, в нем все маргинально зато навигация по иерархии супербыстрая. Для более тяжеловесных операций как минимум что-то типа geany или kate (в маздайке еще programmer's notepad бывает). И таки оно уже на границе между эдитором и ide и там подобные вещи настраиваются и оптимизируются.
> Это не вы 5 минут назад не хотели "мозг в стойло ставить"?
Так это... в сях вот именно в стойло не очень сильно ставят. Да и даже в хрусте unsafe есть. А показать логчиески-некорректную программу - при чем тут стойло? Предполагается что я сразу же и задумаю программу логически-некорректной? А зачем?
> все увижу (и вы тоже, если захотите).
Боюсь что мне не нравится такой стиль кода и я не хочу иметь с ним ничего общего. А ваши аргументы меня не цепляют потому что при объемистом редактировании продвинутыми редакторами это их проблема в основном.
abcd();
cdef();
efgh();
jklm();
Ага блин, но если было
abcd();
{
bcde();
cdef();
}
efgh();
...то мы знаем что они все на 1 уровне, но если хочется то вон то, в середине, можно выдирать как реюзабельный законченный блок! А с пробелами так вообще не отмаркируешь. Вон тем увлекаться конечно не стоит, но это полностью валидный синтаксис в си.> Читается лучше, строк меньше, символов меньше, набирать быстрее, сразу видно где какой блок.
Можно подумать я скобки и форматирование руками делаю чтобы скорость набора просела. А читается оно имхо как стена текста.
> То же самое и с пробелами.
С пробелами это не имеет смысла. Скажем в сях можно разное число пробелов юзать. Например если я знаю что что-то заведомо сложное, то можно и 2 пробела на уровень сделать, для компактности. А если цель наоборот, зарубить сложный код во имя надежности - можно и 8 символов на уровень влепить, писать сильно вложенный код станет неудобно и паливно. То что один размер катил всем - ну, не факт, случаи разные бывают.
> Пробелы в начале строк вы так не используете. Вы ими никогда не
> хайлайтите. Вы хайлайтите переносом строк и зачем-то(для компилятора) добавляете скобки.Я их и для себя добавляю как маркап логически завершенного блока, точки навигации и аннотацию намерений. Я вижу блок даже если еще не накодил его. Более того, его даже можно оставить пустым как напоманание самому себе что тут что-то на самом деле задумано и должно быть добавлено при случае. Пустой блок будет мозолить глаза но фатально ничего не сломает.
> Вы можете использовать пробели для выравнивания посреди строки, но и в
> моем способе вы точно также можете использовать пробелы посреди строки.И тем не менее, со скобами имхо мощнее, гибче а избыточность уменьшает лажу.
> Не встречающимся в других случаях? Три раза ха-ха. Вы все равно вставляете
> пробелы в начале строки, парсить 5 различных символов менее эффективно чем
> 4 символа. А если еще и добавить парность скобок то еще тяжелее.Пардон, но скобки в curly bracket применяются в конкретных случаях. И не фигурируют в остальном тексте программы наобум. И они сильно менее распостранены чем пробелы, что делает их удобными точками навигации, фолдинга блоков и проч.
> Пробел да, 4 пробела в начале строки - нет.
Вы не одупляете. На границах начала и конца блока соответственно, а в этом случае - явных маркеров начала и конца нет.
> Ну вот, я же говорил.
Знаете, статические анализаторы так то много на какие аномалии бухтят... если разрешить... и вот тут мое дело что из этого я считаю нужным видеть а что нафиг.
> Пфф..есть даже плагин на разноцветную подсветку разных блоков. Работает с пробелами.
Да ну нафиг эту эпилепсию. Одно дело мелкая кислотно светящаяся скобка и другое - полэкрана мигает.
> Попытка увести разговор в сторону не засчитана.
Типа не комплекс ходьбы строем...
> Это не вы недавно писали про "эффективность" и "мозг в стойле"?
Я. А в чем проблема, редакторы ж это делают удобно и быстро.
> Располагает к разгильдяйству.
Что-то не помогло это питону, глядя на то как скрипты на этом дохнут в первые 5 минут знакомства со мной, почти все. И эти люди будут про разгильдяйство?...
> Уже неоднократно писал об этом.
Я не знаю что вы там писали, но curly bracket хорошо ловит именно про@бы при редактировании. Мне это нравится. А вот реализовывать задумку, и даже например акцентировать внимание на вон том блоке - таки не мешает.
> Что-то подсветит, а что-то нет.
Ну как бы git обычный его подсвечивает как прожектор.
> И ревьювера и тех кто решил скобки использовать.
Ну как бы длинные строки в нормальных проектах ловятся сами по себе как пробленая субстанциях и если уж мы про ревью, если такое пролезает через ревью то толку от вашего ревью немного и проблема у вас таки в ревью и ревьюерах.
> Так блок не пустой, там в начале что-нибудь безобидное. Или пустой, но
> как вы любите отделяющий логический блок.Так длинные линии проблема сама по себе - и это не должно пройти ни ревью, ни автоматические чекеры. Если это не так, толку от вашего ревью и чекеров - около ноля.
> А с пробелами и вовсе невозможен.
Да и хрен с ним - не выглядит огромной проблемой. Зато вот вам другой бэкдор: пробелов в уникоде так то более одного вида! В сях оно похрену. А вот вас можно попытаться накормить логикой которая выглядит иначе нежели по факту работает, используя пробелы которые типа не пробелы, в том плане что визуализуются как пустое место но не имеют эффекта на логику.
Кажется я только что придумал как иметь питоняш по технологии BadSource, лол :)
> что на питоне учатся и рассказать какие школьники криворукие, поэтому де пробелы обречены.
Да, блин, найти не глючный скрипт на питоне - ну, у меня не получилось ни разу. Вот честно, все что я видел было дикой наколенью. Прикольно когда при этом что-то вещают про надежность.
> Так в прогерском и скобки одной кнопкой. Не будете же вы мануально, право?
Так сама по себе пара скобок либо вообще не меняет логику, либо если это сделать в середину чего-то еще, компил завалит, т.к. случайно влепить их так чтобы компил не свалился - весьма маловероятно.
> Также и с пробелами.
Да ща.
> И у меня не получалось. Но вы отчаянно этого боитесь.
Скорее, мне нравится явное маркирование блоков. Много усилий от меня оно не требует и позволяет ряд интересных вещей. Вплоть до разнесенных по времени декларации намерений и фактического кодинга. Когда пустой блок является placeholder для какого-то сегмента который я попозже накатаю. А если не накатаю - визуально это достаточно заметно и вызовет вопросы.
Не буду повторяться, вижу вы даже не собираетесь вникать. Все ваши аргументы заключаются в одной фразе: лишь бы не как в питоне. Притом про питон речи не было(я не предлагаю следовать его синтаксису). Но видно что и питоном вы никогда и не пользовались и на ходу пытаетесь придумать проблемы которых нет. Когда я вам объясняю почему их нет, вы либо повторяетесь, либо меняете тему, либо меняете сторону на противоположную(но и там проблем с пробелами не находится), либо безуспешно пытаетесь расставить логические ловушки с извращенной логикой.
Да и я устал. Посчитаем что мне тот синтаксис все же не нравится, настолько что я им пользоваться не буду по совокупности свойств.А питон что, образец голимой наколенщины и одноразовго софта писаного сразу на выброс. Там аргументы про экономию сил ламерьем не умеющим редактор настраивать, любой ценой, поймут - там надо чтобы раб у весла как можно больше прожЕктов в единицу времени хреначил, а заказчик все равно ламер и ничерта не смыслит. Ваши аргументы все из этой области. И хрен с ним что багов больше, утеряны намерения кодера и прочие несущественные мелочи. А меня в системщине все же волнует качество кода, возможность других двуногих в него въехать, antibug и проч.
Название языка о много говорит. Какая-то сишечка же.
> We have no intention of supporting non-free platforms, but because the language is standardized, a third-party implementation or fork could easily develop Windows or macOS support if desired.
>We have no intention of supporting non-free platformsОдобряю!
Банда непуганых uдuотов! Благодаря этим "non-free platforms" вы вообще сидите в тырнетах!!
Просто представьте, что Винды нет и никогда не было. В мире работает 100 компьютеров, потому что только 100 погромиздов и умудрилось разобраться, как там настроить Иксы, сконфигурить сеть и запустить (А ПОТОМ И ВЫЙТИ) из vi. :)
Только благодаря "коммерческим Окошкам" ИТ развернулось практически на всё население планеты. Не говоря о том, что ТЕБЕ ЛИЧНО платность винды вообще никак не мешает! Чел хотел - чел купил Венду. И хочет под ней хороший компилер - в чём проблема-то? Боитесь, что все ваши 15 рублей уйдут БГ? Каким образом??
> Банда непуганых uдuотов! Благодаря этим "non-free platforms" вы вообще сидите в тырнетах!!Вы говорите так, будто это что-то хорошее.
>> Банда непуганых uдuотов! Благодаря этим "non-free platforms" вы вообще сидите в тырнетах!!
> Вы говорите так, будто это что-то хорошее.Ну да, так и есть - хорошее! А преставь, вместо тырнетов такие сидели бы в Думе!
>> Банда непуганых uдuотов! Благодаря этим "non-free platforms" вы вообще сидите в тырнетах!!
> Вы говорите так, будто это что-то хорошее.Он говорит так, будто бы _мы_ сидим, а он исключение. Этим исключением он и опроверг своё "правило". :)
>_мы_Вы-то как раз сидите крепко на пляшке non-free platforms. Чем дальше, тем глубже.
Я обычно сижу "на" кресле, а ты, похоже, в очереди к Фрейду. Или уже на операцию?
Так пусть владельны non-free platforms и форкают, если им потребуется чуть менее безумный чем C и более простой чем Rust системный язык.А те, кто хочет писать на нём сидя на non-free platform пусть ставят себе Docker Desktop, non-free прослойку для запуска вполне себе free линукса и конпелируют свой код.
> Банда непуганых uдuотов! Благодаря этим "non-free platforms" вы вообще сидите в тырнетах!!Тырнеты появились без этих платформ. Тырнеты продолжат работать без этих платформ.
Слишком похож на C — слишком мало профита от перехода. В то же время достаточно непохож, чтобы переход был простым.
Почему на опеннете хейтят хРуст? Адекватно кто-то может пояснить?
Потому что ниасиляторы.
> Потому что ниасиляторы.А что там сложного? Я особо не вникал, но документация одна из лучших, сообщество не токсичное в отличии от того же питона. Очень понравился подробный разбор ошибок компилятора.
Потому что Rust как и Go, Swift сведены к одной проблеме - их продвигают фирмы делающие на этом деньги. То есть это своего рода модная тенденция, которая скоро отыграет свое. Аак Python, который тормоз. И вот люди при желанит могли бы написать набор правил к компилятору Си/С++, которые делали бы ровно то, что они хотят. Но может быть им так хочется. Так что лучше уж такой язык, который сам пусть доказывает свою нужность. Возможно кому-то он будет как Vulkan вместо OpenGL. Rust же просто не дастьнаписать криво к каких-то местах, поэтому обладателям кривых мозгов так тяжело, а приходится искать оправданте почему они пишут на визуал бейсике, а не на Rust.
50% опеннетчиков хейтит Хруст и любит Сю.
50% опеннетчиков хейтит Сю и любит Хруст.
0% опеннетчиков могут адекватно воспринимать оба языка.
0.01%
>Почему на опеннете хейтят хРуст?Для начала попробуй его компилятор с llvm собрать из исходников.
Такой же медленнособираемый как и GCC, Clang. В Gentoo этот самый Rust далеко не самый медленный по сборке. К тому же GCC и Clang надо чаще собирать. Просто к моменту окончания сборки GCC терпение обычно заканчивается.
> Почему на опеннете хейтят хРуст? Адекватно кто-то может пояснить?Отвратный синтаксис (впрочем сабж не намного лучше, но все же лучше).
Целиком контролируется корпорациями.
Предлагает "13ый стандарт", свой компилятор, свой инструментарий, свои законы.
Дегенератское сообщество:
- состоит из членов/пропагандистов ЛГБТ, феминизма, BLM и прочего !@#$%
- страдает переизобретением велосипедов (нужно написать еще пару десятков видов ls)
- страдает агитацией самого раста, в основном преподносят его как лекарство от всех болезней и с ужасом узнают что лечит он в основном от гриппа (которую давно научились лечить и без арбидола) и пары крайне редких африканских болезней о которых мало кто слышал
- в основном состоит из слабоквалифицированных хипстеров-студентов и менеджеров мечтающих видеть в отчетах бухглатерии бюджетных хипстеров-студентов вместо высооплачиваемых зубров
Всеми силами пытается выглядеть лучше чем он является:
- Преподносит дефолтные штуки за инновации ("статический анализатор теперь со вкусом менто^W в компиляторе").
- safe/unsafe (спасибо, кэп).В целом раст предлагает кучу новых проблем, но мало проблем решает.
Зачем, когда есть C3? https://www.c3-lang.org/compare/
Зачем, когда есть
D, J, V?
При чем здесь J к D и V? Он же от всех компилируемых императивных языков очень сильно отличается.
Имел в виду Jai
D и этого достаточно :)
Hare selfhosted, а C3 на LLVM. Преимущество, млин...
С4 будет?
Как вы уже забодали плодить языки ради пложения языков. А потом плодить по 2.5 поломаных проекта для них и кричать вот мой то язык самый языкатый и правильный.
>HareПо-русски означает "заяц".
Спасибо, продолжайте наблюдение.
А может дать тебе по Харе?
Да харе уже
>язык программирования HareХорошо, что его компилятор не на llvm/gcc основан.
Почему это хорошо?
Самостоятельность, безопасность, легковесность.
Но вот если для ядра... На Опеннет пару раз приводилась ссылка на исследование о скрытых опасностях связывания кода, произведённого разными кодогенераторами.
Например, никто не подумает использовать СИСТЕМНЫЙ язык там, где требуется оптимизация. Си в этои смысле испортил не одну тысячу погромистов заблуждением, что он якобы быстрый
> Например, никто не подумает использовать СИСТЕМНЫЙ язык там, где требуется оптимизация.
> Си в этои смысле испортил не одну тысячу погромистов заблуждением, что
> он якобы быстрыйА что, попробуй LZ4 на сях соптимизить, да? Прикинь, если он в память упирается, переписывание на асме ему не поможет совсем никак :)
>> Например, никто не подумает использовать СИСТЕМНЫЙ язык там, где требуется оптимизация.
>> Си в этои смысле испортил не одну тысячу погромистов заблуждением, что
>> он якобы быстрый
> А что, попробуй LZ4 на сях соптимизить, да? Прикинь, если он в
> память упирается, переписывание на асме ему не поможет совсем никак :)Расскажи поподробнее, какой у тебя оптимальный и "упирающийся лишь в память" гном/гтк.
Заодно прикинь, сколько разных алгоритмов сжатия и шифрования, помимо LZ4, ты еще используешь повседневно.
> Расскажи поподробнее, какой у тебя оптимальный и "упирающийся лишь в память" гном/гтк.Сразу после того как ты на асме что-то сравнимое по фичам накатаешь вообще.
> Заодно прикинь, сколько разных алгоритмов сжатия и шифрования, помимо LZ4, ты еще
> используешь повседневно.Однако хорошие алгоритмы так то шустро работают даже на си. Просто автор LZ4 очень круто знает особенности современного железа, вплоть до выравнивания кешей проца и проч. А так да, иногда асм может что-то отыграть, особенно если кодогенератор протупляет. Но в целом ареал обитания асма заметно сузился. И таки даже в каком-нибудь мизерном бутлоадере может быть распаковщик или крипто на сях. Как бы майнтенанс и портабельность кода тоже аргумент, равно как и тот факт что его вон там уже 20 раз проверили, в отличие от нечто на асме. Поэтому асмом ща пользуются только если здорово приперло и выигрыш того реально стоит. А вот так весь проект на асме - ну, нет, есть, конечно, колибридос но тот уже возлюбил C--. Еще годиков 10 и до них допрет почему мы любим си :)
>> Расскажи поподробнее, какой у тебя оптимальный и "упирающийся лишь в память" гном/гтк.
> Сразу после того как ты на асме что-то сравнимое по фичам накатаешь
> вообще.Как славно ты опять свинтил с темы на свои фантазии (об асме речь завел тут ислючительно ты).
> ... А так да, иногда асм может что-то отыграть, особенно если кодогенератор протупляет. Но в целом ареал обитания асма заметно сузился.Сам придумал, сам накатал целую простыню ...
btw:
> Однако хорошие алгоритмы так то шустро работают даже на си.И поэтому в какой видеокодировщик не глянь - куча асма.
https://www.opennet.ru/opennews/art.shtml?num=57068
> Компания Intel опубликовала кодировщик видео SVT-AV1 1.0
> https://github.com/AOMediaCodec/SVT-AV1/search?l=assemblyhttps://www.opennet.ru/opennews/art.shtml?num=56876
> Выпуск dav1d 1.0, декодировщика AV1 от проектов VideoLAN и FFmpeghttps://github.com/videolan/dav1d/search?l=assembly
> Как славно ты опять свинтил с темы на свои фантазии (об асме
> речь завел тут ислючительно ты).Остальные языки не доказали делом что они - системные. Всякая академдрянь к системщине близко не стояла - решает какие-то задачи про сферических коней в вакууме в основном. Ну ей системщики и не пользуются, они относительно низкоуровневые и приземленные ребята по академмеркам. С мышлением инженера-имплементера а не абстрактного математика.
Для горе академов сообщаю: в системщине от высокопарных абстракций и крутых загибонов только вред. Код должен быть простым, предсказуемым, понятным, и - должны удобно и просто делаться всякие системные низкоуровневые вещи. Остальное в лучшем случае опционально и при серьезном настрое все-равно делается как часть внешнего процесса. И чем проще яп тем на него проще "safe" спеки накатать типа правил MISRA всяких, нацеленных на то чтобы кодеры однозначно понимали что код делает без разночтений, а поведение кода совпадало с тем что задумано.
> Сам придумал, сам накатал целую простыню ...
Ну, значит покапитанил. Из-за общей невменяемости типа-системных уродов от академа ими никто кроме пары отшибленых академов и не пользуется. И имеется то что имеется. Нечто типа сабжа более сбалансировано в этом смысле.
> И поэтому в какой видеокодировщик не глянь - куча асма.
Это да, однако если детально копнуть в гит того или иного кодека - там весьма стебные цифры бывают. Вот тут AVX/SSE фрагмент делает си в 7 раз. И это круто. А вот там почему-то в 0.6 :)) раза. И вознимает вопрос "зачем эта гадость место вообще занимает?!" (ее ж даже не вызывают потом).
> https://github.com/videolan/dav1d/search?l=assembly
Кажется, капитанить не только я умею... и все же заметьте что основная тушка кодека писана на сях а на асме только небольшие критичные куски где компилер может протупить. Ну как, компилер же не AI и имеет очень примерное представление где горячий код и что критично. Штуки типа PGO пытаются с этим что-то делать, но довольно утомительны в использовании ибо требуют рантайм статистику собирать.
А для понимания почему капитанинг - я так то сам себе интринсиков на асме понаделал под несколько архитектур. А как раз потому чтобы вынести мерзкую непортабельную помойку в 1 мелкий загон. А остальное - более чистый портабельный код, вызывающий таки уже нормальную сишную абастракцию. Даже если унутрях она и будет 1 асмовой командой потом. Или не 1 - от платформы зависит как оно там у них. Факт в том что основной код может быть абсрактным и портабельным. И когда так удается проскочить даже в системщине это все же круто.
>> Как славно ты опять свинтил с темы на свои фантазии (об асме
>> речь завел тут ислючительно ты).
> Остальные языки не доказали делом что они - системные. Всякая академдрянь к
> системщине близко не стояла - решает какие-то задачи про сферических коней
> в вакууме в основном. Ну ей системщики и не пользуются, они относительно низкоуровневые и приземленные ребята по академмеркам. С мышлением инженера-имплементера а не абстрактного математика.Ты опять доказал, что прекрасно владеешь уменим читать жопой и домысливать большую часть, не более.
>>>> Хорошо, что его компилятор не на llvm/gcc основан.
>>> Почему это хорошо?
>> Например, никто не подумает использовать СИСТЕМНЫЙ язык там, где требуется оптимизация.<тут еще можно было кинуть ссылку на недавнюю новость, где излишняя оптимизация gcc подложила очередной сюрприз разработчикам, впрочем, достаточно иногда заглядывать в lkml или багтрекеры
https://lore.kernel.org/lkml/20200104215156.689245-1-arnd�.../
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=37054 >> Для горе академов сообщаю: в системщине от высокопарных абстракций и крутых загибонов
> только вред. Код должен быть простым, предсказуемым, понятным, и - должны
> удобно и просто делаться всякие системные низкоуровневые вещи.
> <остальная простыня на тему "мои сегодняшние фантазии о ..." поскипана>Да успокойся уже, никто на твое звание Чемпиона по чтению опой не претендует.
> Ты опять доказал, что прекрасно владеешь уменим читать жопой и домысливать большую
> часть, не более.Да и ты тоже это не хуже сделал, лолка. Особенно доставили ссылки.
> <тут еще можно было кинуть ссылку на недавнюю новость, где излишняя оптимизация
> gcc подложила очередной сюрприз разработчикам, впрочем, достаточно иногда заглядывать
> в lkml или багтрекерыДля этого достаточно всего лишь .. пользоваться тулсами. Большой и сложный тул не может быть идеальным. А знаешь, когда большой самолет идет на взлет - там пара сотен дефектов запросто есть. Довести до идеального технического состояния эту махину малореально. Но оно в целом летает, а роялит - умение того кто в кресле понимать можно ли с этим лететь. И тебе я бы свою тушку не доверил. Тебе не место в кресле пилота. Ну или в нашем случае, прожект менеджера или лида, равно как и автора своих проектов.
> https://lore.kernel.org/lkml/20200104215156.689245-1-arnd�.../
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=37054Вау, просто эпик.
1) В первом случае аццкий жрач стека. Аж 1330 байтов при варнинге в 1024. Вообще, кернел это сделал потому что там кода МНОГО и если КАЖДЫЙ будет по кило жрать, из тысяч дров, душно все же может стать. Но это специфика кернела и их юзкейсов. И эта проблем в целом решается.
2) Баг на gcc 2.96 это конечно свежо и актуально. Багу 21 год всего. Этот анон поставил рекод арч-некромансии опеннета, е...ь!
3) А так то по приколу в других компилерах тоже баги бывают. LLVM вообще кусок багодрома, и на фоне его приколов вон то смотрится мелочью жизни и незначительными придирками.
4) Писать на асме я все же из-за этого не собираюсь.
5) А в других тулсах баги не находят в основном потому что ими никто не пользуется.> Да успокойся уже, никто на твое звание Чемпиона по чтению опой не
> претендует.А как же ты, жгун? Откопать баг которому 2 десятка лет в качестве доказательств "своей правоты" это жэсть. Мне так слабо, я понимаю что за 2 десятилетия там скорее уже и кода то от gcc 2.96 не осталось, а его проблемы интересуют только музеи истории вычислительной техники. Настолько с@с@ть в управлении проектами и балансировкой соотношений мне слабо, это талант иметь надо походу.
>> Ты опять доказал, что прекрасно владеешь уменим читать жопой и домысливать большую
>> часть, не более.
> Да и ты тоже это не хуже сделал, лолка. Особенно доставили ссылки.Узнается Балабол294 - когда не хотят оспаривать его бредовые фантазии и тыкают в то, что разговор был не об этом, следует переход на "сам дурак".
>> <тут еще можно было кинуть ссылку на недавнюю новость, где излишняя оптимизация
>> gcc подложила очередной сюрприз разработчикам, впрочем, достаточно иногда заглядывать
>> в lkml или багтрекеры
> Для этого достаточно всего лишь .. пользоваться тулсами. Большой и сложный тул
> не может быть идеальным. А знаешь, когда большой самолет идет наТолько вот, Балаболка, разговор шел совсем не об этом. Если бы ты не читал жопой, а обращал внимание на цитированное, то заметил бы, что там выше - было высказывание, что для _системного_ языка супер-навороченная оптимизация возможно "не очень" - ну или наоборот.
Но никак не "перепишите на асм" и че-то-там про академиков и прочие твои фантазии.>> https://lore.kernel.org/lkml/20200104215156.689245-1-arnd�.../
... As there is an easy way to work around it, just add a comment and the barrier that stops gcc from trying to overoptimize the function.
> Вау, просто эпик.
> 1) В первом случае аццкий жрач стека. Аж 1330 байтов при варнинге
> в 1024. Вообще, кернел это сделал потому что там кода МНОГО и если КАЖДЫЙ будет по кило жрать, из тысяч дров, душно все же может стать. Но это специфика кернела и их юзкейсов.
> И эта проблем в целом решается.Опять решил на всякий пожарный подтвердить звание Чемпиона?
> 2) Баг на gcc 2.96 это конечно свежо и актуально. Багу 21
> год всего. Этот анон поставил рекод арч-некромансии опеннета, е...ь!Эк тебя припекло. О том, что это пример "да, оно давно так", ты уже подумать не успел, бедолага - срочно очередную простыню ваять нужно было.
>> Хорошо, что его компилятор не на llvm/gcc основан.
...
> 3) А так то по приколу в других компилерах тоже баги бывают.
> LLVM вообще кусок багодрома, и на фоне его приколов вон то
> смотрится мелочью жизни и незначительными придирками.Да Чемпион ты, Чемпион, успокойся.
>> где излишняя оптимизация gcc подложила очередной сюрприз разработчикам
> А как же ты, жгун? Откопать баг которому 2 десятка лет в качестве доказательств "своей правоты" это жэсть.И? Два сэмпла, почему излишняя оптимизация может выдать "сюрпрайз" в системной разработке, причем "уже давно".
Тебя так подорвало, что отключило логику или просто ты читал опять этим самым и сейчас оспариваешь свои очередные фантазии?> Мне так слабо, я понимаю что за 2 десятилетия там скорее уже и кода то от gcc 2.96 не осталось, а его проблемы интересуют только музеи истории
> вычислительной техники. Настолько с@с@ть в управлении проектами и балансировкой соотношений
> мне слабо, это талант иметь надо походу.Эта балаболка порвалась, вносите следующую!
> Эта балаболка порвалась, вносите следующую!Да вообще пипец, не хочет в багах gcc 2.96 копаться. Вы еще б приволокли мне DOS 3.30. А, майкрософт уже даже там на сях прогал, на асме их уже заколебало к тому моменту.
В конечном итоге создание софта - не о гребаном перфекционизме отдельных отшибленых личностей, высасывающих из пальца бредовые примеры. Оно о разумном балансе свойств. Сишка этот баланс обеспечивает в очень широком спектре, от фирмварей и бутлоадеров до чатботов и вебсерваков, махрово апликушных. А между делом можно реюзануть в обоих некий удачный алгоритм.
p.s. а чисто поугарать я не только умею на асме прогать но и нехилые штуки на этом прогал. Только нафиг мне это счастье когда си есть. А на других яп, кроме, вот, еще полутора wannabe-системных, прогать махровую системщину от "мучительно" до "не катит". И даже так - можно найти например сказ о том как хрустики в микроконтроллеры пытались. Тут то они и познали прелести кастомного лэйаута бинаря и генерации этого. И что их "системная" штука это не очень то умеет. Возьмите, дескать, gcc'шный линкер, но вон там в ночной версии уже почти совсем...
TL;DR: я не люблю взбрыки софта, но у любой проблемы есть severity и priority. И для gcc 2.96 в 2022 году это полное ололо.
Hare Krishna, Hare RAMa!
Язык для индусов?
Hari тогда уж.
Hare RAMa - этот для безопасТной работы с памятью?
Вместо очередного типа Си-подобного языка, но на деле не совместимого по исходникам, в том числе с автоматическим конвертером, лучше добавить в Си ключи убавляющие неопределенное поведение.А так есть еще анализаторы исходников, для проверки на эти самые неопределённые места, и велосипедостроения.
Вот помню как то hint, Вы похоже считаете сумму бит в массиве... Для этого есть готовая функция...
Hare так может? Вот и вердикт.
У тебя с этими ключами ничего не соберётся.
По минимуму, и это достаточно.
После устранения неоднозначностей - соберется.А если собрать исторический код, без правки, так и сейчас, вагон опций используется.
> У тебя с этими ключами ничего не соберётся.Если не соберется, значит там используется злобный хак...постойте! Да это же safe/unsafe как в хрусте!
Hello World! -то соберётся. А это самое главное.
если убрать неопределённое поведение все разработчики компиляторов взвоют поросячьим хрюком, у них на этом все оптимизации
А всё потому, что компилятор ничего не знает о коде и вынужден догадываться. Это и наличие/отсутствие UB как раз и вызывает то, что C/C++ оптимизируется посредственно, а всевозможные императивные убийцы C оптимизируются вообще никак.
Главная проблема языка Си - препроцессор и отсутсвие адекватной замены ему. Это уже ничем не исправить.
m4
Пора бы просто прочесть стандарт. Препроцессор - отдельная фаза трансляции.
Именно. А нужно чтобы на фазе компиляции и типобезопасно.
Тогда пишется новый "препроцессор", как сделали в компиляторе Vala. Страуструп, кстати, изначально тоже написал фронтэнд, он так и назывался - CFront.
> пишется новый "препроцессор", как сделали в компилятореИ это уже получается не язык Си, а какой-то другой. А нужно языковое средство. Времена, когда чтобы начать программировать, требовалось написать свой компилятор, ОС и текстовый редактор давно прошли. К счастью или к сожалению.
Да, другой язык, но при этом совместимость сохраняется и не обязательно все на новый язык переписывать. Си разрабатывался как замена платоформозависимому ассемблеру, отсюда все "проблемы". Почему бы его и не применять как ассемблер (бэк-энд транслятора), если проблемы мешают.
> Пора бы просто прочесть стандарт. Препроцессор - отдельная фаза трансляции.И у него черт подери свое видение всего. Например integer'ов. Что создает много дурных ситуаций на ровном месте.
Да тут у каждого своё видение всего. Пишешь про препроцессор, который обрабатывает токены, видят инты.
> Да тут у каждого своё видение всего. Пишешь про препроцессор, который обрабатывает
> токены, видят инты.Все чуть сложнее чем некоторыые пытаются изобразить.
1) Вообще-то препроцессор немного умеет в математику сам, насколько я помню. Целочисленные операции в директивах препроцессора имеют место быть.
2) Он также умеет в булевские операции и условные операнды. В том числе и с целыми числами из 1). Скажем, #if (SOME_CONST == 2) вполне валидно. И более продвинутая математика над этим тоже.При этом нас начинает колыхать - а что такое "2" в понимании препроцессора. И как эта математика ТАМ работает. И насколько при вычислениях/операциях совпадает с остальным ЯП. Потому что some_var = (SOME_CONST + 10) ничему не противоречит. И было бы очень кстати если бы результат операций был бы симметричен. Но это не совсем так. Целочисленная математика в препроцессоре специфицирована как обычно в сишке, т.е. никаковски.
А препроцессор так то кроме всего прочего еще и почти-тюринг-полный. И единственный лимит на сложность того что он делает это лимит на число уровней вложенности. Гага, токены, с добавкой бульонов и целых могут нехилую логику завернуть. Можно самому compile time assert например сделать. Да, это "всего лишь условная кодогенерация". И все же.
Оно действительно сложнее, но при этом достаточно строго формализовано стандартом, что бы при разногласиях мы могли не спрашивать третьего авторитетного Анонима, а там почитать и найти общий язык. Integer types - это отдельная глава ближе к середине, она относится к последующей фазе трансляции. После директивы #if может быть "the controlling constant expression which is evaluated according to the rules of 6.6" и в сноске указано, что нет гарантий одинакового результата для
#if ’z’ - ’a’ == 25
if (’z’ - ’a’ == 25)
и это называется arithmetic constant expression, а не "целочисленные".Теперь смотрите: оно по разному названо, по разному пишется... а почему разница должна колыхать? Ну, написали так в эпоху "деревянных" машин, сохранилось для совместимости. Не нравится препроцессор, хочется большего, так можно написать свой, добавить свою фазу трансляции.
> Оно действительно сложнее, но при этом достаточно строго формализовано стандартом, что
> бы при разногласиях мы могли не спрашивать третьего авторитетного Анонима,Называя вещи своими именами, сишные стандарты сделаны достаточно паршиво и там много implementation defined и нестыковок. В сумме все это приводит к тому что мнение програмера о том как это должно работать разъезжается с тем как оно реально работает и мы огребаем баги и некоторые из них даже вулны. Это не есть хорошо. Откуда и предпосылки потуг в создании вон тех альтернатив.
> а там почитать и найти общий язык. Integer types - это отдельная
> глава ближе к середине, она относится к последующей фазе трансляции.Однако препроцессор тоже оперирует тем что выглядит ... почти как это самое. Но этим самым не является в том его понимании которое все интуитивно ожидали бы. И такое состояние дел вовсе даже и не фича. Да и сами integer'ы в сях специфицированы так что подарили миру много новых, клевых, годных CVE.
> и это называется arithmetic constant expression, а не "целочисленные".
А таки 25 - это что, не целое число? А коли так - хотелось бы некоей унификации таких вещей. Чтобы эти выражения работали везде одинаково, по одним и тем же правилам, хорошо специфицированным а не implementation defined. Иначе это ведет к куче багов в софте на ровном месте.
> Теперь смотрите: оно по разному названо, по разному пишется...
А выглядит 25 одинаково. Что в препроцессоре, что в int i = 25; Откуда и желание чтобы работало это везде одинаково.
> а почему разница должна колыхать?
Потому что 25 в обоих случаях выглядит одинаково на глаз. Но совсем не факт что идентично себя ведет. Вот вообще не факт. А два набора правил для делания одного и того же по смыслу ведут к бардаку и багам.
> Ну, написали так в эпоху "деревянных" машин, сохранилось для совместимости.
> Не нравится препроцессор, хочется большего, так можно написать свой, добавить свою фазу трансляции.Только портабельность всего этого либо пойдет лесом, либо это будет БОЛЬШОЕ приключение. А вон тот кодер не сможет просто взять и просто подхватить проект без гимора. И желающих какой там еще препроцессор кастомный билдить будет предсказуемо около ноля. Поэтому реально мыши плачут, колются, но погрызают имеющийся кактус. Это ведет к определенным последствиям. Баги и вулны одни из таковых.
>> Оно действительно сложнее, но при этом достаточно строго формализовано стандартом, что
>> бы при разногласиях мы могли не спрашивать третьего авторитетного Анонима,
> Называя вещи своими именами, сишные стандарты сделаны достаточно паршиво и там много
> implementation defined и нестыковок. В сумме все это приводит к тому
> что мнение програмера о том как это должно работать разъезжается с
> тем как оно реально работает и мы огребаем баги и некоторые
> из них даже вулны. Это не есть хорошо. Откуда и предпосылки
> потуг в создании вон тех альтернатив.Мнение программиста, который не читал стандарт, естественно может с ним расходиться. В тему о препроцессоре: ведущий разработчик Пока Линукс заявлял, что #define объявляет переменную. Другой пример, мы писали по стандарту стандартную библиотеку, и, когда взяли тесты от аналогичной из GCC, наша просто под ними заработала. Другое дело, что стандарты меняют и за этим хорошо бы следить.
>> а там почитать и найти общий язык. Integer types - это отдельная
>> глава ближе к середине, она относится к последующей фазе трансляции.
> Однако препроцессор тоже оперирует тем что выглядит ... почти как это самое.
> Но этим самым не является в том его понимании которое все
> интуитивно ожидали бы. И такое состояние дел вовсе даже и не
> фича. Да и сами integer'ы в сях специфицированы так что подарили
> миру много новых, клевых, годных CVE.
>> и это называется arithmetic constant expression, а не "целочисленные".
> А таки 25 - это что, не целое число?25 это два ASCII символа. Это надо понимать и иметь представление, как транслятор их обрабатывает. В системном программировании принято основываться на знаниях, не на интуиции.
> А коли так
> - хотелось бы некоей унификации таких вещей. Чтобы эти выражения работали
> везде одинаково, по одним и тем же правилам, хорошо специфицированным а
> не implementation defined. Иначе это ведет к куче багов в софте
> на ровном месте.Так напишите свой язык, всего-то делов. :)
>> Теперь смотрите: оно по разному названо, по разному пишется...
> А выглядит 25 одинаково. Что в препроцессоре, что в int i =
> 25; Откуда и желание чтобы работало это везде одинаково.Это называется - вырвать из контекста.
>[оверквотинг удален]
> два набора правил для делания одного и того же по смыслу
> ведут к бардаку и багам.
>> Ну, написали так в эпоху "деревянных" машин, сохранилось для совместимости.
>> Не нравится препроцессор, хочется большего, так можно написать свой, добавить свою фазу трансляции.
> Только портабельность всего этого либо пойдет лесом, либо это будет БОЛЬШОЕ приключение.
> А вон тот кодер не сможет просто взять и просто подхватить
> проект без гимора. И желающих какой там еще препроцессор кастомный билдить
> будет предсказуемо около ноля. Поэтому реально мыши плачут, колются, но погрызают
> имеющийся кактус. Это ведет к определенным последствиям. Баги и вулны одни
> из таковых.Лично Вы сталкивались с ситуацией, когда не могли подхватить проект?
надеюсь, работа над этим языком не скажется отрицательно на развитии sway.
Он давно отошел от разработки sway
в общем главное чтобы sway не скатился.
Куда уж проще чем С? Совсем что-ли?
В Си !было не!достаточно восклица!тельных знаков!
эти унылые изобретатели ещё одного убийцы раст и питона не видят разницы между С и С++. питон сделал их очень крутыми программистами.
Очередной Zimbu.
Не взлетит
> полное доверие к действиям программиста (выполнять именно то, что указано, без самодеятельности и неявного поведения)<сарказм>
Дарю Дефолт (Drew DeVault), автор < ... > Свой (Sway) < ... > представил < ... > Харе (Hare)
</сарказм>
Эм, посмотрел на пример, это какой-то Rust:)
И врямь, что только не делают лишь бы должным образом не изучать Си:)
Дрю и Ко запилили свой язык с префирансом и поэтесами (потому что может). Но тут же примчали хейтеры и давай этому Дрю делать большое дрю. Вопрос: с герани?!!! В школьную программу "заю" не добавили, что так возбуждатся?!
Нельзя плодить г0вн0 просто "потому что можем". Любые попытки плюнуть в вечность должны быть как минимум ПРОФЕССИОНАЛЬНЫМИ, обоснованными и реально двигающими прогресс. А запилить "ещё одну сишечку" много ума не надо, благо 20 век дал сотни через-жо-пу-вывернутых языков.
Сейчас время перехода от количества к качеству, много языков умерло как раз поэтому - де6uльные концепции отмирают сами собой. И что на этом фоне может предложить "заяц"?? Обилие :::: ?
Это сарказм или вы просто наркоман?
фуфло, а не язык - перед Си ВООБЩЕ НИКАКИХ преимуществ! Язык ради языка. И бесконечные ::::::: - нафуа???
Игрался с ним пару недель назад, какой-то кастрированный зиг получился, не уверен что у него есть шансы
Кто-то уже группу в тг сделал.
Уже более 8 тысяч языков программирования придумали после Ады Лавлейс... Может, уже харэ? ах, да, Харэ - это теперь ещё один язык из 8 тысяч... Зараза заразная заражает...
> Уже более 8 тысяч языков программирования придумали после Ады Лавлейс...Серьёзно?? Это больше, чем естественных. )))
(Тех под 7 тысяч, да и то со всеми долинами Новой Гвинеи и реки Нигер.)
Интересно будет ли он переписывать на нем sourcehut? Там сейчас переход python -> go
> Интересно будет ли он переписывать на нем sourcehut? Там сейчас переход python -> goЧто, и он тоже? Походу питономакакокапец в разгаре. Может на этом фоне и пришла идея языка, который был бы как сишка которая DeValt'у нравится, но с некоторыми совремнными фичами из других. А что, сама по себе идея вполне рациональная.
В C аналога defer не хватает. Обычно используют метки и goto, но они в конце функции, а хочется, чтобы было рядом с местом "аллокации" ресурса.
Вроде бы был такой proposal в комитет по стандартизации, и его отклонили/отложили. Сходу не нашёл подробности, было похоже на это https://hal.inria.fr/hal-03090771/document
Жесткая помесь Паскаля, бейсика, С....
>но проще, чем Си
>неймспейсы
>let без scope
>паскалятинкаОпять мусора в язык напихали и говорят, что проще. Почему у каждого любителя ХМ в голове живёт js?
Почему js? Автор много пишет на go, поэтому скорее его влияние присутствует.
И именно поэтому у автора проклёвывается let без части in, как это есть в js и вроде бы как в go нет. Клозетных джаваскриптеров за версту видно.
Надо уже взять и расставить все точки на си. Сделать компилятор из s-выражений на типа сишечном синтаксисе и лисповых макросах. Вуаля, раст, зиг, ви, харэ и прочий хайль становятся резко переоценёнными.
> Надо уже взять и расставить все точки на си. Сделать компилятор из
> s-выражений на типа сишечном синтаксисе и лисповых макросах. Вуаля, раст, зиг,
> ви, харэ и прочий хайль становятся резко переоценёнными.Да в сишке препроцессор так то есть, загугли "какой-то козел стал чих пых". Правда, это только в студии катило с русским, но на инглише можно зажечь.
>Да в сишке препроцессор так то естьМакросы лиспа - это прокачанный препроцессор, в котором можно нарисовать свой control flow и кучу фич. И на генсимычах можно генерировать не пересекающиеся имена. Так-то да, я через бэкслеш могу навешать foreach-и и так далее, но лиспомакросы имеют доступ не просто к тексту, а к AST. И в AST лезть - по этой задаче проще лиспа нет никого.
Т.е. если некоторым хочется прокачанного си, пускай берут представление на s-выражениях, где можно залезть в ast, а не эти попытки запилить ещё один раст с очередным contributor covenant, типа безопасностью и апелляцией к вчерашним фронтендерам.
Лично мне синтаксис S-выражений кажется уродским и невыразительным, так что спасибо но нет.А если прогер будет сильно перепахивать яп под себя, будет хуже чем у плюсеров где каждый пишет на своем субдиалекте, поэтому взяв проект вон того придурка поди вообще в нем разберись...
Так что сильно увлекаться такими вещами ну нафиг, такие проекты потом не подлежат совместной разработке и долговременному майнтенансу. Упражнизмы для концептуалов-наколенщиков. Лучше резьбой по дереву займитесь или вышиванием, так от вашего самовыражения вреда окружающим меньше.
>И в AST лезть - по этой задаче проще лиспа нет никого.Сам ЛИСП - концептуальный уродец, на котором можно писать лишь одноэкранники, да и те - ради понтов. Если уж по локти в АСТ, то лучше брать Немерле.
> Сам ЛИСП - концептуальный уродецПо этой фразе однозначно можно отделить тех, кто понимает Лисп и умеет программировать от тех, кто заблудился в профессии. Ты, например, из последних.
>> Сам ЛИСП - концептуальный уродец
> По этой фразе однозначно можно...По твоим подростковым диагнозам можно однозначно сказать - ты ещё салага в ИТ и все твои понты только и держатся на знакомстве с парой экзотичных языков. Чем ты тут гордишься - непонятно, твоих достижений тоже не видно. Так что иди к мамке и скажи, что 3@дротов в сети никто не любит.
Откройте для себя 10-е правило Гринспена. Я, например, без вот этих всех выступлений могу честно признаться, что лямбда-исчисление Чёрча для меня слишком сложно, а пару лисп-машин не дописал и отправил в мусор, поскольку один раз получился жабоскрипт, а второй -- невесть что. ;)
> Откройте для себя 10-е правило Гринспена. Я, например, без вот этих всех
> выступлений могу честно признаться, что лямбда-исчисление Чёрча для меня слишком сложноЛисп - это не сложно. Это КОНЦЕПЦИЯ. Причём концепция ещё самого расцвета ИТ, когда любые бредовые идеи шли сразу в байты. Но для промышленного программинга ЛИСП оказался слишком вычурным и крайне неудобным в сопровождении (особенно если использовать главный козырь ЛИСПа - генерация кода). Так что я как бы понимаю всю ущербность ЛИСПа, а говнонимус хочет опять неизвестно кому показать, как он крут. Даже непонятно, смеяться тут или сразу лечить.
>> Откройте для себя 10-е правило Гринспена. Я, например, без вот этих всех
>> выступлений могу честно признаться, что лямбда-исчисление Чёрча для меня слишком сложно
> Лисп - это не сложно. Это КОНЦЕПЦИЯ.Лямбда Чёрча - это не язык с названием "процессор списков".
> Даже непонятно, смеяться тут или
> сразу лечить.
>>И в AST лезть - по этой задаче проще лиспа нет никого.
> Сам ЛИСП - концептуальный уродец, на котором можно писать лишь одноэкранники,
> да и те - ради понтов.Вы со своими "двадцатью языками" -- молодой гуманитарий.
Можете спорить, можете не спорить, но математик из Вас никакой.
Вы сами это только что и написали (заодно поспорив с фактами, но это уже лишь довесок).> Если уж по локти в АСТ, то лучше брать Немерле.
Дотнетчики никогда не понимали ФП действительно хорошо, допуская фундаментальные косяки.
А що немерле -- то немерле, тут уж "как вы яхту назовёте".
> Вы со своими "двадцатью языками" -- молодой гуманитарий.Нда... уровень аргументации - даже не гуманитарий, а где-то уровня "а я тебе сейчас куличики сломаю"! Иди уже проспись, болезный.
>> Если уж по локти в АСТ, то лучше брать Немерле.
> Дотнетчики никогда не понимали ФП действительно хорошо, допуская фундаментальные косяки.
> А що немерле -- то немерле, тут уж "как вы яхту назовёте".Ну да. Ещё один аргумент того же уровня. Ты точно не с похмелья вылез тут комментить, милейший?
ну так сделай, чего ждёшь?