Андрей Александреску, The Case for D

> Блин. Таблица имеет размер не 2^32 элементов, а меньше, так что значение хеш функции усекается.

для начала почитай классическое определение хеш-таблицы, хотя бы тут:

http://ru.wikipedia.org/wiki/%D0%A5%D0%B5%D1%88-%D1%82%D0%B0%D0%B1%D0%BB%D0%B...

То что сделано в javе это уже что-то другое.

Используются обычные линейные списки.

Очень плохо если используются. Но я в это не верю, пруф что в jave используются линейные списки для разрешения коллизий?

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

Все просто. Когда мы добавляем строку в хеш-таблицу, у этой строки запрашивается хеш, т.е. вызывается функция hashCode() или ее аналог в плюсах. В случае явы эта функция вычисляется всего один раз за весь жизненный цикл строки. Для плюсов же значение хеша мы должны вычислять всякий раз, когда одна и та же строка добавляется в разные таблицы. В этом случае плюсы будут сдавать яве. Хотя это решаемо заменой std::string на что-то другое.

Актуальным является unordered_map, но скорее всего, у него похожие проблемы с std::string строкой.

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

?! это как - 'физическую гарантию'? Куда уж физичнее если на с++ код нарушающий const не скомпилится?

В случае явы эта функция вычисляется всего один раз за весь жизненный цикл строки.

Ты хотел сказать до первого изменения ;)

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

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

Как я уже сказал - преимущество параллельного хранения и заботы об актуальности хеша в каждой строке очень сомнительно. java выходит тормозит не только потому что компилится во время работы :)

Жизнь сложнее. Когда таблица растет, то она переаллоцируется. Хеши могут быть повторно запрошены. И вот здесь плюсовый принцип «не платишь за то, что не используешь» уже не работает. Надо либо где-то хранить вычисленные хеши, либо вычислять их заново.

>для начала почитай классическое определение хеш-таблицы, хотя бы тут

Ты сам то читал что там по ссылке? Да и почитай имплементации чтоле. В джаве сделано самое оно.

Очень плохо если используются.

Очень хорошо. И используются.

> Ты хотел сказать до первого изменения ;)

Все таки зря ты стал переводить термин immutable на плюсовый аналог.

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

Таблица внутри может быть переаллоцированна. И тут опять нужны уже вычисленные хеши. См. мой предыдущий пост.

>Ты хотел сказать до первого изменения ;)

В джаве строке НЕ МЕНЯЮТСЯ.

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

Хде???

Добавлю. Хотя зависит от реализации хеш-таблицы...

> в jave используются линейные списки для разрешения коллизий

Да, так и есть...

for (Entry e = tab[index]; e != null; e = e.next) if (e.hash==hash && e.equals(entry)) return true;

вообще понятно, она просто рехешится в неизвестные пользователю моменты времени.

>Ты хотел сказать до первого изменения ;)

Как всегда у любителей С++ проблемы с конструктивизмом.

Вопрос: А в каких местах программы меняются строки? Ответ: Либо при разборе (парсинг), либо при выводе (форматирование). Когда они гуляют туда-сюда внутри программы они не меняются.

Исходя из новополученных знаний, непонятно при чём тут HashTable. Просто в java любой ключ обязан уметь считать и по желанию хранить свой hash, при этом делаются предположения относительно изначального использования этих ключей - оказывается они должны использоваться только для форматирования или парсинга. Преимущество крайне сомнительное, ограничения немного странные, но сойдут.

Ну напиши в C++ map <const string, string> будет тебе immutable ключ.

>>Делалось утверждение что время такой операции [например поиска] зависит от размера хеш-таблицы. С этим, собственно я и не согласился. Не влияет это.

Хде???

Есть подозрение что всё дело в том, что const std::string не так умен что бы кэшировать _своё hash_ - значение, которое _вычисляется за линеёную сложность_. _Что и давала у меня проседание на большой таблице так сильно._

Как ещё это понять?

А дополнительную путаницу привнесло то что, ни я ни std::string вообще не подозревают что у std::string есть _своё_ хэш-значение :)

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

Вопрос: Зачем в программах вообще нужны строки?
Ответ: Для того чтобы читать и писать данные в формате воспринимаемым человеком либо хранить определения принятые у человека типа ФИО или географических названий.
Вопрос: Если строки используются для взаимодействия с человеком, то и вся обработка строк происходит при взаимодействии с человеком?
Ответ: Да, вся работа с ними происходит GUI-части программы или при разборе текстовых файлов или параметров коммандной строки предоставленных пользователем. Отдельный вопрос это хранение строк, например в СУБД, но там лучше сопоставлять строкам какой-то более натуральный для машины бинарный ID и работать с ID.

