Re[4]: Что мы потеряли? - Философия программирования

Здравствуйте, VladD2, Вы писали:

E>>Во-первых, Object Pascal появился лет на десять раньше:
E>>

E>>Object Pascal was a creation of Niklaus Wirth and Larry Tesler. It was created at Apple Computer in early 1985 through their collaboration. It added object-oriented extensions to the existing Pascal programming language.

E>>и активно использвался Apple-ом для написания софта для Mac-ов. Objective-C был позднее.

VD>Это просто бред. Обжект Паскаль торговая марка Борланда. Правда я действительно немного ошибся. Я в общем-то говорил скорее о Дельфи. Которая и явилась реальным популяризатором Обжект Паскаль. Вирт же к нему вообще отношения не имел.

Уж не знаю, кто владеет торговой маркой Object Pascal и есть ли такая торговая марка вообще, но то, что для Mac-а ObjectPascal использовался очень активно -- это факт. Если не ошибаюсь, то в книге Буча отдельно упоминается библиотека классов MacApp как пример удачной объектной библиотеке. И здесь недавно давали ссылку на видеоролик с первой презентацией Apple Macintosh -- там на одном из screenshot-ов явно виден текстовый редактор с Паскалевким кодом.

E>>Во-вторых, как раз в 1993-м году C++ на персоналках был вообще вне конкуренции для серьезных задач.

VD>Чушь. В 1993 С++ использовали еденицы. Более того тогда и компиляторов то прличных для PC не было. У МС вообще компилтора не было (в это время у них был MS C 6). Был (если не ошибаюсь) Борланд Турбо С++, Зортеч (доступный очень не многим).

VD>Это время когда появился Windows 3.1. Я прекрасно помню, что весе примеры были на С.

VD>Возможно ты просто путашь понятие "был в принципе" и "реально использовался". Так вот С++ был в принципе в 1985. Но реально в начале девяностых он использовался очень не многими. Мой отец примерно в это врямя начал осваивать ПК. До этого они писали на разных Фортранах. А на ПК появились диковинные вещи вроде С.

Говори за себя, ладно? Поскольку ты имеешь в виду "В моем окружении C++ использовали единицы". А вот в моем -- наоборот. И в соседней ветке тебе о том же IT говорит. Что касается Windows, то Borland C++ 2.0 уже позволял писать программы под Windows и часть примеров была на C++. В 93-м мы с моим другом начали писать под Windows и из Borland-овских примеров взяли идею для своей библиотеки классов -- хранить указатель на экземпляр класса, связанный с окном в extra-байтах.

А так же я знаю ряд примеров, когда в эти годы на C++ писали систему управления производственными линиями, информационно-измерительные системы учета расхода воды и электроэнергии, расчитывали прочность зданий, делали системы визуализации для экспертных систем, картографические пакеты, собственные CAD-ы, системы имитационного моделирования, кросскомпиляторы и пр. Наблюдал все это потому, что в подобных проектах участвовали мои сокурсники и знакомые по университету (тогда было обычной практикой для научных руководителей -- сваливать основную работу на студентов-курсовиков и дипломников). И это все было в период с 92-го по 95-й год.

E>> И даже у нас в провинции свободно ходили по рукам разные версии Borland C++ и Zortech C++ (а затем и Watcom C++, это MS C и C++ были редкостью).

VD>Возможно у вас в глубинке было все не как у дргих. Не исключено, что у вас даже MS C++ было редкостью. Ведь он вообще тогда не существовал. А в наших краях ходили MS C 6 и Девелопер Воркбэнч (который хоть и был для доса, но раьботал еле еле). И так же можно было увидеть Турбо С++. А вот найти Зортеч было практически невозможно. А в 1994 году Зортеча вообще не стало. Появился Семантик С++ на чем он и кончился. У меня на работе валяется коробка от него и документация.

