LINUX.ORG.RU

Удалить символ конца строки в CL


0

4

Здравствуйте, всё никак не могу при считывании CSV файла в Хэш-таблицу, символ перевода строки.

вот код:

(defun парсер-CSV (file Хэш-таблица)
;Обнуление строк и столбцов
  (setf Строка 0
		Столбец 0)
;Открытие файла
  (with-open-file (Поток file :direction :input)
;итерирование по потоку из файла
    (loop
       for Строка-потока = (read-line Поток nil)
	   ;если строка не равна nil
       while Строка-потока
	   do(progn(incf Строка);увеличение строки на одну еденицу
	   (setf Столбец 0);Сброс значения столбца до нуля
	   (loop for var in (cl-ppcre:split ";" Строка-потока);итерирование строки по столбцам
	   do(progn (incf Столбец);увеличение строки на еденицу
	   (setf(gethash (Format nil "~a,~a" Строка Столбец) Хэш-таблица)var)))))))

Просто записывается в хэш вместе с символом и потом если эта ячейка вставляется в середину строки то каретка переводится на следующую строку. Как я пробовал решить проблему могу написать если нужно. В емаксе этот символ непечатаемый отображается как «^M» но в инспекторе «Return». Простое сравнение на eql не работает....

Ответ на: комментарий от psv1967

Ты приведёшь пример «средств, позволяющих принципиально свести процесс написания сложного продукта к работе маленькой команды», похороненных по экономическим причинам? Или засчитываем слив?

anonymous
()
Ответ на: комментарий от anonymous

Это все бла бла бла с твоей стороны, сформулируй вопрос? то что написано сейчас не является вопросом, а вырванной цитатой.

Впрочем пожалуйста --- APL системы 70х, начала 80х. Похоронены именно как ты требуешь «по экономическим причинам».

Как признак «средств, позволяющих принципиально свести процесс написания сложного продукта к работе маленькой команды» подойдет: Разработка силами одного человека сложнейшего продукта масштаба предприятия, системы оперативного анализа данных крупнейших банков, программирование со скоростью мысли короче :)

Все это пропало по одной простой причине --- экономической.

Ну давай, возражай.

psv1967 ★★★★★
()
Ответ на: комментарий от anonymous

> Неужто лисп?

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

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

psv1967 ★★★★★
()
Ответ на: комментарий от psv1967

> Не голый лисп, а дсл для прикладной задачи на нем вполне.

Щас он тебе скажет, что создание ДСЛ - это единственное преимущество лиспа, а это в свою очередь - очень узкая, незначительная ниша. Но мы то знаем...

Собственно - это и есть основной тезис кукистов.

anonymous
()
Ответ на: комментарий от anonymous

> Щас он тебе скажет, что создание ДСЛ - это единственное

преимущество лиспа


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

archimag ★★★
()
Ответ на: комментарий от archimag

> техника создания DSL получила наибольшее распространение в Ruby

Пруфлинк есть? А то я то же много чего могу нафантизировать и выдать это за факт.

anonymous
()
Ответ на: комментарий от LamerOk

> а вовсе не DSL'ем единым.

Такого я и не говорил.

archimag ★★★
()
Ответ на: комментарий от psv1967

> Это все бла бла бла с твоей стороны, сформулируй вопрос?

Слушай, ты прикидываешься идиотом, или действительно идиот? Если с третьего раза не можешь понять прямого вопроса, заданного в лоб? Хорошо, в четвёртый, в последний раз спрашиваю:

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

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

anonymous
()
Ответ на: комментарий от psv1967

> Грехем почему то поднялся со своими магазинами (это факт), а купивший его гигант слил технологию. Именно по экономической причине слил

Ну это уже полный п***ц, не лезет ни в какие ворота. Как можно столько времени носить розовые очки? Тебе первый попавшийся лиспер расскажет подлинную историю Грэма и Ко., например, тот же archimag. Дадим ему слово:

Факты о Viaweb

1. В основе системы лежали «продолжения»
2. Работало в режиме cgi
3. В качестве реализации использовался CLISP
4. Переписали уже после ухода Грэхэма

Т.е. это было не очень быстрое и абсолютно не масштабируемое решение. Его в какой-то момент нужно было полностью переписывать на основе нормальной архитектуры.

Резюме: Грэм сотоварищи впарил гиганту идею + proof of concept, который они быстро наваляли на том единственном, чем владели. Этим «чем-то» оказался Common Lisp. Но существовавшие на тот момент компилятор и рантайм были абсолютно не предназначена для задач веба (не могу сказать, что с тех пор ситуация сильно изменилась в лучшую сторону), и лисп в их случае был обречён. Слили его из-за неустранимых технических изъянов, а не по каким-то мифическим причинам из области экономики.

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

anonymous
()
Ответ на: комментарий от anonymous

Ну без пруфов в виде кода viaweb'а это просто слова.

anonymous
()
Ответ на: комментарий от anonymous

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

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

psv1967 ★★★★★
()
Ответ на: комментарий от anonymous

Ну вы тут тоже клоунаду развели. Чего к Грехему прикопались то? Давайте я вам подброшу пример посвежее: ITA Software - разработчиков не два, а несколько десятков, стоит не 50, а 800 млн., основной язык Common Lisp, который используется в том числе и для веб.

