> Были, да. Но она прошла почти незамеченной, и в 70-х все исследования были направлены на нормальные АТД («А» в данном случае «абстрактные», не алгебраические). А потом «something, somwhere has gone terribly wrong» (с), и ублюдочная хрень Смоллтока завладела умами.

и по-моему не зря завладела

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

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

З.Ы. я не говорю, что хороший синтаксис не нужен — он конечно нужен, но сейчас вместо него прогерам приходится учить паттерны... плохо, но не смертельно (тем более, что верификация не страдает)

Броня была непробиваемой для всех основных немецких танковых и противотанковых пушек.

не броня была непробиваемая, а немецкие пушки были малоэффективны, что означает сокращение дистанции поражения, а вовсе не god mode

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

//починил

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

Заблуждение, на первых Т-34 движки и трансмиссия ломались в хвост и гриву, и в поле нифига не ремонтировались.

ну, ломались, и что? Вы погуглите что такое ремонтопригодность

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

И кстати, на начало войны танк был дорогой.

и после войны - тоже

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

да

Я привёл пример, что в более мейнстримовом языке их не меньше.

пока Вы привели пример, показывающий что в мейнстримовом языке они тоже есть, но с этим никто и не спорил

> Были, да. Но она прошла почти незамеченной, и в 70-х все исследования были направлены на нормальные АТД («А» в данном случае «абстрактные», не алгебраические). А потом «something, somwhere has gone terribly wrong» (с), и ублюдочная хрень Смоллтока завладела умами.

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

в том, собственно, и профит объектов — они каждой бочке затычка, и о технологиях типа продолжений уже никто и не знает... и справедливо

if-стейтмент который менее гибок чем в C

это чем же? :)

нет конструкции do..while

есть

while True:
  do_stuff()
  if not condition():
    break

нет такого стройного event loop как в tcl

что там такого стройного?

нет приватный полей в классах

есть

Сразу скажу что питон я очень люблю и много на нём пишу. Цели его опустить нет. Список с потолка взял, в реальности я с другими проблемами сталкиваюсь(хотя проблема сопряжения event loop-ов нескольких либ для меня стоит остро).

if-стейтмент который менее гибок чем в C

это чем же? :)

Присвоение нельзя сделать и сразу проверить, в некоторых ситуациях это очень плохо когда есть if..elif...elif.. Код получается страшный. Впрочем, у меня в этом надобности не возникало и вообще с эксепшенами код возврата не очень полезен. В общем, это касается только кривого кода.

нет конструкции do..while

есть

это костыльная эмуляция, мне очень не нравится. Можем долго спорить, но while True.. это не то же самое что do..while. Я даже скажу почему нету do...while: на синтаксис плохо ложится. Предложенные варианты были не очень. не так же писать:

do
 some_stuff()
while condition

нет приватный полей в классах

есть

с подчёркиваниями? :). Или ты про самописные декораторы? Мне подчёркивания режат. Хотя, добавлять в питон приватные поля это только портить его ООП-модель. Она очень простая и в большинстве случаев эффективная.

нет такого стройного event loop как в tcl

что там такого стройного?

Увы, нету под рукой ссылочки чтобы наглядно показать. Скажем так, в tcl есть средства которые позволяют использовать event loop интерпретатора. Используя это, например, можно избежать проблем когда в проге несколько независимых библиотек со своим event loop. Например, gtk который морду рисует и сетевое io. Так придётся одно с другим как-то сопрягать, по отдельным тредам разносить, устраивать между ними взаимодействие.(а может это всё показалось, на tcl не программирую).

Зато в большинстве других языков нет говорящих соба^W^Welse-веток в циклах for/while.

А чо там? ну так короткий список для моего общего развития :). if-стейтмент... do..while... event loop... GIL... нет приватный полей в классах... What else?

Я просто оставлю это здесь.

Версия для Ъ. На картинке изображена лыбящаяся бородатая харя Гвидо, подпись же гласит:

Быстродействие?
Многопоточность?
Компилятор?
Проверка типов?
Приватные методы?
Паттерн-матчинг?
Хвостовая рекурсия?
Switch-case?
Карринг?
Ленивость?
Алгебраические типы?
Округление результатов?
Соглашения об именовании?

ДА ВСЁ ЭТО НЕ НУЖНО!
PYTHON

Картинка весёлая, но баян :). Доля правды там, несомненно, есть. Но тут же в треде сказали что скорость не нужна :). И ленивые вычисления не проблема. Каррирование... На википедии есть пример и с питоном :). Ну остальное не буду комментировать типа «проверки типов» :).

