Отредактировано anonymous_incognito
>>> Подробности (zouev.blogspot.com)
Для загрузки на попробовать стала доступна версия коммерческой реализации языка программирования Common Lisp — Allegro CL 9.0 Express Edition.
Доступны пакеты для:
Основные новшества и изменения в этой версии:
>>> Загрузка (franz.com)
А как вам идея написать ядро ОС, по сложности и возможностям сопоставимой с Linux, с применением ООП (например, на C++) Каждый драйвер, сервис и др. сделать классом (ну группой классов).
Плюс, который я вижу - за счёт применения классов и пространств имён можно повысить структурированность кода, не переходя к микроядерности.
Минус - необходимость поддержки ООП в ядре влечёт за собой некоторый overhead (вот насколько он будет заметен - тоже интересный вопрос).
Высказывайтесь.
А кто-нибудь здесь пишет на C или C++ в vim? Что у Вас интересного в конфигах? Не поделитесь своими .vimrc?
Доброго времени суток! Недавний мой пост о smalltalk натолкнул меня на мысль, что надо заниматься тем, что больше нравится. В итоге я пришел к выводу, что лиспо-семество мне ближе. Поэтому прошу многоуважаемых спецов по лиспу посоветовать: 1. Какую реализацию Lisp выбрать? В чем ее преимущество перед другими? Есть ли возможность заводить под оффтопик? 2. Какой графический тулкит лучше всего вяжется с данной реализацией? 3. Какой быстрый туториал можно почитать по данной реализации лиспа? (классические труды в over9000 страниц не советовать, их я найду в LispFAQ и через поиск лора, интересуют именно туториалы после которых я могу начать писать код через пару вечеров неспешного чтения).
З.Ы.: Если найдутся противники лиспа и/или сторонники C# - отговорите меня реализовывать ERP на лиспе (работаю на C# сейчас, поэтому с ним будет легче). еще раз хочу заметить, что «ерпа» будет домашней поделкой, «для себя» и в целях саморазвития.
Сабж
Есть ли в интернетах хорошее описание внутренностей OpenJDK, особенно - компилятора? Где, что, почему, зачем, итп
Гуглил, не нагуглил
http://citforum.ru/gazeta/165/
по линку многабукаф, немного для Ъ:
факт остаётся фактом: сторона, представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp’еров была куда убедительней и последовательней, чем сторонников ООП.
Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: “Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле”.
Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП “ускоряет разработку программ”: “Как только ты сказал слово «объект», можешь сразу забыть о модульности”.
Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла “тихая революция”.
Он там прочёл 2 большие лекции. Первая часть первой лекции: http://video.yandex.ru/users/ya-events/view/129/
Смотрели многие, но многие и не заметили.
Это автор STL для C++. Давно занимается вопросами обобщённого программирования. Вопросами отделения типов от алгоритмов. Вопросами унификации библиотек для всех языков без проседания производительности. Сравнивает программистов и электронщиков - первые постоянно собирают всё из транзисторов, а вторые уже давно юзают готовые микросхемы (намёк на хорошие библиотеки). Оч. интересные и вдохновляющие лекции. Советует выкинуть Александреску на помойку, не заниматься изучением питонов и хаскелей и их отличий, а сначала осилить базовые вопросы построения и анализа алгоритмов и читать Кнута или хотя-бы купить и поставить на полку, чтобы он оттуда говорил: «прочитай, прочитай...»
Подскажите какую-нибудь приличную сишную библиотеку для работы с памятью через пул объектов. Года 4 назад что-то находил, но название вылетело из головы совершенно.
Лицензия LGPL, BSD, etc...
>>> Подробности (gnome.org)
а давайте поговорим о сборщиках мусора
используете ли языки с GC, и какими их преимуществами при этом пользуетесь? если не используете, то как автоматизируете работу с памятью (и автоматизируете ли)? знаете ли современные алгоритмы сборки мусора, оцениваете ли их производительность при выборе механизмов работы с памятью?
в общем, жажду конструктивной дискуссии
Подскажите пожалуйста юз-кейсов для корутин и продолжений. Типичные паттерны, алгоритмы, проблемы. Благодарствую.
Ну, что ж, в Development так в Development, хотя Лисп давно перестал быть мемом одного лишь Development'а (и даже одного ЛОРа). Итак, сабж!
[ ] Да, профессионально и за деньги
[ ] Да, just for fun и для самообразования
[ ] Да, участвовал в opensource-проекте
[ ] Да, пилил скрипты Emacs/GIMP/AutoCAD/Lilypond etc.
[ ] Да, в рамках образовательной работы (лаба, курсовик, диплом)
[ ] Да, в рамках академической работы (диссертация, статья, монография)
[ ] Да, мне сказали, что лисперов любят девушки
[ ] Нет, но собираюсь
[ ] Нет, и не собираюсь
[ ] Вообще-то я Джон МакКарти, а вы кто такие?
[ ] в Советской России Лисп пишет на тебе!
Приветствуются развернутые ответы и верифицируемые пруфлинки. Например, на какую фирму работали, в каком конкретно opensource-проекте участвовали, какая была тема научной работы, помогло ли с девушками, и тому подобное. INB4 буквоедов: под «лиспом» подразумеваются все языки семейства: Scheme, CL, Clojure и прочие.
Предлагаю учёным мужам в этом топике собрать и обсудить проблемы в языке Common Lisp. Кому что не нравится?
Мне категорически не нравится реализация методов в CLOS. Метод в нём - это специализированная общая функция (дженерик), просто функций, присущих только данному классу, нет. При создании метода автоматически создаётся дженерик, если он ещё не был создан. Дженерик виден во всём пакете, и все специализации должны соответствовать его сигнатуре. На практике это приводит к тому, что почти сразу появляется проблема несоответствия сигнатур у методов разных классов. Можно, конечно, разнести классы по разным пакетам, но это влечёт за собой больше неудобств, чем решает. Пока весь код - ваш, под вашим контролем, это особой проблемы не представляет, но представьте, что классы плодит куча разных людей?
Не нравится неполная интеграция CLOS в язык: распознавание класса в CLOS для стандартных лисповских типов ещё работает, но не для своих типов, объявленных через deftype.
Ну и вообще CLOS жирноват для 90% задач. Не говоря уж про MOP, который почти никем не используется, а если и используется, то для решения проблем с кривостями CLOS, либо просто книжку AMOP обчитался и повредился умом.
Не нравится реализация пакетов (неймспейсов). Удобно иметь вложенные пакеты, но их нет. Возможность задания никнейма для пакета в самом пакете - членовредительская, ибо каждый гомо сапиенс для своей мегабиблиотеки задаёт двух-, трёхбуквенный никнейм. Букв в общепринятой латинице и так мало (опустим перечень адских пыток, которым после смерти будут подвергнуты те, кто пишет комментарии не на английском языке или вообще использует не-ASCII алфавит для идентификаторов), так ещё количество их кобминаций ограничено любовью человеков к акронимам и красивым сокращениям.
Не нравится отсутствие стандартных средств рефлексии/интроспекции лексического окружения. Лексэнвы эти есть во всех реализациях, но стандартного способа работы с ними нету. Нужда в этой фенечке шкурная, и широкими массами не востребована, но всё же.
loop - какашка. Это не лисп. Точка.
Встроенный макроязык в format - тоже какашка. Я каждый раз после двухдневного перерыва лезу в документацию или старый код, чтобы вспомнить, как форматировать число с плавающей запятой. В общем-то, перенаворочен format. И всякой ерунды в него набито, типа автоматического окончания у числительных, но которое работает только для аглицкого языка.
unwind-protect - хорошо, но от попыток человеком сэмулировать продолжения для CL хочется икать. Такие trade-off вполне понятны, но лучше бы unwind-protect ограничили.
Ну и более мелкие ляпы в стандарте, типа (elt sequence index), но (nth index list).
Да, этот пост написан в Емаксе, запущенно под лисповым оконным менеджером человеком, получающем деньги за написание лиспокода :)
>>> пост (neopythonic.blogspot.com)
Адам Мессингер (Adam Messinger), вице-президент Oracle по разработке, заявил на конференции QCon, что Oracle будет разрабатывать две версии JVM на основе OpenJDK: платную и бесплатную.
Мессингер не объяснил, чем Premium будет отличаться от бесплатной, но, похоже, она будет работать быстрее и поддерживать дополнительные способы взаимодействия с Java-библиотеками, разрабатываемыми самой Oracle.
>>> Подробности (theregister.co.uk)
А так же почему гуглевый тренд показывает стабильный рост интереса к Хаскеллю и, как минимум, стабильное отсутствие роста интереса к лиспам.
Линус Торвальдс в списке рассылки ядра жестоко раскритиковал эти предложения и заявил, что большинство программистов никогда не будут этими новыми системными вызовами пользоваться, что они будут нестабильными и плохо оттестированными.
Цитата: "Поэтому вместо того, чтобы придумывать новые системные вызовы, которые никто не будет использовать, разработчики файловых систем должны стараться обеспечить нормальную работу даже плохого кода. Потому что, хотите вы этого или нет, 99% программ именно так и написаны.
Тот неоспоримый факт, что люди не проверяют ошибки, которые возвращает системный вызов close() (закрытие файла и сброс "грязных" данных из кэша на диск) должен означать, что, например, при отложенной записи на диск нужно обязательно проверять ситуацию переполнения диска. Если ваша файловая система возвращает ENOSPC при закрытии файла через вызов close(), а не при записи в него через write(), значит, что вы потеряли обработку ошибок переполнения диска у 90% приложений. Вот так всё просто.
Жаловаться на то, что ошибка в приложении - это всё равно, что жаловаться на скорость света: вы должны иметь дело с реальным миром, а не с тем, каким бы вы хотели его видеть. То же самое относится к идее, что "люди должны писать во временный файл, вызывать функцию fsync для него и переименовывать его вместо оригинала". Вы думаете, что так должно быть, но в реалии программисты пишут open(filename, O_TRUNC | O_CREAT, 0666). Это неправильно, я знаю. Но в конечном итоге, даже разработчики хорошо написанного приложения могут решить, что fsync() не стоит тех потерь в производительности. В git, например, где мы обычно пытаемся быть очень, очень и очень аккуратными, fsync() в объектных файлах по умолчанию выключен.
Почему? Потому что его включение вызывает неприемлемое поведение ext3. Сейчас, надо сказать, дизайн git'a рассчитан на то, что потеря нового БД файла не фатальна, но потенциально это очень беспокоит и смущает - вам, возможно, придётся откатить изменения назад и переделать некоторые операции вручную.
К чему я всё это говорю ? Иногда те разработчики файловых систем, которые говорят "вы должны использовать fsync(), чтобы получить предсказуемые результаты" - это те же люди, которые испортили всё это до такого безобразия, что fsync'ом абсолютно нереально пользоваться.
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда."
>>> Подробности (slashdot.org)
>>> Подробности (livejournal.com)
| ← назад | следующие → |