archimag ★★★
()
Ответ на: комментарий от anonymous

> Я просто диву даюсь

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

Резюме

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

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

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

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

никаких причин кроме экономических отказываться от лиспа в пользу муравейника разработчиков не было.

psv1967 ★★★★★
()
Ответ на: комментарий от archimag

> разработчиков не два, а несколько десятков

Ну это все равно микроразмер, такие фирмочки оутсорсинговые для городов в 300тыс населения характерны.

стоит не 50, а 800 млн.

вот интересная пропорция 2 -> 50, 50 -> 800 ? Чем крупнее фирма тем больше ее «капитализация». А сейчас даже реальный сектор больше озабочен «ростом стоимости», чем реальным доходом.

Работай они на какой то яве и имея в штате не 50, а 5000 сотрудников имели бы не 800, а все 2-3 миллиарда на пустом месте. И это случится как только они продадутся и начнет решать не пару авторов проекта, а совет эффективных менеджеров.

psv1967 ★★★★★
()
Ответ на: комментарий от psv1967

> Работай они на какой то яве и имея в штате не 50, а 5000

сотрудников имели бы не 800, а все 2-3 миллиарда на пустом месте.


Бред же. Скорей бы всего они бы просто разорились, а инвесторы не смогли бы отбить свои вложения. И никто бы в здравом уме их не купил.

archimag ★★★
()
Ответ на: комментарий от psv1967

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

archimag ★★★
()
Ответ на: комментарий от archimag

> Бред же. Скорей бы всего они бы просто разорились, а инвесторы не смогли бы отбить свои вложения. И никто бы в здравом уме их не купил.

У кого «здравый ум» изволите наблюдать? Там нет, при таких масштабах, личных решений, кроме самых примитивных (типа спереть). Побеждает мнение «выгодно в ближайший отчет --- делаем так». Предприятия крупные давно не зависят от неких тайных и решающих мегасвойств своей продукции. Они зачастую вообще бренд продают.

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

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

В пределе такой биржевой «экономики» некоторые компании даже ничего не выпускали кроме акций. То что другие имитировали(ют) бурную деятельность не делает эту картину принципиально иной.

psv1967 ★★★★★
()
Ответ на: комментарий от psv1967

Осталось только понять, откуда в мире беруться мониторы, клавиатуры, компьютеры, автомобили, новые дома? Про услуги я даже спрашивать боюсь... ;)

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> Осталось только понять, откуда в мире беруться мониторы, клавиатуры, компьютеры, автомобили, новые дома? Про услуги я даже спрашивать боюсь... ;)

усилиями Повстанцев, борющихся против злостных Экономистов

korvin_ ★★★★★
()
Ответ на: комментарий от archimag

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

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

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

anonymous
()
Ответ на: комментарий от psv1967

> так и запишем кловун сдулся

пока, пиши ищо

ко-ко-ко



Слив засчитан.

Впрочем, справедливости ради отметим, что один пример — APL — ты всё-таки привёл. Вернее сказать, его из тебя вытянули клещами. А теперь докажи, что а) APL позволяет принципиально свести процесс написания сложного продукта к работе маленькой команды, б) что от APL отказались по чисто экономическим причинам. Приведи пример продукта, который был написан на APL, причём маленькой (<20 чел.) командой. Затем приведи пример аналогичного (или уступающего) продукта, который был написан не на APL и сравнительно большой командой. Любое петушение и кукареканье не по теме будет рассмотрено как очередной слив.

Кстати, распространяется ли твоя мифология на современных наследников APL, таких как J, на который ты дрочишь? Если да, то я с удовольствием покажу, что ты дрочишь на кусок говна.

anonymous
()
Ответ на: комментарий от anonymous

> Кстати, распространяется ли твоя мифология на современных наследников APL, таких как J, на который ты дрочишь? Если да, то я с удовольствием покажу, что ты дрочишь на кусок говна.

может лучше K?

http://kx.com/end-user-customers.php

http://kx.com/oem-customers.php

korvin_ ★★★★★
()
Ответ на: комментарий от psv1967

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

Послушай, ты вообще знаешь определение «масштабируемости»? Похоже, что нет. Впрочем, я не удивлён.

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


Работало, ага. На сотне клиентов, ага. Поясняю для невежд: плохая масштабируемость — это когда не поможет никакой кластер. Любой мало-мальски смыслящий в веб-технологиях человек знает, что интерпретатор + продолжения + CGI = отсутствие масштабируемости, что и получилось в случае с ViaWeb. Поделие Грэхема не заработало бы принципиально на более-менее серьёзном количестве клиентов. Выход был один — переписать. И продиктован был он исключительно техническими соображениями.

Но тебе, не смыслящему в веб-технологиях ни хера, этого не понять. Поэтому ты выдумал себе миф о злых «эффективных менеджерах», которые ради наживы похоронили йоба-технологию Грэхема и Ко.

ничего лучше лиспа умеющего мемоизировать уже существующий код нет

мемоизировать ... код


мемоизировать


код



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

anonymous
()
Ответ на: комментарий от korvin_

> может лучше K?

