какой был у вас tkTable ?))

http://tcltk.free.fr/index.php3?idxcat=43
http://wiki.tcl.tk/1877

да и от самих биндингов и реализации их зависит.

и да, есть описание api tk :
http://www.hume.com/html84/indexes/tkc_api.html

и можно сделать именно все как вам нужно в конкретном яп.
Вроде так и поступили в tix (бидинг к тк) для питона.

den73

> какой был у вас tkTable ?)) Ответил выше, 2.10, тот который http://tktable.sourceforge.net Биндинги - ltk. В общем, не хотел бы продолжать наезды на tcl/tk, равно как и у Вас вряд ли получится обосновать, что tktable круче, чем какой-нибудь tsmdbgrid. Но это лишь отчасти характеризует язык, нужно учитывать ещё и количество вложенных сил. Также мы сравниваем проприетарный и опен-сорсный проекты.

А 2 add с различной семантикой и одним коротким именем add - это obscure.

Ну, вообще-то, из соображений целесообразности, часто используемые в данном контексте действия должны иметь короткие имена. И я бы даже назвал add просто знаком «+». Опрошенные мной лисперы обычно считают иначе и их трудно переубедить. Поэтому давайте не будем об этом спорить и останемся каждый при своём мнении.

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

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

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

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

>Тормознутостью и

А ты что, замерял? Ты написал охрененную библиотеку виджетов, она у тебя тормозила, потом посмотрел профайлером, и оказалось, что боттлнек это CLOS? Подозреваю, что нет.

>instance.member

Я тебе уже говорил, как эту проблему решить. Ты совсем чтоли упоротый?

(defun -> (object member)
  (slot-value object member))

(defun (setf ->) (new-value object member)
  (setf (slot-value object member) new-value))

>родовые функции прокатили бы

«Обобщенные», вообще-то. Ты, по-моему, точно упоротый. Более того, за основые «тормоза» в CLOS ответственны как раз обобщенные функции, а не объекты - многомерные таблицы виртуальных функций, меняемые в рантайме, это вам не в тапки ссать.

>add

Тебе не нужно делать ADD(как и вообще любую тривиальную функцию) обобщенной функцией, поверь мне, в том числе, по причине, описанной выше.

Для нетривиальных - добавляешь &key &allow-other-keys в список аргументов.

>Как же должен выглядить настоящий, правильный, ООП?

CLOS, разумеется.

В питоне и tcl объектные модели либо просто говно, либо окостыленное говно.

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

хм, ну посмотрел ..:
http://www.scalabium.com/faq/smdbgrid.htm#How%20I%20can%20add%20the%20sorted%...
не впечатлило.
Можно попробовать сделать лучше на тикле.

В общем, не хотел бы продолжать наезды на tcl/tk, равно как и у Вас вряд ли получится обосновать, что tktable круче, чем какой-нибудь tsmdbgrid.

tcl/tk - конструктор-оборотень, швейцарский нож инженера,
Вы спросили про gui и интерфейсы, так ?
А причем тут библиотечное исчисление для ленивых ?))
Довольное многое в tcl делается по месту настолько просто, что не всегда прилично это оформлять это в отдельный модуль и строчить на него «трехтомное издание» документации. Это и плюс и минус языка.
Для привыкших находить готовые на все решения и не шевелить мозгами, tcl кажется примитивным и несколько убогим.

den73

> Наверное потому, что у них имеется здравый смысл. Не, я не поведусь :-) К Вам тот же вопрос - как организовывать работу с большим числом сущностей. Кстати, скачал Ваши исходники. Если сравнить их сложность с тем же VCL, то они несопоставимо проще. У Вас классы исчисляются десятками, а слоты - тоже десятками. В VCL слоты исчисляются, я думаю, тысячами, а классы - сотнями. Как Вы считаете, возникнут ли проблемы масштаба в лиспе, если Ваш код дорастить до такого объёма? Если да, то какие.

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

Вот, кстати, к вопросу о функции add. Видимо, самый крупный проект с классами, который я когда-либо видел.

