Страуструп о будущем семантических средств разработки с комментариями

>Я пишу на Си++, но избегаю излишних иерархических конструкций, ибо непрактично... Однако полное отсутствие поддержки объектов в таком языке как Си иногда приводит к некоторым неудобствам...

fpga (*) (09.09.2008 21:53:41)

Да от си по-сути вообще никакого толку нет, в c++ можно не использовать классы, получится си.

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

Ооп нужно именно при разработке сложных программ.

>Ооп нужно именно при разработке сложных программ. anonymous (*) (09.09.2008 22:19:44)

Золотые слова! Ты забыл добавить, что сложные программы, в большинстве случаев, "ФТОПКУ", а их создателей "АПСТЕНУ".

>А Цэ++ был, первоначально, Це с классами - С-труп его поначалу только так и называл, а компиллер с Це++ был прекомпилятором с ++ в Це, как щаз MOC -прекомпиллер с КюТэ в Це++, советую познакомиться с "кодом", который он генерит - "Кошмар на Улице Вязов" нервно курит в сторонке. anonymous (*) (09.09.2008 21:37:12)

Не верно, 1-й язык с ооп - Симула, а в Object Pascal вообще принципы организации ооп несколько другие- множество конструкторов и деструкторов с разными именами, чего нет в c++.

Учите матчасть.

>Золотые слова! Ты забыл добавить, что сложные программы, в большинстве случаев, "ФТОПКУ", а их создателей "АПСТЕНУ". anonymous (*) (09.09.2008 22:25:36)

Под сложными я имел в виду большого размера.

>Золотые слова! Ты забыл добавить, что сложные программы, в большинстве случаев, "ФТОПКУ", а их создателей "АПСТЕНУ".

Если без ооп пишутся, то да:)

>А почему такая нужная фича до сих пор не является частью языка?

>А какой смысл? Язык настолько элегантен, что позвояет не засорять семантику побочными вещами. Так же как операции ввода-вывода реализуются через шаблоны и производные от них классы, а не тупо как в бейсике встроенными операторами языка. anonymous (*) (09.09.2008 22:08:22)

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

>Не верно, 1-й язык с ооп - Симула, а в Object Pascal вообще принципы организации ооп несколько другие- множество конструкторов и деструкторов с разными именами, чего нет в c++.

Дружище, "первоначально" - не значит "изначально" и относилось не к парадигме ООП вцелом, а к Цэ и мухе ЦэПэПэ.

>Учите матчасть. anonymous (*) (09.09.2008 22:26:41)

Вот, вот, завтра в школе на кружке программирования крестиком спросишь чем отличаются принципы ООП Борландовского "Object Pascal" от Эппловского "Object Pascal".

>Под сложными я имел в виду большого размера. anonymous (*) (09.09.2008 22:28:59)

ААААА! Нуууу так бы и сказал. Извини, поправлюсь:

программы - "АПСТЕНКУ", создателей - "ФТОПКУ"

>idSoftware названа в честь void* указателя на Objective C, который называется id.

Разве? Я думал что там какая-то фигня по Фрейду это id

Выйдите из спячки. С и С++ остаются приоритетами в узких областях. В тех, в которых нужна скорость, чёткость и прочее из серии "1 раз написал - работает быстро, качественно и навсегда. всё, можно про него забыть". Если команда более чем из двух программистов, если у цели более чем 2 версии, если это не драйвер под космическое оборудование - чёрта с два вам позволят всунуть туда С++. Там будет Java, .NET, тот же Python - но не плюсы. Ибо важно, во-первых, качество работы (если какой-нибудь студент забыл освободить память - это должны быть проблемы кретина студента, а не всего приложения, которое из-за переполнения буфера улетает на Луну), во-вторых, нормальная командная работа и сопровождение приложения (я не обязан искать объявление макроса по сорока хедерам того придурка, который работал здесь до меня), в-третьих, гарантия от глупых, но обидных мелочей (обсуждалось выше, плюс добавьте сюда личные приколы каждого компилятора). Всех несогласных отправляю в биореактор.

>С++ красив и логичен

