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

P>Не, Turbo C++ 1.0 и Borland C++2.0 на 286 с 1 МБ еще работали. А 3.0 уже нет. ЕМНИП, именно в 3.0 шаблоны завезли.
+1. Мне так тоже изначально казалось, так как я помню нам очень хотелось что-то для win30 собрать, а не получалось на нашем железе (286) до TPW. Нужен был 386, которые были на пересчет в Питере, так как стоили как 5 жигулей.
Потом sergey2b меня смутил своим "Borland С++ 3.0 позволял собирать для винды на IBM XT что я и делал", что конечно было довольно странно, если вообще возможно.

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

N>>Если она на плюсах, то надо UI делать неделю
CC>Почему?
Не знаю, так получается. Много кода... Твоего суперфрейморка у меня нет, а на QT думаю будет 1к+ loc и это без веба. С веб на плюсах вообще надо будет делать закат солнца вручную. Если это не так, то любой плюсовик, который тут минусы ставит может попробовать такое сделать и доказать, что "плюсы рулят, другие языки не нужны". Однако вот в соседнем топики rudzuk вроде так и не смог получить на плюсах эквивалент ReadAllStrings, который есть чуть менее чем везде, хотя казалось бы делов то.

N>>Это не полностью работающий код в 50 строчек.
CC>Твой код тоже не полностью работающий, к нему ещё надо кучу всего что он вызывает
Дак у тебя же все это есть. Фреймворк показывать не нужно, я додумаю. Покажи интеграцию — apples to apples.

CC>У меня вообще всё своё.
CC>А нафига мне на чужие ограничения и зависимости завязываться?
Нифига ты крут! Только стандартная библиотека и win32, a все остальное "не приходя в сознание"! В Apple тоже?

N>>Скорость мне нужна.
CC>Скорость чего именно?
Я же сказал "вычислений" и пример соседний указал — GameOfLife. В моих дэшбордах финансовая математика (иногда с монте-карло, нелинейной оптимизацией и т.д.). Бывает для ее перевода на numpy/XLA/numba нужно время и первую версию проще делать циклом.

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

R>Обсуждение давно вышло за рамки виртовского паскаля Или мне показалось?
Когда это ввели? В Delphi 5, а тогда уже был полный делфикапец, такого точно не было.

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

n> R>Обсуждение давно вышло за рамки виртовского паскаля Или мне показалось?

n> Когда это ввели? В Delphi 5, а тогда уже был полный делфикапец, такого точно не было.

Если говорить о Delphi, то это появилось лет пять назад. Например, в oxygene (модный паскаль для этих ваших жабов, дотнетов, какав и натива впоследствии) это было с рождения, а он появился лет двадцать назад. Должен заметить, что фича, с точки зрения удобства разработки — никакая (есть еще плюсы с технической точки зрения). Единственный плюс — удобно декларировать счетчик цикла.

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

P>Насколько я помню, первые упоминания о Паскале относятся к 1970 году.
P>Да, я знаю. В USCD добавили прямой доступ к файлам, которого не было в Паскале Вирта. Еще какие-то вещи. Уже не помню. Когда-то у меня даже книжка про него была.
Паскаль не подходил для промышленного программирования, так как до середины 70-х транслятора p-code в натив не было. Только для обучения.

P>Главная заслуга Вирта и Паскаля — они избавили человечество от монстров типа PL/1.
В основном, как евангелист и член комитета по Algol-68. Реальный технический вклад в ликвидации — Ричи и группы в BellLabs.

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

R>Если говорить о Delphi, то это появилось лет пять назад.
Ложка хороша к обеду, а покойнику можно что угодно пришивать он от этого не оживет.

R>Должен заметить, что фича, с точки зрения удобства разработки — никакая (есть еще плюсы с технической точки зрения). Единственный плюс — удобно декларировать счетчик цикла.
Глупость говоришь. Мне даже лень спорит.

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

n> R>Если говорить о Delphi, то это появилось лет пять назад.

n> Ложка хороша к обеду, а покойнику можно что угодно пришивать он от этого не оживет.

