Здравствуйте, Aikin, Вы писали:

I>>, но тогда странно, почему возникают проблемы — вроде "отрефакторить всегда успеешь" и при этом то по твоим словам приходится переписывать.
A>Меняются обстоятельства. Я в той ветке об этом говорил.

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

Здравствуйте, Ikemefula, Вы писали:

I>Ахинея : "стоит начинать с архитектуры (даже тогда, когда ТЗ ещё не до конца осмыслено и разработано)"
I>Это утверждение ниоткуда не следует, ты сам его вбросил, приписав идею мифическим "апологеты ООП/ООД считают"
Хорошо. Допустим я сам придумал ООП/ООД апологетов и то, что разработка "сверху вниз" является доминирующим подходом в среде этих апологетов. Хотя, в подтверждении своей "ахинеи", я ещё в начале треда привёл ссылку на мнение о дискусии OOPSLA, где подобной "ахинеей" страдали такие господа, как Пол Грэм и Александр Степанов. Но всё же предположим, что ты просто не внимательно прочёл тред и влетел в обсуждение с термоядерным батхёртом (неизвестного происхождения). Это можно как-то простить.
Но как быть с этим:
I>Ты придумал какую то ахинею и сам её опроверг, малатца!
Где опровержение и противоречие в моих словах?

I>"не выпустить его или выпустить не своевременно" это уже следствие. Не бывает просто так, от балды, "не выпустить" или "выпустить не своевременно". Если говорить про код, то первая из причин это перетачивание прототипа в продакшн.
Нет, бывает. И ещё как бывает. Например, ввиду того, что нужно выпустить продукт раньше намеченного строка. Скажем, разведка доложила, что конкуренты вот-вот на днях зарелизятся.

I>Ссылкой не поделишься?
Нет, не поделюсь. Для начала мне нужно убедиться, что я разговариваю с разумным человеком, а не с воинствующей макакой. Извольте сначала "пояснить" за опровержения/противоречия в моих словах. А то начну тут зазря бисер метать.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, nullxdth, Вы писали:

N>>Нет, не одинаково сомнительны. В первом случае имеет место быть шаблонный код — копипаста. В лучшем случае, для избавления от boilerplate'а мы можем завести промежуточные переменные, но это лишние переменные — т.е. лишние подробности извлечения фрагментов.
S>Совершенно непонятно, лишние они или нет. Всё потому, что вы описываете сферическую задачу, где ни семантика, ни дальнейшая судьба этих a и b совершенно неясны. Неясно, насколько часто меняется структура JSON. Неясно, к каким изменениям надо быть готовым, а каких можно не ждать. Неясно, сколько деталей важно прикладному программисту для понимания ситуации.
Хорошо. Попробуем ещё раз. Коли не очевидно.
Допустим у нас есть следующая структура:

{"person": {"first_name": "...",
            "last_name":  "...",
            
            "tel":   {"home":   "...",
                      "office": "...",
                      "extra":  "..."}
            
            "email": {"home":   "...",
                      "office": "...",
                      "extra":  "..."}}}

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

result = get_person("Vasya") # result - лишняя сущность (полная информация не нужна)

# Далее идёт очевидная копипаста:
first_name  = result['person']['first_name']
extra       = result['person']['tel']['extra']
office      = result['person']['tel']['office']
home        = result['person']['email']['home']
email_extra = result['person']['email']['extra']

Или так:

person = get_person()['person']    # person - лишнаяя сущность (полная информация не нужна)

first_name = person['first_name']

tel = person['tel']                # tel - лишняя сущность (полная информация о телефонах не нужна)

extra  = tel['extra']              # tel, tel - копипаста
office = tel['office']             #

email = person['email']            # email - лишняя сущность (полная информация о ящиках не нужна)

home        = email['home']        # email, email - копипаста
email_extra = email['extra']       #

А теперь, допустим, мы программируем на CoffeeScript и знаем, что такое Destructuring Assignment.
Говорим так:

{person:
 {first_name,
  tel:   {extra, office},
  email: {home, extra: email_extra}}} = get_person('Vasya')

И получаем в скоупе: first_name, extra, office, home, email_extra и больше ничего. Тут нет ни копипасты, ни лишних сущностей — мы абстрагировались от лишних деталий извлечения информации.
Ещё есть какие-нибудь вопросы? Или это тоже сферическая задача?