Оу, каррамба... И это называется "логичен".
Логичен - это когда, не зная некую часть языка, чаще всего можно самостоятельно её воспроизвести, исходя из общих известных тебе принципов, не залезая в документацию. Вот что такое логично построенный язык программирования.
Представьте себе, что вы не знаете... ммм... например, что в STL есть next_permutation. Скажите, вам вообще в голову придёт её там искать, а не писать собственную? Очень мало новичков так поступят. STL надо зубрить, и ничего с этим не поделаешь. И был бы язык совершенным - не появился бы boost. Который тоже, между прочим, из пальца не высосешь, и просто так не узнаешь...
Как это ни смешно, но самой логичной я до сих пор считаю организацию FCL - стандартной библиотеки классов .NET. Прекратите орать про быдлокодерство, без вас знаю)) речь идёт о конкретном вопросе - логической организованности. Мне не придёт в голову искать функции для отрисовки кривых Безье где-либо, кроме System.Drawing, а регулярные выражения - где-либо, кроме System.Text.RegularExpressions. И я всегда знаю, что делает метод... к примеру, Console.WriteLine, зато такая вещь, как _wprintf_s_l - бессмысленный набор символов... кстати, первое впечатление, что он какой-то левой ногой связан с принтером))) Brainfuck'a на вас не хватает, господа сишники.
Таких примеров можно приводить горы. Для меня лично stdafx.h - тарабарская грамота. Но вот тот же Питон я знаю ещё хуже, чем С++ (С++ я более-менее спокойно читаю, а Питон никогда ни ставил ещё себе за цель хоть попытаться выучить), но его импорты мне ясны с первого взгляда...
В качестве десерта в этот параграф приведу старую, хорошую цитату с Башорга:
Unix - это не свалка костылей и подпорок. Это стройная, логичная система костылей и подпорок. ;)

>FORTRAN, Common Lisp рано со счетов списывать ;-)

Тсс, не пали пока - дай потроллить! ;-D

>Всех несогласных отправляю в биореактор.

Проводи

>В Delphi используется диалект Object Pascal.

Чей диалект? Borland создал Object Pascal по типу эпплвского, используемого до Apple Mac 9. Причём назвал этот "диалект" почему-то TurboPascal 5.5. Потом пошла версия TurboPascal 6.0, Turbo Pascal 7.0 назывался ещё Borland Pascal with Objects, так как мог быть использован для разработки программ защищённого режима DOS 6.2 и Windows 3.1(1).

Среда Delphi 1.0 (для Windows 3.11) ввела в пользование новый синтаксис языка с конструкциями Pascal, появились ссылочные типы для классов и объектов, новый синтаксис использования объектов (В TurboPascal не было понятия "ссылки" — вместо них везде использовались указатели на объекты, поэтому там так тяжело было программировать с библиотекой TurboVision, расставляя шляпки "^".). В Delphi 2.0 появились "интерфейсы" OLE/COM, в Delphi 3.0 интерфейсы в приложении можно было использовать независимо от COM-подсистемы Windows для внутренних нужд. В Delphi 4.0 появились открытые массивы, которые могли изменять размер во время выполнения программы. От Object Pascal'я кроме синтаксиса классического Pascal в Delphi не осталось ничего! Семантика языка на сложных типах (как объектных типах, так и примитивных) изменилась до неузнаваемости!

>Там будет Java, .NET, тот же Python - но не плюсы

Ку-ку:) Назовите пример cерьезного распространенного настольного приложения, операционной системы, написанной на Питоне:) Очевидно вы-школьник и учитесь в кружке по программированию:) Джава не используется. Не знаю ни одного серьезного приложения, написанного на джаве. j2me под мобилки не в счет. На дотнете что-то там еще пытаются.

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

> А почему такая нужная фича до сих пор не является частью языка?

шаблоны являются частью языка. В C++ была политика, что если что-то можно включить в язык или реализовать в библиотеке - делали в библиотеке. Если же требуется что-то включить в язык, то делают это так, чтобы реализация компилятором (виртуальных методов, например) была не тормознее ручной. Грубо говоря, на C ты добавишь тот же overhead.

Язык C++ более generic, он не для конкретной области, потому и более сложный. Но, блин, когда на том же Python требуется реализовать, например, бинарный протокол передачи данных, либо пишется библиотека на C, либо очень неэффективный, некрасивый код на Python.

