Borland выпустила Kylix

Ашибаисся. Качество программ ОЧЕНЬ сильно зависит от языка. Ибо правильные языки не позволят тебе сделать большинство тех ошибок, которые Пасквиль или ЦэПеПе скушают и не подавятся, и правильная парадигма, в языке реализованная, не позволит тебе совершать ошибок проектирования.

Ты ври, да не завирайся. Во первых, "программист", использующий только один язык - не программист вовсе. Языков нужно много разных - ибо идеальных языков не бывает, для каждой задачи свой язык нужен. Ну и в любом крупном проекте нужен как минимум один скриптовый язык. Далее - RAD - никоим образом не развитие IDE. Читай по буквам: Rapid Application Development. Развитие идеи code reusing. RAD может вообще без IDE быть - главное, чтобы это был язык с поддержкой правильной модульности и насильственно заставляющий интерфейсы модулей документировать. Крайне желательно документировать так, чтобы прочитать это не только человек мог, но и автоматом разгрести и выводы кой-какие сделать. Еще - про упаковку виджетов. Возьми любую свою дряную глюкалку, в которой виджеты по координатам распиханы, и попробуй растянуть окошко или заюзать фонт другого размера. Обломался? И правильно. Больше не смей гнать на layout manager-ы. Ну а английский (французский, китайский, русский) - никаких эпитетов, окромя матерных, и не заслуживают. Естественные языки ублюдочны в силу исторических причин. Искусственные языки (тот же Эсперанто) - рулез. Особенно когда хочется их автоматом разгребать/переводить.

2 anonymous > "А попробуй перечислить те классы задач, для которых C++ идеален. Я уверен, что не сможешь - для каждой задачи я найду язык лучше" Задача N1 - написание игры. Есть OPEN GL и подобные. Но, я надеюсь, ты понимаешь, что на OPEN GL в чистом виде написать игру невозможно ? Задача N2. Задачи, которые любит уважаемый AffreuxChien. Связанные с использование баз данных. SQL - хорошо. Но не все может SQL ! Формочку и ту, бедный, нарисовать не может. Суть такая. Для конкретных специфичных вещей в примере N1 и N2 используются специализированные языки которые могут из себя представлять библиотеку для С++, но для главной программы С++ идеален. Задача N3-.... Написание различных системных программ - различных серверов, утилит, ядра Linux (!) и пр. Без комметариев. Перечислил. А теперь ищи язык получше. Назвался груздем - полезай в кузов. "Оба этих языка - объектно ориентированные" И что в этом, по-твоему, криминального ? "слабо типизированные" - об этом уже говорилось неоднократно. Надо специализированные типы - далай. Реализация большинства есть в библиотеках. А многие типы Паскаля ИМХО высосаны из пальца. Все равно не знает CPU, что такое, например, строка и паскалевские высосанные из пальца типы мне не понятны. "императивные языки" объясните идиоту, что сие выражение значит plz. Вот. Похоже на попытку поспорить ?