http://common-lisp.net/project/docudown/documentation/metabang.cl-containers-...

Перечислю только два криминальных имени родовых функций из этого списка: move и finish. Вероятность, что эти имена не встретятся ни в какой другой библиотеке близка к нулю. По-моему, отличий от add мало. Краткое имя пакета containers - тоже может вызвать конфликт, полное - слишком длинное. Да и краткое имя - недостаточно краткое. Т.е., при реальном использовании будет многословно.

den73

Иди ты знаешь куда... Знаешь. Приду домой - заигнорю.

den73

> Вы спросили про gui и интерфейсы,

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

tcl/tk - конструктор-оборотень, швейцарский нож инженера,

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

Довольное многое в tcl делается по месту настолько просто

Пропаганду фильтрую :-)

Я тебе вполне конкретные и корректные вещи говорю.

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

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

И какие это наиболее крупные? И что значит ООП? CLOS? Я не видел __ни_одного__ сколько-нибудь крупного проекта, который не использует CLOS(ок, или хотя бы структуры, и свое какое-то ооп).

В VCL слоты исчисляются, я думаю, тысячами, а классы - сотнями. Как Вы считаете, возникнут ли проблемы масштаба в лиспе, если Ваш код дорастить до такого объёма?

А ты не думал, что его до такого объема доращивать не придется? Потому что VCL это сраное говно для дельфей, и многие тамошние костыли, затычки и прочее говно в контексте просто лиспа не нужно.

> Если сравнить их сложность с тем же VCL, то они несопоставимо проще

Спасибо, я стараюсь.

В VCL слоты исчисляются, я думаю, тысячами, а классы - сотнями.

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

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

до такого объёма

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

Видимо, самый крупный проект с классами, который я когда-либо видел.

http://common-lisp.net/project/docudown/documentation/metabang.cl-containers-..

Видимо он не только самый крупный, но и самый бесполезный.

Вероятность, что эти имена не встретятся ни в какой другой

библиотеке близка к нулю.

Ну, дык, пакеты же.

Краткое имя пакета containers - тоже может вызвать конфликт

Вероятность использования в одном проекте двух различных библиотека, которые будут содержать пакет с названием containers кажется не очень высокой (совсем не высокой). Но даже в таком случае всегда есть rename-package, что позволяет дать те имена, которые вам будут нравится больше. Это несколько усложнит загрузку, но вполне приемлемо. При этом, для многих других языков подобный конфликт имён был бы фатальным, а в CL его можно разрулить.

>Я, конечно, клоню к тому, что Delphi вовсе не так уж плох

А там что, layout уже нормальный сделали?

> Пропаганду фильтрую :-)

Ни в коем случае это не пропаганда, а только мои личные наблюдения и выводы как пользователя tcl ~8 лет.
Пропаганды tcl на этом форуме что-то не припомню , а незаслуженного пинания ногами tcl - хватает.))

den73

> Я обещаю очень стараться, что бы мой код никогда не достигал таких размеров

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

Видимо он не только самый крупный, но и самый бесполезный.

Я с Вами вообще во многом согласен, но Вы скорее пытаетесь меня «лечить», чем ответить на мои вопросы.

den73

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

den73

что в Вашем понимании нормальный? авто-layout есть, grid есть, margins есть. Могло бы, наверное, быть и лучше, но это так всегда. Помнится, в QT получше было, с другими библиотеками не работал.

> но Вы скорее пытаетесь меня «лечить», чем ответить на мои вопросы.

Вряд ли лечить. Скорей хочу показать, что недостатки, на которые вы указываете, являются вашей субъективной точкой зрения. Из моего текущего опыта работы с CL у меня нет каких-либо оснований подозревать что-либо подобное для крупных масштабов. Даже больше. Мои проекты тянут за собой не менее сотни тысяч строк, написанных другими людьми. Это вполне сопоставимо с VCL, которая за собой ничего не тянет. И никаких проблем.

den73

