ооп и функциональщина кратко, внятно.

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

Не-а! Ведь ООП лежал, лежит и будет лежать исключительно в практической плоскости. А раз так, то все опять и снова упирается в реализацию.

А с реализациями у нас напряженка. Где еще сыскать такой язык, который так гибко позволит конфигурировать свой рантайм?

Но меня всегда поражало другое. Почему, ну почему никто не сделал «промышленной» реализации ML, которая бы позволяла писать низкоуровневые программы? Т.е. без десятка стадий кодогенерации (пусть даже в ущерб производительности, пусть даже с ликвидацией магии System F). С возможностью ручного управления памятью. Причем ML за нефиг делать позволил бы рулить режимами (а на что нам еще монады?). С максимальным упрощением рантайма, и с возможностью максимальной его конфигурации вплоть до режима «не тащить с собой». С безусловной ориентацией на интеграцию с C.

Корчеватель в треде!

Если писать «нормальным языком», получится книжка размером с Буча... Оно тебе надо?

Если писать «нормальным языком», получится книжка размером с Буча... Оно тебе надо?

Нет. Но корчеватель-стайл дамп мне тоже не нужен.

Но корчеватель-стайл дамп мне тоже не нужен.

А ты добавь хороших задачек. И будет по Константинову.

А зачем как в лиспе? В лиспе все тормозит :) Вот как в скалке еще можно было бы. Там не так давно появились макры и будут развиваться. Насколько я вижу, они учли опыт nemerle.

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

И еще, в С формально не выразим тип результата *ptr. А это именно ссылка.

Алан врет. ООП было до него, а Страуструп свой С с классами делал примерно в то же время, когда Кей придумывал. Страуструп брал ООП концепции с Simula67.

Какой smalltalk? Он не востребован от слова совсем.

Matrix &Matrix::operator+(const Matrix &B) const

И что тут сложного(ты неправильно написал, но фиг с ним)? На С будет чем-то лучше?

Некоторым людям™ не нравится, что строка «i++» не очевидно показывает «мы тут переходим к следующему элементу дерева».

Боюсь, что они профнепригодны. Я боюсь, что с ними будет при изучении scala, например.

Есть pragma pack(1) и функции для перевод из одного порядка байтов в числе в другой. Никаких проблем.

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

Как только ядро перепишут на Скале, тогда и посмотрим, что с ними будет.

их давно уже мышкой программируют.

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

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

особенно наследование :(

Алан врет. ООП было до него, а Страуструп свой С с классами делал примерно в то же время, когда Кей придумывал. Страуструп брал ООП концепции с Simula67.

Прочти пост еще раз.

наследование проиграло же интерфейсам

как раз таки нет , в отличии от «нормальных языков» для наследования в С++ тебе при компиляции потребуется сырцы родителя , что просто напросто «обнуляет» пользу наследования.

ибо вот так.

и ты бредиш когда перегрузку операторов смешиваеш с полиморфным(по типу обьекта) вызовом.

Он всегда бредит. Не обращай внимания. У меня он вообще вот так подписан:

emulek (23.08.2013 2:21:16) гиперактивный генератор бреда

какой коммент у моего ника у тебя?

Никакого, ты вроде ничем не отличился в сторону минуса. :D

Сиплюсик конечно удобен школьникам, тяжело принимающим всякие %s %d %x и так далее в качестве аргументов принтфов и сканфов

Фишка в том, что те же printf и scanf не проверяют типы и количество передаваемых аргументов, создавая огромное поле для багов и уязвимостей, а также не расширяемы, т.к. набор выводимых типов жестко ограничен.

Ну и к ООП и функциональщине топик не имеет абсолютно никакого отношения.

тайпдефы ... портят читаемость

в случае с шаблонами улучшают, причем иногда радикально

Фишка в том, что те же printf и scanf не проверяют типы и количество передаваемых аргументов, создавая огромное поле для багов и уязвимостей

Типы printf и scanf проверяют компиляторы уже сколько лет... 10-15?

Что, для каждой функции, принимающей произвольное число аргументов, писать валидатор в составе компилятора?

Что, для каждой функции, принимающей произвольное число аргументов, писать валидатор в составе компилятора?

О чем ты? Если о printf-подобных строках форматов, то в приличных компиляторах валидатор уже есть.

1. Класс - химера. Объединяет в себе «тип», «интерфейс», «поведение».

Легковой автомобиль - химера. Объединяет в себе «бензин», «двигатель» и «ходовую часть».

2. Тип. В данном конкретном случае то же самое что и множество. Т.е. class Foo <==> все объекты класса Foo принадлежат множеству Foo.

детский сад, штаны на лямках

т.е. по-твоему «кольцо целых чисел» и «аддитивная группа целых чисел» это один и тот же тип? множества ведь совпадают

уже на 2-м курсе студням рассказывают о том, что алгебраическая структура — это множество с набором операций, удовлетворяющих инвариантам

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

О чем ты? Если о printf-подобных строках форматов, то в приличных компиляторах валидатор уже есть.

О не printf-подобных строках форматов.

Типы printf и scanf проверяют компиляторы уже сколько лет... 10-15?

gcc на это выдает только варнинг, и только с -Wall

ллол thx лестно,

Если о printf-подобных строках форматов, то в приличных компиляторах валидатор уже есть.

О не printf-подобных строках форматов.

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

Поэтому ядро пишут на плюсах?

ядро чего? линукса что ли?

ну а кто же запретит торвальдсу писать его на чем угодно, хоть на брейнфаке?

алгебраическая структура

А по-твоему класс - алгебраическая структура?

И не понял возникшего баттхерта. Поясни.

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

Проверяет и выдает, да.

КО имеет сказать, что пост annulen-а говорил как раз о том, что эти проверки в случае крестов должен и может выполнять тайпчекер

Передай КО, чтобы читал внимательнее.

А ты начал рассуждать про какие-то валидаторы, прикрученные сбоку к компилятору.

Не понял, в чем твоя претензия. Я даже слово «валидатор» использовал в ответ на:

geekless> писать валидатор в составе компилятора?

А тем временем в iostream, вместо проверки соотвествия аргументов строке формата, происходит подбор нужной функции под тип аргумента, что а) убирает лишнюю сущность - тип в строке формата; б) предотвращает ошибки из-за несовместимости типов; в) работает даже в шаблоне, когда тип может меняться