Cогласен с Eugeny Balahonov и с AffreuxChien.<br> Очень потешно слышать о преимуществах древних средств разработки.<br> Даже для разработки системных вещей очень полезно иметь IDE. И потом, ЧУДАКИ, никто ведь не отменяет командную строку - <br> DCC [options] filename [options] <br>Как тут пишут - угадайте, на чем пишут драйверы для NT,95?<br> И ведь написали их уже много, очень много, любая железка выпускается <br>с драйвером под Win(в отличии от линукса). NT и делфийские <br>приложения падают только у тех у кого Direct Hand не включен, у <br>меня на работе NT месяцами не перегружается, как на серверах, так <br>и на клиентах. Т.е. хорошая среда разработки (VC++)не помеха(а <br>совсем наоборот) для ЛЮБОГО типа задач, включая самые <br>низкоуровневые(не юзай MFC,VCL- кто заставляет их юзать?). А на <br>чем игры и движки к ним пишут? - Опять же VC++. Очень похоже на <br>то, что те, кто кричит о глюкавости, кривости, и жестких рамках <br>IDE и Delphi в частности, - просто серьезно не работали с <br>подобными инструментами. Например, кто-то говорил о системе <br>контроля версий. - Ну ведь смешно слышать это. В любом серьезном <br>продукте, заточенном на совместную разработку проектов уровня <br>предприятия есть гораздо более развитая и удобная система <br>контроля версий чем юниксоидная RCS/SCCS( или на ней <br>базирующаяся). <br>Интересно, что на господ не действуют <br>упоминания таких уважаемых продуктов как theBat, Quest Software: <br>SQL Navigator, TOAD, PL/SQL Developer(сам пользуюсь, и не знаю <br>где взять подобное для линукс). Могу добавить в список ряд <br>биллинговых и банковских систем. Вообще, все информационные <br>задачи создаются с помощью 4GL - PowerBuilder,SQLWindows(или <br>близким к ним средств -Delphi, VB). Потому, что в таких задачах <br>важен алгоритм, программер должен сосредоточится, на нем, а не на <br>создании собственного , неповторимого интерфейса ручками(API), и <br>скорость прорисовки этого интерфейса(как тут правильно замечали) <br>не очень критична в 90% задач. Например, многие из СУБД программеров <br>прекрасно знают как работает Win внутри, <br>- класс окна, процедура обработки сообщений, очереди <br>сообщений, ... но каждый раз вручную регистрировать класс окна - <br>увольте, кушайте это сами и наслаждайтесь своей "крутостью". И <br>опять же, ни Delphi, ни МС++ <br>не заставляют вас юзать визуальные классы. Хотите консольное <br>приложение шлепайте, хотите виндовозное, но на API, а если не <br>садомазохист, то на тебе VCL,MFC(я не говорил что MFC (упреждая особо упертых- я не говорил что MFC хорошо спроектирован). <br>А на чистых иксах писать не слаще виндовозного АПИ. В принципе важно не это, а упомянутая вначале, и включенная по дефолту главная опция - DIRECT HAND. <br>Среда, язык программирования, операционка, - это уже десятое дело(хотя очень приятно, что под линуксомс начало появляться что-то серьезное).<br>Читайте Буча, Вирта, Ульмана, Дейта и все будет тип-топ, даже на <br>самодельном ассемблере.<br> А пока надо сначала хотя бы поюзать<br> Kylix(http://129.94.26.198/web/tools/Kylix/kylix.zip,<br> http://www.borland.com/devsupport/kylix/downloads/),<br> а уж потом хаять, - а то получается как у того крепостного <br> - Мужик ты курку едал? <br> - Не-а мой дед видал как барин едал. <br> Первая версия безусловно будет подглюкивать.

Какие такие ошибки ? Какие такие правильные языки ? Можно по - конктретнне plz ? Можя тогда поспориь смогу. А пока Ваша мессага - набор слов. Извините.

>А попробуй перечислить те классы задач, для которых C++ идеален. Я >уверен, что не сможешь - для каждой задачи я найду язык лучше.

Pozhaluista...
i) Raschetnie zadachi, osoblivo po netrivial'nim algorithms. Bistree Fortran'a, + structurirovannost', OOP, type-safety, static polymorphism, etc.
ii) Lubaya netrivial'naya obrabot'ka netrivial'nih data-structures. Constraint programming, computational geometry, ML-related algorithms, etc. Pri pravil'nom i accuratnom ispol'zovanii vozmozhnostei yazika delaet' functional languages _na_poryadki_. Pro prolog i prochuu muru ya uzh voobshe molchu.
iii) Pochti lubaya obrabot'ka grafiki.
iv) E-ee..., srednii uroven' sistemnogo programmirovaniya -- nekotorie otnositel'no high-level componenti OS, etc.

Davai, ischi dlya kazhdogo sluchaya yazik luchshe. Naidesh' -- dai znat':)

ChienMechant

http://www.cs.cornell.edu/icfp/ - результаты одного соревнования по написанию raytracer'а за 72 часа на любом языке. Функциональные языки в десятки раз быстрее C++. Конечно, я понимаю, что для C++ 72 часа может быть мало, и всё такое, но результаты есть, и не в его пользу.

>ам ты чушь собачья. Оба этих языка - объектно ориентированные,

Da, ne vopros... Chto mi predpochitaem -- aspect-oriented ili subject-oriented?:) Cherez paru desyatkov let poglyadim na eti techniques.

> слабо типизированные

Bred. C++ s _pravil'nim_ i _accuratnim_ ispol'zovaniem template-related techniques -- sil'no tipizirovannii yazik. Krome togo, yaziki so strong-typing imeut dovol'no ogranichennuu oblast' primeneniya.


>императивные языки.

