А не плохо получилось и весит мало , надо качнуть попробовать. P.S Pascal Rulez!!!!

Рулез то он может и рулез, но без С под Linux'ом никак.

Кому в здравом уме нужен Паскаль? Зачем?

Наверное тому, кто С не знает :)

Pascal разумный и логически понятный язык в отличии от C.

Да и для обучения и решения начальных мат. задач (дифф.ур-я, интегралы и прочая) Паскаль подходит лучше всего( ну кроме Фортрана) :)

А если есть возможность ипользовать ГУИ и все это будет не иак тормозно как Дельфи/Каликс - то это вообще хороошо!

Молчать, ламеры!

C и Pascal - абсолютно тождественные языки. Всякий, разводящий вонь про разницу между ними - конченный ламер и подлежит транклюкации.

2Antichrist (*) (2002-10-13 18:13:45.449)
только ламер может нести такую хрень. C - асемблер со слабой типизацией, Pascal - язык со строгой типизацией. Это два разных полюса в програмерском мире. Я был о тебе лучшего мнения.

2 Antichrist: если можно, просвещай последнего анонима без матов:)

такие посты вроде предыдущего надо в разделе анекдотов публиковать

Это у Паскаля - строгая типизация? Различия в семантике системы типов Си и Паскаля минимальны (особенно если учесть C99). То, что в Паскале нет неявного преобразования типов - это ещё не строгость. Ведь остались же указатели, осталось явное преобразование типов. Кроме того - нет ни в том, ни в другом действительно формализуемой и чистой системы типов.

Так что - на одном они полюсе, на одном. Чуть подальше от них - Ада. А на совсем другом полюсе - типизированные по Хиндли-Миллнеру языки.

В общем - всем курить Луку Карделли.

ЗЫ: вот, ссылочки... Для общего развития...

http://ontil.ihep.su/~vsl/TypefulProg.A4.pdf

http://ontil.ihep.su/~vsl/TypeSystems.A4.pdf

Оно же:

\bibitem{cardelliprog} Luca Cardelli. Typeful Programming.\\
E. J. Neuhold and M. Paul, Editors. Formal Description of Programming
Concepts, IFIP State of the Art Reports Series. Springer--Verlag,
February 1989.


\bibitem{cardelli} Luca Cardelli. Type Systems. \\
Allen B. Turcker (Ed.): The Computer Science and Engeneering Handbook.
CRC Press, 1997. Chapter 103, pp. 2208--2236.

И то, чего в електронном виде нет:


\bibitem{Milner:78} Milner, R. (1978). A theory of type polymorphism in
programming. Journal of Computer and Systems Sciences, 17, 348-375.



Достаточно полная подборка ссылок на классику (Черч, Рассел, и т.д.) в
библиографии к лекциям Харрисона:

http://www.cl.cam.ac.uk/Teaching/Lectures/funprog-jrh-1996/index.html

Приана, Антихрист, дай ананимусу в глаз! А если по существу. Где-то год назад попробовал Лазурус. Глчный, падучий, но... лиха беда начало. Правильный проект. Вот только пробовать сейчас не буду. Неинтересно уже. Всегда был приверженцем паскаля, но теперь на JAVA подсел. Это просто мечта программера!!!
ЗЫ. Вот сейчас в меня жидкий стул полетит! :))))
ЗЫЫ. Бога нет! :)))
ЗЫЫЫ. Пекемоны - отстой, Телепузики - круто!

Кажется, сейчас будет литься кровь человека, произнесшего "J"-word...

Сравните скорость компиляции ObjectPascal (через FPC или dcc) и C++.

2 delta9 (*) (2002-10-13 12:32:04.955)

> Да и для обучения и решения начальных мат. задач (дифф.ур-я, интегралы и

> прочая)

Не смештите людей - никто не считает на Pascal что-то более сложное чем

\int_0^1 dx :)

Для этого используются либо C/C++ (BLAS,GiNaC,...) и то, что на нем написано