Хе-хе. Видал я хоронителей паскаля... Иных уж нет, а те далече (с).

n> R>Должен заметить, что фича, с точки зрения удобства разработки — никакая (есть еще плюсы с технической точки зрения). Единственный плюс — удобно декларировать счетчик цикла.

n> Глупость говоришь. Мне даже лень спорит.

И это правильно. Кому интересны аргументы теоретиков, видевших последний раз паскаль сто лет назад

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


M>>С другой стороны, Хейлсберг как раз на базе UCSD-паскаля запилил свой турбо

P>Видел. Он позволял писать, почти как на Фортране. Один знакомый этим пользовался, когда не нашел Фортран для PC.
P>Главная заслуга Вирта и Паскаля — они избавили человечество от монстров типа PL/1.

А могли бы просто ничего не делать, и сишечные языки порешали бы. Иногда лучше жевать, чем говорить. Или не писать свои языки, чем писать.

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

N>>>Если она на плюсах, то надо UI делать неделю
CC>>Почему?
N>Не знаю, так получается.
При наличии нормального FW с готовыми компонентами — на любом языке делается очень быстро.

N>и это без веба.
А нафига там веб?

N>так и не смог получить на плюсах эквивалент ReadAllStrings, который есть чуть менее чем везде, хотя казалось бы делов то.
Я похоже пропустил это.
Безотносительно — а нафига оно нужно то? Сколько девелоплю — как то не было реальной необходимости именно в таком.

N>Дак у тебя же все это есть. Фреймворк показывать не нужно, я додумаю. Покажи интеграцию — apples to apples.
Интеграцию чего с чем? Я чот не очень понимаю что именно ты хочешь?

N>Только стандартная библиотека и win32, a все остальное "не приходя в сознание"!
Стандартную библиотеку вычеркни и будет более менее правильно. Мне вовсе от рантайма надо самый базовый минимум, всё остальное давно написано в более удобном и производительном виде.

N> В Apple тоже?
Там свои либы и FW есть, впрочем изрядно корявые. Свою мне лень туда портировать, но иногда какие то части приношу чтоб не решать одну и ту же задачу дважды.
Тех, кто проектировал IOKit и CF хочется забить тапком. Такого рукожопия я давно не видел.
Swift тот ещё кусок говна. Язык, в котором крайне геморройно оперировать байтами совершенно непригоден для системного программирования.

CC>>Скорость чего именно?
N>Я же сказал "вычислений"

Каких именно?

N>В моих дэшбордах финансовая математика (иногда с монте-карло, нелинейной оптимизацией и т.д.).
Этож всё подкапотное, банально операция над массивом данных. К приведённому тобой гуёвому примеру вообще никак не относится.

N>Бывает для ее перевода на numpy/XLA/numba нужно время и первую версию проще делать циклом
В мою бытность мы эту трахомудию пытались затолкать в видюху на Cuda 1.0
Получалось довольно хреново.

У меня в личном туле до такой степени заморочной математики нету ибо нету на то особой нужды.
Впрочем остальные вычисления сделаны ленивыми (ибо там по сути граф вычислений, значения и даже частичные результаты одних формул переиспользуются другими). Написано так что любой гуёвый отображатель значений принимает DataSource объект (от банального источника значений или сумматора, до более сложных), в который инпутами подрубается всё то, что ему надо для вычислений (такие же DataSource), ну а когда это понадобится — будет дёрнута цепочка, всё посчитается и закэшируется. Известные тяжёлые вещи могут быть отправлены в параллельный многопоточный расчёт заранее, даже на этапе создания формулы.
Все эти формулы создаются однократно, а когда меняются какие то входные значения то кэш инвалидируется и граф лениво пересчитывается.
Такую схему в принципе можно натянуть и на тяжёлые пересчёты

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

CC>При наличии нормального FW с готовыми компонентами — на любом языке делается очень быстро.
Taк покажи, не стесняйся. Примерно представляю себе ситуацию с QT, но может у тебя все круче.

