Здравствуйте, eao197, Вы писали:
E>Потому что все очень просто: либо человек знает все от и до, либо он опирается на какие-то абстракции, деталей реализации он может не знать. Полагая (до поры до времени), что эта абстракция его удовлетворяет.
Непонятно, на каком основании делается вот это бинарное утверждение. Речь не шла о том, чтобы потребовать знания зонной теории от любого разработчика софта, исполняющегося на полупроводниковой элементной базе. Речь шла о том, что ограничение знания только поверхностью платформы, под которую кодит человек — плохо.
К примеру, программировать на C#, не зная ничего о MSIL и GC — хуже, чем зная. Ровно потому, что абстракция С# неидеальна. И хотя бы основные вопросы этой неидеальности знать практически необходимо.
E>Но это вовсе не значит, что если бы я был более хорошим проектировщиком БД для MSSQL, то я бы был более хорошим разработчиком в своей предметной области.
А по-моему, как раз значит. Если ты взялся проектировать схему БД, то ты уже вышел за пределы чисто предметной области, и тебе знаний чистого DDL+DML будет недостаточно для того, чтобы хорошо сделать свою работу.
E>Потому что одних только вариаций B+ деревьев существует несколько штук. Не говоря уже о том, что разные БД могут размещать индексы в отдельных файлах, либо вместе с файлом БД, объединять несколько индексов в один файл или же разносить по разным файлам или даже дробить один индекс на серии файлов. А мне более важно, чтобы индекс ускорял выполнение запросов, а не то, как он устроен физически.
Очень интересно. То есть ты считаешь, что можно не знать про различия хеш индексы, B+tree, и Bitmap? Что разработчику БД можно игнорировать различия между скалярными индексами и full text индексами? Или может быть ты объявишь знания о различиях кластерных и некластерных индексов входящими в базис абстракции?
S>>Как по-твоему, детали хранения BLOB относятся к базису абстракции, или это несущественные детали? E>Для базиса это несущественные детали.
Ок, читаем следуюший ответ: E>Когда эти детали станут сказываться на производительности ПО или будут вызывать проблемы в разработке ПО.
Отлично. В соответствии с законом дырявых абстракций, который так тебе не нравится, в любой нетривиальной абстракции есть детали, сказывающиеся на производительности или вызывающие проблемы. В частности, детали хранения блобов сильно влияют на производительность ПО. Поэтому знания только самой абстракции недостаточно, нужно знать и то, что просвечивает через дырки в ней.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>На C++ сейчас писать что-нибудь производительное?
Позвольте полюбопытствовать: на чем же пишут сейчас производительное?
Здравствуйте, CreatorCray, Вы писали:
E>>На C++ сейчас писать что-нибудь производительное? CC>Позвольте полюбопытствовать: на чем же пишут сейчас производительное?
Ну это нужно спрашивать у тех, что C++ охаивает (на профессиональной основе)
По слухам, серьезную конкуренцию C++ должны составлять Java, C#, OCaml, Haskell, Pascal, Ada, Eiffel, Modula-2, Oberon, Clean, Lisaac. Fortran еще в области HPC.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
E>>Потому что все очень просто: либо человек знает все от и до, либо он опирается на какие-то абстракции, деталей реализации он может не знать. Полагая (до поры до времени), что эта абстракция его удовлетворяет. S>Непонятно, на каком основании делается вот это бинарное утверждение. Речь не шла о том, чтобы потребовать знания зонной теории от любого разработчика софта, исполняющегося на полупроводниковой элементной базе. Речь шла о том, что ограничение знания только поверхностью платформы, под которую кодит человек — плохо.
Речь шла о том, что человек, знающий детали работы нижележащих слоев (т.к. БД, ОС и пр.) будет эффективнее, чем тот, кто этого не знает. Это ерунда на том основании, что "знание деталей" ("понимание сути") это эрудиция + некоторая дельта(реального знания деталей). Причем чем дальше, тем больше становится эта дельта.
А мое бинарное утверждение как раз должно было показать, что нельзя меня упрекать в лукавстве, когда я говорю о том, что успешно опираюсь в своей работе на абстракции, детали реализации которых я не знаю. Поскольку это обычное дело и принцип "разделяй и властвуй" еще никто не отменял.
S>К примеру, программировать на C#, не зная ничего о MSIL и GC — хуже, чем зная. Ровно потому, что абстракция С# неидеальна.
Про GC не буду спорить, а вот по поводу MSIL твое утверждение не выглядит правдоподобным. Поскольку оно похоже на утверждения, что лучше уж не писать на C++ для Spark Solaris не зная ассемблера Spark, а на Java -- не зная байт-кодов JVM.
Или же речь идет о том, чтобы писать сборки, которые можно будет использовать из нескольких языков и не во всех языках есть непосредственные средства поддержки чего-либо (операторов индексации, к примеру)?
E>>Но это вовсе не значит, что если бы я был более хорошим проектировщиком БД для MSSQL, то я бы был более хорошим разработчиком в своей предметной области. S>А по-моему, как раз значит. Если ты взялся проектировать схему БД, то ты уже вышел за пределы чисто предметной области, и тебе знаний чистого DDL+DML будет недостаточно для того, чтобы хорошо сделать свою работу.
При инкрементной разработке будет достаточно для того, чтобы получать "good enough" решение на каждой итерации, постепенно пополняя собственный запас знаний. И дойдя в конце-концов до точки, в которой дешевле будет привлечь специалиста по БД, чем заниматься этой работой дальше самостоятельно.
E>>Потому что одних только вариаций B+ деревьев существует несколько штук. Не говоря уже о том, что разные БД могут размещать индексы в отдельных файлах, либо вместе с файлом БД, объединять несколько индексов в один файл или же разносить по разным файлам или даже дробить один индекс на серии файлов. А мне более важно, чтобы индекс ускорял выполнение запросов, а не то, как он устроен физически. S>Очень интересно. То есть ты считаешь, что можно не знать про различия хеш индексы, B+tree, и Bitmap?
На начальном этапе можно.
S>Что разработчику БД можно игнорировать различия между скалярными индексами и full text индексами?
"Разработчик БД" звучит как человек, занимающийся исключительно БД. Такому нельзя игнорировать различия. А если мне нужна табличка с несколькими целочисленными полями, и я делаю индекс по одному из этих полей, то нужно ли мне рассматривать различия между скалярными или full text индексами?
S>Или может быть ты объявишь знания о различиях кластерных и некластерных индексов входящими в базис абстракции?
В базис абстракции РСУБД эти знания, на мой взгляд, не входят.
S>Отлично. В соответствии с законом дырявых абстракций, который так тебе не нравится, в любой нетривиальной абстракции есть детали, сказывающиеся на производительности или вызывающие проблемы. В частности, детали хранения блобов сильно влияют на производительность ПО. Поэтому знания только самой абстракции недостаточно, нужно знать и то, что просвечивает через дырки в ней.
Это не нужно знать априори. Нужно иметь возможность и желание приобретать эти знания. Знать нужно лишь то, что эти знания в любой более-менее серьезной задаче придется приобретать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
S>>И что? Все могут ошибаться. Тем не менее, он пишет и довольно много умных вещей.
E>Ну вот мне не доводилось их находить в его фельетонах. Можешь примеры привести?
Я согласен с тем что его очень часто заносит, но даже за эту пару
E>Речь шла о том, что человек, знающий детали работы нижележащих слоев (т.к. БД, ОС и пр.) будет эффективнее, чем тот, кто этого не знает. Это ерунда на том основании, что "знание деталей" ("понимание сути") это эрудиция + некоторая дельта(реального знания деталей). Причем чем дальше, тем больше становится эта дельта.
E>А мое бинарное утверждение как раз должно было показать, что нельзя меня упрекать в лукавстве, когда я говорю о том, что успешно опираюсь в своей работе на абстракции, детали реализации которых я не знаю. Поскольку это обычное дело и принцип "разделяй и властвуй" еще никто не отменял.
Есть ситуации когда просто необходимо знать детали, в одно время например, я хоть и писал на C++, но приходилось приличную часть рабочего времени читать ассемблерный выхлоп компиляторов, да еще для двух разных платформ, да из профайлера не вылазить, а потом еще и подробно разбиратся с менеджером памяти под одну из них и писать свой. Притом ничего ничего кроме вполне гражданского кода на C++ я при этом не писал.
Здравствуйте, Sinclair, Вы писали:
E>>Нет, там просто в выражениях не стесняются, поэтому частно разывают вещи своими именами, даже если это и нецензурно. S>А, то есть в протоколе не шарят, зато знают много матов. Хороший, должно быть, форум.
Нормальный, linux.org.ru. По количеству полезной информации не сильно хуже этого, только стиль общения там совсем другой. Поэтому и выражение "половые сложности" там обычное явление.
E>>А какой у нас выбор, если кроме имени хоста ничего нет? S>Как какой? Вручную выполнить DNS resolution, точно управляя таймаутом и алгоритмом перебора primary/secondary. Например, можно отправить запрос всем одновременно, не дожидаясь, пока primary стаймаутится.
И в определенных условиях получить неудачное завершение всех операций из-за истечения слишком коротких для данных условий тайм-аутов.
E>>А вот это мне уже пофигу. 90% народу могут думать, что Бог сотворил Землю. Это не значит, что данное утверждение нужно считать законом. S>Ты его пока что не смог опровергнуть. Да и вообще, сформулировать свои претензии к этому закону.
А что опровергать, если Спольски ничего не доказывал?
Основные претензии к его статье такие:
— он делает громкий вывод на основании своих личных ложных предположений. И приводит такие же примеры, вроде того, что TCP не абсолютно надежный протокол;
— он наделяет "дыры в абстракциях" отрицательным смыслом (или же сами абстракции у него приобретают отрицательный смысл на основании наличия этих дыр). Хотя ничего отрицательного в них нет -- это данность. Такая же, как холодные зимы в высоких широтах серверного полушария. Про них так же можно написать какой-нибудь закон, а можно просто спокойно воспринимать как данность.
E>>Как раз в том, что все идет коту под хвост при проблемах в сети. Разработчику предоставляется компромис между простотой написания основного кода и тяжестью последствий нештатных ситуаций. S>Это какой-то неправильный компромисс. Правильный компромисс — это "я могу выбирать, что игнорировать, а что — нет". Вот, к примеру, в типичных HTTP клиентах ты можешь полагаться на стандартную реакцию на особенные ситуации, типа редиректов, а можешь обработать их самостоятельно. Ты, к примеру, можешь сделать такую штуку, как сказать "у меня уже есть данные от позавчера, если они изменились, то пришли мне новую версию, а если нет — то не присылай". Это одно из следствий того, что HTTP не старается изолировать разработчика от факта удаленности вызова. Ни одна реализация RPC не умеет делать такие вещи на уровне протокола.
А что мешает делать это для XML-RPC или SOAP?
E>>Принимать этот компромис или нет -- это проблемы разработчика, но не RPC. S>Ну так мы всё время говорим о разработчике, разве нет?
Я думал, что Спольски говорит об абстракциях, которые не железобетонные. А не о разработчиках.
E>>Ну вот мне не доводилось их находить в его фельетонах. Можешь примеры привести? S>Ну, вот к примеру — закон дырявых абстракций.
Ерунда.
S>Или принципы ценообразования в софте.
На вскидку не помню.
S>Или способы проведения интервью.
Более-менее, как один из возможных подходов.
S>Или то, как выбирать фичи для следующего релиза коробочного продукта.
Не припоминаю.
Ну как-то не очень солидный выхлоп, имхо.
S>Мы всё еще говорим о полезности Спольски для прочтения произвольным разработчиком? Или только о полезности лично для тебя?
Поскольку меня обвиняли в незнании закона, то речь обо мне.
S>Если лично ты не узнаешь ничего нового из его постов, то почему ты берешь на себя наглость критиковать тех, кто узнает?
Я от природы такой.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
FR>Есть ситуации когда просто необходимо знать детали, в одно время например, я хоть и писал на C++, но приходилось приличную часть рабочего времени читать ассемблерный выхлоп компиляторов, да еще для двух разных платформ, да из профайлера не вылазить, а потом еще и подробно разбиратся с менеджером памяти под одну из них и писать свой. Притом ничего ничего кроме вполне гражданского кода на C++ я при этом не писал.
Таких ситуаций множество. Но это не повод утвержать, что изначальное знание деталей конкретной платформы (ОС, БД, VM,...) делает одного разработчика эффективнее другого. Хотя бы потому, что:
— эти знания могут не потребоваться при проектировании;
— эти знания могут не потребоваться при реализации (упрется производительность в БД -- и все, нафиг идут знания о стоимости atomic-инструкций в тактах процессора);
— другой разработчик может применить иные алгоритмы реализации, более эффективные, например, с точки зрения большого O;
— другой разработчик может приобрести эти знания быстрее, чем первый получит возможность применить свои знания на практике;
— этот разработчик может не найти общий язык с заказчиком из-за чего в проекте будет реализоваваться не то, за что заказчик захочет платить деньги;
— этот разработчик может не найти общего языка с другими членами команды и общая скорость разработки снизится из-за усилий, прилагаемых для разруливания этих разногласий;
— этот разработчик может углубиться в "вылизывание" какой-нибудь фичи, из-за чего не будет сделана какая-то другая часть функциональности;
— этот разработчик может очень плохо структурировать и документировать свой код, из-за чего другие члены команды будут тратить больше времени на работу с ним, что снизит общую производительность команды;
— и т.д., и т.п.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
S>>Непонятно, на каком основании делается вот это бинарное утверждение. Речь не шла о том, чтобы потребовать знания зонной теории от любого разработчика софта, исполняющегося на полупроводниковой элементной базе. Речь шла о том, что ограничение знания только поверхностью платформы, под которую кодит человек — плохо. E>Речь шла о том, что человек, знающий детали работы нижележащих слоев (т.к. БД, ОС и пр.) будет эффективнее, чем тот, кто этого не знает. Это ерунда на том основании, что "знание деталей" ("понимание сути") это эрудиция + некоторая дельта(реального знания деталей). Причем чем дальше, тем больше становится эта дельта.
Нет, речь шла именно о том, что написал Sinclair.
Выше было, откровенно говоря, лень писать вам такой же многословный ответ, как и ваш вопрос, сейчас вам его уже дали.
E>А мое бинарное утверждение как раз должно было показать, что нельзя меня упрекать в лукавстве, когда я говорю о том, что успешно опираюсь в своей работе на абстракции, детали реализации которых я не знаю. Поскольку это обычное дело и принцип "разделяй и властвуй" еще никто не отменял.
Ваше лукавство проявляется именно в двоичной логике black or white, на деле все в мире сплошь серые полутона. Абстракции не так уж безупречны, как вы тут втираете (но никто не говорит, что они совсем безполезны — прошу, не надо притворяться таким уж примитивным, а также приписывать такую же примитивность собеседникам), а потому готовность и опыт латания дыр абстракций есть необходимый навык успешной работы именно с абстракциями (с чего вы про ассемблер, честно, не понял).
Здравствуйте, rsn81, Вы писали:
S>>>Речь шла о том, что ограничение знания только поверхностью платформы, под которую кодит человек — плохо. R>Нет, речь шла именно о том, что написал Sinclair.
Ok. Тогда можете ли вы привести критерии оценки поверхности и неповерхности платформы?
R>Ваше лукавство проявляется именно в двоичной логике black or white
Моя бинарная логика появилась после вашего обвинения в лукавстве. Как доказательство несостоятельности обвинения.
R>Абстракции не так уж безупречны, как вы тут втираете
Где я это утверждал?
R>(с чего вы про ассемблер, честно, не понял).
Бывает.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ok. Тогда можете ли вы привести критерии оценки поверхности и неповерхности платформы?
Зачем? Признаться, у меня нет общего правила, только частные наблюдения.
E>Моя бинарная логика появилась после вашего обвинения в лукавстве. Как доказательство несостоятельности обвинения.
Нет, до, см. ниже.
R>>Абстракции не так уж безупречны, как вы тут втираете E>Где я это утверждал? Re[9]: О программировании
Здравствуйте, eao197, Вы писали:
E>Про GC не буду спорить, а вот по поводу MSIL твое утверждение не выглядит правдоподобным. Поскольку оно похоже на утверждения, что лучше уж не писать на C++ для Spark Solaris не зная ассемблера Spark
Неверно. Кодогенерация прямо в IL используется в дотнете очень часто. И появление во второй версии LCG тому хорошее подтверждение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Sinclair, Вы писали:
S>Умные указатели — замечательная штука, если не считать того, что они не запрещают использование глупых указателей.
