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

Это сообщение отредактировал(а) Lazin - 25.8.2009, 15:43

НЕТ!!!   

Я для ++ только один вариант исользования оставил - кросс-платформенный GUI. Тут Qt меня устраивает как ничто другое. 

Какой бы вариант выбрать?
"Да, не нужен", или "Нет, не нужен"? 

Добавлено через 1 минуту и 55 секунд
А вообще любая вещь кому-то либо нужна, либо нет.
А кому-то нужна, но не сейчас - пусть лежит...
Каждому своё...

А у мну как раз такая задача, ничего лучше плюсов придумать не могу (хотя про OCaml и Haskell, несомненно, труЪ).

ДА!!!


Qt это еще одно доказательство того, что "плюсы", это тупиковая ветвь, ведь это на самом деле не совсем С++. Мне очень нравится программировать на Си и на С++, это дает ощущение полного контроля над тем, как будет работать программа, позволяет контролировать семантику, то, где и как будут создаваться объекты и тд. Но просто в последнее время, я обратил внимание на то, что приличную часть времени я трачу на реализацию того, что в других языках программирования работает "из коробки". Например вывод типов, или пытаюсь реализовать ленивый ввод/вывод через задницуитераторы и тд.

ну, рано или поздно она станет сложной  

отсюда

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

  По этому поводу у CodeMonkey есть хорошая подпись. 



  Ток вместо паскаля можно туда еще подставить C#, Python, Java и т.д.

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

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


