kompotFX2 Кот Марамот

Ну как бы ты тут языком не трещал, что жаба круче всех на свете, а протиф циферь не попрешь ;)


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

c1272 NotGonnaGetUs


>про "переписывать" я ничего не говорил.

Ну да. NotGonnaGetUs:"Достаточно переписать/перекомпилить все бибиотеки...".

И правда. Библиотеки использующие особенности ОS действительно придётся переписать или найти уже переписанную.


>Что бы легко перенести программу на Си нужно постараться на этапе написания. В Java нужно постараться, что бы программа не заработало под аналогичной версией JVM в другой ОS.

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


Это не сильное требование, а очевидное. Sun выпускает JVM новый версии для всех платформ.


>Естественно, версии JVM это версии спецификации библиотек java, поэтому как-то глупо расчитывать, что MSJVM (j1.1) будет отображать апплеты написанные с использованием фич j1.4.

И опять все верно. Только где же хваленая переносимость? Поменяли шило на мыло, проблемы просто перенеслись в область совметсимости виртуальных машин.


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


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

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

Кроме того, важно помнить, что существование Java оправдывается не только существованием байт-кода. При создании Java, был отброшен балласт не влезающий в концепцию ООП (в виде таких архаизмов, как fprintf, понятие модели физической памяти, etc), и были разаработаны очень не плохие библиотеки, с учётом опыта других ООП языков, того же SmallTalk. Это всё упростило написание кода до предела. Одна только поддержка синхранизации на уровне синтаксиса языка чего стоит и работа с threads :)
Что бы писать "хорошо" на С++, нужно иметь больше опыта, чем что бы так же "хорошо" писать на Java. И больше опыта нужно именно из-за сложности самого языка, большего кол-ва сущностей с которыми приходится иметь дело программисту.

Понятно, что есть круг задач, где Java не нужна, там где не нужно ОПП и досточно не сложной архитектуры (или ну очень жесткие требования к производительности, что выполнить их можно только на прямую общаясь к нужным функциям ОS или железу), но это не значит, что она не нужна совсем :)

Хотя в пятисотый раз повторюсь, в конце концов решает не язык, а кто на нём пишет. Достаточно идиотов пишущих и на java и на c++ :)

Плюсы которые я вижу в Java это:
- простота написания и поддрежки кода (разбираться в чужом С коде на порядок сложнее),
- удобство стандартного набора библиотек (и всё это умещается в оч.маленькой JVM ~ 30mb :))
- наличие отличных средств разработки,
- EE технологии, спецификации которых разрабатывают граммотные люди
- большой выбор framework'ов реалтзующих те или иные специфакции и просто библиотек, которые действительно хороши
(apache.jakarta.*) и часто бесплатны :)
- и всё это чудо работает где угодно (На езжайте на этот пункт сколько хотите, но html и javaScript между различными браузерами переносимы гараздо хуже :))

c1272 wessen
Короче создатели этого логичного и целостного языка всех запутали.

Кого они запутали?
Сразу пишут - в java нет указателей в понимании Cи.
Любая переменная передаётся ПО ЗНАЧЕНИЮ.
Переменная может быть примитивной или указывать на объект (но не быть объектом, объект существует сам по себе) - всё.
Любые путаницы разъясняются из этих двух постулатов без проблем :)


Пример с выньЦЕ тут приводился. Нет у джавы какой-то особой кросплатформенности, это легенды.

Есть у неё особая кросплатформенность. Заключается она в том, что написанный код не нужно компилировать, а это гарантирует, что написанное один раз приложение будет работать на любой платформе, где есть JVM.
Нет сейчас? Будет работать когда сделают :)
А что получается с C/C++?
Пишем программу, компилим, запускаем.
Берём исходники идём под другую os, где раньше не было компилятора. Компилим, будет работать? :)
Если программа пользовала только базовые методы - то вероятно да.
Если есть строннии библиотеки - 99% нет. Кто будет поддерживать перевод этих библиотек на новую платформу? Большой вопрос, равно как и вопрос сколько он за это попросит за это денег. Особенно, если этой библиотеке уже 10 лет и преписывать её задача не на одну неделю.
Если сторонния библиотека доступна в виде исходного кода - вероятность успеха с 1% поднимится до 10%. Можно самому перекомпилить. Однако, какие можно дать гарантии, что в этих библиотеках логика не завязана на специфичных услугах предоставляемых OS или ассемблерных вставках привязанных к определенному классу процессоров? Может повезёт, а может нет.

