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

GZ>1) Должен быть компонентным. Надеюсь компонент не надо сравнивать с классом?

+1

GZ>2) Должно быть наследование классов. Если нет наследования, то общественность это не поймет. Даже не рассуждая наследование плохо или хорошо, общественное мнение главнее.

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

GZ>3) Должен поддерживать все основные фичи процесса построения приложений. То есть, как минимум обладать большинством фич UML. И не противоречить ему.(RUP-подобные постановки еще главенствуют и я думаю будут продолжать главенствовать).

Что акое фичи UML и в чем должна выражаться их поддержка?

GZ>Все остальное, типа mixin и т.д. — всего лишь конфетки, которые скрашивают нашу жизнь, но не определяют общую линию партии. В общем, бизнес — есть бизнес.

Зря ты так думаешь. Эти конфетки в совокупности способны повысить качество конечных решений и скорость их разработки. А это очень важно.

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

M>Ты меня совсем не понял , я говорил ИМЕННО про язык который бы облегчал создане архитектуры приложения , который бы брал на себя рутинные обязанности по подгонке друг к другу отдельных программных компонент.

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

M>Как бы отдалял нас от проблем связанных с реализацией , и наоборот приближал и формулировал создание архитектур. Некий язык работающий с МЕТА информацией.

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

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

E>Почему? Из-за одной его супер-мега-фичи: возможность передавать в функцию блок кода в качестве параметра.

Лямбда-функции? Так они и в Питоне тож есть.

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

AVK>>Ну и? Какие из них, по твоему, идентичны?
GZ>Дело в том, что фич в документообороте немного(они просто большие по объему).

AVK>>Я бы так не сказал. Одно количество и качество поддержки форматов документов многого стоит.
Нет. Это не бухгалтерские системы. Для систем документооборота неважно то что в документе и его расширение. Важны реквизиты документа, наложенные резолюции, их юридическая значимость, пути прохождения документа, его учет. А показ осуществляется операционной системой и офисом, который является стандартом де факто.

GZ> А вот поставщиков до фигищи.
Да тоже не дофига (если не считать конечно тех, кто лепит такие системы на базе покупной платформы). Основная масса решений пользует какой нибудь документум или лотус.
Не-а. Года два назад, треть рынка была у eos(система Дело). Сейчас не слежу, потому и не скажу точно. Но существует куча более мелких поставщиков. И многие на полностью своих системах.

С уважением, Gleb.

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

VD>Ну, и если один из продуктов работает быстрее, то ему явно светит более широкий рынок.
VD>Так тут то он скорее прав.

Нет. Только кажется правым...
Потому как, по моим наблюдениями, быстродействие зависит
в первую очередь — от архитектуры системы,
во вторую — от алгоритма,
и уже в третью — от языка реализации...

И очень часто хорошую архитектуру на "быстрых" языках делать неподьемно долго и дорого.
в результате — делается что попроще. выигрываются разы, проигрываются порядки.

Дазумеется, если реализовывать один и тот же алгорим и одну архитектуру...
... но это просто глупость архитектора.

VD>Что нельзя сказать про общий смысл его высказывания.

Угую Про общий смысл — вообще молчу.

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

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

Все равно ты не о том говоришь

На примере , как в директ икс подключаются необходимые для декодирования фильтры , так могли бы взаимодействовать между собой компоненты. Но для этого нужет язык МЕТА описания компонентов.


Напрмиер подключая веб сервис мы получаем его описание в терминах языка (напрмиер C#) , а следующим шагом было бы получение МЕТА описания , которое служит языком для языка ( для компа).

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

GZ>>2) Должно быть наследование классов. Если нет наследования, то общественность это не поймет. Даже не рассуждая наследование плохо или хорошо, общественное мнение главнее.

AVK>Совершенно необязательно. Например лично я считаю, что от классического наследования больше вреда, нежели пользы. Наследование интерфейсов + миксины архитектурно значительно лучше (меньше связность, больше гибкость).
эээ. Ты это скажи маркетологам. Я не зря упомянул общественное мнение. У VB был хреновый имидж именно из-за отсутсвия наследования.