Погружаться в ещё один омут говна не имею желания. А вот с J довелось столкнуться в контексте одного примера. Причём пример был тривиальный до жути, и на нём J позорно слил даже Хаскелю.

anonymous
()
Ответ на: комментарий от korvin_

Я предпочитаю дождаться ответа пациента, а потом дать отдельным топиком. А то этот уже скатился.

anonymous
()
Ответ на: комментарий от anonymous

> Работало, ага. На сотне клиентов, ага. Поясняю для невежд: плохая масштабируемость — это когда не поможет никакой кластер.

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

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

psv1967 ★★★★★
()
Ответ на: комментарий от anonymous

> Впрочем, справедливости ради отметим, что один пример — APL — ты всё-таки привёл. Вернее сказать, его из тебя вытянули клещами

ты смотри, слабительное клиенту помогло таки... что то промычал в ответ на 3й прямой вопрос :) кузнец ты наш клещастый :)

Дурашка, ты помнишь кто писал твою любимую книжку «мифический человеко месяц»? и с каким «успехом» описываемый в книге процесс написания OS осиливала мегакоманда под руководством не самого глупого человека?

Ну так вот написание на APL модели аппаратной платформы для которой писалась приснопамятная OS прошло быстро и командой минимального размера. Что тебе еще надо доказывать про эффективность APL?

psv1967 ★★★★★
()
Ответ на: комментарий от anonymous

> Погружаться в ещё один омут говна не имею желания. А вот с J довелось столкнуться в контексте одного примера. Причём пример был тривиальный до жути, и на нём J позорно слил даже Хаскелю.

как там было? ко ко ко? «у нас есть такие приборы» (С)? :)

цыпа, не порть праздник, раскрой тайну «тривиального примера»?

psv1967 ★★★★★
()
Ответ на: комментарий от anonymous

> А то этот уже скатился.

верх цинизма! нежный какой троль пошел однако :) ты не находишь, что это твоими трудами?

psv1967 ★★★★★
()
Ответ на: комментарий от LamerOk

> Осталось только понять, откуда в мире беруться мониторы, клавиатуры, компьютеры, автомобили, новые дома? Про услуги я даже спрашивать боюсь... ;)

... и почему все это исходит все больше и больше на г... ?

Некоторая связь с реальностью еще сдерживает современные компании от полной виртуализации. Но работа над этими досадными мелочами ведется :)

давно видели вменяемую клавиатуру на которой очередные придурки не поменяли местами клавиши от большого ума? и ведь ничего --- покупают :)

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

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

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

psv1967 ★★★★★
()
Ответ на: комментарий от psv1967

> «мифический человеко месяц»

Ну так вот написание на APL


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

archimag ★★★
()
Ответ на: комментарий от psv1967

> как может не масштабироваться 100 независимых веб магазинов?

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

archimag ★★★
()
Ответ на: комментарий от anonymous

> интерпретатор + продолжения + CGI = отсутствие масштабируемости

Это твои фантазии.

anonymous
()
Ответ на: комментарий от psv1967

> клавиатуру на которой очередные придурки не поменяли местами клавиши

монитор не формата и разрешения больше пригодного для жки телевизора


Как страшно быть вами. Но не суть. Мораль то тока одна - дешёвое всегда побеждает, это как бы закон экономики. А вот в ИТ сложилась парадоксальная ситуация, когда 100 дорогих (ибо их много) Java-кодеров выигрывают конкуренцию у 5-ти дешёвых (ибо их мало) APL-кодеров. Да вы гений, парадоксов друг, ага.

archimag ★★★
()
Ответ на: комментарий от archimag

> А если клиент рекламу дал, так что в итоге и его магазин лёг, и все магазины на том же серваке заодно?

Про балансировщики нагрузки ты, видимо, не слышал.

anonymous
()
Ответ на: комментарий от anonymous

> Про балансировщики нагрузки ты, видимо, не слышал.

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

archimag ★★★
()
Ответ на: комментарий от archimag

> Угу, расскажите пожалуйста, как предложенная схема (каждый магазин на своём сервере)

Что, прошу прощения? Я про:

А если клиент рекламу дал, так что в итоге и его магазин лёг, и все магазины на том же серваке заодно?

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

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

А ты после нашего последнего разговора о продолжениях так и не удосужился заняться самообразованием? Все еще не знаешь, как продолжения работают и реализуются? Я вобщем-то не знаю, какие были продолжения «в Грэхэмовском варианте» (были бы исходники - другой разговор, тогда сразу бы стало все понятно), но это был CL. А значит стандартный вариант реализации - cps-преобразование. В этом случае все прекрасно балансируется (почему - тебе задачка на дом). А я не думаю, что Грэхэм был тупее меня, не понимал подобных вещей и выбрал какую-то кривую реализацию.

anonymous
()
Ответ на: комментарий от anonymous

> А я не думаю, что Грэхэм был тупее меня, не понимал подобных вещей и выбрал какую-то кривую реализацию.

А даже если и выбрал - переделать нормально было не проблема совершенно.

anonymous
()
Ответ на: комментарий от anonymous

> Я про: > А если клиент рекламу дал, так что в итоге и его магазин

лёг, и все магазины на том же серваке заодно?


