C# vs Kotlin

Привет всем!

Java c C# уже сравнивали несколько раз. А как насчёт улучшенного (а может кто то считает "улучшенного") варианта java - языка Kotlin?

0

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

Да нет. Быдлокодинг это когда приходится постоянно рефакторить, а это делают практически все те, кто кодит по учебникам. Учебники учат всегда начинать с обобщённых абстракций, так они и делают: сразу пишут класс "автомобиль". Всё по учебнику.. От этого класса они наследуют класс "мотор", класс "багажник, класс "дверь", "колесо" и т.д. Быдлокодинг это по учебнику.. Но тут вдруг надо обеспечить функционал такой сущности, как " паровоз" и наши быдлокодеры начинают переписывать класс "автомобиль" в класс "транспортное средство", а от него уже наследовать класс автомобиль, паровоз.. Стоп, а как же с дверями, колёсами и багажником? Они же были в классе "автомобиль"? Можно продолжать долго это мозго сами знаете что. А программинг не по учебникам начинет не с общих абстракций, а с частных. Например нам надо реализовать вывод геометрических фигур. Быдлокодер по учебнику пишет класс "фигура" и т.д. Нормальный кодер пишет класс "точка". В этом классе будут свойства координат и некоторые методы. От этого класса он наследует класс "линия", "круг", от "линии" - "квадрат" и "треугольник", от треугольника" и "квадрата" класс "треугольнико-квадрат" и т. д. Здесь не нужно боятся множественного наследовани, более того нормальный кодер его приветствует.
Быдлокодер же от "фигуры" наследует фигуры: треугольник, квадрат и т.д. Проблема возникает, когда нужно будет куда-то впихнуть "линию" и "точку". . здесь множественное наследование - зло.
------------
Ну это-то ещё и ничего. Дело всё в том, что функция преобразует один тип данных в другой тип данных. А разные типы данных это разные классы по определению. Прописывая функции в конкретных классах мы тем самым создаём в будущем кучу проблем. Отсюда костыли в виде "дружественных" классов и т. п. Это от того, что сама концепция классификации от общего к частному ложна в своей основе, и то, что методы прописываются в классах вместе с данными, со статикой. Ведь класс это всё же тип данных. Именно ДАННЫХ.
Уберите из классов методы и многое сразу упроститься. Я же не дурак и понимаю что писать someVar[][][][][] крайне неудобно, класс всё это инкапсулирует, и это хорошо. Хорошо передавать целый обьект одним параметром а не писать someVar[][][][][]...
Но, смотрите: я могу это эмулировать причём крайне эффективней через global доступ к обьекту, который представляет из себя не структуру, не структуру структур и т.д., а просто набор переменных под общим суффиксом или префиксом.. Как передать такой обьект одним параметром в функцию? Так он же глобальный, и функция работает с "ним" напрямую..

0

Сообщение от CoderHuligan Быдлокодинг это по учебнику..

Быдлокодинг это без предварительного анализа предметной области, разделения сущностей на абстрактные механизмы взаимодействия и т.д., анализа математики их работы и т.д. и т.п. А то что вы называете "учебниками" на самом деле бульварное чтиво а не учебники. Ни один из них не рекомендован для ВТУЗов а особенно те которые из самой попсовой серии "освой быдлокодинг для чайников за 21 секунду". Их пишут не для того чтобы по ним учились а чтобы бабла срубить с лохов которые их купят.

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

Сообщение от CoderHuligan Отсюда костыли в виде "дружественных" классов и т. п.

Если все правильно это не костыли а сокрытие механизма взаимодействия между двумя классами от внешнего мира. Т.е. чтобы они между собой могли работать и никто в это не мог влезть. К примеру хозяин компонент и раб должны установить двустороннюю связь при создании. При этом хозяин передается аргументом создаваемому рабу. При этом смена хозяина по законам Рейха зпрещена. Логично что хозяина который добавляет раба в свой список рабов не должен иметь возможность вызвать никто кроме самого раба. Соответсвенно метод в приват раб в друзья. Все сыты и довольны.

