Язык программирования для Backend

Здравствуйте.
Халивар неизбежен, однако, мне следует задать этот вопрос.
Что сейчас лучше использовать для Backend?
Конкретнее:
1) Из того, что востребовано;
2) Из того, с чем будет проще разработка крупных проектов, включая разработку API;
3) Не JS.
Прошу конкретизировать вашу позицию.
Всем спасибо!

0

Сообщение от Fulcrum_013 Да то ваши бредни и не более того. Такие взаимосвязи встречаются вооще на каждом шагу и даже внутри как самого гуя так и инженерной и научной логики а не каких то ваших финтифлюшек. И разворачивать их вам никто не даст. Все растет от того где нужна композиция а где агрегация. И переворачивать их нельзя в принципе - нарушатся принципы взаимосвязи в предметной области. А чаще всего оно вообще все двунаправленное.

Мои бредни или вы просто не знаете как на самом деле всё делается? А уже как следствие из этого вы всяких "зомбаков" и видите в коде? Вы уже демонстрировали это в своём примере с байндингом "источника данных" к контролам задом наперёд. И приписали вытекающие из этого последствия не своему рукожопию, а недостаткам языка и GC в частности.

Сообщение от Fulcrum_013 Покажите примеры решения предложенных задач или не звиздите. Не можете - признайте что GC вообще ни на что не годен и полностью уступает как в эффективности так и в средствах автоматики нативным языкам с ручным управлением памятью. Т.е. факты которые давно всем известны кроме безграмотных свидетелей GC.

Звездите здесь только вы. Давайте доказывайте правоту своих наездов кодом. Покажите нерабоспособность GC или как Dispose уничтожает объект. Не пытайтесь увельнуть. Подкрепляйте доказательствами свои заявы. Это не я должен ваши слова доказывать, а вы сами. Код где?

Сообщение от Curry Идеализируете. На каком языке и с помощью каких либ сделает что конечный исполнитель-программист им до фени. И выбор языка и пр. происходит и/или программистами, или их начальниками, или чуть выше - менеджерами среднего звена. И я сильно сомневаюсь что они оптимально выбирают. У кого на чём больше опыта, личные предпочтения, тем более что выбор языка на себестоимость мало скажется (если только не брейф.. выберут), по сравнением с проработкой предоставляемых сервисом возможностей (то есть "что сделать" много важнее чем "на чём"), или, например, стратегии продвижения на рынке.

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

Сообщение от Curry Насчёт GC. Я не утверждаю что на языках с GC нельзя написать то же что на языках без GC (за исключением скорости/времени отклика). Однако, он чаще усложняет код.

Вы лично в своей практике такое усложнение наблюдали? Или это умозрительные эксперименты?

0

Сообщение от Usaga Мои бредни или вы просто не знаете как на самом деле всё делается?

Да то вы не знаете как все делается на самом деле, и даже под капотом библиотек реализовывающих работу ваших CURD-хеллоувердов.

Сообщение от Usaga А уже как следствие из этого вы всяких "зомбаков" и видите в коде?

Это следствие неспособности GC корректно обрабатывать слабые ссылки, которое явлется неспособностью к инстантной реакции. Идите учите матчасть .

Добавлено через 3 минуты

Сообщение от Usaga Вы уже демонстрировали это в своём примере с байндингом "источника данных" к контролам задом наперёд.

А кто вам сказал что у вас не задом наперед и источник не может быть удален раньше получателей? От переворота зомбаки просто поменяют сторону своего появления и не более того. А особенно это касается наиболее распространенной ситуации когда связь в обоих направлениях мягкая. Т.е. взаимная агрегация объектов.

Добавлено через 26 секунд

Сообщение от Usaga А на управляемых языках она ниже.

НА управляемых языках она выше в сотни раз.

Добавлено через 54 секунды

Сообщение от Usaga Потому, что проще с таким языком работать во всех смыслах. А оверхед практически не имеет значения.

Потому что они не имеют средств автоматики необходимой для имплементации правил взаимосвязей в ООП.

Добавлено через 1 минуту

Сообщение от Usaga Покажите нерабоспособность GC или как Dispose уничтожает объект.

Вам показано что для ООП и управления ресурсами GC абсолютно бесполезен и ничем не превосходит полное отсутсвие автоматики.

Добавлено через 2 минуты

Сообщение от Usaga или как Dispose уничтожает объект

Для начала освойте термин "логическое уничтожение объекта" и научитесь отличать объект от буфера. А то как бы вам уже кучу раз показано что Dispose именно это и делает и то что деструктор не делает ничего кроме этого, а вы это понять не в состоянии.

0

Сообщение от Fulcrum_013 Ну вот как раз это и есть несоответсвием модели вычислений вычислителю.

Это схоластика. А вот разделение кода на чистые и не чистые функции - грамотное проектирование. Чистые функции можно отлаживать и тестировать независимо, можно их мемоизировать. Если компилятор знает что функции чистые, то он может лучше оптимизировать вызывающих их код.

Сообщение от Fulcrum_013 код только с рекурсией гораздо более громоздкий и запутанный чем с циклами особенно при наличии ветвления в теле цикла.

Нет. При чём тут ветвления? Они не мешают.

Сообщение от Fulcrum_013 введение только одного императивного элемента - if constexpr уже позволило сократить код в десятки раз

Вы даже думаете что if-ы не используются в ФП? ФП не при чём если ранее в плюсах чего то не было, а потом добавили.

Сообщение от Fulcrum_013 Т.е. не должно быть никаких состояний изменяемых во времени.

Вы вообразили себе какое то своё "ФП". В ФП не должно быть глобального состояния. Вообще глобальные переменные - зло. Не только в ФП.

Сообщение от Fulcrum_013 Вопрос в том что только чистых функций в принципе недостаточно.

К чему было писать трюизм? Далее у вас опять рассуждения про вами выдуманное "ФП".

Сообщение от Fulcrum_013 сводит всю кажущуюся потенциальную эффективность ленивых вычислений в минус.

ФП - это не обязательно ленивые вычисления. Эффективность ленивых вычислений проявляется не всегда, а только на некоторых задачах.

Сообщение от Usaga Другой важный параметр - стоимость разработки. А на управляемых языках она ниже.

У вас есть доказательство, с цифрами?

Сообщение от Usaga Вы лично в своей практике такое усложнение наблюдали?

Разумеется. Если нужно руками делать освобождение неуправляемых ресурсов то это усложнение.
Приводить в пример WinForms,WPF не стоит. Используемые ими ресурсы освобождаются библиотечным кодом по событиям закрытия окон и подобным. Но если мы сами организуем работу с ресурсами, то сами и должны их освобождать.
Я не утверждаю что программисты на GC языках от этого страдают как в аду, но это усложнение.
Для примера, если на С++ нужно сделать окно, которое, пока оно существует, должно подавлять скринсейвер, то в класс окна можно просто добавить переменную 1 раз написанного класса. И всё.

0

Сообщение от Curry У вас есть доказательство, с цифрами?

Я исследований не проводил. Мне доводилось вести любительскую разработку на Си и С++. А теперь я профессионально занимаюсь C#. И я сравниваю "удобство" разработки между плюсами и шарпом. Небо и земля. Заголовочные файлы, сборка всех необходимых зависимостей и их зависимостей из исходников, системы сборки, линковка... Ничего из этого просто несуществует в управляемых языках. Этого просто нет. Зато есть рефлексия, дающая нам самые разные бесплатные ништяки в виде ORM и автомапперов, здоровенная BCL напичканная функционалом на все случаи жизни, пакетные менеджеры позволяющие играючи подключать к проекту библиотеки без необходимости сборки...

Тут не нужны никакие исследования. Просто попробуйте сами.

Сообщение от Curry Разумеется. Если нужно руками делать освобождение неуправляемых ресурсов то это усложнение. Приводить в пример WinForms,WPF не стоит. Используемые ими ресурсы освобождаются библиотечным кодом по событиям закрытия окон и подобным. Но если мы сами организуем работу с ресурсами, то сами и должны их освобождать. Я не утверждаю что программисты на GC языках от этого страдают как в аду, но это усложнение. Для примера, если на С++ нужно сделать окно, которое, пока оно существует, должно подавлять скринсейвер, то в класс окна можно просто добавить переменную 1 раз написанного класса. И всё.

Иными словами это только домыслы и на практике вы с такими неудобствами не сталкивались?

Добавлено через 8 минут

Сообщение от Fulcrum_013 Да то вы не знаете как все делается на самом деле, и даже под капотом библиотек реализовывающих работу ваших CURD-хеллоувердов.

Да-да-да. Иначе и быть не может.

Сообщение от Fulcrum_013 Это следствие неспособности GC корректно обрабатывать слабые ссылки, которое явлется неспособностью к инстантной реакции. Идите учите матчасть .

Нет, это - следствие лично вашего говнокода и неспособности родить нормальный код.

Сообщение от Fulcrum_013 А кто вам сказал что у вас не задом наперед и источник не может быть удален раньше получателей? От переворота зомбаки просто поменяют сторону своего появления и не более того. А особенно это касается наиболее распространенной ситуации когда связь в обоих направлениях мягкая. Т.е. взаимная агрегация объектов.

Задом наперёд - это когда бизнес-логика зависит от UI, чего быть не должно. Модель приложения определяется типом проекта, да? Источник данных может быть удалён раньше. Это ради бога. Но это не значит, что UI должен на этот источник ссылаться напряммую. Так только индусы делают.

Сообщение от Fulcrum_013 НА управляемых языках она выше в сотни раз.

Аргументируйте. Поделитесь своим опытом в использовании языков, которые вы в глаза не видели.

Сообщение от Fulcrum_013 Вам показано что для ООП и управления ресурсами GC абсолютно бесполезен и ничем не превосходит полное отсутсвие автоматики.

Вы ничего не показали. Только говнокод свой, который после незначительных правок начинал работать.

Сообщение от Fulcrum_013 Для начала освойте термин "логическое уничтожение объекта" и научитесь отличать объект от буфера. А то как бы вам уже кучу раз показано что Dispose именно это и делает и то что деструктор не делает ничего кроме этого, а вы это понять не в состоянии.

Dispose не делает ничего такого, чего не сделал бы метод Close или Deinitialize. Объект всё равно остаётся целым и невридимым. Объект - структура в памяти. Dispose её не разрушает. Поэтому завязывайте уже орать об этом методе на каждом шагу.

0

Сообщение от Usaga Dispose не делает ничего такого, чего не сделал бы метод Close или Deinitialize.

ДЕструктор тоже ничего такого не делает.

Сообщение от Usaga Объект всё равно остаётся целым и невридимым.

Объект - структура в памяти. Dispose её не разрушает. Поэтому завязывайте уже орать об этом методе на каждом шагу.[/quote]
Еще раз - осильте в конце концов что подразумевается под термином "логическое уничтожение объекта". К технической работоспособности обломков в буфере это не имеет ни малейшего отношения. Еще раз идите учите матчасть.

0

Сообщение от Usaga И я сравниваю "удобство" разработки между плюсами и шарпом.

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

Сообщение от Usaga на практике вы с такими неудобствами не сталкивались?

Сталкивался. На java, js и Haskell, как минимум.

0

Сообщение от Usaga Вы ничего не показали. Только говнокод свой, который после незначительных правок начинал работать.

Еще раз вам все показано. Вы кроме пустых слов ничего возразить не смогли.
Еще раз для самых одаренных:
вы так ине представили ни кода ни каких либо алгоритмических обоснований тех ситуаций которые GC разрулить не способен.
А именно:
- Автоматическое слежение за жизненным циклом объектов (своевременное высвобождение ресурсов и т.д. при выходе прямо или коственно владеющего объекта из скопа).
- Корректная работа слабых ссылок (т.е. агрегация).
- Обеспечение двойной/сложной композиции.

Т.е. ничего из того что нужно для ООП или управления ресурсами GC не умеет в принципе. И ничего подобного вы в принципе предоставить не сможете.

Примеры же работы автоматики нативных языков с этими вопросами вам показывали, при том что ими забиты все учебники и интернеты под завязку.
Т.е. по факту - GC не пердназначен для управления жизненным циклом и как следствие не достаточен,абсолютно бесполезен и неэфективен для ООП языка. Достаточной и эффективной является автоматика нативных языков, которая проектировалась для управления именно жизненным циклом объектов.

Добавлено через 4 минуты

Сообщение от Curry а только следствие того, что развивают языки с GC.

Ага. путем таки перетаскивания обрубков смартов в ядро языка. А потом всякие безграмотные Usaga пытаются выдать это за работу GC. При этом они даже не в состоянии понять какие неудобства влечет интеграция этих дел делающих GC ненужным от слова совсем в ядро, а не использование их как библиотечных средств. А на самом деле все просто - если шарп до ума довести плюсы получатся.

Добавлено через 16 секунд

Сообщение от Curry а только следствие того, что развивают языки с GC.

Ага. путем таки перетаскивания обрубков смартов в ядро языка. А потом всякие безграмотные Usaga пытаются выдать это за работу GC. При этом они даже не в состоянии понять какие неудобства влечет интеграция этих дел делающих GC ненужным от слова совсем в ядро, а не использование их как библиотечных средств. А на самом деле все просто - если шарп до ума довести плюсы получатся.

0

Сообщение от Usaga Мне доводилось вести любительскую разработку на Си

А на каком именно С++? Какая IDE ? Какая версия стандарта языка? Я, признаюсь, сейчас почти не пишу на С++ уже много лет, сам "плыву" в его новых "наворотах". Читал про них, и даже задачки решал, но без практики оно забывается. С++ тоже развивается, и само собой IDE.

0

Сообщение от Usaga Мне доводилось вести любительскую разработку на Си и С++.

Профессиональную попробуйте. Ото реально небо и земля.

Сообщение от Usaga А теперь я профессионально занимаюсь C#.

Не занимаетесь. А если и занимаетесь то ни разу не профессиональной. У вас абсолютно недостаточная для профессиональной разработки квалификация.

Добавлено через 1 минуту

Сообщение от Usaga пакетные менеджеры позволяющие играючи подключать к проекту библиотеки без необходимости сборки...

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

Добавлено через 54 секунды

Сообщение от Usaga Ничего из этого просто несуществует в управляемых языках

Еще как существует. Только делается поставщиком фреймверка. Точно так же как и с искоробочными нативными фрейймверками.

Добавлено через 58 секунд

Сообщение от Usaga Зато есть рефлексия, дающая нам самые разные бесплатные ништяки в виде ORM и автомапперов

Ну возьмите себе плюсы с рефлексией. Такие расширения существуют как минимум с середины 90-х.

Добавлено через 56 секунд

Сообщение от Usaga здоровенная BCL напичканная функционалом на все случаи жизни,

Ну так и давайте тогда фреймверками искоробочными мерятся а не фичами языков. И тут вы сливаете по полной и окончательно. все что под шарп - это куций обрубок дельфовых либ.

0

Fulcrum_013, я и не знаю стоит ли дальше вести с вами дискуссию. Бред из палаты комментировать даже не хочется. У вас нет аргументов по поводу сказанного и вы пытаетесь "отлаяться" шапкозакидательством выдавая больной бред за аргументацию по сути. А по сути вы не сказали ничего кроме того что язык шаблонов -- функциональный. Может еще парочку раз повторите и мы все дружно признаем вашу правоту без каких-либо доказательств? Вобщем, беседа с вами -- пустая трата времени.

0

zeroalef, Или просто не в состоянии осилить аргументы? Для этого нужно понимать суть чистого ФП, а не судить о нем по мизерной домеси элементов ФП к жаба-скрипту или другому в исходе полностью императивному языку. Тем кто суть ФП понимает возразить против этих аргументов нечего.

0

Сообщение от Fulcrum_013 Тем кто суть ФП понимает возразить против этих аргументов нечего.

Каких аргументов? Вы говорите что владение и заимствование в rust -- это оверхед.
Я вам, неучу, объясняю что это время компиляции и оверхед не может вызывать просто по определению. На что вы отмалчиваетесь. Где аргументы?
Я вам, неучу, замечаю что язык шаблонов в c++ -- это просто реализация техники. Да -- это отдельный язык, да тьюринг полный, и нет -- не функциональный. Вы привели критерии того что язык шаблонов функциональный? Нет не привели, а просто повторили заветную мантру. Где аргументы?
Я вам, неучу, разложил по полочкам почему нельзя сравнивать лямбда исчисление (вы вообще хотть что-то о нем знаете?) и тьюринг машину. Что же вы мне в ответ? Что наличие циклов -- критерий определения функциональности языка. Про рекурсию и TCO не, не слышал. Все живете в 20м веке и считаете что каждый рекурсивный вызов кладется на стек. А просто допустить мысль что циклы записываются в иной форме чем while/for не? Не сообразили?. Вы давно и психиатра обследовались? По-моему, самое время.

0

Сообщение от zeroalef и нет -- не функциональный

И какой же он по вашему?

Добавлено через 22 минуты

Сообщение от zeroalef Что наличие циклов -- критерий определения функциональности языка.

Я вам вообще то про полноту по Тьюрингу говорил а не про что то еще. А про то что это критерий функциональности уже вы придумали. Так что не передергивайте.

Сообщение от zeroalef Я вам, неучу, разложил по полочкам почему нельзя сравнивать лямбда исчисление (вы вообще хотть что-то о нем знаете?) и тьюринг машину.

Что и где вы разложили? Если бы что то разложили то прекрасно бы понимали почему модель ФП не соответствует математической модели вычислителя на которой выполняются вычисления и какие возможности вычислителя оно принципиально теряет.

Добавлено через 1 минуту

Сообщение от zeroalef Все живете в 20м веке и считаете что каждый рекурсивный вызов кладется на стек.

А вот прикиньте таки кладется для всего кроме хвостовой рекурсии. Потому как то что не преобразовывется в цикл без существенных ограничений на глубину рекурсии не инлайнится. Ни в 19-ом веке ни в 29-ом.

Добавлено через 1 минуту

Сообщение от zeroalef Вы привели критерии того что язык шаблонов функциональный?

Именно функциональный потому что инстанциирование шаблонов сводится к виду a(b(c(d...)))

Добавлено через 56 минут

Сообщение от zeroalef Я вам, неучу, объясняю что это время компиляции и оверхед не может вызывать просто по определению. На что вы отмалчиваетесь. Где аргументы?

Не будет это работать только в компайлтайме без существенных ограничений. К примеру без запрета долгоживущим объектам ссылаться друг на друга. А с такими ограничениями от него никакой пользы кроме вреда.

0

zeroalef,
Ну дак раскладка чем ФП от машины Тюринга отличается будет или мне вам это разложить?
А отличается оно простым фактом. При помощи автомата состояний коим является машина Тюринга ( так же как и эквивалентная ей машина Поста), а соответсвенно и любая программа для нее, вычисление функции описать можно - результат является побочным эффектом работы автомата. А вот при помощи функции автомат описать нельзя, при ее помощи можно описать только переход автомата из одного состояния в другое.
Надеюсь дальше не надо разжевывать почему ФП - болото?

0

Сообщение от Curry Оно же не GC определяется, а множеством других отличий. Перечисляемые вами отличия или существуют в плюсах, или те же возможности реализованы по другому, или их отсутствие не следствие GC, а только следствие того, что развивают языки с GC. Разбирать по отдельности всё что вы привели пока не буду.

Так я это всё как следствие GC и не преподносил. Может выразился как-то не так, что вы меня иначе поняли. Это всё аргументы в пользу управляемых языков в целом. С точки зрения опыта работы с С++ и не более того.

Сообщение от Curry А на каком именно С++? Какая IDE ? Какая версия стандарта языка? Я, признаюсь, сейчас почти не пишу на С++ уже много лет, сам "плыву" в его новых "наворотах". Читал про них, и даже задачки решал, но без практики оно забывается. С++ тоже развивается, и само собой IDE.

С++11, Eclipse. Участвовал в одном Open Source проекте как волонтёр-любитель. Это было давно. Сам язык мне вполне нравится. А вот, что бесило - архаичность тулкита выливавшаяся в ненужной, на мой взгляд, лишней работе, которая отнимала время.

Скачать исходники всех зависимостей и их зависимостей. Собрать всё это (у завивимостей могут быть разные системы сборки), сконфигурировать систему сборки, чтобы знала, что где лежит, попробовать собрать, слинковать. Присмотреться к варнингам, вдруг какую зависимость не под ту архитектуру собрал. Не забыть про всякие VSC++ Redistributable или аналогичные вещи.

А теперь качните какой-нибудь проект на том же шарпе с github. dotnet build или Ctrl+Shift+B в студии и... ВСЁ! Вы можете работать. Согласитесь, что какие-то там незначительные оверхеды на управляемую природу языка на этом фоне просто ничто. Их тупо нет.

0

Сообщение от Usaga А вот, что бесило - архаичность тулкита

То есть бесило отсутствие пакетного менеджера со своим репозиторием.
В том же nuget-е есть пакеты для С++, хотя их мало, оно и понятно, MS продвигает .NET. В cppbuilder/Delphi есть GetIt - вот, на этом форуме тоже упоминается. Установка AsyncPro .
Для Qt есть свой пакетный менеджер.

Сообщение от Usaga Согласитесь, что какие-то там незначительные оверхеды на управляемую природу языка на этом фоне просто ничто.

Не нужно смешивать королей и капусту. Наличие множества пакетов в централизованном репозитории MS для .NET никак не следствие природы управляемого языка. Это следствие того, что MS монополист в предоставлении компилятора C# и средства разработки. По этому все разработчики в один репозиторий и валят. В данном случае монополия идёт на пользу.
То есть это

Сообщение от Curry только следствие того, что развивают языки с GC.

Развивало бы MS С++, было бы больше пакетов для него в nuget-е. От самих языков это не зависит.

0

Сообщение от Curry В cppbuilder/Delphi есть GetIt - вот, на этом форуме тоже упоминается.

Это только в рамках CppBuilder\Delphi. А пользователи голого GCC\LVVM что?

Сообщение от Curry Для Qt есть свой пакетный менеджер.

Судя по всему, там чисто компоненты для Qt. Т.е. оно не общего назначения.

Сообщение от Curry Не нужно смешивать королей и капусту. Наличие множества пакетов в централизованном репозитории MS для .NET никак не следствие природы управляемого языка. Это следствие того, что MS монополист в предоставлении компилятора C# и средства разработки. По этому все разработчики в один репозиторий и валят. В данном случае монополия идёт на пользу.

Наличие менеджера пакетов как раз следствие управляемой природы языка. Вы видели как руками ссылка на библиотеку добавляется? Один ключ и путь к DLL. И то за вас пакетным менеджером сотворяется. Почему так просто в сравнении с DLL на Си\С++? Потому, что все метаданные уже зашиты в DLL и никакой дополнительной информации в виде *.H файлов, OBJ-файлов и линкований не надо. Но это только один из плюсов. Другие я тоже упоминал.

Сообщение от Curry Развивало бы MS С++, было бы больше пакетов для него в nuget-е. От самих языков это не зависит.

Зависит. Сам С++ не позволяет всё так просто организовать. Иначе давно бы уже прикрутили подобное и не парились бы. Все были бы в плюсе. В плюс плюсе.

0

Сообщение от Usaga А пользователи голого GCC\LVVM что?

Ну как всегда с опенсорсом и профразработкой. При этом первый компилятор который начал через LLVM компилить таки BCB64.

Добавлено через 4 минуты

Сообщение от Usaga Зависит. Сам С++ не позволяет всё так просто организовать. Иначе давно бы уже прикрутили подобное и не парились бы. Все были бы в плюсе. В плюс плюсе.

Зато сверхвысокоуровневые абстракции позволяет бесплатно. Именно для этого шаблоны должны жить в хидерах.
А так же за счет хидеров позволяет то чего в принципе низя в языках с пакетами/модулями. А именно иметь набор разных реализаций под одну спецификацию модуля/либы. Так же как и набор разных спецификаций экспорта под одну либу/модуль.
Т.е. в плюсах все именно так как надо для профессиональной промышленной разработки, в отличии от паскакалей шарпов и прочей ереси.

Добавлено через 6 минут

Сообщение от Usaga Это только в рамках CppBuilder\Delphi.

А в шарпе таже самая RTTI заточенная под задачи его искоробочного фреймверка, а не общего назначения. Для общего назначения ее формат дожен быть управляем программистом. При этом покоцано все по самые немогу. Бинарный сериализатор в шарпе не умеет с RTTI работать от слова совсем, в отличии от дельфового/билдеровского для которого бинарный формат основной. Не забывайте что обрубки визуального фреймверка, и как следствие культи ножек и ручек для его поддержки, у шарпа именно из Дельфы растут.

Добавлено через 2 минуты

Сообщение от Curry ФП - это не обязательно ленивые вычисления. Эффективность ленивых вычислений проявляется не всегда, а только на некоторых задачах.

Ну там где она проявляется она прекрасно проявляется и в иперативных языках. А во всем остальном ФП - болото.

Добавлено через 5 минут

Сообщение от Curry Развивало бы MS С++, было бы больше пакетов для него в nuget-е. От самих языков это не зависит.

Оно его развивает для собственных внутренних нужд и очень круто развивает. А помойки либ под плюсы и так давно больше чем разумно. Даже при том что на плюсах пишут в основном люди которые прекрасно понимают что применимость той или иной либы в рамках конкретной задачи нужно сначала математически доказывать. Только вот репозитарии по всем интернетам раскиданы потому как в одном месте собраны быть не могут по причине что слишком уж популярный язык как у профи так и у разрабов компиляторов и осей всяких разных.

0

Fulcrum_013, что вы несёте? У вас обострение? Как всё это связано с обсуждаемым выше?

Сообщение от Fulcrum_013 Бинарный сериализатор в шарпе не умеет с RTTI работать от слова совсем

Разве? Показать можете пример?

0

Сообщение от Usaga Разве? Показать можете пример?

Мануал откройте и прочитайте. Там это англицким по белому написано. В бинарку по полям не сериализирует. Только в XML. А в бинарку только буфером аки есть а не по свойствам.

0