Microsoft и спам

Автор темы Гастрит 
30.03.2005 17:18
мне?
А я сказал, что мне что-то не нравится?
По правде сказать, это я сниму шляпу, если Вы за год хоть на Javе, хоть на чем захотите, сумеете... ;-) Хотя не об этом речь.
А круг применимости Java и C# вполне адекватно обозначен в других сообщениях этой ветки, я с этим и не спорю. Кстати, по поводу "универсальной пушки" - в кои-то века в чем-то соглашусь с Гастритом. :-) Если же сравнивать эти два языка между собой (поскольку область применения у них одна), C# кажется поприятнее как язык, но абсолютно непереносим (в смысле непортируем), потому менее интересен с практической точки зрения.
30.03.2005 17:30
ответ
Цитата

Гастрит писал(а) :
Речь у меня шла, вообще-то, не об ООП как таковом, а о "дополнении" его концепциями языков низкого уровня (результатом чего и являются C++, Java etc.). Не получается ли при этом ситуация с универсальной пушкой?

Ну Java вполне себе высокоуровневый язык.
Не такой, конечно, радикальный как Smalltalk, Self или Cecil,
но ведь любой язык --- компромисс. И никак он не универсальная
пушка, а если уж продолжать пушечную аналогию, --- дивизионка,
типа ЗИС-3. Относительно простой язык, годящийся для написания
основной массы приложений.

Цитата

1) Интересно, каков с Вашей точки зрения этот набор?
2) Почему обязательно Haskell?

Кстати, я правильно понимаю, что некоторые текстовые редакторы (как и куски некоторых стрелялок) сваяны на LISP?

Ну Haskell достаточно изящный и мощный из современных языков.
Если хотите, возьмите ML, он менее мощен и содержит
много процедурных конструкций. Код можно написать на нем
поприличнее, но зато Вы не очень удалитесь в своих решениях от,
скажем, С - стиля.

Что касается набора подходящих для FP задач, то я не возмусь
сейчас составить исчерпывающий список, однако многие задачи
типа символьных вычислений, перевода (в широком смысле слова),
перебора решаются в функциональном стиле очень изящно и
естественно ( и как следствие, понятно и красиво)

LISP отнюдь не функциональный язык. Скорее, это процедурный
язык класса Java, cо своеобразным синтаксисом, позволяющий писать
в функциональном стиле. И к тому же это целое семейство
языков, есть scheme --- простенький язык, кстати, относительно
более функциональный, чем остальные лиспы, а есть, извините,
Common Lisp, по навороченности и сложности далеко затмевающий
C++. При таком подходе надо С, С++ и Java в одно семейство
относить.

Про стрелялки на LISP не в курсе, а emacs, которым я активно
пользуюсь, более чем на половину написан на e-lisp.
В AutoCAD тоже сидит LISP система, там, правда, еще много чего есть.

Цитата

А сколько, то бишь, страниц содержат описания C++/Java/C#? wink

Я точно померить не могу, у меня бумажные копии стандартов,
а нумерация страниц в них отдельная по главам, но
C++ примерно 700 страниц, Java около 300.
Вот для C# есть файл, в нем 403 страницы.

А Вот в Common Lisp (причем, без описания MOP) 1200 страниц,
ML --- около 400. Scheme -- около 70, но попробуйте на ней
писать и, еще важнее, читать !
Стандартных описаний других "функциональных" языков у меня нет.

На мой взгляд, радикального отличия нет.
30.03.2005 17:51
и еще пара слов о языках
Удобство решения какой-либо задачи в каком-либо языке программирования -- это, очевидно, не только красота и удобство самого языка, в настоящее время это, наверное, прежде всего удобство подключения модулей, созданных другими разработчиками, плюс, собственно, наличие этих модулей. То, что в C об этом позаботились с самого начала, стало одной из причин, позволивших этому языку выиграть в прошлом веке, и предопределяет то, что этот язык и его производные останутся ведущими в веке нынешнем, несмотря на общеизвестные недостатки.... как и то, что пиков популярности чего-то принципиально отличающегося, видимо, не ожидается.

Цитата