(FORM,Mathematica,Maple,...), либо LISP (Reduce,Maxima,...).

Что касается Fortran, то это не язык, а какой-то кошмар. А его высокая

производительность в вычислениях - это сказки. А если еще и плохой

компиллятор (g77) - так вообще C'-шная программа работает быстрее на ~30%

Проверял на счете интергалов от функций вида

\int_0^b dx e^{-\alpha x} f(x)

где f(x) - рациональная функция без особенностей в области интегрирования,

b>=5 \alpha ( по идее, там несобственный интеграл до бесконечности)

Единственное, где Fortran работает быстрее (~25-50%) - это на Aplha и с родным

компиллятором.

Неспроста cernlib'-ы переписали на C++ (имеется в виду ROOT).

А для аналитических вычислений ничего лучше C++ и LISP на

данный момент нет [хотя сам я не пользуюсь LISP]

Что касается обучения, то уж лучше учить Python или Java.

P.S.

Все сказанное не следует воспринимать в духе "Pascal must die". Есть такой

язык, кто-то им пользуется, кому-то он нравится - пускай себе живет и

развивается. BTW, первым языком, который я выучил, был именно Pascal.

Но то, что он чуть ли не верх совершенства - мягко говоря, не совсем верно.

Объясните мне, тупому, нахера нужна строгая типизация? Я ж ВСЁ РАВНО байтами или машинными словами даже в голове оперирую!

Добрый день

Про кошмар, который фортран - ты это нашей системе сбора данных скажи, которая на этом самом кошмаре написана :)

Со стороны кошмар, но как работает, как работает (вообщем работает) :)

С уважением Евгений

P.S. Каждый пишет на том к чему привык и если ты не программист, то к этой деятельности нужно относиться с отвращением, чтобы на основную деятельность больше времени оставалось :)

Ну, то, что ты тупой - ты сам признал. Поздравляю - при всей тупости ты оказался способен на чрезвычайно объективную оценку.

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

Фортран - это не кошмар. Если это Fortran90 или hpf. И не надо тут про сказки - тот же Intel Fortran советую попробовать, если уж нет под рукой Альфы с DEC FORTRAN-ом. Сразу ясно станет, кто оптимизирует, а кто - хуи пинает.

Ну а ROOT - до сих пор запредельно убогая и тормозная система. В реальных экспериментах не применяется - только чтоб свистелки-перделки для отчётности нарисовать. Нагрузку он совершенно не держит. Такой вот сраный C++.

И ещё - BLAS и LAPACK - это Fortran. На C++ переписывать - смысла нет.

Для аналитических вычислений (кстати, Mathematica не на C писана - на C писан только рантайм ейного языка, всё остальное - уже на нём) C++ не канает абсолютно. Lisp - с натяжкой. Нужны языки хоть с какой типизацией, и, главное, pattern matching-ом (для реализации правил и стратегий). То есть, та же Mathematica (как язык), ML, Haskell.

Надо не только скорость сравнивать, но и качество. Тот же C++ c -O0 тоже шустро компилит. Ну и всё равно шустрее всех OCaml - он не делает оптимизаций на низком уровне.

Правильно, полетит. Java - динамически типизированный язык, а это - по определению суксь.

Как-то про KDE писали (линк я, наверно, не найду), что он так тормозит потому, что программа на С++ принципиально тормозит.

А почему - суксь? И где лежит это определение (урл)? Мне-то, убогому, казалось, что именно это - рулез. Можно типы связывать в последний момент... Кстати, а smalltalk в этом вопросе разве не так же себя вел?

Суксь в том, что имеет непредсказуемое поведение, требует немалого оверхеда на поддержку, и не допускает вразумительных статических проверок на этапе компиляции. То есть, сколь бы строгой динамическая система типов не была, а безопасности, надёжности кода она не повысит. В отличии от статических систем. Короче, я тут для чего ссылки на Карделли дал? Чтоб их курили, или чтоб мне вопросы глупые задавали?

