COBOL v5 – A ‘Brave’ New World

[Komissar]

Работа современных программистов это грамотно скрутить готовые куски кода, а не писать что-то свое.

А как же job security?!!

[OtherSide]

Дело не в велосипедах совсем, дело в желании быстренько стряпать что-то "на коленке", тот самый "коленочный подход"...
От него все беды с несконечными updates и исправлениями.
Фундаментальности около нуля, зато желание что-то по быстрому "рубануть" и "сплавить" хоть отбавляй...

Вы так говорите, как будто в желании по быстрому рубануть и сплавить есть что-то плохое.
На самом деле сложность ПО за последние 20-30 лет выросла на порядки.
Если Билла Гейтса сделал миллионером бейсик, созданный за полтора месяца, то сейчас месяц будут только вебморду на бумаге рисовать. Потратят несколько миллионов, что бы потом пользователь еще носом крутил, что дескать че за дела, в бесплатный софт рекламу вставили, он такое пользовать не согласен

[ARARAT.]

Дело не в велосипедах совсем, дело в желании быстренько стряпать что-то "на коленке", тот самый "коленочный подход"...
От него все беды с несконечными updates и исправлениями.
Фундаментальности около нуля, зато желание что-то по быстрому "рубануть" и "сплавить" хоть отбавляй...

Вы так говорите, как будто в желании по быстрому рубануть и сплавить есть что-то плохое.
На самом деле сложность ПО за последние 20-30 лет выросла на порядки.
Если Билла Гейтса сделал миллионером бейсик, созданный за полтора месяца, то сейчас месяц будут только вебморду на бумаге рисовать. Потратят несколько миллионов, что бы потом пользователь еще носом крутил, что дескать че за дела, в бесплатный софт рекламу вставили, он такое пользовать
не согласен

Не сложность выросла, а ее "выросли" вот такими подходами к программированию...
Стабильность ужастная, постоянные updates и исправления, стоимость огромная просто в long run, поетому и стоимость прoдукта огромна.
Вроде поначалу стоимость "изготовления" небольшая, а что наняли таких кодописателей, они натаскали куски быстренько что то стряпали, там подкрутили, здесь подтянули, вроде как-то заработало, после первого удачного прогона пустили, а потом всю жизнь сидят на его поддержании. И все ето входит в стоимость продукта в конечном итоге и в головные боли пользователей и их затраты кстати...
А так нечего конечно...

PS Кстати, и при етом ети кодописатели требуют зарплат "врачей" почему то...? Одни учатся десятилетиями и ответственность огромная, а у других "два класс образования младшей школы"(еквивалент научиться код писать) и чужие куски кода "под рукой" с нулем ответственности...

[OtherSide]

1 Не сложность выросла, а ее "выросли" вот такими подходами к программированию...

2 Стабильность ужастная, постоянные updates и исправления, стоимость огромная просто в long run, поетому и стоимость прoдукта огромна.
Вроде поначалу стоимость "изготовления" небольшая, а что наняли таких кодописателей, они натаскали куски быстренько что то стряпали, там подкрутили, здесь подтянули, вроде как-то заработало, после первого удачного прогона пустили, а потом всю жизнь сидят на его поддержании. И все ето входит в стоимость продукта в конечном итоге и в головные боли пользователей и их затраты кстати...
А так нечего конечно...

1 Что за ерунду вы пишите. Ну взять игры хотя бы. Дум написала комманда из 5 человек за несколько месяцев. Сейчас игры пишут по 5 лет 300 человек за 100 млн долларов. Тоже самое по другим отраслям. 6 версия 1С без слез не взглянуть - уровень курсовой работы, а на этом продукте выросла одна из ключевых русских IT компаний

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

[Helmsman]

Странные вещи Вы пишете. Повторное использование кода не имеет ни малейшего отношения к языку. Просто кобол часто используется в таких задачах, где reuse в принципе не нужен/невозможен.

[flip_flop]