На C++ можно реализовать любою задачу, причем так же красиво и эффективно, как и на любом языке ориентированном на данных класс задач. Только квалификация требуется выше. Есть исключения - области, где разработка на C++ просто не развита и потому нет нужных библиотек, фреймворков. Web разработка, например. Там даже не понятно, как приложение под вебсервером запустить (CGI прошлый век- тормозит). Правда Гугловые сервисы написаны на плюсах - но это совсем экзотика.

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

>Оу, каррамба... Unix - это не свалка костылей и подпорок. Это стройная, логичная система костылей и подпорок. ;) anonymous (*) (09.09.2008 22:53:53)

Ниасилил, многабукафф.

>Да и иметь дело с данными в виде обычных переменных

Структуры в Си отменили?

>во многих случаях заранее не известно время жизни переменной

А что дает С++ в плане трекинга жизни переменной? Либо освобожаем ресурс в том же скопе в котором и выделили либо имеем вялотекущий кариес с подсчетом ссылок - как в Си.

>сложно спроектировать иерархию функций

Это да - по сути нэймспейсы это единственная фича С++ которая мне нравится в данный момент. Хотя имеем манглинг, так что лучше старые_унылые_префиксы_xxx().

>Ооп нужно именно при разработке сложных программ.

От ООП в С++ толку нет - реюзаемость кода почти нулевая. Это в Жаве можно воткнуть половину апачевских библиотек в проект и не думать что там могут быть какие-то утечки или SIGENV'ы или прочая муть.

>Чей диалект? Borland создал Object Pascal по типу эпплвского,....iZEN ** (*) (09.09.2008 22:59:37)

Вау! Проффэсора разбудили. И он нам прочел лекцию. Бабки куда нести?

Тока, йа нипонил "Кто на ком стоял?"

>И был бы язык совершенным - не появился бы [бла-бла-бла]

по такой логике получается, что если ты пишешь свою библиотеку - автоматом значит, что язык несовершенен, т.к. стандартная библиотека несовершенна, и далее если лезть в дебри по этой логике, то самый несовершенный язык - это Си, т.к. создана куча сторонних библиотек. И причем тут к С++ "stdafx.h - тарабарская грамота" чисто визуалстудии? Выплеснулся stream сознания, называется, но ::sort не сработал =))

>Грустно же годами программировать на php или рельсах...

Пьерро, залогинься.

Ха! Ха! Ха!

единственный Web фрейморк для крыстофф

И то - для чата.

http://en.wikipedia.org/wiki/Pichat

>И я всегда знаю, что делает метод... к примеру, Console.WriteLine, зато такая вещь, как _wprintf_s_l - бессмысленный набор символов...кстати, первое впечатление, что он какой-то левой ногой связан с принтером))) Brainfuck'a на вас не хватает, господа сишники.

Хм, то что Вы назвали скорее относится к вводу-выводу в си, а не с++. Там с помощью классов и шаблонов делается

На PHP программировать весело!

>>Ооп нужно именно при разработке сложных программ.

> От ООП в С++ толку нет - реюзаемость кода почти нулевая. Это в Жаве можно воткнуть половину апачевских библиотек в проект и не думать что там могут быть какие-то утечки или SIGENV'ы или прочая муть. >Absurd * (*) (09.09.2008 23:07:08)

Ну это от реализации классов зависит. Утечки памяти можно контролировать названными способами.

>На PHP программировать весело!

Тока не увлекайся, а то помрешь от передозировки.

>Утечки памяти можно контролировать названными способами.

Скотчем голову обматывать?

>в-третьих, гарантия от глупых, но обидных мелочей (обсуждалось выше,

Есть средство в с++.

> плюс добавьте сюда личные приколы каждого компилятора).

Есть стандарт языка.

> Всех несогласных отправляю в биореактор.

Это не аргумент

>> Всех несогласных отправляю в биореактор.

>Это не аргумент

Аргумент - "всех несогласных жду в биореаторе"

Когда С++-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем С++, языки явно менее мощны, так как в них нет тех особенностей, к которым привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с C++ по мощности, но со всяческими сложными штучками. C++ для нашего программиста вполне достаточно, так как он думает на C++.

