на всеобщий опрос программеров отвечаю

1
преимуществ никаких, сплошные недостатки

2
абсолютно всеравно для какой ос писать

3
нет, например в AIX 90% кобол предпочитают джаве
4
вобще хачу французкий попробовать, а в смысле программирования print и в африке print

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

-

1 Гемморой с поддержкой более чем одного кода он и в Африке гемморой ;)

2 Ту которая позволяет максимально быстро и эффективно решить твою задачу и для той по которой больше документации и инструментов ;)

3 Так как платформа выбирается под задачу (а не наоборот) Вашего вопроса не вижу (задача какая?)

4 Тот, который максимально подходит для решения моих задач ;)

-

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

Угу, а толку от такого знания ? ;)

Программлю все равно токо на одном и так не только со мной ;)

Даже если в проекте используется более одного языка - народ в команде _как_правило_ специализируется на одном

много языков обязан знать постановщик шоб при проектировании не возникало глупых ситуаций ;)

Мамы разные нужны...

> 1) Приемущества и недостатки программирования для разных ОС

1. Начиная с нуля, для любой ОС: никаких, есто только своя специфика.

2. Если имеешь опыт в одной ОС, а надо работать в другой: различия в специфике кажутся (первое время) недостатками.

3. При переносе ПО с одной ОС на другую (AKA порт): см. п.2 + подробнее по некоторым из распространённых случаев (из личного опыта)

a. UNIX -> Windows : Небольшие траблемы в сетевой части, если это Sockets. Большие - если XTI. С filesystem и multithreads - средние (зависит от типа threads, например win не поддерживает стандарт ISO/IEC 9945-1:1996 AKA POSIX.1) Если прожект использует одновременно много специфичных для UNIX вещей в т.ч. X11, проще пользоваться эмуляцией unix-среды, типа cygwin, dejagnu и пр.

b. Windows -> UNIX : Аналогично пп.a но в большей степени. Если Qt, gtk, omf ещё как-то представлены в win, то качественные аналоги MFC, ATL для unix ещё поискать надо. Прожект, исп. VCL ещё худо-бедно можно перенести посредством Kylix, но не всегда.

c. Linux -> FreeBSD : Всё зависит от уровня(или опытности) автора исходной программы. В общем случае грамотно спроектированное ПО для unix переносимо. В частности, для Linux - далеко не всегда. Дело в том, что Linux предоставляет много специфичных подходов дополнительно и даже взамен стандартных в UNIX решений (например доступ к канальному уровню сети). Программист, имеющий опыт работы только в Linux склонен, как правило, использовать такую специфику даже там, где в этом нет необходимости. В результате мы имеем ПО, жестко привязанное к ОС. Конкретно по выше приведённому примеру - допустим это учёт трафика: SVR4-only вариант использует DLPI, BSD-only - BPF, linux-only вариант - SOCK_PACKET, переносимый UNIX вариант - стандартную библиотеку libcap, которая скрывает зависящую от системы реализацию перехвата пакетов (кстати, существует и вариант этой библиотеки для win32 - winpcap, на основе которой, например, создан windump - windows-порт утилиты tcpdump).

d. FreeBSD -> Linux : То же, что и в пп.c , но в несколько менших масштабах. По моим личным наблюдениям у программистов, пишущих для freebsd склонность к излишней привязке к системе выражена не так сильно.

> 2) Высказать личное мнение для какой ОС лучше программится. Особое внимание уделите возможностям и сложности.

Если лучше - значит проще, то лучше всего - для CP/M, немного хуже - для DOS, ещё хуже win, unix. Возможности (AKA сложность) - в обратном порядке ;)

> 3) Java - панацея для моего вопроса? :)

Для кросс-платформенности - в какой-то мере да. Но за всё надо платить. За повышенную переносимость надо платить сниженной эффективностью, скоростью, повышенной требовательностью к ресурсам, более узкими рамками языка и имеющихся в распоряжении возможностей исполняющей среды. Реальное решение - это всегда компромисс. Иными словами - какой вопрос, такой и ответ :)

> 4) И какой язык предпочитаете.

Если есть альтернатива, я (лично) чаще всего предпочитаю C и C++, но в некоторых случаях Java, Perl, Tcl, shell(awk|sed|e.t.c.) и даже JScript (в DHTML).

PS: Серебряной пули нет :)