Если заметил, я сказал MS C, который был изначально. MS C++ появился позднее. Года до 95 лично я пользовался только Borland-овскими компиляторами (2.0, 3.1, 4.0) под DOS, Windows и OS/2. А с 95-го начал еще использовать Watcom C++ 10.* (в основном под OS/2). И даже STL мы начали применять где-то в 96-97. Под MS C++ 4.2 пришлось перейти где-то году в 97-м, когда Borland C++ 5.01 (из C++Builder-а, кажется) стал глючить на нашем проекте в 250K строк. В 96-м я использовал GNU C++ под Linux-ом, а под OS/2 был какой-то ворованный и сильно урезанный IBM Visual Age C++.

Zortech C++ я пробовал, и впечатлился его C++ библиотеками в исходниках. Но среда у него была очень специфическая, по сравнению с Borland-ом 2.0, да и компилировал он, имхо, медленее. И Symantic C++ затем видел, но не понял, чем же он лучше Borland-а и Watcom-а.

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

E>> Для всего остального был Clipper (просто мания какая-то) и почему-то у нас очень популярным был Prolog

VD>У вас может быть. А Клипер с другими ХБэйсами действительно был популярен. И никакой С++ тогда с ним сравниться не мог.

Это если бухгалтерию или учет кадров писать. Да, здесь с Clipper-ом никто не конкурировал.

E>>Книга "Язык программирования С++" в электронном виде на русском языке ко мне попала в 1991-м, а в 93-м или 92-м я купил ее печатное издание в обычном книжном магазине.

VD>Ну, и что-же ты не стал на нем писать? Это же по словам его фататов был очень популярный язык в то время. Ты просто не мог не проникнуться и запасть на него. Ведь правда?

VD>Ах, нет? Ах, ты поглядел на него как на некую диковину и выкинул? А что так?

E>> Да и литературы по Smalltalk-у на тот момент было с гулькин нос,

Вот потому и не стал, что документации не было. Ни книг, ни даже help-а в инсталляции. Только огромная куча примеров, в которых без описания языка я лично не смог разобраться. А популярным Smalltalk был -- я же про него знал (в отличии от Lisp-а или Oberon, про которые только слышал, а про Eiffel, например, я вообще узнал через несколько лет).

И еще о популярности Smalltalk. Такой неповоротливый гигант, как IBM, выпускает средства разработки только для мейнстримовых языков: Visual Age for C++, Visual Age for Java. И в этом ряду Visual Age for Smalltalk.

VladD2,

M>> Возможности замены работающих модулей на лету до сих пор нет нигде, кроме тех же Лиспа и Эрланга (ну и наверняка других, не менее экзотических языков).

VD>Серьезно? А мужики то не знали и даже на VB5 это делали.

Можно порадоваться за Васик, но он здесь не к месту. Такая "горячая замена" есть для любого интерпретатора и называется она "переписывание исходников". Поэтому, имхо, VB5 не эквивалент ниразу.

Чуть усложнили язык — и привет. Такие вещи как статическая типизация и инкапсуляция являясь преимуществами с одной стороны оборачиваются большими препятствиями со стороны hot upgrade. (Например, я обновил интерфейс класса, как мне теперь обновить все объекты этого класса? Все ссылки на эти объекты? Если я заменил класс двумя классами? Если сделал рефакторинг?) Кстати, наиболее продвинутая в этом вопросе Ява также ещё далека от совершенства (я о HotSwap).

Вот что понимают под горячей заменой кода другие люди

:
1. Переход от старого к новому коду и обратно так же эффективен для выполняемого кода, как и отсутствие перехода. (Это совсем не то, что например "горячая замена" JSP-формы, что вызывает генерацию и перекомпиляцию соответствующего сервлета и является по сути маленькой кнопочкой "reset").
2. Контроль за гранулярностью загрузки.
3. Контроль над процессом загрузки (в т.ч. и откат).
4. Слабые условия на новый код, произвольный старый код.
5. Замена (то есть загрузка кода и передача управления) выполняется автоматически средой.

