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

[Ludwig]

придумали абстракции более высокого уровня, которыми проще и самое главное более продуктивно оперировать

Более продуктивно работать - вот кого это касается? Тех кто otherwise вообще не смог бы работать - это да, согласен.

И джава - это не абстракция, а сильное упрощение на самом деле. Полезная для кодирования абстракция - это например лямбда-исчисление, closures, yield semantics, или к примеру отмена типизации (спорно), да и ООП вобщем-то тоже заняло свое место под солнцем. Это все есть абстракции. А Джава/C# не дают ничего нового, это просто кастрация некоторых - лишь некоторых - хороших абстракций - вот в чем проблема.

[Oleg123]

Сообщение от Ludwig

Более продуктивно работать - вот кого это касается? Тех кто otherwise вообще не смог бы работать - это да, согласен.

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

Сообщение от Ludwig

И джава - это не абстракция, а сильное упрощение на самом деле.

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

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

[Ludwig]

Упрощение это как раз основная цель любой абстракции.

Совершенно верно, абстракция - это обобщение, или упрощение. Но мы говорим о разных вещах.

Джава - это упрощение в том смысле, что в нем урезаны какие-то абстракции просто потому, что Комитет решил "это слишком сложно, и будет не по зубам многим".

Где например лямбда-функции, которые раньше были чем-то экзотическим, но сейчас уже есть во всех мейнстримовых языках - Python, Ruby и JavaScript (ECMA)? Между прочим в таких языках как Lisp и Scheme, реализация лямбда-исчисления и closures настолько мощное, что оно покрывает и ООП. Но это уже та самая "квантовая механика".

И плюс, если Джава заставляет много писать, можно ли считать это упрощением?

[Oleg123]

Сообщение от Ludwig

Где например лямбда-функции

По идее в Джаве должно быть многое, если не встроенное, то в виде библиотек уж точно. Вот например можно здесь посмотреть для начала http://www.ibm.com/developerworks/li...l?ca=drs-j2904 .

[Ludwig]

Сообщение от Oleg123

По идее в Джаве должно быть многое, если не встроенное, то в виде библиотек уж точно. Вот например можно здесь посмотреть для начала http://www.ibm.com/developerworks/li...l?ca=drs-j2904 .

Прошелся по статье - прекрасно, только в функциональных языках эти вещи записываются в 20-30 раз короче. То есть буквально класс (public class MyGreatClosureClass implements public void blah-blah) плюс его instantiation (MyGeatClosureClass myGreatClosureInstance = new MyGeatClosureClass() blah blah blah) заменяется одной строкой в JavaScript: function() { ... } или в Lisp: (lambda ...). Вот об этом была речь в том треде. Сошлись на том, что кому-то проще писать в 20-30 длиннее или читать чужой код, который во столько же раз длиннее. Ну и... прекрасно!

[Oleg123]

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

[OgreSwamp]

Сообщение от Ludwig

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

Да не от этого вы злитесь Я где-то видел исследование. Так-же злятся и в других отрослях IT индустрии. Просто раньше программист/админ итд был вроде священного гуру, а сейчас это обычный инженер/сотрудник. Раньше админу безграмотные юзеры чуть ли не челом о земь били, чтобы тот что-нить сделал. А сейчас админы стали рядовыми сотрудниками. Это нормальный рост IT индустрии. Естественно тем, кто стоял у истоков обидно, что наука превратилась в ремесло, но вы всегда можете уйти в науку, а не клепать тонких клиентов Вот я знаю, что на J2EE заработывают больше, но мне нравится работать с картами, ну нравится и все тут Вы просто ИМХО представляете java именно J2EE. А в моей области нет таких примитивов как int, double, long, float, char. На всем экономят Естесвенно нет никаких String, и паковать биты в байты приходится часто. И читать тонны стандартов. И все это используя такой "кривой" язык как java.
Уходите в embedded программирование, или в куда-нить где научные задачи решают, и вас перестанут раздражать те, кто пишет на java. Будете копаться в своей песочнице

[Ludwig]

Сообщение от Oleg123

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

Нет, все таки доведем до конца, где тут неудобство прочтения? -

function make_incrementor(a)
{
    return function(b) { return a + b; }
}

против где-то 7-8 строк на Джаве (класс + создание объекта), а о количестве слов я не говорю - просто ужас А это еще JavaScript, он вобщем-то вербозный.

Lisp и прочие товарищи с их, пардон, хитрожопыми парадигмами - это такая штука, они даются нелекго, но если однажды ты испытываешь GOT IT, то никто на свете не сможет заставить тебя писать длиннее или мыслить everyting-OO. Сам Лисп используется скорее редко, но он развивает вкус к языкам и программированию вообще, когда начинаешь действительно понимать что красиво а что нет. Тогда к лопате и экскаватору добавляются еще куча супер-кибер-экскаваторов, которые могут вырыть траншею шириной хоть в 1см, хоть в 5м

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