ДА ВСЁ ЭТО НЕ НУЖНО!

именно :)

Что-то... как-то... и не смешно, и не правда. В чем лопата-то?

> не смешно

Кто в армии служил, в цирке не смеётся?

>> if-стейтмент который менее гибок чем в C

это чем же? :)

Присвоение нельзя сделать и сразу проверить, в некоторых ситуациях это очень плохо когда есть if..elif...elif.. Код получается страшный.

ничего не стрaшный, но если уж жжётся, то подпихнём костылёк и voi'la :)

>> нет приватный полей в классах

есть

с подчёркиваниями? :)

class foo(object):
    def __init__(self):
        self.__private_bar = None

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

А если так? :)

class foo(object):
    def __init__(self):
        self.__private_bar = None

f=foo()
print(f._foo__private_bar)

Ну это я уже поржать запостил :).

А про костылёк... А если там несколько if...elif...elif? :) Не, ну выкрутится можно... как уж на сковородке :).

я - den73

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

По некоторым вопросам я сделал свои решения и успокоился. В частности: 1. я могу задавать локальные (для данного пакета) никнеймы других пакетов. С вложенными пакетами пока ничего особо хорошего не получилось, т.к. не совсем легко придумать для них хорошую семантику, не порождающую новые грабли взамен старых. Так что, я думаю, локальные никнеймы являются оптимальным решением. Почти готово к публикации, но лень доделать. Если кто хочет помочь с публикацией - это хорошо. 2. вместо loop я пользуюсь iterate, точнее, пропатченным iterate, где можно писать (iter (:for a in '(1 2 3)) (:collect a)). Он до сих пор лежит на iteratekeywords.sourceforge.net, но, видимо,уже отстал от развития iterate. Без этого патча я не мог пользоваться iterate - было слишком неудобно. 3. format-ом я пользуюсь мало, вместо этого сделал своё подобие. Кривое, но работает и меня устраивает. Не опубликовано. 4. Вместо классов стараюсь пользоваться структурами. Благо, реализации обычно допускают рефлексию, т.е. можно вытащить данные о полях структуры. Хотя это, пожалуй, скорее плохо, чем хорошо, ибо классы переопределяются, а defstruct-ы - нет.

> за 20

В том то и проблема, что за 30.

пока зубры ещё живые - всё будет тип-топ,

надеюсь что успеют смену передать

Да нет их уже по большей части. И не потому что умерли, а потому что разбежались. На своих местах остались только самые ленивые и не предприимчивые.

летают на наших мамонтячьих ракетах - у них ещё хуже?

Ну, дык, ракеты это единственное, что у нас ещё получается нормально делать. В смысле, производить ракеты старой разработки. А у американцев временная проблема просто. И они на наших ракетах летают, но свою начинку не дают (а наша говно). Так что у них всё хорошо.

Для спорщиков "какой язык лучше"

Для спорщиков «какой язык лучше»

Скоро начинается новый Google AI Challenge http://hypertriangle.com:13080/index.php

Заведите ветку с обсуждением алгоритма, а реализацию каждый делает на своём любимом языке - и объективно, и патриотично, и в резюме можно вставить.

> Скоро начинается новый Google AI Challenge

прошлый тут как-то мимо прошел... тутошние граждане выяснять «лучшесть» в бою не уме^W любят :)

> I thought I'd add my two cents. I have 30+ years programming and have

used many languages. I see lisp as an unmatched thing of beauty. I have

often thought of why lisp isn't much more popular. I think the reasons

have changed over time but this is the reason why now.

Lisp has two problems as follows:

1. Too many people view lisp as an ancient language. Out of date. Dated.

Old ideas that have been superseded. They see C# as modern. I mean

imagine, C# even has lambda functions now. What do us lispers have to

say about that? Lambda functions are so new, and as a new language, C#

is able to take advantage of these new ideas. Ha.

2. This is a real biggie!! Lisp libraries are too out of date. Really.

The world is using portable GUI's, standard SQL interfaces, XML, Web

Services, etc.. Yes, Lisp has libraries that support many (but not all)

of these sorts of things but I have experimented with them. They really

don't work. They're kludgy, lacking, non-portable, unsupported,

half-implemented, impossible to setup and configure, etc.. It's just too

much work. Lisp has got all the language features totally nailed down in

the most elegant way imaginable but the libraries needed to interact

with the modern world are awful (a technical term).

Again, I have tried many of those libraries and found many half-baked

attempts but few fully supported, portable libraries needed to do real

work. Just try doing Web Services in Lisp!

If there were a critial mass of interest in Lisp the libraries would be

built. Other aspects of the beauity and strength (combined with the

libraries) would help with people's view of lisp as out dated. Support

of (good or bad) standards is the path to popularity. Fix #2 and #1 will

fix itself.

If the libraries are really so bad, how come professional Lisp
programmers achieve so much? There is something wrong in that reasoning.

You can find bad libraries in any programming language. Dan Weinreb of
ITA Sofware said in a presentation at an ECLM that they have never
experienced a library problem for their Common Lisp development, and
they probably use more or less all Common Lisp libraries that exist. ;)
Just one example.

