Это он о Trie закинул. Это когда practically O(1) для структрур вменяемых размеров. Вообще при этом если человек отрацает ООП, то точно школьник без работы. Плюс если пихает что то настолько не практичное как Clojure, то диагноз подтверждается. На вопросы он не ответил, только написал «ты ничего не понял»

Наследование не используешь?

Некорректный вопрос.

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

«Наследование» это категория ОО парадигмы.

Некорректное заявление. Наследование - оно о построении иерархических структур с отношением 1родитель-*потомки. Множественное наследование (или в нормальном варианте примеси) - имитация отношений *потомки-*родители.

Наследование решает задачи реюза, расширения

Эти задачи решает модульность.

и диспетчеризации поведения/данных по какому-то правилу

А этим занимается полиморфизм. И да, что такое «диспетчеризация данных»? o_0

в ОО ограничивается полиморфизмом с кастрированной диспетчеризацией по типу

«Правило наследования ограничивается полиморфизмом?» *facepalm*

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

Модульность и полиморфизм уже упомянули, какие еще? Или это из разряда «таких приборов, которые...»?

нанимают команду профессионалов, которая анализирует ТЗ

блин, ты точно работал? с каких это пор заказчик сам стал писать ТЗ? (не, иногда бывает, но это ж ядерный писец)

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

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

P.S. и финансирование - не проблема

В этот момент ВНЕЗАПНО выясняется, что услуги профи стоят денег

хиленький у тебя «интерпрайз», нифига не «интерпрайзный», на поверку выясняется

блин, ты точно работал? с каких это пор заказчик сам стал писать ТЗ? (не, иногда бывает, но это ж ядерный писец)

Если заказчик разбирается в домейне? // К.О.

и финансирование - не проблема

Финансирование всегда проблема.

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

вангование - 2,
онанизм - 5

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

ты уже изобрёл «абсолютно масштабируемую систему»? а ты - крутой :)

Чтобы система хоть как-то продолжала работать, нужен платный Zend.

да-да, и это в отличие от бесплатного websphere на p-series ;)

PS нищеброды ваяют хайлоад, ололо

заказчик [..] осознает, каким жадным и недальновидным болваном он был

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

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

блин, ты точно работал? с каких это пор заказчик сам стал писать ТЗ? (не, иногда бывает, но это ж ядерный писец)

Если заказчик разбирается в домейне? // К.О.

1) тогда всё становится существенно хуже :)
2) ты много таких видел?

и финансирование - не проблема

Финансирование всегда проблема.

даже не знаю что сказать :)

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

тут проблемы скорее такого плана:

• придумать идею, которая будет привлекательна для капитала, читай - отобьётся в разумные сроки;
• обосновать сроки (инвесторы, они у нас совсем не любят, чтобы больше 1-2 лет оборот был);
• объяснить, что и фейлы иногда случаются;
• ...

ну и т.д.

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

Финансирование всегда проблема.

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

Если заказчик разбирается в домейне? // К.О.
1) тогда всё становится существенно хуже :)

Почему, если не секрет?

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

Так как jawamonker ITT никого выше ПМ в жизни не видел, у него и возникают всякие бредовые мысли об отсутствии денег и написании ТЗ заказчиком.

Ох, и не нравится мне этот Haskell-way фрагментации языка на части:

[INFO] [..] warning: implicit conversion method event2event should be enabled
[INFO] by making the implicit value language.implicitConversions visible.
[INFO] This can be achieved by adding the import clause 'import scala.language.implicitConversions'
[INFO] or by setting the compiler option -language:implicitConversions.
[INFO] See the Scala docs for value scala.language.implicitConversions for a discussion
[INFO] why the feature should be explicitly enabled.

http://docs.scala-lang.org/sips/pending/modularizing-language-features.html

Удобно же сделали.

Если заказчик разбирается в домейне? // К.О.

1) тогда всё становится существенно хуже :)

Нонсенс. Кроме заказчика в нем может больше вообще никто и не разбираться.

2) ты много таких видел?

Нет.