Не пойму - зачем флеймить?

Никто ж на С не нападает! И тем более на С++

Только сравните время, которое потребуется на написание программы на языке, делающем ставку на динамическую систему (и Ява, и СиПлюсПлюс, по-моему, нужно отнести к этим языкам) со временем написания той же программы на "статическом языке", который ругается сразы же при компилляции.

Для небольших проектов, в которых оптимизация по времени не является принципиальной, такие языки как Фортран, Паскаль будут жить. Не пересадите вы массы математиков и физиков, которые многое считают на Фортране (и Паскале, кстати, тоже) на С, на котором из серьезных мат библиотек если разве что сконвертированные с того же Fортрана (тот же ЛАПАК).

Roman

<Можно типы связывать в последний момент... Кстати, а smalltalk в этом вопросе разве не так же себя вел?>
Блин, любой, кто писал на smalltalk, скажет, что смоллточная динамическая типизация, и особенно его правила связывания (с динамическим проходом по dag классов вверх, пока не найден метод) -- кошмар для программиста, и недетский оверхэд. Меня от нетипизированных языков до сих пор колбасит...

В smalltalk-овский кошмар я верю. Соббсно, даже и ожидал чего-то подобного. Но ведь жаба-то сущесвенно строже - там есть достаточно жесткая система типов. Кстати, иногда даже слишком жесткая.

2Antichrist: Полистал я этого мужика. Так он признает, что динамическая типизация - неизбежная часть любого языка. Вопрос в приоритетах - нужно свести ее использование к минимуму. Так в жабе обычно так и живут (ну, может, можно было минимизировать сильнее). А наличие java.ref.* весьма приближает жабу к идеям этого теоретика. Конечно, до полного их осуществления дело не доходит - но ведь язык-то расчитан на практическое применение, не на академические игрушки. Короче, жабский компромисс - совсем не так плох даже с точки зрения вышеуказанных работ.

Ну так надо внимательнее читать - в формальных системах типов вся "динамическая" часть сводится к полиморфизму (e.g. как в ML). Естественно, этот подход не вредит строгости статических проверок и допускает крайне эффективные реализации.

А про практическое применение - та же идиотская Жаба куда как сложнее в применении, чем языки с type inferrence (который для динамической типизации и вовсе невозможен).

2 Antichrist:

> Фортран - это не кошмар. Если это Fortran90

Ну да, кто-то воспринимает передачу параметров/возвращение значения через

COMMON-блоки как нечто абсолютно нормальное. А по-моему, это бред собачий.

> И ещё - BLAS и LAPACK - это Fortran. На C++ переписывать - смысла нет.

Sorry, не BLAS, а blitz++. А LAPACK - это не только FORTRAN.

А смысла переписывать BLAS, наверное, нет [по причине наличия blitz++]

> Ну а ROOT - до сих пор запредельно убогая и тормозная система. В реальных

> экспериментах не применяется - только чтоб свистелки-перделки для отчётности

> нарисовать. Нагрузку он совершенно не держит. Такой вот сраный C++.

Шатаясь по таким форумам, узнаешь много нового о своей лаборатории и установках :)

Все нормально используется, только его собрать желательно с -O3

-march=<target_arch>

> Для аналитических вычислений (кстати, Mathematica не на C писана - на C

> писан только рантайм ейного языка, всё остальное - уже на нём) C++ не канает абсолютно.

Еще и как "канает", см. http://www.ginac.de

А про Mathematica - наверное, она от того и тормозит ТАК (например, по

сравнению с Maple), бедолага, что черти-на-чем написана.

2 Roman: > Не пересадите вы массы математиков и физиков, которые многое считают на

> Фортране (и Паскале, кстати, тоже) на С, на котором из серьезных мат

> библиотек если разве что сконвертированные с того же Fортрана (тот же

> ЛАПАК).

