Если коротко, то подскажите отечественные микропроцессоры, имеющие на кристале MMU. Есть ли такие процессоры? Я пока не нашёл.

А если чуть развёрнуто, хотелось бы «наехать» на две группировки разработчиков встраиваемых систем, которые периодически устраивают холивар на тему использования Linux во встраиваемых системах. Первый лагерь, это микроэлектроники, втаптывающие в грязь разработчиков, использующих Linux на встаиваемых устройствах. Я с вами согласен лишь отчасти - Linux далеко не лучше решение для встраиваемых устройств, но ваши потуги написать всё в суперцикле - вполне себе гадкий и неоптимальный подход. И когда вам приходится писать настоящие RT системы, то вы поневоле обращаетесь к готовым решениям (например, Keil RTX). Второй лагерь - приверженцы Linux на микроконтроллерах. Ну вам же электронщики говорят - не надо микроскопом гвозди забивать.

Так чего же я предлагаю? Если вы ещё не убили друг друга в спорах, нужен ли Linux на встраиваемых системах или нет, то попробуйте представить идеальную систему для встраиваемых устройств. Если представили, то сравните это с http://l4ka.org/l4ka/l4-x2-r7.pdf

Чем ближе ваше представление к l4-x2 - тем вы ближе к соврешенству. Спорить бесполезно, ибо постигший дао L4 станет верным его жрецом, а мысли непостигшего - равносильны разумению ребёнка. Если вы легко оперируете pthreads, семафорами и мютексами - вы всего лишь на половине пути.

Как известно, в мире разработки ПО нет серебряной пули, и даже обычную пулю надо долго искать. Пули в мире ПО делают обычно из говна, потому что материала в изобилии, а технология его производства всасывается с молоком матери. Итого, если отбросить все маркетинговые заморочки, оборачивающие пули в конфетную обертку, и вскрыть сермяжную правду, получаем следующие тезисы.

• Откатоемкие технологии, где ынтырпрайзные коробки стоят миллионы бабла за каждое процессорное ядро, популярны не только в этой стране, а только разве что не в Антарктиде.
  
• При этом вся простота настройки и работы с ними существует только в воображении чувачков из отдела продаж, которые и продукта-то не видели. Для правильной установки и настройки нужно прочитать два талмуда, поиграться в конструктор типа генты, только все делать руками. Хорошо еще посетить пару платных курсов, где настраивать покажут после долгого трепа о достоинствах продукта.
  
• Нет, конечно, бывает автоинсталлятор, который круто смотрится на скринкастах и презентациях, и который даже работает иногда, но в реальном применении после него нужно править почти все.
  
• На самом деле можно ходить на курсы, прочесть все книжки и не узнать главного нюанса, из-за которого все либо глючит, либо тормозит, либо не работает на данной конкретной конфигурации. Для этого нужно нанимать чувака, у которого с этой системой 10 лет полового опыта. Судя по желаемой зарплате, чувак питается фуа-грой вместо гречки.
  
• Исходники программ не хотят открывать в основном не из-за патентов (таких контор, будем-ка честны, единицы), а из-за того, что код адски отвратителен, дыряв и вызывает рвоту.
  
• Если большой многоцелевой программный комплекс написан на одном языке, во имя святой унификации и простоты сопровождения, половина кода будет представлять собой жуткие костыли и упражнения по использованию надутого презерватива в качестве дирижабля — даже самый универсальный язык не учитывает специфики всех возможных задач.
  
• Если большой многоцелевой программный комплекс написан на разных языках, во имя использования оптимального инструмента для каждой задачи — половина кода будет представлять собой жуткие костыли для интеграции всего этого барахла — обертки, скрипты еще на нескольких языках, а список зависимостей будет длиной с Юлькин приговор.
  
• Документации много не бывает. Ее в основном вообще не бывает, в частности там, где она действительно нужна.
  
• Никогда не надо говорить, каково целевое разрешение экрана, при постановке задания на заказное ПО. Хотя спрашивать будут. Потом окажется, что с другим разрешением ПО не способно работать в принципе.
  
