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

Y>Не секрет, компания Российская, но названия здесь публиковать как-то не хочется. Но надо отметить, что наши заказчики забугорные. Мини-ОС полностью своя, но она действительно мини, там реализован именно тот минимум, который необходим нам. Более подробно наверное только в личке.

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

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

E>Если я лукавлю, а верите в закон дырявых абстракций, то любимые вами Java-технологии примерами таких абстракций и являются. Ну и как доведенное до апупеоза следствие -- корпоративное ПО можно разрабатывать на ассемблере без всяких там дырявых J2EE.
Ага, вначале лукавили, а теперь юродствуете, "апупеозствуете".

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

E>>Если я лукавлю, а верите в закон дырявых абстракций, то любимые вами Java-технологии примерами таких абстракций и являются. Ну и как доведенное до апупеоза следствие -- корпоративное ПО можно разрабатывать на ассемблере без всяких там дырявых J2EE.
R>Ага, вначале лукавили, а теперь юродствуете, "апупеозствуете".

А что еще делать, если кто-то всерьез воспринимает словоблудие Джоеля Спольски?

Здравствуйте, eao197, Вы писали:
E>А что еще делать, если кто-то всерьез воспринимает словоблудие Джоеля Спольски?
А у вас какие-то полезные комментарии по поводу его рассуждений? Или всё, что скажет Спольски, априори неверно?

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

E>А что еще делать, если кто-то всерьез воспринимает словоблудие Джоеля Спольски?
Может генерировать свое в стиле "и в то время, как наши космические корабли бороздят просторы" (Re[9]: О программировании

Автор: eao197
Дата: 07.10.08

, 1 абзац)?

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

E>Разговоры о знании принципов -- это всего лишь разговоры. Например, понимание принципов работы современных СУБД -- это как понимание принципов современной атомной модели: где-то что-то слышал про электроны, протоны и нейтроны. Кто-то из них еще состоит из кварков, которые как-то хитро могут объединяться между собой. Так же и СУБД -- есть анализатор запросов, есть оптимизатор, есть какая-то система хранения, есть write-ahead-log. Практической пользы от этих знаний -- никакой.
В жизни не видел людей, которые способны успешно оптимизировать запросы, не понимая, что означает query plan. Развитие разработчика по этому пути неизбежно приводит к пониманию принципов работы. Причем совершенно не обязательно до кварков, но про index seek vs index scan знать уже нужно.

E>Людей, понимающих в ядерной физике (и способных извлекать из своих знаний пользу), как и людей, разрабатывающих СУБД -- гораздо меньше, чем тех, кто успешно пользуется результатами их труда не задумываясь о сути происходящего.
Это только повышает зарплату тех, кто задумывается о сути происходящего.

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

E>>Разговоры о знании принципов -- это всего лишь разговоры. Например, понимание принципов работы современных СУБД -- это как понимание принципов современной атомной модели: где-то что-то слышал про электроны, протоны и нейтроны. Кто-то из них еще состоит из кварков, которые как-то хитро могут объединяться между собой. Так же и СУБД -- есть анализатор запросов, есть оптимизатор, есть какая-то система хранения, есть write-ahead-log. Практической пользы от этих знаний -- никакой.
S>В жизни не видел людей, которые способны успешно оптимизировать запросы, не понимая, что означает query plan. Развитие разработчика по этому пути неизбежно приводит к пониманию принципов работы. Причем совершенно не обязательно до кварков, но про index seek vs index scan знать уже нужно.

Не согласен. Понимание плана выполнения запросов -- это одно, а понимание механизма получения этого плана из SQL-выражения -- совсем другое, а понимание того, как план будет воплощен в жизнь с учетом кластеризации, распараллеливания, управления памятью и асинхронных I/O операций -- уже третье. Более того, план выполнения запроса является видимой частью абстракции РСУБД, фактически это часть ее интерфеса. Пользователь РСУБД вынужден в той или иной мере знакомиться с ней. Как и с такими понятиями, как уровни изоляции транзакций. Тем не менее, пользователь освобождается от знаний того, как же эти уровни изоляции реализуются.