Финансирование всегда проблема.

даже не знаю что сказать :)

А я знаю - те кто в основном «носятся с баблом и не знают куда вложить» на самом деле либо носятся с копейками, до 200К (обычно последними или с проданных хат), либо ищет высокорисковые проекты с потенциально огромной прибылью (венчурное инвестирование), с первыми все ясно, а у вторых проблема: они всегда предлагают маленькие доли основным разрабам, позже ужимая и их. Поэтому разрабы с действительно нормальными идеями, а не выстрелит увидеть динозавра или нет 50/50 - обычно сами продают хаты и идут по первому пути (часто обанкрочиваются, потому что допустим хорошие прогеры, но хреновые маркетологи, продажники, управленцы, бухгалтеры...). А для инвесторов второго пути остаются очумелые хипстеры с 95% «заимствованых» или понакурке идей. Таким образом, из 20-ти команд сливается 19. При чем не на этапе посевного инвестирования, а когда «продажи должны были вытянуть, но не пошли» и попутно принимается решение «еще подождать», подрбросить дровиш^W деньжат. И вот на 20-й, потенциально единственный нормальный стартап, начинает нехватать.

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

Если денег не хватает - начинают занимать, угодай к чему это приводит для core team девелоперов - к сужению доли, вплоть до ее потери в обмен на повышенную зп и значок «почотный олдфаг» с унылыми перспективами. Вот тебе и «проблема с финансированием», с обратной стороны луны :)

Наследование не используешь?

Некорректный вопрос.

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

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

«Наследование» это категория ОО парадигмы.

Некорректное заявление. Наследование - оно о построении иерархических структур с отношением 1родитель-*потомки. Множественное наследование (или в нормальном варианте примеси) - имитация отношений *потомки-*родители.

Я про парадигмы программирования говорю. «Наследование» в программировании в основном относится к ООП. И к чему ты мне «расшифровываешь» очевидные общие вещи?

Наследование решает задачи реюза, расширения

Эти задачи решает модульность.

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

и диспетчеризации поведения/данных по какому-то правилу

А этим занимается полиморфизм.

Это и имелось в виду.

И да, что такое «диспетчеризация данных»? o_0

Диспетчеризация по данным. Почитай про мультиметоды.

в ОО ограничивается полиморфизмом с кастрированной диспетчеризацией по типу

«Правило наследования ограничивается полиморфизмом?» *facepalm*

Фи, какая откровенная ложь. В моем посте было такое предложение «Наследование решает задачи реюза, расширения и диспетчеризации поведения/данных по какому-то правилу (в ОО ограничивается полиморфизмом с кастрированной диспетчеризацией по типу)».

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

Модульность и полиморфизм уже упомянули, какие еще? Или это из разряда «таких приборов, которые...»?

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

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

Посмотри на код внутри методов в джаве в своих проектах или чужих, никуда в этом языке не деться от низкоуровневого и императивного программирования. Теперь посмотри на тот же picture language из SICP-a. А ведь это 80-е годы.

Посмотри на примеры кода на clojure - совсем другой уровень. Совсем-совсем другой. Если будет интересно, скину примеры использования SQL DSL на clojure. Это реально мощно, очень просто и легко читаемо, для чего и делаются DSL-ы.

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

Наследование (структур) возможно и вне ооп.

«Наследование» это категория ОО парадигмы.

Некорректное заявление. Наследование - оно о построении иерархических структур с отношением 1родитель-*потомки. Множественное наследование (или в нормальном варианте примеси) - имитация отношений *потомки-*родители.

Я про парадигмы программирования говорю.

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

И к чему ты мне «расшифровываешь» очевидные общие вещи?

Уточняю свой вопрос, мне показалось ты его не понял.

И да, что такое «диспетчеризация данных»? o_0

Диспетчеризация по данным. Почитай про мультиметоды.

Нет, ты написал «диспетчеризация данных», известные мне мультиметоды это диспетчеризация по типу.

«Правило наследования ограничивается полиморфизмом?» *facepalm*

Фи, какая откровенная ложь.

Ну да, конечно :) «Наследование решает задачи реюза, расширения и диспетчеризации поведения/данных по какому-то правилу (в ОО ограничивается полиморфизмом с кастрированной диспетчеризацией по типу)».

Это читается как правило (наследования) ограничивается полиморфизмом. В круглых - скобках уточнение относительно правила. Или строй предложения однозначно.

Диспетчеризация - мультиметоды, которые также...

Это все понятно, а чем объекты заменяются? А в них умолчательная инициализация, деструкторы, свойства (properties)? И наследование, наследование!!11 :) Еще раз прошу обратить внимание на то, что я _ничего_ не говорю о методах и их перегрузке. Допустим, у нас методы не принадлежат объектам-классам.

+ иногда макросы позволяют добиваться реюза без громоздкости ООП

ооп *вообще* никакого реюза не предполагает, это миф :) А мощь инструмента реюза «макросы» на уровне функций, которые есть в любом яп.

Посмотри на код внутри методов в джаве в своих проектах или чужих

Я на джаве не пишу :)

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

А кто (я?) с этим спорил?

Теперь посмотри на тот же picture language из SICP-a. А ведь это 80-е годы.

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

Если будет интересно, скину примеры использования SQL DSL на clojure.

Попробую угодать, там будет подобие cl-sql, без orm, с необходимостью IRL выбрасывать этот sql dsl нафиг и пи#$^ить sql руками для конкретной бд. А если захочется это все дело запилить на nosql - еще и sql-код выбрасывать. Вместо того, чтобы заюзать (или написать в случае отсутствия) бекенд к orm. Мыши, кактус.

Это реально мощно, очень просто и легко читаемо, для чего и делаются DSL-ы.

SQL - это и есть dsl :) То о чем ты говоришь, с вероятностью 99,291% «морда» к нативному sql для простеньких неспецифичных к бд запросов.

Благодарю. Сейчас портирую свой код с 2.9.1 на 2.10.0. Придется мне над ним поработать. И, вероятно, от reflectiveCalls придется отказаться из-за возможных проблем с ProGuard.

Именно платят за enterpriZe, а не за понты.

Наследование (структур) возможно и вне ооп.

Согласен, наследование вообще общее понятие. Я про то, что оно в программировании в основном как термин применяется в ООП.

ооп ты не используешь, а наследование используешь?

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

Если нет, то что это за класс задач таких, где объекты, массивы данных не обладают общими свойствами?

«Обладать общими свойствами» не прерогатива ОО. Хорошо промыли мозги людям.

Диспетчеризация по данным. Почитай про мультиметоды.

Нет, ты написал «диспетчеризация данных»,

Написал, потом разъяснил, что имел в виду.

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

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

Это читается как правило (наследования) ограничивается полиморфизмом. В круглых - скобках уточнение относительно правила. Или строй предложения однозначно.

«Правило» относилось к задаче диспетчеризации.

а чем объекты заменяются?

Функциональным программированием.

+ иногда макросы позволяют добиваться реюза без громоздкости ООП

ооп *вообще* никакого реюза не предполагает, это миф :)

Хорошо.

А мощь инструмента реюза «макросы» на уровне функций, которые есть в любом яп.

'«макросы» на уровне функций' что это? Что есть в любом ЯП?

Попробую угодать, там будет подобие cl-sql, без orm, с необходимостью IRL выбрасывать этот sql dsl нафиг и пи#$^ить sql руками для конкретной бд.

cl-sql уже не помню. Пару запросов делал, когда играл с CL, но не применял cl-sql в реальной работе.

Преимущества dsl над чистым sql в том, что dsl является частью языка: функции, коллекции - т.е. можно применять весь арсенал языка (например композиции, map/filter, etc).

Например,

(defn warn-clients [client-ids]
  (with-db db
    (select table-client
            :fields [client-id client-phone client-email]
            :where [:in client-id client-ids])))

(map :email (get-clients [1 2 3]))
=> ("asdf@asdf.com" "ttt@qqq.com" "qqq@ttt.com")