А вот какая эволюция Кобола за все 100 лет его развития? Ну, например ФОРТРАН изменился сильно, сейчас у него и все структурные элементы и динамические массивы и ООО и Visual, вообщем любо дорого смотреть: и работу делает и мозги не калечит При этом эффективность осталась и даже выросла для его задач. Такой динозавр как Кобол тоже должен был бы быть адаптирован под современные нужды, нет?

[zVlad]

....Иногда приходится изголяться, сильно использовать "service calls"(вызов системных функций, a OpenVMS имеет просто гиганскую библиотеку их, охнереть просто, вот у меня книжек по библиотекам OpenVMS штук едак 30-50 на полке лежат рядом, там блин все что хочешь можно найти), часть писать непосредственно на DCL(batch язык OpenVMS), комбинировать, работать вплотную с самой OpenVMS(процессы, I-O, память, стреамс и прочее) что-бы что-то сделать едакое(неподвластное самому Коболу) на нем, но все решаемо вообщем то...
И кстати очень интересно, все ети связки, комбинации очень хорошо, мне именно ето больше всего нравится!!!
Мозги временами "вскипают", отлично просто!!!

PS C кстати тоже самое, сам язык довоьно простой(операторы языка и их применние), остальное и самое главное ето именно библиотeки, так и здесь диназавр язык Кобол и огромные библиотеки самой OpenVMS OS. Поетому я наверно и прижился на Коболе...

Пораспросил нашего кобол програмиста (хотя знал и сам что он скажет) насчет "книжек по библиотекам" нашей системы, которая zOS. Их у него нет ни одной и он никогда не занимается, в своем програмировании, "процессами, I/O, памятья, streams" ничем таким кроме управления запросами в DB2.
Дело в том что всем этим занимается CICS, в котором его Кобол програмы выполняются, и сама система. Кроме того, проложение наше имеет так называемые архитектурные модули написанные вендором и выполняющие определенные функции полезные для этого конкретного приложения. Доступ к DB2, например, управление профаилами конечных пользователей, управление диалогом, и т.п.. Но и эти модули написаны с минимальным вовлечением "system calls" большенство из которых это CICS calls, не zOS. В конечном счете, eсли что не так то подключаемся мы, системщики и помогаем либо с CICS, либо с zOS в зависимости от проблемы. Я так понимаю что в zOS/CICS системные функцию работают само по себе, их не надо просить, звать, направлять используя "service calls". Не надо думать что их вообще нет. Они есть, и их много, они документированы. Но они в основном используется внутри, например, CICS, или DB2. Или если вы хотите что-то такое запрограмировать, особенное. Например, я предлагал запрограмировать "single sign-on" без необходимости сначала логиниться в свой work station, и потом в приложение. Как видите это шло от системщика, не от наших програмистов на коболе. В это состоит большое отличие даже между двумя, казалось бы однотипными - mainframe, платформами.
Программисты Кобол на zOS занимаются только Коболом как таковым и проблемами Кобола, которых, как я понимаю, совсем не много.

Что касаемо "динозаврами". Часто используют это слово просто потому что не имеют ничего толкового, конкретного сказать. А из Вашего, ARARAT, конкретного рассказа (который было интересно читать) становится понятным что "динозавром" является не Кобол, а OpenVMS с его библиотеками, которые надо использовать.

[Helmsman]

А вот какая эволюция Кобола за все 100 лет его развития? Ну, например ФОРТРАН изменился сильно, сейчас у него и все структурные элементы и динамические массивы и ООО и Visual, вообщем любо дорого смотреть: и работу делает и мозги не калечит При этом эффективность осталась и даже выросла для его задач. Такой динозавр как Кобол тоже должен был бы быть адаптирован под современные нужды, нет?

Что такое "современные нужды"? Навскидку, добавилась возможность OOP, и, может, ещё какие-то мелочи. Но и это всего лишь инструмент, которые далеко не всегда нужен.

[zVlad]

А вот какая эволюция Кобола за все 100 лет его развития? Ну, например ФОРТРАН изменился сильно, сейчас у него и все структурные элементы и динамические массивы и ООО и Visual, вообщем любо дорого смотреть: и работу делает и мозги не калечит При этом эффективность осталась и даже выросла для его задач. Такой динозавр как Кобол тоже должен был бы быть адаптирован под современные нужды, нет?

