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

[Mikhail Gusarov <dottedmag@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 5795 bytes --]

Twas brillig at 16:21:36 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:

 ES> Я не знаю что такое bullshit... Но а вот обратиться к нужному
 ES> адресу в памяти я на Haskell вряд ли смогу так запросто...

Это дело ядра, вообще-то. Но заворачивание void* тривиально.

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

 ES> Сишный код не кидает исключений...

Зато кидает C++-ный. Попробуйте осознать, что это означает.

 >> RAII? Вы не понимаете, что C++-ный код враппера тупо будет размазан по

 ES> То что нужно от RAII в С всё равно пишут руками, так что эта часть
 ES> только упрощает использование С библиотек в С++...

C++-ный код кидает исключения. В C++ нет ключевого слова finally в блоке
try/catch. Подумайте, почему из этого автоматически следует
_необходимость_ иметь врапперы для всего нетривиального (управляющего
ресурсами любого рода) C-кода, используемого из C++.

 ES> Не в каждой, а только в тех, которые будут использовать сишные либы
 ES> напрямую, пропустив C++ варианты в целях некой оптимизации или
 ES> отсутствия необходимых C++ вариантов...

Сравните с "не в каждой, а только в тех, которые будут использовать
сишные либы напрямую, пропустив Haskell-варианты в целяз некой
оптимизации или отсутствия необходимых Haskell-вариантов".

 >> А вы подумайте, подумайте. Ключевые слова: разница в семантике
 >> управления памятью и обработке ошибок, RAII.

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

Это не аргумент. Врапперы "по ходу дела" в Haskell делаются ровно так
же. Какая разница, что они лежат в отдельном файле?

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

Это вам "прозрачно", потому что вы на C++ пишете. А разработчику на
Haskell "прозрачно" использовать встроенные средства языка, типа FFI,
или обёртки, типа c2hs.

 ES> В C++ не требуется для работы сначала сделать связку в виде
 ES> библиотеки, а потом начать работать...

Если есть желание получить неотлаживаемый memory- или resource-лик, то
да. Это замечательное свойство для языка системного программирования.

 ES> Разница в том, что в С++ GTK можно вызывать и без связки, а в Haskell - нет.

Нельзя. См. выше про RAII, исключения и отсутствие finally.

 ES> Если вы требуете признания того, что Haskell такой же "системный
 ES> язык", что и C++, то я скорее склонен согласиться, чем спорить :)

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

 ES> Но, к сожалению, вести речь о его применимости для многих задач я
 ES> уже не готов... А поскольку я не готов его применить, то
 ES> "системным" считать не могу :) Далее мы, скорее всего, снова
 ES> упрёмся в личные предпочтения...

Т.е. язык системного программирования оказался совершенно субъективным
делом, и ваше высказывание, что C++ - язык системного программирования,
подкреплено лишь вашим авторитетом, ибо существенной разницы между C++ и
Haskell, следуя вашей логике доказательства, мы не нашли, а Haskell вы
таковым не считаете.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]