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

[valexey]

Стив Лайонел (Steve Lionel) развивает ФорТран... о чём можно почитать в интервью с ним... Надо ли это делать?.. Ему виднее...

из комментариев понравилось:

Peter Tarakanov:
"Мы действуем именно таким образом. Студентам читается общий курс программирования с C, Фортраном и основами C++, а затем им подсовываются более-менее приличные вычислительные задачи. В первый же месяц-два выясняется, что те, кто пишет на Фортране, справляются с заданиями быстрее и получают в итоге намного более эффективный код, чем любители C, а те некоторые, кто использует для тех же целей Java, C# или еще что-нибудь "новое и модное", просто сдыхают от объема работы. Уже к концу первого семестра желание писать вычислительные задачи на C/C++/C#/Java/Python и т.д. вместо Фортрана пропадает начисто у всех без исключения."

И это очень правильный подход. Намного лучше насильственного навязывания фортрана как единственно верного языка для этого класса задач (с попутным чмырением c/c++/c#/python на лекциях).

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

Да в том ведь и дело, что такие физики занимаются несвязанными с физикой делами. Нечего физикам лезть в дебри искусства программирования. Им нужны готовые или полуготовые инструменты, будь то Фортран или редактор символьных формул.

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

[vlad]

(причём здесь работа со списками?.. оставьте это преподавателям очень средней школы...)

Работа со списками - это просто проверка на вшивость Если оно выглядит громоздко (для не встроенных списков), то ожидать построения четких моделей данных не приходится.

[Geniepro]

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

Вот хотелось бы более-менее полную статистику на эту тему.
А то ведь можно ещё и адмирала Грейс Хоппер, компиляторщицу по совместительству, вспомнить...

[Geniepro]

И вообще сама эта характеристика "самый сильный и адекватный программист" -- тоже непонятно как её определять.
Вон Сергей Зефиров -- самый сильный программист на Хаскелле в мире, он такие штанги поднимает, что нам и не снилось, и вполне адекватен, я думаю...   

[Romiras]

Да в том ведь и дело, что такие физики занимаются несвязанными с физикой делами. Нечего физикам лезть в дебри искусства программирования. Им нужны готовые или полуготовые инструменты, будь то Фортран или редактор символьных формул.

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

Банально, у специалистов этих категорий разная квалификация. И нечего их смешивать. Чтобы каждый занимался своим делом.
Читал про одного врача-анестезиолога по имени Кон Коливас, который занимался написанием патчей по улучшению производительности ядра Линукса, но в итоге из этого ничего хорошего не вышло. 

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

Чтобы среднестатистические ИТ-шники разводили всякую хрень, просто по недопониманию принципов научного и инженерного творчества?

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

[Romiras]

Чтобы среднестатистические ИТ-шники разводили всякую хрень, просто по недопониманию принципов научного и инженерного творчества?

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

Для этого ИТ-шников нужно учить. Дополнительный кругозор всегда идёт на пользу, но не стоит смешивать эти области. Но нужны более чёткие определения предметной области, чтобы программист чётко выполнял свои задания. Плохо, когда программисту нужно быть физиком. И наоборот тоже. Оба напортачат, что потом мозги сломаешь чтобы что-то понять/изменить в коде.

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

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

С учётом того, что программирование нужно везде, есть ли смысл в армии "чистых программистов"?
Любому предметнику будет только польза от владения программированием. С другой стороны, основная компетентность программистов - именно в приложениях; либо в "мусорных знаниях", как бороться с какой-нибудь сегодняшней проблемой собственно ИТ.

[Romiras]

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

С учётом того, что программирование нужно везде, есть ли смысл в армии "чистых программистов"?
Любому предметнику будет только польза от владения программированием. С другой стороны, основная компетентность программистов - именно в приложениях; либо в "мусорных знаниях", как бороться с какой-нибудь сегодняшней проблемой собственно ИТ.

Это отражает нынешнее положение в ВУЗах и на рынке труда.
Задача программиста в идеале состоит в том, чтобы уметь строить ПО в соответствие с требованиями предметной области. На самом деле ему приходится быть бухгалтером, дизайнером, физиком и врачом. Что получаем в итоге? Из-за того, что смешиваются инженерия построения ПО и предметные области, получаем ПО с высокой стоимостью поддержки по причине нехватки знаний в данной области. Предметная область настолько глубоко "закодирована" в ПО, что даже те, кто написал его, с трудом разбираются в нём. А ведь у ПО есть срок поддержки и после его устаревания следует заново воссоздавать знания предметной области по крупицам из того дикого кода.

Введён инструментарий указателей и функции для работы с оперативной памятью (по аналогии с языком С)

Похоже, путь развития Фортрана пошёл по неверному пути, начиная с версии Fortran 90. Собственно, из-за этого у физиков проблемы с Фортраном и начались.

[kemiisto]

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

А не наоборот? Физикам и прочим приходится быть программистами?

Похоже, путь развития Фортрана пошёл по неверному пути, начиная с версии 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 с сишечкой - суровая реальность. Зато можно биндится к сишным либам без геморроя.

[Valery Solovey]

Задача программиста в идеале состоит в том, чтобы уметь строить ПО в соответствие с требованиями предметной области.

Сомневаюсь, что у предметной области есть требования.
И как же программист будет реализовывать требования, если он ни бум-бум в предметной области и термины из требований понимает "интуитивно"?

На самом деле ему приходится быть бухгалтером, дизайнером, физиком и врачом. Что получаем в итоге? Из-за того, что смешиваются инженерия построения ПО и предметные области, получаем ПО с

Мы получаем в итоге то, что есть сейчас. То есть, сейчас IT-компании преимущественно работают и учат работать так, как Вы описали.
Но на самом деле, программирование здесь сродни письменности. Никто не учит писать только ради того, чтобы уметь писать. С другой стороны, тяжело стать инженером не имея этого навыка (письма). Так что программист должен быть помимо программиста ещё кем-то из "бухгалтером, дизайнером, физиком и врачом", чтобы хотя бы понимать, что от него требуется. Без необходимости получать описания всех подводных камней (потому что специалисту в своей области банально не придёт в голову сделать что-то, о чём чистый it-шник может подумать в силу неосведомлённости).

[valexey]

Да в том ведь и дело, что такие физики занимаются несвязанными с физикой делами. Нечего физикам лезть в дебри искусства программирования. Им нужны готовые или полуготовые инструменты, будь то Фортран или редактор символьных формул.

Уже не раз обсуждалось (с примерами - как Дейкстра; ну или из личных наблюдений...), что самые сильные и адекватные программисты получаются из физиков или инженеров.

Статистику в студию, иначе это высказывание имеет ценность ОБС (одна бабка сказала). Причем статистика по адекватным программистам не старше скажем 45 лет (наука новая, понятно что тем кому старше никак не могли изучаться непосредственно по CS-специальности, просто потому что CS их моложе).

PS. И да, следует различать IT и CS. Первое - это уровень сисадмина.

[Romiras]

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

А не наоборот? Физикам и прочим приходится быть программистами?

Похоже, путь развития Фортрана пошёл по неверному пути, начиная с версии Fortran 90. Собственно, из-за этого у физиков проблемы с Фортраном и начались.

Опять с ног на голову. Проблемы закончились. Сейчас как раз начался ренесанс Фортрана. На современном Фортране можно писать почти 1-в-1 как на столь ненаглядном Обероне.  Можно даже ключевые слова капсом, кому нужно.

Конечно, 1-в-1 писать зачастую бессмысленно, так как, например, отказываться от развитых средст работы с массивами - себе дороже. А interoperability с сишечкой - суровая реальность. Зато можно биндится к сишным либам без геморроя.

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

Задача программиста в идеале состоит в том, чтобы уметь строить ПО в соответствие с требованиями предметной области.

Сомневаюсь, что у предметной области есть требования.
И как же программист будет реализовывать требования, если он ни бум-бум в предметной области и термины из требований понимает "интуитивно"?

На самом деле ему приходится быть бухгалтером, дизайнером, физиком и врачом. Что получаем в итоге? Из-за того, что смешиваются инженерия построения ПО и предметные области, получаем ПО с

Мы получаем в итоге то, что есть сейчас. То есть, сейчас IT-компании преимущественно работают и учат работать так, как Вы описали.
Но на самом деле, программирование здесь сродни письменности. Никто не учит писать только ради того, чтобы уметь писать. С другой стороны, тяжело стать инженером не имея этого навыка (письма). Так что программист должен быть помимо программиста ещё кем-то из "бухгалтером, дизайнером, физиком и врачом", чтобы хотя бы понимать, что от него требуется. Без необходимости получать описания всех подводных камней (потому что специалисту в своей области банально не придёт в голову сделать что-то, о чём чистый it-шник может подумать в силу неосведомлённости).

Я же не говорю, что нужно разделить ИТ-шников и предметников железобетонной стеной. Инженер ПО вплотную работает с предметником, составляя спецификацию при помощи формализации деятельности, по которой затем поручает работу программистам.

Разумеется, программист должен разбираться в предмете, и без этого никак. При этом программист выполняет свою работу, не влезая в деятельность физики или другого предмета. А физик, в свою очередь, не будет заниматься чуждой ему деятельностью отладки программных компонентов.

[Geniepro]

Читал про одного врача-анестезиолога по имени Кон Коливас, который занимался написанием патчей по улучшению производительности ядра Линукса, но в итоге из этого ничего хорошего не вышло. 

Его патчи были вполне нормальными, но ему надоело ими заниматься, плюс ещё эта линуксовая бюрократия... Его патчи были ориентированы на улучшение ядра для десктопа, тогда как главное и основное для linoops'а -- это серверы, где его патчи были бесполезными...