ссылки же :)

прочитала объяснение. мой мозг взорван. порадовалась, что я не пишу на джаве.

Я на работе народ троллил тем, что выдаёт этот Сишный код:

#include <stdio.h>

main()
{
double x;
x=0,013;
printf("%lf\n",x);
x=(0,013);
printf("%lf\n",x);
}

(выдаёт он, ясное дело, 0.000000 и 11.000000 - задачка на элементарную внимательность), но Ява это перекрывает с запасом :-)

тоже красиво :)

есть еще простая задачка про префиксный и постфиксный инкремент в цикле и значения после него и число итераций, чуть ли не половина отвечающих отвечают что-то неверно :)

Не, запятые слишком явно режут глаз.

Там кроме (действительно очень заметных) запятых - ещё восьмеричная система, а если убрать вариант со скобками (который как бы намекает) - то ещё и приоритет операций ("=" отрабатывается раньше, чем ",") :-)

Использую яву, но не догадался.
В понедельник проверю знакомого олимпиадника, хех.

Использую яву, но не догадался.
Вон из профессии!
Я серьёзно. Это полная профнепригодность.
Это то, о чём рассказывают в любой книжке по яве уровнем выше чем “синтаксис за 21 день”

Ерунда.
Вон из профессии следует гнать того, кто такой код пишет (если оно не сугубо с целью троллинга).

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

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

Обоих. Т.е. того, кто пишет, тоже надо, не спорю.

Гнать не наш метод.
Хорошая порка или подготовка к экзамену на сертифицированного программера вполне решают такие проблемы.

Да, интересный пример. Собственно Integer это специальный класс, а не базовый тип "int", чего в не "managed" языках совсем нет, поэтому те, кто не работал с этим и недоумевают.

С другой стороны, по опыту участия в собеседованиях, обращал внимание, что не все программисты java/c# понимают в чем разница ref-типа (объекты в managed куче) и value-типы - это те, которые базовые типы и простые структуры не хранящиеся в куче и передающиеся по значению.

Вроде про различие value- и ref-типов написано в каждой книжке по языкам в первой-второй главе.
А вот про то, что boxed значения можно создать заранее и возвращать готовыми - особенность реализации, до которой сходу и не додумаешься.

Так это-то понятно, и что "fsck"=="fsck" в общем случае false (хотя возможны и исключения) я понимаю. Но что Integer может оказаться не "базовым типом, передаваемым по значению", а чем-то более сложным - для меня как-то неожиданно.

Integer vs int, ага?
Надеюсь, к 8-ой яве изведут базовые типы вообще, ненужны они.

Ага. Особенно если сравнить расход памяти на массив intов и Integerov.
ЕМНИП, на 64битной машине разница будет в четыре раза.

компилятор может автоматически анбоксить, в принципе.

В выражениях может. А при создании не может.
Потому как ему неизвестно, нужен тут примитив, или таки кто-то хочет как объект использовать.

Это решаемая задача. Как и скорость выполнения.

Каким образом? Поставить больше памяти?

Вы себе не представляете, на что способны современные JIT'ы.

Забить на спецификацию языка?
Или он действительно не будет создавать служебную информацию класса, пока кто-то к ней не обратится?

Именно. Делаем эксепшн на slow path, если туда таки сунуться — ну, генерим заголовки. Если не сунуться — всё быстро.

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

честно говоря, видя код a.equal(b) хочется проблеваться. надеюсь, вместо изведения базовых типов они введут, наконец, перегрузку операторов и тайпклассы

Да, с .equal() конкретный продолб, тут тоже спорить не буду.

Ага.
А потом ещё добавят ДЕФАЙН и отменят автоматическое освобождение памяти.
И получится Це Плюс Плюс.

Вот я и не ожидал, что Integer - не базовый тип. Казалось бы - зачем делать "объект" типа "целое число", чего такого может быть в этом объекте, чего не умеет базовый тип "int"?..

например запихиваться в контейнеры, которые умеют работать только с объектами.

Куча разной служебной информации.
Как бонус :) возможность положить в коллекцию или присвоить null.

Это удобный wrapper class, там много разных полезных методов.

Например, можно написать так:

String a = "400";
int b = Integer.parseInt(a);

И не мучаться с парсингом другого типа данных.

Статические методы можно без экземпляра вызвать. Т.е. для этого не нужно создавать Integer.

Я и не создавал.

Я к тому, что для сервисных методов не обязательно иметь именно класс Integer.
Можно поместить их в любой IntUtil, который сам по себе не будет представлять целое число.

Главное - это превращение в объект. Все объекты в подобных языках имеют одного предка с некоторым набором стандатных методов. Как верно заметили - таким образом можно организовывать полиморфные контейнеры не прибегая к шаблонам/дженерикам. Для подобных преобразований ref-type <-> value-type есть специальная терминология boxing/unboxing.

А завтра кто-нгибудь запостит картинку велосипеда со словами “Представляете, какую штуку тут на улице видел!? А вы вот можете догадаться, что оно ещё и ездит! Само! Без мотора!”

Нет, это вполне хороший пример того, насколько абстрактен синтаксис подобных языков по отношению и итоговому исполнению кода. Грубо говоря, подобные вещи являются ошибкой трансляции, поскольку результат не должен зависеть от конкретной реализации транслятора (как-то кэширование объектов типа Integer в диапазоне signed int). То, что эту особенность документируют, картины не меняет - она нарушает логику синтаксиса.

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

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

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

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

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

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

[вздыхая] от же ж какие они, профессионалы, придирчивые. А что нам-то, непрограммистам делать, джаву эту с её Int vs Integer вообще в глаза не видевшим? "Не писать про то, в чём не разбираюсь в совершенстве"? Так тогда проще вообще не писать... или - следовать известному принципу ОИНЧ.

P.S: "ненужны" пишется раздельно. Я понимаю, ты не специалист по русскому языку - но я вот ни разу не специалист по джаве, "и чо"?... ;-)

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

[с интересом] мне устроить опрос? ;-) Уверен, "про жабу" слышали многие, про вот эту штуку - только те, кто ей хотя бы минимально занимался - а это довольно небольшой процент.
Это боян для тех, кто "учебник по жабе" хотя бы открывал - либо для тех, кто это откуда-то случайно услышал. И если специально не интересуешься...