Ядро на ООП

а сайтик остался

Спасибо, чтение главной доставляет не хуже стоплинукса...

Ну так вопрос был «что дают классы», а не «что дают только классы».

Вопрос-то да, но сообщение, к которому он задавался, звучало несколько по-другому:

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

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

Мне просто лень снова начинать срач. Да и не срач это вовсе. Вкратце, Ъ-ООП возможно и без наследования, хотя штука временами удобная.

Вкратце, Ъ-ООП возможно и без наследования

Не-а. Просто наследование заменяется механизмом времени выполнения.

Хотя, если Ъ-ООП - это то, что сказал Великий Алан Кей, тогда ХЗ.

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

WUT? Не над «всем», а над «тем, как сделано сейчас».

WUT? Не над «всем», а над «тем, как сделано сейчас».

Можно перечисление всего, что сделано сейчас и что из этого и каким образом превосходит наследование?

Может тогда сразу перейти к микроядерности, сообщение между модулями сделать в виде сообщений (по классике), а ООП уже черт с ним?)

Звучит правдоподобно. Но хотелось бы конкретных примеров. Ты про таблицы виртуальных методов?

И про них, конечно же. Явное управление «vtable» (в кавычках, так как говорим о С, все таки) делает понимание переопределения функций, иерархии и взаимодействия куда проще. Всё буквально написано текстом, а не выводиться из каких-то определений классов, неявного (и явного) кастинга, в котором черт ногу сломит, когда классов/интерфейсов хотя бы дюжина. В Си же это всегда остается на поверхности и доступно для чтения, как книга.

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

В нашем неидеальном мире и неидеальными мозгами, лозунг «давайте опишем объект, а как он будет работать это уже мелкие детали» просто не работает. Когда ты смотришь в середину кода, и ты абсолютно не представляешь, что делает какой-нибудь (foo)bar.baz()... это грустно. Всё скрыто за определениями классов, нужно буквально держать всю иерархию классов в голове, а это невозможно. И тут приходит на помощь чистый Си, когда всё делается в открытую, без скрытия деталей и иерархии.

symbian

сорцы утекли целиком и полностью

тред не читал

Можно перечисление всего, что сделано сейчас

Конечно. Прямо с хедпоста.

> Limbo это предшественник Go, Rob Pike
Это ведь не функциональны(е|й) язык(и)?

В функциональном стиле можно хоть машину Тьюринга программировать, кто мешает? Ограничивайте сайд-эффекты функций.

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

Функционального в хаскеле не больше чем в basic'e, а все остальные фишки там к функциональщине имеют посредственное отношение (система типов, паттерн-матчинг и т.п.). Просто какие-то языки пытаются (!) сделать программирование в функциональном стиле удобным.

Да, хаскел считается pure functional, с намеком на то, что всё укладывается в одну парадигму — «у нас нету глобального состояния». Ну так никто не мешает связать себе руки в любом другом языке.

Но да, Go не заточен под функциональный стиль. И я ни в коем случае не агитирую за него. Хотя если выбирать между С++ и Go, я выберу Go. Но благо есть еще лучший выбор — чистый Си. :-)

Конечно. Прямо с хедпоста.

Можно урлом?

Да, хаскел считается pure functional, с намеком на то, что всё укладывается в одну парадигму — «у нас нету глобального состояния».

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

Может тогда сразу перейти к микроядерности, сообщение между модулями сделать в виде сообщений (по классике), а ООП уже черт с ним?)

Я просто оставлю начало этой ветки здесь.

У CL слишком большой оверхед.

Прямо с хедпоста.

Можно урлом?

Конечно: Ядро на ООП

Заметь использование слов Linux и C++.

Сигналы можно делать и без ООП? Ну, хотя бы без культуры ООП. Будут у нас какие-нибудь функциональные актеры или, лучше, аспекты (чтобы можно было избавиться от идентичности). Исключительно в целях троллинга фанатов Крестов, конечно :)

Но благо есть еще лучший выбор — чистый Си. :-)

В том-то и дело, что лучше Си ничего не придумали. Но на Си тяжело мыслить прикладными сущностями - только код, железо и память.

Просто какие-то языки пытаются (!) сделать программирование в функциональном стиле удобным.

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

