C++0X vs D programming lang
От: Аноним  
Дата: 16.11.08 11:22
Оценка: :)))
Просто интересно мнение что будет следующим мэйн-стримом: C++0X или язык D?

17.11.08 18:17: Перенесено модератором из 'C/C++' — Кодт
Re: C++0X vs D programming lang
От: alexeiz  
Дата: 16.11.08 11:25
Оценка: +8 :)
Здравствуйте, Аноним, Вы писали:

А>Просто интересно мнение что будет следующим мэйн-стримом: C++0X или язык D?


Ответ простой. Мэйн-стримом будет продолжать оставаться подмножество C++, этакий C с классами.
Re[2]: C++0X vs D programming lang
От: anonim_44ax  
Дата: 16.11.08 11:38
Оценка: :)
К сожалению, согласен.
На мой взгляд, довольно большое количество компаний зарабатывает свой основной капитал на поддержке существующих и зачастую довольно старых проектов. Часто бывает, что эта поддержка состоит в банальном bug-fixing-е плюс осмотрительное и очень осторожное додавание новых возможностей. В результате проект, либо имеет вид эдакого разношёрстного зверя (там тебе и Си начала 90-х, и MPL с супер-шаблонами), либо превращается в "Си Плюс проект" (это уже не Си, но еще и не С++).
Re: C++0X vs D programming lang
От: Roman Odaisky Украина  
Дата: 16.11.08 11:39
Оценка: 1 (1) +8 -1
Здравствуйте, Аноним, Вы писали:

А>Просто интересно мнение что будет следующим мэйн-стримом: C++0X или язык D?


Какой C? Какой D?

Мэйнстримом будут Java, .NET, Python и т. п.
До последнего не верил в пирамиду Лебедева.
Re[2]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 16.11.08 11:41
Оценка: :))) :))) :)))
Здравствуйте, Roman Odaisky, Вы писали:
RO>Мэйнстримом будут Java, .NET, Python и т. п.

Nemerle, непременно Nemerle.
Re[3]: C++0X vs D programming lang
От: alexeiz  
Дата: 16.11.08 11:44
Оценка: :))) :))) :))) :))) :)))
Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Roman Odaisky, Вы писали:

RO>>Мэйнстримом будут Java, .NET, Python и т. п.

MC>Nemerle, непременно Nemerle.


Не размахивай красной тряпкой. Сейчас как понабежит стадо розовых слонов!
Re[3]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 16.11.08 18:09
Оценка:
Мне тут кто минус поставил — видимо, у человека зуб на немерле. Между тем, особенности, изначально присущие функциональным языкам постепенно входят в мейнстрим, и это замечательный неизбежный факт.
Re[4]: C++0X vs D programming lang
От: VoidEx  
Дата: 16.11.08 19:56
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

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


У меня зуб не на Немерле, а на тех, кто слава богу не сбежался
Удалю, если минус имеет для тебя значение.
Re[4]: C++0X vs D programming lang
От: MasterZiv СССР  
Дата: 16.11.08 20:16
Оценка:
alexeiz пишет:

> RO>>Мэйнстримом будут Java, .NET, Python и т. п.

>
> MC>Nemerle, непременно Nemerle.
>
> Не размахивай красной тряпкой. Сейчас как понабежит стадо розовых слонов!

уже позно. Как почётный розовый слон официально заявлаю:
следующим мейнстримом будет CommonLisp.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 16.11.08 20:39
Оценка:
Здравствуйте, VoidEx, Вы писали:
VE>Удалю, если минус имеет для тебя значение.

Да не, не имеет, просто как правило за оценкой стоит определенное мнение, и его как раз хотелось услышать.
Re[5]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 16.11.08 20:45
Оценка:
Здравствуйте, MasterZiv, Вы писали:
MZ>следующим мейнстримом будет CommonLisp.

Эх, не думаю... Все фишки CL и схемы уже расхватали дизайнеры других языков. Ну или почти все (Где еще есть динамическая область видимости переменных? Хотя это, конечно, всего лишь маленький кусочек сахара).
Re[6]: Лисп умер?
От: Mr.Cat  
Дата: 16.11.08 20:47
Оценка:
Блин, написал и ужаснулся. Даже форумы вместо лиспа уже nemerle троллят. Куда мир катится?..
Re[3]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 16.11.08 21:21
Оценка: :)
Здравствуйте, anonim_44ax, Вы писали:

_>К сожалению, согласен.

Почему "к сожалению"?
Цель программирования-то не код покруче навернуть, а разработать что-то нужное и полезное.
IMHO, майнстрим -- это вообще что-то типа VB было, а теперь дотнет стал
Ну да если говорить о приложениях, которые не по месту пишут, то тут майнстрим медленно переползает от чистого С к "С слегка приплюснутому"...
Ну так это же от практических нужд идёт-то, так что наверное и хорошо...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: Почему "к сожалению"? :)
От: alexeiz  
Дата: 17.11.08 03:11
Оценка: +2 -2 :)
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, anonim_44ax, Вы писали:


_>>К сожалению, согласен.

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

К сожалению, потому что код писать с применением высокоуровневых возможностей языка проще. Но эти возможности большинство не знает. Поэтому если ты в команде, где никто не знает что такое функтор (забудьте о boost::function), и любое применение функтора их в шок бросает, то приходится использовать тупые указатели на функции. А это гемор, не говоря уже о том, что просто тошнить начинает от такого подхода.

Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.
Re[2]: C++0X vs D programming lang
От: Аноним  
Дата: 17.11.08 06:30
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Аноним, Вы писали:


А>>Просто интересно мнение что будет следующим мэйн-стримом: C++0X или язык D?


RO>Какой C? Какой D?


RO>Мэйнстримом будут Java, .NET, Python и т. п.


А может на JavaScript будем драйверы писать?
Re[5]: Почему "к сожалению"? :)
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 17.11.08 07:06
Оценка: +2 -2 :))
Здравствуйте, alexeiz, Вы писали:

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

A>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.

А что в плохого в простых указателях на функции? Код должен быть простой настолько, насколько это возможно, настолько простой, чтоб в нем мог легко разобраться даже довольно слабый разработчик.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[6]: Почему "к сожалению"? :)
От: byleas  
Дата: 17.11.08 07:35
Оценка:
Здравствуйте, kaa.python, Вы писали:

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

Viva la C?
Re[7]: Почему "к сожалению"? :)
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 17.11.08 07:56
Оценка: 1 (1) +3 :)
Здравствуйте, byleas, Вы писали:

B>Viva la C?


Viva проект в срок, с использованием тех ресурсов, которые на данный момент доступны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[3]: C++0X vs D programming lang
От: VoidEx  
Дата: 17.11.08 08:57
Оценка: 1 (1) +2
Здравствуйте, Аноним, Вы писали:

А>А может на JavaScript будем драйверы писать?


Драйверы решили пойти в мейнстрим?
Re[3]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 17.11.08 09:17
Оценка: 1 (1)
Здравствуйте, Аноним, Вы писали:
А>А может на JavaScript будем драйверы писать?

На C# когда на сингулярити пересядем.
Re[6]: Почему "к сожалению"? :)
От: Mr.Cat  
Дата: 17.11.08 09:29
Оценка: +1
Здравствуйте, kaa.python, Вы писали:
KP>Код должен быть простой настолько, насколько это возможно, настолько простой, чтоб в нем мог легко разобраться даже довольно слабый разработчик.

Тем не менее, иногда более сложные инструменты (после их изучения, конечно) позволяют сократить трудозатраты на кодинг. Не согласны?
Re[7]: Почему "к сожалению"? :)
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 17.11.08 09:59
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Тем не менее, иногда более сложные инструменты (после их изучения, конечно) позволяют сократить трудозатраты на кодинг. Не согласны?


Могут сократить. Могут увеличить. Но, обычно, проект нужен в лучшем случае прямо сейчас. Соответственно как не крути, код должен быть максимально простым, т.к. рассчитывать на то, что все специалисты в компании знают навороченные и сложные инструменты сложно (если конечно не в гугле или майкрософте работаешь).
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[6]: Почему "к сожалению"? :)
От: alexeiz  
Дата: 17.11.08 10:05
Оценка: 8 (3) +2
Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, alexeiz, Вы писали:


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

A>>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.

KP>А что в плохого в простых указателях на функции?


Эээ, с чего изволите начать?
* состояние в указатель на функцию не положишь, нужно передавать отдельно.
* состояние передается обычно как void*, нужно приводить к нужному типу с помощью unsafe C-style cast-а, type-safety никакая.
* если у объекта состояния еще есть деструктор, который надо вызвать, когда ... а когда, кстати? — это еще прийдется выяснить для каждого конкретного случая. С boost::function все элементарно.
* параметры функции должны совпадать с параметрами, указанными в типе указателя на функцию. В boost::function могут производится конвертация параметров.
* по удобству использования указатели на функцию явно проигрывают boost::function, благодаря тому, что function — это гораздо более высокоуровневая конструкция, чем тупой указатель на фукцию.

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

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


В результате получаем, что с boost::function код упрощается до невозможности. Ан нет! Мы хотим указатели на функции и все тут! Уберите эти шаблоны! Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!
Re[7]: Почему "к сожалению"? :)
От: alexeiz  
Дата: 17.11.08 10:10
Оценка: 1 (1) +6 :))) :))
Здравствуйте, alexeiz, Вы писали:

A>Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!


Добавлю: а потом еще и жалуются — "C++ такой низкоуровневый язык, такой низкоуровневый! У него столько проблем. Вы только посмотрите, какие в нем тупые указатели на функции! Пора на новый язык переходить."
Re[7]: Почему "к сожалению"? :)
От: Ocelot  
Дата: 17.11.08 10:40
Оценка: +1 -1
Здравствуйте, Mr.Cat, Вы писали:

MC>Тем не менее, иногда более сложные инструменты (после их изучения, конечно) позволяют сократить трудозатраты на кодинг. Не согласны?


Именно что трудозатраты и именно что на кодинг.
Более опытному специалисту, освоившему более сложные инструменты и способному все сделать быстрее, придется заплатить больше.
А насколько сложнее станет тестирование? А саппорт?
Re[4]: C++0X vs D programming lang
От: Roman Odaisky Украина  
Дата: 17.11.08 14:23
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

А>>А может на JavaScript будем драйверы писать?

MC>На C# когда на сингулярити пересядем. ;)

Ну и пересаживайтесь, а наше всё — это Hurd.
До последнего не верил в пирамиду Лебедева.
Re[5]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 17.11.08 14:46
Оценка: +1
Здравствуйте, alexeiz, Вы писали:

E>>Цель программирования-то не код покруче навернуть, а разработать что-то нужное и полезное.

A>К сожалению, потому что код писать с применением высокоуровневых возможностей языка проще. Но эти возможности большинство не знает.
Ну мой опыт показывает мне, что чем более высокоуровневыми конструкциями С++ пользуются разработчики, тем легче его написать WriteOnly. В результате либо падает качество разработки (те же спецы + продвинутые конструкции), либо растёт её цена (продвинутые конструкции + более крутые, и следовательно дорогие разработчики)
Фишка в том, что некоторые задачи проще решать при помощи функторов, но таких задач не много, и это не повод усложнять и, следовательно, удорожать весь остальной код.
A>Поэтому если ты в команде, где никто не знает что такое функтор (забудьте о boost::function), и любое применение функтора их в шок бросает, то приходится использовать тупые указатели на функции. А это гемор, не говоря уже о том, что просто тошнить начинает от такого подхода.
IMHO, в функторах нет ничего особенно крутого, но и в указателях на функции нет ничего плохого. Наоборот, при использовании указателей на функции и интерфейсов уменьшается количество шаблонного кода, например...

A>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.

Ну создавай свой бизнес и вперёд...
Только ты быстро очень столкнёшься с экономической неэффективностью подобных, отрентированных на "красоту кода" решений...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 17.11.08 14:47
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Могут сократить. Могут увеличить. Но, обычно, проект нужен в лучшем случае прямо сейчас. Соответственно как не крути, код должен быть максимально простым, т.к. рассчитывать на то, что все специалисты в компании знают навороченные и сложные инструменты сложно (если конечно не в гугле или майкрософте работаешь).


А разве в MS используют особо продвинутые инструменты?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 17.11.08 15:00
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>* состояние в указатель на функцию не положишь, нужно передавать отдельно.

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

A>* состояние передается обычно как void*, нужно приводить к нужному типу с помощью unsafe C-style cast-а, type-safety никакая.

Юзай интерфейсы. Интерфейсы в твоей компании использовать ведь не запрещено? void* обычно используют в чисто С'шном API. Вдруг теми же сервисами не только из C++ пользуются?

A>* если у объекта состояния еще есть деструктор, который надо вызвать, когда ... а когда, кстати? — это еще прийдется выяснить для каждого конкретного случая. С boost::function все элементарно.

1) IMHO, нетривильный деструктор функтора -- не очень хорошо.
2) Вариант с интерфейсами просто и понятно решает проблемы с владением. Например объект, реализующий интерфейс может быть автоматическим в месите вызова
3) Я бы не стал, в случае деструктора функтора, делающего что-то нетривильное (например закрывающего файл), звать его как-то неявно. Типа код вида //// Evaluation.h
struct IEvaluator {
    virtual int GetEvaluation( /* params */ ) const  = 0;
};
extern int UseEvaluator( const IEvaluator* );
// Мой файл
class ByFileEvaluator : public IEvaluator {
    //        тут реализация
} 
void foo()
{
    ByFileEvaluator evaluator( "data.file" );
    UseEvaluator( &evaluator );   
}
простой, понятный, и всем ясно когда файл откроют, когда закроют и что будет, если что-то где-то обламается...

A>* параметры функции должны совпадать с параметрами, указанными в типе указателя на функцию. В boost::function могут производится конвертация параметров.

Опять же, не ясно зачем это так надо.

A>* по удобству использования указатели на функцию явно проигрывают boost::function, благодаря тому, что function — это гораздо более высокоуровневая конструкция, чем тупой указатель на фукцию.

Зато по удобству отладки/поддержки лучше средства традиционные...
Ну тупо в отладчике хорошо вижно, лог проще впихнуть, компиляция быстрее и т. д

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


A>В результате получаем, что с boost::function код упрощается до невозможности. Ан нет! Мы хотим указатели на функции и все тут! Уберите эти шаблоны! Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!


Почему, как без шаблонов, так сразу не С++?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Почему "к сожалению"? :)
От: Didro Россия home~pages
Дата: 17.11.08 15:42
Оценка: +1 -3
Здравствуйте, alexeiz, Вы писали:

A>>Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!


A>Добавлю: а потом еще и жалуются — "C++ такой низкоуровневый язык, такой низкоуровневый! У него столько проблем. Вы только посмотрите, какие в нем тупые указатели на функции! Пора на новый язык переходить."


Все оно конечно так, да не так. Поддержка абстракций на уровне библиотек (ala boost) и на уровне языка — это две большие разницы.
И именно поэтому "пора на новый язык переходить".

Если язык А поддерживает абстракцию F как "first class citizens" ("как родную" другими словами), а язык B сам по себе не поддерживает F — а только через библиотеки, то при прочих равных работать с F будет удобнее в А.
Re[5]: C++0X vs D programming lang
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 17.11.08 16:25
Оценка: :)
Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Mr.Cat, Вы писали:


А>>>А может на JavaScript будем драйверы писать?

MC>>На C# когда на сингулярити пересядем.

RO>Ну и пересаживайтесь, а наше всё — это Hurd.


Вот именно что "все". В смысле "все, приплыли". А мы вот пересядем, и дальше поплывем :-Р

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re: C++0X vs D programming lang
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.11.08 16:28
Оценка: +3
Здравствуйте, <Аноним>, Вы писали:

А>Просто интересно мнение что будет следующим мэйн-стримом: C++0X или язык D?


Ну если говорить о мейнстриме в unmanaged мире, то, безусловно, первый. Поддержка его элементов уже скоро будет в том же VS 2010, а вот для D есть только пара компиляторов и оба в неособо стабильном состоянии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[9]: Почему "к сожалению"? :)
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.11.08 16:28
Оценка:
Здравствуйте, Erop, Вы писали:

E>А разве в MS используют особо продвинутые инструменты?


Используют. МС большой.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: Почему "к сожалению"? :)
От: FR  
Дата: 17.11.08 17:31
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>В результате получаем, что с boost::function код упрощается до невозможности. Ан нет! Мы хотим указатели на функции и все тут! Уберите эти шаблоны! Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!


На D подобный код еще больше упрощается, вот только все равно он будет написан на C++
Re[10]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 17.11.08 19:09
Оценка:
Здравствуйте, AndrewVK, Вы писали:

E>>А разве в MS используют особо продвинутые инструменты?

AVK>Используют. МС большой.
Ну в смысле, что "матан большой, что-нибудь да не знает", понятно...
Но масоово разве используют?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 17.11.08 19:11
Оценка: +1
Здравствуйте, Didro, Вы писали:

D>Если язык А поддерживает абстракцию F как "first class citizens" ("как родную" другими словами), а язык B сам по себе не поддерживает F — а только через библиотеки, то при прочих равных работать с F будет удобнее в А.


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

Если хочешь возразить, то можешь попробовать проиллюстрировать свои рассуждения на примере языка форт...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: Добрый, но бесплатный совет...
От: Erop Россия  
Дата: 17.11.08 19:13
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.


Советую обратить внимание на автора этого сообщения
Автор: Alexander G
Дата: 17.11.08
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Почему "к сожалению"? :)
От: byleas  
Дата: 17.11.08 19:19
Оценка: 1 (1) +1
Здравствуйте, kaa.python, Вы писали:

KP>Viva проект в срок, с использованием тех ресурсов, которые на данный момент доступны.

С этим никто и не спорит. Меня удручает другое — когда этим "довольно слабым разработчикам" не (дают/разрешают/предоставляют возможность) повышать квалификацию, в результате общий уровень команды так и остаётся на уровне "Си начала 90х" или "Си плюс проект". Понятно, что есть ещё и самообразование, но и компания ведь должна быть заинтересована в повышении квалификации работников. Оффтоп, но наболело
Re[10]: Почему "к сожалению"? :)
От: Didro Россия home~pages
Дата: 17.11.08 19:20
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Didro, Вы писали:


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


Уж тогда не форт, а Лисп или Немерле (по нарастающей типобезопасности макросистем язков).
Да, макросы в языке зачастую стирают грань между библиотекой и языком,

но мне кажется, мы говорили про C++.
Re[9]: Почему "к сожалению"? :)
От: byleas  
Дата: 17.11.08 19:34
Оценка:
Здравствуйте, Didro, Вы писали:

D>Если язык А поддерживает абстракцию F как "first class citizens" ("как родную" другими словами), а язык B сам по себе не поддерживает F — а только через библиотеки, то при прочих равных работать с F будет удобнее в А.

Зато язык В получается более общим. Хотя насчёт "удобнее" согласен.
Re[9]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 17.11.08 20:08
Оценка: 1 (1) +3
Здравствуйте, byleas, Вы писали:

B>С этим никто и не спорит. Меня удручает другое — когда этим "довольно слабым разработчикам" не (дают/разрешают/предоставляют возможность) повышать квалификацию, в результате общий уровень команды так и остаётся на уровне "Си начала 90х" или "Си плюс проект". Понятно, что есть ещё и самообразование, но и компания ведь должна быть заинтересована в повышении квалификации работников. Оффтоп, но наболело


Если кратко, то поинт состоит в том, чтобы совершенствоваться не в овладениями шаблонами С++, а в овладении искусством писать хорошие программы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Почему "к сожалению"? :)
От: MescalitoPeyot Украина  
Дата: 17.11.08 20:09
Оценка: +1 -1
Здравствуйте, kaa.python, Вы писали:

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


А кого вы подразумеваете под "слабыми разработчиками"? Если юниоров, то вообще говоря это они должны повышать свой уровень, чтоб приблизиться к опытным разработчикам, а не наоборот. Если же имеете в виду русских индусов, то это имхо может быть справедливо исключительно для аутсорсинга (с натяжкой) и госконтор
... << RSDN@Home 1 alpha 3 rev. 0>>
Re[11]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 17.11.08 20:10
Оценка: +1 :)
Здравствуйте, Didro, Вы писали:

D>но мне кажется, мы говорили про C++.

Люди, окончательно сломавште свой мозг, в процессе работы над стнадартами С++, вроде как считают, что stl -- часть языка, поставляемая с компилятором. Авторы компиляторов вольны не писать stl на С++, а зашить это всё внутрь компилятора, просто от чего-то не хотят
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Почему "к сожалению"? :)
От: Mr.Cat  
Дата: 17.11.08 20:10
Оценка:
Здравствуйте, Ocelot, Вы писали:

MC>>Тем не менее, иногда более сложные инструменты (после их изучения, конечно) позволяют сократить трудозатраты на кодинг. Не согласны?

O>Именно что трудозатраты и именно что на кодинг.
Как будто средства языка и библиотек могут сократить трудозатраты на что-то еще.

O>Более опытному специалисту, освоившему более сложные инструменты и способному все сделать быстрее, придется заплатить больше ... А саппорт?

А вот тут уже надо думать, кто будет писать код, кто будет править в нем баги и т.п.

