×Закрыть

Почему Java программисты зарабатывают больше и что им за это будет

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

Итак начнем с популярности платформы. За Java изначально стояла многомиллиардная компания, которая вкладывала в эту популярность большие деньги, создавала фреймворки, стимулировала сообщества разработчиков для того чтобы создать ощущение простоты разработки и надежности поддержки. Все это любят те, кто заказывают Enterprise софт и поэтому в мире существует безумное количество проектов, заказанных большими компаниями именно с использованием Java. Есть даже мнение, что никого еще не уволили за то, что он выбрал Java как платформу для проекта, и это играет не последнюю роль в выборе, которые делают IT директора крупных компаний. Кроме того Enterprise — это дорого, а раз так то кажется качественным и надежным.

Большинство разработчиков в Украине как раз и работает на иностраных Enterprise заказчиков, поэтому эти платформы настолько популярны в нашей стране и на Java разработчиков существует безумный спрос на рынке труда. Как следствие у них растут зарплаты в результате переманивания разработчиков из одного проекта/компании в другую.

Почему этого не происходит в других технологиях — во-первых из-за немного более низкого ажиотажа и связаного с этим переманивания разработчиков, во-вторых, в отличие от Java проектов, которые преимущественно похожи как две капли воды, в других технологиях намного больше творчества. А как известно начиная с уровня, когда денег достаточно на велосипед и зеркалку, человеку становится немаловажным интересность его работы и в арсенале мотивации сотрудиков появляются другие вещи чем повышение зарплаты и тренажерные залы. Так как на рынке есть другие мотиваторы кроме зарплаты, поэтому в не-Enterprise сегменте зарплаты повышаются несколько меньшими темпами, но если измерить удовлетворенность сотрудников, то мне кажется в этом сегменте она будет не ниже а даже немного выше, впрочем я могу и ошибаться.

С почему выше зработок более менее разобрались, перейдем к тому чем это грозит. Мало кто не согласится, что при одинаковой квалификации большинство задач на Ruby/Python/PHP реализовывается проще и изящнее чем на Java и как следствие продуктивность труда в Java индустрии ниже. Это проблема № 1 — более низкая продуктивность труда. Также постоянно работая в рамках довольно жестких фреймворков у разработчиков теряется творческая составляющая, для проекта это хорошо так как появляется взаимозаменяемость, а вот для инженера не очень, так как это приводит к частичной деградации и остановке в развитии. Простой пример, попросите Java разработчика и Python/PHP/Perl/Ruby разработчика за сколько они сделают простенький сайт вроде milliondollarhomepage.com а еще лучше попросите их сделать и запустить, сроки будут отличаться в разы. Да это пример из веба но там сейчас идет большинство разработки и подавляющее большинство стартапов, которые на слуху это интернет компании.

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

Мораль: если для вас самореализация и удовольствие от работы важнее лишних нескольких сотен $ в месяц ищите возможность писать на чем-то отличном от мейнстрима Java. Спрос на хороших разработчиков сейчас есть во всех технологиях. А взамен вы получите более высокую собственную эффективность, способность работать в более интересных проектах и если вы однажды захотите реализовать небольшой pet-project за пару вечеров, который может перерасти в успешный бизнес то всегда полезно иметь под рукой хороший инструмент которым вы владеете.

...И помните что произошло с COBOL-ом.

PS. Прекрасно представляю себе волну критики от защитников Hibernate, Spring, EJB, JSF и прочих вкусностей, но в отличие от большинства критикующих автор попробовал обе стороны и его мнение базируется исключительно на личном опыте, впрочем оно не претендует на единственно правильное.

PS2. Почти тоже самое можно написать про .NET, где зарплаты лишь немного ниже чем в Java.

  • Популярное

Лучшие комментарии пропустить

Не согласен касательно применимости Java. Аргументы ниже..

Работаю уже на 3-ем НЕ-Enterprise стартапе, использующим Java. Ruby On Rails это тоже фреймворк, ограничивающий творчество при разработке Rails приложений. Как и Django. Как и ZendFramework.

Я равнодушно отношусь к Spring, JSF, EJB, JPA etc. и не считаю их неотъемлемой частью Java-разработки (но это уже другая тема). Однако сам язык Java, как и платформа в лице JVM, это на сегодняшний день самая мощная кросс-платформенная платформа (сори за тавтологию) для WEB-приложений.

А с другой стороны, дело даже не в языках, платформах и технологиях — дело в людях, которые используют эти самые языки и технологии. Уверен что существуют проекты, ужасно написанные на Ruby/Python, в которых черт ногу сломит. Равно как и существуют хорошо и грамотно реализованные Java-проекты. Да и от проблемы копи-паста никакой язык не спасет.

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

Т.е. мораль такова — язык программирования это хорошо, а голова остается самым важным инструментом программиста :)

Категорически не согласен с автором статьи. Буквально по всем пунктам. Итак:

Мало кто не согласится, что при одинаковой квалификации большинство задач на Ruby/Python/PHP реализовывается проще и изящнее чем на Java и как следствие продуктивность труда в Java индустрии ниже.

Извините, это бред. Ruby/Python/PHP и Java это инструменты, каждый хорош для решения своей задачи. Да, просто веб — сайт быстрее разработать на РHP, только java — ни разу не средство для разработки сайтов, это платформа для корпоративного программного обеспечения и разработки сервера(не путать с сайтами). Да, сайт — визитку гораздо быстрее сделать на PHP, но если вы разрабатываете скажем биллинговую систему, где веб — часть это только админка, тогда php не подходит совершенно.

И это не потому, что PHP плох, или Java хороша: каждое средство для своего. Вы же допускаете существование иголки с ниткой и навороченной швейной машины с ЧПУ. Понятно, чтоб пришить пуговицы на рубашке даже доставать из футляра машину не стоит, но если нужно сшить сто рубашек, да разных, да с минимальными трудозатратами, тут уже швейная машина нужна.

По поводу стоимости java — программистов, вы удивитесь но они стоят дороже банально потому, что порог входа выше. Т.е. чтоб студенту начать писать на PHP достаточно прочитать одну — две книги. А чтоб на java писать? Сколько лет проходит прежде, чем человека подпускают к разработке новых проектов? Вот поэтому зарплаты и таковы, а вовсе не потому, что начальство перестраховывается. Любой заказчик хочет платить как можно меньше, это закон. Банки используют джаву не потому, что денег не умеют считать(это их кусок хлеба вообще то) а потому, что это дешево. Ну нет смысла, нанять программистов на PHP, заплатить им меньше денег и не получить в итоге нужного!

в других технологиях намного больше творчества

Это, уж извините, полная ахинея. Вам привести список инструментального программного обеспечения написанного на java, web — серверов, p2p сетей, или сами погуглить можете?

Другое дело, что на Украине вообще мало инновационных проектов, но это на всех языках.

если для вас самореализация и удовольствие от работы важнее лишних нескольких сотен $ в месяц ищите возможность писать на чем-то отличном от мейнстрима Java.

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

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

Ещё раз: никто не будет выбирать дорогое и не эффективное при этом средство. Когда люди голосуют баблом, они очень внимательны в выборе.

337 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Мыкола, хантишь? :)

Немного про Джаву и Кобол “Hate Java? You’re fighting the wrong battle.” goo.gl/qvWbS

Не погоджуюсь абсолютно. Як писали в попередніх постах — кожна мова програмування має своє призначення. Тому порівнювати PHP і Java некоректно. А творчість можна проявити будь-якою мовою, головне бути творчим.

Не согласен! Пусть, уважаемый автор,у вас на момент написания статьи и было высокое эмоциональное состояние, но оплевывать Java из-за одного проекта у вас нету права. Как и любой язык Java имеет свои преимущества и недостатки из-за того что каждый язык ориентирован на свой сегмент. Где-то он справляется лучше, а где-то хуже. Если вы вспомните институтский курс экономики и то что у нас, как и в большинстве стран мира действует рыночная экономика, то цена на продукт стоит ровно столько, сколько должна стоить — «Народ голосует рублем :)». Из этого вытекает простая формула: «Цена программного продукта прямо пропорционально зависит от его сложности, и обратно пропорционально от количества специалистов готовых его реализовать». Говоря о полете фантазии и удовольствии при создании программного кода, то лично мне больше нравится создавать бизнес-логику приложений, а кому то рюшечки в GUI создавать, дело вкуса. Лично мне Java нравится т.к. она выполняет те задачи которые мне нужны, в сторону Python’a посматриваю, а кому то нравится PHP со всеми его многотомными фреймворками, так что тут дело вкуса и поставленной задачи.

Что произошло с Коболом?

Что за бред?

Поддержка решения, сложностью чуть более домашней странички, если оно написано на скриптовом языке, ака ПХП, превращается в сущий ад.

Именно поэтому энтерпрайзы пишут на Java или .Net.

И фреймворки тут совершенно ни при чем.

ЗЫ

А сколько лет опыта за плечами автора?

Поддержка решения, сложностью чуть более домашней странички, если оно написано на скриптовом языке, ака ПХП, превращается в сущий ад.

И фреймворки тут совершенно ни при чем

Я довольно долгое время был ярым противником и критиком PHP, признавая его исключительно как нишевый язык для быстрой разработки простеньких Веб-сайтов. Но потом на глаза попались материалы и про unit testing, и про MVC (включая несколько готовых фреймворков), и даже, по-моему, dependency injection — после чего мое отношение изменилось в гораздо лучшую сторону.

ИМХО проблема этого языка — это большое количество самоучек, которые осилили полторы книги из серии «PHP за 24 часа» и, с другой стороны, наличие спроса на «специалистов» такого уровня со стороны дешевых Веб-студий. Что, в совокупности, поддерживает ошибочный стереотип PHP как языка, как минимум — поощряющего «г...нокодерство», а как максимум — поддерживающего только такой стиль разработки.

В мире Microsoft в свое время, кстати, тоже была подобная проблема, когда переходили с ASP (который поощрял примерно такой же «макаронный» стиль) на ASP .NET. Но там, благодаря другой структуре спроса и усилиям самих Microsoft по пропаганде правильных подходов к разработке, от подобного «пятна на репутации» удалось очень быстро избавиться.

А

что произошло с COBOL-ом.

?

на самом деле уволили как-то жаверов... источником информации есть книга Экслера OZON.ru

в свое время IT отдел разделили на две части. первые занимались складским учетом, а вторые должны были разрабатывать веб-витрину на java, JVM запускали на одной из BSD. В общем разработчки веб витрины срывали все сроки, а разработчики складского учета закончив внедрение своего проекта попробовали использовать ASP.NET и получили быстро работающий прототип, который превосходил по производительности имеющиеся наработки, после чего команду, что работала на JAVA увоилили в полном составе, а разработчики складского учета засучили рукава.

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

То есть, была одна общая команда.

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

Грустная история...

Кстати, а на чем складской учет делала одна из команды?

Попахивает избитой темой — «А давайте поработаем за интерес, вы же творческие люди, вам деньги ни к чеуму».

Можете кидать в меня табуретками но я всегда считал что языки не должны быть платформозависящими, и пока на ЯП нельзя нормально писать под большинство востребованных платформ этот язык для меня мертв. Поэтому поводу не люблю .NET платформу в целом.
Что касается JAVA, тот тут мне феншуй не позволяет ею пользоватся. И тут даже не так влияет сам язык, как его стиль и философия. На JAVA можно писать много хороших вещей, но почему то кроме гигантов таких как Google их мало кто делает. И большинство софта который есть на рынке откровенно страшен для любого кто с ним работает.

Я люблю:
Python — за его простоту и изящество
С/С++ - за его мощь
ASM — за его скорость

Вот такое у меня мнение на этот счет.

А мне:

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

ASM — никак. Ни скорость, ни творчество, просто язык «перевалочных» команд из регистра в регистр, быстро тупеешь.

Сейчас мы в компании заняты небольшим проектом с OCR и поверте если бы не работа с регитсрами напрямую время некоторых операций увеличилось бы настолько что они бы стали безсмысленными. АСМ нужен что бы решать очень узкие конкретные задачи, которые в 99,9% случаев не появляются.

С/С++ - это классика, прямо как Бах или Бетховен

Не знаю как насчет Бетховена и Баха в плюсах, но гадость какую-то написать то ASM-у равных нет. :)И какие же это важные случаи при которых 0,01% перевешивают 99,9% проектных, в бомбе регистр установить быстрее, чем сапер успеет ее отключить при помощи дебагера? :))

К примеру наложение шаблонов изображений, они делаются на регитсрах, а это куда как быстрее. + вынесение некоторых LAP задач(если возможно), тоже существенно снижает время на работу алгоритма.

Ничего, будет время когда регистры уйдут в прошлое.

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

Люди, как и другая Живая форма, повторяются во Времени. Материя — это игра Поля, и все в этом игре как «вспышки» в Пространстве и Времени, с постоянными повторами!

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

А вообще вы какуюто ахинею несете.

Не называйте «ахинеей» то чего не понимаете, во всяком случае не будете выглядеть «Шариковым».

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

Ну и Питон то какраз кроссплатформенный. Потому что высокоуровневый.

ДА нет.. именно языки. Для того что бы писать на Си или Асме под линем или виндой или еще чемто ничего не надо.. написал, скомпилил и работаешь. Отличия разумеется есть, но они привязаны не к языку а к самой системе что вполне нормально. Тобишь кросплатформенность в данном случае это результат работы именно программиста, а не какойто оболочки(как JVM или Mono). Именно об этом я говорю.
Питон кстате не кроссплатформенный сходу тоже. Код для винды и Линя будет разный.

