Фортран

Gudleifr> Это компенсируется тем, что "без интерфейса" практически уже никто не может (Раскин над тем и смеется, что никому это и в голову не пришло).

Кстати, по поводу программирования без интерфейса: А рождественский ёлочный конкурс все фортранисты пропустили? Почему?


Фортранисты не умеют писать эффективные программы без интерфейса?



Питон, кстати, там отметился.

Gudleifr> Это компенсируется тем, что "без интерфейса" практически уже никто не может (Раскин над тем и смеется, что никому это и в голову не пришло).

Но в итоге смеются над его дешевыми драматическими приемами. Программное обеспечение Apple II было настолько примитивно что для сложения двух чисел приходилось писать программу. Надо же. А я делаю это нажатием пяти клавиш.

tarasv> Но в итоге смеются над его дешевыми драматическими приемами. Программное обеспечение Apple II было настолько примитивно что для сложения двух чисел приходилось писать программу. Надо же. А я делаю это нажатием пяти клавиш.

Apple II (болгарская версия Правец 8) работал под встроенным Бейсиком.

Для сложения двух чисел надо написать:
? 4 + 5

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

Gudleifr> Любимое занятие IT-шников - переписывание старых программ по новым правилам "совместимости" и "безопасности".

Это в прошлом.
Щас любимое занятие - полное покрытие юнит тестами. Причем всех слоев сразу.

cholev> Apple II (болгарская версия Правец 8) работал под встроенным Бейсиком.
cholev> Для сложения двух чисел надо написать:
cholev> ? 4 + 5

Я не сталкивался, автор пишет что надо нажать сочетание клавиш чтобы запустить бейсик. Там вообще командного шелла не было и сразу бейсик грузился?

cholev>> Apple II (болгарская версия Правец 8) работал под встроенным Бейсиком.
cholev>> Для сложения двух чисел надо написать:
cholev>> ? 4 + 5
tarasv> Я не сталкивался, автор пишет что надо нажать сочетание клавиш чтобы запустить бейсик. Там вообще командного шелла не было и сразу бейсик грузился?

я тож с эпл2 не сталкивался, но предположу что наверно как в Спектруме, где шелл и бейсик были вместе. однако начинал я на бейсике УКНЦ, спектрум был позже.

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

Но, по крайней мере, Вы поняли, что из трех независимых(!) составляющих:
1) решение задачи;
2) его программирование;
3) запуск программы под конкретную ОС;
трудности третьей, как и в 70-х, вызывают наибольшие проблемы?

cholev>> Apple II (болгарская версия Правец 8) работал под встроенным Бейсиком.
cholev>> Для сложения двух чисел надо написать:
cholev>> ? 4 + 5
tarasv> Я не сталкивался, автор пишет что надо нажать сочетание клавиш чтобы запустить бейсик. Там вообще командного шелла не было и сразу бейсик грузился?

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

Gudleifr> Пардон, где-то тут я, вроде, уже эти "мнения программистов" уже приводил:

Мне, как программисту, эти "мнения" кажутся несколько дикими. Хотя, не спорю: со снижением порога вхождения в программирование, развелось много ОЧЕНЬ странных программистов.

Zenitchik> Хотя, не спорю: со снижением порога вхождения в программирование, развелось много ОЧЕНЬ странных программистов.
Наоборот, порог повышается. Для того, чтобы называться "программистом" нужно знать очень много ерунды, не относящейся к программированию. Полезное программирование кончается там, где у инженера (в т.ч. системотехника или математика) начинаются проблемы с переносом на компьютер своей повседневной рутины.

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

По этому пункту Вы правы.

Gudleifr> Для того, чтобы называться "программистом" нужно знать очень много ерунды, не относящейся к программированию.

А по этому - нет.

16-й> Это в прошлом.
16-й> Щас любимое занятие - полное покрытие юнит тестами. Причем всех слоев сразу.

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

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

Bredonosec> В универе на нем какую-то примитивщину лепили.. Причем, сразу в машинных кодах. И руками вбивали программу посимвольно в память какой-то железяки-аналога 8086
Я завёл ветку, чтобы поговорить о языках программирования высокого уровня, типа Фортран.
А не об ассемблере или ещё о чём.

Zenitchik> ...
No. He will not be trained... He is too old. There is already too much anger in him. ©

Zenitchik> Причём матаппарат программы нужно тестировать особенно тщательно (если только мы не пользуемся готовыми библиотеками, которые хорошо отлажены до нас).
И если у нас есть подробное и адекватное их описание.

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