Преимущества:

• Запрос является обычной функцией (select).
• Позволяет в выражении использовать коллекции языка (client-ids - может быть вектором или списком).
• Контроль над структурой запроса (строки в named query в джаве это просто ппц)
• Автодополнение имен таблиц и полей (table-client, client-id, client-phone, client-email) и проверка их на этапе компиляции, что удобно, предотвращает очепятки и является защитой от расхождения с именами в БД.

А если захочется это все дело запилить на nosql - еще и sql-код выбрасывать. Вместо того, чтобы заюзать (или написать в случае отсутствия) бекенд к orm. Мыши, кактус.

Т.е. у вас переход с sql на nosql происходит часто? И вы безболезненно эти переходы осуществляете?

SQL - это и есть dsl

В данном контексте речь идет о eDSL.

Не надо о C++ говорить как о дегенератости...

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

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

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

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

Слив засчитан.

Выводить из собственного процитированного утверждения утверждение оппонента как его инверсию (при этом еще и перепутав домены) - это конечно пушка.

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

Забздел что обосрешься?

конечно, но пусть сначала C# научится работать на Linux/MacOS/Android

http://xamarin.com/

• где там Linux ?
• GUI код вроде тоже не кросс-платформенный.
• платное, проприетарное.

Так на ынтырпрайзе мир и не заканчивается.

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

Кросс-платформенный (Desktop/mobile) GUI для джавы уже появился? o_O

Лень искат посты того самого великого энтерпрайZ-Java-черт-знает-кого-по-профессии анонимуса.

Но думаю ссылка будет интересна и dizza и vertexua

WTF-архитектура

Ну и да - анонимус, что скажешь про этот доклад?

Выводить из собственного процитированного утверждения утверждение оппонента как его инверсию (при этом еще и перепутав домены) - это конечно пушка.

Да, я поэтому очень развеселился, вашим неожиданным выводам за меня :)

конечно, но пусть сначала C# научится работать на Linux/MacOS/Android

Прекрасно работает много лет, как и на iOS где Scala не работает. Scala.Net в неработоспосбном состоянии, поэтому ее трудно считать.

Прекрасно работает много лет, как и на iOS

огрызок в виде Mono ?

огрызок в виде Mono ?

У вас есть претензии к моно или попоболь мучает?

Добавлю ваш голос за C#

нет, но единообразная работа на Win/Lin/Mac - уже неплохо. есть надежда на javaFX: http://stillhacking.blogspot.com/2012/07/android-and-javafx.html

qwerky, ты дебил. Mono - это open source под кошерной лицензией, отлично работает под Linux, и там есть кросс-платформенный гуй на gtk+. Правда, гуй вообще в принципе не нужен, но это уже другая история.

Я бы не был как категоричен, хотя немение qwerky читать настораживает.

Все же хаскелеры требуются...

Цитата: «I periodically get contacted by recruiters for banks, because my CV mentions Haskell, and there's a massive shortage of Haskell programmers. They're offering silly salaries to people with no experience in the financial sector. Still not quite enough to convince me that I want to move to London and work on tedious soul-destroying stuff though, they'd need to add another zero onto the end for that. If I could telecommute, I'd be quite tempted - I'd pay off my mortgage in about six months.»

Требуются все.
Проблема в количестве вакансий.

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

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

Нормально там все интегрируется. Play! как и Lift - совершенно особые животные, потому с них и спрос особый.

А что это самые крутые вакансии на весь цивилизованный мир?

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

Понимаете, суровой реальностью может быть низкая квалификация разработчиков. Особенно это касается rule engine. Почему-то декларативные правила особенно трудны для освоения тру-энтрепрайзными джавщиками, которым нравится вместо десятка строк или таблички на Drools городить сотни строк на джаве и еще столько же для тестирования (TDD же!).

Для мэйнстрима скорее фундаментализм свойственнен :) Ничем не лучше, вообще говоря.

особенно трудны для освоения

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

а F#? :)

Это был сарказм. Но вообще-то спасибо за прояснение позиции.