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

[Илья Ермаков]

По моим наблюдениям то же самое можно сказать про любого другого инженера. Например про радиоэлектронщиков. Отличий от программирования весьма и весьма мало. И ошибок столько же. В общем, все нормально :-)

В ИТ ни с чем не сравнимая свобода "креативить", гораздо большее время между тем, когда человек "нагромоздил" и когда он почувствовал все проблемы от этого...
И это количественное отличие ("больше свободы") переходит в качественное: не сопоставимую с другими областями способность плодить грабли (то, что Информатика-21 называет "раковая опухоль избыточной сложности"). И всё это начинает самоподдерживаться.

[Илья Ермаков]

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

Почитайте Арнольда или Успенского, например.
Уж куда больше "сферических коней в вакууме", чем плодит "бурбакистская математика".
И программисты, тяготеющие к математике, тяготеют к Хаскелям и С++ Точно по тем же причинам, что вместо ясности и реализма им нужна возможность "утончённого абстрагирования".

[valexey]

По моим наблюдениям то же самое можно сказать про любого другого инженера. Например про радиоэлектронщиков. Отличий от программирования весьма и весьма мало. И ошибок столько же. В общем, все нормально :-)

В ИТ ни с чем не сравнимая свобода "креативить", гораздо большее время между тем, когда человек "нагромоздил" и когда он почувствовал все проблемы от этого...
И это количественное отличие ("больше свободы") переходит в качественное: не сопоставимую с другими областями способность плодить грабли (то, что Информатика-21 называет "раковая опухоль избыточной сложности"). И всё это начинает самоподдерживаться.

Эта свобода креативить, и вообще таймаут после которого разложенные самому себе грабли стукнут по лбу, зависит лишь от размера и сложности системы. Так уж получилось что програмные системы в среднем больше и сложнее чем "железные". В среднем - я имею ввиду те, которые вполне себе ширпотребные и клепаются массово на коленке. В радиоэлектронике или механической инженерии таковые массово клепаемые системы ОЧЕНЬ простые, как и задачи которые они решают. За счет некоторых особенностей програмной инженерии (отсутствие физического воплощения, в результате они на порядки более технологичны чем любая радиоэлектроника или механика) она позволяет создавать более сложные системы, решающие более сложные задачи за приемлемые ресурсы (время,люди). Чем собственно и пользуются.

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

[Илья Ермаков]

Так всё правильно, ну так это и налагает гораздо большие требования на культуру мышления программиста...
Противоречие, выделенное ещё Ершовым: профессия чуть самая массовая из "умственного труда", и в то же время - крайне "требовательная"...

[alexus]

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

Почитайте Арнольда или Успенского, например.

Не сработает... Арнольд тем и славен, что оппонирует "бурбаки", а, следовательно, пристрастен... не объективен. И если Вам ближе позиция Арнольда, то это никак не умаляет заслуг "бурбаки", в том числе, заслуг в области просвещения.

Уж куда больше "сферических коней в вакууме", чем плодит "бурбакистская математика".

По количеству "сферических коней" квантовую физику, например, никому не обойти не удастся, даже в отдалённой перспективе.

И программисты, тяготеющие к математике, тяготеют к Хаскелям и С++ Точно по тем же причинам, что вместо ясности и реализма им нужна возможность "утончённого абстрагирования".

Это всё досужие домыслы... не имеющие никаких аргументов... Всё как обычно... даже скучно.

[qp]

По количеству "сферических коней" квантовую физику, например, никому не обойти не удастся, даже в отдалённой перспективе.

Интересно, а можно пример такого "коня" привести?

[alexus]

По количеству "сферических коней" квантовую физику, например, никому не обойти не удастся, даже в отдалённой перспективе.

Интересно, а можно пример такого "коня" привести?

Да, конечно... Попробуйте сформулировать, что представляют собой элементарные частицы... например, электрон...

[DIzer]

 .... Ну так что  Vlad - где обсуждение конструктивно обсуждение  "ЯП для физики высоких энергий"?   

[vlad]

.... Ну так что  Vlad - где обсуждение конструктивно обсуждение  "ЯП для физики высоких энергий"?   

Не парься Настоящий фидошник никогда не меняет сабжа

[DIzer]

  это точно.