Tozhe verno. Vi predpochitaete functional ili logical? Pro pervie nichego plohogo ne skazhu, za isklucheniem togo, chto pri nalichii vremeni/golovi na plechah na C++ budet viigrish v proizvoditel'nosti. Avtorov zhe logicheskih yazikov, i osoblivo prolog'a s dialect'ami, imho, nado rasstrelivat' bez suda -- vse, chto sozdano na prologe -- eto odin bol'shoi koshmar.:(


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

C++ suchestvenno otlichaet'sya ot pascal'ya po mnozhestvu aspect'ov.
Ok, pokazhi mne hotya bi esche odin imperativnii yazik so stol' zhe razvitimi, kak v C++, sredstvami podderzhki staticheskogo polymorphizma.


Попробуй поспорить.

Poproboval. Teper' poprobui ti.

Я не совсем понимаю, что имеется под статическим полиморфизмом, но если это вдруг шаблоны, то посмотри на Аду95. На мой взгляд, шаблоны там гораздо более развиты, чем в C++.
Если под статическим полиморфизмом понимается что-то другое, то хотелось бы услышать, что именно.

>http://www.cs.cornell.edu/icfp/ - результаты одного соревнования по >написанию raytracer'а за 72 часа на любом языке. Функциональные языки >в десятки раз быстрее C++. Конечно, я понимаю, что для C++ 72 часа >может быть мало, и всё такое, но результаты есть, и не в его пользу.

Ya i sam znau, chto k primeru, quicksort dlya functional languages budet bistree, chem na plusah. Nikto i ne prosit realizovivat' na plusah' _suschestvenno_rekursivnie_ algorithm'i...:)
Nikto ne govorit, chto C++ pozvolyaet _bistro_ pisat' effektivnie programmi. _Etot_yazik_dlya_etogo_ne_prednaznachen_. On prednaznachen dlya effektivnoi realizacii uzhe produmannih/otlazhennih/proverennih (na teh zhe functional languages, kak eto delaut u nas) algorithms pri uslovii nalichiya u razrabotchika vremeni/kvalifikazii/golovi na plechah.
U nas, napisannaya (za opred. vremya, estestvenno) na C++ realizazii odnogo algorithm'a delaet sootvetstvuushuu functional-versiu na _3_desyatichnih_poryadka.

Уважаемый, у Вас как с английским? У меня не очень. Насколько я понял, это соревнование не языков, а разработчиков. Мож я не прав ? Извините, если так и есть. Как вы народ не понимаете - что С/С++ - универсальный язык. Конкретные специализированные вещи вполне можно и нужно реализовывать на специлизированном языке, реализация которого вполне может представлять собой библиотеку языка С/С++. Но чем более специализированный язык, тем больше у него ограничений. Так что С/C++ неправильно сравнивать со специлизированными языками. Быстрее С только Ассемблер и то постараться надо, чтобы быстрее было. Все остальное - наглый гон ! Этого не может быть потому что не может быть никогда.

>Я не совсем понимаю, что имеется под статическим полиморфизмом, но >если это вдруг шаблоны, то посмотри на Аду95. На мой взгляд, шаблоны >там гораздо более развиты, чем в C++.
>Если под статическим полиморфизмом понимается что-то другое, то >хотелось бы услышать, что именно.

Ya pod etim ponimau templates + chastichnaya/polnaya specializaciya + poryadok specializii + concept checking.
K sozhaleniu, ya ne znakom blizko s Ada95, vse, chto ya pomnu pro Ada, eto to, chto tam est' packages/generic packages, kotorie napominaut rannie C++ templates. Vi navernyaka znakomi s Ada95, kol' privodite ee v primer. OK, ya ne v kurse, mozhno li s pomosch'u "adskih" mechanismov, equivalent'nih templates, sdelat ananogi: i) expression templates (navernyaka Vi znaete, chto eto), ii) templates metaprograms, iii) concept checking. Est' li v Ade specializaii po tipam argumentov?
Pochemu ya pishu pro eti veschi -- potomu chto schitau, chto imenno na nih derzhitsya sovremennii C++.
Krome togo, naskolko ya ponimau, v Ada'h net inline-ing'a. Ya dumau, Vi ponimaete, kakuu pomosch' mozhet okazat' inlining horoshemu compilyatoru...