Вы вообще за мыслью следите? Сделайте одолжение, подымите голову на строчку выше.

А я не думаю, что Грэхэм был тупее меня, не понимал подобных вещей


Угу, поэтому наравне с вами тщательно это скрывает.

переделать нормально было не проблема совершенно.


Так и передали нормально, только на Perl + C++.

archimag ★★★
()
Ответ на: комментарий от anonymous

Кстати, обратите внимание, что Грэхэм нигде никак ничего не говорит про масштабируемость. Ну ладно, бог с ним, с Грэхэмом, может привести пример реальной системы масштаба Yahoo! Store на базе продолжений?

archimag ★★★
()
Ответ на: комментарий от archimag

> Вы вообще за мыслью следите? Сделайте одолжение, подымите голову на строчку выше.

Я-то слежу, а вот ты за своей собственной мыслью уследить не в состоянии. Повторяю вопрос:

А если клиент рекламу дал, так что в итоге и его магазин лёг, и все магазины на том же серваке заодно?

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

Так и передали нормально, только на Perl + C++.

Да, только переделать на perl + C++ было огромной проблемой. Да и не доказано, что вообще нужно было что-то переделывать.

anonymous
()
Ответ на: комментарий от archimag

> Кстати, обратите внимание, что Грэхэм нигде никак ничего не говорит про масштабируемость.

А зачем об этом говорить? И так же всем понятно, что она была масштабируемой. Или, по-вашему, Грэхэм _нарочно_ приложил некоторые усилия, чтобы она масштабируемой не была? Просто заговор Грэхэма какой-то.

может привести пример реальной системы масштаба Yahoo! Store на базе продолжений?

А может на базе CL?

anonymous
()
Ответ на: комментарий от anonymous

> повторяю вопрос: > А если клиент рекламу дал, так что в итоге и его

магазин лёг, и все магазины на том же серваке заодно?

как так может произойти, если каждый магазин на своем сервере?



Вы что, вообще гоните? Перед этим было сказано «Или сколько магазинов на один сервак?».

Да, только переделать на perl + C++ было огромной проблемой.

Да и не доказано, что вообще нужно было что-то переделывать.



Ну да, инженерам в Yahoo больше делать было нечего и они рады забавы потратили на это кучу денег и времени.

archimag ★★★
()
Ответ на: комментарий от anonymous

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

Просто удивительно просто. Оказывается такой проблемы как масштабируемость просто не существует.

А может на базе CL?


При чём здесь CL? Но можете и на базе CL, будет любопытно.

archimag ★★★
()
Ответ на: комментарий от archimag

Перед этим было сказано «Или сколько магазинов на один сервак?».

Ах, ок. но это не суть важно - на самом деле сколько угодно магазинов на сколько угодно серверов + балансировщик. Это как оно было на практике, а не в ваших фантазиях.

Ну да, инженерам в Yahoo больше делать было нечего и они рады забавы потратили на это кучу денег и времени.

Ну так грэхем излагает причины, по которым Yahoo решили переписать, только вот никаких проблем с масштабируемостью среди них нет:

(a) The reason they rewrote it was entirely that the current engineers didn't understand Lisp and were too afraid to learn it.

(b) The resulting program is a new world's record case of Greenspun's Tenth Rule. The Yahoo Store Editor called compile at runtime on s-expressions made on the fly. To translate this into C++ they literally had to write a Lisp interpreter.

(c) Even then, they had to drop some features (involving advanced uses of closures).

То есть Грэхем, врет, так? более того, немного погуглив, я нашел:

One of the problems with using Web pages as a UI is the inherent statelessness of Web sessions. We got around this by using lexical closures to simulate subroutine-like behavior. If you understand about continuations, one way to explain what we did would be to say that we wrote our software in continuation-passing style.

When most web-based software generates a link on a page, it tends to be thinking, if the user clicks on this link, I want to call this cgi script with these arguments. When our software generated a link, it could think, if the user clicks on this link, I want to run this piece of code. And the piece of code could an arbitrary piece of code, possibly (in fact, usually) containing free variables whose value came from the surrounding context.

The way we did this was to write a macro that took an initial argument expected to be a closure, followed by a body of code. The code would then get stored in a global hash table under a unique id, and whatever output was generated by the code in the body would appear within a link whose url contained that hash key. If that link was the next one clicked on, our software would find and call the corresponding bit of code, and the chain would continue. Effectively we were writing cgi scripts on the fly, except that they were closures that could refer to the surrounding context.

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

anonymous
()
Ответ на: комментарий от archimag

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

Для решения, которое по определению масштабируемо - не сущесвует.

При чём здесь CL? Но можете и на базе CL, будет любопытно.

Опечатка. Имелось ввиду: «А можете на базе CL?». Ну и с указанием вебсервера, который там используется, естественно.

anonymous
()
Ответ на: комментарий от psv1967

> процесс написания OS осиливала мегакоманда
> написание на APL модели аппаратной платформы ... прошло быстро и командой минимального размера

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

Итак, твоё «доказательство» низложено. Будешь пробовать ещё? Или засчитываем очередной слив?

anonymous
()
Ответ на: комментарий от anonymous

> тебе надо было привести примеры двух эквивалентных проектов

