>>4992010

> не нынешнее ООП от не нынешнего

Нынешнее ООП от не нынешнего, я имел в виду.

>>4992009
Как мне тебе на пальцах объяснить, чем 10 килобайт кода лучше 10 мегабайт? Никак. Потому что 10 мегабайт концептуально должно быть проще писать и обслуживать индусам. И это главное.

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

P.S. >>4992015
Боюсь, у нас с тобою слегка разные понятия об ООП.

>>4992016
Разумеется разные. До холивара разные. Не хочу закончить как остальные еретики. Поэтому даже не буду углубляться в детали. Там что ни слово, то бочка динамита для тебя будет.

>>4992015
Нет ничего зазорного в том, чтобы собрать на коленке алгоритм и набросать дополнительного кода для правильной обработки эксепшенов.
Но потом программа подгоняется под таргет-машину и таргет-тайминги. И это как раз значит "превратить 10 мегабайт кода в 10 килобайт"

>>4992017
Похоже, что кому-то как-то отдавило пальцы особенно тяжёлым объектом, научив завидной осторожности.

Теперь ещё бы выяснить насчёт типизации.

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

Алё, это Ычан?
Совсем уж мутные дискуссии поши, в стиле - "это истина, просто потому что я так считаю".
И отличия старого ООП от нового мне никто так и не хочет объяснить.

>>4992019
Это как с ухом и медведем?

>>4992021
Этот как раз и есть новое понимане. ООП идеально, как ни странно, для объектного программирования. А приспособили его особенности под цеховое производство. По моему это так же неправильно как использовать некоторые религии для политики и захватнических войн. Вот только это чертовски удобно, что поделать. Всё это наследование, инкапсуляция и полиморфизм не требуют на самом деле никакого дополнительного толкования. Толкование нужно чтобы понять как это всё соотносится с конвейерным индусописанием. Ну застолблён уже термин, что с этим поделать. Пусть пользуются.

>>4992020
Похоже, что о типизации я тоже многое не знаю.
Для меня слабая типизация — это когда разъём от мышки, наушников или телевизионной антены прекрасно подходит к розетке на 220 вольт.

>>4992021
Думаю я тут отличие не старого от нового, а идеального, сделанного грамотными людьми, от того что обычно есть.

>>4992025
А что мешает бить молотком по гвоздю, вместо пальца?
Помимо превалирующей тенденции, которой никто не заставляет следовать.

>>4992024
Ну и что в этом плохого? Плохо когда оно при этом ломается, или ты не умеешь использовать так чтоб не ломалось. Лучше конечно чтоб и не ломалось и программист был не погромистом.

>>4992024
Лучше и не скажешь.

На самом деле ITT столкновение творческого и ремесленного мышления. Творчеству не место на производстве, от него там всё в разнос идёт. Нужно строгое следование протоколам, разделение труда и унификация. Любая бюрократия только на пользу идёт. А в творчестве важна свобода самовыражения и стремление к идеалам. Творчество все эти рамки душат, а стороннее вмешательство сводит с ума.

>>4992028
Плохо то, что мне приходится тратить своё время и внимание на проверку совпадения типов, вместо того, чтобы переложить эту нехитрую работу на компилятор. Ещё хуже то, что я могу не заметить вовремя ошибку и потратить потом время на поиск её источника.

>>4992028

>Ну и что в этом плохого?

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

>>4992030
Творчество в IT нужно не просто ради творчества; его конечной целью всё-таки является конкретный результат. Поэтому, имеет смысл сосредотачивать его в тех областях, где оптимальное решение ещё не найдено. Велосипед нет смысла изобретать по-новой КАЖДЫЙ раз.

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

>>4992032
А это уже претензии к языку который так глупо сделан. И к голове того, кто догадался зная это всё же воткнуть. Не проблемы концепции как таковой. В идеале должен слушать розетку без всяких последствий, как после полноценного ручного преобразования.
>>4992033
Если велосипеды будет разными, то почему бы и нет? Другое дело, стоит ли опускаться до самого асамблера когда тебе нужно всего лишь заанимировать картинку в браузере. Думаю любая крайность одинаково безумна. Инструменты нужно применять по назначению и сопоставлять затраты с целями. Бросаться кодить всё на свете на электроне и подключать все модные библиотеки тоже дурость.