0

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

Нет) Вы просто своё мнение субъективное выражаете) Вы языком этим вообще не пользовались, так что не можете давать ему оценку)

0

Сообщение от Usaga Нет) Вы просто своё мнение субъективное выражаете) Вы языком этим вообще не пользовались, так что не можете давать ему оценку)

А при чем тут язык? Разговор шел о том что трассирующий GC - худший из возможных способов автоматического управления памятью.
А касательно шарпа как такового - его место на свалке. Потому что до ума его доводить бессмысленно - С++ получится а он уже есть и без доделки кривых поделок.

0

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

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

Сообщение от Fulcrum_013 А касательно шарпа как такового - его место на свалке.

Перечитайте мой пост выше. О ценности мнения о вещи, которую в глаза не видел.

0

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

Так еще бы. Быдлокодеров то в индустрии процентов 80 не меньше. А еффективные маркетеры под сказочки что быдло быдлокодить перестанет и станет круче квалифицированного инженера потому что за них все язык порешает впихнут еффективным менеджерам любое гавно. На подобные сказочки и Пентагон в свое время велся даже без GC.

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

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

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

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

Сообщение от Usaga О ценности мнения о вещи, которую в глаза не видел.

Вы же не считаете к примеру КОБОЛ или PL/1 или АЛГОЛ или даже Симулу годными для современной разработки? Так вы же их тоже в глаза не видели.

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

Сообщение от Usaga Перечитайте мой пост выше.

Да у вас что не пост то быдлокодерское ЧСВ. Вы к примеру даже не в курсе что для того чтобы определить есть в языке нужные средства или нет достаточно с референсом бегло ознакомится. В Шарпе ничего нужного нет в принципе. Свалка самого отстойного гуано из явы и прочего бреда предназначенная для неквалифицированных разрабов и примитивных задач.

0

Сообщение от CoderHuligan Так для общей информации и размышления.

Бугаенко — фанатик, который на вопросы на своих выступлениях, ничего кроме «мне так нравится» обычно не может ответить.

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

Сообщение от Fulcrum_013 Реально существует две концепции ООП - симуловская со статическими сигнатурами объектов (классами) и смалталковская с динамическими (прототипами). Java живет по симуловской концепции а вот JavaScript по смалталковской даже при том что вроде бы как называются почти одинаков.

В SmallTalk используются классы, а не прототипы.

0

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

Прав, как никогда, лол

Миниатюры

   

0

Сообщение от korvin_ Бугаенко — фанатик

Судя по блогу, это не фанатик чего-то конкретного, а человек, который начал "прозревать". Многим это не нравится, поэтому на него столько нападок. Естественно, что человек, который утверждает что можно программировать без классов но с обьектами вызывает недоумение у "правоверных". Вот как раз правоверные и есть фанатики..

0

Сообщение от Fulcrum_013 А вот сделать статическую там где есть только динамическая никак.

Как.

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

Сообщение от CoderHuligan Судя по блогу, это не фанатик чего-то конкретного, а человек, который начал "прозревать".

Ничего он не начал «прозревать», а фанатик он «сферического идеального ООП в вакууме».

Сообщение от CoderHuligan Многим это не нравится, поэтому на него столько нападок.

На него никто не нападает, ему задают простые конкретные вопросы, типа «почему Вы сделали тут так», а он в ответ мямлит что-то вроде «я не знаю, почему я так сделал, просто мне так захотелось».

ЕМНИП, в этом видео подобное было:

Сообщение от CoderHuligan Естественно, что человек, который утверждает что можно программировать без классов но с обьектами вызывает недоумение у "правоверных"

Не это вызывает недоумение.

0

Сообщение от korvin_ а он в ответ мямлит что-то вроде «я не знаю, почему я так сделал, просто мне так захотелось».

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

Сообщение от korvin_ Не это вызывает недоумение.