OgreSwamp, нет, это не вопрос того, что я больше не бог или что могу остаться невостребованным - вопрос так не стоит. Собственно уже все сказал в том длинном комменте. Просто сторонникам Джавы и C# следует, мягко говоря, попытаться не защищать свою позицию, потому что это выглядит смешно. Кодируете - кодируйте на здоровье, я сейчас тоже полез в это болото, C# конкретно, но хотя бы не надо защишать эту фигню

[Oleg123]

a и b читаются конечно без проблем, но речь не о том, речь о том что логику кода понять труднее, не говоря уже о бизнес логике, которую этот код представляет. Потому что для описания бизнес логики аналисты часто используют обычный английский язык, а императивные языки ближе к обычным языкам, чем функции.
А быстро понять бизнес логику программером (новичком например), представляемую кодом для бизнеса важнее. Поэтому например у нас на проектах красоту и краткость кода легко приносят в жертву нагладности кода и даже его соответствию видению аналитика, то есть если порой аналитик видит где то цикл, а кодеру проще рекурсию туда воткнуть, то если он все таки воткнет туда рекурсию, то его поправят старшие товарищи. Ужоос. Согласен, но селяви.

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

Сообщение от Ludwig

Нет, все таки доведем до конца, где тут неудобство прочтения? -

function make_incrementor(a)
{
    return function(b) { return a + b; }
}

против где-то 7-8 строк на Джаве (класс + создание объекта), а о количестве слов я не говорю - просто ужас

[Ludwig]

Oleg123:

Аналитики - это вообще отдельная статья. Где-то на днях читал, у кого-то известного, что мол эпоха аналитиков прошла еще 20 лет назад, и что сейчас программисты всё делают сами. Я и сам офигел - как это 20 лет назад, вот же они, полно их вокруг нас, как мух... Но частично правда, что в наше время уже нет жесткой специализации по анализ vs. кодирование, и гибкие компании теперь знают, что в идеале программист сам должен понимать что он делает, без предварительного "анализа".

Так вот, схема анализ -> код -> тестирование и все многочисленные промежуточные фазы применяется в больших, неповоротливых и как результат - неэффективных компаниях. И вот именно для них и созданы Java/C#. Эти языки предназначены для начальников и аналитиков, скорее чем для программистов.

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

[Oleg123]

Сообщение от Ludwig

Oleg123:

Аналитики - это вообще отдельная статья. Где-то на днях читал, у кого-то известного, что мол эпоха аналитиков прошла еще 20 лет назад, и что сейчас программисты всё делают сами. Я и сам офигел - как это 20 лет назад, вот же они, полно их вокруг нас, как мух... Но частично правда, что в наше время уже нет жесткой специализации по анализ vs. кодирование, и гибкие компании теперь знают, что в идеале программист сам должен понимать что он делает, без предварительного "анализа".

Так вот, схема анализ -> код -> тестирование и все многочисленные промежуточные фазы применяется в больших, неповоротливых и как результат - неэффективных компаниях. И вот именно для них и созданы Java/C#. Эти языки предназначены для начальников и аналитиков, скорее чем для программистов.

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

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

[Ludwig]

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

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

Ludwig добавил 23.01.2008 в 16:43

Сообщение от Oleg123

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

Это правда. Но чего не видят те, "плохие" компании, которые неповоротливые, неэффективные итд, что если вместо N высококлассных они берут N * M посредственных за более низкую зарплату, то они могут проиграть in the long run из-за того, что на сопровождение плохого продукта уйдет больше ресурсов. Плохой код и все что его сопровождает - долгий пинг-понг между тQA и программистами, бесконечная вереница патчей итд - увлекает настолько, что начинает казаться нормой, и люди теряют из виду насколько они усложнили себе жизнь. Не стал бы этого утверждать, если бы не видел во многих компаниях.

[Oleg123]

Сообщение от Ludwig

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

возможно все и далеки но императив ближе
http://en.wikipedia.org/wiki/Imperative_programming

[Ludwig]

Oleg123,

Мы вобщем говорим не об imperative vs. functional, а скорее о стиле программирования.

Очень хорошо, я сейчас как раз думал, а чем же в самом деле ОО подход, который в статье IBM, лучше или хуже в смысле читабельности моего варианта на JavaScript?

Предположим я ставлю такую задачу: нужна функция f(a, b) (пусть это будет сложение a и b для простоты) но a меняется гораздо реже b. Это и есть вся задача на человеческом языке.

В JavaScript это записывается в максимально компактной и вполне понятной форме - понятной для тех, кто знает что такое безымянная функция.

Теперь Джава: я вижу в коде

MyGreatClosureClass MyGreatClosureObject = new MyGreateClosureClass();
MyGreateClosureObject.Run();

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

Так что выглядит более человечно?

P.S. там на самом деле должно быть еще
MyGreatClosureObject.b = что-то; - еще одна строка.

[OgreSwamp]

Оу щит, Ludwig
Пожалуй действительно стоит прекратить дискуссию (о чем я говорил в саамом первом посте). Извините канечно, но от вас таки разит максимализмом. На сим откланиваюсь и ухожу из темы. Больше дискутировать не вижу смысла.