В моём приложении на Дельфи 538 тыс. строк, библиотеки - это ещё порядка 3-5 млн. Даже учитывая компактность лиспа и то, что некоторая часть кода сгенерена автоматически, думаю, всё же о сопоставимости масштабов говорить рано. Я использую далеко не всё, что есть в библиотеках, но это неважно - главное, весь этот код «уживается в одном образе».

Может быть, Вам повезло или мне не повезло, но когда я по своей наивности попытался сделать (:use :iterate :cl-utilities) - тут-то всё и вскрылось.

> В моём приложении на Дельфи 538 тыс. строк

Я серьёзно думаю, что это не нормально. Даже с учётом автогенерации. Я не знаю приложения, под которое бы надо было столько кода. У меня знакомые командой из 10-15 человек писали одну серьёзную софтину несколько лет и после последнего рефакторинга там было 180 тыс. строк кода на С++. И я с ними ещё спорил, что у них код был раздут.

(:use :iterate :cl-utilities)

Ну а что всё скрылось? Результат, же , ожидаем, и именно таким он и должен быть.

> Я не знаю приложения, под которое бы надо было столько кода.

Ну, скажем, ядро Линукса, или программа Mathematica - программы, причём полезные, с числом строк в несколько миллионов (как на С, так и на языках высокого уровня). Чуть меньше занимают разные SQL-сервера и языки программирования (взять хоть mySQL или тот же CCL). У меня-то простой быдлосклад, для него, может быть, действительно столько не нужно (кстати, я наврал, прикладных строк у меня всего 54тыс, остальное - это кусок библиотек, ошибся я так легко потому, что эта программа мне досталась по наследству, правда, я ещё не посчитал серверную часть, где в основном происходит всё главное). Но мораль не в том, а в количестве строк в образе.

Ну а что всё скрылось? Результат, же , ожидаем, и именно таким он и должен быть.

А в Паскале так не бывает, хотя каждый модуль образует своё пространство имён, полученное слиянием десятков других пространств имён, аналогией чего является :use . Хотя, опять же, я не хочу об этом спорить. Ваше мнение принято: Вы не видите проблем в масштабных разработках на лиспе. Я их вижу. Не сошлись во мнениях. Бывает.

> А в Паскале так не бывает, хотя каждый модуль образует

своё пространство имён

Я не знаю Паскаль. Что в нём происходит в таком случае то? Я что-то никакого разумного поведения себе представить не могу.

den73

> Я не знаю Паскаль.

По-моему, учитывая, что я знаю и Паскаль, и CL, стоило бы уже давно прислушаться к моим жалобам :)

Что в нём происходит в таком случае то?

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

Есть ещё конструкция with <object1>,...<object n> do ...
Она более опасна, я пользуюсь ей не так часто. В ней опять же всё сливается без проблем и возникает (лексически) локальный как бы пакет, видящий все имена атрибутов object1...objectN и то, что было видно в контексте, где написана with. Тут вероятность конфликта весьма велика. Но (по слухам) эта конструкция исправлена в Модуле-2, При попытке считать неоднозначный символ возникает ошибка компиляции - нужно добавить префикс. SQL ведёт себя так же, как Модула-2, и это прекрасно (хотя в книжках написано, что в SQL всегда нужно ставить префикс, но я этого не делаю и подрываюсь на этом крайне редко, зато мои запросы достаточно компактны). Кроме того, в SQL можно определить локальный псевдоним пр-ва имён, а в Лиспе этого (увы) нельзя. Т.е. и здесь в дизайне Лиспа дыра.

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

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

>Т.е. и здесь в дизайне Лиспа дыра.
Нет никакой дыры в дизайне лиспа.

Ты просто не

знаю ... и CL

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

, в лиспе требует кропотливой работы, которая ничем не оправдана.

«Кропотливая работа» требуется чтобы сделать из лиспа паскаль, что само по себе непонятно на какой хрен нужно

Итог - в этом отношении Паскаль даёт большую производительность труда

А ты не пиши на лиспе как на паскале, и это не будет проблемой.

такого гемора с конфликтующими именами, как в Лиспе, в Паскале, по большому счёту нет.