Меня и пересаживать не надо - сам пересел и облегченно вздохнул,

что FORTRAN и Mathematica - это уже в прошлом. А библиотек в C++ хватает, например

Для численных вычислений:

libcln (Class Library for Numbers), http://www.ginac.de/CLN

blitz++ (~LAPACK), http://oonumeric.org/blitz

Для аналитический вычислений:

GiNaC ( GiNaC Is Not A CAS), http://www.ginac.de

> Только сравните время, которое потребуется на написание программы на языке,

> делающем ставку на динамическую систему (и Ява, и СиПлюсПлюс, по-моему,

> нужно отнести к этим языкам) со временем написания той же программы на

>"статическом языке", который ругается сразы же при компилляции.

Да ничего он (g77) не ругается, а программа делает segfault :(

Или параметры в функцию не передаются, хотя делаю все, как в руководстве

написано. А вот g++ замучает своими warning'-ами...

По поводу RTTI: никто Вас не заставляет применять ее, кроме того, посмотрите,

что сам автор пишет по этому поводу.

О времени написания. Замечательно программу на FORTRAN'-е писать в коллективе.

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

не передаются параметры. Нет уж, к черту.

Ну, это Вы, допустим, слегка приврамши. Кроме полиморфизма, в тех текстах есть еще как минимум сериализация (во всех ее формах - от файлов до БД и служб директорий). Там полиморфизм почти бессмыслен (ну что толку от java.io.Serializable?). И тут никаких проверок не сделаете при компиляции, сударь.

А про сложность применения - Вы меня действительно удивили. Жаба - один из самых простых (и легких для надежного программирования) языков. Особенно - если не злоупотреблять java.ref.*. Впрочем, есть беда с коллекциями - это как-то плохо продумано. Впрочем, обещают параметризованные типы - должно полегчать. Если не заломает - можно привести пример более простого и сильно распространенного языка? И простота Жабы не в последнюю очередь объяеняется именно тем, что в ней основной акцент - статическая типизация. Но с возможностью динамической (без которой можно прожить в 80% случаев, а если будут парам. типы - так и в 95%). Как доктор Лука и прописал.

Програмисты делятся на две категории - на тех кого Жаба давит, и на тех кого Жаба не давит. :)

Про оверхеад Жабы надо не расказывать, а показывать - мол записать java.lang.NullPointerException в лог стоит столько-то, а записать core C-шной проги на диск - столько-то.

А Вы себя к каким причисляете?

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

<Sorry, не BLAS, а blitz++.>
Да, blitz++ действительно рулит. Но -- исключительно с нормальным компилятором типа KAI, g++ по моему опыту затыкается на таком коде.

<она от того и тормозит ТАК (например, по сравнению с Maple), бедолага, что черти-на-чем написана. >
Maple написана точно так же. C-шный рантайм языка и некоторые базовые операции для "символьных вычислений", а большая часть -- на maple-овом языке.

<libcln (Class Library for Numbers), http://www.ginac.de/CLN >
libcln -- довольно так себе, к тому же под gpl. LEDA на порядок круче, такого real как там, нет больше нигде.

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

> Шатаясь по таким форумам, узнаешь много нового о своей > лаборатории и установках :)

Подробнее? ROOT на онлайне используется? Какой поток данных (мб/сек) после триггеров второго уровня? Если в оффлайне - то мне не интересно, тут производительности особой не надо.

> Все нормально используется, только его собрать желательно с -O3

Нужно ли объяснять, какой член своего тела CINT кладёт на все эти -O?

Про GiNaC - напомнить расшифровку названия? Или и так всё ясно? Вообще же, меня даже те куцие возможности, что в нём есть, ни разу не впечатлили. Пожалуй, из писанных на Си специализированных CAS-ов можно разве что CompHEP помянуть как достойный пример. Правда, были даже целиком на Фортране писанные CAS-ы общего назначения (уровня Macsym-ы). Сам видел. Был в шоке. Но это было очень давно.