В случае java любые готовые стороннии библиотеки будут готовы к использованию без каких либо изменений, если обратное не оговорено заранее, т.е. разработчик библиотеки не прицепил кучу native кода, как это сделал microsoft в своё время, за что и поплатилась.


Так создатели сишных компиляторов тоже выпускают библиотеки для всех платформ и разработчик тоже не озабочен как там работает read(). Не вижу большой разницы. Разница только в том, что джавовские библиотеки содержат больше функций (объектов).

Если программа ничего кроме базовых библиотек не будет использовать, то разницы нет, а как часто это на практике?

Читал нам лекции по си/cи++, человек не один год на нём работавший, и приводил примеры кода, который после компиляции разными компиляторами для одной оs работал по разному, т.е. выдавал разные результаты.
Пример конечно изысканный, но факт есть факт. После этого только и говорить о переносимости :)

Чем же Вам fprintf не угодил? То что ему уже 30 лет, так это само по себе не недостаток. По-моему гораздо удобнее чем "<<" в C++, которым никто не пользуется. Вроде в джаве тоже ничего лучшего нет.

Например: System.out.println() - по моему, кто угодно сразу скажет, что делает этот метод. Что бы разобраться, что делает 5 штук print'ов - нужно читать маны. Конечно, можно и почитать, в этом даже есть какой-то fun.
А так же разбираться что и как делает strcpy и прочии штуки.
Можно разобраться, и пользоваться можно - но только проще от этого язык точно не становится.

Использование подобных методов возвращает к прошлым временам.
Забавно видеть методы на java по 1000 строчек, написанные пару лет назад людьми пришедшими в java с С/C++, да ещё если этот метод пару раз модифицировали :) А вроде в здравом уме были люди...
Этого я боюсь, поэтому и против print'a. Правда это всего лишь симптом, а не болезнь.


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

Две абсолютно разные вещи, принципиально.
Модель виртуальная память для программиста - это ограничение на максимальное кол-во одновременно существующих объектов и всё.
Модель физической памяти - это наличие ячеек памяти, наличие размера у этих ячеек, наличие адресов у ячеек, возможность прямого доступа к ячейкам и т.д. и т.п. Помниться была проблема, что для одного и того же типа переменной в компиляторах под разные os отводился разный размер, как следствие разные диапазоны значений...
Может ещё проблемы 'buffer overflow' нет в С коде? В том же самом fprintf'е или одного из аналогов этой штуки.
Действительно полегчало.


Влезание джавы в концепцию ООП предлагаю не обсуждать по причине осутсвия таковой. Правильнее было бы сказать: "При создании Java, был отброшен балласт не влезающий в джавовскую концепцию ООП".

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


Не используйте сущности, которые не знаете. Я, например, не знаток C++ и не использую многих его возможностей и хорошо себя чувствую, на мои программы никто не жаловался. Единственное упрощение джава по сравнению с C++ это сборщик мусора. Но это только на первый взгляд упрощение, опыт показывает, что к упрощению кода это GC не привел, более того породил больше проблем, чем решил. А вот сложности, например, с передачей параметров, о которых я говорил, усложнению кода приводят и еще как.

Угу. Пока не возникнет необходимость по какой-то причине править чужой код. Тоже попросить не использовать сущности? А если сущностями можно спокойно не пользоваться, то зачем они нужны? - вот и получается милая и простая java.

Про memory leak's в свете использования gc я уже писал. На счёт больше породил проблем, чем решил - не соглашусь, если не думать что gc понацея от всех бед и понимать, что он делает, то проблем он не порождает.

Сложностей с передачей параметров никаких нет. Всё прозрачно.


> Это всё упростило написание кода до предела.

