![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Ход раком
Чтобы ИТ-индустрия окончательно встала раком, Гуглу сейчас нужно сделать ход конем - разработать ТРЕТИЙ вариант кроссплатформенного языка-платформы с собственной виртуальной машиной, JIT, итд, итп, в дополнение к жабе и дотнету. И сманить девелоперов на него какими-нибудь заманухами страшными.
Тем более что дотнет семимильными шагами двигается в ту же over-engineered сраку, что и жаба, а альтернативы реальной тому и другому и нету.
Тем более что дотнет семимильными шагами двигается в ту же over-engineered сраку, что и жаба, а альтернативы реальной тому и другому и нету.
no subject
no subject
Скажем, строгая типизация та же - это же и есть математическая модель предметки, позволяющая проверить ее на непротиворечивость на уровне реализации.
no subject
Так как раз проблемы в проектировании системы обычно всплывают в мелочах и подсистемах. Т.е. если разбить на подсистемы и спроектировать наиболее неадекватные куски используя строго теоретические модели - мы уже спасемся от части маразма
Только это займет много времени и часто будет шибко громоздко. Матан оно конечно хорошо, но далеко не всегда.
Скажем, строгая типизация та же - это же и есть математическая модель предметки, позволяющая проверить ее на непротиворечивость на уровне реализации.
Конечно. Но приведение предметной области к такой типизации, при помощи логики займет меньше времени, чем приведение ее же но при помощи математики.
no subject
no subject
no subject
Ах, вот оно в чём дело.
Подозревал, но не думал, что такое может быть.
Ну, теперь понятно. Дальше смысла объяснять нет.
no subject
no subject
Можно даже сказать что-нибудь эдакое -
Из того, что человек что-то программирует, увы, очень часто следует, что это получается крайне криво. И хотя этого можно избежать, и у некоторых даже получается (!), но получается это очень редко и опыт никогда ну никак не удаётся перенять и поэтому, программирование всегда останется кривым, кривым, кривым...
В известном смысле, конструктивная математика, это то же самое, что и программирование. И на сегодняшний день это далеко не только теория, а очень даже практически развитая вещь.
То, что предметная область и требования существенно лучше ложатся не на функциональные языки, это ерунда. Ну, тут мне что-то сказать сложно, ведь может же получиться, что имеется в виду что-то очень новое и неочевидное, чего я не знаю.
Но если имеется в виду ОО, то это полная чушь, предположительно, вызванная двумя возможными причинами - некомпетентностью и/или желанием потроллить.
Без иронии - надеюсь, что я ошибаюсь.
Крайне редко при наличии достаточных описательных возможностей языка нужно ОО. Даже в OCaml, в котором, на мой взгляд, во многих местах система типов откровенно слабоватая, объекты на практике используются довольно редко, да и далеко "не по полной программе". И уж точно, в Haskell привнесение объектов (был такой O'Haskell) оказалось совершенно никому не нужным. А сейчас это сделать уж совсем запросто, если кому-то будет надо, только не нужно это никому.
> имеется моделирование математикой, которая
> хорошо может быть заменена выделением сущностей
> и описанием их взаимодействия.
Это всё равно, как увидеть хуёвый дизайн (пусть даже на любимом ОО-языке), сказать, что это никуда не годится, и переписать на ассемблере, "заменяя выделением сущностей и описанием их взаимодействия".
Математический дизайн тоже бывает плохой! Использование математики, к сожалению, не означает автоматической корректности и удобства работы. Разумеется, первым фактором, влияющим на некую "близость к серебрянной пуле", как и прежде, в первую очередь, остаётся квалификация человека.
Математика даёт возможность ограничить очень много, чего. И затем не допустить многих обшибок, например, по невнимательности или по незнанию (типаа давно писал код, забыл).
Теоретически, есть возможность избежать _всех_ ошибок, сделав полное совпадение с формально описанной спецификацией. Но реально, пока что, это делается довольно редко. Естественно, только потому, что это довольно трудоёмко, но и тут ситуация вполне конкретно переламывается, кстати.
Если найду, покажу измерения в человеко-часах, которые ушли на построение формально верифицированного компилятора C, проект называется Compcert.
Вкратце, даже полностью верифицированная хрень по человеко-часам не очень намного превышала просто хорошо написанный и хорошо оттестированный сишный компилятор. Но у них-то корректность _доказана_, а не протестирована!
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Если матмодель описать это еще куда ни шло, то написать техническую документацию для будущих разработчиков практически невозможно, тогда софт не будет написан никогда.
no subject