Всего два слова: https://www.kernel.org/ и https://developer.gnome.org/glib/2.32/

слова писать ты научился, молодец — теперь осталось прочитать что я написал:

да, эти недостатки можно исправить, но результатом исправления будет твой личный с++

и включить мозги

оба этих проекта находятся на разных стадиях движения к «личному с++»; этот «личный с++», хотя может быть даже более удобен для этих проектов, чем с++, оказывается существенно менее пригодным (или даже вообще не пригодным) для других проектов

Мне, в общем-то, безразличны прелести iostream. Я прокомментировал конкретную фразу о непроверяемости аргументов printf и scanf.

А противники форматных строк могут подумать на досуге, почему форматные строки вернулись в D, Scala и Rust.

А по-твоему класс - алгебраическая структура?

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

впрочем, типы *вовсе* не обязаны ограничиваться алгебраическими структурами (вспоминаем введение tapl для определения типа)

но кстати смешивание инкапсуляции и полиморфизма в одном флаконе (классе) по-моему все же неудобно, полиморфизм должен идти отдельно

з.ы. пиши два минуса — они преобразуются в длинное тире

Да, возможно именно с пониманием/использованием наследование у ТС(и вас?) и возникли трудности. Как вы решаете вопрос с принципом открыт-закрыт? Есть еще подход со сигнатурами/структурами в ML'ах, например. Он вам больше нравится? Но ведь он работает на один уровень фактически. Кроме того, не связан с типами, к нему не применим LSP и др. полезные принципы.

Как мне добавить формат для своего типа? В С++ это делается легко и непринужденно.

И не понял возникшего баттхерта. Поясни.

указание множества без указания допустимых операций и инвариантов практически не мешает программе вести себя нежелательном образом (тут вспоминаем определение типа из tapl), поэтому множество без указания допустимых операций и инвариантов вообще нельзя называть типом данных

это на 2-м курсе обычно и объясняют... или даже на 1-м, уже забыл

Форматные строки в перечисленных тобой языках очень сильно отличаются от сишечки. Ибо типобезопасны и расширяемы. В С++ типобезопасность и расширяемость были обеспечены через перегрузку операторов, ибо это просто и работало еще на основе достаточно старых правил перегрузки. Далее появился boost::format, например. С использованием нового стандарта можно без проблем реализовать printf типобезопасно и расширяемо. Сишечке это не по зубам.

наследование не нужно.

зы. нужно(может пригодится т.е пользы больше чем вреда) в очень реальне очень больших системах , где уже есть чёткая систематика.

вообще интерфейсов достаточно.

Интерфейсов недостаточно. Достаточно интерфейсов + «миксинов»(в том или ином виде). Но это часто превращает потенциально простой код в непонятную лапшу.

Ок, ок, не ершись. :D

Форматные строки в перечисленных тобой языках очень сильно отличаются от сишечки.

Спасибо, Капитан, я знаю.

Ибо типобезопасны и расширяемы.

В GCC форматные строки так же типобезопасны, как и всё остальное в Си. Не расширяемы, да (точнее, расширяемы, но расширения уже не типобезопасны, ЕМНИП).