только паскаль намного хуже, паскаль не назовешь более высокоуровневым языком чем С++ и технических деталей там то-же хватает, при этом он обладает более громоздким и не гибким синтаксисом, там вообще нет средств обобщенного программирования, если не считать макросов(хотя в последней версии и появились, но это скорее дженерики a-la C#, чем что-то похожее на шаблоны С++), можно работать с памятью, есть указатели, но нет арифметики указателей!!!  что делает его более опасным в этом нелегком деле, а код непереносимым на не x86 платформы. Может в паскале многих проблем и нет, но это только потому, что сложные проблемы на нем не решают  

  Это все есть, но оно не нужно, это не стиль делфи.  В общем и целом Delphi это тенденция уйти от указателей совсем. Указатели это низкоуровневые средства, которые остались для увеличения возможностей. Ты просто пытался на паскале писать сиподобный код. Это совершенно неудобно. Заметь в делфях есть семантика неявного разыменования и неявные ссылки. Все это должно как бы намекать, не используй указатели совсем. Используй управляемые массивы строки и интерфейсы. Максимально автоматизируй работу с памятью. Согласен TList неудобен, но есть TStringList/TObjectList/TComponentList. Отказывайся от статического связывания, переходи к динамическому связыванию объектов и интерфейсов. Как только ты уйдешь от статики, так сразу поймешь недостатки С++ и удобства Delphi и других языков. Статика негибкая. 

Не добалял никто макросы. Добавили именно что дженерики.

Lazin, так а как же linux? Mono, говорят пока сыроват.

На линуксе питон рулит  .

я одного не понял, при чем тут delphi? 
OCaml и Haskell там есть, а вот delphi - нет  
а delphi для Mac OS X - тем более нет, а OCaml и Haskell - есть  

Lazin, ты просто делфифоб, и твои слова тому подтверждение. 
Rohoss говорил про С++, мол как же на линуксе без плюсов, просто некуда. На самом деле и на линуксе можно прекрасно жить без плюсов. Например любимый всеми пиджин на питоне написан, по большей части да и много другого софта. 

ага, особенно libpurple... еще скажи что на delphi...  

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

Никакой не латентный, я кое-что делал на дельфи, по необходимости, по этому знаю, что это не то что мне нужно  

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

  
Что касается Дельфи - вообще не понятно его существование, когда есть С#. Особенно улыбает тот факт, что есть плагин под студию где можно разрабатывать код на Delphi под .NET. 

  Так это дело рук кодегировцев. Delphi Prism поддерживает все возможности .NET 3.5. Так что возможности есть. Сейчас в проекте x64 и Linux. Так что все со временем будет. Delphi for Win32 уже на уровне .NET 2.0, но при этом дает нативный код. 
  
  Но, вообще, на сегодняшний день самым разумным является 2х ступенчатый подход, когда пишут для некой платформы не привязанной к железу и есть универсальная адаптация этой платформы под железо. Т.е. тебе не нужно делать глубокие тесты на всех платформах и ловить все особенности. У тебя есть гарантированный набор возможностей на который ты можешь рассчитывать вне зависимости от железа. 
  С++ не соответствует этой концепции. Поэтому его доля будет снижаться.

есть подозрения - что скорее Дельфи вольется в студию, чем Embarcadero наконец то сделает поддержку x64.

Это про Mono?


почему не соответствует? них фирштейн.

  В перспективе нативная поддержка.


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

Я конечно не эксперт в языках, но считаю что мнение о С++ неверно. Как известно все известные фреймворки такеи как Ява , дотнет.... предоставляют программисту удобство и избавляют его от рутинной и опасной работы c памятью. И это очень хорошо. Но ведь большинство функций этих каркасов реализовано на с++. И для машины полюбом нужен такой язык который может работаь напрямую с памятью. Я думаю С++ нужен как академическая и научная платформа для всех программистов. Я думаю корррекней было бы сказать не "C++ не нужен", a  "Мне в моем проекте для реализации конкретной задачи я могу обойтись без C++". Говорить что С++ не нужен - то же самое что говорить: "Блин, нафиг я 5 лет в универе штаны протирал, вот лучше бы купил самоучитель :Выучи С# за 24 дня - 10 минут на урок, и уже бы давно в визарде формы ваял".

  Нужен. Один раз написать явамашину и ее поддерживать, а в 1000 раз больше программистов будут просто использовать то что один раз оптимально и эффективно написано. Ява-машина это узкий перешеек между железом и многообразием ява-приложений. Он действительно является узким также в смысле производительности, что должен быть вылизан до предела, но только лишь он. Ведь не скажешь даже, что каждый 10й или каждый 100й программист пишет явамашины или аналогичные вещи.
  Речь идет о вытеснении С++ как высокоуровневого языка. Т.е. долой с массового рынка. Да с байтиками и битиками удобно играться, удобно залезть в абсолютный адрес.
  А теперь подумай, если в С++ нативные средства управления или создания потоков? Синхронизация? Межпроцессорная синхронизация или обмен. Средства для многомодульного программирования или распределенного? 
  Чаще всего это решается для текущей платформы непереносимыми возможностями, после чего наступает длительный этап проверки на всевозможных машинах и появления многих сюрпризов. Такие решения нельзя назвать удачными. 
  Delphi по крайней мере декларирует работу под Windows разных версий и набор родных, стандартных классов для работы с ней. Любой программист Delphi посмотрит код и поймет чего в нем происходит, потому что используются стандартные классы. Безусловно в этом вопросе C# далеко переплюнул Delphi for Win32, но его тоже нужно хорошо изучать и понимать какие языковые средства являются быстрыми, какие удобными но медленными, где можно ожидать нагрузку на сборщик мусора или менеджер памяти. 
  Кроме того алгоритмы они не зависят от языка, архитектуры данных, схемы взаимодействий объектов, архитектура приложения. Чтобы грамотно владеть C# понадобиться не одна неделя, и даже не один год наверное.

в tr1 уже есть синхронизация и потоки, есть OpenMP, TBB итд
interporcess - не просто стандартизировать, взять к примеру те-же средства delphi win32 и его классы для межмодульного взаимодействия, можно-ли их реализовать на posix api?  
в бусте есть библиотека interprocess, кроссплатформенная, она работает одинаково на разных платформах, но к примеру под windows, shared memory эмулируется с помощью отображаемых в память файлов, так как семантика shared memory POSIX не реализуется иными средствами в win32

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

Добавлено через 58 секунд
also, delphi sucks and 

Добавлено через 11 минут и 10 секунд

COBOL, это то-же классика, между прочим до 80% используемого сейчас кода написано на нем - The statistics that surround COBOL attest to its huge influence upon the business world. [B]There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world's actively used code.[/B] There are estimated to be over a million COBOL programmers in the world today. Most impressive perhaps, is that 200 times as many COBOL transactions take place each day than Google searches - a figure which puts the influence of Web 2.0 into stark perspective.
но будущего у него нет

  Во первых новый стандарт еще не принят и не реализован. 

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

  boost это не стандарт, его и подключить можно далеко не ко всем компиляторам. 


  Линковка в рантайме. 
Вот например у меня есть платформа BlackFin и компилятор С++. нативными средствами С++ я не могу
1) Сделать таймер.
2) Вывести строку в cout
3) Вызвать assert()
4) Вывести что либо на экран
5) Вывести запустить второй поток
6) Синхронизировать 2 потока.
7) Синхронизировать поток и прерывание
8) Не могу сделать модуль так чтобы две программы использовали один и тот же кусок кода (например zlib)
9) Не могу создать/удалить/вывести в файл.
10) Эффективно работать с юникодом.