Между прочим, такая горячая замена у компилируемых языков есть только у динамически типизированных (Erlang, Lisp, Smalltalk). А REPL вообще только для двух последних. Совпадение?

Lazy Cjow Rhrr wrote:
> Между прочим, такая горячая замена у компилируемых языков есть только у динамически типизированных (Erlang, Lisp, Smalltalk). А REPL вообще только для двух последних. Совпадение?
Что имелось в виду?

Posted via RSDN NNTP Server 2.0

Mirrorer,

M>В чем же отличие.. ах да.. "*" и "+" намного сложнее воспринимаются чем multiply и add. Но я думаю к этому можно привыкнуть

M>Равно как и к замене <> на ()

Твои мысли удивительным образом пересекаются с

The Nature of Lisp

Случайно, ты — не он?

Programmierer AG,

>> Между прочим, такая горячая замена у компилируемых языков есть только у динамически типизированных (Erlang, Lisp, Smalltalk). А REPL вообще только для двух последних. Совпадение?
PA>Что имелось в виду?

Read-Eval-Print Loop.

http://en.wikipedia.org/wiki/Read-eval-print_loop

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

Lazy Cjow Rhrr wrote:
> Programmierer AG,
>
>>> Между прочим, такая горячая замена у компилируемых языков есть только у динамически типизированных (Erlang, Lisp, Smalltalk). А REPL вообще только для двух последних. Совпадение?
> PA>Что имелось в виду?
>
> Read-Eval-Print Loop.
Как расшифровывается REPL, я знаю

. Я не понял, действительно ли ты
имел в виду, что REPL есть только у CL и Smalltalk. А OCaml
(компилируемый, статически типизированный!)? А J? Или там неправильный
REPL и делает неправильный мед?

Posted via RSDN NNTP Server 2.0

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Read-Eval-Print Loop.

LCR>http://en.wikipedia.org/wiki/Read-eval-print_loop

Т.е. приведенный мной здесь пример на Ruby является примером REPL (в конце сообщения)?

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Твои мысли удивительным образом пересекаются с
LCR>Случайно, ты — не он?

Случайно нет

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

Мысль пришла когда смотрел на пример Scheme. Какое-то гуишное приложение под вынь.
Появилось смутное впечатление что "где-то я такое видел". Оказалось в XML. Дальнейшее изучение Scheme только больше меня убедило в том, что аналогия уместна. Появилась идея сделать туториал на этой ассоциации

Объяснить макросы как преобразования ХМЛ документа и т.п.

А потом начал изучать Haskell и J

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

ЗЫ. При изучении монад в Хаскеле мое видение их тоже удивительно совпало с примером про астронавтов.

ЗЗЫ. А за ссылку спасибо.

... << RSDN@Home 1.1.4 trck1005>>

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

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

Компилируется в байт-код, REPL тоже есть.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>VladD2,

M>>> Возможности замены работающих модулей на лету до сих пор нет нигде, кроме тех же Лиспа и Эрланга (ну и наверняка других, не менее экзотических языков).

VD>>Серьезно? А мужики то не знали и даже на VB5 это делали.

LCR>Можно порадоваться за Васик, но он здесь не к месту. Такая "горячая замена" есть для любого интерпретатора и называется она "переписывание исходников". Поэтому, имхо, VB5 не эквивалент ниразу.

Наверно речь шла о технологии COM. Ошибка тут в том, что не с VB5, а с VB4 стало возможным это все использовать (когда VB стал полностью бинарно COM-овским)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, VladD2, Вы писали:

VD>Ну, ты почитай свои ссылки. А потом... и вопросов не возникнет. Лисп (если не брать эксперементальные клоны) это не типизированный язык и до стадии выполнения у него попросту не хватает информации о типах чтобы породить статический код. По этому в Лиспе используют методы динамической компиляции, а это и есть JIT-компиляция.

