Сравнение языков...

>для чего лучше всего/идеально подходят

Для священных войн, конечно:-)

Очень смешно. Мне это не для этого нужно, а для выбора языка под мою задачу. И все.

Тогда лучше опиши задачу

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

Есть сильно устаревший (но все еще интересный) книг: Пратт Т. Языки программирования: разработка и реализация.

Все современные обзоры ИМХО сильно предвзяты.

Если с нуля разрабатывать сложный проект, то ИМХО лучше всего писАть на Це свой (возможно, мета-) язык, он все равно будет лучше, чем всякие новомодные хреновины.

Создание шустро работающего GUI. На GTK.

Python, Perl? Однозначно не C/C++/Java/Pascal. На скриптовые языки смотри.

Begemoth :

> Однозначно не C/C++/Java/Pascal. На скриптовые языки смотри.

Утверждение, _по_меньшей_мере_ спорное.

(Особенно меня поразила рекомендация использовать Перл для написания шустрого ГУЙа).

Ну сказали же, что шустрого. Зачем заведомо говорить такую чушь? Я советую C.

Я в соседнем топике уже писал. ГУИ на wxPython не тормозил на 300Mhz/32 Ram, так что не надо, здесь имхо язык намного менее критичен, чем гуи либа.

К тому же динамические языки лучше намного лучше подходят для создания гуи.

http://www.melikyan.com/dalshe/articles/power.html

CrazyPit:

> К тому же динамические языки лучше намного лучше подходят для создания гуи.

Модное, но _по_меньшей_мере_ спорное утверждение (ИМХО просто чушь, извини...)

> Модное, но _по_меньшей_мере_ спорное утверждение (ИМХО просто чушь, извини...)

Лучшим практическим доказательством этого утверждения являеться связка TCL/TK, котороя ещё в бородатые году служила отличным(и до сих пор одним из лучших) инструментом для создания гуи в unix.

CrazyPit:

> Лучшим практическим доказательством этого утверждения являеться связка TCL/TK, котороя ещё в бородатые году служила отличным(и до сих пор одним из лучших) инструментом для создания гуи в unix.

Лично у меня от этой связки полностью противоположные ощущения.

Оно пригодно для _простейших_ ГУЙовин. Но чуть посложнее..

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

То есть, для отображения простого диалога, даже для простейшей функциональности типа словаря (посмотри, например, на mova) оно -- самое то. Но попробуй на ней что посерьезнее написАть!

Конечно, можно и на Баше написАть ВЕБ-сервер, а потом пиарить его как наикрутейшее решение...

>Лучшим практическим доказательством этого утверждения являеться связка TCL/TK

то-то у нас десктоп бинарный весь ;)

не знаю как у вас, но у меня большая часть десктопа (по крайней мере фронтэнды, но и не только) написана на динамическом языке, правда конечно не на tcl.

Помойму как раз для _динамического_ сложного ГУИ он выруливает (собственно для этого и делался)...

Хорошо не желаю быть пустословом и флеймером, потомучто не имею пока достаточного опыта работы с TCL/TK. Но связка Python+wx, не смотря на ублюдочность либы, мне позволила писать приложения намного быстрее и кратче чем аналоги на VS и Delphi, думаю с tk или gtk было бы ещё лучше.

ну если desktop == xemacs... :)

... хотя тут я сморозил

не пока gnu emacs;) Поэтому не весь а почти весь.

CrazyPit:

> у меня большая часть десктопа ... написана на динамическом языке, ...

Это, типа, .fvwmrc ?

Или Емаксовые файлы?

Угу, тогда -- да. Для _таких_ целей оно -- как раз. Скриптовые языки изумительно годятся для описания конфигураций. Только вот при обновлении версий оно частенько взглючивает.

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

> Это, типа, .fvwmrc ?

> Или Емаксовые файлы?

> Угу, тогда -- да. Для _таких_ целей оно -- как раз. Скриптовые языки изумительно годятся для описания конфигураций. Только вот при обновлении версий оно частенько взглючивает.

Но и не только конфигурации! Большинство фронтэндов (именно гуи) полностью написано на elisp. Но также и многие полноценные приложения, emacs-jabber, gnus, bbdb полностью написаны на elisp и прекрасно выполняют свое предназначение.

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

Да и не только модно но и во многих(далеко не во всех конечно) областях конечно вполне оптимально. Например для сайтов со средней и лёгкой логикой тот же Ruby On Rails. Или erlang тот же в своей сфере. Упс не увидил слово "продвинутую", ну тогда здесь можно долго спорить, насчёт того какая логика уже "продвинутая", а какая ещё нет. Но очень многим задачам продвинутость и не нужна.