• Во время получасового даунтайма в связи с апгрейдом системы для пользователей этой самой системы главное — каждый день на работу приходить вовремя, а вдруг наконец-таки проапгрейдили.
  
• Те, кто практикуют апгрейд без даунтайма, обычно умалчивают, сколько времени длится цирк после такого апгрейда. А глюки там порой феерические, из-за того, что не весь код сразу раздуплил, что часть его проапгрейдили.
  
• Особая веселуха — это когда горячий апгрейд работающую программу настроит, и подымет все что надо, а постоянный конфиг и автозапуск прописать забудет. Перезагрузка-то рано или поздно случится.
  
• Несмотря на то, что только ленивый не кричит на всех углах, что у него-де TDD и покрытие тестами 100%, качество ПО деградирует просто-таки стремительно. Где они только набирают столько багов, с таким скрупулезным-то тестированием?
  

Добавляйте своего пессимизма, дамы и господа.

Скрепя сердце, с сожалением и горечью, но тем не менее, движимый рациональным подходом к делу, перевел код программы для своего стартапа с Common Lisp на Microsoft .NET, а именно на C#.

http://love5an.livejournal.com/376801.html

Подскажите кто-нибудь ЯП с развитой метасистемой, только нормальный, а не лисп.

Добрый день дорогие аналитики L0R'a. Ковыряю ракет, пишу на нем клиентскую программу - а пока хочется вот что спросить. Все же что лучше - Racket или Common Lisp? Что более перспективно? Ну и естественно, какие у одного недостатки/преимущества по сравнению с другим?

например:

(defun f (&obj)
 (with-slots a b c) obj
  (setf a b)
  (setf b c)))

Дабы не слать напраслину на любителей создавать классы и объекты, пытаюсь разобраться в плюсах, которые отличаются от родителя, на первый взгляд, только названиями файлов, функций и приемами организации мышления погромиста. Так вот, эти ваши классы даже в учебнике называют почти структурами, а мизерное отличие сомнительного профита легко можно решить и в анси си(далее - ансися) при ближайшем обновлении. Ансися страдает перегрузкой названий функций для каждого из подлежащих обработке типов, отсутствием удобной иногда перегрузки функций, что, конечно минус, но не критично, ибо решаемо. Сиплюсик конечно удобен школьникам, тяжело принимающим всякие %s %d %x и так далее в качестве аргументов принтфов и сканфов, но зачем создавать для этого отдельный язык? Ведь << и >> становится лишним препятствием при освоении, если параллельно сдвиги битов читать. Итого, я вывел для себя, что в попытке облегчить участь программиста, разработчики языка усложнили его до степени родителя, не получив особенного профита. Чем же ооп так всем нравится, если оно не облегчает код?

Несколько вопросов:

• Есть ли годная книга по тому, как разрабатывать Ъ ООП способом, с задачками/решениями, а не просто описанием паттернов и нескольких составных паттернов?
• Разрабатывают ли на ФП корпоративные приложения. И как?
• Как переключиться на ООП мышление (и стоит ли) с процедурного/функционального? Волею судьбы сложилось так, что я как-то пропустил мимо объектно-ориентированные возможности С++, C# и Java и слишком много баловался решением мелких задач на Haskell и Scheme (по SICP). Суровая реальность требует наличия ООП навыков.

Решил намедни углубить свои знания по плюсам, чувствуя, что скоро нехило так потребуются по работе. Теперь сижу, обмазываюсь тут всякими трупами страусов, Скоттом Майерсом и другими. Г-пди, как же можно на этом писать, особенно после знания божественных лиспов, хаскелей и прочих матанских агд (sic!). Это какая-то пытка, честное слово, мне натурально мерзко и противно читать как люди пытаются вырезать гланды через задний проход да ещё и хвалятся этим, поглядите, мол, как это круто. Такое ощущение, будто плюсисты все поголовно латентные мазохисты.