И чем же это подтверждается, Вы-то сами проверяли? Я приводил ссылку на тесты (рекомендую все-таки почитать), давшие прямо противоположный результат.
Мой личный опыт с этим полностью согласуется: джавовский код требует больше времени на отладку и требует больше операторов чем C/C++.
Кстати C++ тоже не сильно выгрывает в этом смысле у чистого C.
Так в чем же состоит упрощение? Можно конечно сказать, что джава программисты в тестах были недостаточно квалифицированы. Но в этом случае придется признать неверным утверждение: "Что бы писать "хорошо" на С++, нужно иметь больше опыта, чем что бы так же "хорошо" писать на Java."

Ходил я туда, читал про телефонные номера.
Если отбросить фразы в сторону java заканчивающиеся "но поскольку утверждать это нельзя, не относитесь к ним серъёзно", то там ничего обидного про java не сказано :)
Ну работала она 4.5 года назад в 1.5-2 раза медленнее, ну ела памяти побольше в 3-4 раза, потому что gc вызывается не постоянно, а только когда возникает в этом необходимость, а до поры до времени свободные объекты висят в памяти. Ничего удивительного и не из-за чего махать руками.

Размер кода тоже параметр сомнительный. Код должен быть прежде всего понятным, а потом уже сжатым "в три строчки" за счёт специфики синтаксиса.

Может шутки ради повторим тестирование? Я делаю на Java, вы на Си++ потом сравниваем? :) Как никак jdk нынче до версии 1.5 доползло взамен 1.2, да и компиляторы Cи++ вроде на одном месте не стояли. Только бы свободное время выбрать, да судей не предвзятых найти :)


Так что как ни крути, а получается джава была ухудшением по сравнению с C++, а ее популярность держится исключительно на том, что ее поддерживают сервера приложений и GUI (которые мы не обсуждаем, тут C++ бесспорно проигрывает из-за бедности библиотек), написанные на джаве кросплатформенны (с кучей оговорок) в пределах нескольких платформ.
Ну ни как этого не получается :)
Сервера держатся именно из-за мощности концепций заложенных в основу java, из-за того, что код серверных приложений живёт долго, требует периодической модификации согласно меняющимся требованиям и при этом важна как скорость разработки так и производительность готового продукта.
Присловутые в 2 раза медленее в случае серверов - не проблема, думаю не стоит объяснять механизмы которые позволяют на это не обращать внимание...

"(с кучей оговорок) в пределах нескольких платформ" - не могу конечно утверждать, но вот почему-то мне кажется, что эти пределы перекрывают
"переносимость синтаксиса c++ между компиляторами" с хорошим запасом. Лучше всё-таки не кидаться такими словами ни вам ни мне.


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

c127
%26gt;Переменная может быть примитивной или указывать на объект

Так указателей же нет. Только не нужно говорить, что это не указатель "в понимании C". Указатель как свежесть у мяса, имеет 2 состояния или он есть, или его нет, никакого особого "понимания" у него нет.

Это не конструктивно.

Существует понятие "указатель", "указывать" в обычном смысле, как мы его используем в русском языке.

"Указатель в Си" - это указатель на адрес памяти и он сам по себе является типом данных. Над ним можно проводить кучу разных операций, не относящихся к куску памяти на который он указывает.

В java не примитивные переменные предоставляют доступ к объекту. Механизм доступа в точности соответствует понятию "указывать на что-то" в русском языке, а не языке Си.

У меня никаких проблем с пониманием нет.


Чепуха, уже надоело объяснять почему. К физическим ячейкам никто не обращается.
Опять игра слов.
"модель виртуальной памяти в java" - ограничение на кол-во объектов
"физическая память" - железо. Адресация ячеек на уровне контроллера памяти
"модель физической памяти в Cи" - эмуляция "физической памяти", т.е. ячеек, адресов на них указывающих etc.

Я сравнивал искючительно 1 и 3 пункты. Объяснять в чйм разница между 2 и 3 мне надо. И про "виртуальную память", которой OS скрывает "физическую память" тоже.


