Сколько еще осталось жить Java?

А ты сам на чем пишешь ? Не на всем же сразу, знаешь наверное что-то лучше остального..

Мне еще интересно у кого из таких людей, как с работой ? Лично многое упустил изза _поверхностного_ знания Java, .NET.. Бросился на то что показалось более интересным а щас сижу без денег. А писать то что пишу на энтузиазме на Java, .NET дабы получше узнать, влом, так-как могу на другом написать лучше.. Вот такое вот хрензнает что =)

Пишу - на Java, C#, C++, Common Lisp, Scheme, OCaml, F#, SML (NJ & MLTon), Forth, Prolog (Mercury), Haskell, Tcl, Python, Erlang.

Из этого основные инструменты (в порядке частоты употребления) - CL (+ иои собственные языки, поверх CL сделанные), OCaml, C#, Haskell, Java. Остальное юзается реже, но тоже - регулярно, не ржавеет. Из вообще здесь не перечисленных языков довольно хорошо ("со словарём") знаю ещё с полтора десятка...

На работу - не жалуюсь. Хватает, чтоб за пару лет скопить на открытие своего собственного IT-шного startup-а.

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

>А ты сам на чем пишешь ? Не на всем же сразу, знаешь наверное что-то лучше остального..

>Мне еще интересно у кого из таких людей, как с работой ?

А на чем писал, что без денег сидишь? На PHP, или на Delfi?

>Пишу - на Java, C#, C++, Common Lisp, Scheme, OCaml, F#, SML (NJ & MLTon), Forth, Prolog (Mercury), Haskell, Tcl, Python, Erlang.

Если не секрет - что ты такое пишешь на этом зоопарке ? ;)

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

Широко известное заблуждение CS-ников - теоретиков ;)

Сколько я таких повидал за почти 20 лет работы не сосчитать ;)

По теме:

У меня пара знакомых коллег ваяющих сейчас на Java прошли следующий путь:

1-й: asm (x86,DSP)->C->C++->Java: Сама по себе ему Java не нравится как язык но нравится зарплата (место работы - довольно крупная софтверная компания в UK)

2-й: C->C++->Java: про отношение к Java как к языку - аналогично п1. Место работы (RedHat ;))

Резюме: Нужно учить не язык программирования а навык решать _задачи_ (прикладные или фундаментальные суть не важно). Язык в данном случае выбирает работодатель. Ваша же задача выбрать между получением морального либо материального удовлетворения (исключения в виде сочетания того и другого редки - что подтверждает общее правило)

2sS :

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

> Широко известное заблуждение CS-ников - теоретиков ;)

Кстати, по моим наблюдениям, почти все мои знакомые IT-специалисты, мнение которых я уважаю, в своем развитии проходили через этот этап (насчет прерогативы теоретического "абстрактного" знания с последующим автоматическим приложением прикладного). Большинство вскоре понимало максималистический характер этого юношеского увлечения, но некоторые на нем и застряли, выбрав нишу CS-теоретиков. Более того, я знаю пример, когда подобное увлечение помогло человеку буквально "найти себя": среди моих знакомых есть один поистине гениальный преподаватель, который вообще не в состоянии написать нормально работающую программу -- зато ему дано научить других, как такие программы писАть.

BTW, среди физиков-теоретиков, особенно русских нюхнувших Совка и американов издания последних лет, прослеживается несколько похожая тенденция: презрение к эксперименту и рассчетам в пользу щеголяния "голым" матаппаратом. Фактически, всех теорфизиков-"совков" можно было легко разделить на тех, кто умел что-либо считать (таких было меньшинство), и тех, кто с презрением относился к рассчетам в рамках реальных экспериментов, считая их "мухобойными". Соответственно, масса глупейших работ в рамках опровергнутых жизнью теорий полувековой давности. "Экстремальный" пример -- небезызвестная РТГ одного весьма известного академика (несмотря на грозное "прикрытие", реальные авторы этой теории -- именно такие вот "чистые" теоретики).

