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

А что такое списки динамической структуры?

SarinМеня больше волновали такие вещи как лишние символы. Они мешают восприятию кода.

В языках с динамической типизацей (питон) синтаксис проще (нет объявлений типов), чем в языках со статической типизацией (java), но плата за это трудности при анализе кода и поиске ошибок. Существенным этот момент становится на стадии поддержки кода и/или при работе в команде.

Любовь к языку основанная на субъективном восприятии красоты/простоты синтаксиса - есть странная любовь :)

Но я это к чему всё.

Есть такой язык Nemerle http://nemerle.org/First_Tutorial
Он сочетает статическую типизацию с мощным выводом типов и ядрёными возможностями функциональных языков.

Вот он, как язык, будет рвать и первую и вторую и третью киянку из упоминавшихся выше, если не преждевременно умрёт :)

SarinИ ещё раз: в большом проекте ява будет немного лучше питона. Фактически код на питоне легко воспринимается (как правило) даже теми кто с ним не знаком.

Большой проект на питоне - не нечто удивительное. Это нормально и вполне возможно.

Откуда такие выводы если ты только начинаешь учить java и вряд ли работал в _большом проекте на java_?
Всё, что ты сейчас знаешь о java, это синтаксис в общих чертах (судя по твоим сообщениям на java форуме), следовательно и судить ты можешь не более чем о синтаксисе. А разница в синтаксисе это самая малая из разниц, которые существуют между языками.

Sarin
Я видел проекты на питоне. И знаю как легко было в них ориентироваться. Не имея IDE типа эклипса. Вот.

А почему ты решил, что лёгкость эта связана с _языком_?
На С тоже можно увидеть код, в котором легко ориентироваться, но это "вопреки", а не "благодаря" языку :)
Очевидно, что качество кода в первую очередь зависит от того, кто его пишет, а не на чём пишет.

А мы же, вроде как, смотрим на вклад языка в процесс создания простого в поддержке кода?

В таком случае смотреть нужно на то, что даёт язык, а не программист который им пользуется.

А этот вопрос ещё по круче чем кирка vs лопата, т.к. включает сразу множество подобных -vs-.

Например, функциональное vs императивное программирование,
функциональная vs объекто-ориентированная декомпозиция,
динамическая vs статическая типизация,
разработка через тестирование (тест-реализация-рефакторинг) vs проектирование-реализация
и т.д.

Если в каком-то из этих пунктов не сойтись, то договориться о том, какой язык позволяет писать более понятный код тоже вряд ли получится :)

Как получить ответы на все эти вопросы только увидив схожесть java с (?)паскалем - я не представляю.

Sarin
Да и по синтаксису можно о многом судить. Например о том, что идеология явы близка к паскалю. Кто-то будет спорить о достоинствах паскаля по части сопровождения?
Я, н-р, не вижу этой близости. И достоинств паскаля тоже :)

SarinБоа - не единственная IDE под питон.
Ещё наверное есть ноутпад? :)

Спор о том, какой должна быть IDE это тоже кирка с лопатой. Хотя людей считающих, что писать в far'e с colorer'ом становится всё меньше.

Посмотри на IDEA, чтобы понять, что такое IDE.

Sarin
Накуй тогда высокоуровневые языки вообще? Они делают программирование слишком лёгким.
Вам клаву ипать нравится? Ипите на здоровье. То что Вы будете писать в 10 строчек на яве я буду писать в одну на питоне. Наверное это хорошо повлияет на вашу самооценку. Вы не боитесь трудностей.
...
Своё мнение я высказал. И аргументировать его смог.


Какой тонкий слог. Вероятно это и есть аргументация ? :)


Sarin
Против явы и иже с ней я не выступал. Но, по всей видимости, широты Вашего мышления не достаёт чтобы охватить другой подход.

Аналогичное утверждение можно послать и в ваш огород.

В чём собственно подход?
Отказаться от статической типзации ради возможности не описывать тип переменной?
Разрешить делать вещи, за которые нужно просто пару раз "посадить на кол"?
Лишиться возможностей IDE в угоду экономии нескольких строчек?
Ну... интересный подход.


Sarin
О функциональном программировании:
Кто сделает на нефункциональном языке такое:
массив a = [1, -3, 15, -8, -40, 2]
Выбрать положительные элементы и прибавить к ним 20.
Вот на питоне:
b = map(lambda x: x+20, filter(lambda x: x > 0, a))


Я сделаю!


И что?

Как только даннные обрастут логикой, оверхед выражаемый в количестве печатаемых символов станет равен ноль, а оверхед выражающийся _в хрен поймёшь, что за объект в этой переменной_ - сказачно вырастет.
Чтобы как-то с этим жить, придётся
- вводить столь не любимую типизацию в имена переменных ввиде префиксов, постфиксов и просто красивых символов
- писать кучу комментариев типа "в этот мега метод можно передавать только объект у которого есть методы х,у,z!" (и конечно же всех посадить на кол, кто не будет этого делать экономя !строчки)
- написать 578 тестов в надежде, что они покроют все возможные ветвления в коде
- ползать с текстовым find & replace по сорцам при малейшей необходимости, что-то переименовать, а потом бросить, т.к. окажется, что разобрать где что используется не возможно т.к. разные объекты имеют одинаковые сигнатуры методов
- ...

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


Киянок тут придостаточно...

Я только одного не пойму, причём тут паскаль?!

QuasarТак и знал... дисскуссия превратилась во флейм. Что и требовалось доказать.
Кому требовалось? :)

Quasar
Теперь каждый будет хвалить то, в чем он сильней, опытней и тд.