S>Не понял, что вы называете копипастой. Покажите, какие именно фрагменты кода вы считаете копипастой, и куда они деваются в вашем коде.
Выше.

S>Простой и очевидный способ записать решение этой задачи вам кажется бойлерплейтом (json["foobar"]["long_long_field"]["a"]).
А вам не кажется? Ведь это и есть boilerplate, когда по foobar или foobar->long_long_field нам нужно извлечь более чем один ключ.

S>Зато способ, где пути пишутся слева от переменных, вам кажется "высокоуровневым" и "небойлерплейтом", хотя отличается только порядком аргументов, типом скобочек, и символами цитирования.
Не кажется. Это действительно более высокоуровневое решение. И отличается оно не только синтаксисом, как было показано выше.

Здравствуйте, Ikemefula, Вы писали:

I>>>, но тогда странно, почему возникают проблемы — вроде "отрефакторить всегда успеешь" и при этом то по твоим словам приходится переписывать.
A>>Меняются обстоятельства. Я в той ветке об этом говорил.
I>Обстоятельства всегда меняются. Собтсвенно рефакторинг нужен именно по этой причине — слишком часто приходится влазить и читать/править уже написаный работающий код.
Ну я, эта, согласен. Вот только не понял к чему ты это сказал.

СУВ, Aikin

Здравствуйте, nullxdth, Вы писали:

N>Но как быть с этим:
I>>Ты придумал какую то ахинею и сам её опроверг, малатца!
N>Где опровержение и противоречие в моих словах?

Цтирую некоторую воинствующую макаку, не умеющую читать:

"Практика же показывает совершенно обратное. Что, собственно, и пытаются объяснить некторые господа в этом треде.
Я, также как и эти господа, считаю, что стоит начинать с прототипа. В таком подходе есть несколько преимуещств: во-первых, при разработки прототипа выявляются действительные и, на первый взгляд, совершенно не очевидные проблемы; а, во-вторых, если будут поджимать сроки, то в свет можно выпустить какой-никакой продукт (довести до нужной кондиции прототип) и таким образом выпустить продукт быстрее чем конкуренты.
Если говорить короче, то вместо занятий "астронавтикой", в, подавляющем большинстве случаев, лучше начать писать."

I>>"не выпустить его или выпустить не своевременно" это уже следствие. Не бывает просто так, от балды, "не выпустить" или "выпустить не своевременно". Если говорить про код, то первая из причин это перетачивание прототипа в продакшн.
N>Нет, бывает. И ещё как бывает. Например, ввиду того, что нужно выпустить продукт раньше намеченного строка. Скажем, разведка доложила, что конкуренты вот-вот на днях зарелизятся.

То есть, конкретная причина "разведка доложила" есть "от балды" ? Браво !

I>>Ссылкой не поделишься?
N>Нет, не поделюсь. Для начала мне нужно убедиться, что я разговариваю с разумным человеком, а не с воинствующей макакой. Извольте сначала "пояснить" за опровержения/противоречия в моих словах. А то начну тут зазря бисер метать.

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

Здравствуйте, Ikemefula, Вы писали:

N>>Но как быть с этим:
I>>>Ты придумал какую то ахинею и сам её опроверг, малатца!
N>>Где опровержение и противоречие в моих словах?

I>Цтирую некоторую воинствующую макаку, не умеющую читать:
I>

I>"Практика же показывает совершенно обратное. Что, собственно, и пытаются объяснить некторые господа в этом треде.
I>Я, также как и эти господа, считаю, что стоит начинать с прототипа. В таком подходе есть несколько преимуещств: во-первых, при разработки прототипа выявляются действительные и, на первый взгляд, совершенно не очевидные проблемы; а, во-вторых, если будут поджимать сроки, то в свет можно выпустить какой-никакой продукт (довести до нужной кондиции прототип) и таким образом выпустить продукт быстрее чем конкуренты.
I>Если говорить короче, то вместо занятий "астронавтикой", в, подавляющем большинстве случаев, лучше начать писать."

И где тут опровержение/противоречие?