Например, вот c-smile, в одиночку ну или в небольшой команде (возможно, я ошибаюсь, но пример показательный) делает свой htmlayout и, по его словам, там используется "хардкорный" (как-то так он сам выражался) C++. Вполне логично, т.к. ему самому такой стиль только пользу приносит, а всяким индусам лазить в код ни к чему.

Если же в проекте код вперемешку пишется разными людьми: удаленщиками. аутсорсерами, периодически меняющимисяштатными кодерами и т.п. — то, конечно, придется использовать инструменты, знакомые всем. И то, не знаю, как там с аутсорсерами, но мы, студенты, вполне обучаемы всяким премудростям, от шаблонов до монад — и особо много за работу не берем.

O>А насколько сложнее станет тестирование?

А почему тестирование должно стать сложнее?
Re[11]: Почему "к сожалению"? :)
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.11.08 21:25
Оценка:
Здравствуйте, Erop, Вы писали:

E>Но масоово разве используют?


Массово и создание нетривиального кода плохо совместимы. Все зависит от команды. Если команда обладает высокой квалификацией (а такое в МС не редкость), то и инструментом она пользуется весьма профессионально.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.08 22:20
Оценка: -2
Здравствуйте, Аноним, Вы писали:

А>Просто интересно мнение что будет следующим мэйн-стримом: C++0X или язык D?


Если коротко...
C++ уже не будет мэйнстримом. D еще не будет мэйнстримом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[6]: Почему "к сожалению"? :)
От: yumi  
Дата: 18.11.08 00:00
Оценка: +1
Здравствуйте, kaa.python, Вы писали:

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


Да все верно говоришь, код должен быть настолько простым насколько это возможно, но не проще А именно, как раз использование высокоуровневых средств таких как, например, вышеупомянутый функтор позволяют код делать коротким, простым и понятным.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[5]: Почему "к сожалению"? :)
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.11.08 02:35
Оценка: -2 :))
Здравствуйте, alexeiz, Вы писали:

A>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.


А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов
Re[2]: C++0X vs D programming lang
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.11.08 02:39
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Мэйнстримом будут Java, .NET, Python и т. п.


Чтобы стать мейнстримом, Питону очень не хватает возможности кросс-платформенно создавать нормальные standalone программы.
Re[6]: Почему "к сожалению"? :)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 18.11.08 02:55
Оценка:
Здравствуйте, Pzz, Вы писали:

A>>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.

Pzz>А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов

За что, боярин?!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: C++0X vs D programming lang
От: FR  
Дата: 18.11.08 05:59
Оценка:
Здравствуйте, Pzz, Вы писали:

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


NET'у этого же самого тоже тогда не хватает
А у питона такая возможность есть, даже из коробки.
Re[7]: Лисп умер?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 18.11.08 06:24
Оценка: +1
Здравствуйте, Mr.Cat, Вы писали:

MC>Блин, написал и ужаснулся. Даже форумы вместо лиспа уже nemerle троллят. Куда мир катится?..


А что, лисперы много троллили по форумам?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: C++0X vs D programming lang
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 18.11.08 06:27
Оценка: +1
Здравствуйте, MasterZiv, Вы писали:

>> Не размахивай красной тряпкой. Сейчас как понабежит стадо розовых слонов!

MZ>уже позно. Как почётный розовый слон официально заявлаю:
MZ>следующим мейнстримом будет CommonLisp.

Ужас. Нет уж, пускай мейнстрим наперегонки барахтается в своих самонаилучших языках по маковкиного заговения. Зато весело: каждый год — революция. Лепота и ништяк!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: C++0X vs D programming lang
От: Трурль  
Дата: 18.11.08 07:33
Оценка:
Здравствуйте, Mr.Cat, Вы писали:


MC>Где еще есть динамическая область видимости переменных? Хотя это, конечно, всего лишь маленький кусочек сахара.


В мейнстриме 80х под названием xBase . А вот называть ли это сахаром.
Re[4]: C++0X vs D programming lang
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.11.08 09:42
Оценка:
Здравствуйте, FR, Вы писали:

FR>NET'у этого же самого тоже тогда не хватает


У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.

FR>А у питона такая возможность есть, даже из коробки.


А вы этой возможностью пользоваться пробовали, или вы теоретик?
Re[9]: Почему "к сожалению"? :)
От: alexeiz  
Дата: 18.11.08 10:01
Оценка: 16 (4)
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, kaa.python, Вы писали:


KP>>Могут сократить. Могут увеличить. Но, обычно, проект нужен в лучшем случае прямо сейчас. Соответственно как не крути, код должен быть максимально простым, т.к. рассчитывать на то, что все специалисты в компании знают навороченные и сложные инструменты сложно (если конечно не в гугле или майкрософте работаешь).


E>А разве в MS используют особо продвинутые инструменты?


В майкрософте не используют не только особо продвинутые инструменты, но и сколько-либо мало-мальски продвинутые инструменты. В таких крупных группах как Windows, DevDiv, Windows Mobile (это те, о которых мне известно не понаслышке) C++ используется на уровне C with classes. Office, Search, Exchange — то же самое. SQL — не знаю, но буду сильно удивлен, если там что-то по другому. Где-то что-то слышали о RAII. Исключения используют еще меньше. Коды возврата повсеместно. Свою собственную реализацию STL, поставляемую с VC++ нигде не используют. Пишут свои велосипеды, кривые, без исключений. Может доходить до смешного: серьезный проект, делающий важные и сложные вещи, в котором нет даже и намека на библиотеку контейнеров (внутреннюю или внешнюю к проекту). О бусте и речи не идет (и не удивительно, для начала неплохо было бы STL задействовать). Хотя вру. Слышал, что буст использовали один раз где-то в VS setup-е и еще где-то по мелочам. Under the radar, так сказать. Но буст проблематичен, у него open sauce лицензия. А вот TR1 свой собственный есть — бери не хочу. Не берут.
Re[7]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 18.11.08 10:03
Оценка:
Здравствуйте, Трурль, Вы писали:
Т>А вот называть ли это сахаром.

Ну, ну я не имею в виду, что это синтаксический сахар. Просто удобная, но не особо важная фича.
Re[5]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 18.11.08 10:09
Оценка:
Здравствуйте, Pzz, Вы писали:
Pzz>У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.
Как будто за питоном не стоит гугл. Просто область интересов гугла — по большей части веб. Потому пришествия питона на виндовые десктопы пока не состоялось.

Pzz>А вы этой возможностью пользоваться пробовали, или вы теоретик?

А что конкретно у питона Вас не устраивает? То, что под виндой надо отдельно ставить питоновский рантайм и все дополнительные библиотеки (тогда как под линухом питон как правило притягивается по зависимости с DE, а все дополнительные вещи как правило лежат в репозитории)? Или что-то другое?
Re[6]: C++0X vs D programming lang
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.11.08 10:13
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

Pzz>>У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.

MC>Как будто за питоном не стоит гугл. Просто область интересов гугла — по большей части веб. Потому пришествия питона на виндовые десктопы пока не состоялось.

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

Pzz>>А вы этой возможностью пользоваться пробовали, или вы теоретик?

MC>А что конкретно у питона Вас не устраивает? То, что под виндой надо отдельно ставить питоновский рантайм и все дополнительные библиотеки (тогда как под линухом питон как правило притягивается по зависимости с DE, а все дополнительные вещи как правило лежат в репозитории)? Или что-то другое?

У меня есть простая задача: мне надо дистрибутировать программу в собранном виде простым нормальным пользователям. Чтобы скачал-поставил-работает.

Можно по пунктам, как вы предлагаете эту задачу решать?
Re[10]: Почему "к сожалению"? :)
От: CreatorCray  
Дата: 18.11.08 10:19
Оценка: +1 -1
Здравствуйте, alexeiz, Вы писали:

A>C++ используется на уровне C with classes.

Ну еще чуть чуть темплейтами припорошить и будет как раз самое распространенное использование С++

A>Исключения используют еще меньше. Коды возврата повсеместно. Свою собственную реализацию STL, поставляемую с VC++ нигде не используют.

И в общем то правильно делают, если подумать.

A> Пишут свои велосипеды, кривые, без исключений.

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

A>А вот TR1 свой собственный есть — бери не хочу. Не берут.

Видимо тоже есть основания.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 18.11.08 10:26
Оценка:
Здравствуйте, Pzz, Вы писали:
Pzz>У меня есть простая задача: мне надо дистрибутировать программу в собранном виде простым нормальным пользователям. Чтобы скачал-поставил-работает.
Pzz>Можно по пунктам, как вы предлагаете эту задачу решать?

Под виндой:
1. Тащим рантайм с собой и юзаем его для запуска программы (а-ля komodo).
или
2. Берем msi-дистрибутив питона с python.org и включаем в инсталляционный пакет. Во время инсталляции проверяем, есть ли на компе питон нужной версии и, если нет, ставим.

Под линухом:
Собираем пакеты для нескольких дистрибутивов, в зависимостях указываем питон.
Re[8]: C++0X vs D programming lang
От: Трурль  
Дата: 18.11.08 11:02
Оценка: :)
Здравствуйте, Mr.Cat, Вы писали:

MC>Ну, ну я не имею в виду, что это синтаксический сахар. Просто удобная, но не особо важная фича.


А я имею в виду, что это совсем не сахар. Скорее, крысиный яд.
Re[9]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 18.11.08 11:24
Оценка:
Здравствуйте, Трурль, Вы писали:
Т>А я имею в виду, что это совсем не сахар. Скорее, крысиный яд.

Ну... никто ж не заставляет это использовать. Не нравится — не надо. Всего лишь еще один способ работы с глобальными мутабельными данными.
Re[2]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.11.08 13:38
Оценка: +1 :))) :))) :))) :))
Здравствуйте, VladD2, Вы писали:

VD>Если коротко...

VD>C++ уже не будет мэйнстримом. D еще не будет мэйнстримом.

Почитал тему... и только укрепился во мнении.

Ди не обсуждается вовсе. С++ обсуждается только вскользь. Зато, как всегда обсуждаются Nemerle, Python и даже VladD2. Хотя козалось бы причем тут VladD2?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[2]: C++0X vs D programming lang
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 18.11.08 14:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>C++ уже не будет мэйнстримом.

да он и сейчас, вроде как не мэйнстрим.

VD>D еще не будет мэйнстримом.

если создатели играться не бросят, то он вообще мэйнстримом не будет. хотя очень жаль, хотелось бы чего-то похожего на D, на замену плюсам.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[8]: C++0X vs D programming lang
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.11.08 15:18
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Под виндой:

MC>1. Тащим рантайм с собой и юзаем его для запуска программы (а-ля komodo).
MC>или
MC>2. Берем msi-дистрибутив питона с python.org и включаем в инсталляционный пакет. Во время инсталляции проверяем, есть ли на компе питон нужной версии и, если нет, ставим.

Под вендой как раз относительно просто. Там есть py2exe, он работает.

Идея с msi-дистрибутивом мне не кажется очень уж удачной: нет никаких гарантий, что никто не сломает мне мою питонию программу, поставив какой-нибудь 2.6 (не говоря уж о 3.0) поверх того 2.5, который я приволок с собой.

MC>Под линухом:

MC>Собираем пакеты для нескольких дистрибутивов, в зависимостях указываем питон.

Я не уверен, что бинарно скомпилированные пакеты выдержат локальный update питона. Никто вроде бинарной совместимости байт-кода не обещал.

Я не говорю уж о том, что немного потрахавшись, на C/C++ я соберу все же программу так, что единый бинарник будет работать на всех интересных мне платформах. И мне останется его только распаковать по-разному. А с Питоном действительно похоже что придется держать десяток дистрибутивов.
Re[7]: Почему "к сожалению"? :)
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.11.08 15:31
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

Pzz>>А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов


ГВ>За что, боярин?!


За дело!
Re[3]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.11.08 15:44
Оценка: +1 -2 :))) :))
Здравствуйте, kaa.python, Вы писали:

VD>>C++ уже не будет мэйнстримом.

KP>да он и сейчас, вроде как не мэйнстрим.

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

VD>>D еще не будет мэйнстримом.

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

На мой взгляд Ди бесперспективен. Останови автор его развитие и никто не будет его использовать. Развивай автор его далее и никто не будет его использовать просто потому, что никто не хочет использовать "нестабильный язык". Хотя про его нестабильность еще бабушка на двое сказала.

С точки зрения проектирования — это два языка урода. Если индустрии и нужено нечто новое, то не такое как Ди и уж точно не такое как С++Ох. Кстати, только сейчас понял глубинный смысл имени. Было в лом переключаться на английский по этому написал на русском... когда стал думать чем заменить 0x, понял что русские буквы О и ха подходят лучше всего. В общем, си плюс плюс ох. Или точнее ох, ох, ох...

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

ЗЫ

Извините, что вторгаюсь в это милое обсуждение Nemerle, Питоне и VladD2 с какими то мыслями о никому не интересных Ди и С++ .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[4]: C++0X vs D programming lang
От: CreatorCray  
Дата: 18.11.08 15:53
Оценка: 1 (1) :)
Здравствуйте, VladD2, Вы писали:

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

VD>С точки зрения проектирования — это два языка урода.
VD>В общем, си плюс плюс ох. Или точнее ох, ох, ох...
VD>Извините, что вторгаюсь в это милое обсуждение Nemerle, Питоне и VladD2 с какими то мыслями о никому не интересных Ди и С++ .

[читать голосом диктора с заставки к Fallout]
Vlad...
Vlad never changes...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.11.08 16:15
Оценка: :))
Здравствуйте, CreatorCray, Вы писали:

VD>>Извините, что вторгаюсь в это милое обсуждение Nemerle, Питоне и VladD2 с какими то мыслями о никому не интересных Ди и С++ .


CC>[читать голосом диктора с заставки к Fallout]

CC>Vlad...
CC>Vlad never changes...

Кстати, я же заранее извинился, что говорю по теме. Зачем меня в тягивать в споры о Владах?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[9]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 18.11.08 16:38
Оценка:
Здравствуйте, Pzz, Вы писали:
Pzz>Идея с msi-дистрибутивом мне не кажется очень уж удачной: нет никаких гарантий, что никто не сломает мне мою питонию программу, поставив какой-нибудь 2.6 (не говоря уж о 3.0) поверх того 2.5, который я приволок с собой.
2.6 вроде обратно совместим с 2.5 (если не включать 3.0-mode или как его там). 3.0 — другой продукт вообще. Как он уживается с 2.х — не знаю, но, думаю, уживается.

MC>>Под линухом:

MC>>Собираем пакеты для нескольких дистрибутивов, в зависимостях указываем питон.
Pzz>Я не уверен, что бинарно скомпилированные пакеты выдержат локальный update питона. Никто вроде бинарной совместимости байт-кода не обещал.
А, так Вы собрались исходники прятать? Тогда — действительно не знаю, как лучше поступить.

PS: Впрочем, в опенсорсном *nix python — уже мейнстрим.
Re[7]: C++0X vs D programming lang
От: Daevaorn Россия  
Дата: 18.11.08 16:39
Оценка: 2 (1)
Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Mr.Cat, Вы писали:


Pzz>>>У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.

MC>>Как будто за питоном не стоит гугл. Просто область интересов гугла — по большей части веб. Потому пришествия питона на виндовые десктопы пока не состоялось.

Pzz>Гугл может и любит питон внутри себя, но не продвигает его в качестве именно платформы для всех.


Вы ошибаетесь: http://code.google.com/appengine/
Re[4]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 18.11.08 16:42
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный).

Не совсем то, конечно, но Erlang вроде — как раз пример ФП + битодробления...

VD>Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++.

Да... Не похож.

VD>Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.

Массы вроде бы его приняли.
Re[5]: C++0X vs D programming lang
От: FR  
Дата: 18.11.08 17:00
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.


Так и за питоном сейчас тоже не маленькие компании стоят, например гугль.

FR>>А у питона такая возможность есть, даже из коробки.


Pzz>А вы этой возможностью пользоваться пробовали, или вы теоретик?


Около года выпускали продукт, потом когда py2exe стал достаточно стабильным перешли на него.
Кроме того собирал так же немало небольших утилиток.
Re[10]: C++0X vs D programming lang
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.11.08 17:08
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

Pzz>>Я не уверен, что бинарно скомпилированные пакеты выдержат локальный update питона. Никто вроде бинарной совместимости байт-кода не обещал.

MC>А, так Вы собрались исходники прятать? Тогда — действительно не знаю, как лучше поступить.

Собираюсь я их прятать или нет, это отдельный вопрос, но уж точно не хочу лишать пользователей возможности использовать precompiled byte code. И самостоятельно их компилировать не собираюсь заставлять.
Re[4]: C++0X vs D programming lang
От: FR  
Дата: 18.11.08 17:10
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>На мой взгляд Ди бесперспективен. Останови автор его развитие и никто не будет его использовать. Развивай автор его далее и никто не будет его использовать просто потому, что никто не хочет использовать "нестабильный язык". Хотя про его нестабильность еще бабушка на двое сказала.


Выше замени Ди на немерле

VD>С точки зрения проектирования — это два языка урода. Если индустрии и нужено нечто новое, то не такое как Ди и уж точно не такое как С++Ох. Кстати, только сейчас понял глубинный смысл имени. Было в лом переключаться на английский по этому написал на русском... когда стал думать чем заменить 0x, понял что русские буквы О и ха подходят лучше всего. В общем, си плюс плюс ох. Или точнее ох, ох, ох...


VD>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный). Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++. Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.


Для масс D как раз и хорош, так же как и шарп.
Re[6]: C++0X vs D programming lang
От: nikov США http://www.linkedin.com/in/nikov
Дата: 18.11.08 18:24
Оценка:
Здравствуйте, FR, Вы писали:

Pzz>>У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.


FR>Так и за питоном сейчас тоже не маленькие компании стоят, например гугль.


Ага, и еще Майкрософт.
Re[6]: C++0X vs D programming lang
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.11.08 18:28
Оценка:
Здравствуйте, FR, Вы писали:

FR>Около года выпускали продукт, потом когда py2exe стал достаточно стабильным перешли на него.

FR>Кроме того собирал так же немало небольших утилиток.

Обиднее всего, что в венде эта проблема более-менее решается. С помощью того же py2exe. А вот как раздавать питоновские standalone executables на линухе, совершенно непонятно. Ну не таскать же с собой свой питон, в самом деле?
Re[7]: C++0X vs D programming lang
От: FR  
Дата: 18.11.08 18:57
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Обиднее всего, что в венде эта проблема более-менее решается. С помощью того же py2exe. А вот как раздавать питоновские standalone executables на линухе, совершенно непонятно. Ну не таскать же с собой свой питон, в самом деле?


Так freeze же вроде родная юниксовская утилита, нам до py2exe пришлось свою ваять чтобы полную сборку в один exe со всеми нужными библиотеками делать.
Re[11]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 18.11.08 19:04
Оценка:
Здравствуйте, Pzz, Вы писали:
Pzz>Собираюсь я их прятать или нет, это отдельный вопрос, но уж точно не хочу лишать пользователей возможности использовать precompiled byte code. И самостоятельно их компилировать не собираюсь заставлять.

Мне кажется, питону это не поможет.
Re[8]: C++0X vs D programming lang
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.11.08 19:10
Оценка:
Здравствуйте, FR, Вы писали:

FR>Так freeze же вроде родная юниксовская утилита, нам до py2exe пришлось свою ваять чтобы полную сборку в один exe со всеми нужными библиотеками делать.


Я напускал на зафризенную программу strace и выяснил, что она долго и нудно ищет всякие питоньи запчасти в том месте, где они лежали в момент фриза, и если находит, то использует. Не знаю, что будет, если не найдет, но еще больше меня волнует, что будет, если найдет, но не от того питона.
Re[9]: C++0X vs D programming lang
От: FR  
Дата: 18.11.08 19:19
Оценка:
Здравствуйте, Pzz, Вы писали:

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


А сборку с полной статической линковкой нельзя разве сделать? У нас сначала была полная статическая линковка потом, зависимость только от python23.dll который лежал рядом с exe.
Re[4]: C++0X vs D programming lang
От: Didro Россия home~pages
Дата: 18.11.08 19:30
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, kaa.python, Вы писали:


VD>>>C++ уже не будет мэйнстримом.

KP>>да он и сейчас, вроде как не мэйнстрим.

VD>Мне кажется, что он плавно выходит из мэйнстрима. Году в 2000-ом он был чуть ли не основным языком разработки. Сейчас это игрушка для фанатиков и

тем кому нужна максимальная производительность любой ценой.

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

VD>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный). Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++. Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.


Обработка изображений и видео в реальном времени, на ПК + embedded платформах.
"Обработка" читай распознавание\ интеллектуальная обработка, когда обрабатывают на биты пикселей, а информацию, которую они несут.
И если задумаетесь, что вот вам прямо сейчас будет необходимо проектировать систему для решения задач именно этой области, то вряд ли предложите что-то другое, окромя С++.
Re[4]: C++0X vs D programming lang
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 18.11.08 19:39
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

VD>Мне кажется, что он плавно выходит из мэйнстрима. Году в 2000-ом он был чуть ли не основным языком разработки. Сейчас это игрушка для фанатиков и тем кому нужна максимальная производительность любой ценой.


Не только. Есть довольно много задач, которые решать без C/C++ будет крайне затруднительно. Просто на нем перестали писать все что ни попадя, что безусловно хорошо.
Re[6]: C++0X vs D programming lang
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 18.11.08 19:49
Оценка:
Mr.Cat,