Кстати, я правильно понимаю, что некоторые текстовые редакторы (как и куски некоторых стрелялок) сваяны на LISP?

Насчет "некоторых" - не могу сказать. Я знаю один такой текстовый редактор (клоны не в счет) и (знал - сейчас уже позабыл название) одну такую стрелялку.
То и другое было написано на волне популярности LISPа, которая как будто спАла...

Само по себе использование встроенных скриптовых языков в таких приложениях стало стандартом, другое дело, что LISP для этого, по-видимому, не лучший выбор.

Цитата

А сколько, то бишь, страниц содержат описания C++/Java/C#? wink

Не так много. Описания библиотек большие, но это вряд ли можно считать недостатком.

30.03.2005 17:52
Допвопрос
Цитата

Игорь Абрамов писал(а) :
Ну Haskell достаточно изящный и мощный из современных языков.
Если хотите, возьмите ML, он менее мощен и содержит
много процедурных конструкций. Код можно написать на нем
поприличнее, но зато Вы не очень удалитесь в своих решениях от,
скажем, С - стиля.

Лично я хочу рефал! Дадите? wink

Цитата

Что касается набора подходящих для FP задач, то я не возмусь
сейчас составить исчерпывающий список, однако многие задачи
типа символьных вычислений, перевода (в широком смысле слова),
перебора решаются в функциональном стиле очень изящно и
естественно ( и как следствие, понятно и красиво)

Что с точки зрения экспериментальной математики далеко не "специальная область".

Цитата

а есть, извините,
Common Lisp, по навороченности и сложности далеко затмевающий
C++.

Извиняю, ибо, поистине, любую идею можно опошлить бесконечными "усовершенствованиями" cry Другое дело, что Common Lisp - это именно извращение; а вот возможно ли в принципе нечто типа C++ ужать до нескольких страничек без потери основной функциональности - ещё вопрос.

С уважением,
Гастрит

30.03.2005 18:07
да, думаю, вполне поместится
Цитата

а вот возможно ли в принципе нечто типа C++ ужать до нескольких страничек без потери основной функциональности - ещё вопрос.

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

С тем, что универсальные языки программирования не нужны, не соглашусь; соглашусь с тем, что не стоит писать на них все подряд. :-)
30.03.2005 18:12
Интересно было бы посмотреть
Цитата

e-Past писал(а) :
С тем, что универсальные языки программирования не нужны, не соглашусь; соглашусь с тем, что не стоит писать на них все подряд. :-)

Минуточку - так именно об этом и шла речь! Если вообще выкинуть низкоуровневые языки - на чём, к примеру, те же высокоуровневые реализовывать (другие примеры указывал Игорь Абрамов)?

С уважением,
Гастрит

30.03.2005 18:22
пжалста
Цитата

Гастрит писал(а) :
Лично я хочу рефал! Дадите? wink

Сколько угодно !
http://shade.msu.ru/refal.msu.ru/dloadr.html

Только вот язычок оччень специфический, я, пожалуй, не
уверен, он функциональный, или это надо рассматривать
как нечто отдельностоящее ?

Впрочем, писать на нем текстовый редактор, я никому не
пожелаю.

Цитата

Что с точки зрения экспериментальной математики далеко не "специальная область".
Ну так ведь сама по себе экспериментальная математика
вещь довольно специальная. Здесь, собственно, и РЕФАЛ
и даже навороченная LISP-система довольно полезны.

Но ! Вы разрабатываете по сути не программный продукт,
и даже не проект,
а проводите вычисления на эдаком суперкалькуляторе.
Это в точности то, на что РЕФАЛ и еще куча всего рассчитаны.
Пользуйтесь на здоровье. Только? если начнете подрабатывать
программированием, не пишите на РЕФАЛЕ рассчет зарплаты :),
это может оказаться вредно для Вашего здоровья.

Цитата

а вот возможно ли в принципе нечто типа C++ ужать до нескольких страничек без потери основной функциональности - ещё вопрос.
Содержательное описание всех возможностей (без библиотеки)
можно, наверное, страниц на 30-40 сделать. Только читать
этот текст может оказаться сложнее чем толстую книгу.