>>4992034
Боюсь, что здесь как раз наоборот: при слабой типизации не остаётся места сильной, в то время, как при сильной, тип можно принудительно сменить или изначально сделать универсальным. Хотя, лучше сразу проектировать систему так, чтобы все нужные типы везде совпадали, а ненужные — нет.

Сегодня на работе я собрал прибор, на задней панели которого в ряд стоят семь разъёмов. По одному проходит 220 вольт, по другому — 24 вольта, по третьему — 0…10 вольт, по четвёртому 4…20 миллиампер, по пятому — 3.3 вольта и так далее. Нужно ли объяснять, почему я подобрал разъёмы так, чтобы ни один из них не подходил ко всем другим?

>>4992035
Проблемы концепции — это когда розетка питания и Ethernet расположены на стене рядом и оба разъёма подходят друг к другу. Проблема очень серьёзная. Вплоть до фатальной.

>>4992036
А как тогда называется типизация, когда по умолчанию тыкается куда захочешь без последствий, но можно сделать так чтоб не тыкалось?

>Нужно ли объяснять

Ты высоко ценишь способности своих коллег?
>>4992039
Это не проблема концепции, это проблема её реализации. И отчасти проблема того, кто зная о такой проблеме не принял мер.

>Ты высоко ценишь способности своих коллег?

Какая разница? Виноват то, если что, всё равно буду я, как проектировщик. Собственно, именно я скорее всего их и воткнул бы не туда в запарке в ходе установки. Зачем я буду делать для себя такой сюрприз?

>Это не проблема концепции, это проблема её реализации.

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

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

>Виноват то, если что, всё равно буду я, как проектировщик

Именно. Сделай один разъём и поставь переключатель, как вариант. Или защитные реле там, много способов. Не хочешь заморачиваться - другие будут копошиться с разъёмами или гореть. Тебе конечно выгодней чтоб копошились с разъёмами.

Когда я определяю три строгих типа: год, месяц и день, я делаю это для того, чтобы лишить себя возможности передать их в функцию в неверном порядке.
Гибкость в большинстве случаев нужна в строго определённых местах. Если рука гнётся не только в суставах, а по всей длине, значит кости в ней сломаны.

>Сделай один разъём и поставь переключатель, как вариант.

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

>>4991471
Какие проекты? Какой может быть проект, который реализует в себе весь спектр функций и парадигм программирования в С++?

>>4992996
Тот, над которым ты сейчас трудишься? Если ты ОП.

А вообще, есть знание языка и есть знание того, что тебе не нём нужно делать.
Как у тебя обстоят дела со вторым?

>>4992046
А у меня всплывает докстринг с аргументами функции (day, month, year), прикинь до чего техника дошла?

>>4993025
Если у тебя день и месяц разных типов, и в текущем контексте есть переменные с таким типом, то тебе IDE ещё и сама их туда подставит.

>>4993025
Это ж нужно ждать, пока оно всплывёт. Мне некогда.
Да и при редактировании мышкой подсказка не всегда появляется.

>>4993075
Оно всплывает, как только ты начинаешь печатать.

>при редактировании мышкой

Не делай так больше.

>>4993073
Обычно у меня больше одной переменной каждого типа.

>>4991424
Никак, надо было вкатываться в С#.

Я наверное ужасно старомоден, я до сих пор в блокноте код пищу. Зависимость есть.

>>4993112
Я писал питоновский код в IDLE, пока тот у меня не отвалился. К счастью, ломки при переходе на Wing не было.

>>4992013
Вот раньше ООП было ух, вот раньше оно было даааа.

Некоторые считают, что Ъ ООП это только Lisp и SmallTalk, а все остальное от лукавого, думаю это имеется в виду.
мимиокрокодил

>>4993146

>Lisp
>ООП

Я что-то не понимаю, или Лисп - это ФП?