Потому что ничего не понимают в ООП. Пишут "на ООП" а сами ничего в нём не понимают, хотя убедили сами себя, что понимают, шарят.. А Егор свои выводы делает из чисто практического опыта программинга. Он не теоретик, а практик. Кстати они с командой создают новый язык - "ElegantObjects", если я правильно понял. И его идея, что обьекты должны строится по иерархическому принципу это здравая мысль. Как видим, ООП развивается в лучшую сторону, от прошлых стереотипов к истинному его пониманию. Будем надеется, что всё придёт к правильным решениям.
В этой лекции он задел функциональщиков, поэтому вы так взьелись. Но задел то за дело!

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

Сообщение от korvin_ «сферического идеального ООП в вакууме»

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

0

Сообщение от CoderHuligan Потому что ничего не понимают в ООП. Пишут "на ООП" а сами ничего в нём не понимают, хотя убедили сами себя, что понимают, шарят.. А Егор свои выводы делает из чисто практического опыта программинга. Он не теоретик, а практик.

Ага, прям один единственный практик на всём Земном шаре. Прям д’Артаньян.
Он там в выступлении «ORM — это обидно» ратует за ActiveRecord, видимо, совершенно не зная, что в том же RoR ActiveRecord признан узким местом, мешающим горизонтальной масштабируемости, да и вообще показывает себя низкопроизводительной хренью, непригодную для сколько-нибудь большой нагрузки.

Не менее смешно было, когда он рассказывал про неправильный java.lang.String. Пусть пойдёт расскажет это разработчикам JVM и JDK.

Сообщение от CoderHuligan В этой лекции он задел функциональщиков, поэтому вы так взьелись. Но задел то за дело!

В этой лекции он показал, что совершенно не знает, ни что такое функциональное программирование, ни лисп, а значит все его высказывание на эту тему не более чем газификация луж. А «взъелся» я только из-за нелюбви к фанатикам.

Сообщение от CoderHuligan у него есть здравые идеи. ООП уже давно в болоте квакает, и если не дать ему новую жизнь оно вымрет как мамонт. Но у ООП есть как много неправильных вещей, так и много верных. Просто всё тут смешалось: кони, люди, а от этого смешения все проблемы и вылазят. Он предлагает выход.

Все его «новые идеи» родом из SmallTalk 80-х годов. Открыл Америку, ага.

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

Сообщение от CoderHuligan Кстати они с командой создают новый язык - "ElegantObjects", если я правильно понял.

Потому что они с командой не знают про SmallTalk, Self и Io?

0

Сообщение от korvin_ да и вообще показывает себя низкопроизводительной хренью, непригодную для сколько-нибудь большой нагрузки.

Поэтому и создаёт новый язык. java не справляется из-за ложной нативной реализации.

Сообщение от korvin_ Все его «новые идеи» родом из SmallTalk 80-х годов.

Почему же он их критикует не по децки? Месседжинг на фоне обьектов одного уровня он не приемлет.

Сообщение от korvin_ Потому что они с командой не знают про SmallTalk, Self и Io?

Потому что знают, что так нельзя, и знают как надо(из практики).

0

Сообщение от CoderHuligan Потому что знают, что так нельзя, и знают как надо(из практики).

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

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

Сообщение от CoderHuligan Естественно, что человек, который утверждает что можно программировать без классов но с обьектами вызывает недоумение у "правоверных"

Ну судя по тому что он задвигает у него не объекты будут в результате а замыкания. Это как объекты только для самых бедных. Вот и непонятно зачем если есть как есть? Другое дело что явы и порожденный от нее ширпотреб для самых необразованных чинит всяческие препятствия к реализации оных самоуправляемых иерархий, но это проблемы не ООП как такового, а эффективных менеджеров которым не понятно что неквалифицированный разраб способен максимум на процедурщину, и его продуктивнось ограниченна именно этим фактом. Соответственно и язык прижился в той сфере где менеджеры решили решать вопросы количеством разрабов а не качеством. Да и для CURD оно как бы особо ничего выдумывать и не надо при готовом фреймверке который непосредственное общение с источниками данных выполняет под капотом.
В тех же сферах где вопрос решается исключительно квалификацией разрабов а не количеством все что он задвигает давно забыли как страшный сон.

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