1) Я не CS-теоретик, и никогда им не был. Я чистый практик, и всю теорию учил тогда, когда она становилась абсолютно необходима. Теперь жалею об этом, об испорченных Фортраном привычках, о MACRO32, о MuLisp, увиденном задолго до Franz, и сильно поломавшем правильные представления. Теперь считаю своим долгом предупредить других о подобном пути - чтоб не наступали на все те грабли, по которым прошелся я.

2) Сам ты "зоопарк". Раз не маленький, то обязан знать - каждой задаче - свой язык, универсальных - не бывает.

Ну, ты у нас известных практюх, двух строк сложить в программу не можешь. Ты же убог, не тебе о теоретиках рассуждать. Я что-то не встречал теоретиков в CS, которые не были бы сильными практиками, которые не писали бы такой код, какой ни одна C++-ная макака вроде тебя никогда в жизни не выродила бы. Смотри на тех, кто работает в http://research.microsoft.com/, смотри на их код. Сравни с тем дерьмом, которое рожаешь ты.

>Теперь жалею об этом, об испорченных Фортраном привычках, о MACRO32, о MuLisp, увиденном задолго до Franz, и сильно поломавшем правильные представления. Теперь считаю своим долгом предупредить других о подобном пути - чтоб не наступали на все те грабли, по которым прошелся я.

Фортран не может прививать какие либо "привычки" - это просто инструмент. Если вы пытаетесь молотком забивать шурупы это не есть проблема молотка.

На самом деле никого не интересуют виртуозы - владеющие тем или иным инструментом (или полусотней инстументов) Виртуозы пусть в цирке выступают. Ценятся люди которые умеют решать _задачи_. Как они это сделают, не зависит от инструмента а зависит от их способностей/квалификации.

>2) Сам ты "зоопарк". Раз не маленький, то обязан знать - каждой задаче - свой язык, универсальных - не бывает.

Именно зоопарк. Максимальное число языков, которое можно использовать в проекте - 2 - (прописью - "два") если больше, то ищи проблемы в дизайне ;) Не бывает задач - "вообще"

Судя по описанию вам наверное преподавателем надо работать (если есть способности в педагике) а к "полиглотам" как к исполнителям я с подозрением отношусь (на основании моего опыта ;))

> Фортран не может прививать какие либо "привычки" - это просто инструмент.

Ты забыл, какой там GO TO, и какой способ его применения считается естественным? COMMON-блоки помнишь? Не видел никогда, как люди, всосавшие Фортран с молоком матери, потом на других языках пишут? Я вот - видел. Кошмар. Из себя я эти манеры вышибал несколько лет...

> На самом деле никого не интересуют виртуозы - владеющие тем или иным инструментом (или полусотней инстументов) Виртуозы пусть в цирке выступают.

Виртуозы - это люди вроде Кнута.

А те, кто просто хорошо владеет всеми доступными парадигмами (и их реализациями) - просто нормальные программисты. Не кодеры.

> Именно зоопарк. Максимальное число языков, которое можно использовать в проекте - 2 - (прописью - "два") если больше, то ищи проблемы в дизайне ;)

А не слабо ли тебе обосновать столь нелепое утверждение?!?

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

Язык N1 - Java. На ней пишется реально не так уж и много - кусочки "бизнес-логики".

Язык N2 - XML-ный/ГУЁвый BC4j. На нём описываются промежуточные структуры данных.

Язык N3 - XML-но-ГУЁвый UIX. На нём пишется гуйня-вебня.

Язык N4 - Ant, to bind 'em all.

Язык N5 - Javadoc + DocBook.

И это - для маленьких проектов. Для крупных - ещё Greenspun tenth rule работает.

Куда ни копни - везде потуги расширить парк языков, вместо того, чтоб честно воспользоваться РАЗНЫМИ языками.

Посмотри на Unix-way-ные проекты:

Логика - полу-C, полу-C++. Возможны legacy куски на Фортране. GUI - Tcl/Tk. Встроенные скрипты, конфигурация - lua/guile/siod/tcl/python. Система сборки - make, perl, M4, часто Python и/или Tcl. Если логика сложная - опять появляется Greenspun tenth.