E>>Людей, понимающих в ядерной физике (и способных извлекать из своих знаний пользу), как и людей, разрабатывающих СУБД -- гораздо меньше, чем тех, кто успешно пользуется результатами их труда не задумываясь о сути происходящего.
S>Это только повышает зарплату тех, кто задумывается о сути происходящего.

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

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

По моему мнению, важно не понимание сути (т.е. знания), а способность и желание при необходимости эти знания приобретать. Довелось человеку столкнуться с SQL -- освоить в необходимом объеме и использовать. Возникли после этого проблемы с производительностью SQL запросов -- разобраться с query plan. Показали замеры, что итерации по массиву идут слишком долго -- не полениться заглянуть в литературу и узнать об особенностях кэшей и размещения данных в памяти.

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

E>>А что еще делать, если кто-то всерьез воспринимает словоблудие Джоеля Спольски?
R> Может генерировать свое в стиле "и в то время, как наши космические корабли бороздят просторы" (Re[9]: О программировании

Автор: eao197
Дата: 07.10.08

, 1 абзац)?

Отлично, оставим в стороне мои филофовские измышления по поводу "разделяй и властвуй". Вот описание суровой реальности:

• я не понимаю, что происходит внутри operator new. Не имею понятия о том, откуда берется память, какие накладные расходы накладываются как по времени, так и по размеру выделяемых блоков;
  
• я не понимаю, как просходит пробрасывание исключений после new и как они приходят в catch;
  
• я не понимаю, что происходит в коде:
  

  std::string make_params(...) {
    std::string a = ...;
    std::string b = ...;
    ...
    return a+b;
  }
  
  std::string c = make_params(...);

  
  я не знаю, какие представления используются в std::string (small string optimization, динамическое распределение памяти, copy-on-write, rope), происходит ли return value optimization при обращении к make_params. Я не представляю, в какие ассемблерные инструкции преобразует этот код VC++ для x86 (ассемблером которого я когда-то пользовался) и совершенно не имею понятия, во что это все преобразуется на SPARK-ах и MIPS-ах, ассемблера которых я вообще в глаза не видел, но на которых этот код работает;
  
• при работе с РСУБД средствами OTL я понятия не имею, в какие вызовы каких API и в какой именно момент OTL преобразует мои манипуляции с otl_stream;
  
• я не представляю, по каким алгоритмам MSSQL и Oracle строят планы исполнения моих SQL запросов и какую информацию, кроме имеющихся в схеме БД индексов, они при этом могут еще использовать;
  
• я не представляю, какие структуры данных MSSQL/Oracle используют для ведения, например, индексов;
  
• я не представляю, как MSSQL/Oracle организует работу с диском, добиваясь при этом и высокой скорости и достаточной степени надежности хранения информации;
  
• отправляя 5Kb данных в TCP/IP сокет я понятия не имею, куда они попадают, где дробятся на пакеты TCP/IP протоколов (и дробятся ли вообще), как и когда они уйдут в сеть.

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

Если вы со мной не согласны, значит вы знаете подобные детали. Поэтому сможете в точности рассказать, что именно делает MSSQL (или какая-нибудь другая РСУБД) при получении запроса с insert-ом вплоть до записи последнего байта на диск. Сможете?

Здравствуйте, eao197, Вы писали:
E>Не согласен. Понимание плана выполнения запросов -- это одно, а понимание механизма получения этого плана из SQL-выражения -- совсем другое,
И что, у кого-то есть иллюзия, что можно заниматься оптимизацией, понимая план, но не понимая, как он образовался из SQL выражения?
E>а понимание того, как план будет воплощен в жизнь с учетом кластеризации, распараллеливания, управления памятью и асинхронных I/O операций -- уже третье.
И что, у кого-то есть иллюзия, что план запроса не учитывает кластеризацию и распараллеливание?
E> Более того, план выполнения запроса является видимой частью абстракции РСУБД, фактически это часть ее интерфеса. Пользователь РСУБД вынужден в той или иной мере знакомиться с ней.
Фактически план запроса частью интерфейса РСУБД не является. Мы дальше будем обсуждать твои заблуждения в этой области?
E>Как и с такими понятиями, как уровни изоляции транзакций. Тем не менее, пользователь освобождается от знаний того, как же эти уровни изоляции реализуются.
Ни разу не видел такого, чтобы человек хорошо понимал, что такое уровень изоляции, при этом не понимая, как именно они реализуются.

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