Ассемблер для x86, конечно, быстрее, чем любой язык программирования уровня повыше - я бы с этим согласился и без наездов на мой английский. Я просто хотел показать, что не правда, что C++ "делает функциональные языки на порядок" *в любом случае*.
Конечно, соревнуются там больше разработчики, но почему же тогда три самых быстрых реализации - на функциональных языках? Совпадение?

>Как вы народ не понимаете - что С/С++ - универсальный язык.

C++ -- ne universalnii yazik. Zadach, dlya kotorih on podhodit, gorazdo men'she chem zadach, kotorim on podhodit malo. Primeri Vam uzhe privodilis' -- RAD, business applications, GUI, etc. -- prozentov 80 sovremennih prilozhenii. Bolee togo, on ne podhodit _ni_dlya_odnoi_ zadachi, esli ee nuzhno reshit bistro (ne v smisle, chtob programma bistro rabotala, a chtob bistro ee napisat').

>Этого не может быть потому что не может быть никогда.

Eta phraza bolee chem sootvet'stvuet Vashemu nick'u:))) IMHO, pryamaya zitata...:))

ChienMechant

>Конечно, соревнуются там больше разработчики, но почему же тогда три >самых быстрых реализации - на функциональных языках? Совпадение?

Da net, prosto plusovim razrabotchikam len' uschastvovat' v podobnih contest'ah:) Oni vse bol'she lovyat bugs v pointer-arithmetics...:))

Народ, вы уху ели? И как, вкусно??

Спор о том, какой язык лучше, может вестись среди студентов 1-2 курса,
или поклонников WIN, аж 2 (!) недели назад купивших свой первый в жизни
компутер.

Странно, что боль-мень предметный флейм RAD vs. classic style
(или как его назвать?) свелся к банальному релегиозному спору...

Flawer

>Спор о том, какой язык лучше,

Slish', chuvak, ti gde-nibud' videl hot' odnu phraze o tom, chto yazik A luchshe chem B? Esli ti hoshesh' videt' tolko povod dlya naezdov, eto, tipa, tvoe pravo, no...
Krome togo, ti chto, budesh' otrizat', chto raznie yaziki _luchshe_ podhodyat dlya raznih oblastei? I razgovor shel vpolne predmetnii -- kakoi yazik _luchshe_ podhodit dlya buziness RAD -- koneshno, ne togo urovnya, chto knopochka na formochku -- tut raznici mezhdu plusami i, k primery, VB netu...

ChienMechant

P.S.: A uzh ne znat', kak pishetsya slovo relIgioznii, mogut', navernoe, tolko abiturienti ili poklonniki Linux, azh 2(!) nedeli nazad prochitavshie svou pervuu knizhku.

(Эпиграф: Я не волшебник, я только учусь :-)
Я всех этих терминов не знал, сейчас искал на google, если что понял не так, то исправления, естественно, принимаются.

expression templates + concept checking - насколько я понял, обеих вещей можно достичь использованием функций как параметров шаблонов. Это в Аде есть, также есть и inlining, который при этом может использоваться, но используется ли он на самом деле, я не знаю, могу проверить, если надо.

templates metaprograms: В Аде нет automatic instantiation и частичной специализации, поэтому метапрограммы, похоже, реализовать не получится. С другой стороны, всё-таки, на мой взгляд, шаблоны делались не для этого. Да и можно, наверное, написать "агрессивный" компилятор (не только для Ады), который будет пытаться считать всё, что можно во время компиляции.

Что имеется в виду под специализацией по типам аргументов? Сочетание automatic instantiation + partial specialization?

2Flawer: Конечно, C++ vs Pascal уже всем надоел, наверное, да и отличаются больше компиляторы, чем языки. Я лично пытаюсь услышать как можно больше аргументов против Ады - мне хочется знать, почему она используется не так широко, как C++, хотя на мой взгляд, она во многом лучше. Да, и я - студент 3-го курса, так что можете делать выводы.

2 Flawer > "Спор о том, какой язык лучше, может вестись среди студентов 1-2 курса..." Ну, зря Вы так. ИМХО спор может быть о чем угодно. Единственное место, где пофлеймить можно и умных людей послушать :). А Паскаль suxx. Убеждать меня в обратном бесполезно. 2 ChienMechant > "C++ -- ne universalnii yazik ... on ne podhodit _ni_dlya_odnoi_ zadachi, esli ee nuzhno reshit bistro". Ну, не согласен я. На С++ с использованием соответствующих библиотек можно написать _все_ и быстро. А что такое быстрая разработка приложений ? Программирование мышкой ? Программирование мышкой _не_ убыстряет разработку приложений, если приложение не HelloWorld. Запарился я с пеной у рта это доказывать. 2 justme > C делает по скорости любые языки кроме ассемблера. Практически во всех случаях. Случаев, когда какой-либо другой язык быстрее, крайне мало. Ну, да таких случаев специализированные языки и созданы.

