Re[12]: Бизнес-логика на Erlangе
От: gandalfgrey  
Дата: 15.05.07 11:10
Оценка:
Здравствуйте, deniok, Вы писали:

D>То есть задача в создании универсального акцессора, который на входе получает (1) правила (структуру которых можно описать на некотором языке метаправил, и, следовательно, типизировать ) (2) нечто, что должно подчиняться этим правилам, а на выходе — функция, генерирующая заказанные данные

D>
D>flt :: Rules -> RawData -> (Request -> Maybe Data)
D>

В принципе как бы да — только функция не генерирует данные, а позволяет осуществлять к ним доступ неким унифицированным образом.
Re[13]: Бизнес-логика на Erlangе
От: aka50 Россия  
Дата: 15.05.07 11:20
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

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


D>>То есть задача в создании универсального акцессора, который на входе получает (1) правила (структуру которых можно описать на некотором языке метаправил, и, следовательно, типизировать ) (2) нечто, что должно подчиняться этим правилам, а на выходе — функция, генерирующая заказанные данные

D>>
D>>flt :: Rules -> RawData -> (Request -> Maybe Data)
D>>

G>В принципе как бы да — только функция не генерирует данные, а позволяет осуществлять к ним доступ неким унифицированным образом.

А можно увидеть на псевдокоде принцип подобного действа.
Допустим есть такой ентити:
class Person {
   var name: String = _;
   var position: Position = _;
}


И есть такой (допустим он даже не совместим и не наследуется от person)
class VIPerson {
   var name: String = _;
   var bablo: double = _;
   var position: Position = _;
}


Можно хотя бы на пальцах пояснить как будут выглядеть правила для модификации name в этих объектах.
ЗЫ: хотя все таки слабо представляю код, которому все равно что это за объект он модифицирует ( в случае с иерархией и trait-ами
понимаю)
Re[15]: Бизнес-логика на Erlangе
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.05.07 12:08
Оценка:
Здравствуйте, Курилка, Вы писали:

E>>Подробнее о том, что такое "проблема второй версии протокола" я рассказывал здесь
Автор: eao197
Дата: 29.06.05


К>И чем тебе не нравится предложенный мной вариант? Делаем сообщение аля {msgSignature, [...extesions...], someData}

К>Промежуточному слою нахрен не нужны extensions, поэтому в бранче ПМ будет что-то типа {msgSignature, _, X}

Я и не говорил, что он мне не нравится. Но, если об extensions не задумываться, то весь код ПМ вида {msgSignature, X} придется переделывать в {msgSignature, _, X}, а затем в {msgSignature, _, X, _}, а затем в {msgSignature{Y,Z,_},_,X,_,_} и т.д.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Бизнес-логика на Erlangе
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.05.07 12:14
Оценка:
Здравствуйте, gandalfgrey

<...Про структуры данных разбираются, видимо, в соседней ветке...>

E>>Но к надежности, имхо, это не имеет прямого отношения. Гораздо важнее, является ли используемый язык сильно-типизированным или нет. Скажем отсутствие проблемы повисших указателей или прохода по чужой памяти может сделать программу на Ruby надежнее, чем C++. Но это отнюдь не аргумент в пользу надежности из-за динамики, т.к. Java или C# являются не менее сильно-типизированными.

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

Позволю себе усомниться в ваших оценках сложности и глючности C++ кода. Исходя из собственного опыта.

E>>Рад, что вы настолько уверенны в своей системе.

E>>Хотя, основываясь на своем скромном опыте, мне это кажется в большей степени рекламным слоганом, ну или попыткой самоубеждения
G>Все просто — изоляция процессов спасет отцов русской демократии...А точнее, принцип "let it crash" ( в переводе — да пусть оно сдохнет ). Процессы, порожденные клиентской проксей — чисто пассивные. Их дело — обрабатывать запросы и рассылать уведомления. Если один из них загнется, никто, кроме ядра, этого не заметит. Да и ядро сделает запись в лог и забудет об этом. Процессы, порождаемые запросами от клиента, не имеют прямого доступа к ядру и уронить его не могут при всем желании. Ежели они сдохнут, то клиенту уйдет уведомление об этом. Клиентская сессия продолжится далее

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Бизнес-логика на Erlangе
От: Курилка Россия http://kirya.narod.ru/
Дата: 15.05.07 12:15
Оценка:
Здравствуйте, eao197, Вы писали:

