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


V>>Любые места, где надо не просто что-то раздизайнить, а накидать кучу алгоритмов, выигрывают.

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

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


V>>Такой скорости разработки качественного кода в компилируемых средах не получается,

AVK>Надо добавлять "у меня".

Дудки, у всех кто пробовал оба подхода на серьезных задачах. Fort, Smalltalk, Lisp и даже MS Access и т.д. — это все одного поля ягоды, многие спецы и фанаты этих сред являются прекрасными спецами по различным мейнстримовым джавам, С++ или C#. Люди думают, что они являются фанатами языков/технологий, на самом деле они являются фанатами контроллируемого процесса кодирования.


V>> Потом, ессно, возврат к подробностям несколькодневной давности.

AVK>Совершенно неестественно.

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



V>>И еще. Непередаваемое чувство уверенности в результате своего труда, если был возможен описанный подход.

AVK>Лично мне такие "подпорки" не нужны.

Это твой осознанный выбор после нескольких серьезных проектов выполненных в различных подходах и сравнения эффективности разработки/отладки? Или просто так мнение?


V>>Заметил. Почти всегда, если язык и технология позволяет, в среды разработки обязательно вставляют итерактивные возможности. Случайно?

AVK>Технология дотнета это позволяла с рождения.

И сейчас не позволяет ибо компилировать надо после каждого чиха.


AVK>Однако таких возможностей в нормальном виде нет до сих пор и никакого движения в Оркасе в этом направлении я тоже не вижу.

Я вижу попытку сделать подобное для VB.Net. Нужно еще полноценное скриптовое окошко добавить. Еще нужна возможность дописывать код без перекомпиляции. Т.е. открыл некую форму GUI, начинаешь юзать. Потом, не закрывая добавляешь обработчики событий, снова отлаживаешь и т.д. В общем, пока не вылижешь как следует, не закрывать форму. И если уж закрыл, то вряд ли к ней вернешься опять. Это будет на порядок быстрее, чем традиционная отладка.

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


FR>Я конечно понимаю что вы с vdimas монстры, но все равно мне очень тяжело представить что именно можно в течени двух недель без компиляции вколачивать, может подкинете примерчики?

У меня такое было во время разработки GUI-библиотеки на основе MFC. Нужен был ремотинг для С++, + простой с т.з. программиста биндинг для физуальных форм + простая с т.з. программиста валидация и т.д. Там туча взаимодейтсвующих типов, протоколов, сценариев и т.д. Один дата-грид с кучей типов колонок и для него дата-соурс чего стоили.

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

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

V>>И еще. Непередаваемое чувство уверенности в результате своего труда, если был возможен описанный подход. Не буду описывать эмоции — не поэт. Но включаешь, а оно работает, и так работает и эдак работает, как часы.
WH>Интересно почему у меня на С++ также получается?

Это ты на похвалу так усердно напрашиваешься?
В твоей команде у скольки чел так же получится? То-то.


WH>Писал пару недель без компиляции... запускаю... работает... В худшем случае ловлю пару исключений причину которых устраняю в течении нескольких минут...

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


WH>Я после этих двух недель долбежки кода с ошибками компиляции дольше разбираюсь... по ходу дела рефакторить приходится...,

Ну у меня наоборот. Если лет десять до этого работать в средах типа Turbo C, а потом Borland C++, то это все равно что в FAR-е или блокноте сидеть. Приучает писать без синтаксических ошибок.

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



IT>Всё таки хотелось бы пример, а то без него в недели слабо верится.

Вот у меня в файлах валяется: http://files.rsdn.ru/21096/dataGrid.zip

Описание чего это: Re[8]: JRuby, RubyCLR, IronPython — зачем?

Автор: vdimas
Дата: 02.11.06

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

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

V>Пара недель — это потому что по задумке участвует много типов и у них много методов. И вся эта кухня взаимодействует.