Теперь возьмем ява-программу для телефона. Разница очевидна. Имеется ява платформа, которая гарантирует мне определенный набор возможностей вне зависимости от типа процессора. Создатель телефона трудиться для того чтобы реализовать, то затребовала ява платформа, иначе телефон никто не купит.
Создатель компилятора С++ имеет минимум забот, зато теперь каждый программист С++ имеет кучу гемороя по изобретению велосипеда и каждый новый программист будет делать свой велосипед.
  
  Массовый программист должен иметь перед собой уже не полуфабрикат, готовую шоколадку, где некий стандарт гарантирует перечень ресурсов, ну или можно запросить у машины стандартным образом, умеешь ли ты делать такое? Или разрешено ли тебе такое.

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

С++ годиться только для одноуровневой схемы, которая устаревает постепенно. 

11) Открывать пиво
12) Заказывать пиццу
напиши свои велосипеды - с преферансом и блудницами  
а вообще, компилятор с++ и стандартные библиотеки, это не платформа, все это должно расширяться сторонними библиотеками, в этом вся прелесть данного подхода, никто не заставляет использовать boost, или zlib


тут я бы то-же поспорил, для .NET есть P/Invoke, для Java - JNI, и С++ вполне годен для реализации каких-либо требовательных к ресурсам частей системы

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

Это сообщение отредактировал(а) Lazin - 26.8.2009, 14:42

Епт! Собственно вот на это я и хотел указать.
  C#, Java, Python, Perl, PHP это все платформа, языки предназначенные для 2го уровня двухуровневой системы. 
С++ не нужен как язык второго уровня. 
  

  

 off topic а Delphi?

  Delphi использует как платформу Win32 и его возможности это возможности Windows, например некоторые объекты даже не хранят свое состояние, они каждый раз вызывают API функции для определения своего состояния. Проблем, конечно больше из-за разных версий windows, но в целом это больше похоже на язык 2го уровня нежели С++, поскольку многие функции ОС отражены в классах VCL и являются нативными. Т.е. можно очень много написать не выходя за рамки VCL или используя VCL основанные компоненты. VCL имеет некоторые возможности адаптации к разным ОС, например некоторые системные библиотеки загружаются при помощи LoadLibrary, предварительно проверяется присутствуют ли они или нет, если да, то дополнительные опции включаются. Все это происходит без ведома пользователя. Во многих вещах VCL стр###т программиста, адаптируясь самостоятельно (без его ведома). Модульность это языковой механизм, многопоточность и синхронизация это встроенные классы, аналогично файлы и графический вывод. Многие вещи просто гарантируются платформой Win32. У тебя эти возможности всегда есть ввиду непереносимости кода по определению. Это простое решение  .

это совсем не похоже на язык 2-го уровня, если под словосочетанием "язык 2го уровня" имеется ввиду java или .NET, мало того, что тут дело далеко не в одном языке, да к тому-же, C++ обеспечивает более высокий уровень абстракции от ОС, в случае использования соответствующих библиотек, я уже молчу про все остальное  


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

еще раз хочу напомнить, что delphi тут - огромный offtopic, я вообще думал, что будет холивар на тему ФП vs традиционные языки, но Alexis все опошлил свей любовью к проприетарным, умирающим технологиям 10-летней давности 