E>Я и не говорил, что он мне не нравится. Но, если об extensions не задумываться, то весь код ПМ вида {msgSignature, X} придется переделывать в {msgSignature, _, X}, а затем в {msgSignature, _, X, _}, а затем в {msgSignature{Y,Z,_},_,X,_,_} и т.д.


Нет, у нас в данном случае 1 "точка развития", правда можно сделать опцию (которая уже находится в какой-то "точке") с точкой развития, но тут уж сам себе злобный буратино
Т.к. точка есть лист, то туда можно напихать всё, что душе угодно, забота получателя разобрать нужные опции (и игнрорировать те, что он не понимает).
Re[16]: Бизнес-логика на Erlangе
От: aka50 Россия  
Дата: 15.05.07 13:44
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Курилка, Вы писали:


E>>>Подробнее о том, что такое "проблема второй версии протокола" я рассказывал здесь
Автор: eao197
Дата: 29.06.05


К>>И чем тебе не нравится предложенный мной вариант? Делаем сообщение аля {msgSignature, [...extesions...], someData}

К>>Промежуточному слою нахрен не нужны extensions, поэтому в бранче ПМ будет что-то типа {msgSignature, _, X}

E>Я и не говорил, что он мне не нравится. Но, если об extensions не задумываться, то весь код ПМ вида {msgSignature, X} придется переделывать в {msgSignature, _, X}, а затем в {msgSignature, _, X, _}, а затем в {msgSignature{Y,Z,_},_,X,_,_} и т.д.


Ну это просто обходится, достаточно "подумать заранее"

abstract class Msg
case class NoExt extends Msg
case class MsgSig(val a: int, val ext: Msg) extends Msg
case class MsgExt(val b: int, val ext: Msg) extends Msg

object Proto {
  def doit(m: Msg) = {
    System.out.print("In doit:")
    m match {
      case MsgSig(a, _) => System.out.println("generic simple a=" + a)
    }
  }
  def doit2(m: Msg) = {
    System.out.print("In doit2:")
    m match {
      case MsgSig(a, MsgExt(b, _)) => System.out.println("extended a=" + a + " b=" + b)
      case MsgSig(a, _) => System.out.println("pure simple a=" + a)
    }
  }
  
  def run() = {
    for (i <- MsgSig(1, NoExt()) :: MsgSig(2, MsgExt(3, NoExt)) :: Nil) yield {
      System.out.println("Message: " + i)
      doit(i)
      doit2(i)
    }
  }
}


scala> Proto.run
Message: MsgSig(1,NoExt())
In doit:generic simple a=1
In doit2:pure simple a=1
Message: MsgSig(2,MsgExt(3,NoExt()))
In doit:generic simple a=2
In doit2:extended a=2 b=3
unnamed6: List[Unit] = List((), ())


Менее strict, но возможно более гибкий на списках (и возможно тормознее)

abstract class Msg
case class MsgSig(val a: int) extends Msg
case class MsgExt(val b: int) extends Msg

object Proto {
  def doit(m: List[Msg]) = {
    System.out.print("In doit:")
    m match {
      case MsgSig(a) :: xs => System.out.println("generic simple a=" + a)
      case Nil => 
    }
  }
  def doit2(m: List[Msg]) = {
    System.out.print("In doit2:")
    m match {
      case MsgSig(a) :: MsgExt(b) :: xs => System.out.println("extended a=" + a + " b=" + b)
      case MsgSig(a) :: xs => System.out.println("pure simple a=" + a)
      case Nil => 
    }
  }
  
  def run() = {
    for (i <- (MsgSig(1) :: Nil) :: (MsgSig(2) :: MsgExt(3) :: Nil) :: Nil) yield {
      System.out.println("Message: " + i)
      doit(i)
      doit2(i)
    }
  }
}