GZ>>3) Должен поддерживать все основные фичи процесса построения приложений. То есть, как минимум обладать большинством фич UML. И не противоречить ему.(RUP-подобные постановки еще главенствуют и я думаю будут продолжать главенствовать).

AVK>Что акое фичи UML и в чем должна выражаться их поддержка?
Будем говорить так. Язык должен поддерживать диаграммы физического уровня. Message, объекты и т.д. Функциональные языки под эту категорию не попадают.

GZ>>Все остальное, типа mixin и т.д. — всего лишь конфетки, которые скрашивают нашу жизнь, но не определяют общую линию партии. В общем, бизнес — есть бизнес.
AVK>Зря ты так думаешь. Эти конфетки в совокупности способны повысить качество конечных решений и скорость их разработки. А это очень важно.
Для тебя да(хотя я не уверен в вышесказанных тобою словах). Но язык — это товар. Его нужно продавать и продавливать на рынке. Сколько программистов знает что такое mixin? А что такое наследование — знают все. Если бы все знали что это такое, я думаю, он бы появился еще в первой версии С#.

С уважением, Gleb.

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

AVK>Лямбда-функции? Так они и в Питоне тож есть.

В питоне лямбды несколько "недоделанные" — в них можно только простейшие действия выполнять. То есть, например

>>> a = lambda x: x*x
>>> a(5)
25

можно, а

>>> b = lambda x: if x>0 : x*x
File "<stdin>", line 1
b = lambda x: if x>0 : x*x
^
SyntaxError: invalid syntax

уже нельзя.

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

AVK>>>Я бы так не сказал. Одно количество и качество поддержки форматов документов многого стоит.
GZ>Нет. Это не бухгалтерские системы.

А при чем тут бухгалтерские системы?

GZ> Для систем документооборота неважно то что в документе и его расширение.

Да ну? А поиск как будешь по ним делать или кроссдокументные ссылки?

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

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

Если они столь же примитивные по функционалу, то да. Только вот далеко не любой компонент можно низвести до уровня фильтра.

M>Но для этого нужет язык МЕТА описания компонентов.

Для чего конкретно? Если для описания взаимодействия фильтров, то я тебе такой язык на коленке за полчаса сляпаю.

M>Напрмиер подключая веб сервис мы получаем его описание в терминах языка (напрмиер C#) , а следующим шагом было бы получение МЕТА описания , которое служит языком для языка ( для компа).

WSDL что ли? Так оно уже есть. Indigo вводит еще семантические ограничения.

Здравствуйте, Павел Кузнецов, Вы писали:

>> 4) Должен быть поддержан большой корпорацией. Пользователи языка должны быть уверены, что язык не умрет и не будет оставаться академическим опытом.
ПК>Как следует из опыта, поддержка корпорацией вовсе не означает, что язык не умрет. Свежий пример -- VB, имевший большую базу пользователей, и убитый большой корпорацией.
Ну во первых он не умер, а развился в VB.NET. В данном случае больше подходит аналогия с MC++.

>> Наследование опасно в неумелых руках, но в умелых оно спасает <...>

ПК>В умелых его стараются заменять менее сильными связями.
У меня практически всегда описание предметной области имеет наследование. И что в этом плохого? Филды родителя все инкапсулированы, меняется только поведение. Предметная область меняется редко.

С уважением, Gleb.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>В умелых его стараются заменять менее сильными связями.
И вообще, отсутсвие наследования хорошо компенсируется копи-пастным программирование. Это показал VB. Что лучше?

С уважением, Gleb.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>1. вообще говоря, ни тот ни другой язык не были "совершенно новыми": и до Фортрана были попытки создать язык высокого уровня; и до С++ существовали объектно-ориентированные языки.