template <typename T>
class Rational
{
    public:
    ...
    friend const Rational operator*(const Rational& lhs, const Rational& rhs)
    {
        return Rational(lhs.numerator() * rhs.numerator(), // same impl
            lhs.denominator() * rhs.denominator()); // as in Item 24
    }
}

An interesting observation about this technique is that the use of friendship has nothing to do with a need to access non-public parts of the class. In order to make type conversions possible on all arguments, we need a non-member function (Item 24 still applies); and in order to have the proper function automatically instantiated, we need to declare the function inside the class. The only way to declare a non-member function inside a class is to make it a friend. So that's what we do. Unconventional? Yes. Effective? Without a doubt.

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

Перемещено mono из talks

Задача - создать массив случайных чисел на 3000000 элементов и замерить сколько времени займет нахождение суммы квадратов.

SBCL:

(defconstant +size+ 3000000)

(defparameter *vector* (map-into (make-array +size+ :element-type 'double-float) (lambda () (random 1.0d0))))

(defun sum-vec (v &aux (s 0.0d0))
  (declare (optimize speed (safety 0) (debug 0))
           (type (simple-array double-float (*)) v)
           (type double-float s))
  (dotimes (i (length v) s)
    (incf s (expt (elt v i) 2))))

(time (sum-vec *vector*))

$ sbcl --load bench.lisp
Evaluation took:
  0.009 seconds of real time
  0.012001 seconds of total run time (0.012001 user, 0.000000 system)

Racket

#lang typed/racket
(require racket/flonum)

(define Sz 3000000)
(define test-vec 
    (for/flvector #:length Sz ([i (in-range Sz)]) (random)))

(: sum-vec : FlVector -> Flonum)
(define (sum-vec v)
  (for/fold ([S 0.0]) ([e (in-flvector v)]) 
    (fl+ (fl* e e) S)))

(time (sum-vec test-vec))

$ raco exe bench.rkt
$ ./bench
cpu time: 20 real time: 22 gc time: 0

1. Можно ли код на racket еще улучшить?

2. Сколько времени занимает обработка в ваших языках? Особенно интересует ocaml и haskell

UPD. Думаю стоит пририсовать два нуля к размеру массивов, чтобы они не влезали целиком в кеши, олсо подумать там более произвольным доступом в к элементам.

mocl — набор инструментов для разработки на Common Lisp под мобильные платформы iOS и Android. По заверениям разработчиков получаемый код (используется LLVM) по производительности значительно превосходит аналогичный на Java/Dalvik.

В основе mocl лежит идея, заключающаяся в том, что логика приложения должна быть полностью описана на Лиспе, а пользовательский интерфейс — быть «родным» для платформы. Авторы проводят аналогию с Вэбом, когда логика серверного приложения описана на одном языке (например, на Лиспе), а представление — на другом (HTML + JavaScript).

Цена лицензии варьируется от $1299 для серьёзных компаний до $199 для индивидуальных разработчиков. Также предусмотрена «Source code license» для особых энтузиастов, доступ к которой, по-видимому, дают после обращения в службу поддержки.

Пример приложения на Github.

>>> Подробности

Для загрузки на попробовать стала доступна версия коммерческой реализации языка программирования Common Lisp — Allegro CL 9.0 Express Edition.

Доступны пакеты для:

• Linux (glibc 2.11 или позже);
• Mac OS X (10.6 или позже), включает поддержку Lion;
• FreeBSD (8.2 или позже);
• Windows (XP, Vista, 7, 8, Server).

Основные новшества и изменения в этой версии:

• полная поддержка SMP;
• 820 исправлений и улучшений с последнего релиза;
• полностью обновлен AllegroServe — вебсервер Franz Inc., написанный на лиспе: автоматическая компрессия/декомпрессия файлов, поддержка chunking, новый выбор опций безопасности, включая TLS v1.0 (также известный как SSL v3.1) протокол для защищенных соединений;
• улучшена интеграция с Java через модуль jLinker, улучшен протокол, стал проще API;
• новая и значительно упрощенная инсталляция для графических утилит на Mac 64-бит.

>>> Загрузка