scala> Proto.run
Message: List(MsgSig(1))
In doit:generic simple a=1
In doit2:pure simple a=1
Message: List(MsgSig(2), MsgExt(3))
In doit:generic simple a=2
In doit2:extended a=2 b=3
unnamed7: List[Unit] = List((), ())
Re[17]: Бизнес-логика на Erlangе
От: aka50 Россия  
Дата: 15.05.07 13:52
Оценка: :)
Здравствуйте, aka50, Вы писали:

E>>Здравствуйте, Курилка, Вы писали:

К>>>И чем тебе не нравится предложенный мной вариант? Делаем сообщение аля {msgSignature, [...extesions...], someData}
К>>>Промежуточному слою нахрен не нужны extensions, поэтому в бранче ПМ будет что-то типа {msgSignature, _, X}
A>Ну это просто обходится, достаточно "подумать заранее"

упсс... Курилка, это твоя идея , а я только сейчас понял что ты тоже самое предложил...
Re[12]: Бизнес-логика на Erlangе
От: gandalfgrey  
Дата: 15.05.07 13:53
Оценка:
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, gandalfgrey


E>Позволю себе усомниться в ваших оценках сложности и глючности C++ кода. Исходя из собственного опыта.

Не самого кода, но исходников, написанных программерами. Вот уж тут сбываются самые мрачные прогнозы !

E>Ok. Но наивно слычать такие рассуждения о надежности. Может вам просто не доводилось сталкиваться с логическими ошибками, которые при одних и тех же входящих данных приводят к зависанию или падению процесса. Процесс восстанавливается, восстанавливает те же самые данные и падает опять.

А бывает ! Но это легко отслеживается его прародителем
Re[11]: Бизнес-логика на Erlangе
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.05.07 14:14
Оценка:
Здравствуйте, FR, Вы писали:

FR>Рефакторинг из той же песни, он тоже получается для раздолбаев.


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

VD>>На самом деле обобщенное программирование и правильное проектирование, а так же вывод типов фактически сводят такие проблемы к нул. Но если программист раздолбай и бездарность, то правильное проектирование и применение продвинутых техник программирования может быть затруднительным. Отсюда вывод — приемущество динамики обратно пропорциональны скилу программиста . Это коечно шутка, но в ней ейсть доля шутки.


FR>Не надо сказок про правильное проектирование,


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

FR> в реальном мире такое бывает разве при переписывании старых проектов и то если не добавлять новых фич


Вы просто не умете ее готовить (с)

FR>Ну а серъезно динамика дает больше перимуществ как раз более сильным программистам.


Голословное и крайне сомнительное утверждение. Я скорее соглашусь с мнением еао197 о том, что кто к чему привык тому то и нравится. Лично мне динамика всегда мешает. Я лучше напишу пару лишних строк распознающих тип (если надо), но буду иметь полноценный контроль над тем, что делаю.

VD>>Самое сложное — это не написать кусок кода, а вписать его в уже имющуюся инфраструктуру. То и дело хочется произвести рефакторинг, изменить одно проектное решение на другое. И все это проще делать при наличии строгого контроля типов.


FR>При динамике это тоже просто.


Еще одно голословное и крайне сомнительное утверждение. При динамике никакого контроля за программистом нет. И нужно опбкладываться горой тестов.

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


FR>Влад не провоцируй на разговоры про так любимого тобой Блаба


Блаба? Я на динамических языках поработал не мало.

FR>По опыту на небольших и средних проектах


Я не говорю о детских игрушках которые можно наклепать одному за месяц. Это на чем угодно можно сделать.

FR> динамический язык (питон) требует не больше формальных тестов чем статический (хорошо написаный код на C++).


О, опять С++. Несомненно, не типобезопасный язык может требовать тестов не меньше чем динамический. В прочем, динамика по любому требует больше тестов. Если их нет, то просто снижается качество продукта.

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


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

VD>>Кумаю, что если вы замените Qt хотя бы на Яву, то будет еще очевиднее, что дело не в динамике. А там уже будет рукой подать до перехода на Скалу. И тогда уж станет просто кристально ясно, что дело было точно не в динамике .


