Yammer is not satisfied with Scala
Alexander Azarov
Начинать читать лучше здесь http://codahale.com/the-rest-of-the-story/ , чтобы понять историю и причины собственно текста, который тут http://codahale.com/downloads/email-to-donald.txt
Для меня это грустная история, потому что теперь я начинаю подозревать, что это я не один такой, столкнувшийся с проблемами Scala в собственном проекте. Я ощутил проблемы, описанные в "email-to-donald", практически по порядку их перечисления, где-то до середины письма. Возможно, меня и Yammer объединяет то, что мы небольшие компании и проблемы Scala больно ударяют по нашей продуктивности (а я выбрал Scala как раз для того чтобы эту самую продуктивность повысить). И возможно, что крупные компании (Twitter, Foursquare, LinkedIn) этих проблем не видят вовсе.
Фееричные фрагменты "but at some point a best practice emerged: ignore the community entirely" и "We ended up moving to Maven, which isn't pretty but works" вызывают вообще слезы на глазах, потому что это я очень прочувствовал на собственной шкуре.
От себя могу добавить, что это замечательное чтиво наиболее полезно CTO небольших стартапов, поскольку именно их риски наиболее хорошо расписаны в письме.
OlegYch
противоположно.
Не могу только судить о перфомансе, но полагаю что Trove или Colt
очевидно быстрее :)
Кстати конкретные проблемы было бы интересно обсудить.
On Nov 30, 1:37 pm, Alexander Azarov <alaz...@gmail.com> wrote:
> Очень интересная история о том, как Yammer думает переходить с Scala
> обратно на Java.
>
> Начинать читать лучше здесьhttp://codahale.com/the-rest-of-the-story/,
> чтобы понять историю и причины собственно текста, который тутhttp://codahale.com/downloads/email-to-donald.txt
OlegYch
Примерно то, что я хотел сказать, но не смог выразить :)
Eugene Dubrovka
Alexander Azarov
On Thursday, December 1, 2011 10:10:19 AM UTC+4, Eugene Dubrovka wrote:
Спасибо за историю!Каждый раз, когда я пытаюсь протолкнуть скалу в проект у себя в конторе или у заказчика мне на встречу сразу вопросы:- а что с перформансом? ты уверен, что все так хорошо? а кто будет еще саппортить, кроме тебя?- А что с библиотеками?- а что это за "смайлики" и "елочки" и кто это поймет?
А я могу Вам еще вопросы задать:
- а можно ли будет быстро расширить команду? удастся ли найти разработчиков на Scala?
- поймут ли новые разработчики неявный code style существующей команды? как долго даже опытный Scala разработчик будет привыкать и понимать идеологию существующего проекта?
- какой процент времени разработчики будут тратить на выработку единых patterns в проекте?
- насколько много времени будет уходить на обучение внутри команды
- есть ли риски возникновения кода, который понимает только кто-то один из команды? (скажем, он напишет некий компонент с использованием scalaz, который остальные не понимают)
Я, не имея достаточного опыта, пока не могу ответить на эти вопросы так, чтобы действительно было "быстро", "хорошо", "любой толковый", "все нормально", "это код" и аргументированно.Лично меня эта тема интересует очень сильно. Как мне убедить начальника использовать скалу? Как ввести полного новичка в скалу? С чего лучше всего начать?Я периодически и сам пытаюсь ответить себе на эти вопросы, но еще далеко не уверен.
Не существует ответов на поставленные вопросы, общих и единых для всего многообразия команд и проектов.
Поэтому обсудить такую тему было бы просто супер!
1 декабря 2011 г. 1:40 пользователь OlegYch <oleg...@gmail.com> написал:
Пункты достаточно очевидные. Лишь насчет комьюнити мое мнение
противоположно.
Не могу только судить о перфомансе, но полагаю что Trove или Colt
очевидно быстрее :)
Кстати конкретные проблемы было бы интересно обсудить.
Eugene Dubrovka
Ilya Klyuchnikov
Stanislav Lakhtin
попробовать ответить на эти вопросы
On 1 дек, 11:05, Alexander Azarov <alaz...@gmail.com> wrote:
> On Thursday, December 1, 2011 10:10:19 AM UTC+4, Eugene Dubrovka wrote:
>
> > Спасибо за историю!
>
> > Каждый раз, когда я пытаюсь протолкнуть скалу в проект у себя в конторе
> > или у заказчика мне на встречу сразу вопросы:
> > - а что с перформансом? ты уверен, что все так хорошо? а кто будет еще
> > саппортить, кроме тебя?
Вопросы обучения программистов Scala имеют колоссальную сложность. В
лоб не решаются, мы даже открыли факультет подготовки в ВУЗе
(коммерческом), но пока очевидных сдвигов нет.
> > - А что с библиотеками?
ППЦ. Непримиримая позиция Мартина ко всему, что не освящено их
божественным гением приводит к тому, что Scala живёт как бы сама по
себе, а остальные сами по себе. С вопросами переносимости библиотек
между релизами Scala идут в грубонедоступные места разработчиков самих
библиотек.
> > - а что это за "смайлики" и "елочки" и кто это поймет?
Мало кто поймёт. Трудность вхождения очень высока.
> А я могу Вам еще вопросы задать:
>
> - а можно ли будет быстро расширить команду? удастся ли найти разработчиков
> на Scala?
Вероятнее всего нет, только воспитать.
> - поймут ли новые разработчики неявный code style существующей команды? как
> долго даже опытный Scala разработчик будет привыкать и понимать идеологию
> существующего проекта?
Быстро, если он опытный разработчик, то, фактически, сразу. Проблема
по сути в том, что надо быть действительно хорошим разработчиком,
способным к манипулированию неиспользуемых доселе математических
понятий.
> - какой процент времени разработчики будут тратить на выработку единых
> patterns в проекте?
Это скорее философия, чем программирование. Аккуратнее с DSL. Это
касается также использования возможностей Scala в принципе. Есть
некоторые понятия, которые попросту не стоит использовать.
> - насколько много времени будет уходить на обучение внутри команды
Боевой программист обучается на Scala около года до приемлемого
уровня. Профит от него начинается через пару месяцев. Если он конечно,
действительно, неплохой программист. Мусор не обучается в принципе.
Очень высокий порог вхождения + наша высшая школа не даёт необходимой
компетенции.
> - есть ли риски возникновения кода, который понимает только кто-то один из
> команды? (скажем, он напишет некий компонент с использованием scalaz,
> который остальные не понимают)
Запросто. В кашу можно превратить проект на раз-два;
>
> Я, не имея достаточного опыта, пока не могу ответить на эти вопросы так,
>
> > чтобы действительно было "быстро", "хорошо", "любой толковый", "все
> > нормально", "это код" и аргументированно.
> > Лично меня эта тема интересует очень сильно. Как мне убедить начальника
> > использовать скалу? Как ввести полного новичка в скалу? С чего лучше всего
> > начать?
Просто начать. Исследования будут идти за ваш счёт около года. Потом
будет легче.
> > Я периодически и сам пытаюсь ответить себе на эти вопросы, но еще далеко
> > не уверен.
>
> Не существует ответов на поставленные вопросы, общих и единых для всего
> многообразия команд и проектов.
Есть ответы. Фактически большой разницы между командами не существует.
С автором статьи можно согласиться только отчасти. Такие же проблемы
могли привести команду с Java на C++. В сущности своей Scala
навязывает вам подход, оставляющий вас наедине со своими проблемами.
> >> > Фееричные фрагменты "but at some point a best practice emerged: ignore
> >> the
> >> > community entirely" и "We ended up moving to Maven, which isn't pretty
> >> but
> >> > works" вызывают вообще слезы на глазах, потому что это я очень
> >> > прочувствовал на собственной шкуре.
Странно, что услышаны были только эти ребята. Про это говорят уже года
три все подряд.
> >> > От себя могу добавить, что это замечательное чтиво наиболее полезно CTO
> >> > небольших стартапов, поскольку именно их риски наиболее хорошо
> >> расписаны в
> >> > письме.
Не стоит относиться к этому письму так. Читайте продолжение истории
http://codahale.com/the-rest-of-the-story/
Вопрос не в том риски это или не риски. Лучше Scala или хуже Java. Это
просто пустой холивар.
Artyom Olshevskiy
О боже мой, gcc не инлайнит вызовы, если их нужно лукапить в таблице виртуальных методов. Или что-то навроде того.
Неужели те миллисекунды, что вы экономите на использовании ванильных Java-коллекций не ведут к усложнению кода во столько же раз во сколько он стал быстрее.
Ведь есть же реальные success story использования Scala. Мне кажется или данный пост также как a letter to Donald написаны тем, кто просто неразобравшись пишет Java-style Scala-код. В таком случае видимое отсутствие приемуществ вызвано незнанием абстракций предоставляемых языком. Так бывает, но стоит всё-таки приложить усилия прежде, чем пенять на язык. Ведь ничто не даётся бесплатно. Зато у вас есть шанс выработать best practice и, поделившись им с комьюнити, принести пользу многим.
Я обязательно напишу бенчмарк для for'ов, коллекций и замыканий.
Alexander Azarov
02.12.2011, в 9:50, Stanislav Lakhtin написал(а):
> Как руководитель компании имеющей кучу боевого софта на Scala могу
> попробовать ответить на эти вопросы
>> - есть ли риски возникновения кода, который понимает только кто-то один из
>> команды? (скажем, он напишет некий компонент с использованием scalaz,
>> который остальные не понимают)
> Запросто. В кашу можно превратить проект на раз-два;
>>>>>
>>>>> Для меня это грустная история, потому что теперь я начинаю подозревать,
>>>> что
>>>>> это я не один такой, столкнувшийся с проблемами Scala в собственном
>>>>> проекте. Я ощутил проблемы, описанные в "email-to-donald", практически
>>>> по
>>>>> порядку их перечисления, где-то до середины письма. Возможно, меня и
>>>> Yammer
>>>>> объединяет то, что мы небольшие компании и проблемы Scala больно
>>>> ударяют по
>>>>> нашей продуктивности (а я выбрал Scala как раз для того чтобы эту самую
>>>>> продуктивность повысить). И возможно, что крупные компании (Twitter,
>>>>> Foursquare, LinkedIn) этих проблем не видят вовсе.
> С автором статьи можно согласиться только отчасти. Такие же проблемы
> могли привести команду с Java на C++. В сущности своей Scala
> навязывает вам подход, оставляющий вас наедине со своими проблемами.
>>>>> Фееричные фрагменты "but at some point a best practice emerged: ignore
>>>> the
>>>>> community entirely" и "We ended up moving to Maven, which isn't pretty
>>>> but
>>>>> works" вызывают вообще слезы на глазах, потому что это я очень
>>>>> прочувствовал на собственной шкуре.
> Странно, что услышаны были только эти ребята. Про это говорят уже года
> три все подряд.
>>>>> От себя могу добавить, что это замечательное чтиво наиболее полезно CTO
>>>>> небольших стартапов, поскольку именно их риски наиболее хорошо
>>>> расписаны в
>>>>> письме.
> Не стоит относиться к этому письму так. Читайте продолжение истории
> http://codahale.com/the-rest-of-the-story/
> Вопрос не в том риски это или не риски. Лучше Scala или хуже Java. Это
> просто пустой холивар.
Vasil Remeniuk
>> на Scala?
В качестве примера, могу привести свой недавний опыт, когда под-
команду надо былу расширить на 1 разработчика.
Принципиальная позиция менеджмента была не привлекать разработчика
извне (рынка, или остальной компании), а использовать ресурсы
существующей команды (чтобы минимизировать объем дополнительных
согласований с заказчиком).
В итоге, команда была расширена senior Java-разработчиком, который в
прошлом имел небольшой опыт в Python. Целью было скорейшее вовлечение
его в существующий, достаточно большой проект на Scala/Lift/SBT. Сразу
скажу, что уже через 4-5 дней, освоившись с окружением, он начал
коммитать код.
>> - поймут ли новые разработчики неявный code style существующей команды?
Я знаю только два код-стайла:
- принятый коммьюнити, Scala Code Style (на который постепенно
переходят все open-source проекты);
- Lift code style;
Мы используем первый, и разъяснение тонкостей занимает полчаса.
Для поддержки единого стиля форматирования кода, мы испольщуем sbt-
scalariform (что, в общем, тоже является общепринятой практикой).
>> как долго даже опытный Scala разработчик будет привыкать и понимать идеологию
>> существующего проекта?
Это зависит в большей мере от используемых фреймворков, потому что
основная идеология заложена в них (см. Lift или Akka).
>> - какой процент времени разработчики будут тратить на выработку единых
>> patterns в проекте?
За 1.5 года разработки почти чисто на Scala наша команда с такой
проблемой не сталкивалась. Есть OOP-паттерны, большая часть из которых
просто не нужна, и есть enterprise- и messaging-паттерны, которые не
надо переизобретать.
>> - насколько много времени будет уходить на обучение внутри команды
Возвращаясь к недавнему экспириенсу с добавлением в команду не-Scala-
разработчика, затраты по времени были следующие:
- новый разработчик пробежался по книге Programming Scala (2-3
вечера), активно изучая, одновременно с этим, codebase проекта;
- достаточно хорошо изучил драфт книги Simply Lift;
- после каждого коммита делался код-ревью с предложениями по
улучшениям (благодаря которым осваивались тонкости языка и
фреймворков);
- час-полтора в день на ответы на вопросы в течение первой недели,
около получаса в течение второй-четвертой;
Сейчас код нового разработчика по стилю неотличим от кода, написанного
ранее.
>> - есть ли риски возникновения кода, который понимает только кто-то один из
>> команды? (скажем, он напишет некий компонент с использованием scalaz,
>> который остальные не понимают)
Проблема не специфична для Scala. Такие риски есть, как и при
разработке на любом другом языке. Java-разработчик, в команде,
использующей только примитивные абстракции для канкаренси
(synchronization, executor service'ы), может создать компонент, в
котором требуется низкий lock contention и высокая пропусканя
способность, с обильным использованием CAS-операций, и STM-стиля,
которые другие члены команды не понимают. Или использовать библиотеку
Guava, для работы с коллекциями или строками.
Vasil Remeniuk
они подразумевают совершенно конкретного его члена - Тони Морриса
(http://twitter.com/dibblego), а когда говорят о сложности языка,
библиотеку (во многом) рук Тони Морриса - scalaz.
Несмотря на то, что я лично использую scalaz достаточно ограничено
(promises, validation, иногда state и reader), мое твердое убеждение
состоит в том, что у программиста должен быть достаточный уровень
математической образованности, чтобы не называть MA Sugar (http://
scalaz.github.com/scalaz/scalaz-2.9.1-6.0.2/doc.sxr/scalaz/
MA.scala.html#17903) непонятными точечками и стрелочками. Иначе,
друзья, мы деградируем до того уровня, что следующее поколение
разработчиков будет называть "+" непонятным крестиком, "*" непонятной
звездочкой, и требовать вместо этого писать "нормальные" plus(a, b)
или mult(a,b), потому что так информацию об операциях проще нагуглить.
> ...
>
> read more >>
OlegYch
кроме Тони резкостью отличаются RShulz и extempore, но мне это никогда
не мешало.
Если сравнить например с #java на фриноде - от етих товарищей по
крайней мере всегда можно услышать аргументированное мнение
подкрепленное опытом.
Насчет scalaz могу лишь сказать что у меня бывали случаи когда
разработчики и на guava смотрели широко закрытыми глозами, плевались,
но, при должном гайдансе, работали.
> > > > по сути в том, что надо быть действительно хорошим разработчиком,...
>
> read more >>
Vasil Remeniuk
-----
Twitter: twitter.com/remeniuk
Blog: vasilrem.com
Github: github.com/remeniuk
Scala Enthusiasts Belarus: scala.by
OlegYch
доверять.
Конечно насчет необходимости годового обучения немного сомнительно :)
Бенчмарков уже писано много. ScalaCL возник не на пустом месте.
Alexander Azarov
Поясню чем меня лично привлек отзыв Coda Hale. Именно тем, что он скорее "warning story" о трудностях внедрения Scala. Вызывает доверие то, что письмо написано "по заказу" команды Typesafe, а не ради холивара или show off -- это реальный (и достаточно интимный, письмо не предназначалось для широкой публики) опыт внедрения в конкретном проекте. Еще раз подчеркну, тем более ценный, что выявляет некоторые проблемы.
03.12.2011, в 12:31, Vasil Remeniuk написал(а):
Vasil Remeniuk
ждут сколько угодно адекватных нападок на Scala, чтобы можно было
облегченно выдохнуть с мыслью о том, что не придется учить "этот
сложный язык"... Они с таким упоением обсуждают проблемы Scala, что
может на мгновение показаться, что Java-мире все безоблачно и
прекрасно...
Лично на меня опус Coda Hale не произвел большого впечатления. Он
больше похож на обиженное нытье, которые было написано под [плохое]
настроение, под впечатлением от одного, конкретного, заваленного
проекта. Я достаточно уверенно могу утверждать это, потому что не
далее как полгода назад, на NyScala, Coda, и его сокомандники
заливались соловьями о том, как им здорово живется на Scala.
- Collections в Scala построены таким образом, что "ужасы", которые с
таким смаком описывает Coda, надежно скрыты от потребителя. Сложность
использования коллекций _сильно_ преувеличена, и оценка Coda скорее
вводит новичков в заблуждение;
- Поливать SBT грязью только потому, что он не удовлетворяет нуждам
команды Coda (и ему часто приходится переизобретать велосипед), по-
моему, совсем неправильно;
- Мое субъективное мнение от Scala-коммьюнити на stackoverflow (как
активного его участника, српшивальщика и отвечальщика --
http://stackoverflow.com/tags/scala/topusers) кардинально отличное:
- сам Мартин не гнушается отвечать там на вопросы;
- если вы напишете не слишком хороший ответ/вопрос в Java-ветке,
вас яростно будут минусовать. Если очень хороший - врядли кто-то
поставит "+". В scala-ветке вы реально можете почувствовать
appreciation;
> ...
>
> read more >>
Alexander Azarov
03.12.2011, в 23:55, Vasil Remeniuk написал(а):
> У меня иногда возникает чувство, что члены Java-коммьюнити только и
> ждут сколько угодно адекватных нападок на Scala, чтобы можно было
> облегченно выдохнуть с мыслью о том, что не придется учить "этот
> сложный язык"... Они с таким упоением обсуждают проблемы Scala, что
> может на мгновение показаться, что Java-мире все безоблачно и
> прекрасно...
Василь, не надо пожалуйста переводить разговор в холивар Java vs. Scala.
> Лично на меня опус Coda Hale не произвел большого впечатления. Он
> больше похож на обиженное нытье, которые было написано под [плохое]
> настроение, под впечатлением от одного, конкретного, заваленного
> проекта.
> Я достаточно уверенно могу утверждать это, потому что не
> далее как полгода назад, на NyScala, Coda, и его сокомандники
> заливались соловьями о том, как им здорово живется на Scala.
> - Collections в Scala построены таким образом, что "ужасы", которые с
> таким смаком описывает Coda, надежно скрыты от потребителя. Сложность
> использования коллекций _сильно_ преувеличена, и оценка Coda скорее
> вводит новичков в заблуждение;
> - Поливать SBT грязью только потому, что он не удовлетворяет нуждам
> команды Coda (и ему часто приходится переизобретать велосипед), по-
> моему, совсем неправильно;
Еще смешно: а почему неправильно? И что правильно? Только хвалить? (так все и хвалят)
> - Мое субъективное мнение от Scala-коммьюнити на stackoverflow (как
> активного его участника, српшивальщика и отвечальщика --
> http://stackoverflow.com/tags/scala/topusers) кардинально отличное:
> - сам Мартин не гнушается отвечать там на вопросы;
> - если вы напишете не слишком хороший ответ/вопрос в Java-ветке,
> вас яростно будут минусовать. Если очень хороший - врядли кто-то
> поставит "+". В scala-ветке вы реально можете почувствовать
> appreciation;
Vasil Remeniuk
of time, при котором все всё равно остаются при своем мнении :)
>> Yammer не является заваленным проектом
В рамках yammer, как организации, могут быть небольшие проекты - я не
говорил о всей сети целиком
>> "поливать грязью"
Поливать грязью, значит характеризовать проект с использованием
выражений: "crazy", "burden", ''impenetrable", "idioglossy", etc etc
>> Еще смешно: а почему неправильно?
Когда меня перестал удовлетворять ant, я не говорил, что те, кто его
используют - crazy. Я молча переехал на maven (а потом - на sbt).
>> Не видел. Коль заливались, так это потому что выступали на девелоперской конференции. Чем еще на ней заниматься-то.
Вы склонны верить случайно просочившемуся письму, которое Coda
написал, когда у него, возможно, живот болел. Я склонен доверять его
репорту на конференции :)
> ...
>
> read more >>
Alexander Azarov
04.12.2011, в 0:53, Vasil Remeniuk написал(а):
>>> Не видел. Коль заливались, так это потому что выступали на девелоперской конференции. Чем еще на ней заниматься-то.
> Вы склонны верить случайно просочившемуся письму, которое Coda
> написал, когда у него, возможно, живот болел. Я склонен доверять его
> репорту на конференции :)
Vasil Remeniuk
Artyom Olshevskiy
Stanislav Lakhtin
Наша команда до сих пор на Scala потому что всё что нам было нужно мы
написали себе сами, и сейчас это используем. Нас всё устраивает с
точки зрения текущей функциональности, стройности, красоты кода,
эффективности реализации и контроля сложности. Мы имеем твердое
убеждение, что на существующем уровне мы можем эффективно решать наши
задачи еще не один год. Нам в целом безразлично развитие Scala, потому
что никто не может сказать как будет развиваться та или иная
технология. Когда-то тоже казалось что Java это технология на
десятилетия.
> >> - есть ли риски возникновения кода, который понимает только кто-то один из
> >> команды? (скажем, он напишет некий компонент с использованием scalaz,
> >> который остальные не понимают)
> > Запросто. В кашу можно превратить проект на раз-два;
>
> Из этого следует, что team lead должен тратить больше времени на контроль проекта и кода? Как Вы у себя с этим боретесь?
Да, к сожалению team lead должен много своего времени тратить на
контроль кода. Как-то справляемся инквизиционными методами.
> Я мог быть невнимателен, но все коммьюнити пишет о счастье от SBT и я не видел массовых жалоб на этот проект. Также, я чаще вижу радостные высказывания об отзывчивости и готовности помочь в Scala community, нежели "ignore the community entirely" -- Вы видели такое не раз?
Возможно, вы правы. Давайте я не буду доказывать нашу точку зрения, а
вы оставите своё мнение об этом такое, какое хотите.
> Не знаю, кому Вы эту ссылку рекомендуете, но хочу обратить Ваше внимание, что она есть в начале топика.
Да, прошу прощения за повтор.
> Ну тогда я буду признателен, если Вы ответите только на вопросы о Вашем опыте, а холивар ниже можно убить.
OlegYch
подход, но, к сожалению, фэйлы становятся публичными гораздо реже чем
истории успеха.
Потому важно каждый случай разбирать подробно и экстраполировать.
Конкретно, господа, интересны ваши мнения по следующим аспектам.
Какие фичи скалы нужно учить год чтобы понять (например человеку с
высшим образованием)?
Так же не ясно какая конкретно фича ведет к написанию непонятного
кода.
Я видел много говнокода, и сделал вывод, что чем более ограничен язык
в средствах создания абстракций - тем проще писать кашу.
Есть предположение, что без поддержки IDE довольно сложно узнать
назначение метода с символьным именем или понять откуда появляется
implicit.
Но ведь мы не в ed пишем?
Спасибо, Олег.
Vasil Remeniuk
>> высшим образованием)?
По личному опыту, могу сказать, что изучение разных теоретисеских
аспектов, которые реализованы в языке, или повлияли на определенные
решения в дизайне библиотек, можно потратить намного больше года. Я
перестал читать теоретическую литературу по типизации, функциональному
программированию и актерам спустя полтора года, посла старта изучения
Scala, и начал, в большинстве случаев, использовать уже накопленные
знания (может именно это имел ввиду Coda Hale в своем письме? ;-)),
потому что в болото теории можно было увязнуть только глубже, а
времени на освоение чего-то, кроме языка, уже не оставалось :-)
OlegYch
LYAHFG и RWH перманентно в стеке литературы к прочтению. Скорее не
стек, а приоритетная очередь :(
Stanislav Lakhtin
> Конкретно, господа, интересны ваши мнения по следующим аспектам.
> Какие фичи скалы нужно учить год чтобы понять (например человеку с
> высшим образованием)?
Друзья, я отвечаю не сам Вам на этот вопрос. Я попросил одного из
наших новых программистов описать свой личный опыт от своего лица,
чтобы это заявление не было просто болтовнёй "какого-то кренделя
издалека и тем более руководителя". Вот ссылка http://advprog.ru/articles/Programming-in-Scala
> Так же не ясно какая конкретно фича ведет к написанию непонятного
> кода.
На это там тоже есть пара примеров
> Я видел много говнокода, и сделал вывод, что чем более ограничен язык
> в средствах создания абстракций - тем проще писать кашу.
Лично у меня самый большой бэкграунд в Java/C++, но приходилось писать
на много чём. Я могу сказать, что чем изощрённее язык, тем больше
шансов написать фигню. Тут просто элементарная логика заложена.
> Есть предположение, что без поддержки IDE довольно сложно узнать
> назначение метода с символьным именем или понять откуда появляется
> implicit.
> Но ведь мы не в ed пишем?
Безусловно нет. Мы покупаем и работаем в Intellij IDEA. Однако одно
утверждение лишь частично отражает проблему. Дело в том, что IDE
только помогает управлять сложностью, но сама по себе сложность --
суть понятие абсолютное. Она никуда не девается, не "рассасывается", и
всё программирование всегда сводится к управлению этой сложностью. Мне
не хотелось бы сыпать примеры, они только отвлекают, но способность
ясно читать чужой код -- это основа повторного использования кода.
Если чужой код Вы можете читать только с помощью IDE -- это
недопустимо плохо. Это не просто плохо, это говорит о том, что этот
кусок программного обеспечения требует немедленной замены.
Vasil Remeniuk
наших новых программистов описать свой личный опыт от своего лица,
чтобы это заявление не было просто болтовнёй "какого-то кренделя
издалека и тем более руководителя". Вот ссылка http://advprog.ru/articles/Programming-in-Scala
Мне вот как раз ссылочку в тему ссылочку кинули:
"I graduated from university about five months ago, and have been
working in a local startup for past four months. While at university,
I studied Haskell, F# etc on my own. We were taught Java at the
university, but I was exposed to functional programming very soon, and
have spent far more time with it than I did with imperative
programming. As a result, my brain is wired for a functional thinking.
The company I have joined uses Python, and the code is heavily
imperative. I am having a very hard time reading imperative code. I
cannot keep a track of mutations. When an for-if-else-for-... nesting
goes more than four levels deep, I completely lose the track of what's
happening in the code. To add to it, Python is a dynamic language, so
there are no types in the code. It's been weeks since I have been
trying to understand a part of our codebase (which is supposedly
'moderately complex'), but I haven't made any appreciable progress so
far in understanding it. Please offer me some practical techniques on
how I should go about understanding that code. Thanks in advance!"