| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Религиозные войны > С++ не нужен |
| Автор: Lazin 25.8.2009, 15:42 |
| Открыл для себя OCaml(в лице F#) и в некоторой степени Haskell, а так-же реализовал пару проектов на С# и понял что сабж, в большинстве случаев мне больше не нужен, только для чего-то не сильно сложного, но при этом очень требовательного к производительности, все остальное проще и быстрее реализовать на одном из более гуманных языков программирования |
| Автор: kemiisto 25.8.2009, 16:09 |
НЕТ!!!   Я для ++ только один вариант исользования оставил - кросс-платформенный GUI. Тут Qt меня устраивает как ничто другое. |
| Автор: Snowy 25.8.2009, 16:42 |
| Какой бы вариант выбрать? "Да, не нужен", или "Нет, не нужен"?  Добавлено через 1 минуту и 55 секунд А вообще любая вещь кому-то либо нужна, либо нет. А кому-то нужна, но не сейчас - пусть лежит... Каждому своё... |
| Автор: Shaggie 25.8.2009, 17:36 | ||
А у мну как раз такая задача, ничего лучше плюсов придумать не могу (хотя про OCaml и Haskell, несомненно, труЪ). |
| Автор: Lazin 25.8.2009, 20:11 | ||||||||
ДА!!!
Qt это еще одно доказательство того, что "плюсы", это тупиковая ветвь, ведь это на самом деле не совсем С++. Мне очень нравится программировать на Си и на С++, это дает ощущение полного контроля над тем, как будет работать программа, позволяет контролировать семантику, то, где и как будут создаваться объекты и тд. Но просто в последнее время, я обратил внимание на то, что приличную часть времени я трачу на реализацию того, что в других языках программирования работает "из коробки". Например вывод типов, или пытаюсь реализовать ленивый ввод/вывод через задницуитераторы и тд.
http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html Вообще, будущее языка сомнительно. К примеру, меня(и не только меня) уже давно не удивляют многостраничные сообщения об ошибках, суть которых можно изложить в 3х словах - неправильный аргумент шаблона. Но, недавно из нового стандарта убрали фичу, которая могла-бы от этого избавить(правда для этого нужно переписать все существующие библиотеки) - concepts. К тому-же, новый стандарт еще не принят, принят он будет неизвестно когда, полноценные реализации появятся не скоро, а когда появятся, мой проект будет компилироваться еще дольше! xD |
| Автор: Alexeis 25.8.2009, 20:52 | ||
По этому поводу у CodeMonkey есть хорошая подпись.
Ток вместо паскаля можно туда еще подставить C#, Python, Java и т.д. С++ работает на множестве платформ, устройств, под есть куча SDK и невероятно много кода. Это ком инерции, который держит его на плаву. На самом деле сам язык жутко непривлекательный, но зачастую просто нет выбора. Приходиться писать на нем. |
| Автор: Lazin 25.8.2009, 21:36 | ||||
тут ты не прав, этот язык - лучший выбор для многих задач, но далеко не для всех, ты просто слишком долго писал на паскале, поэтому он для тебя такой непривлекательный проблема С++ - в том, что он достаточно низкоуровневый, поэтому нужно держать в голове множество мелких технических деталей, которые отвлекают от решения поставленной задачи
только паскаль намного хуже, паскаль не назовешь более высокоуровневым языком чем С++ и технических деталей там то-же хватает, при этом он обладает более громоздким и не гибким синтаксисом, там вообще нет средств обобщенного программирования, если не считать макросов(хотя в последней версии и появились, но это скорее дженерики a-la C#, чем что-то похожее на шаблоны С++), можно работать с памятью, есть указатели, но нет арифметики указателей!!!  что делает его более опасным в этом нелегком деле, а код непереносимым на не x86 платформы. Может в паскале многих проблем и нет, но это только потому, что сложные проблемы на нем не решают  |
| Автор: Alexeis 25.8.2009, 21:53 | ||
Это все есть, но оно не нужно, это не стиль делфи. В общем и целом Delphi это тенденция уйти от указателей совсем. Указатели это низкоуровневые средства, которые остались для увеличения возможностей. Ты просто пытался на паскале писать сиподобный код. Это совершенно неудобно. Заметь в делфях есть семантика неявного разыменования и неявные ссылки. Все это должно как бы намекать, не используй указатели совсем. Используй управляемые массивы строки и интерфейсы. Максимально автоматизируй работу с памятью. Согласен TList неудобен, но есть TStringList/TObjectList/TComponentList. Отказывайся от статического связывания, переходи к динамическому связыванию объектов и интерфейсов. Как только ты уйдешь от статики, так сразу поймешь недостатки С++ и удобства Delphi и других языков. Статика негибкая. |
| Автор: bems 25.8.2009, 21:57 |
| Не добалял никто макросы. Добавили именно что дженерики. |
| Автор: Rohoss 25.8.2009, 21:58 |
| Lazin, так а как же linux? Mono, говорят пока сыроват. |
| Автор: Alexeis 25.8.2009, 22:00 |
| На линуксе питон рулит . |
| Автор: Lazin 25.8.2009, 22:35 | ||
я одного не понял, при чем тут delphi?
а delphi для Mac OS X - тем более нет, а OCaml и Haskell - есть |
| Автор: Alexeis 25.8.2009, 22:45 |
| Lazin, ты просто делфифоб, и твои слова тому подтверждение. Rohoss говорил про С++, мол как же на линуксе без плюсов, просто некуда. На самом деле и на линуксе можно прекрасно жить без плюсов. Например любимый всеми пиджин на питоне написан, по большей части да и много другого софта. |
| Автор: Lazin 26.8.2009, 05:35 | ||
ага, особенно libpurple... еще скажи что на delphi...  |
| Автор: bems 26.8.2009, 06:43 | ||
|
| Автор: Lazin 26.8.2009, 09:28 | ||
Никакой не латентный, я кое-что делал на дельфи, по необходимости, по этому знаю, что это не то что мне нужно |
| Автор: mrbrooks 26.8.2009, 09:51 |
Такое ощущение, что С/С++ действительно уходит на задний план. Для чего то маленького и быстрого, либо серьезного и большого. Гуй писать на С++ дело уже не гламурное. К примеру у нас вообще стали обходится веб-интерфейсами - вполне кошерно.  Что касается Дельфи - вообще не понятно его существование, когда есть С#. Особенно улыбает тот факт, что есть плагин под студию где можно разрабатывать код на Delphi под .NET. |
| Автор: Alexeis 26.8.2009, 10:37 | ||
Так это дело рук кодегировцев. Delphi Prism поддерживает все возможности .NET 3.5. Так что возможности есть. Сейчас в проекте x64 и Linux. Так что все со временем будет. Delphi for Win32 уже на уровне .NET 2.0, но при этом дает нативный код. Но, вообще, на сегодняшний день самым разумным является 2х ступенчатый подход, когда пишут для некой платформы не привязанной к железу и есть универсальная адаптация этой платформы под железо. Т.е. тебе не нужно делать глубокие тесты на всех платформах и ловить все особенности. У тебя есть гарантированный набор возможностей на который ты можешь рассчитывать вне зависимости от железа. С++ не соответствует этой концепции. Поэтому его доля будет снижаться. |
| Автор: mrbrooks 26.8.2009, 10:55 | ||||||
есть подозрения - что скорее Дельфи вольется в студию, чем Embarcadero наконец то сделает поддержку x64.
Это про Mono?
почему не соответствует? них фирштейн. |
| Автор: Alexeis 26.8.2009, 12:03 | ||||||
В перспективе нативная поддержка.
Потому что С++ сам по себе в рамках стандарта не дает достаточно возможностей для нормального программирования. Нативно у него поддержка текстовый режим и стандартный ввод/вывод. Остальное зависит от чужих библиотек, которые платформо-зависимы в той или иной степени. Как только ты ушел стандартной библиотеки у тебя сразу же начинаются танцы с бубном. Дальше уже финты с версиями платформами. Короче для С++ нет понятия родной платформы. Зачастую даже не все функции стандартной библиотеки реализуются. |
| Автор: headzero 26.8.2009, 12:08 |
| Я конечно не эксперт в языках, но считаю что мнение о С++ неверно. Как известно все известные фреймворки такеи как Ява , дотнет.... предоставляют программисту удобство и избавляют его от рутинной и опасной работы c памятью. И это очень хорошо. Но ведь большинство функций этих каркасов реализовано на с++. И для машины полюбом нужен такой язык который может работаь напрямую с памятью. Я думаю С++ нужен как академическая и научная платформа для всех программистов. Я думаю корррекней было бы сказать не "C++ не нужен", a "Мне в моем проекте для реализации конкретной задачи я могу обойтись без C++". Говорить что С++ не нужен - то же самое что говорить: "Блин, нафиг я 5 лет в универе штаны протирал, вот лучше бы купил самоучитель :Выучи С# за 24 дня - 10 минут на урок, и уже бы давно в визарде формы ваял". |
| Автор: Alexeis 26.8.2009, 12:45 | ||
Нужен. Один раз написать явамашину и ее поддерживать, а в 1000 раз больше программистов будут просто использовать то что один раз оптимально и эффективно написано. Ява-машина это узкий перешеек между железом и многообразием ява-приложений. Он действительно является узким также в смысле производительности, что должен быть вылизан до предела, но только лишь он. Ведь не скажешь даже, что каждый 10й или каждый 100й программист пишет явамашины или аналогичные вещи. Речь идет о вытеснении С++ как высокоуровневого языка. Т.е. долой с массового рынка. Да с байтиками и битиками удобно играться, удобно залезть в абсолютный адрес. А теперь подумай, если в С++ нативные средства управления или создания потоков? Синхронизация? Межпроцессорная синхронизация или обмен. Средства для многомодульного программирования или распределенного? Чаще всего это решается для текущей платформы непереносимыми возможностями, после чего наступает длительный этап проверки на всевозможных машинах и появления многих сюрпризов. Такие решения нельзя назвать удачными. Delphi по крайней мере декларирует работу под Windows разных версий и набор родных, стандартных классов для работы с ней. Любой программист Delphi посмотрит код и поймет чего в нем происходит, потому что используются стандартные классы. Безусловно в этом вопросе C# далеко переплюнул Delphi for Win32, но его тоже нужно хорошо изучать и понимать какие языковые средства являются быстрыми, какие удобными но медленными, где можно ожидать нагрузку на сборщик мусора или менеджер памяти. Кроме того алгоритмы они не зависят от языка, архитектуры данных, схемы взаимодействий объектов, архитектура приложения. Чтобы грамотно владеть C# понадобиться не одна неделя, и даже не один год наверное. |
| Автор: Lazin 26.8.2009, 13:08 | ||||
interporcess - не просто стандартизировать, взять к примеру те-же средства delphi win32 и его классы для межмодульного взаимодействия, можно-ли их реализовать на posix api? в бусте есть библиотека interprocess, кроссплатформенная, она работает одинаково на разных платформах, но к примеру под windows, shared memory эмулируется с помощью отображаемых в память файлов, так как семантика shared memory POSIX не реализуется иными средствами в win32 что такое "средства для многомодульного программирования" я не знаю, возможно продукт больной фантазии дельфистов, а возможно ты имеешь ввиду interoperability, если так, то тут рулят всевозможные ВМ. Добавлено через 58 секунд also, delphi sucks and Добавлено через 11 минут и 10 секунд
COBOL, это то-же классика, между прочим до 80% используемого сейчас кода написано на нем - http://www.codinghorror.com/blog/archives/001294.html но будущего у него нет |
| Автор: Alexeis 26.8.2009, 14:01 | ||||||||
Во первых новый стандарт еще не принят и не реализован.
Это все сторонние, которое не будет гарантировано работать везде где работает С++ с любым компилятором.
boost это не стандарт, его и подключить можно далеко не ко всем компиляторам.
Линковка в рантайме. Вот например у меня есть платформа BlackFin и компилятор С++. нативными средствами С++ я не могу 1) Сделать таймер. 2) Вывести строку в cout 3) Вызвать assert() 4) Вывести что либо на экран 5) Вывести запустить второй поток 6) Синхронизировать 2 потока. 7) Синхронизировать поток и прерывание 8) Не могу сделать модуль так чтобы две программы использовали один и тот же кусок кода (например zlib) 9) Не могу создать/удалить/вывести в файл. 10) Эффективно работать с юникодом. Теперь возьмем ява-программу для телефона. Разница очевидна. Имеется ява платформа, которая гарантирует мне определенный набор возможностей вне зависимости от типа процессора. Создатель телефона трудиться для того чтобы реализовать, то затребовала ява платформа, иначе телефон никто не купит. Создатель компилятора С++ имеет минимум забот, зато теперь каждый программист С++ имеет кучу гемороя по изобретению велосипеда и каждый новый программист будет делать свой велосипед. Массовый программист должен иметь перед собой уже не полуфабрикат, готовую шоколадку, где некий стандарт гарантирует перечень ресурсов, ну или можно запросить у машины стандартным образом, умеешь ли ты делать такое? Или разрешено ли тебе такое. В концепции двухуровневой платформы С++ может занимать только первый "узкий" уровень, но никак не 2й "широкий". Тут даже говорить нечего, удивляюсь о чем тут спорить? С++ годиться только для одноуровневой схемы, которая устаревает постепенно. |
| Автор: Lazin 26.8.2009, 14:42 | ||||||
11) Открывать пиво 12) Заказывать пиццу напиши свои велосипеды - с преферансом и блудницами а вообще, компилятор с++ и стандартные библиотеки, это не платформа, все это должно расширяться сторонними библиотеками, в этом вся прелесть данного подхода, никто не заставляет использовать boost, или zlib
тут я бы то-же поспорил, для .NET есть P/Invoke, для Java - JNI, и С++ вполне годен для реализации каких-либо требовательных к ресурсам частей системы
|
| Автор: Alexeis 26.8.2009, 15:11 | ||
Епт! Собственно вот на это я и хотел указать. C#, Java, Python, Perl, PHP это все платформа, языки предназначенные для 2го уровня двухуровневой системы. С++ не нужен как язык второго уровня. |
| Автор: Rohoss 26.8.2009, 19:06 | ||
 off topic а Delphi? |
