Lua в ядре NetBSD

Я не согласен с определением абстрактного коллективного Торвальдса (АКТ) мудаком

Безусловно, АКТ полезен на своем месте. Я просто хочу, чтобы он был полезен в более широком контексте :)

Кстати, если ты тот анонимус: по сравнению с Си, в Си++ отличная модульность.

кстати, знаешь где это начало всплывать на полную катушку(проблемы си при передачей по указателям) - когда начали первые rpc реализовывать. требовалось как-то пояснять мы хотим передать данные или их изменить. ну ты в курсе этого всего, idl и прочее.

а воз и ныне там.

Си, в Си++ отличная модульность.

лорчую. но не отличная. но намного лучше. и исключения это намного лучше чем goto в ядре

выбрал си не потому что ничего кроме него они знать не хотят

Именно что не хотят. Обычное дело - «некогда ваши лямбды учить, надо драйвера клепать». Отправь их принудительно на курсы CS - они с си тут же сбегут в ужасе.

си лучше всего подошёл в нишу написания ядер ОС

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

Нет, он не я.

Если вы про namespaces, то, наверное, соглашусь, но не до конца.

почитал тут про языки что ты накидал. профиты есть, но всё равно не торт

в Си++ отличная модульность

Что ж тут отличного, когда pImpl + namespaces руками делать надо.

Отправь их принудительно на курсы CS - они с си тут же сбегут в ужасе.

но куда?

В 70-е возможно, хотя и то сомнительно.

в 70-е ядра писали на ассемблерах, си был вином потому что он переносим. вот и всё

Ок, засчитано :-) Не, я другой, сорри.

отличная же цитата на баше (сейчас) на этот счет:

...Не нужно писать тесты, если:
- Вы всегда пишете код без ошибок, обладаете идеальной памятью и даром предвидения. Ваш код настолько крут, что изменяет себя сам, вслед за требованиями клиента. Иногда код объясняет клиенту, что его требования — не нужно реализовывать.

кто это понимает, покрывает участки, которые могут сломаться

Не вслучае с юнит тестами: нужно писать тесты и код параллельно. Возможно, в случае с интеграционными тестами - да.

по сравнению с Си, в Си++ такая же модульность

Пофиксил, не благодари.

идея написания драйверов на чем-то высокоуровневом прикольная.

прикольная идея в юзерспейс побольше вынести. инфа 100%

Ну этим из более-менее мейнстримного может похвастаться лишь эрланг. Зато Go (в отличие от питонов и жабаскриптов) нормально умеет в многопоточность и многопроцессорность.

Это ложь. Потоки go не могут выполняться на разных ядрах. Читай официальную документацию. Так что оно однозначно хуже Питона: там можно хотя бы отдельный процесс запустить и всё будет работать, а в go нельзя.

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

почитал тут про языки что ты накидал

Ты быстро читаешь :)

всё равно не торт

Самый тортовый язык, BitC, даже допроектировать не успели. На сайте описана предыдущая версия, новая обсуждалась в списке рассылки, но всё как-то резко прекратилось.

я бы решил проблему с организацией тестирования в первую очередь.

мне тоже больше всего он понравился. но..«даже допроектировать не успели»

но проект очень интересный

это не всегда возможно

идея написания драйверов на чем-то высокоуровневом прикольная.

прикольная идея в юзерспейс побольше вынести. инфа 100%

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

Все возможно в определенной степени.

http://golang.org/doc/effective_go.html#parallel

Если ты почитаешь внимательно, там написано, что but until it is if you want CPU parallelism you must tell the run-time how many goroutines you want executing code simultaneously.

у меня такое ощущение что ты недавно прочитал про tdd и теперь будешь её рекламировать везде. в 60% проектов оно или не работает или не нужно(простые программы которые взаимодействуют друг с другом:)

В питоне любой файл - уже модуль, к функциям которого можно обратиться самым естественным образом. Никаких лишних телодвижений для того, чтобы сделать сырец модулем, не нужно. Равно как и каталог с сырцами - пакетом (не считая добавления __init__.py, пусть даже и пустого).

но куда?

Полагаю, им придётся изобрести свой язык или реанимировать что-то из вышеупомянутых. Как полумера - взять C++.

Да, си задавил всех конкурентов. Но это не признак его качества.

си был вином потому что он переносим. вот и всё

А что, есть ещё непереносимые (в понимании си) языки кроме ассемблера?

Вин 70-х обернулся фейлом 2000-х, вот в чём беда.

забавно что случилось с mach когда его взяли apple. внезапно оно разжирело до обычного гибридного. да они вообще нигде не взлетели, дорогое переключение контекста, дорогое ipc+куча глюков.

я скорее про проекты типа fuse

у меня такое ощущение что ты недавно прочитал про tdd

нет..

Одно время я считал точь-в-точь как ты)

любой файл - уже модуль

любой файл-объект, любой каталог-объект, даже функции, даже аллах

вот в этом профит.

особенно для динамических языков, на которых мы пишем, tdd-это в общем случае хорошо. но просто не всегда

Микроядра так и не успеют взлететь.

QNX.

QNX.

И где оно взлетело? На полутора АЭС?

In [1]: def foo(a):
   ...:     return a*a
   ...: 
In [2]: import dis

In [3]: dis.dis(foo.func_code)
  2           0 LOAD_FAST                0 (a)
              3 LOAD_FAST                0 (a)
              6 BINARY_MULTIPLY     
              7 RETURN_VALUE        

профит

последний раз видел его на той-самой-дискетке. надеюсь в blackberry оно взлетит

Ы? В миллионах автомобилей, например.

на аэс windows nt, инфа 146%

в автомобилях wince. (кстати тоже риалтаймово же-профит)

В миллионах автомобилей при желании можно и андроид найти. Но это не делает андроид автомобильной осью.

Ну а что там должно быть, по-твоему? Две загрузки, умножение и возврат.

я про то что всё круто. во-первых, через repl можно что угодно изучить, модульности вплоть до того что у функции можно получить её код

надеюсь в blackberry оно взлетит

Оно жило и развивалось всё это время. В блэкберри оно уже взлетело. Отлично работает, надо сказать.

В миллионах автомобилей, например.

Миллионы неотличимых систем - это не взлет.

хорошо. осталось переписать это все опенсорсно.

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

Ну так это да, можно и суровый байткод получить:

>>> foo.func_code.co_code
'|\x00\x00|\x00\x00\x14S'

В миллионах автомобилей при желании можно и андроид найти.

Не знаю, где ты там андроид найдёшь. Но то, что QNX является системой реального времени и широко используется во встраиваемых системах это факт.

Количество десктопов суммарное с виндовсом, думаю, меньше. :)

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

Ну, для меня единственный понятный байткод - у МК-61/МК-52 (и немного x86), остальное сурово как-то.

хорошо. осталось переписать это все опенсорсно.

Ты не поверишь: http://www.qnx.com/legal/licensing/open_source.html ;)

я больше люблю читать как он сравнивает руби(который не знает) и питон(который не знает) на примитивном уровне. а про методологии разработки это что-то новое. болезнь прогрессирует. но я его не зафрендю ни за что-обожаю его читать

Миллионы неотличимых систем - это не взлет.

Ты же не думаешь, что в автомобиле и в самолёте оно совсем одинаковое?