>Ну напиши в C++ map <const string, string> будет тебе immutable ключ.

Он и так в шаблоне map-а добавляет квалификатор const на тип ключа. Толку от этого как видим немного.

>Хеши могут быть повторно запрошены. И вот здесь плюсовый принцип «не платишь за то, что не используешь» уже не работает. Надо либо где-то хранить вычисленные хеши, либо вычислять их заново.

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

Конечно, можно. Кто спорит. Вопрос в том, а надо ли, когда есть много других готовых средств? Тот же F#, например. Убойная вещь. .NET/Mono + функциональщина в одном флаконе. Даже монады есть, только официально называются workflows и/или computation expressions. Нафига нужны тогда плюсы? ;)

бугага!!!

директ это COM, чистый Си

вы еще сомной поспорте
лучше молчите если не знаете

доколе еще будут процветать авторы, с ослиным упорством не

замечающие прекрасный и мощный язык PHP? этот даже javascript и perl

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

да ты и новость не читал)
причем тут скриптовые языки?

Loki, ZeroBugs. Кстати, вряд ли многие из отметившихся в треде

смогут что-то, сопоставимое с Loki по сложности, написать.

если чесно то это все такая же гадость как и его STL
книги он пишет неплохие
излагает тоже хорошо
но на практике все у него убого

Ну и неудивительно, что D вам после этого начал «видиться».

пока что так
я подожду когда на D реализуют огромный проект
дабы увидеть все это в действии
и полистать сам код
что бы оценить наскоко проще все это можно было бы сделать на С++
если будет намного проще - то судьба языка D обречена токо на интузиастов

неплохо если реализуют на D какойто из уже известных проектов на C++
для сравнения
потому что все познаеться в сравнении

пока что все разговоры о D - теоретические
что то
как то
где то
но кроме hello world смотреть нечего

точно
и под IDA+pdb это четко видно что там С++ классы
а эти классы екпортируються от своих vtbl в Interface - вот это он похоже и называет COM )))ггг

> я подожду когда на D реализуют огромный проект

Сколько же вам десятков огромных проектов надо показать, чтобы вы успокоились? Тех пяти, что проскакивали на ЛОРе в новостях и комментах явно недостаточно.

> что бы оценить наскоко проще все это можно было бы сделать на С++

Смею заверить, на C++ "всё это" было бы проще на отрицательную величину.

> неплохо если реализуют на D какойто из уже известных проектов на C++

http://www.digitalmars.com/dscript/index.html - Интерпретатор JavaScript на C++ и D1.

Сколько же вам десятков огромных проектов надо показать, чтобы вы

успокоились? Тех пяти, что проскакивали на ЛОРе в новостях и

комментах явно недостаточно

я на лоре не живу сколько живете вы)
и после обсуждения этой новости скорее всего откланяюсь и уйду

Смею заверить, на C++ «всё это» было бы проще на отрицательную

величину

врядле

http://www.digitalmars.com/dscript/index.html - Интерпретатор

JavaScript на C++ и D1.

мне интересны более практичные вещи нежели какойто интерпретатор
вот если бы игровой двиг написали на D
или WM под Linux
или что то касающееся VoIP
ну и уже было бы замечательно если перепишут Linux на D
вот тогда будет что оценить, посмотреть

еще не линукс, но уже кое-что http://wiki.xomb.org
игровой двиг - arclib и moonglide

>> Смею заверить, на C++ "всё это" было бы проще на отрицательную величину
> врядле

(КЛБ) Почитайте перевод ;)

> мне интересны более практичные вещи нежели какойто интерпретатор

Конечно! JavaScript никому не нужен, никто в мире на нём не пишет и не использует и он не встроен во все приличные браузеры.

> вот если бы игровой двиг написали на D

Сейчас есть один 3d в разработке. Оставьте свои контакты, сообщим при завершении.

И давно есть arclib для 2d.

> или WM под Linux

Это по вашему огромный проект?

> ну и уже было бы замечательно если перепишут Linux на D

Сначало надо переписать Linux на С++. ;) А то сравнивать будет не с чем. Займётесь?

полистать сам код
что бы оценить наскоко проще все это можно было бы сделать на С++