If you want to get things done in Lisp, you can. (Maybe that's the
difference, that mainstream languages cater to the people whose primary
goal is not to get things done.)

> If the libraries are really so bad, how come professional Lisp

programmers achieve so much?

С библиотеками действительно ситуация такая, как было описано выше.

Dan Weinreb of ITA Sofware said in a presentation at an ECLM that

they have never experienced a library problem for their Common Lisp

development

Конечно. Посмотрите для чего они используют CL. У них просто нет большой потребности в библиотеках. А там, где нужно много хороших библиотек, они используют Java и Python.

с появлением квиклиспа ситуация намного улучшилась, конечно нужно время пока все устоится.

> Давай подойдём к вопросу утилитарно и сравним образцы военной техники потенциальных противников?

Давай подойдем к вопросу утилитарно и скажем, что и в оборонке, и в телекомах, и в <you-name-it> тоже приходит молодежь :) Но Лиспа там больше не становится.

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

А чо там? ну так короткий список для моего общего развития :)

По сравнению с другими динамическими говнами? Меньше пафоса и больше батареек.

Помню про if-стейтмент который менее гибок чем в C, нет конструкции do..while

Если рассуждать на таком уровне, то самый большой недостаток - то, что Python не expression-oriented. Ну, еще лично мне хотелось бы AST-макросы, но... наверное, я просто под впечатлением от Nemerle :)

> Давай подойдем к вопросу утилитарно и скажем, что и в оборонке, и в телекомах, и в <you-name-it> тоже приходит молодежь :) Но Лиспа там больше не становится.

Приходят-то кто? Жабонетобыдлокодеры. Большему не учат в рашке.

>> А потом «something, somwhere has gone terribly wrong» (с), и ублюдочная хрень Смоллтока завладела умами.

и по-моему не зря завладела

Ты не понял моей печали %) А печаль о том, что ООП, особенно в исполнении Смоллтока - это просто набор эвристик, которые некоторое время хорошо работали. То, что работали они в динамическом говноязыке, народ из виду упустил, и в результате индустрия потратила кучу времени на попытки слепить пулю пусть не из говна, но из алюминия. И только в конце 200x заново открыли наследие того же ML.

> Приходят-то кто? Жабонетобыдлокодеры. Большему не учат в рашке.

Какая разница чему учат? Человек сам учиться и имеет возможность самостоятельно принимать решение.

> Приходят-то кто? Жабонетобыдлокодеры.

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

Большему не учат в рашке.

А в какой стране молодежь приходит на работу и приносит с собой Лисп?

> Ты не понял моей печали %) А печаль о том, что ООП, особенно в исполнении Смоллтока - это просто набор эвристик, которые некоторое время хорошо работали. То, что работали они в динамическом говноязыке, народ из виду упустил, и в результате индустрия потратила кучу времени на попытки слепить пулю пусть не из говна, но из алюминия. И только в конце 200x заново открыли наследие того же ML.

Ну, статическая типизация головного мозга не лечится, так же как и динамическая.

я принес, но не в рашке. В рашке инициатива наказуема.

> Ну, еще лично мне хотелось бы AST-макросы, но... наверное, я просто под впечатлением от Nemerle :)

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

Если рассуждать на таком уровне

А если на более высоком? Какие у него, на твой взгляд, самые страшные косяки в дизайне?

> я принес

Да многоли вас таких...

>> Если рассуждать на таком уровне

А если на более высоком? Какие у него, на твой взгляд, самые страшные косяки в дизайне?

В дизайне языка? Кроме того, что он не expression-oriented, мне ничего не мешает. Хотелось бы настоящие private-поля, но, в общем, и без них жить вполне можно.

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