MC>Эх, не думаю... Все фишки CL и схемы уже расхватали дизайнеры других языков. Ну или почти все (Где еще есть динамическая область видимости переменных? Хотя это, конечно, всего лишь маленький кусочек сахара).


Динамическая область видимости есть ещё в StringTemplate — неплохой язык для построения генераторов.
http://files.rsdn.org/10144/thinker.gif quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[8]: Почему "к сожалению"? :)
От: gear nuke  
Дата: 19.11.08 03:03
Оценка:
Здравствуйте, Ocelot, Вы писали:

O>Именно что трудозатраты и именно что на кодинг.

O>Более опытному специалисту, освоившему более сложные инструменты и способному все сделать быстрее, придется заплатить больше.

Поэтому сначала появляется версия 1.0 по дешевому сценарию, набиваются шишки и следует переход к более дорогой v2.0 (и так далее )
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[3]: C++0X vs D programming lang
От: gear nuke  
Дата: 19.11.08 03:03
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>А может на JavaScript будем драйверы писать?


Насмешил, подобные вопросы рассматриваются вполне серьезно
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[4]: C++0X vs D programming lang
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.11.08 06:00
Оценка: 1 (1) +2
Здравствуйте, VladD2, Вы писали:

VD>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный). Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++. Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.


У C/C++ есть несколько очень больших преимуществ:

— не нужна VM (не считая статически подвязываемого C runtime);
— стабильность языка (ага, как раз то, что новые веяния впитываются в C/C++ достаточно медленно);
— чудовищное количество наработанного и используемого ПО (это миллиарды копий, вдумайтесь в это число — 10^9, вы хочите аргументов массой? Их есть у меня);
— все (AFAIK) более или менее широко используемые языки и системы имеют foreign-интерфейс с C (не Lisp, не Java, не .Net).

А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия.

И если учесть эти факторы, то кто там станет мейнстримом завтра — да какая, на фиг, разница? Программистов на C/C++ всегда было относительно немного — 10-15% от общей массы, не считая, — как ты это правильно заметил, — глюка начала 2000-х, когда "плюсовиками" называли себя все, кому не лень.

Другое интересное следствие, заключается в том, что самый прогрессивный и прагматичный путь для индустрии на сегодняшний день — это продолжать развивать C++, поскольку он единственный из распространённых языков, который сможет плавно занять нишу C и привнести в общую среду программирования те самые новые веяния. Другого пути лично я не вижу, а пионерские рассуждения о том, что нужно выкинуть всё и всё переколпакировать лучше оставить пионерам.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Почему "к сожалению"? :)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.11.08 06:05
Оценка: :)
Здравствуйте, Pzz, Вы писали:

Pzz>>>А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов


ГВ>>За что, боярин?!


Pzz>За дело!


Надо мужикам рассказать: Певзнер за безделье не забанит! Добрый боярин!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 19.11.08 09:41
Оценка:
Здравствуйте, yumi, Вы писали:

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


Чем, кроме оптимизации, функтор лучше интерфейса?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Почему "к сожалению"? :)
От: alexeiz  
Дата: 19.11.08 10:09
Оценка: +1 -1
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, yumi, Вы писали:


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


E>Чем, кроме оптимизации, функтор лучше интерфейса?


Интерфейс (в смысле абстракного понятия), требующий фуктора или, например, boost::function будет гораздо проще в определении и в использовании, чем интерфейс, требующий интерфейса (в смысле интерфейсного класса). Сравни, например, Java Runnable и boost::thread.

Чтобы создать поток, с помощью Runnable, нам нужно определить свой собственный класс, унаследованный от Runnable, потом определить у него метод run(), а после этого создать объект этого класса и передать его в класс Thread, и — наконец-то — поток запустится.

Для сравнения, в boost::thread создание потока, исполняющего любую наперед существующюю функции или метод класса или объекта функтора, является тривиальной операцией:
boost::thread thr(&my_arbitrary_function);

И все! Никаких дополнительных интерфейсов и классов, ничего не надо реализовывать, и никаких ненужных сущностей создавать не надо. Все предельно кратко и лаконично.
Re[6]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 19.11.08 11:04
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов


IMHO, это слишком радикально. Вполне достаточно потребовать и добиться того, чтобы они не писали неоправданно сложно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Почему "к сожалению"? :)
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.11.08 11:34
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>И все!


Не, еще не все. Еще есть лямбды с С++0Х
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[9]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 19.11.08 12:06
Оценка: +1 -1
Здравствуйте, alexeiz, Вы писали:

A>И все! Никаких дополнительных интерфейсов и классов, ничего не надо реализовывать, и никаких ненужных сущностей создавать не надо. Все предельно кратко и лаконично.


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

Просто в твоём "кратком и лаконичном" варианте есть два существенных недостатка
1) Интерфейс плохо описан формально
2) Весь код, использующий интерфейс должен быть шаблонным. Иногда это довольно неприятное требование. А иногда и неприемлемое (например когда ты поставляешь наружу из DLL функцию, в которую надо передавать функтор)
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: Почему "к сожалению"? :)
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.11.08 12:34
Оценка:
Здравствуйте, Erop, Вы писали:

Pzz>>А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов


E>IMHO, это слишком радикально. Вполне достаточно потребовать и добиться того, чтобы они не писали неоправданно сложно...


Это во-первых невозможно никак поенфорсить, во-вторых они гордятся своей способностью писать с особым преподвывертом, в третьих некоторые вещи, которых надо стыдиться как ночного недержания мочи, у нис считаются хорошим тоном.
Re[8]: Да ладно! Идеи гуманизма преодолевают любое сопротивл
От: Erop Россия  
Дата: 19.11.08 12:43
Оценка:
Здравствуйте, Pzz, Вы писали:

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


Ну дык, штрафы, переписывание направильного кода в свободное от работы время правильным образом (оно же -- приравнивание времени разработки неправильного кода к перекуру, например. Короче невыполнение должностных обязанностей), "доска позора" и прочие аспекты "ипатьевского метода" таки творят чудеса.
Одни начинают писать вычурную приплюсню реально в свободное от работы время, а другие таки понимают, что это не их работодатель и идут искать "правильного" работодателя, при этом с песней и совершенно добровольно. Опять же, либо находят, либо через несколько итераций переучиваются...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 13:32
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Не совсем то, конечно, но Erlang вроде — как раз пример ФП + битодробления...


Эрланг это трмозной скрипт. Писать на нем низкоуровневый код (что и понимается мной под термином битодробление) просто глупо.
Ты наверно говоришь о библиотеке позволяющей разбирать бинарные структуры данных. Насколько я знаю, она написана не на Эрлаге. Да и никто не гарантирует, что полученный код будет работать так же быстро как код написанный, скажем, на С. Зато он сможет работать параллельно.

VD>>Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.

MC>Массы вроде бы его приняли.

Где? Что-то эти массы не видно в микроскоп.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[5]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 13:39
Оценка:
Здравствуйте, FR, Вы писали:

VD>>На мой взгляд Ди бесперспективен. Останови автор его развитие и никто не будет его использовать. Развивай автор его далее и никто не будет его использовать просто потому, что никто не хочет использовать "нестабильный язык". Хотя про его нестабильность еще бабушка на двое сказала.


FR>Выше замени Ди на немерле


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

FR>Для масс D как раз и хорош, так же как и шарп.


Шарп — это язык с ошибками в проектирование. Ди — это язык без проектирования. Так что он хорош только для тех кто находится в совсем уж узких рамках выбора.

А про массы просто смешно слушать. Где они?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[6]: C++0X vs D programming lang
От: Mr.Cat  
Дата: 19.11.08 13:50
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Ты наверно говоришь о библиотеке позволяющей разбирать бинарные структуры данных.
Да.

VD>Насколько я знаю, она написана не на Эрлаге.

Ессно. Я имел в виду, что "бинарный" паттерн-матчинг там — довольно удобная штука. Просто неправильно понял, что Вы имели в виду под "битодроблением".

VD>Где? Что-то эти массы не видно в микроскоп.

Смотря с чем сравнивать. Если с C++\C# — то да, до их популярности он не дотягивает.
Тем не менее, насколько я понимаю, он уже довольно широко, вон даже на сайтах, типа hh, стали появляться вакансии erlang-разработчиков (это если сравнивать с D, CL и т.п.)
Re[8]: Почему "к сожалению"? :)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.11.08 13:58
Оценка: +1
Здравствуйте, Pzz, Вы писали:

Pzz>>>А я, будь моя воля, выгнал бы нафиг всех писателей на C++. А знатоков "современного" C++ банил бы еще на стадии чтения ихних резюмов

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

Неужто все, кто "знает современный C++" этакое творят?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 13:58
Оценка: 1 (1) -4 :))
Здравствуйте, Didro, Вы писали:

D>Именно, но так, но есть как говорится области, где пока ему нет альтернативы (если не считать, возможно, OCaml).


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

VD>>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный). Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++. Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.


D>Обработка изображений и видео в реальном времени, на ПК + embedded платформах.


Ну, про встраиваемые приложения — это явно слишком большое обобщение. Наверно среди них есть местах коде С++ по прежнему хороший выбор. Но в большинстве случаев — нет. Скажем терминалы оплаты или банкоматы в нашей стране внутри себя содержат как минимум четвертые пни и Windows 2000, что позволяет писать софт для них почти на чем угодно. Никакой супер вычислительной мощности там не надо.

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

D>"Обработка" читай распознавание\ интеллектуальная обработка, когда обрабатывают на биты пикселей, а информацию, которую они несут.


Для меня слова "интеллектуальная" и С++ просто не совместимы. Так что не смешите мои тапочки. Хотите интеллекта, берите МЛ-клоны. По скорости они будут на уровне, а интеллекта там в разы больше. Ну, и "когда обрабатывают на биты пикселей" — это простите просто маразм. Такие вещи что на JavaScript, что на C++ будут работать дико медленно (относительно конечно). Тут как минимум нужно использовать библиотеки написанные на ассемблере с применением симд-инструкций, а по уму данные вычисления вообще стоит переложить на плечи современных видеокарт которые имеют и соотвественный набор команд, и вычислительные мощьности в разы большие чем у современных универсальных процессоров.

Ну, и опять же это, что называется, штучная работа.

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


Дык как только начинаешь задумываться, так сразу становится ясно, что С++ как раз наихудший выбор почти всегда. То есть если спросить меня, что могло бы подвигнуть меня к использованию С++, то я бы ответил очень просто — полное отсутствие альтернативы и очень большой бюджет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[5]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 14:01
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Не только. Есть довольно много задач, которые решать без C/C++ будет крайне затруднительно. Просто на нем перестали писать все что ни попадя, что безусловно хорошо.


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

В последние два раза когда я спросил чем занимается на работе С++-программист ответы были "корверторы пишу" и "финансовую систему делаю". На мой взгляд выбор С++ для этих задач — это просто идиотизм.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[6]: C++0X vs D programming lang
От: Erop Россия  
Дата: 19.11.08 14:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Шарп — это язык с ошибками в проектирование. Ди — это язык без проектирования. Так что он хорош только для тех кто находится в совсем уж узких рамках выбора.

А Ада?

VD>А про массы просто смешно слушать. Где они?

Это ты про шарп?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: C++0X vs D programming lang
От: CreatorCray  
Дата: 19.11.08 14:16
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Слишком часто на С++ пишут разные конверторы

Это как раз нормально. Конверторы они разные бывают.

VD> системы управления бизнес-задачами и прочую муть для которой С++ явный оверкил.

Это да

VD>А обработка видео... Да, наверно. Возможно и С++ тут не всегда хороший выбор, а часть библиотек стоит написать на ассемблере с использованием расширенных команд. Но сколько людей занимаются написанием такого софта? Думаю, что на нашем сайте таких нет. Или есть 1-2 человека.

"Такого софта" == числодробящего существенные объемы данных? Думаю гораздо больше.

VD>Такие вещи что на JavaScript, что на C++ будут работать дико медленно (относительно конечно).



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

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

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

Для тебя — несомненно!

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

Думаю, что тебя уже давно как раз про С++ спрашивать бесполезно
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 14:22
Оценка: -2 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>У C/C++ есть несколько очень больших преимуществ:


ГВ>- не нужна VM (не считая статически подвязываемого C runtime);


Ага. То же преимущество имеют Лисп (есть компилятор в нэйтив), Окамл, и еще пара десятков не так распространенных языков.

ГВ>- стабильность языка (ага, как раз то, что новые веяния впитываются в C/C++ достаточно медленно);


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

ГВ>- чудовищное количество наработанного и используемого ПО (это миллиарды копий, вдумайтесь в это число — 10^9, вы хочите аргументов массой? Их есть у меня);


Это вообще не преимущество. Мало ли что и на чем написано? Может ты о библиотеках? А вот с ними то на С++ полная задница. Есть 3-4 либы используемые более менее повсеместно. Но в основном С++ стал отличной гаванью для велосипедостроителей. Мы вот только что сдали новый номер журнала и в нем есть ряд статей С++-ников. Все как одна — это описание собственных велосипедов. Их авторы еще не знаю, что другие С++-ники тоже любят велосипеды, но собственного производства.

ГВ>- все (AFAIK) более или менее широко используемые языки и системы имеют foreign-интерфейс с C (не Lisp, не Java, не .Net).


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

ГВ>А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия.


Да кого трогает где и кем была создана ванна? Большинство людей волнует удобство этой ванны и ее чистота.


На самом деле все вышеперечисленное не является приемуществом С++. Иначе каой-нить Ди уже давно бы его стер с лица земли.

Преимуществом является другое:
* Огромная разрекламмированность.
* Наличие огромного количества учебников и другой литературы.
* Наличие большого комьюнити.
* Наличие множества хорошо оптимизированных компиляторов промышленного качества.
* Поддержка гигантами вроде МС.

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

ГВ>И если учесть эти факторы, то кто там станет мейнстримом завтра — да какая, на фиг, разница? Программистов на C/C++ всегда было относительно немного — 10-15% от общей массы, не считая, — как ты это правильно заметил, — глюка начала 2000-х, когда "плюсовиками" называли себя все, кому не лень.


Это вообще заблуждение. С++-программистов в конце девяностых начале десятых было очень много. Чуть ли не 50%. А вот сейчас уже виден явный спад. Найти работу С++-нику стало намного сложнее. И эта тенденция будет только нарастать.

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


Блин, ниша С уже давно свернулась в трубочку. Ей богу как на юмористическом концерте. Такие пафосные утверждения имели смысл лет 10 назад.

Будущее точно не за С++. И потихонечку это осознается массами. Просто планктон есть планктон. Чтобы он проникся банальными мыслями ему их нужно десятилетиями в голову втемяшивать.

В общем-то оно и правильно. Люди же зарплату получают не за качество и скорость решения задач, а за проведенное время. А С++ позволяет проводить время наиболее продуктивно — весело и с танцами. Так что большой респект и уважуха всем тем кто пишет что-то отличное от потоковых конвертеров видио и высокооптимизированных графических библиотек! Так держать товарищи!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[7]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 14:30
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

VD>>Где? Что-то эти массы не видно в микроскоп.

MC>Смотря с чем сравнивать. Если с C++\C# — то да, до их популярности он не дотягивает.
MC>Тем не менее, насколько я понимаю, он уже довольно широко, вон даже на сайтах, типа hh, стали появляться вакансии erlang-разработчиков (это если сравнивать с D, CL и т.п.)

Дык C++, C#, Васик и Java и есть на сегодня мэйнстрим. Ну, с огромной натяжкой туда можно отнести Питона.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[7]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 14:46
Оценка: -1
Здравствуйте, CreatorCray, Вы писали:

VD>>Слишком часто на С++ пишут разные конверторы

CC>Это как раз нормально. Конверторы они разные бывают.

Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.

VD>>А обработка видео... Да, наверно. Возможно и С++ тут не всегда хороший выбор, а часть библиотек стоит написать на ассемблере с использованием расширенных команд. Но сколько людей занимаются написанием такого софта? Думаю, что на нашем сайте таких нет. Или есть 1-2 человека.

CC>"Такого софта" == числодробящего существенные объемы данных? Думаю гораздо больше.

Ну, пусть откликнутся те кто его пишут. Ау... Где вы...

VD>>Такие вещи что на JavaScript, что на C++ будут работать дико медленно (относительно конечно).

CC>

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

CC>Ты писал на С++ с использованием современных (не микрософт) компиляторов?

Intel и GNU в их число входят?

CC>Непосредственно на асме писать нужда практически возникает только тогда, когда на нужные команды нет интринсиков. А так — ICC рулит.

CC>Видеокарты, пригодные под обработку не-игровых данных покуда не сильно распространены да и специфичный очень софт получается. Плюс у них свои ограничения и специфика.

А так и просто библиотека будет рулить. Напиши ее или возьми от того же Intel-а и использовать из любого компилируемого языка.
Вот только решение на видюже один фиг порвет все твои выкрутасы.

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

CC>Для тебя — несомненно!

Мы меня обсуждаем? Ну, да меня люди что не задумываются вообще не интересуют.

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

CC>Думаю, что тебя уже давно как раз про С++ спрашивать бесполезно

В нем что-то изменилось с 1998-го года? Можно ссылочку?
Ну, и на такие "думы" могу ответить только одно "сам ты дурак".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[7]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 14:52
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Динамическая область видимости есть ещё в StringTemplate — неплохой язык для построения генераторов.


Ага, неплохой. Еще бы не было этой фичи и было бы по больше контроля, и вообще бы бы замечательным.
На мой взгляд это была ошибка дизайна. Потом автор создал шаблоны с параметрами и они полностью утранили необходимость в динамической области видимости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[6]: C++0X vs D programming lang
От: cadet354 Россия
Дата: 19.11.08 15:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты наверно говоришь о библиотеке позволяющей разбирать бинарные структуры данных. Насколько я знаю, она написана не на Эрлаге.

как раз на Эрланге, binary matching очень удобная вещь для разбора пакетов.
MC>>Массы вроде бы его приняли.

P.S. Почему бы в Nemerle не добавить такуе фишки как например actor model и аналог OTP пусть и без горячей замены кода, MS своим DSS как раз пытаются это делать? насколько я знаю в Scala пытаются это сделать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: C++0X vs D programming lang
От: CreatorCray  
Дата: 19.11.08 15:29
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Слишком часто на С++ пишут разные конверторы

CC>>Это как раз нормально. Конверторы они разные бывают.
VD>Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.
Для финансов — вполне могу поверить. У меня правда на слово конвертор совершенно далекие от финансового применения ассоциации.

VD>>>А обработка видео... Да, наверно. Возможно и С++ тут не всегда хороший выбор, а часть библиотек стоит написать на ассемблере с использованием расширенных команд. Но сколько людей занимаются написанием такого софта? Думаю, что на нашем сайте таких нет. Или есть 1-2 человека.

CC>>"Такого софта" == числодробящего существенные объемы данных? Думаю гораздо больше.
VD>Ну, пусть откликнутся те кто его пишут. Ау... Где вы...
Я тут Числодробилки (не видео, но графические данные в том числе) писал до недавнего времени. С использованием SSE на Intel С++. Сейчас правда основная занятость в другой отрасли.

CC>>Ты писал на С++ с использованием современных (не микрософт) компиляторов?

VD>Intel и GNU в их число входят?
ICC == Intel C++ Compiler

CC>>Непосредственно на асме писать нужда практически возникает только тогда, когда на нужные команды нет интринсиков. А так — ICC рулит.

CC>>Видеокарты, пригодные под обработку не-игровых данных покуда не сильно распространены да и специфичный очень софт получается. Плюс у них свои ограничения и специфика.
VD>А так и просто библиотека будет рулить. Напиши ее или возьми от того же Intel-а и использовать из любого компилируемого языка.
VD>Вот только решение на видюже один фиг порвет все твои выкрутасы.
Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.

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

CC>>Для тебя — несомненно!
VD>Мы меня обсуждаем?
Нет. Просто ты все время выдаешь категоричные заявления, на "ИМХО" совсем не похожие.

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

CC>>Думаю, что тебя уже давно как раз про С++ спрашивать бесполезно
VD>В нем что-то изменилось с 1998-го года? Можно ссылочку?
Я про твое общеизвестное предвзятое отношение.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: C++0X vs D programming lang
От: skeptik_  
Дата: 19.11.08 15:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, kaa.python, Вы писали:


VD>>>C++ уже не будет мэйнстримом.

KP>>да он и сейчас, вроде как не мэйнстрим.

VD>Мне кажется, что он плавно выходит из мэйнстрима. Году в 2000-ом он был чуть ли не основным языком разработки. Сейчас это игрушка для фанатиков и тем кому нужна максимальная производительность любой ценой.


Не чуть ли, а основным. А с 2001 года и по сей день он является вторым номером.
Re[11]: C++0X vs D programming lang
От: the_void Швейцария  
Дата: 19.11.08 15:50
Оценка:
Здравствуйте, Pzz, Вы писали:

MC>>А, так Вы собрались исходники прятать? Тогда — действительно не знаю, как лучше поступить.


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


Зачем самостоятельно? Например, в deb-пакетах для этого есть отлаженная инфраструктура: всё прекомпилирует и куда надо положит.
Re[6]: C++0X vs D programming lang
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.11.08 16:05
Оценка: 34 (3) +2
Здравствуйте, VladD2, Вы писали:

Какая экспрессия.

ГВ>>У C/C++ есть несколько очень больших преимуществ:

ГВ>>- не нужна VM (не считая статически подвязываемого C runtime);
VD>Ага. То же преимущество имеют Лисп (есть компилятор в нэйтив), Окамл, и еще пара десятков не так распространенных языков.

Правильно. Разница в размерах, как минимум.

ГВ>>- стабильность языка (ага, как раз то, что новые веяния впитываются в C/C++ достаточно медленно);

VD>Ну, да. Вот только скажем тот же Окамл тоже не вчера родился и имеет весьма стабильные реализации. Вот только 90% офисного планктона не в состоянии освоить этот язык. Они и С++, то используют процентов на 30.

Кто есть "офисный планктон"?

ГВ>>- чудовищное количество наработанного и используемого ПО (это миллиарды копий, вдумайтесь в это число — 10^9, вы хочите аргументов массой? Их есть у меня);

VD>Это вообще не преимущество. Мало ли что и на чем написано? Может ты о библиотеках? А вот с ними то на С++ полная задница. Есть 3-4 либы используемые более менее повсеместно.

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

VD>Но в основном С++ стал отличной гаванью для велосипедостроителей. Мы вот только что сдали новый номер журнала и в нем есть ряд статей С++-ников. Все как одна — это описание собственных велосипедов. Их авторы еще не знаю, что другие С++-ники тоже любят велосипеды, но собственного производства.


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

ГВ>>- все (AFAIK) более или менее широко используемые языки и системы имеют foreign-интерфейс с C (не Lisp, не Java, не .Net).

VD>И это не преимущество. Потому как именно, что С, а не С++ и уж точно не С++ Ох. В этом Лисп ни чем не хуже чем С++. В .нет и вовсе есть собственный компилятор С++ который оносительно просто может завернуть программу на неуправляемм С++ в дотнетную сборку.

Что лишний раз подтверждает тезис об интерфейсе с C. Теперь в этой компании ещё и .Net. Ну что ж, пусть зацветают все цветы.

ГВ>>А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия.

VD>Да кого трогает где и кем была создана ванна? Большинство людей волнует удобство этой ванны и ее чистота.

Большинство вообще ничего не волнует, кроме холодильника и комфортабельности кресла. Статус-кво это никаким образом не меняет.

VD>На самом деле все вышеперечисленное не является приемуществом С++. Иначе каой-нить Ди уже давно бы его стер с лица земли.


VD>Преимуществом является другое:

VD>* Огромная разрекламмированность.

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

VD>* Наличие огромного количества учебников и другой литературы.


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

VD>* Наличие большого комьюнити.

VD>* Наличие множества хорошо оптимизированных компиляторов промышленного качества.
VD>* Поддержка гигантами вроде МС.

Ну вот видишь, даже ты нашёл кучу преимуществ у C++. Хотя казалось бы.

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


Скажу тебе по секрету, что С++ на самом деле — язык "системного" программирования. С теоретической точки зрения его не совсем разумно тыкать в те области, система терминов которых далеко отстоит от таких, как "память" и "процессор", равно как и функциональные языки не совсем правильно запихивать туда, где задача не описывается выражениями "найти решение" и "анализ". Кстати, применение функциональных языков в областях, связанных с коммуникацией, ИМХО, связано лишь с тем, что зачастую тут "операцию" можно свести к "функции от входящего сообщения".

ГВ>>И если учесть эти факторы, то кто там станет мейнстримом завтра — да какая, на фиг, разница? Программистов на C/C++ всегда было относительно немного — 10-15% от общей массы, не считая, — как ты это правильно заметил, — глюка начала 2000-х, когда "плюсовиками" называли себя все, кому не лень.


VD>Это вообще заблуждение. С++-программистов в конце девяностых начале десятых было очень много. Чуть ли не 50%. А вот сейчас уже виден явный спад. Найти работу С++-нику стало намного сложнее. И эта тенденция будет только нарастать.


Вынужден тебя огорчить: из тех "50% сиплюсплюсников" действительно хороших специалистов было хорошо, если 1/5. Написать в резюме "C++" дело не хитрое, равно как и "Java", ".Net" и т.п.

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


VD>Блин, ниша С уже давно свернулась в трубочку. Ей богу как на юмористическом концерте. Такие пафосные утверждения имели смысл лет 10 назад.


Не знаю насчёт трубочки. Ниша C как была, так и осталась в области системного программирования и правильнее всего ничего не пытаться с этим сделать. Когда стеки tcp/ip будут повсеместно заменены реализациями на ML — тогда и рассуждать будем о трубочках. Покуда родной интерфейс этих библиотек сугубо сишный — в трубочку сворачиваются только аргументы борцов с C/C++. И с каждым днём ситуация усугубляется.

VD>Будущее точно не за С++. И потихонечку это осознается массами. Просто планктон есть планктон. Чтобы он проникся банальными мыслями ему их нужно десятилетиями в голову втемяшивать.


Признаться, я понятия не имею о том, за каким языком будущее. Больше того, я вообще не представляю, как за языком может быть какое-то "будущее", кроме как за инструментом решения тех или иных задач. В случае C/C++ оказалось, что они заняли нишу системного программирования, хотя... Хотя, сколько занимаюсь программиованием, столько нахожу массу критических отзывов об этих языках. Уж как C клеймили, противопоставляя ему то Аду, то ещё что-нибудь!

Я могу примерно представить причины, по которым C/C++ получили такое большое распространение, но и не более того. Ещё могу примерно представить, почему разработчики современных языков обречены на провал, желая повторить этот самый "успех".

VD>В общем-то оно и правильно. Люди же зарплату получают не за качество и скорость решения задач, а за проведенное время. А С++ позволяет проводить время наиболее продуктивно — весело и с танцами. Так что большой респект и уважуха всем тем кто пишет что-то отличное от потоковых конвертеров видио и высокооптимизированных графических библиотек! Так держать товарищи!


Спили мушку.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: Да ладно! Идеи гуманизма преодолевают любое сопротивл
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.11.08 16:53
Оценка:
Здравствуйте, Erop, Вы писали:

E>Ну дык, штрафы, переписывание направильного кода в свободное от работы время правильным образом (оно же -- приравнивание времени разработки неправильного кода к перекуру, например. Короче невыполнение должностных обязанностей), "доска позора" и прочие аспекты "ипатьевского метода" таки творят чудеса.


Довольно трудно формально сформулировать, что такое "правильный" C++ код. Как начнешь формулировать, на выходе все pure ANSI C получается

Ну и следить все время за соблюдением сил никаких нет.

Штрафы, кстати, запрещены Трудовым Кодексом. Остается только гнать в шею
Re[7]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 17:33
Оценка:
Здравствуйте, cadet354, Вы писали:

C>P.S. Почему бы в Nemerle не добавить такуе фишки как например actor model и аналог OTP пусть и без горячей замены кода, MS своим DSS как раз пытаются это делать? насколько я знаю в Scala пытаются это сделать.


Да все по тому же почему туда не добавлено еще 20 классных и полезных фич. Нет свободных рук которые могут это сделать.

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

Лично у меня и так задач выше крыши. Плюс мне не особо нужен продвинутый параллелизм.

Если у кого-то возникнет желание потренироваться в создании подобной макры, то я с удовольствием помогу советом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[9]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 17:41
Оценка: -1
Здравствуйте, CreatorCray, Вы писали:

CC>Я тут Числодробилки (не видео, но графические данные в том числе) писал до недавнего времени. С использованием SSE на Intel С++.


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

CC>Сейчас правда основная занятость в другой отрасли.


Боюсь спросить в какой. Не ужели снова финансы?


CC>>>Ты писал на С++ с использованием современных (не микрософт) компиляторов?

VD>>Intel и GNU в их число входят?
CC>ICC == Intel C++ Compiler

Это я догадался. Я это к тому, что я ими пользовался. Правда SSE не использовал.

CC>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.


Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.

Я это к тому говорил, что говорить о частных решениях в области оптимизации, то С++ — это далеко не оптимальное решение. Несмотря на всю свою низкоуровневость.

VD>>Мы меня обсуждаем?

CC>Нет. Просто ты все время выдаешь категоричные заявления, на "ИМХО" совсем не похожие.

Я "выдаю" свое мнение. Это априори.
По любому если тебе оно не нравится, то и обсуждай его (мнение), а не меня. Или уж тогда говори конкретно, а не свое "имхо" о моем общер развитии.

Пока что, по факту, ты "споря" со мной говоришь то же самое, но своими словами.

VD>>В нем что-то изменилось с 1998-го года? Можно ссылочку?

CC>Я про твое общеизвестное предвзятое отношение.

Мое отношение сжилось из моей же практики. Оно не более предвзятое чем твое, скажем. Просто есть люди которые считают мое мнение очевидным, а есть что читают его предвзятым. Я это прекрасно понимаю. Каждый волен иметь свое мнение. Пока оно не начинает граничить с маразмом, по крайней мере.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[7]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 17:59
Оценка: -2
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>У C/C++ есть несколько очень больших преимуществ:

ГВ>>>- не нужна VM (не считая статически подвязываемого C runtime);
VD>>Ага. То же преимущество имеют Лисп (есть компилятор в нэйтив), Окамл, и еще пара десятков не так распространенных языков.

ГВ>Правильно. Разница в размерах, как минимум.


Размерах, чего, простите? Или это снова пенисометрия?

ГВ>>>- стабильность языка (ага, как раз то, что новые веяния впитываются в C/C++ достаточно медленно);

VD>>Ну, да. Вот только скажем тот же Окамл тоже не вчера родился и имеет весьма стабильные реализации. Вот только 90% офисного планктона не в состоянии освоить этот язык. Они и С++, то используют процентов на 30.

ГВ>Кто есть "офисный планктон"?


Те кто выбирают инструменты "как все" и пишут код "как у всех" в итоге решая, скажем, задачи офисной автоматизации на С++.

VD>>Это вообще не преимущество. Мало ли что и на чем написано? Может ты о библиотеках? А вот с ними то на С++ полная задница. Есть 3-4 либы используемые более менее повсеместно.


ГВ>Да ну?


Ну, да.

ГВ>Ты на порядок-другой не ошибся? Только у меня в одном небольшом относительно проекте используется четыре сторонних библиотеки.


Нет. В лубщем случае буст, асе и еще пара либ. И то не всегда. Чаще все же велосипеды.

VD>>Но в основном С++ стал отличной гаванью для велосипедостроителей. Мы вот только что сдали новый номер журнала и в нем есть ряд статей С++-ников. Все как одна — это описание собственных велосипедов. Их авторы еще не знаю, что другие С++-ники тоже любят велосипеды, но собственного производства.


ГВ>Ну, то, что ты фыркаешь в адрес "велосипедостроителей", означает для меня только то, что ты не совсем понимаешь, почему иной раз приходят к выводу о необходимости построения своего велосипеда.


Я все могу понять. Но при этом я прекрасно понимаю, что стремление к велосипедостроению вызвано двумя основными факторами:
1. Дурью в бошке.
2. Низкоуровневостью и отсуствием полноценных стандартов в С++.
Если сравнить положение дел с библиотеками в С++ и Яве/.NET, то разница видна невооруженным взглядом.

Можно сказать, что Яве и .NET проектировались так, чтобы стать отличной платфоромой для библиотек и фрэймворков. Да и не маловажно, что прямо в составе платформ поставляется огромнейшая стандартная библиотека. Чего в С++ не было, нет и видимо никогда не будет.

ГВ>Попробуй просто поверить, что если бы, например, Lisp оказался столь же распространён, как C++, то на нём велосипеды строили бы не реже. Здесь есть сугубо объективные факторы: невозможно знать обо всех решениях, имеющихся для решения некоторой задачи на некотором языке, потому иной раз лучше написать что-то своё за известное время, чем потратить неизвестное на поиск уже имеющегося.


Зачем мне представлять "бы"? Я привел совершенно конкретный пример Яве/.NET. В них же все ОК с либами?

ГВ>>>- все (AFAIK) более или менее широко используемые языки и системы имеют foreign-интерфейс с C (не Lisp, не Java, не .Net).

VD>>И это не преимущество. Потому как именно, что С, а не С++ и уж точно не С++ Ох. В этом Лисп ни чем не хуже чем С++. В .нет и вовсе есть собственный компилятор С++ который оносительно просто может завернуть программу на неуправляемм С++ в дотнетную сборку.

ГВ>Что лишний раз подтверждает тезис об интерфейсе с C. Теперь в этой компании ещё и .Net. Ну что ж, пусть зацветают все цветы.


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

ГВ>>>А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия.

VD>>Да кого трогает где и кем была создана ванна? Большинство людей волнует удобство этой ванны и ее чистота.

ГВ>Большинство вообще ничего не волнует, кроме холодильника и комфортабельности кресла. Статус-кво это никаким образом не меняет.


Ну, да. Некоторые по году не моются. Но мы вроде не об этом...

VD>>На самом деле все вышеперечисленное не является приемуществом С++. Иначе каой-нить Ди уже давно бы его стер с лица земли.


VD>>Преимуществом является другое:

VD>>* Огромная разрекламмированность.

ГВ>Странно, что при этом взрывное распространение C++ не сопровождалось рекламной компанией. Больше того, в то время существовала ещё груда объектных языков. На вскидку могу вспомнить


У того времени были свои особенности. Сейчас все не так. Да и реклама была не хилая. АтиЭндТи тогда была очень влиятельная контора. Они вот ОС свою протащить сумели.

VD>>* Наличие огромного количества учебников и другой литературы.


ГВ>Достаточно одного хорошего учебника по языку. По тому же Lisp, например, их вполне достаточно.


Не достаточно. Надо чтобы они везде валялись. К тому же по Лиспу нет ни одного хорошего учебника на русском. Это факт.

VD>>* Наличие большого комьюнити.

VD>>* Наличие множества хорошо оптимизированных компиляторов промышленного качества.
VD>>* Поддержка гигантами вроде МС.

ГВ>Ну вот видишь, даже ты нашёл кучу преимуществ у C++. Хотя казалось бы.


Я я их не терял. Просто это все преимущества инфраструктуры, а не языка.

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


ГВ>Скажу тебе по секрету, что С++ на самом деле — язык "системного" программирования.


Да чушь это. И используют его не для системного программирования, а для черт знает чего. А тот же Линкус и ядро НТ один хрен на С написано. А новые ОС пишутся но новых языках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[5]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.11.08 18:01
Оценка:
Здравствуйте, skeptik_, Вы писали:

VD>>Мне кажется, что он плавно выходит из мэйнстрима. Году в 2000-ом он был чуть ли не основным языком разработки. Сейчас это игрушка для фанатиков и тем кому нужна максимальная производительность любой ценой.


_>Не чуть ли, а основным. А с 2001 года и по сей день он является вторым номером.


Да, даже не третьи. Просто сейчас Ява и Шарп вышли в лидеры, а тогда лидером в бизнесе был Васик и уже Ява. На его фоне С++ выглядел неплохо. Но сейчас С++ как минимум идет за ними всеми, то есть, в лучшем случае на четвертом месте.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[6]: C++0X vs D programming lang
От: FR  
Дата: 19.11.08 18:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>На мой взгляд Ди бесперспективен. Останови автор его развитие и никто не будет его использовать. Развивай автор его далее и никто не будет его использовать просто потому, что никто не хочет использовать "нестабильный язык". Хотя про его нестабильность еще бабушка на двое сказала.


FR>>Выше замени Ди на немерле


VD>Зачем? В тебе указан Ди и С++.


Затем что оба в одинаковой ж...

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


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

FR>>Для масс D как раз и хорош, так же как и шарп.


VD>Шарп — это язык с ошибками в проектирование. Ди — это язык без проектирования. Так что он хорош только для тех кто находится в совсем уж узких рамках выбора.


Угу вот только как показывает практика именно языки без проектирования и становятся массовыми и популярными, эволюция рулит

VD>А про массы просто смешно слушать. Где они?


Угу
Re[6]: C++0X vs D programming lang
От: skeptik_  
Дата: 19.11.08 18:12
Оценка: 5 (2) :)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, skeptik_, Вы писали:


VD>>>Мне кажется, что он плавно выходит из мэйнстрима. Году в 2000-ом он был чуть ли не основным языком разработки. Сейчас это игрушка для фанатиков и тем кому нужна максимальная производительность любой ценой.


_>>Не чуть ли, а основным. А с 2001 года и по сей день он является вторым номером.


VD>Да, даже не третьи. Просто сейчас Ява и Шарп вышли в лидеры, а тогда лидером в бизнесе был Васик и уже Ява. На его фоне С++ выглядел неплохо. Но сейчас С++ как минимум идет за ними всеми, то есть, в лучшем случае на четвертом месте.


У меня на руках статистика фрилансерской биржи за все эти годы, и я могу абсолютно уверенно сказать, что Бейсика там никогда и близко не было, и что шарп хотя и начал догонять С++ начиная с 2005 года, но ещё далеко не догнал.

ЗЫ На немерле там до сих пор нет ни одного проекта.
Re[8]: C++0X vs D programming lang
От: FR  
Дата: 19.11.08 18:26
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Не достаточно. Надо чтобы они везде валялись. К тому же по Лиспу нет ни одного хорошего учебника на русском. Это факт.


Да ну SICP есть, финская книжка.
Re[8]: C++0X vs D programming lang
От: VoidEx  
Дата: 19.11.08 18:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я я их не терял. Просто это все преимущества инфраструктуры, а не языка.


Осталось обосновать отсутствие влияния языка на инфраструктуру.
Я это к тому, что если бы вместо Си++ в то время и в том месте оказался бы OCaml, далеко не факт, что он бы стал мейнстримом вместо Си++.
Или ты считаешь, что стал бы?
Просто звучит это так, будто от языка вообще ничего не зависит, кругом правят деньги и большие корпорации. Оно, конечно, ради бога, только к чему тогда споры о языках вообще, если от них толку ноль?
Divide et impera это, конечно, хорошо, только для начала следует убедиться, что разделять можно.
Re[6]: C++0X vs D programming lang
От: Didro Россия home~pages
Дата: 19.11.08 18:56
Оценка: 65 (4) :)))
Здравствуйте, VladD2, Вы писали:

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


На злобу дня, что называется:

Realtime audio processing with Lisp

Просто как иллюстрация этой ветки.
Lisp Realtime Audio processing
Re[8]: C++0X vs D programming lang
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 19.11.08 20:06
Оценка: 42 (3) +9
Здравствуйте, VladD2, Вы писали:

VD>Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.


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

VD>Ну, пусть откликнутся те кто его пишут. Ау... Где вы...


Я. По работе — анализ видео. Есть, например, ограничение по времени на обработку одного кадра стандартного разрешения — 5 млсек. Это на сжатие (или, наоборот, разжатие), анализ, сохранение на диск. Система мягкого реального времени.
Как хобби занимаюсь иногда как раз предсказанием курса валют. На выходных, бывает, загружаю простаивающую сетку на работе — тот же анализ данных, расчёт статистики всякой и т.п. Представь, что обработка работала бы в 5 раз медленнее — ждать пришлось бы не 2, а 10 дней. Плохо же

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


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

VD>А так и просто библиотека будет рулить. Напиши ее или возьми от того же Intel-а и использовать из любого компилируемого языка.

VD>Вот только решение на видюже один фиг порвет все твои выкрутасы.

Можно посмотреть на содержание тех же интеловских библиотек, на задачи которые они решают. Это область применения С++. А там и обработка сигналов, видео/аудио, сжатие, криптография, строки/регэкспы даже есть. Не говоря уже об универсальных математических библиотеках.
Возьмём очень универсальный пакет Матлаб. Ох, и у него математика лежит в dll, написанных на С++.

Я хочу сказать, что адекватных задач для языка С++ много. Кому-то они встречаются редко, а у кого-то постоянно перед глазами. Не стоит абсолютизировать собственный опыт.
https://elibrary.ru/author_counter.aspx?id=875549
Re[8]: C++0X vs D programming lang
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 19.11.08 20:13
Оценка:
VladD2,

LCR>>Динамическая область видимости есть ещё в StringTemplate — неплохой язык для построения генераторов.


VD>Ага, неплохой. Еще бы не было этой фичи и было бы побольше контроля, и вообще бы бы замечательным.

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

И как обращаться из глубоко вложенного шаблона к параметру внешнего шаблона? Если бы не было динамической области видимости, пришлось бы писать такие кренделя (протаскиваем var вглубь до template10):
block(var) ::=
  много текста <template0(p1=var, p2="preved")>
template0(p1, p2) :=
  много текста <template1(p1=var, p2="medved")>
template1(p1, p2) :=
  много текста <template2(p1=var, p2="andvvp")>

...

template10(p1, p2) :=
  наконец тут мы получаем доступ к <p1> 
  который равен <var> и можем его использовать

А с динамической областью видимости можно обратиться прямо к var из template10 не протаскивая его через всю цепь вызовов. В обычных языках это конечно решается просто созданием глобального относительно template0..template10 бинда, а здесь такого нет. Или как?
http://files.rsdn.org/10144/thinker.gif quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[10]: Да ладно! Идеи гуманизма преодолевают любое сопротив
От: Erop Россия  
Дата: 19.11.08 20:29
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Довольно трудно формально сформулировать, что такое "правильный" C++ код. Как начнешь формулировать, на выходе все pure ANSI C получается


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