Вот при всей моей тяге к перфекционизму, не могу разделить мнение без оговорки.
Если покрытие тестами будет делать команда из (эдак, минимально) шести непритязательных ваятелей (архитектор, тим лид, по одной персоне на каждый слой и тестер), то на средне-малой системке они будут развлекаться (эдак, оптимистично) полгода. Итого: 6 чел * 6 мес * 150'000 руб = 5'400'000 руб. Ну, а с налогами будет все 8 млн. Заодно вся команда будет выключена из созидательной деятельности (это в наше-то тяжелое время, когда всякий жуниор со студенческим "опытом" мнит себя мессией).
Критический баг, если он не связан с широкой серией, взрывами, жертвами и необратимыми транзакциями, будет стоить вздрючки руководителю отдела, недели работы местных девочек с экселем и расшаркиваний контингента первой линии поддержки. Т.е. копейки. Что я и вижу регулярно на практике в лучших, не побоюсь этого слова, отечественных бизнес-домах.
Соответственно, "критичный баг" критичному багу рознь. Чаще, это жопоприкрывающая инициатива департамента ЗИ, а не что-то реально насущное.

Gudleifr> Но, по крайней мере, Вы поняли, что из трех независимых(!) составляющих:
Gudleifr> 1) решение задачи;
Gudleifr> 2) его программирование;
Gudleifr> 3) запуск программы под конкретную ОС;
Gudleifr> трудности третьей, как и в 70-х, вызывают наибольшие проблемы?
Как-то в течение 2-3 лет я параллельно программировал на фортране на БЭСМ-6 с ОС Дубна и на ЕС-1033, ОС не помню. Фундаментальный том Джермейн до сих пор на полке стоит.
Затруднения, даже не проблемы, были только с системными командами, которые надо было набить в управляющих перфокартах.
С синтаксисом проблем не было.
А в этой бесплатной оболочке оказался какой-то диалект фортрана, вот и всё.

16-й>>> Щас любимое занятие - полное покрытие юнит тестами. Причем всех слоев сразу.
Zenitchik>> Это реально необходимо. Счастливы в своём неведенье те, кто ни разу не нарывался на критический баг, пропущенный в релиз из-за недостаточного тестирования...
16-й> Вот при всей моей тяге к перфекционизму, не могу разделить мнение без оговорки.
16-й> Если покрытие тестами будет делать команда из (эдак, минимально) шести непритязательных ваятелей (архитектор, тим лид, по одной персоне на каждый слой и тестер), то на средне-малой системке они будут развлекаться (эдак, оптимистично) полгода. Итого: 6 чел * 6 мес * 150'000 руб = 5'400'000 руб. Ну, а с налогами будет все 8 млн. Заодно вся команда будет выключена из созидательной деятельности (это в наше-то тяжелое время, когда всякий жуниор со студенческим "опытом" мнит себя мессией).
16-й> Критический баг, если он не связан с широкой серией, взрывами, жертвами и необратимыми транзакциями, будет стоить вздрючки руководителю отдела, недели работы местных девочек с экселем и расшаркиваний контингента первой линии поддержки. Т.е. копейки. Что я и вижу регулярно на практике в лучших, не побоюсь этого слова, отечественных бизнес-домах.
16-й> Соответственно, "критичный баг" критичному багу рознь. Чаще, это жопоприкрывающая инициатива департамента ЗИ, а не что-то реально насущное.

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

G.s.> А в этой бесплатной оболочке оказался какой-то диалект фортрана, вот и всё.

Я конечно слишком молодой динозавр для фортрана, но всё же попробуйте GNU Fortran. GNU Fortran - GNU Project Работает без всяких оболочек, только хардкор.
The GFortran compiler is fully compliant with the Fortran 95 Standard and includes legacy F77 support. In addition, a significant number of Fortran 2003 and Fortran 2008 features are implemented.

Zenitchik> Счастливы в своём неведенье те, кто ни разу не нарывался на критический баг, пропущенный в релиз из-за недостаточного тестирования...
Критический баг, это когда в программе расчёта траектории американского венерианского аппарата в строке программы вместо
DO 10 I=1,10
оказалось набито
DO 10 I=1.10
Эта легенда почему-то крепко мне запомнилась с 1 курса.
В Алголе такое бы не прошло, т.к. все переменные должны быть объявлены явно.

G.s.> Затруднения, даже не проблемы, были только...
Потому, что Вашу работу хорошо сопровождали. Начиная от того, кто присоветовал литературу, до набивки перфокарт... Прикиньте, сколько человек на Вас работало.
А сейчас число этих посредников выросло на порядок, и платить Вы им должны самостоятельно. Конечно, хорошо бы сесть кому-то на хвост, но пока знатоки "современного FORTRAN" не засветились. (Разве что поспрошать на сайте Каким должен быть язык программирования?. Там, по крайней мере, еще есть инженеры, "всю дорогу" пишущие на PL/1. Может у них есть выход и на фортрановцев).

a.p.> ... хочу сказать что если тестированием не заниматься как следует, в т.ч. с покрытием юнит тестами там где надо (раз уж они вам так запали в душу), то система скорее всего не заработает никогда.

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

a.p.> Впрочем видимо вы промышленной разработкой софта не занимаетесь.

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

16-й> Вот при всей моей тяге к перфекционизму, не могу разделить мнение без оговорки.

совершенно согласен. идеальное тестирование требует бесконечного времени\ресурсов.

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

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