Ну чего там с языками программирования и технологиями?

Вообще то во времена появления фортрана высокоуровневых языков не было вообще. Были либо машинный код либо асм. Фортран (тогда еще он не назывался языком программирования) был первым, что позволил писать проги не зная архитектуры процессора и памяти, и использовать эти проги на других архитектурах.

 

мой пример-ссылка о том как считаются хэши без переполнения. Это сильно просто, нужно только приглядеться.

 

Ничего нового я там не увижу.
Но по мне отсутствие возможностей отключить переполнений, когда это необходимо - это недостаток.
Впрочем, как и возможность забыть включить контроль, когда он нужен. Например, на этапе отладки.

Однако если второе - это личная, решаемая, проблема, то первое - ограничивающий фактор.

 

Кстати только сегодня

Я бы сказал правильный язык должен всегда считать правильно и не пропускать молча потенциальных ошибок. Ибо ошибка это самое плохое что может случиться. Правильный язык может иметь возможность отключения таких проверок (для опытного разработчика), но она не так критична как грамотный счет - ибо эта проблема легко и непринужденно обходится. Легкость отключения, к сожалению, провоцирует "бездумную оптимизацию", играя параметрами без достаточного их понимания.

Игра с переполнениями хороша для системных языков. Прикладные должны защищать от таких ошибок по умолчанию.

 

(для тех кто понимает)
Вчера узнал что оказывается clang уже имеет поддержку tail call optimization для С и С++. То есть не "оптимизация когда получится", а гарантированная генерация TCO (даже для дебаг билда!) и ошибка на этапе компиляции если TCO невозможна.

https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#major-new-features

Проверил и реально работает. Даже до Си (точнее, реализации его clang) добралась одна из концепций ФП. Вот бы еще и в стандарт такое включили...

 

а вот к примеру если брать С, С++ и С#, то кто выйдет в фавориты и почему?

 

смотря для чего.
(-rust- уже ж писал)
у C есть своя ниша применения, он уже далеко не первый, да ему и не нужно быть первым.
А вот C++ уже припоздал со своими новшествами - появилось много других языков, хороших в своих нишах (для программирования в различных областях).
C# видимо хорош в вендовых приложениях - у нас аж два отдела его используют (один отдел - совместно с C++).
И ещё присматриваются к rust (но применять будут не скоро ещё).

мне mono (c-sharp для linux) нравился в 2007, написал на нём утилитку, но изза тогдашней задержки в обновлении бесплатных библиотек под линукс - я забросил его.

а сейчас вот прусь от rust - это эдакий C на-максималках (структуры и првязанные к ним функции).
да и обёртка у него (сборщик зависимостей, разворачиватель проектов, поддержка vcs) из коробки более-менее современная.

 

ну я для виндов и линухов пока только думаю...

 

Если умеючи, то на C# писать проще и быстрей, но на С/С++ ПО получается качественней.

ИМХО.

 

а мне вот и вовсе кажэццо, что в 90% случаев всех не-консольных (CLI) программ - пользователя удовлетворит browser-интерфейс.
т.е. какой-нить html5 для отрисовки.
а это значит - на венда/линух уже нет смысла разделять.
и даже под андроид/аппл-иос уже разработка сливаться будет воедино.

мне проще. мне хочется делать cli-утилиты и ncurses-based программулины.
но вот с путями типа "c:\users\blabla" точно не хочется заморачиваться. только /home/blabla или /Users/blabla на худой конецъ.
посему венду - точно нах.

 

а вот такое насколько удобно в шарпе сейчас делать?

 

Не сложней чем в C/С++

 

В чистом C++ ничего из этого нет. Навешивать Qt? Что там в С# не знаю.

 

а накидай в C#, плиз?
сильно муторно?

 

1. Я не шарпист. На дельфях с виду не должно быть проблем, при внятном ТЗ. Размер бюджета какой?
2. ТЗ-нет. Список терминов - это не постановка задачи.

 

1. ну хоть на делфи
было бы прикольно посмотреть на написание cli-программки на паскале
2. ТЗ там можно прям по списку подзадач накатать
3. бюджет - бартер могу на bash для сравнения написать (c использованием готовых утилит типа grep, awk, sed, parallel, find и прочая)

 

Осталось понять нафига мне твой башовый скрипт делающий х.з. что.

 

ну хотя бы посмотреть как некоторые "сложные вещи" (если их писать на взятом ЯПе) делаются в одну строку без особого провала в производительности.
я и сам был бы рад "соскочить" с баша. но пока что (кроме перла, новомодного ion-shell'а и отчасти grooovy) не вижу ни одного кандидата на роль скриптового системного языка.

кое-какие наброски из этого списка я делал на: coffee, groovy, julia, python, ruby
perl не стал рассматривать изза его старомодности и ... обидел он меня сильно в 200Х-х годах перестав работать через несколько лет изза неподдерживаемости utf8.

 

Если твоя задача вполне решается скриптом на баше - так и оставь.
Значит полноценные языки тебе и не нужны.
И на них, что вероятно, написать то же самое будет и дольше, и потребуется больше кода.

 

у нас в конторе я, временами, вижу ужасные потуги программистов писать что-то, оперирующее с файлами, на их любимом языке програзмирования.
устал уже фейспалмить.
а тут ты говоришь, что на c# можно "умеючи" писать нечто. и на делфи.
вот - думал, увижу чтото волшебное и порадуюсь за твои знания