Pzz>Ну и следить все время за соблюдением сил никаких нет.

Ну при всплытии факта имеют сильно исполнителя и очень сильно его начальника и далее по цепочке...

Pzz>Штрафы, кстати, запрещены Трудовым Кодексом. Остается только гнать в шею

Вот тоже мне проблема. Зато премии не запрещены...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Вот тебе три задачи...
От: Erop Россия  
Дата: 19.11.08 20:51
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


Про лопату -- это всё прикольно конечно, но С++ намного сложнее лопаты, так что аналогия не рулит

D>>"Обработка" читай распознавание\ интеллектуальная обработка, когда обрабатывают на биты пикселей, а информацию, которую они несут.


VD>Для меня слова "интеллектуальная" и С++ просто не совместимы. Так что не смешите мои тапочки. Хотите интеллекта, берите МЛ-клоны. По скорости они будут на уровне, а интеллекта там в разы больше. Ну, и "когда обрабатывают на биты пикселей" — это простите просто маразм. Такие вещи что на JavaScript, что на C++ будут работать дико медленно (относительно конечно). Тут как минимум нужно использовать библиотеки написанные на ассемблере с применением симд-инструкций, а по уму данные вычисления вообще стоит переложить на плечи современных видеокарт которые имеют и соотвественный набор команд, и вычислительные мощьности в разы большие чем у современных универсальных процессоров.


IMHO, ты не там интеллект ищешь...
Есть куча задач, в которых кодирование не представляет вообще никакой проблемы. Проблему представляет разработка и настройка алгоритмов. И тогда годится любой процедурный язык, без существенного встроенного оверхеда и поддерживаемый промышленными трансляторами и средами разработки...
И тогда, зачастую, конкурируют как раз С++ и C... Следующий кандидат (уже сильно хуже) -- что-то ООП из наследников PASCAL...

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


Вот тебе три задачи:
1) Написание базы данных
2) Написание системы, которая в реальном времени анализирует изображение с размещённых в здании камер и привлекает внимание оператора к подозрительным случаям (несанкционированный доступ кого-то куда-то, несанкционированное поведение и т. д.)
3) Написание системы, которая анализирует видео с камеры наблюдения ГИБДД и выдаёт чкриншоты с наилучшими фотками нарушителей + госномер машины нарушителя.

На чём реализовывать будем?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: C++0X vs D programming lang
От: Erop Россия  
Дата: 19.11.08 20:55
Оценка:
Здравствуйте, VladD2, Вы писали:

CC>>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.


VD>Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.


Зато идут на любой машине... И на любой машине одинаково работают, к тому же...

"Куда" пока что, увы, только для разового кода хороша... В коробочный продукт (особенно, если это не игрушка) её ставить как-то стрёмно.
Ну и потом, КУДА, она пока что вроде как тока С и С++ поддерживает?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: C++0X vs D programming lang
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.11.08 21:12
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>>>Ага. То же преимущество имеют Лисп (есть компилятор в нэйтив), Окамл, и еще пара десятков не так распространенных языков.

ГВ>>Правильно. Разница в размерах, как минимум.
VD>Размерах, чего, простите? Или это снова пенисометрия?

В размерах добавляемого кода к распространяемому исполняемому модулю.

ГВ>>Кто есть "офисный планктон"?

VD>Те кто выбирают инструменты "как все" и пишут код "как у всех" в итоге решая, скажем, задачи офисной автоматизации на С++.

Иными словами, офисный планктон — это мейнстрим в кристалльном виде. Интересно.

ГВ>>Ты на порядок-другой не ошибся? Только у меня в одном небольшом относительно проекте используется четыре сторонних библиотеки.

VD>Нет. В лубщем случае буст, асе и еще пара либ. И то не всегда. Чаще все же велосипеды.

Со свечкой везде постоял, чтобы такое утверждать?

VD>Я все могу понять. Но при этом я прекрасно понимаю, что стремление к велосипедостроению вызвано двумя основными факторами:

VD>1. Дурью в бошке.

Оставим за скобками.

VD>2. Низкоуровневостью и отсуствием полноценных стандартов в С++.


Полноценных — это каких?

VD>Если сравнить положение дел с библиотеками в С++ и Яве/.NET, то разница видна невооруженным взглядом.


Безусловно. Велосипеды явы и дотнета ещё впереди.

VD>Можно сказать, что Яве и .NET проектировались так, чтобы стать отличной платфоромой для библиотек и фрэймворков. Да и не маловажно, что прямо в составе платформ поставляется огромнейшая стандартная библиотека. Чего в С++ не было, нет и видимо никогда не будет.


И это просто замечательно, что C++ не занимается предписыванием реализации примитивов.

ГВ>>Попробуй просто поверить, что если бы, например, Lisp оказался столь же распространён, как C++, то на нём велосипеды строили бы не реже. [...]

VD>Зачем мне представлять "бы"? Я привел совершенно конкретный пример Яве/.NET. В них же все ОК с либами?

Как это — OK? Почему же тогда bltoolkit появилась? Натуральный велосипед.

ГВ>>Что лишний раз подтверждает тезис об интерфейсе с C. Теперь в этой компании ещё и .Net. Ну что ж, пусть зацветают все цветы.

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

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

И ещё пара интересных моментов: например COM имеет хорошие такие корни в C++ (за что его и ругали одно время), GDI+ — пусть не корни, но как минимум интерфейс.

ГВ>>>>А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия.

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

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

VD>>>* Огромная разрекламмированность.

ГВ>>Странно, что при этом взрывное распространение C++ не сопровождалось рекламной компанией. Больше того, в то время существовала ещё груда объектных языков. На вскидку могу вспомнить
VD>У того времени были свои особенности. Сейчас все не так. Да и реклама была не хилая. АтиЭндТи тогда была очень влиятельная контора. Они вот ОС свою протащить сумели.

Ты считаешь, что кроме рекламы от нехилой AT&T никаких больше факторов не способствовало продвижению Unix? А может быть, дело в том, что Unix оказался вполне удачной переносимой многопользовательской ОС, которая в самом деле позволила переносить ПО с одной машины на другую?

VD>>>* Наличие огромного количества учебников и другой литературы.

ГВ>>Достаточно одного хорошего учебника по языку. По тому же Lisp, например, их вполне достаточно.
VD>Не достаточно. Надо чтобы они везде валялись. К тому же по Лиспу нет ни одного хорошего учебника на русском. Это факт.

Надо, чтобы ещё их хотели купить. Не находишь, что есть некоторая разница между "валялись" и "хотели приобрести"?

ГВ>>Ну вот видишь, даже ты нашёл кучу преимуществ у C++. Хотя казалось бы.

VD>Я я их не терял. Просто это все преимущества инфраструктуры, а не языка.

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

ГВ>>Скажу тебе по секрету, что С++ на самом деле — язык "системного" программирования.

VD>Да чушь это. И используют его не для системного программирования, а для черт знает чего. А тот же Линкус и ядро НТ один хрен на С написано. А новые ОС пишутся но новых языках.

Кроме Singularity, про какие ОС ты ещё можешь рассказать, которые пишутся не на C? Желательно, про те, которые уже продаются или имеют приличные шансы на это. Поскольку иначе ОС есть и на Lisp.

Кроме того, в системное программирование, в общем, не только ОС включаются. В этот класс, скорее, имеет смысл зачислить весь "инфраструктурный" софт — в том числе библиотеки, серверы баз данных и, вполне очевидно, трансляторы языков программирования. То есть как раз вот тот самый ACE, про который ты вспомнил, вполне себе пример такой библиотеки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Вот тебе три задачи...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 19.11.08 21:16
Оценка: +2 :)
Здравствуйте, Erop, Вы писали:

E>Вот тебе три задачи:

E>1) Написание базы данных
E>2) Написание системы, которая в реальном времени анализирует изображение с размещённых в здании камер и привлекает внимание оператора к подозрительным случаям (несанкционированный доступ кого-то куда-то, несанкционированное поведение и т. д.)
E>3) Написание системы, которая анализирует видео с камеры наблюдения ГИБДД и выдаёт чкриншоты с наилучшими фотками нарушителей + госномер машины нарушителя.

E>На чём реализовывать будем?


Ко всем трем неплохо подходит OCaml.
Re[8]: Вот тебе три задачи...
От: Erop Россия  
Дата: 19.11.08 21:33
Оценка:
Здравствуйте, nikov, Вы писали:


E>>На чём реализовывать будем?

N>Ко всем трем неплохо подходит OCaml.

1) А что, уже есть много пром. компиляторов, программистов, средств разработки, тоже промышленного уровня?..
2) (Кстати) Много баз на нём уже реализовали?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Вот тебе три задачи...
От: Didro Россия home~pages
Дата: 19.11.08 21:36
Оценка: +1
Здравствуйте, nikov, Вы писали:

E>>На чём реализовывать будем?

N>Ко всем трем неплохо подходит OCaml.

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

OCaml Language Sucks
Обратить внимание на: Arithmetic's readability \ No Polymorphism \ Standard Library Sucks


И весь мой пыл куда-то улетучился..
Re[7]: Вот тебе три задачи...
От: FR  
Дата: 20.11.08 05:09
Оценка:
Здравствуйте, Erop, Вы писали:


E>IMHO, ты не там интеллект ищешь...

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

А этот факт всегда игнорируется языкодвинутыми товарищами.
Могу свой недавний пример привести 182 строки кода на С++, 50 чистых рабочих часов. Интеллекта кстати немного, просто нужно было получить от WinAPI то что он не дает напрямую.
Re[8]: Вот тебе три задачи...
От: FR  
Дата: 20.11.08 05:14
Оценка:
Здравствуйте, nikov, Вы писали:

E>>На чём реализовывать будем?


N>Ко всем трем неплохо подходит OCaml.


Угу только можем получить тормоза, компиляторы C++ намного лучше (особенно в графических алгоритмах) оптимизировать будут.
Re[9]: Вот тебе три задачи...
От: FR  
Дата: 20.11.08 05:15
Оценка: :)
Здравствуйте, Didro, Вы писали:

D>Я тоже так думал, и почти уже был готов идти "аргументировать" смену языка разработки, но потом наткнулся на это:


D>

D>OCaml Language Sucks
D>Обратить внимание на: Arithmetic's readability \ No Polymorphism \ Standard Library Sucks


D>И весь мой пыл куда-то улетучился..


Не надо читать ушибленных лиспом, это трава уровня немерле
Re[10]: Вот тебе три задачи...
От: Didro Россия home~pages
Дата: 20.11.08 05:48
Оценка: +1
Здравствуйте, FR, Вы писали:

D>>OCaml Language Sucks
D>>Обратить внимание на: Arithmetic's readability \ No Polymorphism \ Standard Library Sucks


FR>Не надо читать ушибленных лиспом, это трава уровня немерле

Вроде бы в заметке приведены вполне адекватные аргументы (критика) — а уж в лисповом или в немерелевом трансе они явились автору значения не имеет
Re[11]: Вот тебе три задачи...
От: FR  
Дата: 20.11.08 06:31
Оценка: 6 (1)
Здравствуйте, Didro, Вы писали:

FR>>Не надо читать ушибленных лиспом, это трава уровня немерле

D>Вроде бы в заметке приведены вполне адекватные аргументы (критика) — а уж в лисповом или в немерелевом трансе они явились автору значения не имеет

Ocaml конечно корявый язык, но эти проблемы вполне разрешимы:

Arithmetic's readability — http://pa-do.forge.ocamlcore.org/

No Polymorphism — в сравнении с динамическим лиспом конечно, но даже для этого есть Object.magic который хоть и считается дурным тоном но вполне доступен.

Standard Library Sucks — тут он похоже просто искал к чему прикопатся
Re[8]: C++0X vs D programming lang
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 20.11.08 06:55
Оценка: -1
Здравствуйте, VladD2, Вы писали:

ГВ>>Ты на порядок-другой не ошибся? Только у меня в одном небольшом относительно проекте используется четыре сторонних библиотеки.


VD>Нет. В лубщем случае буст, асе и еще пара либ. И то не всегда. Чаще все же велосипеды.


по большому счету, этих 3-4 либ хватает для решения всех задач которые действительно стоит, можно и нужно решать на С++.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[11]: Вот тебе три задачи...
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 20.11.08 09:19
Оценка: 46 (2)
Didro,

D>

D>>>OCaml Language Sucks
D>>>Обратить внимание на: Arithmetic's readability \ No Polymorphism \ Standard Library Sucks


Про Arithmetic readability — это критика чисто базовых возможностей без учёта продвинутых. В Ocaml Mathematical Framework эта проблема решена вполне успешно с помощью ocamlp4:
let symb p = 3*x**2-2*x-3;;
let symb e = p*(sin(x+1)+log(x**2-2*x+2)-2);;

По моему вполне ридабле
http://files.rsdn.org/10144/thinker.gif quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[10]: C++0X vs D programming lang
От: CreatorCray  
Дата: 20.11.08 09:54
Оценка:
Здравствуйте, VladD2, Вы писали:

CC>>Я тут Числодробилки (не видео, но графические данные в том числе) писал до недавнего времени. С использованием SSE на Intel С++.

VD>Значит должен понимать, что это уже не совсем С++. И что имея оптимизированную библиотеку примитивов и на Яве можно весьма шутсрый код писать.
Это уже и не ява будет

CC>>Сейчас правда основная занятость в другой отрасли.

VD>Боюсь спросить в какой. Не ужели снова финансы?
Ага на C#

CC>>>>Ты писал на С++ с использованием современных (не микрософт) компиляторов?

VD>>>Intel и GNU в их число входят?
CC>>ICC == Intel C++ Compiler
VD>Это я догадался. Я это к тому, что я ими пользовался. Правда SSE не использовал.
Ты — может и нет. А вот компилер — с удовольствием.

CC>>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.

VD>Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.
В смысле доступны? кому доступны. Переформулируй, т.к. не понятно про что ты.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: C++0X vs D programming lang
От: CreatorCray  
Дата: 20.11.08 09:54
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Как хобби занимаюсь иногда как раз предсказанием курса валют. На выходных, бывает, загружаю простаивающую сетку на работе — тот же анализ данных, расчёт статистики всякой и т.п. Представь, что обработка работала бы в 5 раз медленнее — ждать пришлось бы не 2, а 10 дней. Плохо же

Угу. Переписывали как то для одного банка систему, которая за ночь на гриде не справлялась с обработкой данных. Так что бывает что и "Скорость = Деньги".

N>Видеокарты, например, умеют работать только 4-х байтовыми float. Для многих задач это принципиальное ограничение. И оно не единственное.

Сейчас уже научили и int и вроде как double

N>Можно посмотреть на содержание тех же интеловских библиотек, на задачи которые они решают. Это область применения С++. А там и обработка сигналов, видео/аудио, сжатие, криптография, строки/регэкспы даже есть. Не говоря уже об универсальных математических библиотеках.

+1
IPP, MTL — просто глаза разбегаются чего там есть.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: C++0X vs D programming lang
От: CreatorCray  
Дата: 20.11.08 09:54
Оценка: +1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здесь есть сугубо объективные факторы: невозможно знать обо всех решениях, имеющихся для решения некоторой задачи на некотором языке, потому иной раз лучше написать что-то своё за известное время, чем потратить неизвестное на поиск уже имеющегося.

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

ГВ>Скажу тебе по секрету, что С++ на самом деле — язык "системного" программирования. С теоретической точки зрения его не совсем разумно тыкать в те области, система терминов которых далеко отстоит от таких, как "память" и "процессор", равно как и функциональные языки не совсем правильно запихивать туда, где задача не описывается выражениями "найти решение" и "анализ". Кстати, применение функциональных языков в областях, связанных с коммуникацией, ИМХО, связано лишь с тем, что зачастую тут "операцию" можно свести к "функции от входящего сообщения".

+100

ГВ>Уж как C клеймили, противопоставляя ему то Аду, то ещё что-нибудь!

..а он все жив

ГВ>Спили мушку.

+1
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: C++0X vs D programming lang
От: CreatorCray  
Дата: 20.11.08 09:54
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Кто есть "офисный планктон"?

VD>Те кто выбирают инструменты "как все" и пишут код "как у всех" в итоге решая, скажем, задачи офисной автоматизации на С++.
Тогда по моим наблюдениям это уже С# и Java

ГВ>>Попробуй просто поверить, что если бы, например, Lisp оказался столь же распространён, как C++, то на нём велосипеды строили бы не реже. Здесь есть сугубо объективные факторы: невозможно знать обо всех решениях, имеющихся для решения некоторой задачи на некотором языке, потому иной раз лучше написать что-то своё за известное время, чем потратить неизвестное на поиск уже имеющегося.

VD>Зачем мне представлять "бы"? Я привел совершенно конкретный пример Яве/.NET. В них же все ОК с либами?
То, что с ними поставляется большая куча говна на все случаи жизни еще не означает, что никому и никогда не понадобится аналог, отличающийся от стандартной реализации по каким либо параметрам.

VD>Да чушь это. И используют его не для системного программирования, а для черт знает чего. А тот же Линкус и ядро НТ один хрен на С написано. А новые ОС пишутся но новых языках.

Windows 7 на чем пишут? Вроде ж новая...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 12:54
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>>>Я тут Числодробилки (не видео, но графические данные в том числе) писал до недавнего времени. С использованием SSE на Intel С++.

VD>>Значит должен понимать, что это уже не совсем С++. И что имея оптимизированную библиотеку примитивов и на Яве можно весьма шутсрый код писать.
CC>Это уже и не ява будет

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

CC>>>Сейчас правда основная занятость в другой отрасли.

VD>>Боюсь спросить в какой. Не ужели снова финансы?
CC>Ага на C#

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

VD>>Это я догадался. Я это к тому, что я ими пользовался. Правда SSE не использовал.

CC>Ты — может и нет. А вот компилер — с удовольствием.

На практике код опережал VC в очень редких случаях и не принципиально.

CC>>>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.

VD>>Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.
CC>В смысле доступны? кому доступны. Переформулируй, т.к. не понятно про что ты.

В смысле те что есть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[9]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 13:22
Оценка: -5 :))) :)))
Здравствуйте, Nuzhny, Вы писали:


VD>>Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.


N>При работе на бирже необходимо очень высокое быстродействие. Как для анализа данных, так и для банальных автоматических торговых систем. Да, их пишут на С++. И нейросети для предсказания курсов на фондовых и валютных рынках тоже. А это как-никак область ИИ (это про твои высказывания о непригодности для интеллектуальных задач).


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

ИИ на С++ — это вообще для человека в этом немного понимающего должно звучать как Чубайс на нанотехнологиях .
Про нейро-сети могу сказать, что это вообще ахинея на данном этапе развития компьютерной отрасли.

Ваши замечательные программы-предсказатели не более чем мошенничество. Программа может помочь проанализировать большие объемы данных и выявить закономерности в прошлых операциях. Но рынок — это живой организм и никто (кроме инсайдеров) не может предсказать его поведения. А ваши замечательные программы просто подгоняются под старые данные, чтобы продать их по лучше. В любой игре нужно что-то большее чем алгоритм. Там нужно чутье и везение. Так что не надо про эти бредни здесь рассказывать.

Если же я ошибаюсь, то просьба купить крутую программу-предсказатель и заработать миллион. 10% от него отдать мне. Это будет замечательным доказательством правоты и я возьму свои слова обратно .

VD>>Ну, пусть откликнутся те кто его пишут. Ау... Где вы...


N>Я. По работе — анализ видео. Есть, например, ограничение по времени на обработку одного кадра стандартного разрешения — 5 млсек. Это на сжатие (или, наоборот, разжатие), анализ, сохранение на диск. Система мягкого реального времени.


"мягкого реального времени" — это по русски будет называться система не реального времени .

N>Как хобби занимаюсь иногда как раз предсказанием курса валют. На выходных, бывает, загружаю простаивающую сетку на работе — тот же анализ данных, расчёт статистики всякой и т.п. Представь, что обработка работала бы в 5 раз медленнее — ждать пришлось бы не 2, а 10 дней. Плохо же


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

VD>>А так и просто библиотека будет рулить. Напиши ее или возьми от того же Intel-а и использовать из любого компилируемого языка.

VD>>Вот только решение на видюже один фиг порвет все твои выкрутасы.

N>Можно посмотреть на содержание тех же интеловских библиотек, на задачи которые они решают. Это область применения С++. А там и обработка сигналов, видео/аудио, сжатие, криптография, строки/регэкспы даже есть. Не говоря уже об универсальных математических библиотеках.

N>Возьмём очень универсальный пакет Матлаб. Ох, и у него математика лежит в dll, написанных на С++.

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

N>Я хочу сказать, что адекватных задач для языка С++ много. Кому-то они встречаются редко, а у кого-то постоянно перед глазами. Не стоит абсолютизировать собственный опыт.


Много? Мне кажется мы это понятие по разному понимаю. Вот долболомов пишущих на С++ что не попадя — много. А задач которые действительно требуют использования С++ отнюдь не много и большинство из них сводится к написанию библиотек, если конечно, по уму все делать, а не писать велосипеды на каждый чих объясняя их появление кривостью всего вокруг и особенностями своих задач.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[7]: Вот тебе три задачи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 13:35
Оценка: -1
Здравствуйте, Erop, Вы писали:
E>Вот тебе три задачи:
E>1) Написание базы данных
E>2) Написание системы, которая в реальном времени анализирует изображение с размещённых в здании камер и привлекает внимание оператора к подозрительным случаям (несанкционированный доступ кого-то куда-то, несанкционированное поведение и т. д.)
E>3) Написание системы, которая анализирует видео с камеры наблюдения ГИБДД и выдаёт чкриншоты с наилучшими фотками нарушителей + госномер машины нарушителя.