http://www-03.ibm.com/software/products ... coboforzos" onclick="window.open(this.href);return false;

P.S. http://www-03.ibm.com/software/products ... -z-systems" onclick="window.open(this.href);return false;

[flip_flop]

А вот какая эволюция Кобола за все 100 лет его развития? Ну, например ФОРТРАН изменился сильно, сейчас у него и все структурные элементы и динамические массивы и ООО и Visual, вообщем любо дорого смотреть: и работу делает и мозги не калечит При этом эффективность осталась и даже выросла для его задач. Такой динозавр как Кобол тоже должен был бы быть адаптирован под современные нужды, нет?

http://www-03.ibm.com/software/products ... coboforzos" onclick="window.open(this.href);return false;

P.S. http://www-03.ibm.com/software/products ... -z-systems" onclick="window.open(this.href);return false;

А можно своими словами, без ИБМ и без zOS? Их читать я не буду точно Или Кобол в принципе не может быть отвязан от МФ? Говорим Кобол, подразумеваем МФ?

[solopipi]

Code: Select all

//COBUCLG  JOB (001),'COBOL BASE TEST',                                 00010000
//             CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)                        00020000
//BASETEST EXEC COBUCLG                                                 00030000
//COB.SYSIN DD *                                                        00040000
 00000* VALIDATION OF BASE COBOL INSTALL                                00050000
 01000 IDENTIFICATION DIVISION.                                         00060000
 01100 PROGRAM-ID. 'HELLO'.                                             00070000
 02000 ENVIRONMENT DIVISION.                                            00080000
 02100 CONFIGURATION SECTION.                                           00090000
 02110 SOURCE-COMPUTER.  GNULINUX.                                      00100000
 02120 OBJECT-COMPUTER.  HERCULES.                                      00110000
 02200 SPECIAL-NAMES.                                                   00120000
 02210     CONSOLE IS CONSL.                                            00130000
 03000 DATA DIVISION.                                                   00140000
 04000 PROCEDURE DIVISION.                                              00150000
 04100 00-MAIN.                                                         00160000
 04110     DISPLAY 'HELLO, WORLD' UPON CONSL.                           00170000
 04900     STOP RUN.                                                    00180000
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR                            00190000
//            DD DSNAME=SYS1.LINKLIB,DISP=SHR                           00200000
//GO.SYSPRINT DD SYSOUT=A                                               00210000
//                                                                      00220000

[Dmitry67]

LKED.SYSLIB DD форева!

[ARARAT.]

...
Что касаемо "динозаврами". Часто используют это слово просто потому что не имеют ничего толкового, конкретного сказать. А из Вашего, ARARAT, конкретного рассказа (который было интересно читать) становится понятным что "динозавром" является не Кобол, а OpenVMS с его библиотеками, которые надо использовать.

Я вообщето на Коболе и являюсь одновременно и прикладным и системный программистом. У нас нет разделений... Я еще выполняю роль и системного админа, когда есть необходимость, т.е. проблемма сложная и требуется системные знания. У нас есть админ, только он знает OpenVMS хуже меня. Вот только недавно перенастраивал распределение памяти, динамической не хватало на SSH.
OpenVMS совсем непричем и тем более ето не диназавр совсем, ето очень мощная OS, причина интенсивного использования service calls в недостатках Кобола по возможностям, в нем нет библиотек функций практически(очень оганиченный набор) и он не системный язык, И вот когда мне надо использовать что-то напрямую из системы, синхронизировать с другими процессами или проект не уровня простого создания репорт.
Вот например делал проект по созданию автоматической подсистемы "слежения" за всеми пользователями системы, что они делают(какие прогс запускают), сколько времени тратят, что изменяют и прочее с полностью скрытым для них приходилось обращаться к системе, работать с отдельными процесами, памятью, и I-O... Ето уже практически чисто системное программирование, но кроме Кобол нечего для етого нет, приходилось изголяться и на Кобол, часть была на DCL и огроное использование service call(ето просто системные вызовы напрямую из программы). Часто использую service calls для простых проверок например даты, для запуска отдельных процессов(для выполнения каких то функций или модулей), для работы с файловой системой(файлами), для перенаправления streams. Етого всего Кобол делать не умеет просто, так как ето язык высокого уровня, а нужны иногда именно низкоуровневый доступ и функции...