И это чушь. char - 1 байт, short - 2 байта, long - 4 байта. Только int зависит от реализации. Это стандарт, более того, на этом строится идея переносимого языка (см. Керниган, Ричи, самое начало). Похоже выяснился источник проблем.
Это источник не моих проблем, а того, кто пишет на этом языке.
Если специальным образом не обрабатывать int, то при использовании разных реализаций компилятора могут быть возникать ошибки. Разве нет?
Естественно это не неустранимая проблема, зато сколько можно получить "удовольствия" от поиска причины бага в многокилометровом чужом коде.


Или я чего-то не понял, или это какой-то бред. Извините. Почему printf() это болезнь, а System.out.println() это шаг вперед?

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


Почему по strcpy() нужно читать маны, а по System.out.println() нет?
Не нравятся маны - читайте книги.
Это вопрос простоты языка для понимания/изучения.
Простой пример:
Как мне догадаться, что мне нужна функция atof(), что сделать из строки число? Придйтся порыться прежде, чем найти. Не важно где, в книгах, гугле, манах или спросить на форуме.
А в java? Что хотим получить? Число. Из чего? Из строки.
Пробегаем по методам класса String - не видим названия в котором есть что-то похожее на convert.
Пробегаем по классу Integer - вот он - Integer.parseInt(String s);
Тут же видим полное описание метода, какие exception'ы он может кидать и т.д. Даже посмотреть его реализацию для уточнения любых вопросов, которые могут возникнуть.

Пока досканально не выучишь библиотеки, теряется время.
Вопрос: на что потребуется больше потратить времени на изучение бибилотек java или с?

Вот и всй, что я имел в виду...


По джаве (и библиотекам) их написано не намного меньше чем по C/C++, но за гораздо более короткое время. Зачем, спрашивается, кто их покупает, платит бабки, если и так все понятно?

А если подумать?
Вышла новая спецификая jdk, вышла новая серия книг отличающихся от старых обзором добавлений в новой версии.
По сути эти книги простое переписывание java doc'ов(толстые книги) и перевода текущего туторила постоянно доступного на сайте java(по тоньше).
Сюда же можно отнести "книги" для студентов по курсам лекций и т.п. Их не много.

Другой класс книг "по java" - это описания технологий программирования с примерами на java. Это книги по использованию Uml, классич.алгоритмам, паттернам, антипаттеры, XP, рефакторинг, серверная архитектура и т.п. Но это не книги по языку, там не учат, что такое java, там излагают идеи равноприменительные к любому ООП языку. Таких книг для Java действительно больше, чем для C/C++.
Не возникло идеи почему? :)

И отдельно стоит небольшая книжечка с описание антипатернов связанных с "неправильным" использованием библиотек java. Где простым и доходчивым языком говорится о том, почему не надо делать много лишних объектов, почему использование StringBuffer иногда оказывается на порядок эффективнее чем String и т.п. проблемок.



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

Использование native кода в джава приложение делает его не преносимым, поскольку native код написанный на том же С++ будет не переносим. Ограничение на переносимость лежит в native коде, а не java коде.
Отсюда следует:
- не используйте native код и приложение будет переносимо полностью.
- проще перенести не большой по объему native код на новую платформу (или переписать сохранив функциональность), чем переносить приложение целиком написанное на native языке.

И кто предстайт в более выгодном свете Си или Java, учитывая, что native код используется крайне редко? Единственное обоснование для его использования написать приложение именно под одно платформу, либо уже есть native код который долго переписывать и на это нет средств, но в последнем случе хуже не станет.

Хотя "жалко", кончено, что чтение реестра непоулчится организовать в linux'е... Действительно, ЭТОТ факт я признал.


Вот по Вашей логике получается: "После этого только и говорить о переносимости :)" джавы.

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


Смешно. То же самое слово в слово говорилось 4.5 года назад. Придумали бы что-нибудь новое.

