Здравствуйте, eao197, Вы писали:
E>Попытка не защитана: заливают катки и играют в хокей разные люди.
за выбором средств контрацепции умные люди тоже обращаются к профессионалам
а на самом деле, разные люди или одни и те же — это никакого значения не имеет
Здравствуйте, Дарней, Вы писали:
E>>Попытка не защитана: заливают катки и играют в хокей разные люди.
Д>за выбором средств контрацепции умные люди тоже обращаются к профессионалам Д>а на самом деле, разные люди или одни и те же — это никакого значения не имеет
Тем не менее профессионалы всегда предоставляют выбор из нескольких средств (если паталогий нет) из которых выбирать тебе самому приходится, на основании собственных знаний и здравого смысла. Причем здесь все равно требуется "понимание" того что, как и для чего ты делаешь.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Тем не менее профессионалы всегда предоставляют выбор из нескольких средств (если паталогий нет) из которых выбирать тебе самому приходится, на основании собственных знаний и здравого смысла. Причем здесь все равно требуется "понимание" того что, как и для чего ты делаешь.
Здравствуйте, Дарней, Вы писали:
E>>Тем не менее профессионалы всегда предоставляют выбор из нескольких средств (если паталогий нет) из которых выбирать тебе самому приходится, на основании собственных знаний и здравого смысла. Причем здесь все равно требуется "понимание" того что, как и для чего ты делаешь.
Д>а что ты этим доказать то хочешь?
То, что ты не прав, говоря:
Программирование — это работа человека, который создает, а не что-то там "понимает"
Программирование -- это работа человека, который понимает, что он делает, как он это делает и, главное, для чего он это делает. И на основании этого понимания он как раз и создает результат. И степень понимания, имхо, определяет уровень результата (помимо прочих составляющих).
Вот как-то так. По крайней мере сейчас, пока программисты еще в кодирующих обезъян не превратились.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Скажу честно. Мне было бы страшно пользоваться программами, если бы Lisp стал мэйнстримовым языком.
V>Если пофантазировать на эту тему, то положение должно было быть не таким как сейчас V>Т.е. и программистов меньше, и сами программы короче.
Ну в общем — да. Говоря о майнстриме я подразумеваю э... толпы... эмм... "индусов", лабающих окошки на Lisp-Delphi
<< Под музыку: Enigma — The Rivers of Belief (the retutning silence) >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Фиг его знает. Значит, свой диплом в 93-м я писал под влиянием очень малоизвестного Smalltalk, о котором было, правда, было написано в книжке где-то 91-го года издания, что и сподвигло меня на поиски.
Под влияением? А что же ты не использовал его?
ГВ> А русскую документацию на BC++ 2.0 в 92-м распечатывал во сне. Место действия — Севастополь. Кстати, вот этот вот словарь
появился как раз в то же время, в 92-93 (обрати внимание на упоминание C++).
ГВ>В том же 93-м мне предложили работу как раз на C++. Контора работала на германцев, кажись. Так что, я бы не стал утверждать, что C++ не был известен или был уделом единиц. Паскалем же нередко пользовались в силу того, что он значимо быстрее компилировался на распространённых тогда машинах (286/1M/5.25+3.5/типичный объём винта не помню). Хотя и 386-е уже были в достаточном количестве, чтобы эта проблема не была большой.
Ну, то есть ты подтверждашь, что как раз 1993 год стал тем самым годом когда в твою жизь реально вошел С++?
Надеюсь, ты понимаешь, что если ты был бы даже самым средним программистом не ищущим ничего новго, то все равно ситуацию никак нельзя было назвать популярность, а скрее можно было бы оценить как "язык начал набирать популярность"?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ГВ>>Фиг его знает. Значит, свой диплом в 93-м я писал под влиянием очень малоизвестного Smalltalk, о котором было, правда, было написано в книжке где-то 91-го года издания, что и сподвигло меня на поиски.
VD>Под влияением? А что же ты не использовал его?
У меня диплом был под ОС, на которой не было SmallTalk. Есть такая ось — PICK. Со встроенной СУБД.
ГВ>>В том же 93-м мне предложили работу как раз на C++. [...]
VD>Ну, то есть ты подтверждашь, что как раз 1993 год стал тем самым годом когда в твою жизь реально вошел С++?
Мог войти и тогда правильнее было бы говорить о 92-м. На самом деле плрофессионально я стал им пользоваться примерно с 95-го (Watcom C++ 10.0).
VD>Надеюсь, ты понимаешь, что если ты был бы даже самым средним программистом не ищущим ничего новго, то все равно ситуацию никак нельзя было назвать популярность, а скрее можно было бы оценить как "язык начал набирать популярность"?
В СССР — безусловно. Но в любом случае это не похоже на: "пользовались только единицы".
<< Под музыку: Enigma — The Rivers of Belief (the retutning silence) >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>В СССР — безусловно. Но в любом случае это не похоже на: "пользовались только единицы".
ОК. Тезис про едениц снимаем. Но ты согласен, что рельано рост популярности С++ только начался в 1993-ем, и меряться перисоми с ним в то время было просто не корректно. Вот к 1998-ому, другое дело... Но к 1998-му Смолтолком уже пахло только в IBM.
А ведь язык то 1976-го года. Ему бы немного ближе к народу быть и был бы супер бестселлером. А так... усего лишь легендарный язык пошлого.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
eao197,
E>Вообще-то проблем с заменой кода я особых не вижу. А вот замена структур данных, которая может производится в момент замены кода -- вот это да, тот еще подарочек. Поэтому мне кажется, что REPL хорошо использовать для bug fixing-а в on-line.
Разумная точка зрения. Тем не менее она обусловлена несовершенством инструментов:
Me = Jay Nelson, лиспер с 15-летним стажем вовлечённый в проект на С.
CW = его коллега, имеющий больший опыт на программирования на C (coworker)
Me: "Ok, show me how to figure out what is wrong."
CW: "Fire up the debugger."
Me: "Good, I know what that is... Hmm, what's the value of this thing all in caps?"
CW: "It can't tell you, that's a macro. It's not part of the program."
Me: "?? How can that be a macro if it never executes? It sounds like an editor expansion that somehow escaped from from its environment."
Me: "Ok, let me create a new variable and evaluate the expression it represents."
CW: "You can't create a new variable silly."
Me: "?? Ok, step into the function. Wait, I see... the incoming arg is wrong. Let's step back and change it."
CW: "No can do."
Me: "?? Ok, mentally I'll assume it is changed and... oh I see the problem. Let's change this function and continue!"
CW: "What planet did you come from? This is just a debugger!"
Me: "Isn't a debugger the thing you use to write code? You type it in to the listener and you modify it in the debugger. When you're done you dump it in an editor using the pretty printer. How do you guys write code?"
Информация, полученная из дебаггера — это обратная связь. И время на получение этой информации ("время отклика") часто слишком велико. Вспомни хотя бы написание ГУЯ, серверов требующих рестарт, вычислений с большими чёрными ящиками.
Проблема не в том, что дебаггер плохой, а проблема в самом дебаггере. Он не нужен, если есть REPL (либо можно считать что REPL=debugger, тут уже чисто терминология, важно то что "время отклика" чрезвычайно мало).
E> А вот upgrade лучше выполнять рестартом -- проще и надежнее.
Опять же разумное утверждение, но это далеко не всегда лучший выбор обусловленный несовершенством инструментов. Такое положение дел плачевно сказывается на скорости порождает таких уродцев, что за голову хватаешься.
Реальный пример: ребята писали веб-приложение. Чтобы узнать, каков результат чьей-то правки сервлета или конфига, нужно было перегрузить сервер. Веб-приложение установили клиенту, потребовалось расширение функционала. Поскольку теперь перегружать сервер стало недопустимым, код стал писаться прямо в JSP (обновление JSP-форм возможно без рестарта сервера). Думаю, не нужно говорить, что за уродец в конечном итоге получился.
E> И вообще, оказывается, что принцип "fail fast, restart quickly" замечательно работает для обновления систем 24x7 -- быстрый рестарт, в момент которого происходит переход на новую версию ПО, оказывается всего лишь частным случаем общей схемы поведения системы.
Ну такой подход имеет место быть, и это конечно лучше, чем "full restart", но он работает при соблюдении 2х условий:
1. Гранулы должны быть достаточно мелкими.
2. Гранулы должны быть независимы.
"Гранулы" — это кусочки системы, которые допускают горячую замену. Т.е. если мы находимся в условиях ООП, то вот примеры:
Имплементация какого-нибудь интерфейса — это одна гранула, замена её возможна, но необходимо ручками отписать переход и сконвертировать состояние. Сложность этой операции варьируется в зависимости от многих факторов.
Базовый интерфейс — это другая гранула, от которой зависит почти всё, поэтому горячая замена этой гранулы влечёт "full restart".
Здравствуйте, VladD2, Вы писали:
ГВ>>В СССР — безусловно. Но в любом случае это не похоже на: "пользовались только единицы".
VD>ОК. Тезис про едениц снимаем. Но ты согласен, что рельано рост популярности С++ только начался в 1993-ем, и меряться перисоми с ним в то время было просто не корректно.
Опять таки, что считать "реальным началом роста популярности"? В принципе, в СССР какую-никакую популярность C++ стал завоёвывать примерно годом раньше. В 93-м я всего лишь встретился в Севастополе с его стабильным коммерческим использованием. Значит, "популярность" для этих конкретных деятелей C++ обрёл никак не позже, чем за полгода-год до этого.
Занимался ли кто-нибудь коммерческим использованием SmallTalk в то время? Ну, вокруг меня таких не было. Хотя в мире, похоже, обстановка была немного иная. Посмотри на http://www.cincomsmalltalk.com/ в разделе блогов и http://www.smalltalk.ru/ Да и сам факт того, что первое издание Буча было проиллюстрировано примерами на SmallTalk в числе прочих, хоть о чём-то, да говорит. Кстати, как и то, что Rational RequisittePro, который входит в состав Rational Suite, написан на SmallTalk.
VD>Вот к 1998-ому, другое дело... Но к 1998-му Смолтолком уже пахло только в IBM.
Сравнить популярность мы без репрезентативной статистики не сможем. Я, например, не склонен обобщать тенденции отечественного "майнстрима" (мутный поток веб-дизайна и складского учёта) на весь мир. Скажу, что в 98-м вокруг меня также не было тех, кто использовал SmallTalk в коммерческих разработках.
VD>А ведь язык то 1976-го года.
71-го или 80-го, смотря, как считать. http://ru.smalltalk.wikia.com/wiki/История_Smalltalk
VD>Ему бы немного ближе к народу быть и был бы супер бестселлером. А так... усего лишь легендарный язык пошлого.
Win2K тут где-то правильно написал, что, мол, не хрен "близостью к народу" хорошую вещь портить. Те, для чьих задач ST был оправдан и уместен, его изучили, купили и пользовались (в ФИДО какие-то разговоры проскакивали время от времени, если не путаю). Ну а для очередного, 8192-го клона бухгалтерии — нафига козе баян?
Насчёт "прошлого" ты тоже загнул. SmallTalk вполне себе жив, энтузиастов хватает.
<< Под музыку: Gregorian — Moment Of Peace >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
<...интересный фрагмент про отладку поскипан...>
LCR>Информация, полученная из дебаггера — это обратная связь. И время на получение этой информации ("время отклика") часто слишком велико. Вспомни хотя бы написание ГУЯ, серверов требующих рестарт, вычислений с большими чёрными ящиками.
LCR>Проблема не в том, что дебаггер плохой, а проблема в самом дебаггере. Он не нужен, если есть REPL (либо можно считать что REPL=debugger, тут уже чисто терминология, важно то что "время отклика" чрезвычайно мало).
Вообще-то я не про отладку говорил. У меня было несколько случаев, когда хотелось произвести горячую замену кода в C++ программе-сервере, без ее останова. Например, в одном случае один из потоков транзакций застопорился, причем общий мониторинг показывал, что система функционирует нормально. Но более детализированная мониторинговая информация показала, что один из счетчиков, который показывал количество одновременно обрабатываемых транзакций именно на этом потоке транзакций, имеет слишком большое значение -- порядка 4 миллиардов. Из-за этого, каждая очередная транзакция откладывалась, в ожидании, когда общее количество транзакций снизится до нужного предела. Ошибка была тривиальной -- счетчик был unsigned int и в одной очень экзотической ситуации он переходил через ноль. В этом бы случае просто выполнить горячую замену проблемного кода и все, не нужно было бы сервер останавливать.
Здесь, в общем-то и дебаггер ни при чем. Да и пользы от него не много -- бесполезно пытаться отлаживать production server под нагрузкой в десятки транзакций в секунду. А вот выполнить hot fix было бы здорово.
E>> А вот upgrade лучше выполнять рестартом -- проще и надежнее. LCR>Опять же разумное утверждение, но это далеко не всегда лучший выбор обусловленный несовершенством инструментов. Такое положение дел плачевно сказывается на скорости порождает таких уродцев, что за голову хватаешься.
LCR>Реальный пример: ребята писали веб-приложение. Чтобы узнать, каков результат чьей-то правки сервлета или конфига, нужно было перегрузить сервер. Веб-приложение установили клиенту, потребовалось расширение функционала. Поскольку теперь перегружать сервер стало недопустимым, код стал писаться прямо в JSP (обновление JSP-форм возможно без рестарта сервера). Думаю, не нужно говорить, что за уродец в конечном итоге получился.
Полностью согласен. Сам через такое проходил, на C++ только.
Вообще оказалось, что создавать программы из компонентов, которые позволяют делать динамическое переконфигурирование во время работы очень не просто. Гораздо проще разбивать систему на мелкие компоненты, каждый из которых допускает рестарт. Вероятно, здесь я собственным опытом дошел до тех принципов, которыми руководствовались создатели Erlang-а и системы на его основе.
LCR>Ну такой подход имеет место быть, и это конечно лучше, чем "full restart", но он работает при соблюдении 2х условий: LCR>1. Гранулы должны быть достаточно мелкими. LCR>2. Гранулы должны быть независимы.
LCR>"Гранулы" — это кусочки системы, которые допускают горячую замену. Т.е. если мы находимся в условиях ООП, то вот примеры:
LCR>Имплементация какого-нибудь интерфейса — это одна гранула, замена её возможна, но необходимо ручками отписать переход и сконвертировать состояние. Сложность этой операции варьируется в зависимости от многих факторов.
LCR>Базовый интерфейс — это другая гранула, от которой зависит почти всё, поэтому горячая замена этой гранулы влечёт "full restart".
Опять же, полностью согласен.
Но я говорил о более крупных компонентах, о целых подсистемах. Например, при использовании созданных с помощью SObjectizer
систем нужно постоянно делать выбор -- формировать ли один процесс из нескольких коопераций агентов или же разносить их по разным процессам. В первом случае существенно упрощается администрирование и настройка приложения. Во втором же случае сложнее администрировать и мониторить процессы, появляются лишние накладные расходы на их взаимодействие, но зато повышается гибкость в переконфигурировании и обновлении версий, и повышается надежность, т.к. отдельная сбойная кооперация не роняет всю систему.
С учетом твоего замечания о гранулярности компонентов объектной системы на уровне классов/интерфейсов получается, что проблема связности является актуальной на разных уровнях абстракции.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197
E>С учетом твоего замечания о гранулярности компонентов объектной системы на уровне классов/интерфейсов получается, что проблема связности является актуальной на разных уровнях абстракции.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я, например, не склонен обобщать тенденции отечественного "майнстрима" (мутный поток веб-дизайна и складского учёта) на весь мир. Скажу, что в 98-м вокруг меня также не было тех, кто использовал SmallTalk в коммерческих разработках.
Хм. В 1993-ем никакого веб-дизайна не было. А "мутный поток складского учёта" был, есть и будет есть во всем мире всегда и везде. Это называется автоматизация бизнеса. Думаю, что это самый массовый потребитель ЯП.
И думаю, что на нас влиял западный опыт. Так что если бы Смолток действительно был бы популярен, то мы мимо него не прошли бы.
VD>>А ведь язык то 1976-го года.
ГВ>71-го или 80-го, смотря, как считать. http://ru.smalltalk.wikia.com/wiki/История_Smalltalk
ОК, не важно. Хотя как раз Smalltalk-76 стал известен в мире, если не ошибаюсь.
ГВ>Win2K тут где-то правильно написал, что, мол, не хрен "близостью к народу" хорошую вещь портить.
Хорошая вещь мало интересна окружающим если она кажется хорошей очень узкому кругу людей. Так что для окружающих эта вещь просто не является хорошей. А попытки навязать мнение о "хорошести" просто бессмысленны. Насильно мил не будешь. Проще сделать вещь хорошей для максимального числа людей.
ГВ> Те, для чьих задач ST был оправдан и уместен,
Согласен. Но было их не много. А сейчас уже совсем мало.
ГВ> его изучили, купили и пользовались (в ФИДО какие-то разговоры проскакивали время от времени, если не путаю). Ну а для очередного, 8192-го клона бухгалтерии — нафига козе баян?
Дык если чудо-средство позволит проще, быстрее и дешевле создать приемлемое по фунциональности, быстродействию и надежности решение, то создатель "клона" банально заработает денег.
ГВ>Насчёт "прошлого" ты тоже загнул. SmallTalk вполне себе жив, энтузиастов хватает.
Что я загнул? Энтузиастов хватает у J, K и даже Брэйнфака. Вопрос в их количестве и в том, что они полезного делают для общества.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ГВ>>71-го или 80-го, смотря, как считать. http://ru.smalltalk.wikia.com/wiki/История_Smalltalk
VD>ОК, не важно. Хотя как раз Smalltalk-76 стал известен в мире, если не ошибаюсь.
ST-76 отличался от ST-72 и на его основе сделан текущий ST-80. Обычно принято считать, что известен именно в мире ST стал в 81г. когда вышел августовский номер журнала Byte, посвященный ST.
Здравствуйте, VladD2, Вы писали:
ГВ>>Я, например, не склонен обобщать тенденции отечественного "майнстрима" (мутный поток веб-дизайна и складского учёта) на весь мир. Скажу, что в 98-м вокруг меня также не было тех, кто использовал SmallTalk в коммерческих разработках.
VD>Хм. В 1993-ем никакого веб-дизайна не было. А "мутный поток складского учёта" был, есть и будет есть во всем мире всегда и везде. Это называется автоматизация бизнеса. Думаю, что это самый массовый потребитель ЯП.
Ну и что? Он от этого "яснее" становится, что ли?
VD>И думаю, что на нас влиял западный опыт. Так что если бы Смолток действительно был бы популярен, то мы мимо него не прошли бы.
Это тема для отдельной дискуссии. Думаю, что здесь повлияла общая подготовка отечественных специалистов, среди которых профессиональных SmallTalk-еров было немного, как я понимаю, если они, конечно, вообще были. Впрочем, как и Lisp-еров.
ГВ>>Win2K тут где-то правильно написал, что, мол, не хрен "близостью к народу" хорошую вещь портить.
VD>Хорошая вещь мало интересна окружающим если она кажется хорошей очень узкому кругу людей. Так что для окружающих эта вещь просто не является хорошей. А попытки навязать мнение о "хорошести" просто бессмысленны. Насильно мил не будешь. Проще сделать вещь хорошей для максимального числа людей.
Да на здоровье, не считай ST "хорошим". Я считаю, что он вполне неплох, хотя мне и не нужен в данной точке пространства-времени. А за интересами "всех" не угонишься. Насильно мил не будешь, но и всем вокруг тоже не угодишь.
ГВ>> Те, для чьих задач ST был оправдан и уместен, VD>Согласен. Но было их не много. А сейчас уже совсем мало. ГВ>> его изучили, купили и пользовались (в ФИДО какие-то разговоры проскакивали время от времени, если не путаю). Ну а для очередного, 8192-го клона бухгалтерии — нафига козе баян? VD>Дык если чудо-средство позволит проще, быстрее и дешевле создать приемлемое по фунциональности, быстродействию и надежности решение, то создатель "клона" банально заработает денег.
Тут много факторов может быть. Прежде всего, об этом средстве нужно узнать, потом — оценить-примерить, потом — уговорить менеджмент, а уже потом — реализовывать. В случае с майнстримовыми тулами первые три фазы запросто исключаются.
А если если тул не майнстримовый, то... Думаю, что есть некая зависимость между самостоятельным использованием "необычного" тула и способностью найти нестандартную задачу вообще. Следовательно, могу предположить, что те, кто был вне майнстрима используемых тулов оказались вне "майнстрима задач". Говоря несколько экспрессивнее: SmallTalk-еры формочки не лабают.
ГВ>>Насчёт "прошлого" ты тоже загнул. SmallTalk вполне себе жив, энтузиастов хватает. VD>Что я загнул? Энтузиастов хватает у J, K и даже Брэйнфака. Вопрос в их количестве и в том, что они полезного делают для общества.
Они делают J, K и Brainfuck. Если это бесполезно для тебя или для массовых задач автоматизации бизнеса, то не стоит переносить сие отношение на всё общество в целом.
<< Под музыку: a-Ha — The swing of things >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
)
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Хотя в мире, похоже, обстановка была немного иная. Посмотри на http://www.cincomsmalltalk.com/ в разделе блогов и http://www.smalltalk.ru/ Да и сам факт того, что первое издание Буча было проиллюстрировано примерами на SmallTalk в числе прочих, хоть о чём-то, да говорит. Кстати, как и то, что Rational RequisittePro, который входит в состав Rational Suite, написан на SmallTalk.
