Фраза о Лиспе...

В первый раз, наверное, со времен РФВС, прочитал _весь_ топик с удовольствием - много интересных мыслей, интересных ссылок, интересных мнений.

Вставлю свое скромное О(pinion). Безусловно прочтенный мною наполовину SICP (с выполненными упражнениями!) также вкорне изменил мой взгляд на программирования. _Нормальные_ программисты должны взращиваться именно на таких учебниках, я бы еще добавил хороший курс дискретной математики, алгебры (конечно-порожденные полугруппы) и математической логики. Что, как я понимаю, и изучается на Западе на специальности computer science. По нелепой иронии судьбы, в России, где так много талантливых людей, "программистами" называют именно (было)кодеров - людей, которые решают конкретные прикладные задачи с помощью компьютеров. Чтобы аналогия стала более прозрачной, сравните, например, бухгалтера и математика. И для того, и для другого математика - их хлеб. Но какова дистанция в стиле мышления и решаемых задачах! Так вот, хочу сказать, что будущих программистов попросту калечат, заставляя мыслить так, как выполняет работу вычислительная машина. Ведь как учат программированию - именно в терминах "а как это делает машина" (сам помню еще свою учительницу в школе, между прочим отличный педагог). И это происходит в ВУЗах(!). Посмотрите: за исключением нескольких ведущих ВУЗов страны на остальных на специальностях "программирование" изучают конкретные программы и языки, что в действительности, конечно, тоже нужно, но уже человеку, который более-менее специалист. Таким образом, без должной подготовки, растут не специалисты, а ремесленники, пусть и весьма искусные. Конечно, после "12 лет" такого существования, Delphi (паскаль) покажется "логичной", а scheme - странной. Не удивителен, также тот факт, что лучшие программисты часто выходят из стен математических и физико-математических факультетов - они могут и умеют думать абстрактно.

Таким образом, "mainstream" сейчас - это все более изощренные орудия труда для ремесленников от программирования (коих тут называют "быдлопрограммерами"), а не то, что составляет действительно computer science в приложении к практическим проблемам.

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

Ну не удержусь еще раз (на этот раз - точно последний, честно-честно)...

> хороший курс дискретной математики, алгебры (конечно-порожденные полугруппы) и математической логики

Нас, кстати, этому учили (наша программа была чем-то средним между американскими reference-программами по CS и SE). Дискретная математика и матлогика, в общем-то, пригодились, но алгебра...

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

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

Другое дело, что необходимо и умение перейти "на уровень выше" и увидеть лес, а не деревья. Здесь нужен какой-то другой предмет - теория систем, ТРИЗ, инженерная философия, если хотите :) Возможно, Scheme пригодится как язык лабораторных занятий по такому предмету.

Настоящий программист должен уметь представить работу системы на разных уровнях.

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

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

А то, что подготовка программистов сейчас - не обучение, а натаскивание, это, ИМХО, следствие деградации системы образования.

> Ну не удержусь еще раз (на этот раз - точно последний, честно-честно)...

хороший флейм согревает душу и тело :)

> Нас, кстати, этому учили (наша программа была чем-то средним между американскими reference-программами по CS и SE). Дискретная математика и матлогика, в общем-то, пригодились, но алгебра...

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

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

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

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

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

SE - это что? А про техническую сторону дела - так математику главное - решить. :)

А, понял. SE - это software engineering?

Активный пеар местных лисперов сподобил меня в очередной раз взяться за покорение Лиспа. Вытащил из кладовки финнов, стряхнул пыль и приступил...

Прежде всего, обнаружил листок формата А4, на котором я, тогда еще студент, старательно расшифровывал мнемоники MicroLisp. Это та реализация, которую я таки с трудом нашел для ZX Spectrum, и которая занимала всего 6 килобайт кода. Правда, больше половины финских примеров не работало. Посему листок был аккуратно сложен в книгу, а книга поставлена на полку. До лучших времен. А вместо Лиспа был взят Форт, интерпретатор которого хоть и занимал аж целых 8 килобайт, зато все примеры из учебников в нем работали. Даже Лисп-машина ;-).

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