А что смешного? Это факт, зачем что-то придумывать?
Да медленее, но не намного.
Да больше, но сравнивать тоже надо правильно. Выдели 64 - есть вероятность что приложение съет всю, выдели 128 той же программе - опять съест, а почему нет? :) Мусор можно дольше не убирать. Ну пусть даже просто больше.
И что?
Простоту языка и удобство работы купили за счйт железа.
Есть области, где требуется написание программ критичных к скорости, там нет смысла использовать java, но ещй больше областей, где разница небольшая разница в скорости не критична.
Через год-два этих областей станет ещй больше - время отклика 1ms или 2ms велика проблема?


1) Это тестирование отличается от других тем, что там набрана статистика. Врядли нам удастся повторить этот момент, а без статистики тест не будет серьезным.
2) Скорость исполнения почти никогда роли не играет. А вот длина кода и особенно скорость разработки (а они связаны, это известный факт, и об этом, кстати, в отчете тоже написано, нужно только почитать внимательнее) играют большую роль. Если верить тестам, да и Вы вроде не спорите, только называете этот параметр сомнительным, то по размеру кода, а следовательно по скорости разработки, джава тоже в пролете.

1) Если речь идйт о статистики в смысле кол-ва вариантов программ, то это и так не серьйзно. Она определяет уровень "квалификации" программиста пишущего на языке - а не специфику языка. Хотя информация конечно, любопытная.
2) Я внимательно читал :) в том числе и оригинал. Для данной задачи скорость написания кода на Cи и Java должна быть одинакова. Сложность задачи исключительно алгоритмическая - какую структуру данных выбрать для хранения слов, понять как она должна работать, как осуществить перебор вариантов.
Их пример с 69 часами - просто прелесть.
Автор сам говорит, что примеров кода на С/C++ очень мало.
Если отбросить варианты отнявшие > 20ч, что говорит о трудности понимания, что же надо написать, то среднее время получится одинаковым, как я и говорю.
С длинной программ лидерства тоже быть не может ни у одного из этих языков при решении предложенной задачи.
Операторы языков очень похожи и для данной задачи нельзя было использовать подходящую библиотеку (нет 10нарного дерева в библиотеках ни того ни другого языка :)). В результате так и получилось, среднее кол-во строк одинаково.
На графиках (5 и 6) всё это видно.


В заключение. Все Ваши существенные аргументы относятся не к сравнению языков программирования, а к сравненнию окружения. У джавы есть виртуальная машина, у С/С++ ее нет. Так я с этим и не спорю.

java можно с натягом рассматривать как синтаксически урезанный Си++, с очень хорошим набором библиотек, сделать который удалось за счёт полного пересмотра базовых библиотек, хороших внешних библиотек (во многом благодоря кроссплатформенности) и активной пропоганды "передовых" концепций в замен старых добрых методов по 1000 строк.


Я сразу сказал, что можно было создать виртуальную машину для C/C++, а не выдумывать новый язык в угоду недоучившейся публике. И C/C++ совершенно спокойно мог бы использоваться абсолютно везде, где сейчас используется джава.
Ага, а я сразу же сказал, чем эта идея хуже, чем сделать новый язык.
"Лишнии" языковые конструкции, груз старых библиотек, костность мышления, которая заставляет старых Сшников писать на С++ как будто никаких ++ там нет.

--

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

Ясно, что java большое упрощение, всё расчитано на "чистый" ООП. Ни каких структур, записей, адресов в памяти, всего что упрощает написание кода "сплошняком". Только классы, интерфейсы, методы, набор ключевых слов для организации доступа, несколько примитивных типов.

Код java можно тупо превратить в код Си заменой ключевых слов (забудем про разницу в библиотеках и ключевое слово synchronize). Обратно тяжелее.