Мне, наверное, отказывает зрение. Неужели я вижу, что тут написано "проще"?

Нет, увы, я мое зрение в полном порядке! Но это же вздор, разве может человек, в здравом уме, утверждать подобное?!

Данный субъект или имеет чрезвычайно закостенелые взгляды, либо умалишенный.

Срочную медицинскую помощь! Санитар!

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

Есть еще ньюанс - substring в жабе O(1) тоже благодаря иммутабельности и осутствия необходимости поддерживать связь с Си с его char* и \0'

В D string - это immutable(char)[].

auto str = "Hello, world!";
auto substr = str[0 .. 4]; // O(1), как и для всех слайсов в любые массивы.
writefln(substr); // -> Hell

у вас проблемы с русским или с С++?

вот если бы игровой двиг

Yage Moonglide team0xf в свое время разрабатывала шутер. Шутер не доделали, но подарили сообществу D огромное количество полезного кода, библиотек и утилит.

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

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

или WM под Linux

Это по вашему огромный проект?

огромный _или_ практичный
))

сам по себе жаваскрипт интерпретатор ведь не интересен
вот если есть уже и www броузер на D
тогда я думаю есть уже на что смотреть

тема уже становиться для меня скучной)

а тем кто сомневаеться в наличии слова ПРОЩЕ в русском языке - советую заглянуть в словарик)

а о том что очень многе не знаю и не умеют программироватьна С++ гугл уже давно доказал(((
отсюда и такая репутация мол в java или С# быстрее работают сборщки мусора
и язык D будет еще быстрее - угу))

дада споры не утихают досих пор
потому что спорят те же знатоки С++ что и пишут плохой код

кошки в микроволновке .... да

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

И сколько можно коверкать Русский Язык? :) Я с трудом понимаю Вашу речь.

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

>Есть еще ньюанс - substring в жабе O(1) тоже благодаря иммутабельности и осутствия необходимости поддерживать связь с Си с его char* и \0'

Какой ужас! Я и не думал, что в жабе всё настолько плохо. И после этого ты ещё к STL придираешься.

Расскажи ка мне, а что будет, если я сделаю строку мегабайт на пять, а потом возьму от неё подстроку из трёх букв, и первоначальную строку удалю^W выкину? Елки палки, если в си++ подводные камни, то в java - подводные эвересты. Из динамита.

>Расскажи ка мне, а что будет, если я сделаю строку мегабайт на пять, а потом возьму от неё подстроку из трёх букв, и первоначальную строку удалю^W выкину?

И ипять любителя С++ волнуют не обекты реального мира, а гипотетические строки размером в пять мегабайт. То что более типичная задача типа нарезки полученных из IO строк на токены это не O(N^2) а O(N) это какбе не важно.

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

Прошу прощения. Не мог вчера комментировать.Занят был.

Итак.

Вот, например, как думаете, что выведет следующий код?

#include <cstdio> int main(){ const int x = 1; *(int*)(&x) = 3; printf(«%d\n», x); printf(«%d\n», *(&x)); printf(«%d\n», *(int*)(&x)); return 0; }

Совершенно ожидаемо он выводит 1 1 3 (подчеркну — ожидаемо для С++). Кстати, здесь, вообще говоря, ни чего дикого нет. Этот подход справедлив что для С, что для С++. Но он, мягко говоря, не очень хорош, т.к. при минимально-косметической правке, С-код вида:

#include <stdio.h> int main( int argc, char *argv[] ) { const int x = 1; *(int*)(&x) = 3; printf(«%d\n», x); printf(«%d\n», *(&x)); printf(«%d\n», *(int*)(&x)); return 0; }

выдаст... «3 3 3». Что, на самом деле, является более верным в части применяемых операторов («алгоритма» в данном случае), а не определения данных. Ну да, мы создали константную переменную, значение которой не изменяется напрямую. Следовательно, явных ошибок нет. Например, на этапе компиляции вот такой вариант дал бы ошибку:

const int x = 1; x = 7; Да. От таких ошибок const спасает. Но не спасает от некорректного обращения с данными. В С этот момент более чётко выражен. Что, собственно, мы и видим. С точки зрения реализации, вывод С-программы честнее. Есть действие по изменению данных — есть его результат.

Страуструп, конечно, зря использовал синтаксис из С. Он-то хотел облегчить переход с С на С++, но он не учитывал того, что со временем появится поколение программистов, которое не хочет знать С (и не знает, если честно). Которое искренне считает С подмножеством С++, исходя из схожести синтаксиса и «забивая» на семантические различия языков. По-моему, это неправильно, но Бог бы с ним.