Да нет, именно уровни.

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

Какая кроссплатформенность? (-:

Питон кстате не кроссплатформенный сходу тоже. Код для винды и Линя будет разный.

Можно об этом тоже подробнее — отчего это он будет разный?

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

Да нет, именно уровни.
Ну С#.NET более высокоуровневый чем C++ но С# на лине работает через раз, а C++ работает отлично.

"Я люблю:
Python — за его простоту и изящество

Это вы ещё лиспа не видели :)

По питону видно, что Гвидо хорошо знал/знает лиспы. А Guy Steele вообще очень активно в джаве поучаствовал :)

WUT? А можно по полочкам разложить что, где и как в питоне от лиспа(ов)? Можете взять например Scheme или CL и указать конкретные примеры.

Какая разница. Упоминание лиспа (утверждение о его крутости и не повторимости) в коментах увеличивает крутость поста на 10 поинтов (знаю, сам пользовалсо :) ).

Лучше чем Норвиг трудно сделать: norvig.com/...ython-lisp.html

По сути вся функциональщина (функции как first class objects, жаль closures неполноценные, но есть хак с пустым списком), repl, с оговорками duck typing.

Кроме того, как личное наблюдение, стиль отступов, типичный для лиспа, сильно напоминает питон, если поубирать скобки. Да и def — почти defun :)

То есть, язык в котором нету макр, в котором есть разделение на expression и statement, где всё есть обьект, где обрезанная лямбда, где для нормальной поддержки замыканий ввели ключевое слово nonlocal, где в конце-концов есть ключевые слова, так вот, этот язык вы называете почти лиспом? При всей моей фанатичной любви к питону, это ни в коем случае не лисп.

Я называю «почти лиспом»? Я утверждаю, что по питону видно, что Гвидо был в теме, когда придумывал. Вам не видно — ну и ладно, особенности ассоциативного мышления.

Простой пример, попросите Java разработчика и Python/PHP/Perl/Ruby разработчика за сколько они сделают простенький сайт вроде milliondollarhomepage.com а еще лучше попросите их сделать и запустить, сроки будут отличаться в разы.

Простите, но ничего кроме улыбки у меня это не вызывает. Потому как вышеупомянутые технологии может и позволяют начать быстрее но впоследствии с ростом проекта скорость сравнивается потому как она уже мало зависит от технологических ньюансов любой из данных технологий. Python/PHP/Perl/Ruby работают как ред-бул — приплыв энергии, затем её резкий спад, квадратная голова на утро а потом уже как все...

Есть даже шутка что PHP — это «PHP for Home Pages». И я отчасти с этим согласен потому как считаю что проект большой сложности на PHP может позволить только лишь очень богатый заказчик.

Мораль: если для вас самореализация и удовольствие от работы важнее лишних нескольких сотен $ в месяц ищите возможность писать на чем-то отличном от мейнстрима Java.

Кто хочет удовольствия то на той же JVM есть Scala, Groovy, Jython. Так что в данном случае можно совмещать высокую ЗП и удовольствие в работе :)

PHP — это «PHP for Home Pages».
Это не шутка, он изначально так расшифровывался.

Мы на ПХП написали CRM/ERP систему для УКРСИББАНКА, которая сделала все предлагаемые решения на JAVA обошлась в разы дешевле. Так что тут не язык, а руки важны.
К примеру тот же Фейсбук — это ПХП, да оптимизированный но все же ПХП. Те же социалки что я видел написанные на ЯВЕ валятся под 200рпс как нефиг делать(при всей их заявленной моще)

Проблема в том что вы хотите одним молотком и поле вспахать, и грибы посадить и гвоздь забить. Для кажой проблемы есть свое наиболие подходящее решение. Это всеравно что писать веб-приложение на АСМе.. можно конечно, но не выгодно. С другой стороны писать драйвер ядра на ПХП как то ну ваще не удобно. Вот в этом и соль.

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

У фейсбука насколько я знаю под капотом много С/С++, ну и однокласники на джава под 200 рпс не падают.

Давайте мы не будем рассуждать о том чего не видели. + как бы у них не один сервер.

Возьмите любое опенсорс или платное решение на базе ЯВА поставьте все на один сервак и протестируйте.
О том что на ЯВЕ очень очень геморно писать вещи о которых разработчики языка изначально не подумали думаю говорить не стоит.

Возьмите любое опенсорс или платное решение на базе ЯВА поставьте все на один сервак и протестируйте.

Дык вот жеж умные люди стараются, тестируют разные конфигурации: там куча вариантов когда на одном сервере достигается больше 1000 транзакций(транзакция — это действия пользователя сразу на нескольких страницах, типа выбрал товар, положил в корзину, купил). причем на многогигабайтных базах а не на уютных бложиках где все данные закешированы в РЭМ.: www.spec.org/...rprise2010.html

О том что на ЯВЕ очень очень геморно писать вещи о которых разработчики языка изначально не подумали думаю говорить не стоит.

Ну если ты внимательно читал тему, то мог бы увидеть что консенсуса по этому поводу не достигнуто.

А консенсуса и не надо. Это является фактом. Спросите любого девелопера.
На многогигабайтных базах? простите но такие базы уже в прошлом. Сейчас логи за неделю весят по несколько ГБ. Я когда в банке работал у нас базы были по несколько терабайт. И работало это на БД Teradata. И ниче никто не пугался(Это к тому что не стоит меня пытатся напугать цифрами)
Если люди не кеширую данные то это уже трабл в архитектуре.. ибо данные обрабатываемые в данное время должны максимально кешироваться.

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

ЯВА — это как огромный завод.. все работает покуда вы не решите поменять тех.процесс. Именно по этому большинство тяжелого софта пишется по старинке на С/С++ с ассемблерными вставками. Не говоря уже о программинге под железо.

Посему ЯВА, да это энтерпрайз, закостянелый и без инноваций.

А консенсуса и не надо. Это является фактом. Спросите любого девелопера.

Извини, а тут прдавцы хотдогово в этой ветке высказываются?

Сейчас логи за неделю весят по несколько ГБ

При том что логи и база это несколько разные вещи

Я когда в банке работал у нас базы были по несколько терабайт. И работало это на БД Teradata.

Терадата — это ОЛАП МПП, а социалки и системы по моей ссылке — это олтп. Хотел бы я посмотреть как терадата на многотеррабайтной базе будет отрабатывать по 1к запросов в секунду.

Если люди не кеширую данные то это уже трабл в архитектуре.. ибо данные обрабатываемые в данное время должны максимально кешироваться.

А кто сказал что не кешируют?

А все ентерпайз решения которые есть на рынке морально устарели лет на 10 это факт. Так как там важнее стабильность.. а полернуть баблом полы это не трабл.

Главное почаще писать что это факт

Возьмем к примеру Google, да они пишут на ЯВА... переписанном с нуля под чистую.

Инфа 100%?

ВА — это как огромный завод.. все работает покуда вы не решите поменять тех.процесс. Именно по этому большинство тяжелого софта пишется по старинке на С/С++ с ассемблерными вставками. Не говоря уже о программинге под железо.

Посему ЯВА, да это энтерпрайз, закостянелый и без инноваций.

Ты забыл добавить что это факт

Вот кстати чувак сам сделал игру, обрабатывает 300к хостов в сутки на одном сервере.

habrahabr.ru/...19329/#habracut

Java это высокий язык для железа.Можно и на assemblere писать трехмерные инженерные расчеты, но насколько есть смысл именно в таком решении задачи, когда на С++ это делать проще и быстрее с его операторами в языке?!

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

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

Сказки. И про ЗП тоже.

Прочитал комменты и ещё раз прошёлся по статье.

Только одному мне кажется, что статья специально написана в провокационном стиле, дабы вызвать холивар / наплыв людей?

Зная автора в реальной жизни, могу сказать, что неспециально, это такой стиль выражения мыслей — резкий и принципиальный. Естественно, отсутствие обтекающих фраз и излишняя эмоциональность выглядят как провокация со стороны. Ну и тема сама по себе флеймообразующая, как же не устроить срач на тему <ЯП 1> vs <ЯП 2>.

Провокационными выгдлядят отсутствие серьезной аргументации при притензиях на абсолютную правоту.

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

Про Python-гуру вообще молчу, там нормальные разработчики имеют не меньше 2k, дороже только разработка под iOS.

Про жёсткие рамки фреймворках Java — здесь вообще закрадываются подозрения о «6 годах работы Java программистом», простите, ничего личного. Как раз проблема Java (в отличие от того же .NET), что есть довольно гибкие спецификации и разнородные библиотеки, но нет нормального пайплайна, чтобы 80% тупых задач решать не изобретая колесо или не выбирая из десятка open-source библиотек. Sun нужно было раньше разрабатывать NetBeans с высокой степенью интеграции со стандартными и 3rd party популярными библиотеками.

Отчасти здесь уместна аналогия с Flash vs. Java Applet. Почему Macromedia Flash занял место под солнцем на долгие года? Потому что была удобная тулза (считай, IDE), могущая за несколько кликов сделать уже как бы творческий продукт.

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

как еще один аргумент в защиту джавы/дотнета...
если представить себе более-менее серьезный проект разработчиков так на 10.... то с использованием джавы я вполне представляю себе команду из 2х синьоров и 8и джун-ту-медиум девов.

Если это Руби/Питон то джедаев должно быть больше.... и это проблема, потому как джедаев мало, а питон-джедаев совсем мало...

Зато юнлинг много, которые незнанием и гордыней своей проект этот к завершению «логичному» приведут :)

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

Кстати джедаев надо примерно столько же и пару толковых учеников джедаев и будет таже эффективность, но ведь 10 человек можно продать дороже?

Когда аутсорсинг перейдет на фиксед прайс проекты тогда ситуация может измениться, но это врядли произойдет, это как CPM vs CPA в медийной рекламе, пложадки хотят денег за показы, а рекламодатели за результат :), пока на недоразвитых рынках побеждает CPM

Категорически не согласен с автором статьи. Буквально по всем пунктам. Итак:

Мало кто не согласится, что при одинаковой квалификации большинство задач на Ruby/Python/PHP реализовывается проще и изящнее чем на Java и как следствие продуктивность труда в Java индустрии ниже.

Извините, это бред. Ruby/Python/PHP и Java это инструменты, каждый хорош для решения своей задачи. Да, просто веб — сайт быстрее разработать на РHP, только java — ни разу не средство для разработки сайтов, это платформа для корпоративного программного обеспечения и разработки сервера(не путать с сайтами). Да, сайт — визитку гораздо быстрее сделать на PHP, но если вы разрабатываете скажем биллинговую систему, где веб — часть это только админка, тогда php не подходит совершенно.

И это не потому, что PHP плох, или Java хороша: каждое средство для своего. Вы же допускаете существование иголки с ниткой и навороченной швейной машины с ЧПУ. Понятно, чтоб пришить пуговицы на рубашке даже доставать из футляра машину не стоит, но если нужно сшить сто рубашек, да разных, да с минимальными трудозатратами, тут уже швейная машина нужна.

По поводу стоимости java — программистов, вы удивитесь но они стоят дороже банально потому, что порог входа выше. Т.е. чтоб студенту начать писать на PHP достаточно прочитать одну — две книги. А чтоб на java писать? Сколько лет проходит прежде, чем человека подпускают к разработке новых проектов? Вот поэтому зарплаты и таковы, а вовсе не потому, что начальство перестраховывается. Любой заказчик хочет платить как можно меньше, это закон. Банки используют джаву не потому, что денег не умеют считать(это их кусок хлеба вообще то) а потому, что это дешево. Ну нет смысла, нанять программистов на PHP, заплатить им меньше денег и не получить в итоге нужного!

в других технологиях намного больше творчества

Это, уж извините, полная ахинея. Вам привести список инструментального программного обеспечения написанного на java, web — серверов, p2p сетей, или сами погуглить можете?

Другое дело, что на Украине вообще мало инновационных проектов, но это на всех языках.

если для вас самореализация и удовольствие от работы важнее лишних нескольких сотен $ в месяц ищите возможность писать на чем-то отличном от мейнстрима Java.

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

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

Ещё раз: никто не будет выбирать дорогое и не эффективное при этом средство. Когда люди голосуют баблом, они очень внимательны в выборе.

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

Особенно если у человека семья, тут уж выбирается не «цаца» а штука, которая дает кусок хлеба с гарантией. Джава дает — про питон такого сказать пока не могу.

Особенно если у человека семья, тут уж выбирается не «цаца» а штука, которая дает кусок хлеба с гарантией.
Это и есть аксиома убогих стран. Принцип «подводной лодки», как с «Курском» — решила власть не поднимать лодку и люди умерли.

Аналогия с «курском» не уместна.

Поддерживаю. Программист он и в Африке программист. Языки и технологии — это всего лишь инструменты, с помощью которых программист решает поставленные задачи.

поддерживаю. главная ведь цели программиста — решить поставленную задачу, а не в творчестве

Глупость пишите. Ваше мнение означает «не нужно думать, нужно делать. Можешь своровать — воруй, но чтобы работа была сделана». Такие, как Вы, являются нормативными постулатниками воровства, разрешающие людям воровать ради своей выгоды.