Впрочем, я опять не об этом. Я об том, что я добрался у финнов до главы о том, как списки в памяти хранятся. Тогда, в студенчестве, меня как-то эта глава не вдохновила. Ну списки и списки. Я в Паскале такие списки в то время левой задней за одну пару ваял. Аха. Без индексов и на рекурсии. Типа крута. Я тогда даже факториал на Паскале рекурсивно писал. Аха. Пробовал даже на третьем курсе рекурсивно написать метод Рунге-Кутта, что на численных методах требовалось. Но преподаватель решения ниасилил :-(. Впрочем, времена были тяжелые. Преподаватель, например, так и ниасилил мой чудный архиватор, который реализовывал упаковку хаффмен-методом на... Прологе. И как наш препод по трансляторам многочисленно кивал на мой парсер Паскаля, писанный на том же Прологе. Оба покемона, правда, безбожно тормозили, а парсер еще и вылетал с переполнением стека. Зато это было круто, концептуально чисто и, что особенно важно, -- высокоуровнево и абстрактно. В общем, лисперы должны меня понять.

Но речь опять не об этом. Речь о том, что я сейчас с высоты своего программистского пьедестала (чего бы там ни говорили всякие yyk'и) отлично знаю, чем массив отличается от списка. И хорошо понимаю, зачем, например, в GOBO для абстракции последовательности определены две реализации. Ибо вставка в середину массива в худшем случае имеет сложность O(n), а поиск -- не ниже O(log n), а то и вообще O(1). Для тех лисперов, которые не понимают -- это я о таких "лишних сущностях", как индексы ;-). С другой стороны, связанные списки имеют сложность вставки O(1), зато поиск -- не лучше O(n). По сортировке не скажу точно. Кажется, у Вирта можно найти алгоритмы O(n log n) и для тех и для других.

В общем, возвращаюсь к теме. Можно ли на Лиспе нативно (или, как любят говорить наши друзья-лисперы, "без кастылей") оперировать с абстракциями массивов? Ну то есть, еще более конкретно:

а) какова реальная сложность функции nth и предиката member (или что там есть аналогичного в CL)?

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

Ну а если кто из лисперов начнет задавать вопрос класса "нафиг нужно?", скажу прямо: нужна абстракция хэш-множеств. То есть, в задаче говорится, что упорядоченный набор данных ну ни разу не нужен, зато нужна скоростная выборка. Скажем, если хранить элементы в виде упорядоченного (отсортированного) списка, то вставка будет O(n) (как для массивов, так и для списков), а вот поиск, как я уже писал, порядка O(log n). А с использованием хэш-таблиц так вообще можно получить и вставку и выборку O(1). Правда, не всегда. Хэши, особенно для структур имеют дурную привычку деградировать, и мы тогда быстренько получаем выборку O(n). Посему я в свое время и не рискнул использовать Python (правда, тогда это был Ruby) для прототипирования. Ибо хз, как там эти хэш-функции считаются. Для надежности пришлось писать свои. А чтобы избежать геморроя со сборкой мусора, то единственным выбором для простоты разработки остался Эйфель.

Если кто еще не понял, нафига мне этот огород, спрошу еще прямее: нужна эффективная работа с BDD/MDD. Ибо на отдельных эпизодах приходилось поддерживать в кэше до 200000 узлов, на на стресс-тестах, которые так и не прошли -- до миллиона. В MoscowML работа с BDD реализована через внешние библиотеки на С. Вот такой кастыль, да. Ибо язык не строит из себя функциональную целку и допускает простую (ну, не такую простую, как в Эйфеле, конечно же) интеграцию с ассемблером. А как оно в Лиспе? Нативно можно сделать? Или опять с помощью "кастылей" придется?

Вот, а если кто меня еще не понял, то для лисперов-гуманитариев, которые нам так складно поют про "единственный высокоуровневый язык программирования", советую почитать о Законе Дырявых Абстракций: http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html. Особенно советую обратить внимание на примеры с SQL и C++. Думаю, приведенный мною пример тоже можно было бы поставить рядом. Впрочем, так же, как и пример tailgunner о дырке в абстракции автоматического освобождения памяти и ее роли в реалтайм системах.

Там же, кстати, можно найти и рассуждения о том, почему нельзя ограничиться знанием одного лишь Лиспа, а начинать изучение всегда придется с ассемблера. Ну в крайнем случае, C.

ух, скоко накропал!

массивов в лиспе есть. Как обычно, намного луче чем в остальных ведомых мне наречиях. Тут понаписато: http://www.lisp.org/HyperSpec/Body/chap-15.html

ещё есь контейнеры типо последовательнось: http://www.lisp.org/HyperSpec/Body/chap-17.html

и хеш таблицо http://www.lisp.org/HyperSpec/Body/chap-18.html

две последние упоминаю просто на всякой случяй. Заодно оглашаю весь список имеющихся в коммон лиспе: http://www.lisp.org/HyperSpec/FrontMatter/Chapter-Index.html

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

до кучи упомяну, чё есть операции pop и push, т.е. список может хорошё работать как стек.

при необходимости можно юзать наружние функции на других наречиях при помощи alien interfaces: http://www.cliki.net/compatibility%20layers

Продолжаем разговор об абстракциях.

Вот, проникшись религией Лиспа об уменьшении сущностей, совершенно нифига не понимаю, почему в CL для определения значений и функций используется совершенно разный синтаксис: в одном случае -- через set, в другом -- через defun? Накуа такая лишняя сучность? Чо эт за дискриминация на "код" и "данные", которые правоверные лисперы должны всячески порицать? Где хваленная обработка "кода аки данных"? Какой догмат запрещает использование вот такой штуки:

* (set 'a '(lambda (x y) (+ x y)) * (a 2 3)

?

И почему, если уж примем богопротивность сего на веру, то почему вот это:

* (set 'a '(lambda (x y) (+ x y)) * (defun add 'a) * (add 1 2)

Выдает совершенно эзотерический NIL вместо логичного 3? Не говоря уж о кошерном исключении, если таковое богохульство недопустимо религией?

Кстати, у финнов написано, в секте FranzLisp функции и переменные -- это единая сучность в двух лицах. Получается, что FranzLisp -- более богоугодное наречие?

Мля, и эти люди еще собираются учить нас про программирование...

...ское форматирование :-(. Программы читать так:

* (set 'a '(lambda (x y) (+ x y))
* (a 2 3)

* (set 'a '(lambda (x y) (+ x y))
* (defun add 'a)
* (add 1 2)

> Накуа такая лишняя сучность?

Юзай схему, а CL - фтопочное чудище, тут я согласен. :)

> ух, скоко накропал!

Это крик души. И одновременно плач по невинно загубленной бурной молодости ;-).

> Заодно оглашаю весь список имеющихся в коммон лиспе:

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

Кроме того, так сходу не увидел в документации оценок сложности. Впрочем, я их нигде, кроме как в GOBO и не видел.

> до кучи упомяну, чё есть операции pop и push, т.е. список может хорошё работать как стек.

А вот это точно никому, кроме декадентов не нужно.

> Юзай схему, а CL - фтопочное чудище, тут я согласен. :)

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

Тогда вообще юзай OCaml какой-нибудь, вполне себе практичный. :)

> Накуа такая лишняя сучность?

см. спор лисп1 vs лисп2. Ктото мыслит чё так луче, ктото мыслит чё подругому. У всех свои аргументы. Ты выбираеш как тебе нравицо.

> Какой догмат запрещает использование вот такой штуки:

никакой. Пользуйся наздоровье.

> Выдает совершенно эзотерический NIL вместо логичного 3?

Увы, лисп не исключение. Чёбы ево юзать, ево надо знать.

(set 'a '(lambda (x y) (+ x y)) - связывает а не с лямда-функцией, а списком. Если хош выполнить, юзай навыбор:

(set 'a (lambda (x y) (+ x y)))

(set 'a #'(lambda (x y) (+ x y)))

или (set 'a '(lambda (x y) (+ x y))) (set 'b (eval a))

> Выдает совершенно эзотерический NIL вместо логичного 3?

здесь разгадка: http://www.lisp.org/HyperSpec/Body/mac_defun.html

Поступи так вместо:

(set 'a #'(lambda (x y) (+ x y)))

(defun add (p q) (apply a (list p q)))

и будет те щястье.

> Однако ж, это таки уже не чистый лисп, похоже?

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

> Или можно позырить на реализацию сих абстракций на девственно чистом Лиспе?

Я не понимаю чё ты хош. Если хош глядеть, как реализовано - зри в изходники того же cmucl или sbcl.

> А вот это точно никому, кроме декадентов не нужно.

Хм, ну когда как...

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

Дыкть, так и делают. На первом курсе учат Паскаль, на втором -- ассемблер. А ближе к четвертому-пятому -- всякую экзотику типа Лиспа или (как у нас) -- Пролога и прочих GPSS. Другая беда, что многие студиозусы к этому моменту уже видят себя крутыми программерами, потому как уже устроились пристойными лабателями GUI в более-менее приличной конторе "Остап и программисты Ltd". Ну а кто виноват?

Кстати, сегодня на OSDN выступал один преподаватель из Львова, зашла речь о языках, которые преподаются в школе. Препод жаловался, что под Linux нет хороших сред для обучения программированию. Народ выпал на измену. Подошли после доклада, начали наперебой предлагать решения: Питон, Паскаль. Вспомнили Лого. Классный язык, я балдел в свое время. Ведь Лого -- это прямая подсадка незрелых детских умов на функциональщину. В общем, наше фсио. Так вот, выяснилось, что успешно внедрить Лого удалось только полякам которые стырили часть реализации у чехов. Если преподавать Лого нашим отечественным школярам, то тут же занимают четвертую позицию. А Вы говорите -- образование...

> Как так? Это спецификация коммон лиспа.

Ну, тут где-то пробегало (в версии от yyk), что чистый лисп -- это (T NIL CONS CAR CDR QUOTE). А все остальное -- или от лукавого или можно выразить через эти божественные сучности.

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

Кстати, не подскажешь по быстрячку, где можно надыбать сабж под оффтопик? Бо искать влом.

> Если хош глядеть, как реализовано - зри в изходники того же cmucl или sbcl.

Вопрос в том, на каком языке написаны эти исходники в части массивов? На кошерном Лиспе или некошерном С?

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

А чо, Кнут уже не рулит?

> ну прецтафь чё лисп - это такой паровой движёк а ты - enterprise slave. Про остальное сам догодайся.

Как говорится, "два солдата из стройбата заменяют экскаватор". У нас тут недавно тестеров тока-тока перевели на автоматическое тестирование гуевины посредством соответствующих роботов. Аха. Тестеры роботов днем ваяют, а те ночью, пока тихо и спокойно -- тестят. И то было на три месяца споров на предмет "а нафига нам это?". И главный аргумент начальства был на тему: "Если мы научим девочек-тестеров писать роботов, то они возомнят себя крутыми программерами. И платить им придется, как программерам. И станет их дом -- полная чаша. И станут они жить не нашей жизнью".

А Вы говорите -- программисты...

> Ну, тут где-то пробегало (в версии от yyk), что чистый лисп -- это (T NIL CONS CAR CDR QUOTE). А все остальное -- или от лукавого или можно выразить через эти божественные сучности.

Можно, без проблем. Вот я и говорю, посмотри в сырцах как оно выражено или в учебниках. Оно несложно выражаецо, но спецификация лиспа требует чёбы оно было готовое. Это типа функции ну например возведения в степень в любом наречии. Хоть её несложно сделать самому, но она почти везде есь готовая.

> оффтопик

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

> Вопрос в том, на каком языке написаны эти исходники в части массивов? На кошерном Лиспе или некошерном С?

В разных реализациях по разному. Могу предположить чё в clisp возможно на С а в cmucl и sbcl на лиспе.

> Целые равномощны натуральным, действительные - рациональным.

Эт, Вы, батенька, загнули. Алеф-2 завсегда был больше, чем алеф-0. Кантора давно в последний раз читали?

;-)

>Вопрос в том, на каком языке написаны эти исходники в части массивов?
На кошерном Лиспе или некошерном С?

clisp на C написан, а sbcl на 99% процентов самина себе. Даже 
где-то в юзнете были замеры объема кода на LISP vs. C. На Си там 
написано минимальное ядро, зависимое от ОС и архитектуры. Здесь никуда 
не денешься -- ОС торчит в мир сишной жопой. Ну там потоки и пр.

Массивы? Массивы оптимизируются хорошо. Как настоящие. Вот тут
кусочек маленький вырванный случайно из кода sbcl. Это кусок 
кодогенератора для нативного x86-64. вот видишь там (inst ...) ? 
Это ассемлер: 

http://sbcl.cvs.sourceforge.net/sbcl/sbcl/src/compiler/x86-64/array.lisp?revisio
n=1.10&view=markup

А тут арифметика.

http://sbcl.cvs.sourceforge.net/sbcl/sbcl/src/compiler/x86-64/arith.lisp?revisio
n=1.19&view=markup

Еслиинтересно, то можешь походить по исходникам. Сишная часть лежит
в runtime.

> Дыкть, так и делают. На первом курсе учат Паскаль, на втором -- ассемблер. А ближе к четвертому-пятому -- всякую экзотику типа Лиспа или (как у нас) -- Пролога и прочих GPSS. Другая беда, что многие студиозусы к этому моменту уже видят себя крутыми программерами, потому как уже устроились пристойными лабателями GUI в более-менее приличной конторе "Остап и программисты Ltd". Ну а кто виноват?

Так я про то и вещаю, что так делать НЕ НАДО, бо калечатся юные умы особенностями ассемблера x86, после чего никакие другие архитектуры без ломки не воспринимаются. Слова "стековый процессор" или иная нестандартщина в лучшем случае вызывают реакцию: "гыы, а что, прикольна... но нафиг не надо".

Лого - да, наше фсио. Но не для студентов-таки.

> А чо, Кнут уже не рулит

Кнут, безусловно, рулит. Но все-таки имеет смысл разделить эти предметы во времени и по преподавателям, а не так как в книге - все в одну кучу. Это позволит оформить "вкусизмы" - предпочтения отдельных личностей к тем или иным аспектам - проще профориентироваться. Кто-то пойдет в писателей компьютерной графики, кто-то - БД, кто-то займется написанием компиляторов. А "неасилившие" станут прикладными программистами :)

> действительные - рациональным.

> Эт, Вы, батенька, загнули. Алеф-2 завсегда был больше, чем алеф-0. Кантора давно в последний раз читали?

Аааа, посыпаю голову пеплом и ищу в интернете адрес действующего монастыря! Конечно, написал херню. Следует читать "рациональные - целым". :)

Да ЛОГО это нечто. Второй язык после васика в детстве. Жалко только про графику рассказано было в книге и нечего про остальное. Зато недавно нашел в инете книжечку по нему нормальную, все никак прочитать руки не доходят.Смотреть http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=3987 если охота качать или читать:
Volume 1: Symbolic Computing http://www.cs.berkeley.edu/~bh/v1-toc2.html
Volume 2: Advanced Techniques http://www.cs.berkeley.edu/~bh/v2-toc2.html
Volume 3: Beyond Programming http://www.cs.berkeley.edu/~bh/v3-toc2.html

> Так я про то и вещаю, что так делать НЕ НАДО, бо калечатся юные умы особенностями ассемблера x86

Асм x86 и Qbasic это была, есть и будет основа основ любого писишного программера. Без этого никуда, окромя дискуссий на лоре.

> Асм x86 и Qbasic это была, есть и будет основа основ любого писишного программера. Без этого никуда, окромя дискуссий на лоре

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

> У вас вообще кроме x86 никаких архитектур не существует. И не было. И до васика люди только счеты программировали.

"мы" ориентированы на практику, а вы на непонятно что.

> "мы" ориентированы на практику

примерно также, как коровы - на мясо.

> примерно также, как коровы - на мясо.

Ни разу. Мы ориентированы на конкретную работу, а вы - на маразм пополам с нарциссизмом.

> Скажу еще раз, чтобы не было недоразумений: безусловно, конечная цель любой науки - практика. Но она не должна быть единственной довлеющей силой, не должна _заменять_ эту самую науку. Иначе все станут ремесленниками, а не специалистами. Быть может и искусными, но не видящими решение дальше, чем того позволяют их инструменты и переданные учителем знания.

IMHO, computer science "не бывает" (С) ПНвС. Это раздел математики, и заниматься им должны математики (не даром ВМиК так называется, да?).

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

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

Быдлокодер, работающий рядом с настоящими программистами,

тупая и неумелая провокация. Жаль чё ктото повёлся.

> Мы ориентированы на конкретную работу

И ты конкретно работаешь на Qbasic? Или его знание помогает тебе в работе?

> Мы ориентированы на конкретную работу

А то ж! Уборщиц тоже надо г-о-р-а-з-д-о больше, чем профессоров. Никто и не спорит

привет снова. Если не секрет, какую пользу ты вынес из топика?

> Или его знание помогает тебе в работе?

Во-первых VB никто не отменял, во-вторых таки да оно помогает ПРАВИЛЬНО вникнуть во всё остальное. Примеры неправильного вникания мы можем в изобилии наблюдать в этом топике.

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

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

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

> оно помогает ПРАВИЛЬНО вникнуть во всё остальное

бугога! :)

> Если не секрет, какую пользу ты вынес из топика?

Пару ссылок - на "жизненную историю" (на RSDN), на статьи по Type Inference в Питон. Совет _прорешать_ SICP. И смутное предположение, что изучение Lisp - это как изучение иностранного языка: хорошая тренировка для мозгов, новый взгляд на родной язык, но... все языки примерно равны по выразительной мощности (что-то лучше выразить на одном, что-то - на другом). Не обязательно начинать _думать_ на иностранном языке.

>> Или его знание помогает тебе в работе?

>Во-первых VB никто не отменял

VB - никто, то ты помянул Qbasic! И вот он - абсолютно бесполезен сегодня. Об этом и речь - конкретные системы быстро устаревают, знания более высокого порядка - нет.

> таки да оно помогает ПРАВИЛЬНО вникнуть во всё остальное

Во _ВСЁ_ ? Всё == VB? Или Qbasic помогает вникнуть в Lisp? Или rule-based системы? В Си++ и его generic programming?

Не трудись отвечать мне. Себе ответь.

Прежде чем обвинишь меня в маразме и нарциссизме - я 16 лет работаю программистом и много всякого повидал/использовал.

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

Ну нам в МГТУ чё-то такое читали, да. Хотя я и учился на кафедре, связанной скорее с электроникой и АСУ - была у нас и теоретико-множественная алгебра (забытая напрочь), и логика (с Прологом, хотя и плоховато прочитанная); а на "чиста программистских" этого всего было больше, и было там и "построение компиляторов", и прочая и прочая.

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

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

Ну запретить издавать паранаучный бред было бы недемократично, а ожидать, что товаровед книжного магазина способен отличить торсионное поле от суперструны - нереалистично ;)

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

весьма сранное на мой взгляд утверждение, сродни тому что язык жестов и устная речь равны по выразительности только потому что и тем и другим можно одинаково успешно послать йухан. Вот тут пипл утверждает чё питон - это такой меееедленный но очень сильно недоделатый лисп: http://nostoc.stanford.edu/Docs/whylisp.html

цытато:

> Python, which is more-or-less lisp w/o the parens, is missing several critical features to do what we do in BioBike, esp. true macros, which enable you to manipulate expressions, create sub langauages, and engage in applicative programming. Someday the Python crowd will realize that uniform syntax is a good thing, and will re-adopt parens (or something like them), and then Python will just be Lisp again, and much the better for it!

Ужель ты _действительно_ думаеш, чё если что-то есть дополнительное, из этово нельзя извлехчь дополнительную пользу?

вместо сранное хотел написать странное, но вроде и так неплохо получилось.

> много всякого повидал/использовал.

кобол видал/юзал? Это по твоему марьгинальное? Когдато мейнстрим был...

> VB - никто, то ты помянул Qbasic! И вот он - абсолютно бесполезен сегодня. Об этом и речь - конкретные системы быстро устаревают, знания более высокого порядка - нет.

QB от VB отличается только гуем. Что вам там наплёл Гейтс никого не интересует. VB это суть QB под винды и с гуём и с классами и точка. А всяких vbrussian.com, которые пытаюстя на VB писать как на Си надо убивать было при рождении - ТАК поганить ТАКУЮ гениальную вещь как Бейсик это форменное извращение.

> Или Qbasic помогает вникнуть в Lisp?

В _программирование_.

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

> Вот тут пипл утверждает чё питон - это такой меееедленный но очень сильно недоделатый лисп

Вот чтобы на такое не отвечать, я и попрощался. Тебе отвечу :) - насчет языков ты передергиваешь (и сам это знаешь), насчет статьи - можно найти таких статей с обратным знаком. И примеров миграций людей с Lisp на Python (с Python на Lisp - не встречал, но и не искал особо). Так что это всё доказывает только то, что мнения есть разные (прикольная цитата со ссылки: "those who don't know Chinese think it's hard too, but the Chinese don't!").

Я бы с удовольствием послушал людей, которые имеют значительны опыт и в Лиспе, и в Питоне. Но как их отличишь от зашоренных ветеранов/неофитов Лиспа?

> кобол видал/юзал?

Кобол - нет. На PL/I - работал.

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

И что? Никогда не был хорошим языком (разработан слишком рано), устарел, но вполне жив за счет огромной кодовой базы.

[и не надо говорить, что Лисп из тех же времен: отличия Lisp 1.5 от CommonLisp - как разница между первой версией Си (1973) и Си++98]

Кстати, если к тебе прилипнет lambda-gtk, то как-то давно в их рассылке было сообщение, что кто-то сделал обвязку для CLOS. Нашел. Лежит (гы-гы) на народе: http://borigen.narod.ru/gtk-on-clos/ То есть получаем что-то аналогичное gtkmm все для того же CL. Объектно-ориентированое.

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

> и сам это знаешь

уверен, незнаю

> можно найти таких статей с обратным знаком.

я бы почитал для приколу если бы закинули пару ссыл.

> мнения есть разные

дык мя именно и интересует, почему склалось такое мнение. Посему и спрашиваю. Если бы мя интнресовал сам лисп/питон/... я бы книшку читал про это а не с жывым пиплом общялся бы.

> значительны опыт

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

> Никогда не был хорошим языком

но зато был майнстримом, котороно ты пытаешся держацо.

> и не надо говорить, что Лисп из тех же времен

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

> вполне жив за счет огромной кодовой базы

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

вообще, судя по датам релизов, ИМХО это всё трупики. На мой взгляд стоит всётаки приглядецо к clg и cells-gtk, особо к последнему.

> я бы почитал для приколу если бы закинули пару ссыл.

Пары нет (ну не интересует меня это), но по ссылкам из топика набрел на это: http://www.prescod.net/python/IsPythonLisp.html оттуда есть линк на интересную статью Норвига, в которой он обвиняет Питон в тормознутости, при этом не упоминая psyco.

>> мнения есть разные

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

Я и сам не знаю. В конкретном случае BioBike - там просто рекламный треск. Думаю, их основная претензия к Питону - то, что он не Лисп.

>> Никогда не был хорошим языком

> но зато был майнстримом, котороно ты пытаешся держацо.

8-O Я не стараюсь держаться мэйнстрима (это LOR, Linux.org.ru, да?), я стараюсь держаться технологий, которые я считаю "правильными". И вот если есть выбор из _таких_ технологий - я выбираю ту, которая мэйнстрим.

> умя нету опыта работы с дотнетиненадом, и не будет никогда.

Не зарекайся

> Но я совершенно точно и обективно знаю чё он кака

8-O впрочем, уже говорили об этом

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

Ты просто не в теме. Я тоже не особо, но IDE на основе Eclipse (это значит, довольно свежая) - есть, новые диалекты - создаются (NetCOBOL, ObjectCOBOL), а коммюнити просто keeps a low profile.