Представтье тот же эксперимент с учебником матанализа.
Тоже, по сути, описание языка.
30.03.2005 18:28
кстати
Году этак в 86 мне попала в руки статья Страуструпа про C++,
в ней было страниц 40, причем не очень плотной верстки,
и все тогдашние возможности были там описаны, причем не так
уж и сжато. Правда, тогда я ничего в этой статье не понял :)

Статья была в чем-то типа Bell Labs Technical Journal.
30.03.2005 18:29
да ни для какого языка такой код не подходит
Цитата

Если посмотреть на навороченный CAD, то там мы найдем безумное
количество кода посвященного пользовательскому интерфейсу,
преобразованию данных, общей, так сказать, высокоуровневой,
логике приложения, сопряжению с базами данных и т.д.
Весь такой код хорошо подходит для языка
вроде Java или C#.

Списочек тот еще получился...
По поводу пользовательского интерфейса - да, потому что его до нас затащили во встроенные объекты, только за веревочку дернуть осталось.
Большая часть кода программ, которые что-то делают, на самом деле не делает ничего - это перекладывание данных с места на место, перевод из одного формата в другой. Ни на каком языке просто и эффективно такое не делается, если операция не является настолько тривиальной, что входит в стандартную библиотеку. Любой CAD обрабатывает большое количество данных в собственных форматах - со всеми вытекающими. :-(
И не только в языках тут дело, скорее даже в ОС, API которых с доисторических времен делается не так, как надо, а так, как проще реализовать.
30.03.2005 18:34
дохлый страус
Цитата

Году этак в 86 мне попала в руки статья Страуструпа про C++,
в ней было страниц 40, причем не очень плотной верстки,
и все тогдашние возможности были там описаны, причем не так
уж и сжато. Правда, тогда я ничего в этой статье не понял :)

Кажется, все его творчество обладает таким свойством (я не про размер, про понимание).. :-)
30.03.2005 18:45
Спасиба! :)
Цитата

Игорь Абрамов писал(а) :
Сколько угодно !
http://shade.msu.ru/refal.msu.ru/dloadr.html

Нууу, это-то и у меня есть cry Кстати, и рефал-плюс (местный аналог Common Lisp'а wink) у Вас несколько несвеж...

Цитата

Только вот язычок оччень специфический, я, пожалуй, не
уверен, он функциональный, или это надо рассматривать
как нечто отдельностоящее ?

Функциональный на 150%.

Цитата

Впрочем, писать на нем текстовый редактор, я никому не
пожелаю.

А в чём, кстати, причина такого пессимизма (я плохо представляю технику написания текстовых редакторов)?

Цитата

Только? если начнете подрабатывать
программированием, не пишите на РЕФАЛЕ рассчет зарплаты :),
это может оказаться вредно для Вашего здоровья.

А какие именно моменты могут оному повредить? Не очертите ли примерный объём работ?

Цитата

Представтье тот же эксперимент с учебником матанализа.
Тоже, по сути, описание языка.

Ну, да. Но только если есть возможность сказать, что производная многочлена определяется индуктивно по порядку оного, а элемент C^1 - это результат пополнения многочленов по некоторой тривиально выписываемой норме - зачем пережёвывать резину про "поточечно заданные функции, для которых в каждой точке существует предел отношения etc."? Языки ведь бывают разной степени удобства (и адекватности описываемым явлениям)!

С уважением,
Гастрит

30.03.2005 19:05
да
Цитата

Минуточку - так именно об этом и шла речь! Если вообще выкинуть низкоуровневые языки - на чём, к примеру, те же высокоуровневые реализовывать (другие примеры указывал Игорь Абрамов)?

Естественно. "Не соглашусь" я на всякий случай написал, т.к. в некоторых сообщениях все же сквозят идеи панацеи ("вы не сможете написать на Refal текстовый редактор и т.п.") - или я чего-то не понял? :-)

Насчет "интересно посмотреть" - ну, Игорь Абрамов уже как раз описал, как это выглядит. :-)
30.03.2005 19:08
приходите еще
Цитата

Гастрит писал(а) :
Цитата