Программирование — это и есть творчество. И не думать можно только воруя.

Какой неожиданный переход однако..

А как может еще быть воспринято мнение, что «программирование это не творчество»? Такое может сказать или человек, который никогда не писал программы по своему роду деятельности и видел как это делается (как пишут программы другие) со стороны, или человек который никогда не писал программы, потому что воровал уже все готовое.

Линию между творчеством и ремеслом лично я провести не могу, хочешь называйся творцом(senior, lead творцом), никто тебе не мешайся. Меня поразил переход к воровству в твоих рассуждениях.

Меня поразил переход к воровству в твоих рассуждениях.

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

А то хакерам не знать, что такое изощренные переходы «сначала я переломаю карандаш, а потом перекушу тебе горло», хацкер :)

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

Творчество, творческая работа это не такое уж плохое слово. Много художников пишут картины на заказ, тоже творчество, но качество такого заказного творчества отличается от картин, написанных в «свободе». Все, что сам создает человек это все творческая работа.

воровать не думая — опасно))

Воровать вообще опасно.

И дело здесь не в «не думая».

Угу... Иначе будет «Диез» сплошнячком))

Не знаю что такое «диез», просто по перспективам это не надежно.

Да, невольно вспоминается тест для детей — 1 в комнате, конфета на столе, терпеть 15 минут чтоб, получить вторую.

хотят тут немного подругому. конфеты сразу две — съешь обе — стошнить может =) (закон сработает)

В целом согласен, Java неэффективна с точки зрения времени разработки и количества кода — по сравнению с кучей других языков. Но с другой стороны — «бабло побеждает зло» :)

Главное не зацикливаться на яве. Работаешь с явой — дома учи .Net, работаешь с .Net — учи питон, с питоном — учи haskell (вместо указаных языков подставить свой вариант:) ).Где-то так.

Главное не зацикливаться на яве. Работаешь с явой — забудь .Net — учи Scala

Scala это конечно супер.

Но:

1. Развивается слишком активно — обновленная версия не скомпилит код на старой. Для продакшена это огромный минус.

2. Вы пробовали найти программиста на Java? попробуйте теперь найти такого же только со знаниями Scala. Естественно желательно что бы он не учил несколько месяцев новый язык, окружение и т.п.3. Недостаток IDE (хотя тут потихоньку исправляется ситуация)

ИМХО — Как вариант расширения кругозора хорошо, но в целом бесполезно.

P.S. Хотя да — чего это я — вариант супер для взгляда на программирование не только в стиле Java

В последнем опросе по языкам было
— 4 проекта на scala на full-time в Украине
— 40 c чем-то хобби проектов

Так что не скажу что бесполезно. [у нас сейчас scala — весьма довольны]

Я бы хобби проекты не рассматривал. Дай бог 0.1% из них вырастет во что-то. А потом они столкнуться с поиском довольно специфичных специалистов.

А по поводу фултайм проектов — это со стороны заказчика крайне смело :)

Причем не подумайте — в целом, я к Scala отношусь крайне положительно, считаю её Java 2.0. Только Java 2.0 pre-alpha.

Там сейчас scala бум — все смотрят на положительный опыи twitter и foursquare. Это точно next big thing. Друглое дело что в Украине будет как раз то, о чем Николай писал, только по отношеник к скала а не скрипт-языков (наши новые технологии провтыкают и будут только ошибкаи в J2EE монстрах фиксить, а все новое уйдет к азиатам)

Груви популярнее скалы: www.indeed.com/...groovy,scala&l= . Мой прогноз — джаве в 7-ке и 8-ке подтянут фичи, и она еще очень долго будет на коне.

Ну эт если в груви производительность подтянут,

там много тормозов не только связанных с реализацией динамических языков на JVM, но и связанных с самих груви СДК.

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

Повторюсь там еще проблемы с реализацией СДК (на джаве, на ЦПП — не в курсе). Например, раньше компиляция происходила, перед каждым (!) выполнением скрипта, мо уже пофиксили.

В любом случае, я думаю что джава останется мэйнстримом.

У нее же не крутой синтаксис, настоящие джедаи и ниндзя побрезгуют работать с таким не интересным языком :-D

(на джаве, на ЦПП — не в курсе).

groovy++ - тоже на jvm.

Прикольно, всегда думал, что это полноценный компилер в нативный код.

Если они таки выровняли производительность, то мо и стоит посмотреть, года 2 назад он был не вменяемым.

Scala предназначена для решения другого рода задач — многопоточности и масштабируемости приложения, тем самым позволяя забыть о такой головной боли как синхронизация и локи, в то время как Groovy — всего лишь sugar . Вы пытаетесь сопоставить несопоставимое ))

советую посмотреть видео от создателя — java.in.ua/...martin-odersky

А слайды есть? Презентация почти час все таки.

Добавил слайды. Cсылка та же — java.in.ua/...martin-odersky

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

Когда человек говорит только о минусах, то либо он не компетентен, либо он лукавит. Более того, все ваши аргументы о сложности поиска программистов, недостатках IDE и т.п. можно применить к Java вернувшись на 10 лет назад в прошлое. Параллели видите?

Теперь давайте пройдемся по вашим аргументам.

1: исходя из вашей логики — все, что стремительно развивается, зло для продакшина — не убедительно

2: вы пробовали найти программиста на Java десть лет тому назад? Нет? А почему их было так мало?

«В целом бесполезно» Аргументируйте, в каких частях целого Scala бесполезна? А так же расскажите, почему этот прогрессирующий и по вашему мнению бесполезный язык используют такие киты как LinkedIn, EDFT, Twitter, Novell, the Guardian, Xebia, Xerox, FourSquare, Sony, Siemens, Thatcham, OPower, GridGain, AppJet, Reaktor.

Я некомпетентный, лукавый и ленивый на доказательства своего ИМХО :) Особенно людям которые чужое мнение считают или некомпетентностью или лукавством :)

10 лет назад жаба решала задачи, которые никто не рашал (теже апплеты например), и поддерживалась крупной конторой (саном).

Теперь вопросы — чего такого умеет скала, чего нельзя зделать на жабе ?

Кем поддержуеться скала? Мартином одерски? Где есть гарантия что он не забьёт на нее через пол года, и она тупо не здохнет?

Вы пробовали найти программиста на Java? попробуйте теперь найти такого же только со знаниями Scala.

Выучить Скалу лично мне не составило большого труда. Довольно всё просто если раньше приходилось встречатся с Питоном и/или Перлом.

Синтаксис Скалы довольно прост и можно простые программы писать уже через пару дней. Сложность состоит в освоении тонкостей функциональных ЯП.

Так дело не в сложности. Дело в том что многие java программисты просто НЕ ХОТЯТ её учить. И в чемто они правы.

Изучение мейнстрим языков (java, .net, python) делает их более конкурентными на рынке. А изучение Scala ну добавит очков на собеседовании в 2-3-х компаниях и все.

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

+стопицот.

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

Мне казалось, только я не воспринимаю яву =).

Просто потому что энтерпрайз и комьюнити — от обоих тошнит. Такое ощущение, что каждый ява программист знает все 14 паттернов, а при фразе «питон компилируется» вытекает пена изо рта, ибо «ПИТОН РАЗВЕ НЕ СКРИПТОВЫЙ»?

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

Николай, принимаю вызов по поводу miliondollarhomepage.com

Вы на питоне под Линукс/Мак пишете?

Предлагаю такие условия:

— чистая исталяция Линукс/Мак

— цель: сайт в стиле miliondollarhomepage.com

— суть соревнования: у кого получится написать с нуля и запустить сайт быстрее

Не шучу. Буду в Киеве в пятницу <nobr>15-го</nobr> вечером. Как насчет выходных?

Требую живую трансляцию и запись в ХД! :)

пора нам какой-нить Хакатон ДОУ забацать.

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

А чем не подходит предложеная выше концепция?
Я так полагаю устав олимпийского хакатона от ДОУ никто не будет разрабатывать.
Поэтому изложу мое видение:
— приглашаем независимого оператора
— собираемся в воскресенье днем в кафе с wifi (на выбор)
— ставим чистую инсталяцию ОС по вкусу
— Макс объясняет суть соревнования и объявляет хакатон открытым
— пользоваться можно чем угодно кроме второго кодера
— кто первый показывает работающий сайт тот и выиграл
— вконце события: обсуждение, обмен опытом учасников, пиво/кофе

— выкладываем отснятый материал на youtube

Я помню fprog.ru конкурс в прошлом году проводил — на каком языке решить какую-то типичную задачу: www.fprog.ru/...stapov-contest
краткие выводы — особой корелляции между языком и местом нет. В призерах были решения на С#, VBA и Common Lisp-е. [На java правда никто не писал]

Джава это не язык программирования, а технологоческий комплекс, для создания солжных бизнес систем и это поясняет большие зарплаты. Приведу пример — когда-то большие вещи писали на PL/2 а считали все на Fortran, был мега язык АДА созданный пентагоном для военных целей. По сей день работают системы написанные на этом «старье». В один прекрасный день Джава присоединиться к списку старья, и придет новый мессия :-)
Вот только думаю языки типа PHP/Ruby/Python не находятся в списке кандидатов.
Тут дело не в скорости разработки, а надежности результата для систем со сложным взаимодействием (ну и поддержки).

А по поводу быстрого кодирования с нестандартными «умными» выбрыками — слышали термин -"write-only"?

ну многие «выбрыки» не write-only даже наоборот,
сравните

B = [x ** 5 for x in A]

с

B = new ArrayList<integer>();
for (Integer x:A) {
B.append(Math.pow(x, 5));

}

В первом случае несколько проще понять что происходит не так ли?

Т.е. жаба девелоперам доплачивают за синтаксис? :-)

В первом случае несколько проще понять что происходит не так ли?
Не правда, лично мне слово «pow» понятнее чем **.
Лично мне Приятно знать во время компиляции узнать что я возвожу в степень строку, а не интегер.
Какого типа будет B — какая именно реализация коллекции будет в питоновском варианте?

Не правда, лично мне слово «pow» понятнее чем **.

нет ну если такая жара пошла то в питоне есть альтернативаB = [math.pow(x, 5) for x in A]

Какого типа будет B — какая именно реализация коллекции будет в питоновском варианте

list будет, стандартной реализации

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

нет ну если такая жара пошла то в питоне есть альтернативаB = [math.pow(x, 5) for x in A]

А теперь от простой мат задачки вернемся к реальной жизни:
Как будет выглядеть код который бежит по списку А и по какому-то условию преобразует поле каждого элемента и записывает в список Б?

Ну или что-то в этом роде. Мои довольно ограниченные познания в питоне — книжка, пару системных скриптов и пару знакомых питонистов(надеюсь никого не оскорбил) — мне подсказывают что код будет не очень отличаться от джавовского, разве что типы не придется объявлять.

list будет, стандартной реализации

А если мне упадет кирпич на голову и я захочу кастомную реализацию, как изменится код, насколько я понимаю, он «утяжелиться».

Из того с чем я сталкивался:

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

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

А если мне упадет кирпич на голову и я захочу кастомную реализацию, как изменится код, насколько я понимаю, он «утяжелиться».

Вот верите, даже не знаю, ни разу не использовал другие листы в питоне, в 99.9% случаев это не нужно. И да питон плохо работает с большими массивами данных где это могло бы быть актуальным, для этого есть C/C++ и таже core Java но в меньшей степени.

Из того с чем я сталкивался:

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

Давайте все таки спорить о вкусе устриц с теми кто их ел, а не кому рассказывали коллеги. Вы удивитесь, но результат будет иным. Вот мнение по поводу сложности самого Брюса Эккеля stackoverflow.com/...nd-chunk-theory

Давайте все таки спорить о вкусе устриц с теми кто их ел, а не кому рассказывали коллеги.

Простите, но тратить 2-3 года своей жизни (поскольку все гуано лезет не в начале проекта, а после некоторого времени), что бы увидеть то что мне показали на своем примере другие и то что очевидно из теории, у меня нет желания.

цитату з «теорії» в студію?

Про отличая статической и динамической типизации рассказать?


static Result move(final User user, final Collection<long> ids, final Long newFolderId) {
	Folder folder = EntityManager.find(Folder.class, newFolderId);
for (Long id : ids) {
final Data data = EntityManager.find(Data.class, id);
data.setFolder(folder);
data.save();
}
return new Result(false, ids, Collections.<long>emptyList(), "");
}

А потом еще добавьте код который если происходит эксепшн сохраняет ид элемента в коллекцию и передает ее 3 параметр MovingResult, соответственно во втором параметре будут только удачно сохраненные.

P.S. Код может не компилитсо, так как изменены имена переменных и классов


static Result move(final User user, final Collection<long> ids, final Long newFolderId) {
	Folder folder = EntityManager.find(Folder.class, newFolderId);
for (Long id : ids) {
final Data data = EntityManager.find(Data.class, id);
data.setFolder(folder);
data.save();
}
return new Result(false, ids, Collections.<long>emptyList(), "");
}

А потом еще добавьте код который если происходит эксепшн сохраняет ид элемента в коллекцию и передает ее 3 параметр Result, соответственно во втором параметре будут только удачно сохраненные.

P.S. Код может не компилитсо, так как изменены имена переменных и классов

простите, вы всерьёз считаете, что написание дополнительных строк кода является помехой для создания хороших и успешных проектов?

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