I>>>"не выпустить его или выпустить не своевременно" это уже следствие. Не бывает просто так, от балды, "не выпустить" или "выпустить не своевременно". Если говорить про код, то первая из причин это перетачивание прототипа в продакшн.
N>>Нет, бывает. И ещё как бывает. Например, ввиду того, что нужно выпустить продукт раньше намеченного строка. Скажем, разведка доложила, что конкуренты вот-вот на днях зарелизятся.
I>То есть, конкретная причина "разведка доложила" есть "от балды" ? Браво !
Да, действительно. "Разведка доложила" — это вовсе не "от балды". Это одна из обоснованных и весомых причин выпуска доработанного прототипа. Не придирайся к словам, ведь из контекста ясно, что имелось ввиду.

I>>>Ссылкой не поделишься?
N>>Нет, не поделюсь. Для начала мне нужно убедиться, что я разговариваю с разумным человеком, а не с воинствующей макакой. Извольте сначала "пояснить" за опровержения/противоречия в моих словах. А то начну тут зазря бисер метать.
I>Ты похоже о чем то своём, наболевшем. Не буду тебя беспокоить.
Нет. Я спросил тебя в очередной раз за противоречия в моих словах. Ты же продалжаешь своё бессмысленный батхёрт.

Здравствуйте, 0x7be, Вы писали:


__>>что такое работа программиста? чем занимается программист? он просто излагает свои мысли насчет устройства программы в виде кода.
__>>откуда у него возникнут другие мысли для написания другово кода? это как в России — какую партию не делай, КПСС получается.
0>Дык, опыт своих же ошибок дает прекрасную пищу для улучшения.
0>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
0>Собственно, это ключевая идея прототипирования

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

А вот на счет классного кода, то лучший код это код после 5-6 фаз глубокого рефакторинга. При чем рефакторинга не от балды "шоб красивее було", а с конкретной целью — сделать код более понятным, сделать код более тестируемым, сделать код более гибким, реюзабельным и тд. За рефакторинг без четко поставленых целей надо убивать на месте.

Здравствуйте, Ikemefula, Вы писали:

I>Ключевая идея прототипирования это не получение классного кода, а сбор требований, выявление имеющихся проблем и выявление всевозможных депенденсов и ответ на вопрос — решаема ли задача в заданном контексте.
I>То есть, другими словами, разведка боем.
I>А вот на счет классного кода, то лучший код это код после 5-6 фаз глубокого рефакторинга. При чем рефакторинга не от балды "шоб красивее було", а с конкретной целью — сделать код более понятным, сделать код более тестируемым, сделать код более гибким, реюзабельным и тд. За рефакторинг без четко поставленых целей надо убивать на месте.

Это верно. Собственно, 0x7be (а также я, Aikin и другие господа) это и имеют ввиду, говоря про лучший код. И с кем ты тут боришься совершенно не ясно.

Здравствуйте, diez_p, Вы писали:

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

Рефакторинг начинается с цели. Если цель — уложить новый функционал, то следующий шаг — дизайн.

Здравствуйте, nullxdth, Вы писали:

I>>А вот на счет классного кода, то лучший код это код после 5-6 фаз глубокого рефакторинга. При чем рефакторинга не от балды "шоб красивее було", а с конкретной целью — сделать код более понятным, сделать код более тестируемым, сделать код более гибким, реюзабельным и тд. За рефакторинг без четко поставленых целей надо убивать на месте.

N>Это верно. Собственно, 0x7be (а также я, Aikin и другие господа) это и имеют ввиду, говоря про лучший код. И с кем ты тут боришься совершенно не ясно.

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

Здравствуйте, nullxdth, Вы писали:

I>>Цтирую некоторую воинствующую макаку, не умеющую читать:
I>>

I>>"Практика же показывает совершенно обратное. Что, собственно, и пытаются объяснить некторые господа в этом треде.
I>>Я, также как и эти господа, считаю, что стоит начинать с прототипа. В таком подходе есть несколько преимуещств: во-первых, при разработки прототипа выявляются действительные и, на первый взгляд, совершенно не очевидные проблемы; а, во-вторых, если будут поджимать сроки, то в свет можно выпустить какой-никакой продукт (довести до нужной кондиции прототип) и таким образом выпустить продукт быстрее чем конкуренты.
I>>Если говорить короче, то вместо занятий "астронавтикой", в, подавляющем большинстве случаев, лучше начать писать."

