Oberon space
General Category => Общий раздел => Тема начата: vlad от Июнь 08, 2012, 02:00:52 pm
-
По мотивам: http://forum.oberoncore.ru/viewtopic.php?f=89&t=3986
С С++ все понятно - это инструмент для специалиста и для специальных областей.
С фортраном тоже все понятно - морально устарел до безобразия.
И даже с КП все понятно - info21 нашел с ним свое счастье и кто-то еще, возможно, найдет.
А вот если для мэйнстрима в физике - какой современный ЯП потянет? Я бы обозначил следующие критерии:
- высокая производительность
- масштабируемость
- независимость от платформы
- достаточная гибкость (на уровне ЯП общего назначения)
- легкость обучения
Я бы предложил джаву (с кучей оговорок, конечно). Есть другие менения?
-
Джава для числодробилок подходит плохо. Ну, то есть не лучше того же шарпа.
Как во всех других серьезных применениях тут важен не язык, а наработанные технологии, инфраструктура вокруг. Накопленный опыт. Почти любой новый язык который начнут туда внедрять (как единственно верный) скорее всего провалится.
Было несколько попыток разработать новый язык для подобных применений (и они до сих пор есть), их развивали и развивают всякие IBM и подобные. Пока ничего не вышло.
PS. А чем так плох современный фортран кроме названия?
-
Джава для числодробилок подходит плохо. Ну, то есть не лучше того же шарпа.
Так шарп совсем не плох. Вон, Сергей из него выжимает скорость на уровне плюсов. Из недостатков там вендор лок (по факту) и сложность (больше, чем у джавы).
Кроме того, всегда можно подточить JIT. В самом языке нет каких-то принципиальных проблем именно для числодробления (вроде как).
Как во всех других серьезных применениях тут важен не язык, а наработанные технологии, инфраструктура вокруг. Накопленный опыт. Почти любой новый язык который начнут туда внедрять (как единственно верный) скорее всего провалится.
Это все понятно. И это можно учесть в виде "интероперабельности с фортраном" и т.п.
PS. А чем так плох современный фортран кроме названия?
Страшный он. Ну вот список, например, односвязный - как там будет выглядеть?
-
Страшный он. Ну вот список, например, односвязный - как там будет выглядеть?
Так: http://fortranwiki.org/fortran/show/gen_list
-
Ну и до кучи: http://fortranwiki.org/fortran/show/Generic+programming
-
Так шарп совсем не плох. Вон, Сергей из него выжимает скорость на уровне плюсов. Из недостатков там вендор лок (по факту) и сложность (больше, чем у джавы).
Кроме того, всегда можно подточить JIT. В самом языке нет каких-то принципиальных проблем именно для числодробления (вроде как).
Сергей добивается скорости шагнув на уровень ниже, то применяя обедненный Си :-) Я не уверен что визикам поголовно такое стоит давать в руки :-) А уж как он с GC борется… От наглядности (а следовательно и надежности) программы мало что остается. Это уровнем ниже чем даже просто Си.
-
Так: http://fortranwiki.org/fortran/show/gen_list
И чего, не страшно???
-
Так: http://fortranwiki.org/fortran/show/gen_list
И чего, не страшно???
Не могу оценить, ибо фортран этот не знаю. А не зная синтаксиса языка все на нем будет казаться страшным.
-
Не могу оценить, ибо фортран этот не знаю. А не зная синтаксиса языка все на нем будет казаться страшным.
Да там даже и без синтаксиса - банально "многа букафф". Для такой просто вещи. Сравни даже с сишным вариантом. С той же жабой (чур фабрики не писать ;) Про питон и прочие хаскели - вообще молчу...
-
Не могу оценить, ибо фортран этот не знаю. А не зная синтаксиса языка все на нем будет казаться страшным.
Да там даже и без синтаксиса - банально "многа букафф". Для такой просто вещи. Сравни даже с сишным вариантом. С той же жабой (чур фабрики не писать ;) Про питон и прочие хаскели - вообще молчу...
Реализация плюсатого шаблона из stl'я списка оного двусвязного, тоже знаешь ли не мало букафф содержит :-) Причем стиль реализации stl'я даже у меня периодически рвотные позвывы вызывает.
Если по теме, то возможно какая-нибудь Ада была бы хорошим вариантом.
-
Реализация плюсатого шаблона из stl'я списка оного двусвязного, тоже знаешь ли не мало букафф содержит :-)
Ну на самом деле для односвзяного списка, даже шаблонного, букв много не надо. Особенно если не претендовать на роль стандартной либы (STL).
Если по теме, то возможно какая-нибудь Ада была бы хорошим вариантом.
Да, про аду я как-то забыл. Может.
-
Кстати, а вот доказательство того, что "физикам-профессионалам" нельзя доверять выбор языка для высокопроизводительных физических вычислений:
http://forum.oberoncore.ru/viewtopic.php?f=27&t=3987
Есть любители сравнивать простенькие циклы, записав их на Шарпе, в котором -- ко всему прочему -- нет ни удобного LOOP-EXIT, ни многоветочного IF.
Даже если там есть оптимизация, она, надо ожидать, не настроена на распознавание этих управляющих структур.
Из чего следует, что в генерируемом коде вероятен оверхед.
Кстати: процессор может пред-вычислять две ветки одного IF-а, но как он справится с двумя вложенными IF-ами?
Меня здесь не интересует разница между алгоритмами, разными по идее (как простой поиск и Бойер-Мур). Чисто вопросы оптимизации низкого уровня.
Кто-нить может прокомментировать?
-
Да нет, это не доказательство, а не более чем возможный повод к более глубокому изучению вопроса -- и то лишь при большом желании оправдать свои обиды.
А вот тот факт, что Вы назвали это "доказательством", -- сам по себе есть доказательство того, что Вы не понимаете, что такое доказательство.
-
Джава для числодробилок подходит плохо. Ну, то есть не лучше того же шарпа.
А чем, конкретно, плохо подходит?
-
Даже, более конкретно вопрос - чем плох C#, используемый как FORmula TRANslator?
Чувствую, что где-то есть засада, но не пойму где.
-
Кстати, а вот доказательство того, что "физикам-профессионалам" нельзя доверять выбор языка для высокопроизводительных физических вычислений
Не понял тезиса,и как цитата приведенная цитата может служить обоснованием чего либо.
-
Поскольку тема далеко не новая, приведу пару старых ссылок, где этот вопрос обсуждался:
Languages best suited for scientific computing? (http://lambda-the-ultimate.org/node/2720) и
Managed language for scientific computing software (http://stackoverflow.com/questions/125516/managed-language-for-scientific-computing-software)
-
Поскольку тема далеко не новая, приведу пару старых ссылок, где этот вопрос обсуждался:
Languages best suited for scientific computing? (http://lambda-the-ultimate.org/node/2720) и
Managed language for scientific computing software (http://stackoverflow.com/questions/125516/managed-language-for-scientific-computing-software)
и е там также мутно, как в этой ветке...правда там нашелся "Боксер" пропиаривший свой продукт...
-
Кстати, а вот доказательство того, что "физикам-профессионалам" нельзя доверять выбор языка для высокопроизводительных физических вычислений:
http://forum.oberoncore.ru/viewtopic.php?f=27&t=3987
Ржунемогу над Термигалеевым с Лаптевым, которые начали разъяснять Ткачёву что да как в дотнете.
Фёдор Васильевич, раз уж Вы сюда зашли...
Если промежуточный язык шире или 1:1 равен исходному, то оверхед невозможен даже теоретически. MSIL грубо говоря и есть тот же C# (или даже чуточку пошире), но только в специальном бинарном формате. От Франца отличие лишь в том, что Франц код специальным образом архивировал чтобы файл был меньше, а ещё чтобы потом кодогенерацию делать очень быстро. Сейчас это не актуально ибо "бинарные" файлы в дотнете и так крохотные, а компилируются они сейчас не целиком при загрузке, а JIT-ом по первому требованию (по-процедурно, а не по-модульно). То есть если какая-то процедура фактически ещё ни разу не вызывалась, то и машинного кода для неё ещё не сгенерировано. Отсюда в дотнете и делегаты вместо указателей на процедуры (покуда для процедуры ещё нет машинного кода не может быть и указателя (адреса)). Короче, JIT компилятор (в .Net или в Java) на момент генерации машинного кода обладает очень большой информацией чтобы произвести очень качественный машинный код.
Про глубину спекулятивных вычислений выполняемых современными процессорами можно отчасти судить вот по этому тесту (там четыре if выполняющихся практически параллельно, пятый if всё портил): http://oberspace.dyndns.org/index.php/topic,253.msg6395.html#msg6395
-
А вот если для мэйнстрима в физике - какой современный ЯП потянет?
Физики сильно разные бывают. Одним нужно только символьную алгебру. Другим нужны вещи доступные только через ассемблер (MMX, SSE, AVX, а то и вообще доступ к процессорам видиокарты).
-
А вот если для мэйнстрима в физике - какой современный ЯП потянет?
Физики сильно разные бывают. Одним нужно только символьную алгебру. Другим нужны вещи доступные только через ассемблер (MMX, SSE, AVX, а то и вообще доступ к процессорам видиокарты).
Кстати, да. Во ВНИИЭФ активно используют CUDA и OpenCL.
-
Физики сильно разные бывают....
Именно поэтому обсуждение в текущем формате бессмысленно (глупо даже надеяться уйти в них дальше чем в обсуждениях по вышеприведенным ссылкам)...Сначала нужно задать модель интересов физика в области "высоких энергий" с приоритетами, а затем под эту модель применять существующие решения.Так что если Владу , либо Инфо21 это интересно не шутки ради.. то пусть озаботятся составлением качественной модели.
-
Да нет, это не доказательство, а не более чем возможный повод к более глубокому изучению вопроса -- и то лишь при большом желании оправдать свои обиды.
Я безусловно рад, что ты нашел таки повод к более глубокому изучению современного состояния компиляторостроения. А то, что у тебя есть желание оправдать свои обиды (видимо на мейнстрим?), для меня новость.
А вот тот факт, что Вы назвали это "доказательством", -- сам по себе есть доказательство того, что Вы не понимаете, что такое доказательство.
Термин "доказательство" вообще весьма расплывчат. То, что являлось доказательством 3-4 тысячи лет назад, то сейчас таковым доказательством может и не являться. Впрочем, наверно все же ты прав. Доказательсво это обычно таки действие/процесс, а это просто факт свидетельствующий в пользу определенной гипотезы.
Впрочем, все что написано выше слабо относится к тематике рассматриваемого в данном топике вопроса.
-
Вы, г-н Веселовский, оказывается, не понимаете не только что такое доказательство, но и что такое "факт, свидетельствующий".
Трудно Вам.
-
Вы, г-н Веселовский, оказывается, не понимаете не только что такое доказательство, но и что такое "факт, свидетельствующий".
Трудно Вам.
Да, нам не просто. Благодарю за сочувствие. Но и тебе, судя по сайту, тоже не сладко приходится.
-
Если промежуточный язык шире или 1:1 равен исходному, то оверхед невозможен даже теоретически.
Нехорошее утверждение - точнее будет, "всегда возможна трансляция без оверхеда".
-
Трудно Вам.
С точностью до наоборот - чем меньше знаешь , тем меньше проблем имеешь (Горе - оно от ума, еще Грибоедов подметил...)
-
Но и тебе, судя по сайту, тоже не сладко приходится.
Фи... и еще раз фи.. вульгарностью напоминает Акарет/а - но у того хоть есть эксюз тяжелое детство, озлобленность на то что не влазит в его сознание... а так же долгое времяпровождение в коровнике, не способствующее развитию интеллекта.
-
Скажу банальность. В долгосрочной перспективе добро всегда побеждает зло. У злого друзей становится меньше, а врагов больше. Так что в конце-концов Ткачёв плохо кончит.
-
Да ладно товарищи. Все мы с тараканами :P
-
Вообще жаль что все переругались в коровнике. Начиная еще со срача info21 с Владимиром Лосем. Разбрелись все...
-
Скажу банальность. В долгосрочной перспективе добро всегда побеждает зло. У злого друзей становится меньше, а врагов больше. Так что в конце-концов Ткачёв плохо кончит.
Может быть... но на практике чаще побеждает "банальное" бабло(т.е. прагматизм)... - как добро , так и зло...
-
Да ладно товарищи. Все мы с тараканами :P
Кстати, вспомнил что еще фидошное время в эхе SU.ASTRONOMY был крайне адекватный товарищ по имени Петр и фамилии Тараканов, занимался астрофизикой. Эха сейчас в коматозном состоянии, так что я пошел гуглить где он сейчас обитает. И нашел: http://www.astro.spbu.ru/?q=peter До кучи у него еще и блог имеется: http://pphantom.livejournal.com/
И в этом блоге есть даже пост в тему:
http://pphantom.livejournal.com/18418.html
Дошли руки почитать многочисленные описания языка Fortress, который, как предполагается, должен стать новым базовым вычислительным языком. Впечатление оказались двоякими - с одной стороны, местами интересно, с другой - четкое впечатление, что язык разрабатывали не прикладники-вычислители, а специалисты в CS (надо сказать, что впечатление соответствует действительности). Неплохие идеи перемежаются с "розочками на торте", которые в реальной жизни будут только помехой - например, использование unicode в синтаксисе и аппарат для работы с физическими размерностями.
Кроме этого, есть и очевидные глупости. Например, динамическая типизация - трудно представить себе, во-первых, зачем она нужна в "числодробительном" языке, и, во-вторых, как написать для такого языка компилятор, выдающий более-менее производительный код. Синтаксис излишне заумен - лично мне в этом отношении он больше всего напомнил Haskell, который народ именно по этой причине периодически сравнивает с Brainfuck. Ну и традиционная уже "мультипарадигменность", ради которой в язык запихали что-то функциональное, что-то от ООП... также традиционно сделав некую кашу, ненужную на практике, но позволяющую гордо заявлять, что "и это [лямбда, инкапсуляция и т.д. - подставлять по вкусу] в нем тоже есть".
Но самое забавное, это общее впечатление. Fortress чем-то очень похож... на Алгол-60. Не конструкциями, а общим стилем языка - достаточно красивого, удобного, пожалуй, для "книжного" описания алгоритмов, но малопригодного для реальных задач.
Кроме того, там достаточно вменяемые комментарии к посту.
-
Отсюда: (http://forum.oberoncore.ru/viewtopic.php?p=73010&sid=18b9a81bacf33b7b1720c9cf90a37693#p73010)
В общем, всегда MSIL.
Специалисты по оптимизирующим компиляторам над подобного рода тестами -- даже без MSIL -- издевались, когда я последний раз в Новосибирске на эти темы с ними просвещался.
Думал, может, тут что-то скрыто новое, мало ли.
Ни хрена тут не скрыто. Одна всё та же ... гениальность.
А до меня, кстати, только что дошло, что Ткачёв элементарно не знает вот про это: (смотри скриншот во вложении). Мсил бывает эни цэпэушный, итаниумный, икс шестьдесят четвёртый, икс восемьдесят шестой. Вот ржака! :) :) :)
-
И в этом блоге есть даже пост в тему:
http://pphantom.livejournal.com/18418.html
Я, видимо, вообще понятия не имею про эти численные расчёты, так как не могу понять, чем им там мешают размерности? Зачем задачу нужно обезразмеривать?
-
Отсюда: (http://forum.oberoncore.ru/viewtopic.php?p=73010&sid=18b9a81bacf33b7b1720c9cf90a37693#p73010)
В общем, всегда MSIL.
Специалисты по оптимизирующим компиляторам над подобного рода тестами -- даже без MSIL -- издевались, когда я последний раз в Новосибирске на эти темы с ними просвещался.
Думал, может, тут что-то скрыто новое, мало ли.
Ни хрена тут не скрыто. Одна всё та же ... гениальность.
А до меня, кстати, только что дошло, что Ткачёв элементарно не знает вот про это: (смотри скриншот во вложении). Мсил бывает эни цэпэушный, итаниумный, икс шестьдесят четвёртый, икс восемьдесят шестой. Вот ржака! :) :) :)
Кстати, а чем они отличаются? То есть есть где-то спеки на них?
-
Кстати, а чем они отличаются? То есть есть где-то спеки на них?
Да нету никаких спек. Чисто ограничительные вещи. Просто ты с самого начала декларируешь, что данную программу собираешься запускать только на такой-то вот процессорной архитектуре. Будет ли компилятор делать какие-то специфичные для этой процессорной архитектуры оптимизации или не будет это уже его личное дело (может, но не обязан).
Конкретную таргетную платформу, в частности, нужно выставлять если ты используешь нативные библиотеки этой платформы (без них запускать твою программу [на других платформах] смысла нет).
-
Кстати, а чем они отличаются? То есть есть где-то спеки на них?
Как-то я столкнулся -- подцепили Win32-dll-ку к сишарпной программе (AnyCPU), всё было окей, пока не запустили эту прогу на Win7 64bit -- вывалилось в осадок. Перекомпилировали шарпную прогу в режиме x86 -- проблема исчезла...
-
А зачем мне голову засорять всякой дрянью.
Пусть Губанов засоряет себе -- и цена его тестам соответствующая.
---
Обсуждение тут ЯП для прикладной области, о которой у тутошней публики самое смутное представление, да еще с гнутьем пальцев -- вот это ржака настоящая.
-
Сначала нужно задать модель интересов физика в области "высоких энергий" с приоритетами, а затем под эту модель применять существующие решения.
Ну так я и попытался обозначить критерии в самом первом сообщении. Общие критерии. Если лезть во все частности и сразу, то ничего не получится. Для очень частной задачи берем оберон и допиливаем под задачу ;)
Так что если Владу , либо Инфо21 это интересно не шутки ради.. то пусть озаботятся составлением качественной модели.
Я не собираюсь стать физиком в области высоких энергий в ближайшее время :) Тем не менее, почему бы не помочь товарищам определиться с тем, что же им на самом деле надо (толку от того, что они ругаются на в общем-то хороший (для своих задач и для своего времени), но неправильно выбранный ЯП?)
-
Нашёл, вот, один документ по стандарту написания программ для C++ (для тех, кто не читал): http://www2.research.att.com/~bs/JSF-AV-rules.pdf
Неужели физики в ЦЕРНе не могут составить для себя подобный документ? Хоть для Ады, Фортрана или любого другого языка?
-
Обсуждение тут ЯП для прикладной области, о которой у тутошней публики самое смутное представление, да еще с гнутьем пальцев -- вот это ржака настоящая.
Вытащить какую-нибудь информацию по прикладной области, конкретно у тебя, невозможно. Символьная алгебра, динамические структуры. Все. Вот, например, про выбор "именно ББ" для обучения намного больше материала...
-
Вытащить какую-нибудь информацию по прикладной области, конкретно у тебя, невозможно. Символьная алгебра, динамические структуры. Все.
Ну так это же ноу хау, конкуренция, все дела. Это не школьная информатика, которая всем открыта... :P
-
А вот если для мэйнстрима в физике - какой современный ЯП потянет? Я бы обозначил следующие критерии:
- высокая производительность
- масштабируемость
- независимость от платформы
- достаточная гибкость (на уровне ЯП общего назначения)
- легкость обучения
http://en.wikipedia.org/wiki/SISAL
http://www2.cmp.uea.ac.uk/~jrwg/Sisal/
Простой паскалеподобный синтаксис, автоматическое распараллеливание программ (гораздо более эффективное, чем ручное на сях), разработан самими физиками (или кто там у них в лаборатории LLNL)...
Но, к сожалению, таки не пошло в массы, видимо, и правда, физики обречены на работу с фортраном...
-
Сначала нужно задать модель интересов физика в области "высоких энергий" с приоритетами, а затем под эту модель применять существующие решения.
Ну так я и попытался обозначить критерии в самом первом сообщении. Общие критерии. Если лезть во все частности и сразу, то ничего не получится. Для очень частной задачи берем оберон и допиливаем под задачу ;)
Так что если Владу , либо Инфо21 это интересно не шутки ради.. то пусть озаботятся составлением качественной модели.
Я не собираюсь стать физиком в области высоких энергий в ближайшее время :) Тем не менее, почему бы не помочь товарищам определиться с тем, что же им на самом деле надо (толку от того, что они ругаются на в общем-то хороший (для своих задач и для своего времени), но неправильно выбранный ЯП?)
1.Словестный понос...
2. Не хотите срать - жопу не мучайте! (как себе . так и другим).
И это хорошо что Инфо21 слегка остудил вас... если бы вы с суконным рылом начали говнить, скажем так, в моей епархии... все закончилось гораздо менее благопристойно...
И вообще , господа, предлагаю относится друг к другу с уважением. Вы можете рассуждать, насколько разумен (или безумен) доктор... Но глупо отрицать что он имее 2 справки гособразца о том что не дурак в СВОЕЙ области , в которую вы вторгаетесь без извинений и малейших на то оснований(более того, я просмотрел ваши жабологи - смеха ради)....
-
Простой паскалеподобный синтаксис, автоматическое распараллеливание программ (гораздо более эффективное, чем ручное на сях), разработан самими физиками (или кто там у них в лаборатории LLNL)...
Массивам и потоковой обработке уделено много внимания, хорошо. Но не увидел (мельком смотрел) ничего про инкапсуляцию и расширяемость, т.е. архитектурные аспекты не освещены.
-
И это хорошо что Инфо21 слегка остудил вас... если бы вы с суконным рылом начали говнить, скажем так, в моей епархии... все закончилось гораздо менее благопристойно...
И вообще , господа, предлагаю относится друг к другу с уважением.
Взаимоисключающие параграфы детектед! ;)
Вы можете рассуждать, насколько разумен (или безумен) доктор... Но глупо отрицать что он имее 2 справки гособразца о том что не дурак в СВОЕЙ области , в которую вы вторгаетесь без извинений и малейших на то оснований(более того, я просмотрел ваши жабологи - смеха ради)....
1. Никто не говорил, что info21 дурак с своей области.
2. info21 много раз выставлял себя дураком в области, в которой только он сам считает себя не дураком (не имея справки гособразца). При этом он не особо парится в оценках людей, которые такие справки имеют.
-
И это хорошо что Инфо21 слегка остудил вас... если бы вы с суконным рылом начали говнить, скажем так, в моей епархии... все закончилось гораздо менее благопристойно...
И вообще , господа, предлагаю относится друг к другу с уважением.
Взаимоисключающие параграфы детектед! ;)
Вы можете рассуждать, насколько разумен (или безумен) доктор... Но глупо отрицать что он имее 2 справки гособразца о том что не дурак в СВОЕЙ области , в которую вы вторгаетесь без извинений и малейших на то оснований(более того, я просмотрел ваши жабологи - смеха ради)....
1. Никто не говорил, что info21 дурак с своей области.
2. info21 много раз выставлял себя дураком в области, в которой только он сам считает себя не дураком (не имея справки гособразца). При этом он не особо парится в оценках людей, которые такие справки имеют.
1 Детектед - ментальная ограниченность
2. Тогда составьте модель физика работающего в области "высоких энергий" и не бздите.. (там уж посмотрим, насколько она состоятельна - и насколько состоятельны Ваши претензии на рассуждения в этой области)
-
1 Детектед - ментальная ограниченность
2. Тогда составьте модель физика работающего в области "высоких энергий" и не бздите.. (там уж посмотрим, насколько она состоятельна - и насколько состоятельны Ваши претензии на рассуждения в этой области)
У меня нет претензий на непогрешимую состоятельность моих ограничивающих критериев, указанных в первом сообщении (и уж тем более у меня нет модели физика). Критерии были даны в качестве затравки к обсуждению из общих (обывательских, если хотите) соображений. Физики, работающие в области "высоких энергий", приглашаются к обсуждению/уточнению этих критериев.
Если ты считаешь, что обсуждение обречено на переливание из пустого в порожнее (хотя бы из-за отсутствия здесь нужных физиков (хотя, вот, info21 появился) или отсутсвия желания у этих физиков), то просто не пиши сюда и тем тихонько загнется сама собой ;)
-
Исходя из особенностей моделирования физических процессов, лучше всего будут подходить языки из семейства Array Programming Language. Я так думаю. Физикам ООП не обязателен и также в их требованиях врядли имеется необходимость в построении сложных программных комплексов. Итого, физикам нужно оставить несложный инструмент для расчетов типа упрощенной версии Фортрана, а для сложных связующих использовать языки хоть C++, хоть Oberon или Python. Тогда физикам не придется выходить за пределы своей предметной области.
-
Если ты считаешь, что обсуждение обречено на переливание из пустого в порожнее (хотя бы из-за отсутствия здесь нужных физиков (хотя, вот, info21 появился) или отсутсвия желания у этих физиков), то просто не пиши сюда и тем тихонько загнется сама собой ;)
;D ;D OK
-
Исходя из особенностей моделирования физических процессов, лучше всего будут подходить языки из семейства Array Programming Language. Я так думаю. Физикам ООП не обязателен и также в их требованиях врядли имеется необходимость в построении сложных программных комплексов. Итого, физикам нужно оставить несложный инструмент для расчетов типа упрощенной версии Фортрана, а для сложных связующих использовать языки хоть C++, хоть Oberon или Python. Тогда физикам не придется выходить за пределы своей предметной области.
Ну как я понял из высказываний info21, связующая составляющая тоже важна. Т.е., применительно к ББ очень удобно, когда и "расчеты" и "скриптинг" выполняются в рамках одного инструмента, без переключения и без оверхеда (во всех смыслах) на переход от одного к другому. Опять же, пресловутые "сложные динамические структуры", которые так любит info21, невозможны в "упрощенной версии фортрана".
-
Но не увидел (мельком смотрел) ничего про инкапсуляцию и расширяемость, т.е. архитектурные аспекты не освещены.
А им, физикам, в их расчётах это действительно надо?
-
Опять же, пресловутые "сложные динамические структуры", которые так любит info21, невозможны в "упрощенной версии фортрана".
"Упрощённая версия Фортрана" -- думаю, здесь имелось в виду, что такой изи-фортран должен быть прост для использования физиками, а не упрощён для создателей компилятора.
Так что в таком "фортране" вполне возможны удобные средства работы со списками и прочими динамическими структурами данных...
-
Опять же, пресловутые "сложные динамические структуры", которые так любит info21, невозможны в "упрощенной версии фортрана".
"Упрощённая версия Фортрана" -- думаю, здесь имелось в виду, что такой изи-фортран должен быть прост для использования физиками, а не упрощён для создателей компилятора.
Так что в таком "фортране" вполне возможны удобные средства работы со списками и прочими динамическими структурами данных...
А зачем?.. ФорТран создавался с вполне определённой целью: транслировать формулы (выполнять расчёт по известным формулам)... И он вполне соответствует своему предназначению. Типичная программа на ФорТран: есть исходный массив данных, которые нужно обработать по определённым формулам, и результаты выдать в результирующий массив. И с такими (или близкими по сути) программами ФорТран вполне успешно справлялся. Если не лень, то посмотрите на сборники научных подпрограмм (десятки, если не сотни, тысяч функций) ориентированных на подобную обработку. Поскольку потребности в расчётах никуда не исчезли, то... переписывать всё это... и ради чего?.. Чтобы втащить баги, в код, который шлифовался десятилетиями?..
Стив Лайонел (Steve Lionel) развивает ФорТран... о чём можно почитать в интервью с ним (http://software.intel.com/ru-ru/blogs/2011/09/27/2005301/)... Надо ли это делать?.. Ему виднее...
Что касается физиков... Если для них компьютер остаётся большим калькулятором, то ФорТран им в помощь... Если же они научились (в чём я сомневаюсь) моделировать... то нужны другие средства... Но какие?.. Не думаю, что Оберон или С++ или функциональные языки подходят для этого класса задач... Выбирать, по сути, не из чего.
(причём здесь работа со списками?.. оставьте это преподавателям очень средней школы...)
-
А зачем?.. ФорТран создавался с вполне определённой целью: транслировать формулы (выполнять расчёт по известным формулам)... И он вполне соответствует своему предназначению. Типичная программа на ФорТран: есть исходный массив данных, которые нужно обработать по определённым формулам, и результаты выдать в результирующий массив. И с такими (или близкими по сути) программами ФорТран вполне успешно справлялся. Если не лень, то посмотрите на сборники научных подпрограмм (десятки, если не сотни, тысяч функций) ориентированных на подобную обработку. Поскольку потребности в расчётах никуда не исчезли, то... переписывать всё это... и ради чего?.. Чтобы втащить баги, в код, который шлифовался десятилетиями?..
А никто и не призывает же переписывать старый, проверенный веками софт с фортрана на новый язык.
От нового языка требуется лишь что бы он был удобнее фортрана (на который физики плюются долгие годы), проще с++ (который эти физики так и не осилили за эти же долгие годы), и при этомне терял возможности вызова всех эти фортрановских подпрограмм...
Что касается физиков... Если для них компьютер остаётся большим калькулятором, то ФорТран им в помощь... Если же они научились (в чём я сомневаюсь) моделировать... то нужны другие средства... Но какие?.. Не думаю, что Оберон или С++ или функциональные языки подходят для этого класса задач... Выбирать, по сути, не из чего.
Ну есть же специализированные языки моделирования типа GPSS, всякие математические пакеты типа Маткад и прочие...
(причём здесь работа со списками?.. оставьте это преподавателям очень средней школы...)
Вот тот же info21 как-то рассказывал про свой проект (по физике), в котором он на блекбоксе реализовал символьную математику и которую конкуренты так и не смогли повторить на яве -- он там вроде использовал динамические списки, рассылал по ним там всякие активные сообщения и тд. и тп.
То есть такие вещи всё же нужны физикам...
-
Вот тот же info21 как-то рассказывал про свой проект (по физике), в котором он на блекбоксе реализовал символьную математику и которую конкуренты так и не смогли повторить на яве -- он там вроде использовал динамические списки, рассылал по ним там всякие активные сообщения и тд. и тп.
То есть такие вещи всё же нужны физикам...
Там вроде бы конкурент на С++ писал. Там вроде бы были тонкости с ручным "свопингом", ибо вся задача в память не лезла. (понятно что алгоритмических тонкостей там было больше, но из чисто технических помню эту)
-
Вот тот же info21 как-то рассказывал про свой проект (по физике), в котором он на блекбоксе реализовал символьную математику и которую конкуренты так и не смогли повторить на яве -- он там вроде использовал динамические списки, рассылал по ним там всякие активные сообщения и тд. и тп.
То есть такие вещи всё же нужны физикам...
Там вроде бы конкурент на С++ писал. Там вроде бы были тонкости с ручным "свопингом", ибо вся задача в память не лезла. (понятно что алгоритмических тонкостей там было больше, но из чисто технических помню эту)
Судя по всему, физикам нередко приходится выходить за рамки своей основной предметной деятельности. Вот если бы занимались одними лишь формулами, то Фортрана вполне достаточно. Так нет же, нужно ещё и огромные данные с периферийных устройств считывать, а потом ещё на экран результат показывать.
Вот поэтому я и упомянул про упрощённый Фортран - тот который занимался бы только обработкой данных по формулам, и не более. А к остальному нужно пристыковать интерфейс для доступа к остальным языкам общего назначения (ввод-вывод, логика). Точнее, наоборот, интерфейс доступа из языков общего назначения - к Фортрановским блокам обработки данных.
-
Стив Лайонел (Steve Lionel) развивает ФорТран... о чём можно почитать в интервью с ним (http://software.intel.com/ru-ru/blogs/2011/09/27/2005301/)... Надо ли это делать?.. Ему виднее...
из комментариев понравилось:
Peter Tarakanov:
"Мы действуем именно таким образом. Студентам читается общий курс программирования с C, Фортраном и основами C++, а затем им подсовываются более-менее приличные вычислительные задачи. В первый же месяц-два выясняется, что те, кто пишет на Фортране, справляются с заданиями быстрее и получают в итоге намного более эффективный код, чем любители C, а те некоторые, кто использует для тех же целей Java, C# или еще что-нибудь "новое и модное", просто сдыхают от объема работы. Уже к концу первого семестра желание писать вычислительные задачи на C/C++/C#/Java/Python и т.д. вместо Фортрана пропадает начисто у всех без исключения."
-
Вот тот же info21 как-то рассказывал про свой проект (по физике), в котором он на блекбоксе реализовал символьную математику и которую конкуренты так и не смогли повторить на яве -- он там вроде использовал динамические списки, рассылал по ним там всякие активные сообщения и тд. и тп.
То есть такие вещи всё же нужны физикам...
Да в том ведь и дело, что такие физики занимаются несвязанными с физикой делами. Нечего физикам лезть в дебри искусства программирования. Им нужны готовые или полуготовые инструменты, будь то Фортран или редактор символьных формул.
-
Стив Лайонел (Steve Lionel) развивает ФорТран... о чём можно почитать в интервью с ним (http://software.intel.com/ru-ru/blogs/2011/09/27/2005301/)... Надо ли это делать?.. Ему виднее...
из комментариев понравилось:
Peter Tarakanov:
"Мы действуем именно таким образом. Студентам читается общий курс программирования с C, Фортраном и основами C++, а затем им подсовываются более-менее приличные вычислительные задачи. В первый же месяц-два выясняется, что те, кто пишет на Фортране, справляются с заданиями быстрее и получают в итоге намного более эффективный код, чем любители C, а те некоторые, кто использует для тех же целей Java, C# или еще что-нибудь "новое и модное", просто сдыхают от объема работы. Уже к концу первого семестра желание писать вычислительные задачи на C/C++/C#/Java/Python и т.д. вместо Фортрана пропадает начисто у всех без исключения."
И это очень правильный подход. Намного лучше насильственного навязывания фортрана как единственно верного языка для этого класса задач (с попутным чмырением c/c++/c#/python на лекциях).
-
Да в том ведь и дело, что такие физики занимаются несвязанными с физикой делами. Нечего физикам лезть в дебри искусства программирования. Им нужны готовые или полуготовые инструменты, будь то Фортран или редактор символьных формул.
Уже не раз обсуждалось (с примерами - как Дейкстра; ну или из личных наблюдений...), что самые сильные и адекватные программисты получаются из физиков или инженеров.
Вы уверены, что люди фундаментального рода деятельности не способны решить проблемы "собственно программирования" более эффективно и адекватно, чем ИТ-шники?
-
(причём здесь работа со списками?.. оставьте это преподавателям очень средней школы...)
Работа со списками - это просто проверка на вшивость :) Если оно выглядит громоздко (для не встроенных списков), то ожидать построения четких моделей данных не приходится.
-
Уже не раз обсуждалось (с примерами - как Дейкстра; ну или из личных наблюдений...), что самые сильные и адекватные программисты получаются из физиков или инженеров.
Вы уверены, что люди фундаментального рода деятельности не способны решить проблемы "собственно программирования" более эффективно и адекватно, чем ИТ-шники?
Вот хотелось бы более-менее полную статистику на эту тему.
А то ведь можно ещё и адмирала Грейс Хоппер, компиляторщицу по совместительству, вспомнить...
-
И вообще сама эта характеристика "самый сильный и адекватный программист" -- тоже непонятно как её определять.
Вон Сергей Зефиров -- самый сильный программист на Хаскелле в мире, он такие штанги поднимает, что нам и не снилось, и вполне адекватен, я думаю... :P
-
Да в том ведь и дело, что такие физики занимаются несвязанными с физикой делами. Нечего физикам лезть в дебри искусства программирования. Им нужны готовые или полуготовые инструменты, будь то Фортран или редактор символьных формул.
Уже не раз обсуждалось (с примерами - как Дейкстра; ну или из личных наблюдений...), что самые сильные и адекватные программисты получаются из физиков или инженеров.
Вы уверены, что люди фундаментального рода деятельности не способны решить проблемы "собственно программирования" более эффективно и адекватно, чем ИТ-шники?
Банально, у специалистов этих категорий разная квалификация. И нечего их смешивать. Чтобы каждый занимался своим делом.
Читал про одного врача-анестезиолога по имени Кон Коливас, который занимался написанием патчей по улучшению производительности ядра Линукса, но в итоге из этого ничего хорошего не вышло. :-\
-
Чтобы среднестатистические ИТ-шники разводили всякую хрень, просто по недопониманию принципов научного и инженерного творчества? :)
Речь не о том, что "просто программист" не может быть "адекватным", а про то, что множество задач обычного, массового программирования не формирует многих важных представлений в голове.
Поэтому, приходя в более серьёзные сферы приложений, первое, что нужно сделать - это начать расширять свои представления и корректировать привычки, развитые ранее.
-
Чтобы среднестатистические ИТ-шники разводили всякую хрень, просто по недопониманию принципов научного и инженерного творчества? :)
Речь не о том, что "просто программист" не может быть "адекватным", а про то, что множество задач обычного, массового программирования не формирует многих важных представлений в голове.
Поэтому, приходя в более серьёзные сферы приложений, первое, что нужно сделать - это начать расширять свои представления и корректировать привычки, развитые ранее.
Для этого ИТ-шников нужно учить. Дополнительный кругозор всегда идёт на пользу, но не стоит смешивать эти области. Но нужны более чёткие определения предметной области, чтобы программист чётко выполнял свои задания. Плохо, когда программисту нужно быть физиком. И наоборот тоже. Оба напортачат, что потом мозги сломаешь чтобы что-то понять/изменить в коде.
-
Дело в том, что программирование, в чистом, незамусоренном виде - это не такая специфичная область. Даже наоборот - это квинтэссенция всеобщих, важных принципов организации, структурирования, проектирования.
С учётом того, что программирование нужно везде, есть ли смысл в армии "чистых программистов"?
Любому предметнику будет только польза от владения программированием. С другой стороны, основная компетентность программистов - именно в приложениях; либо в "мусорных знаниях", как бороться с какой-нибудь сегодняшней проблемой собственно ИТ.
-
Дело в том, что программирование, в чистом, незамусоренном виде - это не такая специфичная область. Даже наоборот - это квинтэссенция всеобщих, важных принципов организации, структурирования, проектирования.
С учётом того, что программирование нужно везде, есть ли смысл в армии "чистых программистов"?
Любому предметнику будет только польза от владения программированием. С другой стороны, основная компетентность программистов - именно в приложениях; либо в "мусорных знаниях", как бороться с какой-нибудь сегодняшней проблемой собственно ИТ.
Это отражает нынешнее положение в ВУЗах и на рынке труда.
Задача программиста в идеале состоит в том, чтобы уметь строить ПО в соответствие с требованиями предметной области. На самом деле ему приходится быть бухгалтером, дизайнером, физиком и врачом. Что получаем в итоге? Из-за того, что смешиваются инженерия построения ПО и предметные области, получаем ПО с высокой стоимостью поддержки по причине нехватки знаний в данной области. Предметная область настолько глубоко "закодирована" в ПО, что даже те, кто написал его, с трудом разбираются в нём. А ведь у ПО есть срок поддержки и после его устаревания следует заново воссоздавать знания предметной области по крупицам из того дикого кода.
Введён инструментарий указателей и функции для работы с оперативной памятью (по аналогии с языком С)
Похоже, путь развития Фортрана пошёл по неверному пути, начиная с версии Fortran 90. Собственно, из-за этого у физиков проблемы с Фортраном и начались.
-
На самом деле ему приходится быть бухгалтером, дизайнером, физиком и врачом.
А не наоборот? Физикам и прочим приходится быть программистами?
Похоже, путь развития Фортрана пошёл по неверному пути, начиная с версии Fortran 90. Собственно, из-за этого у физиков проблемы с Фортраном и начались.
Опять с ног на голову. Проблемы закончились. Сейчас как раз начался ренесанс Фортрана. На современном Фортране можно писать почти 1-в-1 как на столь ненаглядном Обероне. Можно даже ключевые слова капсом, кому нужно.
Для примеру QuickSort'ы из АиСД:
MODULE sorts
USE math
IMPLICIT NONE
PRIVATE
PUBLIC :: sorts_non_recursive_quick_sort, sorts_quick_sort
CONTAINS
! Non-recursive implementation of Quicksort algorithm.
! From N. Wirth, Algorithms and Data Structures, Oberon version: August 2004.
!
SUBROUTINE sorts_non_recursive_quick_sort(array)
INTEGER, DIMENSION(:), INTENT(INOUT) :: array
INTEGER, DIMENSION(:), ALLOCATABLE :: left_bounds, right_bounds
INTEGER :: left_index, right_index, left_bound, right_bound, s, &
pivot_element, temp, stack_size
! The stack size can be limited to lb(n)
stack_size = ceiling(math_lb(real(size(array))))
ALLOCATE (left_bounds(stack_size), right_bounds(stack_size))
s = 1
left_bounds(1) = 1
right_bounds(1) = size(array)
DO
! Take top request from stack.
left_bound = left_bounds(s)
right_bound = right_bounds(s)
s = s - 1
DO
left_index = left_bound
right_index = right_bound
pivot_element = array((left_bound + right_bound) / 2)
DO
DO WHILE (array(left_index) < pivot_element)
left_index = left_index + 1
END DO
DO WHILE (pivot_element < array(right_index))
right_index = right_index - 1
END DO
IF (left_index <= right_index) THEN
temp = array(left_index)
array(left_index) = array(right_index)
array(right_index) = temp
left_index = left_index + 1
right_index = right_index - 1
END IF
IF (left_index > right_index) EXIT
END DO
IF (right_index - left_bound < right_bound - left_index) THEN
! Stack request for sorting right partition ...
IF (left_index < right_bound) THEN
s = s + 1
left_bounds(s) = left_index
right_bounds(s) = right_bound
END IF
! and continue sorting left partition.
right_bound = right_index
ELSE
! Stack request for sorting left partition ...
IF (left_bound < right_index) THEN
s = s + 1
left_bounds(s) = left_bound
right_bounds(s) = right_index
END IF
! and continue sorting right partition.
left_bound = left_index
END IF
IF (left_bound >= right_bound) EXIT
END DO
IF (s < 1) EXIT
END DO
DEALLOCATE (left_bounds, right_bounds)
END SUBROUTINE sorts_non_recursive_quick_sort
SUBROUTINE sorts_quick_sort(array)
INTEGER, DIMENSION(:), INTENT(INOUT) :: array
CALL sort(1, size(array))
CONTAINS
RECURSIVE SUBROUTINE sort(left_bound, right_bound)
INTEGER, INTENT(IN) :: left_bound, right_bound
INTEGER :: left_index, right_index, pivot_element, temp
left_index = left_bound
right_index = right_bound
pivot_element = array((left_bound + right_bound) / 2)
DO
DO WHILE (array(left_index) < pivot_element)
left_index = left_index + 1
END DO
DO WHILE (pivot_element < array(right_index))
right_index = right_index - 1
END DO
IF (left_index <= right_index) THEN
temp = array(left_index)
array(left_index) = array(right_index)
array(right_index) = temp
left_index = left_index + 1
right_index = right_index - 1
END IF
IF (left_index > right_index) EXIT
END DO
IF (left_bound < right_index) CALL Sort(left_bound, right_index)
IF (left_index < right_bound) CALL Sort(left_index, right_bound)
END SUBROUTINE sort
END SUBROUTINE sorts_quick_sort
END MODULE sorts
Конечно, 1-в-1 писать зачастую бессмысленно, так как, например, отказываться от развитых средст работы с массивами - себе дороже. А interoperability с сишечкой - суровая реальность. Зато можно биндится к сишным либам без геморроя.
-
Задача программиста в идеале состоит в том, чтобы уметь строить ПО в соответствие с требованиями предметной области.
Сомневаюсь, что у предметной области есть требования.
И как же программист будет реализовывать требования, если он ни бум-бум в предметной области и термины из требований понимает "интуитивно"?На самом деле ему приходится быть бухгалтером, дизайнером, физиком и врачом. Что получаем в итоге? Из-за того, что смешиваются инженерия построения ПО и предметные области, получаем ПО с
Мы получаем в итоге то, что есть сейчас. То есть, сейчас IT-компании преимущественно работают и учат работать так, как Вы описали.
Но на самом деле, программирование здесь сродни письменности. Никто не учит писать только ради того, чтобы уметь писать. С другой стороны, тяжело стать инженером не имея этого навыка (письма). Так что программист должен быть помимо программиста ещё кем-то из "бухгалтером, дизайнером, физиком и врачом", чтобы хотя бы понимать, что от него требуется. Без необходимости получать описания всех подводных камней (потому что специалисту в своей области банально не придёт в голову сделать что-то, о чём чистый it-шник может подумать в силу неосведомлённости).
-
Да в том ведь и дело, что такие физики занимаются несвязанными с физикой делами. Нечего физикам лезть в дебри искусства программирования. Им нужны готовые или полуготовые инструменты, будь то Фортран или редактор символьных формул.
Уже не раз обсуждалось (с примерами - как Дейкстра; ну или из личных наблюдений...), что самые сильные и адекватные программисты получаются из физиков или инженеров.
Статистику в студию, иначе это высказывание имеет ценность ОБС (одна бабка сказала). Причем статистика по адекватным программистам не старше скажем 45 лет (наука новая, понятно что тем кому старше никак не могли изучаться непосредственно по CS-специальности, просто потому что CS их моложе).
PS. И да, следует различать IT и CS. Первое - это уровень сисадмина.
-
На самом деле ему приходится быть бухгалтером, дизайнером, физиком и врачом.
А не наоборот? Физикам и прочим приходится быть программистами?
Похоже, путь развития Фортрана пошёл по неверному пути, начиная с версии Fortran 90. Собственно, из-за этого у физиков проблемы с Фортраном и начались.
Опять с ног на голову. Проблемы закончились. Сейчас как раз начался ренесанс Фортрана. На современном Фортране можно писать почти 1-в-1 как на столь ненаглядном Обероне. Можно даже ключевые слова капсом, кому нужно.
Конечно, 1-в-1 писать зачастую бессмысленно, так как, например, отказываться от развитых средст работы с массивами - себе дороже. А interoperability с сишечкой - суровая реальность. Зато можно биндится к сишным либам без геморроя.
Так о том и речь, что и наоборот тоже. Поэтому для того, чтобы избавиться от этого явления, требуется создать физикам подходящий инструмент, в котором им не понадобится входить в тонкости инженерии ПО. По мне, со стороны наблюдателя, нынешний Фортран довольно сильно оброс излишними понятиями, связанными с этими тонкостями. Думаю, что лучшим выходом будет надстройка интерфейса над вычислительными модулями Фортрана, нежели лепить всё для поддержки внешних средств. Просто отдать всё невычислетельное другим языкам.
Задача программиста в идеале состоит в том, чтобы уметь строить ПО в соответствие с требованиями предметной области.
Сомневаюсь, что у предметной области есть требования.
И как же программист будет реализовывать требования, если он ни бум-бум в предметной области и термины из требований понимает "интуитивно"?На самом деле ему приходится быть бухгалтером, дизайнером, физиком и врачом. Что получаем в итоге? Из-за того, что смешиваются инженерия построения ПО и предметные области, получаем ПО с
Мы получаем в итоге то, что есть сейчас. То есть, сейчас IT-компании преимущественно работают и учат работать так, как Вы описали.
Но на самом деле, программирование здесь сродни письменности. Никто не учит писать только ради того, чтобы уметь писать. С другой стороны, тяжело стать инженером не имея этого навыка (письма). Так что программист должен быть помимо программиста ещё кем-то из "бухгалтером, дизайнером, физиком и врачом", чтобы хотя бы понимать, что от него требуется. Без необходимости получать описания всех подводных камней (потому что специалисту в своей области банально не придёт в голову сделать что-то, о чём чистый it-шник может подумать в силу неосведомлённости).
Я же не говорю, что нужно разделить ИТ-шников и предметников железобетонной стеной. Инженер ПО вплотную работает с предметником, составляя спецификацию при помощи формализации деятельности, по которой затем поручает работу программистам.
Разумеется, программист должен разбираться в предмете, и без этого никак. При этом программист выполняет свою работу, не влезая в деятельность физики или другого предмета. А физик, в свою очередь, не будет заниматься чуждой ему деятельностью отладки программных компонентов.
-
Читал про одного врача-анестезиолога по имени Кон Коливас, который занимался написанием патчей по улучшению производительности ядра Линукса, но в итоге из этого ничего хорошего не вышло. :-\
Его патчи были вполне нормальными, но ему надоело ими заниматься, плюс ещё эта линуксовая бюрократия... Его патчи были ориентированы на улучшение ядра для десктопа, тогда как главное и основное для linoops'а -- это серверы, где его патчи были бесполезными...
-
А никто и не призывает же переписывать старый, проверенный веками софт с фортрана на новый язык.
От нового языка требуется лишь что бы он был удобнее фортрана (на который физики плюются долгие годы), проще с++ (который эти физики так и не осилили за эти же долгие годы), и при этомне терял возможности вызова всех эти фортрановских подпрограмм...
Угу... и этот новый язык должен будет поддерживать несколько точек входа в подпрограмму... в том числе.
Вот тот же info21 как-то рассказывал про свой проект (по физике), в котором он на блекбоксе реализовал символьную математику и которую конкуренты так и не смогли повторить на яве
Это видимо как в анекдоте про "неуловимого Джо"...
-
Это видимо как ...
С облегчением!
-
Угу... и этот новый язык должен будет поддерживать несколько точек входа в подпрограмму... в том числе.
Не вижу в этом особых проблем. Эти несколько точек входа можно оформить как несколько разных подпрограмм.
Это видимо как в анекдоте про "неуловимого Джо"...
Ну это мы можем только гадать, так как достоверной информации о тех конкурентах вераоятно и у самого info21 нет... 8)
-
Дело в том, что программирование, в чистом, незамусоренном виде - это не такая специфичная область. Даже наоборот - это квинтэссенция всеобщих, важных принципов организации, структурирования, проектирования.
Какая же "не такая специфическая область"?.. А почему "квинтэссенция" не может быть "специфической областью"?.. Математика, например, это "квинтэссенция" или нет?.. А та же физика?..
С учётом того, что программирование нужно везде, есть ли смысл в армии "чистых программистов"?
Мысль!!! Это надо на видное место поместить... И "чистых математиков" тоже долой, пусть "грязные бухгалтера" высшую математику развивают!.. "Чистых философов" - дустом посыпать... три раза в день, чтобы неповадно было... Пусть сантехники философию развивают... потому как, они по определению грязные, и снабжены житейской мудростью и практичностью. :)
Любому предметнику будет только польза от владения программированием.
Золотые слова!.. Почему-то сразу вспоминается ленинская фраза про "кухаркиных детей"... дорвавшихся до управления государством... Доуправлялись...
С другой стороны, основная компетентность программистов - именно в приложениях; либо в "мусорных знаниях", как бороться с какой-нибудь сегодняшней проблемой собственно ИТ.
Вот... всё ближе к сантехникам... у них та же компетентность... да, и у хлебопёков... и у всех других спецов.... ибо любой спец раскрывается, именно прикладывая свои знания и навыки к чему-то... при этом борясь с сегодняшними проблемами собственной отрасли...
-
Но преимущественно ИТ-шники прославились тем, что создают эти проблемы себе сами.
Разумеется, есть сложные, имманентные проблемы этой деятельности. Но решение этих проблем является развитием, углублением физико-математической ветки мысли, скажем так.
Т.е. нормальный "физик", которому нужно браться за проблемы программирования стоит на стартовых позициях гораздо лучших, чем "не-физик". Ему нужно углубить и продолжить свои представления, чистому ИТ-шнику надо, для начала, познакомиться с какой-либо отраслью, которая связана с взаимодействием с реальным миром, а не виртуальными, уже такими же ИТ-шниками сгенерированными, сущностями...
-
И "чистых математиков" тоже долой, пусть "грязные бухгалтера" высшую математику развивают!.. "Чистых философов" - дустом посыпать... три раза в день, чтобы неповадно было... Пусть сантехники философию развивают... потому как, они по определению грязные, и снабжены житейской мудростью и практичностью. :)
Про дефекты чисто-математического мышления (например, "бурбакизма"), не "отформатированного" физикой, много сказано гениями от самой математики, например, В. А. Арнольдом. Классическое мат. образование предполагало значительный объём "физической подготовки". Постепенно математики стали "освобождаться" - и ни к чему хорошему сие дело, по мнению того же Арнольда, не привело.
-
Но преимущественно ИТ-шники прославились тем, что создают эти проблемы себе сами.
По моим наблюдениям то же самое можно сказать про любого другого инженера. Например про радиоэлектронщиков. Отличий от программирования весьма и весьма мало. И ошибок столько же. В общем, все нормально :-)
-
Кстати, ладно бы электронщики (это вроде как слегка родственно компьютерам) но механические инженеры (не знаю как по русски их назвать. конструктора? мechanical engineer) ступают ровно по тем же граблям. В нашем проекте мы сменили уже несколько этих самых инженеров, ибо лепят какую-то лажу (в нашем проекте механика не менее важна нежели алгоритмика или электроника, скорее даже более важна). Механический инженер сам по себе тоже абсолютно бесполезен. Чтобы он был полезен ему необходимо окунуться в предметную область задачи (также как и программисту), а они туда окунаться НЕ ХОТЯТ. Предпочитают жить в собственном виртуальном механико-инженерном мире.
PS. Замечу, что в отличае от механических инженеров, нам менять инженеров-программистов пока не приходилось.
PPS. Сори, наболело.
-
В университете к нам (физикам) приходил читать лекции по химии Химик с Химфака. Почти на каждой лекции он шутил над физиками, что мол среди физиков частенько встречаются сумасшедшие, а вот среди химиков ещё ни одного сумасшедшего не было.
Я это к чему... а может из химика ещё более крутой программист мог бы получиться если бы он им захотел с какого-то дуру стать? :) В химии ведь всё суровее чем у физиков, про всякую там тёмную энергию и прочую сферическую хрень погудеть не выйдет, там чуть что неправильно, так сразу взорвёшся или отравишься.
Соблюдайте технику безопасности!
http://konkretny-112.livejournal.com/458287.html
-
Но преимущественно ИТ-шники прославились тем, что создают эти проблемы себе сами.
Кто-то из мудрых сказал, что "все проблемы возникают от непонимания элементарных вещей"... безо всякого учёта специфики деятельности...
Т.е. нормальный "физик", которому нужно браться за проблемы программирования стоит на стартовых позициях гораздо лучших, чем "не-физик".
Угу... подсуньте ему план счетов из бух.учёта... пусть себе поразвлекается на стартовых позициях...
Ему нужно углубить и продолжить свои представления, чистому ИТ-шнику надо, для начала, познакомиться с какой-либо отраслью, которая связана с взаимодействием с реальным миром, а не виртуальными, уже такими же ИТ-шниками сгенерированными, сущностями...
Во! Поэтому умницы-математики поступают строго наоборот. Они говорят... мы ввели такое-то понятие и разработали для него алгебру, и теперь при рассмотрении любого реального явления, имеющие свойства нашего понятия, можно использовать данный алгебраический аппарат. Простенько и со вкусом! А физикам слабо... Они "сферических коней в вакууме" рассматривают... которые рушатся при соприкосновении с реальным миром... И хорошие программисты тяготеют к математикам, а плохонькие - к физикам... :) (IMHO... само собой)
-
В университете к нам (физикам) приходил читать лекции по химии Химик с Химфака. Почти на каждой лекции он шутил над физиками, что мол среди физиков частенько встречаются сумасшедшие, а вот среди химиков ещё ни одного сумасшедшего не было.
Я это к чему... а может из химика ещё более крутой программист мог бы получиться если бы он им захотел с какого-то дуру стать? :) В химии ведь всё суровее чем у физиков, про всякую там тёмную энергию и прочую сферическую хрень погудеть не выйдет, там чуть что неправильно, так сразу взорвёшся или отравишься.
Дык вот, Kemiisto у нас тут как раз химик :-) Химик-теоретик.
-
а вот среди химиков ещё ни одного сумасшедшего не было.
Потому как ежели ты изначально сумасшедший, то не успеешь стать известным химиком, а за долго до этого взорвёшься или отравишься :) :) :)
-
а вот среди химиков ещё ни одного сумасшедшего не было.
Потому как ежели ты изначально сумасшедший, то не успеешь стать известным химиком, а за долго до этого взорвёшься или отравишься :) :) :)
Естественный отбор в действии!
-
В университете к нам (физикам) приходил читать лекции по химии Химик с Химфака. Почти на каждой лекции он шутил над физиками, что мол среди физиков частенько встречаются сумасшедшие, а вот среди химиков ещё ни одного сумасшедшего не было.
Кстати, когда я учился нам (тоже таки теорфизикам) химик тоже регулярно говорил, что мол один фиг вы, физики, химию понять не можете, так что я, так и быть, не буду от вас особых достижений требовать :-)
Сложилась цепочка: математики не могут (или не хотят) понять физику, физики не могут или не хотят понимать химию. Чего же не могут (не хотят) понимать химики? :-)
-
Сложилась цепочка: математики не могут (или не хотят) понять физику, физики не могут или не хотят понимать химию. Чего же не могут (не хотят) понимать химики? :-)
Математику! :D Круг замкнулся! Мы все умрём! :o
-
По моим наблюдениям то же самое можно сказать про любого другого инженера. Например про радиоэлектронщиков. Отличий от программирования весьма и весьма мало. И ошибок столько же. В общем, все нормально :-)
В ИТ ни с чем не сравнимая свобода "креативить", гораздо большее время между тем, когда человек "нагромоздил" и когда он почувствовал все проблемы от этого...
И это количественное отличие ("больше свободы") переходит в качественное: не сопоставимую с другими областями способность плодить грабли (то, что Информатика-21 называет "раковая опухоль избыточной сложности"). И всё это начинает самоподдерживаться.
-
Во! Поэтому умницы-математики поступают строго наоборот. Они говорят... мы ввели такое-то понятие и разработали для него алгебру, и теперь при рассмотрении любого реального явления, имеющие свойства нашего понятия, можно использовать данный алгебраический аппарат. Простенько и со вкусом! А физикам слабо... Они "сферических коней в вакууме" рассматривают... которые рушатся при соприкосновении с реальным миром... И хорошие программисты тяготеют к математикам, а плохонькие - к физикам... :) (IMHO... само собой)
Почитайте Арнольда или Успенского, например.
Уж куда больше "сферических коней в вакууме", чем плодит "бурбакистская математика".
И программисты, тяготеющие к математике, тяготеют к Хаскелям и С++ :) Точно по тем же причинам, что вместо ясности и реализма им нужна возможность "утончённого абстрагирования".
-
По моим наблюдениям то же самое можно сказать про любого другого инженера. Например про радиоэлектронщиков. Отличий от программирования весьма и весьма мало. И ошибок столько же. В общем, все нормально :-)
В ИТ ни с чем не сравнимая свобода "креативить", гораздо большее время между тем, когда человек "нагромоздил" и когда он почувствовал все проблемы от этого...
И это количественное отличие ("больше свободы") переходит в качественное: не сопоставимую с другими областями способность плодить грабли (то, что Информатика-21 называет "раковая опухоль избыточной сложности"). И всё это начинает самоподдерживаться.
Эта свобода креативить, и вообще таймаут после которого разложенные самому себе грабли стукнут по лбу, зависит лишь от размера и сложности системы. Так уж получилось что програмные системы в среднем больше и сложнее чем "железные". В среднем - я имею ввиду те, которые вполне себе ширпотребные и клепаются массово на коленке. В радиоэлектронике или механической инженерии таковые массово клепаемые системы ОЧЕНЬ простые, как и задачи которые они решают. За счет некоторых особенностей програмной инженерии (отсутствие физического воплощения, в результате они на порядки более технологичны чем любая радиоэлектроника или механика) она позволяет создавать более сложные системы, решающие более сложные задачи за приемлемые ресурсы (время,люди). Чем собственно и пользуются.
В том же нашем проекте некоторые задачи так или иначе переносятся в софтвер. То есть задачи которые должна была решать механика и электроника переносится в програмную часть. Просто потому, что ПО само по себе более технологично, цена ошибки там всегда ниже и оные ошибки там встречаются реже (при той же сложности системы).
-
Так всё правильно, ну так это и налагает гораздо большие требования на культуру мышления программиста...
Противоречие, выделенное ещё Ершовым: профессия чуть самая массовая из "умственного труда", и в то же время - крайне "требовательная"...
-
Во! Поэтому умницы-математики поступают строго наоборот. Они говорят... мы ввели такое-то понятие и разработали для него алгебру, и теперь при рассмотрении любого реального явления, имеющие свойства нашего понятия, можно использовать данный алгебраический аппарат. Простенько и со вкусом! А физикам слабо... Они "сферических коней в вакууме" рассматривают... которые рушатся при соприкосновении с реальным миром... И хорошие программисты тяготеют к математикам, а плохонькие - к физикам... :) (IMHO... само собой)
Почитайте Арнольда или Успенского, например.
Не сработает... Арнольд тем и славен, что оппонирует "бурбаки", а, следовательно, пристрастен... не объективен. И если Вам ближе позиция Арнольда, то это никак не умаляет заслуг "бурбаки", в том числе, заслуг в области просвещения.
Уж куда больше "сферических коней в вакууме", чем плодит "бурбакистская математика".
По количеству "сферических коней" квантовую физику, например, никому не обойти не удастся, даже в отдалённой перспективе.
И программисты, тяготеющие к математике, тяготеют к Хаскелям и С++ :) Точно по тем же причинам, что вместо ясности и реализма им нужна возможность "утончённого абстрагирования".
Это всё досужие домыслы... не имеющие никаких аргументов... Всё как обычно... даже скучно.
-
По количеству "сферических коней" квантовую физику, например, никому не обойти не удастся, даже в отдалённой перспективе.
Интересно, а можно пример такого "коня" привести?
-
По количеству "сферических коней" квантовую физику, например, никому не обойти не удастся, даже в отдалённой перспективе.
Интересно, а можно пример такого "коня" привести?
Да, конечно... Попробуйте сформулировать, что представляют собой элементарные частицы... например, электрон...
-
;D.... Ну так что Vlad - где обсуждение конструктивно обсуждение "ЯП для физики высоких энергий"? ;D ;)
-
;D.... Ну так что Vlad - где обсуждение конструктивно обсуждение "ЯП для физики высоких энергий"? ;D ;)
Не парься :) Настоящий фидошник никогда не меняет сабжа :)
-
:) это точно.
-
По количеству "сферических коней" квантовую физику, например, никому не обойти не удастся, даже в отдалённой перспективе.
Интересно, а можно пример такого "коня" привести?
Да, конечно... Попробуйте сформулировать, что представляют собой элементарные частицы... например, электрон...
Ну да, наглядно представить себе электрон невозможно. Но это далеко не означает, что его квантовомеханическое описание - это "сферический конь". Такова уж его природа.
Впрочем, все это к теме не имеет никакого отношения.
-
Кстати, забавно chapel (http://chapel.cray.com/) использует синтакс заимствованный из C и Модулы. Там и модули и var с const есть. Хота главное там, конечно, параллельное программирование.
-
Ну да, наглядно представить себе электрон невозможно. Но это далеко не означает, что его квантовомеханическое описание - это "сферический конь".
Вообще-то, квантовомеханическая волновая функция (или вектор состояния, на который действуют вторично квантованные полевые операторнозначные функции) как раз и есть самый натуральный образцово-показательный сферический конь. :) :) :)
Не верите? Попробуйте сформулировать, что такое волновая функция...
-
Кстати, забавно chapel (http://chapel.cray.com/) использует синтакс заимствованный из 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», и не тот, кто «знает десять языков», а тот, кто обладает достаточными знанием и опытом в обоих разделах применительно к конкретной задаче. Имею наглость гарантировать, что можно запросто быть «аццки паршивым программистом», будучи полным гуру в одном отдельно взятом разделе. Если у человека хромает «алгоритмичекое мышление», он никогда не построит грамотное решение задачи, если хромают практические навыки — никогда не сможет это решение грамотно реализовать.
...
- т.е. что они у вас только в первом разделе механики?.. :)
Кстати, там ему дальше указывают, что называть всё отнесённое в теорию "алгоритмическим" не слишком верно... оно так...
Грабин, помнится, своих конструкторов-механиков окунал... направляя на производство... а также позволяя особо одарённым, но сферически мыслящим спроектировать, например, несобираемый узел... и посмотреть на результат реализации... ;)
-
Да, по поводу математических и физических коней:
«Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой.
Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».
- а обсуждение статьи быстро скатилось и на физику (http://blogerator.ru/page/oop_why-objects-have-failed#comment-161) (т.к. в самой статье ООП рядополагалось с ТО)... и на математику (http://blogerator.ru/page/oop_why-objects-have-failed#comment-638)... :) Интересны комменты, где это даже связывалось... вроде этого (http://blogerator.ru/page/oop_why-objects-have-failed#comment-816)...
-
Ну и чтоб уж совсем сабжа не менять:
Про Фортран: мой близкий друг, физик, очень много работает на Фортране (как, по его рассказам, и все его коллеги — тысячи их), на Фортране, а не в маткадах, потому что задачи объёмные, обсчитываются на больших машинах, а Фортран предоставляет и хорошее быстродействие и нужные возможности параллелизации их алгоритмов. И переписывать это на что либо другое никто не собирается — это просто ненужно.
- не знаю уж, где именно это имеет место...
-
Да, по поводу математических и физических коней:«Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой.
Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».
- а обсуждение статьи быстро скатилось и на физику (http://blogerator.ru/page/oop_why-objects-have-failed#comment-161) (т.к. в самой статье ООП рядополагалось с ТО)... и на математику (http://blogerator.ru/page/oop_why-objects-have-failed#comment-638)... :) Интересны комменты, где это даже связывалось... вроде этого (http://blogerator.ru/page/oop_why-objects-have-failed#comment-816)...
Это спор о вкусовых предпочтениях... В сути того же ООП никто разбираться не хочет, и спор превращается в обмен "колкостями".
-
а обсуждение статьи быстро скатилось и на физику (http://blogerator.ru/page/oop_why-objects-have-failed#comment-161) (т.к. в самой статье ООП рядополагалось с ТО)... и на математику (http://blogerator.ru/page/oop_why-objects-have-failed#comment-638)... :) Интересны комменты, где это даже связывалось... вроде этого (http://blogerator.ru/page/oop_why-objects-have-failed#comment-816)...
Никого же не удивляет, что в машиностроении, например, есть инженеры-конструкторы, которые придумывают новое изделие, отвечая на вопрос: "Что нужно делать?"; и есть инженеры-технологи, придумывающие новые методы изготовления, отвечая на вопрос: "Как нужно делать?". Наконец, есть исполнители, которые, выполняя инструкции технологов, делают то, что придумали конструкторы.
В программировании инженерные подходы плохо приживаются... исполнитель здесь является и конструктором, и технологом... ООП ему, "как собаке пятая нога".
-
Да, по мере чтения комментов возникало такое ощущение... и не в первый раз (имея в виду как осмысление опыта того же Грабина, так и Ваше замечание, что не следует путать ООА и ООП)... :)
-
А никто и не призывает же переписывать старый, проверенный веками софт с фортрана на новый язык.
От нового языка требуется лишь что бы он был удобнее фортрана (на который физики плюются долгие годы), проще с++ (который эти физики так и не осилили за эти же долгие годы), и при этомне терял возможности вызова всех эти фортрановских подпрограмм...
Угу... и этот новый язык должен будет поддерживать несколько точек входа в подпрограмму... в том числе.
...
Ага... техноязык в силуэте поддерживает... и это, как стало понятно отсюда (http://drakon.su/leh-redaktor), видимо, потому, что изначально был граф-нотацией для управляющих структур Фортрана-С3Х... вот только реально исполняются не размеченные графы, а код, транслированный из Фортран-текста... :)
Кстати, Ада, если я правильно понял Кауфмана здесь (в первой выдержке) (http://forum.oberoncore.ru/viewtopic.php?p=71991#p71991), поддерживает множественность точек входа (при асинхронном рандеву)... так?..