Выводы
- Си++ сложнее для изучения, чем Java.
(В итоге это не принципиально.)
- ОО Модель в Си++ шире, чем в Java. Множественное наследование, делгация методов, передача параметров, переопределение операторов, еtc
(Это позволяет как минимум строить "сложные" конструкции объектов и такие же связи между ними. Что лучше вылавливать в них потом ошибки или не усложнять код ровном месте - трудно сказать.)
- в Cи++ много "хаков" экономящих строчки при написании кода.
(требует достаточно большого опыта работы с языком, зато код компактнее,
главное только потом не забыть, что же он делает)
В java что-то похожее появилось в версии 1.5 (пока бета) например foreach, автоматическая обвёртка примитивных типов при добавлении в коллекции и т.п.
- В Си++ можно писать код "по-старинки", как на С.
(С одной стороны хорошо, с другой плохо. Плохо, потому что грамотно написать ОО код, который легко править, отлаживать, документировать и т.д. проще, чем написать такой же по этим параметрам код без ОО подхода (хотя и возмжно:)) Хорошо, потому что простые программы пишутся быстрее, сохраняется связь со старым кодом(?), старые добрые классич.алгоритмы существуют именно в таком виде, т.е. их легче реализовывать. )
- В с++ есть указатели и связанные с этим возможности и сложности, есть необходимость следить за удалением объектов, есть проблемы аналогичные memory leak's в java, но в меньшей степени.

Следствия:
- Читать чужой код на Си++ тяжелее, чем чужой java код, т.к. java простая до безобразия, т.е. приходится меньше фич языка держать в голове.
- В С++ больше вариантов для принятия решения - "можно так, можно этак, а что лучше, а почему, а какой ситуации и т.д." - для того, чтобы делать это эффективно, нужен баальшой опыт, намного больше, чем java юзера. (о "намного" сужу по своему опыту, может просто дурак?)
- Скорость написания кода одинакова, если пишем ОО, и C выигрывает, если "положить", на все эти объекты и писать в "столбик", т.к. не надо тратить время на выделение сущностей, связей и т.д.


Но в целом, эти различия не значительны для опытных программистов.

Разница только в скорости работы (выигрывает Си++), способе достижения переносимости (выигрывает java) и доступных библиотеках(java). Если библиотека хороша и удобна, код будет написан быстрее, чем если её совсем нет или организованна она через одно место. В области написания серверных приложений Java молодца, т.к. за этим процессом следят, существуют контейнеры для серверных приложений, фреймворки для этих контейнров и куча куча всего, что упрощающая работу не связанную с логикой приложения.
На клиентской стороне такого подавляющего преимущества нет. Разве что swing не плох :) Боятся пока писать серьёзные приложения в большом кол-ве.
Хотя пишут. Пример, той же самой IDE IntelleJIdea. Но пока ещё рановато...
Вот станут процессоры ещё на 1 Ггц побыстрее, добавят юзеры памяти чуть побольше и полетим с оpenGL'кими swing'aми вперёд :)

c127
Это источник проблем в нашей дискуссии: Вы не знаете C в необходимой мере, поэтому просто не понимаете моих аргументов.

Попытались бы объяснить "на пальцах".


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

Да какая тут философия. Если я покажу на столбик со стрелкой, вы тоже скажите, что это указатель такой же как в языке си? :) Вроде нет. Хотя тоже указвает на объект какой-то.
С переменными в java таже самая ситуация, указатель есть, но не такой как в си.
"Революционность" в том, что указатель в java исполняет только одну роль - указывает на объект, и не имеет ни как дополнительных нагрузок в виде "ячеек памяти".
Откуда у вас появляется чувство, что sun вас пытается обмануть и вы бросаетесь его разоблочать в этом вопросе - не понятно :)

Только не надо говорить, что я признал, что в java есть указатели :) Я постом выше написал тоже самое, что и сейчас.


Кнут в своем "Искусстве программирования" построил виртуальный компьютер, определил для него ассемблер и обращается к адресам этой виртуальногй машины. Эта книга - классика алгоритмов, советую почитать, и все они написаны на этом ассемблере. В этой машине какая память виртуальная или физическая?
Ответьте на него.

В этой машине "физическая модель памяти". Как и в Си. А вот в java нет :)



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

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


Вы по-видимому недавно программируете, так что просто поверьте мне, фраза "Ну работала она 4.5 года назад в 1.5-2 раза медленнее, ну ела памяти побольше в 3-4 раза, потому что..." была очень популярна в конце 90-х.

