Кобол обычно критикуется за многословность и громоздкость, поскольку одной из целей создателей языка было максимально приблизить конструкции к английскому языку. (До сих пор Кобол считается языком программирования, на котором было написано больше всего строк кода [2].) Так, широко известно высказывание Дейкстры «Использование Кобола калечит ум. Его преподавание, следовательно, должно рассматриваться как уголовное преступление».[3]

В то же время, Кобол имел прекрасные для своего времени средства для работы со структурами данных и файлами, он стал первым языком, в котором появился тип данных «запись».[4] Это обеспечило ему долгую жизнь в бизнес-приложениях, по крайней мере, в США.

Dr. Dobb’s Journal (со ссылкой на The Gartner Group, Computerworld, Ovum и Micro Focus International)[5] приводит следующие факты. К 1997 году активно использовалось около 240 миллиардов строк кода на Коболе. Около 90 % финансовых транзакций в мире обрабатывается кодом на Коболе, и 75 % коммерческой обработки данных написано на Коболе. Общая стоимость используемого в настоящее время коболовского кода оценивается в 2 триллиона долларов США. До сих пор ежегодно пишутся миллиарды новых строк кода на Коболе.

Free COBOL Runtimes.
COBOL compilers for .NET, Windows, Linux and SPARC.
Take control of your application distribution costs.
http://www.netcobol.com/

выучить что ли...

Дейкстра хорошо сказал: «Использование Кобола калечит ум. Его преподавание, следовательно, должно рассматриваться как уголовное преступление»

за 1С тогда пожизненно сажать надо!

а этот Дейкстра вообще слишком много говорил...

(2) а чем именно лично вам 1С не угодил?
мало денег зарабатывваете программируя на 1С?
неудовлетворяющие клиентов решения программируете на 1С?

чем вот именно вам он так неугодил то?

моя первая зарплата для 2500 человек была написана в 1979 году на КОБОЛе.
Вот думаю, искалечил он мне ум или нет? :)

А писал я на нем, не задумываясь о том, сложная конструкция, или простая. Что мне было надо - то и писал. 10 лет работала программа на ЕС-1020.
Так что вспоминаю с "приятностию" этот язычок :)

(4) это был вброс, забей

(5) Если есть мозги - пишешь хоть на чем. а если мозгов нет - призываешь перейти "на новую прогрессивную платформу"...

(4)
полноценные объекты хочу!
наследование хочу!
рамки, в которые всех ставит 1С достали!

>COBOL - жив и будет жить

это не для наших реалий. п.э. пох...

(8) любая система имеет рамки и ограничения.

(8) а можно пример пары задач которые должны решаться на платформе 1С но не могут по причине "рамок"?

(11) написание операционной системы на 1с ;)

но возможности создания своих объектов мне лично не хватает...

(12) проводник и бразуер и игрушки видел на 1С
а что еще нужно для операционки? :)

приведите пример кода на коболе
хотя, если учить, то шарп

а танчики и дум еще не написаны на 1с? нууу.. это не язык.. недоразумение :)

ухаха
perform varying i from 1 to 10
точно литературный язык

(15) кому сдался этот шарп..

(18) а кому кобол? щас два варианта - шарп/ява... остальное все идет лесом, как бы дельфисты не пыжились

чего не хватает в 1С:

Программирование

Более жесткий синтаксис был бы крайне полезен. Или хотя бы стоило добавить возможность его «углубленной» проверки, по аналогии с другими языками – инициализированные, но не использованные, переменные внутри процедуры/функции; проверка запроса на оптимальность (построение плана запроса); несоответствия типов переменных при повторной их инициализации и т.д.

Архивы и буфер обмена. Добавить отбор по объектам в конфигураторе. Сделать так, чтобы были видны только те объекты, которые интересуют на данный момент.

Выгрузка cf-файлов по выбранным объектам.

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


Объекты.

Наследование.

Перегрузка функций.

>Добавить отбор по объектам в конфигураторе. Сделать так, чтобы были видны только те объекты, которые интересуют на данный момент

