ЯП для физики высоких энергий

[Влад Жаринов]

Да, по поводу математических и физических коней:

«Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой.

 Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».

- а обсуждение статьи быстро скатилось и на физику (т.к. в самой статье ООП рядополагалось с ТО)... и на математику... Интересны комменты, где это даже связывалось... вроде этого...

[Влад Жаринов]

Ну и чтоб уж совсем сабжа не менять:

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

- не знаю уж, где именно это имеет место...

[alexus]

Да, по поводу математических и физических коней:

«Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой.

 Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».

- а обсуждение статьи быстро скатилось и на физику (т.к. в самой статье ООП рядополагалось с ТО)... и на математику... Интересны комменты, где это даже связывалось... вроде этого...

Это спор о вкусовых предпочтениях... В сути того же ООП никто разбираться не хочет, и спор превращается в обмен "колкостями".

[alexus]

а обсуждение статьи быстро скатилось и на физику (т.к. в самой статье ООП рядополагалось с ТО)... и на математику... Интересны комменты, где это даже связывалось... вроде этого...

Никого же не удивляет, что в машиностроении, например, есть инженеры-конструкторы, которые придумывают новое изделие, отвечая на вопрос: "Что нужно делать?"; и есть инженеры-технологи, придумывающие новые методы изготовления, отвечая на вопрос: "Как нужно делать?". Наконец, есть исполнители, которые, выполняя инструкции технологов, делают то, что придумали конструкторы.
В программировании инженерные подходы плохо приживаются... исполнитель здесь является и конструктором, и технологом... ООП ему, "как собаке пятая нога".

[Влад Жаринов]

Да, по мере чтения комментов возникало такое ощущение... и не в первый раз (имея в виду как осмысление опыта того же Грабина, так и Ваше замечание, что не следует путать ООА и ООП)...

[Влад Жаринов]

А никто и не призывает же переписывать старый, проверенный веками софт с фортрана на новый язык.
От нового языка требуется лишь что бы он был удобнее фортрана (на который физики плюются долгие годы), проще с++ (который эти физики так и не осилили за эти же долгие годы), и при этомне терял возможности вызова всех эти фортрановских подпрограмм...

Угу... и этот новый язык должен будет поддерживать несколько точек входа в подпрограмму... в том числе.
...

Ага... техноязык в силуэте поддерживает... и это, как стало понятно отсюда, видимо, потому, что изначально был граф-нотацией для управляющих структур Фортрана-С3Х... вот только реально исполняются не размеченные графы, а код, транслированный из Фортран-текста...
Кстати, Ада, если я правильно понял Кауфмана здесь (в первой выдержке), поддерживает множественность точек входа (при асинхронном рандеву)... так?..