И почему тогда не было бы проблем на Форте? Или там типов меньше и они не взаимодействуют?

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

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

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

Я бы использовал Mock Objects.
Ну и слишком большая зависимость между классами и методами — тоже плохо.

АХ>>но при тестировании выявятся и функциональные, и архитектурные просчеты.
WH>Выявляются они при уточнении требований.
WH> А требования уточнить без соседей которым нужен полнофункциональный модуль уточнить не получится.

Я думаю, что разумнее добавлять функциональность инкрементально.

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

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

IT>И не говори. Я без компиляции и трёх строчек не напишу Оно у меня фактически вместо кнопки Save, а сохраняюсь я часто.
Давно писал на С++ под линух через SSH? Ну ладно пишу я в студии через самбу но компилить всеравно нужно через SSH.

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

WH>>А как скомпилировать усли у меня классов и методов не хватает?
IT>Всё таки хотелось бы пример, а то без него в недели слабо верится.
Ну например распределенное хранилище с транзакциями, балансировкой и репликацией. Проектная мощьность сотни террабайт данных и десятки тысяч запросов в секунду. Правда не сразу по этому будет возможность тюнить эту систему по ходу дела.

ЗЫ Вопрос на засыпку: Сколько винтов в пятом рейде должно сгореть чтобы потерялись данные?

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

V>Ну я свой код после такого три дня отлаживал и потом еще несколько раз возвращался баги искал. Просто это были времена, когда никаких бустов еще не было, и все инструментально-шаблонные примочки, т.е. базовое окружение для проекта тоже сам делал. К тому же на VS6.0. В общем, ты понял, каково приходилось твоим коллегам в прошлом.
Ну я из буста только filesystem и intrusive_ptr использую.

V>Ну у меня наоборот. Если лет десять до этого работать в средах типа Turbo C, а потом Borland C++, то это все равно что в FAR-е или блокноте сидеть. Приучает писать без синтаксических ошибок.
Синтаксис синтаксисом, а перенося кусок кода из одного файла в другой можно очень легко забыть про какойнибудь инклуд.

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

АХ>Неважно рисовать — не рисовать, главное начинать с прототипов. Продумать интерфейсы, потом мясо.
Вот прототип две недели и занял. Ибо продумать нужно было очень много. И основное время уходило не столько на сам код сколько на медетацию над ним.

АХ>Я бы использовал Mock Objects.
Ну и зачем на эту фигню отвлекатся?

АХ>Ну и слишком большая зависимость между классами и методами — тоже плохо.
Зависимость то не большая. Да и кода в конце концов получилось не много но вот только написать такие вещи с ходу не получается...

АХ>Я думаю, что разумнее добавлять функциональность инкрементально.
Дык функциональности то не много... вот только сложная она...

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


C>... и подмножеством конечных состояний F в S. Выходные значения — это какое-то неизвестное науке расширение.

Это означает, что ты не можешь "склеить" некие конечные состояния НКА в одно конечное ДКА.


C>X' = X = { 'a' }
C>S' = 2^S = { S'e = {}, S'0 = {S0}, S'1 = {S1}, S'2 = {S2}, S'01 = {S0, S1}, S'02 = {S0, S2}, S'12 = {S1, S2}, S'012 = {S0, S1, S2} }
C>s'_0 = { s_0 } = S'0
C>F' = { s' in 2^S | (forall s in s')(s in F) } = { S'12 }
C>T'(s', x) = union { T(s, x) | s in s' }
C>T'(S'0, 'a') = T'(S'01, 'a') = T'(S'02, 'a') = T'(S'012, 'a') = S'12
C>T'(S'e, 'a') = T'(S'1, 'a') = T'(S'2, 'a') = T'(S'12, 'a') = S'e

C>или в виде графа, исключая недостижимые состояния:

C>S'0 -- 'a' --> (S'12) -- 'a' --> S'e <='a'