Что-то я не понял. Вот когда при использовании :use происходит конфликт имен в CL случается ошибки (которую, кстати, можно разрулить, но не суть). Когда в Pascal случается конфликт имён тоже происходит ошибка. В Pascal такое случается очень редко. В CL ты столкнулся с таким при (:use :iterate :cl-utilities). Но вообще такое тоже случается редко.

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

конфликт глобальной и локальной переменной с одинаковыми именами (в лиспе такое тоже возможно).

Ты чего вообще? Может у нас какие-то разные лиспы?

> Когда в Pascal случается конфликт имён тоже происходит ошибка.

не происходит:

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

А, ну это же кажется гораздо хуже, нет?

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

И не представляешь, что такое пакет(package) по сути

Знаешь, есть такое понятие «клевета». Если ты кого-то в чём-то обвиняешь, у тебя должны быть заготовлены доказательства, иначе это - клевета. Мне интересно, как ты будешь доказывать, что я не знаю, что такое пакеты.

Нет никакой дыры в дизайне лиспа.

Аминь.

Когда в Pascal случается конфликт имён тоже происходит ошибка.

Нет, не происходит. Из конфликтующих имён паскаль выбирает самое первое по порядку предложения uses, или какое-то случайное (я даже этого не знаю). Ошибка произойдёт, если это будет не то имя, к-рое я имел в виду. Далее, это может иметь разные последствия: а) ошибка компиляции,если то имя, которое выбрал компилятор, не совместимо по типам. б) ошибка в логике приложения, если оно совместимо по типам. Случай а) я встречал несколько раз, случай б) - ни разу. Наилучшее поведение - это поведение modul-ы -2 и SQL, которые порождают ошибку не в момент образования пр-ва имён, а в момент попытки чтения конфликтующего имени. Это позволяет использовать все неконфликтующие символы без квалификатора и защищает от ошибки при наличии конфликта.

А лично я :use для всяких левых пакетов

Я не понял, какой из двух приведённых пакетов ты считаешь «левым»? Или оба? Я лично читаю код в 90% случаев в редакторе и, если что-то непонятно, сразу прыгаю на определение того, что мне непонятно. Заодно и скобки подсвечиваются, и можно скакать по структуре дерева. Так что я не вижу смысла писать квалификатор пакета в тех местах, где его можно не писать. Символы, которые я часто использую, я, как правило, помню, откуда взялись (да, кстати, и не столь важно, откуда они берутся, пока их можно писать без квалификатора).

Ты чего вообще?

(let ((x 1))
   ...
   (let ((x 2))
     ... 
      x ; если проглядел x = 2, можно ошибиться.
      )))

как вариант,

(defvar x 1)
...
(defun g () x) ; ой. 
...
(let ((x 2)) ; не имея в виду, что x - special. 
  (g)
  )

По правде говоря, эта беседа мне поднадоела. В общем, всем спасибо за ответы, наверное, на этом можно закончить. Правда, ясности на тему «правильного ООП» добавилось немного.

Блин, я неправильно написал про Modulu-2 и SQL. При чтении конфликтующего символа они порождаю ошибку компиляции, а не ошибку в широком смысле слова :-)

> Из конфликтующих имён паскаль выбирает самое первое по

порядку предложения uses

Это ужасно.

поведение modul-ы -2 и SQL, которые порождают ошибку не в момент

образования пр-ва имён, а в момент попытки чтения конфликтующего

имени.

Это тоже ужасно.

Это позволяет использовать все неконфликтующие

символы без квалификатора

я не вижу смысла писать квалификатор пакета в тех местах,

где его можно не писать

Подумай о людях, которые будут твой код читать. Ты то сам код читаешь, или только пишешь? Это ведь был бы полный кошмар. Смотришь чужой код и должен для каждого вызова определять из какого это пакета. Никогда бы не хотел подобным заниматься. Слава богу, в языках с которыми я активно работал и код на которых регулярно читаю такое невозможно.

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

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

Правда, ясности на тему «правильного ООП» добавилось немного.

CLOS же. Очень хорошая система.

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

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

Мне интересно, как ты будешь доказывать, что я не знаю, что такое пакеты.