Кстати зачем

final User user

она ж не используется?

она ж не используется?

Это пример 5-летнего кода, когда-то использовалось. Суть не в этом.

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

Напоминаю:

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

Напишите, пожалуйста, этот унылый (там кстати весь класс унылый, все руки никак не дойдут поправить) джава код на питоне, что бы он выглядел элегантно. Моя ставка что он существенно ничем отличатся не будет.

Напомню мой посыл:

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

Это ж говнoкод чуть более чем наполовину, на питоне так не напишешь :). Давайте что-то поэлегантнее что-ли.

— Слышал я вашего Шаляпина. Фальшивит, картавит, проглатывает окончания.
— А где вы его слышали?

— А мне вчера Рабинович по телефону напел.

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

Как будет выглядеть код который бежит по списку А и по какому-то условию прео��разует поле каждого элемента и записывает в список Б?

Не для холивара ради привожу пример на Питоне:

# Заполняем А числами от 0 до 99A = range(100)

# Cоздаем новый список, где все парные числа возводяться в квадратB = [ (i*i if i%2==0 else i) for i in A ]

У каждого языка есть свои сильные и слабые стороны. Не вижу причин с пеной у рта защищать питон: недостатки всегда найдуться. Тоже можно сказать и про Java. Своим задачам свои инструменты.

B = [ (i*i if i%2==0 else i) for i in A ]

Пока красиво. А завтра скажут что вместо целого надо использовать объект, и в «елсе» должно быть не i а еще какое-то преобразование. И с добавлением бредовых условий ваш код в одну строку станет все тяжелее и тяжелее,

гдубо говоря когда в форе больше 3-5 инструкций (строк или как это назвать) код существенно не отличается — это был основной посыл.

Кстати, лично мне оператор ?: более понятен чем питоновский if-else-в одну строку, типа если я перехожу по елсе, то меня не обязывают читать другую ветку,

может это просто привычка

Я согласен с тем, что «реальный» код на питоне тоже может выглядеть уродливо и в конце концов может оличаться от Java только лишь отсутсвием необходимости указывать типы на каждом шагу.

На нашем примере с изменением списка по условию, в случае более сложных условий можно будет вынести условное изменение (i*i if i%2==0 else i) в отдельную функцию (change_if_condition). Важно помнить, что язык и его возможности — лишь инструмент, который нужно применять где это имеет смысл. Конечно же засовывать непростую бизнес логику в выражение такого рода — более чем спорное решение.

По поводу ** правда, при первом прочтении не вкурил :-) пришлось джаву читатьНо я не имел в виду чисто код, скорее ваши архитектурные решения, которы сторонним людям могут быть трудны

Август, а в чем простота архитектурных решений джавы, в том что по ним написаны многокилограмовые талмуды (меня в свое время убил размер книги Hibernate in Action)? Я не спорю что найти 20 одинаково архитектурно мыслящих J2EE разработчиков проще чем 5 Python, но не факт кто выполнит задачу лучше. Но в первом бюджет/доход аутсорсера будет больше и многих это устраивает :)

Толмуды надо читать только в тех местах которые нужны. Хибернейт умеет много такого что я никогда не использовал и надеюсь не буду :-)
Но моя мысль в другом. Например прихожу я завтра в ваш проект, и начинаю долго и упорно понимать как оно работает, толмудов с тюрориалами у вас я думаю нет.
В джаве я могу изначально понять что примерно человек знает.
Дальше еще хуже — хочешь ты к корпоративной системе прикрутить распределенные транзакции, асинхронный обмен через очереди, всякие вебсервисы, портралы которые показываю чужой контент, голосовые сервисы...

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

За 3 года в питоне мы не столкнулись ни разу с проблемой отсутствия библиотек нужных нам, а проект у нас сложный, очереди, NoSQL и прочее есть, а вот например в Java из прошлого опыта невозможно работать с картинками, так как стандартные либы так плохо работают JPEG что это ужас и решали это через ImageMagic враппер который личил память и вообще был на порядок геморойней PIL который в питоне, казалось бы миллионы разработчиков, а никто не может написать либу для картинок нормальную.

Про распределенные транзакции это не очень пример, я немного знаю как это сделано в джаве, там все равно все зависит от базы с которой ты работаешь (нужен two faze commit для N-1 источников из N) и реализовать туже логику при необходимости можно в течении 10 мин на питоне под конкретную ситуацию, алгоритм там простой, просто джава это скрывает в конфигах а тут прийдется писать самому, но не факт что дольше чем хачить конфиги в яве да и понимания будет больше.

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

Пример картинки, который неосилит imageio в студию. А то я тут недавно заимплементил систему которая конвертит из jpeg & png в multipage tiff до 100к картинок в день большого разрешения, и работает как часы уже пол года.

реализовать туже логику при необходимости можно в течении 10 мин на питоне под конкретную ситуацию

Жду через десять минут реализацию two phase commit протокола для DB2 на питоне.

юноша, вы читать умеете?

если DB2 поддерживает two phase commit то это реализовано не в наших любимых Python/Java а в базе данныз, и это как правило есть в драйверах к базе который ни вы ни я не должен писать, так как это сделал давно вендор или другие добрые люди.

На основании этого можно строить распределенные транзакции в ЛЮБОМ языке программирования (при наличии поддержки драйвера которая как мы скзали зачастую не зависит от языка) если N-1 участников транзакции поддерживают двухфазный коммит, только вы этим гордитесь, так как это можно офигенно продать заказчику ПО как супер-дупер надежность его данных, а остальным это понятно по умолчанию.

юноша, вы читать умеете?

Любишь задавать глупые вопросы?

а основании этого можно строить распределенные транзакции в ЛЮБОМ языке программирования (при наличии поддержки драйвера которая как мы скзали зачастую не зависит от языка)

В языке и/или платформе нужен менеджер распределенных транзакций, который очень желательно что бы поддерживал например автодетект дедлоков, как это сделано в большинстве jee app servers, конечно все это можно навелосипедь самому, но за 10 мин. думаю не управишься.

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

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

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

В твоем примере существенны только лямбды, которые в джаве скоро появятся, с ними пример вполне можно записать как: Array<integer> B = m({int a => pow(a, 5)}, A);, динамическая типизация тут не причем.

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

Мне проще второй случай)

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

var B = A.Select( x => Math.pow(x, 5));

Символов ненамного больше)

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

Python-розробникам в java не подобається те, що java не схожа на python.
Java-розробникам в python не подобається те, що python не схожий на java.
Хто б міг подумати! :)

Цікаво, як багато тут інженерів, котрі користуються технологіями відповідно до поставленої задачі та критеріїв пов’язаних з її розв’язанням?

Неправда, лучше! На питоне или рельсах есть аналог gwt?

А ты подумай.

Я свалил писать на GWT с приличным опытом в PHP/Javascript,
так вот хочу сказать, спустя полтора года работы
а) На действительно больших проектах которым является наш — ява конечно принесла бенефиты (но сразу я очень сильно плевался на строгую типизацию, отсутствие лямбда функций, и вообще на весь типичный явский overhead)

б) Для написания интерфейсов, работающих в браузере — GWT как тулкит, и ява как язык, на мой личный взгляд подходят не сильно --- т.к. во-первых, все отличные готовые виджеты, верстка и дефолтная стилизация которая идет из коробки — скорей всего выбросится, т.к. ваш заказчик захочет совершенно отличного дизайна, а во-вторых, вы работаете в браузере а это DOM / XPath — а не виджеты(которыми, кстати если увлекаться — можно плохо кончить в виде супер-тормознутого интерфейса)

Все это опять же подтверждает точку зрения уже высказанную где-то выше о том, что Ява — это в первую очередь не язык, а бутерброд различных технологий заточенных под разные задачи. На нашем проекте это замечательно подтвердили два разработчика с J2EE опытом которые наколбасили такой «трушный» ява код, который еле ворочался в браузере после компиляции

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

Так что приводить тут GWT как плюс Явы перед Питоном, несколько некорректно

p.s. Кстати, а сервер-сайд у нас на питоне =)

Так что приводить тут GWT как плюс Явы перед Питоном, несколько некорректно

Из твоего плохо структурированного потока мыслей я если честно не понял почему не корректно. Потому что у вас двое неумех налабали тормозной интерфейс? А у нас интерфейс вполне летает. У вас неполучилось сверстать? А у нас получилось.
И у гугла все с адвордс и блогером получается.

Извини, но типичный вброс у тебя вышел.

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

Моя мысль(подтвержденная собственным опытом) следующая:

что Ява — это в первую очередь не язык, а бутерброд различных технологий заточенных под разные задачи.

p.s. Да, к сведению — у нас тоже все замечательно получилось и сверстать и «летать» :)

ты, я смотрю, отличился больше всех.

Ответь за слова, покажи парочку моих вбросов.

Моя мысль(подтвержденная собственным опытом) следующая:

что Ява — это в первую очередь не язык, а бутерброд различных технологий заточенных под разные задачи.

Как это относится к некорректности рассмотрения гвт как плюса джавы?

На нашем проекте это замечательно подтвердили два разработчика с J2EE опытом которые наколбасили такой «трушный» ява код, который еле ворочался в браузере после компиляции

:))) наверно скоро его переименуют в Try Java :))))

В итоге мы пришли к использованию того же jQuery

А в Вашем случае получилось:

try {
Java
} catch (Ёпрст ё) {
System.out.print(ё.*^$*&^&%);
} finally {
jQuery;

}

:))))

=)
Просто в случае GWT во время писания на Ява, следуюет никогда не забывать что это превратится в яваскрипт ) И кстати, с try / catch — все не так просто, он может не отработать как ожидается в каком-нибуть IE...

А про веселые баги когда в dev-режиме (тру-ява) — все работает, а после компиляции в браузере все валится я вообще молчу...

ИМХО программисты делятся на гениальных, хороших, средних, и никаких. А уже потом по языкам и технологиям. Поэтому набирать программистов исключительно с разбивкой по языкам и технологиям — слишком тупо, хоть и проще (Как и разбивать статистику з/п на DOU). Меня как труженника украинского аутсорса сей факт регулярно огорчает. Почему-то большие (Facebook, Google) делают немного не так. Возможно потому, что в украинском аутсорсе зачастую люди меняют место работы раз в пару лет.

ИМХО продвинутому джависту соответствует спец, который может знать питон, С, С++, еще какие-то языки, желательно чуть-чуть функциональщины, хорошо понимать как работает компьютер за пределами интерпретатора. Ну и общее, актуальное и для джавистов: базы данных, алгоритмы, если веб, то понимать HTTP и фронтенд etc.

Поэтому если сравнивать java vs. python в чистом виде по зарплате, то очевидно, что за больший learning curve платят больше.

Хорошие знакомые питонисты знают кроме питона много всего. Джависты тоже, но это не так выражено, для них все, что за пределами JVM — в тягость :)

знакомые питонисты знают кроме питона много всего. Джависты тоже, но это не так выражено, для них все, что за пределами JVM — в тягость :)

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

поверьте на слово- в Джаве есть где утонуть и без питона.

поверьте на слово- в Джаве есть где утонуть и без питона.
Я именно об этом. Вне JVM жизни нет.
= Вне JVM жизни нет =
отнюдь.
джависту много чего надо кроме JVM.

Джава с фреймворками — лишь половина примерно.

Эти утверждения довольно справедливы для веб-стартапов, где очень важен быстрый старт и быстрое развитие на начальной стадии, а вопросы производительности и управляемости проектов становятся актуальными только когда сайт вырастает. Где коммиты делаются по несколько раз в день, новый фитчи появляются в течение дня, а деплоимент не требует больше чем 1-2 минут без остановки работы самого сайта.

В момент когда проект вырастает до 5-10 программистов джава была бы уже куда более интересна чем php, python, RoR, etc, но до этого вырастают далеко не все проекты.

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

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

Да, конечно, деплои — это и имеется ввиду.

И? Ты думаешь на жабе нельзя делать деплоймент без остановки системы? Или может ты думаешь что питон производительней?

А чего ты вообще к дискасу прицепился? Там питон играет очень маленькую роль, логика может быть написана на любом языке, основные фишки, это правильно с масштабировать БД, менеджить сколько там у них серверов, настроить лоад балансинг, спроэктировать сеть, а питоновская часть там вполне заурядна, и я не верю что очень сложна.

Где в данной ветке возникло слово фронтэнд? И как это отменяет факт что дискус работает на 500 млн пользователях не благодаря питону?

Никто не говорит, что не бывает исключений из правил или что утверждление справедливо в 100% случаев. Вообщем-то не настолько важен сам язык, как мотивация и уровень программиста. Костылей наделать можно одинаково много на джаве и на питоне, руби и т.п.

Вот некоторые видимые мне недостатки питона:
* Нет нормальной ide — большинство моих знакомых питон программистов програмят в виме и прочих нотепадах с подсветкой синтаксиса, существующие питон ide недостаточно стабильные и/или функциональные
* питоновский дебагер от эклипса так же далек как gdb от висуал студии
* рефакторинг — мне в джаве нужно одно нажатие мышкой что бы переименовать метод, или перенести клас в другой пакет, даже если он используется в 650-и местах, а вам в питоне?
* динамическая типизация — как прекрасный шанс положить систему в продакшне
* производительность