>>4993152
https://en.wikipedia.org/wiki/Common_Lisp_Object_System

>>4993152

>>4992027

>что мешает бить молотком по гвоздю, вместо пальца

Вы не понимаете природу разработки!

>Обычно у меня больше одной переменной каждого типа.

А у меня почти всегда одна в каждом конкретном контексте.
Названная в честь своего типа.
Во избежание.

Ещё полезной практикой является система префиксов, дающих понимание того, с чем ты имеешь дело:
gtEncoderValueBit — глобальный тип.
lvEncoderValueBit — локальная переменная.

>>4993332
О, индусская нотация.

>>4991424
Зачем в 2020 году учить C++?

>>4993643
Я бы задал вопрос шире. Зачем в 2020 году вообще чего то учить? Можно быть вполне успешным и без лишнего груза.

>>4993648
А потом находятся те, кому 8 гигов памяти не хватает и даже 16.

>>4991991
А разве C и C++ так сильно отличаются? Я слышал, что в C++ ООП добавлено, а так отличий от С почти нет.
мимо пишу лабораторные по С на С++

>>4993681
А тебе эти лабораторные потом засчитывают? Я слышал, что C более низкоуровневый, поэтому на нем и пишут ОС. На плюсах же их, насколько я помню, не пишут, только C и ассемблер. Последний я, кстати, недавно начал учить.

>>4993643
Что же тогда учить, JavaScript? Rust?

>>4993643
Вообще C++20 наконец-то стал отдаленно походить на человеческий ЯП.

>>4993681
В 98 году так и было, но современные стандарты это практически разные языки.

>>4993680
Ты про хром? (он на плюсах)

>>4993784
Серьезно? Это ж насколько у его программистов кривые руки?..

>>4993692
Ага. Только есть уже множество других языков, которые уже давно нормальные. Да и переусложненность все равно никуда не делась.

>>4993685
Поглядев мельком в код некоторых драйверов Linux, подумал, что лучше б не выпендривались и на плюсах написали. А то там то же самое ООП и паттерны, но на Си, с передачей структур с состоянием вместо классов и таблицами коллбэков вместо виртуальных функций. Meh.

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

>Что же тогда учить, JavaScript? Rust?

>>4993887
У меня в престо-опере всё это работает, кроме компилятора JS. Вкладок около сотни. Всё что написано по стандартам W3C прекрасно отображается. Правда там под капотом тоже непойми что.

>сделанные в общем случае не пойми как

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

>>4993891
Лиса может успешно не справиться с совместимостью хрома. Что не вина лисы, впрочем.

Трудно сказать. Невозможно предсказать прошёл ли пик увлечения JavaScript или на нём скоро начнут писать операционки. Можно было бы посоветовать электрон, не будь у гугла 7 пятниц на неделе. Си хороши своим стабильным спросом на протяжении десятилетий.

>>4993642

>>4994003
Вот Электрон не советовал бы. Ну, то есть, он хорош, когда у изучающего есть опыт программирования, причём в обеих областях, и веб, и десктоп. Без этого - боюсь, процесс создания конечного продукта будет выглядеть как нагромождение мегатонн заклинаний. Да чего уж там, он и с опытом так выглядит. В общем, имхо, за Электрон нужно браться, когда есть под него чёткая задача. К примеру, кроссплатформенный веб-подобный дизайн UI, работа с какими-нибудь сервисами по веб-протоколам/JSON RPC, необходимость отображения разнообразного или произвольного контента. Для поковырять лучше C# или питон.

>>4994180
...или просто Node.JS, без электрона.

>>4991424
зачем? раст в несколько раз лучше

>>4993689

> Rust

да

>>4991486
2 месяца штмл, жабаскрипт

> раст
> лучше

Это то чудо, которое побило perl по нечитаемости?

Был язык C++, сделанный до того криво, что поверх него случайно еще один язык, которые шаблоны и совершенно нечеловекочитаем.

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

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

Итог: D никто не использует, Rust лезет во все щели. Резюме: эта субстанция, как известно, не тонет…