Фортран

с.т.> а как ты на "кредитных конвеерах" нормальное тестирование сделаешь когда у тебя на всех средах кроме ПРОМа - голимая синтетика на входных данных.

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

16-й> Кабы еще знать, что ты имеешь ввиду под "промышленной". Это там, где прокатный стан прямо к компу подключен проводками? Нет, этим не занимаюсь. Или там, где у банка кредитный конвейер обчищает страждущих? Этим, например, вполне.

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

с.т.>> а как ты на "кредитных конвеерах" нормальное тестирование сделаешь когда у тебя на всех средах кроме ПРОМа - голимая синтетика на входных данных.
16-й> Так о то ж. И со всех сторон затычки сопряженных сервисов понатыканы, эмулирующие типовой ответ. В лучшем случае смежники, ответственные за сервис, что-то селективно могут подсунуть, в зависимости от твоей нижайшей просьбы.

Так это ж вы тут и не про юнит-тесты. А юнит тесты этож на уровне класса/модуля/файла и т.п. У него данные всегда синтетика. Соответственно и нужны где хоть какая логика не тривиальная, или математика и т.п. Вот от таких ошибок очень помогает:
> когда в программе расчёта траектории американского венерианского аппарата в строке программы вместо
> DO 10 I=1,10
> оказалось набито
> DO 10 I=1.10

G.s.> Оказывается, мой первый освоенный язык программирования ещё жив и даже развивается.

А чего удивительного. Многие суперкомпьютерные расчеты под ним как жили так и живут. Он поддерживает MPI и OpenMP. Знаю немало людей которые именно на нем кодят.

G.s.>>> Если есть ещё тут люди, которые помнят слово "программирование", а не используют новояз "кодирование", хотелось бы пообщаться.
Zenitchik>> А от кого в отрасли ты слышал этот новояз?
G.s.> Я же не в безвоздушном пространстве живу.
G.s.> Как исчезло слово "мультипликация" и вылезла "анимация"?
G.s.> Так и читая всякие дзены и прочее, вижу терминологические изменения.
Непонимание нюансов вижу я.

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

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

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


...
Это не мутация термина, а более точный термин просто. Просто "программирование" перестало описывать то, чем занимается человек достаточно точно.

G.s.> Критический баг, это когда в программе расчёта траектории американского венерианского аппарата в строке программы вместо
G.s.> DO 10 I=1,10
G.s.> оказалось набито
G.s.> DO 10 I=1.10

Точка стандартный десятичной разделитель.
Так что, скорее всего DO 10 I=1.10 правильная строка

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

Собссно, именно поэтому современное программирование во многом гуманитарная деятельность. Чего многие технари попробовавшие что-то там простенькое закодить или даже сложненькое посчитать, понять и принять пока не могут.

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

cholev> Так что, скорее всего DO 10 I=1.10 правильная строка
Она была распознана как "DO10I = 1.10" , т.е. как оператор присваивания.

Пофиксил:
Татарин> Задача "заставить машину что-то там делать" решается много проще, чем задача создания НЕНУЖНОГО продукта, который может жить и развиваться какое-то достаточное время.

Татарин>> Задача "заставить машину что-то там делать" решается много проще, чем задача создания НЕНУЖНОГО продукта, который может жить и развиваться какое-то достаточное время.
Любого.

Gudleifr> Полезное программирование кончается там, где у инженера (в т.ч. системотехника или математика) начинаются проблемы с переносом на компьютер своей повседневной рутины.
Ну, как обычно: всё, что не влазит в голову, трудоёмко или просто объёмно объявляется бесполезным.

Сколько я таких певцов "бессмысленной современной физики" или "бессмысленного скриптописания", сколько адептов теорий "простого понятного классического эфира" или "программирования на ассемблере" (или в тяжёлых случаях даже на фортране или пасале) уже перевидал.

Конечно, полезный расчёт можно написать даже на васике или фортране. Часто его и НУЖНО писать на чём-то таком, примитивном, простеньком. Но это не значит, что оными задачами мир и ограничивается. Просто по сути задачи программирования, требующиеся инженерам или прикладникам, как правило, просты.

Не всегда (ресолверы всяких 3д-задач, кое-какой обсчёт квантовой химии или некоторые задачи биоинформатики могут быть сложными), но как правило они просты. Сложность там в инженерии, физике или там биологии, сложности для программиста в таких вещах никакой нет. Если мозг специалиста достаточно деформирован, он может заявить, что, мол, раз типичный кодер с улицы не может написать такое (читать как "не понимает конкретной области деятельности"), то и задача эта оченно для программиста сложная. Но это не так.

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

Но человеку, который видел только дико примитивные (в смысл программирования) задачи типа квантовых расчётов или моделирования атмосферы, это объяснить невозможно. Он же "та-акие сложные вещи сам писал!"

16-й> Щас любимое занятие - полное покрытие юнит тестами. Причем всех слоев сразу.Zenitchik> Это реально необходимо. Счастливы в своём неведенье те, кто ни разу не нарывался на критический баг, пропущенный в релиз из-за недостаточного тестирования...

Именно unit test для всего это или очень маленький проект или плевать на сроки и бюджет. И еще надо доказать что тесты покрывают все возможные состояния. Поэтому юнитами обычно покрывают критичные места, а остальное интеграционными.

cholev> Точка стандартный десятичной разделитель.
cholev> Так что, скорее всего DO 10 I=1.10 правильная строка

С точки зрения компилятора тех времен - да. Но программист то хотел цикл от 1 до 10

cholev> ЕМНИП да. Кстати на советские клоны 8080 198х начало девяностых точно так. Запустил ПК, Бейсик загрузился от ЭПРОМ-а.
cholev> А вот с правец-8 шло встроенное дискетное устройство на 5.25"

