Здесь согласен с тем, что...

...

В обсуждаемых С++ и D вам не нужно реализовывать ООП, вы им просто пользуетесь.

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

Например, при написании какого-либо небольшого утиля, заточенного на (например) множественное копирование файлов по ftp между различными хостами через один сервер, нам объекты не будут помогать, они будут мешать (в терминах BSD sockets задача решается «на раз»). Можно, конечно, и на С++ написать в «стиле С», но не нужно, иначе тогда какой смысл в С++ и его классах?

И где здесь ооп?

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

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

Ну, каков вопрос, таков...

... и ответ.

И где здесь ооп?

И где его здесь нет? Спросил же — абстракцию и инкапсуляцию показать или сами догадаетесь? )))

абстракцию и инкапсуляцию

Промыли голову плюсами и джавами? Один мужик, Алан Кей, считает что ооп совсем не в этом.

Не понял вопроса...

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

Конкретная задача - написать функцию a, которая при вызове a(1+1) принимает аргументом не результат выражения, а само выражение и может вычислить его когда захочет, или не вычислять вообще.

Ага...

... читал. А другой мужик вообще в ООП несколько разочарован. «Апелляции к авторитетам» не интересны.

Каковы ограничения на...

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

хотя бы потому, что пространства имён, raii, шаблоны, стандартные контейнеры и пр. не имеют никакого отношения к ООП, но делают программирование приятнее.

... и здесь мы (чуть дальше) дойдём до «выразительности кода» и прочих сложно-сопоставляемых вещей. Если уж мы заговорили о:

но делают программирование приятнее.

приятностях в программировании. А кто-то фанатеет от экономичности кода. Ему приятнее обходится без спорных с его точки зрения усовершенствований. Этот кто-то неправ?

loz, продолжим завтра. Сегодня уже поздновато для меня.

Ну Гебриел оценивает ооп, а Кей, как один из отцов, объясняет что это вобще такое.

Синтаксические есть?

Ну очевидно это любая форма языка.

Надо ли разделять случаи «1+1» и «1 + 1»

Если они разделяются в языке.

По какому критерию функция будет вычислять или будет отказываться вычислить выражение?

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

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

ООП было до Кея, более того, в С++(а соответственно и в Java, C# и многие другие языки) ООП пришло из Симулы, к которой Кей не имел никакого отношения. А если смотреть на результат, то смалтолк как был маргинальщиной, так ей и остался...

Он тоже не нужен?

Ещё один велосипед не нужен.

Inheritance

Если бы это было наследование, то такой код был бы валиден:

struct derived d;
struct base *bp = &d;

Method Polymorphism

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

О да! Тут вполне правильно написано все http://dlang.ru/Why-D-is-Better

Жгут!!! D! Продакшен!!! Хочу еще!!!!!

О да! Тут вполне правильно написано все http://dlang.ru/Why-D-is-Better

Жгут!!!

Да прямо напалмом. Вот это вообще порвало на кусочки:

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

Авторы в какой-то другой реальности живут.

Легендарные 5000 строк? Александреску написал что именно там было?

Примерно то, что может быть в 20000-50000 строчках на С++.

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

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

Т.к. Ди стоит на порядок выше,

Сам по себе этот факт еще не означает, что

то и подход должен быть другой

Жгут!!! D! Продакшен!!! Хочу еще!!!!!

По ссылке много странного, конечно, но что вас смущает в сочетании «D» + «продакшен»? (кроме того, что такого слова не существует)

Вы прикалываетесь?

Вот пример новости о D: Вышла очередная референсная реализация компиляторов языков D1 и D2

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

Примерно то, что может быть в 20000-50000 строчках на С++.

Ну еруда ведь. К сожалению, D не даёт такого заметного сокращения.

Вы прикалываетесь?
Вот пример новости о D: Вышла очередная референсная реализация компиляторов языков D1 и D2

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

Ну вы даете. Новость то двухлетней давности. Вполне возможно Ди использовать для продакшена. Только вот не во всех сферах - это да. Накидать быстренько форму для доступа к БД для офиса - для этого есть более лучшие инструменты. А тот же сайт - вполне люди пишут, и все летает говорят (сам не писал, не проверял, но с людьми общался - в том числе и на заказ пишут). vibe.d (фреймворк для async io), кстати, один из ярких примеров возможностей языка.

Ну вы даете. Новость то двухлетней давности.

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

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

Я как бы работаю в компании, которая использует D в качестве основного языка уже более трёх лет

Именно D2?

Именно D2?

D1, в процессе перехода на D2 (пока используется в части внутреннего инструментария). А это что-то _радикально_ меняет?

D1 [...] А это что-то _радикально_ меняет?

В D1 давно не делается breaking changes, а в D2 - постоянно. Считать ли это «радикальным» - не знаю.

В D1 давно не делается breaking changes, а в D2 - постоянно. Считать ли это «радикальным» - не знаю.

На самом деле, в D2 уже довольно давно нет настоящих breaking changes (почти все нынешние случаи это починка accepts-invalid багов), а D1 от изменений отнюдь не избавлен, так как некоторые коммиты идут через cherry-pick в соответствующую ветку.

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

Вот новых программистов найти трудно, это ощутимая проблема.

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

Вопервых, желаю что бы вы не «как бы работали», а работали. :) Во вторых 3 года. За этот срок нормальный проект только подойдет к завершающей стадии. Пока он один - никакие изменения не страшны. Если таких проектов десяток - будут проблемы. У множества мелких проектов проблем то же быть не должно, в случае если надо будет что-то изменить, а язык уже поменялся, просто переписываешь и все. И да - это не продакшен. Это наколенное макетирование. В принципе, и на нем можно деньги зарабатывать.

За этот срок нормальный проект только подойдет к завершающей стадии.

~3 года этот тот срок, который система используется на живых серверах и продаётся. И да, это нормальный срок для разработки на C++. Для D нормальные сроки в несколько раз меньше. Впрочем, изначальные прототипы я игнорирую.

Чтобы не продолжать домысливать, то, чего нет - http://www.sociomantic.com

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

Я пишу на Ди начиная с 2.057 версии и да, бывает, что код не собирается новой версией. Как например недавно перешел на 2.064 и он отказался собирать один проект (из нескольких). Было сильное нежелание разбираться что да как, но пришлось и оказалось, что был костыль и он на самом деле был не нужен. Я даже не знаю, жаловаться на это или наоборот радоваться что компилятор стал строже?

Были пару раз изменения которые заставили готовый код модифицировать в связи с удалением deprecated кода, но они заняли немного времени. С каждым релизом компилятор становится лучше, а с breaking changes я фактически не сталкивался. Это я еще раз к тому, что вы сами пробовали писать на Ди?

Я пишу на Ди начиная с 2.057 версии и да, бывает, что код не собирается новой версией. Как например недавно перешел на 2.064 и он отказался собирать один проект (из нескольких).

Я пишу с 2010 года, версия, кажется 2.048. С тех пор была дюжина изменений, которые приводили к некомпилируемости кода. Большинство из них я могу понять, хот некоторые не очень удобны. Но то, что теперь многие математические функции не хотят работать с переменными целых типов и приходится писать явное конвертирование в real, мне не очень понятно.

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

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

Сам я Go не пробовал, но люди утверждают, что он более простой, причем заметнее. Но и по возможностям в целом уступает. Еще читал такую оценку, что Google не стоит за разработкой языка, такой цели у них не было, просто гугл в свое время (сейчас вроде лавочку они прикрывают) разрешал сотрудникам работать над личными проектами и это как раз личный проект некоторых инженеров гугл. Что многое объясняет. В любом случае нужно больше языков, хороших и разных. :)

Еще читал такую оценку, что Google не стоит за разработкой языка

Еще как стоит. В Google есть люди, которые на full-time занимаются языком Go.

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

Нет. На нем проектов я не далал. Только смотрел. Многое понравилось. Но мои вкусовые ощущения значения не имеют.

Обязательно нужно отрубить себе голову, что бы убедиться что это плохо?

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

Я пишу с 2010 года, версия, кажется 2.048. С тех пор была дюжина изменений, которые приводили к некомпилируемости кода.

А что именно пишете, если не секрет?

Еще как стоит. В Google есть люди, которые на full-time >занимаются языком Go.

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

Обязательно нужно отрубить себе голову, что бы убедиться что это >плохо?

Обязательно о теплых странах судить по книжкам или лучше все-таки самому съездить? И сравнивать разработку на Ди с отрубанием головы это вы сильно переборщили. Все намного безопаснее.

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

В том то и дело, что люди разные. И ваше утверждение про breaking changes которые мешают работать при том что сами вы даже не пробовали в этом свете выглядит беспочвенным. Особенно учитывая, что его уже используют в продакшене и не D3, а D1. Кому надо - те делают, кому не надо - ищут причины. Вот и все.

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

Вообще-то между «не стоял» и «не стоит» очень большая разница :)

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

В итоге единственное что важно - это то, что D поставленную задачу решил. А всё остальное - сильная форумная аналитика в поисках идеала :)

Вообще-то между «не стоял» и «не стоит» очень большая разница :)

Согласен, формулировка была неверной. :)