Зверёк, а не стоит ли попытаться определить, что такое "совершенно новые". Я позволю себе заметить, что в некотором смысле Java и C# не есть нечто совершенно новое по сравнению с Фортраном. Да-да, как ни странно это звучит. Потому что декомпозиция задачи и построение алгоритма делается примерно одним и тем же способом, а то, что в одном случае есть классы и т.д, а в другом нет — это особенности реализации, а не идеи. Домучила же Микрософт свой любимый Бейсик до того, что в нем классы появились. Захотела бы — и в Фортране классы появились бы, и даже Fortran.Net соорудили бы — нет здесь никаких принципиальных препятствий.

ЗХ>- до Фортрана считалось, что любой язык высокого уровня будет порождать слишком неэффективный код; поэтому одной из главных задач команды Фортрана было создание эффективного компилятора

Ну не знаю. ИМХО основной задачей при создании Фортрана было упростить разработку программ по сравнению с машинными кодами. Об эффективности потом заговорили. Но это ИМХО.

ЗХ>- до С++ считалось, что ОО языки — академическая игрушка, не позволяющая писать эффективные программы; одной из главных задач Страуструпа было порождение эффективного кода.

Опять-таки не уверен. По-моему, основной задачей было как-то структурировать код, создать некие более крупные объекты, функциональность которых можно потом модифицировать (virtual)и которые те самым можно повторно использовать. А эффективность просто следовала из эффективности С — там почти что ничего не изменилось.

ЗХ>Т.е. и в том и в другом "прорыве" действовала модель "взять уже известные (но все же новаторские) идеи, и создать их эффективную реализацию". Я довольно сильно упрощаю, но общая тенденция, кажется, такова.

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

А вообще, чтобы что-то новое принципиально изобрести, надо быть не отягощенным знанием старого. По известной формулировке Эйнштейна "Все знаю, что это сделать нельзя, но наконец появляется один, который этого не знает. Он и делает открытие"

ЗХ>В современных условиях прорыв такого типа представляется маловероятным, т.к. "железо больше не ресурс": для новых языков программирования вопрос зверской эффективности уже не является определяющим фактом популярности.

На эту тему я как-нибудь поподробнее выскажусь. Мне этот тезис не кажется верным.