Схема совмещает это все. А попытки создать Схему для дотнета помогут использовать "двухтактный JIT", первый раз самим компилятором Схемы, второй раз — нативным JIT. У Схемы один очень серьезный недостаток — она безнадежно опоздала, да и ставший модным Common Lisp убил всю красоту ФП. (По сути, только последний недавний 5-й стандарт на Схему более-менее приличный, но этот стандарт опоздал лет на 20)

VD>На свете есть языки в которых типизация статическая, но типы так же явно не указываются. Это Хаскель, клоны ML, Немерле, Скала. Пследние два допускают вывод типов только в врыжениях. Эти языки специально спроектиррованы так, чтобы типы в них были всегда изместны еще до стадии сыполнения.

Схема выводит типы, где может. Где не может — остается интерпретатором. Т.е. часть кода на схеме компилируется в двоичный код, а часть — в предкомпиленные S-выражения.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

eao197,

LCR>>http://en.wikipedia.org/wiki/Read-eval-print_loop
E>Т.е. приведенный мной здесь пример на Ruby является примером REPL (в конце сообщения)?

Очень похоже на это.

Весь кайф REPL (и отличие от обычной командной строки) в том, что работа идёт с настоящими объектами. Они "плавают" в "море" сами по себе, мы вытаскиваем их, модифицируем их, и возвращаем обратно плавать. И таким образом наворачиваем функционал системы (начиная с нуля), которая уже работает и мы наблюдаем её работу. Естественно такая командная оболочка должна помогать "вылавливать" нужные сущности (объекты, функции и т.п.) и результатом таких сеансов "объектной ловли" в конечном итоге должен быть работающий исходный код.

Вычисления в command window — это не то. Объекты в command window берутся от пользователя (а не из "моря") и после вывода их представления на экран исчезают. Eclipse и IDEA имеют такое окно, но им почти никто не пользуется, потому что сформировать нужный объект, потом провести над ним вычисление — это нетривиальная работа, чтобы затем просто выкинуть объект. Поэтому все, кого я знаю, действуют по старинке: редактор-компилятор-отладчик.

Я пробовал писать из шелла в Эрланге, но оттуда удобно только наблюдать за состоянием системы. Определять функции (особенно рекурсивные) требует некоторого усилия и расширять/изменять их неудобно. И в общем, я не думаю, что можно всю систему написать таким образом. Тем не менее у Эрланга всё для этого имеется (read, eval, print).

Если Ruby компилируем, то нужно расширить список компилируемых языков с REPL.

ps: Ещё Питон и OCaml.

Глеб,

PA>Как расшифровывается REPL, я знаю

.
Да, и правда чего это я?

PA> Я не понял, действительно ли ты
PA>имел в виду, что REPL есть только у CL и Smalltalk. А OCaml
PA>(компилируемый, статически типизированный!)?

Ой, забыл о нём. Да-а... Получается, что OCaml уникален. Теперь меня мучает вопрос:

Верно ли, что Hot Upgrade необходим для REPL, или это ортогональные вещи?

Если ортогональны, то я зря приплёл REPL в сообщении к Re[4]: Что мы потеряли?.

PA>А J?
А тут интерпретатор, однако. Но вообще в командной строке J можно писать программы, там в принципе то, что нужно (есть правда маленькие нарекания).

PA> Или там неправильный REPL и делает неправильный мед?
Правильный REPL — это те самые вычисления в командной строке плюс окружение должно помогать инкрементальному стилю разработки программ. Подробнее я ответил Евгению в Re[8]: Что мы потеряли?.

vdimas,

LCR>>Можно порадоваться за Васик, но он здесь не к месту. Такая "горячая замена" есть для любого интерпретатора и называется она "переписывание исходников". Поэтому, имхо, VB5 не эквивалент ниразу.