CC>А нафига там веб?
Потому же почему и у амазона с гуглом. Код работает под linux, а у клиента win.

CC>Безотносительно — а нафига оно нужно то? Сколько девелоплю — как то не было реальной необходимости именно в таком.
map/filter/sort/groupby/reduce? Грязные данные кроме строк никуда не запихаешь.

CC>Интеграцию чего с чем? Я чот не очень понимаю что именно ты хочешь?
Те самые 50 строчек, которые используют твой крутейший фреймворк.

N>> В Apple тоже?
CC>Тех, кто проектировал IOKit и CF хочется забить тапком. Такого рукожопия я давно не видел.
CC>Swift тот ещё кусок говна. Язык, в котором крайне геморройно оперировать байтами совершенно непригоден для системного программирования.
Самооценка у тебя я смотрю на уровне. Так и надо: "Все дебилы и только Я крутой!"

CC>Этож всё подкапотное, банально операция над массивом данных. К приведённому тобой гуёвому примеру вообще никак не относится.
Эти пример показывает сколь быстро можно к мат.модели на раннем этапе R&D присобачит какой-то UI. Ессно сама модель тоже на Питоне, ну или в моем случае Скале, но это местный калорит. UI нужен для разработки, калибровки и т.д., а так же для придания уверенности пользователям, что модель работает. Часто можно обойтись просто Jupyter, но не всегда. Так сейчас это работает чуть менее чем везде, где разрабатывают мат. модели: в Lockheed, Pfizer, OpenAI, у нас на WallSt, думаю и у вас в Apple.

N>>Бывает для ее перевода на numpy/XLA/numba нужно время и первую версию проще делать циклом
CC>В мою бытность мы эту трахомудию пытались затолкать в видюху на Cuda 1.0
Tы просто не владеешь темой. XLA это и есть оболочка для cuda.

CC>...
CC>Все эти формулы создаются однократно, а когда меняются какие то входные значения то кэш инвалидируется и граф лениво пересчитывается.
Просто оbserver pattern или явнoe построение computational graph через метапрограммирование? Если второе было бы интересно посмотреть. Пo второму варианту все эти tflow с pytorch и работают, но там правда еще много чего. Разберешься как они реализованы, поймешь почему все на питоне ML модели программируют, а не на плюсах.

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

N>Паскаль не подходил для промышленного программирования, так как до середины 70-х транслятора p-code в натив не было. Только для обучения.

Да я знаю. В нем даже раздельной компиляции не было. А в Фортране и Коболе была. Я на Паскале в жизни всего одну программу сочинил. На 3-м курсе. А свое мнение о паскалеподобных языках оставил еще в Оберонных войнах.
Но тут же КСВ, нужно было поддержать разговор. И, похоже, мне это удалось.

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

N>+1. Мне так тоже изначально казалось, так как я помню нам очень хотелось что-то для win30 собрать, а не получалось на нашем железе (286) до TPW.

Тут я теоретик. Я ни строчки для win 3.x не написал. Слышал только, что в какой-то из версий BC появилась среда для разработки под Винду.

N>Нужен был 386, которые были на пересчет в Питере, так как стоили как 5 жигулей.

Это да. В нашем местечке мы чуть ли не экскурсии устраивали на 386 посмотреть.

N>Потом sergey2b меня смутил своим "Borland С++ 3.0 позволял собирать для винды на IBM XT что я и делал", что конечно было довольно странно, если вообще возможно.

Тут боюсь наврать. По-моему, я видел какую-то среду, которая называлась Turbo C++ 3.0. Но поскольку у нас основным инструментом был MS Fortran, то от использования BC мы отказались. Мне из него удалось запустить только один раз подпрограмму на Фортране, которая ничего не принимала. Для совместимости пришлось бы стартовый модуль переписывать на асме и еще много чего. Проще было взять MS C 6.0. Там подключение прошло, почти как по учебнику.

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

CC>>При наличии нормального FW с готовыми компонентами — на любом языке делается очень быстро.
N>Taк покажи, не стесняйся.
А зачем это мне?

