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

Решил чтобы не захламлять тред "исповедь сисадмина" перетащить ответ сюда.
Вопрос был: https://forum.wbfree.net/index.php?...а-многа-букаф-мат.35926/page-209#post-1671687
"А где с этим хорошо?"
------------------

Исторически - в "не-АЛГОЛоподобных" языках, то есть вне "семейства" фортрана/паскаля/с/явы/прочего подобного. В группах языков которые пошли "от LISP" или "от ML".
https://ru.wikipedia.org/wiki/Лисп
https://ru.wikipedia.org/wiki/ML

У обоих семейств семантика (да и синтаксис) кажется "вырвиглазными" по сравнению с "уютной привычной песочницей" языков процедурного/структурного/объектного программирования.

В ряде современных языков, которые уже созданы "с некоторой оглядкой" на функциональное программирование и с некоторым влиянием одного.
Из более менее популярных нынче примеров это Rust (язык, не я), Swift, Kotlin (отчасти)

Надо помнить что все эти высокоуровневые конструкции не являются 100% обязательными, и в первую очередь дают ярко выраженный реальный эффект/заметное облегчение и ускорение написания программ только в одной области, там где нужно разрабатывать алгоритмы/решать задачи.
Условно говоря, в декларативном стиле тот же qsort на высокоуровневом языке реализовывается в четыре строки (ну реально в две, просто для красоты/удобства восприятия длинную строку лучше разбить), а не в тридцать как в императивном стиле на Си.
Вот типичный троллоло-пример из лурка, здесь слева используются и рекурсивные типы данных (список), и сопоставление с образцом (pattern matching), и еще такой "чит" как "list comprehension" (очень высокоуровневая конструкция "выбери из списка элементы удовлетворяющие некоторому условию")




Код слева (если понимать высокоуровневые конструкции языка) очень короткий, выразительный и понятный. Собственно говоря этот код - прямое переложения описания quicksort на язык программирования:
1.если список пустой то результат его сортировки это пустой список
2. Если список не пустой (содержит хотя бы один элемент) то этот элемент это у нас маркер, и мы из остатка (хвоста списка) выбираем элементы которые меньше маркера и не меньше маркера. Выборки сортируем и сцепляем друг за другом.
Все. Просто как валенок и ошибиться практически невозможно, ну и можно математически доказать правильность реализации.
Сишный код куда более низкоуровневый, с явным перекладыванием байтиков туда-сюда и куда более "cache-friendly", то есть на реальных реализациях процессоров будет работать куда быстрее. Но написать и отладить его времени нужно куда больше.

Сортировка это еще очень простой пример, его наверное еще можно написать и отладить на си за разумное время. А вот что то навроде балансировки дерева это уже задача без pattern matching будет простыня кода на полторы страницы, в то время как на высокоуровневом языке пяток-десяток строк.

В написании гуи-кода конечно подобные уровень не особо нужен, но даже тут уже сложность начинает давить и пытаются внедрить технологии типа ФРП: https://en.wikipedia.org/wiki/Functional_reactive_programming

 

У подобных высокоуровневых конструкций при всех их очевидных достоинствах есть один немаловажный недостаток: плохая читаемость и трудность в отладке.

Для большинства простых смертных, по крайней мере.

Ну и насколько эффективный код в итоге генериться компилятором - тоже вопрос открытый.
Я не сторонник premature оптимизаций, но я несколько недолюбливаю подобные "черные ящики", ибо туда внутрь чаще всего даже с отладчиком не залезть.

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

IMHO.

 

"плохая читаемость" она "в глазах наблюдателя". Я себя помню 35+летней давности, будучи программистом на Бейсике и смотрящим на Паскаль: "боже как же это можно читать?"
Как раз высокоуровневая конструкция, будучи более лаконичной, читается куда проще (естественно, после того как появилось понимание того что она делает). Для меня "бейсиковского" периода была абсолютно непонятной идеология компилируемых языков и я спрашивал "а где в фортране команда "RUN" ?
Я могу представить что кому то сперва покажется более комфортно на каждый чих писать функции навроде (на Свифте код):

Code:

func lessThen<A:Comparable>(_ array:[A], _ value:A) -> [A] {
    var result:[A] = []
    for elem in array {
        if elem < value {
            result.append(value)
        }
    }
    return result
}

вместо того чтобы воспользоваться функцией

Code:

.filter { $0 < value }

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

Трудность в отладке? Come on, я за пару минут набросал тоже на Свифте сортировку в квази-фунциональном стиле:

Code:

func Sort<A: Comparable>(_ array:[A]) -> [A] {
    if array.count == 0 {
        return []
    }
    let head = array.first!;
    let tail = array.dropFirst()
    let left = tail.filter{ $0 < head }
    let right = tail.filter{ $0 >= head }
    return Sort(left) + [head] + Sort(right)
}

Заработало сразу, по крайней мере на примерах:

Code:

let numbers = [10, 2, 5, 8, 6]
let text = ["rgreat", "rust", "flk", "sarych", "airty"]
print(Sort(numbers))
print(Sort(text))

[2, 5, 6, 8, 10]
["airty", "flk", "rgreat", "rust", "sarych"]

Это не заглядывая абсолютно никуда, из головы (правда, в среде и со всеми автокомплитами). Оно конечно совсем не хаскель, и потому ощутимо длиннее (ну нету pattern matching в Свифте для массивов и на уровне функций), но в принципе алгоритм один в один перенесен.
Сдается мне, что программист "без высокоуровневых конструкций" потратил бы куда больше времени. Как в написании, так и в отладке (которая в моем подходе просто не нужна).

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

Поверь мне, современные компиляторы ооооочень далеко ушли. Тот же Ocaml генерит пристойный код. Раза в два более "рыхлый" чем генерит "голый" си заточенный на оптимизацию, но это "разы" а не "порядки".

Хаскелем мир не ограничивается, это просто был пример-экстрим. Смотри тот же Свифт, Раст, Котлин - они очень много почерпнули и реально "подняли" уровень со времен С++.
И да, коммерческое программирование самое массовое это вообще жабаскрипт-обезьянки. Очень легкозаменяемые и "пятачок за пучек".

 

Ремарка: c# работает на винде, всяких юниксах и маках. Начиная с версии net core 3, разница в работе минимальна.

@rgreat: вроде ты писал про несовместимость версий? Опять же, версии net core совместимы снизу вверх. Прога, написанная на c# v7 (net core 3) запускается на v11 (net core 6) без запинки, если не использованы устаревшие уже на момент v7 конструкции/вызовы.

Ну, а так, язык развивается, и многие достаточно сложные вещи типа асинхронных задач разрабатывать гораздо проще, ибо не надо задумываться о семафорах и блокировках — это делается «унутри системы». Ну, а такая вещь как dependency injection облегчает жизнь программера в разы: когда запуская необходимый сервис на старте (одной командой!) получаешь его функционал во всех необходимых местах, просто прописывая, что он тут нужен.

 

Я про .net vs net core, как минимум.

 

Дотнет всё-таки уже сильно устарела, её продолжали поддерживать до 4.6.x, но уже с версии 3.5 всё было понятно.
На неткоре можно запустить большинство дотнетовских апликух.
А ещё неткор опенсорсный и поддержка нугет пакетов весьма удобна.

 

Неа. Многие библиотеки совсем другие. Почти везде надо адаптировать.
А некоторые проекты переписывать чуть ли не с нуля.

 

Если дотнет на компе стоит, то прога работать должна.

Если речь по исходники, то могут быть проблемы при использовании методов шифрования типа SSL.

 

Этих дотнет рантаймов еще и куча разных одновременно должна стоять что бы собраные разными версиями проекты работали.

Содомия, как по мне.

Но тут я пристрастный гражданин.
У меня язык не требует ни дистрибутива рантаймов, ни установки виртуальных машин, ни пихания сотни мегабайт библиотек в каталог с ПО.
Нативный код в запускаемом файле и все. Ну или в dll/so.

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

 

Любую прогу на шарпе можно скомпилировать в конечный код, не требующий установки окружения на компе: все необходимые длл будут в комплекте.

А я как раз занимаюсь межпроцессными сервисами на неткоре. Вот не припомню чего бы не было в коре, что было в доте.