Про статическую типизацию - тут уже не за фортраны всякие базар, и не за Паскали. Так что не надо про g77 - смотреть на ML надыть.

И, кстати, Mathematica не тормозит - этот язык весьма неплохо в рантайме компилируется. Maxima, кстати, тоже вовсе не чистый Лисп, у ней свой rule-based язык. А, как я уже гойворил, rule-based лучше всего на языках с Хиндли-Миллнером получается.

Да, и ещё за BLAS - советую на Atlas посмотреть. Более шустрой C++-ной реализации в природе нет.

Напугал ежа голой попой. За сериализацию - смотреть на модуль Marshal в OCaml. Где тут нужна динамическая типизация, ась?

Жаба - сложный язык. Простейшие вещи в ней реализуются весьма идиотскими путями, допускающими огромное количество возможностей обшибиться. Именно благодаря чистой императивности, динамической системе типов и полному отсутствию возможностей метапрограммирования - даже от препроцессора отказались, идиоты, даже такого примитива, как сиплюсплюсные шаблоны нет. И это - удобный язык для RAD?!?

Да, статической типизации в Жабе нет. Только динамическая.

За примером строгого, простого, статически типизированного (с type inference) языка - смотреть на ML. Ссылку на Харрисона я тут уже давал, там в конце примеры. Особо поучительно выглядят парсеры на комбинаторах, реализация простого алгоритма унификации и простой proof assistant. Аналогичный код на Жабе занял бы на пару порядков больше места, и вряд ли был бы хоть немного читабельным.

2 Antichrist:

> Про GiNaC - напомнить расшифровку названия? Или и так всё ясно? Вообще же,

> меня даже те куцие возможности, что в нём есть, ни разу не впечатлили.

Там есть почти все, что надо, и ничего лишнего, для той задачи, под которую

его писали, т.е. для многопетлевых вычислений в КХД. А производительность

на 2 порядка выше, чем у Mathematica+FeynCalc(хотя в нем только в одной петле

считать можно), Maple+xloops, и в 2-3 раза выше, чем у FORM. Именно благодаря

простоте его простоте.

BTW, если у GiNaC "куцые" возможности, то что ж Вы тогда про FORM скажете?

К тому же, многие задачи можно посчитать только на GiNaC, т.к. всяческие CAS

просто валятся в корку либо жалобно пищат, что не хватает памяти.

> И, кстати, Mathematica не тормозит - этот язык весьма неплохо в рантайме

> компилируется.

Вам показать пример, который я руками быстрее посчитал, чем на Mathematica?

(машина: Tyan Thunder K7, 2 Athlon MP 1.2 GHz, 1 Gb DDR SDRAM,18 GB Ultra160 SCSI, Debian GNU/Linux 3.0)

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

Вот когда будут машины с 10000 Gb DDR SDRAM и Athlon 500GHz, тогда на ней

что-то считать можно будет. Но все равно, на FORM'-е или GiNaC'-е можно

считать гораздо более сложные вещи.

2 AC:

> Да, blitz++ действительно рулит. Но -- исключительно с нормальным

> компилятором типа KAI, g++ по моему опыту затыкается на таком коде.

Нет, не затыкается он. Просто надо всегда собирать с -O3 и подбирать

-finline-limit

> libcln -- довольно так себе, к тому же под gpl.

А что, это разве плохо, что она под GPL?

<Просто надо всегда собирать с -O3 и подбирать -finline-limit >
Ну, я конечно такой тупой. GCC (3.2 не пробовал) _не_умеет_ нормально оптимизировать "инлайнинг" в шаблонах, и _не_умеет_ оптимизировать через границы инлайн-функций. KAI делает GCC _минимум_ процентов на 40 на таком коде. По опыту ежедневного юзания blitz, mtl и boost.graph.

<А что, это разве плохо, что она под GPL? >
Конечно плохо. На ней нельзя делать проекты с прицелом на "коммерческую" реализацию.