N>И где тут опровержение/противоречие?

Все, целиком.

I>>>>"не выпустить его или выпустить не своевременно" это уже следствие. Не бывает просто так, от балды, "не выпустить" или "выпустить не своевременно". Если говорить про код, то первая из причин это перетачивание прототипа в продакшн.
N>>>Нет, бывает. И ещё как бывает. Например, ввиду того, что нужно выпустить продукт раньше намеченного строка. Скажем, разведка доложила, что конкуренты вот-вот на днях зарелизятся.
I>>То есть, конкретная причина "разведка доложила" есть "от балды" ? Браво !
N>Да, действительно. "Разведка доложила" — это вовсе не "от балды". Это одна из обоснованных и весомых причин выпуска доработанного прототипа. Не придирайся к словам, ведь из контекста ясно, что имелось ввиду.

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

N>>>Нет, не поделюсь. Для начала мне нужно убедиться, что я разговариваю с разумным человеком, а не с воинствующей макакой. Извольте сначала "пояснить" за опровержения/противоречия в моих словах. А то начну тут зазря бисер метать.
I>>Ты похоже о чем то своём, наболевшем. Не буду тебя беспокоить.
N>Нет. Я спросил тебя в очередной раз за противоречия в моих словах. Ты же продалжаешь своё бессмысленный батхёрт.

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

Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, Ikemefula, Вы писали:

I>>>>, но тогда странно, почему возникают проблемы — вроде "отрефакторить всегда успеешь" и при этом то по твоим словам приходится переписывать.
A>>>Меняются обстоятельства. Я в той ветке об этом говорил.
I>>Обстоятельства всегда меняются. Собтсвенно рефакторинг нужен именно по этой причине — слишком часто приходится влазить и читать/править уже написаный работающий код.
A>Ну я, эта, согласен. Вот только не понял к чему ты это сказал.

Ты лучше свои сообщения перечитай

Здравствуйте, Ikemefula, Вы писали:

I>>>>>, но тогда странно, почему возникают проблемы — вроде "отрефакторить всегда успеешь" и при этом то по твоим словам приходится переписывать.
A>>>>Меняются обстоятельства. Я в той ветке об этом говорил.
I>>>Обстоятельства всегда меняются. Собтсвенно рефакторинг нужен именно по этой причине — слишком часто приходится влазить и читать/править уже написаный работающий код.
A>>Ну я, эта, согласен. Вот только не понял к чему ты это сказал.

I>Ты лучше свои сообщения перечитай
Давай на этом и закончим, ок?

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

I>>Ты лучше свои сообщения перечитай
A>Давай на этом и закончим, ок?

Можно и закончить, я не против.

Здравствуйте, Ikemefula, Вы писали:

I>Мне тоже не ясно где ты борьбу видишь, т.к. я всего то излагаю собственно мнение
Например:
0x7be, говорит:
0>Дык, опыт своих же ошибок дает прекрасную пищу для улучшения.
0>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
0>Собственно, это ключевая идея прототипирования
Ты же отвечаешь так, будто 0x7be не прав относительно идеи прототипирования:
I>Ключевая идея прототипирования это не получение классного кода, а сбор требований, выявление имеющихся проблем и выявление всевозможных депенденсов и ответ на вопрос — решаема ли задача в заданном контексте.
I>То есть, другими словами, разведка боем.
Будто 0x7be, говоря про лучший код имел ввиду нечто другое, отличное от
I>[...] а с конкретной целью — сделать код более понятным, сделать код более тестируемым, сделать код более гибким, реюзабельным и тд.
Фактически ты, на правах капитана, сказал тоже самое, что говорил 0x7be и Aikin, но сказал так, будто это нечто иное, отличное от того что говорят господа.
И почему я тут вижу некую борьбу непонятного происхождения? Чёрт его знает... (у меня есть подозрения, что не только я эту борьбу вижу)

Здравствуйте, Ikemefula, Вы писали:

I>Ключевая идея прототипирования это не получение классного кода, а сбор требований, выявление имеющихся проблем и выявление всевозможных депенденсов и ответ на вопрос — решаема ли задача в заданном контексте.
I>То есть, другими словами, разведка боем.
Зачем ты ограничиваешь цели прототипирования только требованиями?
ПМСМ, прототипирование — это экспериментальная проверка своих гипотез, в том числе и технического характера.

