The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Бета-выпуск языка программирования Rust 1.0, opennews (??), 04-Апр-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


68. "Бета-выпуск языка программирования Rust 1.0"  –1 +/–
Сообщение от Аноним (-), 04-Апр-15, 20:33 
>Я перешел правда с C#. Очень доволен. Обратно, а тем более на Плюсы не за что не вернусь. Теперь код так же легко как на Питоне писать, разве что либ меньше чем у самого Питона, но зато сишные либы идут на ура.

C#, Python - фу, какая гадость. С++ штука отличная но нужно уметь не перегнуть палку. Но раз любители python'a в восторге от D, то я пока повременю с D.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

83. "Бета-выпуск языка программирования Rust 1.0"  +2 +/–
Сообщение от Crazy Alex (ok), 05-Апр-15, 04:54 
Лучше всё же глянь. Он с питоном сравним в основном простотой писания кода и сильно более "человеческим" синтаксисом, чем у плюсов. А так - как раз для плюсовика там рай, если он не в джава-стиле привык писать с двумя дестяками уровней наследования и тяжелыми паттернами на каждом шагу.
Ответить | Правка | Наверх | Cообщить модератору

95. "Бета-выпуск языка программирования Rust 1.0"  –1 +/–
Сообщение от Аноним (-), 05-Апр-15, 11:16 
>> и тяжелыми паттернами

Что Вы понимаете под "тяжелыми паттернами"?

Ответить | Правка | Наверх | Cообщить модератору

105. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Crazy Alex (ok), 05-Апр-15, 23:52 
Много уровней абстракции тянут за собой более-менее стандартный набор - фабрики, медиаторы, фасады, прокси и т.п. - всё, что отвечает за то, чтобы не утонуть в громоздком коде. Как по мне - они очень замыливают глаз в плане понимания "а что мы тут, черт возьми, хотим сделать" - особенно когда тыкаются в глаза в названиях классов и методов. Туда же - запрет иметь классы-реализации без абстрактных классов, попытки конфигурировать то, что никто и никогда не будет менять, вроде используемого движка БД... Оно, насколько я опнимаю, пошло из библиотек джавы, которые, во-первых, должны быть универсальными, а во-вторых - рассчитаны на работу в раках стека Java EE, что автоматом подразумевает монструозность приложения, в-третьих - результат бедности (особенно в прошлом, когда традиция и появлялась) джавовского синтаксиса.

В плюсах всегда был возможен другой стиль - когда наследование используется минимально, зато в ход идут STL, шаблоны, перегрузка, стековые объекты, сейчас еще auto добавилось - в результате в софте небольшого масштаба (скажем, на пару сот тысяч строк) можно иметь более-менее читабльный код именно в  плане понимания "что делаем".

Ответить | Правка | Наверх | Cообщить модератору

107. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от csdoc (ok), 06-Апр-15, 00:52 
> Много уровней абстракции тянут за собой более-менее стандартный набор - фабрики, медиаторы,
> фасады, прокси и т.п. - всё, что отвечает за то, чтобы
> не утонуть в громоздком коде. Как по мне - они очень
> замыливают глаз в плане понимания "а что мы тут, черт возьми,
> хотим сделать" - особенно когда тыкаются в глаза в названиях классов
> и методов. Туда же - запрет иметь классы-реализации без абстрактных классов,
> попытки конфигурировать то, что никто и никогда не будет менять, вроде
> используемого движка БД... Оно, насколько я опнимаю, пошло из библиотек джавы,
> которые, во-первых, должны быть универсальными, а во-вторых - рассчитаны на работу
> в раках стека Java EE, что автоматом подразумевает монструозность приложения,

Кроме Java EE есть и другие фреймворки, например, https://spring.io/ Там все гораздо лучше.

> В плюсах всегда был возможен другой стиль - когда наследование используется минимально,

Использование наследования вместо композиции - это вообще антипаттерн,
для Java нормальным вариантом является именно что композиция, а не наследование.
подробнее об этом написано в http://www.ozon.ru/context/detail/id/6108824/

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

В плюсах вообще все делается через наследование - и имплементация интерфейса
и наследование поведения, что не способствует понятности плюсовых исходников.