Знакомый програмист говорит, что хуйню надо писать на TKL-TK, а все остальное на Си. Тогда одни и те же проги будут работать и в маздае и в линуксе.

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

нормальные проги надо писать на ассемблере...

Толку - то, что УНИВЕРСАЛЬНЫХ ЯЗЫКОВ НЕ БЫВАЕТ. Так что приходится выбирать языки под задачу. Однако, где-то в 90% случаев проект должен состоять из 4х языков - скриптовая обёртка, внутренний скрипт, "движок" (куда всякие bottleneck-и входят) и DSL (часто совпадает с внутренним скриптовым языком, но может разрабатываться специально под задачу). Однако же, знать менее 10-15 языков, и называть себя программистом - просто смешно - задачи то разные, и эти 3-4 языка для разных задач совпадать не будут.

-

2vilfred

>нормальные проги надо писать на ассемблере...

а де же смайлик ? ;)

-

2Antichrist

использовать более 2-х языков для проекта - дурной тон замучаешся поддерживать (языки имеют свойство развиваться причем БЕЗ обратной совметсимости - пример C++) то про что ты написал - годится только для внутреннего использования - принцип прост чем больше ты придумываешь межъязыковых интерфейсов (по делу и неподелу) тем сильнее усложняется системв а лишнее число степеней свободы ненужно нафиг

>эти 3-4 языка для разных задач совпадать не будут.

слава богу большая часть моих задач требует 1 максимум 2-х языков...

PS: ну знаю я 10 языков и что ? Больше 2-х одновременно я никогда в проектах не использовал (ну если не считать за язык HTML ;))

PPS: А то - что используется как внутренний скриптовый язык проекта я вообще за язык не считаю ;) потому как не мне на нем программить я ендлузеру ;)

Я уже давно на anekdot.ru не хожу. Мне LOR-а хватает. Даже если уйдут главные клоуны (vilfred, mark, ...), на их место прибежит с десяток новых.

RE:

> олку - то, что УНИВЕРСАЛЬНЫХ ЯЗЫКОВ НЕ БЫВАЕТ. Так что приходится выбирать языки под задачу. Однако, где-то в 90% случаев проект должен состоять из 4х языков - скриптовая обёртка, внутренний скрипт, "движок" (куда всякие bottleneck-и входят) и DSL (часто совпадает с внутренним скриптовым языком, но может разрабатываться специально под задачу). Однако же, знать менее 10-15 языков, и называть себя программистом - просто смешно - задачи то разные, и эти 3-4 языка для разных задач совпадать не будут.

10-15 языков - мда...

Вынужден признать, что 10-ти ЯП я не знаю. Но думаю, что и не узнаю, ибо текущего набора вполне хватает, а я человек достаточно ленивый - без особой нужды напрягаться не люблю. Может всё-же смягчить требования к тем, кто "называет себя программистами" в части кол-ва языков? Или ввести градации: Скажем так, есть гении, есть универсальные программисты, есть просто программисты, и есть узконаправленные программисты (например в 1С) - и каждый из них профессионально делает своё дело в рамках собственной специализации.

Как так хватает? 10 - это только-только с существующими подходами познакомиться.

Как минимум по одному языку из каждого класса: C, Tcl, *sh, Python, Lua, Java, Eiffel, Lisp (или Scheme), Forth (или PostScript), ML, Haskell (или Clean), Ada, Prolog (или Mercury), Mozart Oz. Ну и кучка совсем специализированных, вроде *yacc.

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

Не замучаешься поддерживать. Главное - с говном вроде C++ вообще не связываться. И интерфейсы никакие придумывать не надо - это же блин unix, тут свой way есть - пайпы - лучший интерфейс.

re:PS: не еврю, что это было лучшим решением.

re:PPS: как это не тебе? Как минимум рантайм всякий, библиотеку, и т.п. тебе писать, чтоб эндлузеру жилось лучшее...

RE:

Ну как сказать?

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

2. Некоторые из приведённых языков, я не выделял бы в особую группу (по разным причинам, например из за семантической схожести), некоторые вообще не считаю за языки (PS, yacc), некоторые можно назвать "мёртвыми" или "рудиментарными".

Ну и, наконец, за "гадость" я держу отнюдь не C++, а как раз Eiffel, Haskell и иже с ними.

PS: По поводу велосипедистов полностью согласен - вреда от них зачастую больше, чем пользы.