Сообщение от korvin_ Как.

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

0

Сообщение от CoderHuligan Поэтому и создаёт новый язык. java не справляется из-за ложной нативной реализации.

Ха-ха-ха.

Сообщение от CoderHuligan Почему же он их критикует не по децки?

Кого их? Свои идеи?

Сообщение от CoderHuligan Месседжинг на фоне обьектов одного уровня он не приемлет.

Что эта фраза вообще должна означать?

Сообщение от CoderHuligan Потому что знают, что так нельзя, и знают как надо(из практики).

Это их «как надо» 1:1 повторяет SmallTalk/Self/Io. Так как нельзя?

0

Сообщение от CoderHuligan ООП уже давно в болоте квакает, и если не дать ему новую жизнь оно вымрет как мамонт

В болоте как мамонты квакают те кто ООП не осилил. Все те проблемы которые приписывают ООП существуют только у тех кто квакает в болоте. Хотя таких реальное большинство в индустрии. И причина здесь не в ООП а в отсутствии профильного образования и как следствие непонимания задачи в целом, и восприятие парадигмы/языка как какого то магического средства которое сделает разработку софта очень простой задачей. ООП не может сделать реализацию сложной задачи очень простой. Оно при правильном применении к результатам грамотного анализа предметной области позволяет преодолеть эту сложность. Но как раз именно этому учат исключительно в унивирситетах, а не на каких то курсах типа "академия ШАГ" и тем более не в школе на уроках информатики. Вот отсюда и квакание в болоте у 80% мамонтов в индустрии.

0

Сообщение от Fulcrum_013 Отсутствие же механизма шаблонов и перегрузки операторов для обобщенных типов вообще делают их малопригодными для чего либо кроме самых примитивных задач форматирования ввода-вывода. Хотя конечно тюринговской трясиной и не являются, но продуктивность в более-менее сложных задачах от плюсов будет отставать значительно. Эффективность будет отставать везде.

Шаблоны не нужны, если только вы не сторонник Го.

Сообщение от Fulcrum_013 Языком общего назначения он не является, так же как и все из этой троицы.

Конечно является. ОС на нем пишут, драйверы пишут, игры тоже пишут. Про обычный бизнес и говорить не приходится.

Сообщение от Fulcrum_013 Зачем себя ограничивать? Начинайте с С++. Получите достаточно знаний чтобы изучать C#/JAVA/Kotlin стало бы таким же не нужным и бесполезным занятием как изучение к примеру симулы или алгола.

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

Сообщение от Fulcrum_013 Вообще С++ создавался как средство для разработчиков топ-уровня. И таких языковых средств как в плюсах нет больше нигде. Основной же идеей плюсов которая не реализована больше нигде, является отказ в ООП языке от архаичного GC и переход к управляемому автоматическому управлению памятью (смартпоинтерам) которое на порядок гибче и эффективнее GC. Языковые средства которые для этого понадобились и реализованы в плюсах, в других языках отсутствуют напрочь.

С++ изначально всего лишь "Си с классами" - способ таскать функции вместе с данными, и при этом не продолбать производительность. Остальное развитие плюсов - просто натаскивание всего что везде есть в других языках. В итоге имеем, что имеем - неповоротливого монстра, где уже 10 лет не могут согласовать формат модулей.

Сообщение от Fulcrum_013 Констант нету в аргументах шаблонов. При реализации более продвинутых чем искоробочные stl смартпоинтеров (к примеру двунаправленных интрузивных) это резко усложнит жизнь.

Const generics пока нет, это немного осложняет жизнь. Но они скоро будут. И это сильно более мощная концепция, чем константы в темплейтах, к слову. Так что пока нет, но результат стоит того, чтобы подождать.

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

Вы просто не называйте их макросами, если у вас после плюсов начинает трясти от упоминания этого слова. Они сильно ближе к лисповым макросам или там Roslyn анализаторам на шарпе.

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

Потому что плюсовики в случае косяка языка начинают винить разработчика/его руки/его маму, но отказываются смотреть на проблему. В стиле "два раза освободил память - ну ты лашара".