| Автор: Alexeis 26.8.2009, 20:35 | ||
Delphi использует как платформу Win32 и его возможности это возможности Windows, например некоторые объекты даже не хранят свое состояние, они каждый раз вызывают API функции для определения своего состояния. Проблем, конечно больше из-за разных версий windows, но в целом это больше похоже на язык 2го уровня нежели С++, поскольку многие функции ОС отражены в классах VCL и являются нативными. Т.е. можно очень много написать не выходя за рамки VCL или используя VCL основанные компоненты. VCL имеет некоторые возможности адаптации к разным ОС, например некоторые системные библиотеки загружаются при помощи LoadLibrary, предварительно проверяется присутствуют ли они или нет, если да, то дополнительные опции включаются. Все это происходит без ведома пользователя. Во многих вещах VCL стр###т программиста, адаптируясь самостоятельно (без его ведома). Модульность это языковой механизм, многопоточность и синхронизация это встроенные классы, аналогично файлы и графический вывод. Многие вещи просто гарантируются платформой Win32. У тебя эти возможности всегда есть ввиду непереносимости кода по определению. Это простое решение . |
| Автор: Lazin 27.8.2009, 05:47 | ||||||
ну если модульность для тебя это только языковой механизм, то я молчу... еще раз хочу напомнить, что delphi тут - огромный offtopic, я вообще думал, что будет холивар на тему ФП vs традиционные языки, но Alexis все опошлил свей любовью к проприетарным, умирающим технологиям 10-летней давности Добавлено через 31 секунду
и хватит ругаться матом! |
| Автор: Void 27.8.2009, 18:03 | ||
Одного упоминания названий языков недостаточно, чтобы развязать такой холивар. Приведи конкретный пример, как удалось реализовать преимущества ФП на конкретной задаче, адресно пни императивщиков, и получи толпу, доказывающую, что это их задачи это не решает, и вовсе это не преимущества на самом деле, и вообще что за китайская грамота. И скажи спасибо, что ещё не набежали хардкорщики, у которых не плюсы плохи, а программисты недостаточно хороши для плюсов. |
| Автор: kemiisto 27.8.2009, 18:20 | ||
Да, да! Покормите, мну! Ого, вы тут настрочили! Пойду читать. |
| Автор: Nastya 27.8.2009, 19:14 |
| Нууу, как человек, зарабатывающий на жизнь, тем что пишет на С++. думаю нужен |
| Автор: gcc 27.8.2009, 20:14 |
| Lazin, а что ты хочешь на нем писать, сайты визитки и окна какие-то...? |
| Автор: Alexeis 27.8.2009, 20:23 | ||
Так если бы его не было, то было бы что-то другое по лучше  . Я тож 95% всего пишу на С++, но была бы замена перешел бы не задумываясь. |
| Автор: Lazin 27.8.2009, 21:23 | ||||||||
 но пнуть всегда рад вот, к примеру, http://cufp.galois.com/2008/slides/SymeDon.pdfсоздателя F#, там кратко изложено то, почему я хочу использовать F# в работе я пока толькко изучаю возможности языка, но уже крышу сносит, вот пример async workflow:
получение данных будет выполняться асинхронно, все синхронные операции будут выполняться в пуле потоков, на С# это далеко не так просто реализовать |
| Автор: GoldFinch 27.8.2009, 21:56 |
| С++ - единственный известный мне язык который поддерживает системное программирование, и при этом поддерживает множество удобных парадигм программирования - ООП, обобщенное программирование Действительно, в других языках есть встроенные вещи которые в С++ делаются написанием сотни строк кода или невозможны вообще. Но этих высокоуровневых языках нет такой поддержки низкоуровневого программирования, которая есть в С++ Кроме того, они генерируют низкопроизводительный код. |
| Автор: Lazin 27.8.2009, 22:36 |
| GoldFinch, объясни, зачем нужна эта низкоуровневость и скорость выполнения кода большинству приложений, ты так говоришь, как будто это хорошо К тому-же скорость выполнения кода, это очень спорный момент. Взять к примеру простые синтетические тесты, например http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ghc&lang2=gpp&box=1. Он ни о чем не говорит, я бы предпочел посмотреть на результаты сравнения идиоматичного кода, а не оптимизированного до уровня абсолютной не читаемости, так как большую часть времени мы пишем именно такой код, и используем библиотеки, которые состоят в основном их такого кода ну а про поддержку я вообще молчу. |
| Автор: GoldFinch 28.8.2009, 00:22 |
| Lazin, большинству приложений - не надо. мне - надо. при этом я знаю, что обобщенный код, который я пишу, используя хитрые библиотеки типа boost, скомпилируется в такой же код, как если бы я писал его на С. К тому же неужели какой-нибудь F# так же богат возможностями что и C++ ? Может там есть десяток удобных вещей, но всеравно нет и малой доли того что есть в С++? Да, чтобы сделать boost::lambda понадобились тысячи строк кода, и можно сказать что "в более высокоуровневом языке X это встроено", но если бы в этом более высокоуровневом языке это не было встроено, разве это можно было бы там сделать? |
| Автор: Alexeis 28.8.2009, 00:32 |
| GoldFinch, ну смотри, идет разработка длительного корпоративного проекта, программист написал и через пару лет ушел, дальше нужно его развивать. Приходит новый программист и он должен изучать не только код написанный его предшественником, но и все библиотеки который тот использовал. В случае если библиотеки стандартные, то потребуется только изучение кода, который писал программист. При работе в команде, очень важно использовать стандартные решения, так чтобы твой код был максимально прозрачным и очевидным, поэтому использование решений "из коробки" предпочтительнее во многих случаях. Только одиночка может себе позволить писать все под себя. |
| Автор: Lazin 28.8.2009, 08:07 | ||||||||||||||
еще как, это более выразительный язык
если говорить о F#, то там к примеру нет шаблонов, потому-что там они нафик не нужны, потому-что есть type inference, код автоматически обобщается на произвольные типы, иногда правда прихоится явно указывать некоторые типы, что-бы ограничить типы возможных аргументов если написать что-то вроде
то это будет эквивалентно плюсовому std::make_pair, целиком и полностью, код будет работать с любыми типами. Писать обобщенный код на порядок проще, это нормальная практика, а не Zen, доступный лишь немногим, как template metaprogramming в С++. другой пример - в ocaml и F# есть оператор |> левый операнд которого передается на вход правого, используется для организации конвейерной обработки данных
и большинство средств языка, не реализованы на уровне языка, а строятся из более простых языковых конструкций
Код на С++, интенсивно использующий template metaprogramming - писать очень сложно, как результат - падение производительности труда. На самом деле, оправданных применений у этой техники не так много. Например проверка размерностей на этапе компиляции, или создание всевозможных EDSL, в случае, если эти EDSL будут использоваться многими программистами, для написания большого количества кода, иначе игра не стоит свеч и это просто усложнение кода. Неопытные программисты, часто заблуждаются, считая, что чем более сложный код они напишут, тем "круче". С++ очень подходящий язык, для того, что-бы писать очень сложный код, который на самом деле делает что-то очень простое. На самом деле, задача программиста - сделать наоборот, что-бы код делал что-то сложное, но выглядел и работал при этом очень просто. Добавлено через 6 минут и 55 секунд
ты не прав, boost - это стандарт де-факто, так как разработчики многих библиотек - члены комитета стандартизации, и многие из бустовских библиотек - будут в новом стандарте ты так-же путаешь язык и технологии, которые с его помощью используют, к примеру, если я пишу на delphi приложение для работы с БД Oracle, то на мое место будут искать не любого дельфиста, а именно специалиста по Oracle, delphi тут уже вторичен |
| Автор: Lazin 28.8.2009, 08:28 | ||
| вот еще один пример, например нам надо написать ф-ю, которая ищет в списке N самых маленьких чисел, для этого нужно отсортировать список по возрастанию и взять N первых элементов, но этот алгоритм не оптимален, так как сортируется весь массив, а нужно остановить сортировку тогда, когда будут известны первые N элементов в STL ест алгоритм partial_sort, который частично сортирует данные, реализован как отдельная ф-я, с ним можно это реализовать оптимальным образом ну а вот решение на Haskell:
как сделать такое на последовательностях F# я не нашел, поэтому пример на haskell |
| Автор: GoldFinch 28.8.2009, 13:28 |
| 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#? |
| Автор: Любитель 28.8.2009, 15:46 | ||
| Как язык для прикладного ПО - конечно, нафиг, не нужен. Но в области системного ПО (правда, большинство используют его как "продвинутый С", а не как С++ - но эт другой вопрос) конкуретнов нет. Добавлено через 13 минут и 59 секунд
Последовательности F# - это обычные объекты, реализующие IEnumerable. ТАк что проблема не в F#, а в стандартных либах .Net FX. В текущей реализации LINQ-а OrderedEnumerable делает сортировку при запросе первого элемента, но сортировку всех элементов. Т. е. true-way - сделать LazyOrderedEnumerable |
| Автор: GoldFinch 4.9.2009, 18:07 |
| в области системного ПО есть еще D |
| Автор: nerezus 5.9.2009, 12:20 |
| Представьте, что Java/C# бы работали нативно, а не через JIT-компиляцию. Много бы осталось народа на C++? Сам юзаю его, но лишь потому, что нечем заменить. |
| Автор: chipset 11.9.2009, 11:27 |
| LISP |
| Автор: nerezus 11.9.2009, 13:13 |
| chipset, не катит, прадигма другая ;) |
| Автор: Любитель 11.10.2009, 12:05 | ||
Да, кстати - наткнулся на интересную статью (в виде нескольких экстешен методов для удобного использования AsyncBuilder-а в C#): http://weblogs.asp.net/podwysocki/archive/2008/10/15/functional-c-implementing-async-computations-in-c.aspx |
| Автор: MAKCim 11.10.2009, 14:50 |
| C++ не нужен |
| Автор: Любитель 11.10.2009, 15:20 |
| Ну почему.. Неймспейсы - зачастую удобны. Перегрузка методов - удобно. Без сомнения. Конечно, с классическими классами в сишный мир напрашиваться неудобно.. Но иногда и это удобно. Хотя паблик-АПИ в сишном мире на классах строить не стоит... Это так, моё мнение.. PS Перевелись на винграде сиплюсплюсники... Даже Lazin уже против С++... |
| Автор: kemiisto 11.10.2009, 15:27 | ||
Прям бальзам на душу. Сегодня с утра увидел http://forum.vingrad.ru/forum/topic-263651/unread-1/30.html#st_0_view_0, в котором когда-то отписался. Популярный получился пост, -3. Прочитал... Голосом Виктора Гусева во время матча Россия - Испания(?): "Такие языки нам не нужны." |
| Автор: nerezus 11.10.2009, 17:23 | ||
[sarcasm]С не нужен, есть же ассемблер.[/sarcasm] Приведи пример полиморфизма на C. Да так, чтобы IDE нормально с ним работала, к примеру правильно автодополняла и подчеркивала неверное: чтобы человек не терял зря время. |
| Автор: Void 11.10.2009, 17:54 |
| Из всех аргументов в пользу C++ привести поддержку IDE — это сильно |
| Автор: Любитель 11.10.2009, 17:55 | ||
| nerezus, ээ.. а причём тут полиморфизм. Объявляем указатель на функцию, запихиваем его в структуру - вот тебе VTABLE. Помню давно немного ковырялся (безуспешно в итоге, но не в этом дело) с сорсами xine, там целенаправленно не используют С++ (портабельность в первую очередь). Вместо этого есть небольшой гайд по поводу реализации "классических" концепций ООП на С. Только я не понял - а что от ИДЕ то требуется?! Да и вообще ИДЕ - это всё-таки больше ява, ну и шарп. Ну за последнии годы клиентский веб-девелопмент тоже обзавёлся качественной поддержкой со сторон ИДЕ. Есть ещё, конечно питон, пхп и руби, но.. Эти ИДЕ (в первую очередь речь про PyDev, RadRails и PDT, что-то там есть в NetBeans и IDEA вроде, но.. я не видел даже) не такие уж и развитые.. Добавлено через 1 минуту и 43 секунды
Во-во |
| Автор: Lazin 11.10.2009, 18:14 | ||
я бы так не сказал, для некоторых задач он по прежнему нужен, но я постепенно ухожу от подобных задач(и не только я), в голову приходит такая аналогия: раньше все усилители были ламповыми, с одной стороны это круто, у электронных ламп очень высокое входное сопротивление, нет обратного тока, параметры не зависят от температуры, а самое главное, с ними очень легко работать. Но есть и недостатки, которые перевешивают их достоинства. Постепенно, в аналоговой звуковой аппаратуре воцарились усилители, построенные на полупроводниковых элементах, которые служили дольше, потребляли меньше электроэнергии и были значительно дешевле, а значит - доступнее. Благодаря этому, полупроводниковые приборы появились в каждом доме. Но они стали сложнее в разработке. Вот это, сильно напоминает переход индустрии от Си к С++, задачи становятся сложнее, что-бы их решать эффективно, нужны более гибкие и выразительные языки программирования. Если вернуться к нашей аналогии - можно представить себе систему управления баллистической ракетой, построенной на лампах накаливания, но ни одна баллистическая ракета ее не поднимет, либо, эта система будет очень простой. Позднее, появилась цифровая аппаратура, с одной стороны, разрабатывать ее стало проще, не нужно рассчитывать параметры усилительных каскадов, фильтров.. достаточно рассчитать коэффициенты разностных уравнений для DSP процессора и получить нужный переходный процесс. Мало того, с помощью нескольких микросхем, можно моделировать достаточно сложную аналоговую технику. Но с другой стороны, сигнал на выходе DAC, отличается от оригинального. Зато, с помощью цифры возможно то, что раньше было просто не реально. Это, как управляемый(JVM, CLR) и неуправляемый код. С одной стороны, программы на С#/Java, работают немного медленнее, но с другой, имеют свои преимущества. Это не отменяет того, что иногда нужно использовать и неуправляемый код. Так-же, как существование цифровых технологий, не делает ненужными аналоговые усилители. Добавлено через 4 минуты и 34 секунды перечитал свой пост, вот это меня штырит  |
| Автор: nerezus 11.10.2009, 18:55 | ||||
Добавлено через 1 минуту и 18 секунд
|
| Автор: unicuum 11.10.2009, 19:09 |
| Не слушайте Lazin'а, он просто устраняет конкурентов. |
| Автор: Любитель 11.10.2009, 19:23 | ||
Ок. Ты мне скажи, а что С++ даёт в этом плане по сравнению с сями? Чего-т я не понимаю |
| Автор: GoldFinch 11.10.2009, 21:27 | ||
как раз в ракетах - лампы, полупроводники менее надежны (не выдерживают радиации, и других воздействий) |
| Автор: MAKCim 11.10.2009, 22:14 | ||||||||
и из-за этого нужен С++? ;) проще в GNU C это добавить...
сколько раз уже приводил
 Lazin, я не спорю системное программирование - С прикладное - более удобные инструменты С++ идет лесом ибо он не нужен ни там, ни там ;) имхо, рулят связки типа python + C: выразительность первого и эффективность второго логика на python => меньшее количество ошибок, оптимизация на С => повышение эффективности я сторонник принципа "каждый инструмент должен делать то, для чего он был создан" любое обобщение практически всегда усредняет конкретные возможности в С++ много чего есть, но как-то всю через ж... ;) |