Логично, если нет накопителей то зачем шелл вообще. Я на персоналках начал с тех что работали под CP-M и все домашние компы прошли как-то мимо меня.

tarasv> Именно unit test для всего это или очень маленький проект или плевать на сроки и бюджет. И еще надо доказать что тесты покрывают все возможные состояния. Поэтому юнитами обычно покрывают критичные места, а остальное интеграционными.
Угу. Или юнит-тестами покрывают какие-то критичные, знаковые сценарии для часто меняемого (и много где переиспользуемого) кода: ручное тестирование таких вещей слишком трудозатратно а енд-ту-енд вообще иногда невозможно. Такое бывает.

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

Татарин> А ещё юнит-тесты очень любят аутсорс-конторы, которым в критерии оценки ставят количество сданных строк кода в продукте.

а ещё процент покрытия кода юнит-тестами под 90% любят заказчики которым в критерии приёмки у подрядчика нужно какие-то критерии качества прописать

G.s.> Если есть ещё тут люди, которые помнят слово "программирование", а не используют новояз "кодирование", хотелось бы пообщаться.
Во времена фортрана это скорее было "создание математического обеспечения"
Если мы про 70-е и ранее

Panda-9>> Сейчас, так сложилось, пытаюсь освоить Python. Какой-то он расхлябанный в сравнении с Фортраном, будто какой-то диалект разговороного английского.
G.s.> Много слышу про Python, рекламируют, но что-то не вдохновляет.
А зря - очень неплохой язык

G.s.> А, блин, интегрирование по Рунге-Кутту или интегралы какие-нибудь эллиптические???
А это кому нужно?

Вон мне потребовалось погонять систему линейных дифференциальных уравнений - а именно эпидемиологическую модель SEIRD
Я изначально поглядывал в сторону чего-то типа MATLAB или MATCAD - ну открытый аналог

... а потом просто взял Python - там есть библиотеки для решения диффуров - и все.

Думаю, для C/C++ их тоже не составит труда найти если надо - тот же LAPACK давно для них есть

Gudleifr> Это компенсируется тем, что "без интерфейса" практически уже никто не может (Раскин над тем и смеется, что никому это и в голову не пришло).
Фортран это числодробилка
Зачем интерфейс ?
Кто мешает файлы с параметрами использовать ?
А потом посмотреть в том же GNU Plot

yacc> Фортран это числодробилка
yacc> Зачем интерфейс ?
Даже у нас была функция, которая рисовала графики. Вызывалась в программе на фортране. Так что какой-то графический интерфейс полезен.

G.s.>> ...
Gudleifr> Каюсь, упоминание BASIC было ошибкой. Теперь, все будут вспоминать не БЭСМ-6, а Спектрум...
Для задач вычисления интерпретатор бейсика хреново работал

Мне помниться надо было срочно рассчитать коэффициенты для нерекурсивного цифрового фильтра - ну там синусы косинусы - вечером, когда уже в дисплейный класс не пойти
Сделал на Спектруме
Там где я на Си рассчитывал за минуту фильтры 100 порядка, тут он тормозил... на 10-20 порядке - десятки минут
При сходной с XT тактовой частотой.
Потому что интерпретатор

Скомпилированная на ДВК-2 программа на Фортране также работала быстро.
Ну правда без винчестера приходилось несколько возиться:
два дисковвода, на одном система, редактор и программа, на втором - либо фортран компилятор, либо компоновщик объектных модулей ( линкер ) с библиотекой
чтобы скомпилировать программу приходилось менять второй диск - сначала OBJ создавать, потом со второго диска получать исполняемый SAV
Но работало потом быстро

yacc>> Фортран это числодробилка
yacc>> Зачем интерфейс ?
Серокой> Даже у нас была функция, которая рисовала графики. Вызывалась в программе на фортране. Так что какой-то графический интерфейс полезен.
На XТ я не парился - получал выходной файл dat и потом скармливал его в grapher
им же можно было и распечатать

Вот его меню

yacc> Фортран это числодробилка
yacc> Зачем интерфейс ?
См. цитату из Раскина в начале темы. Большинство "современных программистов" начинают думать над уравнением с рисования экранной формы. Тупо возьмите любой из этюдов Уэзерелла и поймайте себя мысли: как Вы видите его решение? Что Вы рисуете в уме?

Татарин> Непонимание нюансов вижу я.
Татарин> Вполне понятное для человека, который занимается вычислениями для каких-то своих задач, а не варится в общем котле софтварного произвдства.
Да, это так и есть.
Я делаю ПЕРЕвод ФОРМул именно для себя, т.е. для задач, которые ставлю себе сам.
И никогда не работал в коллективе, создающем готовое ПО, тем более товарное на сторону.
Однако остается фундаментальный вопрос: чем "код" отличается от "программы"?

Gudleifr> См. цитату из Раскина в начале темы. Большинство "современных программистов" начинают думать над уравнением с рисования экранной формы.
Там пример с VB - вообще не показатель ( он, кстати, еще не умер ? )

Скажем на Линуксе гораздо проще сделать консольное приложение.

Помнится был даже такой анекдот:
"
1) я тут программу пишу
2) а какой у нее будет интерфейс ?
1) как у Юникса
2) а... то есть НИКАКОГО
"

Если там речь про VB - это лет 10-20 назад писалось ?
А то сейчас есть фронтэнд и бэкэнд.
Вот в бэкенде вообще как такового интерфейса нет - пусть энтим UX/UI фронтэндеры занимаются на своем JS, ТS или чем еще