Спасибо. Полезную информацию вы мне преподнесли. Я ещё мало разбираюсь в программировании, но могу добавить в защиту С++, что этот язык используется при разработке почти всех ОС и различных проектов также. Поэтому очень полезно его знать при разработке для разных ОС.

1. Как это "неудобно"? Необходимо. Задачи ведь действительно всё время разные - вот и языки разные использовать придётся.

2. Я знаю, что Питона, Eiffel и Жабу можно было бы в одну группу засунуть, но, так сказать, есть нюансы - система модулей, лямбда в Питоне, и т.п. Существенные нюансы - как минимум для того, чтоб заниматься разработкой собственных языков (e.g., DSL-ей).

То, что лично ты не считаешь PS за язык - так то ты дурак, это твои половые трудности. По всем критериям PS - полноценный язык. Yacc и компанию - я так и отнёс к очень специфичным DSL-ям, которые необходимо знать для разработки собственных DSL-ей - уж больно это сверхсуперпуперобщий паттёрн - FSM - от парсеров до серверов юзается.

Про "мёртвые" языки - вообще не понял. Мёртвых языков не бывает.

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

-

>И интерфейсы никакие придумывать не надо - это же блин unix, тут свой way есть - пайпы - лучший интерфейс.

Дык не везде это проходит к сожалению ... пайпы конечно же хороши
но уж слишком велики накладные расходы. В моих задачах внутренний интерфейс на пайпах целиком не сделаешь - а вот IPC между мастером и слейвами, и частично с постпроцессором на них родимых ;)

>re:PS: не еврю, что это было лучшим решением.

Дык проверено временем :)

В моей предметной области сейчас наблюдаются 2 тенденции.

Изначально софт писался по традиционной 3-х уровневой схеме

- препроцессор (навороченный скриптовый язак + GUI)
- сольвер ( собсно сама "решалка-считалка")
- постпроцессор (навороченный GUI + экспорт результатов в мильёне форматов)

Тенденции такие:

1) Сделать все попрощи и полегче но all-in-one
сейчас это весьма популярно среди людей из промышленности
(сам имею заказы на такую фигню "с ополаскивателем" ;))
Мне даже один из заказчиков высказал пожелание "иметь такие же вентеля на управляющей панели как на реальном железе" ;)))

2) Пакеты рыссыпаются на вполне самостоятельные и совершенно отдельные компоненты то есть препроцессор отдельно (при этом он умеет готовить данные для тучи сольверов) сольвер отдельно + куева туча расширения
для всяких разных поз из камасутры ;) постпроцессор отдельно - причем
сейчас он уже умеет импортировать данные из тучи сольверов

>re:PPS: как это не тебе? Как минимум рантайм всякий, библиотеку, и т.п. тебе писать, чтоб эндлузеру жилось лучшее...

дык библиотека то не на скриптах пишется ;)

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

Про предметную область - не распознал, о чём речь, однако: all in one - определённо не решение, то, что логика и GUI не должны быть закодированны в одном месте - можно считать, что совсем аксиома. Даже в случае жесткой нехватки ресурсов.

Про препроцессор - это то и есть самое место для другого языка, отличного от языка логики. И тут фантазии есть где порезвиться, от Хаскелля (см. крутейший препроцессор WASH) до Форта...

Про рантайм - плох тот язык, чьи рантайм-библиотеки в основном не на нём же самом писаны. ;)

Приветствую.
10-15 языков ... это сильно... хм /представив себе - сколько дев придётся юзать .. или же какой код будет если статично собирать .. иначе при переносе с одной машины на другую - возникнут неприятности.../
про GUI - вещь по себе приятная, но необходимая ... смотря что за задача/
а вообщем не спец я . так - немного личных впечетлений .. -)
Best respect,$echo.
P.s. Начните с Питона, если опыт минимален.
и еще - писать надо под конркетную задачу, тогда намного эффективнее.
Можно на досуге читать код /например на сях -в целях ознакомления/.

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

призываю успокоиться и не петушиться

yesssss )))
Best respect,$echo.

Ты бы хоть подписывался, ебанат пизданутый. Может, ТЫ, уёбок, считаешь себя "программистом"? Тогда докажи. Устроим тебе проверочку, порвём онанимного подонка на британский флаг. Ссышь, мудило? Умер уже?

Сегодня воскресенье, если ф что. Выходной. Отдыхает Человек.
А Вас часто бьют ? Или Вы в реале пай-мальчик?
....
$echo.

кто-то пёрнул чтоли???
аааа... антихрист крякает... ну пусть их...

>>Спасибо. Полезную информацию вы мне преподнесли. Я ещё мало разбираюсь в программировании, но могу добавить в защиту С++, что этот язык используется при разработке почти всех ОС и различных проектов также. Поэтому очень полезно его знать при разработке для разных ОС.

Каких "почти всех"? ОС, давшая название этому сайту, пишется на С

RE:

> 1. Как это "неудобно"? Необходимо. Задачи ведь действительно всё время разные - вот и языки разные использовать придётся.

Совсем не обязательно, если все эти задачи удобно решаются в рамках одного языка. Я не встречал задач, которые бы не решались посредством C++. Возможно что-то специфичное несколко удобнее реализовать на более узком языке - знаю, что сортировка в HUGS занимает около 3 строк, аналог на С больше - ну и что? Это ещё не аргумент. Используя C++ STL это тоже займёт 3 строки. Качественное отличие здесь в том, что STL реализована средствами самого C++, что говорит о гибкости этого языка. А вот если PLSQL от Oracle не способен работать с файлами, каталогами и пр. то добавить в него эти способности можно лишь через подключения доп. пакетов, реализованных на _других_ языках. Можно возразить, мол PLSQL не предназначен для работы с FS - всё верно: это специализированный язык, и в нём очень легко и удобно решается класс задач, под которые он заточен. Но как только мы выходим за рамки специфики, начинаются сложности. В реальной жизни получается так: успешно завершив 90% проекта на таком спец.языке, команда на оставшихся 10% испытывает такие трудности, которые сводят на нет все предыдущие "удобства". Получив однажды такой опыт, наша группа раз и навсегда отказалась использовать узконаправленные языки, кроме случаев, когда это _действительно_ необходимо (кстати, такие случаи - очень большая редкось, и основаны они чаще всего на капризах стороны заказчика).

> 2. Я знаю, что Питона, Eiffel и Жабу можно было бы в одну группу засунуть, но, так сказать, есть нюансы - система модулей, лямбда в Питоне, и т.п. Существенные нюансы - как минимум для того, чтоб заниматься разработкой собственных языков (e.g., DSL-ей).

Фунциональное программирование вообще поддерживается в STL. В частности, лямбда-абстракции давно реализованы в C++ , как пример BLL (boost::lambda). Причём реализованы не как чужеродные библиотеки, а на самом C++ (о чём это говорит - см. выше). Что касается разработки т.н. DSL - не вижу необходимости использовать "систему модулей". В проекте С мне достаточно таких утилит, как zubr или bizon, yacc или antlr и поддержки DSO API dlopen, dlfunc, dlsym, если библиотека с языком должна быть динамической. На C++ я могу использовать boost::spirit для создания собственно сканнера и синтаксического анализатора (по спецификации EBNF), не выходя за рамки языка и не пользуясь никакими внешними инструментами. Кстати, преподносимое как преимущество Eiffel над Java и C# решение проблемы одноимённых функций прекрасно решается в C++ путём виртуального наследования (сам же eiffel мне не нравится из за синтаксической схожести с pascal, но это дело вкуса).

> То, что лично ты не считаешь PS за язык - так то ты дурак, это твои половые трудности. По всем критериям PS - полноценный язык. Yacc и компанию - я так и отнёс к очень специфичным DSL-ям, которые необходимо знать для разработки собственных DSL-ей - уж больно это сверхсуперпуперобщий паттёрн - FSM - от парсеров до серверов юзается.

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

> Про "мёртвые" языки - вообще не понял. Мёртвых языков не бывает.

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

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

В Haskell реализована только одна "революционная" идея - функциональное программирование. И на этой идее свет клином не сошёлся - это верно также, как и то, что далеко не все задачи сводятся к написанию конвертеров, на что и ориентирован Haskell. Язык этот узконаправленный, со всеми вытекающими из этого недостатками (см. выше). Идеи черпают не из языков, но из головы(своей или чужой), а в языках эти идеи реализуют. И ещё раз повторю: C++ позволяет мне НЕ пользоваться другими языками на любом уровне, от работы с аппаратными ресурсами до высоких абстракций, даёт в распоряжение большое кол-во С и С++ кода для повторного использования. В результате получается проект с однородными модулями, не испытывающим сложности во взаимодействии. И это _лучше_, чем использовать зверинец из нескольких десятков спец.языков хотя бы потому, что экономит время, которое пришлось бы затратить на решение вопросов совместимости. Я думаю, ты сможешь это понять, если перестанешь "вставать в позу" и начнёшь думать.

Сколько бреда...

Да, средствами Сри++ можно решить любую задачу. Но какой ценой?

Ещё раз - УНИВЕРСАЛЬНЫХ ЯЗЫКОВ НЕ БЫВАЕТ. И нежелание использовать несколько разных языков в одном проекте - это уже из разряда религии (ну или психиатрии). НИКАКИХ ПРОБЛЕМ С СОВМЕСТИМОСТЬЮ НЕТ (но ты думать не желаешь, и уж тем более не желаешь и не способен учиться - так что изволь принять это утверждение на веру - проверить его - силёнок у тебя не хватит).

Про ФП на этом детсадовском убожестве STL - просто смешно. STL вообще стыдно в приличном обществе упоминать...

Haskell - ну, блин, не хрен тут так кичиться своей непрошибаемой безграмотностью. ФП - вообще в 30х годах появилось, никаких Гоферов ещё не было. Нового в Хаскелле - классы типов, автоматический вывод реализаций интерфейсов некоторых классов, и т.п. Хаскелл - не узкоспециализированный язык (как бы там всякое императивное быдло не визжало), он ничуть не менее универсальный, чем C++.

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

RE:

> Да, средствами Сри++ можно решить любую задачу. Но какой ценой? Ещё раз - УНИВЕРСАЛЬНЫХ ЯЗЫКОВ НЕ БЫВАЕТ. И нежелание использовать несколько разных языков в одном проекте - это уже из разряда религии (ну или психиатрии).

Говорил уже: к использованию одного языка я пришел _опытным_ путём - религия и[ли] психиатрия тут не причём :) Опять же, если цена решения на C++ ниже, есть смысл его и использовать, не так ли?

> НИКАКИХ ПРОБЛЕМ С СОВМЕСТИМОСТЬЮ НЕТ (но ты думать не желаешь, и уж тем более не желаешь и не способен учиться - так что изволь принять это утверждение на веру - проверить его - силёнок у тебя не хватит).

Это не Foreign.C ли решает все проблемы? ;D На веру я уже давно ничего не принимаю, а мои проверки доказывают обратное - их не рашают ни haskelldirect, ни greencard. Благо возможностей проверить у меня предостаточно.

> Про ФП на этом детсадовском убожестве STL - просто смешно. STL вообще стыдно в приличном обществе упоминать...

Голословное утверждение.

> Haskell - ну, блин, не хрен тут так кичиться своей непрошибаемой безграмотностью. ФП - вообще в 30х годах появилось, никаких Гоферов ещё не было.

Ты наверно о prolog? Не знаю, как на счёт 30х годов, но смею заметить: "за бугром" о ФП стали писать только в 1978. И я ничуть не сожалею, что в далёкие школьные времена, присматриваясь к ЯП, не повёлся на всякие lazy evaluation, и выбрал С. /* да, мне повезло - у меня был выбор, в то время как многим так или иначе был навязан basic в качестве Первого языка ;) */ Кстати, все программисты, использующие т.н. 4GL вынуждены пользоваться "презренным" с их точки зрения "low-level how" для оптимизации своего "high-level what" (если SQL запрос работает недопустимо долго - тут уж никуда не денешься, будешь вставлять CHANGE RULE|COST и.т.п.), цинично умалчивая это и задирая нос, а стОит ли?..

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

Неаргументированный выплеск эмоций, ну да ладно - вызов принимается. Итак по порядку:

Фукциональность классов типов в C++ реализуется посредством шаблонов(вложенных, если нужно) классов и ф-ий. Автоматический вывод AKA догадки компилятора об умолчаниях программиста есть зло и источник ошибок. А само понятие интерфейс подразумевает то, что компилятор НЕ должен строить никаких предположений о его (интерфейса) реализации. Об универсальности - С++, позволяя функциональный подход, одновременно предоставляет возможность детальной оптимизации алгоритма и контроля на низком уровне. В результате код, полученный после компиляции той же самой программы сортировки (которую так любят приводить в пример, с акцентом на кол-во строк) с использованием метода in-place, register vars и пр. на C++ будет работать быстрее и требовать меньше памяти. В haskell такая оптимизация "руками" не предусмотрена(только не надо приводить в пример костыли из GHC - расширения те не входят в стандарт языка), ибо это яркий представитель 4GL (причём далеко не самый удачный) и на данный момент является (и долго ещё будет) узкоспециализированным языком. И на последок о гибкости языка - а низкоуровневые пакеты типа System.Posix.IO или Network.Socket реализованы на самом haskell?

>вынуждены пользоваться "how" для оптимизации "what"

Не повод ли это для неиспользования "how" вообще? ;-)

>Фукциональность классов типов в C++ реализуется посредством шаблонов

При этом уродливее(менее красиво) чем в том же хаскеле.

>догадки компилятора об умолчаниях программиста-зло и источник ошибок.

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

>компилятор НЕ должен строить предположений о реализации интерфейса

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

>С++, позволяя функциональный подход Могу себе представить текст, реализующий что-то типа тривиального (f1 a1 . f2 a2) a3 ;-)

>Об универсальности - С++ ... >haskell является узкоспециализированным языком

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

Какой то holy war получается :-). Но все же, чем неугодны Foreign.C, и (опциональный) lazy evaluation?

> а низкоуровневые пакеты типа System.Posix.IO или Network.Socket реализованы на самом haskell?

Ну, если да - то язык _очень_ гибок, если нет - то с расширениями на других языках очевидно нет проблем :-) Оба исхода - в пользу хаскеля IMHO:-).

Re:

>Не повод ли это для неиспользования "how" вообще? ;-)

Скорее, именно в этом кроется причина использования n-дцати языков в одном проекте 8)

> При этом уродливее(менее красиво) чем в том же хаскеле.

Возможно, но терпимо, а после привыкания и вовсе видится красивым ;)

>Однако позволяет не тратить время на описание очевидных вещей.

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

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

Т.е. чтобы создать экземпляр класса? Ну, компилятор C++ требует для этого реализации всех абстрактных методов, Java не требует. Определять тут нечего.

> Могу себе представить текст, реализующий что-то типа тривиального (f1 a1 . f2 a2) a3 ;-)

Представь есть такое, вот пример (это парсер):

a = b >> *(('+' >> b) | ('-' >> b)); b = c >> *(('*' >> c) | ('/' >> c)); c = int_p | '(' >> a >> ')' | ('-' >> c) | ('+' >> c);

или вот:

int i = 4, j = 5, k = 6; cout << ((arg1 + arg2) * arg3)(i, j, k);

factorial(arg1 * 6 / factorial(var(i)));

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

Да мало-ли чего говорят - главное, чем пользуются...

> Какой то holy war получается :-).

Типа того. Борьба теми же методами 8) Если серьёзно, просто достали постоянные плевки и вопли разных скандально известных персонажей в сторону C++.

> Но все же, чем неугодны Foreign.C, и (опциональный) lazy evaluation?

Да не говорил я, что Foreign.C неугоден. А отложенные вычисления достаточно неэффективно реализуются (с точки зрения потребления ресурсов), поэтому в критичных случаях логично иметь возможность их отключать.

> Ну, если да - то язык _очень_ гибок, если нет - то с расширениями на других языках очевидно нет проблем :-)

Ээ, так можно всё мировоззрение к ..м свести, как в известном анекдоте ;)

Расширения пишутся _специально_ для языка (который очевидно и сам на чём то написан), а совместимость рассматривается в контексте использования других модулей, изначально не предназначеных для взаимодействия с данным. Чувствуешь разницу - кто под кого прогибается? :))

Вообще в теории FP отрицается понятие императивности, но многие задачи решаются _лучше_ (а некоторые _только_) императивным путём. Это доказывает бОльшую универсальность императивного подхода, нежели функционального. В функциональных языках с этим приходится мириться, вводя поддержку императивов, и Haskell не исключение. Развитым возможностям генерации списков этот язык обязан именно IP (ибо список это монада). И реализация IP через монады выглядит убого по сравнению с реализацией FP через STL. В этом плане Ocaml и даже Clean более универсальные и практичные языки, чем Haskell. Хотя уникальные типы в Clean - тоже не верх совершенства, но в нём хотя бы есть возможность отключить отложенные вычисления.

PS:

Ладно, надоело спорить. В мире достаточно самостоятельных людей, которые способны решить для себя, какой язык является наиболее практичным, а какой "для оригинальных чудаков", далёких от реальности. Распространённость ЯП расставляет всё на свои места. Глупо считать себя Цезарем и свою точку зрения единственно правильной, списывая её неразделённость большинством на ограниченность последнего. Если предоставить право выбирать для отдыха кресло или горшок, большинство предпочтёт первое, поскольку это удобнее (при отсутствии анатомических аномалий наподобие хвоста и болезней вроде геморроя, конечно), что и отразит статистика. Хотя некоторые "бесхвостые" бездумно последуют примеру "хвостатых", но и в большинстве, и в меньшинстве будет одинаковый процент сторонников, примкнувших повинуясь только инстинкту ассимиляции. И одинаковый процент тех, кто принимал решение сознательно и индивидуально, не ориентируясь на "общее мнение" - следовательно, статистика верна.

>Ладно, надоело спорить.

А я уже успел отдохнуть :-). Но ладно, спорить не буду - просто пара замечаний:

>в этом кроется причина использования n-дцати языков в одном проекте

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

>очевидное для программиста - не всегда очевидно для компилятора

Если бы правилах 8-ки нужно было заказывать очевидные удары, эта игра, скорее всего, была бы давно забыта :-) IMHO.

>А отложенные вычисления ... логично иметь возможность отключать.

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

>Это доказывает бОльшую универсальность императивного подхода

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

>реализация IP через монады выглядит убого по сравнению с реализацией FP через STL

Да нормально она выглядит. Местами менее красиво, чем в империтивных языках, и, вероятно, с ограничеными возможностями, но то же справедливо в отношении FP в C++.

>Распространённость ЯП расставляет всё на свои места

Но при этом она говорит _только_ о распространенности и о простоте идей, лежащих в основе языка. Эти параметры не гарантируют технологической правильности выбора. Хотя, вероятно, существенно влияют на правильность экономическую - снижая стоимость рабочей силы.

Вот куда кривая завела(-: потеоретизирую слегка:-) Есть 2 критерия, определяющих популярность языка:

1. Требовательность к качеству мозгов рабочей силы. Очевидна обратная зависимость от данного параметра.

2. Ориентированость бизнеса ПО на прибыль и, как следствие, желания работодателей уменьшать расходы на рабочую силу. Что возможно при большой популярности и широкой доступности рабочей силы средней квалификации. [Собственно, это же относится и к любому другому коммерческому производству - предпочтение отдается не качественным но дешевым вариантам.]

Разрыв этой цепи с положительной обратной связью возможен при значительной конкуренции на рынке. Но, к сожалению, современное состояние рынка ПО таково, что он склонен к монополизации - за счет закрытости протоколов, патентов,..., и, как следствие, высокой стоимости смены програмного обеспечения. Посему ему конкуренция не грозит. И Хаскель со товарищи останутся слабораспространенными :-( Пока.

RE:

Логично...
Вспомнил в тему один афоНАризм:
Если требования всех заказчиков ПО свести к 3-м пунктам -
"чтобы это было качественно, быстро и дёшево",
то ответы всех программистов сводятся к одному -
"мы можем соблюсти любые 2 требования из указанных одновременно" 8)

А спорить я начал, собственно, из за фразы "Главное - с говном вроде C++ вообще не связываться" и продолжил в ответ на уточнение "он является самым ублюдочным и криво спроектированным языком из всех, когда либо созданных человечеством"...
ИМНО такие сентенции подразумевают, что разумность создателя языка, а в купе с ним и всех, кто его(язык) поддерживает или им пользуется, ставится под сомнение.
Авторитетно заявить такое взрослый, умственно полноценный и отдающий себе отчёт человек просто не может, не подтвердив предварительно своей компетентности (которая должна быть, по крайней мере, на уровне автора языка).

PS:
Ну и ещё причина - мне такие баталии полезны в качестве практики - по работе приходится часто "бодаться" с заказчиками, мнущими себя достаточно граммотными для того, чтобы указывать способы реализации своего заказа ;) И борьба эта осложняется 2-мя ограничениями:
во первых нельзя обижать (потому конструкции "не учи отца и баста" не применимы, и во вторых, спорить нужно, опускаясь до уровня знаний заказчика, иначе он, не поняв о чём речь, просто не воспримет аргумент :)
А ЛОР - идеальная среда для моделирования таких ситуаций :))

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

Хорошо получается IMO :-)

Мдя, "а где-же антихер?" спросит любознательный читатель - известное дело, в саду. Надо бы запомнить линк на данную дискуссию и при случае указать. Красиво, с чуЙством, с толком, с расстановкой.
loki respect!
Mimino.