Опубликован релиз статически типизированного языка программирования V 0.4.10 (vlang). Основными целями при создании V были простота изучения и использования, высокая читаемость, быстрая компиляция, повышенная безопасность, эффективная разработка, кроссплатформенное использование, улучшенное взаимодействие с языком C, лучшая обработка ошибок, отключаемый сборщик мусора (GC), современные возможности и более удобное сопровождение программ. Проект также развивает свою графическую библиотеку и пакетный менеджер. Код компилятора, библиотек и сопутствующих инструментов открыт под лицензией MIT...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62938
А нужен ли он ?
Каждый уважающий себя программист просто обязан создать свой собственный язык!
У каждого уважающего себя программиста, если он учился не в заборошатательной не-ПТУ-а-колледж или Мухозасиженском Государственном ПолиМиелеТехническом Университете Культуры Имени Отдыха, обычно на 3м - начале 4го курса идёт модуль с теорией компиляторов, в рамках курсача для которого студенты делают свой паскале/бейзико/ассемблероподобный язычок и примитивный компилятор: от разбора текста до генерации бинарного файла вин_х86.Все верно.
но на опеннет-то зачем с этим курсовиком?
> Мухозасиженском Государственном ПолиМиелеТехническом УниверситетеЗа что вы так MTI приложили?
Linux - студенческий курсовой проект
Гм. Да по ощущениям скорее наоборот, только "в глухой провинции у моря" оно и осталось: детишки, садимся в кружок, открываем dragon book на 518 странице и читаем в слух про взаимоот-с-ношения яков-с-бизонами. Да, мы понимаем, что это вам никогда ни зачем и ни для чего не пригодится, но в конце 80х, когда верстали программу - это было еще актуально, так что готовимся - нам до конца года еще свой диалект LISP писать..."
В более приличных местах, судя по тому, что я вижу - на соответствующих курсах уже какой-нибудь DSL поверх джвы пилят, что как бы уже это... болеедругое(ТМ)
>только "в глухой провинции у моря" оно и осталосьА там язык будет на уровне турбопаскаля, сорокалетней выдержки, или хоть с каким-то намёком на современность?
Обижа-аа-аете, C89 - как препода и учили!
Учился чёрти где, своих компеляторов не писал и не понимаю нафига бы они мне упали.
Сам по себе язык делать - идея так себе, если нет конкретной потребности в нём.А вот если делать игру, в которой будет скриптинг на своём собственном языке, а потом этот язык развить до универсального - вот это выглядит уже разумнее.
Чуть менее зашоренный аналог Go с C ABI и большой библиотекой из коробки ? Шутите ? Конечно нужен, если конечно авторы сохранят такую совместимость на должном уровне и если библиотеки продолжат развиваться. Единственное, с учётом того, что его не спонсируют корпорации, то путь у него будет тернистый, но всё же, если сообщество будет достаточно активным, то хороший язык получится.
Просто пишите на го.
Пробовал. Не получается. В результате выходят хелловорлды по несколько мегабайт.
Ну если на Go не получается, с чего ты решил что на вот этом - получится?
Шел бы ты в танцы чтоли :)
А я и не решил. На этом хотя бы есть шанс, что получится. А на go точно без вариантов.
Я ж говорю - тебе в танцы а не в программинг :)
> В результате выходят хелловорлды по несколько мегабайт.В таком случае оставайтесь на второй год в начальных классах, если у вас с банальной арифметикой плохо (не то что с програмированнием), так как хеловорд на Го не может быть более 2 мег ;)
Для двоечников:
```
package main;func main(){println("Hi anonimchik!")}
```
>Чуть менее зашоренный аналог Go с C ABI и большой библиотекой из коробки ?Давно уже есть, даже раньше чем Go появился, называется D https://dlang.org/
Точнее, вместо Сишки, то BetterC.
Да кто ж про Ди не знает? Все занют что он "не взлетел" :(
Zig есть из активных
> Zig есть из активныхЯзык с ручным управлением ресурсами в 2025 году? Спасибо, уже нажрались Сишечки за полвека.
Языка у которого нет даже первого релиза - всё ещё нет
Спонсоры, донатеры, корпорастеры это так все языки развивались? Си тоже корпами популяризировался или EcmaScript? Или сами разрабы его двигали путем использования?
Это не претензия, это размышления, если ЧО ;)
> Спонсоры, донатеры, корпорастеры это так все языки развивались? Си тоже корпами популяризировался или EcmaScript?Именно так. Потому что разработчики работают на корпорации и используют технологии, которые применяют в корпорациях. А любительские игрушки вроде сабжа никогда погоды не делали.
Си - язык, на котором написана когда-то популярная Юникс. Без успеха Юникса Си остался бы на свалке истории, как его предшественники.
Как бы не на свалке, но протекает в ту сторону. Власти США уже запланировали перейти на безопасные языки.
И это их попытка нумбер ....тцать :)
А я им верю - теперь то всё точно поуичиЦЦо!
Ну удачи им заменить GCC и LLVM хотя бы на уровне их развития в 2010 году, не говоря уже про 2025.
> с учётом того, что его не спонсируют корпорации, то путь у него будет тернистыйСори, но без спонсирования корпорациями у него вообще не будет никакого пути. Потому что в реальной жизни на реальных проектах это никто использовать не будет. Удел его - вон те игрушки, которые сами авторы и пишут.
Вы бы сами-то завязали свой коммерческий проект поделку от дюжины безработных васянов вместо проверенного в бою языка? Ну вот даже если опустить такую мелочь, как отсутствие на рынке труда разработчиков, его использующих?
Как минимум всю работу над языком уже оплачивает одна компания, возможно остальные подтянутся позже когда они увидят в этом выгоду
>C ABI и большой библиотекой из коробки ? Шутите ? Конечно нуженТак, давайте подумаем, что уже есть подобного? Rust, Vala, Terra, Standard ML (MLton, Mythryl), Cython, Ocaml, Go (cgo), c# и куча других языков, о которых я либо не знаю, либо забыл. Так зачем вам ещё один, неуж-то предыдущих было мало? Так что нет, не нужен
+ PowerShell
Это простой транслятор в си, такое каждый на коленке сделать может. А значит, нужен только если тебе зашёл его синтаксис.
> Это простой транслятор в си, такое каждый на коленке сделать может.Даже это лишним считаю. Можно в Cи #define-ми внешний вид операторов поменять по приколу, и достаточно.
А какая разница ? Разрабы вполне умно сделали, ибо у них было одно из двух - взять в качестве промежуточного языкового представления какой-нибудь LLVM IR или взять самый распространённый и популярный язык способный взять на себя эту роль, т.е. сишку, бонусом они получили возможность меньше тратить времени на колдовство с LLVM IR, доставку(в базовой поставке можно носить `tcc`) и высвободили больше ресурсов на развитие возможностей языка и библиотек, бонусом дав возможность без мороки встраивать сишный код и библиотеки на нём по аналогии с тем как обычно встраивается ассемблерный код в саму сишку. Да и если генерить достаточно оптимальный сишный код, то тогда как по мне и переезжать на чистый натив смысла нет, тем более что сишка очень легковесная и с ней нет проблем со скоростью компиляции.
мне синтаксис не нравится, лучше напишу свой
Завязка на Си - это означает иметь все те же проблемы, что и Си, поскольку Си семантически неоднозначен, что указано даже в стандарте (Implementation-Defined behaviour, Undefined Behaviour, Unspecified Behaviour).Тем самым,ты не решаешь проблемы Си, а порождаешь новые, поскольку ты дробишь экосистему и всё ещё твоя программа содержит некорректный код, на который за слоем транспилера ты никак не можешь повлиять.
>с ней нет проблем со скоростью компиляции.Ха-ха-ха, проблем у него нет. Видимо, проблем настолько нет, что Инго Молнар целый год разбирал кучу овна в ядре Линукса, чтобы при написании кода ты не умер от старости при сборке. А таких проектов на миллионы строк в проде дофига - базы данных, игровые движки, всякий коммерческий софт вроде медицинского оборудования, CADы...
Не генерь си с UB и всё.По такой логике все проги такие, так как в машинный код в конце превращаются)
>тем более что сишка очень легковесная и с ней нет проблем со скоростью компиляции.Есть - так как при компиляции через промежуточный язык возникают лишние шаги, типа парсинга сишных исходников. Это будет куда медленнее, чем выдавать сразу машинный код, как это делает go, ocaml, или любой другой язык с быстрым компилятором.
Ви компилит себя за 0.3 секунды:
Проблема всех языков в раздутом синтаксисе, а также в том, что люди не могут остановиться. В какой-то момент даже приличные простые языки начинают сжирать сами себя. Тот же Питон, каким он был и каким стал, это просто дичь.
У LISP раздутый синтаксис?
конечно - вона сколько скобочек надо для просто хеловрота!
Успокойтесь, где LISP, а где русский программисты. Они такое слово не знают
Знают. У меня даже книжка по лиспу была в 2-х томах. Интересно было ознакомиться, но не нашел практического применения. Можете возразить словами Шерлока Холмса: "Именно практическое!"
Я практически применяю: пишу математику на лиспе. И когда она оттестирована и работает как надо - переделываю в прод на с++.
Сначала используете функциональный ЯП, а потом переписываете на императивный? Какой-то весьма странный подход. И вам за это деньги платят? Или это для души?
> Сначала используете функциональный ЯП, а потом переписываете на императивный? Какой-то
> весьма странный подход. И вам за это деньги платят? Или это
> для души?Ээээ... называть кресты "императивным" языком - это прям сильно. Т.е. можно на ём и так - но прям стараться надо, чтоб ООП сильно не измазаться. А так-то он "мультипарадигменный", по элементы ФП включительно.
Чтобы из формул сделать программный код, ООП не полезно. Только отвлекает от сути.
> Чтобы из формул сделать программный код, ООП не полезно. Только отвлекает от
> сути.Ну, если не заботиться о валидации ввода, исключениях, и краевых случаях то да - "код датасайентистов"(ТМ) и получится.
Вы перечислили очень важные задачи. Я их решаю следующим образом. Ввод-вывод, контроль допустимости данных и их очистка, обработка исключений (как правило, ввода-вывода) выполняются отдельными модулями, никак не связанными программно с расчетными модулями. Расчетный модуль предполагает, что данные абсолютно ""хороши" для него. Это немного необычно, потому что в известных мне библиотеках (ASA, SAP, IMSL, ESSL и другие из прошлых и текущих) как раз расчетный модуль имеет кучу возвращаемых кодов, сообщающих о той или иной ошибке из генерируемых выше. Неприятности, которые контролирует расчетный модуль, у меня ограничиваются контролем выделения и корректного освобождения памяти и отслеживанием ошибок переполнения и потери значимости.
> Вы перечислили очень важные задачи. Я их решаю следующим образом. Ввод-вывод, контроль
> допустимости данных и их очистка, обработка исключений (как правило, ввода-вывода) выполняются
> отдельными модулями, никак не связанными программно с расчетными модулями. Расчетный
> модуль предполагает, что данные абсолютно ""хороши" для него. Это немного необычно,
> потому что в известных мне библиотеках (ASA, SAP, IMSL, ESSL и
> другие из прошлых и текущих) как раз расчетный модуль имеет кучу
> возвращаемых кодов, сообщающих о той или иной ошибке из генерируемых выше.
> Неприятности, которые контролирует расчетный модуль, у меня ограничиваются контролем
> выделения и корректного освобождения памяти и отслеживанием ошибок переполнения и потери
> значимости.Тут видимо кто что и как считает. У меня большая часть проблем связана не с формальным соответствием ввода спецификации\схеме данных, а например "физическим смыслом" датчик сбоит - давление на выходе категорически не соответствует давлению на входе, формально все данные корректны - а по сути издевательство, и проверять вот это все в отрыве от "математики" (Еще и достаточно простой, так что такты CPU экономить незачем) - ну, такоЭ себе. А вот условное "моделирование" в ООП-парадигме показывает неплохие результаты.
То, что вы описали, немного похоже на тестирование программы на так называемых, извините за жаргон, "дурацких" данных. Когда пользователь вправе ввести что угодно - любые числа, даже физически невозможные для данного класса проблем, но алгоритм должен обработать такие экстремальные ситуации.
> То, что вы описали, немного похоже на тестирование программы на так называемых,
> извините за жаргон, "дурацких" данных. Когда пользователь вправе ввести что угодно
> - любые числа, даже физически невозможные для данного класса проблем, но
> алгоритм должен обработать такие экстремальные ситуации.Ну не то, чтобы прямо "да" - но близко. Ошибки уровня предметной области вообще самые неприятные, делать для них валидатор вне логики основных расчётов == фактически воспроизведению этой же логики в валидаторе, ну и вот нахрена оно?
С чего бы он не императивный?
Вы что, хотите сказать, что ООП противоречит имеративности?
> С чего бы он не императивный?С того, что он "мультипарадигменный" с очень сильным уклоном в сторону специфического ООП. Не до уровня "все есть объект", разумеется - но писать на нем _вообще_ не соприкасаясь с ООП некоторым образом эээээ... затруднительно.
> Вы что, хотите сказать, что ООП противоречит имеративности?
Ээээ... это _буквально_ разные концепции - "описание последовательности шагов до достижения результата" vs "моделирование предметной области с помощью классов объектов".
Ну дак мультипарадигменность не отменяет того, что он императивный. Эти концепции сочетаются.> писать на нем _вообще_ не соприкасаясь с ООП
На Си же писали без ООП, и ничё.
> Ну дак мультипарадигменность не отменяет того, что он императивный. Эти концепции сочетаются.То, что я могу писать на python'е "в императивном стиле" даже main() не объявляя не сделает его "императивным языком", ja? Как был объектно-ориентированным, в котором буквально всё является объектом, так и останется.
>> писать на нем _вообще_ не соприкасаясь с ООП
> На Си же писали без ООП, и ничё.Ну в общем "да" - но удачи вам написать так что-то сложнее хелловрота. И да, даже успешное начинание подобного рода "императивным" язык не сделает).
Ты слово "императивный" путаешь с "процедурным", имхо.Императивный - как делать.
Декларативный - что делать.ООП входит в императивный стиль. И python - обычный императивный ЯП.
Это тебе не лисп, и не пролог.
> Ты слово "императивный" путаешь с "процедурным", имхо.Этой имхе бы какого подтверждения...
> Императивный - как делать.
> Декларативный - что делать.
> ООП входит в императивный стиль. И python - обычный императивный ЯП.
> Это тебе не лисп, и не пролог.Не входит. Императивный подход широко используется для описания поведения методов - это да, но сам концепт - "моделирование предметной области через изменение состояния объектов путем реализации специфицированного поведения" таки сильно отличается от "(линейной) последовательности операций, обеспечивающих выполнение..."
Но тут может конечно "кого как учили" "два еврея - три синагоги", "количество ангелов на острие иглы" и вот это всё ). Событийно-ориентированное программирование - оно "императивное" или не очень? С одной стороны явно не "декларативное", и обработчики событий вполне себе в виде последовательности действий могут описываться - с другой стороны "явного execution flow" того-с... нету.
Ты слишком всё усложняешь.Императивный подход означает свободное управление процессом выполнения.
Попробуй в прологе задать переменную с заданным значением (с дальнейшим её прямым использованием) или развернуть цикл на заданное число итераций как сделал бы в том же питоне. Увидишь разницу декларативного языка от императивного.
> Событийно-ориентированное программирование - оно "императивное" или не очень?
Ты же можешь управлять событиями, как и генерировать любые из них, значит прямо влияешь на управление процессом.
Есть примеры книг по математике с примерами на прекрасно читаемом кодом на С (в дополнение к Фортрану). Зачем двойную работу делать?
"Для понимания того, что затрудняет использование функционального программирования в производственной практике, также необходим теоретический анализ. Функции оказываются столь абстрактными и высокоуровневыми объектами, что непосредственная интуиция и попытки действовать чисто экспериментально немедленно ведут в тупики."
Кто ясно мыслит - ясно излагает.
Когда неясен дальнейший путь, нужно вернуться к истокам. Только C.
У Си слишком раздут синтаксис. Вот у машинного кода вообще нет синтаксиса.
> раздут синтаксисПо сравнению с чем? С ассемблером - ок. А так не особо.
У Си может синтаксис выглядит не так человечно, как у современных языков, да ещё и его препроцессор всё сильно усугубляет, но у многих соверменных языков синтаксис сложнее. Но это не значит, что на них писать тяжелее, скорее наоборот.
> Вот у машинного кода вообще нет синтаксиса.{0,1}
Это не синтаксис, а базовая лексика.
Это вообще-то алфавит машинного языка, с помощью которого кодируются коды-операций центрального процессора. Синтаксис - это правила по которым строятся последовательности из алфавита языка. Лексика - смысл.
> Лексика - смысл.Лексика - словарный запас, то есть последовательность 0 и 1.
Пересмотрите Кернигана-Ритчи и восхититесь красотой языка.
Я стандарт смотрю, там язык другой.
А вы выйдете за навязываемые ограничения и посмотрите на язык до его стандартизации. И да, пока ещё можно писать без "стандартных библиотек"
> А вы выйдете за навязываемые ограничения и посмотрите на язык до его
> стандартизации.Зачем мне это надо? Создавать свой транслятор K&R C69 я не готов.
> И да, пока ещё можно писать без "стандартных библиотек"
Увы, LSB Core - X86-64 5.0 Edition запрещает не использовать glibc:
Table 7-1. Non Conforming Instructions
...
SYSCALL
...Conforming applications shall not invoke the implementations underlying system call interface directly. The interfaces in the implementation base libraries shall be used instead.
Питон это самое лучшее что было с языками программирования - доля рынка вещь упрямая.
Питон очень плох для крупных проектов, если не придерживаться определённого стиля программирования. А популярен он только из-за кажущейся простоты и сравнительно богатой стандартной библиотеки. Многим как раз именно такого вполне достаточно.
> А популярен он только из-за кажущейся простотыПочему "кажущейся"? Он на самом деле очень сложный, что ли?
Из-за простоты к нему подтянулись пользователи, включая корпорации. Как результат - и популяреость: теперь это ведущий язык в сфере научных рассчетов, статистики и ML.
Иронично это сработало только из-за того что у него терпимый синтаксис и ОООЧЕНЬ много библиотек в базовой поставке, от чего питон часто и рекламили чем-то вроде "http сервер в одну строку - а ваш C/JAVA и пр. так может ?" Собственно и сейчас питон агрессивно пиарят лукавыми вбросами уровня "Python быстрее C/C++" разной паршивости роликами на ютубе, в которых авторы переносят производительность питонячих обвязко к сишно-плюсовым библиотекам на сам питон. Но в целом всё же уйти от того, что на питоне из коробки можно сделать очень много неплохих однострочников, действительно подкупает многих людей, что не отменят того, что сам язык хотя и сладкий, но уже превращается в брагу, ибо код на питоне сложно поддерживать, в особенности именно из-за того избыток сахара, различные костыли(вроде `if __name__ == "__main__": main()`) и динамическая типизация часто приводит к сложному в поддержке коду и пока некоторые получаемые конструкции могут выглядеть коротко, порой чтобы изменить поведение некоторых однострочников, не вписавшихся в базовый сценарий, их приходится переписывать целиком. Лично у меня в последнее время впечатление усугубилось убогостью конфликта между пакетными менеджерами, pip и самим питоном, от чего каждое крупное обновление питона приводит к слому кучи его пакетов(как раз из-за обёрток в `pytorch, cuda` и пр.) и необходимости всё перекачивать по новой, получая часто нерабочее состояние в котором некоторые пакеты не работают, некоторые работают, с некоторыми не работает ПО, с некоторыми не работает питонячая среда, в некоторых случаях получая жутейшие конфликты всех со всеми, против которых `penv` не спасает. Если же вспоминать о питоне как о единственном языке, то там по мимо сложности в поддержке быстро могут всплыть проблемы с производительностью. Поэтому реклама была крутой и однострочники и последовательные сценарии на питоне писать действительно приятно, но сложное ПО - боль.
> быстро могут всплыть проблемы с производительностьюПроблемы с производительностью в интерпретируемом скриптовом языке? Да быть такого не может!
> писать [...] сложное ПО - боль.
Питон виноват в том, что у кого-то хватает ума писать сложное ПО на скриптовом языке?
Извините, но ваша критика вызывает лишь недоумение.
Так его и рекламируют как язык для всего, его сравнивают по производительности с сишко-плюсами(внимательнее читайте) через обвязки(не упоминая факта того, что производительны именно сишные библиотеки, а не питон). Поэтому мои претензии к нему по большому счёту к его маркетологам, в остальном как язык для накидывания однострочников и последовательных сценариев он действительно неплох, но как отмечал в роллинг дистрах с ним можно огрести.
>> писать [...] сложное ПО - боль.
>Питон виноват в том, что у кого-то хватает ума писать сложное ПО на скриптовом языке?Питон выдаёт ошибку "длина исходника больше 100 строк, перепишите на нормальном языке"? Нет? Тогда аргумент в силе. Поскольку по чуть-чуть размер скрипта выростает до неконтролируемых масштабов
> Питон выдаёт ошибку "длина исходника больше 100 строк, перепишите на нормальном языке"? Нет? Тогда аргумент в силе.Мдэ... А если суп вилкой жрать, то окажется, что она плохой столовый прибор.
Только вот эту вилку пытаются засунуть буквально везде. И системные утилиты, и сайты, и десктоп, и игры, и в математические расчёты, даже в микроконтроллеры пытаются
И встраиваемый язык(куда он совершенно не подходит)
И в этом тоже виноват язык, я правильно понимаю?
В этом виноваты те, кто пишут на этом языке
>Почему "кажущейся"? Он на самом деле очень сложный, что ли?Потому, что легко на нём только hello world-ы строк на двадцать делать. Типизации у него нет, первый же рефакторинг, и будет куча ошибок.
Ээээ... уже "да". Причем как с т.з. перегруженности синтаксическим сахаром и общей "неконсистентности" добавляемых возможностей (Хотя современный php он так и не догнал) - так и с т.з. возможности написать на нем чего-нибудь долговременно сопровождаемое сложнее hello, world!
> теперь это ведущий язык в сфере научных рассчетов, статистики и MLЭто совершенно не так. Он используется только в качестве интерфейса, не более того. Все расчетные алгоритмы выполнены только на C/C++ в силу того, что их скорость в 60 тысяч (!) раз превышает скорость интерпретатора. Кстати, сказанное касается и других модных интерпретируемых "языков" типа R.
> Он используется только в качестве интерфейса, не более того. Все расчетные алгоритмы выполнены только на C/C++Да, именно поэтому он и лидирует в упомянутых областях - потому что люди напрямую работают с этими алгоритмами через человеческие интерфейсы Питона, а не с C/C++/Cuda, которые под капотом.
Для разработки алгоритмов не годится Питон - он слишком медленный. Поэтому сразу его в мусор!
Помнится, лет 30 назад в моде было иллюстрировать математические книги алгоритмами на Бейсике (несколько таких изданий есть в моей библиотеке). Легко понять, что для реальных практических задач эти программы неприемлемы с силу катастрофически низкого быстродействия.
апологеты пайтона предявляют претензии к разработчикам протоколов, что у них клиент блеклый, не все конечно))
Начальник нашего отдела крайне одобряет вашу аргументацию. Мы все — тоже. Пешыте истчо.
Питон дуреет с такой прикормки.
Синтаксис Питона изменился? Это новость.
С 2 на 3.
Он и в третьей версии менялся, с тем же моржовым оператором
А что не так с ним стало? У питона охренительный синтаксис, или вы неосилятор аннотаций типов?
Аннотация типов не обязательна, поэтому относится к стилю программирования. Вам бы внимательнее читать написанное, а потом бы уже строчить вопросы. Кроме того, аннотация типов интерпретатором никак не проверяется. От слова "совсем".
Главная проблема почти всех языков это отсутствие хорошей IDE.У питона в синтаксисе проблема в отступах, которые определяют блок функции или класса. Абсолютно неудачная идея. Или объявление приватного метода, где нужно добавить '_' в качестве префикса, чтобы сделать его приватным. Это бред, а не синтаксис.
От этого он не станет приватным - его точно так же можно вызывать, как и не приватный метод
Ну тогда не знаю, как ещё в питоне объявить приватный метод.
> Ну тогда не знаю, как ещё в питоне объявить приватный метод.
> https://www.geeksforgeeks.org/private-methods-in-python/Ответ собственно не в "как", а "зачем". Для того, чтобы сказать другому разработчику "ты туда не ходи - ты сюда ходи, снег бошка попадет..." общепринятого соглашения в виде "_"/"__" достаточно, а делать это частью языка для борьбы с М.А.Какирами - никто и не планировал.
>отключаемый сборщик мусораА надо было делать опционально включаемый.
OCaml транслируется в байт-код или машинный код. "Скриптовый" ортогонально ко всему этому.
За синтаксис присваивания как ":=" Вирта (и тех, кто скопировал эту "фичу") нужно долго и упорно бить кочергой.
> VinixСовсем фантазии у ребят нету. На названия.
А программистов, которые не способны парсить синтаксис, хоть немного отличающийся от сишечки -- надо гнать ссаными тряпками.
Очевидно, способны. Но они ещё способны давить бесполезные беспринципные языки.В Go таким образом решили сократить var (и понеслось), а тут автор языка говорит, что он любит Go больше, чем кто-либо на свете, и поэтому заставит вместе использовать ключевое слово (mut) и моржовый оператор (:=).
:= — обычное присвоение в математической нотации, чем оно вам не нравится?
Возбухания по поводу begin/end ещё понятны (хоть и это всё же и лучше отступов в питоне), но явно выделенное присвоение — разве плохо?
Это не "явно выделенное присвоение", ты что ли ни Go, ни обсуждаемый язык не видел?
> разве плохоРазумеется. Вместо одного символа '=', теперь нужно писать два ':=', да ещё и с двоеточием, которое чтобы написать, надо шифт зажимать.
> Разумеется. Вместо одного символа '='Ага и для сравнения теперь я должен два символа '==' писать?
Ну и что?
Два равно проще написать чем двоеточие.
Да и присвоение мне кажется чаще используется чем сравнение.
> Да и присвоение мне кажется чаще используется ...ага в тех самых сравнениях чаще используется :р
>Вместо одного символа '=', теперь нужно писать дваВремени вы от этого почти не сэкономили, а вот потенциальную ошибку - создали
А в чём ошибка то?
if (a = b)
Ну дак компилятор тут должен ошибку выдать. А если нет, значит дизайн языка тупой.
А компилятор не знает, баг это или фича. Более того, это распространённый паттерн в си подобных языках
if (a = b()) {
///
}
> теперь нужно писать два ':=', да ещё и с двоеточием, которое чтобы написать, надо шифт зажимать.Пиceц пацаны... Я думал, я очень ленивый, ан нет, выиграли :)
>> теперь нужно писать два ':=', да ещё и с двоеточием, которое чтобы написать, надо шифт зажимать.
> Пиceц пацаны... Я думал, я очень ленивый, ан нет, выиграли :)Ничо-ничо, чатжопэте еще и код за них писать будет :)
Писать := надо только один раз при определении переменной.Присваивание всё так же =
Что ты будешь делать с этими сэкономленными секундами, анон?
Вот когда у тебя глаз замылится и ты не сможешь в коде увидеть, что вместо проверки на равенство (==) стоит присвоение значения (=), твои сэкономленные секунды пойдут по одному месту.
> программистов, которые не способны парсить синтаксис, хоть немного отличающийся от сишечки -- надо гнатьПрграммисты-то могут. А вот опеннетные комментаторы, не имеющие никакого отношения к разработке ПО, всерьез веруют, что выучить язык - самое сложное в любой предметной области. Вот как только выучишь - и сразу ядра ОС и прикладной софт всех мастей будет литься, как песня!
>> программистов, которые не способны парсить синтаксис, хоть немного отличающийся от сишечки -- надо гнать
> Прграммисты-то могут. А вот опеннетные комментаторы, не имеющие никакого отношения к разработке
> ПО, всерьез веруют, что выучить язык - самое сложное в любой
> предметной области. Вот как только выучишь - и сразу ядра ОС
> и прикладной софт всех мастей будет литься, как песня!Вот это самое смешное: здешние "программисты" даже синтаксис осилить не могут. А ведь дальше им браться за семантику. А про "предметную область" и прочие страшные слова они и слыхом не слыхивали. Зато своё "экспертное" мнение у них имеется.
Мне не нужно их парсить. Когда пишу программы, я думаю на С.
> Мне не нужно их парсить. Когда пишу программы, я думаю на С.Чем же тут гордиться? :)
> Совсем фантазии у ребят нету. На названия.По-твоему нужно было Vindovs?
Да как бы ровным счетом наоборот - использование символа "=" (равенство) для обозначения оператора "присваивания" - источник целого класса ошибок.
"У Пети было 5 яблок. У Васи - на три яблока больше. Сколько яблок было у них обоих?".Интуитивная алгебраическая запись:
---------------------------------
Петиных = 5
Васиных = Петиных + 3 = 5 + 3 = 8
ВсегоЯблок = Васиных + Петиных = 5 + 8 = 13Запись от Вирта для студентов Макнамары:
---------------------------------
Петиных := 5
Васиных := Петиных + 3; // 5 + 3 = 8
ВсегоЯблок := Васиных + Петиных // 5 + 8 = 13
"Yoda notation" от большой интуитивности возникла, ага.
А обратная польская - тобы высвободить битики и облегчить разбор ввода для стек-машины, и?Те ухищрения, которые имели смысл на машинах 70х-80х, сегодня имеют только эволюционно-познавательный смысл.
Но не уводи тему-то
> А обратная польская - тобы высвободить битики и облегчить разбор ввода для
> стек-машины, и?
> Те ухищрения, которые имели смысл на машинах 70х-80х, сегодня имеют только эволюционно-познавательный
> смысл.Ээээ, да, но нет. В смысле, сейчас эту проблему конечно на уровне IDE\компилятора порешали - но цэ именно что "обкостылинг", да и изначально крови выпито немало, без чего вполне себе можно было и обойтись.
\Ну и да, учитывая отсутствие в дикой природе кода на С без варнингов, предполагаю, что тулинг проблему решает вот нифига не полностью\> Но не уводи тему-то
Не увожу. Исходный тезис - в силе, и технологии обкостылинга проблемы подтверждают её актуальность. Да, любителям "интуитивной алгебраической записи" надо последовательно топить за отказ от второго "=" при записи равенства "==" - математики же как-то обходятся, да? Аж на целый ещё один символ короче будет - шах-и-мат, Николя!
> "Yoda notation" от большой интуитивности возникла, ага.А оператор "доктор Зойдберг в берете" (`/:=`) от чего возник? В C проблему решили через -Wparentheses, а целиком решили в D. Без Зойдбергов.
И претензия не в тему, оператор присвоения в Go и V - это `=`. Go и C++17 позволяют его одинаковым образом использовать внутри if. Без Зойдбергов.
>> "Yoda notation" от большой интуитивности возникла, ага.
> А оператор "доктор Зойдберг в берете" (`/:=`) от чего возник? В C
> проблему решили через -Wparentheses, а целиком решили в D. Без Зойдбергов.Ну да - изначальные проблемы в дизайне языка _частично_ обкостылили тулингом, ergo - проблемы-то и не было! "Л" - логика!
> И претензия не в тему, оператор присвоения в Go и V -
> это `=`. Go и C++17 позволяют его одинаковым образом использовать внутри
> if. Без Зойдбергов.Какое отношение это имеет к моему исходному тезису, м?
> Ну да - изначальные проблемы в дизайне языка _частично_ обкостылили тулингомОтвет неправильный, эти языки с проблемами закопали целиком. От алгола с его +:= до дельфи.
> Какое отношение это имеет к моему исходному тезису, м?
Так давай показывай свой "целый класс ошибок" в V, тут же присвоение через `=`.
Или в Go. Вот тут: `if x = rand.Uint32() % 10; x > 5 {...}`
Или в D.
> ergo - проблемы-то и не было!
Не, я могу объяснить очевидное, мне не лень.
Проблема была. Но решать её через `:=` не следует.
C и C++ - это языки со священной коровой обратной совместимости. В этом их суть - тащить проблемы начиная с 70-х. C++ неудачную реализацию регулярок будет тянуть до своей смерти - и не важно, что она тормознутая и что ей почти никто не пользуется, скорость языка - это для комитета мелочь на фоне обратной совместимости.
Поэтому странно рассчитывать на решение, ломающее обратную совместимость (как в D). Хотя с учётом того, как Страуструп переобулся насчёт эпох (раньше всё твердил, что "нельзя создавать диалекты", а сейчас сам продвигает профили), у тебя шансы есть.
>> Ну да - изначальные проблемы в дизайне языка _частично_ обкостылили тулингом
> Ответ неправильный, эти языки с проблемами закопали целиком. От алгола с его
> +:= до дельфи.Да-да-да, а вот с, с++, javascript "без проблем" все еще живут.
>> Какое отношение это имеет к моему исходному тезису, м?
> Так давай показывай свой "целый класс ошибок" в V, тут же присвоение
> через `=`.
> Или в Go. Вот тут: `if x = rand.Uint32() % 10; x
> > 5 {...}`Иронично, что в go присваивание в управляющих конструкциях как раз таки через := делается ).
Вот только из перечисленных сколько-нибудь широко используется go, а в c\c++\javascript которых кратно больше... ну, вы поняли.>> ergo - проблемы-то и не было!
> Не, я могу объяснить очевидное, мне не лень.
> Проблема была. Но решать её через `:=` не следует.Не то, чтобы "была", а в общем-то вполне себе "есть", пусть острота некоторым образом и снизилась. Но внимание, вопрос! Что было проще сделать в одна тысяча девятьсот семьдесят лохматом году: поменять дизайн языка с учетом послезнания или вот использовать "более другую" закорючку?
>> Или в Go. Вот тут: `if x = rand.Uint32() % 10; x > 5 {...}`
> Иронично, что в go присваивание в управляющих конструкциях как раз таки через := делается ).Нет, это рабочий код, надо лишь выше определить x. Так где этот "целый класс ошибок" в Go, V, D, Rust?..
> Не то, чтобы "была", а в общем-то вполне себе "есть",
> пусть острота некоторым образом и снизилась.Судя по гуглокнигам, -Wparentheses и -Wall в начале 90-х уже были. Если кому-то требуется больше 30 лет, чтобы выучить опцию компилятора...
> Что было проще сделать в одна тысяча девятьсот семьдесят лохматом году:
> поменять дизайн языка с учетом послезнания или вот использовать "более другую" закорючку?А предзнание использовать никак? Из фортрана или PL/I?
Было проще продвигать дальше юникс-вейное "чем хуже, тем лучше". Двоичные литералы C получил лет через 60 после своего предшественника, PL/I. Может, предшественник не имел ни проблемы ошибочного присвоения в if, ни Зойдбергов? Да, в нём нет assignment expression, только statement. Может, это было случайное решение? Судя по наличию в нём и checked-арифметики из C23 - вряд ли.
> Интуитивная алгебраическая запись:Петиных <- 5
Васиных <- Петиных + 3
ВсегоЯблок <- Васиных + Петиных
> Интуитивная алгебраическая запись:
> ---------------------------------
> Петиных = 5
> Васиных = Петиных + 3 = 5 + 3 = 8
> ВсегоЯблок = Васиных + Петиных = 5 + 8 = 13На типизированных языках - не прокатит, прийдется сперва представить, кто по жизни они там есть, - эти Петя и Вася и что это они вообше там за общак замутили в виде ВсегоЯблок.
Поэтом сравнилово - не катит
> Запись от Вирта для студентов Макнамары:
> ---------------------------------
> Петиных := 5
> Васиных := Петиных + 3; // 5 + 3 = 8
> ВсегоЯблок := Васиных + Петиных // 5 + 8 = 13Т.к. о Го разговор, то
:= лишь о том, чтоб обьявить **новую** переменную того типа который присваивают, и когда она уже обьявлена, то повторное := выстрелит ошибку, т.к., надо изпользовать тогда просто =
> Интуитивная алгебраическая запись:
> ---------------------------------
> Петиных = 5
> Васиных = Петиных + 3 = 5 + 3 = 8
> ВсегоЯблок = Васиных + Петиных = 5 + 8 = 13От алгебры здесь только значки. А "интуитивно" -- будет так:
Петиных: 5;
Васиных: петиных + 3, т. е. 5 + 3 = 8
Всего яблок: васиных + петиных, т. е. 5 + 8 = 13Как ни странно, эта интуитивная запись больше похожа на ':='. Вообще, трудно придумать что-то более глупое, чем знак равенства использовать в качестве оператора присваивания. К сожалению, благодаря сишечке это стало мейнстримом. А по моему мнению, лучшим выбором было бы как раз двоеточие. Идеально подходит по смыслу.
В математике либо пишут название переменной и равенство с двоеточием, либо "Пусть x = ...".
Вторая форма записи кстати представлена в некоторых языках через словечко let.
> В математике либо пишут название переменной и равенство с двоеточием, либо "Пусть
> x = ...".
> Вторая форма записи кстати представлена в некоторых языках через словечко let.Нет, в таких случаях в математике применяется тире, а не знак равенства. Потому что как раз математики хорошо умеют отличать формальную запись (к коей относится знак равенства) и текст на естественном языке (к коему относятся тире или двоеточие).
Правильный ход - сразу своя графика из коробки. Одна из причин почему взлетел Питон. И почему не взлетает Раст, хотя толкают мощно.
>И почему не взлетает РастОсталось понять, почему вы так считаете. Стандартная графическая библиотека - это не то, что необходимо языку, который прицелился на написание системного ПО. А так для Rust существуют как минимум две таких библиотеки уже: egui, iced.
И все плохие. Вот на этом языке и нет нормального гуй софта.
Его в 2k25 на любом ёзыке - НЕТ! :)
KDAB пытаются делать биндинги к qt, но их блог больше похож на журнал проповедей баптистской церкви
Системщиков мало. Прикладников, которым нужно хоть какое-то ГУИ в разы больше. Именно они и делают инструмент популярным. Кстати системный Си почти сразу получил графику, огромное количество игр еще с дос-оских времен.
> это не то, что необходимо языкутипичная логика фанатиков раста: если у них в языке что-то не так или чего-то нет, ответ всегда один - "тебе это не нужно"
Питон взлетел совершенно не по этому. Раст взлетел вопреки этому. Какая-то с ног на голову перевёрнутая реальность.
Основная причина взлета Питона это переход от "код как алгебраическое выражение" к "код как геометрическая форма". Переход только частичный, эти блоки отступом, но это уже качественно иной уровень и сразу изрядная ликвидация синтаксического мусора ( {}, bеgin, end )
Ээээ... идея, что программистов можно выдрессировать не ходить под себя и писать читаемый\сопровождаемый код - как раз таки очевидно неудачная.
"Взлетел" он по причине терминальной вырвиглазности perl'а, полной убогости тогдашнего php, Окадемичности тикля и неприспособленности bash'а к написанию чего-нибудь сопровождабельного длиннее 15 строчек.
Союзно!(С)
>но это уже качественно иной уровень и сразу изрядная ликвидация синтаксического мусора ( {}, bеgin, end )И невозможность автоформатирования. Откройте https://try.ocamlpro.com/, и попробуйте написать код - табуляцию нажимать не придётся вообще, табуляция выводится сразу же из синтаксиса.
Самое забавное, что для python'а тоже широко используются форматтеры - посмотрите на какой-нибудь black :).
Интересно, как они будут работать? Для того, чтобы понять, как это кодить на питоне, достаточно представить, что при вставке кода случайно бы вставлялось несколько случайных символов {}, и каждый раз после вставки нужно было бы их удалять
> Интересно, как они будут работать?Ээээ... пишешь код, а при коммите хуком дергается black и приводит написянное к единому стилю, что не так-то?
И как вам это поможет писать код, не трогая клавишу табуляции, не зажимая пробел и не формотируя код руками каким-то другим образом?
> И как вам это поможет писать код, не трогая клавишу табуляции, не
> зажимая пробел и не формотируя код руками каким-то другим образом?А зачем бы мне это "обеспечивать"? У меня задача - обеспечить _читаемость_ кода. Хочет уася все "в одну строчку через;" - хрен ты ему запретишь, он художник, он так видит!
А вот в репозитории все должно быть в соответствии с корпоративным стайлгайдом, и тут форматтер-линтер-санитайзер-черт-в-ступе вполне к месту. А количество нажатий пробела кодописакой мне до звИзды, если честно.
> Раст взлетел вопреки этомувот только раст не взлетел
>И почему не взлетает Раст, хотя толкают мощно.Видно, не туда толкают ;)
Все новые проекты пишу на V, потрясающий язык, к Go даже возвращаться не хочется
>Все новые проектыВсе новые хелловорды? Go, конечно, ещё тот отстой, но ведь это V - оно ведь сырое ещё.
Вы только посмотрите на него! Какой молодец!
хотелось бы узнать что за программы. Сценарии? Расчёты? Приложения?
Пока что лучший язык.
По какому критерию?
По критерию лучший язык.
Критериев может быть несколько. По критерию худший язык он худший?
Критерий лучший язык один. И сам факт существования этого критерия говорит о том что он не может быть худшим языком.
Критерий никогда не бывает один. И вам доказали, что поменяв критерий, вы получили противоположное утверждение. Вы пришли к противоречию. Следовательно, исходные предположения ошибочны. Ч.т.д.
Лучший язык по критерию лучший язык? Интересно. А ты, видимо, самый умный человек среди тебя.
Автор русский, а статьи в русской Википедии почему-то нет. Странно!
В английской Википедии статьи о таком языке тоже нет.
> В английской Википедии статьи о таком языке тоже нет.
Непонятно, почему господин выше посетовал, что нет на русском. Хотел провокацию устроить? На немецком и на литовском тоже нет. Кстати, перевод браузером весьма неплох.
Потому что нет на русском.
За свой собственный пакетный менеджер можно сказать, что у проекта есть вопросы с будущим.Что бы он взлетел, нужна интеграция с другими языками, а свой собственный пакетный менеджер поощряет практику изоляции от проектов на других языках.
Как только появляется пакетный менеджер, это уже не язык программирования, а система со своей инфраструктурой, которую рано или поздно сломают. Все подобные проекты было ломаны и неоднократно.
Кстати, когда устанавливаешь либу для реакта из npm, он автоматически показывает, сколько там уязвимостей. Жесть, во что превратили веб. И в расте есть карго. Значит, и раст с уязвимыми пакетами хз от кого.
> Кстати, когда устанавливаешь либу для реакта из npm, он автоматически показывает, сколько там уязвимостей. Жесть, во что превратили веб. И в расте есть карго. Значит, и раст с уязвимыми пакетами хз от кого.А C и C++ пакетных менеджеров нет, но зависимости никуда не делись. И они там не менее "хз от кого", и сколько уязвимостей никто не показывает, хотя их там на порядки больше.
> А C и C++ пакетных менеджеров нет, но зависимости никуда не делись. И они там не
> менее "хз от кого", и сколько уязвимостей никто не показывает, хотя их там на порядки больше.Виндопроблемы. В линухах с нормальными дистрами это обеспечивается общесистемными политиками апдейта пакетов.
А в винде и с теми пакетниками будет - васянпомойка. У каждого яп свои полися по части пакетов, секурити, слома совместимости и проч, так что вот вам дюжина апдейтеров (попробуйте вспомнить какой вы уже запускали) - и хрен знает что отлипнет после апдейта. Так что безопасно вам ессно так - не будет. Хоть там что.
В линухе то как раз с единой точкой апдейтов и конкретными полисями этого всего - еще можно потрепыхаться. Если все ставить именно системным пакетником, а не....
>> А C и C++ пакетных менеджеров нет, но зависимости никуда не делись. И они там не
>> менее "хз от кого", и сколько уязвимостей никто не показывает, хотя их там на порядки больше.
> Виндопроблемы. В линухах с нормальными дистрами это обеспечивается общесистемными политиками
> апдейта пакетов.Протухший на момент релиза софт идет "в нагрузку", ага.
> Протухший на момент релиза софт идет "в нагрузку", ага.Протухший - лексикон скриптовика.
Главное в дистрибутивах минимизировать изменения API, желательно вообще без несовместимостей.
На желания скриптовиков - глубоко всем положить.
>> Протухший на момент релиза софт идет "в нагрузку", ага.
> Протухший - лексикон скриптовика.
> Главное в дистрибутивах минимизировать изменения API, желательно вообще без несовместимостей.
> На желания скриптовиков - глубоко всем положить.Действительно. И кому бы, кроме "скриптовиков" мог понадобиться "непротухший" nginx? Главное - api не менялось, а то, что 1.22 eol еще до релиза bookworm'а - так то-ж ярунда (Пользоваться дебиановским никто и не планировал).
А кому еще нужен nginx?И да. Именно для такого есть flatpack.
Если уж у ваших приложений суперкороткий период поддержки - идите в песочницу!
Таким только в песочнице и место!
> А кому еще нужен nginx?
> И да. Именно для такого есть flatpack.
> Если уж у ваших приложений суперкороткий период поддержки - идите в песочницу!
> Таким только в песочнице и место!И правда, чо это я? Пойду пацанам расскажу...
> И они там не менее "хз от кого", и сколько уязвимостей никто не показывает, хотя их там на порядки больше.вот только этим занимаются мейнтейнеры. про разделение труда слышал?
> Как только появляется пакетный менеджер, это уже не язык программирования, а система со своей инфраструктурой,Ну если вы это противопоставляете, то языки программирования в вашей формулировке нахрен вообще никому не нужны, потому что программирование это прежде всего реюз уже написанного кода, а для этого нужна экосистема.
> которую рано или поздно сломают
Какой конкретно сценарий атаки вы рассматриваете?
>потому что программирование это прежде всего реюз уже написанного кода, а для этого нужна экосистема.Зачем для каждого нового языка изобретать свой собственный велосипед? Почему не взять уже существующий пакетный менеджер, тот же nix?
> Какой конкретно сценарий атаки вы рассматриваете?Подмену пакетов.
> Какой конкретно сценарий атаки вы рассматриваете?с чего ты взял, что это будет атака? закопают и всё
>Основными целями при создании V были простота изучения и использования, высокая читаемость,
>эффективная разработкаВот интересно, хоть один серьёзный язык, кроме подобных brainf*ck ставил себе целью создать сложный и неудобный для разработки язык? Тогда почему они настолько разные?
> Вот интересно, хоть один серьёзный язык, кроме подобных brainf*ck ставил себе целью создать сложный и неудобный для разработки язык?Языки которые ставят себе целью быть "сложными и неудобными в разработке" и являются "подобными brainfuck", т.е. эзотерическими. Полноценные ЯП себе такую цель ставить не могут, но у многих это получается в силу архаичности (C) или полной некомпетентности тех кто их дизайнил (V) и развивал (C++).
> Языки которые ставят себе целью быть "сложными и неудобными в разработке" и являются "подобными brainfuck", т.е. эзотерическими. Полноценные ЯП себе такую цель ставить не могут, но у многих это получается в силу архаичности (C) или полной некомпетентности тех кто их дизайнил (V) и развивал (C++).Серьёзная такая предьява, oсобенно на счет крестов... критик наверное знатный, где по вас почитать публично можно?
Раст ставил. Чем сложнее код тем меньше уязвимостей. На брейнфаке вообще ни одной cve не нашли за все его существования.
Язык не имеющий стабильной версии - всё равно что не существует. А для несуществующего языка более восьми тысяч проблем - как-то слишком много https://github.com/vlang/v/issues Тем более, со столь примитивной системой типов
> более восьми тысяч проблемЭто закрытые проблемы. Так к чему придирка? К тому что большинство сообщённых проблем закрыли?
>Это закрытые проблемы. Так к чему придирка?К тому, что язык низкого качества. И задача по отлову багов лежит на плечах пользователей
Ну а как иначе, корпорации деньжат не вливают, значит пользователи бесплатно должны тестить новомодный супер-пупер язык на себе.
Не думаю, что в данном конкретном случае пользователи кому-то что-то должны, потому что у пользователей есть огромный выбор. Вот этот язык абсолютно ничего нового не привносит. Поэтому его пригодность для пользователей весьма сомнительна.
> задача по отлову багов лежит на плечах пользователейА вы проанализировали все восемь тысяч репортов и проверили кто их составлял? Или слова чтоб набросить?
с растом аналогичная ситуация, единственный компилятор - pre-alpha, но уже 10+К issues
Для любителей си есть hare
Для любителей есть C#.
>Проектом развивается новая ОС Vinix со своим ядром, написанная с нуля на языке VЯзык Си тоже шёл в комплекте с операционной системой (C - UNIX). Автор языка правильно делает - создаёт свою экосистему.
Растаманы учитесь. V не лезет в чужой монастырь со своим уставом.
Типа под каждый ЯП должна быть своя ОС? Ну ок, redox. Дальше что?
Наличие ОС, даже фигово работающей, это отличный способ проверки самого языка на надёжность и удобство разработки.
Так что пусть пишут, эти игрушечные ОСи нужны в первую очередь самим разработчикам.
Так говоришь будто vinix будет кому-то нужен. Чему учиться?
>Так говоришь будто vinix будет кому-то нужен.Vinix нужен тем, кто его пилит. Этого достаточно.
>Чему учиться?
Учится тому, чтобы не лезть в чужой монастырь со своим уставом.
Странно, что там в гошке улучшать.Сделать go с раст-фичами типа владения переменной это была бы бомба - GC был бы не нужен (ну почти) и разброс горотин по тредам нативным бы стал, а не в райтиме.
Я уже ранее приводил эту ссылку.