Для игрушек C++ не канает. Все равно, как ты сам подметил, bottleneck будет в OpenGL, а не в твоем приложении - так что лучше уж заюзать более строгий язык. Задача 2 - базы данных. Тут тоже ся плюсатая не канает ни в борщ ни в Красную Армию - даже Java, и та лучше подходит (особливо если учесть наличие таких сытных библиотек, как BC4J). Системные програмы - по большей части вообще должны быть скриптовыми, это не просто мое сугубое IMHO, но и факт, проверенный на практике. К примеру, в мелких дистрибутивчиках Линукса, предназначенных для работы на офигенно ущербном железе и прошивки во флешки, все системные тулзени переписаны на Tcl. На Цэ там почти ничего и нет. Ядро - тоже сомнительно, что стоило его писать на Цэ - ошибок было бы гораздо меньше. Вспомни Лисп-машины, примеру ради для.

Далее - объектно ориентированные: ОО не панацея, и худ тот язык, который на ОО закладывается изначально. Слабая типизация - её просто не должно быть. От неё почти все беды и исходят. Что такое строгая типизация - смотри, примеру ради, на Хаскелль или ML. Императивные - это содержащие сайд-эффекты, которые крайне трудно прогнозировать и отслеживать. Переменных (мутабельных объектов) не должно быть, они - зло. В функциональных языках сайд-эффектов нет, и, соответственно, можно автоматически преобразовывать и даже доказывать код. В современных компиляторах это позволяет достигать производительности большей, чем ты ручками на C++ или ассемблере сделаешь.

Зря ты думаешь, что на C++ можно написать все. Он же императивная параша, его никакие библиотеки не спасут. Не веришь? Напиши тогда пусть даже самую примитивную систему символьной алгебры.

Ой, вот только не надо гнать, что C++ быстрее Фортрана. Знаем, проходили. Все попытки перейти с Фортрана на C++ заканчиваются жутким обломом. Хотя бы вспомним тот факт, что Фортран (касабельно численных методов исключительно) офигенно хорошо оптимизирует, и, что важно, автоматически параллелит многие операции. На C++ это невозможно в принципе, в силу его низкоуровневости. Ну и type safety в C++ нет никакой - да и откуда она возьмется в языке, где существуют указатели....

Нетривиальные структуры данных - опять мимо тазика. Тут нужен именно функциональный язык со статической типизацией. И не гони про "на порядки" - эта информация лет на двадцать устарела. Сейчас нормальные функциональные языки частенько делают C++ за счет бОльшего потенциала для оптимизации, proper tail recursion, правильной работы с памятью, и т.д.

Графика - тоже мимо тазика. Иначе на фига лисп в автокаде и схема в GIMP-е?

Так что, ты по всем пунктам прогнал. Поздравляю.

На тему правильных языков: посмотри на http://caml.inria.fr/ и http://www.haskell.org/ Еще для полноты картины сходи на http://www.schemers.org/

Если последний anonymous - это не vsl, забывший пароль, 
то его родной брат - точно :)

Ну вы блин даете мужики! Для информации о правильных языках и прочей ерунде. Есть такая организация ISO. С неё гонят все национальные стандарты. Так Вот стандарт ISO определяет следующие языки программирования Фортран, Кобол, Ада и Си. Есть черновой стандарт Си++ принят или нет не знаю. Уверен, что в ISO сидят люди, как минимум не глупее тех, кто пишет в эту эху. Далее - о фри и не фри компиляторах. Если фри компилятор будет какчественнее (спасибо А. Райкину за термин), чем не фри на нем и будет писаться софт. Пример. В QNX перестали пользовать Watcom который стоит больших бабок и перешли на gcc. Так, что люди, не горячитесь вы так. Жизнь сама расставит все по полкам

2justme:
> Я лично пытаюсь услышать как можно больше аргументов против Ады - мне
> хочется знать, почему она используется не так широко, как C++, хотя
> на мой взгляд, она во многом лучше.

