LINUX.ORG.RU
Ответ на: комментарий от bugmaker

>> И еще: по-моему, в таких случаях нужно писать "did you know THAT", не "what". Нет?

>Я ужо говорил, чё перепечятал это из толи борландовской толи мсявой проги

Не узнал тебя под анонимусом

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

А, ну тогда я буду спать спокойно... ;)

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

> За 2-3 века было прогрессу больше чем за тыщелетия.

Не в том дело, когда развитие было быстрее (я бы не взялся оценивать). Главное - развитие было всегда, и некоторое время рабовладение было его двигателем.

> Я предпочитаю сам создавать то, чё лет чз 10 смотреть будут.

Доведешь до юзабельного состояния - запости ссылку

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

> Главное - развитие было всегда, и некоторое время рабовладение было его двигателем.

Не, я думаю, с "двигателем" ты перебрал... Ну ещё "используя эффективность" или что-то в этом роде... Но двигателем... ;)

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

>> Главное - развитие было всегда, и некоторое время рабовладение было его двигателем.

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

ОК, "и некоторое время рабовладение способствовало прогрессу".

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

> У тебя проблемы с датами или чтением?

С чтением. Прочитал, что рабство стало невыгодным к "500 г. до н.э.".

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

> > Египет и Микены, Рим и Карфаген были большим шагом вперед по сравнению с племенными кланами пастухов

> При этом зижделись на использовании рабского труда.

Ну дык и я о том же. Впрочем, это уже совсем жесточайший оффтопик.

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

> Не узнал тебя под анонимусом

Это не я под ононимусом, это просто так неудачно процитировали.

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

> Не в том дело, когда развитие было быстрее

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

> Главное - развитие было всегда,

ну, совсем ево не может не быть, полюбому.

> и некоторое время рабовладение было его двигателем.

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

> Доведешь до юзабельного состояния - запости ссылку

Ладно. А как доказать, что это именно то, на что будут смотреть?

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

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

Да? Школьный курс истории утверждал, что "индейцы не знали колеса".

> А как доказать, что это именно то, на что будут смотреть?

Мне без разницы - будут, не будут. Мне _самому_ взглянуть любопытно.

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

> Да? Школьный курс истории утверждал, что "индейцы не знали колеса".

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

> Мне без разницы - будут, не будут. Мне _самому_ взглянуть любопытно.

ну на лисп глянь сперва, там многое на ево основе.

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

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

> Я знал, что ты это скажешь 8)

Хшё когда меж собеседниками взаимопонимание.

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

> А что можно тюнить в хеше, кроме собственно хэш-функции и количества (политики аллокации) этих, как их по русски, "ведер"?

И этого за уши хватает.

> У плюсового hash_map первое - параметр шаблона. Наверняка есть и реализации, где второе настраивается через policy.

Конечно существуют. Более того, я сам такие писал ;-). Об чем, собсно, и спич.

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

> Потому что изначально он был нацелен на работу с символами, а не адресами. Да, в его синтаксис можно загнать и работу с сылками, но в итоге вы не получите конечной гибкости. А работа с символами - некоторый "оверхед".

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

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

>Лисп тоже не сразу стал CL-м.

Совершенно верно. Стандартом ANSI он стал только в 1994 году. Вся история LISP -- это борьба реализаций и подходов. То есть настоящий эволюционный процесс. И CLOS в одночасье не появился. До этого были абсолютно разные реализации: LOOPS от Xerox, FLAVORS от симболикса и др. AFAIK, именно версия от Xerox легла в основу стандарта. Ну или по большей части.

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

>>Лисп тоже не сразу стал CL-м.

>Совершенно верно. Стандартом ANSI он стал только в 1994 году.

Не знаю насчет стандарта ANSI, но "Common Lisp was defined and a book published in 1984 called 'Common Lisp: the Language'". Так что сам язык - ровесник Си++.

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

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

На сколько легко? И как давно? Вы про сегодняшний день, или про всю историю лиспа?

"непортабельно из-за слишком малого ядра языка" - расшифруйте пожалуйста :) И опять же, мы о лиспе "CAR-CDR" или о CL? В CL-е ядро маленьким никак не назовёшь. А со всеми необходимыми типами и т.п. - это уже почти CL получится. Вывести всю систему типов из списка можно, но это будет очень неэффективно (если вы только не предложите спец. процессор :)

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

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

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

>Не знаю насчет стандарта ANSI, но "Common Lisp was defined and a book published in 1984 called 'Common Lisp: the Language'". Так что сам язык - ровесник Си++.

