Ну, тогда и C грешен. в смысле, там undefined beh'ов дофига в стандарте.

Безгрешен только ассемблер - там ошибка программы всегда является ошибкой программиста. :) Любой высокоуровневый язык имеет больше wat-ов, чем низкоуровневый, именно поэтому критичные для функционирования системы компоненты стараются писать на ANSI С без всяких этих объектных прибамбасов. Любовь ко всё более высокоуровневым и абстрактным языкам (особенно функциональным) как раз и объясняется тем, что программистам всегда хочется написать побыстрее с меньшим количеством багов, но особо не думая (при этом очевидно, что ничего в этом мире бесплатно не бывает - падает интегральное качество кода). :) "Ах, кошмар-кошмар, параллелизм не прозрачный, mutable data, - это ж не барское дело, о семафорах задумываться!", "Ой, статические переменные по всему коду доступны, ой инкапсуляцию не сделаешь - это что, я должен помнить, что у меня там в методах класса понаписано?!" и т.п. Обленились все и куда-то спешат - размеренней жить надо, не суетиться. ;)

С — хрупкий и очень плохо переносимый макроассембелр. И UB там больше чем в Java. Точнее, в Java UB просто нет на самом деле, надо различать UB и то, что показано в этом пост.

падает интегральное качество кода
Хахахахаха. Это очень смешно. Код на хаскеле, если компилируется, скорее всего не содержит ошибок. Код на C если компилируется — скорее всего их содержит.
Нет, правда, интегральное качество кода на низкоуровневых языках всегда ниже, чем на высокоуровневых. Потому что просто меньше ошибок ловиться автоматически.

Си заставляет программиста понимать, как работает то, что он пишет. Невозможно качественно написать, к примеру, кернел, когда масса операций в коде сокрыто от программиста (создание/уничтожение объектов, маллоки, работа со стеком, обработка эксепшенов - продолжать можно очень долго). Да - это существенно сложнее, чем написать сто килобайт кода двумя строчками (к созданию 99кб из которых программист даже не притронулся), отладка дольше и требует намного более высокой квалификации, но простота ООП и функциональщины сходна простоте инстант джанк фастфуда по сравнению с нормальной едой. :)

Не "ха-ха-ха", а просто у Вас слово "интегральный" вызывает совсем иные, достаточно однобокие ассоциации. :) Качество кода определяется не только количеством ошибок, но и производительностью, латентностью, ресурсоёмкостью, способностью быть интегрированным на произвольную аппаратную платформу без потери скорости и т.п. Сейчас просто требование к коммерческому софту выродилось в один параметр: "оно не падает", а понимание того, что "оно не падает" происходит не столько из-за отсутствия ошибок, сколько из-за того, что половину из них скрывает язык, а вторую - не дают сделать программисту ограничением его прав, - очень редко встречается. :)

но и производительностью, латентностью, ресурсоёмкостью, способностью быть интегрированным на произвольную аппаратную платформу без потери скорости и т.п.
Это всё миф. Особенно про произвольную аппаратную платформу. В случае C/C++, по крайней мере. Как и про скорость.

Посмотрите, на чём именно написаны ядра никсов, DSM системы, Lustre, драйвера под майринет, инфинибанд и прочий софт для HPC - и многое станет понятно. :) Бизнес-приложения - это не скорость, а масштаб, поскольку там намного проще купить стойку с серверами, чем написать эффективный код.

ядра никсов,
Привет, 70-ые. Я сам люблю никсы (особенно с родословной, а не линукс), но надо понимать, что им почти 50 лет уже. И, кстати, они все, что выжили — ООП. Сюрприз, да. И если там код в модуле A будет менять переменную в модуле B — расстреляют. Хотя техническая возможность есть. Это к вашим нападкам на ООП.

DSM системы,
Это какие? Я знаю пяток расшифровок сокращения DSM.

Lustre, драйвера под майринет, инфинибанд и прочий софт для HPC
А это всё работает в никсах, деваться некуда. А вот рассчётный софт уже начинают писать на более других языках.

Бизнес-приложения - это не скорость, а масштаб, поскольку там намного проще купить стойку с серверами, чем написать эффективный код.
Это тоже не совсем так. Мы вот пишем очень эффективный код 100% Pure Java — у нас с некоторой жизненной нагрузкой справляются 2 сервера (4 для дублирования) среднего уровня. Наши ближайшие конкуренты, у которых платформа написана на C++, требуют 26 серверов (52 для дублирования), для обработки в точности той же нагрузки.
И, да, на C++ то, что мы пишем на Java, мы бы не могли писать так быстро и с таким низким количеством дефектов — просто потому что захлебнулись бы в деталях.

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

Имеется в виду Distributed Shared Memory.

Да не некуда деваться, а просто ни на чём другом быстрый код не напишешь. Вы вообще в курсе про тот уровень проблем который возникает в HPC в настоящее время? Например на интеловских процах не хватает полосы QPI, чтобы эффективно обрабатывать тупую пересылку результатов GPGPU между нодами по инфинибанду, особенности кэша в Fermi не дают возможность столь же быстро читать из неё данные, как и писать, чипсеты Qlogic, Mellanox и прочие не могут быть сопряжены с GPU прямым DMA, необходимым для низкой латентности и т.п. Это бесконечно далеко от всего того детского сада с синтаксисом и джавой, которым заняты бизнес-программисты. :)

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

Да, я в курсе всех этих проблем, потому что наши задачи очень близки :) И, да, мы умеем упираться в полосу QPI на Java.