IMHO ничего таинственного тут нет.

C++ содержит C, а последний -- native language для UNIX.
Кроме того, Ада несколько тяжеловата. Самое же главное --
на момент начала экспансии M$ с компиляторами Ады под ДОСом
была напряженка, а C/C++ был там уже популярен благодаря Борланду.
M$ пришлось раскручивать C++ просто для того, чтобы потеснить
Inprise.

Flawer

2anonymous (*) (2001-03-14 01:01:08.0):

>...самую примитивную систему символьной алгебры.
Не флейма ради -- просто информация:
http://www.ginac.de/

Flawer

>Ой, вот только не надо гнать, что C++ быстрее Фортрана. Знаем, >проходили. Все попытки перейти с Фортрана на C++ заканчиваются жутким >обломом. Хотя бы вспомним тот факт, что Фортран (касабельно численных >методов исключительно) офигенно хорошо оптимизирует, и, что важно, >автоматически параллелит многие операции. На C++ это невозможно в >принципе, в силу его низкоуровневости.

Ok, ne bistree, no i ne huzhe, osoblivo na obichnom zheleze. Pri ispol'zovanii normal'nogo compiler'a i vsyakih features napodobie ET, proizvoditel'nost' budet pochti odinakovaya. Pri etom, ya nadeus', ti ne budesh sporit', chto, e-e... yazikovie vozmozhnosti plusov luchshe, chem fortran'a.

>Ну и type safety в C++ нет никакой

Type safety v plusah est'. Bolee togo, pro luboi dazhe polzovatel'skii type mozhno _staticheski_ uznat' vse, chto ugodno, vplot' da togo, podderzhivaet li on zadannii interface.

>Тут нужен именно функциональный язык со статической типизацией.

Functional language nuzhen dlya realizazii/proverki _idei_ algorithm'a.
Dal'she on dolzhen bit' perepisan na plusah.

>И не гони про "на порядки" - эта информация лет на двадцать устарела.

Ya i ne gonu. Peredo mnoi dve realizazii odnogo i toge zhe algorithm'a -- plusovaya i functional'naya. Plusovaya delaet functional'nuu v srednem na 3 poryadka.

>функциональные языки частенько делают C++ за счет бОльшего потенциала >для оптимизации,

Chasten'ko delaut krivie neotlazhennie neprodumannie plusovie programmi. "Pravilnaya" rabota s memory slishkom doroga.

>Графика - тоже мимо тазика. Иначе на фига лисп в автокаде и схема в >GIMP-е?

Ne nado sofistiki, OK? Vnutri i togo, i drugogo -- C++, ili, togo huzhe, C... Ya nadeus', ti ne budesh' delat' texture correction na functional language?

>Так что, ты по всем пунктам прогнал. Поздравляю.

Poluchaet'sya, chto ya ne gonu, a inogda gonish' i ti. Pozdravleniya ostav' sebe.

P.S.: Pro caml i haskell ya znau. Ne lechite menya zhit':)
P.P.S.: Esli bi functional languages bili bi panazeei, kak ti zdes' declariruesh', vse b davno pisali na nih. A to vot narod ubogii, vse bol'she na plusah, da na java, da azh na RPG s cobol'om...

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

Ei!

Figli tut moi posti dlya anonymous'a-lubitelya functional languages udalyaut? On menya, tipa, opuskaet, a ya emu i otvetit' ne mogu?:)
Togda ubiraite i ego post...

>Plusovaya delaet functional'nuu v srednem na 3 poryadka.
Это что, в 1000 раз быстрее ?!?!?!

2 rivares
>"..стандарт ISO определяет следующие языки программирования..."

Взгляните-ка: ISO-7185 Standard Pascal, ISO-10206 Extended Pascal.

Ну дык там же честно сказано Is Not a Computer Algebra System. Это совсем другая песня...

1) Компилятор фортрана должен быть правильным. Правильный компилятор фортрана делает правильный компилятор C++ со страшной силой. Так уж получается...

2) Как язык фортран лучше хотя бы тем, что под него просто до хрена библиотек. Кроме того, Fortran 90 содержит все, что нужно такому языку, и с него на C++ ни за какие коврижки никто не перескочит.

3) Ну ты почитай, что такое правильные системы типов, что такое type safety, и почему её в языке с указателями быть не может по определению. А потом еще, чисто по приколу, подумай - как в C++ сериализовать произвольный тип.

