Доступен новый выпуск языка программирования OCaml 4.14.2, поддерживающего концепции функционального, императивного и объектно-ориентированного программирования, и нацеленного на создание безопасных и надёжных программ. В языке применяются статическая типизация, сборка мусора, исключающие переполнения буферов типы, проверка и статический анализ на стадии компиляции. Код инструментария для языка OCaml распространяется под лицензией LGPL...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60815
Кто его использует на проде? Есть истории успеха?
> Есть истории успеха?Да, Rust на нём был когда-то давно написан.
Спасибо - расходимся...
Думаю не только он. Уж больно очень подходит для написания компиляторов.
вижу функциональщину - посылаю в сад
Я тоже не умею читать ничего, кроме bash.
Встречаю много любителей функциональщины, которые твердят, что она лучше подходит для всего, начиная с обучения и заканчивая продом. Только вот сами они на ней не пишут, а когда спрашиваешь "как сделать X" или есть ли "библиотека для X" - разводят руками.
Там жеж не только фунциональщина. Первая буква в названии языка ни очём не говорит?
ага, намешаем стилей на любой вкус, вдруг хоть кто-то позарится
MLDonkey же
Кстати, как в компиляторе с поддержкой генерации кода для MIPS? Вроде, выпилили? Это насчёт возможности сборки MLDonkey для роутеров.
Из более-менее новых роутеров собссно сам MIPS выпилили, на ARM убежали.
Ну ещё встречаются с MIPS-ядрами. А в эксплуатации ранее выпущенных ещё вагон и маленькая тележка. И благодаря OpenWRT ещё долго будут в эксплуатации.
Сам MIPS выпилился, если что.
Уже лицензированные производителями ядра SoC никуда не делись.
Не спорю, но это вопрос времени.
Ahrefs
Thezos
Тысячи их
> Ahrefs
> Thezos
> Тысячи ихМетод индукции используешь? Летне работает в данном случае.
В соседней теме про GnuCOBOL такая история. https://opennet.ru/60802-gnucobol
Много кто использует libguestfs. Оно частично на OCaml.
Это же шутка да?)
Bloomberg, Jane Street и еще десяток хэдж фондов поменьше =)
> Bloomberg, Jane Street и еще десяток хэдж фондов поменьшеЧто они на нем пишут?
DSL, backend финансовых систем
Я так понимаю им важна система типов и подтверждение корректности за этот счёт (чтобы баги всплывали сразу, а не после сделки на много нулей)
Ну тот же баг с ХуперТхреаданг в Штеудопроцах отлавливался месяцами.
И что, лучше месяц ловить ошибку из-за которой не проходит операция, чем ты донатишь 0.01 цента, а человеку приходит 1 000 000$(случай из жизни)
Законы сохранения в экономике не действуют (с)
Ну, кто-то работу будет искать, а кто-то будет обвинен в намереном внедрении уязвимости с целью финансовых махинаций. Там уже будет другой закон сохранения.
да им пофиг на чём писать. босс сказал используем то-то и всё
Не совсем. Но, конечно, вы правы отчасти.
OCaml считается лучшим языком для написания прототипа компилятора.Jane Street пишет всё, включая то, что писать на OCaml, кмк, не следует (low latency). Но им виднее. Другие пишут DSL, см. https://www.dslfin.org/resources.html
Собственно, вся история с формальным описанием контрактов началась со статьи Composing Contracts: An Adventure in Financial Engineering. Как несложно увидеть, авторы, за исключением SPJ, французы. Естественно, в дальнейшем они использовали решения, базирующиеся на OCaml, а не Haskell.
По-сути, OCaml - это статически типизированный Питон. Поэтому если хочется делать решения, которые значительно более стабильны, чем на Питоне, то отлично подойдёт. Но, конечно, библиотек сильно меньше.
А вообще, Микрософт создали F#. Это местные эксперты привыкли мыслить шаблоном "NIH-синдром", оправдывая свой профессионализм в git clone && rpmbild, а те, кто определяет развитие, создают инструменты для себя сами, что бы не зависеть от конкурентов.
> инструменты для себя сами, что бы не зависеть от конкурентов.Это и есть проявление NIH-синдрома
Сказал человек на форуме, где пишут новости про "новые" дистрибутивы:
для почты, для хакеров, для админа, для домохозяйки, для музыканта, для пердолинга, просто потому что не любим системмд, с новыми нескучными обоями и тд.
Где у каждой либы есть тонны форков переписьканных на разных языках или просто "потому что".
>> инструменты для себя сами, что бы не зависеть от конкурентов.
> Это и есть проявление NIH-синдромаЭто и есть "местные эксперты привыкли мыслить шаблоном".
у fb на нем много проектов, можно на шитхабе посмотреть
Ну, к примеру, на нем написаны многие инструменты для формальной веривификации. Например coq. А ком написанный на coq умеет экстрагироваться в код на ocaml для последующей сборки компилятором ocaml. Например такой подход используется в разработке формально верифицированного компилятора C – CompCert.
Зачем нужен легаси предок Rust? Он даже не может работать на bare metal.
Для разработки таргетов транспайлера Haxe:
Спасены и сюда добрались.
На самом деле байт-код OCaml может исполняться на тех процессорах, для которых компилятор Rust не может генерировать код.
Например?
Даже и не знаю, что можно ответить на такой вопрос. Например, можно посмотреть исходники ocamlrun. Увидеть, что он написан на Си. Догадаться, что его можно собрать под целевой процессор. Можно даже написать свой интерпретатор, это явно проще, чем делать бэкенд компилятору. Например, написанный на ассемблере лежит у меня на гитхапе.
>Например, можно посмотреть исходники ocamlrun. Увидеть, что он написан на Си.а если внимательно посмотреть на таргеты раста, то можно среди них увидеть wasm.
еще чтото надо пояснить?
Поясни, как портировать хотя бы coreutils на wasm.
> Поясни, как портировать хотя бы coreutils на wasm.
Конечно, поясни. У тебя сейчас, как обычно, пятница? Или ты хотел пояснить, как будешь запускать wasm на голом железе?
А как ты будешь запускать ocaml на голом железе?Вот точно так же и wasm, берёшь и пишешь интерпретатор байткода. Или берёшь готовый: https://github.com/wasm3/wasm3
wasm же явным образом не jvm, и создан с мыслью о том, чтобы его было легко реализовать. Все сложности поверх, типа jit или сборки мусора, это проблемы которые ты сам можешь себе создать, если тебе хочется, но если не хочется, то можешь и не создавать.
На вопрос про пятницу ты почему не ответил? Опять пьян и полагаешь, что через Тор можешь заспамить в ответ ссылками, как ты что-то там гипотетически сможешь сделать, если вдруг протрезвеешь? Если я сборщик мусора написал на асме вместе с ВМ OCaml, я уж как нибудь и знакомые исходники на Си смогу подпилить. А ты иди, напиши, потом возвращайся.
Не мог бы ты изложить что хотел сказать попроще, чтобы мне не надо было бы вчитываться выискивая в твоих словах хоть что-то по сути вопроса? Для меня это выглядит как сплошное обсуждение меня, но, как ты можешь догадаться, мне неинтересно твоё мнение о мне. Может я упустил что-нибудь интересное? Или может ты хочешь добавить что-нибудь интересное?
> Не мог бы ты изложить что хотел сказать попроще, чтобы мне не
> надо было бы вчитываться выискивая в твоих словах хоть что-то по
> сути вопросаРазумеется, мог бы. Сразу, как ты объяснишь, зачем ты влез с ответом на мои вопросы к конкретному персонажу. Как твоя писанина связана с моим исходным утверждением - это мне не интересно.
>На вопрос про пятницу ты почему не ответил?А твоя мамка знает что ты дурачek ?
>Если я сборщик мусора написал на асме вместе с ВМ OCaml
Если ...
если написал то откуда вопросы как запускать wasm?
> ... можешь заспамить в ответ ссылками, как ты что-то там гипотетически сможешь сделать ...
блин, проспись. перечитай эту ветку вопростов-ответов. найди контекст и не теряй.
нелязя же так позориться
>>На вопрос про пятницу ты почему не ответил?
> А ?Я знаю, что ты систематически тут пишешь, находясь в состоянии алкогольного опьянения. Ты сам признался, что для тебя такое в порядке вещей.
>>Если я сборщик мусора написал на асме вместе с ВМ OCaml
> Если ...Вот именно. Мой опыт позволяет мне судить о сложности. А те ссылки, что ты тут спамишь - ты сам не понимаешь, что там написано.
> если написал то откуда вопросы как запускать wasm?
Это к тебе вопросы. Ты не написал, зачем ты это суёшь? Хочешь, что бы я за тебя оценил сложность?
>> ... можешь заспамить в ответ ссылками, как ты что-то там гипотетически сможешь сделать ...
> блин, проспись. перечитай эту ветку вопростов-ответов. найди контекст и не теряй.
> нелязя же так позоритьсяНашёл за тебя: "байт-код OCaml может исполняться на тех процессорах, для которых компилятор Rust не может генерировать код."
>Я знаю, что ты систематически тут пишешь, находясь в состоянии алкогольного опьянения.И-и-и... ?
Пьяным,с твоих слов, пишу я, а тупишь тут ты.>А те ссылки, что ты тут спамишь - ты сам не понимаешь, что там написано.
не суди по себе.
>Это к тебе вопросы. Ты не написал, зачем ты это суёшь? Хочешь, что бы я за тебя оценил сложность?
пытаюсь понять какой такой магией обладает окамл байткод по сравнению с wasm, что как-то сильно усложняет написание виатуалки для васма по сравнению с окамлбайткодом.
>Нашёл за тебя: "байт-код OCaml может исполняться на тех процессорах, для которых компилятор Rust не может генерировать код."ну и опять же. раст не может генерить код, но и окамл не может.
окамл может в байткод - отлично. но и раст может в васм.
>>Я знаю, что ты систематически тут пишешь, находясь в состоянии алкогольного опьянения.
> И-и-и... ?
> Пьяным,с твоих слов, пишу я, а тупишь тут ты.Если ты сам признался, то -- с твоих слов. Как выпьешь, так все вокруг тупеют?
SPARC
https://rustc-dev-guide.rust-lang.org/backend/codegen.html
> https://rustc-dev-guide.rust-lang.org/backend/codegen.htmlИ что? Где твой бэкенд?
> И что? Где твой бэкенд?а LLVM что за зверь?
И раст "может исполняться на тех процессорах" которые поддерживаются LLVM. Растодельцы избавили себя от машиннозависимой кодогенерации.
Растодельцы: Хорошо сказали
Растоподельники
Ты всю эту чушь пишешь, что бы заболтать исходный тезис "...для которых компилятор Rust не может генерировать код"?Как Rust, скомпилированный при помощи LLVM, будет исполняться на процессорах, если LLVM не генерирует под них код?
> Ты всю эту чушь пишешь, что бы заболтать исходный тезис "...для которых
> компилятор Rust не может генерировать код"?Алё, раст вообще не генерирует код ни для каких архитектур. Раст это фронтенд, с ллвм бекендом. Раст только генерирует ИР представление для ллвм-а. По ссылке все написано.
И ваш "исходный тезис" - ересь, написанные на раст программы будут исполняться только на тех архитектурах которые поддерживает его бекенд ллвм.
И вам задали прямой вопрос, какая это такая архитектура, которая не поддерживается в ллвм, но виртмашина окамла для нее есть.
>> Ты всю эту чушь пишешь, что бы заболтать исходный тезис "...для которых
>> компилятор Rust не может генерировать код"?
> Алё, раст вообще не генерирует код ни для каких архитектур. Раст это
> фронтенд, с ллвм бекендом. Раст только генерирует ИР представление для ллвм-а.
> По ссылке все написано.Я понимаю, что тебе очень хочется оспорить всякое моё утверждение. Недостаток опыта вынуждает выискивать проколы в формулировках. Очевидно (прочитай оглавление Драгонбук, хотя бы), что компилятор Rust состоит из фронт-энда и бэк-енда. Таким образом он генерирует код. При помощи LLVM или ещё чего в бэкенде - это вообще дело десятое. Суть в том, что пока не сгенерирован код, нет возможности его исполнить (разве что в маня-мирке "инженера", где он гипотетически работает в виде wasm).
> И вам задали прямой вопрос, какая это такая архитектура, которая не поддерживается
> в ллвм, но виртмашина окамла для нее есть.Кто "задали"? Если это был ты, то твои вопросы хорошо бы начать игнорировать, а тебя занести в ЧС ради экономии времени.
Тебе ведь бесполезно второй раз объяснять, что ocamlrun написан на Си, который собирается не только бэкендом LLVM. Кроме того, ВМ достаточно проста; если я написал вариант на асме, то и другие смогут.
> Я понимаю, что тебе очень хочется оспорить всякое моё утверждение.не ставил перед собой такой цели
> Недостаток опыта вынуждает выискивать проколы в формулировках.
Строгость определений (формулировок) основа-основ любой науки, и не надо точную науку превращать в искусство разговорного жанра (по великому-могучему - пиз...Ъ). И именно допуск таких "проколов" порой говорит не о недостатке опыта, а о незнании предмета (области). "Дураком" быть, "дурака" судить за незнание.
> Очевидно (прочитай оглавление Драгонбук,
> хотя бы), что компилятор Rust состоит из фронт-энда и бэк-енда. Таким
> образом он генерирует код. При помощи LLVM или ещё чего в
> бэкенде - это вообще дело десятое.Читаем внимательно первый абзац из ссылки выше:
Code generation (or "codegen") is the part of the compiler that actually generates an executable binary. Usually, rustc uses LLVM for code generation, but there is also support for Cranelift and GCC. The key is that rustc doesn't implement codegen itself. It's worth noting, though, that in the Rust source code, many parts of the backend have codegen in their names (there are no hard boundaries).
Вот первое предложение вырвано из той самой "Красной книги Дракона". А суть в том, что кодогенерация есть процесс получения машиннозависимого готового к исполнению кода, именно такое определение в "Красной книге Дракона".
Отсюда возникают вопрос, а можно ли называть процесс получения промежуточного представления (кода) - кодогенерацией? Как по мне - нет, ибо тогда и построение АСД (AST) можно назвать кодогенерацией, так как это такое же промежуточное представление.
> Суть в том, что пока
> не сгенерирован код, нет возможности его исполнить (разве что в маня-мирке
> "инженера", где он гипотетически работает в виде wasm).Ну да, а теперь ответьте себе на вопрос, генерирует ли раст код? Занимается ли он кодогенерацией по определению данной в "Красной книге Дракона"?
Отсюда и возникают "проколы в формулировках", которые нельзя проигнорировать, и это вовсе не придирка.
> Кто "задали"? Если это был ты, то твои вопросы хорошо бы начать
> игнорировать, а тебя занести в ЧС ради экономии времени.дело ваше.
> Тебе ведь бесполезно второй раз объяснять, что ocamlrun написан на Си
This raises a chicken-and-egg paradox: where did the first compiler come from? It must have been written in a different language. In Rust's case it was written in OCaml. :)
> А суть в том, что кодогенерация есть процесс получения машинозависимого готового к исполнению кода
> Отсюда возникают вопрос, а можно ли называть процесс получения промежуточного представления (кода) - кодогенерацией? Как по мне - нет, ибо тогда и построение АСД (AST) можно назвать кодогенерацией, так как это такое же промежуточное представление.Абажди, но ведь в современных х86 процессорах cisc-код внутри процессора преобразуется в risc-код.
Т.е. х86-код это тоже промежуточное представление.🤔
> Т.е. х86-код это тоже промежуточное представление.🤔ну подайте на вход х86 процессора risc-код, будет он его исполнять? - нет. Почему? потому-что на вход он ждет совсем другое представление. А что он (ЦПУ) с ним там сделает, не важно с точки зрения ЯП. ЦПУ для ЯП это исполнительное устройство. И х86-код промежуточным никак нельзя назвать с точки зрения ЯП. А с точки зрения ЦПУ это входные данные, как для ЯП - исходный текст на языке.
>> Т.е. х86-код это тоже промежуточное представление.🤔
> ну подайте на вход х86 процессора risc-код, будет он его исполнять? -
> нет. Почему? потому-что на вход он ждет совсем другое представление. А
> что он (ЦПУ) с ним там сделает, не важно с точки
> зрения ЯП. ЦПУ для ЯП это исполнительное устройство. И х86-код промежуточным
> никак нельзя назвать с точки зрения ЯП. А с точки зрения
> ЦПУ это входные данные, как для ЯП - исходный текст на
> языке.Ок.
"ЦПУ для ЯП это исполнительное устройство." -> "LLVM для ЯП это исполнительное устройство."
"А что он (ЦПУ) с ним там сделает, не важно с точки зрения ЯП." -> "А что он (LLVM) с ним там сделает, не важно с точки зрения ЯП."
> "ЦПУ для ЯП это исполнительное устройство." -> "LLVM для ЯП это исполнительное устройство."В принципе да, ток устройство в контексте ллвм надо взять в кавычки, входными данными для которого будет IR представление, а выходными - ЦПУ машинные коды.
> "А что он (ЦПУ) с ним там сделает, не важно с точки
> зрения ЯП." -> "А что он (LLVM) с ним там сделает,
> не важно с точки зрения ЯП."таки да, и в этом контексте говорить, что "раст не сгенерирует там код какой-то, для какого-то там ЦПУ" - ересь чистой воды.
Зачем в кавычки, LLVM это software defined processor unit.
> Зачем в кавычки, LLVM это software defined processor unit.исполнить - вычислить, получить результат. Генерация кода - не процесс исполнения, и тем более не исполнительное устройство.
>> Я понимаю, что тебе очень хочется оспорить всякое моё утверждение.
> не ставил перед собой такой целиЯ тебе не верю. Особенно после твоей экспертизы по PathGuard, где ты спутал 32-х и 64-х разрядные системы и что-то мне доказывал.
>> Недостаток опыта вынуждает выискивать проколы в формулировках.
> Строгость определений (формулировок) основа-основ любой науки, и не надо точную науку превращать
> в искусство разговорного жанра (по великому-могучему - пиз...Ъ).Вот и не превращай. Открою тебе секрет: сгенерированный твоим LLVM код не пригоден для запуска. Там совершенно внезапно нужен еще и линкер. Кому важна суть моего сообщения, тот это понимает без лишних объяснений. Кому интересен спор ради спора, тот будет строчить мне кучу бессмысленных сообщений.
> Я тебе не верю.все правильно, вера для тех кто не умеет сомневаться.
> Особенно после твоей экспертизы по PathGuard, где ты
> спутал 32-х и 64-х разрядные системы и что-то мне доказывал.ага я спутал, и забыл что 32-битные программы могут исполняться на 64-битных ОС.
> Вот и не превращай. Открою тебе секрет: сгенерированный твоим LLVM код не
> пригоден для запуска. Там совершенно внезапно нужен еще и линкер.а ну да, нуда, еще и всякие ЛТО и прочая приблуда.
> Кому важна суть моего сообщения, тот это понимает без лишних объяснений.
увы не телепат, ясно.
> Кому интересен спор ради спора, тот будет строчить мне кучу бессмысленных сообщений.
я только "придираюсь" :)
>> Особенно после твоей экспертизы по PathGuard, где ты
>> спутал 32-х и 64-х разрядные системы и что-то мне доказывал.
> ага я спутал, и забыл что 32-битные программы могут исполняться на 64-битных
> ОС.Ты банально не имеешь понятия, что руткит - это драйвер (намеренно пишу некорректный, но всем понятный термин). Так что вот этот сарказм малость мимо кассы.
> Ты банально не имеешь понятия, что руткит - это драйвер (намеренно пишу
> некорректный, но всем понятный термин). Так что вот этот сарказм малость
> мимо кассы.а че не модуль ?
>> Ты банально не имеешь понятия, что руткит - это драйвер (намеренно пишу
>> некорректный, но всем понятный термин). Так что вот этот сарказм малость
>> мимо кассы.
> а че не модуль ?Потому что он - сервис режима ядра.
он не нужен, есть F#
Rust?
тоже ничего
В смысле, ответ на вопрос - ненужен.
тоже ненужно
Функциональные фишки F# переползают в C#.
> Функциональные фишки F# переползают в C#.и это правильно.
это не предок Rust. Разберитесь в теме, ваш пост выглядит нелепо
(C ленинским прищуром) Зачем нужен раст, который не работает на Эльбрусе ?? И тащит потенциальную малварь с серверов вражеского государства ??
Стыдно должно быть. Эльбрус – жуткая проприетарщина с NDA. Он бесконечно далёк от свободы и от чего-либо левого.
Да Владимир Ильич тоже знаешь ли оказался вовсе не про шва6одку и демократию, а вовсе даже наоборот.И даже диктатура оказалась вовсе не пролетарьята, как обещали, а коммунистических функционеров, ни один из которых и близко к станку не стоял. (Ну на митинге только разьве. Отверточку вот-с, заодно сп-л.) Зато как он отомстил за своего брата!
Так что ель-брус - наше, скрепное, вот только подучимся чипы производить, и дрожите, проклятые англосукси!
> И даже диктатура оказалась вовсе не пролетарьята, как обещали, а коммунистических функционеровТехнически они обещали именно диктатуру коммунистических функционеров. Ленин официально продавил именно такую трактовку диктатуры пролетариата ещё где-то в 1904 или около того. Если кто-то не читал что мелким шрифтом написано, то, как говоr'ица, ССЗБ.
Это как с "безопасностью" раста. Звучит огого как, а если копнуть, то только от нескольких классов ошибок спасает и при выполнении ряда условий, перечисленных на страницах 429..785 приложения A3.
> Так что ель-брус - наше, скрепное, вот только подучимся чипы производить, и
> дрожите, проклятые англосукси!и с коих пор влив "ваше скрепное"?
Так точно, товарищ майор! На..й нам ненужон этот хруст!Он еще и запрещенную тираристическую секту Л..чтотатам пропагандирует! (потому что придумать такой синтаксис - могли только конченные п-сы)
Я бы на вашем месте сажал этих хрустиков всех подряд, лет на десять для начала, а там разберутся. Списочек - к вечеру подготовлю.
4.x - это LTS ветка. В ней ничего интересного уже не будет.
Все вкусняшки появляются в 5.x
С нем же такое было что в новую версию добавили так много нового что пришлось называть как новый язык. Не с Перлом ли?
Не, тут другой случай.>OCaml 5 as a language is fully compatible with OCaml 4 down to the performance characteristics of your programs. In other words, any code that works with OCaml 4 should work the same with OCaml 5.
Вполне приятный синтаксис. Не то что колючий раст или загогулистый плюс-плюс.
Сколько по десятибалльной шкале?
6500 K (Экв. цветовая температура)
> 6500 K (Экв. цветовая температура)К вечеру надо снижать, чтобы глазки не были красными.
Главное, в инфракрасную область не скатиться, а то выходы за пределы буферов не заметите.
Не страшно, фанаты безопастности все заметят и напомнят, еще и новость на опенхоле опубликуют.
embedded операционка на нём есть и всякие вкусности к ней, уже много лет пилят, видимо кто-то пользуется: https://github.com/mirage
Это libos, про embedded там ни слова.
MirageOS is a library operating system that constructs unikernels for secure, high-performance, low-energy footprint applications across various hypervisor and embedded platforms.
> MirageOS is a library operating system that constructs unikernels for secure, high-performance,
> low-energy footprint applications across various hypervisor and embedded platforms.https://github.com/mirage/mirage
"MirageOS is a library operating system that constructs unikernels for secure, high-performance network applications across various cloud computing and mobile platforms."И вообще то это не "embedded операционка" как писал товарищ выше.
Не там смотришь. Попробуй еще поискать, я верю в тебя, ты справишься.
> Не там смотришь. Попробуй еще поискать, я верю в тебя, ты справишься.Если для тебя описание от её авторов это "не там" - ССЗБ 🤷♂️
Plus, we improved the cross-compilation support, added more compilation targets to MirageOS (for instance, for bare-metal Raspberry-Pi 4), and made it easier to integrate MirageOS with non-OCaml libraries.А если хорошо поищешь, то найдешь работы в направлении esp32 еще с 2018 года.
Главное не опускай руки. Вперед навстречу знаниям и развитию.
> Plus, we improved the cross-compilation support, added more compilation targets to MirageOS
> (for instance, for bare-metal Raspberry-Pi 4), and made it easier to
> integrate MirageOS with non-OCaml libraries.Ты бы поменьше новостные сайты читал.
> А если хорошо поищешь, то найдешь работы в направлении esp32 еще с
> 2018 года.Мало ли кто куда чего в 2018 копал.
Внимательный читатель страницы MirageOS на гитхабе, обязательно обнаружит ссылку на домашнюю страницу этой ОС. И именно там, от "отцов основателей" узнает о embedded, bare-metal, esp32 и вообще, кто и куда копал.
Как бы "MirageOS is a Xen and Linux Foundation incubator project" явно не новостная лента.
Юношеский максимализм очень плохая штука, и никого до добра не доведет.
Кроме Си языков нет. Есть Асм и коды, но это не языки. Есть специализированные, вроде учебных вроде Бейсика и Паскаля, на которых вполне можно писать, или всякие баз данных, вроде SQL и 1С. Остальное всё тлен.
Кроме морковки пирожных нет.
Ну вот сабж и есть французский ответ Бейсику и Паскалю, на котором можно и учиться и писать профессионально. Другое дело что этот их французский остальному миру не очень понятен.
Остальному миру так же не очень понятны языки семейства Паскаль. Любой здешний эксперт скажет, что мир должен говорить на Бейсик Инглиш. Ну и писать на языках программирования, созданных в США.
>Остальному миру так же не очень понятны языки семейства Паскаль.Почему? Адептов Паскаля много по всему Миру.
>Любой здешний эксперт скажет, что мир должен говорить на Бейсик Инглиш.
Здешние эксперты критикуют тебя за то, что ты пытаешься не признавать устоявшиеся правила транскрибирования. Твои аргументы навроде поисковых запросов смешны.
>Ну и писать на языках программирования, созданных в США.
Э-э не гони минипулятор ты наш. Люди пишут прежде всего на популярных и востребованных языках программирования.
>>Остальному миру так же не очень понятны языки семейства Паскаль.
> Почему? Адептов Паскаля много по всему Миру.Потому что "много" это манечка, а не цифра.
>>Любой здешний эксперт скажет, что мир должен говорить на Бейсик Инглиш.
> Здешние эксперты критикуют тебя за то, что ты пытаешься не признавать устоявшиеся
> правила транскрибирования. Твои аргументы навроде поисковых запросов смешны.И давно эксперт по трансскипированию транскрипции стал говорить о себе во множественном числе? До того, как узнал о частотном анализе, или после?
>>Ну и писать на языках программирования, созданных в США.
> Э-э не гони минипулятор ты наш. Люди пишут прежде всего на популярных
> и востребованных языках программирования.Перечисли всех, кто входит во множество "наш" и покажи доверенность от людей, дающую тебе право говорить за них, манипулятор, ты, мой.
Си это шутка, воспринятая всерьёз. Во времена холодной войны они эту дурь хотели сюда пропихнуть, но "не рой другому яму"...
Во времена холодной войны сюда Си особо и неначто было пихать. ЕС ЭВМ - там всё оботечествлённое межделмашевское своё. КР580 - Бейсики разные.
Про СМ3,4,1420,1700 - нееееа, не слышал? Первая - это 78й год.
А последняя только формально в той же серии СМ. А в отличие от них, 32-битная (VAX).
в смысле?
СМ - это огромный ряд совершенно разных серий. (Как и ЕС, в общем-то, где 1045 это мэйнфрейм, а 1845 писюк с-ный) CM1 и 2 - вообще ни разу не клоны DEC и ничего общего не имеют с 3 кроме типоразмеров и разъемов.
1421 - если я не ошибаюсь в названии (ни одной такой не видел и их не сохранилось, но слухи о них ходили) - содержала внутри встроенный МИР1 вместе с алмиром в качестве периферийного узла."VAX" этих тоже было не одна - помимо 1700й которая делалась на базе инэумовского завода - была совершенно на нее непохожая киевская 1702, где вместо декообразной "общей шины" была какая-то своя аналогов-не-имеющая (соответственно - вся шинная периферия оказалась несовместимой... ну, вероятно у них была какая-то зато специфическая железяка, которую надо было туда втыкать кровь из носу)
Конечно нет - ЕСТЬ ФОРТРАН - ВЕЛИКИЙ И УЖАСНЫЙ - до Unix возникший и после смерти C паки грядущий !
Времена идут, языки меняются, а математики пишут на Фортране. И в чем они неправы? Там хоть синтаксис более-менее нормальный.
Математику Фортран не нужен, ему нужны бумага, карандаш, ластик, линейка и ручка.
Лисп.
Все остальное от лукавого. 😎
(defquote '(Ибо воистину. Первый Язык, жемчужина посреди простых камней, и нет языков кроме Него. Скобки, в которых пустота — тело Его, мистическое двуединство кода и данных — дух Его, божественная рекурсия — сердце Его. Истинно говорю вам, избегающий света Его есть безумец, вот, свершается кара над главой его, и убогостью отмечены поделия его, подобные пустым глиняным горшкам рядом с хрустальным сосудом благодати Его. Принявший же и постигший истинный свет Его подобен прямой и отточенной стреле, чисты помыслы его и крепка рука его, и благословенны творения его, дарующие радость и утоляющие печали, ибо одухотворены духом Его и отмечены благодатью Его.))
Недостаточно зрелый, слишком часто выходят изменения.
Гениальный вывод (сарказм).
Сейчас модно быть "в струе".
Cтандарта - нет, сторонних реализаций нет. Незрелый язык программирования.
Хм, интересно, не имеется ли планов или обсуждений о добавлении OCaml-фронтэнда в состав GCC?
Совсем другое дело Rust, обкатанный по самые небалуйся. И комитет по стандартизции, состоящий из выкинутых Мурзиллой на мороз, имеется.
Есть работа для программистов на этом языке?
Есть.
Но не для подсанционной.
На хэ-хэ-хантере забанили?
Там периодически появляются вакансии. Не то чтобы прям много, но бывают.
Можете привести конкретные примеры? Скажем, объявления о найме в ту или иную компанию?
навскидку, к примеру на https://jobs.thelocal.com задайте в поиск просто ocaml, получите сразу несколько достаточно интересных вакансий, вроде "Research and Development Engineer (M/F), Formal Verification of Rust Programs"
https://ocaml.org/jobs
Проверка переполнения буфера сниджает производительность более, чем на порядок. В ISA x86_64 когда-то были инструкции BOUND, от которых, слава богу, нахер отказались из-за того, что нет эффективного решения таких проверок даже с аппартной подпоркой. Проблема переполнения буфера живет исключительно в головах программистов -- она из той серии, где "sudo rm -rf /".
От BOUND отказались, когда Intel и AMD перешли к RISC ядру, исполняющему микрооперации, в которые декодировались инструкции IA32/AMD64. Эта команда оказалась на порядок медленнее аналогичного по результату набора простых инструкций. Та же участь постигла и ENTER/LEAVE.