Да просто опять упомяну тот факт, что пакеты CL это не неймспейсы статических языков. Ты в это совершенно не врубаешься. У пакетов CL немного другие функции и совершенно другие возможности.

мммм в изменённом состоянии сознания.

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

> А, ну это же кажется гораздо хуже, нет?

да, хотя ошибки в связи с этим возникают весьма редко, ничего хорошего в этом нет

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

Вот я сижу и не понимаю - почему это у меня не вызывает проблемы? Частично я уже объяснил: я сижу в IDE и могу всегда перейти на определение символа. Вторая часть объяснения состоит в том, что значительная доля символов будет из текущего пакета.

Это ужасно.

В теории - да. На практике (почему-то) - нет. Сам вот не знаю, почему. Но поверь, это действительно не ужасно. И эта «не ужасность» удивительна и достойна, как минимум, постановки вопроса «а почему это ужасно в теории, но не ужасно на практике»?

Подумай о людях, которые будут твой код читать. Ты то сам код читаешь, или только пишешь?

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

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

Я назвал тот способ, который я считаю правильным. Не такой, как в Паскале, а такой, как в SQL. Очевидно же, что SQL на сегодня популярнее лиспа. Некоторые языки успели родиться, войти в моду и выйти из моды, а SQL как был, так и остаётся и ещё долго никуда не денется. Таким образом, опыт прагматичного (не знаю насчёт прогрессивного) человечества как раз на моей стороне.

CLOS же. Очень хорошая система.

Ладно, подумаю над этим. В принципе, вроде действительно неплохая.

> Вот я сижу и не понимаю - почему это у меня не вызывает проблемы?

Главное, что у других вызывает.

я сижу в IDE

Можно подумать, что на CL можно программировать без IDE (которая будет, при этом, покруче Delphi).

Вторая часть объяснения состоит в том, что значительная доля

символов будет из текущего пакета.

Известно же, что 10% случаев обеспечивают 90% проблем.

И эта «не ужасность» удивительна и достойна, как минимум, постановки

вопроса «а почему это ужасно в теории, но не ужасно на практике»?

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

Очевидно же, что SQL на сегодня популярнее лиспа.

Очевидно же, что их нельзя сравнивать.

Во-первых, куда исчезли указатели, адреса, ссылки или что угодно, что играет их роль? Что, память перестала быть «плоской» и адресуемой («байты которые живут в домиках», как объясняют детям)? Эта модель, отбитая в платах, существует - вы можете пользоваться плодами возведённых над ней абстракций (другие модели, видимо, более удобные во всех прикладных отношениях, a.k.a. «я могу презреть все уровни что лежат как выше так и „ниже“ моего уровня понимания, т.к. я пишу „реальные программы“(tm) на крутом языке FOO»), но всё это там где и было (и си, как некий DSL к этой самой $arch_of_the_time - тоже на месте, в вашем ядре, драйверах - да где угодно). Тут же - трудно назвать байт «объектом», а ссылку-указатель на другой байт «стрелкой»? Осторожно, категории где-то рядом! Короче, нет страшной-нависшей-глыбы-теорката которую нужно искоренять - всё так устроено. Любые сложные структуры данных и функции их обработки - тёмный лес, кнут-кормен и прочая «рутина», как было замечено в соседнем треде. Любая попытка рассматривать предметы программирования как предметы с отношениями в некотором замесе - тоже тёмный лес, алгебра и теория категорий. (Да, а почему зелёный листок зелёный - квантовая электродинамика, вот блин - почему всё не просто-то, а?)

Во-вторых. Ок - решаете прикладные задачи на языке программирования с удобными вам моделями (ООП, whatever). И «математика не нужна». Вы говорите о задачах в терминах языков программирования. В терминах каких языков вы будете говорить о самих этих языках, о самом программировании? Неужто на естесвенном языке, или на типичных ЯП - тоже ведь нет, это как схватить себя за хвост. Понимаете о каком *языке* идёт речь?

> Во-первых, куда исчезли указатели, адреса, ссылки или что угодно, что играет их роль?

А что играет их роль в haskell? И ссылка (reference) в таких языках, как java, ruby, python, php - это совершенно не аналог ссылки (указателя) из си.

я могу презреть все уровни что лежат как выше так и «ниже» моего уровня понимания

Эта модель, отбитая в платах, существует

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

Осторожно, категории где-то рядом!

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

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

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

Неужели штанга так плохо влияет на мозг?

Вы влезли в разговор про консистентность синтаксиса $var. Или вы о чем-то своем говорите?

А вы таки умеете написать этот пример без ошибок? Ждемс...

> Вы влезли в разговор про консистентность синтаксиса $var.

Я ответил на конкретный вопрос «Повтори-ка на питоне». То, что это показывает ненужность синтаксиса $var, мне безразлично.

А вы таки умеете написать этот пример без ошибок? Ждемс...

a=«b»

exec(a + «=» + «'c'»)

print b

c

В свою очередь хочу спросить: зачем это нужно - указатели эмулировать?

> зачем это нужно - указатели эмулировать?

Не указатели, а символы a la lisp.

Но мне ответ просто не интересен, ибо меня полностью устраивает текущая ситуация

Если тебя ещё и оплата твоей работы на лиспе устраивает, то я снимаю шляпу. А мне платят за Delphi и SQL, лисп я привлёк по своей инициативе и он используется только как средство разработки. До этого я пытался заработать и на лиспе, участвуя именно в лисповых проектах (имея уже немалый опыт работы на нём). Концы с концами мне бы удалось свести, но не более того. Уборщицы, в общем-то, больше зарабатывают, чем я тогда заработал. И тут - коронный вопрос, на который не может ответить ни один лиспер: почему лисп потерял своё главенствующее положение в мире софта? Почему Дельфи написан не на лиспе? Почему моя база хранится в фарйбёрде, а не в очередной версии ap5? Почему постгресс был написан на лиспе, а сейчас он написан на других языках? Почему в Автокад внедрили бейсик? Тебя может всё устраивать. Ты мне объясняешь, что проблема на моей стороне. Может быть, я что-то делаю не так, как ты. Во-первых, ещё не факт, что мои методики хуже твоих, они просто другие, я использую лисп при работе за деньги и иногда это бывает завязано на сроки. Я вынужден оптимизировать свои методики. Но факт упрям: в мире софта лисп задвинут в дальний ящик, хотя когда-то он был королём. Ты даже это пытаешься оспаривать, когда отказываешься сравнивать лисп и sql. Но это - только твоё нежелание, при непредвзятом взгляде ситуация совершенно очевидна. Что бы не было причиной потери лиспом своих позиций, сама эта потеря является неумолимым фактом и причина, видимо, была достаточно серьёзной. Можно подумать, что это неправильный мир или какой-то заговор с целью оболванивания людей. Отчасти и я склонен так считать. Но нельзя всё списать только на это. Люди пользуются другими языками потому, что эти языки обладают какими-то преимуществами, а не (только) потому, что эти люди - идиоты. Я пришёл с блюдёчком, с каёмочкой и пытаюсь объяснить (подробно), в чём проблемы лиспа, в чём другие языки его обгоняют и что можно было бы сделать,чтобы сократить этот разрыв. На основании опыта работы с разными языками. Ты, не имея опыта работы, например, с Паскалем, от меня отмахиваешься и списываешь эти проблемы на меня (это уже неразумно). Однако, если бы ты смог понять, что эти проблемы не на моей стороне, а во многом это объективные проблемы самого лиспа, то это даёт ключ к исправлению ситуации, и именно этот ключ я пытаюсь найти и привести в действие, поскольку в лиспе есть такие вещи, которых в других языках пока не предвидится. По части исправления явных косяков лиспа я кое-в чём преуспел (и я точно знаю, что у меня получился положительный результат, потому что уже года два работаю с использованием своих решений, и могу сравнить, как мне работалось до них и после них). На c.l.l это тоже кое-кто признал (конечно, меньшинство). Но меня это не парит, ведь лисперы - это, по сути, маргинальная группа в программировании, несмотря на все преимущества лиспа (о которых, поверь, я знаю ничуть не хуже тебя, и демонизировать SBCL я тоже когда-то умел). Но ты отмахиваешься и не хочешь знать про остальной мир. Ну, воля твоя, это твоя жизнь и тебе её жить.

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