Поскольку интерфейсы в Java оказались очень удачной идеей -
эту же идею потом реализовали и в новом гугловском языке программирования Go.

Ответить | Правка | Наверх | Cообщить модератору

109. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от dcdcfd (?), 06-Апр-15, 02:10 
> Поскольку интерфейсы в Java оказались очень удачной идеей - эту же идею потом реализовали и в новом гугловском языке программирования Go.

и не только в ге
http://wiki.freepascal.org/Interfaces


Ответить | Правка | Наверх | Cообщить модератору

113. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от Crazy Alex (ok), 06-Апр-15, 12:49 
Что за бред, простите. В плюсах есть мощные шаблоны и auto, которые в подавляющем большинстве случяаев вообще избавляют от нужды в динамическом полиморфизме в пользу duck typing. Вот о мышлении "давайте для всего сделаем интерфейс" я и говорил - оно вообще не нужно в плюсах. Просто берешь и пишешь имплемиентацию. Если нужна фабрика - это шаблонный метод, ты даже не знаешь, какой тип она вернёт и тебе не требуется, чтобы он что-то наследовал - только чтобы сигнатуры методов были совместимы с вызовами. А в случае джавы - антипаттерн или нет - но придётся наследоваться лишний раз.

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

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

116. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от csdoc (ok), 06-Апр-15, 17:08 
> Что за бред, простите. В плюсах есть мощные шаблоны и auto, которые
> в подавляющем большинстве случяаев вообще избавляют от нужды
> в динамическом полиморфизме в пользу duck typing. Вот о мышлении
> "давайте для всего сделаем интерфейс" я и говорил - оно вообще не нужно в плюсах.

Способность видеть отличие между интерфейсом и реализацией - это плюс.

Интерфейсов в плюсах нет, вместо интерфейсов там абстрактные классы используются.

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

> Просто берешь и пишешь имплемиентацию.

Можно вообще не заморачиваться никакими паттернами
а просто брать и писать имплементацию.
И оно даже будет как-то работать.

> Если нужна фабрика - это шаблонный метод, ты даже не знаешь,
> какой тип она вернёт и тебе не требуется, чтобы он что-то наследовал
> - только чтобы сигнатуры методов были совместимы с вызовами.

Factory method - это только один из способов реализации фабрики.
Есть и другие, например:

https://en.wikipedia.org/wiki/Abstract_factory_pattern
https://ru.wikipedia.org/wiki/Абстрактная_фабрика_(шаблон_проектирования)

> А в случае джавы - антипаттерн или нет - но придётся наследоваться лишний раз.

С чего бы это вдруг? В Java есть интерфейсы. Там не нужно наследоваться.

> И, разумеется, в плюсах есть вложенные классы - ещё от сишных вложенных
> структур пришли. Другое дело, что у них нет автоматического доступа к
> экземпляру клсса-владельца - надо явно отдать ссылку или указатель на него.

Есть static nested classes, но нет inner classes.
Вот именно inner classes + интерфейсы покрывают все случаи,
когда в плюсах для этого используется создающее проблемы множественное наследование.

> А интерфейс от абстрактного класса вообще ничем кроме названия не отличается.

"Что за бред, простите".

Ответить | Правка | Наверх | Cообщить модератору

130. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Crazy Alex (ok), 07-Апр-15, 00:44 
Различие между интерфейсом и реализаций видно очнеь легко - интерфейс - это объявления публичный членов, если речь идёт о классе. Напомниаю, что на плюсах можно отлично писать вообще вне парадигмы ООП - а используя, к примеру, принципы data-flow. А вот желание везде именно явно отделить интерфейс, даже если он будет реализован один единственный раз, да чтобы это было именно слово interface - это как раз та проблема, о которой я и говорю. Для больших проектов такой подход окупается. "Безобразно, зато единообразно". Для малых/средних, те более на плюсах - больше мусора в коде, чем толку.

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

И да, до какого-то размера "не заморачиваться паттернами, а писать реализацию" - самый правильный подход. Потому что писанины меньше, а архитектура и так вся в голове помещается. И поддерживается - опять-таки, до определённого размера - такой код ЛЕГЧЕ, чем тот, где всё тщательно выписано.

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