[qp]

По количеству "сферических коней" квантовую физику, например, никому не обойти не удастся, даже в отдалённой перспективе.

Интересно, а можно пример такого "коня" привести?

Да, конечно... Попробуйте сформулировать, что представляют собой элементарные частицы... например, электрон...

Ну да, наглядно представить себе электрон невозможно. Но это далеко не означает, что его квантовомеханическое описание - это "сферический конь".  Такова уж его природа.

Впрочем, все это к теме не имеет никакого отношения.

[qp]

Кстати, забавно chapel использует синтакс заимствованный из C и Модулы. Там и модули и var с const есть. Хота главное там, конечно, параллельное программирование.

[Губанов Сергей Юрьевич]

Ну да, наглядно представить себе электрон невозможно. Но это далеко не означает, что его квантовомеханическое описание - это "сферический конь".

Вообще-то, квантовомеханическая волновая функция (или вектор состояния, на который действуют вторично квантованные полевые операторнозначные функции) как раз и есть самый натуральный образцово-показательный сферический конь.

Не верите? Попробуйте сформулировать, что такое волновая функция...

[qp]

Кстати, забавно chapel использует синтакс заимствованный из C и Модулы. Там и модули и var с const есть. Хота главное там, конечно, параллельное программирование.

Со сборщиком мусора, правда, есть проблемы:

Open issue. Chapel was originally specified without a delete keyword. The intention was that
Chapel would be implemented with a distributed-memory garbage collector. This is a research
challenge. In order to focus elsewhere, the design has been scaled back. There is an expectation
that Chapel will eventually support an optional distributed-memory garbage collector as well
as a region-based memory management scheme similar to that used in the Titanium language.
Support of delete will likely continue even as these optional features become supported.

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

Кстати, ладно бы электронщики (это вроде как слегка родственно компьютерам) но механические инженеры (не знаю как по русски их назвать. конструктора? мechanical engineer) ступают ровно по тем же граблям.

Ну да... конструктор-механик...

...
В нашем проекте мы сменили уже несколько этих самых инженеров, ибо лепят какую-то лажу (в нашем проекте механика не менее важна нежели алгоритмика или электроника, скорее даже более важна). Механический инженер сам по себе тоже абсолютно бесполезен. Чтобы он был полезен ему необходимо окунуться в предметную область задачи (также как и программисту), а они туда окунаться НЕ ХОТЯТ. Предпочитают жить в собственном виртуальном механико-инженерном мире.
...

Вы примерно об этом:

...
 Искусство Программирования™, как и любая прикладная наука, состоит из двух разделов: теоретического и практического. К первому относятся базовые знания в теории алгоритмов, теории автоматов, математической лингвистике, реляционной алгебре, структурах данных, моделировании систем и т.д. — словом, всего того, что программеры (по идее) должны были изучить на соответствующем факультете в своём институте. Суммируя эти познания, их можно назвать «алгоритмическим мышлением» — способностью построить нужную модель и грамотно разработать алгоритмическое решение задачи, используя доступные теоретические наработки. Второй раздел, практический, предполагает знание уже конкретных языков программирования, аппаратных и програмных платформ, сред разработки и исполнения, нужного middleware-инструментария и т.п., а главное, умение использовать всё это на уровне, необходимом для правильной реализации нужных моделей и алгоритмов. Так вот, «хороший программист» это не тот, кто «обязан знать C», и не тот, кто «знает десять языков», а тот, кто обладает достаточными знанием и опытом в обоих разделах применительно к конкретной задаче. Имею наглость гарантировать, что можно запросто быть «аццки паршивым программистом», будучи полным гуру в одном отдельно взятом разделе. Если у человека хромает «алгоритмичекое мышление», он никогда не построит грамотное решение задачи, если хромают практические навыки — никогда не сможет это решение грамотно реализовать.
...

- т.е. что они у вас только в первом разделе механики?..
Кстати, там ему дальше указывают, что называть всё отнесённое в теорию "алгоритмическим" не слишком верно... оно так...
Грабин, помнится, своих конструкторов-механиков окунал... направляя на производство... а также позволяя особо одарённым, но сферически мыслящим спроектировать, например, несобираемый узел... и посмотреть на результат реализации...