LINUX.ORG.RU

Наивысшая производительность цикла разработки и исполнения это причина популярности Java


0

0

Трудно не согласиться с блоггером Karsten Wagner http://www.blogger.com/profile/096524... который в своем эссе признался, что из всех ему известных языков программирования он чаще всего прибегает к Java при разработке своих приложений. Он сравнивает Java с Lisp, Smalltalk, Haskell и не всегда сравнение в пользу динамических языков. Рассматривается влияние производительности кода, которая по его мнению все еще играет значимую роль в выборе ЯП, особенно для веб-проектов. Также большую роль в популярности Java оказывает ее статическая природа, позволяющая создавать непревзойденные до сих пор ни кем по удобству IDE и инструменты.

>>> Подробности

anonymous

Проверено: anonymous_incognito ()
Ответ на: комментарий от zort

> функциональным языком в современном смысле слова он не является, значит research платформой быть не может. как практический язык, сейчас, является набором не эффективных решений и плохих программистских практик. строительство языка на макросах не эффективно с точки зрения "комилятрных" технологий и переиспользуемости

Ты забыл добавить "это говорю вам я!" в конце каждого предложения.

> чистый компилятор будет гораздо эффективнее,

есть слухи что кодить напрямую в машинный код ещё эффективнее. Только нужно подучиться малёхо.

> а проблемы с сопровождаемостью от такого конструирования и бажность уничтожают все плюсы.

Источник? Чтото я не слыхал ни про повышенную бажность ни про траблы с саппортом. И ваще, изволь ознакомиться с областями, в которых применяют лисп. И почему его там.

> предпочтительный стиль программирования (функционально рекурсивный) не совместим с теорией алгоритмов.

это теория алгоритмов несовместима с, ты всё напутал

> Сейчас полно других языков с first class functions, lists, recursion etc типа Ocaml, их и рекламируйте,

чё хотим то и рекламируем, ну ваще

> встроенная объектная система.

Типо она лучше лисповой?

> Все плюсы лиспа которых нет Ocaml'о-подобных - это на самом деле минусы, и ресерчеры это давно поняли, и поэтому не развивают.

вылазь из машины времени, слишком газанул сильно. И больше не кури в её салоне этих грыбов.

> Да, я знаю что в java половина design patternов заменяеся просто и естественно простыми лисповыми "костыльками" на основе функций, но чтоб эти "костыльки" написать, простой "Иван" должен потратить кучу времени, так пусть уж тогда тратит его на изучение последних достижений в облсти PL, а не достижений 80х.

Аха, а ещё в 80х вобла была...

bugmaker ★★★★☆
()
Ответ на: комментарий от bugmaker

>легким и автоматизированным способом, намного более логичен и прозрачен

и вабще этот способ волшебный, и им пользуются только умные, влиятельные, состоявшиеся люди, ага.

zort
()
Ответ на: комментарий от DIMON

>> Висит ведь до сих пор в топе "довертесь виртуальной машине"

> Я больше доверяю биореактору :))

Зря. Оттуда постоянно ктонибудь сбегает.

bugmaker ★★★★☆
()
Ответ на: комментарий от bugmaker

> стиль работы в лиспе отличается от стиля работы в бейсике. Код производится более легким и автоматизированным способом, намного более логичен и прозрачен, и поэтому бейсиковские проблемы в лиспе просто не возникают.

Отож :) Ответь на простой вопрос - при изменении сигнатуры функции, отловит ли компилятор все неправильный обращения к ней? Так, как это будет в Си++ или Java.

tailgunner ★★★★★
()
Ответ на: комментарий от bugmaker

>есть слухи что кодить напрямую в машинный код ещё эффективнее

компиляция семантики языка в низкоуровневый байткод(оr somethining) быстрее макросовых костылей. это компьютерно-научный факт. если вам интересно сами разбирайтесь.

>это теория алгоритмов несовместима с, ты всё напутал

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

>Источник? Что-то я не слыхал ни про повышенную бажность

мне источников не надо, чтобы знать что челы с совковым образованием не в состоянии верифицировать ровным счётом ничего из своих "макро трансформаций"