* чехарда с несовместимыми версиями: когда вы там собираетесь мигрировать на питон 3? Когда питон 4 появится?

Если человеку удобно работать в vim’е, то это его выбор, на производительности и профессионализме это не сказывается. Впрочем IDE есть и в целом они давно имеют те функции которых якобы не хватает, посмотрите панель на последнем PyCon’е.

Скорее вопрос почему приходится заниматься переименовыванием методов? Сразу не хватило фантазии? Или вам код генераторы создают тонны хлама которые потом приходится разбирать годами?

Динамическая типизация вообще никогда не была проблемой ни для чего. Всегда боялся когда же случится проблема, но так за 10 раз ее ни разу и не встретил, может она надуманная?

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

Проблемы с версиями такой же мифический зверь как и единороги. Язык развивается, сообщество постепенно мигрирует, актуальные проекты меняются постепенно. Жизнь продолжается, паники ни у кого нет.

Ответ больше похож на чистый холивар. :) Особенно по поводу переименования методов. Фантазия не причем. Изменилась суть метода. Если работать по TDD или хотя бы покрывать код тестами достойно, то проблема динамических языков вообще не проявляется. Скорость — вообще понятие специфическое. Ее можно измерять только на похожих задачах, да и то с учетом особенностей платформы.

Холивар — это когда у сторон есть аргументы. А когда у одной ник со словом хакер, то уже ничего кроме фейла получиться не может :)

У меня есть аргументы, а вот качество твоих именно и порождает флейм.

Производительность программ на Python сопоставима с программами на C
А можно хоть немного фактов?
скорость разработки в разы выше.
А скорость добавления нового функционала в 10-летний проект?
Скорее вопрос почему приходится заниматься переименовыванием методов? Сразу не хватило фантазии? Или вам код генераторы создают тонны хлама которые потом приходится разбирать годами?
То есть питонисты код никогда не рефакторят под действием изменившихся требований к функционалу?
Динамическая типизация вообще никогда не была проблемой ни для чего. Всегда боялся когда же случится проблема, но так за 10 раз ее ни разу и не встретил, может она надуманная?
Как я уже сказал у вас видимо проекты мелкие, логика простая и народу мало. Или вы тратите много усилий на абсолютное покрытие всего юнит тестами.
Производительность программ на Python сопоставима с программами на C, мнимая тормознутость это мем десятилетней давности, скорость разработки в разы выше.
Это вообще эпик фейл, смотрим и просвещаемся:shootout.alioth.debian.org/...thon3&lang2=gcc среднее отставание — в 30 раз.
Проблемы с версиями такой же мифический зверь как и единороги. Язык развивается, сообщество постепенно мигрирует, актуальные проекты меняются постепенно. Жизнь продолжается, паники ни у кого нет.
Какн я уже говорил, джавистам не нужно вкладывать сотни человеколет для миграции кучи существующего кода на новую версию, потому что создатели неосилили обеспечить обратную совместимость. Если это не плюс для тебя, то у меня для тебя плохие новости о твоей профпригодности. Хотя перечитав твой пост о производительности пистона, у меня и так для тебя есть плохие новости о твоей профпригодности.
— перегрузку операторов
Scala в помощ
— множественное наследование
Интерфейсы. По плюсовому множественному наследованию еще никто ниразу не скучал — нафиг-нафиг.
— лямбда-функции
— замыкания
Вы бы еще в плюсах просили замыкания (-;
— опциональные аргументы (function test(a, b=0), test(5))
— именованные аргументы (test(a=5, b=6))
Синтаксический сахар. Опциональные аргументы можно делать через overload.
— комплексные числа
Есть библиотек полно.
— ограничивает ООП стилем
Вот это, ИМХО, и есть вся дискуссия. Мне кажется тут спор ООП против лямбды/замыканий/ФП-штучек, строгое типизирование против нестрогого и т.п.
В большинстве случаев не нужно в вебе
Удачи в переименовании метода который используется в 500 файлах :)
вывод типов (ага, в 2011 году)
Ага, но это плюс, поскольку проще контролировать типы на этапе написания кода
перегрузку операторов
Как мне этого не хватало после плюсов, но в джаве для этого есть интерфейсы
множественное наследование
Не нужно. Если очень хочется, то легко решается через интерфейсы и делегировании. Кстати — этот способ более прозрачен чем множественное наследование
лямбда-функции
— замыкания
Реализованы через анонимные классы, хотя и с рядом ограничений. Не функциональному языку особо не нужны, поскольку часто ухудшают дизайн (архитектуру) кода
опциональные аргументы (function test(a, b=0), test(5))
— именованные аргументы (test(a=5, b=6))
Ухудшают дизайн кода, хотя иногда удобно. Легко обходится мапой, хотя єто и не полноценное решение
unsigned числа
Не нужны
кортежи
Обходятся созданием промежуточного объекта — это более прозрачный и контролируемый подход
комплексные числа
Как и в питоне — это всего лишь класс, просто надо подключить либу.
Кстати, вы часто их используете, например для веб-проектов ;)
ограничивает ООП стилем
И это плохо? Ах да без функционального программирования жить нельзя.
Средства generic программирования не полны по Тьюрингу
Вы хоть понимаете что это значит и зачем оно нужно? Кстати, если вы такое написали, то немного не понимаете зачем эти дженерики нужны.

P.S А generic и питоне полны по Тьюрингу?

Как язык, си-шарп богаче Java. Как платформа — беднее, много более «проприетарнее», с замыканием на одну OS (mono не в счёт — неполноценная вещь, которую никто ни в какой продакшн не поставит).

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

Дженерики в джаве и шарпе — это принципиально разные конструкции, почитайте, кстати, а в шарпе они полны по Тьюрингу?

Не нужны. Не нужны. Не нужны. Не нужны.

Субъективно.

Приведите пример когда они нужны в контексте джавы (ну или хоть питона)

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

А у меня в Джава проекте идентификатор энтити под названием Репорт (репорт.гетИд()) используется более чем 250 местах (где-то 100-200 файлов) + 60 тестов

Да, в сишарпе они полны.

А можно посмотреть на доказательство.

Никогда не мог представить как это «дико извиняюсь...» это Вы забежали в шкуре убитого животного, с дубиной в руке, с обвисающими руками, в полу-согнувшись и «я дико извиняюсь...» ... и таким же «галопом», покинул студию/кабинет/аудиторию.

Доказательства тут

Вы уверены что поняли разницу в назначении дженериков джавы, дженериков шарпа и плюсовых шаблонов?

Раз мы разобрались с полнотой, то еще пара вопросов:

В каком-нибудь C# uint соответствует такому же типу в mysql. В джаве прийдется создавать <nobr>64-битный</nobr> int.

Если ваши числа таковы что находятся в диапазоне от 2^31 до (2^32 — 1) не логичнее ли использовать 64-битное целое что бы избежать переполнения?
Беззнаковые числа нужны, только чтобы более удобно мапить биты, а это довольно редкая... специфическая ситуация.

Кстати, как обстоят дела с такими числами в Питоне?

Множественное наследование (пример высосан из пальца): создаем mixin-ы ComparableMixin, которая содержит реализацию сравнения одного класса с другим и IterableMixin которая содержит реализацию итерации по экземпляру класса.

Вопрос: почему нельзя реализовать ваш пример через делегирование и реализацию интерфейса (если его необходимо сохранить)


Можно. Наследование опять же сохраняет довольно много времени.

Извечный вопрос: Если метод есть в обоих предках, а в наследнике не переопределен, какой вызовется?

Как вы сами сказали, есть специфичные ситуации, где резоннее было бы использовать unsigned числа. РСУБД — пример.

РСУБД — пример, только если вы ее реализуете ... на питоне.
Переведу с моего языка на общепонятный:

«Специфический» — тот который встречается крайне редко, при реализации какой-то очень утилитной мути.

>>> a = 1000
>>> type(a)
<class ’int’="">
>>> a = pow(2, 130)
>>> type(a)
<class ’int’="">
>>> a

1361129467683753853853498429727072845824

А теперь давайте поговорим о том зачем нужны не безразмерные типы (ну там о потреблении памяти и скорости работы)

А зачем на питоне писать базу данных?

Ну тогда и не надо беззнаковые числа :)

Для этого достаточно знать method resolution order. Его же можно в консоли легко посмотреть

Нятно, а теперь ситуация:
1)поменялся порядок программа поламалась ибо ведет себя по другому
2) Был переопределенный метод, это потерли (вы работаете без иде, поэтому вы не получили ворнинг)

Результат в РАНТАЙМЕ ошибка, не при компиляции, а в рантайме, и если вам не повезло то не на тестовой площадке, а на продакшене.

Внимание вопрос:

Нах мне (или другому разработчику) такое счастье?

А теперь поднимитесь к исходному посту и подумайте:
Являются ли перечисленные вами примеры недостатками или скорее бомбой замедленного действия которую подорвет «гениальный выпускник аграрной академии» придя к вам на проект?

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

P.S. Мне тут предстоит сделать небольшой проектик с неопределенными сроками, соответственно в выборе технологий абсолютно не ограничен.

Поэтому очень жду Вашу, Павел, статью о преимуществах питона (это НЕ стеб).

Такие ошибки отлавливаются тестами.

Расскажите нам о том как вы покрыли 100% кода тестами :)

Должен вас уверить — веб-разработка с таким выводом ошибок ничуть не хуже IDE-like.

Не понял, тестирование в продакшене?

«Гениальные выпускники аграрной академии» у нас, например, отсеиваются при собеседованиях.

Вау мир питонистов крут! Я уже хочу туда.
— 100% покрытия кода,
— нет надобности в дорогих и тяжелых ИДЕ, можно править десятки тысяч файлов в виме

— все ситхи отсеиваются на собеседованиях, а в конторах работают только мастера-джедаи и самые одаренные падаваны

Если скажете что у вас есть печеньки я точно с вами!

Еще раз напоминаю про статью, бо пока я склоняюсь к скале и лифту

Ви ще скажіть, що джава захищає від «геніального випускника аграрної академії». І в коді на джаві мало буває помилок помітних лише після запуску (тестів чи самої програми).
Це все не аргументація стосовно використання тієї чи іншої мови/платформи, а виключно підтвердження того, що «на вкус и цвет все фломастеры разные.»

Об’єктивні критерії можуть з’явитися лише тоді, коли перед конкретною людиною повстає певна задача.

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

так это единственная причина по котороый вы с ней работаете?

Хахаха.

Есть такое понятие «вероятность».

Тобто джава існує для того, щоб недалеким розробникам було з чим працювати?

Крім того, як на мене, цей захист від дурнів — ілюзія. Як казав Ньютон: «I can calculate the motion of heavenly bodies but not the madness of people.»

Доказательства тут goo.gl/i4YJ6

И где там доказательство? Там просто постулировано что полны, и все тут. Я уж не говорю о том что современные прогараммы вполне ушли за рамки тьюринг полноты.

Мажорные версии появляются примерно раз в десять лет. Не вижу проблем.Тем более мажорные версии и ориентированы на переделку каких-то основных частей языка.
Проблема не в том что они появляются, проблема в том что они сильно несовместимы взад, вот поэтому все хорошие начинания пистона 3 будут еще долго недостижимы армии программистов которые имели несчастье выбрать пистон платформой. С джавой таких проблем никогда не было бы.
В большинстве случаев не нужно в вебе
Ide нормально повышают производительность, особенно при рефакторинге или изучении сложного кода, спорить с этим могут только упоротые фанатики, или школьники которые с ide не работали.
Не поддерживает:
Большинство из предложенного было убрано, что бы минимизировать возможность школьников и прочих индусов писать write only код, некоторые фишки полезны согласем, но они постепенно добавляются.

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

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

Тебе не интересно какого типа твои переменные? Тогда это многое обьясняет.

Тебе не нужно, а многим нужно. А каждый раз смотреть в консоли(на поднятом проекте?) у тебя будет занимать в 10 раз больше времени чем у джава програмиста.

Что передергиваю? Мой тезис: в джава ide можно подсвечивать тип переменной, и это круто. Ответ: а мне это не нужно. Резонный вопрос: тебе не нужно знать какой тип переменной?

Такие странные ситуации возникают когда фанатики технологии не могут признать очевидные ее недостатки, и выдумывают странные отмазки.

тебе не нужно знать какой тип переменной

та ні не треба.. я пишу програму і знаю що туди попаде або стрічка або нулл

Ide нормально повышают производительность, особенно при рефакторинге или изучении сложного кода

ви звичайно будете шоковані і вас потягне заперечувати наступне твердження але раджу подумати ще раз і обєктивно: наявніть тулзів для рефакторингу і тулзів що покращують розуміння складного і заплутаного коду може свідчити про часту потребу в рефакторінгах і розумінні складного і заплутаного коду що в свою чергу може свідчити про «в середньому» частішу наявність такого коду там де ці тулзи існують

погодьтеся якби проблеми не існувало — ніхто б не тратив людиногодини на розробку такого досить складного софта

а ні не треба.. я пишу програму і знаю що туди попаде або стрічка або нулл

Если ты единственный программист на проекте, и тебе никогда не нужно иследовать код твоих колег, то к тебе конкретно вопросов больше нету. Но представь себе, далеко не весь мир устроен так просто.

ви звичайно будете шоковані і вас потягне заперечувати наступне твердження але раджу подумати ще раз і обєктивно бла ла бла

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