А надо наоборот? Найти тему в которой ничего не понимаешь и хвалиться ею? :)

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

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

Quasar
Камень в огород Явы это БЕЗУМНЫЕ требования к железу. Чтобы работать с многопользовательской, многоуровневой системой нужны очень неслабые железки.

Взять к примеру вот это твоё утверждение.

Откуда берётся слово "БЕЗУМНЫЕ"?
Сколько стоит разработка "многопользовательской, многоуровневой системой"?
Сколько будет стоить эквивалентная разработка на другом языке?
А если вычесть одно из другого и сравнить с ценой на "безумное" железо?
Какова разница в стоимость поддержки?
А почему это камень в огород java, а не "многопользовательских, многоуровневых систем"?

QuasarДаже система построенная на DCOM с использованием 3х звенной архитектуры будет менее требовательна к железу, чем аналогичная система, написанная на Яве.
NotGonnaGetUs , скажите честно, это неправда?

Не пользовался DCOM, судить не могу.

Даже если предположить, что это правда, о чём это скажет?
Помимо требований к железу есть и другие факторы, которые могут играть роль при разработке той или иной системы.

Quasar
Но вы скажете, что мол, на яве мы имеем переносимость. Но тем не менее не всегда с первого раза система написанная на Java, скажем под win32 запуститься на том же линуксом или фрей.

Сколько не пишу, почему-то всё запускается с первого раза. Разница между платформами появляется только в виде необходимости подджерживать различные типы веб-браузеров. Всё потому, что количество pure java библиотек равно 99%. Оставшийся 1% используется только там, где в этом есть нужда, а если есть такая нужда, то какие могут быть вопросы о переносимости?!

Quasar
Я не пытаюсь расжечь флейм, просто смотрим на вещи как есть.
Посмотрите статью, кстате:
http://www.twistedmatrix.com/~glyph/rant/python-vs-java.html
Ты правда считаешь, что это статья отражает реальность?

1. Время затрачиваемое на Start up JVM не должно учитываться в тесте, т.к. с ростом сложности приложения оно становится 0, а для тривиальных тестов составляет больше 50% (start up связан с процессом верификации классов подгружаемых JVM, поэтому сравнивать время загрузки пустого класса, как это сделано в тесте - глупо).
С момента написания статьи появилась возможность запустить один инстанс JVM per PC, т.о. о start up overhead'е можно не задумываться.

2. Есть представление о том, что такое Hot Spot и с какой версии java он появился?
Если JVM делает предположение, что данный фрагмент кода будет вызываться часто, этот фрагмент компилируется и далее вызывается native код.
Как это связано с мега тестами?
На момент вызова теста у JVM ещё нет статистики, достаточной чтобы решить нужно его компилить или нет. Т.к. вызов метода-теста происходит один раз, то он будет интерпретироваться, и производительность будет не высока.
С 6-ой версии будет работать такая фича, как переключение с режима интерпретации на native код в процессе _интерперетации_. Т.е. если метод очень долго работает (тест), то не дожидаясь окончания его работы JVM передаст управление native коду.

JVM сделана так, чтобы обеспечить повышенный перфоманс для долго работающих приложений (долго = методы вызываются чаще, чем 1 раз за срок жизни приложения). Одноразовые запуски - удел скриптов.

3. Код в тестах писался так, чтобы нагрузить GC у Java и показать оптимизации для встроенных типов питона.

Hint(1): создание объектов оболочек для каждого int.
Hint(2): преобразование в объекта в String перед печатью.
Hint(3): использование синхронизированных классов

//ConsoleTest
Тест ни о чём.
System.out.println сбрасывает output буффер.


^^^ тест с сайта работает у меня 110с, исправленный 10с.
Процесс заключённый в цикле требует всего 0.3с.
Если output перенаправить в файл, а не в консоль моей IDE, то получается 0.6 секунд.

Сравни с сайтом.

Как думаешь, 110с и 0.6с это одно и тоже?


//Hashset

Test c сайта у меня работает 0.26с.
Мой вариант (java 1.5): 0.16с.


Добавь к этому, что 1.1.х работает существенно медленее, чем 1.5 и тогда получится что ни о каких 2х в пользу питона речи быть не может.
К тому же надо понимать, что в данном случае hashMap может быть заменнён на больее подходящую структуру данных, если мы собираемя в ней хранить только числа.

Опять не тест.

//IOTest
Опять не буферезированный output.

Вариант с сайта 0.66с.
Мой вариант 0.43с.
1.2х в пользу питона перекрыт.


Тест опять ни про что, т.к. файловая система одинаково тормозит в любом языке.

//ListTEst
Хотя тест и так показывает превосходство java:
Их вариант 0.110с
Мой вариант 0.070с


Дальше говорить бесполезно, и так всё очевидно.

Достаточно посмотреть на
Object Allocation 23.65 211.11 Java 8X Faster than Python
чтобы задаться вопросом:
А правда ли есть смельчаки пишущии в OOP стиле на Python'e, если самая распространённая операция с объектами это 8х-ый проигрыш java?
А как тогда обстоят дела с эффективностью полиморфных вызовов?

Fabrichenko Viktor2NotGonnaGetUs респект!!! я бы поленился делать :-))

Я тоже долго ленился :)

мод NotGonnaGetUs Java 8X Faster than Python
Вы бы еще на ASM попробовали, было бы еще круче.
Python не для того что бы тягаться с С или Явой в скорости - не королевское это дело.

Ой. Мод, ты хоть читал сообщения тех, кому я отвечал?