А вот простота кода на неткоре вместе с безопасностью, скоростью и стабильностью на высоте.

Я больше скажу, c# вытесняет джаву с высоконагруженных систем.

 

Java вообще полено. Хотя очень популярное полено.

 

В курсе. Но ценность C#, AFAIC, за пределами виндов ощутимо уменьшается, ибо "пропадает" куча специфичный для виндов API и остаются только стандартные библиотеки языка и рантайма.
То есть писать на C# под мак можно, наверно, но смысла особо нет - на Свифте (со стороны мака) привычнее, языки сравнимого уровня/возможностей. Напрямую нативные АПИ макоси, как я понимаю, из Сишарп "не вызвать", надо юзать всякие библиотеки-адапреры и получить заведомо уступающую (вследствие непрозрачности/неоднозначности адаптеров) версию.
Единственная ниша - этот сугубо "platform-agnostic" приложения, навроде консольных, для работы на трех системах, но и тут C# не единственный.

Да, async/await нынче очень модно и кошерно и реально позволяет "прийти в асинхронность" с куда более низким порогом вхождения.
Но у МС куда более интересно (с моей точки зрения) то что они в стандартную поставку девтулзов F# всунули и вроде даже кое-какой интероп между F# и C# сделали. То есть принесли "почти OCaml", язык функционального программирования в массовую среду разработки и дали всем юзерам возможность его использовать. Не взлетело, конечно же, ибо массовый рынок программирования это кодирующие обезьянки, которые только одну парадигму ОО сумели освоить и другая в их мозги уже не влезет, но сам факт вызывает удивление и достоин всяческого уважения.

MS Research вообще молодцы ибо собрали в команду умных дядек навроде Саймона Пейтона Джонса, платят им деньги и помогают двигать вперед computer science. Не факт что явная отдача будет в ближайшие 10 лет, но практически все современные ЯП явно создаются под влиянием ФП и позволяют использовать некие концепции "сразу из коробки".

 

Во кстати!
Человеку выросшему на бейсике/асме/фортране/сях в это поверить трудно (сам долго не верил), но когда код очень высокоуровневый (не вводит принудительно сильно низкоуровневых парадигм навроде переменной цикла и последовательного доступа к элементам массива), то и возможности у компилятора для оптимизации охраненно повышаются. Вплоть до автоматического разбрасывания по тредам/процессорам (что в общем случае запрещено при использовании цикла из-за ограничений конструкции).
Звучит дико, но факт.

 

Уже не настолько. Для JVM создаются новые языки, которые сохраняют совместимость с жабой но позволяют писать более продуктивно.
Навскидку Scala и Kotlin.

 

Ну так это уже и не Java.

Все одно что все проекты на LLVM одним языком назвать.

 

Не дико. Просто особенности реализации. Это либо реализовано в компиляторе, либо нет.

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

А я не люблю черные ящики. Можете считать меня control freak-ом.

 

Да, естественно.
Заслуга джавы в том, что она принесла "в массы" ряд концепций которые были "диковатыми" до нее (хотя и активно использовались в ряде областей). Навреде VM и GC

 

Не совсем так. Я бы сказал по другому. На языке недалеко ушедшем от асма (фортран/си/паскаль) даже примитивный компилятор/минимальный оптимизатор и так дадут более менее быстро работающий код. Потому что такие языки идут "от подхода фон Неймана", "от железа" и человека "тянут в низ", думать на уровне железа.

На высокоуровневом языке, если оптимизатор плохой или его нет - то работать будет очень медленно. Потому что такие языки идут "от матана", от математического подхода, и изначально задача "сделать близко к железу" в них не стоит.
И да, если не вдаваться в подробность и не понимать как работает оптимизатор - то можно получить очень медленно работающую задачу.
Компиляторы зачастую опенсорсные и то как они работают подробно расписано. "Черный ящик" он для тебя настолько же, насколько и компилятор паскаля/си, пока ты не знаешь как компьютер работает на низком уровне.
На Си/Паскале тоже можно, но не настолько ))))

 

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

 

а вот когда я нашел куски джавологов на суперсовременной криптобиокабине, мне стало грустно