Мне думается будущее за языками, сочетающими в себе как функциональность так и ООП. Это будет стоящая вещь. Нужен язык для ОС. В начале зарождения ОС был придуман Си. Сейчас утекло много воды с тех времен, назревает необходимость в новых языках и парадигмах, таких как смесь ФП+ООП==ФООП. Во всех успешных движках так или иначе реализованы механизмы сигналов и параллелизма.

«у нас нету глобального состояния»

Глобальное состояние это зло. Нужно использовать persistent-сущности на системном уровне так-же легковесно, как процессы эрланга. Ну и паттерн-матчинг с кортежами и атомами: куда сейчас без них? Именно такие архитектуры, позволяют создавать системы, умеющие подгружать код на лету, что немаловажно для современных ОС (линукс умеет так работать на уровне модулей). В моей коллекции «горячие загрузчики» следующие: erlang, lisp, forth. Если кто-то знает еще языки с горячей догрузкой кода как в эрланге - буду признателен.

Ну так никто не мешает связать себе руки в любом другом языке.

Это да, но большие проекты не делаются в одиночку. Люди разные. По настоящему буйных гиков мало.

Acme != Plan 9

Acme — часть Plan 9.

---
hobbit, swwwfactory

форт и все-все-все

Никто не забыт и ничто не забыто.
http://concatenative.org/
Среди живых конкатенативных языков есть factor, retro.
И да, для любителей APL-подобных языков: http://www.nsl.com/

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

Это справедливо подмечено. Ни один ФП-язык не является функциональным в чистом виде, если только может быть лисп и smalltalk и то там кроме ФП много чего намешано.

Пофиг эта функциональшина. Главное это: сигналы, параллелизм, кортежи, паттерн-матчинг, атомы, наследование, легковесные процессы, кластеризация, пространства имен. Что меня не устраивает в ерланге, так это отсутствие пространств имен.

форт и все-все-все

Никто не забыт и ничто не забыто. http://concatenative.org/

Спасибо за ссылку. Зачетно. Бальзам для мозга.

Сигналы можно делать и без ООП?

Почти. Надо было дочитать эту ветку в дискуссии до конца.

Заметь использование слов Linux и C++

О, я заметил наличие взаимоисключающих параграфов (ООП и C++).

Acme — часть Plan 9.

Нет. Это все равно, что утверждать, будто GEdit — часть Linux.

Это справедливо подмечено. Ни один ФП-язык не является функциональным в чистом виде, если только может быть лисп и smalltalk и то там кроме ФП много чего намешано.

OHSHI... Сколько противоречий в одном коротком предложении.

происходит подмена понятий,

Это справедливо подмечено. Ни один ФП-язык не является функциональным в чистом виде, если только может быть лисп и smalltalk и то там кроме ФП много чего намешано.

OHSHI... Сколько противоречий в одном коротком предложении.

Это суть.

А как вам идея написать ядро ОС, по сложности и возможностям сопоставимой с Linux, с применением ООП

Linux и так написан «с применением ООП»

Прежде чем вбрасывать, загляни в исходники того, аналог чего ты хочешь «с ООП».

Это суть.

Суть в чем? В том что чисто функциональные Haskell, Clean, Curry, Mercury, Miranda не являются чисто функциональными, а мультипарадигменный лисп и объектно-ориентированный смолток являются чисто функциональными? Ты героином часом не балуешься?

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

Ты героином часом не балуешься?

Обижаешь - только зеленый чай употребляю.

Суть в чем?

Не берусь утверждать, что данные языки относятся к функциональным. Не проверял специально есть чистая функциональность или нет, но убежден, что чисто функциональных языков в природе не существует.

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

мультипарадигменный лисп и объектно-ориентированный смолток являются чисто функциональными?

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

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

как это печально

уточню - речь идет об функциональных языках

уточню - речь идет об функциональных языках

не помогло

заметил наличие взаимоисключающих параграфов (ООП и C++).

Утипути. Если ООП возможно на Си, то оно уж точно возможно на Си++.

тогда уж @binary, чтобы машкод возвращал вместо передаваемой функции, прозрачно вызываемый вместо байткода.

