Re: [devel] [JT] Re: Управление группами пользователя

["Evgeny Sinelnikov" <sin@altlinux.ru>]

20 ноября 2008 г. 16:36 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
> Twas brillig at 16:21:36 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:
>
>  ES> Я не знаю что такое bullshit... Но а вот обратиться к нужному
>  ES> адресу в памяти я на Haskell вряд ли смогу так запросто...
>
> Это дело ядра, вообще-то. Но заворачивание void* тривиально.
>

В Haskell это доступно на уровне языка? Или опять тривиальное
заворачивание через связку?

>  >> Кто будет оборачивать коды ошибки в исключения? Кто будет
>  >> реализовывать
>
>  ES> Сишный код не кидает исключений...
>
> Зато кидает C++-ный. Попробуйте осознать, что это означает.
>
>  >> RAII? Вы не понимаете, что C++-ный код враппера тупо будет размазан по
>
>  ES> То что нужно от RAII в С всё равно пишут руками, так что эта часть
>  ES> только упрощает использование С библиотек в С++...
>
> C++-ный код кидает исключения. В C++ нет ключевого слова finally в блоке
> try/catch. Подумайте, почему из этого автоматически следует
> _необходимость_ иметь врапперы для всего нетривиального (управляющего
> ресурсами любого рода) C-кода, используемого из C++.
>

finally обходится через RAII. Кроме того, side-эффекты сишных
библиотек, в ряде случаев, не способны отслеживать даже сами сишные
приложения. Так что не стоит столь педантично подходить к этому
вопросу... Заворачивать нужно равно то, что требуется... А если
уходить в глубокую рекурсию с перебором всех возможных вариантов, то
враппер получится невразумительный... Любые задачи в общем случае
решаются сложнее, чем в частных.

>  ES> Не в каждой, а только в тех, которые будут использовать сишные либы
>  ES> напрямую, пропустив C++ варианты в целях некой оптимизации или
>  ES> отсутствия необходимых C++ вариантов...
>
> Сравните с "не в каждой, а только в тех, которые будут использовать
> сишные либы напрямую, пропустив Haskell-варианты в целяз некой
> оптимизации или отсутствия необходимых Haskell-вариантов".
>
>  >> А вы подумайте, подумайте. Ключевые слова: разница в семантике
>  >> управления памятью и обработке ошибок, RAII.
>
>  ES> Ну, тут пожалуй соглашусь, только в том, что связки могут быть не
>  ES> простыми... Но ведь дело в том, что для частных случаев в С++
>  ES> связки делаются в самом коде, и при этом не требуется усилий чтобы
>  ES> получить доступ к вызовам С-шных библиотек...
>
> Это не аргумент. Врапперы "по ходу дела" в Haskell делаются ровно так
> же. Какая разница, что они лежат в отдельном файле?
>

При увеличении сущностей увеличивается сложность... Но может быть всё
не так и плохо...

>  ES> Для С++ есть QT, а так... да верно, если всё писать на С, то со
>  ES> связками те же проблемы... Но писать их проще, и пишутся они
>  ES> прозрачно, через встроенные средства языка...
>
> Это вам "прозрачно", потому что вы на C++ пишете. А разработчику на
> Haskell "прозрачно" использовать встроенные средства языка, типа FFI,
> или обёртки, типа c2hs.
>

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

>  ES> В C++ не требуется для работы сначала сделать связку в виде
>  ES> библиотеки, а потом начать работать...
>
> Если есть желание получить неотлаживаемый memory- или resource-лик, то
> да. Это замечательное свойство для языка системного программирования.
>
>  ES> Разница в том, что в С++ GTK можно вызывать и без связки, а в Haskell - нет.
>
> Нельзя. См. выше про RAII, исключения и отсутствие finally.

Можно-можно... Работать будет криво, но это вопрос второй... У C++
есть более удобные альтернативы, так что вопрос о связках во многих
случаях просто не стоит... Для Haskel же вопрос связок вещь
необходимая ибо библиотек не так много, что и сужает сферу его
применимости.

>
>  ES> Если вы требуете признания того, что Haskell такой же "системный
>  ES> язык", что и C++, то я скорее склонен согласиться, чем спорить :)
>
> Вот! Да, ровно этого я и добивался. А теперь вопрос, на который вы
> отвечаете ниже: а с вашей точки зрения Haskell и правда язык системного
> программирования?
>

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

>  ES> Но, к сожалению, вести речь о его применимости для многих задач я
>  ES> уже не готов... А поскольку я не готов его применить, то
>  ES> "системным" считать не могу :) Далее мы, скорее всего, снова
>  ES> упрёмся в личные предпочтения...
>
> Т.е. язык системного программирования оказался совершенно субъективным
> делом, и ваше высказывание, что C++ - язык системного программирования,
> подкреплено лишь вашим авторитетом, ибо существенной разницы между C++ и
> Haskell, следуя вашей логике доказательства, мы не нашли, а Haskell вы
> таковым не считаете.
>

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

Я вряд ли выберу Haskell для какой-нибудь системной задачи... И, я
думаю, вряд ли найдётся много добровольцев использовать его в
системных задачах. А вот C++ может использоваться (без RTTI и STDLIB)
даже во встроенных системах...

-- 
Sin (Sinelnikov Evgeny)