zort
()
Ответ на: комментарий от tailgunner

если вы имеете ввиду во время компиляции, то какой нибудь CommonLispовый с каким нибудь специальным ключем - точно отловит.

zort
()
Ответ на: комментарий от zort

> если вы имеете ввиду во время компиляции, то какой нибудь CommonLispовый с каким нибудь специальным ключем - точно отловит

"Какой-нибудь"... может быть :) Конкретные примеры, плиз. Вот есть SBCL и CLisp - они отловят? И что именно для этого надо сделать?

tailgunner ★★★★★
()
Ответ на: комментарий от zort

> челы с совковым образованием не в состоянии верифицировать ровным счётом ничего

О как... пошли наезды на Союз 8-O

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Отож :)

А шо отож? Функция в лиспе и функция в сях/жабе это несколько разные явления. Не говоря уж о макросах и спецформах всяких.

> Ответь на простой вопрос

Не такой уж и простой, как кажется. Как ты соизволиш отловить неправильные типы например в такой конструкции: (apply #'+ a) ? Конструкция означает суммирование всех элементов списка а, каковой список произошёл из недр проги. Фактически, этотоже самое что отловить на этапе компиляции ошибки типов содержимого например Hashtable в жаве или аналогичного контейнера в с++. Никогда не видел ClassCastException в жабе или сегфолт в с++? Т.е. в лиспе ситуация полностью аналогична. В самых примитивных случаях всё отлавливается, а в запутанных - нет. Только в лиспе не лукавят, и не говорят что якобы строгая статическая типизация, которой на самом деле нету ни в жабе ни в с++.

> при изменении сигнатуры функции, отловит ли компилятор все неправильный обращения к ней?

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

bugmaker ★★★★☆
()
Ответ на: комментарий от zort

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

"У нас" - это где? Союза ("совка", как называлие его те, кто к нему плохо относился) нет уже 15 лет.

tailgunner ★★★★★
()
Ответ на: комментарий от bugmaker

> строгая статическая типизация, которой на самом деле нету ни в жабе ни в с++.

Тебя несет.

> это плацебо.

Э. А. По не с тебя "Бес противоречия" написал? :D

tailgunner ★★★★★
()
Ответ на: комментарий от zort

>> есть слухи что кодить напрямую в машинный код ещё эффективнее

> компиляция семантики языка в низкоуровневый байткод(оr somethining) быстрее макросовых костылей. это компьютерно-научный факт. если вам интересно сами разбирайтесь.

дык компиль быстро-быстро, ато наверное ещё на сёдня план по компиляции не выполнил, а уже пришед флеймить тут.

>> это теория алгоритмов несовместима с, ты всё напутал

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

гик, ты? Чё, от аккаунта пароль потерял или зобанил кто?

>> Источник? Что-то я не слыхал ни про повышенную бажность

> мне источников не надо, чтобы знать что челы с совковым образованием не в состоянии верифицировать ровным счётом ничего из своих "макро трансформаций"

точно он. "источников не читаю, ибо итак всё понятно". Узнаю ваш почерк!

bugmaker ★★★★☆
()
Ответ на: комментарий от tailgunner

мы живем на территории Советского Союза, в котором не было CS образования и науки на средне мировом уроне, и 10 лет из 15 жили в экономическом кризисе. СS образованию взяться не откуда.

ЗЫ совок - это я для сокращения.

ЗЗЫ кончаем офтопить.

zort
()
Ответ на: комментарий от tailgunner

>> строгая статическая типизация, которой на самом деле нету ни в жабе ни в с++.

> Тебя несет.

Нет, тебя. И будет ещё долго носить, пока не осознаеш зачем в жабе есть ClassCastException.

>> это плацебо.

> Э. А. По не с тебя "Бес противоречия" написал? :D

Возможно. А что, не должен был?

bugmaker ★★★★☆
()
Ответ на: комментарий от bugmaker

>> Тебя несет.

> Нет, тебя.

:D я всего лишь задаю вопросы.

> И будет ещё долго носить, пока не осознаеш зачем в жабе есть ClassCastException.

Я это лет 10 как знаю. И к вопросу о сигнатуре функции это исключение отношения не имеет. А я ведь даже не начал спрашивать об обращениях к полям :)