FR>Думаю ява даст сильный тормоз за счет приличного увелечения объема кода. Скала вряд ли даст какое либо ускорение.


Агащазблин. Ява даст увеличение объема кода по сравнению с С++ котодм на базе Qt? я плякаль.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Бизнес-логика на Erlangе
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.05.07 14:14
Оценка:
Здравствуйте, Mamut, Вы писали:

VD>>Понимаешь ли в чем дело. Есть утверждения спорные и их можно понять. А есть абсурдные. Вот это было отнюдь не спорным.


M>Ну, не знаю Имхо, флейм статика vs. динамика еще не закончен


Дык речь, то не о нем. Речь то о надежности которую можно достичь только на динамике .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Бизнес-логика на Erlangе
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.05.07 14:14
Оценка: :)
Здравствуйте, gandalfgrey, Вы писали:

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


VD>>На Дельфи создана масса сложнейших систем. И они уже давно работают. Уже этот факт подтверждает, что на ней точно можно это делать.

G>Так-таки и сложнейших ? А можно пару примеров ?

Еще в 1998-ом на выстовке SoftTool минимум треть всех систем автоматизации предприятий были на Дельфи. Названий у меня нет, но я знаю где тебе их моутт дать.

VD>>Тут разумно говорить о сложности разработки, а не о надежности.

G>Одно с другим связано, причем напрямую. Ежели для достижения одного и того же функционала сложность разработки на одной платформе превышает сложность разработки на другой в разы, то не будет ли таковым ( или близким к тому ) и соотношение надежности этих разработок ?

Так еще раз.
1. Сложность разработки не имеет никакой корелляции с динамикой и статикой.
2. Объем и сложность системы не имеет прямой зависимости от ее надежности (устойчивости к сбоям). Надежность определяется проектными решениями и качеством тестирования. В том числе надежнаость увеличивается если при прочих равных использвут типобезопасный, статически-типизированный язык, так как это снижает требования по объему тестирования. Причем, заметь, применение статики не "единственно возможный шанс добиться качества", а фактор способствующий его увеличению.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Бизнес-логика на Erlangе
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.05.07 14:14
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Всегда было интересно посмотреть на примеры использования Немерля в реальных проектах. Таковые есть?


Лично я занимаюсь Интеграцией с VS 2005 и самим компилятором. Оба проекта довольно серьезные. Кмпилтор, пожалуй самый большой проект. Так же можно поглядеть на генератор парсеров который делает konsoletyper. Насколько я знаю доступны коды автоматического проверяльшика доказательств теорем который пишит один из разработчиков компилятора (точную ссылку не знаю). Есть так же ряд частных разработок, но они закрытые, так что посмотреть их код не представляется возможным.

ЗЫ

Зачем так оверквоить?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Бизнес-логика на Erlangе
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.05.07 14:14
Оценка:
Здравствуйте, eao197, Вы писали:

E>Потому, что мы с тобой спорим в общей священной войне dynamic vs static, в которой много факторов и надежность отнюдь не главный. Здесь же утверждалось, что динамика способствует надежности. Будучи приверженцем динамики я, все-таки не наблюдал такой прямой зависимости между динамикой и надежностью. Поэтому и влез в этот спор, чтобы понять, может я чего не знаю еще.


Приятно видеть объективность в довольно религиозном вопросе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Бизнес-логика на Erlangе
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.05.07 14:14
Оценка:
Здравствуйте, FR, Вы писали:

FR>Но обычно приверженцы статики кричат чуть ли об абсолютной ненадежности динамики.


Мне кажется, что тебе кажется.

Вменяемые люди понимают, что на нет одного определяющего фактора. Такие факторы как типобезпасность несомненно сильно влияют на качество ОП (здесь ведь под надежностью понимают именно это). Статическая типизация так же положительно влияет на качество ПО, так как устраняет целые классы ошибок. Но конечно же остается еще море мест где она бессильна. Так что вполне нормально когда программа на динамическом языке более надежна чем скажем на С++, так как он не типобезопасен. Да и нет ничего необычного в том, что скажем программа на Питоне окажется надежнее чем аналогичная программа на Яве. Ведь первая может быть лучше спроектирована и тщательнее оттестирована. Но так же вполне очевидно, что статическая типизация не может негативно влиять на качество ПО сама по сибе (как по сути утверждает автор высказывания).

