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

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

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
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.