[ARARAT.]

А вот какая эволюция Кобола за все 100 лет его развития? Ну, например ФОРТРАН изменился сильно, сейчас у него и все структурные элементы и динамические массивы и ООО и Visual, вообщем любо дорого смотреть: и работу делает и мозги не калечит При этом эффективность осталась и даже выросла для его задач. Такой динозавр как Кобол тоже должен был бы быть адаптирован под современные нужды, нет?

Что такое "современные нужды"? Навскидку, добавилась возможность OOP, и, может, ещё какие-то мелочи. Но и это всего лишь инструмент, которые далеко не всегда нужен.

+100 У нас не используется нечего нового...
Даже ООП не пошел, его наши Кобол программеры просто не знают/понимают...

[zVlad]

...
Что касаемо "динозаврами". Часто используют это слово просто потому что не имеют ничего толкового, конкретного сказать. А из Вашего, ARARAT, конкретного рассказа (который было интересно читать) становится понятным что "динозавром" является не Кобол, а OpenVMS с его библиотеками, которые надо использовать.

Я вообщето на Коболе и являюсь одновременно и прикладным и системный программистом. У нас нет разделений... Я еще выполняю роль и системного админа, когда есть необходимость, т.е. проблемма сложная и требуется системные знания. У нас есть админ, только он знает OpenVMS хуже меня. Вот только недавно перенастраивал распределение памяти, динамической не хватало на SSH.
OpenVMS совсем непричем и тем более ето не диназавр совсем, ето очень мощная OS, причина интенсивного использования service calls в недостатках Кобола по возможностям, в нем нет библиотек функций практически(очень оганиченный набор) и он не системный язык, И вот когда мне надо использовать что-то напрямую из системы, синхронизировать с другими процессами или проект не уровня простого создания репорт.
Вот например делал проект по созданию автоматической подсистемы "слежения" за всеми пользователями системы, что они делают(какие прогс запускают), сколько времени тратят, что изменяют и прочее с полностью скрытым для них приходилось обращаться к системе, работать с отдельными процесами, памятью, и I-O... Ето уже практически чисто системное программирование, но кроме Кобол нечего для етого нет, приходилось изголяться и на Кобол, часть была на DCL и огроное использование service call(ето просто системные вызовы напрямую из программы). Часто использую service calls для простых проверок например даты, для запуска отдельных процессов(для выполнения каких то функций или модулей), для работы с файловой системой(файлами), для перенаправления streams. Етого всего Кобол делать не умеет просто, так как ето язык высокого уровня, а нужны иногда именно низкоуровневый доступ и функции...

Очень интересно. Спасибо.
Сравнение с диназаврами вообще скорее признак дилетантизма. Это очевидно хотя бы из того что когда начинается серьезный деловой разговор то оказывается что сравнение это не подходит ни для чего.
На МФ, в zOS, соотношение прикладных скилсов и системных диаметрально противоположным. Исключения конечно бывают (кстати, а для вашей платформы ваша ситуация типична, или это исключение тоже?), но чаще системщики разбираются в системе лучше чем прикладные ребята. Это хотя бы потому так что не имея соответствующего доступа, в zOS, сделать то что Вы делаете будет невозможно.
То что в Коболе нет библиотек для конкретной ОС это совершенно понятно. Это не роль языка, но у языка должен быть интерфейс к системным функциям, причем желательно у всех языков акредитированных в конкретной ОС. У нас наиболее подходящим для того что Вы делаете как системщик языком является REXX.