E> Поскольку деталей здесь столько, что вряд ли под силу удерживать в голове одному человеку и при этом еще заниматься написанием кода с учетом этих деталей. Значит, это всего лишь приближение -- какие-то общие вещи должны быть на слуху. Попросту говоря, банальная эрудиция.
Эрудиция — это всего лишь знание "оглавления". Я совершенно не понимаю, как знание того, что существует уровень изоляции, поможет выбрать правильный уровень изоляции.
E>По моему мнению, важно не понимание сути (т.е. знания), а способность и желание при необходимости эти знания приобретать. Довелось человеку столкнуться с SQL -- освоить в необходимом объеме и использовать. Возникли после этого проблемы с производительностью SQL запросов -- разобраться с query plan. Показали замеры, что итерации по массиву идут слишком долго -- не полениться заглянуть в литературу и узнать об особенностях кэшей и размещения данных в памяти.
Ну это как бы две стороны одной медали. Понятно, что человек с удочкой универсальнее, чем человек с рыбой. Но если у человека принципиальное непонимание того, что для решения задачи нужно с чем-то разобраться, то он вряд ли приобретет знания при необходимости. Потому что он уже заучил твою мантру "утверждения о том, что более эффективен тот разработчик, который понимает суть платформ на которых он работает -- это ерунда" и доволен ей на 100%.

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

E>>Не согласен. Понимание плана выполнения запросов -- это одно, а понимание механизма получения этого плана из SQL-выражения -- совсем другое,
S>И что, у кого-то есть иллюзия, что можно заниматься оптимизацией, понимая план, но не понимая, как он образовался из SQL выражения?

Можешь рассказать алгоритм посторения плана, например, из MSSQL 2005?

E>>а понимание того, как план будет воплощен в жизнь с учетом кластеризации, распараллеливания, управления памятью и асинхронных I/O операций -- уже третье.
S>И что, у кого-то есть иллюзия, что план запроса не учитывает кластеризацию и распараллеливание?

Глаза протри. Я писал не про учет, а про знание деталей реализации плана. Ты можешь озвучить эти детали для какой-нибудь РСУБД?

E>> Более того, план выполнения запроса является видимой частью абстракции РСУБД, фактически это часть ее интерфеса. Пользователь РСУБД вынужден в той или иной мере знакомиться с ней.
S>Фактически план запроса частью интерфейса РСУБД не является.

Где я говорил про интерфейс РСУБД?

S> Мы дальше будем обсуждать твои заблуждения в этой области?

У тебя есть занятие получше?

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

Детали реализации этого для конкретной РСУБД можешь рассказать?

S>Ну это как бы две стороны одной медали. Понятно, что человек с удочкой универсальнее, чем человек с рыбой.

На русский можешь перевести?

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

E>>А что еще делать, если кто-то всерьез воспринимает словоблудие Джоеля Спольски?
S>А у вас какие-то полезные комментарии по поводу его рассуждений?

Ну, например:

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

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

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

Я с такой интерпритацией понятия абстрации не согласен, поэтому и весь закон "дырявых абстракций" в моем понимании так же является ошибочным. Если уж пользоваться аналогиями, то мне больше нравится рассматривать абстракции как строительные леса -- конструкции, которые позволяют подниматься все выше и выше, требуя при этом все большей и большей осторожности и осмотрительности. Поэтому не нужно громких выводов о том, что "любая нетривиальная абстракция дырява" -- просто напросто любая абстракция не является сплошной и надежной железобетонной плитой изначально. И откровения Спольски -- это как будто он подошел к строительным лесам и воскликнул: "Да они же дырявые!". Так ведь они изначально были задуманы таковыми.