> Если рассуждать на таком уровне, то самый большой недостаток - то, что Python не expression-oriented. Ну, еще лично мне хотелось бы AST-макросы, но... наверное, я просто под впечатлением от Nemerle :)

Ну, предположим, добавили эти expression-oriented и AST-макросы, что получаем в итоге? НедоЛисп? так почему бы сразу лисп не использовать?

> Ну, предположим, добавили эти expression-oriented и AST-макросы, что получаем в итоге?

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

НедоЛисп?

Назови его, как сам захочешь. Я, как говорится, «could care less only if paid».

так почему бы сразу лисп не использовать?

Опуская технические детали (ну там платформу, библиотеки, IDE и прочие инструменты) - потому что лисперы через одного йопнутые на голову последователи Эрика Наггума. Ну ладно, не через одного, но таких многовато.

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

Я знаю как тебе помочь, не читай ЛОР - читай списки рассылки, мир сразу станет лучше.

> Я знаю как тебе помочь, не читай ЛОР

«Поздно, поздно! - кричал Вульф. Пена и кровь стекали по его подбородку» (с)

:)

читай списки рассылки, мир сразу станет лучше.

Дело в том, что я их читаю. И, если в список рассылки заявился какой-то ушлепок и начал объяснять «вы лохе и ничего не понимаете в языках программирования», этот ушлепок наверняка лиспер. Проверено в девелоперских списках D и Python.

НедоЛисп?

Это скорее ПереЛисп, т.к. там есть ADT и ADT-ориентированные функции и лямбды.

Что касается макр - опять же, если в языке нет ADT, то чтобы иметь возможность метапрограммирования нужно в реализации поставить хук под название «макросы», если же АТД присутствуют - сам язык представим в виде АТД, и роль макросов играют обычные функции.

Собственно, в лиспе вместо АДТ s-выражения, а макросы - функции от s-выражений, возвращающие их же.

> Что касается макр - опять же, если в языке нет ADT, то чтобы иметь возможность метапрограммирования нужно в реализации поставить хук под название «макросы», если же АТД присутствуют - сам язык представим в виде АТД, и роль макросов играют обычные функции.

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

Макрос даже не обязательно должен быть функцией. Единственное требование - его можно _использовать_ в качестве функции, которая принимает АСТ и возвращает АСТ (как АСТ представлено - вообще не важно). Вот макрос может быть чем угодно, что удовлетворяет такому требованию.

А чем так знаменит Эрик Наггум? Да, похоже, что его уже нет с нами...

> А чем так знаменит Эрик Наггум?

Троллингом нубов.

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

> Дело в том, что я их читаю. И, если в список рассылки заявился какой-то ушлепок и начал объяснять «вы лохе и ничего не понимаете в языках программирования», этот ушлепок наверняка лиспер. Проверено в девелоперских списках D и Python.

Это скорее всего один-ушлепок-тролль специально подписанный на все эти форумы, и скорее всего ненавистник лиспов - просто провокатор.

> Это скорее всего один-ушлепок-тролль

Скорее всего это виртуал лавсанчика.

> Кстати, к тебе, как апологету статики, вопрос.

То, что я предпочитаю статическую типизацию, не значит, что я какой-то гуру по современным система типов (у меня даже Пирс нечитанный лежит где-то :/).

типы соответствуют произвольном предикатам языка и единственная информация компилятору о типе переменной - это в какой ветке вычислений эта переменная стоит

Эээ... это что-то похожее на dependent types? У них какие-то фундаментальные теоретические проблемы. Спрашивай лучше quasimoto и jtootf, они этим увлекаются.

Function это system class - выполнятся они могут в любой стадии (runtime, compile-time, read-time, load-time, ...), но чтобы облегчить процесс метапрограммирпования в реализации их разделяют на разные виды функций, которые лежат в разных хэш-таблицах - в одной лежат обычные функции (аккессор - symbol-function), в другой макро-функции (аккессор - macro-function) и в третьей функции макро-комиляторы (аккессор - compiler-macro-function). Все эти виды функции могут использоваться в любой стадии (действительно - у нас есть аккессоры и мы можем взять объекты системного класса function, удовлетворяющие предикату functionp, и можем использовать их как значения (аргументы) и, в том числе, как аппликаторы (для funcall/apply)).

Это разделение не строгое, оно только означает, что функции первого вида _как правило_ работают в runtime, а второго и третьего _как правило_ в compile-time.

И последнее - есть ещё соглашение о том что (symbol ...) есть (apply (accessor symbol) ...) где accessor это symbol-function, т.е. функция из первой таблицы.