Сообщение от Curry И если полный аналог плюсовых смартпоинтеров там вообще нужен с его ownership/borrowing.

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

Но 99% всех данных иерархичны, так что проблем обычно нет. В остальном случае юзаем смарт поинтеры, как и в плюсах. Только вот только там, где нужно, и за счет Rc/Arc мы еще и можем в однопоточной среде получить их бесплатно (в отличие от тяжеловесного плюсового Arc, который всегда делает интерлок).

Сообщение от Fulcrum_013 Больше похоже на то что просто повод покричать какой он новый и как он круче плюсов. Хотя на самом деле засунули move symantic под капот и думают что чем то круче при убогом всем остальном. На самом деле то что под капот то в большинстве случаев обрезка возможности пользовать что то более другое, более подходящее для конкретной задачи . К примеру управлять семантикой. Например для UI мультипоток (неожиданно) сто лет не нужен, а вот CopyOnWrite Symantic строки гораздо удобнее чем Move Symantic. А в некоторых местах вообще копирование/перемещение должно быть запрещено. К примеру массив указателей на дочерние объекты куда-то дергать вообще противопоказано.

Есть хороший набор в телеграм-канале на эту тему Можно даже пополнить.

Сообщение от Fulcrum_013 Это называется сговнить всю малину. Если я умножаю ускорение на время то в результате должен получить скорость. А вот время на время или скорость на скорость умножаться вообще не должны. Так же к примеру как если вычесть из точки точку должен получится вектор. А если к точке прибавить/вычисть вектор должна получится точка. При этом точка с точкой складываться не должна ни при каком раскладе. Именно такой подход к перегрузке резко подрубает возможности накосячить в формулах. Без этого перегрузка операторов практиечски теряет основной свой смысл - определение алгебры над сущностями предметной области.

Как бэ всегда можно поменять и тип второго операнда, и результат операции, если хочется.

Сообщение от Fulcrum_013 Ну Хейлсберг похоже действительно решил на старости лет проверить сколько говна способны сожрать быдлокодеры при условии что это гавно халявное. Надеюсь понимаете почему Борланд его Майкрософту слили вместе с мертворожденным по заказу Майкрософта C# Builder aka WinForms

Хелсберг давно не имеет отношения к шарпу, так-то.

Сообщение от Fulcrum_013 Языки с GC языками общего назначения не являются по определению.

чему определению?

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

Ага. Например пакетного мендеджера в плюсах так и не появилось, генериков не появилось, тайпклассов не появилось. Только костылить через темплейты остается, печаль однако.

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

Сообщение от Fulcrum_013 В болоте как мамонты квакают те кто ООП не осилил. Все те проблемы которые приписывают ООП существуют только у тех кто квакает в болоте. Хотя таких реальное большинство в индустрии. И причина здесь не в ООП а в отсутствии профильного образования и как следствие непонимания задачи в целом, и восприятие парадигмы/языка как какого то магического средства которое сделает разработку софта очень простой задачей. ООП не может сделать реализацию сложной задачи очень простой. Оно при правильном применении к результатам грамотного анализа предметной области позволяет преодолеть эту сложность. Но как раз именно этому учат исключительно в унивирситетах, а не на каких то курсах типа "академия ШАГ" и тем более не в школе на уроках информатики. Вот отсюда и квакание в болоте у 80% мамонтов в индустрии.

Я правильно понимаю, что ООП это вершина эволюции, ничего лучше не придумывали и никогда уже не придумают? Тайпклассы там не очень получается, например?

Добавлено через 34 секунды
Что касается сабжа, то языки примерно равны, хотя у шарпов рантайм поинтереснее конечно.

А на жвм скала сильно лучше, те же HKT там таки завезли.

1

Сообщение от Psilon Тайпклассы там не очень получается, например?

ТАйплклаасы это костыль для тех кто смотрит на объект как на пассивное хранилище данных а не на активную сущность.

Сообщение от Psilon генериков не появилос

Генерик это кастрированный шаблон. ТАк что это шаблонов нигде кроме плюсов нет.