Короче, вот такой код сейчас у меня есть:

>(--> "asdf" upcase)
"UPCASE"
>(find-symbol "UPCASE")
nil ; важно, поскольку не засоряется пр-во имён

> (defstruct my-long-struct a b)
MY-LONG-STRUCT

> (defun ffff () 
             (let1 s (make-my-long-struct :a "w" :b "ell, ok")               
               (declare (my-long-struct s))
               (str+ s.a.upcase s.b)))
FFFF

> compile 'ffff

> disassemble 'ffff
      ....
74:      call  [250C6638]       ; MY-LONG-STRUCT-A
80:      push  eax
81:      moveb ch, 2
83:      move  eax, 206B913C    ; "UPCASE"
88:      call  [21CA83B8]       ; BUDDEN-TOOLS::RUNTIME-->
94:      push  eax
95:      moveb ch, 1
97:      move  eax, [ebp-4]
100:     call  [250C6668]       ; MY-LONG-STRUCT-B
106:     moveb ch, 2
108:     call  [21CA3500]       ; STR+
     ....

> apropos "s.a"
; нет таких символов

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

Естественно, что a.b - это сокращение от (--> a b). Делать просто другое имя для slot-value, как предлагал Lovesan - это мало пользы, потому что, кроме слотов, есть ещё и структуры (кстати, по слухам с c.l.l, в CLOS тормозят как раз не родовые функции, которые очень хорошо разгоняются, а именно сами объекты, хотя я не проверял).

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