N> Примерно представляю себе ситуацию с QT, но может у тебя все круче.
QT generic UI FW, у меня заточенный под решение моих задач.
Generic всегда будет многословнее и разбухший от компромиссов и вариаций функциональности.

CC>>А нафига там веб?
N>Потому же почему и у амазона с гуглом. Код работает под linux, а у клиента win.
У меня это решается проще: код под винду, на маке работает через Wine.
Эти криворукие правда рендеринг шрифтов испортили в Wine7+, отчего Bold на экране теперь слабо отличается от Regular, +возвращаемые размеры текста не всегда соответствуют реально отрисованному.

CC>>Безотносительно — а нафига оно нужно то? Сколько девелоплю — как то не было реальной необходимости именно в таком.
N>map/filter/sort/groupby/reduce?
Только не говори что это всё должно быть реализовано внешними тулами куда надо скармливать текстовые файлы или вовсе через pipe.

N>Грязные данные кроме строк никуда не запихаешь.
Если у меня raw data это числа или вообще структуры, всё это заталкивать в строки и обратно это какой то особый вид мазохизма.
А потом надо полагать следует плакаться что всё медленно и память жрёт как бесплатную.

CC>>Интеграцию чего с чем? Я чот не очень понимаю что именно ты хочешь?
N>Те самые 50 строчек, которые используют твой крутейший фреймворк.
Понятнее не стало
Само использование компонента, т.е. создание его и wiring в него источников данных/action handlers — это пара строчек.

N>Самооценка у тебя я смотрю на уровне.
"Вижу говно — называю говном." (С)
Если не веришь — пойди сам посмотри.

N>Эти пример показывает сколь быстро можно к мат.модели на раннем этапе R&D присобачит какой-то UI.
Если у тебя уже есть UI компоненты — присобачить их будет просто. Язык тут уже дело десятое, абы был достаточно высокоуровневым. Чтоб понятнее было: С тут плохо подойдёт, С++ — хорошо.

N>Tы просто не владеешь темой. XLA это и есть оболочка для cuda.

Это просто ты поспешен с выводами. Чего ты вообще думаешь я про куду вспомнил?
XLA появился на свет лет на шесть позже тех времён.

CC>>Все эти формулы создаются однократно, а когда меняются какие то входные значения то кэш инвалидируется и граф лениво пересчитывается.
N>Просто оbserver pattern или явнoe построение computational graph через метапрограммирование?
Явное построение, но без мета, ибо в моём случае всё возможные варианты того, что нужно посчитать заранее известны, а лишние слои абстракций городить мне не интересно.

N> Если второе было бы интересно посмотреть
Нету там ничего интересного, банальщина.

N>Пo второму варианту все эти tflow с pytorch и работают, но там правда еще много чего.
Мы как то от финансов в ML ушли, я смотрю.

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

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

N>>Taк покажи, не стесняйся.
CC>А зачем это мне?
Действительно, лучше не показывать.

N>>Потому же почему и у амазона с гуглом. Код работает под linux, а у клиента win.
CC>У меня это решается проще: код под винду, на маке работает через Wine.
Никаких маков в банках нет и проблема вообще не в этом. Мне нужен доступ к железу и информации, которых у юзера нет. Все, как и у гугла и амазона.

CC>>>Безотносительно — а нафига оно нужно то? Сколько девелоплю — как то не было реальной необходимости именно в таком.
N>>map/filter/sort/groupby/reduce?
CC>Только не говори что это всё должно быть реализовано внешними тулами куда надо скармливать текстовые файлы или вовсе через pipe.
Это все реализованно в языке миллионом способов от стандартой библиотеки до polars, но для удобства начального анализа имеет смысл не трахаться с IO и превратить файл в массив строк.

N>>Грязные данные кроме строк никуда не запихаешь.
CC>Если у меня raw data это числа или вообще структуры, всё это заталкивать в строки и обратно это какой то особый вид мазохизма.
ReadAllStrings как бы подрузмевает что файл у тебе текстовый, а не "raw data это числа или вообще структуры", не?

