Разработка модулей ядра linux на Haskell

Хоп-хэй ла-ла-лэй!

/me пляшець и танцуець

Фото автора бложика какбэ намекает, что без веществ не обошлось :)

http://the-programmers-stone.com/2009/10/12/embedded-figures-test-distinct-si...

А здесь таблица со списком того, что он принимал.

http://the-programmers-stone.com/wp-content/uploads/2009/10/eft11oct2009-01.png

Фото автора патчей вообще за гранью добра и зла, потому он его не показывает.

Оу, ты вернулся!

что говорит Линус по поводу?

Ему боятся докладывать про сборщик мусора в ядре -- поленом зашибет раньше, чем выговорит "fuck™".

А на Бэйсике низзя? Визуальном? :-D

только managed. память-то надо убирать? ;)

Хочу выучить хаскель.

реквестую модули ядра на перле и встроенный в ядро интерпретатор!

Лениво как-то писать эти модули.

Рекламы как-то многовато, за Хаскелль
платют, видать, маловато

А смысл?
На Haskell можно что-то написать чего на Си нельзя?
На Haskell разработка быстрее чем на Си?
На Haskell отладка быстее чем на Си?
Haskell более переносимый?

Какие преимущества?

Тебе еще раз ссылку дать?

Много вражеских букф.

Да.

>На Haskell разработка быстрее чем на Си?

Да

>На Haskell отладка быстее чем на Си?

Да.

Дочитал до места, где предлагается насильственно и часто вызывать сборку мусора performGC.

Автор блога видимо не осилил концепцию сборщика мусора.

Дальше считаю смысла читать нет.

> Дочитал до места, где предлагается насильственно и часто вызывать сборку мусора performGC.

> Автор блога видимо не осилил концепцию сборщика мусора.

Он утверждает, что при таких регулярных вызовах видимое замедление будет субъективно меньше, чем при единичных длительных вызовах, которыми славится джава. И такая равномерность гораздо удобнее регулярных остановок. Читай внимательнее :)

>Да.

Я там еще пару вопросов задал :)

>Я там еще пару вопросов задал :)

На них скорее ответ нет (:

>> Дочитал до места, где предлагается насильственно и часто вызывать сборку мусора performGC.

>> Автор блога видимо не осилил концепцию сборщика мусора.

>Он утверждает, что при таких регулярных вызовах видимое замедление будет субъективно меньше, чем при единичных длительных вызовах, которыми славится джава. И такая равномерность гораздо удобнее регулярных остановок. Читай внимательнее :)

Читал внимательно. Насильственный и частый вызов сборки мусора приводит к тому, что компьютер будет заниматься только сборкой мусора.

Что касается Java, то там все хорошо. Сборщик мусора можно настроить так, что приложение не будет "замерзать".

И кстати есть отдельный специальный ключ, запрещающий явный вызов GC (-Xdisableexplicitgc), который позволяет нейтрализовать "особенно умных" разработчиков.

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

Вывод из общих соображений, или проводил эксперимент?