На marshal/ocaml и ml посмотрю. Вот только расскажите - много ли их применяют в промышленном программировании? Объем кода на них и на жабе сравните. Из языков _такой_распространенности_ жаба - самый простой. Или такая формулировка Вас тоже не устраивает? Как критерий распространенности можно погулять по sourceforge и пальцами проекты посчитать. Да, критерий тот еще - можете предложить лучше...

Про препроцессор - тут, как я понимаю, есть идеологические причины (так они понимают ОО:) Про шаблоны - я уже упоминал, будут параметризованные типы скоро.

А для RAD - удобный язык. Даже слишком:). Прямо воротит, когда видишь, как из Жабы Вижуал Васик делают...

Статической типизации нет? Т.е. компилятор типы не проверяет совсем? Это новость...

Поставленные задачи, возможно, на Жабе реализуются из рук вон. Но как часто из приходится решать? Каждый день? А нечитабельный жабский код я в своей жизни видел только у очень плохих кодеров. Если человек хоть немного думает о том, что пишет - код обычно читается. Хотя, наверное, за 6 лет работы на жабе (в проектах разных размеров) я мало кода видел... Посмотрите на код, лежащий на jakarta.apache.org. Посмотрите на жабские реализации scheme/python. Читается с листа.

http://sourceforge.net/softwaremap/trove_list.php?form_cat=160

Java - 6636, ML - 89. Конечно, это говорит об элитарности ML и бОльшем интеллекте владеющих им. Говорит ли это о простоте... Возможно, эти 89 проектов решают именно те задачи, где жаба отдыхает. Хотя я там все больше вижу байндинги к разным Сишным либам...

Кстати, С - 9056 и С++ - 8400. Т.е. порядок тот же. Хотя то, что Java - сильно проще С(++), доказывать тут, наверное, не нужно...

Как-то удивительно мало Паскаля (195). Среди лидеров также ПХП (5021) и Перл (3883). Даже противный PL/SQL вдохновил 582 проекта. Да, интересная статистика. Хотя она представляет только то, что представляет.

Да, посмотрел я на доки по ml. Да, многие типы, введенные в жабе как библиотека, в ml стали частью языка. В этом он где-то напомнил мне perl (не надо мне про разницу, я ее и сам вижу). И проверка всего этого "щасться" при компиляции - действительно является синтаксической (в жабе это уже в области семантики). Предлагаю посмотреть на это дело таким путем. Да, человек делает ошибки. И чем больше мы их выловим при компиляции - тем лучше. Из этого исходит лука, от этого пляшут авторы ml. Но есть и другой критерий - сложность синтаксиса. perl, ml и пр. вводят в синтаксис чуть ли не всю клавиатуру (вроде, перл уже достиг). И человеку весьма непросто удержать весь этот syntax sugar в голове. В результате он пользуется только тем, что запомнил. Да, жаба многословна. Но синтаксических конструкций, мне кажется, там существенно меньше, чем в ml (в т.ч. и за счет меньшего количества базовых типов). И они существенно проще (ИМХО). Короче, имеем конфликт - способность человека делать ошибки против неспособности запомнить перегруженный синтакс. Как обычно, в этом конфликте для каждого - своя точка оптимума. Для большинства, как мне кажется, Java ближе к решению. Хотя всегда будут и те, кто захочет платить за богатство и сложность ml/perl. Вопрос только в статистике...

KAI vs g++ и еще кое-что

2AC:

> Ну, я конечно такой тупой. GCC (3.2 не пробовал) _не_умеет_ нормально

> оптимизировать "инлайнинг" в шаблонах, и _не_умеет_ оптимизировать через

> границы инлайн-функций.

Почему же тупой? Просто не все хорошо у g++ - при одном -finline-limit работает

медленно, при другом -- вообще не собирается, при третьем - работает нормально,