есть фильтр по подсистемам

>Выгрузка cf-файлов по выбранным объектам.

гы... как потом объединять этот винигрет?.. есть cfu в принципе

(19) два варианта это - си/ява, шарп и остальные - в опе

а вообще пишут-ли сейчас на алголе, фортране, пиэле ? много субд было: ИНЕС, RBASE, куда они делись?
Думаю, никуда. Просто элементная база была другая, и назначение соответствующее.
Значит, надобность в этих языках отпала.
А вот Си - живет.. примерно в 88 году у меня на руках появился дистрибутив QuickC, на двух 5"флоппи, до сих пор лежат в столе :)

КОБОЛу отпущено столько-же сроку, что и первым.. Удобство исчезло, исчезнет и язык.

(23) дураков нет бизнес-приложения на с писать...

(24) на фортране точно пишут. Алгол успешно проср@ли.

(26) поддержка разных древних полудохлых проектов и прочая экзотика?

(23)но-но!! какой-бы ни был язык, всё равно для экономических расчетов лучше СУБД ничего еще не придумано.
ИМХО, увидеть это просто: в СУБД очень легко изменять структуру файлов-хранилищ информации .. по крайней мере в *.DBF.. Насчет SQL- не в курсах, но подозреваю, там тоже электронные таблицы..

(28) бред какой-то...
экономические _расчеты_ и СУБД никак не связаны...

(29)а, ну извини..

о чём речь вообще
кто на си за вечер конфу напишет? а на 1с можно
это разные области кодохенерирования

(28) казалось бы, при чем тут экономические расчеты и бизнес-приложения..

http://www.csis.ul.ie/cobol/exercises/Exm-CSISEmailDomain/Prg-CSISEmailDomain.htm - хрень какая-то

на клиппер/фоксик очень смахивает

(33) я думал, супер макроассемблер

(28) ну и кроме того, в нормальной СУБД видеть (а тем более, изменять) структуру хранения данных пользователю не следует...

а кто связал СУБД и экономические расчеты? я-ж не написал, что назначение СУБД - эк.расчеты.. Просто удобное средство.

если писать бухучет на Си, при внесении изменений надо менять не только содержательную часть, но и управляющую программу, т.к. описание внешних файлов лежит именно в ней. И это неудобно.
1с разделила управляющую часть (движок) от информативной, которая обрабатывается на СУБД.
Есть посредник между ними - конфигурация.
Вот управляющая программа (27) не меняется уже лет 7-8, а вот СУБД-шные файлы - чуть не каждый месяц

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

Кроме СУБД много есть другие концепции БД, например Cash

Cache

А кто-нибудь знает на каком языке написана 8-ая платформа?

(40) все знают, с++

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

>>  дураков нет бизнес-приложения на с писать...

братьям Нуралиевым расскажи - вот дураки 1С на С++ пишут ;)

(38), (39) гадость ваш Cache!

(43) 1С в части engine все-таки не бизнес-приложение... а именно эта часть написана на с++.

(45) без комментариев )

(0) - а теперь милый человек, попробуй ка написать резюме на реальную позицию Cobol программиста где нибудь в США или Европе, после того как "выучил за ночь".

ага.

Там и за 120 000 USD в год не могут людей найти - штучная профессия, оставшихся спецов можно пол пальцам одной руки сосчитать.

(47) да ну - на foxpro похож...  уговорил выучу ;)

(48) - желаю удачи при дальнейших собеседованиях в США

(24) Однокурсник работает на PL\1 в ИП. И все там ОК! Капиталисты умеют считать деньги.

(49) легко - самое сложное по телефону говорить - слишком быстро тарахтят носители языка - приходится их притормаживать )

брат кстати в штаты из испании  переезжает - там совсем кисло стало, но ему проще - он мелкомягкими сертификатами облеплен

(1) а Пролог тогда просто взрывает мозг?

знаю человека, который ЗИК на прологе написал... и ничего лет 10 зарплату считало...

