Здравствуйте, WolfHound, Вы писали:
WH>Если ты думаешь что бизнес найдя технологию которая в место 100 человек позволит задействовать 2-3 пусть и болие дорогих хоть секунду будет колебатся перед тем как выкинуть на улицу кучу нахлебников которым нужно платить деньги то поверь мне ты очень сильно заблуждаешься. От сюда вывод что опыт Вирта не дает никаких преймуществ по сравнению с тойже Жабой или C#.
Во-первых, это не выгодно разработчикам сред для программирования. 100 копий VS.NET или BDS или 2-3 есть разница в прибыли??? Во-вторых, чем больше сумма проекта, тем по большому счету всем выгоднее. Для заказчика в IT одтеле это больший вес и большее влияние. Больше з/п в конце концом потому как больше сумма денег, больше ответственность, ... В нашей среде это откаты Для исполнителей те же принципы К тому же уволить 100 сотрудников это большой гемор. И т. д. и т. п. Тут я не раздедяю эту точку зрения
Здравствуйте, Mystic, Вы писали:
M>Во-первых, это не выгодно разработчикам сред для программирования. 100 копий VS.NET или BDS или 2-3 есть разница в прибыли???
А кого это волнует кроме разработчиков сред программирования? M>Во-вторых, чем больше сумма проекта, тем по большому счету всем выгоднее.
А как сумма проекта зависит от колличества программистов? M>Для заказчика в IT одтеле это больший вес и большее влияние. Больше з/п в конце концом потому как больше сумма денег, больше ответственность, ... В нашей среде это откаты
И какое отношение это имеет к колличеству программистов? M>Для исполнителей те же принципы К тому же уволить 100 сотрудников это большой гемор. И т. д. и т. п.
Если мастодонт не уволит сотню нахлебников то его порвет стартап который наймет 2-3 человека и за счет меньших издержек предложит большие откаты... M>Тут я не раздедяю эту точку зрения
Это твое право.
Это с точки зрения бизнеса.
А теперь с точки зрения программирования: посмотри на C# и на Oberon и скажи в чем преймущества Oberon'а перед C#?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А теперь с точки зрения программирования: посмотри на C# и на Oberon и скажи в чем преймущества Oberon'а перед C#?
В такой постановке этот вопрос напоминает: "посмотри на арбуз и свинной хрящик и скажи, в чем преимущества арбуза перед свинным хрящиком?".
Может стоит детализировать этот вопрос предметными областями? Например:
-- в Web-программировании;
-- в разработке (к примеру) офисного пакета;
-- в разработке системы управления движением транспорта в метрополитене;
-- в разработке встроенного ПО для промышленного робота;
-- в разработке ПО для математических расчетов.
То, что 90% программистов работают над мейнстримовыми задачами и пользуются мейнстримовыми технологиями совершенно не значит, что все остальное отстой, пережитки прошлого или старческий маразм пожилого гения. Мне рассказывали о вариантах Unix-а для специализированных компьютеров, на которых не было ничего, кроме C и чудом портированного туда Python-а. И люди работали там нормально, не испытывая никаких комплексов и даже уходить не хотели не смотря на разные выгодные предложения. Вполне могу себе представить системы, где нет ничего, кроме Oberon-а. И задачи, которые решаются на этих системах. Это свой рынок. Со своими законами. И кто-то там работает и, думаю, чувствует себя вполне нормально.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>То, что 90% программистов работают над мейнстримовыми задачами и пользуются мейнстримовыми технологиями совершенно не значит, что все остальное отстой, пережитки прошлого или старческий маразм пожилого гения.
Демагогия не пройдет. Реч шла именно о мейнстриме так что не надо уводить разговор в сторону. E>Мне рассказывали о вариантах Unix-а для специализированных компьютеров, на которых не было ничего, кроме C и чудом портированного туда Python-а. И люди работали там нормально, не испытывая никаких комплексов и даже уходить не хотели не смотря на разные выгодные предложения. E>Вполне могу себе представить системы, где нет ничего, кроме Oberon-а. И задачи, которые решаются на этих системах. Это свой рынок. Со своими законами. И кто-то там работает и, думаю, чувствует себя вполне нормально.
Это их проблемы. И к данному разговору это отношения не имеет. Вирт думает что Оберон панацея для мейнстима но он не понимает что Оберон по сравнению с Жабой или с C# ничего не дает.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
E>>То, что 90% программистов работают над мейнстримовыми задачами и пользуются мейнстримовыми технологиями совершенно не значит, что все остальное отстой, пережитки прошлого или старческий маразм пожилого гения. WH>Демагогия не пройдет. Реч шла именно о мейнстриме так что не надо уводить разговор в сторону.
Извини, значит я не понял. Меня вот что смутило:
Индустрия рубит бабло. И индустрии наплевать на все что не помогает рубить бабло.
Разработка встроенных и промышленных систем -- это то же индустрия. Не так уж сильно использующая достижения софтверного мейнстрима, насколько мне известно.
WH>Вирт думает что Оберон панацея для мейнстима но он не понимает что Оберон по сравнению с Жабой или с C# ничего не дает.
В статье Вирта я утверждения о том, что Оберон является панацей для мейнстрима не видел.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>Демагогия не пройдет. Реч шла именно о мейнстриме так что не надо уводить разговор в сторону.
Извини за назойливость, но мне действительно интересно, считаешь ли ты, что C# однозначно имеет преимущества перед Oberon во всех перечисленных мной областях?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Извини за назойливость, но мне действительно интересно, считаешь ли ты, что C# однозначно имеет преимущества перед Oberon во всех перечисленных мной областях?
С точки зрения языка оберон и C# 1.1 примерно равны. Но если сравнивать с C#2 то тут Оберон проигрывает в чистую. E>-- в Web-программировании;
C# рулит. ASP.NET, ADO.NET и еще куча библиотек не достапных оберону. Также у .NET рантайм гораздо богаче. Плюс мощьные срездства разработки которые тоже очень облегчают работу. E>-- в разработке (к примеру) офисного пакета;
C# рулит. Таже фигня что и ВЕБом. E>-- в разработке системы управления движением транспорта в метрополитене;
И тут у C# опять за счет средств разработки и большой библиотеки гораздо лучше. E>-- в разработке встроенного ПО для промышленного робота;
Опять таки никаких преймуществ у оберона я тут не вижу. Особенно если в этого робота воткнуть что-то типа Singularity. E>-- в разработке ПО для математических расчетов.
Тут и Оберон и C# пока что с треском сольют Intel C++ compiller'у. Но если МС для .NET делает оптимизатор который с большой вероятностью таки догонит а то и перегонит интеловский компилятор то разработчики оберона уверены что оптимизитор им не нужет ибо на оберн-ос нет тормозной аппаратной защиты и там все работает быстро . Причем когда МС доведет до промышленного состояния Singularity там не будет тормозной аппаратной защиты и в отличии от оберон-ос с безопасностью тоже все в порядке ибо прагматики из МС в отличии от романтиков из ETH понимают что сейчас существует огромное колличество людей которые спят и видят как бы стащить чужую информации или обрушить чужой сервер.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
E>>-- в Web-программировании; WH>C# рулит. ASP.NET, ADO.NET и еще куча библиотек не достапных оберону. Также у .NET рантайм гораздо богаче. Плюс мощьные срездства разработки которые тоже очень облегчают работу.
+1
E>>-- в разработке (к примеру) офисного пакета; WH>C# рулит. Таже фигня что и ВЕБом.
+1
E>>-- в разработке системы управления движением транспорта в метрополитене; WH>И тут у C# опять за счет средств разработки и большой библиотеки гораздо лучше.
+-
Имхо, в таких задачах средства разработки и библиотеки большой роли не играют. Здесь большее значение приобретает простота и предсказуемость языка, среды исполнения.
А так же наличие инструментов для тех платформ на которых будет работать эта система.
E>>-- в разработке встроенного ПО для промышленного робота; WH>Опять таки никаких преймуществ у оберона я тут не вижу. Особенно если в этого робота воткнуть что-то типа Singularity.
-1
См. предыдущий пункт. Singularity в промышленной эксплуатации нет. Oberon есть. Уже одно это выводит C# из рассмотрения, если на целевой платформы нельзя запустить Windows или, хотя бы, Mono. Но и тогда придется решать вопросы со сборкой мусора, например.
E>>-- в разработке ПО для математических расчетов. WH>Тут и Оберон и C# пока что с треском сольют Intel C++ compiller'у.
-1
Дело не в скорости самой программы, а в том, насколько удобнее будет программитам-математикам писать программу на этих языках. Делать расчеты на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++ и рулил, сам сталкивался).
Ну и опять же, когда MS доведет Singularity... Они пока Longhorn довести не могут
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > Дело не в скорости самой программы, а в том, насколько удобнее будет > программитам-математикам писать программу на этих языках. Делать расчеты > на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++ > и рулил, сам сталкивался).
Проще всего делать рассчеты на Фортране. Да и получается быстрее всего.
Здравствуйте, WolfHound, Вы писали:
WH>С точки зрения языка оберон и C# 1.1 примерно равны. Но если сравнивать с C#2 то тут Оберон проигрывает в чистую.
Ага, щаз...
Сравним C#2 и C#1:
Что добавили:
1) Генерики — синтаксический сахар над copy/paste.
2) Так называемые "анонимные методы" — есть просто синтаксический сахар над вложенными процедурами. (Вложенные процедуры еще в паскале были)
3) Автотипы — чистейший синтаксический сахар.
Что так и осталось по прежнему:
1) Struct как нельзя было расширять (наследовать) — так и осталось нельзя. (В Обероне value типы — расширяемы)
2) Массивы как были ссылочными — так и остались ссылочными. (В Обероне массивы — value типы)
3) Модулей как не было — так и не появилось (class library можно только загружать, но нельзя выгружать, т.е. class library — не модули).
Итог
Добавили только сахар. Принципиальных изменений вносить не стали.
Здравствуйте, eao197, Вы писали:
E>>>-- в разработке системы управления движением транспорта в метрополитене; WH>>И тут у C# опять за счет средств разработки и большой библиотеки гораздо лучше. E>+- E>Имхо, в таких задачах средства разработки и библиотеки большой роли не играют.
Не согласен. E>Здесь большее значение приобретает простота и предсказуемость языка, среды исполнения.
А что у C# с этим какието проблемы? E>А так же наличие инструментов для тех платформ на которых будет работать эта система.
А на каких платформах это будет работать?
В любом случае если мне понадобится надежность любой ценой то я возьму функциональный язык.
E>См. предыдущий пункт. Singularity в промышленной эксплуатации нет. Oberon есть. Уже одно это выводит C# из рассмотрения, если на целевой платформы нельзя запустить Windows или, хотя бы, Mono. Но и тогда придется решать вопросы со сборкой мусора, например.
В любом случае оберон выдет из расмотреня еще раньше ибо это академическая поделка.
Опять же смотри више там где нужна надежность использовать имеперативные языки глупость.
E>Дело не в скорости самой программы, а в том, насколько удобнее будет программитам-математикам писать программу на этих языках. Делать расчеты на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++ и рулил, сам сталкивался).
Это шутка да? Я не могу себе представить ситуации где бы Оберон по сравнению с С++ рулил в расчетах. Может ты мне продемонстрируешь это?
E>Ну и опять же, когда MS доведет Singularity... Они пока Longhorn довести не могут
Этим занимаются какбы совсем разные подразделения МС...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Проще всего делать рассчеты на Фортране. Да и получается быстрее всего.
Да бог его знает. Я расчетами занимался в университете, поскольку специализировался на кафедре Вычислительной Математики и Программирования.
Так у меня сложилось впечатление, что Фортран берет большим количеством готовых библиотек, а скорость берется из-за его низкоуровневости.
Но преподаватели говорили, что удобнее всего для вычислений им использовать как раз Паскаль -- алгоритмы на нем гораздо проще делать, чем на Фортране, а по скорости не сильно уступают. А наличие встренных масивов с контролем выхода за диапазоны, строгая типизация и пр. просто на порядки повышает комфортность программирования (по сравнению с C).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > C>Проще всего делать рассчеты на Фортране. Да и получается быстрее всего. > Да бог его знает. Я расчетами занимался в университете, поскольку > специализировался на кафедре Вычислительной Математики и Программирования. > Так у меня сложилось впечатление, что Фортран берет большим количеством > готовых библиотек, а скорость берется из-за его низкоуровневости.
Ну да, оптимизаторы для Фортрана — пожалуй самые лучшие. Это же простой
язык, без рекурсии (точнее она есть, но в новых версиях Фортрана, а
поэтому не всегда используется).
> Но преподаватели говорили, что удобнее всего для вычислений им > использовать как раз Паскаль -- алгоритмы на нем гораздо проще делать, > чем на Фортране, а по скорости не сильно уступают. А наличие встренных > масивов с контролем выхода за диапазоны, строгая типизация и пр. просто > на порядки повышает комфортность программирования (по сравнению с C).
А у вас математики что-то знают, кроме Паскаля? Я удивлен.
Здравствуйте, WolfHound, Вы писали:
WH>Это шутка да? Я не могу себе представить ситуации где бы Оберон по сравнению с С++ рулил в расчетах. Может ты мне продемонстрируешь это?
Легко.
Ткачёв думаете просто так что ли перешёл на Оберон/Компонентный-Паскаль?
Оберон в версии CP и BlackBox выбран в качестве инструментария для всех проектов на основе ~25-летнего опыта использования в данном направлении самых разных подходов и анализа ошибок.
Фишка в том, что алгоритм расчёта может быть чрезвычайно сложен.
Правильно реализовать чрезвычайно сложный алгоритм на языке C++ гораздо сложнее чем на Oberon/Component Pascal, которые имеют сборщик мусора.
Доктор физико-математических наук Фёдор Васильевич Ткачёв приводит следующий пример.
Он в BlackBox на Component Pascal реализовал алгоритм за 3 месяца.
Его конкурент решал ту же самую задачу на С++ 3 года.
В результате, программа Ткачёва на Component Pascal оказалась в 8 раз быстрее программы на С++ и работала правильно, в то время как программа на С++ работала нестабильно, падала, страдала утечками памяти и т.п. Обвинить конкурента в криворукости нельзя — он действительно классно знает С++. Просто алгоритмы очень сложные — надо интенсивно работать с гигабайтными динамическими структурами.
Здравствуйте, WolfHound, Вы писали:
E>>Здесь большее значение приобретает простота и предсказуемость языка, среды исполнения. WH>А что у C# с этим какието проблемы?
Моменты наступления сборки мусора априори предсказуемы или об этом нужно вручную заботится?
Помнится, здесь была большая тема про сборку мусора в real-time системах. И приводилась ссылка на компанию, которая продавала программно-аппаратный комплекс, разработанный на основе Oberon.
E>>А так же наличие инструментов для тех платформ на которых будет работать эта система. WH>А на каких платформах это будет работать?
Например, на QNX, VxWorks, LynxOS, OS-9, или любой другой из этих.
WH>В любом случае если мне понадобится надежность любой ценой то я возьму функциональный язык.
Опять же, если он будет в наличии.
WH>Опять же смотри више там где нужна надежность использовать имеперативные языки глупость.
Глупость -- может быть. Но большое количество критически важного софта пишется именно на императивных языках. На том же C, в частности.
WH>Это шутка да? Я не могу себе представить ситуации где бы Оберон по сравнению с С++ рулил в расчетах. Может ты мне продемонстрируешь это?
Оговорюсь, не по скорости, а по удобству для программистов-математиков. А где -- например, при расчете надежности ленточных фундаментов методом конечных элементов, при расчете распределения температуры на лопастях турбин методом граничных элементов, при расчетах надежности конструкций методом конечных разностей, при реализации расчетов оптимизации чего-нибудь различными вариантами методов оптимизации (того же симплекс метода, к примеру). Поскольку я специализировался на кафедре Вычислительной Математики и Программирования, могу утверждать, что математики предпочитали пользоваться Паскалем, а не C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Сергей Губанов wrote: > Что добавили: > 1) Генерики — синтаксический сахар над copy/paste.
Бред. Генерики никоим образом не являются заменой cut&paste, а заменой
явных приведений типов. Но Оберону это пофиг — в нем есть одна
генерик-коллекция (массив), которой они гордятся.
> 2) Так называемые "анонимные методы" — есть просто синтаксический сахар > над вложенными процедурами. (Вложенные процедуры еще в паскале были)
Неверно. Анонимные методы являются синтаксическим сахаром методами +
делегатами.
> 3) Автотипы — чистейший синтаксический сахар.
Но их нет в Обероне.
> Что так и осталось по прежнему: > 1) Struct как нельзя было расширять (наследовать) — так и осталось > нельзя. (В Обероне value типы — расширяемы)
А вот это как раз с помощью сахара делается:
struct base
{
int a,b,c;
};
struct child
{
base _base;
int d,e,f;
};
> 3) Модулей как не было — так и не появилось (class library можно только > загружать, но нельзя выгружать, т.е. class library — не модули).
Для модулей собираются добавить GC. То есть неиспользуемые сборки будут
просто прибиваться сборщиком мусора. В отличие от явной выгрузки, это
вполне безопасно (а в Java уже лет 5 код классов собирается GC).
Здравствуйте, WolfHound, Вы писали:
E>>Дело не в скорости самой программы, а в том, насколько удобнее будет программитам-математикам писать программу на этих языках. Делать расчеты на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++ и рулил, сам сталкивался).
Пробовали ли вы закодировать простейшее выражение с комплексными числами на голом C?
WH>Это шутка да? Я не могу себе представить ситуации где бы Оберон по сравнению с С++ рулил в расчетах. Может ты мне продемонстрируешь это?
Я не знаю, что такое Оберон, но однозначно могу сказать, что на комплексных числах Фортран кроет С++ по скорости. И иначе быть не может, поскольку комплексные числа — это встроенный тип в Фортране и оптимизатор все про них знает. А в C++ это некий класс, просто класс. Класс как класс и всех делов. Возможно, что и с Паскалями-Оберонами нечто похожее.
E>>Ну и опять же, когда MS доведет Singularity... Они пока Longhorn довести не могут WH>Этим занимаются какбы совсем разные подразделения МС...
А нам-то что от этого? MS он и есть MS. Еще не хватало вникать в организацию ихней структуры.
Помню во времена NT-4 было много визга про супер-систему под кодовым названием "Cairo", которую потом похерили и вместо нее выпустили полуфабрикат Chicago. Занимались разные подразделения...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, little_alex, Вы писали:
_>Кстати в обероне можно вернуть указатель на локальную функцию?
Нет конечно. Точно так же как нельзя вернуть адрес любой локальной сущности.
Вложенная процедура живет в контексте процедуры её вызвавшей и имеет доступ к её локальным переменным. Поэтому снаружи её вызывать нельзя. Раз нельзя, то и указатель на неё получить нельзя.
Хотя на пятом курсе как-то специально сделал все лабы по спецкурсу по методам принятия решений (или методам оптимизации, не помню точно) на Turbo Pascale-е, поскольку расчеты действительно было проще на Паскале делать.
Что сейчас -- даже не представляю. Вероятно, большинству пришлось от Паскаля отказаться.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Для исполнителей те же принципы 
. Причем когда МС доведет до промышленного состояния Singularity там не будет тормозной аппаратной защиты и в отличии от оберон-ос с безопасностью тоже все в порядке ибо прагматики из МС в отличии от романтиков из ETH понимают что сейчас существует огромное колличество людей которые спят и видят как бы стащить чужую информации или обрушить чужой сервер.