Самое интересное, что это была и есть правда. Java работает медленее и ест больше памяти по вполне понятным причинам. Очевидно есть грань, ниже которой отношние Java/C не упадёт, думаю где-то между этими 1.5-2 и есть. ("Ну работала она 4.5 года назад в 1.5-2 раза медленнее, ну ела памяти побольше в 3-4 раза, потому что..." - я сравниваю с Си++, а не с JVM той поры и этой - может вы по-другому подумали.)

Смеяться надо над другим:
Мне пришлось однажды сравнивать работу одной програмки (правда написанной через одно место) под MSJVM (last version) и JRE 1.4.
Это был html table editor - он генерил много объектов, создавал много потоков и часто вызвал методы перерисовки содержимого на экране.
При редактировании таблички 20х20, в первом случае отклик был минута-полторы, во втором - отклик измеряемый десятками ms. Это действительно забавно.




>1) Если речь идйт о статистики в смысле кол-ва вариантов программ, то это и так не серьйзно. Она определяет уровень "квалификации" программиста пишущего на языке - а не специфику языка.

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

(Не "программиста", а "программистов". - усреднённого программиста, пропустил слово)

Я легко поверю, что среди людей "знающих" язык java, доля криворуких больше, чем среди "знающих" Cи++.
Но работодатель ведь не просто так людей берёт, если для текущей работы нужны граммотные люди (а этот параметр инвариантен между языками), он возмёт грамотных.
Тем не менее, к языку самому по себе этот параметр относится слабо.


>Для данной задачи скорость написания кода на Cи и Java должна быть одинакова. Сложность задачи исключительно алгоритмическая - какую структуру данных выбрать для хранения слов, понять как она должна работать, как осуществить перебор вариантов.
...
С длинной программ лидерства тоже быть не может ни у одного из этих языков при решении предложенной задачи.
...
Читать чужой код на Си++ тяжелее, чем чужой java код, т.к. java простая до безобразия, т.е. приходится меньше фич языка держать в голове.

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

Опа, и как я такое чудо пропустил? :)
Строки это объекты - передаются они, как и все объекты, не позначению.
Хотя я примерно представляю, как могло возникнуть такое мнение.
Объект String реализует паттер immutable object (в отличии от объекта StringBuffer), поэтому преобразование с участием String похоже на преобразования с примитивными типами, плюс попытка присвоить параметру метода новое значение (вот уж точно запутались) - в результате получили, что стринг передался по значению :)

В языке нет и не было кривизны. Только простота.
Соответсвенно, "всё неверно" - верно.


>Но в целом, эти различия не значительны для опытных программистов.

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

Ну, ситуацию со String я вроде разъяснил.
Что ещё не так с параметрами функции - не понял.
Не нравится, что примитивные типы передаются по значению?
Ну, это не должно быть проблемой для опытного программиста.
На самом деле необходимости в этом нет - только привычка так делать. Из java выкинули всё без чего можно легко обойтись.

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

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

--

Хотя согласен, если всю жинь писать на C/C++ и любить этот язык, будет трудно писать на java. Будет возникать постоянное желание сказать - "а вот это в С/С++ можно было сделать по другому" :)

Мой зав.кафедрой (нучный центр нейрокомпьютеров при РАН) интересную вещь сказал - "Зачем мне все знать все эти PC, Windows, Linux, Word etc - что такое знание Word'a? Это условность. Сделают завтра по другому - все мои знания пропадут. А теория нейронных сетей как появилась в 40-50хгг, так все работы до сих пор актуальны."

Опытные программисты на C в подобной ситуации - они владеют особенностями синтаксиса языка и стандартными библиотеками, это, бесспорно, не за один день преобретаемые знания, но это всего лишь "знать какие кнопочки в Worde нажимать". Заставь писать на другом языке и добрая половина профессионализма пропадёт. Останется только "истинное"
программерское знание, которое "вечно" - алгоритмы, методы проектирование, методы отладки, etc, о чём уже не раз говорил. А ведь жалко взять и за раз столько потерять, правда? :)

Да и вряд ли надо матёрому сишнику переходить на java. Он и так работу найдёт и свои дни счастливо доживёт (скорее всего:)).
А вот тому, кто только начинает или не успел "заматереть" - стоит хорошо подумать к чему стремиться.