CC>А потом надо полагать следует плакаться что всё медленно и память жрёт как бесплатную.
А потом ты берешь распределенный dataframes типа spark или dice и начинаешь обрабатывать террабайты в секунду, а не экономишь на спичках.
Premature optimization is the root of all evil.

CC>Понятнее не стало
CC>Само использование компонента, т.е. создание его и wiring в него источников данных/action handlers — это пара строчек.
Ладно мне надоело. Все ты понимаешь, но прикидываешься.

CC>Это просто ты поспешен с выводами. Чего ты вообще думаешь я про куду вспомнил?
CC>XLA появился на свет лет на шесть позже тех времён.
JAX/XLA работает на чем угодно и без куды.

CC>>>Все эти формулы создаются однократно, а когда меняются какие то входные значения то кэш инвалидируется и граф лениво пересчитывается.
N>>Просто оbserver pattern или явнoe построение computational graph через метапрограммирование?
CC>Явное построение, но без мета, ибо в моём случае всё возможные варианты того, что нужно посчитать заранее известны, а лишние слои абстракций городить мне не интересно.
Руками строить граф это "закат солнца вручную" — очень много loc. Кроме того нужен eсли граф глубокий, хорошо иметь специальный дебаггер, аналог tensorboard.

N>>Пo второму варианту все эти tflow с pytorch и работают, но там правда еще много чего.
CC>Мы как то от финансов в ML ушли, я смотрю.
У нас те же графы, только без нейронок.

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

LVV>А вот ответьте на вопрос: почему первая интегрированная среда была сделана Андерсом Хейлсбергом для Паскаля ?
LVV>Тоже ведь не случайный выбор с бодуна после нового года ...
Да, я ругаю Паскаль и буду ругать. Ибо для современных реалий это крайне плохой язык как для обучения, так и просто для использования, в том числе и современные его диалекты. Однако в свое время это был прекрасный язык, практически лучший. У меня это был третий язык после Бейсика и Ассемблера, четвертым был Си. И по существу на тот момент Паскаль был действительно лучшим языком для обучения, ибо он и тянул на домашних компьютерах, и было достаточно строг, при меньших способах прострелить себе ногу был вполне по скорости сравним с Си. Особенно с ассемблерными вставками.

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

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

N>для удобства начального анализа имеет смысл не трахаться с IO и превратить файл в массив строк.
А потом это всё прочитать как массив строк?

N>ReadAllStrings как бы подрузмевает что файл у тебе текстовый, а не "raw data это числа или вообще структуры", не?
Дык в этом то и проблема что с какого то перепугу числовые данные процессятся как текст

CC>>А потом надо полагать следует плакаться что всё медленно и память жрёт как бесплатную.
N>А потом ты берешь распределенный dataframes типа spark или dice и начинаешь обрабатывать террабайты в секунду, а не экономишь на спичках.
Ну вот и получается что там, где достаточно обычного компа тебе надо кластер

N>Ладно мне надоело.
Мне давно уже надоело.

CC>>XLA появился на свет лет на шесть позже тех времён.
N>JAX/XLA работает на чем угодно и без куды.
Ещё раз, для тех кто в танке: его тупо не существовало в те годы.

CC>>Явное построение, но без мета, ибо в моём случае всё возможные варианты того, что нужно посчитать заранее известны, а лишние слои абстракций городить мне не интересно.
N>Руками строить граф это "закат солнца вручную" — очень много loc.
Не, как раз немного. Пара функций, которые бегут по структурированным на этапе импорта данным и строят всё что надо.
Дальше просто дёргаешь объект на нужную дату а из него уже торчат хвосты всех нужных DataSources

N> Кроме того нужен eсли граф глубокий, хорошо иметь специальный дебаггер, аналог tensorboard.
Есть такой, жмёшь Alt-F1 при наведённой на интересующее тебя значение и вылазит попап, который показывает DataSource и все его inputs, по которым тоже можно кликать. Они именованные

CC>>Мы как то от финансов в ML ушли, я смотрю.
N>У нас те же графы, только без нейронок.
Размеры таки поменьше чем в нейронках