причем зависимость совершенно какая-то дикая. И подобрать нужное значение не

совсем просто, хотя никакого ума тут не надо.

> KAI делает GCC _минимум_ процентов на 40 на таком коде.

KAI стоит денег, и очень не маленьких [если, например покупать лицензию

на сеть из ~10 машин]. А учитывая то, КАК начальство (причем не только

наше "родное", но и "забугорное"!!) вообще относится к

тому, что за софт надо ПЛАТИТЬ... Если б выигрыш был >=4 -- 5 раз, то еще

можно было бы уговорить, а так...

Не буду же я всей лабе покупать все за свои деньги?

> <А что, это разве плохо, что она под GPL? >

> Конечно плохо. На ней нельзя делать проекты с прицелом на "коммерческую" реализацию.

Ну, если так, то, конечно, плохо. Халявы не бывает :)

2 Antichrist:

> Естественно, как язык - фортран - бред собачий.

Совершенно согласен! IMHO, на asm'-е проще писать.

> Но - некоторые его свойства, к сожалению, практически не присутсвующие в

> других языках (высокоуровневые конструкции для отображения простых

> математических сучностей) позволяют писать крайне эффективные компиляторы.

А подробнее можно? Какие такого рода конструкции есть в FORTRAN, но нет в C/C++?

> Это - и только это - делает его на данный момент лучшим выбором для по

> крайней мере внутренних циклов числодробильных задач. В такой формулировке годицца? Я бы сказал - НЕКОТОРЫХ числодробильных задач при соответствующем выборе

компиллятора. Ну, а в целом, -- медицинский факт, как говорится.

FFT 20011 точек на FORTRAN раза в полтора быстрее, чем на C++. Если бы

еще в FORTRAN функции можно было нормально передавать параметры,

то его можно было бы без проблем использовать. А так - лучше поставить

товарищу бутылку пива, пущай он на asm'-е все это пишет :)

<Ну, если так, то, конечно, плохо. Халявы не бывает :) >
Опять. Причем здесь халява. Есть лицензии "свободно для академического использования, за бабки -- для коммерческого", которые не требуют ничего впоследствии открывать. Идеальный вариант.

Вот именно, что GiNaC - не система символьной алгебры, а весьма специализированное приложение из той же серии, что CompHEP.

И такой подход - весьма крив. Куда как приличнее - генерация Фортрановского кода из того же FeynArts - определённо шустрее будет, и разпараллелить можно.

На тему производительности Математики - надо сравнивать не с человеком, а с аналогичным кодом на С++.

Распространённость - не аргумент. Массы быдла пользуют то, что разрекламированно, а не то, что является лучшим решением. И так - во всём, далеко не только в IT. Если же ты будешь продолжать настаивать на учёте распространённости продукта как важном критерии выбора, то и я, в свою очередь, потребую от тебя перехода на Microsoft Windows - он ведь значительно распространённее, чем Linux.

Ну а с их идеологическими причинами они могут отправляться к "Идущим вместе". ОО - не настолько всеобщая формальная модель, чтоб ей ещё и тупо следовать. Параметризованные типы - это всё фигня. Правда, шаблоны - тоже фигня, функторы в ML гораздо мощнее и универсальнее.

Для RAD Жаба абсолютно не подходит. Потому как даже контейнеров приличных нет. Нельзя быстренько сляпать работающий алгоритм и потом уже оптимизировать, для простейших задач приходится пейсать кучу лишнего кода.

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

Ты обшибся. Не введены в ML никакие типы как часть языка. Есть только мала-мала синтаксического сахара на тему списков - и то, это следует рассматривать как злые происки препроцессора, препроцессоры там вообще применяются весьма активно. Ну а как реализовать Хиндли-Миллнера на уровне *синтаксиса* - я даже представить себе не могу. Похоже что вы абсолютно не поняли фишку ML.