Так тебе какие два проекта не приведи - ты потребуешь доказательства их эквивалентности. А доказать можно только эквивалентность проекта самому себе.

Но, кстати, говоря об этом: viaweb. Конечно, это CL, а не APL, но прекрасный пример - большая команда не может на с++\perl реализовать полный функционал того, что реализовала маленькая команда на CL.

anonymous
()
Ответ на: комментарий от anonymous

> Ну так грэхем излагает причины, по которым Yahoo решили переписать

Да, я читал Грэхэма и он последний, кому бы я стал верить в этом вопросе. Что он должен был сказать?

Другими словами, Грэхем использовал легковесную эмуляцию продолжений,

которая, как становится сразу ясно из описания, изначально включала в


себя возможности масштабирования.



Ну как, расскажите как. Потому что я вижу совершенно обратное.

archimag ★★★
()
Ответ на: комментарий от archimag

> Да, я читал Грэхэма и он последний, кому бы я стал верить в этом вопросе.

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

Что он должен был сказать?

То что есть. Он уже продал виавеб, какой смысл ему был врать? Почему в самом yahoo виавеб описывалось как «задающее стандарт в области производительности»? Почему оно прекрасно работало 5 лет? Кто-нибудь почувствовал резкое, четкое ускорение работы после перехода на новый движок? Опять же слова Грехэма про то, что лисповая часть была эмулирована на плюсах - и в этом случае все траблы связанные с продолжениями тоже остались - это прямая ложь?

Ну как, расскажите как.

Там написано - как. Я повторюсь - у реализаций основанных на cps-преобразовании нету никаких проблем с масштабируемостью. На самом деле и у других нету, потому что никто не мешает автобалансировщику делать балансировку по новым продолжениям, а не по запросам. Просто по серверам будут раскидываться не отдельные запросы, а пачки штук по ~10 максимум. Здесь есть, конечно, ряд подводных камнеЙ, но они вполне обходятся.

anonymous
()
Ответ на: комментарий от archimag

Да, и самый важный вопрос - почему они переписали именно на с++/perl, а не на чотком, классном CL, но без продолжений? Этот факт заставляет предположить, что дело было не в продолжениях, а в самом CL, нет?

anonymous
()
Ответ на: комментарий от anonymous

> Он уже продал виавеб, какой смысл ему был врать?

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

Почему оно прекрасно работало 5 лет?


За 5 лет количество пользователей, если я правильно помню, увеличилось примерно в 20 раз.

Там написано - как.


Там описана совершенно жуткая схема. А вы тут сказки рассказываете. Изложите уже эту волшебную схему, которая это г.. превратит в конфетку.

archimag ★★★
()
Ответ на: комментарий от anonymous

> почему они переписали именно на с++/perl, а не на чотком,

классном CL, но без продолжений?


А почему они должны были переписывать на CL? Да в то время CL и совсем не был «чотким и классным». Один только факт использования CLISP чего стоит.

archimag ★★★
()
Ответ на: комментарий от archimag

> И тот должен признаться, что да, своё бабло я срубил, а система была г..?

Ну почему говно? Она 5 лет вполне нормально работала.

За 5 лет количество пользователей, если я правильно помню, увеличилось примерно в 20 раз.

Ну так есть инфа о том, что оно тормозило?

Там описана совершенно жуткая схема.

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

А вы тут сказки рассказываете.

Сказочник - это ты. Безграмотный сказочник.

anonymous
()
Ответ на: комментарий от archimag

> Да в то время CL и совсем не был «чотким и классным».

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

anonymous
()
Ответ на: комментарий от archimag

> Мораль то тока одна - дешёвое всегда побеждает, это как бы закон экономики

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

А вот в ИТ сложилась парадоксальная ситуация, когда 100 дорогих (ибо их много) Java-кодеров выигрывают конкуренцию у 5-ти дешёвых (ибо их мало) APL-кодеров. Да вы гений, парадоксов друг, ага.

С какого бодуна ява кодеры дорогие? Они такскать «энмасс» дорогие, суммарно-с. Причем обоснованно, ни один эксперт оценивающий стоимость работ не подкопается. Ну а прочие все вещи в цене практически всегда процент накрученные на объективные затраты. Отсюда и выгода иметь муравейник ява программистов.

APL кодеры дорогие за голову (посмотрите на K). Но раз их на проекте раз-два и всё, то в сумме денег мало.

Ну простая ситуация ведь?

psv1967 ★★★★★
()
Ответ на: комментарий от anonymous

> Макрос выдирает нужные лямбды, и гдето там сохраняет, во время старта

сервера все лямбды у нас уже есть, по-этому можно хоть нцать серверов

запустить



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

archimag ★★★
()
Ответ на: комментарий от anonymous

> Напоминаю: тебе надо было привести примеры двух эквивалентных проектов, один из которых был бы написан на APL маленькой командой, второй — с использованием другого инструмента и большой командой.

Будем продвигаться по шагам :) что бы не напрягаться зря :)

1) Два статпакета это пример «эквивалентных проектов»?

psv1967 ★★★★★
()
Ответ на: комментарий от anonymous

> что за последние несколько лет появилось в CL такого,

что он _стал_ чотким и классным?


Не знаю, что в вашем понимании «чоткий и классый», но по уровню развития платформы он безусловно уступает той же Java.

проблема, как я и сказал, была все же в CL, а не в продолжениях.


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

archimag ★★★
()
Ответ на: комментарий от archimag

> Я думаю, что ссылаясь на что-то, надо понимать, на что ссылаешься. «Мифический человеко-месяц» как раз начинается с описания фенома «написания удивительного продукта парой инженеров за пару месяцев в гараже» и детального объяснения почему это не работает для реальных промышленных систем.

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

Приведите пример что кто то повторил полное описание аппаратной платформы на промышленном (используемом в «программной индустрии» :) языке. Даже не за год, и каким угодно большим коллективом.

У меня есть только пример бурана, но там был пролог.

psv1967 ★★★★★
()
Ответ на: комментарий от archimag

> Вы же по своему обыкновению ничего не читаете и не помните контекста обсуждения.

Откройте секрет, как вы столь уверенно различаете анонимусов? :)

psv1967 ★★★★★
()
Ответ на: комментарий от archimag

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

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

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

Зачем? Не надо ее после каждого запроса изменять.

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

Ну да, я же сказал о том, что после получения запроса перед запуском лямбды устанавливается контекст. Ну вам никто не мешает этот контекст в запросе передать, что в нормальных реализациях и делается. Тем более что в viaweb судя по описанию эти лямбды создавались/запускались/передавались практически руками - так что ввести пару простейших оптимизаций было очень легко впоследствии, даже если их там не было изначально. Я конечно не отрицаю, что _можно было_ все это сделать криво и немасштабируемо, но зачем, если простейшее и очевидное решение как раз-таки масштабируемо вполне? И еще раз повторю - решение на с++/perl по определению имело те же недостатки, что и оригинал. Если первое было немасштабируемо, то нутыпонелда. Другими словами, сделать масштабируемое решение из viaweb никаким переписыванием не было возможно, если оно таковым не было изначально.

anonymous
()
Ответ на: комментарий от archimag

> Не знаю, что в вашем понимании «чоткий и классый», но по уровню развития платформы он безусловно уступает той же Java.

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

Проблема Viaweb была в комплексе причин, с чего и начался разговор.

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

anonymous
()
Ответ на: комментарий от archimag

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

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

anonymous
()
Ответ на: комментарий от anonymous

> Не надо ее после каждого запроса изменять.

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

устанавливается контекст



Раскройте же секрет использования это чудной техники в контексте CL, каким образом можно установить контекст вычислений для лямбды? Грэхэм говорит про хэш-таблицу с кусками кода, а в ссылке просто указывался ключ. Т.е. если «установка контексте для лямбды» и возможно с помощью какого-нибудь грубого хака и изменения оригинального кода реализации (хотя я о таком ничего не слышал), то в любом случае Грэхэм использовал другой подход.

Другими словами, сделать масштабируемое решение из viaweb никаким

переписыванием не было возможно, если оно таковым не было изначально.



Как так? Любое веб-приложение можно переписать полностью так, что пользователь этого даже не заменит. Взять и написать заново точно так же выглядящее для пользователя приложения можно множеством различных способов.

archimag ★★★
()
Ответ на: комментарий от anonymous

> Во-вторых, в поддержку этой гипотезы у тебя только один аргумент

- «продолжения масштабируемыми быть не могут»


Вы вообще о чём в конце то концов?

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

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

archimag ★★★
()
Ответ на: комментарий от archimag

Раскройте же секрет использования это чудной техники в контексте CL, каким образом можно установить контекст вычислений для лямбды?

(defvar *x*)
(defun f () (print x))

(setq *x* 20) ;установили контекст
(f) ;вызвали лямбду

или

