Comments 137
Это ответ на какую статью? Можно ссылку?
О и да хабра добрались статьи "ответы"
Почему-то вспомнился Хармс.
Автор: Вот, это — Smalltalk, язык объектно-ориентированного программирования
Читатель: А по-моему, это говно!
Автор стоит несколько минут потрясённый этой новой идеей и падает замертво. Его выносят.
Автор, возможно, слишком резок, но во многом прав. Однако, есть два момента:
Борьба с верующими считается богоугодным делом и оценивается по высшему разряду, но за неё ставят минусы в карму.
Допустим, я нахожусь на месте оппонента и соглашаюсь со всем написанным. После этого я обязательно спросил бы: «И какие ваши предложения?»)))
Интересно, но местами было тяжело читать из-за очень нерусской грамматики.
А я уехал в Канаду и до сих пор работаю на МФ.
Я их много прочитал за годы жизни в Канаде
Впрочем, это всё объясняет.
Аффтор, у вас старческий маразм. :)
ИБМ был против Windows 3.1, ИБМ был за то чтобы окна появились с 286-ми компютерами.
Они и появились на 286. На ХТшках венда 3.1 не работала.
А на ХТ и АТ пусть пока будет MS-DOS, в которых тоже были приложения как бы в окнах.
АТ - Это и есть 286
Но нет Бил решил снять сливки до 286-ых, ну и естественно "подсадил" нетребовательного пользователя на Windows 3.x c которым этот пользователь приперся и на 286-е,
Не вводите людей в заблуждение. Виндовс 3.1 требовала 286-го компа. Виндовс 3.0 и предыдущие теоретически и в минимальной конфигурации могли работать на i8088, но, поскольку, из мало кто видел, это несущественно.
начала рушиться ЕС ЭВМ, причем лавинообразно. Это привело к тому что получился разрыв в передачи опыта программирования и вообще отношения к компьютерам от высокопрофессиональных МФ-щиков к начинающим ПК-шникам
Называть ЕС ЭВМ мейнфреймами, а их незамысловатых программеров высокопрофессиональными мейнфремшиками изрядно... опрометчиво :).
На МФ я писал на Ассемблере, Фортране, ПЛ/1, REXX
Вряд ли есть чем здесь гордиться по сравнению с бейсиком, кроме, разве что Rexx'а. Rexx прикольный. Сделали бы бимеры визуальную среду для рекса, на VB никто и не взглянул бы.
По части Windows и ХТ, АТ, 286/386 писал по памяти. Практически наугад. Давно это было когда читал про это. Да и кому сейчас это важно. Дела давно минувших лет.
Но факт остается фактов что разошлись ИБМ и Микрософт в понимании что, когда и как выкатывать на рынок. Чтобы применить свою стратегию Микрософт порвал с ИБМ.
Кто был прав сегодня не возможно установить. Два раза такие дела проиграть невозможно. Я считаю что ИБМ был прав.
Называть ЕС ЭВМ мейнфреймами, а их незамысловатых программеров высокопрофессиональными мейнфремшиками изрядно... опрометчиво :).
Позвольте спросить: Вы в теме?
Вряд ли есть чем здесь гордиться по сравнению с бейсиком, кроме, разве что Rexx'а. Rexx прикольный. Сделали бы бимеры визуальную среду для рекса, на VB никто и не взглянул бы.
Причем здесь "гордиться"? Я просто сказал с чем из языков работал. Для примера.
На REXX я написал километры программ, но PL/I мощнее. Кроме того REXX интерпретарот чем определяются его интересные фишки, а значит производительность не про него. Есть компилятор, но это тоже не совсем то что компилятор PL/I. Бэйсик по сравнению с PL/I это, как говорилось, язык аборигенов.
Сравнивать Ассемблер и Бэйсик вообще не возможно. REXX сравнивать с VB тоже сомнительное дело. REXX это про автоматизацию в современном этого понимании.
Хочется и здесь спросить: А Вы в теме?
Но факт остается фактов что разошлись ИБМ и Микрософт в понимании что, когда и как выкатывать на рынок
Как раз таки получается, что не разошлись же. Обе начали на 286. Но вынь была оболочкой, а полуось - операционкой. Более тяжёлой и требовательной к железу. Не всяк мог себе позволить комп на котором нормально работала полуось. Вот и весь секрет. Варп только выравнял ситуацию.
А предыдущие дела... это уже не важно. У бимеров тоже была тогда оконная оболочка. Но про неё помнит ещё меньше народа, чем про вынь 1.0/2.0. Я точно помню что игрался с нею, но сейчас не могу даже вспомнить как оно называлось.
Чтобы применить свою стратегию Микрософт порвал с ИБМ.
Это было уже сильно позже. Когда 95 вышла.
Кто был прав сегодня не возможно установить.
Кто прав - это странный вопрос. Кто победил, тот и прав.
Я считаю что ИБМ был прав.
Как старай полуосевик я тоже за бимеров :). И считаю, что миркософт поступил отвратительно, кинув бимеров сделав втихушку на своей части наработок для бимеров свою НТ. Да, говорят, юридически всё чисто, но морально - отвратительно же.
А то, когда и что выпустили - да обе две одновременно это поле исследовали. Мс сориентировались быстрее. Бывает. У бимеров с варпом был хороший шанс, но они сами его про...мотали (а может удар "под дых" от микросовтов тоже свою рояль сыграл).
Вы в теме?
Я не в теме промышленных мейнфреймеров, я начинал в академической среде и там, несмотря на науку, не видел оверкрутизны. Может в промышленности были такие, но, судя по тому, что следов от их деятельности не осталось, там их тоже не было :).
На REXX я написал километры программ, но PL/I мощнее
Переусложнённый монстр.
Кроме того REXX интерпретарот
Ну, да. Так и бейсик тоже. Но при должном умении и желании это не помешало ему стать вижуал бейсиком. Умение наверняка было, а, вот, с желанием - швах. При всех недостатках vb позволил почти кому угодно порешать кучу своих проблем, а не ждать у моря погоды пока мейнфреймовые суперпрофессионалы только начнут расчехлять свой пл/1... :) микросовты тут всех переиграли, но язык выбрали, конечно дебильный.
Хочется и здесь спросить: А Вы в теме?
На пиэле не писал, а, вот, с рекксом развлекался. Помню приятно поразила его бесконечноразмерная арифметика.
Обе начали на 286.
Строго говоря ИБМ нанял Микрософт делать ОС и другой софтвар, в основном для ИБМ мэйнфрэйм, как то замены аппаратных компонент System Network Architecture (SNA) и, Вас удивит наверняка, транслятор PL/I c Index Sequential Access Method (ISAM). Я с эти продуктом работал в 90-е переводя PL/I программы с ЕС ЭВМ на ПК.
А предыдущие дела... это уже не важно. У бимеров тоже была тогда оконная оболочка. Но про неё помнит ещё меньше народа, чем про вынь 1.0/2.0. Я точно помню что игрался с нею, но сейчас не могу даже вспомнить как оно называлось.
Не знаю с чем Вы игрались, но вот из истории Микрософт на Вики. Интересно Вы откуда берете факты для Ваших утверждений?
In 1985, IBM requested Microsoft to develop a new operating system for their computers called OS/2. Microsoft produced that operating system, but also continued to sell their own alternative, which proved to be in direct competition with OS/2. Microsoft Windows eventually overshadowed OS/2 in terms of sales. When Microsoft launched several versions of Microsoft Windows in the 1990s, they had captured over 90% market share of the world's personal computers.
Это было уже сильно позже. Когда 95 вышла.
Откуда берётся этот бред? См. выше и:
Computerworld wrote in 1987 that "Gates has pushed [Windows] almost fanaticallly for years".[40] On May 22, 1990, Microsoft launched Windows 3.0.[10] The new version of Microsoft's operating system boasted new features such as streamlined graphic user interface GUI and improved protected mode ability for the Intel 386 processor; it sold over 100,000 copies in two weeks.[10][52] Windows at the time generated more revenue for Microsoft than OS/2, and the company decided to move more resources from OS/2 to Windows.[53] In an internal memo to Microsoft employees on May 16, 1991, Bill Gates announced that the OS/2 partnership was over, and that Microsoft would henceforth focus its platform efforts on Windows and the Windows NT kernel. Some people, especially developers who had ignored Windows and committed most of their resources to OS/2, were taken by surprise, and accused Microsoft of deception. This changeover from OS/2 was frequently referred to in the industry as "the head-fake".[54][55] In the recent years, the popularity of OS/2 declined, and Windows quickly became the favored PC platform.
"the head-fake" переволится как "ложный удар головой". Также:
The OS/2 Venture:
In 1985, the two companies entered a joint development agreement to create OS/2, an operating system meant to succeed the original PC-DOS.
OS/2 Fails to Compete:
Microsoft also continued developing and selling its own Windows operating system, which eventually surpassed OS/2 in sales and market share, leading to the partnership's functional end.
Я не в теме промышленных мейнфреймеров, я начинал в академической среде и там, несмотря на науку, не видел оверкрутизны. Может в промышленности были такие, но, судя по тому, что следов от их деятельности не осталось, там их тоже не было :).
В академической среде использовались в основном хорошие, отечественные БЭСМ-6. В военке, главным образом в ПРО Москвы, отечественные же компьютеры превосходящие тогдашние ИБм МФ, и были Уралы, тоже не хуже тогдашних ИБМ МФ.
К концу 80-х, началу 90-х ЕС ЭВМ почти сравнялись с ИБМ МФ. Но рухнул СССР и рухнула ЕС ЭВМ, в которой конечно же было тоже много проблем.
С середины 90-х в России началась история ИТ с нуля.
Как Вы вообще могли наблюдать какие-либо следы чего-либо в тогдашнем ИТ? Интересно, раельно интересно.
Так и бейсик тоже.
Гугл с Вами не совсем согласен:
Visual Basic, in its various iterations, primarily functions as a compiled language, though aspects of its ecosystem involve interpretation.
Visual Basic (classic) and Visual Basic .NET are both compiled.
Вы про PL/I:
Переусложнённый монстр.
Вы же:
На пиэле не писал,
?????
с рекксом развлекался. Помню приятно поразила его бесконечноразмерная арифметика.
Cовсем не этим он интересен на самом деле.
Не знаю с чем Вы игрались, но вот из истории Микрософт на Вики. Интересно Вы откуда берете факты для Ваших утверждений?
Из непосредственного чувственного опыта, данного нам в ощущениях, разумеется. При чём здесь микросовт, я про другую оконную оболочку. Это была именно оболочка над досом, а не ос/2. Гораздо примитивнее виндовса 3.1.
Откуда берётся этот бред?
Ну, значить чуть раньше 95-ки. Но это точно не ваш бред про то что это началось с XTшек. В вашей же цитате написано про protected mode ability for the Intel 386 processor для вынь 3.0 - какое уж тут "снять сливки до 286-ых"...
В академической среде использовались в основном хорошие, отечественные БЭСМ-6.
Расскажите мне про то что мы использовали, ага :). Была ЕС 1055, была М-4030 (я на ней даже пооператорствовал), Кучка СМ-4-ых. Бэсма у нас, впрочем, тоже была. Хорошей она была в 60-х. В 80-е, она просто была. Доживала. Ещё должны были Эльбрус привезти. Настоящий. Возможно, даже второй. Говорили, что "пришло несколько вагонов Эльбруса" :). Но, что-то пошло не так и он где-то "потерялся". Ещё до распада совка это было.
отечественные же компьютеры превосходящие тогдашние ИБм МФ, и были Уралы, тоже не хуже тогдашних ИБМ МФ.
Смешно.
С середины 90-х в России началась история ИТ с нуля.
Как Вы вообще могли наблюдать какие-либо следы чего-либо в тогдашнем ИТ?
Я их наблюдал с середины 80-х. Про следы вы точно сказали - следы того, что удалось сделать (а потом украсть) в 60-70-х
Visual Basic, in its various iterations, primarily functions as a compiled language
Я же про бейсик. И про то, что при желании его можно было сделать компилируемым, как раз, как вижуал (или, до этого был такой весёлый "квейсик" - quasic на pdp-клонах - тоже компилируемый).
На пиэле не писал,
?????
не писал - не значит не интересовался. :)
Cовсем не этим он интересен на самом деле.
ну, там какая-то странный тип данных был, да. Но мне как раз как-то понадобилась длинная арифметика, а тут rexx под руку попался - очень кстати.
Вики пишет, что как раз для мейнфремов был компилируемый rexx и ещё был NetRexx, компилирующийся в ява-байткод. Так что если бы бимеры захотели, сделали бы из него вижуал-бомбу для полуоси и побили вы вижуал васик.
Или даже не вижуал, а просто приделали удобную манипуляцию с сущностями Presentation Manager как в Tk. Ахахах! Он, оказывается, был такой - VREXX! Блин, чего ж я тогда про него не знал...
ну, там какая-то странный тип данных был, да. Но мне как раз как-то понадобилась длинная арифметика, а тут rexx под руку попался - очень кстати.Вики пишет, что как раз для мейнфремов был компилируемый rexx и ещё был NetRexx, компилирующийся в ява-байткод. Так что если бы бимеры захотели, сделали бы из него вижуал-бомбу для полуоси и побили вы вижуал васик.Или даже не вижуал, а просто приделали удобную манипуляцию с сущностями Presentation Manager как в Tk. Ахахах! Он, оказывается, был такой - VREXX! Блин, чего ж я тогда про него не знал...
Никаких странных типов данных в REXX нет. Все типы данных это то что позволяют обрабатывать компьютеры. Странным Вам могло показаться то что одна и та же переменная за время жизни в одной программе может представлять данные разных типов. Поэтому REXX не может быть 100% компилируемым.
Что Вы понимаете под "длинной арифметикой"?
Да, на МФ есть компилятор для REXX. Но это не совсем тоже самое как компилятор под PL/I и Cobol. Это типа "виртуальной машины". Целиком компилировать REXX невозможно.
Вижуал бомбой был ViaualAgr for SmallTalk и другие ИБМ вижуалс (их было много). Почему этой бомбы не хватило объяснить невозможно. Это за пределами разума.
На МФ, в z/OS, да и zVM (про другие системы не знаю), все поддерживаемые языки поддерживают диалоговую "оболочку" называеиую ISPF:
ISPF, which stands for Interactive System Productivity Facility, is an IBM software product that provides a menu-driven, panel-based interface for interacting with IBM mainframe operating systems, primarily z/OS. It serves as a development tool for programmers to create and modify code, manage data sets, and build interactive applications called dialogs.
Есть масса стандартных приложений в диалоговой форме так что даже работа с собственно ОС уже давно не командами (CLI) выполняется, а в разумном диалоге. Команды никуда естественно не делись, но их используют главным образом в скриптах. ISPF тоже может использоваться в скриптах. История ISPF прослеживается с 1974 года и есть её емуляторы на ПК.
Да это для терминала 3270. Но этот терминал не тоже что другие терминалы используемые в системах типа Unix/Linux. Очень даже не тоже самое.
Мы на прошлой неделе перевели последнее приложени с МФ в облако. Я общался с пользователями этого приложения, которое диалоговое на базе 3270, они говорят что новое приложение на современном GUI им не нравится, 3270 им подходил больше. Новое приложение они назвали "мышка".
Вот пример 3270 скрина из Omegamon:
Да, по нынешним временам это непривычно выглядит, но это удобнее чем GUI если речь идет не про игрушки, а про производительную работу. При правильном применении этот интерфейс сокращает количество движений пользователя и количество ненужных, светящихся пикселей.
Так вы сами не в теме AT-XT-286. Вы с другой планеты прилетели поучать сирых и убогих бывших владельцев самопальных спектрумов.
Радиоинженеры всегда критикуют схемные решения радиолюбителей, агрономы - садоводов любителей.
Называть ЕС ЭВМ мейнфреймами... опрометчиво :).
Вы что-то путаете. Единая система и есть мейнфреймы. Др. дело, что, как один из компонентов серии, были также выпущены и ПК, как рабочие станции и терминалы к мейнфремам ЕС. ЕС-1840 (это был PC XT) и ЕС 1841 (это был PC XT), А, всего в странах СЭВ много выпускалось персоналок в серии ЕС. См. https://ru.ruwiki.ru/wiki/ЕС_ПЭВМ
Вы что-то путаете. Единая система и есть мейнфреймы.
Да, это понятно, что речь о стыренной копии System/360, только называть их мейнфремами у меня язык не поворачивается. Большими они были только по габаритам. А к мейнфреймам больше System Z относятся. Или поздние S/360, которые содрать уже сил и технологий не было. С другой стороны, все они наследники s/360 архитектуры и по этому критерию, наверное, таки "мейнфремы". Только хииииленькие ))
Да, это понятно, что речь о стыренной копии System/360, только называть их мейнфремами у меня язык не поворачивается. Большими они были только по габаритам. А к мейнфреймам больше System Z относятся. Или поздние S/360, которые содрать уже сил и технологий не было. С другой стороны, все они наследники s/360 архитектуры и по этому критерию, наверное, таки "мейнфремы". Только хииииленькие ))
Да Вы, батенька, оказывается и в мэйнфрэймах разбираетесь. Помогу Вам.
Не было никаких "стыренной копии System/360". ЕС ЭВМ были лишь программно совместимыми с IBM System/360. Cтыренными можно было разве что назвать ереванскую линейку ЕС-1045. Да и то лишь потому что на её грузился т.н. "black box" - микропрограммная поддержка VM. Программа восстановления машинных ошибок для ЕС ЭВМ разрабатывалась безотносительно каких-либо моделей ИБМ. Это значит что на этом уровне они были несовместимы. Элементная база тоже использовалась своя, согласен, стыренная. Схемотехника была своя. Детали конечно могут быть разными.
Да, архитектура ЕС ЭВМ в точности повторяла System/360/370, но схемотехника была оригинальной. Вот что про это пишет Вики:
Главный вопрос для сторонников клонирования, фактически, был в том, возможно ли скопировать аппаратную часть системы без полной технической документации, или же её целесообразнее реализовать заново «с нуля», одновременно дополнив и улучшив.
В качестве альтернативных вариантов рассматривалось сотрудничество на равноправных условиях с какой-либо из западноевропейских фирм. Академик А. А. Дородницын, сторонник этого варианта, в качестве партнёра рассматривал английскую фирму ICL[3][4].
Руководство IBM, которое он же принимал в стенах ВЦ РАН, от подобного сотрудничества отказалось.
Разработкой ЕС ЭВМ занимался Научно-исследовательский центр электронной вычислительной техники (НИЦЭВТ). Значительная часть работы НИЦЭВТа состояла в клонировании оригинального программного обеспечения System/360, множество сотрудников было занято исследованием дизассемблированного машинного кода оригинального компьютера и его адаптацией.
К счастью, фирма IBM поставляла значительную часть ОС в виде исходных текстов, что дало возможность доработать систему, устранить многие ошибки в коде системы и ввести дополнительные возможности. Поздняя система ОС ЕС 6.1.9 была уже гораздо стабильнее оригинала OS/360 21.8 (последней системы линии).
Новая советская ОС ЕС 7 уже не имела прямого IBM-овского аналога, представляя собой увязанные в единый пакет Систему виртуальных машин (СВМ, аналог VM) и Базовую операционную систему (БОС, не имевшую IBM-овского аналога и представлявшую собой развитие ОС ЕС версии 6).
В ЕС ЭВМ скопирована была только архитектура системы, аппаратная же реализация была создана заново. На надёжность и эксплуатационные характеристики этой серии отрицательно влияло низкое качество советских компонентов
Вообще слово Main Frame означает Главная Рама и это был ИБМ внутренний термин буквально значащий главную раму на которую монтировались узлы компьютера в лабораторных условиях.
Гораздо позже этот термин распространился на класс компьютеров образующих ядро ИТ, или бэкэнд. Под этот термин подгонялись VAX-ы и даже PDP.
Между System/360 и System Z были еще System/370, XA, XC, ESA (ES9000).
ЕС ЭВМ тоже далилась на Ряды, от 1 до 4:
К «Ряду 1» (аналог серии System/360) принадлежали модели ЕС-1010, ЕС-1020, ЕС-1021, ЕС-1030, ЕС-1040, ЕС-1050, и основанные на них усовершенствованные модели: ЕС-1010М, ЕС-1011, ЕС-1012, ЕС-1022, ЕС-1032, ЕС-1033, ЕС-1052.
К «Ряду 2» (аналог серии System/370) принадлежали модели ЕС-1015, ЕС-1025, ЕС-1035, ЕС-1045, ЕС-1055, ЕС-1060, ЕС-1061, ЕС-1065.
К «Ряду 3» принадлежали модели ЕС-1036, ЕС-1046, ЕС-1057 (ГДР), ЕС-1066, ЕС-1068.
В сериях устройств Ряд 3 и особенно Ряд 4 был запланирован и частично реализован ряд технических усовершенствований, не имевших аналогов в машинах IBM. Реализовывались специализированные вычислительные блоки, такие как векторные и матричные процессоры, процессоры, работавшие на иных физических принципах (например, оптический) и так далее[уточнить].
Практически все эти разработки были остановлены в 1990-х годах после распада СССР.
Последние машины серии ЕС выпускались уже под лицензией и с использованием оборудования IBM.
Особо хотелось бы отметить вот эту модель:
ЕС-1130 разрабатывался в Минске при участии специалистов из Москвы и Киева. Главный конструктор — В. П. Качков, основные разработчики — М. Е. Неменман, М. П. Котов и А. Г. Рымарчук. Использовался микропроцессорный набор К-1800 (производство завода «Вента», Вильнюс). Конвейерный процессор, до 1 инструкции за такт, мощная система самодиагностики. В качестве системного терминала и инженерного пульта использовался ЕС ПЭВМ-1840. Выпущено 230 (по другим данным — 437[22]) машин.
Во-первых, потому что с М.П. Котовым я был (R.I.P.) лично знаком (как впрочем и со многими сотрудниками его отдела) и много с ним общался.
Во-вторых, М. Е. Неменман был взят в ИБМ как носитель интересных идей реализованных в ЕС-1130.
Вечный спор между сделать хорошо, но медленно или быстро но кое-как. Рынок всегда выбирает второе. Пока вы делаете хорошо, поляну уже захватят чьи-то кривые поделки.
Если Вы про поделки то да. Но есть продукты которые десятилетиями существуют, развиваются и держатся на рынке в своей нише.
Поделки же (не важно как долго их доводят) не держатся на рынке, сменяются другими поделками. Благо на рынке продуктов для х86-64 всегда есть место, в том числе чем-нибудь занятое, временно.
Существует прием как открыть новую нишу. Надо лишь придумать новое название, как правило для чего-нибудь давно известного, немного это специализировать на какую-нибудь не закрытую потребность, и вперед. Благо на этом рынке много участников падких на новын название. Это кстати и прием для наемных сил в ИТ на х86-64.
Когда все ранние направления засижены долгожителями, новые силы находят новые движения и хватабтся за них создавая видимость прогресса.
Наш менеджер на неделе зазывал нас пойти на трэйниг в Микрософт по ИИ (Copilot, Git, etc...). Не все согласились. Менеджер заявил мол тогда вы отстанете. Правда не объяснил в чем мы отстанем.
В России же в начале 90-х и далее в основном конечно были 16 разрядные АТ и ХТ.
Путает автор. От XT уже в конце 80-х нос воротили в моём вычислительном центре одного регионального санатория. AT в последний раз в практическом применении видел там же в 1990. В начале 90-х в моей лаборатории др. госорганизации уже использовали 368. К 1992-93 — 486. Пентиумы пошли уже в третьей упоминаемой мною тут организации в 1996.
У меня тоже на работе были 486-е и пентюх сервер в 1995 году. Ну так это на работе, в небедной компании.
А что по-Вашему было с домашними компьютерами? А к чему имели доступ тогдашние начинающие "программисты"?
Так почти то же самое что и на западе -- 8080, Z80 в большинстве случаев, редко 6502.
Но в СССР существовал клон PDP-11 в однокристальном исполнении -- БК-0010, полноценный 16 разрядный бытовой компьютер.
А к чему имели доступ тогдашние начинающие "программисты"?
У нас в провинциальном универе были большая ЕС ЭВМ (1020 или еще какая не помню), какая-то средняя СМ-ка (но мы под нее не успели попрограммировать, только какими-то учебными программами за ней пользовались), Robotron 1715, ЕС 1840/1841, IBM XT и AT. Это 1990-1995-й годы. С 1994-го я уже работал в небогатой компании на 386-х и 486-х.
У нас в провинциальном универе были большая ЕС ЭВМ ...
Я сделал дополнение в статье про ЕС ЭВМ. Почитайте, будет интересно.
Почитайте, будет интересно.
Не-а. Может вам показалось, что вы добавили ложку мёда в бочку дерьма. Но как бы то ни было, вся ваша статья как была бочкой дерьма, так и осталась.
Регистрируясь на Хабр-е пару-тройку месяцев назад я надеялся на конструктивные, профессиональные диалоги с моими соотечественниками, с которыми я скоро собираюсь быть и земляками тоже.
Конечно Вы не показатель для всех, но все равно не приятно читать такое. Просто промолчать Вы не могли?
Просто промолчать Вы не могли?
Ну вы-то не промолчали и выдали статью, в которой выплеснули изрядное количество известной субстанции. А раз ваша статья (за исключением цитат из внешних источников) этой самой субстанцией и является, то почему бы и не озвучить свою оценку?
Кроме того, что вы наговорили откровенной ерунды про перспективы Windows и OS/2 в начале-середине 1990-х, так вы еще и умудрились назвать варварами поколение программистов. На фоне того поколение вы выглядите динозавром, которому повезло прожить свою жизнь в нише мейнфреймов.
Ну вы-то не промолчали и выдали статью, ....
Просто не читайте моих статей. Я никого не заставляю это делать.
Кроме того, что вы наговорили откровенной ерунды про перспективы Windows и OS/2 в начале-середине 1990-х, так вы еще и умудрились назвать варварами поколение программистов. На фоне того поколение вы выглядите динозавром, которому повезло прожить свою жизнь в нише мейнфреймов.
Сравнение с варварами был литературный прием. Ничего личного. Но с точки зрения человека с моим опытом (и не только из-за его продолжительности) именно так я воспринимал появление поколения ТИ-шников в 90-е. Это была абсолютно невосприимчивая ни к чему, кроме того что ей удалось освоить, секта. И речь вовсе не об ИБМ МФ. А о тех же OS/2, VisualAge, DB2/2, Query Analyzer, REXX в OS/2, LotusNotes, и т.п. которые в то время были на голову выше Windows 95, Visual Basic, FoxPro (Clipper, Clarion), Exchange.
Все это (OS/2 и т.д) было доступно без особых усилий. Конечно это было не для домашнего применеия, но в производствах, в которых, несмотря на экономический коллапс, средст для этого было достаточно. Цены были не заоблачными. Документация была восхитительной. Но даже этого не произошло.
Про нишу, в которой я умудрился "прожить свою жизнь". Еще раз повторю, я несколько лет проработал не на МФ-ах. Более того, работая с МФ в Канаде, я много времени (годы) имел дело с Linux, WebSphere на Linux (включая WebSphere, уже на МФ), разными другими продуктами связанными с МФ, но устанавливаемые на Windows. Linux. И на МФ я несколько раз устанавливал Linux для разных целей.
По приезду в Канаду у меня было два резюме: одно про ИБМ МФ, другое про OS/2, VisualAge и т.п.. По последнему я даже проходил тестирование для работы на заводе Stelco. Прошел успешно (у меня с собой была документация по VisaulAge, привезенная из России, пара основных книг), но рекрутер сказала что заказчик изменил проект. Что было на самом деле конечно не известно.
И вот вдруг на меня обратили внимание по резюме на ИБМ МФ. И прошло 25 лет. 26-ой идет и я при делах. А мне уже 70.
Из Википедии:
Ва́рвары (др.-греч. βάρβαρος, barbaros — «негреческий», «чужеземец»[1]) — люди, которые для древних греков, а затем и для римлян были чужеземцами, говорили на непонятном им языке и были чужды их культуре.
В Новое время «варварами» стали обозначать совокупности народов, вторгавшихся в пределы Римской империи, пользуясь её ослаблением, и основывавших на её территории самостоятельные государства (королевства).
В переносном значении «варвары» — невежественные, грубые, жестокие люди, разрушители культурных ценностей.
Вышенаписаное добавленно к статье под заголовком "Дополение 3".
Просто не читайте моих статей.
Ну а раз уж довелось, то почему бы и да.
Это была абсолютно невосприимчивая ни к чему, кроме того что ей удалось освоить, секта.
И это сказал персонаж, который позволяет себе оценивать ту же Java ни разу на ней не попрограммировав? Мощно, внушаить.
Может раскажите, чему такому можно было научиться на МФ, чему было нельзя было научиться на персоналках? У вас там, в мире IBM, какие-то другие алгоритмы, структуры данных и парадигмы программирования? Или для вас программирование -- это перетаскивание контролов на формочках в визуальном редакторе или автоматизация LotusNotes?
А о тех же OS/2
Я начал программировать под Windows в 1993-ем, а под OS/2 в 1995-ом. Имею представление. И то, что OS/2 ничего не светит, было понятно еще в 1994-ом, хотя OS/2 Warp была хороша, но не то, чтобы принципиально лучше WinNT 3.51. Когда же вышла WinNT 4.0 полуось уже можно было закапывать, она могла остаться (и оставалась, что характерно) только в совсем специфических нишах. Даже удивительно, что так долго продержалась.
Посему то, что вы тут изглагаете выглядит как "врет как очевидец".
nnnnn
И это сказал персонаж, который позволяет себе оценивать ту же Java ни разу на ней не попрограммировав? ...
Если бы Вы читали меня внимательно, то я писал что оценивал Java как пользователь продуктов изначально написанных на SmallTalk и потом переписанных на Java.
C Java приложениями я имел дело в WebSphere и не только. Да не писал. Я много на чем не писал, на Кобол например, T-SQL, PL/SQL, или Python но при необходимости я мог читать исходные тексты и понимать что в них написано. А порой и модифицировать по необходимости.
Может раскажите, чему такому можно было научиться на МФ, чему было нельзя было научиться на персоналках?
Тому каким должен быть сервер. Сервер на персоналке это нонсен что понятно даже из слов.
Более того, МФ это не сервер, а сервер серверов и не потму что виртуальные машины, которые как бы есть на персоналках, а и без виртуальных машин в z/OS (MVS). Ничего похожего на z/OS в мире персоналок нет. Более менее иммитация MVS дана в Dockers и Containers, но буквально и то и другое (т.е. с Линуксом) есть в z/OS.
Или для вас программирование -- это перетаскивание контролов на формочках в визуальном редакторе
А что еще есть, например, в визуальном редакторе Visual Basic? Неужели все также "перетаскивание контролов на формочках "?
Я начал программировать под Windows в 1993-ем, а под OS/2 в 1995-ом.
Поделиться своим пониманием программирования под Windows и под OS/2? Что Вы использовали там и там? Интересно.
OS/2 ничего не светит, было понятно еще в 1994-ом, хотя OS/2 Warp была хороша, но не то, чтобы принципиально лучше WinNT 3.51.
Windows NT 3.51 .... was released on May 30, 1995
Да Вы прям пророк.
Если бы Вы читали меня внимательно, то я писал что оценивал Java как пользователь продуктов изначально написанных на SmallTalk и потом переписанных на Java.
Т.е. вы, как пользователь программ на Java, оцениваете возможности Java как языка программирования. Мощно, внушаить!
Да не писал.
Ну вот я не писал програм ни на C#, ни на Haskell. Так я и не рассуждаю на тему того, что они каким-то другим языкам уступают или нет.
Тому каким должен быть сервер.
К программированию это относится косвенным образом. Не говоря уже о том, что для большого числа предметных областей (embedded, desktop, mobile, web front-end) это понимание не нужно чуть меньше чем совсем.
Сервер на персоналке это нонсен что понятно даже из слов.
Особенно смешно это звучит сейчас, когда (наверное) 99% серверов в Интернете крутятся на x64 серверах, являющихся прямыми наследниками IBM XT.
А что еще есть, например, в визуальном редакторе Visual Basic? Неужели все также "перетаскивание контролов на формочках "?
Понятия не имею, мой опыт программирования Visual Basic ограничивается VisualBasic for Application, в котором в то время визуального редактора не было. Но суть в том, что перетаскивание контролов -- это далеко не все, что есть в программировании. Да и когда мне доводилось заниматься GUI, то быстро выяснилось, что возюкание мышкой в дизайнере форм не самый удобный способ это делать (по крайней мере в тех задачах, которые были).
Поделиться своим пониманием программирования под Windows и под OS/2?
"Понимания"? Что вы вкладываете в это слово в данном контексте?
В Windows был свой API, в OS/2 -- свой. Язык программирования и там, и там один и тот же, в моем случае C++, прикладные алгоритмы и структуры данных не зависили от ОС. Были свои нюансы в том в API и возможностях ОС (типа классов приоритетов для тредов и количества этих самых приоритетов), но это именно что нюансы.
Windows NT 3.51 .... was released on May 30, 1995
Не вижу противоречий. OS/2 Warp вышла раньше (чем NT 3.51) и, емнип, требовала меньше аппаратных ресурсов, чем тогдашние Windows NT (уже не помню какая там была актуальная нумерация, 3.5 или еще какая-то). При этом работала гораздо надежнее и стабильнее и обеспечивала реально многозадачную среду, в отличии от Windows 3.1/3.11. Но даже тогда было понятно, что не светит OS/2 потеснить Windows. А когда в 1995-ом у меня появилась возможность поработать и в Windows 95, и в NT 3.51, то это убеждение только подтвердилось, т.к. по надежности и уровню поддержки настоящей вытесняющей многозадачности NT если и уступала OS/2, то некритично.
Т.е. вы, как пользователь программ на Java, оцениваете возможности Java как языка программирования. Мощно, внушаить!
Да, с пользовательской точки зрения. В данном случае по критерию производительности программ на нем. Что в этом не так?
....для большого числа предметных областей (embedded, desktop, mobile, web front-end)...
Я сказал "серсер". Т.е. нечто иное чем Вы перечислили. О чем Вы?
Особенно смешно это звучит сейчас, когда (наверное) 99% серверов в Интернете крутятся на x64 серверах, являющихся прямыми наследниками IBM XT.
Смеятся тут нечему. Крутятся в интернете кластеры серверов. Т.е. отдельная х64 не в состоянии даже выполнять один программный сервер, например, базу данных. Их запрягают десятками, сотнями, тысячами в одну упряжку.
МФ не только в состоянии в единственном числе выполнить любую нагрузку, но как правило выполняет множество программных серверов в одном имидже ОС: БД, сервер приложений, файл сервер, принт сервер, Веб сервер. И не по одному а по сколько хачется.
ERP приложение, которое я поддерживал со стороны системы, для компании с 10000 работнтками (не все конечно имели доступ, но многоие и не только в бухгалтерии, но и на станциях (атомных станциях)) выполнялось на одном МФ со всеми программными серверами имевшимися в этом приложении, а также Development, QA, Training, Sandbox-ы, на весьма скромном МФ, очень далком от топового.
х64 это кирпичи в стене здания, а МФ это здание. Так понятнее?
В Windows был свой API, в OS/2 -- свой. Язык программирования и там, и там один и тот же, в моем случае C++, прикладные алгоритмы и структуры данных не зависили от ОС. Были свои нюансы в том в API и возможностях ОС (типа классов приоритетов для тредов и количества этих самых приоритетов), но это именно что нюансы.
Т.е. с Вашей точки зрения программиста С++ между Windows и OS/2 нет разницы. Тогда почему же: "OS/2 ничего не светит, было понятно еще в 1994-ом". Напомню Ваша фраза начиналась с того что Вы программировали и там и там. Т.е. можно было ожидать что имеено из опыта программирования будет сделан вывод. Но получилось что таки нет.
И снова понеслось:
Но даже тогда было понятно, что не светит OS/2 потеснить Windows. А когда в 1995-ом у меня появилась возможность поработать и в Windows 95, и в NT 3.51, то это убеждение только подтвердилось, т.к. по надежности и уровню поддержки настоящей вытесняющей многозадачности NT если и уступала OS/2, то некритично.
Я согласен с тем что во многом (опять же с точки зрения пользователя) NT в начале 2000-х в общем сравнялся с OS/2. Windows 95 был вне игры совсем.
Чем бы был сейчас OS/2 если бы его ИБМ продолжил развивать мы сказать не можем. Я считаю что они бы полностью сранялись потому что на х86-64 есть вполне досигаемый предел развития ОС и он уже давно достигнут. Уже давно новые версии Windows это лишь новый интефейс и по другому разложенные приложения по папкам, и по другому запутанный Settings.
C МФ все обстоит иначе. Все системы МФ написаны ИБМ. Вот картинка для наглядности.
z/OS флагманская система для IBM Z. Только она использует все возможности процессора МФ и возможности эти главным образом под z/OS и разработаны. Новые возможности появляются по мере появления новых поколений МФ. Последним дополнением был AI. Эти возможности сразу имплементируются в z/OS, версии которой синхронизированны с поколениями МФ. Повторить этот путь не возможно. Средств не хватит ни у кого. Да и зачем. Все уже и так есть. Правда не для России. Увы. Но и это не шоу стопер на самом деле.
Виртуальные машины это z/VM. z/OS может работать и на виртуальной машине, но это абсолютно не обоснованно было бы ничем. потому что z/OS это в определенном смысле и есть виртуальные машины, только для одной ОС - MVS. С пользовательской же точки зрения кроме MVS есть еще Unix и Linux. Но z/OS это гораздо больше чем виртуальные машины.
Что в этом не так?
Если вы сравниваете производительность программ так и сравнивайте производительность программ, а не языки программирования.
Я сказал "серсер". Т.е. нечто иное чем Вы перечислили. О чем Вы?
О том, что в 1990-е для подавляющего большинства программистов знания о "серверах" были чуть менее чем бесполезны. А для многих это и сейчас так. Что не мешает им решать сложные задачи.
Т.е. отдельная х64 не в состоянии даже выполнять один программный сервер, например, базу данных.
Точно уверены? Вот точно-точно? Хоть бы параметры этой самой "базы данных" озвучили...
Их запрягают десятками, сотнями, тысячами в одну упряжку.
И десятками тысяч. Что в итоге дает горизонтальное масштабирование такой величины и за такую небольшую цену, что МФ от IBM, предполагаю, и не снилась.
Но мы уходим от темы, а именно -- программисты из 90-х занимаясь варворством на дохлых PC-ках довели ситуацию до того, то МФ от IBM на общих масштабах нужно разглядывать в микроскоп. Да, где-то они все еще рулят и педалят, но погоды не делают. Т.е. прогрессом их вынесло на обочину. Ну и зачем, спрашивается, программистам из 90-х нужно было на эти самые МФ оглядываться с придыханием? Вопрос риторический.
х64 это кирпичи в стене здания, а МФ это здание. Так понятнее?
Нет.
Т.е. с Вашей точки зрения программиста С++ между Windows и OS/2 нет разницы. Тогда почему же: "OS/2 ничего не светит, было понятно еще в 1994-ом".
Потому что руководители направления OS/2 из IBM не бегали по сцене и не кричали "Developers, Developers, Developers!!!" А Балмер бегал и кричал. И MS привлекли такое количество разработчиков под Windows, что OS/2 нечего было ловить.
Конечным потребителям была совершенно фиолетова техническая совершенность потрохов OS/2. Им нужен был полезный софт, а полезный софт массово писали под Windows, а не под OS/2. Именно это и похоронило OS/2. И это мне лично было понятно еще в 1994-ом.
Я согласен с тем что во многом (опять же с точки зрения пользователя) NT в начале 2000-х в общем сравнялся с OS/2
В начале 2000-х OS/2 была уже никому (даже IBM) ненужным ископаемым. NT стала хорошей системой еще в середине 1990-х и OS/2 выигрывала лишь тем, что могла лучше работать на машинах с относительно дохлыми процессорами и 8Mb RAM. Но уже на 16Mb, не говоря уже про 32Mb, разницы не было. Т.е. технический прогресс и этот аргумент из под ног OS/2 выбил.
Я считаю что они бы полностью сранялись потому что на х86-64 есть вполне досигаемый предел развития ОС и он уже давно достигнут. Уже давно новые версии Windows это лишь новый интефейс
Судить по возможностях современных x86-64 по Windows -- это не менее мощно, чем судить о Java по производительности программ на Java в конце 1990-х.
Конечным потребителям была совершенно фиолетова техническая совершенность потрохов OS/2
Да и не так чтобы она была совершенна. Так, просто норм, заметно лучше 95-й. В частности, в полуоси 16-битный код выполнялся нативной подсистемой, как и в Вин95, и мог вполне увалить всю полуось. А в NT, например, он выполнялся в изолированной виртуальной машине.
Будем считать дискуссию исчерпаной. Как и должно быть каждый остался при саоем мнении.
Поделиться своим пониманием программирования под Windows и под OS/2?
Из того, что запомнилось до сих пор:
В Windows (как и до этого в MS-DOS, как и в X-ах, если не ошибаюсь) отсчет координат шел от верхнего левого угла экрана (и от верхнего левого угла текущего окна). А вот в OS/2 Presentation Manager -- от левого нижнего. Т.е. в OS/2 PM координаты x и y шли как в школьной геометрии. Что, однако, при выводе текста на русском языке или при рисовании в окне технологических схем/чертежей, оказывалось менее удобно -- мы то читаем слева направо и сверху вниз, логично было бы и координаты в таком же направлении отсчитывать. Но в OS/2 PM нужно было делать дополнительный пересчет;
в OS/2 PM была плохая "привычка" не создавать окна, если программист ошибся с перечислением ресурсов окна. Например, для фрейма (вроде бы так в OS/2 PM называлось окно с заголовком, иконкой и меню) нужно было задать ID для меню и для иконки. И если программист по недосмотру какой-то из этих ресурсов в ресурсном файле не определил, то фрейм просто не создавался без какой-то внятной диагностики. А найти такую ошибку, особенно по первости, было непросто. Это когда уже шишки были набиты возникла привычка проверять содержимое ресурсного файла и такие ошибки стало искать проще. Но вот под Windows такой проблемы не было -- даже если ID иконки или меню оказался неправильным, окно все равно создавалось, просто чего-то в нем не хватало и ты сразу видел чего именно. Плюс к тому, в Windows не было деления окон на фреймы и не фреймы, что мне казалось более логичным, чем подход из Presentation Manager.
Хочу так же эмоционально и непонятно про коммерческую победу Ethernet над другим прекрасными и правильными сетевыми технологиями.
А в этой статье не хватает воспоминаний про продукцию фирмы Digital и ее распространенных клонов на территории СССР. Весь универ за Электроникой-60 просидел с самодельной сетью и цветным графическим монитором.
Вспомнилось... в 90х подрабатывал на сортировке компьютерного сэкондхэнда - приходила одна или две фуры с б/у компами из Цюриха (там сидел один эмигрос, знакомый сэкондхенда - для утилизации после апгрейда продавал через своего знакомого так как там старый комп просто так не выбросить. Списанные компы он получал или бесплатно или даже за копеечку себе в карман).
Приезжали вполне бодрые середнячки, не топ, но часть нормальные пентиумы. Нужно было все причесать, убрать лишнее, поставить нужное, винду 95 и вперед, в коммисионку. Такса была 10 баксов за комп. Когда начал подработку, там работал один паренек, только со школы.
Что удивило.
Первое, это большая корзина для мусора, по пояс, набитая картами и устройствами SCSI - на вопрос почему это здесь, ответили "мы знаем что это, суем сюда - мы только IDE используем". Для домашнего рабочего компа разрешили взять чего хочу, взял пару контролеров, 7 хардов и один CD writer, Plextor. Богатая коллекция MFM / RLL дисков тоже лежала, иногда баловался с их разборкой - глянуть что внутри.
Много было стриммеров, почти в каждом компе, от мелких на 40 мб, типа дискет, в гнездо 5", до полноразмерных внешних. Помню, топчан из них собрал.
Как то зашел в комнату набитую до потолка разными IBM PS/2. Оказалось, спроса нет, OS/2 нормальные люди не пользуются, пока складываем сюда. Да, и харды и прочее у них бесполезное - другие разъемы.
Наверное хорошая система была, PS/2, но скорее всего, цена была конская, не для частных лиц и почему то даже конторы в Цюрихе перестали ее использовать. А так звучит интересно:
Сентябрь 1996. OS/2 Warp 4.0 (кодовое название Merlin). В этой версии включено полное управление голосом, средства голосового ввода текста, встроенные механизмы Java, OpenDoc, средства работы в глобальной сети Internet и другие передовые технологии, разработанные корпорацией IBM. Сильно изменен дизайн системы и более удачно (относительно предыдущих версий) проработана сетевая подсистема.
PS/2 и OS/2 лично не пробовал, ни одного рабочего компа как то не получилось там собрать, просто мысль не возникала, думаю зря, нужно было покопаться, реанимировать но у меня не было ни опыта, ни софта для этого.
PS/2 и OS/2 лично не пробовал, ни одного рабочего компа как то не получилось там собрать, просто мысль не возникала, ....
OS/2 устанавливался на любой компьютер, начиная с 386.
Показательна фраза "даже мысль не возникала". Молодежи обычно свойственно любопытство к чему то новому, необычному.
В середине 80-х когда я уже был спецом по ОС ЕС меня заинтересовала СВМ ЕС. Никто тогда в Челябинской области ей не пользовался (соврал, один НИИ пользовался уже). К концу 80-х практическми все ВЦ Челябинской области работали на СВМ ЕС и БОС ЕС. К эту приложили руку я и мои ребята из бюро системного программирования регионального центра по обслуживанию ЕС ЭВМ.
С 1993 года, уже работая на меткомбинате, я дал добро на освоение OS/2. В 1995, уже не работая на меткомбинате, я перевел одну фирмочку с Windows на OS/2. Вскоре меня оттуда уволили - их крыша в Москве использовала Windows.
Не было спроса, вот и не интересовала. Искать спецом и ставить ее - хватало другой работы. Оживлял всякий хлам, со стримерами повозился, принтеры чинил. Примеров OS/2 такая интересная , давай поставим не было. Вот Силикон графикс впечатлил, разок попробовал. AS 400 тоже необычная железяка оказалась, даже отремонтировал ее, условно (выяснил нерабочий слот). AIX не впечатлил - сервер как сервер. Под Солярис один раз кастомизировал код на проекте (с) - сдал работу и забыл.
Это (ps/2) в Чехии было, в судетах - занесло туда случайно, можно сказать, пинком, на пару лет. В Канаду я в 99 приехал, но через пять лет раскрутил на заказы на аутсорс работодателя и свалил.
Я тоже (как Вы по-видимому знаете) в Канаде с 99 года. Но так и осел (через "е"), хотя уже все сроки выхода на пенсию прошли и уже получаю две пенсии, работая.
Ну и как продолжаешь аутсорсить?
20 лет стажа в Канаде есть - 4 года поработал на full time работах (две по специальности программистом а первые две для поддержки тонуса работягой пока язык подтягивал) и в начале 2000х открыл корпорацию в Онтарио, чтоб работать контрактником, через нее и жил - деньги в основном зарабатывал не в Канаде - в основном в штатах, пару раз по рабочей визе заезжал по просьбе клиента, была специфика, но в основном как контрактор. Компанию закрыл в конце 2021, в январе 2022 получил dissolution letter от CRA - выдохнул, тяжело вести дела удаленно, да и закон нарушал - директора резидента не было последнее время. С 2018 работал как ИП в России и в Канаде не был. С 2022 начались сложности с платежами но через прокладок платежи проходят за долю малую.
Мотался туда сюда поначалу, а потом на удалёнке 15 лет - в России мне комфортнее, уход за родителями требовался
Товарищ ни строчки не написал на Java, но мнение имеет, ага.
У ИБМ была VisualAge for SmallTalk и многие другие программные среды. VB был ублюдком по сравнению с VAS. Но сложилось так что «рынок выбрал» г‑но.
Г-ном тут был как раз смолток, а не васик.
К васику кроме "это не круто" никаких претензий-то и придумать нельзя.
А ибмский смолток просто никому оказался не нужен.
Вот так это было, а не так как Вы пишите.
Родную грамматику когда осилим, брат ?
У меня по русскому языку и литературе в атестате должны были быть тройки. Но учителя сжалились и написали четверки. Они знали что я хочу поступать в технический ВУЗ и помогли с средним баллом по атестату.
Вообщем то это не понадобилось когда я в первый раз поступал потому что я шел как производственник (чтобы было понятно я вместо 9-10 классов заканчивал школу рабочей молодежи 9-11 классы, а как учились в этих школах думаю понятно) и прошёл бы даже с тройками.
Но во второй раз (меня отчислили на первом курсе за пьянку и драку) это помогло, потому что я уже шел без льгот. Чтобы не подумали что я дебил, сообщаю, ВУЗ я закончил с красным дипломом и почетным дипломом Студенческого Научного Общества. У меня было место на кафедре для продолжения научной работы, но меня призвали в Советскую Армию (1979-1981).
Нет, я не оправдываюсь, но "прошу понять и простить". Пожалуйста.
И что не так в данном конкретном примере?
Visual Basic имеет с BASIC примерно столько же общего, сколько Java с JavaScript.
Совпадающий кусок названия и какие-то общие синтаксические конструкции.
Сравнивать VB с теми бейсиками, на которых учили школьников, это как сравнивать космолёт и самокат.
Visual Basic имеет с BASIC примерно столько же общего, ....
Золотые слова. А я вот всё жду когда кто-нибудь из новых поколений ИТ-шников сможет сравнить Basic в Visual Basic с SmallTalk в ViaualAge. Да и визуалы не грех сравнить, на конец 90-х, например. Тогда в 90-х визуалы те были очень-очень разные. VusualAge был визуал, Visual Basic был имитацией визуального программирования. Я с обоими имел дело. Как сейчас дела у Visual Basic не знаю. Может он заполнил пропасть, может нет.
Афффтор защищает свою точку зрения на основе своего жизненного и профессионального опыта, но автор почему то не считается с тем, что у каждого свой опыт, а частности в конце 80х-начале 90х, когда Basic уже почти 10 лет коммерческим продуктом за рубежом, в СССР (переходящим в РФ) только начали появляться так называемые бейсик-компиляторы (клавиатура со встроенным вычислительным блоком, который подключался к ламповому монитору 12") с названием БК0010 и 0011. Про возможность купить домой такой БК даже не говорю - её не было. Оснащали НИИ и (к счастью) школы, в одной из которых я и стал тем самым "дикарём программирования", с помощью учителя информатики, совмещающего работу в НИИ со школой (большой ему поклон). Это я к тому, что когда в СССР народ ещё баловался Спектрумами (в т.ч. самособоанными) и занимались в школе на БК, там (например в Канаде) уже сформировалось поколение людей, которые больше 10 лет уже пользовались коммерчески успешными продуктами типа 8-битные компьютеры Commodore 64, ZX Spectrum, Atari, Apple II, MSX и др.
Это я написал у тому, что продукты нацеленный на профессиональное использование OS/2 использовался профессионалами по назначению, а для любителей OS/2 был сложным в освоении и поэтому со временем любители-дикари пересели сначала на более дешёвую MS-DOS и его последователя Windows.
Про возможность купить домой такой БК даже не говорю - её не было.
Была. У пары моих знакомых были дома БК0010. Это было где-то в 1990-1991 годах.
однокурсник УКНЦ домой приобрел как раз примерно в это время, занятная была машина, с двумя процессорами (один обслуживал периферию).
Другой однокурсник отпахал лето в стройотряде и купил БК (что то около тысячи руб стоил).
я паял довольно долго спектрумы и аоны на продажу (увы, подработка), первое время толкучки гоняли (при СССР), затем Тушино/Митино, все стало легально, Закончил с убер спектрумом на 128К если память не подводит, с трехдюймовым дисководом и TD DOS.
A потом взял IBM PC AT 286 с мегом памяти и понеслось (сборка ПК на заказ). На этой 286 и диплом сдал (расчетная оптимизация умножителя частоты).
Ностальгия...
... диплом сдал (расчетная оптимизация умножителя частоты).
Мой диплом назывался: "Растровый, цифровой, запоминающий осциллограф". Как видно из названия это цифровая электроника. Были цифровые значения, хранящиеся в памяти, и был вывод этого на экран телевизора Горизонт-107.
Все было материализованно в сиде нескольких плат утыканных интегральными схемами: логики (И/ИЛИ-НЕ), регистрами и памятью (8 микросхем по 256 бит в каждой). Все советское. 1979 год.
Ностальгия. Да.
Афффтор защищает свою точку зрения на основе своего жизненного и профессионального опыта, но автор почему то не считается с тем, что у каждого свой опыт, а частности в конце 80х-начале 90х, когда Basic уже почти 10 лет коммерческим продуктом за рубежом, в СССР (переходящим в РФ) только начали появляться так называемые бейсик-компиляторы (клавиатура со встроенным вычислительным блоком, который подключался к ламповому монитору 12") с названием БК0010 и 0011. Про возможность купить домой такой БК даже не говорю - её не было. Оснащали НИИ и (к счастью) школы, в одной из которых я и стал тем самым "дикарём программирования", с помощью учителя информатики, совмещающего работу в НИИ со школой (большой ему поклон). Это я к тому, что когда в СССР народ ещё баловался Спектрумами (в т.ч. самособоанными) и занимались в школе на БК, там (например в Канаде) уже сформировалось поколение людей, которые больше 10 лет уже пользовались коммерчески успешными продуктами типа 8-битные компьютеры Commodore 64, ZX Spectrum, Atari, Apple II, MSX и др.
Очень хороший поинт (сорри за мой английский).
Мой опыт вовсе не ограничивается ИБМ мэйнфрэйм. Я достаточно много поработал и с не-мэйнфрэймовскими технологиями. И я не свою точку зрения защищаю, а делюсь более чем 40-летним опытом в ИТ в самых разных направлениях в двух странах: СССР/Росиия (15 лет) и Канада (25 лет). И моя цель рассказать и показать то чего ныненшнее поколение российских ИТ-шников было, по разным обстоятельствам, лишенно .
В конце 80-х начале 90-х в СССР все предприятия использовали ЕС ЭВМ. На них стояли многопользовательские и многозадачные операционные системы, языки программирования типа ПЛ/1, Фортран. Существовали промышленные системы управления производствами, банками и т.п..
Из Вашего же сообщения сладывается такое представление как будто в СССР не было ничего и компьютеры только только начали появляться. Я полагаю так и подается в российских учебных заведениях начиная с детских садов и заканчивая университетом имени Баумана.
А 80-м и 90-м предшествовали 70-е. Я как раз обучался в конце 70-х и нам давали Алгол (отличнейшный язык для введения в программирования), Фортран, Минск-22, ЕС ЭВМ. Это при том что моя специальность была далека от чисто компьютерной сферы.
Что касается Канады. Многие с кем я общался в начале 2000-х рассказывали что у них даже в школах были ИБМ мэйнфрэймы и изучали они Фортран, Кобол (кстати в отличии от Канады (Запада), где Кобол до сих пор широко используется, в СССР в основном на производстве использовался ПЛ/1).
В канадской компании где я отработал 25 лет, несмотря на то что они с 1995 года начали уходить с МФ, еще в 2010-е говорили что их ERP класса система будет всегда на МФ. Эта система три года как в облаках. Это слулось потому что вендор этой системы выпустил новую версию "не совместимую" с МФ (в кавычках потому что на самом деле эту версию можно и на МФ выполнять), так они в документах написали. Но другие пользователи этой системы, из США, не пошли на эту версию и остались на последней версии совместимой с МФ.
Применение МФ в ИТ на Западе достаточно распространено. И у ит-шников западных есть все возможности и перспективы для получения работы в области МФ, где кстати меньше конкуренции и стабильнее условия наима. В таких компаниях где есть МФ молодежь хочет работать и работает.
Иначе произошло в новоявленной стране Россия. Произошел разрыв поколений и опыта переносимого из поколения в поколение. Более того Россия полностью потеряла компетенции в целом, огромном секторе ИТ - в бэкэнде на МФ. Китай и Индия эти компетенции сохраняют и поддерживают. Причем Китай начал позже чем СССР работать в этом направлении.
Помню в начале 2000-х в учебном центре ИБМ в Торонто я постоянно встречал забавные группы студентов, я бы сказал приехавших из деревень. Это были молодые китайцы, которых обучале ИБМ-вским технологиям. На всех семинарах ИБМ по МФ, которых я посетил за 25 лет немало, всегда была молодежь.
Я считаю на уровне государства российского должен быть поставлен вопрос возврата утеренных компетенций. Без этого Россию нельзя считать сколько-нибудь значимой в области ИТ. А еще лучше было бы попытаться создать свою платформу и ОС приближенную по возможностям к ИБМ МФ. Т.е. возродить ЕС ЭВМ.
Это укрепило бы ИТ-шную независимоть и ИТ в целом. А сейчас Россия даже без МФ зависима и, если так дальше пойдет, то у России будут больште проблемы из-за этой зависимости. Все разговоры про отечественный софт и ОС это пока бла-бла-бла. Локализованный Postgre Pro. Ну-ну.
Некоторые, наиболее интересные сообщения от читателей, на которые я даб развернутые ответы, добавляются к статье в виде дополнений.
На данный момент имеется два дополнения. Будут по-видимому еще. Интересные сообщения появляются в комментрариях.
Больше спасибо за статью ответ.
У меня конечно в два раза меньше опыта в ИТ чем у вас, но буквально сразу как начал работать нутром почувствовал, что Мастдай и весь софт мелкомягких ущербное г-но написанное с основной целью - зарабатывать бабло, а не решать задачи/проблемы.
И уже тогда стал интересоваться Unix like системами. Сперва долго сидел на FreeBSD, а потом перешёл на Linux т.к. он стал более распространенным.
И не жалею!
П.с. полностью с вами согласен по поводу развития своих собственных компетенций и написания свой ОС
полностью с вами согласен по поводу развития своих собственных компетенций и написания свой ОС ...
Для начала хотя бы нужно быть в курсе, а значит иметь, все компетенции используемые в других странах в ИТ.
Это может сделать только государство российское. Для этого нужна мощная воля и понимание. Частному предпринимательству это не по силам, да и не нужно. Не нужно пока кто-то (опять же государство) не создаст для этого возможности. А в России это отставлено на усмотрение частному предпринимательству.
И уже тогда стал интересоваться Unix like системами. Сперва долго сидел на FreeBSD, а потом перешёл на Linux т.к. он стал более распространенным.
Я думаю если бы вам довелось столкнуться с z/OS, а это совокупность MVS и Unix (я Вас уверяю вы смогли бы работать в z/OS с Unix без особых трудностей), то Вам эта ОС тоже понравилась бы.
Кстати многие Unix спецы (в смысле Solaris, HP-UX, AIX) не очень воспринимают Linux. Я не знаю почему, но это так.
Я сам столкнулся с MVS только в Канаде, когда уже 15 лет проработал c предтечей MVS - ОС 360, и главным образом с СВМ ЕС (виртуальные машины) где была гостевая система типа ОС 360.
Кое что я знал о MVS конечно, но то с чем я столкнулся, начав в полный рост работать с MVS, меня потрясло и потрясает до сих пор. А это не много ни мало 20 лет (первые 5 лет я был DB2 DBA).
В z/OS есть, и довольно давно, z/OS Container Extensions (zCX):
https://www.ibm.com/support/z-content-solutions/container-extensions/
IBM® z/OS® Container Extensions (IBM zCX) makes it possible to integrate Linux on IBM Z applications with z/OS. Application developers can develop and data centers can operate popular open source packages, Linux applications, IBM software, and third-party software together with z/OS applications and data. IBM provides a Linux distribution configured to run Docker
An open platform that developers and system administrators can use to build, ship, and run distributed applications.
CE. IBM supplied support code will simplify installation and operation. Clients can participate with their own Linux applications that can easily be packaged in Docker format and deployed in the same way as open source, IBM, and vendor packages. Container Extensions runs on IBM z14™ and later systems.
У ИБМ была VisualAge for SmallTalk и многие другие программные среды. VB был ублюдком по сравнению с VAS. Но сложилось так что «рынок выбрал» г‑но.
Ну вот я на первом же абзаце поперхнулся. Кто видел оба продукта, никогда бы так не написал. Если OS/2 была просто скучная, но довольно крепко собранная система, то VisualAge, это нечто, опередившее своё время. Неповоротливый пыхтящий диском монстр, выдающий исполняемые программы такого размера, что и сейчас не стыдно, а тогда у вас хеллоуворлд был по весу сравним с Экселем того времени. Вы могли прямо в 1995-м ощутить вкус этак 2015-го.
И да, это же IBM. Это энтерпрайз, и цены там на лицуху от килобакса начинались, если память не изменяет. Напомню, первая Delphi, на голову превосходящая Visual Age практически по всем параметрам, будь-то порог входа, продуктивность разработки, возможности библиотек и возможности визуального/текстового программирования, быстродействие и размеры скомпилированных приложений, стоила $50, VB стоил похожих денег, если не ошибаюсь, или вообще был бесплатным приложением к MS Office. Действительно, почему же рынок не выбрал VisualAge?
Неповоротливый пыхтящий диском монстр, ...
Не знаю на чем Вы мучали диск, но на пентиуме с парой SCSI дисками (1995 год) исполняемая программа компилировалась достаточно быстро. После компиляции, на 486 компе, исполняемая программа бегала достаточно бойко. Претензий от пользователей не было. Причем скомпилированная в OS/2 программа выполнялась и на Windows 95.
Что касаемо размера то для того времени это было вполне приемлемо и не было проблемой. Может Вы слишком много фичей включали в наборо для программирования. Вспоминается что перед программированием нужно было набрать нужные фичи для собственно того что будет использовано и соответственно можно было перегнуть палку.
В любом случае Вы сильно драматизируете.
Конекретно в чем Dephi на голову превосходил VisualAge можете объяснить, или это бла-бла-бла?
Не знаю на чем Вы мучали диск, но на пентиуме с парой SCSI дисками (1995 год) исполняемая программа компилировалась достаточно быстро
Вот именно. "Достаточно быстро" на топовой машине с топовой же дисковой подсистемой. Сколько таких разработчиков тогда в мире было?
Претензий от пользователей не было
Ваши пользователи сам покупали ваши программы с поддержкой, или это были корпоративные пользователи, которые просто использовали то, что им дали?
Что касаемо размера то для того времени это было вполне приемлемо и не было проблемой.
Простите, но хеллоуворлд от VisualAge без архивации не влезал даже на 3.5" дискету - основной носитель информации в те годы. Это было приемлемо внутри корпоративной сети, но было совершенно неприемлемо для каких-то публичных каналов дистрибьюции софта.
Конекретно в чем Dephi на голову превосходил VisualAge можете объяснить, или это бла-бла-бла?
Я в принципе перечислил, но могу и подробнее объяснить:
Цена. Раз в двадцать дешевле
Порог входа: Delphi 1 включала подробную справку и по языку, и по библиотекам, и по API операционной системы. Попробуйте Smalltalk изучить по VisualAge
Скорость компиляции. Достаточно быстро, это сколько минут на Пентиуме? Delphi на 486-м компилировала со скоростью несколько десятков тысяч строк в секунду.
Производительность приложений. Visual Age for Smalltalk был, помнится, плюс-минус как бейсик, местами даже и хуже. Delphi генерировала полностью нативный код, не такой оптимизированный, как у компиляторов С++, но тем не менее, на порядок более быстрый
Работа с данными: Delphi, это живой коннект к базам данных прямо в design time, вы их видите в дизайнере, можете манипулировать выборками и отображением. Это экономило массу времени.
Работа с кодом: все эти визуальные штуки в Delphi имели прямое отображение в код, и вы могли переключаться между кодом и дизайнером. В VisualAge без вариантов - окошки, окошки, окошки.
Тут даже не надо пытаться сравнивать. Visual Basic победил VisualAge по цене и простоте, а Delphi, это в принципе продукт намного более высокого класса, и архитектурно спроектированный более профессионально и без багажа легаси, и в первых своих версиях ещё и качественно выполненный.
Вот именно. "Достаточно быстро" на топовой машине с топовой же дисковой подсистемой. Сколько таких разработчиков тогда в мире было?
Ну во-первых, это была не Канада, а Россия, город Челябинск. Во-вторых, машина была сервер (ИБМ-ский пентиум с двумя SCSI дисками по 2 ГБ если память не изменяет) используемый совместно небольшой группой менеджеров перевозок. На сервере стояла OS/2, VisualAge for SmallTalk, и DB2/2 - база данных приложения, используемого этими менеджерами приложением, которое я разрабатывал на этом сервере. Т.е. отдельной машины у меня не было.
Ваши пользователи сам покупали ваши программы с поддержкой, или это были корпоративные пользователи, которые просто использовали то, что им дали?
Я состоял в штате этой фирмы, на зарплате. Сам создал их локальную сеть зарядил все компы, включая сервер, написал приложение для производственной работы (до этого они делали все на бумаге), создал все отчеты для бухгалтерии и другие (для крыши). На все ушло 9 месяцев, после чего меня уволили и перешли на Windows. Их крыша в Москве использовала Windows.
Простите, но хеллоуворлд от VisualAge без архивации не влезал даже на 3.5" дискету - основной носитель информации в те годы.
Примерно в тоже время что я описывал выше, я писал приложение для лругой фирмы и переносил испольный файл на... 3.5" дискете (1.44 MB). Было ли это архивированно, не помню. Ну и если да, то что? Это катастрофа какая то что ли?. SmallTalk это не классический Бэйсик и не С, SmallTalk генерировал нечто для виртуальной машины, и это ООП технология программирования, если конечно это что-нибудь Вам говорит.
Я в принципе перечислил, но могу и подробнее объяснить:
Перечисленно было, но ничего технического. Эмоции.
1 пропускаем, no comments, не технично.
2 Именно по VisualAge документации я и изучал SmallTalk. Ничего другого у меня и не было. Отличная документация. Великолепное введение в ООП, референсы, библиотеки. Вы какое имеете представление об этом? Слышали от кого-то или держали в руках?
3 Скорость нужна при ловле блох (руская народная мудрость). В процессе разработки и отладки не требовалось каждый раз как хотелось выполнить программу ее компилировать. В редакторе нажимаешь кнопку "Run" и программа бежит до ошибки. Компилировать исполняемый модуль требовалось не каждый день даже. Сколько минут это делалось 5 или 10 не имело никакого значения. Я не буду гадать сколько, не помню, но это никогда не было проблеиой в виду редкости этой работы. Запускаешь компиляцию и продолжаешь делать другую работу. Смотришь - компиляция закончилась. Может в Delphi это надо было делать чаще? Я не знаю.
4 Понятно. Про SmallTalk Вы ничего не знаете. Помнится Вам что-то по-видимому другое. SmallTalk, поскольку это ООП язык, иными словами интерпретатор, не может генерировать нативный код по определению. Тоже что и Java, .NET. Компилятором генерируется байт код исполняемый виртуальной машиной SmallTalk. Естественно это будет не так быстро как нативный код, но тогда Delphi не про ООП. Почуствуйте разницу. Когда программы ИБМ написаные на SmallTalk (Visual Explain for DB2) перевели в Java, то на той же моей машине где SmallTalk летал (это уже было в Канаде) Java тормозила не по детски.
5 ViaualAge также работал с БД. Видить данные в дизайн тайм вовсе не обязательно. Я не буду говорить как было с этим в VisualAge, но у меня наряду с VisualAge были и другие тулзы для БД. БД была DB2/2. Запросы к ней писались в дизайн тайм визуально. Главное для дизайна это видеть таблицы и их структуры чтобы построить запрос. Это было. Данные можно видить другим тулзом или в тестовой прогонке программы, что делались как мы помним нажатие кнопки "Run" в дизайнере.
6 Ложь. Просто ложь.
Сonclusion: вы не знаете о чем говорите.
Ну во-первых, это была не Канада, а Россия, город Челябинск. Во-вторых, машина была сервер
Вообще не принципиально. Вас таких, имеющих неплохой сервер под среду разработки, была дюжина на весь Челябинск, да и в условном Чикаго не то, чтобы сильно много таких было. Delphi прекрасно работала на самом заурядном компьютере у вас в офисе и дома, а VB - вообще на любом утюге.
Было ли это архивированно, не помню. Ну и если да, то что? Это катастрофа какая то что ли?
Это не катастрофа. Это неприятный недостаток. И всё остальное в отдельности - не катастрофы, а недостатки разной степени неприятности. Но вот ответьте мне на простой вопрос: у вас есть система, имеющая кучу недостатков, и есть система, этих недостатков не имеющая. Зачем вам выбирать ту, которая вся в недостатках?
Вы какое имеете представление об этом? Слышали от кого-то или держали в руках?
Я работал в банке, и у нас был VisualAge, как и куча всего-всего от IBM, и пара AS/400 в центре всего. Я не был непосредственно разработчиком VisualAge, но был знаком. Поэтому в чём-то могу ошибаться, но в целом послевкусию своему вполне доверяю. И полагаю, учили вы его всё-таки не по встроенной документации, а по толстому IBM-овскому талмуду, купленному за отдельные деньги.
4 Понятно. Про SmallTalk Вы ничего не знаете. Помнится Вам что-то по-видимому другое. SmallTalk, поскольку это ООП язык, иными словами интерпретатор, не может генерировать нативный код по определению
В смысле, не знаю? Я как раз это и написал. И это - ещё один не катастрофический, но крайне отстойный недостаток. Delphi сочетала в себе и всю мощь ООП, и генерацию быстрого и компактного нативного кода.
3 Скорость нужна при ловле блох (руская народная мудрость)
5 ViaualAge также работал с БД. Видить данные в дизайн тайм вовсе не обязательно
Вот именно. Это неважно, это не обязательно, это не нужно, это можно потерпеть. Вот из всего этого калека VAS и состоял. Почему же он, такой хороший, проиграл рынок? Вообще не понятно :)
Сonclusion: вы не знаете о чем говорите.
Сеньор, я прекрасно понимаю вашу точку зрения. Компьютерная игра, которую я запомнил ярче всех - Galaxian, а IDE - третий Турбо Паскаль начала 1980-х, ещё с редактором, не далеко ушедшим от vi. Но просто я реалист, и стараюсь адекватно оценивать софт в рамках своего времени, а не слепо топить только лишь потому, что я эту софтину когда-то полюбил. Вот третий Турбо-Паскаль в 1983-м, это была вполне современная классная IDE. А VisualAge 3 в 1995-м - корявый отсталый мастодонт. Вы его полюбили лишь потому, что нормальные IDE не знали.
И полагаю, учили вы его всё-таки не по встроенной документации, а по толстому IBM-овскому талмуду, купленному за отдельные деньги.
Коечно. А как еще может профессионал изучать новые средства работы на компьютерах. Пр запискам на стенках туалетов?
Не за отдельные деньги, а за коробку с CD и всеми сопутствующими официальнвми документами.
Delphi сочетала в себе и всю мощь ООП, и генерацию быстрого и компактного нативного кода.
Сомнаваюсь что вообще какая-либо ООП там была, т.к. ООП и компактный нативный код это несовместимо.
Почему же он, такой хороший, проиграл рынок?
Я не торгаш с рынка. Ничего сказать не могу. И уже объяснял что OS/2 и все под ним пошло под нож в угоду коалиции для рыночной возни и боданий с Микрософтом. Там еще была тема Terminal Computer. Они стояли в учебном центре ИБМ в Торонто. Темы этой тоже нет. Много что было исчезло. Ит этим сильно отличается от других областей человеческой деятельностию.
ИБМ все наработаное на OS/2 перевел в Linux и Java. Это их продукты и их право так делать. Все остальное это бла-бла-бла.
Дискуссия окончена. Спасибо.
Delphi и его нативный виндовый фреймворк VCL работают на ООП. Где использовалась и система асинхронных сообщений и синхронных событий. Где можно было реализовать и MVP и MVVM подходы и прочее, прочее прочее.
Коечно. А как еще может профессионал изучать новые средства работы на компьютерах.
Вот видите. А Delphi 1 можно было изучить из самой Delphi, имея только общие навыки о программировании, полученные на чём-то другом.
Сомнаваюсь что вообще какая-либо ООП там была, т.к. ООП и компактный нативный код это несовместимо.
Я не торгаш с рынка. Ничего сказать не могу
Позвольте мне вас же и процитировать, но теперь уже это не предположение, а факт:
Сonclusion: вы не знаете о чем говорите.
Вот видите. А Delphi 1 можно было изучить из самой Delphi, имея только общие навыки о программировании, полученные на чём-то другом.
Да, вижу. Для меня это значит что Delphi это простой как умывальник инструмент. Как гаячный ключ. И более.
Позвольте мне вас же и процитировать, но теперь уже это не предположение, а факт:
все равно это плагиата. Да и в защиту Delphi как флагмана ООП движения Вы ничего так и не сказали. Нечего?
Да, вижу. Для меня это значит что Delphi это простой как умывальник инструмент.
Я в этом случае даже вас поддержу. Delphi именно простой инструмент. Его разработчики смогли создать намного более мощный инструмент, при этом на простой и элегантной архитектуре, тем он был и прекрасен в своё время. Но тем не менее, то, что его ещё и изучить по встроенной документации было можно, это в первую очередь говорит о качестве встроенной документации.
Да и в защиту Delphi как флагмана ООП движения Вы ничего так и не сказали. Нечего?
Вы что услышать хотели-то? Я вам написал как есть, что вы не знаете, о чём говорите. Другие читатели вон тоже ответили в таком же духе. Мне за вас погуглить "OOP Delphi" для заполнения пробела в ваших знаниях, что ли?
Мне за вас погуглить "OOP Delphi" для заполнения пробела в ваших знаниях, что ли?
Мне что за Вас погуглить "OOP Delphi vs. SmallTalk" для заполнения дыр в Ваших знаниях, что ли?
In essence, Delphi offers a more traditional, compiled approach to OOP with strong visual development tools, while Smalltalk provides a unique, highly dynamic, and pure object-oriented environment emphasizing live programming and exploration.
Мне что за Вас погуглить "OOP Delphi vs. SmallTalk" для заполнения дыр в Ваших знаниях, что ли?
Простите, но во-первых, в вашей ИИ-цитате прямо написано, что Delphi предлагает традиционный подход к ООП с использованием сильных средств визуальной разработки. Что же здесь вас могло натолкнуть на мысль, что в Delphi с ООП что-то не то?
Во-вторых, написано, что Smalltalk предлагает уникальную динамичную объектно-ориентированную среду. Вот только "уникальный" - не значит ни "правильный", ни "хороший", ни "эффективный". Это значит, "не такой как все". А навигация по объектам даже в скомпилированном и запущенном коде в Delphi появилась ещё в 1997-м, чего ИИ-ассистент гугла, увы, не знает.
Дружная здесь компашка дельфистов живет как я погляжу. Вас плюсуют, меня минусуют. Но это говорит лишь о том что, таки да, ViaualAge в России не то чтобы не прижился, а вообще не существовал.
И это называется прогрессивный класс ИТ-шников, которым даже льготную ипотеку государство дает. Да при таком раскладе и дворники из азии запишутся в ИТ-шники.
Не стыдно брать такую ипотеку? А, коллеги, те кто брал? Чем Вы лучше токаря или металлурга или врача или учителя? Ничем. Без вас страна не загнется, а вот без перечисленных вполне может.
Я не агитирую за ViaualAge, но надо признавать реалии даже о тех ИТ-шных направлений которые не попали из прошлого в настоящее. Надо уменить отделять мух от котлет.
По теме прокомментирую позже.
Дружная здесь компашка дельфистов живет как я погляжу. Вас плюсуют, меня минусуют
А вам не приходила в голову мысль, что может быть, это не мы все там из одной секты, а просто вы неправы?
Но это говорит лишь о том что, таки да, ViaualAge в России не то чтобы не прижился, а вообще не существовал.
Смотрите, в РФ была очень хитрая особенность рынка в 1990-е: цена на любой софт была нулевая. И это нивелировало один из главных недостатков VisualAge - цену, совершенно не соответствующую его возможностям. И даже с таким шикарным бонусом в итоге он оказался никому не нужен. Ни там, ни здесь.
Потому что он действительно был аутсайдером. Да, он был "уникальным". Я бы сказал, курьёзным. Архитектурно любопытным. Но в продакшене людям не нужна любопытная архитектура. Людям нужна эффективная архитектура, архитектура, которая обеспечит и продуктивность разработки, и продуктивность рантайма. Смоллтолк был посредственным в первом и совсем на дне во втором. И это естественно, т.к. он по своей архитектуре изначально тянул свой рантайм, по сути, виртуальную машину. Причём виртуальную машину образца 1980-х, когда не знали ни JIT-компиляции, ни хотя бы оптимизации байт-кода. Отсюда и неприличные размеры, отсюда и неприемлемо низкая производительность.
Я не агитирую за ViaualAge
Ага. А я Бэтмэн.
Смотрите, в РФ была очень хитрая особенность рынка в 1990-е: цена на любой софт была нулевая. И это нивелировало один из главных недостатков VisualAge - цену, совершенно не соответствующую его возможностям.
VisualAge был доступен в виде бесплатной CD для попробовать в течении 90 дней "trail period"). После 90 дней его можно было переустановить и будет еще 90 дней. Т.е. ViaualAge тоже был бесплатным (кстати а Вы знаете какие были цены на OS/2 продукты и 90-е?). С официальной покупкой предоставлялся "ключ" с которым трайл становилась постоянной.
Именно с этого, бесплатно, я и начинал знакомится с VisualAge for SmallTalk. СD с Delphi рядом со мной не проносилась вообще. Где было ее достать я не знал, и впервые услышал про Delphi я скорее всего уже в Канаде, от минчанина.
Покупка была осущественна фирмой которая приняла мои предложения по построению и написанию их системы на продуктах ИБМ (сервер) и OS/2. Фирма была маленькая, но богатая, для них это не было проблемой чтобы купить. Настолько не проблема что они соскачили с созданного мною (под давление со стороны Москвы, в их системе) меньше чем через год.
Кстати вы сами говорили что знали ViauakAge весьма поверхностно. Как при этом Вы может судить была ли цена соответствующей или нет?
И это естественно, т.к. он по своей архитектуре изначально тянул свой рантайм, по сути, виртуальную машину. Причём виртуальную машину образца 1980-х, когда не знали ни JIT-компиляции, ни хотя бы оптимизации байт-кода. Отсюда и неприличные размеры, отсюда и неприемлемо низкая производительность.
Тут какой то бред пошел. Что это за "виртуальная машина образца 1980-х,"?, Да, SmallTalk программы выполнялись на виртуальной машине, но во-первых, это была не "образца 1980-х" машина, во-вторых, это была машина SmallTalk и того года которого была вресия на дистрибутивном CD.
Вы явно не в теме про SmallTalk. Поэтому я предлагал закончить дискуссию, но Вы решили продолжить. Что ж я не против. Поэтому наберите в гугле "SmallTalk JIT" и прочитайте:
Smalltalk, a foundational object-oriented language from the 1970s and 1980s, pioneered Just-in-Time (JIT) compilation for high-level languages by translating bytecode to machine code on demand and caching the results for performance. Innovations from Smalltalk research, including JIT techniques, influenced later languages like Java and its HotSpot virtual machine, as well as Self, a dialect that achieved impressive speeds through JIT compilation. Modern Smalltalk implementations, such as Squeak, continue to use fast VMs with JIT capabilities for efficiency.
VisualAge был доступен в виде бесплатной CD для попробовать в течении 90 дней "trail period").
Лицензия роялти-фри на коммерческую разработку к этому разве прилагалась?
Как при этом Вы может судить была ли цена соответствующей или нет?
Хм. Посмотреть возможности в целом и попробовать на уровне "хеллоуворлда" - это более чем достаточно для принятия решения "стоит оно денег или нет". Вы же кровать в магазине как-то покупаете, посидев на ней и посмотрев внешне, а не берёте её предварительно в аренду на три месяца? Вот, и с IDE оно так же работает.
. Что ж я не против. Поэтому наберите в гугле "SmallTalk JIT" и прочитайте:
Ну видите, даже вы не знаете, а гуглите :) А я чуть дальше погуглил, чтобы убедиться, это я забыл что-то, или не очень забыл. Оказывается, не очень забыл - лишь некоторые частные реализации СмоллТолка включали JIT-компиляцию, а в основном это был просто байт-код и виртуальная машина. Какой подход использовался конкретно в VAS, я не нашёл, но судя по производительности приложений на уровне VB или даже ниже, JIT-компиляцией там и не пахло, или она была сама по себе очень паршивой.
И не бросайтесь громкими словами а-ля "бред", пожалуйста. Ошибаться в мелочах, это не бред. Бред - это когда взрослый дядька ведёт дискуссию методами школьника-тролля.
Лицензия роялти-фри на коммерческую разработку к этому разве прилагалась?
Тамже написана "trail trial period". Как всегда опечатался. Trial значит "пробный".
Посмотреть возможности в целом и попробовать на уровне "хеллоуворлда" - это более чем достаточно для принятия решения "стоит оно денег или нет".
А вот так вот просто. Тогда как Вы можете укорять меня в том что я не имею права судить о языках? В том что я ни строчки не написал на Java (может это были не Вы)ю Так можно все языки перепробовать и про все сказать писал.
Ну видите, даже вы не знаете, а гуглите
Ну давйте помогу. Попробуем набрать в Гугле "VisualAge for SmallTalk JIT". Оппа:
VisualAge for Smalltalk, developed by IBM (and later by Instantiations, Inc. as VA Smalltalk), incorporated a Just-In-Time (JIT) compiler.
A JIT compiler is a crucial component in modern virtual machine-based environments like Smalltalk. It dynamically translates bytecode (or intermediate code) into native machine code during program execution, rather than requiring a separate compilation step beforehand. This allows for optimized performance, as the JIT can make optimizations based on runtime information and specific hardware characteristics.
но судя по производительности приложений на уровне VB или даже ниже, JIT-компиляцией там и не пахло, или она была сама по себе очень паршивой.
Приложение былор "Hello World"?
И не бросайтесь громкими словами а-ля "бред"
Бред - это когда взрослый дядька ведёт дискуссию методами школьника-тролля.
Я привык называть вещи своими именами. Вас я лично не оскорблял, написано было про написаное Вами. Будьте аккуратнее и не торопитесь тролить.
Тамже написана "
trailtrial period". Как всегда опечатался. Trial значит "пробный".
Ну то есть, не прилагалась, и разрабатывать софт для продакшена на этом легально было нельзя. Ок.
А вот так вот просто. Тогда как Вы можете укорять меня в том что я не имею права судить о языках?
Потому что я
а) пробовал СмоллТолк
б) понимаю, как работает СмоллТолк
в) прекрасно понимаю, как работают другие популярные языки, которые я знаю очень хорошо
Вы
а) пробовали СмоллТолк
б) (возможно) понимаете, как он работает
в) крайне мало понимаете в других языках.
Знаете, сложно объективно судить, какой пирожок вкуснее, если вы скушали только один, а остальные даже и не укусили не разу.
Ну давйте помогу. Попробуем набрать в Гугле "VisualAge for SmallTalk JIT".
Без проблем. Я этого не сделал лишь потому, что этот факт несущественный. Я знаю, что он жутко медленный, а если он жутко медленный ещё и с JIT, это сразу +20 очков Гриффиндору к его отстойности.
Или второй, более лицеприятный для него вариант (и, кстати, вполне вероятный), что JIT там банально появилась не в 1995-м, а лет этак через несколько, как и в Java. Опять же таки, это уже не суть важно, но если вам интересно, можете погуглить, заодно расскажете.
Я привык называть вещи своими именами
Ок, прекрасно. Запишите в блокнотик:
Ошибка оппонента - не бред.
Мнение оппонента, которое вам категорически не нравится - не бред.
Вас хватило только на ИИ часть? Дальше не смоглось пройтись.
Вот буквально под ИИ частью, из дискуссии англоговорящих коллег (я ни в коем случае не считаю что это аргумент за "идеальность" Смаллтолка, это скорее про то что не всё на чем написало "ООП" и в самом деле ООП. И еще это пример как надо профессионально вести подобные дискусии):
«Чистый» ООП, такой как Smalltalk, радикально отличается от любого современного языка и представляет собой совершенно уникальную парадигму программирования. Подробнее см. на сайте https://en.wikipedia.org/wiki/Smalltalk. Не только каждый фрагмент данных является объектом, но и каждый элемент потока управления — методом. Операторы if, циклы, операторы return и т. д. — всё это методы: вместо if a then b else c у вас ifTrue:[ b ] ifFalse:[ c ] (скобки обозначают «блок кода», он же замыкание). В нём нет глобальных функций, всё является методом, включая операторы (например, gcdOfThisAnd: b вместо gcd(a, b)). Весь язык состоит только из литералов, блоков кода, объявлений переменных и методов, вот и всё. Smalltalk также чрезвычайно динамичен и поддерживает рефлексию практически всеми мыслимыми способами. Вы не только можете получить доступ, просмотреть и переопределить каждый отдельный метод (включая методы управления потоком выполнения и примитивные операторы, описанные выше), ваша программа может изменять IDE, среду выполнения и даже саму себя. Поскольку IDE сама по себе является программой Smalltalk, а ваш код — это «образ», который загружается и непрерывно выполняется в «среде» Smalltalk, той же среде, в которой работает IDE (вместе с любыми другими программами Smalltalk), что очень похоже на виртуальную машину.
Конечно, у такого подхода есть множество серьёзных недостатков, включая проблемы с безопасностью, производительностью, возможность создания очень плохого дизайна и спагетти-кода и т. д. Но он также очень хорош, и некоторые из его возможностей весьма полезны. Например, бесшовная интеграция вашей программы и IDE позволяет вам по-настоящему настроить IDE для поддержки написания вашей программы, например, добавляя собственный пользовательский интерфейс, не говоря уже о том, что это упрощает реализацию действий кода и отладку. А возможность проверять и переопределять всё, включая примитивные структуры и закрытые члены других классов, позволяет проводить трассировку, что в традиционном языке программирования практически невозможно. Насколько мне известно, основные дистрибутивы SmallTalk — это https://squeak.org/ и https://pharo.org/. Я слышал, что Pharo более сложный и «практичный», в то время как Squeak более образовательный и удобный для новичков. Но оба они придерживаются своих корней: «всё есть объект или метод», экстремальной рефлексии и интегрированной среды выполнения/IDE.
«Чистый» ООП, такой как Smalltalk
Я вполне обоснованно считаю "каноном" ООП тот его вариант реализации, который популяризовал во всём мире С++. Он практичен, он удобен, он понятен, он эффективен, он гибок. В Delphi, об которую мы тут ломаем копья, ООП аналогичное. Да, там наложены особенности синтаксиса Паскаля, но "под капотом" структуры данных, обеспечивающие работу ООП, такие же, как в С++. Ну, точнее, там аж два варианта реализации ООП, есть ещё легаси от борландовского Паскаля, но я его не беру в расчёт, основной там С++-совместимый.
Что касается Смоллтолка, это всего лишь любопытный, но непрактичный эксперимент из 1970-х, когда ещё учёные, а не только программисты, пытались нащупать идеальный язык программирования. В случае Смоллтолка не нащупали, его парадигма "вообще всё объекты и их методы, а общаемся мы сообщениями" (откуда же и название пошло) так же полезна при разработке, как поддержка 65535 мышей в ОС. Она никаких реальных проблем не решает, зато:
у такого подхода есть множество серьёзных недостатков, включая проблемы с безопасностью, производительностью, возможность создания очень плохого дизайна и спагетти-кода и т. д
Ну а преимущества сугубо эфемерные:
Например, бесшовная интеграция вашей программы и IDE позволяет вам по-настоящему настроить IDE для поддержки написания вашей программы, например, добавляя собственный пользовательский интерфейс
Это легко делается и в Delphi, если вдруг нужно. Там код вашей программы компилируется на лету, и та его часть, которую вы хотите, чтобы исполнялась в design time, например, для добавления какого-то функционала в IDE, будет исполняться. И как оказалось, для этого не нужна ни странная архитектура, ни медленная виртуальная машина. Достаточно хорошей модульности и скоростного компилятора, работающего быстрее, чем вы печатаете.
А возможность проверять и переопределять всё, включая примитивные структуры и закрытые члены других классов, позволяет проводить трассировку, что в традиционном языке программирования практически невозможно
Эти парни, как и вы, не знают, о чём говорят. Очень легко показывать преимущества какой-то одной платформы, если ты имеешь околонулевые познания относительно других платформ.
В случае Смоллтолка не нащупали, его парадигма "вообще всё объекты и их методы, а общаемся мы сообщениями" (откуда же и название пошло) так же полезна при разработке, как поддержка 65535 мышей в ОС
Справедливости ради: в Ruby реализован тот самый ООП из SmallTalk, только в нормальном синтаксисе и исходники лежат в обычных файлах, а не в образах виртуальных машин, как это было в SmallTalk-овских средах.
Этот самый ООП с паре с синтаксисом Ruby дает удобные инструменты для реализации eDSL. Чем, собственно, Ruby и хорош (и за счет чего получился Ruby-On-Rails, а за счет RoR свою долю хайпа получил и Ruby).
Ценой же является медленное исполнение кода. Плюс, за счет динамики и возможности построения eDSL-ей под задачу, в большом объеме Ruby-нового кода сложнее разбираться, чем в коде на статически типизированных языках.
Так что я бы не сказал, что идеи SmallTalk-а умерли. Они трансформировались. Но с быстрым кодом, имхо, они не совместимы в принципе. Просто по своей природе. А автор статьи, как я понимаю, SmallTalk для формошлепства использовал, да еще и в режиме "в одно лицо, без коллег". В таких условиях ни скорость исполнения, ни ресурсоемкость, ни удобство коллективной работы в расчет можно и не брать.
Справедливости ради: в Ruby реализован тот самый ООП из SmallTalk, только в нормальном синтаксисе ...
Что Вы имеете в виду? C многими языками знаком, включая те на которых не написал ни строчки, но более ясного, чистого, лаконичного и понятного синтаксиса, который не расписан в многостраничных главах, а помещается на паре-тройке страниц я не встречал. Многостраничным является документ с описанием стандартных классов и их методов. Но это уже дополнительный материал про то что можно использовать готовым для применения, а не изобретать велосипед каждый раз.
Так что я бы не сказал, что идеи SmallTalk-а умерли.
Да и SmallTalk не умер. Под другими названиями продолжает жить.
Но с быстрым кодом, имхо, они не совместимы в принципе. Просто по своей природе.
Нет никакой такой природы по которой код настоящих ООП языков не может быть достаточно быстрым. Кроме того ни один язык заявляющий об ООП-ности, не сможет обогнать код с языка компилируемого в машинные команды.
Много ли Вы знаете современных языков в ходу у программистов которые не имеют виртуальную машину для байт-кода?
Хотя бы для переносимости, как минимум, это имеет смысл, но читый ООП это далко не про производительность и соревнования по скорости. Это для самого программирования.
А автор статьи, как я понимаю, SmallTalk для формошлепства использовал, да еще и в режиме "в одно лицо, без коллег". В таких условиях ни скорость исполнения, ни ресурсоемкость, ни удобство коллективной работы в расчет можно и не брать.
Не знаю что Вы имеете в иду под "формошлепством", но и без этого понимаете Вы не правильно.
Да я писал всего и пишу мои программы в одиночку. И это, кстати, гораздо интереснее чем подлаживаться под хрен знает что и кого. Вру, писал в команде из двух человек. Я и еще один. Но второй писал вспомогательные программы и передовал их мне для пакетирования с моими.
Все равно из этого никак не может следовать что c VisualAge for SmallTalk "ни скорость исполнения, ни ресурсоемкость, ни удобство коллективной работы в расчет можно и не брать". Это ничем не связанные вещи. Не пытайтесь натягивать сову на глобус. Не получится.
Что Вы имеете в виду?
Что синтаксис там Паскале-подобный, а не вот это вот ifTrue и ifElse.
Нет никакой такой природы по которой код настоящих ООП языков не может быть достаточно быстрым.
Нет, поэтому C++ и Eiffel и не тормозят. А SmallTalk и Ruby динамичекие, у них тормоза в ДНК.
Много ли Вы знаете современных языков в ходу у программистов которые не имеют виртуальную машину для байт-кода?
Давайте подсчитаем: С, С++, Go, Rust, Swift + Objective-C, ObjectPascal, Ada. Можно для экзотики еще и Haskell с OCaml-ом добавить. Ну и Eiffel, раз уж экзотику в теме про ООП упомянули.
но читый ООП это далко не про производительность и соревнования по скорости.
Повторюсь: С++ и Eiffel прекрасно себя чувствуют в области производительности. А то, что вы со своим SmallTalk-ом никогда производительный код и не писали, так это не проблема ООП ни разу.
Да я писал всего и пишу мои программы в одиночку.
И почему я не удивлен?
Что синтаксис там Паскале-подобный, а не вот это вот ifTrue и ifElse.
Слышал про Паскаль, но никогда не интересовался даже. Я вообще всю жизнь занимался только тем что нужно для работы.
Только однажды лет десять назад, от несего делать, прочитал две книги про системное программирования на Интел и Виндовз. От Интел и от Микрософт.
Про историю ИТ люблю читать и прочитал много.
Нет, поэтому C++ и Eiffel и не тормозят. А SmallTalk и Ruby динамичекие, у них тормоза в ДНК.
Вы оборвали мой текст в цитате. Намерено? Вот он: "Кроме того ни один язык заявляющий об ООП-ности, не сможет обогнать код с языка компилируемого в машинные команды."
Давайте подсчитаем: С, С++, Go, Rust, Swift + Objective-C, ObjectPascal, Ada. Можно для экзотики еще и Haskell с OCaml-ом добавить. Ну и Eiffel, раз уж экзотику в теме про ООП упомянули.
Я ничего не знаю ни про один из перечисленных. Но здесь нет Java и .NET.
А то, что вы со своим SmallTalk-ом никогда производительный код и не писали, так это не проблема ООП ни разу.
Вы этого не можете знать, поэтому Вы наговариваете. Т.е. врете. Не хорошо.
И почему я не удивлен?
Интересно почему? Опять гадость какую то про меня придумали.
Вы оборвали мой текст в цитате. Намерено? Вот он: "Кроме того ни один язык заявляющий об ООП-ности, не сможет обогнать код с языка компилируемого в машинные команды."
Я тоже не стал комментировать эту цитату, т.к. не знаю, кто и зачем её написал, но эта цитата откровенно глупая. А мне не хотелось обзывать глупцом незнакомого человека, не зная его мотивов. Может быть, он что-то другое хотел сказать, или то ошибка переводчика.
Почему цитата глупая? Ну, если взять аналогию, в ней написано примерно как "Ни один автомобиль, заявляющий об использовании бензинового двигателя, не может обогнать легковые машины". ООП и способ компиляции, это совершенно ортогональные свойства, и ООП-языков, непосредственно компилирующих в машинные команды, едва ли не больше, чем тех, которые используют промежуточный байт-код.
Вы этого не можете знать, поэтому Вы наговариваете. Т.е. врете.
Ну, я вот знаю. И не вру :)
Я тоже не стал комментировать эту цитату, т.к. не знаю, кто и зачем её написал, но эта цитата откровенно глупая. А мне не хотелось обзывать глупцом незнакомого человека, не зная его мотивов. Может быть, он что-то другое хотел сказать, или то ошибка переводчика.
Фраза написана мной. И вы прекрасно это знаете. Вы обозвали меня глупцом без каких-либо аргументов.
Приведите аргументы, или извинения. До того я не в диалоге с Вами. Пока.
P.S.
Почему цитата глупая? Ну, если взять аналогию, в ней написано примерно как "Ни один автомобиль, заявляющий об использовании бензинового двигателя, не может обогнать легковые машины". ООП и способ компиляции, это совершенно ортогональные свойства, и ООП-языков, непосредственно компилирующих в машинные команды, едва ли не больше, чем тех, которые используют промежуточный байт-код.
А вот это вот глупость, выросшая из непонимания что такое компиляция в машинный код и что такое байт-код. Удивлен, что Вы этого не знаете, но не очень учитывая другие Ваши "странности".
Фраза написана мной. И вы прекрасно это знаете.
Не обратил внимание, прошу прощения, думал, вы это тоже нагуглили и процитировали. С вами был бы менее резок, честное слово :)
Приведите аргументы
Пожалуйста:
Почему цитата глупая? Ну, если взять аналогию, в ней написано примерно как "Ни один автомобиль, заявляющий об использовании бензинового двигателя, не может обогнать легковые машины". ООП и способ компиляции, это совершенно ортогональные свойства, и ООП-языков, непосредственно компилирующих в машинные команды, едва ли не больше, чем тех, которые используют промежуточный байт-код.
Я-то могу подписаться под каждым написанным тут словом.
А вот это вот глупость, выросшая из непонимания что такое компиляция в машинный код и что такое байт-код.
Я прекрасно знаю, что такое байт-код, и что такое компиляция в машинный код, благо, работаю с этим практически ежедневно последние пару десятилетий. Мяч на вашей стороне, объясняйте, что вы этим хотели сказать.
"Кроме того ни один язык заявляющий об ООП-ности, не сможет обогнать код с языка компилируемого в машинные команды."
Это заявление из категории "ничто не может двигаться быстрее света". Только вот свету и не нужно двигаться быстрее, он и так движется с максимальной скоростью. Нативные ОО-языки (вроде C++, Eiffel, D, Ada 95) и так компилируются непосредственно в нативный код. В отличии от динамических SmallTalk-ов с Ruby, в которых JIT может сработать, а может и нет.
Я ничего не знаю ни про один из перечисленных.
Но мнение о том, что "настоящий ООП только в SmallTalk" имеете. Поэтому чем дальше, тем большим клоуном выглядите.
Но здесь нет Java и .NET.
Вы просили те, что компилируются в нативный код. Java транслируется в байт-код и не обязательно этот байт-код будет JIT-ится. А .NET -- это и не язык программирования вообще, это платформа.
Вы этого не можете знать, поэтому Вы наговариваете
Так поделитесь: что такого производительного вы делали на SmallTalk и во сколько раз обгоняли на бенчмарках аналоги на нативных языках, типа C++.
Интересно почему?
Потому что из ваших слов за три киллометра несет отсутствием опыта сколько-нибудь серьзной разработки ПО.
Нативные ОО-языки (вроде C++, Eiffel, D, Ada 95) и так компилируются непосредственно в нативный код.
Что такое нативный код?
...тем большим клоуном выглядите.
Извинитесь или попадете в игнор.
Но мнение о том, что "настоящий ООП только в SmallTalk" имеете.
Я про это уже подробно писал Вам лично. Вы что не читаете сообщения других? А нет, понял, Вы читаете, но то что Вам не подходит пропускаете мимо ушей.
А .NET -- это и не язык программирования вообще, это платформа.
Хорошо C#. Так Вас устроит? Могли бы и сами догадаиться.
Так поделитесь: что такого производительного вы делали на SmallTalk и во сколько раз обгоняли на бенчмарках аналоги на нативных языках, типа C++.
Уже делился, Вы не все читаете, Вы все знаете без этого.
Бенчмарками занимаются бездельники, которые ничего сами делать не умеют, а только сравнивают.
Потому что из ваших слов за три киллометра несет отсутствием опыта сколько-нибудь серьзной разработки ПО.
Вы этого не знаете и знать не можете. Возьмите свои слова обратно или в игнор пойдете.
Итог: извинитесь и возьмите слова обратно. Тогда продолжим.
Нативный код - код, исполняемый напрямую процессом, без посредников и прочих ухищрений.
И я так же предполагал. Ссылка в статье на Вики про Делфи написаное "native code" приводит к статье с названием "Machine code". Не знаю когда и почему появился этот термин "native". Всегда был термин машинный код. Четко и ясно говорящий обо всем.
Делфи генерирует машинный код. Отлично. Тогда в Делфи нет, например, dynamic typing. Довольно важного элемента ООП. И возможно других плюшек полноценного ООП. Что Вы про это можете сказать?
Тогда в Делфи нет, например, dynamic typing. Довольно важного элемента ООП.
Не могу утверждать, важный ли это элемент ООП, как по мне, не важный, но тем не менее, динамическая типизация в Delphi есть, см. Delphi variants. Разработчики компиляторов давным-давно научились реализовывать все былые преимущества интерпретаторов прямо на уровне машинного кода. Сегодня вы можете даже код запущенного приложения изменять в отладчике, и компилятор (при соблюдении ряда условий, естественно) перестроит выполняющееся приложение незаметно для вас, и продолжит выполнение с той же точки.
Динамическая типизация никак не относится к ООП. Тем не менее, в Делфи есть специальные динамические типы: Variant и TValue
Я вполне обоснованно считаю "каноном" ООП тот его вариант реализации, который популяризовал во всём мире С++.
Докажите это как Пифогор одноименную теорему.
его парадигма "вообще всё объекты и их методы, а общаемся мы сообщениями"
Без этого любой язык в описании которого есть слово "объект", но не выдерживается парадигма должен называться псевдо-ООП языком. Можно даже ввести уровни псевдости. И соревноваться у кого уровень выше.
Эти парни, как и вы, не знают, о чём говорят.
Первый признак сектанства.
Докажите это как Пифогор одноименную теорему.
Без проблем. Скажите мне, какую из парадигм ООП вы хотите найти в С++, и я вам покажу пример - и вы увидите, что ООП там реализована в полной мере. А что это канон, вам покажет рейтинг TIOBE - первые строчки занимают либо языки с ООП аналогичной или производной от С++ модели, либо процедурные языки.
Без этого любой язык в описании которого есть слово "объект", но не выдерживается парадигма должен называться псевдо-ООП языком
Без этого любой язык, в описании которого есть слово "объект", но не выдерживается парадигма, никому ничего не должен. Частный случай реализации ООП в СмоллТолке, это просто эксперимент. Неудачный, как показала практика.
ООП, это вообще не про процент содержания "объектности" в языке. Это стиль написания приложений, парадигмы написания. А язык, это набор инструментов, позволяющих использовать на выбор какие либо парадигмы. Вот современные языки в массе своей "из коробки" поддерживают три стиля - процедурное программирования, ООП и функциональное программирование. Некоторые, более ограниченные, поддерживают какие-то две парадигмы. SmallTalk годится только для одной :)
Скажите мне, какую из парадигм ООП вы хотите найти в С++, и я вам покажу пример - и вы увидите, что ООП там реализована в полной мере.
Хороший заход, рыцарский, достоин уважения.
Я не буду корчить из себя полиглота по ООП языкам, а просто погуглю в англоязычном секторе и с переводом помещу здесь. Для пробы (гугл на уровне ИИ по строке "smalltalk vs. c++ oop paradigm"):
Smalltalk и C++ представляют собой различные подходы к парадигме объектно-ориентированного программирования (ООП), особенно в плане чистоты и реализации основных концепций ООП: Чистая ООП-парадигма Smalltalk: Всё есть объект: Smalltalk — «чистый» объектно-ориентированный язык, то есть все значения, включая числа, логические значения и даже сами классы, рассматриваются как объекты. Примитивных типов в традиционном понимании нет. Передача сообщений: Вычисления в Smalltalk происходят посредством передачи сообщений между объектами. Объекты взаимодействуют, отправляя сообщения, которые запускают выполнение методов, связанных с принимающим объектом. Это делает акцент на динамической диспетчеризации и позднем связывании. Динамическая типизация и гибкость выполнения: Smalltalk является динамически типизированным, с проверкой типов во время выполнения. Это обеспечивает значительную гибкость для программирования и отладки в режиме реального времени в интегрированной среде разработки. Одиночное наследование: Smalltalk в первую очередь поддерживает одиночное наследование, способствуя более простой и согласованной объектной модели.
Гибридная объектно-ориентированная парадигма C++: Гибридный язык: C++ — это многопарадигменный язык, сочетающий процедурное программирование с объектно-ориентированными функциями. Он включает в себя как примитивные типы данных, так и объекты. Классы и объекты: C++ делает акцент на классах как на шаблонах для создания объектов, которые инкапсулируют данные и поведение.
Статическая типизация и проверка во время компиляции: C++ является статически типизированным языком, со строгим контролем типов, выполняемым во время компиляции. Это направлено на раннее выявление ошибок и повышение производительности. Множественное наследование и низкоуровневое управление: C++ поддерживает множественное наследование, позволяя классу наследовать от нескольких базовых классов, хотя это может привести к сложностям, таким как «проблема ромба». Он также предлагает низкоуровневое управление памятью и прямое взаимодействие с оборудованием, от которых Smalltalk обычно абстрагируется.
Краткий обзор ключевых различий: Чистота: Smalltalk — чисто объектно-ориентированный язык, в то время как C++ — гибридный. Типизация: Smalltalk — динамически типизированный язык, C++ — статически типизированный. Модель вычислений: Smalltalk использует передачу сообщений; C++ — вызовы функций и методов. Наследование: Smalltalk обычно использует одиночное наследование; C++ поддерживает множественное наследование.
Гибкость против контроля: Smalltalk отдает приоритет гибкости выполнения и простоте разработки, тогда как C++ предлагает детальный контроль над системными ресурсами и производительностью.
Без этого любой язык, в описании которого есть слово "объект", но не выдерживается парадигма, никому ничего не должен.
Слово "объект" не делает язык языком ООП. В вышеприведенной цитате говорится: "C++ делает акцент на классах как на шаблонах для создания объектов". Шаблон (template) это не совсем объект, или совсем не.
А язык, это набор инструментов, позволяющих использовать на выбор какие либо парадигмы.
А какие Вы знаете парадигмы появлявшиеся в области программирования (их было несколько) и как бы Вы объяснили их смену. Или точнее появление одна за другой, вплоть до отрицания значимости парадигм в настоящее время (это если верить Вам (цитата), к чему я тоже склоняюсь, но за всех говорить не могу).
Уточняющий вопрос: Любые парадигмы? Если да то все же почему после опробования одних эволюция шла к другим. Откуда они появлялись если все парадигмы "хороши"?
Спасибо.
просто погуглю в англоязычном секторе и с переводом помещу здесь.
Знаете, в чём минус современного ИИ гугления? Вы не сможете валидировать результат. ИИ вам даёт ответ, основываясь на том. что он смог вытянуть из кучки верхних результатов поиска, а верхние результаты поиска, они сейчас зависят от ранжирования сайта в гугле, а не от их релевантности.
Давайте несколько моментов:
Примитивных типов в традиционном понимании нет
Это делает акцент на динамической диспетчеризации и позднем связывании. .
Это недостаток, это удар по производительности ради... да в общем-то ради ничего.
Динамическая типизация
Это в общем случае недостаток языка, когда снижение требований к программисту разменивается на качество кода. Впрочем, в случае СмоллТолка не могу утверждать наверняка, не помню уже, как конкретно оно там реализовано. Есть два внешне похожих подхода, собственно динамическая типизация и динамическое выведение типов. Первое - отстой, второе безопасно и удобно, их часто путают, особенно ИИшечки, но какой из них в СмоллТолке, я не знаю.
Одиночное наследование: Smalltalk в первую очередь поддерживает одиночное наследование
Это не достоинство и даже не отличие. Все языки хоть с какой-либо поддержкой ООП, умеют в одиночное наследование.
Возможность множественного наследования, это уникальная особенность С++, но она казалась полезной в 1980-е, сейчас же это антипаттерн, сродни оператору goto. Оно есть, но на практике его не используют, по крайней мере на трезвую голову.
Он также предлагает низкоуровневое управление памятью
Он разрешает ручное управление памятью. Как опцию, если вам это нужно. В то же время вы обычно полагаетесь на объекты с автоматическим управлением временем жизни.
и прямое взаимодействие с оборудованием
Вот это вообще неправда. Это зависит не от языка, а исключительно от операционной системы. В MS DOS - да, там другого способа работы с железом бы и не было. В современных десктопных/серверных ОС никакого взаимодействия с оборудование у вас не будет, ни в С++, ни в Бейсике. По крайней мере, если вы пишете код, который будет выполняться в пользовательском окружении, а не в ядре ОС.
В вышеприведенной цитате говорится: "C++ делает акцент на классах как на шаблонах для создания объектов". Шаблон (template) это не совсем объект, или совсем не.
Здесь перепутаны мухи и котлеты. Шаблоны - это четвёртая парадигма программирования, которую поддерживает С++, метапрограммирование. Тоже плюс-минус уникальная штука для С++. И это не про ООП.
Уточняющий вопрос: Любые парадигмы? Если да то все же почему после опробования одних эволюция шла к другим
Потому что у всех парадигм есть слабые и сильные стороны, нет одной серебряной пули. Процедурное программирование самое простое и наглядное, но при росте кодовой базы раньше всех делает навигацию по коду затруднённой. Это всего лишь три уровня иерархии, по сути - подпрограмма, файл и модуль/библиотека.
ООП значительно расширило размеры кодовой базы, которую может осознавать разработчик, добавив, с одной стороны, промежуточный иерархии, объект, с другой стороны, сделав этот слой очень гибким и расширяемым благодаря наследованию и полиморфизму.
Потом наступил момент, когда и ООП начало давать сбои, т.к. объекты, это штука с состоянием, которое надо помнить, отслеживать, искать в нём ошибки и так далее. И когда их в программе многие тысячи, а что-то работает не так, отладка становится болью.
Вспомнили про ещё одну парадигму, которая тихонько развивалась параллельно, ФП. В функциональном программировании у вас нет сложных внутренних состояний, у вас блоки кода имеют только входы и выход, что позволяет их легко валидировать, писать к ним тесты и так далее.
Минус ФП был также в плохой модульности, но его побороли, скрестив ФП с ООП, поэтому современные языки умеют в обе парадигмы.
Мне что за Вас погуглить "OOP Delphi vs. SmallTalk"
Вы бы лучше объяснили читателям зачем вообще сравнивать ООП в разных языках?
Ну вот в ObjectPascal ООП реализовано одним способом.
А в SmallTalk другим.
И что?
Вы будете делать выбор между ObjectPascal и SmallTalk на основании различий в их ООП? Реально?
Отвечу кратко. ООП это теория. Типа теоремы Пифагора. Можно конечно не соглащаться что сумма квадратов катетов равна квадрату гипотенузы, но это уже не иеорема Пифагора будет.
Ближе к ИТ это все равно как называть реляционной БД, например, YDB. Или персоналочные БД типа DBase лишь на том основании что в них говорилось о таблица.
Можно и то что вертится под VMware называть виртуальными машинами, но это будут виртуальные системы на самом деле.
Отвечу кратко. ООП это теория. Типа теоремы Пифагора.
Теорема Пифагора имеет математически выверенное доказательство.
Можете предъявить что-то подобное для "ООП"?
В комплекте документов на VisualAge была книжка "Введение в ООП", страниц 120-150. И как Вы могли видеть выше SmallTalk был признан как "чистый" т.е. правильный вариант имплементации ООП.
Теорема Пифагора была названа не в качестве прямой аналоги, а "Типа теорема Пифагора..." было сказано. Параллельные линий тоже как оказалось пересекаются и доказать (как впрочем и опровергнуть) что это не так никто не может.
ИТ это очень не строгая область знаний и методов. В ИТ очень много субъективности и спекуляций. Код любой программы (кроме "Hello World", да и то) это черный ящик с входом и выходом, которые могут быть представленны бесконечным (хорошо, большим) количеством вариантов кода внутри.
И как Вы могли видеть выше SmallTalk был признан как "чистый" т.е. правильный вариант имплементации ООП
Где я это мог видеть?
Кем он был "признан"? Что, где-то есть какой-то ISO или ANSI или ГОСТ стандарт на ООП, в котором приписано, что стандартной реализацией ООП является SmallTalk?
Вас не смущает, что ООП вообще и первый ОО-язык програмирования появились задолго до SmallTalk-80?
Надеюсь, вы не сольетесь в очередной раз и не разразитесь очередной порцией нелепостей, а ответите на поставленные вопросы.
Заодно, чтобы два раза не вставать: какими еще ОО-языками, кроме SmallTalk-а, вы пользовались?
Надеюсь, вы не сольетесь в очередной раз и не разразитесь очередной порцией нелепостей, а ответите на поставленные вопросы.
То как и что пишите Вы в мде вопросов не относящихся к дискуссии тоже можно было бы назвать "порция нелепостей".
Где я это мог видеть?
Выше в этих комментариях где приводились цитаты, найденные в Гугл, например. Мной и другим участником.
Кем он был "признан"?
Тем кто знает о чем речь. Кто знает процедурные языки, чистый ООП язык SmallTalk, и смеси этих двух парадигм программирования.
Вас не смущает, что ООП вообще и первый ОО-язык програмирования появились задолго до SmallTalk-80?
Не понимаю почему меня это должно было смущать. Тем более что конечно же знал. Я, если Вы еще не поняли, более 40 лет работаю в ИТ и поработал во многох очень разных сферах ИТ и разных странах (в трех: СССР, Россия, и Канада).
И что из этого? Из того что что-то было до SmallTalk-80? Было до и было после. Почти все в ИТ, в современном включая, когда то было. Это ни кого и никогда не смущало и не останавливало от изобретении новых и новых "велосипедов".
Заодно, чтобы два раза не вставать: какими еще ОО-языками, кроме SmallTalk-а, вы пользовались?
Немного Visual Basic. 90% из 40 лет я вообще работал на позициях не связанных с программированием прикладных программ. Я был разными админами в разных системах и базах данных. Инсталяции, апгрейды, конфигурирование, помощь программистам, и т.д. и т.п.. Я писал программы для облегчения моей работы как админ и для повышения ее качества. В основном на REXX, без какого-либо интерфейса с ними. Они делали все сразу сами. Это был мой принцип программирования. Сделать такю программу, которую надо лишь запустить на выполнение. И запускались эти мои программы по временному графику. Тому кому это было надо лишь проверял их протоколы выполнения. Ну и еще надо было подготавливать списки объектов (в данном случае это были БД) над которыми мои программы делали то что надо (в данном случае делали реорганизацию).
Из последних работ был перевод данных из нереляционной БД IDMS в DB2 for z/OS и с помощью репликации в MS SQL. Мои программы читали директори IDMS и выдавали все DDL для DB2 и для MS SQL, а также управляющие операторы утилиты LOAD DB2.
Подобные программы есть на рынке, но мое руководство не раскошелилось бы их купить. Сделал сам. Правильнее было сказать что покупать их я даже не просил. Знал что не купят.
Немного Visual Basic.
Ну а как вы тогда можете так убедительно судить о языках, будучи специалистом в иной сфере, пусть и несколько смежной? Смотрите, я за 35 лет стажа писал коммерческий софт и на всякого рода Бейсиках, и на С++, и на Pascal/Delphi, и на Java, и на PHP, и на Python, и на C#, и на JavaScript/Typescript, не говоря уже про специализированные вещи вроде различных диалектов SQL, RPG или банального HTML/CSS. И это только профессиональная разработка, я даже не считаю платформы, которыми я просто изучал из любопытства, или делал что-то разовое эпизодическое, вроде Lisp, С/AL или того же SmallTalk. И то, у меня нет 100% уверенности в моей правоте, т.к. что-то я могу упустить, что-то могу забыть, что-то перепутать за давностью лет.
Вы резонно пишите. Я Вас понимаю.
Я не сгласен с тем что из того факта что я формально проработал в "смежной" области то я не могу судить о языках.
Во-первых, и у меня есть список языков на которых я достаточно поработал чтобы их понять. Начиная с Ассемблера и до SQL, через пусть не HTML, но подобный ему Dialog Tag Language (DTL).
Во-вторых, можно всю жизнь проработать программистом на одном языке (я с такими встречался, их особенно много было на МФ) и ничего не знать о языках вообще.
В-третьих, работа на уровне операционной системы (в "смежной" сфере) неизбежно связана с программированием (а как иначе могла возникнуть ОС если не посредством программирования). Да есть админы, которые не знают программирования, и есть программисты не знающие систему.
Насчет "убидительно судить". Я ни разу не вышел за рамки того что точно знаю сам и того что довелось читать у других спецов кто знает больше и обосновано судит. Я много читал разных аналитик.
Про Delphi я не вышел за рамки того что было сказано Вами же. И не очень то и судил Delphi. В тоже время могу сказать что начале 2000-х много общался с парнем, работатающим с Delphi и знавшим о SmallTalk меньше Вас. Его аргументы были почти в точно такие же как Ваши.
Мой перечень на чем я программировал, начиная с 1974 года:
язык ЭВМ "Наири", название которого я не помню.
Язык Символического Кодирования (ЯСК) Минск-22
Алгол-60, олносеместровый курс в институте без выхода на машину.
ФОРТРАН ЕС ЭВМ. Реальное программирование в институте и после.
Бэйсик и Ассемблер на ПК Электроника Д3-28. Реальное программирование.
ПЛ/1 и Ассемблер ЕС ЭВМ. Много реального программирования.
CLIST в CMS под СВМ ЕС,
ISPF/PDF и DTL в CMS, и в Канаде в MVS.
SQL/DS БД в VM/SP
QMF, QBE
REXX VM/SP
OS/2, DB2/2, Visual Query Analyzer, REXX OS/2
VisualAge for SmallTalk c OS/2 и Windows
LotusNotes, учебное программирование.
Visual Basic (слегка, но сам)
1С Бухгалтерия. Небольшие доработки по запросам от бухгалтеров.
DB2 for OS/390 и z/OS c версии 5 до 9. DBA и программист на REXX.
ISPF Editor. Казалось бы ну что там программировать в редакторе текстов. Но на самом деле на ISPF Editor много написано программ по ктороым и не скажешь что они написаны в редакторе. Это довольно распространенный метод программирования того что в итоге отражется в тестовых файлах или для их модификации. В MS Word такая возможность тоже есть.
IDMS база данных, программирование на EasyTrieve, реальное программирование для миграции данных из IDMS на DB2 и далее в MS SQL,
T-SQL MS SQL, хранимые процедуры, дебагинг написанного другим человеком и попытка перевода T-SQL хр. процедур в DB2. Не закончено, потеряло смысл.
Application Development System (ADS). Правильно находится на Гугле такой только строкой: "application development system broadcom ADS". Начал изучать с целью дебагинга програм написанных другими. Слишком сложно чтобы быстро вникнуть. Потряло смысл. Но уважение вызывает.
Как видите наши списки практически не пересекаются. Что не удивительно.
А судить о языках можно и нужно потому что они довольно легко классифицируются и для того чтобы понимать разницу. Не в синтаксисах, а в основах и как эти различия отражаются не только сиюминутно, но в долгой перспективе.
ИБМ загубил OS/2 и VisualAge вовсе не потому что им стало стыдно за него когда они узнали про Windows NT и Delphi и расплакались. Они сознательно и организованно перешли на Linux и Java. И все что было у них переписали. Но не в Delphi почему то. Могли купить того кто тогда Dephi владел, как Lotus. Но не стали. Это показатель?
А что, кстати, с Delphi сейчас? Просветите.
Как видите наши списки практически не пересекаются. Что не удивительно.
Ну, да, но у вас и сфера несколько иная, логично, что и инструменты другие.
Они сознательно и организованно перешли на Linux и Java.
Ну так а почему перешли? Потому что их нативные инструменты перестали покупать. Они не резали корову, которая приносит молоко, они резали корову, которая кушает, а молока не даёт.
А что, кстати, с Delphi сейчас? Просветите.
А с Delphi произошла, так сказать, IBMизация, которая его и убила (ну, как убила, загнала в узкую и медленно отмирающую нишу). Они, с одной стороны, решили поменять платформу, на ту, которая с байт-кодом и виртуальной машиной :) Не получилось, итоговый продукт был медленным, малофункциональным, неудобным. С другой стороны, они постепенно, год за годом поднимали цены, а потом взяли и перестали продавать базовые версии, оставив только энтерпрайз-решения. С третьей стороны, они потеряли свою документацию. Физически, из-за какого-то факапа исходники документации они утратили и писали её заново.
В итоге они потеряли лет пять-шесть (последняя "классическая" популярная версия вышла в 2001-м или 2002-м, а следующая пригодная для работы вышла в 2007-м), и их рынок за это время съела Майкрософт.
А что, кстати, с Delphi сейчас? Просветите.
Delphi сейчас развивается семимильными шагами. И на протяжение уже десятка лет стабильно поддерживает выход обновлений 3 раза в год + мажорная версия. Развивают язык, развивают среду разработки, развивают фреймворки. Сейчас Delphi поддерживает сборку под все основные платформы: Windows/Linux/MacOS/iOS/Android. Имеет штатный, очень мощный, кроссплатформенный UI фреймворк. Среда разработки поддерживает ИИ-инструменты. Имеется и Community-версия среды разработки. В язык добавили за последнее время: дженерики, анонимные функции, инлайн объявление переменных, локальный скоуп, енумераторы, таски, RAW-строки, хелперы, инлайн методов, расширенную рефлексию (например, атрибуты). А через месяц выходит свежая мажорная версия - Delphi 13.0, где добавили тернарный оператор, noresult модификатор и много чего ещё (NDA).
Delphi сейчас развивается семимильными шагами. ...
Спасибо. Я и сам смотрел Интернет. Все Ок с Delphi. И это хорошо.
Delphi сейчас развивается семимильными шагами.
Delphi-то развивается. Комьюнити Delphi не развивается. Приток новых разработчиков на платформу крайне невелик.
В язык добавили за последнее время: дженерики, анонимные функции, инлайн объявление переменных
Мне кажется, у вас время летит незаметно :) Я ушёл с Delphi в конце позапрошлого десятилетия. И это было добавлено "за последнее время" уже тогда.
Они сознательно и организованно перешли на Linux и Java. И все что было у них переписали. Но не в Delphi почему то.
Потому что тогда Delphi был исключительно под Windows. И создавалась среда разработки изначально как инструмент создания приложений под Windows.
Потому что тогда Delphi был исключительно под Windows.
Я не думаю, что Delphi вообще каким-то образом могла попасть в поле зрения менеджеров IBM, независимо от её таргет-платформы :) IBM давно подключилась к Java-движению, ещё за десятилетие до окончательного устаревания её собственных средств разработки, и в общем-то у неё не было никаких причин искать что-то ещё.
Но Delphi это не Java. А выбрана была именно Javа. И уже был у ИБМ VisualAge for Java.
Согласитесь, если Вы знаете что-то про VisualAge, что Delphi несравнимо с VA. Не согласны?
Один мой аргумент: Delphi это один язык, а VisualAge это много языков под одним зонтиком визиалного программирования.
Согласитесь, если Вы знаете что-то про VisualAge, что Delphi несравнимо с VA. Не согласны?
И да, и нет. Реализованы по-разному, но задачу они решают абсолютно одну и ту же - автоматизируют разработку приложений.
Один мой аргумент: Delphi это один язык
Тоже не совсем. Это два языка :) Просто та же самая IDE, но с другим компилятором, изначально называлась Borland C++ Builder. Потом, в 2007-м, если не ошибаюсь, их объединили в один продукт, но изначально продавали отдельно, на выбор. Но да, у Visual Age выбор языков все равно был пошире. С другой стороны, Delphi/BCB предлагали всего лишь два, но в то время самых популярных языка.
Выше в этих комментариях где приводились цитаты, найденные в Гугл, например.
Цитаты из гугла -- это почти как надписи на заборе.
Тем кто знает о чем речь.
Это какое-то скаральное знание?
Кто знает процедурные языки, чистый ООП язык SmallTalk, и смеси этих двух парадигм программирования.
Я вот тоже знаю много страшных слов. Но не считаю что настоящий ООП только в SmallTalk. И? Кто меня опровергнет?
Не понимаю почему меня это должно было смущать.
Оно и заметно.
Немного Visual Basic. 90% из 40 лет я вообще работал на позициях не связанных с программированием прикладных программ.
Все чудесатее и чудесатее. Было сильное подозрение, что вы кроме SmallTalk-а ничего и не пробовали. Отсюда и такой пиетет.
А тут еще и выясняется, что вас и программистом то назвать можно с натяжкой.
Цитаты из гугла -- это почти как надписи на заборе.
To whom how? Кому как.
Но не считаю что настоящий ООП только в SmallTalk. И?
Вы удивитесь, но и я так не считаю. Просто я знаю хорошо SmallTalk и ничего про другие. Поэтому и ссылаюсь на него. Это плохо? Предосудительно?
А тут еще и выясняется, что вас и программистом то назвать можно с натяжкой.
Спасибо хоть с натяжкой, не вообще нельзя назвать.
Я выше привел список средств программирования использованных мною в разной степени за 40+ лет в ИТ.
Точто я ОФИЦИАЛЬНО "работал на позициях не связанных с программированием прикладных программ " вовсе не означает что я не программировал. Еще как программировать.
А вот годы проведенные на "бухгалтерском балансе" или "управлении складом" я не считаю большим опытом в программировании. Тем более что зачастую это моноязычная ситуация. С/С++, Delphi, Visual Basic. Что там у Вас в активе?
Вы удивитесь, но и я так не считаю.
Удивлюсь. Ибо: "Настоящим ООП языком был и остается только ST." -- это точная ваша цитата.
Просто я знаю хорошо SmallTalk и ничего про другие. Поэтому и ссылаюсь на него. Это плохо?
Да.
Что там у Вас в активе?
Из языков программирования? Из того, что использовалось для работы: C, C++, Java, D, Ruby. Из прочего, что выходило за рамки обычных HelloWorld-ов: Pascal, VB for Application, Eiffel, Python. Плюс еще полдюжины языков, на которых дальше HelloWorld-ов не пошло за ненадобностью или потому, что привкус не понравился: Modula-2, Ada, Scala, OCaml, Go, Rust, JavaScript, Erlang, Lua и всякая никому не известная экзотика, вроде Pike или Nice.
Сомнаваюсь что вообще какая-либо ООП там была, т.к. ООП и компактный нативный код это несовместимо.
Да уж. Да уж. Да уж.
C++ и Eiffel вместе с ObjectPascal и Objective-C тихо офигевают в сторонке.
И это все что у Вас есть сказать?
Во-первых, вы же сами отказались от продолжения разговора.
Во-вторых, Хабр не тот ресурс где принято называть вещи своими именами. Самое мягкое, что я могу сделать -- это назвать глупость глупостью. Но и это, скорее всего, вызовет поток минусов в карму.
Я не за кармой пришел на Хабр, а за общением с российскими коллегами. В преддверии возможного моего становления российским ИТ-шником в каком-нибудь роде.
И ожидания были что я встречу профессионалов. Пока это плохо ( не совем но все же) получается. Но как говорится в соцсетях собеседников не выбирают.
Стараюсь быть взаимнопараллельным, но это не мой конек что в виртуале что в реале. Меня на работе считают русским грубияном (rough man). На самом деле я очень добрый человек, даже слишком. Жена с этим согласна.
Пока это плохо ( не совем но все же) получается.
Я даже могу подсказать почему.
Из-за ваших категоричных и бездоказательных утверждений из категории (простите, я своим текстом, лень точные цитаты выискивать):
настоящий ООП только в SmallTalk;
ООП -- это такая же теория, как и теорема Пифагора;
ООП и компактный нативный код не совместимы;
x86-64 сервак даже базу данных не потянет.
настоящий ООП только в SmallTalk;
Нет не только. Есть Ruby и другие языки по сути переименовый SmallTalk. Может и еще, все знать не возможно.
Но языки типа Delphi, С++, Visual Basic, Object Cobol, Object REXX (c REXX без Object я очень много наработал, наверное больше всего). Т.е. любые языки изначяально бывшими процедурными и однажды объявившие свою ООП-шность таковыми считаться не могут. Хотя бы потому что есть SmallTalk, его последователи, Ruby. Парадигму процедурного языка заменить на ООП не возможно. Поэтому она остается, и к ней за уши притынут ООП. Все что притягивается за уши не может быть эталоном (чуть, в спешке, не написал этанолом).
ООП -- это такая же теория, как и теорема Пифагора;
Уже пояснил. Нет конечно, но и толкования стройной парадигмы ООП в угоды привить ООП к процедурным языкам, из-за их рыночной популярности, это все равно что отвергать теорему Пифагора. Почему бы Микрософт вместо Visual Basic было не создать чистый ООП язык, назвать его Gates, и продвинуть на рынок пользуясь своей популярностью. Понятно почему, было бы гораздо труднее закрепиться на рынке с таким продуктом. Гораздо проще было добавить ООП (в ублюдочном виде) и размахивать двумя флагами: Basic и ООП. Для знакомых с Basic ООП стало таким как оно сделано в Visual Basic, и никаким другим.
ООП и компактный нативный код не совместимы;
Не совместимы в том смысле что нет единого подхода к программированию. Нативный код получается из процедурной части, а ООП часть это байт код. Отлаживать их надо по разному, дингностировать тоже по разному. Когда чистый ООП все делается единообразно. Мы видим и пользовательские обекты и языковые в одной и той же трассировке. Трассировка в ViasualAge for Smalltalk outstanding. Тестировал, знаю. И знаю как трассируются и тестируются процедурные языки.
x86-64 сервак даже базу данных не потянет.
Ок. Может. Та ERP система которую я сопровождал 25 лет будучи перенесена в облако стоит на отдельном серваке х86-64 с кучей коров (ударение на первое "о") и памяти. Просто потому что с МФ перенесли парадигму централизованной БД.
Кроме БД у этой ERP были сервера приложений, пакетные задания, репортинг, Dev, QA, Training. И все это выполнялось на одном, очень маленьком, МФ.
А сейчас эта ERP стоит в облаке на 36 серверах. Есть разница?
Горизонтальная масштабируемость это единственный метод на х86-64 чтобы ранить (от слова "run") сколько-нибудь объемную работу.
На МФ тоже есть горизонтальная масштабируемость, но, во-первых, она начинается на гораздо бОльших объемах работ посильных одному МФ, во-вторых, это больше для Non-stop и Disaster Recovery, а в-третьих, это (гор. масшт.) использует устройства и методы связи узлом не имеющиеся в мире х86-64. Технически их можно было бы сэмулировать на х86-64, но тогда окажется что нет софта для использования этих устройств. А на Мф естественно есть и то и другое.
Все что притягивается за уши не может быть эталоном
Это вы просто Eiffel-я не знаете. И Java. Чистые ОО-языки, между прочим.
А в Eiffel еще крутая поддержка множественного наследования, которого в SmallTalk нет в принципе. Наверное, покруче, чем в C++.
Когда кругозор стремится к нулю, а опыта разработки на ОО языках и того меньше, то и SmallTalk эталоном покажется.
Уже пояснил.
Нет.
Не совместимы в том смысле что нет единого подхода к программированию.
"Единый подход" вдруг стал синонимом "компактного"? o_O
Знаете, у меня уже цензурные слова заканчиваются, чтобы передавать степень моего опупевания от ваших "откровений".
Ок. Может. Та ERP система которую я сопровождал 25 лет будучи перенесена в облако стоит на отдельном серваке х86-64 с кучей коров (ударение на первое "о") и памяти.
Какие-нибудь количественные показатели у этой ERP есть? Ну там объем данных дохилиард терабайт, пропускная способность десятки миллионов RPS, поддержка одновременной работы трех миллиародов юзверей с пяти контенентов?
Горизонтальная масштабируемость это единственный метод на х86-64 чтобы ранить (от слова "run") сколько-нибудь объемную работу.
Именно. Для вертикального масштабирования есть ваши любимые МФ. Когда МФ обсераются на объемах, приходят десятки тысяч x86-х и все дела. Хотя, не удивлюсь, если в течении 5-10 лет эти самые десятки тысяч x86-х сменят сотни тысяч ARM-ов.
Это вы просто Eiffel-я не знаете. И Java. Чистые ОО-языки, между прочим.А в Eiffel еще крутая поддержка множественного наследования, которого в SmallTalk нет в принципе. Наверное, покруче, чем в C++. ...
Это Вы не мне, а @PerroSalchicha скажите. Это для него С++ этанол эталон.
А я должен был знать все что Вы знаете чтобы знать что есть ООП и что есть не совсем ООП? По-моему это слишком. Перебор.
Нет.
По-моему я там больше чем "Уже пояснил" написал. Это не прочиталось? Не понялось?
"Единый подход" вдруг стал синонимом "компактного"? o_O
Я не знаю что такое ""компактное"? o_O ". No comments.
Какие-нибудь количественные показатели у этой ERP есть? Ну там объем данных дохилиард терабайт, пропускная способность десятки миллионов RPS, поддержка одновременной работы трех миллиародов юзверей с пяти контенентов?
Нет там дохилиардов (надо запомнить). Обычная БД для производства связанного с эксплуатацией двух (было три, одну продпли) атомных станций с десятком-полтора реакторов и сотней-две гидро-тепловых станций. Правда одна таблица куда складывали всякий мусор: ворд документс, снимки, может даже видео весила больше всех остальных таблиц, А их ~1500, используются ~750.
Я же там написал что до облака это крутилось на очень-очень маленьком МФ, примерно 2013 года выпуска, с 4 CPU и 32 ГБ памяти на всё про всё включая две системы и все Production, Dev, QA, Training со всеми серверами приложения . А теперь, в Azure это на 36 серверах х86-64. Разных серверах, но все же.
Не надо себя распалять в воображении о числах. В реальной жизни все гораздо меньше.
Когда МФ обсераются на объемах, приходят десятки тысяч x86-х и все дела.
Вы верите в то что десятки тысяч х86-64 в Azure стоят дешевле МФ?
Мы перешли в Azure 3 года назад. Наши финансисты уже подвывают (пока не воют) что то дорого получается ИТ для миллиардного бизнеса. А у нас всего то около 2000 серверов, на неданем митинге по использованию серверов было показано 752. Это видимо те которые мониторятся.
Проблема в том, мил человек, что полноценно загрузить тысячи независимых х86-64 серверов гораздо сложнее чем один МФ. Почему у нас использовались зажатые процессоры? Чтобы не платить за неиспользованные мощности. Да и то зажатые процессоры только несколько часов в день (исключая выходные) были загружены на 100%. ИБМ был милостив и счета выставлял по средней загрузке.
Мы перешли в Azure 3 года назад.
Azure, как и любые другие чужие облака, это способ продать одну картофелину за полтора бакса, если её нарезать слайсами. Арендуя сервер в Azure, вы оплачиваете сам сервер, его место в датацентре, работу обслуживающих его админов, работу их саппорта, работу программистов, пишущих и сопровождающих весь азуровский софт, даже тот, который вам нафиг не сдался (ну, т.е. почти весь азуровский софт), зарплаты менеджмента облачного подразделения Майкрософт, зарплату охраны и уборщиц, налоги и собственно маржу Майков. Если хотите экономить, поднимайте частное облако, благо ваш масштаб
у нас всего то около 2000 серверов, на неданем митинге по использованию серверов было показано 752
это вполне себе предполагает.
Я же там написал что до облака это крутилось на очень-очень маленьком МФ, примерно 2013 года выпуска, с 4 CPU и 32 ГБ памяти на всё про всё включая две системы и все Production, Dev, QA, Training со всеми серверами приложения
Ну так и сейчас для этого не нужно 36 серверов. С этим справится и один современный сервер, даже с одним CPU ядер на шестнадцать. Ну, два, с учётом резервирования.
А я должен был знать все что Вы знаете чтобы знать что есть ООП и что есть не совсем ООП? По-моему это слишком. Перебор.
Заявления о "настоящести ООП" без наличия хоть сколько-нибудь существенной эрудиции в данном вопросе превращают вас в клоуна. В лучшем случае.
Это не прочиталось? Не понялось?
Это ерунда, а не попытка доказать то, что "ООП -- это теория". В области программирования достаточно много реально научных теорий, например, теория алгоритмов. Еще можно вспомнить про формальную верификацию. Которые к теореме Пифагора по своей доказательной силе гораздо ближе, чем ваши рассуждения.
Не надо себя распалять в воображении о числах.
Так это же вы заявляете о том, что x86 не может быть нормальным сервером. Только вот когда заходит речь о реально больших числах, например, о том, как Google обслуживает свой поиск или свой Gmail, так выясняется, что там x86-е в немерянных количествах. А не МФ от IBM.
Проблема в том, мил человек, что полноценно загрузить тысячи независимых х86-64 серверов гораздо сложнее чем один МФ.
Тысячи серверов загружают те, кто знает, умеет и имеет актуальную в этом необходимость. Например, Google, Amazon, Netflix, Microsoft, Yandex и т.д.
Кому это не нужно, берут то, что нужно под задачу.
не стоит байки старичка воспринимать в серьез, на privet.com он умудрился CPU спутать даже не с ядрами, а с vCPU. то что он принял за сервера, почти наверняка просто докеры на мелкой машинке.
Не припомню такого ника WaiEvent на Привете. Скрываешься? Я конечно догадываюсь о ком речь. Была пара тройка тролей на эти темы. Один особенно помнится, с ником с буквами "iD..." в нике. Ты?
Домысливать за других это удел болтунов. Нет, стукач, вот кто ты. Ты пишешь здесь то что здесь не было опубликованно и опровегнуть тебя я не смогу. И вообще, ты еще под стол пешком ходил когда я работал с виртуальными машинами на МФ и читал лекции по ним.
P.S. Старичок, с его 70 лет, еще работает и на on-call в том числе. Этой ночью звонили решать проблемы с сервисом 24*7(365). Что ты, мОлодец, будешь делать в твои 70 лет еще не известно.
не ломайте деда изверги, он зациклился в манямирке
читать конечно тяжеловато, но оооочень интересно
Диалог между поколениями ИТ-шников