Добавлено через 31 секунду

и хватит ругаться матом!

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

Да, да! Покормите, мну!  

Ого, вы тут настрочили! Пойду читать.

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

Lazin, а что ты хочешь на нем писать, сайты визитки и окна какие-то...?   

Это сообщение отредактировал(а) gcc - 27.8.2009, 20:20

  Так если бы его не было, то было бы что-то другое по лучше   . Я тож 95% всего пишу на С++, но была бы замена перешел бы не задумываясь. 

я то-же на нем пишу, все меньше и меньше...  
на ком?
я сам еще только учусь  
но пнуть всегда рад  
вот, к примеру, презентация создателя F#, там кратко изложено то, почему я хочу использовать F# в работе
я пока толькко изучаю возможности языка, но уже крышу сносит, вот пример async workflow:


получение данных будет выполняться асинхронно, все синхронные операции будут выполняться в пуле потоков, на С# это далеко не так просто реализовать  

Это сообщение отредактировал(а) Lazin - 27.8.2009, 21:24

С++ - единственный известный мне язык который поддерживает системное программирование, и при этом поддерживает множество удобных парадигм программирования - ООП, обобщенное программирование

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

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

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

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

К тому же неужели какой-нибудь F# так же богат возможностями что и C++ ?
Может там есть десяток удобных вещей, но всеравно нет и малой доли того что есть в С++?
Да, чтобы сделать boost::lambda понадобились тысячи строк кода, и можно сказать что "в более высокоуровневом языке X это встроено", но если бы в этом более высокоуровневом языке это не было встроено, разве это можно было бы там сделать?


Это сообщение отредактировал(а) GoldFinch - 28.8.2009, 00:26

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

еще как, это более выразительный язык  
неа
если говорить о F#, то там к примеру нет шаблонов, потому-что там они нафик не нужны, потому-что есть type inference, код автоматически обобщается на произвольные типы, иногда правда прихоится явно указывать некоторые типы, что-бы ограничить типы возможных аргументов
если написать что-то вроде

то это будет эквивалентно плюсовому std::make_pair, целиком и полностью, код будет работать с любыми типами. Писать обобщенный код на порядок проще, это нормальная практика, а не Zen, доступный лишь немногим, как template metaprogramming в С++.
другой пример - в ocaml и F# есть оператор |> левый операнд которого передается на вход правого, используется для организации конвейерной обработки данных
так вот, реализуется он крайне просто - 

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

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

Добавлено через 6 минут и 55 секунд

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

вот еще один пример, например нам надо написать ф-ю, которая ищет в списке N самых маленьких чисел, для этого нужно отсортировать список по возрастанию и взять N первых элементов, но этот алгоритм не оптимален, так как сортируется весь массив, а нужно остановить сортировку тогда, когда будут известны первые N элементов
в STL ест алгоритм partial_sort, который частично сортирует данные, реализован как отдельная ф-я, с ним можно это реализовать оптимальным образом
ну а вот решение на Haskell:
делающее ровным счетом то-же самое, но никаких специальных ф-й тут не применяется, sort будет сортировать список не полностью, а ровно на столько, насколько нужно, благодаря ленивости языка  
как сделать такое на последовательностях F# я не нашел, поэтому пример на haskell

Lazin, но фактически, если на С++ чего-то нет, скорей всего это можно в нем реализовать, завернув это в библиотеку, так чтобы пользователю было удобно
у меня все равно подозрение, что в F# или haskell или еще где чего-то не окажется, и там нельзя будет это реализовать так же просто.

вот например, есть сервер с хитрым бинарным протоколом, надо написать к нему клиентский код, и чтоб работал и в винде и в никсах.
на С++ я беру boost.asio для приема\отправки пакетов, 
добавляю код который шифрует пакеты и считает их контрольные суммы,
беру библиотеку сериализации чтоб извлекать\записывать данные в пакеты,
библиотеку RPC чтоб при приходе пакета вызывался callback, а отправка выглядела как вызов метода сервера

как такое же выглядит на F#?

Добавлено через 3 минуты и 44 секунды
Lazin, но фактически, если на С++ чего-то нет, скорей всего это можно в нем реализовать, завернув это в библиотеку, так чтобы пользователю было удобно
у меня все равно подозрение, что в F# или haskell или еще где чего-то не окажется, и там нельзя будет это реализовать так же просто.

вот например, есть сервер с хитрым бинарным протоколом, надо написать к нему клиентский код, и чтоб работал и в винде и в никсах.
на С++ я беру boost.asio для приема\отправки пакетов, 
добавляю код который шифрует пакеты и считает их контрольные суммы,
беру библиотеку сериализации чтоб извлекать\записывать данные в пакеты,
библиотеку RPC чтоб при приходе пакета вызывался callback, а отправка выглядела как вызов метода сервера

как такое же выглядит на F#?

Добавлено через 3 минуты и 57 секунд
Lazin, но фактически, если на С++ чего-то нет, скорей всего это можно в нем реализовать, завернув это в библиотеку, так чтобы пользователю было удобно
у меня все равно подозрение, что в F# или haskell или еще где чего-то не окажется, и там нельзя будет это реализовать так же просто.

вот например, есть сервер с хитрым бинарным протоколом, надо написать к нему клиентский код, и чтоб работал и в винде и в никсах.
на С++ я беру boost.asio для приема\отправки пакетов, 
добавляю код который шифрует пакеты и считает их контрольные суммы,
беру библиотеку сериализации чтоб извлекать\записывать данные в пакеты,
библиотеку RPC чтоб при приходе пакета вызывался callback, а отправка выглядела как вызов метода сервера

как такое же выглядит на F#?

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

Добавлено через 13 минут и 59 секунд

Последовательности F# - это обычные объекты, реализующие IEnumerable. ТАк что проблема не в F#, а в стандартных либах .Net FX. В текущей реализации LINQ-а OrderedEnumerable делает сортировку при запросе первого элемента, но сортировку всех элементов. Т. е. true-way - сделать LazyOrderedEnumerable 

в области системного ПО есть еще D

Это сообщение отредактировал(а) GoldFinch - 4.9.2009, 18:09

Представьте, что Java/C# бы работали нативно, а не через JIT-компиляцию.
Много бы осталось народа на C++?

Сам юзаю его, но лишь потому, что нечем заменить.

LISP

chipset, не катит, прадигма другая ;)

