Роджер Корман (Roger Corman) перевёл (http://lispblog.xach.com/post/107215169193/corman-lisp-sourc...) в разряд свободных проектов Corman Lisp (http://www.cormanlisp.com/f), реализацию языка программирования Common Lisp. Код Corman Lisp опубликован (https://github.com/sharplispers/cormanlisp) на GitHub под лиценизей MIT. До открытия кода Corman Lisp развивался в качестве проприетарной реализации языка Common Lisp, включающей компилятор, ассемблер, дизассемблер, компоновщик, сборщик мусора, стандартную библиотеку функций и интегрированную среду разработки. Corman Lisp рассчитан на работу в ОС Windows и полностью интегрируется с Win32 API, позволяя использовать его в приложениях на языке Lisp. Отмечается, что несмотря на привязку к Windows, некоторые реализованные в Corman Lisp технологии могут оказаться полезными для развития других реализаций Common Lisp.URL: http://lispblog.xach.com/post/107215169193/corman-lisp-sourc...
Новость: http://www.opennet.me/opennews/art.shtml?num=41396
Ура? Или открыли потому что не нужен был?
Мне кажется, что открыли потому, что поддерживать нет никакого желания, а обламывать пользователей значит выглядеть сволочью. А так код открыт -- кому надо, тот пускай и пилит. Этот самый Корман просто снял с себя всю ответственность.
И с этой точки зрения -- ура, оно конечно ура, но не для нас, а для пользователей этого самого лиспа, ежели таковые существуют.
>> ура, оно конечно ура, но не для нас, а для пользователей этого самого Corman Lisp, ежели таковые существуют.Fixed. Во избежание двоякого толкования.
Для пользователей этого самого Шиндошс
В России скоро начнется бум...
В ReactOS мне пригодится...
надо всего только Visual Studio 2005 под ReactOS портировать.
Точно, и перенести на x86.
Вроде и не нужно и выкинуть жалко... куда? да в опенсорс!
Будто что-то плохое.
А будто что-то полезное!Беда-то в том, что пока этот "Цорман" сидел и ждал миллионы, проект протухал (хотя мог бы малу-помалу улучшаться сообществом). СЕЙЧАС за такую "помойку х86" никто не возьмётся, ибо невозможно сразу весь проект перевести под 64-битные рельсы - улучшать-то нужно сразу весь код, чтобы можно было тестировать! Ну и заодно несовместимости с современной VS - я хоть и не понимаю, через какое место можно было стать несовместимым, но факт есть факт - из современной студии этот прект не скомпилять.
Втройне смешно смотреть на этот "выкидыш в опенсорс" из-за ЛИСПа - если ещё лет 10 назад мы как-то дёргались между Дельфи, VC++, Watcom, Perl и прочими "уникумами", то сейчас кроме C# и Жабы практически нет ничего вразумительного. И кому нужен этот ЛИСП, будь он хоть четырежды многоплатформенным?? Он не построил своего комьюнити, не наработал серьёзную массу библиотек - это даблфэйл, после которого не выживают, что и показал пример Кормана.
> Втройне смешно смотреть на этот "выкидыш в опенсорс" из-за ЛИСПа - если
> ещё лет 10 назад мы как-то дёргались между Дельфи, VC++, Watcom,
> Perl и прочими "уникумами", то сейчас кроме C# и Жабы практически
> нет ничего вразумительного.Шутить изволите? Мелкомягкая виндо-недоделка и жаба, та самая, которая-не-тормозит? =/
> И кому нужен этот ЛИСП, будь он хоть
> четырежды многоплатформенным?? Он не построил своего комьюнити, не наработал серьёзную
> массу библиотек - это даблфэйл, после которого не выживают, что и
> показал пример Кормана.Ну во-первых, если вам нужны внушительные по размерам библиотеки, милости просим в Scheme.
А во-вторых, комьюнити у нас роскошное. На #lisp во freenode сидят столько грамотного народу, сколько и не снилось каналам о популярных технологиях.Да, на нём не пишут прикладного софта, которым Вы ежедневно пользуетесь, но на нём пишут куда более серьёзные вещи. Вот в Jet Infosystems на нём пилят систему мониторинга и анализа трафика. А Вы говорите, не выживают... Да они живее всех живых.
> И кому нужен этот ЛИСП, будь он хоть
> четырежды многоплатформенным?? Он не построил своего комьюнити, не наработал серьёзную
> массу библиотекГромкие заявления. В задумчивости посчитал пакеты в Quicklisp-е - 1130!
>- это даблфэйл, после которого не выживают, что и
> показал пример Кормана.Его пример показал то что несвободное дохнет. Свободные sbcl,ccl,ecl,abcl (разные ниши) парадоксальным образом живут. Все по слову великого Столмана :)
Если выкинуть жалко, то подарить фонду Apache.
Читаю мысли.
Ты только что подумал: "не нужно".
Правильно читаешь, однако...
Читай полностью. Я подумал: "не нужно читать мои мысли".
Он и изначально распространялся с исходными кодами, только под другой лицензией.
Цитата из википедии: "CormanLisp свободно доступен (для некоммерческого использования) вместе с исходными кодами (за исключением IDE, ведущего себя как классическое Shareware с месячным сроком использования)".
> за исключением IDE, ведущего себя как классическоеУгу, это как и MSVC, кроме как в маздайном ИДЕ и компиляторе нигде не соберётся.
Тут конечно можно приписать, "- а вы пишите кода на Pure ANSI C или ISO STD C++ 200x"
но тогда возникает вопрос - накуя мне этот MSVC и этот КарманЛисп, если GNU Common Lisp
делает бесплатно и портабельно.
Как клоун, потративший однажды 10 часов чтобы скомпилировать 10 кб программу для Линукс под Windows заявляю: один хрен.Код, написанный в Windows на MSVS, сложно портировать на Линукс из-за отсутствия MSVS под Линукс.
Код, написанный в Линукс с использованием GNU C, сложно портировать под Windows из-за заголовочных файлов, который гвоздями прибиты к Линукс.
Чтобы было "портабельно" нужно вводить ещё один уровень абстракций и виртуальную машину, абстрагирующую ваш исходный код от особенностей конкретной ОС. Языки C/С++ такими не являются.
Если нужны примеры - берёшь исходник binutils (например, он на GNU C) и пытаешься собрать любой исходник под Windows.
Думаю, с портабельностью всё гораздо проще: сам язык нужно держать под жёстким стандартом, НО(!) непрерывно его(стандарт) развивать и пополнять сторонними либами (которые, опять же, вносятся в стандарт), чтобы в результате получилась среда а-ля .NET - максимально исчерпывающая для большинства задач и полностью портированная под популярные архитектуры.
Понятно, что 100% это сделать нереально, но и 99% - хороший результат! А сейчас мы имеем чуть менее, чем никакую портабельность даже для тупого сишного кода просто потому, что "так в линуксе принято". :(
Проще? Ты сказал проще, мою юнный падаван? Нет, не проще... Пелена тьмы спала с моих глаз. Идиотизм кромешный начался.Если смотреть на всё с теоретической точки зрения, то:
1. из-за отсутствия стандартизации оборудования существует множество аппаратных реализаций что вынуждает вводить уровень абстракции программ от аппаратуры - ОС.
2. из-за отсутствия стандартизации API/ABI ОС существует множество несовместимых API/ABI ОС что вынуждает вводить ещё один уровень абстракции программы от ОС - программы, выполняющиеся на виртуальной машине.
3. из-за большого количества программ и часто меняющегося API/ABI невозможно довести всё до ума, что вынуждает вводить ещё один уровень абстракции - эмулятор (он же песочница).
4. и вот уже пошли разговоры о том, что виртуальные машины из п.2 лучше запускать не на реальном оборудовании в песочнице, а из-под другой виртуальной машины.Мне одному кажется, что это путь в никуда?
Стандартизация идёт по трём путям:
1. когда приказали сверху (POSIX)
2. когда приспичило снизу (w3c, IEEE, VESA/VBE, PnP)
3. когда мы первые придумали и назвали нашу кривую реализацию стандартом (FAT, multiboot)Сегодня нет острой необходимости унифицировать ПО под разные ОС, поэтому в стандартах этого тоже не будет. Вопрос когда С/C++ для Windows разойдётся с С/C++ для Линукс - это вопрос времени. Они уже несовместимы на уровне библиотек и это только начало.
Если государство не вмешается, то каждые 5-10 лет будет появляться новый уровень абстракции, благо что рост производительности выч. техники пока это позволяет.
На портирование конечно требуются усилия, но это все решаемо. Как разработчик С++, переводивший несколько месяцев систему с Windows на Linux, которую писали несколько лет и собираемую 2 часа ответственно это заявляю. Система многопоточная, работает с медиапотоками, есть места, которые привязаны к железу. Да, нужно ввести уровень абстракции платформы, но никакую виртуальную машину тут приплетать не нужно. Внешние заголовочные файлы нужно добавлять регламентировано и оправданно, а не где попало.
> Код, написанный в Линукс с использованием GNU C, сложно портировать под Windows
> из-за заголовочных файлов, который гвоздями прибиты к Линукс.Вот у что-что, а с GNU C на куда хочешь, проще некуда.
Тем более гнусности это такая экзотическая хрень, которую
даже под UNIX редко юзают, типа alloca() иль массив указателей меток.
Долго же его жаба душила..
> Долго же его жаба душила..Он верил в американскую мечту - когда-то стать миллионером. :) Он только забыл, что никогда и нигде люди не зарабатывали на своих смехотворных программах - везде выигрывал только хитро*опый бизнес.
Ошибаешься. Статистика говорит, что невозможно предсказать какой проект станет успешным, но есть процент успешных проектов. На этих допущениях основан венчурный бизнес. Применительно к старт-апам есть понятие "выстрелил" - когда проект становится популярным и выходит на окупаемость. Если проект не выстрелил - его закрывают и начинают новый. Ничего личного, просто бизнес.Это относится не только к ИТ.
Во втором абзаце вся суть и сермяжная правда о разработке софта который прибит гвоздями к вантузу. Десять казней отдыхают.
Дело скорее в гвоздях, чем в том к чему прибито:
>в коде используется обилие низкоуровневых оптимизаций на языке ассемблер
> Дело скорее в гвоздях, чем в том к чему прибито:
>>в коде используется обилие низкоуровневых оптимизаций на языке ассемблерПопутный вопрос: ну да, ассемблер, И ЧТО? У интела что-то поменялось в х86? Другими словами, "user space" ассемблер ТОЖЕ МОЖНО ПОРТИРОВАТЬ - nasm/fasm имеют почти masm/tasm синтаксис.
Корман проиграл из-за жадности и недальновидности - теперь его *овноподелие только и достойно, что отсвечивать на гитхабе.
Оно даже не было открыто? И значительная часть лиспопоклонников фапала на проприетарное г-но?