> > Э. А. По не с тебя "Бес противоречия" написал? :D

> Возможно.

Это многое объяснило бы :)

tailgunner ★★★★★
()
Ответ на: комментарий от bugmaker

>И будет ещё долго носить, пока не осознаеш зачем в жабе есть ClassCastException.

Для вот такого:

Object a = "aaa"; Integer i = (Integer) a;

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

r ★★★★★
()
Ответ на: комментарий от zort

> мы живем на территории Советского Союза, в котором не было CS образования и науки на средне мировом уроне

Насколько _я_ знаю, в Союзе вполне были и CS, и SE. Не выдающиеся, но нормальный средний уровень.

tailgunner ★★★★★
()
Ответ на: комментарий от bugmaker

>Узнаю ваш почерк!

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

zort
()
Ответ на: комментарий от tailgunner

>>> Тебя несет.

>> Нет, тебя.

> :D я всего лишь задаю вопросы.

"умный не спрашивает, а сам постигает природу вещей". Знаеш откуда цытато?

>> И будет ещё долго носить, пока не осознаеш зачем в жабе есть ClassCastException.

> Я это лет 10 как знаю. И к вопросу о сигнатуре функции это исключение отношения не имеет.

Ещё как имеет. Какого лиха ловить ашыпки типов на этапе компиляции если они всё равно все не ловятся? Старая добрая традиция со времён фортрана. В фортране кстати ловились...

> А я ведь даже не начал спрашивать об обращениях к полям :)

чьим?

>>> Э. А. По не с тебя "Бес противоречия" написал? :D

>> Возможно.

> Это многое объяснило бы :)

А помоему только зря запутало бы.

bugmaker ★★★★☆
()
Ответ на: комментарий от r

>> Для вот такого:

> Object a = "aaa"; Integer i = (Integer) a;

Неугадал. Кому понадобится понаписать такое в реальном проекте?

bugmaker ★★★★☆
()
Ответ на: комментарий от r

>Object a = "aaa"; Integer i = (Integer) a;

Ты будешь смеяться но джава ушла в segmentation fault!


public class fuck {

public static void main(String[] args) {

Object a = "aaa"; 
Integer i = (Integer) a;

	System.out.println(i);

}

}

p.s: jdk 1.5.09 сановский 

signal
()
Ответ на: комментарий от tailgunner

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

zort
()
Ответ на: комментарий от magellan

>Вон в соседней новости Mono ересь обсуждают. И, кстати, НИ ОДНОГО ПОМОЙНОГО ПОСТА.

Куясе... ща пойду исправлю...

anonymous
()
Ответ на: комментарий от bugmaker

> "умный не спрашивает, а сам постигает природу вещей". Знаеш откуда цытато?

Не знаю :( Я вообще ни разу не умный

> Какого лиха ловить ашыпки типов на этапе компиляции если они всё равно все не ловятся?

Что, совсем не ловятся, никакие? :D Зачем вообще писать программы, раз в них всё равно есть ошибки? ;)

>> А я ведь даже не начал спрашивать об обращениях к полям :)

> чьим?

Объектов :)

tailgunner ★★★★★
()
Ответ на: комментарий от bugmaker

ага, еще теорией категорий, f-алгебрами, и катаморфизмами всякими... дурацкий VSL со сыоим хацкелем. :(

zort
()
Ответ на: комментарий от signal

а моя - не.

Exception in thread "main" java.lang.ClassCastException: java.lang.String
        at fuck.main(fuck.java:6)

java version "1.5.0_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01)
Java HotSpot(TM) Client VM (build 1.5.0_09-b01, mixed mode, sharing)

bugmaker ★★★★☆
()
Ответ на: комментарий от tailgunner

>> Какого лиха ловить ашыпки типов на этапе компиляции если они всё равно все не ловятся?

> Что, совсем не ловятся, никакие? :D

ловятся тривиальные.

> Зачем вообще писать программы, раз в них всё равно есть ошибки? ;)

чтобы дебажить. Это ведь так увлекательно.