В *BSD есть ООП. В Linux вроде тоже

http://www.freebsd.org/doc/en/books/arch-handbook/kernel-objects.html

тогда уж @binary, чтобы машкод возвращал вместо передаваемой функции, прозрачно вызываемый вместо байткода.

Клепают помаленьку :)

Явки, пароли, пруфы? Неужто в рамках цпайтона?

уточню - речь идет об функциональных языках

не помогло

• имеешь суждение о некоторых языках, но основе опыта с только одним языком?
• или основываешься сразу на знании всех языков?
• или может вообще рассуждаешь с теоретической точки зрения, не зная ни одного языка?

Проясни пожалуйста.

Проясни пожалуйста.

ну вот ты сам и ответил же:

имеешь суждение о некоторых языках, но основе опыта с только одним языком

суждения при этом совершенно фантастические

ну вот ты сам и ответил же:

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

суждения при этом совершенно фантастические

тебе ближе метод «закат солнца в ручную»?

Не надо отводить стрелки от себя на простой и прямой вопрос

это был вопрос ко мне? тогда ответ нет на все три пункта

тебе ближе метод «закат солнца в ручную»?

это-то тут при чём?

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

С этим согласен. Причем, если бы clojure не была такой успешной, то в требования «функциональных языков» еще бы записали до кучи и статическую типизацию. Есть такие поползновения (для дотошных: ссылки приводить не стану).

имеешь суждение о некоторых языках, но основе опыта с только одним языком?

Нет. Значит, знаешь несколько языков, что аналогично и с моей стороны

или основываешься сразу на знании всех языков?

Нет. То-же самое с моей стороны.

или может вообще рассуждаешь с теоретической точки зрения, не зная ни одного языка?

Нет. Значит надо понимать практик и разработчик.

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

Может ты пытался высказаться только о себе? Тебя никто не слушает? Доводы не убедительны для окружающих? Не хватает аргументов? Сделай что-то достойно работающее если нет. Если есть, то перепиши заново, «отрефакторь» - есть серьезные проблемы в архитектуре. Больше прорабатывай...

тебе ближе метод «закат солнца в ручную»?

это-то тут при чём?

суждения при этом совершенно фантастические

А ты как рассуждаешь? По инструкции? Бытие определяет сознание, не? Или просто цепляешься в надежде хоть что-то сказать умное? Или действуешь строго по указанию из вне или свыше?

у тебя странная манера вести дискуссию. вот мой комментарий, касается он твоего утверждения о том, что знания Erlang'а достаточно для суждения о других (функциональных) языках программирования. судя по твоим комментариям в данном треде, недостаточно. всё

Вернулись к тому, с чего начали.

На данном этапе мне хватает эрланга, чтобы судить о других функциональных языках. Не претендую на последнюю инстанцию (говорил, что могу ошибаться), но мне достаточно самой ФП-идеи, основанной на приобретенном опыте. Она легко переносится на другие области в том числе и языки. Мне эта идея нравится и мне сразу заметны позитивные результаты. Есть движение. Это просто мое убеждение.

Отношусь к твоим убеждениям уважительно если есть таковые, но считаю по другому. И объяснил как и почему. Важна идея, а как и где она реализована это уже следствие. В эрланге эта идея реализована, экстраполирую, что и в других ФП-языках есть реализация этой идеи. Но она та-же самая. Этого достаточно, чтобы понять что там под капотом. Это ведь так-же понятно как мнимое число))

у тебя странная манера вести дискуссию

А у тебя разве нет?

В эрланге эта идея реализована

Erlang - практически чистый ОО-язык, от функционального подхода там считай одна персистентность данных; функция в Erlang - это не декларативное описание зависимости результата от аргументов, а вполне себе императивное описание (последовательных) шагов расчёта. экстраполировать подобный опыт что на какой-нибудь Scheme, что на Haskell - не самое разумное решение

Этого достаточно, чтобы понять что там под капотом

под капотом у Haskell, Erlang и, скажем, Rust очень разные вещи

понятно как мнимое число

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

К слову о коде на С...

https://github.com/kevinlawler/kona/blob/master/c.c

Как вы это раскапываете?

Как вы это раскапываете?

Просто надо очень не любить С. :)