> Судя по описанию вам наверное преподавателем надо работать (если есть способности в педагике) а к "полиглотам" как к исполнителям я с подозрением отношусь (на основании моего опыта ;))

Преподавателям больше 25000GBP/Y не платят. А мне и в индустрии неплохо живётся. С "зоопарком", дедлайнами и малограмотными заказчиками.

>Преподавателям больше 25000GBP/Y не платят.

Какой преподаватель будет горбатится за 50 кусков зелени в год? Столярного дела чтоли ? ;)

Нормальные просто с острова валят на континент или просто за океан.

>А мне и в индустрии неплохо живётся. .... >с малограмотными заказчиками.

Долго вам еще не быть Project Manager-ом ;)

Дениги как и заказчик "не пахнут" ... заказчик пожелает - бушь на Excel писать ;) Искусство "прожект манагера" заключается в способность убедить заказчика не лезть в детали реализации ... не всегда это получается. Самое х@#вое это когда заказчик себя _мнит_ спецом ... очень трудно иногда не послать его лесом а ни-и-и-зя. В этом то и заключется искусство так развести исполнителя и заказчика чтобы оба остались довольны.

Вот как порулишь одним _своим_ проектом и побегаешь между теми и другими, поймёшь чем плохо использование 25 языков сразу. Гибриды то появляются не от хорошей жизни потому как проще нанять 5 кодеров, ваяющих на одном гибридном языке чем нанять 25 узких спецов или 5 полиглотов (последний случай вообще смертелен для проекта)

> Какой преподаватель будет горбатится за 50 кусков зелени в год? Столярного дела чтоли ? ;)

Фанатики и горбатятся. За океаном - не лучше, по крайней мере в тех местах, где не западло работать в принципе - MIT, UC, CMU...

> Дениги как и заказчик "не пахнут" ... заказчик пожелает - бушь на Excel писать ;)

Как правило, заказчика это не парит.

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

Именно. Но как правило - таки получается.

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

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

И не размахивай своей практикой - раз ты не работал со спецами, а только с макаками - то не можешь и сравнивать.

Я понял причину разногласий.

Ты смотришь с позиций Очень Крупной Серьёзной Консервативной IT-конторы с манагерами в галстуках.

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

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

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

И он сможет выдать 100 человеко-часов в неделю ? ;)

PS: У меня макакам от CS делать нечего ибо они элементарно не знают прикладного предмета (прошли это лет 10 назад и довольно быстро)

Пришел один такой (кричал что знает 9 языков и 4 системы) - не смог решить одной элементарной задачи потому как нефига не смыслил в предметной области.

>И не размахивай своей практикой - раз ты не работал со спецами, а только с макаками - то не можешь и сравнивать.

Ты телепат чтоли ? Про макак см. предыдущий абзац.

PS: Я ничего не имею против "просто программистов" только нужно понимать что просто "уметь программировать" мало.

К примеру ты можешь прекрасно знать английский, но это не значит что ты легко сможешь написать "Гамлета". Пойми разницу.

Как правило, человек, сумевший разобраться на требуемом уровне в CS, обадает достаточными аналитическими способностями, дабы быстро въехать в любую предметную область. Так же и с умением решать задачи - голые теоретики, ни одной задачи в жизни не решившие, идут в Красную Книгу, так как в дикой природе не встречаются (ну, разве что среди помянутых тобой преподавателей, самых плохих из них).

Про 100 человекочасов - дык его эффективность в сотни раз выше, чем у макак, ему на ту же работу гораздо меньше человекочасов надо.

Die-Hard:
> BTW, среди физиков-теоретиков, особенно русских нюхнувших Совка
> и американов издания последних лет, прослеживается несколько
> похожая тенденция: презрение к эксперименту и рассчетам в пользу
> щеголяния "голым" матаппаратом.

Эх! узнаю себя-дурака в 20 лет. физика - не наука.
мы - математики - другое дело, единственные, кому
доступно таинство НАСТОЯЩЕЙ НАУКИ.

sS:
> Резюме: Нужно учить не язык программирования а навык решать
> _задачи_ (прикладные или фундаментальные суть не важно). Язык
> в данном случае выбирает работодатель.