S>Или всё, что скажет Спольски, априори неверно?

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

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

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

E>Как говорят на одном забавном форуме, то, что Спольски решил, что TCP его абстрагирует от ненадежной сети полностью, это личные половые трудности самого Спольски.
Ничего подобного. На том забавном форуме, наверное, все такие мега гуру в TCP. И никогда, к примеру, не пользуются открытием сокетов по имени хоста, потому что эта операция может занять слишком долго, и неизвестно, какой именно неймсервер она будет использовать.
E>Спольски выдает свой закон дырявой абстракции с той позиции, что абстракция должна быть железобетонной плитой, каменной стеной, за которой можно быть совершенно спокойным и не думать ни о чем.

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

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

Да, именно это Спольски и пытается донести. Потому что 90% народу ходит по любой абстракции как по железобетонной плите. Именно потому, что никто и не пытается рассматривать абстракции как леса.
E> И откровения Спольски -- это как будто он подошел к строительным лесам и воскликнул: "Да они же дырявые!". Так ведь они изначально были задуманы таковыми.
Нет, наоборот: "мы спрячем от вас ненужные подробности, и вы можете полагаться на более простую абстракцию". Вот, к примеру, RPC. Если бы он был задуман как леса, то несоменнно в нем были бы способы управлять таймаутами и кэшированием. Увы, RPC упорно пытается делать вид, что происходит локальный вызов. Где тут строительные леса?

S>>Или всё, что скажет Спольски, априори неверно?

E>Не могу судить обо всем, что Спольски пишет, только о том, что сам читал. Но даже тут на моей памяти Спольски перемывали косточки пару раз (один раз по поводу претензий к размеру .NET Framework дистрибутива, второй раз по поводу его "открытия" лямбда-функций) и, имхо, не зря.
И что? Все могут ошибаться. Тем не менее, он пишет и довольно много умных вещей.

E>У меня отношение к фельетонам Спольски уже давно достаточно однозначное -- после их прочтения не остается сухого остатка. Пока читаешь забавно, после прочтения не можешь понять, что же из всей прочитанной истории можно вынести.
О да. Из обсуждаемой статьи совершенно невозможно понять, что "все нетривиальные абстракции дырявы".

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

E>Отлично, оставим в стороне мои филофовские измышления по поводу "разделяй и властвуй". Вот описание суровой реальности:
Ок, я буду это учитывать в дальнейшем общении.
E>Ничего из вышеперечисленного не мешает мне писать программы.
На основании чего сделан такой вывод? Я правильно понимаю, что ты просто не пишешь программ, которые работают с Oracle или MS SQL, или программ на C++, которым предъявляются хоть какие-то требования по производительности?

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

E>Если вы со мной не согласны, значит вы знаете подобные детали. Поэтому сможете в точности рассказать, что именно делает MSSQL (или какая-нибудь другая РСУБД) при получении запроса с insert-ом вплоть до записи последнего байта на диск. Сможете?
До последнего байта — нет. Но те вещи, которые существенны для разработки приложения, конечно же знаем. В частности, в каких структурах хранятся индексы, что учитывает оптимизатор при построении плана запроса, как хранятся данные таблиц, как происходит захват и отпускание блокировок в зависимости от уровня изоляции. Ты не переживай — мы еще очень много всего лишнего знаем. Например, какие классы генерятся C# при обработке конструкции yield return, каким образом linq получает SQL из сишарпного кода. Знаем, какие заголовки возвращает асп.нет после того, как я подтвердил аутентификацию пользователя. Знаем, как именно кодируются данные в SOAP вызове, и какие накладные расходы это влечет. И это я только так, по поверхности поскреб.

