Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, aka50, Вы писали:

К>>>Знаешь, а прикольная идея как раз эдакий "рубильник" встроить в сам язык, чтоб можно было бы регулировать соотношение гибкость/жёсткость в ту сторону, которую нужно, причём, чтоб это было универсальным подходом, как сама расширяемость того же лиспа.

A>>Идея может и хорошая, но есть кучка минусов:
A>>1. Рушится стройная концепция языка, т.к. разработчик вынужден кроме реализации собственно языка производить еще и тонкую настройку "рубильников"
A>>2. Разработчик языка должен предусмотреть интероперабельность различных "рубильников", результаты такого подхода мы можем все наблюдать в java 1.4 vs 1.5
A>>3. Если этих рубильников в языке будет много, начнется "dll-hell" и реализовать пп2 будет еще сложнее

A>>По этому и получаем: либо красивый язык, но включающий все и сразу с определенными ограничениями (принятыми разработчиками исходя из задач языка или иных мотивов) или получаем lisp где в общем-то не сложная и распространенная конструкция list coprehension превращается в доп библиотеку...

M>Так не в один язык надо встраивать, а сделать как в .NET — высокоуровневые языки и низкоуровневые языки.
M>Большую часть кода (80%) писать на высокоуровневом. Ядро (20%) писать на низкоуровневом.

Я почитал статью и мне теперь понятно о чем ты. Ты не просто язык "лучший в мире", ты новую vm задумал, которая порвет аки тузик грелку все .net, erlang и прочие jvm... Красота, но извини, я давно в комунизм не верю. У меня сложилось стойкое ощущение, что то, что сейчас делают эксперты и проектировщики предлагается реализовать в виде некого... хмм... ну в общем рантайма, который разом решает все проблемы. Данный вывод из статьи я сделал фактически на приведенных ниже цитатах (остальное, можно и не читать)

СОП (Семантически Ориентированное Программирование) — новая парадигма, в которой предлагается программировать непосредственно в семантических (смысл, значение) понятиях. Работу программистов часто сравнивают с переводом текста с одного языка на другой. Семантически Ориентированное Программирование можно сравнить с написанием автоматического переводчика с языка на котором удобно формулировать программу на понятный компьютеру язык, и в дальнейшем специалист (может быть далёкий от программирования) сможет писать программу в удобной ему форме, полностью отвечающей предметной области.

СОП не накладывает никаких ограничений на парадигму программирования – можно писать программы и с процедурной, и в функциональной и в логической парадигме. СОП нейтрален по отношению к ним, ведь сама среда разработки оперирует понятиями концепций, семантических значениях. И как программист выберет набор понятий, в которых он пишет программу – в такой и будет написана программа. В этом смысле (функционального ли программирования, процедурного ли) описание набора семантических понятий ничем не отличается от создания специализированного DSL (domain-specific language) языка.

Однако, надо заметить, что отдельно взятая среда разработки программ основанная на СОП не является панацеей. Он позволяет программировать в любой парадигме, создавать новые и добавлять расширения в имеющиеся языки программирования – но не может гарантировать, что созданные программы будут эффективно исполнятся на целевой платформе. Например, реализация ленивых (lazy) вычислений для виртуальной машины Java (JVM) будет крайне неэффективной – чрезмерно требовательной к ресурсам и медленной в исполнении, просто в силу архитектуры JVM. Это одна из причин, по которым полная реализация СОП парадигмы предполагает не только создание среды разработки программ, но и среды исполнения (runtime, VM) основанной на тех-же принципах, гибко настраиваемой под конкретные нужды отдельных программных проектов. Ещё одной причиной желательности создания новой виртуальной среды исполнения программ является необходимость использовать потенциальные преимущества новых аппаратных платформ ближайшего будущего, но об этом чуть позже.

Вот это семантически эквивалентно понятию silver bullet, которого как известно не существует — полная реализация СОП парадигмы предполагает не только создание среды разработки программ, но и среды исполнения (runtime, VM) основанной на тех-же принципах, гибко настраиваемой под конкретные нужды отдельных программных проектов

Вот это вообще фантазии и некий конь. В статье нет ни одной строчки (или я не увидел?) что подразумевается под этими мифическими "понятиями": предлагается программировать непосредственно в семантических (смысл, значение) понятиях

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

Книга { название, аннотация }

[SQLTable: ТаблицаКниг]
class Book {

  [SQLField: индекс, primary key] id : int

  [SQLField: название, not null, 80 chars] title : string

  [SQLField: аннотация, maybe null, long varchar] annotation : long string

  private dirty : bool

 }

Это, извините банальный orm и с проблемами оного можно ознакомиться простым поиском по этому форуму по слову hibernate или даже как более продвинутого собрата LINQ, и сразу станет понятно, что это ни разу не решение _всех_ проблем и думать о том, _как_ именно будет меппиться объект нужно (для серьезных приложений в 1млн строк кода) до начала программирования, а не после.

По этому я допускаю, что ты хорошо разбираешься в vm, ее проблемах (и проблемах jvm в частности), но вот в проблемах больших проектов и проектирования вообще — извини, похоже не очень.