>Хм, то что Вы назвали скорее относится к вводу-выводу в си, а не с++. Там с помощью классов и шаблонов делается

API ввода-вывода должно работать на уровне чанков бинарных данных. Парсинг текста к вводу-вывода отношения не имеет никакого. Гибриды ужа и ежа типа С++ iostream проектируют только мудаки.

BTW, мессаги выводимые на iostream хреново локализуются, так как переводить надо "всю фразу целиком, замещая подвижные части макросом типа %i", "а"<<"не"<<"по"<<"кускам", так как куски обычно нужны разные в разных контекстах.

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

Не могу удержаться от цитирования такого шедевра целиком:

>Когда С++-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем С++, языки явно менее мощны, так как в них нет тех особенностей, к которым привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с C++ по мощности, но со всяческими сложными штучками. C++ для нашего программиста вполне достаточно, так как он думает на C++. geek ** (*) (09.09.2008 23:30:37)

Какой полет мысли! Живо представляю себе картину маслом:

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

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

грызите кактус в своё удовольствие - никто не мешает вроде =)

> Умник, назови хоть один неакадемический чистый ФЯП(помимо Хаскела).

Ерланг? Latex? Листы Excel? ;)

Или неприменно ленивый?

>грызите кактус в своё удовольствие - никто не мешает вроде =)

отвечу соответственно: смакуйте говно на палочках и не отвлекайтесь на грызущих кактус =)

> Джава не используется. Не знаю ни одного серьезного приложения, написанного на джаве. j2me под мобилки не в счет. На дотнете что-то там еще пытаются.

Класс.

>Ерланг? Latex? Листы Excel? ;)

Продолжаю ряд: Листы Коки Ж)

> При этом он настолько сложен что по хорошему коду на С++ можно как по отпечаткам пальцев однозначно определить программиста.

Русский язык тоже настолько сложен, что по хорошему рассказу можно как по отпечаткам пальцев однозначно определить программиста... разве нет?

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

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

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

>> При этом он настолько сложен что по хорошему коду на С++ можно как по отпечаткам пальцев однозначно определить программиста.

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

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

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

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

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

>Аргумент конечно сильный

Кто бы говорил :)

>Ведь довольно сложно собрать аггрегат если у разных болтов сечение и направление резьбы зависит от настроения и вкусов конкретного изготовителя.

Вот это - типичный ГСМ

>Язык настолько элегантен, что позвояет не засорять семантику побочными вещами.

Не смешно.

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

А почему в С++ нет оператора "СделайМнеЗайебись"?

>А я подскажу - виновато множественное наследование.

В органы уже сообщил?

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

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

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

твой личный опыт никому не интересен

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

OpenOffice 2.4.1_2 у меня под FreeBSD 7.1-PRERELEASE уже не собирается (make install clean в каталоге порта). Не пойму в чём дело: ошибка как-то связана с libxml и libxml2 (их две в системе и каждая из них нужна какому-то приложению). Странно, систему держу в идеальной чистоте, левые проги не ставлю мимо системы портов. У меня руки опускаются при виде этого монстра, написанного на Си++ и требующего для своей компиляции около 10ГБ свободного дискового пространства!

Кстати, увеличение частоты процессора (замена Athlon X2 3800+ на 5400+) время компиляции предыдущей сборки OOo 2.4.1_1 не уменьшилось! Видимо это связано с дисковой подсистемой и основные тормоза — в дисковых операциях, а не в компиляторе C++. К примеру, Java-приложения (NetBeans, Eclipse) после замены процессора стали заметно быстрее работать.

>На C++ можно реализовать любою задачу, причем так же красиво и эффективно, как и на любом языке ориентированном на данных класс задач.

Эффективно возможно, но что-бы называть _это_ красивым нужно быть полным извращенцем...

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

ЛОЛ троль общается с копипастой

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

Предварительное голосование по новому стандарту будет уже в этом году. Часть возможностей уже есть в gcc

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

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

На C++ используя библиотеки и шаблоны можно писать ЛЮБОЕ приложение так же эффективно, как и на узкоспециализированном языке. За исключением областей, где C++ почти совсем не используется. Чтобы не написать глюкогенную неподдерживаемую муть нужно имень квалификацию выше.