V>Наверно речь шла о технологии COM. Ошибка тут в том, что не с VB5, а с VB4 стало возможным это все использовать (когда VB стал полностью бинарно COM-овским)

Хм. Ну ладно, COM. Как COM решает вопрос с горячей заменой кода? Скажем, провели мы малость рефакторинг. Дальше?

Здравствуйте, vdimas, Вы писали:

V>У Схемы один очень серьезный недостаток — она безнадежно опоздала, да и ставший модным Common Lisp убил всю красоту ФП. (По сути, только последний недавний 5-й стандарт на Схему более-менее приличный, но этот стандарт опоздал лет на 20)

В смчсле "опоздал"? По некоторым параметрам это мейнстримовские языки от него на 20 лет отстают. А если чего-то не хватает в стандарте — пиши Request for Implementation

Lazy Cjow Rhrr wrote:
>
> Верно ли, что Hot Upgrade необходим для REPL, или это ортогональные вещи?
Теперь стало понятнее.
Да, в этом смысле REPL для OCaml недостаточно мощный. Там не происходит
модификации "объекта в море", как ты описывал в
Re[8]: Что мы<br />
потеряли?, там используется lexical scoping — ввод нового
определения объекта foo добавляет новый объект в окружение, но все ранее
определенные объекты, использующие foo, ссылаются на предыдущее значение
foo.
И Hot upgrade нет — #load "foo.cmo" не сработает, если интерфейс модуля
Foo изменился.
Поэтому написать всю программу с помощью OCaml toplevel проблематично.
Я его использую в связке с tuareg-mode емакса для экспериментов с
текущим модулем, хватает.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Хм. Ну ладно, COM. Как COM решает вопрос с горячей заменой кода? Скажем, провели мы малость рефакторинг. Дальше?

Согласно правилам COM, однажды опубликованный интерфейс и гвид к нему фиксируются. Так что твой рефакторинг может быть только внутри компонента. А заменить на горячую компонент легко.

Set someVar = Null    
Application.DoEvents        ' если ссылок на компонент больше нет, то в WM_IDLE будут выгружены лишние DLL
PrepareNewDllVersion        ' типа вызов процедуры замены старой DLL на новую
Set someVar = CreateObject("Lib.AppId") ' создали объект заново

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

vdimas,

LCR>>Хм. Ну ладно, COM. Как COM решает вопрос с горячей заменой кода? Скажем, провели мы малость рефакторинг. Дальше?

V>Согласно правилам COM, однажды опубликованный интерфейс и гвид к нему фиксируются. Так что твой рефакторинг может быть только внутри компонента.

Подменить имплементацию интерфейса — это детский сад, совсем неинтересно. Весь прикол в том, что работающий код ожидает интерфейс I1, а получает вместо новый интерфейс I2 (как раз в этот момент был горячий апгрейд) и всё летит в щепки. Можно (теоретически) сделать так, чтобы по команде "Фас!" любой компонент переезжал с одного интерфейса на другой, но это невозможно сделать в общем случае и простота такого решения вызывает сомнение.

V> А заменить на горячую компонент легко.
V>

V>Set someVar = Null    
V>Application.DoEvents        ' если ссылок на компонент больше нет, то в WM_IDLE будут выгружены лишние DLL
V>PrepareNewDllVersion        ' типа вызов процедуры замены старой DLL на новую
V>Set someVar = CreateObject("Lib.AppId") ' создали объект заново
V>

Это понятно, дело техники.

	От:	Gadsky
	Дата:	30.08.06 06:30
	Оценка:	+1

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	30.08.06 06:55
Оценка:	+1

От:	eao197	http://eao197.blogspot.com
Дата:	30.08.06 07:15
Оценка:	11 (2) +1

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	30.08.06 08:47
Оценка:

	От:	Programmierer AG
	Дата:	30.08.06 08:56
	Оценка: