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

#ifndef LISP_HATER
> Там промелькнула интересная мысль, касающаяся обсуждаемой здесь темы, что язык для реализации задачи нужно выбрать так, чтобы ломать голову над задачей, а не над языком.
Вполне согласен с Дийкстрой :) Но он, пожалуй, имел ввиду что с некоторыми языками ты *всегда* будешь думать не о проблеме, а о том как это корректно выразить средствами языка. А иногда люди по лени или невнимательности *не* делают это правильно, и в софте появляются потенциальные buffer overflows и memory leaks.
Что же до Лиспа - каюсь, грешен, нравится он мне :) Но в отличии от многих моих оппонентов я имею хорошее представление как о Лиспе, так и о C++, тогда как их познания ограничиваются последним. И большинство критики идет не по причине каких-то недостатков Лиспа (в таких спорах как правило упоминаются мнимые недостатки и умалчиваются реальные), а в силу человеческой натуры. Редкие люди, вбив годы жизни в овладение каким-то конкретным языком, согласятся признать что может быть что-то лучше хоть в чем-то, и когда им просто пытаешься что-либо объяснить они сразу занимают глухую оборону.
Ну скажите, *кто* из вас выбрал Си осознанно, взвесив его достоинства и недостатки и изучив альтернативы? В этой стране есть только два широко используемых и преподаваемых языка: Си и Паскаль. Обычно студент на ранних курсах попадает в один из этих кланов по стечению обстоятельств, и научившись что-то делать на своем языке немедленно начинает обсирать лагерь противника, мимоходом раздавая пинки языкам "третьего сорта".
#endif
> А вот начинать обучение (именно обучение) необходимо с АСМ&C.
Тогда достаточно одного ассемблера - Си это почти то же самое.
> Си ведь очень лёгок для понимания.
Спорный вопрос. У нас тут есть один юрист, решивший подучить программирование, считай абсолютный чайник. Тебе придется долго ему объяснять смысл dereferencing или что такое enum. Поэтому (ИМХО конечно) уж лучше изучить сначала Паскаль, и научиться в нем работе с указателями. Там это все-таки проще.

Да, я правильно обозначил то, что ни в коем случае нельзя использовать для первоначального обучения: ИМПЕРАТИВНОЕ ПРОГРАММИРОВАНИЕ, то есть, подход Тьюринга к введению понятия алгоритма. Ты же непонятно в какую степь приплел совершенно ортогональное понятие - структурное программирование. Так что научись читать и думать, это полезно, не будешь в лужи садиться всем на посмешище. Про сисколлы отвечать не буду - я уже предлагал просто тупо посмотреть на результат работы профайлера. Вообще, все безмозглые адепты кульхацкерства почему-то приходят в бешенство от одного лишь упоминания этой тулзени - должно быть, подсознательно соображают, что она демонстрирует всю бессмыссленность их адского труда. Про численные задачи речи не идет - там оптимизация необходима. Но скажи, написав тот же ElGammal на ассемблере для скорости, ты еще и разбор параметров коммандной строки для своего PGP на ассемблере напишешь? Короче, ты просто недоразвитый словоблуд, не способный воспринимать аргументы. Твой бред даже комментировать сложно - пустой поток несвязных слов. Если ты не понял, что я имел в виду под однозначным отображением логики предметной области, без потери смысла, то это говорит лишь о твоей умственной отсталости и полнейшей необразованности, и не более того. И, кстати, если ты уверен, что все твои задачи прекрасно ложатся на C/C++/Java, и нет ничего, что на порядок лучше подошло бы, то ты исключительно "hello world"-ы пишешь, очевидно. Хочешь задачку, об которую твоя гнилая императивщина пососет? Напиши простенькую систему символьной математики ;) И если ты где-то у меня нашел высказывание "C,C++ - суксь, и все тут", то ты просто больное чмо. Я никогда такого не говорил. Я утверждаю, что императивные языки плохо подходят для понимания теории программирования, что они привывают крайне поганые кульхацкерские привычки, что потом очень сложно выбить.

Так вот и я той же темы стараюсь придерживаться, но постоянно приходят всякие и начинают выпендриваться со своим кульхацкерством позорным.
И посторайся наконец понять, что я объясняю, не съезжая в сторону (кто там про рисование ГУЙни под досом на ассемблере вставлял? тоже ведь оффтопик).
Короче: есть человек, не имеющий ни малейшего понятия о программировании. Надо его обучить так, чтобы он мог хотя бы простые софтины для автоматизации своей работы писать. Для этого необходимо сначала вбить в него всю теорию: что такое алгоритм, что такое информация, для чего ее надо обрабатывать, и, наконец, как ее обрабатывать. Безмозглые кульхацкеры идут по самому идиотскому пути, дающему наиболее уродливые результаты: предлагают сразу же взяться за решение прикладных задач, всего лишь изучив какой-либо язык программирования (почему-то упирають на любимые кульъацкерские ассемблер и сю с плюсами). В результате получается кадр, способный вывести красивое окошко, в котором цветастая фраза hello world нарисована, но не представляющий себе, сколько стоят разные алгоритмы сортировки, и не понимающий, для чего существуют контейнеры. Правильный же путь, который исповедуют ведущие ВУЗы мира, таков: для начала изучить соответствующие разделы математики, после чего, дать чисто математическое описание информации и алгоритма. И тут уже наши разногласия вступают в дело: ты предлагаешь вводить алгоритм по Тьюрингу, что, конечно, ближе к телу, но зато ужасно неудобно и для новичка абсолютно непонятно. Я предлагаю вводить понятие алгоритма по Черчу, что для уже вкусившего математики будет насквозь знакомо и понятно, и всякий воскликнет: "%^#! какого #$@ я сам не догадался, ведь все так просто!".

Фи! На хрена юристу указатели?!? Они и программисту не нужны на фиг...

> Они и программисту не нужны на фиг...
Ну, когда я делал garbage collector для Синклера, без понятия об указателях обойтись было бы трудно. Да и вообще, матчасть знать надо.

>Фи! На хрена юристу указатели?!? Они и программисту не нужны на фиг... LOL! А нафига процессору регистры вааще! Пример a`la vsl: Написать драйвер SCSI контроллера на Scheme. _ burillo@mail.ru

> ...Написать драйвер SCSI контроллера на Scheme.
А зря прикалываешься :) Были когда-то Лисп-машины, были у них и скази. Угадай, на чем там писали драйвера...

Отвечать буду всем, так что по порядку. 1) Насчет игр - кто-то очень сильно заблуждается и видимо, никогда ничего подобного не писал. Написание игр - это большое искусство, мало имеющее, конечно, с "программированием" в понимании vsl, и с "информатикой" в моем понимании. Тут много математики, хотя и не столь сложной, много приходится думать об оптимизации, как на алгоритмическом уровне, так и на уровне техсредств. Вообще много приходится думать - как выжать из данной машины все, на что она способна. Романтика... А всякие БД - по сравнению с этим - ерунда полная, необходимо лишь знание конкретных тулкитов, которые будут использоваться (MySQL, apache, PHP и т.п.) и все. 2) Насчет серьезных задач. vsl, хотя и почему-то в страшно ругательной форме, привел хорошую задачу, которая решается просто на языках типа того же лиспа и замучаться как сложно на C. Да, это действительно хорошая серьезная задача, не слабее по тому, как надо напрягать мозги по сравнению со средней игрушкой. Тут перед тем, кто умеет такое хорошо и быстро писать на лиспе - снимаю шляпу. Сам не умею, просто пока необходимости не было. 3) Насчет первоначальной темы разговора. Я лично за изучение первоначально языков без серьезной матчасти и работающих так, как работают большинство современных машин (читай - PCшки), то есть языки типа C, а еще лучше типа бейсика. Объекты, ФП и прочее должно вводится уже позже, как следствия и расширения. Тогда хотя бы с психологической точки зрения они будут восприниматься серьезно. Я видел людей, которых обучали с нуля с жутких понятий алгоритма и т.п. - печальное зрелище, они никогда не воспримут лисп и иже с ним всерьез, они считают, что все это - детские игрушки, так, для обучения чисто. 4) Насчет необходимости оптимизаций и про разорение разработчиков железа. Люди, почитайте гнушную литературу. Какую позицию мы имеем? Софт - это нематериальное благо. Его можно копировать без каких-либо изменений в неограниченном количестве. То есть фактически любая оптимизация софта потенциально увеличивает полезность софта на бесконечность много. Хард - это материальное благо. Его копировать нельзя (пока физхимики не изобретут помолекулярные копировальщики предметов). За него обязательно надо платить - хотя бы за материалы из которых он изготавливается. Улучшение харда влечет за собой фиксированный прирост производительности всего человеческого сообщества - ровно столько людей станут работать лучше, сколько купят новый хард. Таким образом, надо улучшать именно свободный софт, а улучшать хард - он сам собой улучшиться, все равно кто-то этим будет заниматься...

Отвечать буду всем, так что по порядку.
1) Насчет игр - кто-то очень сильно заблуждается и видимо, никогда ничего
подобного не писал. Написание игр - это большое искусство, мало имеющее,
конечно, с "программированием" в понимании vsl, и с "информатикой" в
моем понимании. Тут много математики, хотя и не столь сложной, много
приходится думать об оптимизации, как на алгоритмическом уровне, так
и на уровне техсредств. Вообще много приходится думать - как выжать из
данной машины все, на что она способна. Романтика... А всякие БД - по
сравнению с этим - ерунда полная, необходимо лишь знание конкретных
тулкитов, которые будут использоваться (MySQL, apache, PHP и т.п.) и
все.

2) Насчет серьезных задач. vsl, хотя и почему-то в страшно ругательной
форме, привел хорошую задачу, которая решается просто на языках типа
того же лиспа и замучаться как сложно на C. Да, это действительно хорошая
серьезная задача, не слабее по тому, как надо напрягать мозги по сравнению
со средней игрушкой. Тут перед тем, кто умеет такое хорошо и быстро
писать на лиспе - снимаю шляпу. Сам не умею, просто пока необходимости
не было.

3) Насчет первоначальной темы разговора. Я лично за изучение
первоначально языков без серьезной матчасти и работающих так, как работают
большинство современных машин (читай - PCшки), то есть языки типа C,
а еще лучше типа бейсика.
Объекты, ФП и прочее должно вводится уже позже, как следствия и расширения.
Тогда хотя бы с психологической точки зрения они будут восприниматься
серьезно. Я видел людей, которых обучали с нуля с жутких понятий алгоритма
и т.п. - печальное зрелище, они никогда не воспримут лисп и иже с ним
всерьез, они считают, что все это - детские игрушки, так, для обучения
чисто.

4) Насчет необходимости оптимизаций и про разорение разработчиков железа.
Люди, почитайте гнушную литературу. Какую позицию мы имеем? Софт - это
нематериальное благо. Его можно копировать без каких-либо изменений
в неограниченном количестве. То есть фактически любая оптимизация софта
потенциально увеличивает полезность софта на бесконечность много. Хард -
это материальное благо. Его копировать нельзя (пока физхимики не
изобретут помолекулярные копировальщики предметов). За него обязательно
надо платить - хотя бы за материалы из которых он изготавливается.
Улучшение харда влечет за собой фиксированный прирост производительности
всего человеческого сообщества - ровно столько людей станут работать
лучше, сколько купят новый хард. Таким образом, надо улучшать именно
свободный софт, а улучшать хард - он сам собой улучшиться, все равно
кто-то этим будет заниматься...

To vsl: сэр vsl,в мире пользуются все-таки понятиями Неймана и Тьюринга, а не Черча. И основные курсы информатики,теории программирования и методов трансляции основаны как раз на машине Тьюринга, и том, что на нее ложится. И доказательства правильности алгоритма не менее легко и понятно ложатся на машину Тьюринга, а также и искусственный интеллект, и параллелизм, и многое другое прочее, вплоть до законов робототехники Азимова... Я сам слушал эти курсы в разных университетах мира, и мои друзья также. Выборка велика - до 40 университетов. Так что не надо гнать про то, чему учат... Учат именно тому, чему надо.

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

2vsl
>Правильный же путь, который исповедуют ведущие ВУЗы мира, таков: для
>начала изучить соответствующие разделы математики, после чего, дать
>чисто математическое описание информации и алгоритма

Так и есть - как ты сказал, только в этих ВУЗ-ах все же начинают обучение
с Ada (читай императивное пр-е), только когда ты допетрил что к чему,
начинают изучать другие варианты - CAML и Prolog. Ну нельзя начинать с
функционального или логического прог-я - это же сплошная рекурсия. Чайникам
это вредно.

> Так и есть - как ты сказал, только в этих ВУЗ-ах все же начинают обучение с Ada
Справедливости ради надо сказать что в MIT первокурсников учат именно Scheme. Правда, некоторые там вешаются. Но некоторым наоборот нравится.

Я знаю, что такое писательство игрушек, сам когда-то по приколу писал для MSX1... Это хацкерство, а не нормальное программирование, особенно если учесть, на какой круг пользователей игрушки рассчитаны. Я сам уже много лет ни во что, кроме как в MUD-ы не играю (ну, еще малость в Galaxy, но это те же яйцы), а вот как раз такие игрушки пишутся весьма generic методами, без хацкерства.
Про изучение: я, говоря о том, с чего следует начинать изучать программирование, предполагаю наличие базовых знаний в математике, ибо я уверен, что не зная математики к компутеру и подходить не стоит. А знающему математику человеку гораздо легче понять лямбда-исчисление, чем хреново формализуемый Тьюрингов подход, что проверенно многократно.

Гражданин анонимный идеалист не слышал словосочетания "математическая лингвистика"? И никогда не обращал внимание на то, что с естественными языками всегда работают с использованием ФП, да и первые функциональные языки были ориентированны исключительно на лингвистические задачи? Ну а про идеализьм - думаю, нам еще лет дцать ждать, пока не появится возможность программировать на естественных языках. До тех пор - математика рулит, и именно математика, а никак не литература, в этой области является Искусством. Правда, если совместить программирование с литературой, получится Literate Programming, но уж о таком гражданин ламер явно никогда и не слышал, даже если и юзал иногда случайно TeX...

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

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

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

Кстати подскажите где можно накопать какой-нить инфы про АДА (в
электронном виде) и транслятор какой-нить фришный скатать. Так,
чтобы посмотреть что это такое и с чем его едят (заинтересовал vsl)

А насчет указателей в паскале, так по-моему это как раз то, что
начинающим лучше и не показывать потому, что будут потом шарахаться
от них в других языках. Взять к примеру горячо любимую народом Delphi
большинство объектов из VCL создаются статическими (в отличии от Builder'а)

FireWind

либо www.adahome.com, либо www.gnat.com

Вот тут кто-то хаял Ada, а за зря. Не знаю,
почему в российских ВУЗ-ах отдают предпочтение
Pascal, синтаксис похож, но возможности разные.

Ada - ссылки

1. Компилятор называется gnat, поищи в портах или как там их зовут (FreeBSD я не знаю). Если вдруг будешь собирать сам, то ему нужен gcc-2.8.1, ни больше, ни меньше.
2. Смотри на Yahoo категорию Computers/Programming_Languages/Ada/
3. Там найдёшь The Ada Lovelace tutorial - хорошая (на мой взгляд) обучалка.
4. Reference Manual - например, на www.adahome.com/rm95 - если возникнут вопросы, довольно легко читаем (опять же, на мой взгляд). Можно найти в формате PS, info и др.
5. Ссылки (в порядке интереса, на мой взгляд): http://www.adaic.com, http://www.adahome.com, http://www.adapower.com
6. Ada for Linux team - http://www.gnuada.org/alt.html

Ну вот, вроде всё.

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

Ну тогда все ясно. Именно игрушки я считаю самым серьезным программированием. Почти все остальное -
ерунда по сравнению с этим. В игрушках приходится "выкладываться" по полной программе - и вся алгоритмизация
идет в дело, и фиксации на системы/плафтормы и все остальное. С моей точки зрение - это - не "кулхацкерство".
Это нормальное, глубокое, серьезное программирование. С твоей точки зрения - это как раз ерунда
(хотя все-таки жаль, что ты игрушек не писал, MSX1 вообще полный сакс был, MSX2 рулит - там
спрайты 32 были чуть ли не аппаратно :))), а серьезные задачи - это требующие глубоких знаний
математики, плотной теоретической базы. Спорить тут бесполезно, что я в общем делать больше и не
намериваюсь. Просто хочу обратить внимание на тот факт, что, как видишь, куча народу не зная ни формализаций
алгоритма, ни вообще какой-либо сложной теории математического программирования - прекрасно пишут
программы и не догадываются даже о том, что можно все настолько усложнить. Так что мне кажется,
загонять программирование в рамки математики - не совсем правильно, хотя, бесспорно, некоторая подготовка
нужна. Советую всем, кто тут есть больше по этому поводу не спорить и тихо-мирно разойтись со своими
мнениями. Неприятно, когда появляются воинственно настроенные люди, пытающие доказать всем и вся,
что они стопроцентно правы, будь то это ламерски выглядящие анонимусы или тот же vsl...

Напоследок хочу обратиться ко всем emacs-систам с просьбой - прочитайте мое сообщение в форуме
на тему (X)Emacs - давайте лучше это пообсуждаем - оно полезнее будет :))

MSX сосет, ZX-Spectrum рулит! Вот где настоящая открытая архитектура: открываешь корпус и лезешь с паяльником :)

FireWind> Кстати подскажите где можно накопать какой-нить инфы про FireWind> АДА (в электронном виде) и транслятор какой-нить фришный FireWind> скатать. Так, чтобы посмотреть что это такое и с чем его FireWind> едят (заинтересовал vsl)

Смотри http://faqs.hotmail.ru/progr/other_l/ada.htm

Пока там старый FAQ из su.pascal.modula.ada, но полезные ссылки
можеш уже найти :)

Как только причешу HTML вариант этого Ada FAQ (через 2 недели
предположительно) появится цивильная версия (смотреть там же)

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

Мало ли, что ты видел. А я видел математиков, которые могут литр водки выхлебать и потом идти на работу. Короче, ты про болезнь пузырька слышал? Ей подверженны все "программисты" вроде тебя, так называемые интуитивисты. Как ни пытайся интуитивно до сортировки Хоара допереть, всегда пузырек получается ;)
Почему-то последнее время развелось слишком много ламеров, которые считают, что в программировании можно без математики обойтись. Именно благодаря таким ламухам сейчас общее качество кода (в ширпотребных приложениях, естественно, до крутых задач таких неучей не допускают) крайне низкое, и некоторые даже шутят, что программ без ошибок не бывает. Грустно, однако...

Ндаааа. Все видели высказывание "Дурь все это насчет реляционных БД..."? Вот вам и пример недоучки (автору: извини, ничего личного). "Ленина не читал, но поддерживаю". Человек даже не понял, о чем речь идет. Но высказался.

В предыдущем постинге про БД было что-нибудь про _алгоритмы_? Еще раз -- понятие нормальной формы реляционной базы данных без математики как-то не понятие вообще. А если у Вас база не будет нормализована, то никакой алгоритм Вас не спасет -- "задолбаетесь" целостность данных поддерживать.

"живого человеческого восприятия поставленной задачи" это конечно круто, только вот восприятие у Вас одно, у меня другое, а у меня после литра водки -- третье. И потом, почему Вы решили что у Вас восприятие "живое", а у меня -- нет? А целостность базы данных -- понятие объективное. О котором Вы, очевидно, никакого понятия не имеете (каламбур, однако).

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

Народ! А вам не кажется, что тема дискуссии была в самом начале очень лихо подменена? Как можно судить по первому письму, человек уже умеет (как-то) программировать под DOS и Windows, и теперь хочет узнать, какие особенности его ждут под Линуксом. Вместо этого толпа ломанулась обсуждать всякие теоретические бредни. Надо полагать, потому, что никакой специфики ОС не существует (или здесь никто о ней не в курсе)?

Grue.

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

Никакой подмены. Человек хотел писать ГУЙню, на что ему было отвечено, что для этого ему надо отказаться от дурацких досовиндовых привычек, наиболее опасная из которых - писать гуйню на C/C++.

Специфика в исходниках ядра? А что, больше линукс ничем от винды не отличается? Как интересно! То есть, если исходников не читать - и не отличишь? Восхитительно! ;-)))

Grue

>линукс ничем от винды не отличается? Речь не о "винде", а о нормальных, т.е. Unix-like системах. А снаружи Unix он и есть Unix (по крайней мере для начинающего) А еще есть POSIX, которому соответствует даже Windows NT (не помню только: полностью или частично)

Черт знает, господа. Всю жизнь пишу сугубо прикладные программы, работающие с базами данных. И никогда даже мысли не возникало проверять их на предмет соответствия математическим теориям. Даже на достаточно больших базах - 500-1000 таблиц никаких затруднений не возникало. Все делается как-то интуитивно. Брюс Ли говорил, что не нужно вставать в стойку, издавать боевой клич и корчить страшную гримассу, чтобы отразить удар противника. Его нужно просто отразить...

Сейчас будет новый флейм, но я пока ничего конструктивного по поводу почему надо писать GUI на скриптовых языках не слышал. Хотя бы один пример, плз? TCL/Tk я смотрел, причем он мне сразу не понравился - жутко напоминает некий гибрид перла и це, а интерпретация Tk крайне смахивает на Gtk'шную, с его уродливыми callback'ами (в C еще имеющими обыковение глючить, если случайно где-нибудь дереференс пропустишь или еще чего-нибудь) и заумными "упаковками" в layout'ы. Еще один минус здоровый - с программой обязательно нужно таскать TCL (6-7 мег) и TK (еще столько же). Про скорость и не говорю - интерфейс достаточно ощутимо тормозит у меня на P200, особенно если виджетов на экране много. Про красоту и настраиваемость интерфейса, конечно, речь не веду, это не Gtk и Qt, но это я могу переварить. Но пока ничего конструктивнее объектов я там не увидел. Примеры?

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

потому, что проще, быстрее, короче, понятней и нормальный geometry management.

>TCL/Tk я смотрел, причем он мне сразу не понравился - 
>жутко напоминает некий гибрид перла и це, 

только фигурными скобочками :)
да и то - их смысл совсем другой. Вкратце это то-же, что 
кавычки, только без variable substitution и обработки escape-sequence.

и с горбатым перлом по читабельности не сравним. 
(хотя наворотить тоже можно)

>а интерпретация Tk крайне 
>смахивает на Gtk'шную, с его уродливыми callback'ами (в C еще 
>имеющими обыковение глючить, если случайно где-нибудь дереференс 
>пропустишь или еще чего-нибудь) и заумными "упаковками" в layout'ы. 

не нравится packer и grid - пользуй placer - он бильдерам родня :)

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

>Еще один минус здоровый - с программой обязательно нужно таскать TCL 
>(6-7 мег) и TK (еще столько же).
неправда-всего 2-3 мег

>Про скорость и не говорю - интерфейс достаточно ощутимо тормозит у 
>меня на P200, особенно если виджетов на экране много. 

что есть то есть.. тормозит..:(
а Вы интерфейс тщательнЕе планируйте - 
тогда и виджетов меньше будет (KISS) :)

А примеры - в книгах Ousterhout, Welch, 
на сайтах Ajubasolution и Neosoft
где-то на Florin лежала русская дока, 
ну - и, если не влом загляни в /usr/lib/tkX.X/demos

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

Во первых, у Tcl нет ничего общего ни с C ни с Перлом, это как бы упрощенный Лисп для малаграматных. Во вторых, я не впилил, чем тебе layout-ы не угодили? Что, хочешь все, как в детском садике, по координатам укладывать? И плакать горько, когда от ресайза все накрывается медным тазом? Ну и про размеры - гонево. Все гораздо легче весит, и таскать с собой не надо - оно везде есть. Тормоза тоже далеко не такие страшные, по сравнению с преимуществами для разработчика. Про объекты - придумаю тебе примерчик, не плачь. Если сам не успеешь додуматься...

>Сначала нужно изучить машину и естественно ASM&C. А теперь напиши на асме _рабочую_ программу (NICE.SOURCES.D) посвящается. P.S. И зачем всё вышескипнутое знать прикладнику .

Ага. 100 пудов, тут уже давно филиал NICE.SOURCES.D ;)
Может, предложить maxcom-у прозрачный гейт в обе стороны настроить?

Советую немножко поостыть и не обращаться ко мне в таком тоне. Я могу и обидеться - а ведь я ни лично тебе, ни вообще никому пока ничего оскорбительного или обидного не говорил. Просто поинтересовался вопросом. Итак, по пунктам: 1) Ничего от Лиспа я в TCL не заметил. Все те же самые конструкции if () { } else { } и т.п. Фактически те же самые функции, структурная структура (извиняюсь за тавтологию). Ну может быть чуть-чуть похож на обрипанный Лисп без скобочек своим способом передачи параметров функциям (хотя лично мне это куда больше напоминает QBasic). 2) Layout'ы мне угодили, читай внимательнее. Мне не угодила теория упаковки, контейнеров и т.п. вещей, распространенных в Gtk. Имхо так, как сделано там - это попытка подогнать под одну (плохую) идеологию плохо подгоняемые вещи. В моем любимом Qt эти Layout'ы сделаны несколько более человечно - просто несколько классов от QLayout'а и все. Комбинируй как хочешь - и не надо никаких упаковок... 3) Про размеры. Уточнил. RPMки tcl - 5.7 мег, 5.5 мег. 11+ мег, как ни крути. Причем их должны иметь все - не только разработчики. И про то, что они у всех есть - вот это именно гон. У меня их больше не стоит. Также, как и питона, и схемы и еще много чего. Если учесть, что таких альтернативных (прошу прощения, если опять подниму случайно эту тему) языков порядка десятка и каждый из них под 10 мег - то это получается любому надо держать под 100 мег этих интерпретаторов. Хорошо ли это? 4) Про скорость. Я склонен утверждать, что мой P200 является нижним пределом по скорости, на каком-нибудь P133 это уже будет неюзабельно. А качество интерфейса отнюдь не заслуживает таких жутких требований. 5) Про объекты - не знаю, пока для всего, что я делал в GUI объекты очень неплохо подходили. Жду собственно примера :)

Опять по порядку: 1) Быстрее, короче - далеко не факт. Каждый раз писать каллбэк на всякую ерунду типа надписи на кнопочку - это отнюдь не быстрее и короче. 2) Проще - субъективный довод. 3) Нормальный geometry management - тут я как раз не сильно согласен. placer - это вообще ерунда, ее даже рассматривать не буду. Но сама идеология упаковки виджетов в какие-то контейнеры, контейнеры с алигнментами и т.д. и т.п., потом жуткие фразы типа "активизировать мою запаковку", выглядящие так, как будто запускаешь ядерную ракету... Опять повторюсь, но мне лично ближе подход Qt в этому... 4) Насчет похожести Tcl на что-либо - конечно, я глубоко не копался, но мои доводы см. в предыдущем письме к vsl. 5) Насчет размера - тоже см. предыдущее письмо. Оценивал RPMки RedHat 6. (Ой, только не надо новый флейм по поводу RedHat is not Linux, ok?) 6) Насчет /usr/lib/tk и /usr/lib/tcl - по ним в основном выяснял, что за язык. Свою програмку одну написал, естественно, в доки особенно не заглядывал, так... Ощущения стойкое, что пишешь под Gtk - все настолько неудобно :(

>Опять по порядку:
>1) Быстрее, короче - далеко не факт. 
>Каждый раз писать каллбэк на всякую ерунду типа надписи на кнопочку
>это отнюдь не быстрее и короче. 

про надписи на кнопочках:
#создаем кнопочку
button .b -text {текст на кнопочке} -command "run_command"
pack .b -anchor n
#меняем надпись на кнопочке
.b config -text {новая надпись на кнопочке}
быстрее, короче, проще и понятней некуда (imho)

>2) Проще - субъективный довод. 
уточняю - проще, если знаешь Tcl :)

>3) Нормальный geometry management - тут я как раз не сильно
>согласен. placer - это вообще ерунда, ее даже рассматривать не буду.
>Но сама идеология упаковки виджетов в какие-то
>контейнеры, контейнеры с алигнментами и т.д. и т.п.,
>потом жуткие фразы типа "активизировать мою запаковку",
>выглядящие так, как будто запускаешь ядерную ракету...
>Опять повторюсь, но мне лично ближе подход Qt в этому...

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

>4) Насчет похожести Tcl на что-либо - конечно, я глубоко не копался,
>но мои доводы см. в предыдущем письме к vsl.
да хрен его знает на что он похож... Я ничего похожего не знаю.

>5) Насчет размера - тоже см. предыдущее письмо. Оценивал RPMки RedHat
>а причем тут rpm-ки?

libtcl - 462k
libtk  - 682k
tclsh  - 4k
wish   - 4k
/usr/lib/tcl8.0 - 169k
/usr/lib/tk8.0 - 912k (если DEMOS выкинуть - 288k)

складывать умеем?

Я конечно извиняюсь, но если писать GUI на скриптовом языке для такой программы как 3DStudio MAX, то могу представить себе этот тормоз.

>Опять по порядку:
>1) Быстрее, короче - далеко не факт. 
>Каждый раз писать каллбэк на всякую ерунду типа надписи на кнопочку
>это отнюдь не быстрее и короче. 

про надписи на кнопочках:
#создаем кнопочку
button .b -text {текст на кнопочке} -command "run_command"
pack .b -anchor n
#меняем надпись на кнопочке
.b config -text {новая надпись на кнопочке}
быстрее, короче, проще и понятней некуда (imho)

>2) Проще - субъективный довод. 
уточняю - проще, если знаешь Tcl :)

>3) Нормальный geometry management - тут я как раз не сильно
>согласен. placer - это вообще ерунда, ее даже рассматривать не буду.
>Но сама идеология упаковки виджетов в какие-то
>контейнеры, контейнеры с алигнментами и т.д. и т.п.,
>потом жуткие фразы типа "активизировать мою запаковку",
>выглядящие так, как будто запускаешь ядерную ракету...
>Опять повторюсь, но мне лично ближе подход Qt в этому...

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

>4) Насчет похожести Tcl на что-либо - конечно, я глубоко не копался,
>но мои доводы см. в предыдущем письме к vsl.
да хрен его знает на что он похож... Я ничего похожего не знаю.

>5) Насчет размера - тоже см. предыдущее письмо. Оценивал RPMки RedHat
>а причем тут rpm-ки?

libtcl - 462k
libtk  - 682k
tclsh  - 4k
wish   - 4k
/usr/lib/tcl8.0 - 169k
/usr/lib/tk8.0 - 912k (если DEMOS выкинуть - 288k)

складывать умеем?

Угу. Еще неплохо было бы продать такую прогу. Уж не в исходниках-ли ?

В общем, возвращаясь к начальной теме. Я программировать GUI недавно начал (а точно - неделя как :) В начале я писал всякий системно-служебный софт под юнихи на gcc. Потом я прикололся, что есть djgcc - типа, все проги можно собирать под дос, да ещё и LFN виндовые поддерживаются. Потом по приколу mingw32 поставил... (это всё gcc) Прикол - под ним виндовые проги собираются! :)))) Нашёл к нему офигенную RAD IDE - http://polymorph.spb.ru Потом поставил под свой FreeBSD VDK builder... Не так кайфово, но приятно... В общем, при работе с библиотекой VDK я не заметил каких-то особых отличий в программировании под винду или юникс. Тем более, что вместо winmain в mingw32 можно писать main :))) Для тяжёлых случаев - библиотека классов wxWindows. Одинаковые классы что под виндовс, что в юниксе, что на маках...

В общем, возвращаясь к начальной теме.
Я программировать GUI недавно начал (а точно - неделя как :)
В начале я писал всякий системно-служебный софт под юнихи на gcc.
Потом я прикололся, что есть djgcc - типа, все проги можно собирать под дос, да ещё и LFN виндовые поддерживаются.
Потом по приколу mingw32 поставил...
(это всё gcc) Прикол - под ним виндовые проги собираются! :))))
Нашёл к нему офигенную RAD IDE - http://polymorph.spb.ru
Потом поставил под свой FreeBSD VDK builder... Не так кайфово, но приятно...
В общем, при работе с библиотекой VDK я не заметил каких-то особых отличий в программировании под винду или юникс.
Тем более, что вместо winmain в mingw32 можно писать main :)))
Для тяжёлых случаев - библиотека классов wxWindows. Одинаковые классы что под виндовс, что в юниксе, что на маках...

>Я конечно извиняюсь, но если писать GUI на скриптовом языке для
>такой программы как 3DStudio MAX, то могу представить себе этот
>тормоз

3DSMax - не эталон, а песочница, где дети играют.
странная попытка впихнуть как можно больше в одного 
большого гиппопотама, и, как результат - безобразно 
перегруженный отвратный интерфейс для чемпионов по
скоростному мышенажиманию.
Для таких продуктов скриптовые языки и не предназначены.
Идеальное применение Tcl/Tk - automated test systems с 
простым интерфейсом.
Кстати, Tcl - отличный кандидат если необходимо расширить
приложение скриптовыми возможностями - он идеально встраивается
в приложения на Си. И в программах типа 3dsmax (тьфу!:) это иметь
необходимо.

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