>>> А я ведь даже не начал спрашивать об обращениях к полям :)

>> чьим?

> Объектов :)

в лисповых обектах слоты вместо.

bugmaker ★★★★☆
()
Ответ на: комментарий от signal

ты наверное усилием мысли своей нанависти к jvmу повлиял на молекулы процессора... экстрасенс...

zort
()
Ответ на: комментарий от bugmaker

>Кому понадобится понаписать такое в реальном проекте?

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

r ★★★★★
()
Ответ на: комментарий от r

> Я просто показал что все можно привести к обжекту а обжект прокастить к чему-попало - и следствием будет CCE.

Ну это понятно. Фишка в том, что это необходимо юзать в контейнерах, таких как Collection и Hashtable всякое, без этого никак. А в лиспе оне на уровне языка. В этом и разница. Что в жабе содержимое контейнера при извлечении можно откастовать криво, что в лиспе.

> А в реальном проекте это встречается где-попало, взять хотя бы рефлекшен.

Гдепопоало это нехшё. И после этого говорят о строгой типизации? Хм...

bugmaker ★★★★☆
()
Ответ на: комментарий от r

jdk1.6:

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer :)

krum
()
Ответ на: комментарий от bugmaker

> ловятся тривиальные.

Хм. Автору поста срочно дать описание тривиальных и нетривиальных ошибок.

kda ★★★★★
()
Ответ на: комментарий от signal

>Object a = "aaa"; Integer i = (Integer) a;


---------------------

Ты будешь смеяться но джава ушла в segmentation fault!

public class fuck {

public static void main(String[] args) {

Object a = "aaa"; 
Integer i = (Integer) a;

	System.out.println(i);

}

}

p.s: jdk 1.5.09 сановский 

------------------------

Не надо "ля-ля":

public class Test {

public static void main(String[] args) {

Object a = "aaa"; 
Integer i = (Integer) a;

	System.out.println(i);

}

}

Java 5

Exception in thread "main" java.lang.ClassCastException: java.lang.String
        at Test.main(Test.java:6)

Java 6

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
        at Test.main(Test.java:6)

Ручонки ламерские пионЭрам когда выпрямлять будем?

anonymous
()
Ответ на: комментарий от tailgunner

>Союза ("совка", как называлие его те, кто к нему плохо относился) нет уже 15 лет.

Странно. Союза нет, а совок никуда не делся. Вот буквально 4 дня назад прошли выборы в Советы народных депутатов, победила как всегда КПСС, как там она бишь сейчас называется? Поэтому и специалисты по компьютерной науке не нужны, ибо статьями в "Химии и жизни" на хлеб не заработать. Кстати, нужна кому-нить подшивка за Химии и жизни за 43 года? В PDF недавно раздавали варезники

anonymous
()
Ответ на: комментарий от anonymous

>Сигналу надо менять погоняло. Он просто принародно опозорился. :)

Ага ,сразу после исчезновения анонимузов с лора :)

P.S. с падением джавы -отбой : это была проблема с библиотеками на моей домашней машине :)

signal
()

Зачем подтверждать такую чушь? Перенесите эту новость в толксы.

Есть много сфер где Ява никогда не дотянется по скорости разработки к скриптовым языкам. И про РОР он пишет полную херню.

Ну блин, а какое говно он про Хаскел написал? Типа я смотрел код GHC - так там полный ахтунг. Человек тупой баран или он не понимает, что код сложного компилятора не может быть сладким пряником?...

Cris
()
Ответ на: комментарий от signal

> это была проблема с библиотеками на моей домашней машине :)

ПионЭры-"кульхацкеры" не могут даже ручки выпрямить, зато лезут про Жабу чего-то болтать.

anonymous
()
Ответ на: комментарий от Begemoth