ну от я ж просив подумати ще раз і обєктивно =)

були б раді чи ні це в вже зовсім інше питання

Если ты единственный программист на проекте

та ні не один але як би дивно це для вас не звучало — баги що стосуются динамічної типізації доводится фіксити надзвичайно рідко

2? ;-)

Если у тебя есть метод: def a(b): который написал другой программист, откуда ты знаешь что он ожидал что бы туда приходило? Строка, число, кортеж или класс какой?

кожен метод має призначення і так вже заведено в рубі програмістів не називати методи *а* і змінні *б*

також в рубі заведено писати більше менших методів з метою покращення читабельності і життя майбутнім мейнтейнерам

повірте в кожному мому методі навіть ви не маючи досвіду програмування в рубі будете знати що очікуєтся на вході і що буде на виході =)

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

ви без сумніву праві я тільки хочу додати що світ не ідеальний нерівномірно і з мого власного досвіду саме в рельсах такої неідеальності менше

імхо

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

Цікаво, як живуть усі ті нещасні програмісти, що пишуть динамічними мовами. Видно досі ніхто з них не знає з якими даними працюють використані ними методи.

Ви розумієте про що ви говорите? Статична типізація — не панацея. Вона не завжди необхідна.

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

Релігія? Дійсно кумедна дискусія. Якщо ви не помітили, я, серед іншого, джавою пишу. Навіть так: у більшості випадків для мене це одна із основних мов.

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

Вобще тема конечно холиварная, но лично я согласен с автором. Именно по описанным в статье причинам я сейчас покидаю текущее место работы (разработка на Java EE).

Народ, джависты, а почему программисту на Питоне стоит попробовать Яву? Можно хотя бы несколько пунктов?

1. Чтоб не изобретать «велосипеды»
Джава очень богатая платформа. Есть куча высококачественных опенсорсных проектов, подглянув в код которых даже мельком можно нередко просветится по поводу всяких best practices.
Правда это не для тех кто «чукча не читатель, чукча писатель» и видит повсюду lurkmore.ru/...ьный_недостаток (-;
2. Чтоб попробовать «более чистый» ООП
и все связанные с ним вещи — паттерны, dependency injection контейнеры, etc.

3. Чтоб ощутить радости статической типизации (-:

Чувствуется, что на питоне вы не писали:
1. Точно такая же ситуация и в питоне, посетите pypi разок. Такие проекты как Django, SQLAlchemy, Shapely, Twisted и т.п.
2. Чистый ООП? Это что вообще такое? Большинство паттернов созданы, чтобы обойти искуственно созданные преграды — norvig.com/...esign-patterns и www.paulgraham.com/icad.html
3. Их можно и в массе других языков ощутить. Какой-то очень странный довод.

1. Готов поспорить, что на Java всего больше чем на Питоне. Что, конечно же, не мешает черпать мудрость из Питоновских проектов, но некоторые велосипеды, возможно прийдётся таки переизобрести, или пользовать binding для C-шных/плюсовых имплементаций.

Пример — Apache Lucene, написан на Java, Xapian — написан на C++.

3. Можно и в других. Можно и в Java. Это не довод, это повод (-:

Если вы пишете просто веб-порталы, которые не нуждаются в сложных протоколах взаимодействия между компонентами, серьезной масштабируемости, гибкой интеграции с внешними сервисами и прочих глупостях, то и не надо вам ее пробовать. Пишите спокойно на Питоне. Вы же умеете на нем делать свою работу. Зачем тратить время попусту.

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

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

Не силен в Питоне, поэтому не буду утверждать, что в нем такое не разработать. При таких желаниях добро пожаловать в Java! :)

В мире Java на тему «один комнонент на десктопе и на сайте» есть, пожалуй, только Oracle ADF. Но я бы не рекомендовал с ним связываться (-;

А где такое есть вообще?

Гм, подозреваю, что нигде :)

В области компонентов, умеющих себя рендерить как для веба, так и для десктопа, я знаю только одну технологию, точнее пару — Eclipse RAP и Eclipse RCP. Но Eclipse RAP-таки лезет на сервер за каждым обновлением. На медленных линиях связи это очень неудобно. Это вообще довольно сложная и интересная тема. Например, в случае десктопного клиента и сервера на одной и той же машине вполне достаточно какого-то простого протокола обмена данными. В случае веба возникает необходимость использовать трансляцию Питона или Явы в Javascript, плюс пускать обмен данными между клиентом и сервером через WebSocket либо хотя бы организовывать long polling.

На тему многопоточности и компонентов я бы упомянул такую штуку, как circuits. В мире Явы, к сожалению, аналогов не знаю.

Но вопрос больше из разряда: «Почему я должен есть яблоки, а не бананы?». Ответ зависит от целей.

Автор приводит пример с

milliondollarhomepage.com

.

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

Холивары никогда не потеряют своей актуальности :)

Решил и я поделиться своим мнением. К сожалению, большая часть подобных обсуждений затрагивает Java. Причем, обычно в примерах сравниваются колбаса и яблоки. Java отлично выполняет те обязательства, которые на нее возложены — кроссплатформенной среды разработки. На Java можно писать как веб-приложения, так и полностью серверные решения. Наличие огромного количества инструментов и библиотек позволяют делать серьезные масштабируемые приложения и простенькие сайты достаточно легко. Для этого нужно знать и уметь правильно пользоваться платформой Java. Lucene/Solr/ElasticSearch позволяют легко реализовать поисковый движок, JMS отлично справляется с асинхронной коммуникацией и балансировкой нагрузки, Jersey/Spring MVC дают возможность легко реализовать REST сервисы, EJB решают проблему масштабируемости уровня бизнес-сервисов. Этот список можно продолжать очень долго.

Теперь коснемся вопроса производительности. Кто-то в комментариях правильно заметил, что тут речь о производительности в реализации решения, а не скорости набора кода. Современные IDE как Intellij IDEA (да простят меня почитатели Eclipse, NetBeans и прочих) позволяют практически не тратить времени на набор кода. Во многом они обязаны этим статической типизации в Java. Интеллектуальные подсказки и многочисленные генераторы кода позволяют сосредоточиться на решении задачи и забыть об отнюдь не идеальном синтаксисе Java. Добавив сюда отличные средства для работы с модульным тестированием, мы получаем отличную среду разработки.

По поводу веб-проектов на Java. Лет 5 назад это действительно была проблема. Потому что приходилось писать достаточно много кода для создания простенького проекта из нескольких страничек. На данный момент ситуация сильно отличается. Хотите сгенерировать большую часть кода и вообще ничего не писать для CRUD приложений? Пожалуйста — пользуйтесь GRails или Spring Roo. Хотите иметь как можно меньшую привязку к Java? Используйте Spring MVC с Freemarker. Хотите писать все на Java и не заморачиваться на JavaScript? Выбирайте GWT. И это мы даже не начинали говорить об инструментах наподобие ZK, Vaadin, Echo и прочих. Хотите сделать «чисто» AJAX-приложение, полностью безопасное и устойчивое к атакам? DWR вам в руки! Огромный выбор инструментов позволяет подобрать оптимальное решение для каждого проекта, исходя их его ресурсов и требований.

Теперь по поводу интересности работы. Мне кажется интересность заключается не в синтаксисе языка, а в доменной модели приложения, инженерных практиках, которые позволяют избежать отвратительного качества кода и вместо правки багов заниматься разработкой новой функциональности. Также это интересные архитектурные решения и проектирование дизайна приложения, разработка бизнес логики и интеграция с интересными внешними сервисами. И делать это на Java, Groovy, Python или PHP — это лишь дело вкуса и умения.

И пару слов по поводу зарплат. Отличие далеко не в пару сотен долларов, как верно подметили товарищи в предыдущих комментариях. Для пущей убедительности взгляните на все доступные вам статистики зарплат. А стартапов полно и на Java, причем в которых разрабатываются очень прогрессивные и востребованные идеи. А удовольствие от работы получают не от языка, а от компании, команды и проекта.

Закончить хотел на позитивной ноте. В последнее время видел несколько проектов, которые переходят на Java с Ruby on Rails. И это даже не беря в расчет Twitter (engineering.twitter.com/...itecture.html) Появление и продвижение Scala открывает новые возможности перед Java программистами. Развитие Android делает их еще более востребованными на мобильном рынке (который давно ушел от J2ME). Я на 100% уверен, что Java не умрет, а просто плавно перейдет на новый виток развития. Держитесь!

P.S. Всех джавистов приглашаем на конференцию JEEConf (jeeconf.com).

Кумедна полеміка виходить.
Хотів лише нагадати, на випадок, якщо хто забув, що творчість не відміняли.
Хто хоче творити, а не «робити як вони», буде керуватися своїми відчуттями (і певними об’єктивними критеріями) обираючи інструменти. З часом переглядяти свій вибір, якщо потрібно.

Для мене очевидне одне, не можу не погодитися в цьому з автором: зациклюватися на одній єдиній технології — потенційно небезпечно.

Для мене очевидне одне, не можу не погодитися в цьому з автором: зациклюватися на одній єдиній технології — потенційно небезпечно.

Это справедливо для технологий с узкой нишей, например питона(несложная веб логика, скриптование и мат. расчеты для экстремалов), но джава намного многограннее, и оставаясь на ней можно и веб девелопить(для чего есть тоже куча диаметрально противоположных по идеологии подходов на любой вкус: gwt, jsf, mvc frameworks), и распределеные базы данных ваять, и апликухи для мобилок, и десктопные приложения, и для облаков писать.

Ниша любой технологии априори узкая (по большому счету) ибо во время ее проектирования не знают будущего. Естественно, в будущем ее стараются использовать по максимуму, потому что уже взялись. Убирают то, что вообще никуда не годится, переделывают, что еще хоть куда-то, добавляют нехватающие детали. Но рано или поздно появляются задачи с которыми определенной технологии как минимум очень тяжело справиться. И со временем таких вещей становится все больше.
Я не говорю, что джава отжила свое, еще нет. Но не знать куда развиваются пусть даже «вражеские» технологии чревато отсталостью.

Но не знать куда развиваются пусть даже «вражеские» технологии чревато отсталостью

Так ведь знают — есть же Groovy/Scala для любителей «снова модного» функционального программирования и нестрогой типизации.

>Groovy/Scala
>нестрогой типизации

поделил на 0

Вроде бы я не об этом. Я не работал с Groovy/Scala, но почему-то кажется, что это рюши. Те же фреймворки. Разве они определяют технологию? Платформу? Удобство разработки, в некотором роде, да. Еще что-то?


Я не говорю, что джава отжила свое, еще нет.

Java не плохой язык, и на нем управление робототехникой хорошо делать. Проблема всего что сейчас есть — это время на разработку, финансирование проекта и минимум персонала. Поэтому на западе фильмы снимаются за сотни миллионов долларов и есть что смотреть из фильмов, а в странах советского союза из 10 тыс долларов пытаются снимать «кино-шедевры» за день-два и пытаться конкурировать с западными кинокомпаниями.

В статье не учитывается тот факт, что java испольщуется сейчас в основном как инфраструктурная платформа для других языков. Если взять даже самую кривую энетрпрайз технологию, то все равно внутри обнаружишь какие-то el-expressions. А на чистой java в не-legacy проектах мне кажется сейчас мало кто пишет.

(К примеру у нас сейчас из двух текущих проектов в инфраструктуре JVM, один проект на scala, второй — на смеси groovy и java.) И scala и groovy более чем сравнимы с python по продуктивности разработчика, а java — это типа ’C’ для JVM, используется когда надо что-то конкретное низкоуровневое подкрутить.

JVM оченнь хорошая штука и динамические языки на ней тоже, но я бы не говорил что в основном все пишут под JVM не на Java, в Украине и в мире очень много легаси проектов на J2EE, иначе просто не было такого бешеного спроса на соответствующих разработчиков и именно это я считаю тупиковой ветокой эволюции в IT, просто на Java и особенно на J2EE пишется огромное количество проектов, которые не должны писаться на ней, потому что — много разработчиков и «так принято». И безусловно есть вещи которые нужно писать на Java, но они составляют в лучшем случае 30% от общего числа наших проектов.

просто на Java и особенно на J2EE пишется огромное количество проектов, которые не должны писаться на ней, потому что — много разработчиков и «так принято». И безусловно есть вещи которые нужно писать на Java, но они составляют в лучшем случае 30% от общего числа наших проектов.
Заявила истина в последней инстанции как обычно не снизойдя до аргументации.
Павел, кончайте троллить.
Джависты потому и джависты, что выбрали джаву. Это настолько очевидно, что вроде как и писать не надо ничего.

Если вам так нужны «признания», пожалуйста — я пишу на Java в своё удовольствие.

Ок, будем верить в «позитивный троллинг».
Просто одно дело — «тыкать» в изящество какого-нибудь кода, и другое — писать что-то вроде «на убогой джаве нет популярных стартапов, и пишут на ней только ради денег, пересиливая себя» (-;

Вы, я так понимаю, предлагаете нам глянуть в сторону Питона и Хаскеля?

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

Очень интересно будет почитать. Очень надеюсь на адекватность аргументов, а не в стиле этих xkcd.com/353

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

Да да, опубликуй, предчувствую epic fail.

Потребность в Java диктуется производством мобильных устройств. Поэтому Java это почти тот же ассемблер, но в завуалированном виде. Поэтому все приходится писать самому, чтобы в будущем не упрекали в не лицензионном использовании сторонних библиотек. Поэтому Java не так просто как SQL-команда серверу по отбору данных. Здесь уровень нагрузки на восприятие сильно отличаются. И со временем такое программирование меняет человека в сторону большей молчаливости и безразличия через усталость.

Языки, на подобии ассемблера, понижают уровень способностей из-за «низкоуровневого мышления».

Интересный не обоснованный поток мыслей.

Мало кто не согласится, что при одинаковой квалификации большинство задач на Ruby/Python/PHP реализовывается проще и изящнее чем на Java и как следствие продуктивность труда в Java индустрии ниже.

Вот я не согласен. Продуктивность Java падает не так быстро как продуктивность разработки на Ruby/Python/PHP с ростом проекта и «движлом» среди команды, на сколько я сталкивался.

Мораль: если для вас самореализация и удовольствие от работы важнее лишних нескольких сотен $ в месяц ищите возможность писать на чем-то отличном от мейнстрима Java.

Не понимать. «Интересность» задачи не зависит от технологии на которой ее реализуют. Кстати, касательно того же «мейнстрима Java» он существенно размылся за последние годы, тотальный EJB и JSF уже года 3-4 как не наблюдается.
Есть куча других Java-технологий, в том числе и модных закосов под РоР и ДСЛ + 100500 новых фреймворков которые позволяют «писать под веб сугубо на джава (без ЦСС, джавасерипта и с минимумом ХТМЛ)»

Но самое интересное, что если нужно сделать проект не для фана, а что бы он работал и был сделан аккуратно, то мы возвращаемся к старым (условно) и проверенным фреймворкам.

COBOL к стати на столько жив что вы даже не представляете )

завернут в web сервисы в глубинах ESB банков и компаний- но жив. И будет жить еще доооолго и переживет еще не одного кто думал что кобол мертв. Прямо таки Ницше и Cobol если вы понимаете о чем я

Ну мне даже с его предшественником RPG II пришлось понекрофильствовать в начале 2000х. Да, большая контора, вложившаяся в разработку 20-25 лет назад, и еще лет 10 вылизывания потом, не может это выкинуть. Но это не жив, так, плавает в формалине, чтобы не вонять.

это скорее мамонт в цистерне с формалином — и показывать стыдно и выкинуть не куда ))) бешеные миллионы строк и денег