IMHO - самое правильное из того, что было сказано.

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

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

кстати говоря, говоря о lisp'e, когда в соседних строках
упоминается его академическая элегантность/чистота и тут
же рядом говорится о мощи метапограммирования, мне как-то
сразу вспоминается проф. Преображенский с его словами о
том, что "они должны лупить себя по затылку".

> кстати говоря, говоря о lisp'e, когда в соседних строках упоминается его академическая элегантность/чистота и тут же рядом говорится о мощи метапограммирования, мне как-то сразу вспоминается проф. Преображенский с его словами о том, что "они должны лупить себя по затылку".

Вот уж в чистоте Лисп никто никогда не обвинял. Да и в академичности - тоже.

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

Еще-б зарплата в этих "маленьких" была как у "больших" ;)

Успехом будет если года через 3 её купит большая.

(У моих знакомых было аж 2 подобных прецедента)

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

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

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

> Еще-б зарплата в этих "маленьких" была как у "больших" ;)

В среднем, вообще-то, сильно больше, чем у больших.

> (У моих знакомых было аж 2 подобных прецедента)

Дык того же Грэхема за 50 лимонов купили. У других же успех - стать большим и жирным тормозом (e.g. - Apple, Microsoft). ;)

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

Никогда не замечал подобной закономерности.

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

Избави нас бог от "быстро въехавших" ;) Только в прошлом месяце с одним таким общался. Нах-Нах. ;) Могу озвучить ряд его "открытий" ;)

>Про 100 человекочасов - дык его эффективность в сотни раз выше, чем у макак, ему на ту же работу гораздо меньше человекочасов надо.

Если бы. Есть статистический опыт. Никто не стал бы платить за 100 человеко-часов, если бы это можно было б сделать в 100 раз быстрее.

Ну нету таких гениев-кодеров в природе ;)

>В среднем, вообще-то, сильно больше, чем у больших.

Ключевое слово - "в среднем"

Вам же платят не среднюю по конторе зарплату а вполне конкретную.

Вообще в больших конторах с одной стороны меньше накладные расходы а с другой там например чтобы картридж в принтере поменять приходилось заявку из европы аж в Хьюстон отправлять (емейлом) - не шутка кстати нефига ;)

>Никогда не замечал подобной закономерности.

Сколько бльших и маленьких контор сменили ?

> Избави нас бог от "быстро въехавших" ;) Только в прошлом месяце с одним таким общался. Нах-Нах. ;) Могу озвучить ряд его "открытий" ;)

Озвучь, интересно. Люблю приколы.

> Если бы. Есть статистический опыт.

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

> Ну нету таких гениев-кодеров в природе ;)

Полно.

P.S. Я аналогичные жалобы слышал и про строителей. Нынешние бараны работают реально более чем в сотню раз медленнее, чем бойцы старой закалки. Да ещё и этих, старых, дико за это ненавидят, визжат о нарушении правил профсоюза и прочий подобный бред. В IT - та же щняга, только заикнись о том, что можешь в сотни раз быстрее среднего барана работать - тебя уроют.

Не могу удержаться, добавлю офтопика.

Несколько лет назад развлекался, играя на гитаре
с -1 midi записями. и попалась мне песенка doors,
которая мне ну очень нравилась. одна беда, в партии
баса (однотактовый риф, повторяется все 5 минут,
вручную задолбаешься исправлять) была ошибка, которая
резала слух.

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

ВЫВОД: каким же надо быть идиотом, чтобы в программу,
предназначенную для _музыкантов_ встраивать именно
lisp.

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

ВЫВОД: спасибо фирме microsoft, которая не пытается
воспитывать пользователей своей OS, предлагая им в
качестве стандартного языка такой, на котором уже
всякое "быдло" (например, музыканты) писать не смогут.

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

вот оно: дураки не ведают сомнений.

Ты про snd говоришь? Там не Лисп, а Схема. Та, которую среднестатический американец в школе изучал.

Если попробуешь заявить, что VB - проще для непрограммиста - пасть порву.