Впрочем, писать на нем текстовый редактор, я никому не
пожелаю.

А в чём, кстати, причина такого пессимизма (я плохо представляю технику написания текстовых редакторов)?

Собственно, техника там тупая, программа сидит в цикле,
ждущем события с устройства ввода, затем проводит изменения
в тексте или параметрах вывода и соответсвующим образом изменяет
изображение на экране. В более навороченных вариантах есть
несколько объектов, которые должны таким же образом реагировать
на поступающие события.
Простенький редактор такого рода легко пишется процедурно,
более сложный лучше писать в объектном стиле.

Но на РЕФАЛЕ это, по моему, пишется слишком криво.
Читаемость будет на уровне ассемблерного кода,
полученного из под транслятора.

Цитата

А какие именно моменты могут оному повредить? Не очертите ли примерный объём работ?
Объем работ:
Пользовательский интерфейс куда более изощренный, тут
РЕФАЛу совсем кранты.
Какая-никакая базка данных, хотя можно, конечно и текстовыми
файлами с контрольными суммами обойтись, или
SQL на лету строить и таблицы подхвативать.
Несколько видов ведомостей и отчетов. Не так уж и сложно,
но довольно муторно.
Собственно правила расчета, это, кстати, более менее
на РЕФАЛе пишется, хотя как будет выглядеть собрание,
пары сотен правил, и можно ли его будет по-нормальному
читать и понимать я пока не могу себе представить.

30.03.2005 19:50
всенепременно зайдём!
Цитата

Игорь Абрамов писал(а) :

Собственно, техника там тупая, программа сидит в цикле,
ждущем события с устройства ввода, затем проводит изменения
в тексте или параметрах вывода и соответсвующим образом изменяет
изображение на экране.

Коротко говоря:

редактор {
= <редактор <ввод>>;
e.1 = <изменения_в_тексте e.1> <редактор <ввод>>;
}

Пойдёт Вам такой цикл?


Цитата

Объем работ:
Пользовательский интерфейс куда более изощренный, тут
РЕФАЛу совсем кранты.
Какая-никакая базка данных,

И что? Я, например, на рефале экзаменационные билеты печатаю. Программа - в одной таблице, разбивка по билетам - в другой, некоторые вспомогательные данные - в третьей. Чем Ваш случай хуже?

Цитата

Собственно правила расчета, это, кстати, более менее
на РЕФАЛе пишется, хотя как будет выглядеть собрание,
пары сотен правил, и можно ли его будет по-нормальному
читать и понимать я пока не могу себе представить.

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

С уважением,
Гастрит

30.03.2005 19:57
жирновато...
Цитата

e-Past писал(а) :
Естественно. "Не соглашусь" я на всякий случай написал, т.к. в некоторых сообщениях все же сквозят идеи панацеи ("вы не сможете написать на Refal текстовый редактор и т.п.") - или я чего-то не понял? :-)

1) Цитированная Вами фраза - не моя.
2) Мне как раз кажется, что текстовый редактор на рефале напишется. А вот ядро ОС - вряд ли (по меньшей мере, под нынешние архитектуры). После ТАКОГО эксперимента C# и Java покажутся эталонами скорости biggrin

Цитата

Насчет "интересно посмотреть" - ну, Игорь Абрамов уже как раз описал, как это выглядит. :-)

Всё равно плоховато зипанулось smile

С уважением,
Гастрит

31.03.2005 02:44
а еще суровая реальность
Цитата

Игорь Абрамов писал(а) :
Я может не очень понимаю, что Вы имеет ввиду под действительно
тяжелым приложением, но некоторые вполне типичные представители
CAD удобнее писать на интерпретируемых языках. Да они так
и сделаны.
Какие вы имеете в виду? Вот, например, МCAD систем всего ничего:
Pro/Engineer, Catia, UG (SolidEdge), AutoCAD и SolidWorks.
Больше нет. Вернее, есть либо доморощенные, т.е. не на продажу, либо не системы biggrin Вот их я считаю действительно тяжелыми приложениями. Ни одна из них не написана, или переписанана, на Java. Даже Solidworks, относительно новая и самая "легкая" из всех, и та на С++.