(14) тогда только вирус осталось написать.
типовые не вспоминать - они вне конкуренции...

(55) вирус уже был...

(7) Согласен, забадали с этой 8-кой.

(20) это надо в v8: Пожелания к 1С поместить

(58) такой большой а в сказки веришь...

(59) не, я к тому, что ЭТО там более уместно, чем здесь...

(30) ИМХО чисто теоретически экономическую задачу можно реализовать не только на СУБД (особенно на реляционной), но и на графах и прочих структурах данных.

(60) СУБД - это всего лишь средство _хранения_ данных. Чем их извлекать, чем обрабатывать, и что делать дальше - вопросы другие.

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

(62) Тем не менее, кобол устарел. Но это не повод отказываться от поддержки стабильно работающих вещей.

(48) увы и близко не стояли.. Помнится году в 85-м писал отповедь проектной конторе в Ворошиловограде, чтоб отвалили с Коболом.. А лни ж уже настрочили.. километры сорцев.. технологии никакой..   Тот, кто работал знает, что Кобол и в подметки РL-ю не годился.. В первую очередь, из за кривого обработчика программных прерываний, особенно для локализованной версии..

(50) PL конечно был сказка-мечта, а не язык.. Конечно, впоследствии его начали прилаживать к СУБД, помнится  пристраивал его к DB-2 в 88-м, но увы.. контора упала.. и аллес.. А что запомнилось из нехорошего, так то, что   каждый запрос к SQL нужно было компилировать, т.е. в реале система была достаточно жесткой

(63) поддержу,  устарел,причем еще в конце 70-х.. и ежли что-то работает, увы нужно держать

(61) согласен, поэтому и говорю, что экономические задачи и СУБД - в общем случае независимые понятия.

(63) ИМХО все зависит от поддержки. Пока ДБФ был кому-то интересен - он развивался или по крайней мере использовался. Пока был интересен PL/1 и REXX - использовались и развивались они. Пока интересна Java - она хоть как-то развивается, пусть даже вопреки желаниям Apple.

>> Пока ДБФ был кому-то интересен - он развивался или по крайней мере использовался.

ограничения

sql -серверы - настоящее

(69) не спорю. принципиально это в настоящее время ничего не решает.

(69) SQL-то он тоже пока развивается, но будущее за объектно-ориентированными СУБД. К сожалению, они уже более 10 лет в зачаточном состоянии.

(71) не угадал

(72) Чего не угадал - проще работать с системой, когда она хранит объекты, а не когда мы храним в SQL таблицы, которые в объекты преобразуются.
По крайней мере, блокировки и операции в случае объектов выглядят более прозрачно.
P.S. SOAP - это как раз объектный подход.

контрпример в 1С есть и таблицы и объекты )

писание на коболе в институте вспоминаю с содроганием. и ацпу. Больше я его нигде не видел.

(0) не удивлюсь если там же напишут, что 90% финансовых транзакций производят на процессоре 80286

(76) скорее IBM 360/370 :-)

(76)(77) во многих местах вполне эксплуатируются 386-486 машины. Тем более, если они используются для работы с документами, электронной почты и терминального доступа к мэйнфреймам.
заметьте, как в полном соответсвии с законами диалектики меняются парадигмы: персональные вычислители (логарифмические линейки, калькуляторы)-пакетный досуп к мэйнфреймам (из которых остались по существу систем/360, в т.ч. и в реинкарнации ЕС ЭВМ) - персоналки - терминальная работа на мэйнфреймах (RTS-RSX) - персоналки - терминальный доступ к серверам - персоналки - терминальный доступ к приложениям (SaaS)...

(78) Что-то сомнительно, что во многих. Технический парк-таки требует обновления, а упомянутые машины давным давно сняты с производства.

Вот чему точно нельзя учить начинающих программистов - так это SAP. Потому как там много неоптимальных конструкций

(79) Ну и обновляют. по выходу из строя. или когда уже крайний "моральный износ".