Сообщение от Psilon чему определению?

Языка общего назначения

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

Сообщение от Psilon Там физически не может быть одного владельца.

И че какие вопросы? Ну несколько владельце в так несколько один так один. Это в принципе и на искоробочных смартпоинтерах делается а на смартпоинтерах с двустаронними ссылками так и с поддержкой внешнего удаления вообще без никаких вопросов. просто выставляешь ссылка слабая или слабовладеющая. В принципе элементарно сделать чтобы владеющий/не владеющий даже в рантайме переключалось.
А вот у GC с этим реально проблемы будут. Он без смартпоинтеров две независимые трассы на рут имеет свойство течь.

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

Сообщение от Psilon С++ слишком перегружен ненужным хламом, чтобы его изучать.

Не заметил.

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

Сообщение от Psilon В стиле "два раза освободил память - ну ты лашара"

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

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

Сообщение от Psilon Шаблоны не нужны

Бред.

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

Сообщение от Psilon Потому что плюсовики в случае косяка языка

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

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

Сообщение от Psilon Так что пока нет, но результат стоит того, чтобы подождать.

Дженерики в принципе ущербны а не только отсутсвием констант. Как там дела с template-template обстоят? А с проверкой в компайлтайме применимости операторов к обобщенному типу?

0

Сообщение от Fulcrum_013 ТАйплклаасы это костыль для тех кто смотрит на объект как на пассивное хранилище данных а не на активную сущность.

Интересно. А как расширять объект, автор которого не подумал о какой-то функциональности? Ехал враппер через враппер?

Сообщение от Fulcrum_013 Генерик это кастрированный шаблон. ТАк что это шаблонов нигде кроме плюсов нет.

Как только шаблоны начнут хоть как-то валидировать свою корректность без инстанцирования, а желательно еще доказывать корректность относительно открытого множества Т, сразу же соглашусь

Сообщение от Fulcrum_013 Языка общего назначения

чьему определению, прошу прощения?

Сообщение от Fulcrum_013 И че какие вопросы? Ну несколько владельце в так несколько один так один. Это в принципе и на искоробочных смартпоинтерах делается а на смартпоинтерах с двустаронними ссылками так и с поддержкой внешнего удаления вообще без никаких вопросов. просто выставляешь ссылка слабая или слабовладеющая. В принципе элементарно сделать чтобы владеющий/не владеющий даже в рантайме переключалось.

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

Сообщение от Fulcrum_013 А вот у GC с этим реально проблемы будут. Он без смартпоинтеров две независимые трассы на рут имеет свойство течь.

Как раз с ГЦ все отлично, ибо он умеет детектировать циклы, и убивать два взаимоссылающихся объекта в случае необходимости. А вот работать с такими объектами одно удовольствие, потому как не надо париться как в случае плюсов или того же раста.

Сообщение от Fulcrum_013 Не заметил.

Печально

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

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

Отвечаю как программист с опытом С++: на самом деле это не так. Это умные указатели. Они не контролируют время жизни, по Александреску они созданы для дереференса и для вызова правильного деструктора либо после разрушения переменной(unique_ptr), либо по достижению счетчика нуля(shared_ptr). Ну и в какой-то степени unique_ptr можно считать частным случаем shared_ptr. Вопрос: почему они не контролируют время жизни объекта? Потому что RAII хорош только в том случае, когда ты используешь так называемые "правила хорошего тона". Вот как можно сломать unique_ptr: C++ 1 2 3 4 5 6 7 #include <memory>   int main () {   int* p = new int (10);   std::unique_ptr<int> a (p);   std::unique_ptr<int> b (p); } Программа будет завершена аварийно из-за попытки двойного освобождения. Если бы умные указатели контролировали время жизни объекта, такого бы не случалось. Отвечаю как программист с опытом Rust: время жизни объектов контролирует сам язык, поэтому вышеуказанная ситуация в Rust в принципе не возможна. К примеру, Box используется для размещения объекта в куче (и вызове free при разрушении; почти как unique_ptr): C++ 1 2 3 4 5 fn main() {     let p = String::from("10");     let a = Box::new(p);     let b = Box::new(p); } Программа не соберется с ошибкой: C++ 1 2 3 4 5 6 7 8 error[E0382]: use of moved value: `p`  --> src/main.rs:4:22   | 3 |     let a = Box::new(p);   |                      - value moved here 4 |     let b = Box::new(p);   |                      ^ value used here after move   | Вот что такое контроль времени жизни объекта. К Box/Rc/Arc это не имеет никакого отношения. Это вшито в язык, а не в библиотечный код.

