![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassЧтобы ИТ-индустрия окончательно встала раком, Гуглу сейчас нужно сделать ход конем - разработать ТРЕТИЙ вариант кроссплатформенного языка-платформы с собственной виртуальной машиной, JIT, итд, итп, в дополнение к жабе и дотнету. И сманить девелоперов на него какими-нибудь заманухами страшными.
Тем более что дотнет семимильными шагами двигается в ту же over-engineered сраку, что и жаба, а альтернативы реальной тому и другому и нету.
Тем более что дотнет семимильными шагами двигается в ту же over-engineered сраку, что и жаба, а альтернативы реальной тому и другому и нету.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-08-15 05:10 am (UTC)no subject
Date: 2010-08-15 05:43 am (UTC)Скажем, строгая типизация та же - это же и есть математическая модель предметки, позволяющая проверить ее на непротиворечивость на уровне реализации.
no subject
Date: 2010-08-15 05:48 am (UTC)Так как раз проблемы в проектировании системы обычно всплывают в мелочах и подсистемах. Т.е. если разбить на подсистемы и спроектировать наиболее неадекватные куски используя строго теоретические модели - мы уже спасемся от части маразма
Только это займет много времени и часто будет шибко громоздко. Матан оно конечно хорошо, но далеко не всегда.
Скажем, строгая типизация та же - это же и есть математическая модель предметки, позволяющая проверить ее на непротиворечивость на уровне реализации.
Конечно. Но приведение предметной области к такой типизации, при помощи логики займет меньше времени, чем приведение ее же но при помощи математики.
no subject
Date: 2010-08-15 05:51 am (UTC)no subject
Date: 2010-08-15 05:56 am (UTC)no subject
Date: 2010-08-15 06:34 am (UTC)Ах, вот оно в чём дело.
Подозревал, но не думал, что такое может быть.
Ну, теперь понятно. Дальше смысла объяснять нет.
no subject
Date: 2010-08-15 04:53 pm (UTC)no subject
Date: 2010-08-15 06:29 am (UTC)Можно даже сказать что-нибудь эдакое -
Из того, что человек что-то программирует, увы, очень часто следует, что это получается крайне криво. И хотя этого можно избежать, и у некоторых даже получается (!), но получается это очень редко и опыт никогда ну никак не удаётся перенять и поэтому, программирование всегда останется кривым, кривым, кривым...
В известном смысле, конструктивная математика, это то же самое, что и программирование. И на сегодняшний день это далеко не только теория, а очень даже практически развитая вещь.
То, что предметная область и требования существенно лучше ложатся не на функциональные языки, это ерунда. Ну, тут мне что-то сказать сложно, ведь может же получиться, что имеется в виду что-то очень новое и неочевидное, чего я не знаю.
Но если имеется в виду ОО, то это полная чушь, предположительно, вызванная двумя возможными причинами - некомпетентностью и/или желанием потроллить.
Без иронии - надеюсь, что я ошибаюсь.
Крайне редко при наличии достаточных описательных возможностей языка нужно ОО. Даже в OCaml, в котором, на мой взгляд, во многих местах система типов откровенно слабоватая, объекты на практике используются довольно редко, да и далеко "не по полной программе". И уж точно, в Haskell привнесение объектов (был такой O'Haskell) оказалось совершенно никому не нужным. А сейчас это сделать уж совсем запросто, если кому-то будет надо, только не нужно это никому.
> имеется моделирование математикой, которая
> хорошо может быть заменена выделением сущностей
> и описанием их взаимодействия.
Это всё равно, как увидеть хуёвый дизайн (пусть даже на любимом ОО-языке), сказать, что это никуда не годится, и переписать на ассемблере, "заменяя выделением сущностей и описанием их взаимодействия".
Математический дизайн тоже бывает плохой! Использование математики, к сожалению, не означает автоматической корректности и удобства работы. Разумеется, первым фактором, влияющим на некую "близость к серебрянной пуле", как и прежде, в первую очередь, остаётся квалификация человека.
Математика даёт возможность ограничить очень много, чего. И затем не допустить многих обшибок, например, по невнимательности или по незнанию (типаа давно писал код, забыл).
Теоретически, есть возможность избежать _всех_ ошибок, сделав полное совпадение с формально описанной спецификацией. Но реально, пока что, это делается довольно редко. Естественно, только потому, что это довольно трудоёмко, но и тут ситуация вполне конкретно переламывается, кстати.
Если найду, покажу измерения в человеко-часах, которые ушли на построение формально верифицированного компилятора C, проект называется Compcert.
Вкратце, даже полностью верифицированная хрень по человеко-часам не очень намного превышала просто хорошо написанный и хорошо оттестированный сишный компилятор. Но у них-то корректность _доказана_, а не протестирована!
no subject
Date: 2010-08-15 06:57 am (UTC)no subject
Date: 2010-08-15 07:01 am (UTC)no subject
Date: 2010-08-15 07:11 am (UTC)no subject
Date: 2010-08-15 07:25 am (UTC)no subject
Date: 2010-08-15 07:30 am (UTC)no subject
Date: 2010-08-15 07:03 am (UTC)no subject
Date: 2010-08-15 07:12 am (UTC)no subject
Date: 2010-08-15 07:26 am (UTC)Если матмодель описать это еще куда ни шло, то написать техническую документацию для будущих разработчиков практически невозможно, тогда софт не будет написан никогда.
no subject
Date: 2010-08-15 07:29 am (UTC)