Комментарии 35
Дальнейший трёп про парадигму — это уже лирика.
Взаимоисключающие параграфы:
Дело в том, что Python (да и Java) не имеет встроенной поддержки чисел с фиксированной точкой.
…
Для выполнения вычислений с фиксированной точкой в Python мне пришлось импортировать модуль Decimal
Вообще удивительно как автор всю специфику кобола свёл к фикс.точке.
Decimal — часть стандартной библиотеки, которая встроена и которую не нужно никак специально ставить.
Вон в хаскеле Bool, Int и Float часть прелюдии — http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html и ничего.
выходят новые стандарты: COBOL-85, COBOL 2002 и объектно-ориентированный COBOL
COBOL 2014
en.wikipedia.org/wiki/COBOL
есть OpenCobolIDE 4.7.6 (Last released: Dec 30, 2016)
pypi.org/project/OpenCobolIDE
большинство современных языков программирования совершенно не имеют встроенной поддержки вычислений с фиксированной точкой. (Я так думаю, что правильнее было бы сказать, что ни один из современных языков это не поддерживает, но я не могу это надёжно проверить.)
Вычисления с фиксированной точкой поддерживает Ada — скажем, в версии стандарта Ada 2012 (см. здесь и здесь).
Во всех статья про плавающую точку немного лукавят, говоря что фиксированная точка спасет мир. Это не так.
Проблема IEE 754 в том что основание системы счисления хранения числа это 2 и соответственно некоторые десятичные дроби в нем не представимы. Отсюда и возникают сразу же ошибки вычислений.
Есть стандарт IEE 754- 2008 где как раз это и починили но этот стандарт в железе не реализован (может где и есть).
ЗЫ В яве есть BigDecimal из коробки, так что говорить, что Ява вообще не умеет в десятичную арифметику это не правда. С другой стороны для него нет перекрытых арифметических операций в компиляторе, поэтому писать выражения через вызов методов сложно.
У меня есть два соображения по этому поводу.
1. В США натуральные дроби — это моветон, сложная штука, которую не используют.
2. В бухгалтерии и финансах не приняты.
В США натуральные дроби намного нужнее для людей, чем у нас, так как они не используют метрическую систему. Если ты не умеешь быстро считать дроби, то как ты унции в галлоны, а ярды в мили переведёшь?! По поводу нативной поддержки decimal: хоть её и нет, но в amd64 есть ряд инструкций в описании которых пишется, что эта инструкция используется в основном для fixed point.
В США рациональные числа везде, едешь такой, а тебе указатель до съезда 1/4 мили.
А поддержки аппаратной понятно почему нет, придётся памяти о грызть не мало. float может примерно на 25 порядков число больше или меньше отобразить чем 64 битное рационально. Поэтому дилемма, либо точно и с небольшим диапазоном, либо не совсем точно но с большим диапазоном. Ну и для большинства задач float достаточен.
да реализуйте свои структуры данных
Симметричный ответ: а зачем тогда числа с плавающей запятой ввели? Ну и реализовывали бы их на своих структурах данных. Зачем это тащить в процессор?
Низачем. На RISC-процессорах из часто и нет.
Плавающая запятая довольно дорогая в программной реализации. В отличии от рациональных чисел.
Там ведь (при приведении к общему знаменателю) и числитель и знаменатель будут расти (весьма быстр и почти гарантировано). В результате чего вам очень быстро не хватит int_64.
В результате чего вы перейдёте на длинную арифметику, а производительность упадёт катастрофически.
ПС
А цель, избежать накопления ошибки, в общем случае, так и не будет достигнута ;)
да реализуйте свои структуры данных
Симметричный ответ: а зачем тогда числа с плавающей запятой ввели? Ну и реализовывали бы их на своих структурах данных. Зачем это тащить в процессор?
Я не знаю зачем они их ввели, но сейчас из этого мало хорошего вытекает. Наверно маркетинг, они же тогда софтом сильно не занимались, значит нужно было добавлять "плюшки" аппаратно. Но если тенденцию продолжить — будет только хуже.
Они производители процессоров, что значит они бы реализовали бы на "своих структурах данных"? Сейчас каждый топ производитель имеет свой компилятор
Ну и опять о цене миграции, многие системы которые работают с финансами написанные на коболе и исполняемые на мейнфреймах, очень не просто сертифицировать, по факту для того, что бы создать подобную систему на альтернативной платформе в нее придется инвестировать ровно столько, сколько было инвестировано за время ее жизни.
Может наоборот, законодательство не меняется, потому что программы на Cobol, и никто не хочет в них лезть для изменений.
ни одна система на коболе не переживет, отечественного бешенного принтера
Да ладно, не драматизируйте. Античные системы, как правило, реализуют вычислительное ядро, а это — простая логика движения средств, правила бухучёта и прочие базовые вещи, которые бешеный принтер по большей части обходит стороной. А интерфейсы ко внешним системам, где и творятся основные Адъ и Израиль, разумеется, не на Коболе.
Пишу на MicroFocus COBOL по работе, на никсах.
Плюсы его, во-первых, в том что можно создать текстовой GUI за секунды.
Постройка классов чумовая, да ещё можно все совпадающие переменные двух разных классов двигать между ними без напряга.
Лёгкость интеграции с другими программами просто убийственная, передать данные шелл скрипту — как нефиг делать, принять тоже. Можно курлы с SSL всякие запускать без напряга. Вообще, прицепить к нему SQL датабазу какую-нибудь проблем совсем не составит.
И самое главное — оверхед. А точнее почти полное его отсутствие. Это просто безумие. Я теперь до конца жизни в С# всякие буду плеваться за одно только это.
Настоящие минусы:
Всё, буквально всё нужно делать ручками. Если нет наработок то COBOL лучше вообще не трогать.
Уебищно выглядит любое меню. Людям привыкшим к современному, в нём ничего не понятно.
Тех долг… Это просто кошмар. В старых проектах — сотни если не тысячи человеко-часов тех долга. Его просто нельзя трогать, так как никто за это не заплатит.
Наждачный секс с файл локами, залочиванием, разлочиванием, полным отсутствием какой-либо защиты файлов от повреждения при записи и т.д. и т.п.
Дебаггинг чего-то более сложного чем калькулятор — это кошмаррррр. Трейсинг переменных ужасен.
В COBOL можно следовать best practices, но большая часть существующего кода им не следует. А значит вам его дебагить-непередебагить — см выше про дебаггинг.
Я тут ещё могу часами писать, но надеюсь суть вы поняли.
Заложники COBOL и математика. Часть 2