Кстати, раз ты такой умный - посоветуй софтовый гитарный процессор под линух, для электроакустики. Я в этом деле ни ухом, ни рылом...

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

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

> посоветуй софтовый гитарный процессор под линух, для
> электроакустики.

не могу посоветовать ничего :)

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

> Я в этом деле ни ухом, ни рылом...

я тоже, к сожалению

> Максимальное число языков, которое можно использовать в проекте - 2 - (прописью - "два") если больше, то ищи проблемы в дизайне ;)

У меня есть пример с несколькими языками. Есть программа, управляющая экспериментом. GUI на Tcl/Tk, основной костяк на C++, некоторые критичные к быстродействию модули на Си + asm для доступа к аппаратуре, еще имеется свой язык для описания наборов данных, которые вводятся перед экспериментом. Где здесь ошибки в дизайне?

>Озвучь, интересно. Люблю приколы.

Сдавали одну работку по CFD. Встрял один "спец". Типа аналитик. Даже в MIT вроде учился (не знаю уж на кого)

Собственно задачка была в оценке влияния внешнего давления на некое устройство из которого истекает _сверхзвуковая_ струя.

Вопрос звучал так.

"Почему это у вас при изменении внешнего давления не меняется расход через девайс"

Боссу пришлось применить чудеса дипломатии чтоб "эксперта" _сильно_ не обидеть ;)

LOL... Ну, значит, херово учился "аналитик"... Бывает...

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

>У меня есть пример с несколькими языками. Есть программа, управляющая экспериментом. GUI на Tcl/Tk, основной костяк на C++, некоторые критичные к быстродействию модули на Си + asm для доступа к аппаратуре, еще имеется свой язык для описания наборов данных, которые вводятся перед экспериментом. Где здесь ошибки в дизайне?

Сам писал ? Один ?

Пойми. Нечто сделанное тобой "на коленке" (в хорошем смысле слова) и тобой же для себя же поддерживаемое это одно.

А мало-мальский коллективный проект (с текучкой с изменениями интерфейсов с корректировкой тз под новое железо blah-blah-blah) это совсем иное.

я _чисто_абстрактно_ сделал бы либо C++/ASM либо тикль/С либо просто C++ (он сам по себе гибрид на нём можно и гуй и доступ к железу) - но без деталей сказать сложно.

BTW: У меня видимо нечто подобное народ писал на C+аsm(для специфичных процессоров) но дело было давно и сейчас с поддержкой имеют место быть сложности. Хотим переходить на нечто от стороннего производителя но стандартное - пускай они поддержкой занимаются.

> посоветуй софтовый гитарный процессор под линух, для электроакустики

Nyquist + Audacity. Это правда совсем не гитарный процессор, но при желании можно легко соорудить нужные эффекты: http://audacity.sourceforge.net/help/nyquist . Да, Nyquist - это Лисп :)

> Ок, хотя бы под венду. Чтоб было от чего плясать.

не, тоже уже не знаю, чего там появилось. перестал
я этим интересоваться. меньше эффектов - лучше :)

про linux, вспомнил: http://linux-sound.org/
что-то там есть в разделе effect processors.

А чем не нравится Tcl (метаязык, всё же) + Asm (причём, tcl к нему - макропроцессор)?

>А чем не нравится Tcl (метаязык, всё же) + Asm (причём, tcl к нему - макропроцессор)?

Там есть какой-то "движёк" на C++. Без понятие что это такое, и в данном конкретном случае я бы не стал заранее говорить на чем его писать...

Если брать _нашу_ систему сбора данных то у тикля не хватит производительности всё обработать а на асме просто не стал бы корячится ;)

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

Замучаешся поддерживать изменения ...

PS: посмотри на XPVM.

Типичная жертва тикля. Интерфейс жутко неудобен.

Хотя есть и прилично сделанные на нем вещи.

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

Ну, в кривых руках и Deep Blue в z80 превратится. ;)

Кривизна - не вина Tcl или Tk, а только лишь самих разработчиков.

cakewalk типа говорят один из лучших музлабалок но под вин