(81) А как не наступить моральному износу-то? Что за работа с документами без МС Ворда или аналога? Ну да ладно, представим, что каким-то сферическим динозаврам в вакууме достаточно какого-нибудь Ворда под Винду 3.1 (или чего ещё по-хуже) и они вообще не обмениваются документами с внешним миром.

Но техника-то старится по-любасу. Комплектухи для 486 тупо нигде не достанешь. Следовательно, компьютер меняется целиком. И что потом? Пользоваться WordPad-ом для совместимости со старьём? А в случае "чего по-хуже" ставить виртуалку с ДОС (или ещё каким закаменевшим дерьмом мамонта)? Это, типа, эффективность такая, такой зоопарк поддерживать и пользоваться, в любой момент ожидая отказа оборудования?

(82) Что-то типа того. Не тратить деньги потому, что появилось "новое крутое решение" (если, конечно, это решение не даст такую сумму дохода/экономии, которое очень быстро окупит замену).
Графические станции апгрейдятся/меняются достаточно быстро. Сервера передвигаются на менее ответственные роли... Есть сроки плановой замены.
Не забывай, что кроме покупки нового компа нужно покупать новый софт, и еще платить за утилизацию старого железа. Поэтому для замены должны быть какие-то основания кроме "вау! новый крутой комп появился".

Что то здесь попутали?

DBF - формат структуры файла... описательный заголовок и набор записей.
SQL - язык запросов к файлам определённой структуры.
СУБД - в общем случае сервер приложения (отдельная прога, управляющая, как правило файлами собственной структуры) и к неё (проге) можно обращаться на языке SQL. Что касается языка программирования: КОБОЛ, FoxPro, Harbour, 1C, C, Java, то это совсем "сбоку". В частности:

1. На проге C# вы можете работать с файлами структуры DBF, используя управляющую СУБД LetoDB или ADS либо
2. На проге VFoxPro можете работать с СУБД MS SQL...

В свете обсуждения КОБОЛ - просто очень давно созданный и заточенный под структуры типа "запись" язык программирования и всё!

LINUX, UNIX и пр.
в одной знакомой крупной испанской фирме (торговля) ни одной винды - только терминалы AS 400

(84) да, я про ДБФ вспомнил в контексте его использования файловой 1С 7.7 - исключительно как хранилище данных. безусловно, к развитию формата и даже его поддержке это имеет весьма слабое отношение.

(2) ты с Коболом сталкивался, чтоб так говорить?

(87) к сообщению (2) Вспомнил об одной из занятных идей "коллеги, не обижайте 1С-ников, если они вдруг проявляют торможение при восприятии некоторых, казалось бы, очевидных вещей. Они не виноваты, с мозгами у них всё в порядке. Просто платформа, в которой они работают, приучила их мыслить другими категориями и применяя другие принципы". Полностью прочитать можно в ворд документе: http://www.zhsoft.16mb.com/word/blog1c.doc

(0) Рад за него! А кто это?
гы-гы-гы... :)

(1) Был еще язык Форт. Эффект тот же :)

(90)
ЙОДЫ МАГИСТРА РЕЧИ ТАЙНА ОТКРЫТА:
НА ФОРТЕ ПРОГРАММЕР СТАРЫЙ ОН ПРОСТО ЕСТЬ.
(с)
да ничего язык... применялся для управления системами и в астрономии

Базовый язык форт бесплатно распространяется группой Forth Interest Groop (FIG). Диалект языка форт используется в OpenProm — базовом программном обеспечении ЭВМ на базе процессоров SPARC. Программы на языке Форт кратки, занимают немного места в памяти. Несколько ключевых слов этого языка — знаки препинания, поэтому программы работают быстро, но одновременно это затрудняет их чтение и сопровождение.

жив курилка...
SP-Forth is an ANS forth system for Windows and Linux. It features optimized native code generation, high speed execution, full ANS'94 support, small yet highly-extensible kernel, big number of additional libraries for developing sophisticated windows applications, active and helpful community.

http://spf.sourceforge.net/

(91) :)
(93) ужас