>> А в случае джавы - антипаттерн или нет - но придётся наследоваться лишний раз.
>С чего бы это вдруг? В Java есть интерфейсы. Там не нужно наследоваться.

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

>Есть static nested classes, но нет inner classes.
>Вот именно inner classes + интерфейсы покрывают все случаи,
>когда в плюсах для этого используется создающее проблемы множественное наследование.

В плюсах, если это нужно, просто вложенному объекту отдаётся ссылка на родителя в конструктор. И всё.

>> А интерфейс от абстрактного класса вообще ничем кроме названия не отличается.
>"Что за бред, простите".

Никакого бреда. Джавовский interface и плюсовый абстрактный класс (точнее, pure abstract class) функционально абсолютно идентичны.

Ответить | Правка | Наверх | Cообщить модератору

133. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от csdoc (ok), 07-Апр-15, 02:02 
> Различие между интерфейсом и реализаций видно очнеь легко - интерфейс - это
> объявления публичный членов, если речь идёт о классе.

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

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

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

Есть такое очень хорошее видео:

https://www.youtube.com/watch?v=G6LJkWwZGuc
Николай Алименков — Парадигмы ООП

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

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

Иногда я этот совет нарушал и тогда было очень проблематично писать юнит-тесты.

> И да, плюсовые абстрактные классы в плане поведения от джавовских интерфейсов вообще
> ничем не отличаются. ТОлько и того, что ключевое слово разное, да
> для интерфейсов implements надо писать.

Абстрактные классы есть и в Java. Но это не то же самое что и интерфейсы.

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

> И да, до какого-то размера "не заморачиваться паттернами, а писать реализацию" -
> самый правильный подход. Потому что писанины меньше, а архитектура и так
> вся в голове помещается. И поддерживается - опять-таки, до определённого размера
> - такой код ЛЕГЧЕ, чем тот, где всё тщательно выписано.

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

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

Это сейчас, когда паттерн известен и хорошо изучен он кажется очевидным.
Когда-то явно этот паттерн не был выделен и его осмысление было открытием.

http://habrahabr.ru/post/170125/
Для чего нужны шаблоны проектирования

>>> А в случае джавы - антипаттерн или нет - но придётся наследоваться лишний раз.
>>С чего бы это вдруг? В Java есть интерфейсы. Там не нужно наследоваться.
> Ну "реализовывать интерфейс".

Если хочем иметь возможность менять реализации - да, надо отделить мухи от котлет,
и сказать, что вот это у нас интерфейс, а вот это у нас - реализация интерфейса.

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

Извините, а зачем переменной присваивать значения разных типов? Не понимаю.

> В плюсах же это не обязательно - пока не нужен динамический полиморфизм
> (а он, как ни странно, довольно редко нужен) - можно обойтись без наследования.

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

>>> А интерфейс от абстрактного класса вообще ничем кроме названия не отличается.
>> "Что за бред, простите".
> Никакого бреда. Джавовский interface и плюсовый абстрактный класс
> (точнее, pure abstract class) функционально абсолютно идентичны.

Понятно. Я смотрю просто на это все с точки зрения языка программирования Java,
а там interface и pure abstract class - это совсем не одно и тоже, а разные сущности.

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

В Java эти понятия очень четко разделены - интерфейс - это всегда только контракт,
а наследование от класса - это наследования реализации/поведения а не интерфейса.

Из-за чего - Java позволяет писать более понятный код, по сравнению с плюсами:

James Gosling: Java — это C++, из которого убрали все пистолеты, ножи и дубинки.

Ответить | Правка | Наверх | Cообщить модератору

111. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 06-Апр-15, 08:20 
> Оно, насколько я опнимаю, пошло из библиотек джавы, которые, во-первых, должны быть универсальными

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

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

114. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Crazy Alex (ok), 06-Апр-15, 12:52 
Да, должны. Но если универсальность включает в себя требование удобного использоавния в приложениях из многих миллионов строк, а внимание более простым случаям не уделили - то платить за организацию кода прикладной программист будет больше, чем мог бы. Вот теми самыми иерархиями и громоздким кодом.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру