ful != full, это разные вещи. Посмотри на lawful или truthful, careful - скорее просто образуется прилагательное, без дополнительного смысла полноты

Давай поспорим насчёт того, какой из подходов в общем случае лучше, декларативный или процедурный, а потом посмотрим, какой язык какой подход поощряет

декларативный.

Поощряют одинаково

Впервые слышу, возможно, недавно появились

недавно

Они равнозначны. Однозначно хуже только отсутствие ссылочной прозрачности.

А с этим плохо и в фарше и в шарпе

Ну, не согласен. Как раз со смыслом не “полноты”, но “присутсвия”. Да и забей, я не спорю, так ковыряюсь в буквах просто)

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

Тебе ничто не мешает иметь ООП с ссылочной прозрачностью

ООП и ФП друг другу не противоречат

Но речь о том, какой язык чему поощряет

И ооп можно в обоих языках делать

Оба плохо поощаряют ссылочную прозрачность, потому что не имеют в системе типов инструментов, которые позволяют эргономично использовать ссылочно прозрачный стиль в коде

Чтобы писать в ссылочно прозрачном стиле и не страдать - нужен набор инструментов, которых нет ни в F#, ни в C#.

Потому что они оба находятся в рамках дико ограниченной системы типов CLR

Ну как "хреновых". Они часто размытые очень. Хотя формально лицензия вроде как неотзывная, на самом деле в таких формулировках на практике судья может решить аннулировать лицензию, вернув автору копирайт.

> The “source code” for a work means the preferred form of the work for making modifications to it.
> A “covered work” means either the unmodified Program or a work based on the Program.
> A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.

Очень обтекаемо. Кому именно "preferred"? Где заканчиваются границы covered? Где заканчиваются границы Standard Interface?

Например, кто-то написал код на C++ под GPL, я его взял, взял код CPP-TO-PYTHON транслятора, поместил их вместе в одну работу. Это производная работа? Да, значит она тоже должна быть под GPL. Ок, она под GPL. Я беру эту новую программу, запускаю её. Она в качестве результата выдаёт мне Python код, который просто является трансляцией исходного C++ кода.

Является ли эта трансляция "source code"? В бытовом смысле нет. В юридическом смысле неопределено(лицензия этого толком не объясняет тоже).

Является ли она "covered work", то есть работой, основанной на исходной программе, или это просто случай использования программы, как её "Standard Interface"? В последнем случае полученная работа не попадает под GPL по тексту самой лицензии.

Есть контроль на уровне типов. Он самый строгий, особенно если соблюдается и для сигнатур. Но вопрос не в том стоит. Вопрос в том, что сеттер может изменить левое поле, о котором никто и не подозревал, и это общепринятая практика, а пачкание функций общепринятой практикой не является.

вроде как в компиляторе гцц написано, что скомпилированніе им программі — продукт использование и не подлежат гпл

Смотри, чтобы писать в ссылочно прозрачном стиле - тебе нужен хорошо работающий IO тип.

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

Другими словами, если ты можешь сделать static mut и изменять его с гонкой данных, это ещё не значит, что ты должен, или что так советуют делать, или что это не будет видно в коде