E>На чём реализовывать будем?


Да, хоть на Лиспе. Более чем удобный язык для данного решения. Уж на любом клоне МЛ-я точно будет удобнее чем на С++.

У меня встречный вопрос. Ты сам то хоть одну из этих задач решаешь на работе?
Если, нет, то чем занимаешся?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[12]: C++0X vs D programming lang
От: CreatorCray  
Дата: 20.11.08 13:35
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Если >90% времени исполняется код из либы — то вообще пофигу на чем писать управление. Хоть на брейнфаке.

CC>>Ага на C#

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

VD>Тогда что спорить, если ты и сам делом подтверждаешь мои тезисы?

Не, не подтверждаю. У нас и на С++ и на Java и на С# проекты есть. Даже perl под линухом был.
Просто на данный момент я на C# проекте. Только и всего.

VD>>>Это я догадался. Я это к тому, что я ими пользовался. Правда SSE не использовал.

CC>>Ты — может и нет. А вот компилер — с удовольствием.
VD>На практике код опережал VC в очень редких случаях и не принципиально.
Какой код опережал VC? Что то ты в последнее время загадками говоришь.
У меня по тестам разница между VC 7.1 и ICC 10.1 — более двух раз на криптографии, написанной на С++. 56Mb/s vs 120Mb/s.

CC>>>>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.

VD>>>Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.
CC>>В смысле доступны? кому доступны. Переформулируй, т.к. не понятно про что ты.
VD>В смысле те что есть.
Тогда в сравнении чего с чем у кого никакая производительность?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Вот тебе три задачи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 13:36
Оценка:
Здравствуйте, nikov, Вы писали:

E>>Вот тебе три задачи:

E>>1) Написание базы данных
E>>2) Написание системы, которая в реальном времени анализирует изображение с размещённых в здании камер и привлекает внимание оператора к подозрительным случаям (несанкционированный доступ кого-то куда-то, несанкционированное поведение и т. д.)
E>>3) Написание системы, которая анализирует видео с камеры наблюдения ГИБДД и выдаёт чкриншоты с наилучшими фотками нарушителей + госномер машины нарушителя.

E>>На чём реализовывать будем?


N>Ко всем трем неплохо подходит OCaml.


Да любой клон МЛ-я или даже компилируемый Лисп.

Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[10]: C++0X vs D programming lang
От: CreatorCray  
Дата: 20.11.08 13:42
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Глупость — использовать эту библиотеку для прикладных задач из С++ же и рассказывать окружающим, что рекеспы и шифрование — это область применения С++.

Ну расскажи тогда, к области применения чего относить криптографию?
На примере RC6 например, как одного из наиболее просто реализуемых современных шифров.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Вот тебе три задачи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 13:43
Оценка: :)
Здравствуйте, Erop, Вы писали:

E>>>На чём реализовывать будем?

N>>Ко всем трем неплохо подходит OCaml.

E>1) А что, уже есть много пром. компиляторов, программистов, средств разработки, тоже промышленного уровня?..


Лет эдак 10.

E>2) (Кстати) Много баз на нём уже реализовали?


Море. Вопрос только в том, что пользуются люди в основном коммерческими раскручеными субды: IBM DB 2, MS SQL Server и Orcle.
Они конечно хороши, так как в них вложили сотни миллионов долларов (а может и больше), но они были бы во много раз лучше, если бы их писали на более адекватном инструменте.

Кстати, еще один встречный вопрос... Ты знаком хотя бы с одним клоном МЛ? Писал что-нибудь на нем? Подождут даже Scala, F# или Nemerle.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[10]: C++0X vs D programming lang
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.11.08 13:54
Оценка: +3 :))) :)
Здравствуйте, VladD2, Вы писали:

VD>"мягкого реального времени" — это по русски будет называться система не реального времени .


...Как авторитетно заявил видный специалист в области систем реального времени VladD2.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Вот тебе три задачи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 14:05
Оценка: -3
Здравствуйте, FR, Вы писали:

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


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

Да и достали вы уже с этими графическими алгоритмами возмите готовую библиотеку (того же McКакЕгоТам) и пишите логику, а не утыкайтесь в частности обработки графики.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[8]: Вот тебе три задачи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 14:07
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>А этот факт всегда игнорируется языкодвинутыми товарищами.


Это ты о питонистах?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[9]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 14:46
Оценка: -1 :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Так или иначе, но это имеет прямое отношение к языку. Если отставить в сторону пассажи про "офисный планктон", то наличие коммьюнити и поддержка гигантов в современных условиях — очень существенный аргумент. Я отнюдь не пытаюсь сказать, что он единственный, но то, что немаловажный — это бесспорно. Если ты не заметил, я здесь сам прибегаю к аргументам массовостью.


Вот этот вопрос главный! И "офисный планктон" тут как раз и рулит как хвост собаков. Дело в том, что большая часть работников гигантов — это тот самый узколобый офисный планктон. Плюс планктон — это основной потребитель. Его проще убить чем переучить на что-то стоящее.
По сему система самораскручивает бездарность и поддерживает экстенсивные средства разработки.

ГВ>Кроме Singularity, про какие ОС ты ещё можешь рассказать, которые пишутся не на C? Желательно, про те, которые уже продаются или имеют приличные шансы на это. Поскольку иначе ОС есть и на Lisp.


Оберон ОС. Да их куча если покапаться. Просто в фаворе сейчас Вынь и Линл. И хрен ты что с этим сделаешь все по тем же причинам.

В общем, все варится в рынке где игроки имеют слишком не равные возможности. Это тормозит прогресс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[9]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 14:47
Оценка: :))
Здравствуйте, kaa.python, Вы писали:

KP>по большому счету, этих 3-4 либ хватает для решения всех задач которые действительно стоит, можно и нужно решать на С++.


Да, да. Это фраза такая же крылатая, как и "640 Кбайт хватит всем"...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[9]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 14:55
Оценка: -1 :)
Здравствуйте, CreatorCray, Вы писали:

ГВ>>>Кто есть "офисный планктон"?

VD>>Те кто выбирают инструменты "как все" и пишут код "как у всех" в итоге решая, скажем, задачи офисной автоматизации на С++.
CC>Тогда по моим наблюдениям это уже С# и Java

Человек выбирающий С# или Java для подобных задач значительно более разумен. А высшие существа и отличается от планктона тем, что могут думать и принимать разумные решения. Другое дело, что есть разные стадии развития. То что человек может понять, что С++ не лучшее средство для офисной автоматизации — еще не означает, что он дальше не выключит мозг и не начнет закидывать задачи буденновками.

Собственно, можно тебя привести в пример. Ты же себя наверно идиотом не считаешь? И ведь ты как раз предпочел C# для решения тех самых офисных задач?

VD>>Зачем мне представлять "бы"? Я привел совершенно конкретный пример Яве/.NET. В них же все ОК с либами?

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

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

VD>>Да чушь это. И используют его не для системного программирования, а для черт знает чего. А тот же Линкус и ядро НТ один хрен на С написано. А новые ОС пишутся но новых языках.

CC>Windows 7 на чем пишут? Вроде ж новая...

В Windows 7 ядро Висты, в Висте ядро, ХРюши, в ХРюше ядро 2000-ных, ...
Намек ясен? Ядро как было на С, так и остается. Ну, иногда пара, тройка расширений из плеюсов. Но ты никогда не дождешся, чтобы в ОС экспортировался интерфейс на С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[9]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 15:00
Оценка: :)
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>И как обращаться из глубоко вложенного шаблона к параметру внешнего шаблона?


С этим проблем нет, если через параметры передаются ссылки на объекты.

LCR>А с динамической областью видимости можно обратиться прямо к var из template10 не протаскивая его через всю цепь вызовов. В обычных языках это конечно решается просто созданием глобального относительно template0..template10 бинда, а здесь такого нет. Или как?


Динамическая область видимости создает такие ошибки, что порой хоть "караул" кричи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[11]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 15:07
Оценка: -1
Здравствуйте, eao197, Вы писали:

VD>>"мягкого реального времени" — это по русски будет называться система не реального времени .


E>...Как авторитетно заявил видный специалист в области систем реального времени VladD2.


Ты сам то кроме как обсуждать других что-то еще сам можешь сказать?
Если, нет, то просто молчи.

Лучше иди почитай определение понятия реальное время. Реальное время — это гарантированные задержки. А так называемый софтриалтайм — это фактически их отсутствие. Под софтриалтам обычно понимают не реалтайм софт кторый большую часть времени выдает требуемую производительность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[10]: Почему "к сожалению"? :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 15:12
Оценка:
Здравствуйте, Erop, Вы писали:

E>Просто в твоём "кратком и лаконичном" варианте есть два существенных недостатка

E>1) Интерфейс плохо описан формально
E>2) Весь код, использующий интерфейс должен быть шаблонным. Иногда это довольно неприятное требование. А иногда и неприемлемое (например когда ты поставляешь наружу из DLL функцию, в которую надо передавать функтор)

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

Короче, тебе нужно немного почитать о других мирах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[10]: C++0X vs D programming lang
От: CreatorCray  
Дата: 20.11.08 15:12
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>>>Кто есть "офисный планктон"?

VD>>>Те кто выбирают инструменты "как все" и пишут код "как у всех" в итоге решая, скажем, задачи офисной автоматизации на С++.
CC>>Тогда по моим наблюдениям это уже С# и Java
VD>Человек выбирающий С# или Java для подобных задач значительно более разумен........
Я про то, что ["как все" и пишут код "как у всех"] — это уже те, кто на шарпе и жабе.

VD>И ведь ты как раз предпочел C# для решения тех самых офисных задач?

Не могу сказать что это было именно мое решение. Но для определенного круга офисных задач шарп ИМХО подходит лучше. Тут спорить я не собираюсь. У нас как раз такой круг: одно огромное приложение с которым юзер работает бОльшую часть времени.

VD>На счет "говна" не надо. Там как большей частью код приемлемый.

Ну, я бы сказал — сойдет.

VD> Не без маразма конечно, но до маразма С++-ных библиотек им все же долеко. К тому же их отличает внятный и логичный интерфейс.

Не всегда. Впрочем каки для других языков. Библиотеки пишут люди.

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

С++ных библиотек очень дофига. Я не думаю что ты видел их все.

VD>>>А новые ОС пишутся но новых языках.

CC>>Windows 7 на чем пишут? Вроде ж новая...
VD>В Windows 7 ядро Висты, в Висте ядро, ХРюши, в ХРюше ядро 2000-ных, ...
Это был подкол, если ты не заметил.
PS. В висте ядро 2003й
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: C++0X vs D programming lang
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 20.11.08 15:29
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>ИИ на С++ — это вообще для человека в этом немного понимающего должно звучать как Чубайс на нанотехнологиях .

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

Откуда такая информация? Анализ результатов трейдерских соревнований говорит, что сейчас рулят стохастические нейросети.

VD>Ваши замечательные программы-предсказатели не более чем мошенничество. Программа может помочь проанализировать большие объемы данных и выявить закономерности в прошлых операциях. Но рынок — это живой организм и никто (кроме инсайдеров) не может предсказать его поведения. А ваши замечательные программы просто подгоняются под старые данные, чтобы продать их по лучше. В любой игре нужно что-то большее чем алгоритм. Там нужно чутье и везение. Так что не надо про эти бредни здесь рассказывать.


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

VD>"мягкого реального времени" — это по русски будет называться система не реального времени .


Это общеупотребительный термин, я его не придумывал. По-русски он означает то же, что и на любом другом языке. К чему это замечание
https://elibrary.ru/author_counter.aspx?id=875549
Re[10]: C++0X vs D programming lang
От: FR  
Дата: 20.11.08 15:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Хоби меня не интересует. Главное, что ты пока что один (ОДИН) откликнулся и сказал, что твои задачи действительно соответствуют выбранному инструменту. А наши главные крикуны ставящие мне минусы на любое не лестное слово в адрес С++ тихо молчат в тряпочку. Подозреваю, что они как раз из тех, кто пишет софт для офисов и обосновывают это тем, что им дико не хватает производительности.


Ну у меня на данный момент задачи вполне соответствуют C++, притом быстродействие в общем не нужно, да и какое быстродействие у С++ builder, зато очень много и глубоко приходится копатся в WinAPI и COM в общем системные утилиты.
Re[9]: Вот тебе три задачи...
От: FR  
Дата: 20.11.08 15:38
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.


Есть подозрения что написана она на все-таки на си
Re[10]: Вот тебе три задачи...
От: FR  
Дата: 20.11.08 15:40
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Угу но не для всех задач подходит.

VD>Да и достали вы уже с этими графическими алгоритмами возмите готовую библиотеку (того же McКакЕгоТам) и пишите логику, а не утыкайтесь в частности обработки графики.


Re[9]: Вот тебе три задачи...
От: FR  
Дата: 20.11.08 15:40
Оценка: :)
Здравствуйте, VladD2, Вы писали:

FR>>А этот факт всегда игнорируется языкодвинутыми товарищами.


VD>Это ты о питонистах?


Не знаю, я теперь плюсист
Re[7]: Вот тебе три задачи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 15:41
Оценка:
Здравствуйте, Erop, Вы писали:

E>IMHO, ты не там интеллект ищешь...

E>Есть куча задач, в которых кодирование не представляет вообще никакой проблемы. Проблему представляет разработка и настройка алгоритмов. И тогда годится любой процедурный язык, без существенного встроенного оверхеда и поддерживаемый промышленными трансляторами и средами разработки...
E>И тогда, зачастую, конкурируют как раз С++ и C... Следующий кандидат (уже сильно хуже) -- что-то ООП из наследников PASCAL...

Ты представляешь какова разница между проектированием алгоритма на С++ и скажем ОКамле?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[10]: Вот тебе три задачи...
От: Курилка Россия http://kirya.narod.ru/
Дата: 20.11.08 15:50
Оценка: 6 (1) +1
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, VladD2, Вы писали:


VD>>Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.


FR>Есть подозрения что написана она на все-таки на си


Вот что лежит в папке src мнезии (770 килобайт из R12B-3):
mnesia.erl
mnesia.hrl
mnesia_backup.erl
mnesia_bup.erl
mnesia_checkpoint.erl
mnesia_checkpoint_sup.erl
mnesia_controller.erl
mnesia_dumper.erl
mnesia_event.erl
mnesia_frag.erl
mnesia_frag_hash.erl
mnesia_frag_old_hash.erl
mnesia_index.erl
mnesia_kernel_sup.erl
mnesia_late_loader.erl
mnesia_lib.erl
mnesia_loader.erl
mnesia_locker.erl
mnesia_log.erl
mnesia_monitor.erl
mnesia_recover.erl
mnesia_registry.erl
mnesia_schema.erl
mnesia_snmp_hook.erl
mnesia_snmp_sup.erl
mnesia_sp.erl
mnesia_subscr.erl
mnesia_sup.erl
mnesia_text.erl
mnesia_tm.erl
Re[11]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 15:56
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Откуда такая информация? Анализ результатов трейдерских соревнований говорит, что сейчас рулят стохастические нейросети.


И где твои миллионы?

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

Теоретические ратобы в области нейронных вычислений показывают точность предсказаний порядка 50%. Это все равно что кидать монетку или использовать генератор случайных чисел.

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

VD>>Ваши замечательные программы-предсказатели не более чем мошенничество. Программа может помочь проанализировать большие объемы данных и выявить закономерности в прошлых операциях. Но рынок — это живой организм и никто (кроме инсайдеров) не может предсказать его поведения. А ваши замечательные программы просто подгоняются под старые данные, чтобы продать их по лучше. В любой игре нужно что-то большее чем алгоритм. Там нужно чутье и везение. Так что не надо про эти бредни здесь рассказывать.


N>Так ведь и в алгоритмы постоянно меняются. Ни один разумный трейдер не будет 10 лет подряд доверять одному неизменному алгоритму. Мошенников, продающих советников, хватает. Но есть и серьёзные конторы, которые вместе с программой продают абонемент на регулярную корректировку параметров торговой системы в соответствии с коньюктурой рынка.


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

N>Если интересно, то почитай про Джеймса Саймонса. Он миллиардер, в его конторе не торгует ни один живой трейдер.


Ты еще про гебролайф почитай или еще что-то в этом дуже.

VD>>"мягкого реального времени" — это по русски будет называться система не реального времени .


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


К тому, что есть реальное время и все остальное. Софт-реалтайм == не реал-тайм. Это замечательный маркетинговый термин.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[11]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 16:05
Оценка:
Здравствуйте, Nuzhny, Вы писали:

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


Кстати, реалтайм-задачи можно решать хоть на скриптах. Это просто распространенное заблуждение, что риалтайм == очень быстро. Риалтайм значит — выполнение за гарантированное время. Скажем любые задачи по кодированию или декодированию видео не реалтайм задачи, так как пропуск одного двух кадров или задержка в работе на несколько миллисекунд не проблема для конечного результата. Главное чтобы картинка была приемлемой. А вот какой-нибудь софт отвечающий за инициацию некого процесса в ответ на поступающие сигналы, может допускать реакцию с задержкой до секунд, но при этом быть реалтайм, так как при превышении этих секунд управляемый им агрегат может просто сдохнуть.

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

В общем, ситуация просто смешная. 99% пишут на С++ черт знает что, но как только у них просят обосновать их выбор они сразу начинаю петь черт знает про что в том числе про риалтайм и каким-то боком причисленным к ниму кодированием видео.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[10]: Вот тебе три задачи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 16:06
Оценка: :))
Здравствуйте, FR, Вы писали:

VD>>Это ты о питонистах?


FR>Не знаю, я теперь плюсист


Это тебя жизнь то прижала.

А что делаешь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[12]: C++0X vs D programming lang
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.11.08 16:12
Оценка: +6
Здравствуйте, VladD2, Вы писали:

VD>>>"мягкого реального времени" — это по русски будет называться система не реального времени .


E>>...Как авторитетно заявил видный специалист в области систем реального времени VladD2.


VD>Ты сам то кроме как обсуждать других что-то еще сам можешь сказать?


Если по теме топика (C++0x vs D), то я уже неоднократно на эту тему высказывался, но могу повторить:
— D, по-моему мнению, не выйдет в мейнстрим. Поскольку его разработчик не заинтересован в том, чтобы язык использовался более-менее прагматичными программистами. Был бы заинтересован, то давно бы озаботился бы стабилизацией языка. В общем, как был он долгостроем, так и останется. Хотя и жалко.
— С++ будет вытеснен из многих сфер, в которых он оказался в 90-х, когда ни C# не было, ни Java не могла с ним конкурировать. Тем не менее, он уже давно достиг стадии бессмертности за счет огромного объема кода, который никто за раз не перепишет, а будут сопровождать и развивать. А выход C++0x сделает жизнь C++ников гораздо лучше.

Так же по теме топика я не согласен ни с теми, кто пропагандирует "modern C++ design", ни с теми, кто от C++ отказывается в пользу C. C++ как C with classes + разумное использование шаблонов -- вот то, чем я пользуюсь сам и требую от подчиненных.

Так же по теме топика я не согласен, что OCaml (другие компилируемые диалекты ML) или компилируемые варианты Lisp (какие, кстати?) являются конкурентами C++. В теории -- очень возможно, а вот на практике, с учетом кроссплатформенности, наличия оптимизирующих компиляторов, инструментов разработки/отладки/профилирования, библиотек, обученных профессионалов и пр. -- фигушки.

VD>Если, нет, то просто молчи.


Молчал до тех пор, пока маразм не начал переходить все границы.

VD>Лучше иди почитай определение понятия реальное время. Реальное время — это гарантированные задержки. А так называемый софтриалтайм — это фактически их отсутствие. Под софтриалтам обычно понимают не реалтайм софт кторый большую часть времени выдает требуемую производительность.


Различие между hard- и soft-real-time заключается в том, что:
— в hard-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны и, что самое важное, неизбежно приходит маленький пушной зверек;
— в soft-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны, но, что самое важное, маленький пушной зверек не приходит.
Однако, требований по укладыванию вычислений в отведенные кванты никто с soft-RT не снимал. И отсутствие маленького пушного зверька вовсе не означает, что разработка soft-RT гораздо проще hard-RT.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 16:16
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Я про то, что ["как все" и пишут код "как у всех"] — это уже те, кто на шарпе и жабе.


Как не странно — нет. С++ тут как минимум ничем не выделяется.

VD>>И ведь ты как раз предпочел C# для решения тех самых офисных задач?

CC>Не могу сказать что это было именно мое решение. Но для определенного круга офисных задач шарп ИМХО подходит лучше. Тут спорить я не собираюсь. У нас как раз такой круг: одно огромное приложение с которым юзер работает бОльшую часть времени.

Ну, вот видишь? Ты же не стал спорить или увольняться? Значит разделяешь это решение.

Интересно было бы узнать об офисных задачах для которых С++ был бы лучшим выбором. Поделись...

VD>> Не без маразма конечно, но до маразма С++-ных библиотек им все же долеко. К тому же их отличает внятный и логичный интерфейс.