Говоря о «дырке» я подразумеваю что не всегда путь «изменения всего, что нельзя поменять, поменять можно при должных усилиях», правилен. В конце-концов, «области видимости» и связанные с ними ограничения не зря были придуманы.

> const int x будет помещён в readonly память и попытка изменить эту ячейку бросит аппаратное исключение.

Нет. Прежде всего потому, что такой памяти на процессорах как правило нет. Уточняю — на процессорах «общего назначения» — Intel, AMD, ARM, ... На специализированных процессорах, возможно :) она и есть. Но это вырожденный и нами не рассматриваемый случай.

На самом деле, убедиться в том, как именно будет работать этот код можно просто. Сделайте вывод асемблерного кода в файл. Для С++ — g++ -O3 -S test_cpp.cpp, для C — gcc -O2 -S test.c. Получите файлы test_cpp.s и test.s соответственно. Различий в коде будет... «немного». :)))

Но они будут.

> Линус большинство своей жизни программировал свой процессор где никакого программирования толком нет тем самым он себе нарушил представления о языке С ну и темболее С++ Линус и не знал

Да? Правда? И Алан Кокс (не обращайте внимания на фамилию) то же программировал свой процессор? И бОльшая часть кернел-хакеров? Линус это не «гордый одиночка», ночами ваяющий свою систему, назло Майкрософту, уверяю Вас...

На данный момент это уже целая толпа народа, которая далеко не вчера получила свои «дипломы программистов» (скорее, «справку о том, что не дурак») и прекрасно знает отличия С от С++. Не по наслышке и не по лекциям укуренного в хлам препода, где-то скоммуниздившего пиратскую винду и M$ DevStudio, скачавшего из Сети пару книжек и вещающего о том, что де он знает как надо писать софт. Уверяю Вас. Не знает.

Теперь по цитате из Торвальдса:

3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."

На самом деле, он действительно прав. Не важно на каком языке реализована та или иная концепция. Важно насколько эффективно она реализована в результирующем (бинароном коде). Не привело ли это к тормозам.

В случае (как и сказано файловых систем), есть чёткое определение что ФС долждна делать — создавать/удалять/.../записывать/читать/ файлы. Причём, ядру совершенно не важно какая именно ФС — рейзер или экст2, а может и сквашфс какая-нибудь. Для подсистемы ФС _ядра_ любая из используемых ФС является объектом. Детали реализации в подсистеме самой по себе ФС не важны. Неважно как именно ФС открывает файл. Важно что когда происходит системный вызов open() файл открывается и возвращается дескриптор открытого файла. Парадигма ООП на С...

Посмотрите сами в исходниках ядра. Там масса примеров такого подхода.

нет не получться не моно ядро

все будет зависить от реализаци исключений

Хорошо. Давайте проще. Напишите свою реализацию ядра. На С++. Вы же, в отличие от Торвальдса, его знаете? :) Сделайте (для начала) планировщик, потом, если не отпадёт охота, то продолжайте расширять своё ядрышко-чистый изумруд за счёт _конвертации_ («напрямую» использовать не пойдёт — не честно) существующих драйверов. Это так... Минимум, что называется...

Ну, потом расскажете — стоило ли оно того, или на самом деле, C++ в данном, конкретном случае is sucks. Я же, в свою очередь, опять-таки приведу пример Symbian (почему бы я в такое не ввязался). Уж больно много с Symbian S60 FP от 1 до 5 горя хапнул (опосля PalmOS SDK) — там, в полностью на С++ написанной ОС, всё весьма не гладко. И надо смотреть какой же класс тут применяется — например, чистит он за собой стек или нет. И как он высвобождает ресурсы — сам или попросить надо. Попа, одним словом. Полная.

> каким боком COMовость доказывает сишность? даже скорее наоборот, раз это COM, то это VC++ со всей мишурой в виде MIDL, ATL и тогдалие. скомпилен директ как минимум плюсовым компилятором, на что укажет сигнатура в бинарниках в той же IDA. конечно, есть и нзкоуровневые модули у директа, написанные на си и ассемблере, но тем не менее.

На уровне ядра виндовз, которое (наверное) было изменено, системные средства, обеспечивающие возможность использования СОМ на прикладном уровне, были реализованы на С. Преимущественно на С.