Видите ли, коллега, у жабаистов свой подход к этому делу. Сначала они делают язык в котором любая простейшая операция требует 30 строк кода, а потом пишут IDE, который будет помогать им генерить этот boilerplate код и жутко гордиться тем, какой у них продвинутый IDE. Было бы смешно, если бы все это не происходило на полном серьезе, за огромные бабки и, самое главное, с непопровимым ущербом для разума незнакомых с другими языками (те же Lisp, Smalltalk). На неподготовленных людей мысль о том, что IDE автоматически генерирует проект с тысячей строк кажется привлекательной, они не бегут в ужасе от языка, где эта тысяча строк необходима. Да у автора и самого постоянно проскакивают фразочки типа "Many of the uglities the Java language has simply disappeared when I used this IDE". В общем, ничего нового: создадим себе трудности и потом будем их героически преодолевать..

anonymous
()
Ответ на: комментарий от dave

> Когда станет много кода, а создание IDE уровня NetBeans или IDEA требует кучи кода, то тогда динамическая природа языка станет мешать, особенно в случае групповой разработки. Пойдут различные нестыковки между участками кода, написанными разными людьми. Например, начнут вылазить различные run-time ошибки из-за несоответствия типов данных в самых неожиданных местах. В общем, ничего хорошего...

Ха-ха. Можно подумать, что Джава поможет отловить, если ей передадут, например, неотсортированный массив вместо отсортированного.

Кстати, интересно, Emacs - это "куча" кода? (При том, что делает он, мягко говоря, побольше, чем Джавовские IDE)

anonymous
()
Ответ на: комментарий от Cris

>Есть много сфер где Ява никогда не дотянется по скорости разработки к скриптовым языкам.

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

Но скриптовые языки не масштабируемы.

>Типа я смотрел код GHC - так там полный ахтунг. Человек тупой баран или он не понимает, что код сложного компилятора не может быть сладким пряником?...

Он понимает, что "преимущества функционального подхода рассыпаются в прах при роста объема проектов" и "компилятор, написанный на Хаскель, такая же каша, как если бы его писали на C или другом гавне". Все эти pattern-matching и type-inference работают только в игрушечных примерах, а в жизни (коде GHC) все совсем не так как на самом деле.

anonymous
()
Ответ на: комментарий от Cris

>И про РОР он пишет полную херню.

Да кстати, я выучил ROR, где мне теперь на job.ru найти вакансии требующие навыков настройки ROR?

>Есть много сфер где Ява никогда не дотянется по скорости разработки к скриптовым языкам.

Да, они есть. Но В ЦЕЛОМ доминирует-то Java, потому что имеет средства для решения САМОГО широкого круга задач. Даже легкость написания кроссплатформенного GUI http://kawagner.blogspot.com/2007/03/why-do-most-people-seem-to-use-inferior.... является определяющим фактором в продвижении Next Big Language.

anonymous
()
Ответ на: комментарий от anonymous

> где мне теперь на job.ru найти вакансии требующие навыков настройки ROR?

Нашёл где искать. Ты б ещё на rabota.ru сходил.

> Но В ЦЕЛОМ доминирует-то Java, потому что имеет средства для решения САМОГО широкого круга задач.

Нет, не поэтому. Всё дело в том, что Java is designed to be understandable by brain-damaged people. (c)

AHOHuMYC
()
Ответ на: комментарий от zort

> компиляция семантики языка в низкоуровневый байткод(оr somethining) быстрее макросовых костылей. это компьютерно-научный факт. если вам интересно сами разбирайтесь.

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

> это компьютерно-научный факт. если вам интересно сами разбирайтесь. Научились бы выражать свои мысли хотя бы более-менее связно, прежде, чем выступать с заявлениями про то, что > челы с совковым образованием не в состоянии что-то сделать. Большинство из них в состоянии изъясняться более внятно, чем обдолбанный 13-летний подросток.

anonymous
()
Ответ на: комментарий от zort

> компиляция семантики языка в низкоуровневый байткод(оr somethining) быстрее макросовых костылей. это компьютерно-научный факт. если вам интересно сами разбирайтесь.

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

> это компьютерно-научный факт. если вам интересно сами разбирайтесь.

Научились бы выражать свои мысли хотя бы более-менее связно, прежде, чем выступать с заявлениями про то, что > челы с совковым образованием не в состоянии что-то сделать. Большинство из них в состоянии изъясняться более внятно, чем обдолбанный 13-летний подросток.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.