Очень удивлен что в такой, со слов многих, развитой системе - OpenVMS - потребовалось создавать "...автоматической подсистемы "слежения" за всеми пользователями системы, что они делают(какие прогс запускают), сколько времени тратят, что изменяют и прочее с полностью скрытым для них приходилось обращаться к системе, работать с отдельными процесами, памятью, и I-O...". В zOS есть несколько стандартных и опциональный вариантов (RMF стандартная компанента, например) решающих эти и многие другие вопросы. В основном все такое базируется на том что система и ее подсистемы сами собирают и хранят много информации обо всем, и если есть нужда то пишутся программы обрабатывающие эту информацию либо, как говорится post process, либо оперативно, мгновенно, динамически.

Есть у нас System Automation для запусков, перенаправлений, контроля и реакции на любые события. Причем System Automation это не черный ящик. Многие его программы, написанные на Rexx, доступны в исходном коде и можно писать и подключать свои программы.

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

[ARARAT.]

Система контроля которуя я писал была на уровне наших задач например ето пользователь тронул етот account, тогда-то с помошью того то, сделал то то, провел столько то времени и т.д. Да, мы используем index RMS(встроенна в OpenVMS) в качестве BD...
По результатам managers могут посмотреть кто что делаeт, сколько на ето тратит времени и прочие вещи... Деталировка очень детальная, точность хорошая, правильно отрабатывает множественные логинс для одного и того же пользователя, и сама база для етого не огромная и регулярно чистится автоматом. Никаким образом не видна и не увеличивает время работы(задержек никаких нет), работате уже несколько лет с нулем внимания с моей стороны. Там не одна прога была там был пакет на разных уровнях и разных назначений...
Естественно OS имеет все логи по евентам на своем уровне, задание было не об етом совсем... Я же говорю сама OpenVMS очень мощная и удобна кстати, на ней приятно работать. Да стабильность просто абсолютная, не разу практически она не упала по причине software(неважно системного или прикладного), ее положить практически невозможнo...

У Кобол и есть етот самый интерфасе с помощью которого и исполняются ети servise calls, запроси OS на выполнение... Библиотек етих запросов огромна и она очень развита нa OpenVMS. Я могу делать практически все прямо с Кобол, не выходя никуда, именно ето я и использую...

PS Насчет закупки например C компилятора для етих целей(моя мечта была) тоже пытался "пробить" в самоm начале своей работы в етой компании, даже делал "показательные выступления" спецом написанные progs на Кобол и C показывал как можно увеличить скорость исполнения, какие возможности у C.
И итоге все ох дa ах, как отлично все в C, но дальше етого нечего не пошло... Причина Кобол язык высокого уровня, на нем проще делать что нам нужно и одновременно OpenVMS позволяет делать все остальное в том-же Кобол если нужно с помощью именно тех service calls и обращений к DCL. Ну и конечно C никто кроме меня не знает...
Сейчас уже я с ними в принципе согласен, так как взяли бы C было бы примерно тоже самое, что я делаю с Кобол, если нужно что-то едакое теже service calls надо делать...
А то что мне писать легче на C, им же не легче...

[Мальчик-Одуванчик]

Вот ещё, небезизвестный Мицгол на нашу тему и тоже с той же самой цитатой, хе-хе: "Четыре профессиональные деформации программистов на языке Perl, демонстрируемые на живом примере"

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

[ARARAT.]