После минимизации и нового кодирования номеров состояний ты бы по своей схеме получил бы так:

S0 --'a'--> S1

Что было бы ошибкой для приведенного примера.

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

IT>>Всё таки хотелось бы пример, а то без него в недели слабо верится.
WH>Ну например распределенное хранилище с транзакциями, балансировкой и репликацией. Проектная мощьность сотни террабайт данных и десятки тысяч запросов в секунду. Правда не сразу по этому будет возможность тюнить эту систему по ходу дела.

Круто! И почему эту крутизну нужно писать неделями не компилируя?

WH>ЗЫ Вопрос на засыпку: Сколько винтов в пятом рейде должно сгореть чтобы потерялись данные?

Без понятия. Так ты потому не компилировал код, что у тебя винты погорели?

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

V>>Пара недель — это потому что по задумке участвует много типов и у них много методов. И вся эта кухня взаимодействует.

IT>И почему тогда не было бы проблем на Форте? Или там типов меньше и они не взаимодействуют?

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

: some_stub ;

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

V>Непредсказуемого окружения обычно более половины в реальных задачах

Спорно, очень спорно. У меня такая ситуация только когда я пишу пакеты для VS. А вот сервера как правило от окружения зависят крайне мало.

V>, ибо сейчас очень много сторонних библиотек используется,

У нас не очень много.

V> да еще и сам фреймворк.

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


AVK>>Надо добавлять "у меня".

V>Дудки, у всех

Не говори за всех.


AVK>>Совершенно неестественно.

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

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

V>Это твой осознанный выбор после нескольких серьезных проектов выполненных в различных подходах и сравнения эффективности разработки/отладки? Или просто так мнение?

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


AVK>>Однако таких возможностей в нормальном виде нет до сих пор и никакого движения в Оркасе в этом направлении я тоже не вижу.

V>Я вижу попытку сделать подобное для VB.Net. Нужно еще полноценное скриптовое окошко добавить. Еще нужна возможность дописывать код без перекомпиляции.

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

V>Это будет на порядок быстрее, чем традиционная отладка.

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

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

V>>Ну я свой код после такого три дня отлаживал и потом еще несколько раз возвращался баги искал. Просто это были времена, когда никаких бустов еще не было, и все инструментально-шаблонные примочки, т.е. базовое окружение для проекта тоже сам делал. К тому же на VS6.0. В общем, ты понял, каково приходилось твоим коллегам в прошлом.
WH>Ну я из буста только filesystem и intrusive_ptr использую.

Мы как бы гораздо больше, да и я у тебя в С++-форуме кучу примеров видел с использованием много чего и даже spirit.

V>>Ну у меня наоборот. Если лет десять до этого работать в средах типа Turbo C, а потом Borland C++, то это все равно что в FAR-е или блокноте сидеть. Приучает писать без синтаксических ошибок.
WH>Синтаксис синтаксисом, а перенося кусок кода из одного файла в другой можно очень легко забыть про какойнибудь инклуд.

Ах, ты про это... Ну тогда извини, был не прав.

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

ie>Задумался тут.... А зачем они нужны?
ie>Я понимаю что интеграция всего и вся рулит, но многие ли это реально будут использовать? —

В поисках информации об истории Java наткнулся на интересную критику Java от Николая Безрукова: Slightly Skeptical Java Page (Java vs. Scripting Languages). Пара цитат для затравки интереса:

Even in comparison with old languages like PL/1, Algol 68 and Ada it does not looks as step forward. Actually PL/1 which fell victim of structured programming fundamentalism (and subsequent rise of Pascal and later C) is even today very competitive to Java. It was a solid, small by today standards and expressive language with its incredible quality of optimizing and debugging compilers on IBM mainframes: real masterpieces of software engineering). If we are talking about browser's applets Java is the right language for the wrong problem (AJAX might be a better way to address client side programming). If we are talking about server side, then for Web page generation it is a wrong language for the right problem .

или вот еще:

All-in-all I think that a decent scripting programmer can wipe the floor of a pure Java programmer of the same qualification productivity wise, unless he/she are forced into an environment that gives Java an significant edge (for example, if Websphere is adopted as an application server). Still, due to huge investment in Java enterprise tools, the mere mass of existing Java programmers and related enterprise applications create a sustainable moment for its preservation and even grouth. I think that we might need to wait until the next generation of scripting languages to really challenge Java on the server side. One might say that Gosling did two bad things for programming community: saved Emacs from obsolesce and created Java

(выделено мной).

и еще:

All-in-all Java stuck somewhere between a scripting language and a "serious" system programming language. That's why sometimes I hate Java despite its excellent programming environment.

и в завершении:

It is important to understand that Java sunset is also happening because there is a distinct fashion in today's programming culture. Consultants, language evangelists, academics and IBM brass all want the next new thing to talk about. It's probably a time for me to start to defend Java instead of attacking it: my views on "Java vs scripting languages" became too much part of the mainstream thinking As Bryan W. Taylor in his paper Java Is Dead, Long Live Java! – The Future of Java @ SYS-CON AUSTRALIA aptly noted:


The first big arena of innovation is the addition of scripting support. Some people rightly claim Ruby or Python is better the Java for some tasks. Groovy and Beanshell solve these same problems and will become a standard (in the JSR sense) part of the Java stack. Each offers something better than standalone scripting. Both integrate into a truly mixed environment with compiled bytecode and interpreted scripts interoperating smoothly. Beanshell's syntax offers as little surprise as possible for the Java developer and Groovy gives a Ruby-like syntactic efficiency, but can also be compiled to pure bytecode and reused seamlessly, a big improvement over JRuby or Jython.

Так что может сложиться впечатление, что интерес Sun-а в Jython, JRuby, Groovy в том, что уж если народ начнет отворачиваться от Java в пользу скриптовых языков, так пусть делают это на платформе JVM

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

IT>>И почему тогда не было бы проблем на Форте? Или там типов меньше и они не взаимодействуют?

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

Т.е. если дробить задачу на более мелкие части, то проблем не будет. Уже теплее Тогда ещё вопрос. Почему у тебя на форте получается, а на классах не получается писать задачу более мелкими кусочками? В чём проблема?

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

V>Мы как бы гораздо больше, да и я у тебя в С++-форуме кучу примеров видел с использованием много чего и даже spirit.
Ну так это когда было... Фигня все это.

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

WH>>Ну например распределенное хранилище с транзакциями, балансировкой и репликацией. Проектная мощьность сотни террабайт данных и десятки тысяч запросов в секунду. Правда не сразу по этому будет возможность тюнить эту систему по ходу дела.
IT>Круто! И почему эту крутизну нужно писать неделями не компилируя?
Тут есть две причины:
1) Основное время занимала медитация над всем этим делом.
2) Держать в согласованном состоянии куски системы которая находится в стадии активного медетирования накладно. Отвлекает от медитации.

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


V>>Это твой осознанный выбор после нескольких серьезных проектов выполненных в различных подходах и сравнения эффективности разработки/отладки? Или просто так мнение?

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

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

Например, прежде чем я осознано перешел на дотнет, я потратил год на игры и небольшие фрилансерные проекты (старался браться за самые дотнетно-системные). Если бы 1.0 вышел с текущими возможностями 2.0 (и готовый решарпер) я потратил бы наверно гораздо меньше — максимум пару месяцев до стадии "осознанности". Ибо после С++ на 1.0 писать было очень и очень некомфортно, типа как на Java (на которую я пять лет пытался "осознанно" перейти ).


AVK>Отладка требуется обычно в таких ситуациях, когда скриптовое окошко помочь неспособно.

Это окошко может помочь быстро воссоздавать сложные отладочные ситуации. В общем, отладочное окно — это нормальный такой полезный инструмент.