я думаю цей пост можна сприймати як заклик хоча б спробувати ті ж рубірельси чи пітоноджанги

я не впевнений що існує на планеті людина яка за задоволенням після рельсів повернулася до програмування того ж вебу на жабі

Сам автор харектиризует этот пост как вброс, что как бы характеризует автора: twitter.com/...837502798643200

в кожного своя термінологія :)

За что ему большое спасибо, за последние пару недель не участвовал ни в одном годном сраче :)

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

Мало кто не согласится, что при одинаковой квалификации большинство задач на Ruby/Python/PHP реализовывается проще и изящнее чем на Java и как следствие продуктивность труда в Java индустрии ниже.

Совершенная ерунда.

И помните что произошло с COBOL-ом.

Какое отношение COBOL имеет к Java? Такое, что завистники/нелюбители Java отчего-то вдруг решили её с ним сравнивать?

«Мало кто не согласится, что при одинаковой квалификации большинство задач на Ruby/Python/PHP реализовывается проще и изящнее чем на Java и как следствие продуктивность труда в Java индустрии ниже. Это проблема № 1 — более низкая продуктивность труда.»

Не соглашусь ибо ересь!

Разница не в языке, разинца как раз в enterprise/не enterprise.

PHP/Ruby выигрывают в том, что на них заказывается много проектов _среднего_ размера человекочасов этак на тысячу. Соответственно, технологии меняются чаще и не успевают приедаться, знания не успевают устаревать. При этом уровень таких проектов по технологиям довольно серьезен.

Не согласен касательно применимости Java. Аргументы ниже..

Работаю уже на 3-ем НЕ-Enterprise стартапе, использующим Java. Ruby On Rails это тоже фреймворк, ограничивающий творчество при разработке Rails приложений. Как и Django. Как и ZendFramework.

Я равнодушно отношусь к Spring, JSF, EJB, JPA etc. и не считаю их неотъемлемой частью Java-разработки (но это уже другая тема). Однако сам язык Java, как и платформа в лице JVM, это на сегодняшний день самая мощная кросс-платформенная платформа (сори за тавтологию) для WEB-приложений.

А с другой стороны, дело даже не в языках, платформах и технологиях — дело в людях, которые используют эти самые языки и технологии. Уверен что существуют проекты, ужасно написанные на Ruby/Python, в которых черт ногу сломит. Равно как и существуют хорошо и грамотно реализованные Java-проекты. Да и от проблемы копи-паста никакой язык не спасет.

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

Т.е. мораль такова — язык программирования это хорошо, а голова остается самым важным инструментом программиста :)

1. linkedin
2. Каким боком бекэнд к юзабилити? Тёплое с мягким?

Павел, здесь тема о джаве а не о стартапах.

Оглашать проекты я естественно не собираюсь по известным причинам. Успешным стал пока только один. Но думаю до 15-20 млн он все же не дотягивает.
Но вопрос в другом. Неужели вы думаете что возможность масштабирования WEB сайтов на Java чем-то уступает таковым на руби/пайтон/пхп?
Масштабируемость это прежде всего правильная архитектура базы данных, а не язык, на котром происходит выборка этих самых данных и генерация ответа.

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

Согласен с вами.

Это правда если система ничего особо не делает кроме как перекладывания инфы из мскл-а в хттп респонс.

Как вы считаете, почему успешных java-стартапов на порядок-два меньше, чем на питонах етц?

А ты уверен что их нету?

Как переход с Rails на Си поможет, скажем, github?

Не понял что ты имел в виду.

Павел, видимо, имел в виду, что если система делает что-то более сложное, чем «перекладывание инфы из мскл-а в хттп респонс», то как именно смена ЯП существенно поможет производительности?

Подождем обьяснения Самого Павла все таки.

Ответ такой, что в гитхабе РоР занят именно перекладыванием инфы из БД в ххтп респонс, а например собственно гит написан совсем не на РоРе

s/

А ты уверен что их нету?

/Ты уверен что их на порядок два меньше?/g

Те кто на слуху: zynga, cloudbees, cloudera, но конкретные примеры не говорят о статистике, а вот например такой график говорит: www.indeed.com/...java startup&l=

Если разобраться, то такой график показывает количество вакансий со словами «java startup» & «python startup» соответственно. Я очень надеюсь что правильные выводы ты сделаешь сам.

Найди сам, ты ведь делаешь смелые утверждения о том что пистон стартапов на порядки больше чем джава?

Это звиздеж, фейсбук наверное на пхп написал хайв, кассандру и патчил мемкеш.
Амазон на джаве.
Можно ссылку про ютуб?
У тебя осталось два проекта на пистоне? Какой их ревеню?

У джавовой зинги 2 млрд. У амазона вообще 30.

будь-який стартап з часом виростає з технологій на яких починався або по мірі можливостей ті технології покращує

це тим не менше ніяк не заперечує той факт що ті технології для стартапів підходять краще :)

У меня в ютубе работает знакомый, программером на питоне. Через епам их сча туда много натащили.

Епам поставляет программистов гуглу? Неожиданно.

Ну, кому неожиданно, а кого рекрутëры епама уже порядочно достали. Они где-то с декабря активизировались, а последние пару месяцев просто бушуют. И явно друг с другом не общаются, я запарился уже в линкедине говорить «спасибо, не интересно».

Вы просто не в курсе — у них это давно уже.

В этой теме мы обсуждаем разработку. Точка (-:

Правда — посмотрите тему, там автор про всё подряд, не только про веб и фронтенды.

Вот в том и дело, что джавой одной вполне можно обойтись.

М-да. Фейсбук не только имеет весьма специфическую архитектуру (упомянутая Cassandra на Java например), но еще и собственный PHP движок. Да и стартапом его уже считать сложно, как и LiveJournal например (это же вообще динозавр).

Фейсбук не вышел на IPO, значит это стартап.

Что ж, тогда пожалуй слово «стартап» для нас лишено смысла в данной дискуссии.
Нам интересны новые проекты (год-два, не более) — ведь именно перед ними стоял вопрос выбора из современных (для нас) технологий.

Технологии, на которых сделан LiveJournal например, в наше время вряд-ли настолько же привлекательны/конкуретны как и во время начала LJ.

P.S. Flickr — «успешный» «стартап»?..

engineering.twitter.com/...aster_1656.html
Цитирую для невнимательных:

“‘‘Last week, we launched a replacement for our Ruby-on-Rails front-end: a Java server we call Blender.’’”

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

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

Мне кажется (чисто интуитивно) что большинство организаторов новых стартапов это как раз те программисты, которые в прошлом работали на Java, .NET, PHP, и в качестве чего-то нового обычно берут Python, Ruby, Scala.. Но я могу быть не прав.

Опять же, я не говорю что джава лучше чем руби/пайтон и не пытаюсь их сравнивать. И руби и пайтон и пхп достойны уважения в равной степени с джавой и дотнетом. Основная моя идея в том что язык программирования не есть ключ к успеху или поражению. И не вижу никаких объективных причин считать что джава для стартапов подходит хуже или лучше.

как выбор платформы для server-side связан с юзабилити?
и да, мы разрабатываем продукт, начавшийся как стартап 3 года назад, у которого сейчас 100 млн/день.... не на питоне :)

Стартап то (текущий) — не ваш, вы просто туда аутстафитесь?

LinkedIn.
Крім того, на Java написаний чи то AdWords, чи то AdSense (точно не пам’ятаю), який Google купили за дикі мільйони баксів.
Крім того, Java часто використовується після того як стартапи стикаються з проблемами росту і масштабування. Наприклад, Hadoop в Facebook і Twitter, або механізм черги в Twitter, які вони реалізували на Scala, що працює поверх JVM.
Крім того, сучасні стартапи — це такий сплав технологій і проектів, де сайт-обгортка, часто створена на Ruby/Python/PHP, — це лише вершина айсбергу. А власне business value генерується на недоступних громадському оку серверах часто, зокрема, на Java технологіях.
Крім того, більшість «стортапів» Рунета і Укрнета агарчають Ларі Пейджа своєю унилістю і не можуть бути взірцем для прийдешніх поколінь.

ЛОЛ.
Всі співробітники Амазон побігли продавати свої акції і звільнятися з роботи.

І все завдяки правдорубу з форуму developers.org.ua, який заявляє, що їхня робота нецікава.

очень круто, что украинская компания помогает стартапам из silicon valley.

На счет гибкости — согласен (но это процентов 10%-20% преимущества, не больше).
По поводу деградации — это везде происходит если долго работать с одним и тем же (опыт есть), что мешает развиваться параллельно?
По поводу интересности — тут зависит исключительно от проекта, а не от технологии. Хотя малая корреляция есть, да.
Про пару сотен баксов — тоже глупость. Топовые пхп которых я знаю получают ~2k. Самый топ — 2.4к. В тоже время знаю несколько явистов на 3к и 3.5к — топовый. Как по мне это больше чем пару сотен.

А в целом все от человека зависит и не имеет отношения ни к технологиям, ни к стартапам.

Самый топ для PHP уже вырос, не знаю как по java.

Дима, про топ неправда

Короче статья — набор крайне спорных утверждений:

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

Чем джава фреймворки жостче чем пистоновские?

Простой пример, попросите Java разработчика и Python/PHP/Perl/Ruby разработчика за сколько они сделают простенький сайт вроде milliondollarhomepage.com а еще лучше попросите их сделать и запустить, сроки будут отличаться в разы.

Хорошо что автор не написал в какую сторону.

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

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

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

Украинские стартапы с их нищенским вознаграждением нам не нужны, а вот зарубежом расклад джава вс пистон в стартапах совсем другой.

А взамен вы получите более высокую собственную эффективность, способность работать в более интересных проектах и если вы однажды захотите реализовать небольшой pet-project за пару вечеров, который может перерасти в успешный бизнес то всегда полезно иметь под рукой хороший инструмент которым вы владеете

Я вот на ГАЕ прототипируйы на джаве вполне реактивно, одномиллионную страницу смогу вывести в интернет за пару часов, за исключением прикручивания платежной системы, т.к. там могут быть подводные камни.

...И помните что произошло с COBOL-ом.

А пистон типа неуязвим от ухода в прошлое?

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

Сложные проекты потихоньку переползают в web. Вы просто их еще не встречали )

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

90% жабы — это веб. Но в данном случае сравниваются "украинские интересные интернет стартап-ы"(можно примеры что бы недалеко ходить сразу кстати?) и enterprize разработка, и почему то делается вывод что enterprise программисты стоят на месте и не развиваются. Очень даже развивзются, просто в других направлениях.

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

Сори, за повторение первого комментария

В статье ни слова у украинских стартапах (я, кстати, тоже таковых не знаю).

А в неукраинских питон явно не доминирует, и джавист вполне себя сможет найти.

А по поводу развития... На мелких проектах человек не развивается, на крупных развивается, но медленнее (в силу того, что нет смены технологий на протяжении дологого времени) а вот на средних развитие получается самым динамичным.

Сори, за повторение первого комментария

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