Lepsik
Сам по себе С++ не предпологает. Не нравится библиотека из стандартной поставки - пользуйтесь сторонними, коих, мультиплатформенных ( а они работают на таком количестве платформ, которые и не снились Джаве). Мне лично нравится VCL от Borland.

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

Согласен, наличие хороших мультиплатформенных библиотек не может не радовать, скорее было бы удивительно, если бы их не сделали в конце концов.


--Пока досканально не выучишь библиотеки, теряется время.
для этого inline help имеется - или джависты с командной строки работают ?
Мне и в голову не приходит заучивать сотни и тысячи фукнций winapi и все того что наваял microsoft в своих SDK, DDKi

Вопрос: на что потребуется больше потратить времени на изучение бибилотек java или с?

C конечно, описание которого занимает 26 страничек формата А6, а не двухкилограммовый кирпич жавы.

Зачем с командной строки, зачем обижать? :)
Досканально знать библиотеку - это знать её возможности. Что бы не ломать голову - умеет/не умеет, а чётко и быстро найти как выполнить нужное дествие. Тут большую роль играет архиектура бибиотеки, чем умение пользоваться inline help'ом.
Хотя, стоит заметить, что речь я вёл про библиотеки из разряда стандартных сишных.
Если в Си++ есть милые/хорошие библиотеки, то изучить их не труднее чем java библиотеки. Тут нужно только правильно подсчитать кол-во библиотек, которые придётся учить. Утверждать, что-либо более не могу - опыта маловато.

В java, слава богу, никакого winapi и не ясностей с выбором библиотек нет.


Просто задачи новые встают. Сравни winword95 и winword Office11. Просто небо и земля. Начинают решаться задачи о которых из-за нехватки ресурсов никогда не задумывались.
Это хорошо подмечено. Хотя функциональность не может разрататься без предела, пользуется ей всего лишь человек. Согласен, быть в числе лидеров среди таких монстров как офис, java продукты ещё пару лет не смогут :)


---2) Скорость исполнения почти никогда роли не играет. А вот длина кода и
вы что ли ноутпады пишете ? порисуйте графику в 3D де кстати примеры а-ля DOOM жаве ? Он портирован на тучу платформ на С++

Графика это прежде всего железо, поэтому джава рисовать будет плохо. Тут не поспоришь. Пока не наблюдал хороших библиотечек под openGl для java.
Как будет посмотрим :)


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

вне сомнений С++ выиграет.

В задаче о которой шла речь - нет :) Хотя если слипить всё в одну кучу...


--Операторы языков очень похожи и для данной задачи нельзя было использовать подходящую библиотеку (нет 10нарного дерева в библиотеках ни того ни другого языка :)). В результате так и получилось, среднее кол-во строк одинаково.

писака был слабый.

Ваш вариант в студию :)


--Код java можно тупо превратить в код Си заменой ключевых слов (забудем про разницу в библиотеках и ключевое слово synchronize). Обратно тяжелее.

есть трансляторы в жаву так что не труднее

А тестировать их работу пробовали? эффективность получившегося кода, читаемость, размер, etc. В любом случае - это задача далеко не тривиальная, если хорошо закрутить код на сях.


- Си++ сложнее для изучения, чем Java.

дак и мощнее

На столько мощнее, что достаточно задач, где эта мощность не нужна.
"Зачем платить больше, если стирает так же?" (с)


- В Си++ можно писать код "по-старинки", как на С.

В С++ можно писать практически также как в любом другом языке программирования

- Читать чужой код на Си++ тяжелее, чем чужой java код

работаю в команде и не скажу что испытваю какие-нибудь затруднения

Согласен - можно, верю - не испытываете.
Речь не об этом. Речь о том, что java в этих вопросах проще.
Не любой код написанный на Cи++ прост для понимания, именно из-за возможностей языка. Можно написать такое, что чёрт ногу сломит, пока будет разбираться. Если все пишут аккуратно и красиво, очевидно проблем с пониманием не будет.
Как я говорил - при высокой квалификации программиста, все различия проще/сложнее между языками сглаживаются и остаётся только разница в библиотеках.


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