(Нету базовых средств + немилосердные тормоза + непредсказуемое поведение) и сразу в продакшн?
> В С вон вообще никаких лямбд нету - однако ж на нем написаны все сколько-нибудь промысшленные OS
А на питоне?
> А питон активно применяется как язык-клей, для реализации сложной, часто изменяемой логики.
Ну и зачем сложную логику на недоделаном?
> Просто ее готовить надо уметь (что сложнее, чем с юниксами)
Она от этово луче не станет, в самом распрекрасном случае будет отравлять жысь админу а не юзверям
> Вон хотмейл пару сотем миллионов ящиков обслуживает, и ниччо. На винде.
Врут небось, нету там венды. там соляра с кумайлом.
> А гмейл - то же самое делает, с интерфейсом на питоне. А ЖЖ (ну, он поменьше) написан весь целиком не перле. Как и, если не ошибаюсь, Amazon (ну, так было несколько лет назад точно, сейчас не знаю).
дык я не отрицал, что при большом желании принципиально возможно всё заставить работать. Только вот соотношение затраты/результат у лиспа намного выше получяецо. Не в разы даже а на порядки.
> воистину бугога. Какая разница, начём лисапед, на с++/stl или на с/фортране? Просто цытата древняя, пора обобщить на питонос++ тоже.
Мы, вроде, договорились не передергивать? Или ты будешь продолжать, пока я тебе программку про файлы не напишу?
Я имел ввиду, что я готов согласиться с этой цитатой, если в ней заменить Common Lisp на "C++ and STL". Для людей с мозгом, выеденным лиспом, сообщаю, что тогда она будет звучать как "any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of C++ and STL".
А имел я ввиду то, что а) гринспун "хвалился", скорее, полнотой библиотеки, чем мощью языка, б) все это давно перенесено в "алгольный" мир, со сравнительным по отношению к лиспу качеством от "не сильно хуже" до "лучше".
> > В С вон вообще никаких лямбд нету - однако ж на нем написаны все сколько-нибудь промысшленные OS
> А на питоне?
На питоне написан gmail. Это из того, что на слуху (я сам перлист-сишник, за питоном не слежу особо). Рядом со мной его успешно применяют в контексте корбы, очень даже в продакшене (вебсервис на сотни тысяч хитов в день, и подготовка данных для другого - уже с десятками миллионов хитов, правда отдаваемых сишной программкой).
> > Вон хотмейл пару сотем миллионов ящиков обслуживает, и ниччо. На винде.
> Врут небось, нету там венды. там соляра с кумайлом.
Детсад, мля. Винда там. И на msn search тоже винда. То, что ты неспособен ее завести и защитить - это твои проблемы.
Кстати, обычные мейлеры на таких сервисах не живут, совсем. Там custom software. Думается мне, на C (ну, может быть с крестами).
> > А гмейл - то же самое делает, с интерфейсом на питоне. А ЖЖ (ну, он поменьше) написан весь целиком не перле. Как и, если не ошибаюсь, Amazon (ну, так было несколько лет назад точно, сейчас не знаю).
> дык я не отрицал, что при большом желании принципиально возможно всё заставить работать. Только вот соотношение затраты/результат у лиспа намного выше получяецо. Не в разы даже а на порядки.
Еще раз (да, я зануда) - пример мегасервиса (ну хотя бы рунетовского масштаба, миллион+ хитов в сутки) на лиспе. Ежели все так круто - то, видимо, 2 человека в гараже с SBCL-ем на десятке серверов - реальная угроза для гугля? Где же они?
> Это характерный подход для ООП, потому что только в этом случае неправильно построенная иерархия обектов может привести к тому, что единова придёцо переписывать прогу с нуля (!). Если же иерархии обектов нету, можно довольно свободно адаптировать как структуры данных так и алгоритмы в случяе косяка в разработке или небольшово изменения задачи.
Голословное утверждение. В реальности ошибка в проектироании иерархии классов приводит к рефакторингу, изменениию части классов, отношений между ними, но никак не к переписыванию с нуля.
Аналогично я могу заявить что создание DSL это характерный подход для лиспа подход. "неправильно построенный DSL может привести к тому, что единова придёцо переписывать прогу с нуля (!)"
+5
проблемы с DSL в проекте _значительно ужаснее_ чем проблемы в иерархии классов, фактически при изменении DSL возникают теже проблемы как при переносе приложения между двумя сильно различными платформами на другой язык, с С на паскаль например - в общем DSL- гавно
Bugmaker, написал тебе я прогу. Только твоё ТЗ было сформулированно
нечётко, исходник ты не показал, так что у нас наверное получились
несколько разные проги, нарпимер я сделал persistent storage на
sqlite, соответственно пооиск по базе файлов работает очень шустро.
Давай ты не будешь передёргивать, говорить типа оно у меня
нетиненадо, а приведёшь исходник с аналогичной функциональностью на
лиспе. Чтобы там были реализованы фнкции/методы/макросы для
добавления файла в базу, удаления, и выборки файлов по заданному
критерию. Возможные опреаторы для выборки: >, >=, <, <=, !=.
База данных sqlite
Моя прога работает на Win32/Linux, поддерживает unicode. Прога на
лиспе желательно должна работать под Win32/Linux также с
поддержкой юникода.
Вот когда напишешь такую прогу, тогда и поговорим :-)
#!/usr/bin/env python
import sys
import os.path
import sqlalchemy.mods.threadlocal
import sqlalchemy
import sqlalchemy.exceptions
class File(object):
def __init__(self, **kwargs):
for key, value in kwargs.iteritems():
setattr(self, key, value)
def __unicode__(self):
s = [ unicode(self.__class__.__name__) + u': ' ]
for c in self.c:
s.append(u'%s=%s ' % (c.key, getattr(self, c.key)))
result = u''.join(s)
return result
metadata = sqlalchemy.BoundMetaData('sqlite:///files.db',
strategy='threadlocal')
files_table = sqlalchemy.Table('files', metadata,
sqlalchemy.Column('id', sqlalchemy.Integer, primary_key=True),
sqlalchemy.Column('name', sqlalchemy.String(1000), index=True),
sqlalchemy.Column('size', sqlalchemy.Integer, index=True),
sqlalchemy.Column('dir', sqlalchemy.String(1000), index=True),
sqlalchemy.Column('count', sqlalchemy.Integer, index=True))
sqlalchemy.mapper(File, files_table)
class FileDb:
def __init__(self):
try:
sqlalchemy.Query(File).select(limit=1)
except sqlalchemy.exceptions.SQLError:
metadata.create_all()
def flush(self):
sqlalchemy.objectstore.get_session().flush()
def add(self, full_name, size):
dir, name = os.path.split(full_name)
count = self.updateFile(name, size)
File(name=name, dir=dir, size=size, count=count)
self.flush()
def delete(self, full_name, size):
dir, name = os.path.split(full_name)
count = self.updateFile(name, size, -1)
[sqlalchemy.objectstore.delete(f) for f in
sqlalchemy.Query(File).select_by(name=name, dir=dir, size=size)]
self.flush()
def updateFile(self, name, size, delta=1):
files = list(sqlalchemy.Query(File).select_by(name=name, size=size))
count = len(files)
for f in files:
f.count = count + delta
return count + delta
def select(self, condition=files_table.c.count >= 0):
return sqlalchemy.Query(File).select(condition)
def main():
filedb = FileDb()
if 'add' in sys.argv:
filedb.add('/home/vasily/pic/zombieeuiip.jpg', 31558)
filedb.add('/home/vasily/zombieeuiip.jpg', 31558)
filedb.add('/home/vasily/pic/sars.jpg', 19311)
filedb.add('/home/vasily/sars.jpg', 19311)
filedb.add('/home/vasily/junk/sars.jpg', 19311)
filedb.add('/home/vasily/pic/pic6.jpg', 29638)
filedb.add('/home/vasily/pic/pic8.jpg', 17577)
if 'delete' in sys.argv:
filedb.delete('/home/vasily/pic/zombieeuiip.jpg', 31558)
if 'select' in sys.argv:
print 'All files:'
for f in filedb.select():
print u'%s' % f
print
print 'N > 2'
for f in filedb.select(files_table.c.count > 2):
print u'%s' % f
print
print 'N != 2'
for f in filedb.select(files_table.c.count != 2):
print u'%s' % f
print
print 'N < 3'
for f in filedb.select(files_table.c.count < 3):
print u'%s' % f
if __name__ == '__main__':
main()
P.S. Прога передаётся в public domain.
Можешь её использовать для чистки своего винта :-)
> проблемы с DSL в проекте _значительно ужаснее_ чем проблемы в иерархии классов, фактически при изменении DSL возникают теже проблемы как при переносе приложения между двумя сильно различными платформами на другой язык, с С на паскаль например - в общем DSL- гавно
Проблемы с DSL могут быть разные - простое расширение может практически не повлечь изменения :) Изменения в имеющемся ядре DSL - да, повлекут серьёзные изменения в проекте.
А на чём основано Ваше утверждение? Личный опыт (проект, ссылки)? Или мы "подышать" вышли? С такими голословными утверждениями вы сами лучше всего подходите под последнее слово в вашем посте (не люблю переходить на личности, но гавно не люблю ещё больше ;)
>>>Был уже апдейт: >>И что, скажете читабельность повысилась ?
>Я скажу - да, повысилась. Ясный и даже красивый код.
Мне в Лиспе и с mapcar был ясный и красивый. Мы вроде говорили о читабельности для тех, кто раньше не видел ни то, ни другое. Думаю, что самое разумное будет сойтись на том, что оба варианта хорошо читаются.
>>>1. Не припомню в английском слова "cons"
>>construсt...
>Ну тогда в Питоньей программе вообще все слова английские
И как в английском звучит перевод слова "xrange" ?
>> Кто не может даже в таком очевидном случае увидеть предложений, те идут это на
>Достойный ответ, да
Какой вопрос, такой и ответ. Я что ли про учителя джидаев начал. Код на Питоне тоже не очень-то похож на готовое предложение.
>> IMHO не может быть чтоб код с [1:],[:i],[i:], xrange, yield >>читался лучше кода без этих значков
>range, yield - это слова, отражающие назначение соотетствующих >конструкций. [1:] и т.д. - достаточно близки математической нотации.
Хорошо. Грех не признать, что Питон читается довольно легко, но сказать, что Лисп читается хуже тоже будет неправдой. В ряде случаев за счет изменчивости синтаксиса Лиспа можно вообще использовать ограниченный английский (или иной естественный) язык, например в DSL для самых маленьких ;-)
> Хорошо. Грех не признать, что Питон читается довольно легко, но сказать, что Лисп читается хуже тоже будет неправдой. В ряде случаев за счет изменчивости синтаксиса Лиспа можно вообще использовать ограниченный английский (или иной естественный) язык, например в DSL для самых маленьких ;-)
Лично я и не считаю, что язык программирования должен походить на английский / русский / албанский. И мерится по критерию похожести на английский глупо.
Питоновский код (из примера) превосходно читается любым питонщиком, лисповый код (наверное) хорошо читается любым лиспером.
Человек не знакомый с лиспом (или знакомый поверхностно, как я) ни фига не сможет понять что написано в лисповой программе (без дополнительных знаний про mapcar, mapcan), имея только опыт работы с алголоподобными языками.
В случае с питоном, если человек не знает что такое yield (как работает xrange() можно понять из контекста) тоже ни фига не сможет понять.
Предлагаю свернуть телегу с похожестью на английский, т.к. это
Посмешил. То же самое наверное надо сказать про С++ ;-)
Во первых в реализациях Common Lisp почти всегда есть FFI, который позволяет оперировать какими угодно сишными конструкциями, выделять области памяти, объявлять структуры, ворочать указателями на функции и т.д. и т.п. Потом даже реализации Common Lisp дают различные вариант доступа к нутру, например на Corman Lisp можно запросто ассемблерные вставки делать, да и в SBCL почти то же самое. Да и кто сказал, что все Лиспы должны быть такими как Common Lisp, вон в Lush вообще можно Си перемешивать с Лиспом. Лисп это идея, а не конкретный стандарт и реализация.
Прикол в том, что в SBCL операции с указателями на задаче свертки массива например с гауссианом работают во много раз быстрее, чем родные массивы ;-) От оптимизированного GCC отстал только процентов на 20-30 (для справки: это на SBCL 0.9.16 на Pentium 4 Northwood под оффтопиком). Так что обработку изображений уже можно одним Лиспом делать без всяких сишных вкраплений.
> А погуглить и кинуть урл, подтверждающий мысль, слабо?
А тебе? Не говоря о том, что это цитаты из "Beating the Averages" (невнимательно читал, да?)
> Причин может может быть вагон и маленькая тележка.
Неважно, какие именно причины - они были достаточно вескими.
"Viaweb at first had two parts: the editor, written in Lisp, which people used to build their sites, and the ordering system, written in C, which handled orders. The first version was mostly Lisp, because the ordering system was small. Later we added two more modules, an image generator written in C, and a back-office manager written mostly in Perl."
Заметил, что там был отнюдь не только Лисп? И то, что Лисп использовался в _редакторе сайтов_, а не в том, что реально обслуживало заказы и было под нагрузкой?
"In January 2003, Yahoo released a new version of the editor written in C++ and Perl."
Вот об этом я говорил - Яху переписало прототип на Лиспе в практичные языки
"It's hard to say whether the program is no longer written in Lisp, though, because to translate this program into C++ they literally had to write a Lisp interpreter: the source files of all the page-generating templates are still, as far as I know, Lisp code. (See Greenspun's Tenth Rule.)"
Этот фрагмент просто восхищает. FUD, ненавязчимвый и эффективный. Итак - человек ушел из Яху в 1999, и говорит о программе, выпущенной ими в 2003: "It's hard to say the program is no longer written in Lisp", "they literally had to write a Lisp interpreter", "still, as far as I know", и, конечно, любимое всеми лисперами 10-е правило Гринспана.
>"In January 2003, Yahoo released a new version of the editor >written in C++ and Perl." >Вот об этом я говорил - Яху переписало прототип на Лиспе в >практичные языки
Ну быдломанагеры видно приложили лапу со своими "100 миллионов мух..."
>Этот фрагмент просто восхищает. FUD, ненавязчимвый и эффективный. >Итак - человек ушел из Яху в 1999, и говорит о программе, >выпущенной ими в 2003: "It's hard to say the program is no longer >written in Lisp", "they literally had to write a Lisp >interpreter", "still, as far as I know", и, конечно, любимое всеми >лисперами 10-е правило Гринспана.
Дык, судя по тому что было не так давно писано про Yahoo Store на Фрешмите, они просто воспроизвели функциональность Лиспа на С++, потому что переписать на плюсы, используя чисто плюсовые идиомы, не получилось. Так что Грэм по большому счету нигде не соврал.
>"Viaweb at first had two parts: the editor, written in Lisp, which >people used to build their sites, and the ordering system, written >in C, which handled orders. The first version was mostly Lisp, >because the ordering system was small. Later we added two more >modules, an image generator written in C, and a back-office manager >written mostly in Perl."
>Заметил, что там был отнюдь не только Лисп? И то, что Лисп >использовался в _редакторе сайтов_, а не в том, что реально >обслуживало заказы и было под нагрузкой?
Нормальные люди так и делают. Если есть узкое место, то с интерпретатором на танки идти как то смешно. Лисп то был - GNU CLISP. Сегодня бы на Лиспе скорее всего вообще все было написано (на SBCL скорее всего). Успех то все равно пришел в следствие удобного редактора магазинов, остальное у конкурентов тоже было в порядке.
> Ну быдломанагеры видно приложили лапу со своими "100 миллионов мух..."
Ну, если тебе это _видно_ - тогда ой. А во фразе про "100 миллионов мух..." есть один дефект - там предлагается человеку действовать так, словно он - муха. Это заставляет усомниться в уме тех, кто ее придумал, и тех, кто ее повторяет. А если это шутка, то какая-то она слишком тонкая (== плоская).
> Так что Грэм по большому счету нигде не соврал.
Ну да, по большому счету. Подумаешь, написал о том, о чем точно не знает, в выгодном для себя тоне. Дело житейское.
> они просто воспроизвели функциональность Лиспа на С++
Ну, всегда можно сказать, что рабочая система - это воспроизведение функциональности прототипа. Это игра словами.
> Если есть узкое место, то с интерпретатором на танки идти как то смешно.
ИМХО, там дело было не в "узком месте", а в глючности редактора - для продакшена это было недопустимо :) Но это читая спекуляция.
> Сегодня бы на Лиспе скорее всего вообще все было написано
"бы", "скорее всего".
[ Глюкодел, это ты? По стилю вроде похоже, но русский язык не исковеркан ]
> Вот это уже правильный подход. Ну и с читабельностью в свою очередь предлагаю на этих двух пунктах вопрос прикрыть.
Мудрость Питона стих 7: Readability counts
Читабельность имеет значения, вопрос в том, в чём её измерять, а вот это уже проблема. Единственное что приходит в голову, это сменить опрос на главной странице и таким образом провести статистическое исследование о том что читается лучше питон или лисп среднестатистическим Лоровцем.
А опрос всё равно не поменяют, так что выяснить это достоверно не удастся... :-(
> Вот об этом я говорил - Яху переписало прототип на Лиспе в практичные языки
Когда же вы оставите при себе свои домыслы? Из текста виден только переход с одного языка на другой и _ни слова_ о причинах! Тем более ни слова про "прототипы" и "практичные языки"! Идите в сад! :)
Тем более, что переписав редактор, шаблоны генераторов они таки оставили в лисповой нотации ;)
> Читабельность имеет значения, вопрос в том, в чём её измерять, а вот это уже проблема. Единственное что приходит в голову, это сменить опрос на главной странице и таким образом провести статистическое исследование о том что читается лучше питон или лисп среднестатистическим Лоровцем.
Это будет "статистика для статистики". Проведите опрос среди:
1) не знающих оба языка
2) знающих только питон
3) знающих только лисп
4) знающих оба языка
Вот тогда можно будет сравнивать ;)
> > На питоне написан > А сколько-нибудь промысшленная OS?
О, да, мсье честно выполняет обещание продолжать передёргивать.
> > Детсад, мля. Винда там. И на msn search тоже винда.
> Нету тама венды, откуда?
Ну не знаю, от windows developement team, видимо - навряд ли они ее сами у себя покупали ;).
> > пример мегасервиса
> мы лисп обсуждаем или мегасервис?
В данный конкретный момент мы обсуждаем применимость Common Lisp для создания крупных систем, эксплуатирующихся под высокой нагрузкой 24x7. На примере вебсервисов. Вот большой вебсервис на Perl+HTML::Mason я знаю - Amazon, на Python - Gmail, а на Uncommon Web?
> > Где же они?
> да фих их знает, не интересовался. Своих траблов полно.
Слив засчитан. Лисп-адвокат не может привести более одной success story в наиболее динамично развивающейся нынче (и последние 10 лет) области.
> Вроде Яху его переписали? Из чистой вредности, конечно. Но всё равно, получается, что продал Грэм прототип, не для "риального прадакшена" (C) (R) (TM)
Ага, то-то он на этом "не для продакшена" свою фирму долго кормил, а потом yahoo купила фирму, поскольку конкуренты отсасывали по полной. У Грема на странице это хорошо расписано: http://www.paulgraham.com/road.html
А переписали (до конца ли ?) много позже, поскольку там, как и везде, заправляют манагеры, которым проще нанять толпу быдлокодеров на плюсах, чем искать пару вменяемых лисперов.
>Ну, если тебе это _видно_ - тогда ой. А во фразе про "100 миллионов >мух..." есть один дефект - там предлагается человеку действовать >так, словно он - муха. Это заставляет усомниться в уме тех, кто ее >придумал, и тех, кто ее повторяет. А если это шутка, то какая-то >она слишком тонкая (== плоская).
От далеких предков нам к сожалению достался стадный инстинкт. Многим достаточно узнать, что большинство кушает гуано, и они с радостью присоединяются, мол чего там, все так делают, наверное в этом есть сакральный смысл.
>Ну да, по большому счету. Подумаешь, написал о том, о чем точно не >знает, в выгодном для себя тоне. Дело житейское.
Вы тоже, я смотрю, довольно свободно оперируете терминами в свою пользу. Ну надо же придраться к чему-то в статье, вот и нашлось к чему.
>Ну, всегда можно сказать, что рабочая система - это воспроизведение >функциональности прототипа. Это игра словами.
Игра словами, это то чем Вы, уважаемый, сейчас упорно занимаетесь, делая вид, что не понимаете, что я имел в виду.
>ИМХО, там дело было не в "узком месте", а в глючности редактора - >для продакшена это было недопустимо :) Но это читая спекуляция.
Домыслы пошли ? С таким же успехом можно предположить, что переписать Yahoo Store на другие языки решили из-за внезапного острого приступа даунизма среди манагеров.
>> Сегодня бы на Лиспе скорее всего вообще все было написано
>"бы", "скорее всего".
Начем выленять отдельные слова и словосочетания из текста ?
>[ Глюкодел, это ты? По стилю вроде похоже, но русский язык не >исковеркан ]
Не он. Я так сильно коверкать русский физически не могу. ;-)
> В данный конкретный момент мы обсуждаем применимость Common Lisp для создания крупных систем, эксплуатирующихся под высокой нагрузкой 24x7. На примере вебсервисов. Вот большой вебсервис на Perl+HTML::Mason я знаю - Amazon, на Python - Gmail, а на Uncommon Web?
Вы "обсуждаете" не _применимость_ а _применяемость_, что есть совсем разные вещи... :)
А самому поискать? Или будем меряться - кто эффективнее использует google? :) Ну вот - одну нашёл :)
Вообще, трёх функций, от которых требующо описываемые мной действия, было бы достаточно
> Только твоё ТЗ было сформулированно нечётко, исходник ты не показал, так что у нас наверное получились несколько разные проги
можно было спросить уточнения, я бы необиделсо
> нарпимер я сделал persistent storage на sqlite, соответственно пооиск по базе файлов работает очень шустро.
ужос! Это даже хужее чем я предполагал. Вместо переменных питону требуецо даза банных информацию хранить :D
> Давай ты не будешь передёргивать, говорить типа оно у меня нетиненадо, а приведёшь исходник с аналогичной функциональностью на лиспе.
Давай. Только погодим, пока тот чел с с++/стл подтянецо. Я подозреваю он просто слил, но из вежливости погодим.
> для добавления файла в базу
сразу таки в базу? чем фс для этово не подходит?
> Прога на лиспе желательно должна работать под Win32
не вижу никаких причин почему бы не работало, но масдаищя позорново вечьноглякавово умя нету, так что проверить нечем
> Вот когда напишешь такую прогу, тогда и поговорим :-)
Давай тада формализуем техзадание, потомушто для моей первоначальной задачи подключение дазы банных - это ПРЕОГРОМНЫЙ оверкилл, а так - я не против. Только как быть с первоначальной задачей? Повторюсь, требуецо создать структуру данных средствами языка, и две функции для работы с этим.
> P.S. Прога передаётся в public domain. Можешь её использовать для чистки своего винта :-)
винт давно почищено, это несложно было даже срецтвами баша сделать. А твоёй прогой на практике ИМХО пока не удасца пользовацо, там даже обхода дерева каталохов на фс нету, вручную файло нужно добавляти.
> трёх функций, от которых требующо описываемые мной действия, было бы достаточно
или
> требуецо создать структуру данных средствами языка, и две функции для работы с этим
сколько функций?
>> Давай ты не будешь передёргивать, говорить типа оно у меня нетиненадо, а приведёшь исходник с аналогичной функциональностью на лиспе.
> Давай. Только погодим, пока тот чел с с++/стл подтянецо.
А что, кто-то собирался на Си++ писать? Что-то я не помню таких. Если речь обо мне, я сразу сказал, что вряд ли возьмусь (и даже объяснил, почему). Если же и возьмусь - то тоже на Питоне.
> можно было спросить уточнения, я бы необиделсо
Да, неплохо бы. Сейчас уже упоминается, что нужно обходить дерево каталогов ФС. Ты определись, что нужно - программа чистки хоума, или структура данных для такой программы?
ясен пень, чё пипл, знакомый с програмёжем в основном по бейсику, более поймёт a=7 чем (setq a 7). Ещё более понятно, чё на задачах, отличных от примитивной калькуляции, вторая запись в общем случае более предпочтительна чем первая, как раз из-за тово, чё (сравнительно) сложные конструкции и сочинять и читать лехче. Другое дело, чё пипл, знакомый с програмёжем в основном по бейсику, не вполне представляет, чё конструкции сложнее чем а=7 бывают в принципе, из-за чего и разногласия нащёт читаемости.
Я ужо. Только не могу понять, почему же он появилсо только в ООП? Или не-ООПнутых прог сравнительной сложности не было или они таки не нуждались в "рефакторинг"?
>> трёх функций, от которых требующо описываемые мной действия, было бы достаточно
> или
>> требуецо создать структуру данных средствами языка, и две функции для работы с этим
> сколько функций?
Не вижу противоречия. Я предполагаю чё структура будет создаваться каким-то учястком кода, который нетрабла вткнуть вфункцию. Такчто функция-инициализатор и две для работы. Всево три.
> А что, кто-то собирался на Си++ писать? Что-то я не помню таких.
вчера выполз троль с c++/STL. Отлистай и прочти, иначе много потеряеш. Я очень смяялсо :D
> Сейчас уже упоминается, что нужно обходить дерево каталогов ФС.
Изготавливать всю прогу необезательно совсем, я предлжил ограничицо указанными тремя функциями. Исключительно в демонстрационных целях. Но раз уж чел создал некоторый код и предложил им пользовацо, я укозал причину, по которой этот код на готовую прогу не тянет.
> более поймёт a=7 чем (setq a 7). Ещё более понятно, чё на задачах, отличных от примитивной калькуляции, вторая запись в общем случае более предпочтительна чем первая, как раз из-за тово, чё (сравнительно) сложные конструкции и сочинять и читать лехче
Ты вообще сам хоть понял что написал? Поясни на примере, где setq будет "читабельнее" знака равенства.