Ну и VM эрланга, полагаю, изначально была написана не на эрланге (и даже сейчас не чистый эрланг) - и что? :) Си технически позволяет написать всё то, что позволяет Эрланг, но не наоборот. Не надо путать технические возможности языка с парадигмой программирования на нём. Мне представляется совершенно нормальным, что элементы ООП используются в ANSI С с прозрачной для программиста реализацией методов, поскольку в этом случае всё остаётся под его контролем.

Ну проблемы хоть и близкие по сути, но разные по уровню. :) В Джаве просто арифметика - это наименне тормозная часть языка, однако всё, связанное с конструкторами, деструкторами и GC - это пипец и холокост для производительности. Если ваши конкуренты пишут на каком-нибудь сишарпе и под MS, то их 26 серверов скорее всего определяются наличием MSCP, который просветлился в майкрософте и теперь под каждый сервис ставит свой сервер согласно корпоративной философии. %)

Я ж не предлагаю вам уходить с джавы - это совершенно нормальный язык для бизнес-приложений, он таковым и разрабатывался изначально, - но он не универсален. Обучение программированию на джаве с нуля приводит к тому, что программист мыслит только в одном высокоуровневом контексте - это очень ограничивает инструментарий. Например поиск произвольной подстроки по БД, который пишут базоданщики, всегда основан на индексах и довольно тормозной, хотя стоило бы просто выделить большой двоичный массив в памяти и сделать бинарный поиск по первым четырём байтам подстроки (или восьми, если это юникод) - это работает не просто быстрее, а на несколько порядков, но такое решение не придёт в голову высокоуровнему программисту НИКОГДА. Это и есть основная проблема - люди становятся заложниками парадигмы программирования.

И, да, я уверен, что через 10-15 лет будут специальные, проблемно-ориентированные, языки для описываемых вами задач. Которые спрячут разницу между AMD и nVidia, Intel и ARM (или MIPS или Whatta-Whatta-Tech) в компиляторы и библиотеки. И физики будут спокойно писать свои задачи, не заморачиваясь на очередной патч драйверов nVidia, который меняет всю расстановку сил и делает код, оптимизированный позавчера, в 10 раз медленней.

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

Бизнес приложения это скорость. Интегральная.
То есть даже если приложение на яве будет считать бизнес два часа вместо одного часа (хотя после появления JIT оно не совсем так), оно появится у клиента на полгода раньше.

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

Ну, дык! Совершенно универсальных решений не бывает.
Каждое хорошо для своей области.

Разумеется, и пугает как раз то, что современная программистская мода очень узконаправлена. Никто ж не предлагает всем резко собраться и начать писать Майкрософт Оффис на ассемблере - просто надо уметь вовремя вылезать из траншеи одного подхода, если он демонстрирует признаки неоптимальности для решения задач _программиста_, а не клиента. :) Ссылка на тему: http://snowps.livejournal.com/23416.html

А у программиста есть в рабочее время задачи кроме тех, что ставит ему клиент?

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

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

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

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

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

Угу - программизм не должен быть с тотальным преобладанием мануфактурности, но современному рынку нужна именно она. :)

Ну, дык!
Кто-то ещё пишет на ассемблере. И на сях. И на разных хаськелях-шмаскелях.
Даже новые языки, вон, придумывают и имеющиеся пытаются модифицировать.
Значит дело их живёт.

Кстати о языках, синтаксисе, семантике и ошибках. Есть ли в этом коде ошибка? Язык — ANSI C любой редакции. Предполагаем, что все нужные H-файлы для определения типов включены.


void printPtrDiff(uint8_t *p1, uint8_t *p2) {
 printf("PtrDiff: %jd\n", (intmax_t)(p1 - p2));
}


Вот такой простой код. Он правильный? Это валидный C-код?

Зачем мне выяснять, в чём именно здесь проблема? Я сам такой код никогда не напишу (поинтеры так не сравнивают), равно как и никогда не буду использовать нововведения вроде %jd. Не надо стремиться использовать весь заложенный в язык функционал - это пустая трата времени, приводящая к снижению гибкости мышления.

равно как и никогда не буду использовать нововведения вроде %jd.
И как вы тогда напишете переносимый на разные аппаратные платформы код, позвольте узнать?

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

Использованием той его функциональности и тех типов данных, которые максимально близко работает на произвольных платформах. Мифом как раз является возможность создания эффективного кода на произвольной платформе одними исходниками. Без ifdef <платформа> нормальные исходники не бывают. :)

Миллионы строк кода не являются мерилом сложности проекта, поскольку цикл можно написать как в три строчки, так и пятью тысячами if-then. Вы просто, как и большинство современных программистов, излишне ориентированы на результат, выплёскивая по пути всех детей, которые мешают бежать быстрее к оплате клиентами счетов. Расслабьтесь - вы в очень многочисленной компании сторонников такого подхода, я просто как бы не за тамбурмажором в общем параде иду, а смотрю в другую сторону - всё это я уже видел, мне скучно. :)

Без ifdef <платформа> нормальные исходники не бывают. :)
Пишите ваш код так, ка будто поддерживать его будет маньяк-убийца, который знает ваш домашний адрес.

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

А всё, что вы тут пропагандируете (включая ифдефы) — оно может и позволяет писать эффективный код, но вот со всеми остальными целями не справляется, увы.

Ну вообще-то так и надо код писать, иначе бы линукс серверный рынок не наводнил. :)

Ну кто ж согласиться, что выплеснутый ребёнок - это его собственный. ;)

Из всего вышеописанного вырисовывается всего две цели - скорость написания и осиливаемость для индуса. :) Я бы трижды подумал, выбирая подобный контекст рациональности при оценке критериев создания софта.