Здравствуйте, eao197, Вы писали:
E>Можешь рассказать алгоритм посторения плана, например, из MSSQL 2005?
Это будет долго . Там довольно сложный алгоритм. Но я знаю, какие факторы он учитывает. И я знаю, из каких операций строится query plan, и какие когда можно, а когда нельзя применять.

S>>И что, у кого-то есть иллюзия, что план запроса не учитывает кластеризацию и распараллеливание?
E>Глаза протри. Я писал не про учет, а про знание деталей реализации плана. Ты можешь озвучить эти детали для какой-нибудь РСУБД?
Естественно. Операции распаралллеливания явно указываются в плане запроса. Там прямо так и будет написано: здесь распараллелили, здесь слили.

E>Где я говорил про интерфейс РСУБД?
Тремя строчками выше. Цитирую: "фактически это часть ее интерфеса".

E>Детали реализации этого для конкретной РСУБД можешь рассказать?
Могу. Но не буду — тебе быстрее будет открыть страничку "transaction isolation levels" в MS SQL Books Online и прочитать. Да, я всё это помню до сих пор, несмотря на то, что базы данных не проектирую лет пять. Просто не умею я не получать знания в процессе работы. И все знакомые мне успешные разработчики именно такие. Что находится в полном противоречии с твоими воззрениями.

S>>Ну это как бы две стороны одной медали. Понятно, что человек с удочкой универсальнее, чем человек с рыбой.
E>На русский можешь перевести?
Могу, но не буду.

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

S>Здравствуйте, eao197, Вы писали:
E>>Можешь рассказать алгоритм посторения плана, например, из MSSQL 2005?
S>Это будет долго .

Т.е. ответа не будет.

S>Там довольно сложный алгоритм.

Не сомневаюсь. Дьявол, как известно, в деталях. Нет деталей -- нет понимания, т.к. в общих словах даже строение вселенной и основные типы сил взаимодействия в ней рассказать можно.

S>Но я знаю, какие факторы он учитывает. И я знаю, из каких операций строится query plan, и какие когда можно, а когда нельзя применять.

В качестве ремарки -- это говорит человек, который БД занимается, по его же словам, 20 лет.

А я во с БД имею дело раз в полгода. И когда я воспользовался помощью инструмента Database Engine Tuning Advisor, он мне столько интересного насоветовал, чего я в принципе не знал (например, про модификаторы NONCLUSTERED для индексов, опции SORT_IN_TEMPDB и пр.). По твоей логике получается, что все это я должен был выучить еще до того, как взяться за проектирование схемы БД.

S>>>И что, у кого-то есть иллюзия, что план запроса не учитывает кластеризацию и распараллеливание?
E>>Глаза протри. Я писал не про учет, а про знание деталей реализации плана. Ты можешь озвучить эти детали для какой-нибудь РСУБД?
S>Естественно. Операции распаралллеливания явно указываются в плане запроса. Там прямо так и будет написано: здесь распараллелили, здесь слили.

Я спрашивал -- ты знаешь, с помощью каких операций выполняется распараллеливание? Запуск новых процессов или нитей, или фиберов. Через какие структуры данных происходит обмен результатами параллельной обработки?

E>>Где я говорил про интерфейс РСУБД?
S>Тремя строчками выше. Цитирую: "фактически это часть ее интерфеса".

Ты видишь то, что хочешь видеть, поэтому и разговариваешь сам с собой. Цитата:

Более того, план выполнения запроса является видимой частью абстракции РСУБД, фактически это часть ее интерфеса.

"ее интерфес" относится к "абстракции РСУБД".

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

E>>Детали реализации этого для конкретной РСУБД можешь рассказать?
S>Могу.

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

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

E>>Ничего из вышеперечисленного не мешает мне писать программы.
S>На основании чего сделан такой вывод?

На основании последствий эксплуатации написанных мной программ.

S>Я правильно понимаю, что ты просто не пишешь программ, которые работают с Oracle или MS SQL

Обычно нет. Необходимость в этом возникает раз в полгода, иногда реже.

S>или программ на C++, которым предъявляются хоть какие-то требования по производительности?