Да про COBOL это хохма вообще дикая — если следовать ущербной логике автора, то старый COBOL сменил новый COBOL в лице Java, и еще один в виде .Net, из чего следует, что... будущее за еще одним COBOL-ом, а не за минималистическими скриптовыми языками (-:

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

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

нє нє нє... не треба в Джавіста в Пих, дуже вас прошу! І .Net-тчики в пиху також велике зло. Я бачив код джавіста на Пиху, буде перепрошую, але вони продовжують писати на Джаві, використовуючи синтаксис іншої мови. Тому краще бути профі в якісь одній мові (групі мов) ніж пригати туда сюда.

джава как первый язык далеко не самый худший выбор

Да, потому что наоборот, джава после питона, скучно и противно до ужаса.

Ну если сравнивать с ПеХоПе то да :)

так а я что писал что джава как первый язык плохой выбор, просто это плохой выбор как единственная платформа которой профессионально владеешь, что и происходит с большинством J2EE разработчиков

с питоном такого разве не происходит? кто говорил, что начав писать на питоне потом на джаву противно смотреть?

но тем не менее некоторые вещи люди, которым противно туда смотреть на ней пишут, у всех технологий есть рамки применимости, но Java далеко не silver bullet как про нее расказывают ее евангелисты.

как и питон.... как и все остальное.....

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

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

Почему плохо? Можно конкретные аргументы без воды?

потому что stackoverflow.com/...nd-chunk-theory

писать 5 строчек кода для того чтобы сделать массив в котором элементы будут квадратами первого вместо одной
B = [x ** 2 for x in A]

это класс задач на который тратят 50% времени J2EE разработчики

И веселится потом когда вместо А пришел стринг в продакшне. На этом разваливаются 50% питон стартапов. Будем еще прописные истина перетирать?

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

Это потому что у вас 5 программистов, среди которых видимо никогда не было текучки, и видимо меньше 10 тыс. строк кода.

Юноша, если у вас нет аргументов то идите в другую тему а не засоряйте эфир тем, чего не знаете.

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

Так что аргументы типа lurkmore.ru/Сперва_добейся против него не стоит применять ибо lurkmore.ru/Сперва_добейся

Помоему автор явно врет, т.к. еще недавно по его же словам в образованной 3 года компании трудились 5 программистов, как они успели настрогать на 20 человеколет непонятно.

Дальше, пусть несколько млн — это два, 2 млн / 20 человеклет = 100 тыс. строк в год, / 200 рабочих дней = 500 строк кода в день. У вас чукчи писатели а не читатели? Или вы код генерите а потом сразу выбрасываете?

ну его реально больше миллиона строк было когда последний раз считали с пол-года назад :) (питон, шаблоны, стили) да и программистов уже больше года как не 5, но вообще чего я оправдуюсь то :)

шаблоны, стили

В это охотно верю, только причем тут питон, непонятно.

но вообще чего я оправдуюсь то :)

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

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

Ви чудово дискутуєте. Хотів лише нагадати, що в пості, навколо котрого нібито крутиться дискусія, немає жодного слова «всі».

Зато есть фразы:

«как следствие продуктивность труда в Java индустрии ниже», «в отличие от Java проектов, которые преимущественно похожи как две капли воды», «большинство задач на Ruby/Python/PHP реализовывается проще и изящнее чем на Java», «Java разработчики в подавляющем большинстве своем работают менее эффективно».

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

J2EE (где все одинаково и неэффективно)

Если сразу исходить из таких аксиом, то никаких опросов не нужно. Фанатизм не излечим.

Если хочешь отстоять свою позицию, и доказать что jee(j2ee уже давно не актуально) действительно неэфективен, я всегда готов к конструктивной дискуссии, а так пока что твой евангелизм заключается исключительно в закидывании шапками.

В дополнение добавлю, да в джаве сейчас большой процент баласта в виде офисного планктона который не болеет проффесией, он больше чем в питоне, но причины этого:
— из-за указанных высоких зарплат
— из-за некоего ореола элитарности и кулхацкерности вокруг питона, из за чего, согласен, туда стремятся талантливые люди которые хотят выделятся и отличатся из серой массы

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

это класс задач на который тратят 50% времени J2EE разработчики

Николай, это исключительно вброс.
Пруф — habrahabr.ru/...ogs/gtd/102620

Кодинг — это реально 10-20% времени. Чем хуже уровень тем больше это время.

Мало кто не согласится, что при одинаковой квалификации большинство задач на Ruby/Python/PHP реализовывается проще и изящнее чем на Java и как следствие продуктивность труда в Java индустрии ниже.

Я не соглашусь, для небольших веб проектов с небольшим обьемом кода это еще более менее справедливо. Когда поголовье программистов переваливает за 10 голов, начинаются проблемы например с динамической типизацией.
Посмотрев топик на сайте smartweb-a пришел к выводу что у автора случилась психическая травма от обилия xml-a в ранних версиях хибернейта и спринга. Но тут есть два но:
— спринг и хибернейт вполне прогрессировали, и даже на момент 2008-го вроде вполне поддерживали всякие jpa и javax.inject анотации

— спринг почему то все суют куда надо и ненадо, а это всего лишь IoC фреймворк. Судя по коментам на smartweb автору IoC не нужен, значит ему и спринг не нужен.

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

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

Если ты считаешь что проект с одним программистом и 100 программистами живут по одним законам, то дальше развивать тему не имеет смысла.

на счет 100 не знаю. Точно знаю что 30 программистов вполне себе уживаются с динамической типизацией. Так что можете попробовать развить )

Уживаются — это не количественная характеристика. Вам нужно потратить усилия(дополнительные юнит и не юнит тесты?) что бы минимизировать скажем случаи возникновения obj instance has no attribute ’method’ в продакшне, а в жабе это будет изкаробки.

Однако так называемое «потерянное время» с лихвой компенсируется убогостью джавы.

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

Чисто к слову, а что это за проект такой, с 100 программистов?

Ты с другой планеты? Погугли по словам google search, bing, oracle rdbms, ms office.

Все круто, только сейчас как раз знающие Java в плюсе, т.к. могут сделать свой собственный проект под Андроид.

И не только под Андроид, раз уж вспомнили про мобильные платформы..

HTML5 наступает. Так что преимущество сиюминутное. Мобильные приложения (в связи с малыми мощностями аппаратов) будут очень активно уходить в web

Угу, тут вот как раз сегодня представили очередной маломощный Android-аппарат с двухъядерным процессором 1,2 ГГц и 768 МБ оперативной памяти... =)

1.2Г это конечно круто. Как и 64К когда-то )

Вы сравнивайте с свеже анонсированными десктопами.

Зачем? Там разные приложения, разный подход к разработке. Даже мультизадачность в таких аппаратах можно оценивать как минус, а не плюс. Если мощности у них будут одинаковые, то просто системники станут размером с этот девайс, а сами перерастут во что-то другое. Как у того чувака с ТЕДа с вебкамерой на голове.

А с какой радости я должен сравнивать производительность смартфонов и настольных ПК? Мы ведь не запускаем на мобильных аппаратах приложения для 3D-моделирования и прожорливые игры.

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

Интересно, как можно сравнивать объектно-ориентированный язык программирования, и язык разметки?..

Мабуть мається на увазі широке розповсюдження cloud computing. Мобільний пристрій при такому використанні буде тонким клієнтом з веб-інтерфейсом на основі JavaScript, HTML 5, CSS.

Мабуть, але тоді тим більше в бек-енді на клауді дуже може бути та сама Java. А ось щодо клієнтів, практика показує, що натівні apps на iPhone наприклад набагато приємніші для користувача, і краще продаються, аніж «інтерфейс для бідних» в браузері. Той самий Google Maps наприклад, про який Джобс згадував.

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

У натівних apps є один великий мінус — їх треба писати під кожну платформу, тоді як у випадку використання не дуже красивих (?) браузерних варіантів в ідеалі все буде працювати однаково на любих мобільних платформах (повторюю — в ідеалі, насправді на практиці це поки що не так). З розвитком HTML рюшечок буде більше, браузери будуть краще підтримувать стандарти і через деякий час (на мою думку чекать прийдеться не дуже довго — декілька років) всі потихеньку почнуть відмовлятися від натівних apps на мобільних пристроях. На рахунок бекенду — Java для бекенду дуже добрий варіант. Вона тільки для бекенду і годиться.

Погоджуюсь.
Лише теж пара дрібних зауважень:
— Натівний вигляд аплікацій — найкращій, це досвід Apple доводить. Тобто набагато краще, коли всі аплікації на одній платформі виглядають і поводяться схоже (мають однакові шорткати, однаково реагують на стандартні контроли, т.п.), ніж коли одна аплікація працює/виглядає однаково на різних платформах. Хоча момент це скоріше додатковий, але не принциповий, це так;
— Джава для десктопів теж якось там, але часом таки годиться (ну і J2ME колись був непоганий в своїй ніші), тільки нажаль чомусь ні Sun ні Oracle ніколи не займались цим напрямком серйозно. Від них та і не допросились ферймворку для Свінга наприклад, хоча просили і чекали в Java 7 наприклад.

Тому зараз джава на десктопі це всілякі «страшні» штуки аля Eclipse, ішні IDE на Eclipse RCP, специфічні проги аля Admin клієнт для e-Commerce шопу ElasticPath, і одинокі штуки аля Azureus. А можна ж було зробити щось такє як SwingGL наприклад ( code.google.com/p/swing-gl ), тільки повноцінне. І хто зна, можливо певна ніша джавішних дестопних аплікух існувала би...

существуют и решения для нативного вида приложений, вот ,например, Sencha Touch www.sencha.com/...products/touch

Flash Builder вам в руки. HTML5 — тупик. Браузер не может обеспечить производительность выше чем ту что дает сама система, поэтому нативное есть нативное.

Очень просто — сопоставление количества байт с качественным уровнем, несущим этими байтами.

Пример:

HTML: <div style="left:10px; top: 10px;«>Матрица A</div> — 50 символов

C++: A+B=C — складывание двух матриц в результате получается третья матрица. Всего 5

символов занимает эта запись.

Сравниваем:

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

При наборе этих 50 символов человек был сосредоточен и напряжен в 10 раз сильнее, чем при сложении матриц. Для организма (напряжение, сосредоточение) нет никакой разницы между нажатиями на клавиатуре символов сложения матрицы или HTML-кода. В обоих случаях доля траты энергии и сил была одинакова в расчете на один символ. При этом, те 50 символов из HTML кода, на качественном интеллектуальном уровне выводят всего лишь слово «Матрица A». В то время как на C++ выполнены сложные математические вычисления. И получается, что HTML разметчик в 10 раз сильнее устал и в 10 раз глупее программиста на С++.Вот Вам и все сравнение. Привлеки хорошего спеца по тому же Маткаду, на HTML-верстку, от изучения до реального сайта, с ужатыми сроками на все, и через год такой человек станет глупее, с потерянным интересом к тому чем занимался раньше — он отучиться думать, все его время будет направлено на запоминание и пробы для достижения нужного результата.

«Товарищ Сталин, что вы курите?»
Трата энергии и сил — в дебаге (-; , а A+B=c это бред а не C++ и не складывание матриц. Отвелчённый пример про «вёрстка — тупо, маткад — круто» весьма отвлечённый, но пусть будет. Только из этого примера следует, что HTML5 ни на какие ООП языки не наступает, не так ли?

Вобщем непонятно к чему и о чём это всё.

Был бы еще тот «огонек» интереса к мобильной технике, чтобы писать под нее.

Мобильные платформы это уже не платформы будущего, это платформы настоящего (КО). Это ж круть, тут еще все только начинается.

А меня чего-то не «торкает» эти все телефоны с большим экраном. Так чтобы взял в руку поклацал по менюшкам и на последние деньги купил себе такой же. Нет такого почему-то.

Уважаемый Сергей, вы уж простите, но всем наплевать на то, что нравится личо вам.

Мобильные устройства это весьма и весьма широкий и популярный рынок уже сейчас, с вполне приличным оборотом. Станете отрицать?

Не знаю, мне никогда не хотелось ни цифрового фотоаппарата, ни плейера, ни видеокамеры. Хотя людей, которые чуть ли не горели желанием фотоаппарат купить суперкрутой, видел много. Наверно такое бывает когда стареешь раньше, чем по принято по годам возраста. А может это так реальность жизни накладывает свой отпечаток — лишая интереса ко всему. Как у рабов — 15 лет отработал в таких условиях, ничего не имел, поэтому и желать не чего. Законы в стране приучили таким быть.

А были бы конкурсы, выставки того что каждый чего достиг в программной части, того глядишь и все было бы по-другому. А так все жили «сплоченным правом», никого не устраивало чтобы все было открыто и доступно. В результате одни оказывались в лучшем результате — другие ни в каком. Такие как я многим не удобны — понимают все правильно и умеют доступно пояснить. «На страну бочку катит.», а страна это ведь люди, те кто жил такими законами и правилами. Поэтому таким как я больше предпочтут чтобы был слабоумным в итоге, чтобы пояснить всем кто будет интересоваться, что мол «это у него проблемы вот видите, страна здесь ни при чем».

У кого-то есть огонек, у кого-то нет.
В любом случае под эту платформу есть кому писать. Не надо учить новую технологию.
Даже если 5% из миллиона java-программистов напишут хотя бы по одному приложению, это уже 50 000 приложений.

Подписаться на комментарии