4) Ты, судя по всему, нормальных компиляторов функциональных языков не видел, если они у тебя так тормозят, что возникает противоестественное желание на плюсы переписать. Частенько, за счет proper tail recursion и более продвинутой модели памяти и механизму передачи параметров такие языки в разы обгоняют C++. И не гони про дороговизну работы с памятью - malloc/free - самый тупой и дорогой метод из всех известных.

5) С графикой - не путай низкий и высокий уровень.

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

Да ну?!? Напомнить, как Watcom глючил и тормозил с плавучкой? Если уж говорить про качественные компиляторы для x86 - то пока на первом месте идет MSVC. Следом за ним, с большим отрывом - gcc. А Watcom - где-то в дупе, на свалке истории.

2anonymous (*) (2001-03-14 20:08:27.0)
> Ну дык там же честно сказано Is Not a Computer Algebra System.
> Это совсем другая песня...

Прочитайте там (http://www.ginac.de) чуть дальше расшифровки
названия. Они делают как раз то, что Вы просили.

Flawer

Я не волшебник, я только учусь(c)
Тут неоднократно проскакивало сообщение о том, что "в нормальном типизированном языке не может быть указателей". Тогда может быть кто-то мне объяснит, как в таком случае реализовывать такие структуры как списки и деревья произвольных размеров.
Только пожалуйста поподробнее, а то я на 1-ом курсе пока...

Вот тебе B-дерево:

type 'a tree = EmptyNode | BinNode of 'a tree * 'a * 'a tree;;

Никаких указателей, чисто функциональная структура.

Далее говорим, к примеру, ((BinNode (EmptyNode, 1, EmptyNode))), и получаем дерево типа int tree, с одним элементом в голове.

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

2anonymous (*) (2001-03-14 22:15:11.0):
> Это система того же класса, что и CompHEP
Ничего общего с CompHEPом, кроме того, что делается конкурирующей
группой физиков. xloops еще можно было как-то сравнивать с CompHEP...

> Интерактивной работы с символьными выражениями,
> что нужно, к примеру, в серьезном
> компиляторе, там таки не предусмотренно
Не понял Вашего утверждения: зачем в КОМПИЛЯТОРЕ нужна
ИНТЕРАКТИВНАЯ РАБОТА? IMHO мы друг друга не понимаем.

С др. стороны, как раз интерактивная работа ими подразумевается
через ROOTовый CINT.

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

Короче, GiNaC появился потому, что MAPLE процедуры в XLOOPS
работали слишком медленно, и они затеяли переписать обработку
символьных выражений на C++. Цитата с http://www.ginac.de:
It is designed to allow the creation of
integrated systems that embed symbolic manipulations...

На "...самую примитивную систему символьной алгебры"
GiNaC явно тянет.

Вообще, наша дискуссия тут -- оффтопик. Если хотите,
продолжим мылом.

fla_wer@hotmail.com

>Кроме того, Fortran 90 содержит все, что нужно такому >языку, и с него> на C++ ни за какие коврижки никто не перескочит.

N-da? To-to u nas ryadom azh celii department fizikov, i vse na plusah pishut... No eto tak, ne vozrazhenie, a iz razryada sofistiki.
Vse ravno, v lubom sluchae, kak yazik, C++ kak minimum bezopasnei, chem fortran.

>3) Ну ты почитай, что такое правильные системы типов, что такое type >safety,

Da znau ya, znau chto eto takoe..

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

Chto ti pristal k ukazatelyam. Mezhdu prochim, ukazatil tozhe imeet type. Nikto tebya ne prosit pisat' reinterpret_cast<MyCoolVeryComplexType*>(474747ul | 0xF0000000ul);
BTW, vse ravno vse svodit'sya k ukazatelyam, prosto v silu neobhodimosti adresovat' storage. Tolko, v sluchae FL, za tebya eto sdelaet' compiler, a v sluchae c++ -- ti eto dolzhen delat' _inogda_ sam. Pohozhe, ti nasmotrelsya na kernel sources, i tebya tak kolbasit:)

>А потом еще, чисто по приколу, подумай - как в C++ сериализовать >произвольный тип.

Nikak, i chto? Kstati, sovetuu na dosuge podumat', pochemu...
Bolee togo, iz togo, chto eto mozhno zdelat', f.e., v Java ili, tem bolee, v smalltalke, vovse ne sleduet', chto eto bolee strong-typed languages. Tak chto reflexifity i serialization zdes' ni k selu ni k gorodu.