Недавно был один случай прикольный...
Я лет едак 10 назад написал Patient Appointment Scheduler system на Кобол, и вот ети кодеписатели решили перенести(переписать) его на front end browser based сделать...
Одна малюсенькая функция етого есть пересчет дат с нормального формата на weeks based, любой given date, от любой точки отсчета(начало месяца, года или любой другой given date). Так вот они так и не смогли ее реализовать, так как не смогли найти "куски кода"(ну исами не смогли написать) что-бы сделать такую функцию в таком глобальном исполнении. Просто драпнули week based format... Или еще одна фишка была, мой scheduler перерасчитывал все мгновенно из-за много-мерных массивов с точностью до секунды за весь год сразу, поетому был очень мощный механизм для поиска и назначения аппоинтментс с динамической воможностью изменения аппинтмент слот(формата сетки аппоинтментс) на любой день отдельно или месяц или весь год в любых форматах даты. Причем все ето делалось безо всяких задержек и прямо на екране "одним движением руки"... Тоже не смогли реализовать... Я кстати написал етот пакет за один месяц(ядро, основные прогс), в пакет входит примерно 15 прогс разного назначения, все actions фиксируется, кто что когда сделал, изменил, множественные календари для рабочих смен докторов с "перегрузкой"(наложением друг на друга), активных, пассивных на уровне всего facility или отделных докторов, с возможность установки временных календарей и динамично их переключать. Сами типы аппоинтмнетс множественного типа, включая офисные типы, типа митингов например. Все базы автоматически сохраняют все историю с самого начала, базы хранятся в активных и пассивных состояниях, все датy были с возможностью "*" в любых "разрядах", например записать календарь на Март на любые года или например все Субботы и Воскресенья OFF для докторов или начиная с 2017 до "*", короче свобода полнейшая кажый разряд мог брать "*" как "от" так и "до" в любой комбинации, можно было одной записью, а не каждый год/месяц/неделю в отдельности и много-много чего еще(manual по всей етой системе был не одна сотня страниц когда я его писал, правда его почти никто и не читал ). Механизм поиска очень мощный и очень детальный(ето много раз пригодилось когда кто-то чего там удалял и потом были проблеммы) с автоматическим очищением и тоже работает без моего внимания ети 10 лет... И ето все сделанно ручками с нуля, безо всяких кусков кода, работает absolutely solid безо всяких сбоев на множественным машинах одновременно(как обычно бывает в больших доктор офисах).
Особенно week based format был полезен для праздников, так как они здесь не редко типа "последний Четверг" например, и сделав week based формат требуется всего одна записть для етого, иначе каждый год надо вбивать manual... Или пациент звонит и говорит мне аппоинтмент на вторую неделю Марта или аппоинтмент через 20 недель тоже удобно работать для пользователя напрямую с weeks, а не обычными датами...

А все почему, да потому что кодописатели которые тащат код отовсюду не умея писать сложные вещи самим... Не привыкли, метода "современного программирования" совсем другая как нам тут выше писали...

PS Что-то я расписался блин...

[zVlad]

Недавно был один случай прикольный...
Я лет едак 10 назад написал Patient Appointment Scheduler system на Кобол, и вот ети кодеписатели решили перенести(переписать) его на front end browser based сделать...
Одна малюсенькая функция етого есть пересчет дат с нормального формата на weeks based, любой given date, от любой точки отсчета(начало месяца, года или любой другой given date). Так вот они так и не смогли ее реализовать,

..............
А все почему, да потому что кодописатели которые тащат код отовсюду не умея писать сложные вещи самим... Не привыкли, метода "современного программирования" совсем другая как нам тут выше писали...

PS Что-то я расписался блин...

Конечно не повсеместно, но средний уровень програмирования явно катится вниз. Слишком много внимания уделяется визуальной части приложений. Как будто внешнее представление важнее внутреннего содержания. Веб дизайнерами все стали, а программировать нужные важные алгоритмы разучились. Нагрузка переносится с компьтера на пользователя который зачастую должнен совершить много операций с диалоговой компанентой чтобы добиться конечной цели гораздо легче достигаемой без изысканного диалога.
Даже в моем скучном МФ описание конфигурации сделано было диалоговым и гораздо более трудоемким чем когда это было на уровне текстового файла с помощью макрокоманд с определенным синтаксисом. В последнем случае можно было размножить некий шаблон и отредактировать только те части где нужна другая информация не трогая того что одинаково. А в диалоге надо пройти по всем шагам итеративного диалогового процесса повторяя ввод одной и той же информации. Глупо. Есть правда софт, который платный и у нас его нет.

Есть еще интересный пример. Софт написанный in house, на Коболе на МФ. Сколько работаю софт этот порываются перевести на ПК. Много лет прошло, воз и ныне там, и вот уже устанавливаем отдельный МФ для этого софта. Маленький МФ, с одним CPU. Благо что этот МФ еще и DR site для другого более мощного приложения.
Куда катимся?

[ARARAT.]