Вот, кстати, безотносительно ГУЙа, как раз сегодня я потратил воскресение для того, чтобы налабать некий гейтвэй на Баше, по заданию именно на Баше было надо...

Я потратил день на задачу, с которой бы справился за полчаса, если бы мне позволено было заюзать Це.

Просто потому, что каждый шаг был _слегка_ слишком высокоуровневым. Например, sed принимает опцию -u, а tr -- нет. А sed почти не умеет работать с newline символами. А cat в инкарнации GNU опцию -u игнорирует, а по стандарту должен буферизовать блоками...

Короче, когда за тебя все кубики дядя написАл, тебе легко слепить из кубиков нечто децЦкое, конечно. Но вот комфортное жилье ты себе из кубиков не построишь.

> Короче, когда за тебя все кубики дядя написАл, тебе легко слепить из кубиков нечто децЦкое, конечно. Но вот комфортное жилье ты себе из кубиков не построишь.

Ваши слова протеворечат светлым принципам unix-way :))

PS: Думаю если бы был выбран python, perl (уж этот уродец помойму почти везде есть, где есть баш) или ruby а не bash всё было бы намного лучше.

> Ваши слова протеворечат светлым принципам unix-way :))

Отнюдь!

Операционке -- операционковое, аппликухе -- аппликуховое!

Юних позволяет мне решить многие типовые задачи, за что я ему благодарен. Когда же для решения задачи требуется написАть программу, я пишу программу. А не занимаюсь сексом с различными "динамическими расширениями" операционки (коими и являются "динамические" языки). ИМХО подобная двухуровневая схема себя полностью оправдывает (нарушения этого принципа, ессно, от супер-ОС известной фирмы проистекает, где вообще операционки в привычном нам смысле не наблюдается -- ОС только ABI предоставляет).

Впрочем, признаЮ, что _большинство_ присутствующих, скорее всего, со мной не согласятся.

Что ж! Такова жизнь... Все основы напрочь забыты, профессорА читают студентам предметы "как наколоть заказчика", идут жаркие дискуссии о том, что восходящее проектрование все-таки круто, и в обозримом будущем нам будут впаривать про архаичность разделения адресного пространства на ядерное и юзерланд...

>адресного пространства на ядерное и юзерланд...

прально! оно нам не надо: будет один веб - зачем какое-либо разделение, если будет одна-единственная программа - браузер.

>прально! оно нам не надо: будет один веб - зачем какое-либо разделение, если будет одна-единственная программа - браузер.

Ага я тоже так думаю. И кстати это сейчас в самом деле становиться мэйнстрим идеей в разработке ПО для юзеров. Но это конечно тру компьютерщиков не так коснёться.

CrazyPit:

> ...Но это конечно тру компьютерщиков не так коснёться.

Типа, издеваешься?

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

Для тру компьютрещиков всё уже написано:))) Так что не нужны новые перделки:)

ЗЫ: ну меня это точно коснёться, потому что я собираюсь этим заниматься /звучит гомерический раскатистый смех/

да-да-да, браузер - просто более умный терминал:))) назад в 70-ые? Учитывая повсеместное распростанение вай-фай и быстрого и бесплатного интернета идея вполне жизнеспособная, так сказать браузер ОС. FireOS :)

> браузер - просто более умный терминал:)))

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

> назад в 70-ые?

Много хуже.

> идея вполне жизнеспособная, так сказать браузер ОС.

Только не в современном виде.

> ГУИ на wxPython не тормозил на 300Mhz/32 Ram, так что не надо

У меня прям слезы на глазах от твоих слов: "Нет, вообще тормозов при работе не было. Вот грузилось секунд 30."

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

Не морочте голову, гуи вообще не нужно ни одной программе кроме gimp'a.
А с изобретением мозг-коннектора, наконец, все виды UI вымрут. Останeтся лишь интерфейс мыслей.

> У меня прям слезы на глазах от твоих слов: "Нет, вообще тормозов при работе не было. Вот грузилось секунд 30."

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

>Не морочте голову, гуи вообще не нужно ни одной программе кроме gimp'a. >А с изобретением мозг-коннектора, наконец, все виды UI вымрут. Останeтся лишь интерфейс мыслей.

имхо к тому времени позитронные роботы уже захватят мир:)

2 Die-Hard :

> Я потратил день на задачу, с которой бы справился за полчаса, если
> бы мне позволено было заюзать Це.
>
> Просто потому, что каждый шаг был _слегка_ слишком высокоуровневым.
> Например, sed принимает опцию -u, а tr -- нет. А sed почти не умеет
> работать с newline символами. А cat в инкарнации GNU опцию -u
> игнорирует, а по стандарту должен буферизовать блоками...

