Здравствуйте, Master Yoda, Вы писали:
MY>Здравствуйте, Eugene Beschastnov, Вы писали:
EB>>Прошу прощения, но Ваш начальный вопрос был: MY>>>А разве коммерческий софт когда-то разрабатывался всерьез на Lisp-е или Smalltalk-е?
MY>Всерьез — означает широкомасштабно, повсеместно, распространенно. Если так было, то я спорить не буду, я не утвеждал это и даже спечиально оговорился, что могу ошибаться.
Странное использование слова "всерьёз" (я воспринял Ваш вопрос, как "разрабатывался ли когда-нибудь серьёзный коммерческий софт на Smalltalk" — и отвечал именно на этот вопрос), ну да ладно.
MY>Эта не подмена темы. Вы начали перечислять продукты созданные на Smalltalk с тем уклоном (как мне по крайней мере показалось), что он ничуть не менее популярный, чем Java или C#.
Вам показалось. Глупо спорить с очевидными вещами — а то, что Smalltalk менее популярен, чем Java или C# — это очевидно.
MY>Я ответил, что так не считаю. Если я вас неправильно понял (хотя мне так не кажется), то извините.
EB>>1) Как здесь уже говорили, Smalltalk слишком хорош для "среднего кодера". Он предоставляет очень большую свободу — и, как следствие, требует большой самодисциплины.
MY>Вот с этого и надо начинать, а не перечислять достоинства Smalltalk. Я же не спорю с тем, что это замечательный язык, что для него есть много библиотек, что у вас сложилось хорошее коммьюнити и т.д. и т.п.. Я просто не могу с этим спорить, поскольку не сталкивался с этим языком. Поэтому охотно вам верю.
Чтобы устранить недопонимание: я не "перечислял достоинства Smalltalk", а попытался более-менее объективно (но на основе собственного опыта) сравнить его с Java. Я же не виноват, что он по четырём пунктам лучше, по двум — наравне, и нет ни одного пункта, по которому он был бы хуже .
Кстати, забыл еще один критерий для сравнения — скорость. По моему опыту, интегральная скорость работы программ на Smalltalk примерно равна скорости работы программ на Java. В чём-то Java быстрее, в чём-то — Smalltalk, но в среднем — примерно наравне. Я сейчас говорю про VisualWorks, потому что диалект в данном случаем имеет очень большое значение — например, Squeak работает заметно медленнее.
MY>Лейтмотив моих рассуждений — пользуются тем языком, который лучше всего вписывается в текущую ситуацию в коммерческой разработке софта. Это включает в себя и уровень программистов в этой отрасли (и многие другие факторы). А под последними вашими словами сам готов подписаться.
Опять же —
Здравствуйте, Eugene Beschastnov, Вы писали:
VD>>... Смолток практически ничего не дал миру кроме ООП которое и без Смолток выше крыши в мэйснтирме.
EB>Не позорился бы, а? http://www.smalltalk.ru/articles/smalltalk.html
Не выпендиривался бы ты, а сказал с чем не согласен. Если конечно есть что сказать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Лисп (если не брать эксперементальные клоны) это не типизированный язык и до стадии выполнения у него попросту не хватает информации о типах чтобы породить статический код. По этому в Лиспе используют методы динамической компиляции, а это и есть JIT-компиляция.
Неправда. Common Lisp практически единственный современный диалект Lisp-а. У него статическая типизация есть! И он далеко не 'эксперементальный клон'. Соотвественно есть быстые компиляторы. А вот JIT для Lispа AFAIK нет.
M>>Анонимные функции, макросы, карринг, метапрограммирование, легковесные процессы... Да даже сборщик мусора появился на минимум десять-двадцать лет позже Лиспа и Смоллтолка (и это в Java, про C# молчу).
VD>Ну, ты загнул.
Может мне в маркетологи податься..
M>> Возможности замены работающих модулей на лету до сих пор нет нигде, кроме тех же Лиспа и Эрланга (ну и наверняка других, не менее экзотических языков).
VD>Серьезно? А мужики то не знали и даже на VB5 это делали.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, DenisY, Вы писали:
DY>>О чем ты? google common lisp compiler
VD>Ну, ты почитай свои ссылки. А потом... и вопросов не возникнет. Лисп (если не брать эксперементальные клоны) это не типизированный язык и до стадии выполнения у него попросту не хватает информации о типах чтобы породить статический код. По этому в Лиспе используют методы динамической компиляции, а это и есть JIT-компиляция.
Пример CMUCL — фраза native code compiler надеюсь не нуждается в переводе?
VladD2, есть подозрение, что твоё мнение о лиспе (и, возможно, не только) основано не на реальных данных о нём.
Здравствуйте, IB, Вы писали:
IB>Во-первых, не мне неважно, а вообще не важно, а во-вторых, упомянул не я...
Во-первых, не вообще не важно, а тебе не важно, так как за всех говорить ты не можешь. А упомянул правда не ты. Но это неважно , так как разговор на эту тему ты поддерживаешь.
IB>Упомянуто же это было к тому, что не смотря на то, что в данном аспекте, причины популярности не существенны, популярность — это более чем объективный критерий удобства той или иной технологии.
Это не правда. Bullshit.
G>> Ничего нового и интересного ты не сказал — и так все знают, что Java популярнее Lisp. IB>Если бы ты был более внимателен, то смог бы понять, что я говорю не об этом, уж с тем что Java популярнее чем Lisp, слава байту, не споришь даже ты..
Хе, если бы ты писал более доходчиво, не составило бы труда понять, о чем ты. А то я до сих пор не понимаю. А с объективными фактами я, слава богу, спорить не имею обыкновения.
IB>Ты занимаешься немного другим, не споря против самого факта, ты пытаешься принизить его значимость, несколько передергивая, что не очень корректно в форуме, где главный предмет обсуждения, как ты верно заметил, технологии.
Докажи. Где я передергиваю.
G>> Здесь не маркетинговая тусовка, и главный предмет обсуждения — технологии, а не объемы продаж и сегментации рынков. IB>Конечно, поэтому давай обсуждать тьехнологии, а не кто, что нового сказал...
Давай. Пока, правда, ты почему-то стратегический маркетинг обсуждаешь — наверно о LISP со Smalltalk сказать нечего. Ок, нивапрос, поговорим о маркетинге.
G>>Это тоже многим известно, что происходит при промышленном применении технологий, тут не только пионеры сидят. IB>Кто бы сомневался, конечно не пионеры, однако некоторые передергивают как дети..
А некоторые бросаются словами налево-направо, как пионеры. Покажи где я передергиваю. Подсказка: обыкновенно для этого показывают на ошибку в рассуждениях, и контраргументы приводят. А "как дети" и "детский сад" обычно говорят, когда сказать нечего.
G>> Рассуждали бы все таким образом (популярность, и неважно в силу каких причин), как ты описываешь — все бы сейчас до сих пор писали на макроассемблере и автокоде. IB>Почему популярность определенной технологии на каком-то отрезке времени, для определенного класса задачь, должна исключить появление более удобных технологий в последствии?
Жизненный цикл технологии несколько сложнее, чем тебе кажется. Очень мало технологий становится популярны сразу после появления (они не друг за другом появляются, как тебе кажется) — такого практически никогда не бывает. На практике обычная ситуация — перспективные в будущем технологии известны и развиваются до того, как на определеном текущем отрезке времени получает популярность технология Х. Примеров можно привести массу, один из них — Windows NT и Win 95. Маркетолог сказал бы, что у технологии NT, не смотря на то, что она появилась раньше, "время выхода на плато продуктивности" существенно больше, чем у 95. Однако, в перспективе 5-7 лет NT вытеснит 95.
Более того. Первое применение новой технологии практически всегда заканчивается провалом, если это технология существенно отличается от предыдущих. Оконные интерфейсы и мышка были изобретены в 60-х. Ксерокс пытался продавать свои рабочие станции на этом принципе — провал. Apple LISA — провал. И только Макинтош — успех. Дальше, правда, еще больше бабок забрала Windows 3.1 (технология вышла на "плато продуктивности").
Для людей, которые занимаются стратегическим маркетингом в области хай-тек, это прописная истина, а не предмет дискуссий. Термин "хайп-цикл" ничего тебе не говорит? Google "hipe-cycle". Это в качестве ликбеза по теме "популярности" и "технологий", и по твоему вопросу, почитай. Да, ликбеза. Маркетинг в хайтеке — очень непростая штука, это кажется только по началу, что ты все знаешь.
G>>Замечательно. Согласен. IB>Вот и отличненько, тогда впредь, когда будешь рассуждать об "удобстве" некоей технологии, не забудь упомянуть класс здадачь, где эта технология демонстрирует себя во всем блеске..
А я не рассуждаю об удобстве. Ты меня с кем-то путаешь. Я устал наблюдать в десятый раз одну и ту же картину — когда людям сказать нечего, а очень хочется, при этом по предмету разговора они уверены только в одном — что они об этом предмете толком ничего не знают. Из этого они делают вывод, что предмет разговора — непопулярен, и тут изумленная публика выясняет, что оказывается, сказать в этой ситуации можно очень даже много .
G>> Так давай не и будем, не разбираясь в технологиях (LISP/Smalltalk), c умным видом говорить об их удобстве или неудобстве, высасывая аргументы из пальца ("популярность"). IB>Я согласный, убирай умный вид и прекращай сосать из пальца, а я пойду с лиспом разбираться..
Я тоже согласный. Тока с одним условием — ты тоже не забудь убрать умный вид, ну и палчик тоже не соси, мы ведь тут взрослые дяди, правильно?
Здравствуйте, Gaperton, Вы писали:
G>Во-первых, не вообще не важно, а тебе не важно, так как за всех говорить ты не можешь.
За всех не могу, однако и ты за меня тоже не можешь... , поэтому именно вообще не важно, естественно, если мы все еще говорим об удобстве.
G>А упомянул правда не ты. Но это неважно , так как разговор на эту тему ты поддерживаешь.
Я пытаюсь поддержать разговор на тему является ли популярность продукта критерием его "удобства" при решении определенного класса задач.
G>Это не правда. Bullshit.
Вот собственно на этом твоя аргументация и закончилась, конструктивненько, не правдали?
G>Хе, если бы ты писал более доходчиво, не составило бы труда понять, о чем ты.
Да господи, так надо было просто спросить, а не упражняться в ехидстве... Собственно о чем речь, я напомнил тебе выше.
G>Докажи. Где я передергиваю.
Легко. Вообще, можно было бы твои сообщения по данному поводу подробненько разобрать, но у нас же технический форум, а не ликбез по прикладной софистике.. Но вот характерный пример, свою аргументацию ты строишь вообще на абстрактных аналогиях уходя даже от программирования:
Есть масса непопулярных технологий, который существенно удобнее и функциональнее своих популярных аналогов. Причем, практически в любой отрасли.
Мои же посылки отвергаешь на основании того, что я якобы не разбираюсь в какой-то конкретной технологии.
Так будь ты последователен, в конце-концов. Либо мы рассуждаем об абстрактном соотношении "популярность"/"удобство", тогда причем тут знание конкретной технологии, либо твоя аналогия полностью некорректна.
G> Пока, правда, ты почему-то стратегический маркетинг обсуждаешь...
То, что я обсуждаю, я привел выше, а ты почему-то соскочить все время пытаешься, сейчас вот на маркетинг понесло..
G> А "как дети" и "детский сад" обычно говорят, когда сказать нечего.
Ага, а так же пытаются ставить под сомнение квалификацию оппонента, что, кстати, правилами форума запрещено...
IB>>Почему популярность определенной технологии на каком-то отрезке времени, для определенного класса задачь, должна исключить появление более удобных технологий в последствии? G> Жизненный цикл технологии несколько сложнее, чем тебе кажется.
Тоже вот, ловкий нырок в сторону — вместо ответа на прямо поставленый вопрос, нарываешься на лекцию о маркетинге...
Все что ты написал очень интересно, не смотря на то, что так же всем известно (большие дяди, в конце концов ) и в целом верно, только вот ни в чем не противоречит моим словам...
G> На практике обычная ситуация — перспективные в будущем технологии известны и развиваются до того, как на определеном текущем отрезке времени получает популярность технология Х. Примеров можно привести массу, один из них — Windows NT и Win 95. Маркетолог сказал бы, что у технологии NT, не смотря на то, что она появилась раньше, "время выхода на плато продуктивности" существенно больше, чем у 95. Однако, в перспективе 5-7 лет NT вытеснит 95.
Гут, все верно. Далее я утверждаю, что раз технология X (95) была более популярна чем технология Y (NT) для решения ряда задач, на определенном отрезке времени, значит на этом отрезке времени для решения этих задач использовать X, в большинстве случаев, было "удобнее", чем Y.
G>Для людей, которые занимаются стратегическим маркетингом в области хай-тек, это прописная истина, а не предмет дискуссий.
Вот я и не понимаю, к чему ты это привел..
G>Маркетинг в хайтеке — очень непростая штука, это кажется только по началу, что ты все знаешь.
Раз уж мы съехали на маркетинг, то в контексте нашей дскуссии важно знать одно — если маркетинг успешный и технология стала популярной, значит эта технология "удобна".
G>А я не рассуждаю об удобстве. Ты меня с кем-то путаешь.
"Каким образом тот факт, что большинство пишет на Java, C++, Delphi, доказывает, что на LISP и Smalltalk неудобно писать те приложения, которые на них были написаны?"
...
"Есть масса непопулярных технологий, который существенно удобнее и функциональнее своих популярных аналогов."
Кто здесь? Собственно первая цитата и сподвигла меня поправить точность "твоей" формулировки, с чего и начался наш задушевный разговор..
G> Я устал наблюдать в десятый раз одну и ту же картину — когда людям сказать нечего, а очень хочется, при этом по предмету разговора они уверены только в одном — что они об этом предмете толком ничего не знают.
Да, ты прав. Душераздирающее зрелище, наверное поэтому они все время пытаются съехать с неудобной темы?
G> Из этого они делают вывод, что предмет разговора — непопулярен, и тут изумленная публика выясняет, что оказывается, сказать в этой ситуации можно очень даже много .
Конечно, позволю только себе напомнить, во избежании очередного отклонения от темы, что мы разговариваем не об абсолютной популярности или не популярности той или иной технологии а о "популярность как критерий удобства".
G> Тока с одним условием — ты тоже не забудь убрать умный вид, ну и палчик тоже не соси, мы ведь тут взрослые дяди, правильно?
Дык, я этим и так не грешу, на Котлера не ссылаюсь, умными терминами не разбрасываюсь, авторитетом не давлю, так что теперь твоя очередь.. Да, палец тоже убери..
Is dynamically typed, but with optional type declarations that can improve efficiency.
_> Соотвественно есть быстые компиляторы. А вот JIT для Lispа AFAIK нет.
Неможет динамически типизированный язык быть заранее на 100% откомпилирован. Темболее не может быть откомпилирован язык который может в рантайме порождать и выполнять макросы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Пример CMUCL — фраза native code compiler надеюсь не нуждается в переводе?
Это как раз пример эксперементов. Читаем во превых строках:
...It mainly conforms to the ANSI Common Lisp standard... a sophisticated native-code compiler which is capable of powerful type inferences, and generates code competitive in speed with C compilers.
Вывод типов и статическая компиляция резко убивают некоторые особенности Лиспа (динамическую генерацию и исполнения кода).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
...
Q: How do I compile my Lisp program to an executable?
A: CMUCL does not support delivery as an executable. If this bothers you, note that this is also the case of most other programming language implementations: for example Sun's java implementation requires a bundle of class files.
...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Возвращаясь к отправной точке — какие возможности мы потеряли, перейдя с Lisp/Smalltalk на всякие VB/Delphi/C++? а потом на всякие Java/C# и т.д., и какие возможности теперь заново изобретают (в худших формах) в этих новых "язвках"?
Что потеряли:
— возможности метапрограммирования (используя тот же язык и ту же парадигму программирования)
— простоту языков, "отсутствие" синтаксиса (сравните количество ключевых слов в Smalltalk и Java/C#/C++)
— стройность концепции языка (чистый ООП в Smalltalk)
— динамическую типизацию и Block Closure (на мой взгляд это очень важно)
Все эти взаимосвязанные между собой пункты позволяют значительно легче "объяснять свою идеи компьютеру" на более абстрактном уровне, а не в терминах Byte & Integer. Так "отсутствие" синтаксиса позволяет при необходимости написать и использовать свой DSL.
Что "изобретают":
— generics / препроцессоры
— кодогенерация
— DSL с использованием XML
— новые ключевые слова в языках
— делегаты
Наверное, много чего еще можно добавить...
P.S. И почему Smalltalk считается экзотическим языком? Тот же ООП только в более ярко выраженной форме. Поменьше точек и скобок, плюс вызов метода немного иначе выглядит, а так все принципы те же что и в Java/C#
Java:
foo.findText(text, bigText);
for (int i=0; i<10; i++) {
foo.go(i)
}
Smalltalk:
foo findText: text in: bigText.
0 to: 9 do: [:i | foo go: i].
Здравствуйте, FR, Вы писали:
FR>>>Я думаю что на современных языках можно решить любую задачу которую можно решить на лиспе, вопрос только в удобстве и производительности пишущего, ну еще может в красоте решения. AVC>>Вот и интересно, какова разница (и для каких задач, и почему), и в чью пользу? AVC>>Меня не слишком интересуют "остроумные" высказывания (в этом топике они есть) относительно машины Тьюринга, Брейнфака, задачи останова и т.п. FR>Я думаю высококвалифицированному программисту при решении большого класса нетривиальных задач лисп и ему подобные могут помощь сильно ускорить и упростить разработку.
Ответ, может быть, и точный, но ясным его не назовешь.
Каких-таких "нетривиальных задач"?
Есть ли какой-нибудь пример?
Кивок на требуемую высокую квалификацию (жирным шрифтом), видимо, должен означать: "ну что тебе объяснять — все равно не поймешь"?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, VladD2, Вы писали:
VD>Это как раз пример эксперементов. Читаем во превых строках: VD>
...It mainly conforms to the ANSI Common Lisp standard... a sophisticated native-code compiler which is capable of powerful type inferences, and generates code competitive in speed with C compilers.
VD>Вывод типов и статическая компиляция резко убивают некоторые особенности Лиспа (динамическую генерацию и исполнения кода).
Да не же — типы есть в стандарте Common Lisp. И mainly conforms совсем не-за типов.
Is dynamically typed, but with optional type declarations that can improve efficiency.
VD>Неможет динамически типизированный язык быть заранее на 100% откомпилирован. Темболее не может быть откомпилирован язык который может в рантайме порождать и выполнять макросы.
Очень интересно, что значит 100% . У меня программа скомпилированная Intel C++ компилятором выполняется более чем в 2 раза быстрее ,чем скомпилированная MSVS 6.0. Значит ли это что msvs компилирует не на 100%? Проверки типов — ну будут они в коде, который нагенерирует компилятор Lisp'а. Равно как и яве при приведение типа от Object, как и dynamic_cast в C++. Этих проверок можно избежат если объявить типы некоторых переменных(например аргументов ф-ии) — остальные типы компилятор выведет сам.
VD> Темболее не может быть откомпилирован язык который может в рантайме порождать и выполнять макросы.
Выполнять в рантайм нагенерированные макросы это не очень частое явление даже в Lisp. Например в некоторых коммерческих реализациях забанены compile и eval в продукте, который распространяет пользователь компилятора по соображениям лицензирования — что бы не перепродалали компилятор.
IFAIK Emacs Lisp и AutoLISP создавались до CL. Их сложно назвать современными диалектами по многим причинам — хотя бы отсутствие лексических переменных чего стоим.
...
VD>Q: How do I compile my Lisp program to an executable?
VD>A: CMUCL does not support delivery as an executable. If this bothers you, note that this is also the case of most other programming language implementations: for example Sun's java implementation requires a bundle of class files.
VD>...
На самом деле это обозначает, что cmucl не умеет генерировать ELF заголовки (заголовок исполнительного файла в *nix)
Просто скомпированный образ загружает маленькая C программа. Но функции внутри образа скомпилированы в маш код.
Здравствуйте, AVC, Вы писали:
FR>>Я думаю высококвалифицированному программисту при решении большого класса нетривиальных задач лисп и ему подобные могут помощь сильно ускорить и упростить разработку.
AVC>Ответ, может быть, и точный, но ясным его не назовешь. AVC>Каких-таких "нетривиальных задач"? AVC>Есть ли какой-нибудь пример? AVC>Кивок на требуемую высокую квалификацию (жирным шрифтом), видимо, должен означать: "ну что тебе объяснять — все равно не поймешь"?
Ну я сам тоже не являюсь высококвалифицированным программистом на лиспе
Просто хотел донести такую мысль что лисп и ему подобные это инструменты для одиночек, что освоить их тяжело, но если освоишь то можешь решать многие задачи намного быстрее.
Здравствуйте, little_alex, Вы писали:
_>Очень интересно, что значит 100% . У меня программа скомпилированная Intel C++ компилятором выполняется более чем в 2 раза быстрее ,чем скомпилированная MSVS 6.0. Значит ли это что msvs компилирует не на 100%? Проверки типов — ну будут они в коде, который нагенерирует компилятор Lisp'а. Равно как и яве при приведение типа от Object, как и dynamic_cast в C++. Этих проверок можно избежат если объявить типы некоторых переменных(например аргументов ф-ии) — остальные типы компилятор выведет сам.
Извнини, но поднятие твоего уровня знаний в области компиляции мне не интересно. Копай в сторону статической и динамической типизации, обязательной и не обязатльной спецификации типов, вывода типов, динамической компиляции. Вся эта информация легко находится через Википедию.
Мне же эти разговры не нитересны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
Пока, правда, ты почему-то стратегический маркетинг обсуждаешь — наверно о LISP со Smalltalk сказать нечего. Ок, нивапрос, поговорим о маркетинге.
.
, поэтому именно вообще не важно, естественно, если мы все еще говорим об удобстве.
Мы уже победили, просто это еще не так заметно...