Недавно был один случай прикольный...
Я лет едак 10 назад написал Patient Appointment Scheduler system на Кобол, и вот ети кодеписатели решили перенести(переписать) его на front end browser based сделать...
Одна малюсенькая функция етого есть пересчет дат с нормального формата на weeks based, любой given date, от любой точки отсчета(начало месяца, года или любой другой given date). Так вот они так и не смогли ее реализовать,

..............
А все почему, да потому что кодописатели которые тащат код отовсюду не умея писать сложные вещи самим... Не привыкли, метода "современного программирования" совсем другая как нам тут выше писали...

PS Что-то я расписался блин...

Конечно не повсеместно, но средний уровень програмирования явно катится вниз. Слишком много внимания уделяется визуальной части приложений. Как будто внешнее представление важнее внутреннего содержания. Веб дизайнерами все стали, а программировать нужные важные алгоритмы разучились. Нагрузка переносится с компьтера на пользователя который зачастую должнен совершить много операций с диалоговой компанентой чтобы добиться конечной цели гораздо легче достигаемой без изысканного диалога.
Даже в моем скучном МФ описание конфигурации сделано было диалоговым и гораздо более трудоемким чем когда это было на уровне текстового файла с помощью макрокоманд с определенным синтаксисом. В последнем случае можно было размножить некий шаблон и отредактировать только те части где нужна другая информация не трогая того что одинаково. А в диалоге надо пройти по всем шагам итеративного диалогового процесса повторяя ввод одной и той же информации. Глупо. Есть правда софт, который платный и у нас его нет.

Есть еще интересный пример. Софт написанный in house, на Коболе на МФ. Сколько работаю софт этот порываются перевести на ПК. Много лет прошло, воз и ныне там, и вот уже устанавливаем отдельный МФ для этого софта. Маленький МФ, с одним CPU. Благо что этот МФ еще и DR site для другого более мощного приложения.
Куда катимся?

+100
По циклам катимся, как всегда...
Вот сейчас опять скоро начнется цилк маинфрамов(они сейчас так могут и не называться) с облаками и облачными сервисами, ведь по сути ето оно и есть как было с маинфраме и множеством клиентов подключаемых к ним и для запуска приложений(share processing) и для хранения данных(shared data).
Причины просты и понятны, стоимость собственной инфраструктуры и защищенность данных in-house всегда будет выше(защищенность ниже) чем shared на централизованных маинфрамес(или как "обзывают" сейчас облаках)...

[zVlad]

По циклам катимся, как всегда...
Вот сейчас опять скоро начнется цилк маинфрамов(они сейчас так могут и не называться) с облаками и облачными сервисами, ведь по сути ето оно и есть как было с маинфраме и множеством клиентов подключаемых к ним и для запуска приложений(share processing) и для хранения данных(shared data).
Причины просты и понятны, стоимость собственной инфраструктуры и защищенность данных in-house всегда будет выше(защищенность ниже) чем shared на централизованных маинфрамес(или как "обзывают" сейчас облаках)...

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

[SVK]

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

Куда катимся?

Вот сюда:

PressAnyKey.jpg

[ven27]

Класс, известную шутливую фразу Дейкстры восприняли как экстремизм )))

Да двушечку б ему за такое!

[geek7]

Работа современных программистов это грамотно скрутить готовые куски кода, а не писать что-то свое.

А как же job security?!!

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

[geek7]

Дело не в велосипедах совсем, дело в желании быстренько стряпать что-то "на коленке", тот самый "коленочный подход"...
От него все беды с несконечными updates и исправлениями.
Фундаментальности около нуля, зато желание что-то по быстрому "рубануть" и "сплавить" хоть отбавляй...

Вы так говорите, как будто в желании по быстрому рубануть и сплавить есть что-то плохое.
На самом деле сложность ПО за последние 20-30 лет выросла на порядки.
Если Билла Гейтса сделал миллионером бейсик, созданный за полтора месяца, то сейчас месяц будут только вебморду на бумаге рисовать. Потратят несколько миллионов, что бы потом пользователь еще носом крутил, что дескать че за дела, в бесплатный софт рекламу вставили, он такое пользовать не согласен

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