ЗХ>Еще одним существенным фактором мне представляется накопляемая в индустрии инерция типа "я могу принять новую парадигму, если она приложится к моему любимому языку" (всякие там AspectXXX, да и R# наверное, это достаточно ярко демонстрируют).

Угу. Меня только что побили в форуме по .Net, когда я попытался там задать ряд вопросов, ответ на которые в C++ банален.

>Тут нужно заметить, что и для С++ важным фактором была совместимость с С (что некоторые и полагают главной ошибкой ), но чем дальше, тем сложнее языки; попытка сделать язык с одной стороны совершенно новый, с другой стороны совместимый со "старым", столкнется со слишком большими идеологическими ограничениями, накладываемыми "старым". (Отсюда можно сделать вывод, что новые парадигмы могут стать не развитиемм старых, а "уходом в другую сторону").

Нет, не согласен. C#, что бы там его адепты не говорили, есть несколько модифицированный C++. И именно поэтому у меня возникли проблемы с перенесением привычных понятий в Шарп. А вот если дадите мне принципиально новый язык и убедите, что им заниматься стоит — я отрину все, что я знаю, вспомню себя в молодости и начну его изучать, как будто я ничего не знаю.

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

AVK>Да ну? А поиск как будешь по ним делать или кроссдокументные ссылки?
Для полнотекстового поиска используются библиотеки другого производителя. Не сам же будешь реализовывать морфологический поиск. К тому-же это сейчас можно сделать и на уровне БД(если файлы лежат в нем). Кроссдокументные ссылки это что? Есть связанные документы, то есть дополнения к приказу, на основании приказа. А что такое кроссдокументная ссылка?

С уважением, Gleb.

IMHO: next breakthrough — полноценное визуальное программирование.

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

AVK>>Совершенно необязательно. Например лично я считаю, что от классического наследования больше вреда, нежели пользы. Наследование интерфейсов + миксины архитектурно значительно лучше (меньше связность, больше гибкость).
GZ>эээ. Ты это скажи маркетологам. Я не зря упомянул общественное мнение. У VB был хреновый имидж именно из-за отсутсвия наследования.

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

AVK>>Что акое фичи UML и в чем должна выражаться их поддержка?
GZ>Будем говорить так. Язык должен поддерживать диаграммы физического уровня.

Язык? Все равно не понял о чем ты.

GZ> Message, объекты и т.д. Функциональные языки под эту категорию не попадают.

UML никак не является обязательным фактором. Вон МС без каких либо проблем в VS 2005 от него отказалась. Думаешь что теперь новая студия не будет пользоваться успехом?

AVK>>Зря ты так думаешь. Эти конфетки в совокупности способны повысить качество конечных решений и скорость их разработки. А это очень важно.
GZ>Для тебя да(хотя я не уверен в вышесказанных тобою словах). Но язык — это товар. Его нужно продавать и продавливать на рынке.

И все таки на этот рынок сильно влияет мнение потребителей. Вон МС сколько веб-сервисы не проталкивает, а широкого использования все как то не видать.

GZ> Сколько программистов знает что такое mixin?

А сколько программистов знают что такое yield, generic constraint? Если концепция полезна, то программисты с ней разберуться, тем более с такой простой как миксин.

GZ> А что такое наследование — знают все.

Когда ОО языки появлялись знали далеко не все. И это не помешало этим языкам приобрести популярность.

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

AVK>Забивать никто не предлагал. Но любой софт это компромисс между функционалом, непрожорливостью и стабильностью. Тенденция в том, что золотая середина начинает смещаться от непрожорливости в сторону двух других.
Если рынок имеет очень высокую конкуренцию, то эти понятия все важны. И выделять их нельзя. Правда еще важно — имидж продукта и количество и качество клиентов, качество поддержки и еще куча всего. Забыть о чем-то — это проиграть.

С уважением, Gleb.

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

PD>Нет, не согласен. C#, что бы там его адепты не говорили, есть несколько модифицированный C++. И именно поэтому у меня возникли проблемы с перенесением привычных понятий в Шарп. А вот если дадите мне принципиально новый язык и убедите, что им заниматься стоит — я отрину все, что я знаю, вспомню себя в молодости и начну его изучать, как будто я ничего не знаю.

Забавный ты человек. Тебе говорят, что C# это совсем не C++, что окромя синтаксиса, между ними мало общего. Ты не веришь, набиваешь себе шишки, но при этом продолжаешь гнуть старое.

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

AVK>WSDL что ли? Так оно уже есть. Indigo вводит еще семантические ограничения.


Да , WSDL это именно шаг в сторону которую я описывал , но современные языки зная WSDL описанеи , не построят связей между компонентами. Это описание скорее для юзера , кторы йбудет потом работать с классом сгенерированным WSDL.

Я же говорю про описание компонента , которое сможет ПОНИМАТЬ ( оперировать) сам язык или его управляющая оболочка.

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

E>>Почему? Из-за одной его супер-мега-фичи: возможность передавать в функцию блок кода в качестве параметра.

AVK>Лямбда-функции? Так они и в Питоне тож есть.

Нет, лямбда по сравнению с Ruby блоками гораздо слабее, как мне показалось при поверхносном знакомстве с Python.

Ну и может быть кто-то из знающих Python товарищей скажет, как в Python сделать такую конструкцию:

sources_root( "impl" ) {
    cpp_source "a.cpp"
    cpp_source "b.cpp"
    
    sources_root( "win32" ) {
        cpp_source "c.cpp"
    }
    
    sources_root( "posix" ) {
        cpp_source "d.cpp"
    }
}

где в фигурных скобках -- блоки кода. А sources_root и cpp_source -- это методы объекта, в контексте которого должны работать блоки кода.