FR> Что тоже неправда. Наверно поэтому Влад так разошелся, это же красная тряпка когда утверждают нечто абсолютно противоположное одному из его любимейших мифов


Ты меня с кем-то путашь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Бизнес-логика на Erlangе
От: Tonal- Россия www.promsoft.ru
Дата: 15.05.07 18:10
Оценка:
FR>>Рефакторинг из той же песни, он тоже получается для раздолбаев.
VD>Это зависит. Но сам факт стремления к улучшению кода говорит сам за себя.
VD>Жить без рефакторинга вообще практически невозможно. В процессе работы над той или иной проблемой нам открываются новые знания (подробности о которых раньше мы не могли знать). Это приводит к корректировке планов. Без рефакторинга проект быстро превращается в ночной кошмар. А с рефакторингом развивается дальше.
+1

FR>> в реальном мире такое бывает разве при переписывании старых проектов и то если не добавлять новых фич

VD>Вы просто не умете ее готовить (с)
Всегда завидовал людям, которые не работают с внешними заказчиками.

VD>>>Самое сложное — это не написать кусок кода, а вписать его в уже имющуюся инфраструктуру. То и дело хочется произвести рефакторинг, изменить одно проектное решение на другое. И все это проще делать при наличии строгого контроля типов.

FR>>При динамике это тоже просто.
VD>Еще одно голословное и крайне сомнительное утверждение. При динамике никакого контроля за программистом нет. И нужно опбкладываться горой тестов.
Зачем гора? Старые тесты как работали, так и остануться неизменными. Дописать придётся только для новых вариантов.
А вот в статике, придётся переписывать довольно много,.. и все старые тесты тоже,.. что требует гораздо больше усилий для подобных изменений несмотря на помощь компилятора.

VD>Блаба? Я на динамических языках поработал не мало.

У всех бывают свои личные неудачи.

VD>>>Кумаю, что если вы замените Qt хотя бы на Яву, то будет еще очевиднее, что дело не в динамике. А там уже будет рукой подать до перехода на Скалу. И тогда уж станет просто кристально ясно, что дело было точно не в динамике .

FR>>Думаю ява даст сильный тормоз за счет приличного увелечения объема кода. Скала вряд ли даст какое либо ускорение.
VD>Агащазблин. Ява даст увеличение объема кода по сравнению с С++ котодм на базе Qt? я плякаль.
А где я говорил про Qt и С++?
Проекты делаються на Python + Qt. Библиотека биндинга называется PyQt. Qt Designer производит xml-ку по которой генерируется код на Python. На систему сигнал-слот просто идеально ложаться замыкания. Ни одной стрчки на С++ там нет, и пока не предвидиться.
Так что с Явой мы пока обождём.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[10]: Бизнес-логика на Erlangе
От: Tonal- Россия www.promsoft.ru
Дата: 15.05.07 18:15
Оценка:
Здравствуйте, eao197, Вы писали:
T>>Вот тут и появляется выигрышь динамической типизации — решение о конкретном типе можно откладывать. А в случае, если его приходиться менять, практически не требуется менять сопредельные интерфейсы.
T>>Соответственно разработка обладает большей мобильностью.

E>Опять же, речь не о мобильности, а о надежности.

E>Все же это разные вещи.

T>>Ну и сериализация, которая для динамики делается гораздо сильно проще чем для статики.

E>Да ладно, стоит один раз нормально сделать , а потом использоваться без всяких заморочек.
И в плоские файлы и в базу даных одну систему сериализации? Сильно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[13]: Бизнес-логика на Erlangе
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.05.07 18:58
Оценка:
Здравствуйте, Tonal-, Вы писали:

T>А где я говорил про Qt и С++?