CC>Не всегда. Впрочем каки для других языков. Библиотеки пишут люди.

Не всегда конечно. И именно потому что люди. Но я говорю о закономерности. Даже тот же МС создававшего просто таки чудовищно извращенные АПИ в стиле С и КОМ-а в дотнете таки отошли от "доброй традиции" и стали делать АПИ в которых в большинстве случаев можно разобраться без документации. Хотя дурь и тут бывает. Меня, например, дико "радует" System.IO.* в части перечисления файлов и каталогов. Это же надо было сделать их не итераторами, а массивами? В результате если тебе нужно вывести первые 100 файлов из огромного каталога, то ты вынужден ждать пока ОС не прочтет весь каталог. Но при этом все же АПИ получился понятны, в отличие от того же АПИ Винды.

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

CC>С++ных библиотек очень дофига. Я не думаю что ты видел их все.

Конечно не все. Но все что видел сразу поднимали у меня этот вопрос. Странно, правда?

VD>>>>А новые ОС пишутся но новых языках.

CC>>>Windows 7 на чем пишут? Вроде ж новая...
VD>>В Windows 7 ядро Висты, в Висте ядро, ХРюши, в ХРюше ядро 2000-ных, ...
CC>Это был подкол, если ты не заметил.
CC>PS. В висте ядро 2003й

Если ты не заметил, то разжовываю. Windows 7 не новая ОС. Там 90% старого кода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[11]: Вот тебе три задачи...
От: FR  
Дата: 20.11.08 16:20
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это тебя жизнь то прижала.


Угу, ладно бы еще нормальные плюсы с бустом и вкусными шаблонами, а у меня
C++ Builder

VD>А что делаешь?


Утилиты системные.
Re[13]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 16:29
Оценка:
Здравствуйте, eao197, Вы писали:

E>Так же по теме топика я не согласен, что OCaml (другие компилируемые диалекты ML) или компилируемые варианты Lisp (какие, кстати?) являются конкурентами C++. В теории -- очень возможно, а вот на практике, с учетом кроссплатформенности, наличия оптимизирующих компиляторов, инструментов разработки/отладки/профилирования, библиотек, обученных профессионалов и пр. -- фигушки.


Ну, то есть вопрос в инфраструктуре? Причем для С++ ее создали, а вот для другого не получится?

А мне кажется вопрос в головах. Прямые клоны МЛ и Лиспа слишком плохо влезают в голову тех кто способен освоить "С++ с классами" .

VD>>Если, нет, то просто молчи.


E>Молчал до тех пор, пока маразм не начал переходить все границы.


А маразм — это те случаи когда чужое мнение не совпадает с твоим?

VD>>Лучше иди почитай определение понятия реальное время. Реальное время — это гарантированные задержки. А так называемый софтриалтайм — это фактически их отсутствие. Под софтриалтам обычно понимают не реалтайм софт кторый большую часть времени выдает требуемую производительность.


E>Различие между hard- и soft-real-time заключается в том, что:

E>- в hard-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны и, что самое важное, неизбежно приходит маленький пушной зверек;
E>- в soft-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны, но, что самое важное, маленький пушной зверек не приходит.

Это не так. Ее всегда так. Есть "софт-реалтайм" который просто затормаживает процсс. Скажем то же потоковое видео. Пара кадров не успевших сжаться в реалтайме и пришедших чуть позже — не проблема, на фоне всего потока. Какие-то кадры сожмутся по быстрее и в целом поток останется равномерном с точки зрения человека. Только это уже не раелтайм.

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

E>Однако, требований по укладыванию вычислений в отведенные кванты никто с soft-RT не снимал. И отсутствие маленького пушного зверька вовсе не означает, что разработка soft-RT гораздо проще hard-RT.


Разработка не реалтайм-софта тоже может быть сложно. Да и реалтайм-софт может с успехом обеспечивать нужные характеристики даже будучи написанным на ВбСкрипте. Посему меня по прежнему удивляет зачем сюда притыкают С++. И чем он тут может помочь.

Все разумное о С++ заканчивается на том, что для него таки появились компиляторы с качественной оптимизацией. На этом все. Остальные домыслы про реалтайм и т.п. — это чушь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[12]: Вот тебе три задачи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 16:34
Оценка:
Здравствуйте, FR, Вы писали:

VD>>А что делаешь?


FR>Утилиты системные.


Как-то не определенно. А можно более развернутый ответ дать? И зачем для утилит Билдер?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[13]: C++0X vs D programming lang
От: FR  
Дата: 20.11.08 16:36
Оценка: 20 (1)
Здравствуйте, eao197, Вы писали:

E>Так же по теме топика я не согласен, что OCaml (другие компилируемые диалекты ML) или компилируемые варианты Lisp (какие, кстати?)


http://www.sbcl.org/
http://www.cons.org/cmucl/
http://www.cormanlisp.com/
Re[13]: Вот тебе три задачи...
От: FR  
Дата: 20.11.08 16:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Как-то не определенно. А можно более развернутый ответ дать? И зачем для утилит Билдер?


Утилиты разные, всякого рода чистильщики реестра, работа с файловой
системой, дефрагментаторы и тому подобное.
Потому что GUI довольно много и у работодателя есть GUI программисты на этом самом билдере,
и куча унаследованного (часто просто кошмарного) кода на нем.
Я же GUI не пишу, копаюсь в ядре там C++ очень даже на своем месте.
Re[10]: C++0X vs D programming lang
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.08 16:52
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Вот этот вопрос главный! И "офисный планктон" тут как раз и рулит как хвост собаков. Дело в том, что большая часть работников гигантов — это тот самый узколобый офисный планктон. Плюс планктон — это основной потребитель. Его проще убить чем переучить на что-то стоящее.

VD>По сему система самораскручивает бездарность и поддерживает экстенсивные средства разработки.

Ну нагородил...

ГВ>>Кроме Singularity, про какие ОС ты ещё можешь рассказать, которые пишутся не на C? Желательно, про те, которые уже продаются или имеют приличные шансы на это. Поскольку иначе ОС есть и на Lisp.

VD>Оберон ОС. Да их куча если покапаться.

И много продано?

VD>Просто в фаворе сейчас Вынь и Линл. И хрен ты что с этим сделаешь все по тем же причинам.


По одной причине: количество накопленного софта. Остальное в таких масштабах не считается.

VD>В общем, все варится в рынке где игроки имеют слишком не равные возможности. Это тормозит прогресс.


Ну не скажи, не скажи. Чарльз Бэббидж создал компьютер, а язык C сделал все компьютеры равными. Не так уж плохо, если разобраться.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: C++0X vs D programming lang
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.11.08 17:56
Оценка: 4 (1) +1
Здравствуйте, VladD2, Вы писали:

E>>Так же по теме топика я не согласен, что OCaml (другие компилируемые диалекты ML) или компилируемые варианты Lisp (какие, кстати?) являются конкурентами C++. В теории -- очень возможно, а вот на практике, с учетом кроссплатформенности, наличия оптимизирующих компиляторов, инструментов разработки/отладки/профилирования, библиотек, обученных профессионалов и пр. -- фигушки.


VD>Ну, то есть вопрос в инфраструктуре?


В очень большой степени -- да.

VD>Причем для С++ ее создали, а вот для другого не получится?


На данный исторический момент меня мало интересует что может быть или почему чего-то не случилось. Проблемы инфраструктуры OCaml или Lisp-ов это проблемы тех, кому эти языки нравятся. Мне, например, OCaml не нравится. В моих условиях (проекты очень приближенные к телекому) реальный выбор можно делать разве что из Java, C++, Eiffel и Ada.

VD>А мне кажется вопрос в головах. Прямые клоны МЛ и Лиспа слишком плохо влезают в голову тех кто способен освоить "С++ с классами" .


Я боюсь, что "C++ с классами" оказался слишком сложным для тех, кто кичится знаниями ML и Lisp-а.

VD>А маразм — это те случаи когда чужое мнение не совпадает с твоим?


Маразм -- это когда люди говорят, что за использование C++ нужно отрывать руки. Или что soft-real-time не является real-time.

VD>В общем, я говорил о том, что большинство людей говоря "реальное время" реально подразумевают приемлемую скорость. Отсюда и оксюмороны вроде софт-риалтайма появляются.


Оксюмороны это для тех, кто о реальном времени знает из Wikipedia.

Потоковая трансляция аудио/видео -- это всего лишь одно из применений soft-real-time. В промышленности очень большое количество информационно-измерительных систем, построенных на основе различных SCADA -- это все примеры мягкого реального времени.

VD>Да и реалтайм-софт может с успехом обеспечивать нужные характеристики даже будучи написанным на ВбСкрипте.


Скорее это попытка выдать online обработку за какое-то подобие real-time. В real-time обычным GC в принципе делать нечего, поэтому для JavaRT очень долго пилили специфический GC. А в нормальном real-time динамическая память вообще не используется.

VD>Посему меня по прежнему удивляет зачем сюда притыкают С++.


Поскольку C++ и Ada -- это, пожалуй, единственные высокоуровневые языки, которые позволяют программисту контролировать все издержки. Есть еще C, Oberon, Modula-2 и, вроде как, специальные адаптации Eiffel-я, но они либо ниже уровнем C++ и Ada, либо совсем экзотика. Не могу судить про Forth -- про его использование во встраиваемом ПО я слышал, но не уверен на счет RT.

VD>И чем он тут может помочь.


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

VD>Остальные домыслы про реалтайм и т.п. — это чушь.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: C++0X vs D programming lang
От: FR  
Дата: 20.11.08 18:04
Оценка:
Здравствуйте, eao197, Вы писали:

E>Поскольку C++ и Ada -- это, пожалуй, единственные высокоуровневые языки, которые позволяют программисту контролировать все издержки. Есть еще C, Oberon, Modula-2 и, вроде как, специальные адаптации Eiffel-я, но они либо ниже уровнем C++ и Ada, либо совсем экзотика. Не могу судить про Forth -- про его использование во встраиваемом ПО я слышал, но не уверен на счет RT.


У форта с этим все в порядке он к аппаратуре поближе чем C++ будет.
Re[11]: C++0X vs D programming lang
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.11.08 18:40
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Если интересно, то почитай про Джеймса Саймонса. Он миллиардер, в его конторе не торгует ни один живой трейдер.


Видимо до этого он был мультимиллиардер.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[12]: C++0X vs D programming lang
От: VoidEx  
Дата: 20.11.08 18:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Nuzhny, Вы писали:


N>>Если интересно, то почитай про Джеймса Саймонса. Он миллиардер, в его конторе не торгует ни один живой трейдер.


VD>Видимо до этого он был мультимиллиардер.


Эх, жаль смайлика с Петросяном в оценках нет. Обычный могут неверно понять.
Re[16]: C++0X vs D programming lang
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.11.08 19:13
Оценка:
Здравствуйте, FR, Вы писали:

E>>Поскольку C++ и Ada -- это, пожалуй, единственные высокоуровневые языки, которые позволяют программисту контролировать все издержки. Есть еще C, Oberon, Modula-2 и, вроде как, специальные адаптации Eiffel-я, но они либо ниже уровнем C++ и Ada, либо совсем экзотика. Не могу судить про Forth -- про его использование во встраиваемом ПО я слышал, но не уверен на счет RT.


FR>У форта с этим все в порядке он к аппаратуре поближе чем C++ будет.


Может быть. Никогда не попадались мне статьи о разработке встроенного ПО или RT систем на Форте. Про остальные вышеупомянутые языки читал неоднократно и видел открытые вакансии на разных сайтах (C++, Ada, Modula-2).

О Форте точно знаю со слов одного знакомого, который в московском Sparc-центре писал на Форте BIOS-ы для Sparc-ов. Так что я по поводу Форта не копенгаген, скорее осло


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: C++0X vs D programming lang
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 20.11.08 19:54
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>И где твои миллионы?


Надо понимать, что игра на Форексе — это мелкие спекуляции, попытка угадать движение "китов" рынка: финансовых воротил, центробанков крупнейших держав, международных корпораций. Т.е. при игре крупными суммами начинается влияние на рынок. Поэтому знания, данные нужны абсолютно другие. Мелкие спекулянты (к которым я и отношусь) и миллионы несовместимы.

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


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

VD>Теоретические ратобы в области нейронных вычислений показывают точность предсказаний порядка 50%. Это все равно что кидать монетку или использовать генератор случайных чисел.


Можно пару ссылок на такие работы? Уж больно сенсационно звучит.

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


Гм. Но ведь к тому и идёт. Данные из какого источника тебя бы убедили, что процент автоматических торговых систем постоянно возрастает?

VD>Ни один разумный человек не будет полагаться на решения принятые софтом. Использовать софт для принятия решений самостоятельно — разумно.



Эти два предложения противоречат друг другу. Поэтому мысль твою не уловил.

N>>Если интересно, то почитай про Джеймса Саймонса. Он миллиардер, в его конторе не торгует ни один живой трейдер.

VD>Ты еще про гебролайф почитай или еще что-то в этом дуже.

М? Ты не веришь информации, выдаваемой поисковиком про этого человека? Информацию из какого источника ты примешь как достоверную?
https://elibrary.ru/author_counter.aspx?id=875549
Re[12]: C++0X vs D programming lang
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 20.11.08 20:08
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Тут согласен. Но системы охранного видеонаблюдения всё равно относят к софт-реалтайм. В лаборатории МВД они тестируются на соответствие количеству fps. Редкий пропуск кадров допускается (не помню точно цифры), тут с тобой согласен.
Если интересно, то скажу, что логика верхнего уровня в нашей системе задаётся на скриптовом языке (доступном и для конечных пользователей). Работает быстро, гибко и удобно. Например, по сработке детектора движения надо повернуть камеру, включить прожектор, звуковое оповещение и т.п. Можно и гораздо более сложную логику написать, работать с интерфейсом. Но это не касается критических участков: обработки видео, звука, работы с приёмно-контрольными приборами. И пока все довольны.
https://elibrary.ru/author_counter.aspx?id=875549
Re[10]: Почему "к сожалению"? :)
От: byleas  
Дата: 20.11.08 21:14
Оценка:
Здравствуйте, Erop, Вы писали:

E>Если кратко, то поинт состоит в том, чтобы совершенствоваться не в овладениями шаблонами С++, а в овладении искусством писать хорошие программы...

Мир не замкнулся на шаблонах, это один из инструментов. Но вот со вторым овладением и появляются некоторые проблемы в некоторых компаниях.
Re[9]: Вот тебе три задачи...
От: Erop Россия  
Дата: 20.11.08 21:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Да любой клон МЛ-я или даже компилируемый Лисп.

А зачем? Кодирование в этих задачах не проблема будет. В чём будет выгода от функциональщины?

VD>Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.

Ну-ну... Популярная и мощная СУБД, наверное?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Вот тебе три задачи...
От: Erop Россия  
Дата: 20.11.08 21:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>У меня встречный вопрос. Ты сам то хоть одну из этих задач решаешь на работе?

VD>Если, нет, то чем занимаешся?

Другими задачами ИИ...
Думаю, при нужде, мог бы порешать и эти (кроме СУБД. Там решать уже нечего )
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: Почему "к сожалению"? :)
От: byleas  
Дата: 20.11.08 21:29
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>В майкрософте не используют не только особо продвинутые инструменты, но и сколько-либо мало-мальски продвинутые инструменты.

Используют, просто не везде.

Поинт 1:

The latter book engendered the Loki library, used in a variety of products, including Windows Vista (see attribution) and some Adobe products (see attribution)…

(c) Andrei Alexandrescu.

Поинт 2:

Пишут фактически на C с классами. Разумеется, наследуются от COM-интерфейсов, кроме них есть несколько базовых классов BaseEncoder, BaseDecoder, BaseBitmap да и все. Иерархии больше двух предков фактически нет.

Из темплейтов есть только один суровый джедайский контейнер DynArray, аналог std::vector, и все. Он настолько суров, что наверное следует сказать о нем пару слов. Он принципиально не зовет никаких конструкторов и никаких деструкторов, хочешь иницалироваться — зови inplace new или делай Init. Копирует, разумеется, тупо память, без всякой пидарасни с copy constructor. Большая часть реализации DynArray — не темплейтная, сам DynArray — ее темплейтный потомок, который только подставляет sizeof(T) базовому классу, практически все инлайнится. Есть вариант темплейта с начальным размером массива, он тогда выделится на стеке. Отличный контейнер, ничего лишнего.
Никаких смартпойнтеров (по мне, кстати, стоило бы).

Нет exceptions, вся обработка ошибок через return и HRESULT.

(c) CEMEH
Re[8]: Вот тебе три задачи...
От: Erop Россия  
Дата: 20.11.08 21:33
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты представляешь какова разница между проектированием алгоритма на С++ и скажем ОКамле?


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


И в наших задачах, например, С++ очень удобен, так как представляет довольно адекватную абстракцию компьютера, с одной стороны, и при этом позволяет писать довольно абстрактный код, при этом имеющий строго определённую и понятную процедурную семантику...
Правда им надо уметь свободно владеть. Для меня сложность кодирования какого-то уже известного алгоритма, представляется чем-то странным. Это же чисто технический вопрос. Он не требует исследований и всегда легко сходится
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 20.11.08 21:46
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты думаешь в терминах С++. Потому и выводы у тебя однобокие.

Вроде обсуждались С++ные функторы...

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

Угу, например C и С++...


VD>Короче, тебе нужно немного почитать о других мирах.

Ну это, знаешь что не надо делать, чтобы не узнать куда следует идти?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: C++0X vs D programming lang
От: byleas  
Дата: 20.11.08 21:50
Оценка:
Здравствуйте, Erop, Вы писали:

E>Ну и потом, КУДА, она пока что вроде как тока С и С++ поддерживает?

Для C# тоже связка есть.
Re[8]: Почему "к сожалению"? :)
От: byleas  
Дата: 20.11.08 22:05
Оценка: 6 (1)
Здравствуйте, kaa.python, Вы писали:

KP>Могут сократить. Могут увеличить. Но, обычно, проект нужен в лучшем случае прямо сейчас. Соответственно как не крути, код должен быть максимально простым, т.к. рассчитывать на то, что все специалисты в компании знают навороченные и сложные инструменты сложно (если конечно не в гугле или майкрософте работаешь).

Кстати, в этом вопросе интересен Adobe. Посмотреть на ASL (Adobe Source Libraries) — высокоуровневый С++: концепты, свойства, gil (generic image library), вошедшая в буст. И линейка продуктов. Работающая. Без крайностей вида HRESULT UIntMult(x,y,&z).
Re[11]: Почему "к сожалению"? :)
От: Erop Россия  
Дата: 20.11.08 22:06
Оценка:
Здравствуйте, byleas, Вы писали:

B>Мир не замкнулся на шаблонах, это один из инструментов. Но вот со вторым овладением и появляются некоторые проблемы в некоторых компаниях.


И так бывает. Но при чём тут тогда функторы?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: C++0X vs D programming lang
От: Erop Россия  
Дата: 20.11.08 22:10
Оценка: +1
Здравствуйте, byleas, Вы писали:

E>>Ну и потом, КУДА, она пока что вроде как тока С и С++ поддерживает?

B>Для C# тоже связка есть.

А что? Кто-то смог на "куде" реализовать ГЦ?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: C++0X vs D programming lang
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.11.08 23:03
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>У меня по тестам разница между VC 7.1 и ICC 10.1


Т.е. сравниваем VC 2002 года выпуска и свежайший еще пару недель назад компилер от Интеля?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[12]: C++0X vs D programming lang
От: EvilChild Ниоткуда  
Дата: 20.11.08 23:03
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Интересно было бы узнать об офисных задачах для которых С++ был бы лучшим выбором. Поделись...

А что такое офисные задачи?
Я думаю твои страхи по поводу C++ сильно преувеличены.
Я вот на C# пишу, рядом люди на C++ пишут, причём то, что было бы уместнее на C# писать
и так большинство их проблем с C++ вообще никак не связано.
Хотя некоторые болезни присущие ему безусловно людям кровь портят.
now playing: SCSI-9 — Waterglide
Re[17]: C++0X vs D programming lang
От: FR  
Дата: 21.11.08 03:41
Оценка:
Здравствуйте, eao197, Вы писали:

FR>>У форта с этим все в порядке он к аппаратуре поближе чем C++ будет.


E>Может быть. Никогда не попадались мне статьи о разработке встроенного ПО или RT систем на Форте. Про остальные вышеупомянутые языки читал неоднократно и видел открытые вакансии на разных сайтах (C++, Ada, Modula-2).


Ну он вообще-то даже создавался для решения именно такой задачи, система управления телескопом.

E>О Форте точно знаю со слов одного знакомого, который в московском Sparc-центре писал на Форте BIOS-ы для Sparc-ов. Так что я по поводу Форта не копенгаген, скорее осло


Я на нем немало пописал, но очень давно, сейчас остались только теплые воспоминания
Re[15]: C++0X vs D programming lang
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 21.11.08 04:44
Оценка:
Здравствуйте, eao197, Вы писали:

E>Скорее это попытка выдать online обработку за какое-то подобие real-time. В real-time обычным GC в принципе делать нечего, поэтому для JavaRT очень долго пилили специфический GC. А в нормальном real-time динамическая память вообще не используется.