Да кто ж мне позволит это делать? На C++ сейчас писать что-нибудь производительное? Да это нонсенс. :/

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

Не переноси свой опыт на остальных.

E>>Если вы со мной не согласны, значит вы знаете подобные детали. Поэтому сможете в точности рассказать, что именно делает MSSQL (или какая-нибудь другая РСУБД) при получении запроса с insert-ом вплоть до записи последнего байта на диск. Сможете?
S>До последнего байта — нет.

Тогда в топку заявления о понимании.

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

E>>Как говорят на одном забавном форуме, то, что Спольски решил, что TCP его абстрагирует от ненадежной сети полностью, это личные половые трудности самого Спольски.
S>Ничего подобного. На том забавном форуме, наверное, все такие мега гуру в TCP.

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

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

А какой у нас выбор, если кроме имени хоста ничего нет?

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

S>Да, именно это Спольски и пытается донести. Потому что 90% народу ходит по любой абстракции как по железобетонной плите.

А вот это мне уже пофигу. 90% народу могут думать, что Бог сотворил Землю. Это не значит, что данное утверждение нужно считать законом.

S>Нет, наоборот: "мы спрячем от вас ненужные подробности, и вы можете полагаться на более простую абстракцию". Вот, к примеру, RPC. Если бы он был задуман как леса, то несоменнно в нем были бы способы управлять таймаутами и кэшированием.

А ты уверен, что все реализации RPC страдают этими недостатками?

S>Увы, RPC упорно пытается делать вид, что происходит локальный вызов. Где тут строительные леса?

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

S>>>Или всё, что скажет Спольски, априори неверно?

S>И что? Все могут ошибаться. Тем не менее, он пишет и довольно много умных вещей.

Ну вот мне не доводилось их находить в его фельетонах. Можешь примеры привести?

E>>У меня отношение к фельетонам Спольски уже давно достаточно однозначное -- после их прочтения не остается сухого остатка. Пока читаешь забавно, после прочтения не можешь понять, что же из всей прочитанной истории можно вынести.
S>О да. Из обсуждаемой статьи совершенно невозможно понять, что "все нетривиальные абстракции дырявы".

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

Собственно, об этом знали все, кто осознавал применимость афоризм "дьявол в деталях" к тому, что происходит при разработке ПО.

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

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

E>А какой у нас выбор, если кроме имени хоста ничего нет?
Как какой? Вручную выполнить DNS resolution, точно управляя таймаутом и алгоритмом перебора primary/secondary. Например, можно отправить запрос всем одновременно, не дожидаясь, пока primary стаймаутится. Да мало ли тонкостей — ты же сам говоришь, что абстракции это всего лишь леса. Ну вот к примеру абстракция сокетов еще абстрактнее, чем протокол TCP. Стало быть, ты в курсе, что именно скрывает эта абстракция, и готов в любой момент отойти от лесов или использовать их с осторожностью.

E>А вот это мне уже пофигу. 90% народу могут думать, что Бог сотворил Землю. Это не значит, что данное утверждение нужно считать законом.
Ты его пока что не смог опровергнуть. Да и вообще, сформулировать свои претензии к этому закону.

E>А ты уверен, что все реализации RPC страдают этими недостатками?
Конечно. Потому что вся идеология RPC эти недостатки считает достоинствами.

E>Как раз в том, что все идет коту под хвост при проблемах в сети. Разработчику предоставляется компромис между простотой написания основного кода и тяжестью последствий нештатных ситуаций.
Это какой-то неправильный компромисс. Правильный компромисс — это "я могу выбирать, что игнорировать, а что — нет". Вот, к примеру, в типичных HTTP клиентах ты можешь полагаться на стандартную реакцию на особенные ситуации, типа редиректов, а можешь обработать их самостоятельно. Ты, к примеру, можешь сделать такую штуку, как сказать "у меня уже есть данные от позавчера, если они изменились, то пришли мне новую версию, а если нет — то не присылай". Это одно из следствий того, что HTTP не старается изолировать разработчика от факта удаленности вызова. Ни одна реализация RPC не умеет делать такие вещи на уровне протокола.