Именно поэтому я (кроме самых простых случаев) пишу на Perl
вместо возни с bash+sed+awk+uniq+join...
И уж поверь мне, это _намного_ быстрее, чем на C.

(может конечно GUI на C пишется быстрее - спорить не буду,
никогда не GUI не писал)

s/никогда не GUI не писал/никогда GUI не писал/

> Именно поэтому я (кроме самых простых случаев) пишу на Perl
> вместо возни с bash+sed+awk+uniq+join...
> И уж поверь мне, это _намного_ быстрее, чем на C.

+1

более того, я вообще на С стану что-то делать только
если это ну никак на perl не получится.

а может вот это подойдёт?

Lutz Prechelt: Comparison of Seven Languages

http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf

> Ну сказали же, что шустрого. Зачем заведомо говорить такую чушь?

А обосновать слабо в каком месте это чушь? И почему.

> Я советую C.

А не лучше ли сразу на языке ассемблера все писать? Никто _логику_ обработки не советует писать на скриптовых языках.

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

Вопрос был про написание GUI. И в каком месте там будет "продвинутая логика"? Вынесите ее в отдельную либу, реализованную на компилируемом языке.

>Так называемый Web 2.0 - именно это и означает. Видимо, специально подбирали самые убогие, громоздкие и неподходящие технологии.

Вы таки имеете ввиду xml, js?

Какие ваши предложения?

GUI drScheme написан на каком языке?

Begemoth:

> И в каком месте там будет "продвинутая логика"?

Дык, там и будет.

Если у тебя штука-другая виджетов, то, конечно, никакой особой логики там нет. А, вот, собрать что-либо нетривиальное нормально работающее из кубиков вряд ли удастся.

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

idle:

> более того, я вообще на С стану что-то делать только если это ну никак на perl не получится.

Ну да, Перл несколько особняком стоИт. На нем, действительно, легко лабать простенькие приблуды для своих целей, когда шелла не хватает.

Но IMHO чуть что посложнее на Це получается проще.

Наверное, все же, дело вкуса...

> Но IMHO чуть что посложнее на Це получается проще.

> Наверное, все же, дело вкуса...

И что жы такое нужное для ГУЯ умеет C, чего не умеет Perl/Python? Как раз сложная логика, при наличии мозга и гигиены, на динамических и функциональных языках делается очень удобно. Замыкания и language-native (а не библиотечные) контейнеры очень, очень сильно упрощают код - логика видна сразу, а не после продирания через мешанину библиотечных накладных расходов.

Правда, _иногда_ все же не хватает type inference/type checking - но достаточно редко. И, в основном, для отлова всяческих 'thinko' - тупых ошибок, которые плюсовый компилятор отловил бы сразу, а перл не замечает.

>GUI drScheme написан на каком языке?
Сам себе же отвечаю: на схеме. И вроде сносно работает (с 3-й версии), по крайней мере, свои задачи выполняет.

> Вы таки имеете ввиду xml, js?

Я имею в виду прежде всего использование [X]HTML как протокола визуализации. А XML и JS лишь придают картине законченный кретинизм.

> Какие ваши предложения?

Покопайся в истории и в современной литературе. Code Migration существует довольно давно. NeXT (DPS aka Display PostScript), Java applets и пр. Я не говорю, что Java applets - идеал, но это была, да и сейчас есть, реально действующая технология. Прогресс в этой области, как ни странно, не то что стоит, а даже и назад, по-моему, движется (глядя на AJAX). Да и если говорить о HTML+XML+JS, то, рискуя начать очередной флейм на заезженную тему, скажу, что s-expressions рулят, ПМСМ.

anonymous (*) (13.03.2006 20:35:42):

> И что жы такое нужное для ГУЯ умеет C, чего не умеет Perl/Python?

1. Да с системой взаимодействовать хотя бы! Система-то на Це написана...

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

Разумеется, если разработка проекта сразу совмещена с кодированием (как это ныне принято), language-native семантика (и замыкания;)) вполне себе юзабельны в качестве средства разработки. Только, вот, качество на выходе хреноватое получается.

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

Действительно, формулы, как правило, вполне вписываются в функциональную парадигму, но почему-то все математики пишут статьи вполне императивно! Более того, чем в более "функциональном" стиле написана статья, тем она менее читабельна -- это факт, выработанный столетиями практики.

