Здравствуйте, Alex EXO, Вы писали:
AE>Числодробилка будет тормозить. Это без вопросв.
Согласен. Тогда сразу признаем утверждение о тормознутости Явы и супер-скорости Эрэнга неудачным. ОК?
AE>Но в реальных проектах числодробилки это весьма небольшой кусок.
Понятие "в реальных проектах" не детерминировано. У каждого из нас разные "рельные проекты". Где-то недостатки Эрлэнга (как то интерпритируемость и динамическая типизация) оказутся несущественными, а приемущества (как то дешевое распараллеливание) существенными. А где-то наоборот. Вот именно по этому мне не нарвится залихватское утверждение которому я возразил. Это результат очередного неразумного пиара. Верю, что получилось это не со зла, но результат на лицо. Мне лично смешно слышать о тормозах Явы на фоне шустрости Эрлэнга.
AE> Даже в биллинге (где мого расчетов) и то логики и анализа все же больше.
Не знаю. И занть не хочу. Но логика и анализ — это тоже вычисления. И если они не выливаются в библиотечные вызовы, то они тоже будут медленее по сравнению с хорошо оптимизированным машинным кодом прождаемым Явой. Другое дело, что тут могут сиграть легкие процессы и т.п. А так же может оказаться, что произвоидительности достаточно, и что нужна не она, а простота разработки.
AE>Вычислиения типа сопромата я не рассматриваю, это вообще отдельная область — там все еще FORTRAN рулит...
Это миф. Там рулят алгоритмы и оптимизация.
AE>В численности — думаю не сильно. AE>Другое дело, что надо учитвывть эффективность. Вот сейчас сижу среди java-писателей... меня самого предположим AE>можно не учитывать — недавно за жаву сел, но если смотреть по тем кто пишет на ней несколько лет, то AE>эффективность разработки примерно в 3-4 раза ниже чем на эраланге.
Тут оно как. Всегда есть много малоэффективных программистов, а то и вообще не способных к творчеству. А вот хороших программистов мало. Эрлэнг несмоненно обладат рядом приемуществ способных помчь хорошему программисту решить задачу быстрее. Однако Ява так же обладает такими возмостями (хотя и меньшими). И хороший программист решит задачу на обоих языках, просто Эрлэнг ему может дать больше. Вопрос даст ли Эрлэнг что-то не очень хорошему прграммисту? Ява дает статическую типизацию и типобезопасность. Плюс она дает тучу фрэймворков и готовую технологию организации больших проектов программистами разной квалификации. Это, по-моему, не мало. Учитывая что в Ява-проектах можно использовать Скалу, не факт, что этот выбор будет менее эффективным чем выбор того же Эрлэнга. Пока что я вижу приемущество Эрнанга именно в областях где тербуется параллелизм (причем не обязательно многопроцессорнсоть).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Язык достаточно примитивный, поэтому очень давно появились сильно оптимизирующие компиляторы. Сишные сейчас в принципе не уступают. Ну и очень много готовых расчетных библиотек.
Заслуги языка тут нет. Да и С++-компиляторы давно их догнали. Инлетл С++ по крайней мере этим хвастуется постоянно. А еще надо учитывать что многое определяется библиотеками. Тот же Интел предостовляет библиотеки для разных языков.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alex EXO, Вы писали:
AE>Добавлю, что это "совсем другой рантайм". Та жава, которая на мобильниках куда шустрее серверной работает. AE>Просто чувствуется, что внутренние алгоритмы совсем другие.
Рантайм другой, а про скорость явное заблуждение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
VD>>А я о любых. Весьма крупные проекты вроде Линукса и NT вообще в основном на С написаны. G>Именно что ! Но ведь не на С++/жабе, верно ?
В NT на сегодя не малая часть написана на С++.
Учитывая обратную совместимость С++ с С вообще не знаю о чем можно говорить.
VD>>Многие? Можно хотя озвучить хотя бы 10 проектов на Коболе известных тебе? G>бОльшая часть бизнес-софта в Штатах и Канаде написана на Коболе.
Позволь не согласиться. Когда-то это было так. А теперь нет. В общем, попробуй найти ссылки.
G>В той же Франции 60% экономического ПО до сих пор работает на Коболе.
Назави хотя бы оду известную тебе французкую систему написанную на Коболе. Хотя забавно будет и вообще хоть про одну услышать. А то вот, я за всю жинь слышал только об одной, но она была написана на собственном языке который был написан на С.
G> Новых проектов, конечно же, гораздо меньше
Это миф.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Угу пришлось немного ковырять, кошмар страшный FR>Но все-таки основная масса устройств подерживают только яву (или и яву в том числе).
Не спорю. Я как бы говорил о том, что ФЯ на этих девайсах такая же экзотика как на PC в 1990-ом. Может кто-то и видел, но вот как его зовут никто не знает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Да, кстати. Также ни для кого не секрет, что подавляющее большинство проектов в этом мире — полный отстой. Выводы?
В Макдонольсе всегда много вакансий!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Кроме этого — сам MIDP убожество страшенное. Практически ноль сервисов. Что касательно GC — его тоже лучше особо не напрягать, объектов выделять поменьше, реюзать их почаще, а то все нафиг сляжет. По крайней мере в мобилах образца 2003 года точно так было, сейчас — хз. В результате — по технике программирования практически 0 разницы с С++. Только еще тормознее.
Главная разница — типобезопасность. Если не раводить разговоры об идеальных программистах, конечно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
А> Я применял. В компиляторах, в системах анализа кода, в числодробильне и символьной математике, в CAD-ах, в играх.
Здорово! Вот Кармах С в играх применял. О результатах знают все. Так может и ты поделишся?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Согласен. Тогда сразу признаем утверждение о тормознутости Явы и супер-скорости Эрэнга неудачным. ОК?
Понимешь какое дело, сейчас работаю в коллективе который делает на яве, примерно то же,
что на прошлом месте работы делалось на эрланге. Причем классически эти прикладные задачи
традиционно считаются яве как раз "по профилю" — специализированный документооборот со всякими фичами.
Потому могу посравнивать что получается в итоге, то есть не на отдельных функиях,
а на больших задачах в целом.
А получается следующее:
по быстродействию для операции создания сложного объекта (в одном случае это "документ" с развесистой
структурой, в другом — его аналог примерно такой же сложности), на аналогичном "железе"...
ява — 0,3 сек, эрланг 0,05 секунды
занимаемая приложеним оперативная память (при сравнимой функциональности):
ява — 600 мб, эрланг — 75 мб.
Да можно говорить, что приложения написаны "с разным качестовм", и это действительно так —
эрланговское куда стабильнее и гибче. (При этом в эрланговское приложение вложено около 4 чел/лет,
а в жавовское около 10.)
Что тут виновато? Библиотеки? Да, у эрланга они "легче" и проще в обращении...
Архитектура? Тоже наверняка сказлась. Ну и разработчики, разумеется (особенно попытки "копать колодец
всем взводом").
Все это так, но тенденция остается. Это не единственный известный мне жавовский проект и не
единственный эрланговский. Так что о "тормознутости явы" как таковой наверное действительно
говорить не стоит, но можно сказать, что на ней как правило получаются тормознутые приложения.
VD>Тут оно как. Всегда есть много малоэффективных программистов, а то и вообще не способных к творчеству. А вот хороших программистов мало. Эрлэнг несмоненно обладат рядом приемуществ способных помчь хорошему программисту решить задачу быстрее. Однако Ява так же обладает такими возмостями (хотя и меньшими). И хороший программист решит задачу на обоих языках, просто Эрлэнг ему может дать больше.
Да, все примерно так.
VD>Вопрос даст ли Эрлэнг что-то не очень хорошему прграммисту?
Думаю, что "не очень хорошего программиста" к эрлангу лучше не подпускать.
Да собственно и не только к эрлангу, к тому же ruby тоже не стоит...
VD>Ява дает статическую типизацию и типобезопасность. Плюс она дает тучу фрэймворков и готовую технологию организации больших проектов программистами разной квалификации. Это, по-моему, не мало. Учитывая что в Ява-проектах можно использовать Скалу,
Со скалой пока туго. Пробовал использовать. Сырая она еще слишком, чтобы считаться промышленным решением.
Здравствуйте, Alex EXO, Вы писали: AE>ява — 600 мб, эрланг — 75 мб.
AE>Да можно говорить, что приложения написаны "с разным качестовм",
Прикол в тему.
Только что было в внутрифирменной рассылке...
Итак класс StringUtilities (один класс!), содержит следующие три метода (разумеется написанные разными людьми):
public static String getStringValue(String s) {
return s != null ? s : "";
}
public static String handleNull(String str) {
if (null == str)
return"";
else
return str;
}
public static String null2empty(String title) {
if (null == title)
return"";
return title;
}
от так ота...
И это не смотря на использование всяких навернутых сред разработки для java, торые должны были бы повышать обзорнрсть кода...
Здравствуйте, RustM, Вы писали:
RM>К сожалению с эрлангом не знаком, но не может же язык имея типизацию не относится ни к одному из двух вариантов (статической и динамической)
Разумеется ! Он динамический. Просто по определению из статьи на википедии он не является ни тем, ни другим
RM>ИМХО, понятие сильная типизация слишком расплывчато. Лучше использовать Типобезопасный и не типобезопасный
Гм. Но ведь это далеко не одно и тоже ?
Здравствуйте, VladD2, Вы писали:
VD>В NT на сегодя не малая часть написана на С++.
В NT 4.0 плюсового кода все же не было. Про XP не знаю
VD>Учитывая обратную совместимость С++ с С вообще не знаю о чем можно говорить.
А причем здесь совместимость ? Ежели проект на ++ написан так, что после очень небольшой переделки он компилируется plain C компилером, то я не считаю это С++
VD>Позволь не согласиться. Когда-то это было так. А теперь нет. В общем, попробуй найти ссылки.
Fujitsu очень широко использует кобол. Налоговая служба штатов работает на коболе
Но это все мэйнфреймы, конечно.
G>>В той же Франции 60% экономического ПО до сих пор работает на Коболе. VD>Назави хотя бы оду известную тебе французкую систему написанную на Коболе. Хотя забавно будет и вообще хоть про одну услышать. А то вот, я за всю жинь слышал только об одной, но она была написана на собственном языке который был написан на С. http://www.ione.ru/scripts/comments.asp?c=x&ItemID=1255&Sort=&Page=5&CommentID=1329&ItemType=2 http://www.cio-world.ru/infrastructure/server/35114/
большая часть банков и страховых контор использует его ( за кордоном )
а вот если считать ABAP диалектом кобола, то сразу вылезает R3, к примеру ( это ERP такое )
G>> Новых проектов, конечно же, гораздо меньше VD>Это миф.
Ну, не совсем...Не зря же в IBM WebSphere 5 введена была поодержка Кобола. Хотя — я могу согласиться, что большинство новых проеков на коболе — это перепись старых. Но средства разработки на коболе появляются и новые...
Здравствуйте, VladD2, Вы писали:
VD>Те кто "хотит строем" уже все во фрэймворках. Так что ты их никогда таким образом не обгонишь.
Это фреймворк, заточенный под ОДНУ задачу. Он несколько примитивный, но вполне соответствует своим целям. И. как средство специализированное, весьма эффективен как средство ускорения разработки именно ЭТОЙ задачи.
Здравствуйте, VladD2, Вы писали:
VD>Главная разница — типобезопасность. Если не раводить разговоры об идеальных программистах, конечно.
Вот вот, нет идеальных программистов, идеальных программ и идеальных языков.
Какой мне толк от "типобезопасности", если 90% (в целях оптимизации) статические.
Когда для того чтобы победить тормознутость Явы, пришлось разобраться как работает байт код! Что это дало? оказывается, что если в каждой функции объявлять ссылку на массив, и назначать ей статический массив находящийся в этом же классе (т.е. используем для доступа не сам массив, а локальную ссылку на него), то производительность работы c массивом поднимется до 50%. И это не зависит от аттрибутов, все дело в используемых инструкциях. И таких примеров достаточно.
Самую большую задержку составляло не разработка продукта, а его "ЗАТОЧКА" под мобилы! На ОДНОЙ И ТОЙ ЖЕ модели, которая продается в разных странах (возможно разные партии/прошивки и т.п.) программа может работать по разному. Т.е. криво работает даже стандартная библиотека (т.е. c недокументированными особенностями). Чем тут мне поможет типобезопасность? Или когда приложение работает на эмуляторе работает, а на мобиле напрочь виснет. Чем тут оно поможет?
Мы говорим, о том, что использование Java, имхо, не дает использовать в полной мере весь потенциал мобил. Пример лично видел как Doom реализация работала на первом Nokia 7650 который попал нам в руки (чуть больше двух лет назад), стоила мобила дофига. И такой же FPS показывала 3D игра написанная на Java. Игра написана довольно качественно, что была даже реализация под Nokia 6510i (черно-белый).
Влад если б на мобилаж работал Немерле, то, наверное, я бы его и стал использовать. А пока используем то, что есть, но это "то что есть", не так хорошо как могло бы быть(или как задумывалось).
Здравствуйте, Alex EXO, Вы писали:
AE>ява — 0,3 сек, эрланг 0,05 секунды AE>занимаемая приложеним оперативная память (при сравнимой функциональности): AE>ява — 600 мб, эрланг — 75 мб.
AE>Да можно говорить, что приложения написаны "с разным качестовм",
Думаю, что вообще говорить не о чем. Если подходить к сравнению серьезно, с научным подходом, то нужно делать тесты, обеспечивать их корректность и налогичность, ставить эксперементы. Задача не из простых и вы ее явно не делели.
AE>Все это так, но тенденция остается.
А я вот вижу другую "тенденцию". Ты ушел из такой замечательной компании где можно было исползовать Эрнэнг и пришел на такую плохую где Ява и где качество кода вроде бы ниже. Значит н все в порядк в Королевстве Датском.
AE> Это не единственный известный мне жавовский проект и не AE>единственный эрланговский. Так что о "тормознутости явы" как таковой наверное действительно AE>говорить не стоит, но можно сказать, что на ней как правило получаются тормознутые приложения.
Я бы сказал так. На любом языке намного проще получаются запутанные, медленные и недобные решения. А качественный результат всегда получается сложнее.
VD>>Вопрос даст ли Эрлэнг что-то не очень хорошему прграммисту?
AE>Думаю, что "не очень хорошего программиста" к эрлангу лучше не подпускать. AE>Да собственно и не только к эрлангу, к тому же ruby тоже не стоит...
Значит мы уже нашли нехилое приемущество Явы. Может она не так наварочена как Эрнланг (например, паттерн-матчинга нет), но к ней можно допускать менее квалифицированных программистов. Так ким обрзом если у компании стратегия включает использвоание и опытных и не очень поытных программистов, то Ява для нее уже очень привлекательна.
AE>Со скалой пока туго. Пробовал использовать. Сырая она еще слишком, чтобы считаться промышленным решением.
Да, это действительно проблема. Но думаю, что в течении несколькоих лет это пройдет.
ЗЫ
Собственно я уж точно не фанат явы. Просто хочется чтобы оценки были ближе к реальности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alex EXO, Вы писали:
AE>от так ота...
По-моему, то обычная ситуация для любого большого проекта на любом языке. Страшного тут ничего нет. Если выявлено дублирование, то нет проблем удалить два лишних варианта и заменить их вызовы на третий.
AE>И это не смотря на использование всяких навернутых сред разработки для java, торые должны были бы повышать обзорнрсть кода...
Скажи, а чем бы тут помог Эрланг? Уверне, что ничем.
Средства же помогут автоматически удалить лишние варинаты, но обнаружение нетривиального дублирования кода — это задача для интеллекта. А так как искуственного интеллекта пока нет, то прийдется заниматься этим человеку.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
VD>>В NT на сегодя не малая часть написана на С++. G>В NT 4.0 плюсового кода все же не было. Про XP не знаю
Тут как-то была утечка кода W2k. С++-кода там было много.
VD>>Позволь не согласиться. Когда-то это было так. А теперь нет. В общем, попробуй найти ссылки. G> Fujitsu очень широко использует кобол. Налоговая служба штатов работает на коболе G> Но это все мэйнфреймы, конечно.
Опять одни общие слова. И вот так всегда. Отсюда и появляется мих о том, что Кобол очень распрастранен. Меж тем его давно и с успхом вытесняет Ява даже на мэйнфрэймах. А учитывая, что многие отказались от мэйнфрэмов и что большая часть нового софта уже не писалась для них, то на сегодня Кобол практически встретить почти невозможно.
G>большая часть банков и страховых контор использует его ( за кордоном ) G>а вот если считать ABAP диалектом кобола, то сразу вылезает R3, к примеру ( это ERP такое )
Интересно, откуда вырос этот миф? У меня дома лежит книга по АБАП 4 от того самого R3. Ни слова про Кобол там нет. Язык называется 4GL (тогда это было модно). Сам языек больше похож на современные императивные языки и отличается от них кучей специализированных возможностей по работе с текстом и типами данных вроде таблиц. В общем, императивный язык с морем (порой дебильного) сахара для задач учета. На кобол похож не больше чем VB.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, RustM, Вы писали:
RM>>К сожалению с эрлангом не знаком, но не может же язык имея типизацию не относится ни к одному из двух вариантов (статической и динамической) G>Разумеется ! Он динамический. Просто по определению из статьи на википедии он не является ни тем, ни другим
С чего ты это взял?
RM>>ИМХО, понятие сильная типизация слишком расплывчато. Лучше использовать Типобезопасный и не типобезопасный G>Гм. Но ведь это далеко не одно и тоже ?
Ага. Это разные вещи которые могут сочетаться в одном языке, а могут нет. Отличие их от "сильная типизация" или "строгой типизации" заключается в том, что эти понятия довольно хорошо детерминированы и с ними нет путанницы. Под "сильная типизация" же можно понимать что угодно, так как в разное время разные авторы трактовали этот термин по-своему.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>С чего ты это взял?
Там намекается, что все динамические языки передают информацию о типе вместе со значением. В данном случае это не всегда так.
VD>Ага. Это разные вещи которые могут сочетаться в одном языке, а могут нет. Отличие их от "сильная типизация" или "строгой типизации" заключается в том, что эти понятия довольно хорошо детерминированы и с ними нет путанницы. Под "сильная типизация" же можно понимать что угодно, так как в разное время разные авторы трактовали этот термин по-своему.
Тут я, видимо, соглашусь. Хотя тоже встречаются несколько разные интерпретации этого термина.
Выводы?
Если нам не помогут, то мы тоже никого не пощадим.
если б на мобилаж работал Немерле, то, наверное, я бы его и стал использовать. А пока используем то, что есть, но это "то что есть", не так хорошо как могло бы быть(или как задумывалось).