Цитата

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

Весь такой код хорошо подходит для языка
вроде Java или C#.
Сижу, смотрю... Вы не правы. UI и т.д. кода много, но это не безумное количество. К тому же, в CAD системах очень важно быстродействие, а на Java UI будет существенно медленее и памяти будет жрать больше. Да и структуры данных на Jave в таких системах держать - извращение. Память будет съедаться - никаких ресурсов не хватит. У нас даже memory manager свой, под наши нужды оптимизированый ибо то, что OS предлагает - медленнее. А если еще на garbage collector пологаться....
А "высокоуровневую логику" все-равно на чем писать, на Java или C++, только при наличии грамотной framework, на C++ быстрее работать будет.
Про C# я и не говорю. Кастомеры на unix-ах тоже хотят работать (linux в их число не входит).

Кстати, один из неудачных примеров UI на Java - сановский дебагер SunStudio. Просто java оболочка вокруг dbx + netbeans редактор + немного удобств. Прекрасно работает с программами не сильно сложнее "Hello World". А вот когда начинаешь что-то серьезное дебагить, UI тормозит страшно. В результате все перешли на старый workshop'овский UI поверх нового dbx по совету представителей Сана, которые на жалобы о тормознутости нового UI отвечали "you know, you're unique company"...

31.03.2005 12:42
и снова консерватизм
Причем, иногда он вполне здоровый.

Я же НЕ призываю всех немедленно бросить старинные
исходники на С, Фортране, а то АДЕ с ПЛ/1 или
срочно начинать перписывать их.

Повторю в более развернутой форме свои тезисы.
1) В 90%> кода большинства программ к производительности
требования весьма умеренные. Дело в том, что хорошо если
эти 90% потребляют 10% времени работы в критические моменты,
т.е. тогда, когда приходится ждать приложение.

2) Для этих 90% вполне допустимо поступиться 50% производительности
в обмен на большую надежность, удобство разработки и сопровождения. (В худшем случае мы потеряем 5%, на деле,
от повышения уровня языка и облегчения переработки программ
зачастую происходит выигрыш в алгоритмической части,
смотрите классическую историю системы Multics)

3) Большинство этих систем если уж не построено на основе, то
содержит в качестве языка расширения нечто интерпретируемое и зачастую специализированное. В AutoCADe это во-первых, AutoLISP,
во-вторых, мне припоминаются какие-то следы их собственного
язычка программирования в тех исходниках, которые я видел.
[Должен оговориться, целиком изнутри я не видел ни одной из
перечисленных Вами систем САПР]. В Catia, к которой я лет 15
назад приделывал некий модуль был тоже свой язык. Он напоминал
тогдашний IBM REXX, впрочем, может, он и им и был.

4) У реальных пользователей САПР, с которыми я имел дело,
(ABB, Alpha Laval, Philips, Fuji, AGFA --- машиностроительный,
DEC, Intel --- радиоэлектронный) САПР по существу свой,
в него в качестве составляющих компонент включены
стандартные инструменты, но все это принтегрировано
и расширено своим кодом. А этот код, извините, иногда
составляет под миллион строк иногда на Visual Basic :))).
Производительность системы в целом у
них, кстати никогда не была проблемой.

5) Java в целом вполне созрела для такого рода вещей. С оговорками,
естественно. Много мелких компонент, как Вы привели в качестве примера, видимо, нерационально в нее толкать.
В качестве положительного примера хорошего инструментального
средства на Java рекомендую IBM Eclipse.

6) C# язык интересный и перспективный. Но пока он только
Windows, надо или ограничиваться этой платформой, или
ждать пока Mono не окрепнет. (10 лет назад с Java была
похожая история, тогда не было возможности нормальный
межплатформенный GUI на ней сделать). И некие новые проекты
я сейчас видимо на нем буду начинать. Тем более, что
VS 2005 для C# вроде как не хуже Eclipse для Java, по крайней
мере, на первый взгляд.
Извините, только зарегистрированные пользователи могут публиковать сообщения в этом форуме.

Кликните здесь, чтобы войти