Ответ на »сообщение 1301« (torvic)
___________________________
>>>имеет смысл реализовывать идеи и концепции, создавая вариации на тему, заточенные под конкретную платформу
И выбрасывать все наработки при переходе к другой платформе?

Давайте посмотрим в будущее: системы команд и архитектура процессоров не вечны , ОС не вечны, "платформы" не вечны ... и нужно минимизировать потери на переходах. Собственно это и было одной из причин создания высокоуровневых языков: алгоритмы живут гораздо дольше платформ.
Это еще один камень в огород .НЕТ - выбрасывайте ваши прежние наработки на Паскале, Лиспе и т.д. и т.п. и все за решетку (#).

Ответ на »сообщение 1299« (Jack Of Shadows)
___________________________
реализация стандартов лиспа, хаскеля, питона ... под дотнет или яву
это тупиковый путь
имеет смысл реализовывать идеи и концепции, создавая вариации на тему, заточенные под конкретную платформу
собственно все этим путём и идут - f#, nemerle, ironpython, boo, scala, groovy

Ответ на »сообщение 1299« (Jack Of Shadows)
___________________________

У лиспа ведь своя VM и тоже нехило жрет память.

ИМХО, "толстая" RTL это еще не VM. Уж если браться рекламировать Лисп, такие терминологические вольности недопустимы, так как автоматически (причем совершенно беспочвенно) отсекают тех, кого VM не устраивает.

Основным недостатком из за которого ООБД проиграли реляционным, было то что они жестко привязаны к типам в конкретном языке.
Сохранил обьекты на delphi, не можешь прочитать их из java.

http://www.versant.com/en_US/products/objectdatabase

>>>Transparent object persistence from C++ and Java

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

ИМХО, один из очевидных вариантов добиться такого эффекта --- реализовать взаимодействие клиентского приложения с ООСУБД по аналогии с CORBA (IDL + stubs + стандартизация языковых привязок), без привлечения .Net.

Ответ на »сообщение 1296« (Сергей Перовский)
___________________________
dotnet отличная идея, которая давно напрашивалась. К сожалению реализация действительно сделана по принципу "Все для фронта, все для победы". Победы сишарп разумеется. Остальное гори оно синим пламенем.
Какие проблемы решает dotnet ?

1. Единая виртуальная машина.
Скажем если вызывать dotnet библиотеки из лиспа, то получается запуск 2-х виртуальных машин из за одной программы. У лиспа ведь своя VM и тоже нехило жрет память.
Если все языки под dotnet, то и VM запускается один раз.

2. Единое пространство библиотек. Никаких тебе FFI (foreign function interface)
Значит из любого языка доступно все богатство библиотек dotnet без всяких дополнительных инструментов.

3. Единое поле типов
В настоящее время даже если при помощи FFI подключать в язык чужие библиотеки, все равно надо еще и типы преобразовывать. Туда и обратно.
В dotnet независимо от языка типы одни и те же. Не нужно никакого преобразования

4. Из предыдущего пункта вытекает еще одно преимущество. Обьектно-Ориентрированные БД !! Наконец то!!
Основным недостатком из за которого ООБД проиграли реляционным, было то что они жестко привязаны к типам в конкретном языке.
Сохранил обьекты на delphi, не можешь прочитать их из java.
Благодаря единому полю типов стало возможным записывать и читать из ООБД на любом dotnet языке.

К сожалениюю заточенность dotnet под сишарп явственно проглядывает.
Особенно это бьет по лиспу. Ведь основным атомарным типом в лиспе является символ.
А такой тип отсутствует в сишарп, и конечно же в dotnet. Отсюда и трудности с реализацией полноценного лиспа на dotnet. Максимум чего смог достигнуть проект LSharp - это интерпретатор с односторонним движением.
То есть lsharp из dоtnet импортировать может. А вот обратно нет.

Таки образом для лисперов dotnet остается (пока ?) достаточно чужеродной, враждебной средой.
Что интересно - похоже и для хаскеля тоже.

Ответ на »сообщение 1296« (Сергей Перовский)
___________________________
Многие утверждают, что язык промежуточного слоя должен быть императивным, т.к. его легче переводить в императивный же ассемблер. Но я не уваерен в очевидности такого рассуждения.  А вы знаете неимперативный ассемблер?

Ответ на »сообщение 1296« (Сергей Перовский)
___________________________

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

А на кого или на что должен быть ориентирован такой промежуточный язык: на человека или на компьютер? В чем его предназначение: обеспечивать реализацию разноплановых языков на разных платформах или служить для взаимодействия/обмена между языками?

Если на человека и на взаимодействие, то позиции Си довольно сильны. Если на компьютер и на реализацию, то есть, например, SDE-представление на основе семантического словаря (Semantic-Dictionary Encoding), которое предложил Michael Franz. Это не язык в традиционном понимании, а промежуточное представление программного кода перед генерацией native-кода под конкретную архитектуру. Насколько я понял этот подход, он не ограничен реализацией непременно одних императивных языков.

Кстати, тот же Franz показал, в чем состоят недостатки использования для этих целей любых промежуточных языков, ориентированных на виртуальные машины.

Теперь подеремся из за .NET :(
Идеологически очень здраво - общая платформа для разноязыких модулей.
Ничуть не хуже предложения написать все необходимые языки, используя в качестве ядра раскрутки Лисп или Форт.
А вот получилось как всегда...
Вместо десятка понимающих суть реализовывали сотни недоучек.
Пока все известные мне примеры перевода сложных программных продуктов на .NET приводили к резкому увеличению числа глюков. Или к бесконечным отсрочкам релизов, если у разработчиков сильная команда тестеров.

Мы пришли к очень интересным вопросам: каким должен быть язык промежуточного слоя. Джек считает, что функциональным и предлагает Лисп. Юниксоиды уверены, что С - идеальный язык промежуточного слоя АДНАЗНАЧНА. В Майкрософте представляют его как упрощенный С# - в него очень удобно транслировать С#, остальные пусть сами о себе беспокоятся.
Многие утверждают, что язык промежуточного слоя должен быть императивным, т.к. его легче переводить в императивный же ассемблер. Но я не уваерен в очевидности такого рассуждения.

Господа. Что вы прицепились к последовательности исполнения ?
Она не определяяет императивность.
Императивность это изменение состояния системы.
В лиспе и ocaml - тоже жестко заданная последовательность. Что не делает эти языки менее функциональными.

Что касается dotnet. Не так уж он и нужен. Я работаю на lispworks и не испытываю никакой нехватки библиотек.
Все что мне надо - есть.
Хотя нет, не все. - Не GUI билдера как в dotnet. Поэтому я не использую лисп для создания виндовых приложений. Однако MS скоро и эту проблему для меня решит. С выходом в свет их WPF, можно будет рисовать dotnet-ные окна используя для этого программу с идиотским названием Expression Interactive Designer http://www.microsoft.com/products/expression/en/interactive_designer/default.mspx

А потом уже из лиспа работать с этой GUI, также как я работаю с HTML формами сделанными в DreamWeaver.
Ну а на сегодня у меня есть библиотека RDNZL, при помощи которой я могу импортировать в лисп ЛЮБУЮ dotnet библиотеку.

(enable-rdnzl-syntax)
RDNZL-USER 4 > (import-types "System.Windows.Forms"
                            "MessageBox" "MessageBoxButtons" "DialogResult")
NIL
RDNZL-USER 5 > (use-namespace "System.Windows.Forms")
RDNZL-USER 6 > (defun message-box (text &optional (caption "RDNZL"))
                [Equals [MessageBox.Show text caption
                                  [$MessageBoxButtons.OKCancel]]
                        [$DialogResult.OK]])
MESSAGE-BOX
RDNZL-USER 7 > (message-box "Hello World!") ;; user presses "OK" button
T

Ответ на »сообщение 1289« (Артем)
___________________________
>>>А как же реализованная в IL возможность оптимизации хвостовой рекурсии, которую испотльзует F# и не использует C#? Насколько я слышал, это не единственная фича .Net, которую C#  не использует.

Насколько я слышал, F# её уже не использует, а сам разворачивет хвостовую рекурсию в цикл. А когда использовал, очень тормозил.

>>>Посмотрите на F#, у него гораздо больше перспектив, чем у его прообраза - OCaml

Насчет перспектив F# - вопрос весьма темный.

>>> А чем требование того, что язык должен компилироваться в CIL хуже требования компиляции в машинные коды?

Не хуже (если пренебречь вопросами эффективности), но и не лучше.

>>> Опять-таки, скажите, чем требование того, чтобы язык подчинялся требованиям VM хуже того, чтобы язык подчинялся требованиям OS?

Опять-таки, не хуже, но и не лучше.