Короче, мне нравятся по возможности более низкоуровневые императивные алголоподобные процедурно - ориентированныне языки типа Це, Паскаля, Ады, etc. При существующих структурах вычислительных систем, все прочие изобретения типа ООП, функциональщины и доведенной до абсурда декларативщины (типа Пролога) мне кажутся просто излишне пропиаренными.

Другое дело, что 90% ежедневно решаемых задач для продвинутого пользователя любого современного компьютера составляют разовые приблуды, которые, действительно, удобно писАть "на коленке" на чем-нибудь динамическом типа Перла или Питона. Но это _не_ большие проекты!

2 Die-Hard :

> > И что жы такое нужное для ГУЯ умеет C, чего не умеет Perl/Python?

> 1. Да с системой взаимодействовать хотя бы! Система-то на Це написана...

Мне вообще-то казалось, что ты не "пионэр" и не будешь рассуждать о
том, чего сам не знаешь.
Из Perl доступен большая часть "традиционного" Unix API, включая
POSIX/SUS интерфейсы. И это работает "из коробки", в Perl стандартной
комплектации. Кроме того, для Perl написаны биндинги к большинству
мало-мальских популярных сишных библиотек. Самые популярные включены
в стандартную комплектацию Perl, другие доступны с CPAN.
Что приятно, хорошо написанный биндинги придают сишным библиотекам
perl'овый look'n feel, что упрощает работу с ними.
И наконец - для Perl написать расширение (модуль) на C - как два
байта переслать ;-) Если у тебя есть готовая C библиотека, заюзать
ее из Perl не представляет никаких проблем.

(Python не знаю но подозреваю, что с ним все обстоит примерно
аналогично)

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

Непонятно, что есть "хэндлы" и как их надо "крутить" :-)))
Если ты имеешь в виду "хэндлы" для обработки именно GUI событий,
то IMHO язык тут не виноват. Посмотри хоть на Qt (C++) - тоже
без бутылки не разберешься ;-)

> Другое дело, что 90% ежедневно решаемых задач для продвинутого
> пользователя любого современного компьютера составляют разовые
> приблуды, которые, действительно, удобно писАть "на коленке" на чем-
> нибудь динамическом типа Перла или Питона. Но это _не_ большие
> проекты!

Глупо думать, что "большие проекты" можно писать на одном-единственном
языке:-))) Потому он и большой, что в нем есть куча разных частей,
требующих _разных_ подходов и _разных_ языков - включая всякие
embedded scripting языки, SQL, специализированные DSLи и т.д.
И в грамотном выборе инструментов (в том числе и языков) для проекта
собственно и заключается немалая часть профессионализма.

HTH

P.S. А я вот книжку по Ruby купил ;-)

> > И что жы такое нужное для ГУЯ умеет C, чего не умеет Perl/Python?

> 1. Да с системой взаимодействовать хотя бы! Система-то на Це написана...

Уже написали. Наглое вра^W^W - неправда это, короче ;) Nothing personal.

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

Не вижу, как это зависит от языка. Более того, есть Not So HO, что объекты (в смысле "ссылка на нечто с методами") сильно более прозрачны, чем opaque handles или структы функций, столь распространенные в C. Т.е. на перле или даже плюсах я могу, по крайней мере, насовать виджетов в контейнер и потом сделать какую-нибудь гадость типа foreach @widgets {$_->redraw() if can($_, 'redraw')} На C это будет сильно более громоздко, если тулкит не озаботился эмуляцией полиморфизма.

> Разумеется, если разработка проекта сразу совмещена с кодированием (как это ныне принято), language-native семантика (и замыкания;)) вполне себе юзабельны в качестве средства разработки. Только, вот, качество на выходе хреноватое получается.

Я человек молодой, и нихрена не помню - но это такой типа UNIX way, "release early, release often", "inside out programming" и "eat your own dogfood" придумали как раз в 70-е, а не сейчас. Я очень сильно сомневаюсь, что "Design and Implementation of UNIX Operating System" на самом деле включал формальную фазу проектирования ;)

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

Последнее утверждение спорно - просто почти не бывает людей, _сначала_ ставших компетентными математиками, а потом увидевших компьютер. В те же 60-70-е их было сравнительно много - и мы получили LISP. Сейчас VB и JS (или паскаль 15 лет назад, как я) школьники-энтузиасты узнают в 12-15 - и мозг уже потом не перекроить.

По поводу первого же - современный Perl, с source filtering умеет все, что и CL. Если производительность не важна (в смысле, цена высокоуровневой логики на порядки меньше, чем всяких сортировок и фильтров многогиговых данных, выполняемых оптимизированным сишным кодом) - то макры заменяются higher order функциями, и все.