Но конечно же, виноват программист/IDE/фаза луны, но только не божественный язык.

Добавлено через 1 минуту
К слову, перечитал претензию к тайпклассам, понял, что вы похоже даже не знаете что это такое.

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

Сообщение от Fulcrum_013 Косяков у плюсов нет.

ахаха. Спасибо, насмешил.

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

Конечно, могут. И есть языки, где можно сделать задачу без стрельбы по ногам. В случае того же раста оно еще и по производительности будет не хуже, а в некоторых сценариях лучше.

Сообщение от Fulcrum_013 Дженерики в принципе ущербны а не только отсутсвием констант. Как там дела с template-template обстоят? А с проверкой в компайлтайме применимости операторов к обобщенному типу?

если template-template это дворовое название HKT, то в расте никак пока. Для этого есть скалохаскели. Печально, конечно, но все сразу не бывает. Плюс есть кастрированная версия в виде AssociatedTypes (это та штука, которая в трейте Mul выше позволяет задать резульат умножения, например), так что не так уж и необходимо. Хотя, конечно, сценарии придумать можно.

Но веб-сервер с ботом написал без каких-либо проблем, так что жить вполне приятно можно.

1

Сообщение от Psilon время жизни объектов контролирует сам язык,

Вот это как раз и проблема. Откуда ему знать правила контроля времени жизни для какой то определенной предметной области?

Сообщение от Psilon Программа будет завершена аварийно из-за попытки двойного освобождения.

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

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

Сообщение от Psilon Но конечно же, виноват программист/IDE/фаза луны, но только не божественный язык.

Язык то причем до библиотечных средств и выбора оных разрабом?

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

Сообщение от Psilon Потому что как я уже говорил, они атомарные

Они какие угодно. Не стоит циклится на искоробочных. Это заплатка для бедных которые так и не въехали в тему.

Сообщение от Psilon А еще куча способов, где смарт-поинтер никак не спасет.

А есть еще большая куча схем реализации смартпоинтеров на все случаи жизни.

Сообщение от Psilon Как раз с ГЦ все отлично, ибо он умеет детектировать циклы, и убивать два взаимоссылающихся объекта в случае необходимости

Может. Но это можно и без него. В простейшем случае при помощи искоробочного weak_ptr.
А вот пару объектов имеющую кроме сссылок друг на друга еще и свои отдельные трассы на рут он при обрыве одной из трасс разобрать не умеет. Соответсвено если хотя бы у одного из объектов эти ссылки добавляемы в динамический массив при создании такой двусторонней связи то все это потечет и потечет конкретно.
А такая схема соответсвует наиболее встречающейся связке паттернов композит и обсервер.
Именно поэтому в языках с GC добавляют weak_ptr. Но именно добавление weak_ptr и делает GC ненужным.
При этом в языках с GC нет средств поддержки смартпоинтеров (автовызов деструкторов для статически размещенных объектов и автогенерация деструкторов) а соответсвенно использовать более продвинутые варианты смартпоинтеров не получится.
Так что получается в современных условиях GC это просто ненужная обуза.

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

Сообщение от Psilon Конечно, могут.

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

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

Сообщение от Psilon Интересно. А как расширять объект, автор которого не подумал о какой-то функциональности?

В ООП принято сначала думать а потом код писать. Как и при любой нормальной разработке. Тогда получаются иерархии объектов которые живут по принципу "добавил в модель и забыл".
Соответственно и костыли для лечения рукожопства не нужны.

0