В общем, система типов там очень простая - есть декартово произведение, есть варианты и есть именованные туплы. Ну и функциональное отображение. Всё! Ничего больше и не требуется. Всё очень просто формализуется.

Синтаксис ml - так же предельно примитивный. Сложнее, чем синтаксис Схемы, но на порядки проще той же Жабы. Он фактически один в один отображает интуитивный синтаксис лямбда-исчисления - то есть, биндинги, аппликации и абстракции. Чуть-чуть сложности добавляется в паттёрнах - и то, паттёрны значительно проще всех этих измудских Жабских/Сишных case-ов.

Так что - читай снова. Синтаксических конструкций в ML - кажется, меньше десятка. Много проще, чем в Жабе. Базовых типов - вовсе нет. Математическая модель - простая и полная, в отличии от всего того ебанатства, которое лежит в основе таких императивных оопных языков, как Жаба.

В общем - Жаба - чреземерна сложна. А то "большинство", которое считает её простой - либо мозги промытые имеет, либо имеет недостаток мозгов.

Распространенность - не аргумент. Мой основной тезис в том, что для каждого есть своя точка компромисса. И для многих Жаба оказалась этой точкой. Поэтому я считаю ее _статистически_ удобнее ml. А Линух для меня - точка компромисса. Хотя _статистически_ удобнее винюки. Логика ясна? Кстати, статистическое удобство косвенно зависит и от маркетинга - через систему обучения.

Про rad - я боюсь, мы разные вещи под этим понимаем. Я то в rad всегда видел средство по-быстрому сляпать интерфейсик, работку с БД, сеточкой и пр. А вас интересует такая узкоспециальная форма как rad для арихметики...

Да, уровень абстракций на жабе ниже ml. В этом есть недостатки. Но в этом и достоинство pop-языка (от popular). Люди ленивы. Мыслить абстрактно (высоко-абстрактно) - трудно (не все хотят) и не все могут. Вы хотите заставить людей делать то, чего они делать не станут (большинство). Поэтому ml&Co вряд ли выйдут за пределы песочницы в 89 проектов...

ЗЫ. Да, совсем забыл - мы с Вами на брудершафт пили? Что-то запамятовал. Или не узнаю Вас под маской Antichrist.

Ну а мой аргумент - подавляющее большинство объективной оценкой при выборе инструмента не пользуется. Отсюда и распространённость всякого говна - Жабы, VB, Дельфи, Виндовса...

Под RAD я понимаю ровно то же самое, что написано в самом этом слова - Быструю Разработку Приложений. Интерфейсы тут абсолютно не при делах. То, что козлы из Багланда заставили всех думать, что RAD сводится к визуальному рисованию формочек - исключительно их, козлов, половые трудности. То есть, моё понимание RAD вовсе не узкое - для меня это всегда быстрое изготовление тяп-ляп-прототипа. С дальнейшим рефакторингом (если потребуется) до шустро/стабильно работающей системы.

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

Так что, ленивому человеку ML подходит лучше Жабы - не надо напрягаться с чужеродными абстракциями, всегда можно наплодить свои.

ЗЫ: сложно переключаться между ФИДО, где обращение на "вы" равносильно плевку в морду, и всяким разнообразным инетным форумам, где в каждом - свой устав. Здесь, кстати, манера общения в основном ФИДОшная.

ЗЗЫ: ну вы типа поняли, что ошиблись на тему сложности синтаксиса и семантики ML, а так же на тему его системы типов? Если нет - то ещё раз читать Харрисона.

А есть желание выпить? ;))))

Как насчет Bishoptown pub в субботу, скажем?

PS: А мне, прошу прощения, нравится .NET - прекрасный rad + огромный выбор языков. (Честно говоря мне c++/c# хватает)

Вообще-то, я не пью. Хотя можно просто побазарить, а там как пойдет... ICQ/28064549.

Нас сейчас тут выставят за офтопик. Тоже мне - другого места не нашлось пьянки организовывать в Корке как linux.org._ru_...:)