На всякий случай намекну, что никакой обязанности выполнять сборку мусора наличие GC не накладывает.
Вполне нормальной практикой, к примеру, является вполне статическое выделение памяти под буфера на этапе инициализации; остатняя часть алгоритма, которая и шарашит в RT, выделениями вообще не занимается. В этом случае GC будет спать, пока его не позовут явно.
Невыделение памяти невовремя можно даже контролировать аналитическими тулзами типа FxCop.

И это — реально применяемая практика. GC, точнее его ограничения, вызывает проблемы не только в RT-системах. Даже в просто высоконагруженных системах с частыми обращениями в натив запиненые буфера вызывают преждевременную фрагментацию памяти; обходится это теми же мерами, что приведены выше.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[13]: C++0X vs D programming lang
От: gandalfgrey  
Дата: 21.11.08 07:59
Оценка:
Здравствуйте, eao197, Вы писали:

E>Если по теме топика (C++0x vs D), то я уже неоднократно на эту тему высказывался, но могу повторить:

E>- D, по-моему мнению, не выйдет в мейнстрим. Поскольку его разработчик не заинтересован в том, чтобы язык использовался более-менее прагматичными программистами. Был бы заинтересован, то давно бы озаботился бы стабилизацией языка. В общем, как был он долгостроем, так и останется. Хотя и жалко.
А разве ветка 1.xx не является стабильной ? Там заметных изменений и не появляется. Одно время доверчивых программеров стращали грядущей веткой 3.хх — якобы Брайт при подстрекательстве одиозного Александреску сделает из Д что-то совсем непредставимое.

E>Различие между hard- и soft-real-time заключается в том, что:

E>- в hard-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны и, что самое важное, неизбежно приходит маленький пушной зверек;
E>- в soft-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны, но, что самое важное, маленький пушной зверек не приходит.
E>Однако, требований по укладыванию вычислений в отведенные кванты никто с soft-RT не снимал. И отсутствие маленького пушного зверька вовсе не означает, что разработка soft-RT гораздо проще hard-RT.
Я бы поправил это таким образом : Софт-реалтайм означает, что заданный процент вычислений должен укладываться в заданный квант времени.
Re[14]: C++0X vs D programming lang
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 21.11.08 08:30
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

G>А разве ветка 1.xx не является стабильной ?


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

Но смысла связываться с 1.* лично я не вижу, т.к. развиваться она уже не будет -- все новое добавляют в 2.*, которая не совместима с 1.*. Т.е. нет смысла что-то делать на 1.* зная, что после выхода 2.* придется переделывать, причем серьезно, т.к. в 2.* есть константность и иммутабельность.

G>Одно время доверчивых программеров стращали грядущей веткой 3.хх — якобы Брайт при подстрекательстве одиозного Александреску сделает из Д что-то совсем непредставимое.


Последнее, что я слышал про планы по поводу D -- это выход 2.0 с константностью, иммутабельностью, nothrow и, возможно, pure-функциями осенью этого года. Но пока не слышно. А в D 3.0 собирались добавить синтаксические макросы.

Александреску уже сделал для D2 что-то вроде адаптации C++ного STL (http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html , http://www.digitalmars.com/d/2.0/phobos/std_functional.html). И вообще, после подключения Александреску к разработке D появился очень серьезный крен в сторону поддержки ФП в языке (как раз константность, иммутабельность и pure-функции).

E>>Различие между hard- и soft-real-time заключается в том, что:

E>>- в hard-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны и, что самое важное, неизбежно приходит маленький пушной зверек;
E>>- в soft-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны, но, что самое важное, маленький пушной зверек не приходит.
E>>Однако, требований по укладыванию вычислений в отведенные кванты никто с soft-RT не снимал. И отсутствие маленького пушного зверька вовсе не означает, что разработка soft-RT гораздо проще hard-RT.
G>Я бы поправил это таким образом : Софт-реалтайм означает, что заданный процент вычислений должен укладываться в заданный квант времени.

Как раз не соглашусь: hard- отличается от soft- как раз тяжестью последствий. Допустимый процент непопаданий для soft-а -- это уже критерии качества конкретной soft-RT системы при ее приемке.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: C++0X vs D programming lang
От: CreatorCray  
Дата: 21.11.08 09:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>И ведь ты как раз предпочел C# для решения тех самых офисных задач?

CC>>Не могу сказать что это было именно мое решение.
VD>Ну, вот видишь? Ты же не стал спорить или увольняться? Значит разделяешь это решение.
Я ж не фанатик

VD>Но при этом все же АПИ получился понятны, в отличие от того же АПИ Винды.

По мне так WinAPI достаточно понятен и прост. Впрочем кому как.

VD>Если ты не заметил, то разжовываю. Windows 7 не новая ОС. Там 90% старого кода.

Новых, чтоб совсем с нуля я в жизни вне тепличных условий вообще не встречал.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: C++0X vs D programming lang
От: CreatorCray  
Дата: 21.11.08 09:04
Оценка:
Здравствуйте, AndrewVK, Вы писали:

CC>>У меня по тестам разница между VC 7.1 и ICC 10.1

AVK>Т.е. сравниваем VC 2002 года выпуска и свежайший еще пару недель назад компилер от Интеля?
7.1 == VC2003.
В общем это не важно. Просто ICC у меня установлен под 2003-ю. Под ней и вся работа идет.
Я когда то сравнивал с 2005-й — соотношение было такое же.
Ставить монстра 2008 со всем его .NET-oriented говном чтоб писать на С++ — нафиг нафиг. У меня на работе весь зоопарк стоит, только пишу я тут под С#.
Чисто по работе с кодом 2003я из них самая шустрая.

ICC 10.1 уже относительно старенький
ICC 11.0 — свежий, но из за одного бага в оптимизаторе он VC7.1 на моих тестах как раз на криптухе слил Но на остальных тестах выиграл даже у 10.1, хотя и немного.
Жду вот, когда они пофиксят багу, чтоб по нормальному уже протестировать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: C++0X vs D programming lang
От: gandalfgrey  
Дата: 21.11.08 09:43
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну типа является (багов в ней еще достаточно осталось, судя по тому, сколько их при каждом минорном релизе фиксится).

Да, но сам язык уже не меняется.

E>Но смысла связываться с 1.* лично я не вижу, т.к. развиваться она уже не будет -- все новое добавляют в 2.*, которая не совместима с 1.*. Т.е. нет смысла что-то делать на 1.* зная, что после выхода 2.* придется переделывать, причем серьезно, т.к. в 2.* есть константность и иммутабельность.

Дык ить, кто-то заставляет переходить 1.хх на 2.хх ? Выбор прост : нужно что-то новое — вперед, к ветке 2.хх и дальше. Не надо ничего нового — все устраивает — дык никто ветку 1.хх не закрывал

E>Последнее, что я слышал про планы по поводу D -- это выход 2.0 с константностью, иммутабельностью, nothrow и, возможно, pure-функциями осенью этого года. Но пока не слышно. А в D 3.0 собирались добавить синтаксические макросы.

Читал на форумах, что собираются паттерн-матчинг присобачить. И сделать, наконец, нормальные тупли !
Я лично еще хочу легковесные изолированные процессы и обмен сообщениями ! А ! Чуть не забыл ! Еще встроенную сериализацию ( правда, для статически типизированного языка слабо представляю саму возможность этого ) 8))))

E>Как раз не соглашусь: hard- отличается от soft- как раз тяжестью последствий. Допустимый процент непопаданий для soft-а -- это уже критерии качества конкретной soft-RT системы при ее приемке.

Насчет тяжести последствий : сбор данных о расходе энергии / жидкости / газа — это жесткий или мягкий реалтайм ?
Re[10]: Вот тебе три задачи...
От: Mamut Швеция http://dmitriid.com
Дата: 21.11.08 10:04
Оценка:
VD>>Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.
E>Ну-ну... Популярная и мощная СУБД, наверное?

Define: популярная
Define: мощная



Влад правильно заметил, что обычно люди не вижят ничего дальше MSSQL, Orcale и DB2 только потому что они у всех на виду и на слуху


dmitriid.comGitHubLinkedIn
Re[15]: C++0X vs D programming lang
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.11.08 10:44
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

AVK>>Т.е. сравниваем VC 2002 года выпуска и свежайший еще пару недель назад компилер от Интеля?

CC>7.1 == VC2003.

Я в курсе. RTM был в конце 2002 года.

CC>В общем это не важно. Просто ICC у меня установлен под 2003-ю. Под ней и вся работа идет.


И чего? От этого он оптимизирует на уровне ICC 7.0?

CC>Ставить монстра 2008 со всем его .NET-oriented говном


В этом плане 2008 ничем от 2003 не отличается, shell и базовые сервисы те же самые с мелкими багфиксами, ".NET-oriented говно" тебя ставить никто не заставляет. Ситуация немножко изменится только в 2010.

CC>ICC 10.1 уже относительно старенький

CC>ICC 11.0 — свежий

Ну понятно, все как я и ожидал — icc возрастом в год старенький, а vc возрастом 6 леи — новье. Больше вопросов нет.

CC>Жду вот, когда они пофиксят багу


Долго ждать будешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[16]: C++0X vs D programming lang
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.11.08 10:44
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


В последнем СП предложено решение поинтереснее — можно получить нотификацию о пришествии GC. Это позволяет оповестить load balancer чтобы он не использовал в кластере узел, погруженный в GC.
Ну а в 4.0 обещают GC, который работает парналлельно и практически не использует локов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[11]: Вот тебе три задачи...
От: Erop Россия  
Дата: 21.11.08 11:08
Оценка: +2
Здравствуйте, Mamut, Вы писали:

M>Define: популярная

В % каких-нибудь не затруднит выразить популярность?
M>Define: мощная
Тоже интересно бы почитать сранвнение с ораклом, или с MSSQL, хотя бы...

M>

M>Влад правильно заметил, что обычно люди не вижят ничего дальше MSSQL, Orcale и DB2 только потому что они у всех на виду и на слуху

Да ладно. Ты прниводи объективные преимущества, которых люди не видят. Потому, как "прога хорошая, но пользователи слишком тупы, чтобы этим пользоваться" -- это не преимущество, а недостаток... IMHO...

Скажем мне не нужна зажигалка, на использование которой мне не хватает ума. И прога такая тоже не нужна...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: C++0X vs D programming lang
От: CreatorCray  
Дата: 21.11.08 11:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Я в курсе. RTM был в конце 2002 года.

AVK>И чего? От этого он оптимизирует на уровне ICC 7.0?
С 2005-й тоже сравнивал, если ты не заметил.

CC>>Ставить монстра 2008 со всем его .NET-oriented говном

AVK>В этом плане 2008 ничем от 2003 не отличается, shell и базовые сервисы те же самые с мелкими багфиксами, ".NET-oriented говно" тебя ставить никто не заставляет. Ситуация немножко изменится только в 2010.
Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?

CC>>Жду вот, когда они пофиксят багу

AVK>Долго ждать будешь.
Не думаю. Прошлую (с делением float на 10^х пофиксили довольно быстро)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: C++0X vs D programming lang
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.11.08 12:06
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>С 2005-й тоже сравнивал, если ты не заметил.


2004 год.

CC>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?


А, религия. Ну тогда ладно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: C++0X vs D programming lang
От: Klapaucius  
Дата: 21.11.08 12:19
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>Затем что оба в одинаковой ж...


А как в D обстоят дела с интеропом с C++?
Когда я последний раз интересновался, все было, насколько я помню, не очень радужно — только через C.
Это довольно странно, ведь D позиционируется как замена C++.
Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[18]: C++0X vs D programming lang
От: CreatorCray  
Дата: 21.11.08 12:22
Оценка:
Здравствуйте, AndrewVK, Вы писали:

CC>>С 2005-й тоже сравнивал, если ты не заметил.

AVK>2004 год.
2010 еще не вышла.

CC>>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?

AVK>А, религия. Ну тогда ладно.
Т.е. нормальным считается понаставить кучу совершенно ненужного говна?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: C++0X vs D programming lang
От: CreatorCray  
Дата: 21.11.08 12:23
Оценка:
Здравствуйте, AndrewVK, Вы писали:

CC>>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?

AVK>А, религия. Ну тогда ладно.
Вдогон. Ты кстати видел что именно входит в список обязательно устанавливаемого?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: C++0X vs D programming lang
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 21.11.08 12:32
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

E>>Как раз не соглашусь: hard- отличается от soft- как раз тяжестью последствий. Допустимый процент непопаданий для soft-а -- это уже критерии качества конкретной soft-RT системы при ее приемке.

G>Насчет тяжести последствий : сбор данных о расходе энергии / жидкости / газа — это жесткий или мягкий реалтайм ?

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

По поводу сбора данных -- it depends. Насколько я помню, бывают счетчики с ограниченным диапазоном значений -- не успел вовремя вычитать, он уходит в ноль. Получается, что работа с таким оборудованием -- уже hard RT. Если сбор данных будет сопровождаться каким-то управлением (типа открывания/закрывания задвижек), то опять может быть hard RT (слишком позднее срабатывание задвижки черевато аварией). Если система строится на основе ОС, не предоставляющей hard RT гарантии, то все равно лучше soft RT может ничего не получится. И т.д.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: C++0X vs D programming lang
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 21.11.08 12:42
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

E>>Ну типа является (багов в ней еще достаточно осталось, судя по тому, сколько их при каждом минорном релизе фиксится).

G>Да, но сам язык уже не меняется.

E>>Но смысла связываться с 1.* лично я не вижу, т.к. развиваться она уже не будет -- все новое добавляют в 2.*, которая не совместима с 1.*. Т.е. нет смысла что-то делать на 1.* зная, что после выхода 2.* придется переделывать, причем серьезно, т.к. в 2.* есть константность и иммутабельность.

G>Дык ить, кто-то заставляет переходить 1.хх на 2.хх ? Выбор прост : нужно что-то новое — вперед, к ветке 2.хх и дальше. Не надо ничего нового — все устраивает — дык никто ветку 1.хх не закрывал

Ситуация несколько сложнее. Язык версии 1.* вроде как есть и поддерживается пока только одним компилятором DMD на платформах x86 Windows и Linux. Под него существуют некоторые библиотеки. И все. Совершенствованием 1.* больше никто не занимается. Новые библиотеки создаются уже для 2.*. Даже у Tango появилась ветка для D 2.0, хотя сама Tango так до 1.0 пока и не дошла.

Т.е. если сейчас заложиться на диалект 1.* для долгосрочных проектов, то это означает, что в скором времени эти проекты окажутся привязанными к умершей ветке языка с ограниченным количеством инструментов и библиотек. Поскольку я не слышал о том, что кто-то хочет дальше заниматься D 1.0.

E>>Последнее, что я слышал про планы по поводу D -- это выход 2.0 с константностью, иммутабельностью, nothrow и, возможно, pure-функциями осенью этого года. Но пока не слышно. А в D 3.0 собирались добавить синтаксические макросы.

G>Читал на форумах, что собираются паттерн-матчинг присобачить.

Я читаю только news.digitalmars.announce, про паттерн-матчинг не слышал.

G> И сделать, наконец, нормальные тупли !


Тупли там на основе шаблонов. Имхо, более простые в освоении и использовании, чем в C++0x.

G>Я лично еще хочу легковесные изолированные процессы и обмен сообщениями ! А ! Чуть не забыл ! Еще встроенную сериализацию


У вас же есть Erlang, зачем вам что-то еще?

G>(правда, для статически типизированного языка слабо представляю саму возможность этого ) 8))))


К статически-типизированным языкам типа C++/D даже невстроенная сериализация с продвинутыми возможностями приделывается на раз.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: C++0X vs D programming lang
От: CreatorCray  
Дата: 21.11.08 12:51
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

CC>>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?

AVK>А, религия. Ну тогда ладно.

Вот нафига мне при установке ТОЛЬКО C++ без MSDN.

Document Explorer
Web Authoring
SQL Server Compact + SQL Server Design tools
SDK for .Net framework tools
SDK reference assemblies
SQL publishing Wizard

А оно ставится всегда и без спросу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: C++0X vs D programming lang
От: FR  
Дата: 21.11.08 13:07
Оценка: 1 (1)
Здравствуйте, Klapaucius, Вы писали:

K>А как в D обстоят дела с интеропом с C++?

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

Появилась ограниченная подержка C++ http://www.digitalmars.com/d/2.0/cpp_interface.html
Всегда была подержка COM http://www.digitalmars.com/d/2.0/COM.html

K>Это довольно странно, ведь D позиционируется как замена C++.


Угу именно как замена, полноценную же подержку C++ можно реализовать только сделав C++ подмножеством D.

K>Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.


Учитывая прозрачную связь с си http://www.digitalmars.com/d/2.0/interfaceToC.html и вышенаписанное у D в этом отношении все вполне нормально.
Ж.. же одинаковая не техническая а политическая, выражающаяся в близкой к нулю популярности обоих инструментов.
Re[9]: Вот тебе три задачи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.11.08 13:10
Оценка:
Здравствуйте, Erop, Вы писали:

VD>>У меня встречный вопрос. Ты сам то хоть одну из этих задач решаешь на работе?

VD>>Если, нет, то чем занимаешся?

E>Другими задачами ИИ...


А, можно подробнее?

E>Думаю, при нужде, мог бы порешать и эти (кроме СУБД. Там решать уже нечего )


Ага. 640 Кбайт хватит всем (с) Бил Гейтс
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[8]: C++0X vs D programming lang
От: FR  
Дата: 21.11.08 13:17
Оценка: 1 (1)
Здравствуйте, Klapaucius, Вы писали:

K>Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.


Кстати Java библиотеки легко транслируются на D http://www.dsource.org/projects/dwt
Re[9]: Вот тебе три задачи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.11.08 13:24
Оценка: -1 :)
Здравствуйте, Erop, Вы писали:

VD>>Ты представляешь какова разница между проектированием алгоритма на С++ и скажем ОКамле?


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

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

Я правильно понял, что ответ на мой вопрос — "нет"?

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


Как ты можешь судить об удобстве чего-то не попробовав альтернативы?

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


Алгоритмы бывают весьма сложными. Например, алгоритм вывода типов в современном ЯП или алгоритм сжатия данных. Реализовывать их лопатой вроде С++, то реализация будет в десятки (а то и в сотни) раз сложнее спецификации. За тем и нужны более высокоуровневые и удобные языки, чтобы уменьшить разницу между спецификацией и реализацией. Кроме того обычно алгоритмы выражаются не четко и при их реализация почти всегда становится процессом творческим, что опять таки значительно проще осуществить используя удобный, мощный, высокоуровневый язык, нежели ассемблер с классами. Так что твои слова выглядят как хвастовства и бравада. Но понять ты это не сможешь если сам не освоишь хотя бы один более высокоуровневый язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[19]: C++0X vs D programming lang
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.11.08 14:30
Оценка: +1 -1
Здравствуйте, CreatorCray, Вы писали:

CC>>>С 2005-й тоже сравнивал, если ты не заметил.

AVK>>2004 год.
CC>2010 еще не вышла.

Зато вышла 2008. Примерно в то же время, что и icc 10.1.

AVK>>А, религия. Ну тогда ладно.

CC>Т.е. нормальным считается понаставить кучу совершенно ненужного говна?

Нормальным считается сравнение инструментов одного возраста. А уж, учитывая что сейчас ты занимаешься разработкой на C#, твои отмазки про то, что VS 2003 самое оно, выглядят ну очень неубедительно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[19]: C++0X vs D programming lang
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.11.08 14:30
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


Не поверишь — мне пофик.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[19]: C++0X vs D programming lang
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.11.08 14:30
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Document Explorer


MSDN Library и внутренняя справка VS.

CC>Web Authoring


Team Suite ставил?

CC>SQL Server Compact + SQL Server Design tools


А разве его нельзя отменить?

CC>SDK for .Net framework tools


Как такового, отдельного .NET SDK в 2008 студии уже нет, есть Windows SDK 6.0A.

CC>SQL publishing Wizard


Функционал самой студии.

CC>А оно ставится всегда и без спросу.


Ужос просто.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[10]: Вот тебе три задачи...
От: Erop Россия  
Дата: 21.11.08 14:35
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Другими задачами ИИ...

VD>А, можно подробнее?
Зачем тебе?

E>>Думаю, при нужде, мог бы порешать и эти (кроме СУБД. Там решать уже нечего )

VD>Ага. 640 Кбайт хватит всем (с) Бил Гейтс
Ну, сейчас, если и развивать СУБД, то лучше из уже имеющейся, работающей системы...
А они, сюрприз-сюрприз -- обычно на С/С++ написанны...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: C++0X vs D programming lang
От: CreatorCray  
Дата: 21.11.08 14:56
Оценка:
Здравствуйте, AndrewVK, Вы писали:

CC>>Document Explorer

AVK>MSDN Library и внутренняя справка VS.
при установке ТОЛЬКО C++ без MSDN.

CC>>Web Authoring

AVK>Team Suite ставил?
Нет

CC>>SQL Server Compact + SQL Server Design tools

AVK>А разве его нельзя отменить?
Нет

CC>>SDK for .Net framework tools

AVK>Как такового, отдельного .NET SDK в 2008 студии уже нет, есть Windows SDK 6.0A.
И тем не менее в процессе инсталляции 2008й нечто под таким названием пытается ставиться

CC>>SQL publishing Wizard

AVK>Функционал самой студии.
Зачем он при установк