E>Принимать этот компромис или нет -- это проблемы разработчика, но не RPC.
Ну так мы всё время говорим о разработчике, разве нет? Закон, предлагаемый Спольски, говорит только о том, что нельзя полагаться на железобетонность абстракций.

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

E>Для меня -- нет. Поскольку я знал о том, что абстракции не являются железобетонными плитами задолго до прочтения этой статьи.
Молодец, возьми с полки пирожок. Мы всё еще говорим о полезности Спольски для прочтения произвольным разработчиком? Или только о полезности лично для тебя? Если лично ты не узнаешь ничего нового из его постов, то почему ты берешь на себя наглость критиковать тех, кто узнает? Или хотя бы узнает новые формулировки инстинктивно известных вещей?

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

E>Не сомневаюсь. Дьявол, как известно, в деталях. Нет деталей -- нет понимания, т.к. в общих словах даже строение вселенной и основные типы сил взаимодействия в ней рассказать можно.
Совершенно верно — можно. Непонятно, почему ты столь категорично противопоставляешь — либо вообще ничего не знать, кроме приятной абстракции, либо уж знать всё досконально. Вот я тебе приводил пример про сокеты и TCP: для того, чтобы писать хорошо работающие программы, крайне полезно знать о том, какое место занимает DNS в том, что тебе кажется чистым TCP. Знать бинарное представление DNS пакета уже необязательно. Знать, каким именно образом TCP реализован поверх IP/ICMP — тоже полезно для понимания поведения программы в ситуациях, к примеру, обрыва связи. А вот детали реализации Ethernet и ее использования в IP — это уже экзотика, хотя для человека, который проектирует сетевые приложения, это тоже совсем не лишняя информация.

E>В качестве ремарки -- это говорит человек, который БД занимается, по его же словам, 20 лет.
Да. Не ежедневно, но 20 лет.

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

E>Я спрашивал -- ты знаешь, с помощью каких операций выполняется распараллеливание? Запуск новых процессов или нитей, или фиберов.
Фиберов.
E>Через какие структуры данных происходит обмен результатами параллельной обработки?
Нет, вот эти вещи я не знаю.

E>>>Где я говорил про интерфейс РСУБД?
S>>Тремя строчками выше. Цитирую: "фактически это часть ее интерфеса".


E>Интерфейс абстракции -- это дико звучит, наверное.
Совершенно верно.
E>Но нужно же было как-то обозвать тот понятийный базис, который нужно знать при работе с какой-то абстракцией (для РСУБД его составляют общие знания о реляционных отношениях и алгебре, SQL, схеме данных, индексах, понятии плана выполнения запроса).
Хорошо, давайте поймем, что именно входит в "понятийный базис" какой-нибудь абстракции. Вот, к примеру, почему ты планы к этому базису отнес, а, к примеру, устройство индексов — нет? Как по-твоему, детали хранения BLOB относятся к базису абстракции, или это несущественные детали? В какой момент эти детали станут существенными?

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

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

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

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

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

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

Но это вовсе не значит, что если бы я был более хорошим проектировщиком БД для MSSQL, то я бы был более хорошим разработчиком в своей предметной области.

S>Хорошо, давайте поймем, что именно входит в "понятийный базис" какой-нибудь абстракции. Вот, к примеру, почему ты планы к этому базису отнес, а, к примеру, устройство индексов — нет?

Потому что одних только вариаций B+ деревьев существует несколько штук. Не говоря уже о том, что разные БД могут размещать индексы в отдельных файлах, либо вместе с файлом БД, объединять несколько индексов в один файл или же разносить по разным файлам или даже дробить один индекс на серии файлов. А мне более важно, чтобы индекс ускорял выполнение запросов, а не то, как он устроен физически.

S>Как по-твоему, детали хранения BLOB относятся к базису абстракции, или это несущественные детали?

Для базиса это несущественные детали.

S>В какой момент эти детали станут существенными?

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