Здравствуйте, 0x7be, Вы писали:

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

Правильно понимаю, в строчке ниже ты видишь только два первых слова ?
"сбор требований, выявление имеющихся проблем и выявление всевозможных депенденсов и ответ на вопрос — решаема ли задача в заданном контексте"

0>ПМСМ, прототипирование — это экспериментальная проверка своих гипотез, в том числе и технического характера.

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

Проверка гипотез это слишком мало.

Здравствуйте, nullxdth, Вы писали:

N>Например:
N>0x7be, говорит:
0>>Дык, опыт своих же ошибок дает прекрасную пищу для улучшения.
0>>На моей практике, лучший код — это код написанный, выброшенный и переписанный заново с учетом опыта.
0>>Собственно, это ключевая идея прототипирования
N>Ты же отвечаешь так, будто 0x7be не прав относительно идеи прототипирования:
I>>Ключевая идея прототипирования это не получение классного кода, а сбор требований, выявление имеющихся проблем и выявление всевозможных депенденсов и ответ на вопрос — решаема ли задача в заданном контексте.
I>>То есть, другими словами, разведка боем.
N>Будто 0x7be, говоря про лучший код имел ввиду нечто другое, отличное от
I>>[...] а с конкретной целью — сделать код более понятным, сделать код более тестируемым, сделать код более гибким, реюзабельным и тд.
N>Фактически ты, на правах капитана, сказал тоже самое, что говорил 0x7be и Aikin, но сказал так, будто это нечто иное, отличное от того что говорят господа.

Опыт, лучший код, понятный, тестируемый — это все второстепенные вещи и именно об этих второстепенных вещах говорит 0x7be.

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

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

Менеджмент посмотрел прототип, подумал и свернул все приложение.

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

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

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

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

Здравствуйте, nullxdth, Вы писали:

I>>Ахинея : "стоит начинать с архитектуры (даже тогда, когда ТЗ ещё не до конца осмыслено и разработано)"
I>>Это утверждение ниоткуда не следует, ты сам его вбросил, приписав идею мифическим "апологеты ООП/ООД считают"
N>Хорошо. Допустим я сам придумал ООП/ООД апологетов и то, что разработка "сверху вниз" является доминирующим подходом в среде этих апологетов. Хотя, в подтверждении своей "ахинеи", я ещё в начале треда привёл ссылку на мнение о дискусии OOPSLA, где подобной "ахинеей" страдали такие господа, как Пол Грэм и Александр Степанов. Но всё же предположим, что ты просто не внимательно прочёл тред и влетел в обсуждение с термоядерным батхёртом (неизвестного происхождения). й. Извольте сначала "пояснить" за опровержения/противоречия в моих словах. А то начну тут зазря бисер метать.

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

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Аноним, Вы писали:

А>>ООН = Объектно Ориентированные Нагромождения

I>Вот тебе поддержка из Википедии:

I>Alexander Stepanov suggested that OOP provides a mathematically limited viewpoint and called it "almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work....".

Что-то в таком духе я всегда про него и думал, глядя на STL. "an interesting piece of code", панимаешшшшь. Я вот насмотрелся на интересный код, и теперь научился ценить самый неинтересный код.

I>Paul Graham has suggested that the purpose of OOP is to act as a "herding mechanism" that keeps mediocre programmers in mediocre organizations from "doing too much damage". This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques.

Золотые слова. Люто, бешенно плюсую.

К сожалению, какой же дурак не считает себя "productive programmer who knows how to use more powerful and more compact techniques", откуда и вся эта современная любовь к глобальным функциям в неймспейсах.

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

К счастью, многие фреймворки пишут действительно не-mediocre programmers, и получается очень няшно. FCL, например. Спасибо и на том, что дурацкий код с вызовами FCL становится почитабельнее, чем с вызовами STL/CRT.

I>Joe Armstrong, the principal inventor of Erlang, is quoted as saying "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

Ага, только вот из всего софта, что я видел, именно ejabberd, знаковый продукт Эрланга на тот момент, я НЕ смог завести вообще. Что-то там у него с environment было . Не находил чего-то.