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

Чт Ноя 20 16:21:36 MSK 2008

20 ноября 2008 г. 12:31 пользователь Mikhail Gusarov
<dottedmag at altlinux.org> написал:
> Twas brillig at 11:53:05 20.11.2008 UTC+03 when sin at altlinux.ru did gyre and gimble:
>
>  ES> Но я полагаю, что Haskell запускает для своих приложений внутренюю
>  ES> среду, позволяющую реализовать его функциональность на компьютерах,
>  ES> аппаратно её не поддерживающих.  С++ же настолько же близок к
>  ES> железу, что и C... В этом они с Haskel не сравнимы..
>
> Как это отражается на функционировании? Всё остальное - среда, не среда
> - полнейший bullshit.

Я не знаю что такое bullshit... Но а вот обратиться к нужному адресу в
памяти я на Haskell вряд ли смогу так запросто... Я уже сказал, что
"не знаком с Haskell настолько, чтобы дать вам развёрнутый ответ"... А
соответственно допускаю, что в нём можно многое, но в нём, в отличии
от С++, вряд ли можно всё что, что можно в C...

>
>  >> Не совместим. extern "C", #define class class_, и т.д.
>
>  ES> Да, есть такой набор ограничений, за их исключением совместимость
>  ES> практически полная... Я бы сказал, что на практике эти ограничения
>  ES> встречаются тогда когда, ими пренебрегают. Думаю, что в ряде
>  ES> случаев, даже намеренно...
>
> Кто будет оборачивать коды ошибки в исключения? Кто будет реализовывать

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

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

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

> всей программе тонким слоем? Причём в каждой программе - свой код.
>

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

>  >> Связки для Haskell занимаются ровно тем, что в C++ делается либо
>  >> неявно и несепарабельно (превед!), либо отдельной связкой,
>  >> называемой обёрткой: преодолением разницы в подоходах языков к
>  >> управлению памятью и ресурсами и обработке ошибок.
>
>  ES> Я не совсем понял, о чём здесь идёт речь,
>
> А вы подумайте, подумайте. Ключевые слова: разница в семантике
> управления памятью и обработке ошибок, RAII.
>

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

>  ES> но вот это, например, явная связка:
>  ES> http://www.cse.unsw.edu/~chak/haskell/gtk/
>  ES> http://haskell.org/gtk2hs/
>
> gtkmm.
>

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

>  ES> Кстати, GTK как раз и содержит в заголовочных файлах ряд
>  ES> вышеозначенных несовместимостей, которые, как я полагаю, сделаны по
>  ES> причине явных предпочтений авторов в пользу С, по сравнению с C++.
>
> О да. А также он содержит ряд вышенеозначенных несовместимостей,
> мешающих без ручного кода сделать Haskell-биндинг. Как я полагаю,
> сделаны они по причине явных предпочтений авторов в пользу C по
> сравнению с Haskell. Могли бы потрудиться и написать попроще, чтобы
> биндинги генерить можно было. Впрочем, для C++ всё равно биндинг нужен.
>

согласен, GTK - ужасен... :)

>  ES> По моему вы недооцениваете порядок сложности того, что
>  ES> предлагаете...  Иначе почему концепция, которую взяла за основу в
>  ES> c2hs близка к мёртвому проекту "A GTK+ Binding for Haskell",
>  ES> который был сменён gtk2hs?
>
> Потому, что GTK+ Binding for Haskell забросили авторы? Это не имеет ни
> малейшего отношения к делу.
>

Я только спросил... раз не имеет - значит так уж сложилось... но
причины-то были...

>  ES> А ведь в gtk2hs я вижу кучу ручного кода....
>
> В gtkmm я тоже вижу кучу ручного кода.
>
> gtk2hs - 1.1M
> gtkmm-1.2.10 - 704k
>
> Где разница?
>

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

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

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

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

> Пока что вы
>
> a) сказали, что "Haskell, очевидно, не язык системного
> программирования". Я утверждаю с той же степенью авторитетности, что
> "C++, очевидно, не язык системного программирования"
>

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

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

Хм.. набор, определяющий "системность языка"? Я его и не пытался
предоставить...

>  >> Покажите несуразное сравнение. Я пока вижу только суразные.
>
>  ES> "Тогда Haskell - это тоже язык системного программирования"
>
> Тогда опровергните! Не "мне кажется" или "я считаю", а фактами. Раз уж
> вы выдвинули свою теорию о классификации языков - она должна выдержать
> первое же испытание.
>

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

Вы что-то путаете по поводу "моей теории" классификации языков - я её
не выдвигал. Я высказал мнение о том, что сравнимать С++ и Haskell,
против C и C++, несуразно...

-- 
Sin (Sinelnikov Evgeny)