>Частенько, за счет proper tail recursion и более продвинутой модели >памяти и механизму передачи параметров...

Chto ti pristal k tail-recursion. Esli u menya zadacha, e-e..., suchestvenno recursivnaya, ya voz'mu kakoi-nibud' FL.

> не гони про дороговизну работы с памятью - malloc/free - самый тупой >и дорогой метод из всех известных.

Nikto ne prosit polzovat' malloc/free po povodu i bez. Mozhno vzyat' luboi memory manager i radovat'sya...

>5) С графикой - не путай низкий и высокий уровень.

I ti ne putai. Tak mozhno zdelat' vivod, chto, f.e., VBA -- gorazdo kruche chem te zhe plusi -- ved' eto yazik Word, Excel, etc.

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

E-e... Esli bi vse bilo tak prosto, kak ti govorish'.

Это...иду я сегодня по Барселоне...прохожу мимо книжного магазина
 мимо меня проплывает название книги : Kylix...
Доходит медленно...постепенно шаги замедляются и приходит мысль - почудилось..

Но сознание - неспокойно...возвращаюсь..
протираю глаза.. название книги не меняется...посмотрел и точно "ОН"..

Книжечка правда таксебешная, но прикольно...купил конечно..
если кто любит читать книги по информатике на испанском...могу дать отхерить кода приеду..
кто-нить устати скачал уже Kylix?
Очень хоца переписать...таки киньтё чёнить на vadimt@mail.ru

А представьте псевдоуказатель - класс. После этого меняйте записи на классы: TListItem=class(TObject) ItemData:TSomeData; IsNext:boolean;//совсем уж правильно. Даже nilа не нужно Next:TListItem; end; TList=class(TObject) public property Lists:array[N]of TListItem read GetList write SetList; private ...... end; Фактически - указатели есть, но их никто не видит!!! :-) Я так всегда делаю!!

2Ленин:

>Когда человек пишет софт для FSF - он ИМХО вкладывает в него душу. Зачем тогда вообще ему писать бесплатный софт ? Так что качество бесплатного софта должно быть на порядок выше т.н. коммерческого. RedHat - это вторая организация после Борланда, которая должна сдохнуть. Третья - Corel.

Класно сказано.

Относительно С++ полностью с Вами согласен и поддерживаю.

А кто на меня захочет наехать, то заранее говорю:
ПОШЕЛ В ЖО#%!

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

Я все сказал. :)))

> Я все сказал. :)))

А ты название темы видел? Сказал он всё, блин... модератора на тебя нет!

ага - 20-50 лохов

2lenin:
>В паскале есть такие штучки, как массив, выход за границы которого >недопустим
Это в каком таком "паскале"? В борландовском (по крайней мере, начиная
с 5.0) всегда можно (и нужно!) вырубать все проверки на переполнение/
выход за границу в настройках, потому как это только для отладки/
проверки нужно.

2lenin:
>C делает по скорости любые языки кроме ассемблера
Уточните: все, которые Вы знаете...
Forth не пробовали? Или он тоже suxx, потому что не пробовал, а не
пробовал, потому что suxx?:)))

"Forth не пробовали? Или он тоже suxx, потому что не пробовал, а не пробовал, потому что suxx?" Не надо, уважаемый, умничать. Forth я пробовал. Ничего хорошего в нем я не нашел. Писать на нем зае....ся. Написал программку поиска совершенных чисел. Работало медленнее, чем интерпритатор Бесика. Вот криворукий, да ? Правда, давно это было, лет 7 назад, может, сейчас и написал-бы че-нить побыстрее. На ассемблере тоже в принципе можно писать программы, которые быстрее аналогичных, написанных на С, но не каждый это может сделать, согласны, уважаемый ?

Угу. Еще можно еще не пользоваться некоторыми уродскими типами данных, можно стараться не использовать юниты (что ИМХО очень тяжело), можно пользоваться всякими прелестями типа INC, можно, наконец, на asme что-то приписать. В таком случае, уважаемый, от паскаля не остается ничего, и если Вы все это можете и используете, чем Вам не нравится С ? А то, что Борланд сделала из паскаля нечто, что можно использовать - это я писал уже и полностью с этим согласен. Только не паскаль это, а одно название, на котором Борланд бабки и делает.