Да, кстати - наткнулся на интересную статью (в виде нескольких экстешен методов для удобного использования AsyncBuilder-а в C#):
http://weblogs.asp.net/podwysocki/archive/...tions-in-c.aspx

C++ не нужен

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

Это так, моё мнение..

PS Перевелись на винграде сиплюсплюсники...  Даже Lazin уже против С++...

Прям бальзам на душу.  

Сегодня с утра увидел топик, в котором когда-то отписался. Популярный получился пост, -3.  Прочитал... Голосом Виктора Гусева во время матча Россия - Испания(?): "Такие языки нам не нужны."

[sarcasm]С не нужен, есть же ассемблер.[/sarcasm]
Приведи пример полиморфизма на C. Да так, чтобы IDE нормально с  ним работала, к примеру правильно автодополняла и подчеркивала неверное: чтобы человек не терял зря время.

Из всех аргументов в пользу C++ привести поддержку IDE — это сильно 

nerezus, ээ.. а причём тут полиморфизм. Объявляем указатель на функцию, запихиваем его в структуру - вот тебе VTABLE. Помню давно немного ковырялся (безуспешно в итоге, но не в этом дело) с сорсами xine, там целенаправленно не используют С++ (портабельность в первую очередь). Вместо этого есть небольшой гайд по поводу реализации "классических" концепций ООП на С.

Только я не понял - а что от ИДЕ то требуется?! Да и вообще ИДЕ - это всё-таки больше ява, ну и шарп. Ну за последнии годы клиентский веб-девелопмент тоже обзавёлся качественной поддержкой со сторон ИДЕ. Есть ещё, конечно питон, пхп и руби, но.. Эти ИДЕ (в первую очередь речь про PyDev, RadRails и PDT, что-то там есть в NetBeans и IDEA вроде, но.. я не видел даже) не такие уж и развитые..

Добавлено через 1 минуту и 43 секунды

Во-во 

я бы так не сказал, для некоторых задач он по прежнему нужен, но я постепенно ухожу от подобных задач(и не только я), в голову приходит такая аналогия: раньше все усилители были ламповыми, с одной стороны это круто, у электронных ламп очень высокое входное сопротивление, нет обратного тока, параметры не зависят от температуры, а самое главное, с ними очень легко работать. 
Но есть и недостатки, которые перевешивают их достоинства. Постепенно, в аналоговой звуковой аппаратуре воцарились усилители, построенные на полупроводниковых элементах, которые служили дольше, потребляли меньше электроэнергии и были значительно дешевле, а значит - доступнее. Благодаря этому, полупроводниковые приборы появились в каждом доме. Но они стали сложнее в разработке.
Вот это, сильно напоминает переход индустрии от Си к С++, задачи становятся сложнее, что-бы их решать эффективно, нужны более гибкие и выразительные языки программирования. Если вернуться к нашей аналогии - можно представить себе систему управления баллистической ракетой, построенной на лампах накаливания, но ни одна баллистическая ракета ее не поднимет, либо, эта система будет очень простой.  
Позднее, появилась цифровая аппаратура, с одной стороны, разрабатывать ее стало проще, не нужно рассчитывать параметры усилительных каскадов, фильтров.. достаточно рассчитать коэффициенты разностных уравнений для DSP процессора и получить нужный переходный процесс. Мало того, с помощью нескольких микросхем, можно моделировать достаточно сложную аналоговую технику. Но с другой стороны, сигнал на выходе DAC, отличается от оригинального. Зато, с помощью цифры возможно то, что раньше было просто не реально.
Это, как управляемый(JVM, CLR) и неуправляемый код. С одной стороны, программы на С#/Java, работают немного медленнее, но с другой, имеют свои преимущества. Это не отменяет того, что иногда нужно использовать и неуправляемый код. Так-же, как существование цифровых технологий, не делает ненужными аналоговые усилители. 

Добавлено через 4 минуты и 34 секунды
перечитал свой пост, вот это меня штырит  

 А какой смысл в ЗАМЕНЯЕМОМ ЯП, когда нет для него нормальных IDE?

Добавлено через 1 минуту и 18 секунд
 И? Переводить ошибки в рантайм и иметь *лишний* гемор?)

Не слушайте Lazin'а, он просто устраняет конкурентов.  

Ок. Ты мне скажи, а что С++ даёт в этом плане по сравнению с сями? Чего-т я не понимаю 

как раз в ракетах - лампы, полупроводники менее надежны (не выдерживают радиации, и других воздействий)

и из-за этого нужен С++? ;)
проще в GNU C это добавить...



сколько раз уже приводил






Lazin, 
я не спорю
системное программирование - С
прикладное - более удобные инструменты
С++ идет лесом ибо он не нужен ни там, ни там 
;)

имхо, рулят связки типа python + C: выразительность первого и эффективность второго
логика на python => меньшее количество ошибок, оптимизация на С => повышение эффективности

я сторонник принципа "каждый инструмент должен делать то, для чего он был создан"
любое обобщение практически всегда усредняет конкретные возможности
в С++ много чего есть, но как-то всю через ж... 
;)

 Пройдет десяток лет с момента принятия в стандарт до распространения сабжа.

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

Ужоснах... 
А как будет выглядеть какой-нибудь элементарный паттерн (Abstract)Factory на С? Ну или его аналог в соответствии с парадигмой. 



И полиморфизм в С тоже через ж... ;) 

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

Ох не надо... Один раз уже расширили.

  

У вас теперь панический страх перед расширениями языка?  
По-моему, если расширять разумно - то будет всё нормально! 

Это сообщение отредактировал(а) Любитель - 18.10.2009, 11:49

ссылка на злобу дня: http://eli.thegreenplace.net/2009/10/17/th...season-is-back/

Там употреблялось слово IMHO  значит вся статья зло.

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

P.S. Есть ли форум посвященный идеологии языков?