(eval `(f)) ;вызвали лямбду
если там именно кусок кода хранился. Ваистену совершенно нетривиальная метода. Тупой Грэхем бы никогда, ну никогда до такого додуматься бы не смог. Вопрос тут в единственном - устанавливал ли Грехэм контекст или сохранял с лямбдой? Если он хранил куски кода, то контекст он устанавливал. Если саму лямбду - мог сохранять с лямбдой. Во втором случае, действительно, выходит немасштабируемое решение. Но оно легко переделывается в явную передачу контекста через запрос. Ах, постой, там же был CGI? Ну тогда он сохранял код и сериализовал контекст, других вариантов нет. Вопрос - сохранял ли он контекст на сервере, но даже если да, тут уж вообще требуется минимум изменений для сериализации в запросе, фактически, надо переписать функции (де)сереализации контекста и все.

anonymous
()
Ответ на: комментарий от archimag

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

Множеством различных - но не каким угодно. Если состояние где-то сохранялось, то оно так и должно где-то сохраняться, иначе логика работы _в чем-то_ но будет изменена. И тут собственно один вариант - если раньше состояние хранилось на сервере, то теперь его надо передавать к/от юзеру, что при желании можно увидеть. И в любом случае проще было тут слегка изменить CL-вариант, чем пидорасить все с нуля на цепепе.

anonymous
()
Ответ на: комментарий от archimag

> Вы вообще о чём в конце то концов?

Я о причине переписывания виавеба. А ты о чем?

Мы эту тему уже обсуждали и тогда остановились на том, что серилизация продолжений и передача их через куки имеют ограниченную область применения

1. в общем удобнее через строку запроса чем через куки 2. чем она ограничена?

Ты опять фантазируешь, меня это начинает утомлять.

Если у вас было что сказать на эту тему, то надо было говорить там.

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

anonymous
()
Ответ на: комментарий от anonymous

> (defvar *x*)

Зашибись, вы предлагаете конвертировать лексические переменные в динамические? Тогда вообще о каких лексических замыканиях идёт речь? При таком подходе ни замыканя, ни продолжения вообще нах не нужны. Прям ELisp какой-то.

archimag ★★★
()
Ответ на: комментарий от anonymous

> 1. в общем удобнее через строку запроса чем через куки

2. чем она ограничена?


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

archimag ★★★
()
Ответ на: комментарий от archimag

> При таком подходе ни замыканя, ни продолжения вообще нах не нужны.

Ну так Грэхем и пишет, что у него там «типа» замыкания и продолжения, а на самом деле сохранялись куски кода, выдираемые макросом.

Зашибись, вы предлагаете конвертировать лексические переменные в динамические? Тогда вообще о каких лексических замыканиях идёт речь?

На самом деле я предлагаю конвертировать локальные переменные в глобальные, потому что локальный контекст вызванного продолжения де-факто глобален. А вообще - ты знаешь другой способ протащить контекст в случае использования CGI? То есть у тебя лямбда - это просто `(lambda () (print x)), например, ясно же, что перед тем, как делать ее eval тебе надо установить значение х. Какая разница будет эта х лексической или динамической в данном случае? Сама лямбда этого даже «не заметит».

anonymous
()
Ответ на: комментарий от archimag

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

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

anonymous
()
Ответ на: комментарий от anonymous

> И еще раз повторю - решение на с++/perl по определению имело те же недостатки, что и оригинал.

Переходи с химии на что-нибудь растительное иначе быстро и плохо кончишь.

LamerOk ★★★★★
()
Ответ на: комментарий от anonymous

Давай я лучше тебе помогу это сделать:

решение на whatever по определению имело те же недостатки, что и оригинал.

решение на whatever по определению имело те же недостатки


whatever по определению имело те же недостатки


whatever по определению имело те же


по определению имело те же


по определению те же


по определению

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

А теперь обрати внимание на то, что там не просто решение на whatever, а решение на whatever, которое эмулировало логику работу оригинала.

anonymous
()
Ответ на: комментарий от anonymous

> которое эмулировало логику работу оригинала.

А теперь объясни, с чего ты наполнил смысл слова «эмулировало» смыслом слова «копировало»?

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


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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Это ты с какого потолка взял такие требования? В общем случае к изменению начинки веб-софта требования только одно - шоп пользователь ничего не заметил. Унутрях можно менять что угодно как угодно. Можно менять файлы на сикль или наоборот, можно менять cgi на выделенного демона и т.д. Нет никакой причины, чтобы делая заново логику виавеба, повторять все те косяки, что были сделаны грэхемом.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> шоп пользователь ничего не заметил.

вообще-то это более строго требование, чем «сохранение логики работы». Можно сохранить логику работы, так что ты льешь воду на мою мельницу.

Можно менять файлы на сикль или наоборот, можно менять cgi на выделенного демона и т.д.

Поменять файлы на сикль - это изменение логики работы приложения? У нормальных людей это легкий рефакторинг двух ф-й.

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

Ну, во-первых, Грэхем говорит, что косяки они повторили (т.к. по сути написали интерпретатор на сях для старого лиспокода). Допустим, это не так. Тогда, во-вторых, ты, видимо, меня прослушал - речь вообще исключительно о передаче состояния. Если состояние было и где-то хранилось, то это состояние и в переделанной версии тоже будет существовать, и оно должно будет где-нибудь храниться. Вопрос тут - где? Допустим, в Грэхемовской версии оно хранилось на сервере, а его переложили в те же куки. И тут мы подходим к следующему. Итак, в-третьих. Разговор шел вообще о чем? О том, зачем виавеб был переписан. Если прав Архимаг - то есть дело в хранении состояния на сервере (предположим у Грэхема хранилось на сервере) - то зачем переписывать виавеб целиком? Можно было переписать те несколько ф-й, которые отвечали за де/сереализацию, загрузку и сохранение состояния так, чтобы состояние хранилось как в новой версии. Это было бы на порядок проще, чем переписывать с нуля, велосипедить руками интерпретатор для части лиспо-кода, который не удалось заменить, и отказываться от части фич. Если же Архимаг не прав - то есть были другиче причины для того, чтобы переписать - то тогда действительно, можно предположить, что в решении Грэхема и впрямь были указанные Архимагом недочеты. но это уже не важно - ведь переписывали все равно по другйо причине. А недочеты убрали просто походя - ну реально, раз переписываем, то почему бы сразу и не пофиксить досадные мелочи?

anonymous
()
Ответ на: комментарий от anonymous

> вообще-то это более строго требование

Поменять файлы на сикль - это изменение логики работы приложения?


У тебя какое-то своеобразное понимание логики _работы_ приложения.

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


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

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


Это бессмысленное утверждение, проистекающее из твоего непонимания понятия «логика работы». Может перевод на слова «реализация»/«имплементация» как-то поможет тебе понять, о чём была речь.

Если прав Архимаг - то есть дело в хранении состояния на сервере


Читай тред еще раз. Архимаг не про какое-то вшивенькое «хранение состояний» говорил, а про само технологическое решение. Впрочем, раз ты не понимаешь, что такое «логика работы», то понятие «решение» для тебя заведомо пусто.

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

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> У тебя какое-то своеобразное понимание логики _работы_ приложения.

Логика работы - это, например «сохранить данные», «загрузить данные», а куда и как мы их будем сохранять/загружать - это уже не логика. Это детали реализации, которые не принципиальны.

В общем случае, это ложное утверждение.

Нет.

вместо этого состояния можно получить либо комбинации других состояний

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

либо вообще его убрать.

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

Это бессмысленное утверждение, проистекающее из твоего непонимания понятия «логика работы». Может перевод на слова «реализация»/«имплементация» как-то поможет тебе понять, о чём была речь.

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

Архимаг не про какое-то вшивенькое «хранение состояний» говорил

Именно про это он и говорил. Будь внимательнее. Архимаг сказал, что решение немасштабируемо, потом что оно использует континуации, для которых следует хранить состояние. Если не понимаешь о чем разговор - не лезь. Хотя какие тебе континуации, если ты даже логику от реализации отличить не способен.

anonymous
()
Ответ на: комментарий от anonymous

> Логика работы - это, например «сохранить данные», «загрузить данные», а куда и как мы их будем сохранять/загружать - это уже не логика. Это детали реализации, которые не принципиальны.

В этом твоя ошибка. Данные не существуют сами по себе. Данные - способ реализации логики. Разная логика - разные данные.

Если состояние убрать - логика работы изменится.


Правильно.

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


Не правильно. Кто тебе сказал, что речь идёт о данных, видимых пользователю?

«логика работы» и «реализация» - это как раз ортогональные понятия.


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

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


Это ты будь внимательнее. Вот о чём шла речь:

http://www.linux.org.ru/jump-message.jsp?msgid=6064943&cid=6080576

«Хранение состояний» лишь один косяков всего решения. Ты возбух, что без кода виавеб - это всё туфта. Тебе привели пруфы. Теперь ты юлишь, и пытаешься выехать на совершенно смешном тезисе, что те, кто переделывал систему должны были «повторить логику реализации». Я, насколько мог, постарался тебе объяснить бредовость этого тезиса. Если ты не можешь этого понять - это уж не моя вина.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> Данные не существуют сами по себе. Данные - способ реализации логики. Разная логика - разные данные.

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

Не правильно. Кто тебе сказал, что речь идёт о данных, видимых пользователю?

А кто тебе сказал, что нет? Я смотрю на слова Грехэма - он использовал продолжения, чтобы сохранять данные о состоянии программы (собственно продолжения по определению именно состояние и сохраняют). Это как раз тот вид данных, который пользователь всегда видит.

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

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

«Хранение состояний» лишь один косяков всего решения.

Ну так ты читай внимательно то, что сам цитируешь. Архимаг называет единственный косяк - хранение состояния (если ты невнимательно читал дискуссию поясняю - Архимаг уверен, что приложения, основанные на продолжениях, не могут быть масштабируемы, т.к. продолжения сохраняют состояние на сервере. это, конечно, не верно (можно сохранять и не на сервере), но до Архимага сей факт никак не дойдет, он рогом уперся и все). Пункт 3 смешон - кто мешает заменить одну из реализаций CL другой реализацией? Аналогично пункт 2 - чтобы отвязатьсяо т cgi нужен минимум изменений.

Ты возбух, что без кода виавеб - это всё туфта. Тебе привели пруфы.

В том и дело, что мне не привели ни одного пруфа. Все утверждения Архимага основываются на том, что МОЖЕТ БЫТЬ виавеб перестал выдерживать нагрузки, из-за того, что МОЖЕТ БЫТЬ Грехем использовал немасштабируемый вариант продолжений (Грехэм - идиот раз), что МОЖЕТ БЫТЬ Грехэм не знал ничего о декомпозиции (Грэхем - идиот дважды) в результате чего сериализирующий состояния код был размазан по всему приложению, что МОЖЕТ БЫТЬ Грэхем нагло пиздит, когда называет совершенно другие причины переписывания виавеба. Другими словами, Грэхем - дважды идиот и пиздабол. Ни одного не то что пруфа - а хотя бы затхлого аргумента, который подтвердил бы его точку зрения, Архимаг не привел за все время. Все основывается на том, что МОЖЕТ БЫТЬ это было так. Но почему это должно быть именно так, как хочется Архимагу, если все факты (слова Грэхема, особенности использованных технологий, очевидность ряда решений) против? С какой стати следует верить Архимагу, который не знает ничего о том, как работал виавеб, а не Грэхему, который уж точно знает как и явно больше знает о причинах переписывания - не как Архимаг, производя нереальные цепочки того, что МОГЛО БЫ БЫТЬ, а основываясь на информации из первых рук?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.