Ну я сейчас не готов говорить, почему у этих языков в результате такая разная судьба. Этот период надо пережить. Я могу только говорить за себя. Когда я учился в бауманке, то моей тематикой были около-ИИ-шные темы. Ну и первое, что попадалось на глаза были LISP и Пролог. В результате в качестве среды для реализации был выбран Пролог. Инфраструктура была более развитая. Он чаще попадался на глаза. А еще интернета толком не было тогда. Только некоторые счастливчики на работе имели. Поэтому узнать более подробно, а тем более получить что-то подобное на руки для LISP было нереально. А вот с Прологом было все гораздо лучше (всюду был как минимум компилятор Borland Turbo Prolog). А как появился Интернет, то средство было выбрано. Потом был голландский SWI Prolog (его я использовал наиболее активно), Quintus Prolog и т. д. Считаю, что я много потерял, не имев возможности обратить внимание на LISP тогда. C++ был сразу подхвачен индустрией для массового внедрения. А LISP большей частью был в университетской среде. Кто первый встал, того и тапки. Вот и все мысли неглубокие. Говорить о том, что не произошло, не имеет смысла. Говорить уместно о том, что произойдет :)

P.S. А эффективные реализации Пролога есть и на LISP. :)

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

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

Первым-то встал как раз Лисп. Почему же раз за разом тапки доставались не ему?

> Говорить уместно о том, что произойдет :)

И что же произойдет?

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

(defun permutations-my (x) (if x (loop for e in x append (loop for p in (permutations (remove e x :count 1 :test 'eq)) collect (cons e p))) '(nil)))

Так вроде читабельней

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

(defun permutations-my (x)
  (if x
      (loop for e in x append
            (loop for p in (permutations (remove e x :count 1 :test 'eq))
                  collect (cons e p)))
      '(nil)))

Дубль два.

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

>Первым-то встал как раз Лисп. Почему же раз за разом тапки доставались не ему?

В тапки индустрии. Крутился вокруг исследовательских проектов относительно небольшого количества людей (типа посвященных). Ну еще внутри корпораций для своих нужд использовался и до тех пор, пока были люди, его знающие. И главное -- не было тмогущественных компаний, которые его продвигали и совершенствовали. Был симболикс, были подразделения в Texas Instruments (CLX там и был написал в 1987 году, LISP-машины делали), была LMI, для которой старался RMS. Но это не тот масштаб. И слава богу, что так. Мне не хочется, чтобы Lisp стал мэйнстримом. Поэтому и убеждать не хочу никого. :)

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

> Первым-то встал как раз Лисп. Почему же раз за разом тапки доставались не ему?

Опять про море? ;)

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

Ещё вопросы есть?

P.S. Не устали нам доказывать, что лисп вам незачем? :)Ь

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

>> Первым-то встал как раз Лисп. Почему же раз за разом тапки доставались не ему?

>Опять про море? ;)

А у него я еще не спрашивал ;)

> Где ему тапки не достались? На писишках? Так он там первым и не был

Да нигде - ни на мини-машинах, ни на рабочих станциях. "Встал первым" == "первым ассимилировал в себя кучу передовых идей".

> Ещё вопросы есть?

А ответы?

> P.S. Не устали нам доказывать, что лисп вам незачем? :)Ь

??? "Доказывать" ? Я сказал в самом начале - _сейчас_ Лисп мне не нужен, что тут доказывать? А мнения лисперов о том, почему их язык при всех достоинствах остался уделом немногих - мне интересны. "Мне не хочется, чтобы Lisp стал мэйнстримом." - это интересное мнение. Еще бы услышать обоснование :)

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

> Первым-то встал как раз Лисп. Почему же раз за разом тапки доставались не ему?

За песюки война токо-токо начинается. Ну ненужно было раньше на писишках таково рода наречий. И двух-трёхкратный проигрыш в производительности жалко было отдавать, и задачи сравнительно простые и прог мало делалось => можно было нанять нужное число человек и всё на с/с++ сделают. Именно в последнее время проснулся интерес к интерпретируемым/байткодным. Начяли появляцо всякие руби с питонами. А подход к программированию пока старый остался, с/с++-образный. Нового не выработали ещё. Скоро случицо кризис в айти, потом ужо всё по своим местам расползёцо.

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

> Да нигде - ни на мини-машинах, ни на рабочих станциях.

Хм, биологи давно вовсю юзают. Остальным пока не припёрло.

> "Встал первым" == "первым ассимилировал в себя кучу передовых идей"

Бывают _ненужные_пока_ идеи, хоть они правильные и передовые.

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

Как раз достаточно многих. Из более чем 2000 языков и наречий много ли сможеш назвать? А сколько из них юзаецо больше лиспа?

bugmaker ★★★★☆
()

Новости с полей (между делом). Если кому интересно, то появился инсталлятор SBCL 0.9.17 для Windows. У меня таковых нет. Так что пофиг. А кому-нибудь будет интересно. Сборка официальная, но статус еще носит "экспериментальный". Скоро SBCL пополнится полноценно еще одной платформой.

http://prdownloads.sourceforge.net/sbcl/sbcl-0.9.17-x86-windows-binary.msi?do...

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

> "Встал первым" == "первым ассимилировал в себя кучу передовых идей".

Ну и? На тот момент эти идеи нафиг никому не упёрлись - вот и тапок нет. Что поделаешь, если до людей сразу не доходит, а только после нескольких десятков лет хождения по граблям... Так что вы это у себя спросите - почему же у лиспа до сих пор тапок нет ;)

> А ответы?

А-а-а-а.... чукча не читатель... Понятно ;)

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

Потому что он многим и не нужен. На постсоветском пространстве вообще натуральное хозяйство ещё очень даже в ходу... и это в 21-м веке. Что уж удивляться, что лисп многим не нужен... Мотыгой сподручнее ;)

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

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

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

> полноценной поддержки винды ещё не будет (хотя здесь чего об этом горевать?.. ;)

надеюсь, венда исдохнет намного раньше чем оно появицо.

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

> надеюсь, венда исдохнет намного раньше чем оно появицо.

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

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

Аха, давай. Жаль чё лисп бинари выполнябельные не делает :( А ещё фигня такая в cmucl - загрузил gtk-cells, фсио работает. Схрнил core. Загружаю с сохранённым, он при загрузке пытаецо компилить lambda, ругаецо, и потома "Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #xB7FB085C." Нушозанах?

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

А в clisp если в cells пытаешсё уникожий текст запихать в виджет, ругаецо "1103 невозможно отконвертировать к инородному типу FFI:UCHAR" хотя оный clisp компилен с поддержной уникода и в cmucl тоже самое работает. Вот ацтой!

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

> Аха, давай. Жаль чё лисп бинари выполнябельные не делает :(

gcl? ecl?

> А ещё фигня такая в cmucl -...

Извини, не помогу. Спроси в конфе cmucl-а, comp.lang.lisp или в fido7.ru.lisp

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

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

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

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

> А в clisp если в cells пытаешсё уникожий текст запихать в виджет, ругаецо "1103 невозможно отконвертировать к инородному типу FFI:UCHAR"

Да, ибо нет у cLisp FFI:UCHAR :) Отрапортуй баг в конфу cell-а ;)

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

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

Вот тут с тобой совершенно согласен. CMUCL и SBCL генерят "натив", при этом "впереди планеты всей" ;)

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

> gcl? ecl?

Дык оне вроде невполне?

> Извини, не помогу. Спроси в конфе cmucl-а, comp.lang.lisp или в fido7.ru.lisp

Да ничё, сам справлюсь. Это я так лисп ругаю.

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

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

Ну выделяют ведь, и этому есть причины, и есь следствия.

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

> Да, ибо нет у cLisp FFI:UCHAR :) Отрапортуй баг в конфу cell-а ;)

как так? А англицкие буквы как работают? С ими траблов нету.

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

> Вот тут с тобой совершенно согласен. CMUCL и SBCL генерят "натив", при этом "впереди планеты всей" ;)

Выполнябельник всё-таки удобнее ИМХО. А ево-то и негенерят :(

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

> Я тут начял лисп ругать. Присоединяйся!

Чтобы _так_ ругать Лисп, надо его хорошо знать, а я его не знаю.

Но присоединюсь, конечно: СКОБАЧКИ САСУТ!!!!

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

> SBCL тоже делает, но размер... ;)

Причём ограничение принципиальное видимо. На случяй eval. Хотелось бы иметь возможнось скомпилить минимальный бинарь без возможности eval в ём ибо всёодно невсегда нужный.

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

> как так? А англицкие буквы как работают? С ими траблов нету.

А, это я прогнал - извини. ffi:uchar есть, но это не unicode char, а unsigned char - разные вещи :)

По cLisp смотри Impnotes - там очень неплохо описываются все его особенности. FFI тоже хорошо расписан :)

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