T>Проекты делаються на Python + Qt. Библиотека биндинга называется PyQt. Qt Designer производит xml-ку по которой генерируется код на Python. На систему сигнал-слот просто идеально ложаться замыкания. Ни одной стрчки на С++ там нет, и пока не предвидиться.
T>Так что с Явой мы пока обождём.

Ясно. Значит я тебя не так понял.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Бизнес-логика на Erlangе
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.05.07 19:11
Оценка:
Здравствуйте, Tonal-, Вы писали:

T>>>Ну и сериализация, которая для динамики делается гораздо сильно проще чем для статики.

E>>Да ладно, стоит один раз нормально сделать , а потом использоваться без всяких заморочек.
T>И в плоские файлы и в базу даных одну систему сериализации? Сильно.

Под "базой данных", надо полагать, понимается реляционная СУБД. В принципе, можно и туда, в varchar или blob-поля.
А еще есть объектные СУБД, там еще проще.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Бизнес-логика на Erlangе
От: Андрей Хропов Россия  
Дата: 15.05.07 19:16
Оценка:
Здравствуйте, FR, Вы писали:

FR>Согласен языки типа Scala или Nemerle вполне могут дать близкую к питону или руби скорость разработки.


Я думаю, что даже теоретически более быструю (хотя конечно многое зависит от самого разработчика), т.к. всякие Intellisense, рефакторинги, подсветка ошибок гораздо лучше работают в IDE для статически-типизированных языков. Ну и объем кода юнит-тестов поменьше будет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Бизнес-логика на Erlangе
От: FR  
Дата: 16.05.07 11:04
Оценка: :)
Здравствуйте, VladD2, Вы писали:


VD>Жить без рефакторинга вообще практически невозможно. В процессе работы над той или иной проблемой нам открываются новые знания (подробности о которых раньше мы не могли знать). Это приводит к корректировке планов. Без рефакторинга проект быстро превращается в ночной кошмар. А с рефакторингом развивается дальше.


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

FR>>Не надо сказок про правильное проектирование,


VD>Если для тебя это сказки, то в общем-то нам больше с тобой разговаривать не о чем.


FR>> в реальном мире такое бывает разве при переписывании старых проектов и то если не добавлять новых фич


VD>Вы просто не умете ее готовить (с)


При правильном проектировании рефакторинг не нужная вещь, а ты без него жить не можешь странно да?

FR>>Ну а серъезно динамика дает больше перимуществ как раз более сильным программистам.


VD>Голословное и крайне сомнительное утверждение. Я скорее соглашусь с мнением еао197 о том, что кто к чему привык тому то и нравится. Лично мне динамика всегда мешает. Я лучше напишу пару лишних строк распознающих тип (если надо), но буду иметь полноценный контроль над тем, что делаю.


У тебя просто фобия, поэтому ты не можешь нормально пользоватся динамикой

FR>>При динамике это тоже просто.


VD>Еще одно голословное и крайне сомнительное утверждение. При динамике никакого контроля за программистом нет. И нужно опбкладываться горой тестов.


Зато есть обобщеность и легкость проскирования которая сильно облегчает правки.


FR>>Влад не провоцируй на разговоры про так любимого тобой Блаба


VD>Блаба? Я на динамических языках поработал не мало.


Извини но я не вижу что ты грокнул динамику. Без этого конечно тоже можно работать, но только на кровне блаба.

FR>>По опыту на небольших и средних проектах


VD>Я не говорю о детских игрушках которые можно наклепать одному за месяц. Это на чем угодно можно сделать.


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

FR>> динамический язык (питон) требует не больше формальных тестов чем статический (хорошо написаный код на C++).


VD>О, опять С++. Несомненно, не типобезопасный язык может требовать тестов не меньше чем динамический. В прочем, динамика по любому требует больше тестов. Если их нет, то просто снижается качество продукта.


Читай выделенное.

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


VD>Более менее серьзная программа имеет тучу мелких процедур которые взываются отнюдь не постоянно. Так что даже простое изменение может бытьне протестированно "при запусках". А уж рефакторинг точно приводит к изменениям которые требуют тотального тестирования, если конечно нет статической типизации которая спасает от многих ошибок.


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