| Автор: nerezus 11.10.2009, 22:27 | ||
|
| Автор: Любитель 11.10.2009, 23:41 | ||
Если б расширили С - я бы был только за (хотя, так уж сложилось, я не работаю ни с одним, ни со вторым). Но в сегодняшней реальности зачастую лучше использовать С++. Ради банальных фишек. Замороченные возможности никому не нужны |
| Автор: W4FhLF 18.10.2009, 07:54 | ||||
Ужоснах... А как будет выглядеть какой-нибудь элементарный паттерн (Abstract)Factory на С? Ну или его аналог в соответствии с парадигмой.
И полиморфизм в С тоже через ж... ;) |
| Автор: MAKCim 18.10.2009, 10:18 |
| W4FhLF не вижу ничего ужасного есть базовые операции и базовый объект, их агрегирующий реализация конкретной функции через приведение типов получает адрес объекта, с которым она работает, и выполняет над ним действия полиморфизм в чистом виде если не нравится как выглядит, это не значит, что сделано через ж... ;) |
| Автор: bems 18.10.2009, 10:38 | ||
Ох не надо... Один раз уже расширили. |
| Автор: kemiisto 18.10.2009, 11:48 | ||
|
| Автор: Любитель 18.10.2009, 11:49 |
| У вас теперь панический страх перед расширениями языка? По-моему, если расширять разумно - то будет всё нормально! |
| Автор: Lazin 18.10.2009, 13:58 |
| ссылка на злобу дня: http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/ |
| Автор: unicuum 18.10.2009, 16:40 | ||
Там употреблялось слово IMHO  значит вся статья зло. |
| Автор: zkv 7.11.2009, 00:14 |
| ага, не нужен, и варианты получше есть, только количество написанных либ, близких к делу, на скаку не обойдешь (да и с идеологией проблемы некоторые назревают)... P.S. Есть ли форум посвященный идеологии языков? |
| Автор: kemiisto 7.11.2009, 00:19 | ||||
Вспомнился одесский анек:
zkv, здесь, обычно, идеология и обсуждается. |
| Автор: kemiisto 21.12.2009, 18:13 |
"Разум победит", как говорит SelenIT. Аж в рифму!  |
| Автор: Alexeis 21.12.2009, 18:24 |
| kemiisto, ну там шкала растянута падение всего навсего с 16% до 11%, что соответствует падению всего на 30% относительно себя. |
| Автор: djamshud 21.12.2009, 18:53 |
| Почему нет варианты ответа "автор опроса не нужен"? Я бы за него проголосовал). |
| Автор: GoldFinch 21.12.2009, 19:14 |
| djamshud, уже не смешно, иди кормись куда-нить еще |
| Автор: Lazin 21.12.2009, 20:00 |
| в этой теме питается автор опроса, вот так вот! |
| Автор: djamshud 21.12.2009, 20:03 |
| GoldFinch, кисо, я тебя обидел? Ну. Иди ко мне. Прости. Пожалуйста. Что ты хочешь? Давай забудем обиды? Добавлено через 4 минуты и 43 секунды Lazin, да, вы знатный толстячек:). |
| Автор: Lazin 21.12.2009, 20:22 | ||
я между прочим стометровку за 12 сек. пробегаю, а не только на форму лясы точу, так что кто из нас толстячок, еще большой вопрос |
| Автор: djamshud 21.12.2009, 20:27 |
| Боюсь представить, что с вами случилось бы, не поддерерживай вы себя в форме :D. |
| Автор: Lazin 21.12.2009, 20:31 |
| жульмере хешельбекельме |
| Автор: S.A.G. 21.12.2009, 20:35 |
| А из-за чего дебаты, разве сложно после С++ выучить шарп или Яву? |
| Автор: S.A.G. 21.12.2009, 20:51 | ||
Я тоже могу тогда сказать, что нужен, т.к. я его сейчас изучаю. |
| Автор: Alexeis 21.12.2009, 21:25 | ||
Вопрос не про сложно, а есть ли смысл? Если рассматривать чисто сам язык без ОС, без всяких библиотек, без учета наследия и количества компиляторов, ни чего приглядного нет. |
| Автор: GoldFinch 21.12.2009, 21:38 |
| Alexeis, именно, но если учесть это все, и сравнить с другими языками - результат обратный |
| Автор: Lazin 21.12.2009, 21:48 |
| GoldFinch, например? я так понимаю, что речь идет не об унаследованном коде, а о библиотеках - фреймверках |
| Автор: Alexeis 21.12.2009, 22:03 |
| GoldFinch, рынок это не что-то стабильное, он живет и развивается. Про C++ мне кажется как и про делфи (не паскаль в целом) можно сказать. Он БЫЛ. Как все живое оно имеет свое начало, расцвет и старость. С++ уже не в расцвете сил. Еще не старик, еще имеет силы, но молодым имеет смысл глубоко изучать новое. Не зацикливаться на нем. |
| Автор: A5uKa 21.12.2009, 23:10 |
| Кстати, интересно знать ваше мнение. Вы расцениваете программиста, который пишет скажем на .NET и вообще не знает С++ ... ну и других языков старой школы. И не хочет их учить. Или программиста, который не учит и не будет учить современные языки вообще, но вот знает С++ ... Может быть лучше не учить детей алфавиту, а сразу давать слова ? |
| Автор: nerezus 21.12.2009, 23:15 | ||
А так это разные малопересекающиеся области. |
| Автор: GoldFinch 22.12.2009, 10:12 |
| кстати, если мне надо писать кроссплатформенный код, с минимумом зависимостей, то что мне выбрать? .NET - реально - только винда, и то, только та винда, на которой есть фреймворк Java - только та винда, где есть JRE |
| Автор: Alexeis 22.12.2009, 10:16 | ||
Если выбрать Mono как подмножество .NET, то должно и под линукс. |
| Автор: nerezus 22.12.2009, 10:23 | ||||
А фреймворк уже лет 7 как по дефолту идет.
Qt и Java - примерно по ~15мб. .NET в винде как правило есть, в линухе через моно - но надо тестировать, ибо совместимость страдает. |
| Автор: Lazin 22.12.2009, 10:48 | ||
вступи в секту пиши на haskell-e, на самом деле минимальная зависимость от ОС, если не использовать FFI |
| Автор: GoldFinch 22.12.2009, 12:56 | ||
ну вот пишу я сервер на С++, из зависимостей - только буст, пишу под виндой, дебажу под виндой, работать будет на фряхе. Добавлено через 1 минуту и 54 секунды haskell не хочу, хочу чтоб более-менее императивно было Добавлено через 5 минут и 47 секунд .NET будет смысл использовать лет через 5-10, когда он действительно будет везде. А сейчас он есть не каждой ВинХП, а Моно вроде бы еще далеко не все поддерживает, скажем в msvs2010 .NET 4.0, неужели в Моно оно есть? а 3.5 есть? |
| Автор: Alexeis 22.12.2009, 13:17 | ||
Не аргумент. С теперешними скоростями инета инсталятор может выкачать или просто описать в требованиях. Задача вполне себе простая. Еще можно сказать, что это не будет совместимо в Win98 . |