Касаемо прикладного уровня, СОМовость доказывает не только сишность, но даже и асемблерность. Доказательство -> http://www.wasm.ru/publist.php?list=15 Оговорюсь сразу. Проверял. Работает.

Рекомендую найти например, win2k source code, да полюбопытствовать. Скажете — «код старенький» и «всё поменялось»? Ну... Какие, Вы, право, привередливые... :) М$ только и делает, что весь свой код переписывает. С нуля. :)

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

Если вы не смогли осилить в чем разница между L, LC и LD методами, R, C и T классами то это ваши личные трудности. Я не говорю что это хорошо. Лично мне не нравится что поведение кода завязывается на naming convensions, но если код под Symbian написан граммотно, то он более чем понятен.

> Если вы не смогли осилить в чем разница между L, LC и LD методами, R, C и T классами то это ваши личные трудности. Я не говорю что это хорошо. Лично мне не нравится что поведение кода завязывается на naming convensions, но если код под Symbian написан граммотно, то он более чем понятен.

Нет. Всё нормально. Осилил. Я просто говорю о том, что это не хорошо. Не более. И сравниваю, кстати, с куда как более простым в использовании, но к сожалению, помершим, PalmOS SDK. Там всё решалось намного проще. При (например) программировании для той же Treo 650. По поводу naming conversions это туда же.

Собственно, по большому счёту я говорю о том, что НЕ ВСЕГДА ИСПОЛЬЗОВАНИЕ С++ ЯВЛЯЕТСЯ ПРЕИМУЩЕСТВОМ ПРОЕКТА. Иногда это недостаток. И весьма крупный. В случае с «ядром» это может оказаться не столько решением проблем, сколько порождением новых.

>печально что такие горе программисты портят репутацию С++ языка

О! Ещё один большевик проклюнулся "В Светлое Будущее в газенвагене!"
Кто, по твоему мнению, хороший программист, тот, кто умеет логично мыслить или тот, кто разбирается во всех алогичностях и подводных камнях компилятора?

>в программисты идут люди безграммотные и не прибитые к этому

а мне отрасль программирования представляется этаким заводом под завязку забитым разнообразным оборудованием, квалифицированными рабочими, управленцами, маркетологами и... ни одного инженера :)

>То что более типичная задача типа нарезки полученных из IO строк на токены это не O(N^2) а O(N) это какбе не важно.

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

К сведению: в плюсах такие «быстрые» строки пишутся за пару часов. Но ни в stl, ни в boost их нет. Почему? Потому что не нужны.

> Нет. Всё нормально. Осилил. Я просто говорю о том, что это не хорошо. Не более. И сравниваю, кстати, с куда как более простым в использовании, но к сожалению, помершим, PalmOS SDK.

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

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

Полагаю, что из первого (умения логически мыслить) рано или поздно должно... «изтечь» второе. :)

>С++ сложный (!) для освоения

В том-то и дело, что C++ не сложен для освоения (если его учить не по Страусу :), а сложен для ИСПОЛЬЗОВАНИЯ.

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

Абсолютно с Вами согласен! И с историческими причинами в особенности! Кстати, на той же пальме был С++ и даже, как-то там был STL. Положа руку на сердце, скажу сразу. Не пользовался. Протестировал, обнаружил значительное увеличение результирующего файла, посмотрел на коммулятивный эффект при расширении функционала программы, бросил. ДА. Куммулятивный эффект был и довольно значительный. Но не воткнуло. С код в том случае мог быть намного меньше.

Касаемо «истории» Symbian, я могу ещё один прелюбопытнейший факт привести — на тот момент, о котором я сейчас напомню, было по сути дела, две более-менее удобоваримые платформы — симбиан и пальма. ПокетПиСи тогда вообще наглухо выносил мозг.

Вспомните — именно в Symbian группировка, если не ошибаюсь, 29А, реализовала свой Cabir. На пальму, сколь ни старались, такое «чудовище», взгромоздить так и не смогли. А, по сути дела, именно ракспространение кабира (по-арабски «большой» :) ) дало начало всем этим «подписям» для Symbian. Чтоб юзер часом не ответил утвердительно на вопрос «Am I spread?» :)

>Полагаю, что из первого (умения логически мыслить) рано или поздно должно... "изтечь" второе. :)

а предметная область "идёт лесом", йа крутой программер, йа все "мели знаю", а маршрут не моё дело, пусть быдло-заказчик мне внятно его растолкует :)