Финансовые компании - везде "тотальный контроль"? - О работе

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

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

M>А по поддержке хоть какие-нибудь проекты были? Хотя бы на пару месяцев. Или сопровождение своих (разработанных и выпущенных) проектов в течение какого-то времени (полгода примерно)? Лучше, конечно, саппорт кода от более-менее типичной команды (со студентами в ней и т.п.). Подобный саппорт сильно влияет на видение того, "какой была программа". Все-таки часть проблем возникает именно в последствии. И часть из них — при чтении/поддеркже кода другими людьми. Если нет, возможно, замечания руководителя и по теме (хотя если он замечания не аргументирует, это плохо).

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

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

Ну, как-то была переделка кода, написанного не-студентом, но код был плох, объективно говоря (сам автор это потом признавал

Честно проваландавшись с этим кодом в течение месяца (веря в то, что первый импульс "всё переписать" приходит к большинству из нас, и он не конструктивен

, в итоге я всё-таки его весь выкинул к едреням и написал заново, в чём потом не раскаивался

Я бы не стал ввязываться в поддержку некачественного кода, честно говоря. Рынок не настолько плох

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

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

Проблема в том, что человек огульно предлагает исключительно свои подходы, игнорируя альтернативные. Это мне показалось плохим симптомом. Человек, который не понимает, что подавляющее большинство задач может быть решено >1 способом (и, следовательно, есть не-0 вероятность, что другой человек выберет способ, отличный от твоего собственного), на мой взгляд, создаёт очень большие проблемы.
Впрочем, со временем (непродолжительным) оказалось, что не всё так плохо — похоже, можно с ним сотрудничать, он способен слушать, слава Богу!

Поэтому пока повременю с уходом

M>Еще вопрос. А что за языки? Некоторые друг от друга очень сильно отличаются, а некоторые очень похожи друг на друга и мало чем отличаются. Точнее, я чуть переформулирую вопрос. А сколько различнхы систем типов было в этих языках? Были ли языки с возможностью метапрограммирования (макросы в compile-time)? Хвастаться языками просто так особого смысла не имеет. Известно же, что "Опытный фортранщик на любом языке может писать как на фортране". То же самое и на других языках встречается. Т.е. одно дело "просто написать работающее приложение", другое — "написать приложение в идеологии языка". В некоторых случаях paradigm shift достаточно большой и переход на новый язык может быть достаточно длительным. Ну а стили радикально отличаются. Например, на функциональных языках (ocaml, haskell) внутри методы очень сильно по внешнему виду отличаются от таких же в императивщине без нормальной поддержки fp (js, java, python, etc...). Кстати, вы зря javascript не считаете. На нем можно делать вещи, которые в C#/Java даже и не снились. Вот в каком-нибудь nemerle можно, но там только макросами (система типов мешает

), а вот в js — вполне в рантайме, обычными функциями.

языки — c, c++, smalltalk (от visual age, кажется), java, vbasic (да-да, не vba, а реально vbasic — на нём, оказывается, можно не только макросы для офиса писать, но и dll с exe-шниками

, c#. На этих коммерческие проекты были. Ну, те, которые "для себя", или в процессе учёбы, не привожу. smalltalk, напримем, настолько резко отличается по идеологии, что на нём затруднительно было бы писать, как на фортране

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

M>Еще вопрос. А что за языки? Некоторые друг от друга очень сильно отличаются, а некоторые очень похожи друг на друга и мало чем отличаются. Точнее, я чуть переформулирую вопрос. А сколько различнхы систем типов было в этих языках? Были ли языки с возможностью метапрограммирования (макросы в compile-time)? Хвастаться языками просто так особого смысла не имеет. Известно же, что "Опытный фортранщик на любом языке может писать как на фортране". То же самое и на других языках встречается. Т.е. одно дело "просто написать работающее приложение", другое — "написать приложение в идеологии языка". В некоторых случаях paradigm shift достаточно большой и переход на новый язык может быть достаточно длительным. Ну а стили радикально отличаются. Например, на функциональных языках (ocaml, haskell) внутри методы очень сильно по внешнему виду отличаются от таких же в императивщине без нормальной поддержки fp (js, java, python, etc...). Кстати, вы зря javascript не считаете. На нем можно делать вещи, которые в C#/Java даже и не снились. Вот в каком-нибудь nemerle можно, но там только макросами (система типов мешает

), а вот в js — вполне в рантайме, обычными функциями.

да, и Вы меня заинтриговали — а что такого можно делать в js, что нельзя в с#? Реально, интересно.
(Дело в том, что, как мне кажется, в c# можно делать почти всё. Единственное, о чём лично я "горевал" — это отсутствие макросов и работы с темплейтами, как в сях. Дженерики, всё-таки, меньше возможностей имеют, чем старые добрые темплейты, как ни крути. Но зато они и меньше возможностей запутать код дают

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

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

On 21.01.2013 0:33, SkyDance wrote:

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

Posted via RSDN NNTP Server 2.1 beta

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

_>Прогер сделал ошибку в коде, не учтя некоторых тонких моментов многопоточного кода, а за ним никто не присмотрел. Ошибка произошла в бою на очень специфичном кейсе, который не отловили при тестировании. Чья тут работа плохая? Код не падал и не тек, делал что надо, тесты были. А должности лишат тебя.

Ты смешал ревью кода и обязательный единый стиль написания.

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

kkh>да, и Вы меня заинтриговали — а что такого можно делать в js, что нельзя в с#? Реально, интересно.
kkh>(Дело в том, что, как мне кажется, в c# можно делать почти всё. Единственное, о чём лично я "горевал" — это отсутствие макросов и работы с темплейтами, как в сях. Дженерики, всё-таки, меньше возможностей имеют, чем старые добрые темплейты, как ни крути. Но зато они и меньше возможностей запутать код дают

high-order functions (функции высшего порядка). Ну и "обобщенные" функции высшего порядка (название мое, в литературе вряд ли найдете. Это те функции, которые в системы типов вроде ML'евской и Haskell'ной не укладываются).

На пальцах. high-order functions — это всевозможные map, например. Т.е.

functiion map(fn, array) {
  res = [];
  for (var x in array)
    res.push(fn(x));
  return res;
}
function mapC(fn) {
  return function(arr) {
    return map(fn, arr);
  };
}

Вот map и mapC — функции высшего поярдка. Они принимают функции и иногда возвращают их. mapC — каррированная версия map (ну вот так она выглядит в javascript). Чтобы проникнутся удобством high-order function я бы рекомендовал OCaml или какой-нибудь другой из семейства ML-языков посмотреть. Заодно проникнетесь духом функционального программирования.

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

function bindf(fn, ...args) {
  return function(...args1) {
    return fn.apply(null, asArray(args))
  }
}

/// somewhere in a code
button1.addEventListener("click", bindf(navigateToPage, "abc"));
button2.addEventListener("click", bindf(navigateToPage, "def"));
button3.addEventListener("click", bindf(navigateToPage, "quit"));

/// another example
value1 = Reactive.variable(123)
value2 = Reactive.variable(321)
atanv = Reactive.apply(atan2, [value1, value2])
atanstr = str.rapply(null, [atanv])
setText.rapply(null, textField, atanstr)

Оба примера — вариации на реально и часто используемые библиотеки (там не совсем js, правда). Первое — биндинг функции к аргументам. В основном как раз для слушателей используется. Особенно для компонентов UI (для рендеринга какого-нибудь элемента в list, например). Там рендеринг элементов делается обычным методом (без классов) и слушатели удобнее прикручивать так, чем явно расписывать замыкание, вызов метода и т.п.

Второй пример — реактивное программирование. Внутренности не показаны (достаточно приличных пока нет для публики, хотя уже заказывали). Внутри — те же самые fn.apply(...) с обработкой аргументов. в примере atanv и atanstr автоматически изменяют значение при изменении value1 и value2. А еще в случае изменения вызывается setText(textField, atanstr.value()) (textField — не reactive). x.rapply(null, ...) == Reactive.apply(x, ...) — базовый как раз reactive а потом на него биндинг для функций делается. В UI оказалось очень удобно. А заодно оказалось, что в ui много функций, которые не имеют побочных эффектов (pure function) и зависят только от их входных параметров. Поэтому при желании их можно очень даже хорошо тестировать.

У вас в парадигмах примерно 2-2,5 видел (точно разные smalltalk и немного макросов в C++). Вам бы еще FP стоит посмотреть (тот же ML какой-нибудь, потом можно и Haskell).

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

M>high-order functions (функции высшего порядка). Ну и "обобщенные" функции высшего порядка (название мое, в литературе вряд ли найдете. Это те функции, которые в системы типов вроде ML'евской и Haskell'ной не укладываются).

M>На пальцах. high-order functions — это всевозможные map, например. Т.е.
M>

M>functiion map(fn, array) {
M>  res = [];
M>  for (var x in array)
M>    res.push(fn(x));
M>  return res;
M>}
M>function mapC(fn) {
M>  return function(arr) {
M>    return map(fn, arr);
M>  };
M>}
M>

M>Вот map и mapC — функции высшего поярдка. Они принимают функции и иногда возвращают их. mapC — каррированная версия map (ну вот так она выглядит в javascript). Чтобы проникнутся удобством high-order function я бы рекомендовал OCaml или какой-нибудь другой из семейства ML-языков посмотреть. Заодно проникнетесь духом функционального программирования.

а чем делегаты (ну, и пошедшие от них лямбды) в C# хуже? там тоже можно присваивать делегаты переменным, массивы делать из них, методы и делегаты могут принимать и возвращать другие делегаты (тривиальный пример — сортировка, где методу, реализующему алгоритм сортировки, передаём в качестве параметра делегат, осуществляющий, собственно, сравнение элементов), и т.п. И с точки зрения синтаксиса довольно элегантно сделано, на мой взгляд — например, та же концепция "захвата переменных".
Можем, например, практически "куски кода" (которые используют в т.ч. "захваченные" локальные переменные и поля/свойства классов) сложить в очередь и исполнить попозже, или передать кому-то, кто их исполнит из под аккаунта с повышенными (или пониженными) привилегиями, или из другого потока, и т.п. При этом такой делегат часть данных может получать в качестве параметров (т.е. в момент фактического исполнения), а часть, которые захвачены — как бы данные, "замороженные", на момент создания этого делегата (особенно, если к моменту фактического исполнения давно из "скоупа" вышли, где делегат создавался

.

M>Второе, "обобщенные" функции. Это страшные вещи, которые с arguments работают вместо списка параметров. Один из любимых (правда, на firefox-диалекте, на простом js параметры нужно бы из arguments разбирать):
M>

M>function bindf(fn, ...args) {
M>  return function(...args1) {
M>    return fn.apply(null, asArray(args))
M>  }
M>}

M>/// somewhere in a code
M>button1.addEventListener("click", bindf(navigateToPage, "abc"));
M>button2.addEventListener("click", bindf(navigateToPage, "def"));
M>button3.addEventListener("click", bindf(navigateToPage, "quit"));

если я правильно понял идею, подобием этого на C# может быть нечто вроде:

void SomeMethod()
{
  button1.Click += (sender, e) => NavigateToPageAndDo( "http://abc", null );
  button2.Click += (sender, e) => NavigateToPageAndDo( "http://def", null );

  var someOtherObject = SomeObjectFactory.CreateSomeOtherObject();
  button3.Click += (sender, e) => NavigateToPageAndDo( "http://ghi", x => someOtherObject.SomeAdditionalAction(x) );
}

void NavigateToPageAndDo( string pageUrl, Action<string> _someAdditionalAction ) {
  
  // ... do navigation to page
  
  if ( _someAdditionalAction != null ) {
    ( new Thread( () => _someAdditionalAction( pageUrl ) ).Start();
  }
}

причём, никто не мешает и более сложно сделать, и передавать не просто Action<...>, а, скажем, Func<string, Action<string>>, который будет в зависимости от того, что ему передано первым параметром, возвращать различные обработчики Action<string>. Ну, и кучу аналогичных прикольных вещей можно делать :-)

M>/// another example
M>value1 = Reactive.variable(123)
M>value2 = Reactive.variable(321)
M>atanv = Reactive.apply(atan2, [value1, value2])
M>atanstr = str.rapply(null, [atanv])
M>setText.rapply(null, textField, atanstr)
M>

M>Оба примера — вариации на реально и часто используемые библиотеки (там не совсем js, правда). Первое — биндинг функции к аргументам. В основном как раз для слушателей используется. Особенно для компонентов UI (для рендеринга какого-нибудь элемента в list, например). Там рендеринг элементов делается обычным методом (без классов) и слушатели удобнее прикручивать так, чем явно расписывать замыкание, вызов метода и т.п.

да и в C# не слишком сложно (если, опять же, я правильно понял суть идеи)

Action Bind(
Action<string, string> action,
string param1,
string param2
) {
return () => action( param1, param2 );
}

в js, может, и удобнее сделано (тут вопрос вкусовых пристрастий, спорить нельзя), зато отлаживать, видимо, сложнее — если где "накосячил", это только в рантайме выяснится. А в C# скомпилиться не даст — для сложного кода это может быть существенной экономией времени.

M>Второй пример — реактивное программирование. Внутренности не показаны (достаточно приличных пока нет для публики, хотя уже заказывали). Внутри — те же самые fn.apply(...) с обработкой аргументов. в примере atanv и atanstr автоматически изменяют значение при изменении value1 и value2. А еще в случае изменения вызывается setText(textField, atanstr.value()) (textField — не reactive). x.rapply(null, ...) == Reactive.apply(x, ...) — базовый как раз reactive а потом на него биндинг для функций делается. В UI оказалось очень удобно. А заодно оказалось, что в ui много функций, которые не имеют побочных эффектов (pure function) и зависят только от их входных параметров. Поэтому при желании их можно очень даже хорошо тестировать.

M>У вас в парадигмах примерно 2-2,5 видел (точно разные smalltalk и немного макросов в C++). Вам бы еще FP стоит посмотреть (тот же ML какой-нибудь, потом можно и Haskell).

спасибо, если возможность будет — обязательно посмотрю

У меня был такой же случай.
Я как бы не совсем нуб, но молод еще и опыта у меня не много, так вот однажды я на испытательном сроке получил задачу.
Задача была на проектирование архитектуры классов.
Ну я делал так, как считал нужным и так же как у вас, ко мне тоже придирались буквально по каждой строчке кода.
Позже, когда я все таки доделал эту задачу, мне сказали о том, что я ее делал слишком долго. На задачу нужно было потратить минут двадцать, а я ее делал 8 часов. Тот кто давал мне эту задачу прямым текстом сказал мне — "Мне не понравилось то, что я проталкивал через тебя СВОЮ реализацию".
Так и хотелось сказать "А нах*я ты это бл*дь делал? НА*УЯ?". Ну конечно я ничего не сказал, хотя был зол дико.
На основе этого сделали, по моему мнению, не верный вывод о моей низкой производительности.
Конечно я пытался оспорить, но ничего не вышло. В итоге я не прошел испытательный срок.
В общем если бы я был на вашем месте, я бы подыскивал другое место.
На всякий случай, мало ли.

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

N>Ну я делал так, как считал нужным и так же как у вас, ко мне тоже придирались буквально по каждой строчке кода.
N>Позже, когда я все таки доделал эту задачу, мне сказали о том, что я ее делал слишком долго. На задачу нужно было потратить минут двадцать, а я ее делал 8 часов. Тот кто давал мне эту задачу прямым текстом сказал мне — "Мне не понравилось то, что я проталкивал через тебя СВОЮ реализацию".

Толсто, конечно, но на фоне этого выглядит даже забавно.

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

Опять какой-то детский примитивизм и юношеский максимализм. Когда ж вы уже повзрослеете-то.

Нет, это не толсто, это правда.

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

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

_>>>>В нашей конторе за одну такую ошибку, как рассказывают, уволили тим-лида. Накосячил не он. Поэтому не нужно о сказках, ага?

A>>>А QA куда смотрели, когда принимали код, корторый рулит миллионами? Девелоперы в такой ситуации самые последние с кого нужно спрашивать, если конечно нет умышленного саботажа.

_>>Да не важно куда смотрели. Сам факт в том, что кто-то наговнокодил, и это попало в продакшн. Поэтому код должен ревьювиться обязательно, и претензии топикстартера необоснованы, имхо.

A>Код должен тестироваться в первую очередь. От отсутсвия код-ревью умерло гораздо меньше проектов, чем от отсутствия тестирования. Так что спрашивать нужно в первую очередь с ПМа, потом с QA как такой код оказался в продакшене.

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

A>Вот буквально сейчас правлю багу, так там хоть обревьюйся, ничего не увидишь, т.к. косяк внутри сторонней библиотеки.

Конечно ревью не панацея, просто уменьшает энтропию.

On 22.01.2013 0:48, SkyDance wrote:

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

Posted via RSDN NNTP Server 2.1 beta

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

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

_>>Прогер сделал ошибку в коде, не учтя некоторых тонких моментов многопоточного кода, а за ним никто не присмотрел. Ошибка произошла в бою на очень специфичном кейсе, который не отловили при тестировании. Чья тут работа плохая? Код не падал и не тек, делал что надо, тесты были. А должности лишат тебя.

A>Ты смешал ревью кода и обязательный единый стиль написания.

Я пример привел.

Думаю не нужно объяснять, чем чревато написание кода аля фортран в классах аля *Manager, типа PaymentManager, в котором туева хуча методов и 2-3к строк кода в сумме. Видел немало людей 10+ опыта, которые так пишут. И даже если чел знает как юзать те или иные конструкции, это его никак не оправдает.

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

A>>Код должен тестироваться в первую очередь. От отсутсвия код-ревью умерло гораздо меньше проектов, чем от отсутствия тестирования. Так что спрашивать нужно в первую очередь с ПМа, потом с QA как такой код оказался в продакшене.

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

Это уже вопросы к построению процесса разработки. Я комментировал ситуацию с уовльнением лида за пропущенный баг.

A>>Вот буквально сейчас правлю багу, так там хоть обревьюйся, ничего не увидишь, т.к. косяк внутри сторонней библиотеки.

_>Конечно ревью не панацея, просто уменьшает энтропию.

Согласен, хотя и не всегда он нужен в обязательном порядке. Вот у нас в основном код коммитят 4 человека и еще несколько в меньшей степени, все знают о стиле, архитектуре, стараются не нарушать. Код далеко не идеален, но работает и читается легко. Самым старым кускам в нем уже лет 7-8. Ревью делаем паре индусов, которым еще не совсем доверяем. Пока все живы, серьезные баги отлавливают тестеры и аналитики, готовящие решлиз для клиента и ошибки в основном из области, что-то не принесли из основного репозитория или наоборот притащили лишнего, т.к. клиентов несколько десятков и набор фич отличается от клиета к клиенту.

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

kkh>а чем делегаты (ну, и пошедшие от них лямбды) в C# хуже?
Наличием типизации, очевидно. Местами типизация удобна, но далеко не всегда. Кстати, делегаты в C# используют номинативную или структурную типизацию? Т.е. delegate D1(int, String) и delegate D2(int, String) — это один и тот же тип или разные? Если разные, то все совсем печально (high-order на них вообще не написать). Ну а так — функции для делегатов с одним аргументом. с двумя аргументами и т.д. нужно писать.

kkh>там тоже можно присваивать делегаты переменным, ...
Это я все знаю. Это обычная функция как first-class object. Причем у меня вообще не js был а ActionScript3, там как раз функции у объектов получаются нормальными "делегатами" (примерно так же, как в python), а не так, как в js (с дополнительными приседаниями).

kkh>И с точки зрения синтаксиса довольно элегантно сделано, на мой взгляд — например, та же концепция "захвата переменных".
А там грабли лежат

. Нижележащий bindf частенько и в циклах используется, где мне нужен как раз "захват значений". Ниже покажу.

kkh>если я правильно понял идею, подобием этого на C# может быть нечто вроде:

Ну да, как-то так. Только вот вы указываете в каждой строчке тип (sender, e). А он у меня не важен. И, к сожалению, местами различается. Все мои личные библиотечные контролы принимают туда функцию без аргументов (угу, даже карринг из fp не спасет). А вот ad-hoc собранные ui-компоненты получают event. В общем, у вас типы нужно писать.

И я бы даже согласился, что по обхему кода даже примерно одинаково получается. (хотя вот += у моих кнопок тоже нет, обработчик только один и идет в конструктор). Но есть еще циклы. А там захват значений ведет себя совсем по-другому.

for (var item in items) {
  var btn = createItemButton(item, Functions.bindf(showItemDetail, [item]))
}

Вот у вас при наивном переводе вы получите багу. Все обработчики будут работать с последним item. И обработчик нужно делать в каждом цикле. Я не помню, может, bindf как раз для циклов у меня появился (чтобы замыкания на значения делать), а потом разошелся по остальному коду. Замыканий "на переменные" мне что-то нигде нужно не было, нужны были именно замыкания на значения (примерно так же, как в "чистом" fp (там только значения) и в java для inner interface).

kkh>да и в C# не слишком сложно (если, опять же, я правильно понял суть идеи)
Идея чуточку сложнее. Есть подписка на изменения.

interface Reactive<T> {
  // listener :: (context) -> void
  public void addChangeListener(listener : Function);
  public void removeChangeListener(listener : Function);
  public T value()
}

delegate R D1<R, T>(T t)
delegate R D2<R, T1, T2>(T1 t1, T2 t2)

Reactive<R> Bind(D1<R, T> f, Reactive<T> value) {
  ReactiveImpl<R> res = new ReactiveImpl<R>(...);
  value.addChangeListener(res.update);
  return res;
}

Reactive<R> Bind(D2<R, T1, T2> f, Reactive<T1> value1, Reactive<T2> value2) {
  ReactiveImpl<R> res = new ReactiveImpl<R>(...);
  value1.addChangeListener(res.update);
  value2.addChangeListener(res.update);
  return res;
}

Reactive<R> Bind(D2<R, T1, T2> f, T1 value1, Reactive<T2> value1) {...}
Reactive<R> Bind(D2<R, T1, T2> f, Reactive<T1> value1, T2 value1) {...}

В общем, там еще на изменения нужно подписываться и слушателей поддерживать. Кстати, я не уверен, что там одной ReactiveImpl<R> хватит. Может, из-за типизации придется их много делать (по числу параметров). Это сильно реализацию усложняет. Можно, конечно генератор написать, но... Его еще тестировать нужно, да и в проекте будет куча однотипных классов. Я такое не люблю.

Еще интереснее становится, когда мы начинаем на базе Reactive делать более сложные вещи. Язык у меня однопоточный (что AS3, что Javascript), поэтому какие-то вещи приходится делать асинхронно. Иногда после асинхронной загрузки нужно запустить другую загрузку (картинки там подгрузить и т.п.). Так вот. Все асинхронные комбинаторы построены на том же Reactive. Там точный тип получается вроде Reactive<ProgressInfo<T>>. В ProgressInfo — информация об ошибке, о состоянии загрузки или данные. По интерфейсу оно очень похоже на реактивное. Реализуется через тот же reactive (там mapping или биндниг). Так что для всех Reactive.Bind нужно будет генерировать подобные им Async.apply(...) методы (с разными сигнатурами типов). В общем, грустно. Особенно учитывая, что в некоторых случаях количество аргументов в Async.apply доходит до 7-8 (может, чуть больше). Из них 4-5 штук — действительно асинхронные, остальные — передача каких-то параметров дальше в метод (это чтобы класс для хранение результатов вручную не изобретать и анонимную функцию для проброса параметров из замыкания не делать)).

kkh>в js, может, и удобнее сделано (тут вопрос вкусовых пристрастий, спорить нельзя), зато отлаживать, видимо, сложнее — если где "накосячил", это только в рантайме выяснится. А в C# скомпилиться не даст — для сложного кода это может быть существенной экономией времени.

У меня был AS3, там частичная типизация есть. На функциях — нет, и это было хорошо. Весь хардкор — только в библиотеках, которые unit-тестами обвешены (ибо regression отлавливать по всему приложению было бы совсем не круто). Все в клиенте даже если и не сойдется с типами, то не сойдется сразу. А я прилжоение запускаю и по всему новому/изменившемуся UI все равно прохожу. Так что если типы не сойдутся, то это будет сразу заметно. Да, не всегда очевидно место ошибки, бывает. Но крупные ошибки бывают редко, при частых запусках (угу, система сборки тоже тюнинговалась в свое время под быструю инкрементальную сборку в процессе разработки) контекст обычно понятен, так что ошибка быстро правится.

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

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

Если что, я динамику не защищаю. Она не везде хорошо подходит. Для какой-нибудь алгоритмики я бы все-таки взял что-нибудь более типизированное (ocaml, haskell, scala). Для UI и сложного состояния программы — все-таки динамику. Или что-нибудь "не слишком строго типизированное". В какой-то мере можно scala использовать, например. Через implicit conversion вполне неплохой аналог Reactive получался, но со своими ограничениями. На haskell/ml мне не нравятся аналоги (разные операторы только из-за типизации). Но если хочется еще больше свободы, scala я тоже не взял бы (ну и эстетически не очень она нравится).

	От:	Гоги
	Дата:	18.01.13 18:31
	Оценка:

	От:	ResidentR6
	Дата:	18.01.13 20:29
	Оценка:

	От:	ambel-vlad
	Дата:	18.01.13 21:30
	Оценка:

	От:	kkh
	Дата:	18.01.13 23:04
	Оценка:

	От:	kkh
	Дата:	18.01.13 23:12
	Оценка:

	От:	Vzhyk
	Дата:	21.01.13 07:42
	Оценка:

	От:	alzt
	Дата:	21.01.13 09:23
	Оценка:

	От:	maxkar
	Дата:	21.01.13 14:15
	Оценка:

	От:	-n1l-
	Дата:	21.01.13 19:39
	Оценка: