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

Убогий LOR ругается на слишком длинный текст.

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

Это личные тараканы, имхо. Довольно очевидно, что, например, ООП часто вылезает в не-ООП языках (ядро, GTK) - и выглядит коряво.

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

Язык должен соответствовать задаче. И если система с плане логики "разная" - то либо вы используете несколько языков с разными подходами, либо реализуете "другие" подходы на основе вашего основного языка (в императивщине на схеме, или реализации backward inference в логике предикатов на С нет ничего необычного - это просто серийное изобретение велосипедов), либо используете язык, в котором синтезированы все нужные подходы (CL, Perl, C++ - как видно из списка, за это приходится платить монструозность и "особенностями" языка).

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

Ближе к 99%.

> Но это _не_ большие проекты!

А для больших проектов важна, скорее, дисциплина проектирования и реализации, чем язык. Существуют вполне успешные немаленькие и сложные системы на том же перле (навязший в зубах Amazon, хотя бы - я думаю, у них тонны и тонны нетривиальной маркетинговой логики унутре). Сам писал морду/логику биллинга на перле - 500kloc/5 человек, и ниччо (это, конечно, не большой проект - но и не наколенная поделка на один раз). И существует масса косых поделий на C *да и на Ada, я думаю, найдется - просто ее меньше людей знает ;)

Короче, то, что нужно сначала думать, потом делать, применение "скриптовых" языков не отменяет. А, подумавши, реализовать план, имхо, проще на языке с более богатой семантикой, а не с более бедной.

Вопросы производительности же - совсем отдельные.

> А, подумавши, реализовать план, имхо, проще...

...в Гарлеме? :) Или в Дании?

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

Хоть это и не относится к дискуссии, не могу не упомянуть книжку:
"Higher Order Perl" by Mark Jason Dominus (ISBN: 1558607013)

Не все главы одинаково интересны, но книжка весьма достойная.
IMHO особенно глава 7: Higher-Order Functions and Currying.
(у меня есть PDF, если кому надо - можно организовать)

Die-Hard:
>
> Ну да, Перл несколько особняком стоИт. На нем, действительно,
> легко лабать простенькие приблуды для своих целей, когда
> шелла не хватает.
>
> Но IMHO чуть что посложнее на Це получается проще.

все-таки, думаю, "это зависит".

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

для меня преимущества Це для большого проекта, это:

1. в "C" меньше ошибок (в компиляторе).

2. он меньше меняется. те, при переходе к следующей версии
   perl у нас больше шансов поломать проект, причем поломка
   может сразу и не проявиться.

3. вся библиотека, поставляемая с perl - IMHO, очень плохо
   написана. ну, почти вся. я ее никогда не использую.

4. хорошо написанный код на "C" ЗНАЧИТЕЛЬНО ЛЕГЧЕ МОДИФИЦИРОВАТЬ.
   все-таки, типизация.

последнее - самое важное. означает, в частности, что совместная
разработка на "C" гораздо надежнее.

тем не менее, на perl почти всегда гораздо проще. низкоуровневые
примитивы, конечно же можно и на "C" написать, perl довольно легко
(хотя и не так легко, как хотелось бы) позволяет использовать .so
или просто встраивать С код в XS.

лично я реализовал (те, начал и закончил самостоятельно) только
один "большой" (по моим меркам) проект. управляет железяками на
сумму порядка 20 миллионов $, работает в десятках городах страны.
0 программных ошибок за 5 лет эксплуатации. multimedia, realtime,
между прочим.

написан - в основоном - на perl. драйвера, несколько низкоуровневых
библиотек - на "C".

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

> Разумеется, если разработка проекта сразу совмещена с
> кодированием (как это ныне принято)

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

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

не очень я верю в спецификации любого рода, кроме собственно
кода. devil in the details. другое дело, что думать, конечно
надо. кому-то (как мне) помогает листочек бумажки, другой -
почему бы и нет - для этого будет рисовать UML (если я не путаю,
что это такое).

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

трудно не согласиться :)

Onanim :

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

> Мне вообще-то казалось, что ты не "пионэр" и не будешь рассуждать о том, чего сам не знаешь.

Знаю ;)

> Из Perl доступен большая часть "традиционного" Unix API,

Во всех языках оно есть. Я другое имел в виду.

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

> Непонятно, что есть "хэндлы" и как их надо "крутить" :-)))

Всяческие неочевидные опции/прибамбасы (особо Тикль злоупотребляет).

> Если ты имеешь в виду "хэндлы" для обработки именно GUI событий, ...

Нет, я -- в общем. Хотя про ГУЙ это, например, к Тиклю относится в полной мере.

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

Я не спорю, что бОльшую часть повседневной рутины писать на перле значительно (в разы) удобнее/быстрее, чем на Це (читать, правда, потом тяжеловато, но для одноразовых поделок это не актуально).

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

Я знаком с этой твоей позицией и не совсем ее разделяю.

Многие проходят через такой этап, когда кажется, что любая проблема немедленно колется на подзадачи, для каждой из которых необходимо выбрать подходящйи инструментарий. И вот начинается -- тянем за собой зоопарк из 20 интерпретаторов каждого по 3-4 несовместимые версии...

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

anonymous (*) (14.03.2006 11:59:31):

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

Я тоже так раньше думал, потом понял, что это не так.

> Я очень сильно сомневаюсь, что "Design and Implementation of UNIX Operating System" на самом деле включал формальную фазу проектирования ;)

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

> ... просто почти не бывает людей, _сначала_ ставших компетентными математиками, а потом увидевших компьютер.

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

2idle:

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

Почти со всем согласен, кроме этого:

> Разумеется, если разработка проекта сразу совмещена с кодированием (как это ныне принято)

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

Мой опыт противоположный, отсюда, видимо, и разночтения.

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

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

2 Die-Hard :

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

Если честно - я не понял этой фразы, особенно применительно скажем к
perl-расширениям на C (XS). Конечно если ты никогда этого не делал,
для тебя это черная магия :-) но ничего магического там нет. Ничего
не "жужжит" и вполне можно "дернуть примитив пониже".
Куда надо "переключаться"? Perl - это программа на C. Если ты написал
XS модуль - это обычная .so. Во время выполнения одна программа на C
(perl) загрузит библиотеку, найдет там entry points и вызовет их.
Точка. Что и куда тут "переключается"?
По твоей логике писать расширения к Java на C тоже нельзя - ведь
этот JNI тоже будет "жужжать" :-)))

> Нет, я -- в общем. Хотя про ГУЙ это, например, к Тиклю относится в
> полной мере.

Ну и причем тут языки программирования??? Tk - это GUI toolkit. Он не
привязан к определенному языку (хотя изначально использовался в связке
Tcl/Tk, но есть и Perl/Tk и Python). А Tcl -это просто язык, в котором
нет никаких мистических "хэндлов". А "хэндлы" могут быть в любой
библиотеке - возьми хоть Qt (C++) - тоже не сразу разберешься ;-)

> Короче, че тут спорить, пиши на Перле.

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

А спорить действительно не о чем...

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

Потому что некомпилируемые языки всегда будут медленнее компилируемых, т.к. обработка программ осуществляется другими в процессе запуска.

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

Это сказал ты, я такого не говорил и так не считаю.

Onanim:

> Perl - это программа на C. Если ты написал XS модуль - это обычная .so. Во время выполнения одна программа на C (perl) загрузит библиотеку, найдет там entry points и вызовет их.

Ну, примерно это я и назвал "жужжать".

> По твоей логике писать расширения к Java на C тоже нельзя - ведь этот JNI тоже будет "жужжать" :-)))

Угу.

> А Tcl -это просто язык, в котором нет никаких мистических "хэндлов".

Еще как есть!

В основном, конечно, из Tk произрастающие, но все хэндлы Tk имманентно наследуются Тиклем как языковые конструкции, примерно так же, как заморочки разных седов и тестов становятся частью языка Баш.

> Но это не мешает мне понимать, что Java имеет свои плюсы и моя с ней несовместимость - это мои личные проблемы.

Ну вот тут я не согласен и более категоричен.

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

2idle (вдогонку):

Возможно, просто недоразумение -- я "горячий сторонник" не только разработки "сверху вниз", но и рефакторинга.

Честно говоря, я всегда начинаю _продумывать_ проект именно снизу, какие структуры данных могут понадобиться, какие алгоритмы можно применить, на какие конкретные грабли можно наступить и т.д.

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

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

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

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

Кстати, статьи я пишу точно так же. Не знаю про современную индустрию, но Чехов тоже писАл именно так :)!

> > Perl - это программа на C. Если ты написал XS модуль - это обычная
> > .so. Во время выполнения одна программа на C (perl) загрузит
> > библиотеку, найдет там entry points и вызовет их.

> Ну, примерно это я и назвал "жужжать".

Ты это серьезно? То есть dlopen()+dlsym()+вызов функции это "жужжать"?

То есть ты хочешь сказать, что сам пишешь монолитные, статические
программы, используя только статические библиотеки (ну чтобы тебя
не смущало "жужжание" динамического загрузчика)? И естественно
libc тоже всегда статически линкуешь, да?

А решения типа plug-in'ов (в виде .so) ты выходит вообще не признаешь?
Ну ты меня озадачил... непонятно как без этого можно писать
большие проекты, о которых ты говорил. :-/

Вот ещё интересная статья близкая к теме: http://www.cabochon.com/~stevey/blog-rants/tour-de-babel.html

Onanim (4.03.2006 23:27:45):

> То есть dlopen()+dlsym()+вызов функции это "жужжать"?

dlopen() на каждый чих -- это именно "жужжать". И если я не контролирую, когда в моей прогамме происходит dlopen(), то мне такого счастья не надо.

Кстати, как и всякие феньки, пришедшие от Сантехников, dlopen() довольно хреново переносим.

> И естественно libc тоже всегда статически линкуешь, да?

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

> А решения типа plug-in'ов (в виде .so) ты выходит вообще не признаешь?

ПризнаЮ.

2 Die-Hard :

> dlopen() на каждый чих -- это именно "жужжать". И если я не
> контролирую, когда в моей прогамме происходит dlopen(), то мне
> такого счастья не надо.

Блин... ну что тут скажешь... могу еще раз повторить - в загрузке
perl XS модулей ничего магического. И происходит это в совершенно
определеный момент а не на какой-то мистический "каждый чих".

> Кстати, как и всякие феньки, пришедшие от Сантехников, dlopen() довольно хреново переносим.

Афигеть! dlopen() специфицирован еще SUSv2 (которому уж скоро 10 лет).
Каким же это образом Apache ухитряется загружать свои модули
на куче платформ? Как же это Perl работает с XS модулями на всех
платформах? Куча софта использует plug-in'ы - и все работает,
причем кроссплатформенно :-)
Да, не все флаги для dlopen() стандартизированы - ну так не используй
всякие extension'ы.

HTH

> > Не вижу, как это зависит от языка. Более того, есть Not So HO, что объекты (в смысле "ссылка на нечто с методами") сильно более прозрачны, чем opaque handles или структы функций, столь

> Я тоже так раньше думал, потом понял, что это не так.

Не как? Не прозрачнее, или не более громоздко? Во второе не верю, первое - аргументы? Что лично у тебя прекрасная память и ассоциативное мышление, и что тебя не напрягает писать код типа gtk_button_set_label ;) - я понял. Не понял, почему.

Единственный аргумент (относительно простоты разработки, а не производительности программ) в пользу статических языков - это типобезопасность и "документация типами", если можно так выразиться. Но как раз к Си-то это все относится в гораздо меньшей степени, чем к Яве или, скажем, Хаскеллю. Или даже чем к плюсам. > > Я очень сильно сомневаюсь, что "Design and Implementation of UNIX Operating System" на самом деле включал формальную фазу проектирования ;)

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

А по-моему, замечательный пример. Коммерческие реализации все выросли из AT&T-шного кода так или иначе, clean-room из человеческих систем - только Linux. И проектирование там заключалось на 90% в "задокументируем базовую версию и опишем те три фичи, которые будем добавлять". Типичное итеративное программирование, "выращивание". И едва ли кто найдет формальное обоснование этих фич, более внятное, чем "мы думаем, что это позволит потом все делать проще" или "это нужно, чтобы реализовать фичу 12.34 в следующей версии программы Baz".

> > ... просто почти не бывает людей, _сначала_ ставших компетентными математиками, а потом увидевших компьютер.

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

Неясна аналогия между математической статьей и программой. Даже если ее развить - то получится, что статья - это либо программа на декларативном логическом языке (если математическая, "Обозначим aplha = foo bar baz. Тогда можно показать, что при alpha < blah выполняется fred"), либо сериализация дерева исполнения алгоритма в инженерных статьях ("в нашей задаче foo не превышает 14, поэтому, согласно [36], применима формула bar = 8,13*ln(foo), и bar < 21,5. Из таблицы [48, с. 321] выберем подходящий материал - глину. Из нее и будем лепить горшок").

А итеративные инструкции - это те, которые уже "откомпилированные", т.е. технологии ("взять глину марки 500, выложить в центр гончарного круга...").

Я не то, чтобы фанат функциональных языков - но они очень удобны, и достаточно часто. И отнюдь не обязательно в pure форме: в STL+boost очень много "функциональных" идей, реализующих вполне "итеративные" (sequental state changing) локальные цели, типа "заполнить контейнер".

> > То есть dlopen()+dlsym()+вызов функции это "жужжать"?

> dlopen() на каждый чих -- это именно "жужжать". И если я не контролирую, когда в моей прогамме происходит dlopen(), то мне такого счастья не надо.

Вах-вах. А еще ты пишешь только под жестко-реалтаймовые системы, потому что "reshed на каждый чих, и ты не контролируешь, когда твоя программа отправится в sleep, тебе такого счастья не надо"?

Мне всегда казалось, что задача программиста - обеспечить верную работу при _минимальных_ допущениях относительно среды. И не путем минимизации среды и создания своих, "контролируемых" замещений.

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

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

http://docs.python.org/ext/ext.html

показалось слишком сложно?

(про превосходство динамических языков и гуи в виде tcl/tk)

Если это и отличный инструмент, то только отличный от других. На практике у него слишком много специфических проблем. Основное:

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

2) отсутствие какой-либо единообразной объектной системы -- в результате если хочется множество разных виджетов, то к нему добавляется ещё и множество объектных систем. В целом оно даже работает, но выглядит... И реализация одних и тех же функций для разных типов виджетов получается исключительно не единообразной. Хочется прямо завернуть их все в объекты собственной системы.

Хуже всего именно пункт 1. Это значит писать огромное число тестов на все возможные случаи. Ибо свалиться оно может в любой произвольный момент. А каких-либо "динамических" свойств языка при всём при этом используется самый мизер.

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

> 1) дурной синтаксис, провоцирующий, как было верно замечено, именно (с точки зрения языка) семантические ошибки (вроде отсутствия знака '$' перед переменной) и отсутствие стадии компиляции позволяющей подобные ошибки (в других языках) выявлять;

Ты отстал от жизни на 20 лет. Настоящие интерпретаторы (chars stream->token stream->displatch table) сейчас встречаются, разве что, в командных оболочках. Питон, перл, пыхпых - компилируются в байткод/AST. И пропустить $ перед именем переменной в perl -sw нихрена не получится.

Про перловый taint mode я вообще молчу - такого средства проверки корректности вообще практически нигде нет.

> 2) отсутствие какой-либо единообразной объектной системы -- в

Можно подумать, Swing и SWT прямо одинаковые, ага. Или gtkmm и Qt. Это не проблема языка ни разу.

В смысле, у перла, конечно есть проблема излишнего минимализма объектной системы (TCL я не знаю, но у него она, afaik, тоже есть), из-за которого все всё делают по-разному. А вот у Ruby или Python все нормально.

> Хуже всего именно пункт 1. Это значит писать огромное число тестов на все возможные случаи. Ибо свалиться оно может в любой произвольный

Т.е. код на C++ ты не тестируешь? И поймать bad_alloc "в любой произвольный момент" он не может, потеряв какие-нибудь непривязанные к стеку ресурсы?

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

Неумение использовать инструмент - проблема программиста. Я вот довольно широко использую и рекурсию, и замыкания, и объекты с наследованием на Perl - и ничего. Ошибок, связанных с неверной семантикой практически не возникает.

> Если это и отличный инструмент, то только отличный от других. На > практике у него слишком много специфических проблем. Основное:

в дремучем 94-м на все твои вопросы уже ответили -- и про синтаксис, и объектную систему.

http://www.vanderburg.org/Tcl/war/

> Но "ядро" программы должно быть на компилируемом языке.

вообще-то тикль для этого и создавался --

Я извиняюсь, у меня почти нет времени. В воскресенье вечером я, однозначно, на наделю пропаду (уеду).

2anonymous (*) (15.03.2006 12:50:26):

> Не прозрачнее, или не более громоздко? Во второе не верю, первое - аргументы?

Одинаковые по соотношению функциональность/(дебильнось кода) программы на Це _всегда_ значительно короче и _почти_ всегда прозрачнее (чем на ЦеПП) -- это _мой_ опыт, не согласующийся с массовым -- массекспиренс я объясняю (себе) пиаром. Это не предмет для диспута на ЛОРе, но жизненный опыт.

> ... в пользу статических языков ...

Порадовала фраза про статические языки, особенно ремарка про производительность!

Помнится, приятель утверждал, что программа на Прологе выполняется быстрее, чем на Ассемблере... И, ведь, отчасти был прав!

> ... Коммерческие реализации все выросли из AT&T-шного кода ...

См. мой ответ вдогонку idel

> Неясна аналогия между математической статьей и программой. ...

Сильно упрощая -- чем больше в статье формул в ущерб пояснениям, тем менее она понятна.

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

anonymous (*) (15.03.2006 12:58:58):

> Мне всегда казалось, что задача программиста - обеспечить верную работу при _минимальных_ допущениях относительно среды. И не путем минимизации среды и создания своих, "контролируемых" замещений.

Точно!

И Це в Юнихе (в почти всех реализациях, а не в абстрактном Позиксе) мне это обеспечивает (в отличие от Перла).

Я знаю заморочки Линуха, Солярки, Хпукса, ОФСа (который теперь Тру64), я понимаю, откуда у них ноги растут. Если мне надо универсального тулкита -- я выберу универсальный опенсорс (плевать, если небесплатный) написанный на Це.

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

Я дней на 15 уеду, но меня эта тема сильно волнует, я б еще пообкашлял все это.

Если кто еще сюда заглянет, я в начале след. месяца, как появлюсь, открою новый топик в Девелопменте с сылкой сюда, ок?

Особенно Onanim и Idle интересуют, отзовитесь сюда...

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

> Я знаю заморочки Линуха, Солярки, Хпукса, ОФСа (который теперь Тру64), я понимаю, откуда у них ноги растут. Если мне надо универсального тулкита -- я выберу универсальный опенсорс (плевать, если небесплатный) написанный на Це.

Под конец дискуссии замечу, что Perl и Python под это определение попадают на 100%: опенсорсные реализации универсальных (в смысле - "общего назначения") языков, написанные на C.

А по поводу производительность - вот у меня есть прога на перле, считающая некую статистику из текстовых входных данных. Вся сложная логика - на Perl, но 95% времени она проводит в ожидании завершения sort(1). Ну и что мне даст переписывание на С? Ничего, кроме секса с ручным управлением ресурсами, тормозных строк и страшненьких интерфейсов libpcre.

> Различия функциональщины и декларативщины не сводятся к различию между рекурсией и итерацией

Более того. Функциональный язык - это _в_первую_очередь_ лямбда и функции высшего порядка. И процедура исполнения вполне может быть и последовательной (от этого никуда не деться). И функциональное мышление заключается именно в code is data, а не в "loop не нужен, юзайте CPS". И именно это и обеспечивают современные динамические языки (к которым, как ни странно, относится и CL).

> Ты отстал от жизни на 20 лет. Настоящие интерпретаторы (chars stream->token stream->displatch table) сейчас встречаются, разве что, в командных оболочках. Питон, перл, пыхпых - компилируются в байткод/AST. И пропустить $ перед именем переменной в perl -sw нихрена не получится.

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

Далее, под объектной системой подразумевается: incrtcl, xotcl, snit, stooop и другие. К свингу и прочим *программам* построенным на имеющейся объектной системе Java оно никакого отношения не имеет. Сравнивать можно вот так прямо с java или с c++, или с perl. Так вот ключевое отличие тикля -- своей ествэесственной объектной системы он не имеет и использует, может параллельно использовать, множество загружаемых. Прогресс или бардак сложно сказать. Скорей параллельно то и другое.

Здесь же и "исключения" в виде catch... Типичный случай получения граблями по лбу при использовании статических errorCode и errorInfo.

> Неумение использовать инструмент - проблема программиста. Я вот довольно широко использую и рекурсию, и замыкания, и объекты с наследованием на Perl - и ничего. Ошибок, связанных с неверной семантикой практически не возникает.

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

> Т.е. код на C++ ты не тестируешь? И поймать bad_alloc "в любой произвольный момент" он не может, потеряв какие-нибудь непривязанные к стеку ресурсы?

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

> А ты не в курсе дела. Очень даже получается, потому как для tcl обе конструкции (varname и $varname) синтаксически верны.

[snip]

Ну это все частные проблемы TCL (и, в меньшей степени, Scheme) - суровый минимализм базовой системы и порожденный им полный гараж велосипедов. Perl, Python, Ruby и Common Lisp этим почти не страдают.

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

Ну так и должно быть, в теории (соотношение код/тесты). И жаба - не панацея, NullPointerException никто не отменял. Более того, поскольку декструкторов нету - то отследить использование ресурсов, отличных от памяти, получается тяжело. (создали локальный объект-сокет, вызвали метод из стрононней библиотеки, словили NPE, вывалились на два уровня выше. Сокет утек. На плюсах, по крайней мере, деструктор стрима бы сработал и сокет закрыл. Там вообще, при некоторой дисциплине, управление памятью получается "как автоматическое, только лучше". use the stack, Luke ;-).

CrazyPit:

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

> Лично у меня от этой связки полностью противоположные ощущения. > Оно пригодно для _простейших_ ГУЙовин. Но чуть посложнее.. > Извини, я имею немалый практический опыт секса с этой штукой. > Я бы, пожалуй, голые Иксы предпочел бы для чего-либо не совсем > тривиального...

Странно. У меня за четыре года работы опыт только положительный. Или скажешь, вот это ( http://www.az.inural.ru/temp/screen.gif ) тривиальный интерфейс?

fk0:

>(про превосходство динамических языков и гуи в виде tcl/tk) >Если это и отличный инструмент, то только отличный от других. >На практике у него слишком много специфических проблем. Основное:

Проблемы у всего есть в общем-то...

>1) дурной синтаксис, провоцирующий, как было верно замечено, именно (с точки зрения языка) семантические ошибки (вроде отсутствия знака '$' перед переменной) и отсутствие стадии компиляции позволяющей подобные ошибки (в других языках) выявлять;

Есть такая проблема. Но как раз ГУЙ тестируется достаточно легко.

>2) отсутствие какой-либо единообразной объектной системы -- в результате если хочется множество разных виджетов, то к нему добавляется ещё и множество объектных систем.

Используем практически только базовые Tk. Повер него - своя библиотека "высокоуровневых" виджетов.

> И реализация одних и тех же функций для разных типов виджетов получается исключительно не единообразной. Хочется прямо завернуть их все в объекты собственной системы.

Так и сделано. Все завернуто.

>В общем и целом думаю, GUI писать всё-таки можно. Но "ядро" программы должно быть на компилируемом языке.

Согласен. В этом плане речь надо вести только о GUI. "Ядро" должно быть отдельно (у нас - WEB-сервисы).