(defun variable-type-or-class (VAR ENV) 
  "Возвращает тип ИЛИ класс значения"
  #+:LISPWORKS4.4
  (cond
   ((constantp VAR ENV)
    (class-of var))
   (ENV
    (let1 remote-environment (slot-value env 'lexical::remote-environment)
      (when remote-environment 
        (let1 variable-types
            (iter (:for venv in (slot-value remote-environment 'compiler::venv))
              (ignored (struct-to-alist venv))
              (:collect `(,(slot-value venv 'compiler::name)
                          ,(slot-value venv 'type))))
          (cadr (assoc var variable-types))))
      )))
  #-:LISPWORKS4.4
  (error "You lose"))

Желающие могут повторить её для своей любимой реализации лиспа и выложить сюда же. В примере с ffff такая функция должна правильно определять тип s.

А вот такой вопрос по tcl.

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

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

С моей точки зрения, это - очень естественная, крайне нужная для работы и довольно простая в реализации (на любом языке) вещь. Собственно, если бы её не было в лиспе, то и меня не было бы в этой теме. И я не понимаю, почему почти весь мир мудохается без этой возможности (извините, не могу здесь применить более мягкое слово).
Тем не менее, я видел её эту возможность не так много раз (в порядке убывания качества реализации):
1. В лиспе.
2. В Microsoft SQL Server.
3. В операционной системе (можно подменить исполняемый файл).
4. Видимо, это можно делать в случае разделяемых библиотек на любом языке, если библиотека грузится явно.
5. Ну, строго говоря, в Microsoft Visual Studio есть «Edit and continue» для C++, но оно работает далеко не всегда.
6. Сейчас, я научился подменять функции в Дельфи, правда, тут есть большие ограничения да и не совсем ясно, чем их подменять - инкрементной компиляции в Дельфи нет.
7. На ассемблере можно делать вообще всё, что угодно, но это не считаем.

Как ни странно, этого не оказалось в Питоне, после чего на нём был сразу поставлен жирный крест, как на негодном образце дизайна.

Итак, вопрос. Можно ли так сделать в tcl?

Очепятка! ПРавильно так:

> (--> "asdf" upcase)
"ASDF"
> (--> (find-package :cl-user) name)
"COMMON-LISP-USER"

такая возможность в tcl есть

вариант 1:
явный способ
proc dd {a b c} {
puts «old»
puts «$a $b $c»
}

dd 1 2 3
proc dd {a b} {
puts «new»
puts «$a $b»
}


dd 1 2
------------------
выдаст
old
1 2 3
new
1 2


вариант 2
Использовать команду eval.
У eval параметр - строка и будет выполнена
интерпретатором tcl как набор команд.
Подробнее:
http://tmml.sourceforge.net/doc/tcl/eval.html

для вариаций с входными параметрами (умолчания и т.д) и переменным их числом можно использовать args:
http://www.tcl.tk/man/tcl/tutorial/Tcl12.html

Для зашиты ресурсов в потоках используют мютексы из дополнительной библиотеки thread.

> И тут - коронный вопрос, на который не может ответить ни один

лиспер: почему лисп потерял своё главенствующее положение в мире

софта?

Да ну, я эту тему тут регулярно раскрываю по собственной инициативе.

Ты, не имея опыта работы, например, с Паскалем, от меня отмахиваешься

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

Люди пользуются другими языками потому, что эти языки обладают

какими-то преимуществами, а не (только) потому, что эти люди

- идиоты

Конечно, что-либо подобное утверждают только лиспотроли, которым ты, вероятно, на своё несчастье и поверил в своё время.

Но ты отмахиваешься и не хочешь знать про остальной мир.

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

Ну не будем спорить, ваше отношение понятно. Но вы зачем-то начали разворачивать эту метафору - сравнение «стрелок и объектов» с «указателями и байтами», в исторической перспективе. Зачем? Разве что для красного словца, реально-то никакой связи. Первое - существующие архетектуры, второе - формализм который привлекают для описания программирования. Вот я и говорю - эти архетектуры никуда не делись, нужно писать какой-нибудь энтерпрайс на языках с жирными VM чтобы позволить себе забыть о архитектуре (ну либо на чистом ФП, в Haskell есть только _модели_ плоской памяти и указателей). А что касается второго - формализма - он сам по себе существует, независимо от программирования, его просто используют как инструмент описания (начали использовать математику для описания программирования - скатились обратно к байтам, это как?).

Вообще - математика не имеет никакого отношения к программирования, как она не имеет отношения к биологии или экономике. Она вообще ортогональна любой сфере практической деятельности, и в то же время её, как инструмент формализации, можно привлечь в любую область, в том числе в программирование. И это может быть разная математика - специальная, в духе Кнута, или в духе исчисления предикатов Дейкстры. Ну или как в теории типов - попытка свести всё сущностное программирование к математическим понятиям (ну вообще всё :). Категории действительно очень слабая абстракция, фактически, граф с дополнительными свойствами, и поэтому они находят широкое применение. Это как с множествами и отображениями - множество очень общее понятие (изначально, по Кантору, - «мысленое объединение некой совокупности объектов в единое множество») которого хватает для формализации ТД используемых в программировании, отображение между множествми - также очень общее понятие которого хватает для формализации тех функции которые в программировании кодируют процедурами.

сравнение «стрелок и объектов» с «указателями и байтами», в исторической перспективе. Зачем? Разве что для красного словца, реально-то никакой связи. Первое - существующие архетектуры, второе - формализм который привлекают

Опечатался, наборот, плоская память, байты, указатели - от архетектуры. А стрелики, объекты и прочее - от формализма.

А чем плох такой код:

(defstruct my-struct a b)

(let ((my-struct (make-my-struct :a "foo" :b "bar")))
  (concatenate 'string 
               (string-upcase (my-struct-a my-struct))
               (my-struct-b my-struct)))
=>
"FOObar"

или, если нужно «declaration is assertion»:

(defstruct my-struct
  (a "" :type string)
  (b "" :type string))

(let ((my-struct (make-my-struct :a "foo" :b "bar")))
  (declare (type my-struct my-struct))
  (the string (concatenate 'string
                           (string-upcase (my-struct-a my-struct))
                           (my-struct-b my-struct))))

?