Язык очень простой...советую Недавно наткнулся на F# он специально разработан для научных целей.

Matlab

В основном: C# - для прикладного программирования С++ - для расчетов, ритичных к производительности Lisp/Scheme - для моделирования нейронных сетей

C# ибо http://sexdrugsandappliedscience.blogspot.com/2009/02/c-vs-c.html F# тоже очень хорошо. И матлаб, да.

Прочитал статью, вывод: автор не осилил С++ :-/

Автор знает C++ лучше многих. Но восхищаться этим монстром, который все страшнее от стандарта к стандарту, автор не намерен. Использовать приходится, да. Для performance-sensitive code. Но восторга это не вызывает.

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

Следовательно, следующему коду на C# 1. foreach (double value in values) 2. DoStuff(value); Соответствует следующий код на С++ 1. for_each(values.begin(), values.end(), DoStuff);

Ок, с foreach был не самый лучший пример. Но ведь громоздкий и неприятный синтаксис - отнюдь не единственная проблема этого языка. По другим пунктам есть что сказать?

> Next, I hate includes. There is no good reason for good programming language to have such a non-obvious and non-robust way to incorporate different subsystems or just pieces of code. Really! IDE can do it for me! Хорошо, пусть includes - очень сложная проблема для программиста. Внимание вопрос: без IDE, то есть с помощью коммандной строки, автор также легко соберет свой проект на С#? > And the last thing that's important for me: in most cases (except of writting really performance-sensitive code) you should not care about memory deallocation at all. Execution environment can do it for you. Rather quickly. Сборка мусора в новом стандарте. > But don't forget: there are wrappers for everything. There is XNA, Emgu.CV and CUDA.NET. Забыли дописать "Но не забывыйте: их аналоги на 20% быстрее" ;) > 1. Really fast. > 2. There is Boost. Позволю себе дополнить список автора: 3. Really cross-platform! 4. There is Qt 5. There is ACE

> Хорошо, пусть includes - очень сложная проблема для программиста. Внимание вопрос: без IDE, то есть с помощью коммандной строки, автор также легко соберет свой проект на С#? Ну да. Никаких проблем. Правда не совсем понятно, зачем этим заниматься. Да, #include - это не так уж сложно. Но инструменты должны решать проблемы, а не создавать их. Если, конечно, ваша цель - не программирование само по себе. > Сборка мусора в новом стандарте. Не читал обзоров и описаний грядущего стандарта. Скажите: этим будет действительно удобно пользоваться. Или все-таки будет легкое ощущение протеза вместо руки? > Забыли дописать "Но не забывыйте: их аналоги на 20% быстрее" ;) Если будете сыпать цифрами - давайте пруфлинки. Приведенная вами информация не только неподтвержденная, но еще и неверная. Где вы ее берете? Я тогда тоже кое-что хочу добавить. Очевидно, создатели stl и boost никогда не проводили usability sessions (в отличие от тех же разработчиков .NET framework). Проявляется это вот в чем: для того чтобы решить какую-то задачу с использованием C++ библиотек, обычно требуется от 10 минут и больше (часто намного больше) времени провести в гугле и за чтением документации. В .NET подавляющее большинство задач имеет интуитивное решение. А происходит это потому, что разработчики framework делали инструмент, которым будет удобно пользоваться, а не инструмент, при помощи которого можно сделать ВСЕ. Да, и кто называет операцию добавления элемента в вектор push_back()? Не сумасшедшие?

попробую вставить свои мысли :) имхо основной момент всех этих войн заключается в том, что стоит приходить ко мнению, что каждый инструмент нужен для определенных задач. если же говорить об языке, то большинство аргументов за и против какого-либо языка как правило достаточно надуманы. я как апологет скорее с++ :) могу сразу сказать, что (по порядку) 1) проблема с includes как правило возникает только у новичков. "профи" решают ее достаточно быстро используя как соглашения, так и стандартные средства типа оберток или прагм 2) сборка мусора это скорее для меня шаг в сторону новомодности нежели реальный инструмент. тк boost-овские контейнеры при их использовании покрывают 99.9% потребностей (цифры из практики... для остального 0.1% как правило нужны специализированные хранилища) 3) сложность разработки - да. те писать на с++ по моему мнению может только человек с опытом. иначе получается очень страшный код. те вопрос именно в знании. в отличие от с# в котором люди двигаются по порядку "не знаю", "знаю немного", "знаю все", в с++ как правило получается "знаю немного", "знаю все", "знаю немного", "знаю все" :) многие при этом останавливаются на одном из этапов. эти данные кстати я получил специально опрашивая знакомых сишников, которые работали и с другими языками :) 4) по поводу названий это дело привычки. мне в свое время было очень непривычно и неудобно переходить на функциональные языки, писать на перле, да много чего было, но в целом я думаю, что в названиях как раз языки менее всего отличаются :) однако, как человек, писавший на с# я могу сказать, что gui писать на нем на порядок проще. как пишущий на php могу сказать, что сайты делать лучше именно на нем, а не на том же c# в силу как простоты, так и вопросов поддержки и инфраструктуры. кстати, вопросы поддержки, версионирования и выстраивания той же инфрастрктуры для реальных проектов для с# имхо еще решены далеко не полностью. особенно мучительно больно было в гетерогенных проектах, когда часть кода пишется на одном языке, часть на другом и все должно работать и обновляться вместе. с++ (я тут конечно имею ввиду не сами языки, а все что находится вокруг них для поддержки таких вещей плюс архитектуру на которую языки опираются) в этом случае давал больше простора. как-то так. поэтому статьи в духе "почему язык Н плохой" для меня смотрятся очень странно :) в частности хочется спросить а что же автор писал, тк обычно те, кто писал большие и очень большие проекты обычно ругаются не на языки, а на конкретные проблемы, которые конечно же есть везде.

Эта "новомодность" реализована виртовской командой еще в UCSD-Pascal. Скорее нужно говорить о том, что промышленность доросла до практического использования виртуальных машин.

Ах да, "Really cross-platform!" - это Java. Когда у вас даже не специфицированы размеры типов в языке, о какой кросс-платформенности может идти речь? А ведь это все наследие языка C и обратная совместимость. Чем больше багаж, тем больше проблем в аэропорту.

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

Дорогая Варвара. Тут и так довольно тухло, а так немного веселее. Жаль, что вы не понимаете столь очевидных вещей. Или вы хотите с этим поспорить? )))

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

Не специфицированные размеры типов - это же как раз очень хорошо! Вот есть у вас процессор, у которого минимальный адресуемый размер памяти ("байт") - 32 бита, и как быть? В плюсах sizeof(int) и sizeof(char) будет 1, и все будет работать. В жаве, насколько я помню, размеры типов не специфицированы вообще никак - оно работает на вирмашине и дает столько памяти под тип сколько само захочет.

Речь о том, что писать переносимый код на C++ намного труднее, чем на managed-языках. Забыли вы один sizeof(char) на своей платформе с 8ми-битными символами, и ничего не заметили. А потом через год на новой архитектуре у вас программа упала. Попробуйте-найдите ошибку. Совсем другое дело Java или C#. Там размеры типов явно специфицированы. Вы уверены в коде, который пишете. А при JIT-компиляции на соответствующей платформе можно уже применять необходимые оптимизации.

Ну, sizeof(char) - он по стандрту всегда равен единице, это и есть минимально адресуемый байт. Вот sizeof(int) - да, имеет право меняться. С другой стороны, стандарт вам обещает, что в такие-то типы данных влезают такие-то числа, а сколько именно они в памяти занимают - вас интересует достаточно редко. А через год на новой архитектуре программа сначала просто не скомпилируется - придется сначала вызовы специфичных для архитектуры функций заменить... Кстати, по пунктам оригинальной статьи: * Уродливый код - да, за сколько-то лет человечество придумало более красивый способ написать foreach. С другой стороны, приводимый в качестве примера STL - это отнюдь не образец юзабилити. Вот аналогичная строчка с использованием QT: foreach(double value, values) doStuff(value); И это - C++. Точнее, почти C++ - у кутэ есть свой препроцессор (при компиляции им надо обрабатывать файлы до компилятора), который автогенерит разные дополнительные функции к классам, но и только. * Автор не любит пути к инклюдам и либам. Ну, их никто не любит - но они проставляются один раз в жизни и все дальше само работает. Автор даже не упомянул более интересные вещи, которые могут произойти при рекурсивном вложении инклюдов, но опять же, очень просто сделать так, чтобы этого никогда не произошло. * Память. О дааа... Пусть бросит камень тот кто никогда не допускал утечек памяти. Хотя... Возьмем для примера опять QT: в большинстве случаев ведь кутэшные объекты никто явно не удаляет. Практически всегда любым объектом A владеет какой-нибудь объект B, который уничтожит A когда сам будет уничтожаться. Плюс часть объектов обычно создана на стеке (в частности главный объект QApplication), поэтому они уничтожаются автоматически. Ну и разумеется, в природе существуют сборщики мусора для C++, основанные на указателях разной степени разумности. Кстати, управлять памятью самому иногда реально приходится. Представьте, что вам надо много-много достаточно маленьких объектов одного типа (например, 3 поля типа int или 32-х битного аналога), и их никак нельзя запихнуть в массив. При выделении памяти будет как минимум сохранено значение указателя на выделенную память и размер выделенной памяти - чтобы не выделить ее же повторно. В результате 60000 объектов будут занимать область памяти, в которой могло бы разместиться 80000 (если в своем менеджере памяти не хранить информацию о размере выделенной области) или даже почти 100000 (если можно использовать несколько больших блоков памяти, используя каждый как стек - т.е. не хранить указатели на выделенные участки памяти)

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

Хм. Действительно, "Plain ints have the natural size suggested by the architecture of the execution environment 39) ; the other signed integer types are provided to meet special needs." Ну тогда это значит, что надо заводить свой хедер, в котором платформо-зависимо продефайнить какие-нибудь sint<число>/uint<число> где <число> == 8, 16, 32, 64, сколько-еще-надо. Да, +1 проблема, но не фатально же.

Ну вот эти проблемы мелкие все накапливаются и накапливаются. И становятся одной большой проблемой.

Почему "накапливаются"? На каждую из перечисленных мелких проблем давно придумано решение, которое эту проблему устраняет. Да, если например какой-нибудь код сначала писался чисто под Visual C++/вин32 а потом вдруг его захотелось портировать на какое-нибудь экзотическое железо, то да, все поломается. Приблизительный аналог - переход с Java EE на Java ME, никакая кросс-платформенность не поможет :)

Не, вы видите, что происходит? Я вам говорю: "Я вижу в С++ вот такие вот проблемы". Вы мне: "Ну это же все можно решить, это не проблема". Если бы эти проблемы НЕЛЬЗЯ было решить в С++, им бы вообще никто не пользовался. Я же вижу основную неприятность в том, что эти проблемы вообще нужно решать, когда уже есть НАМНОГО более удобные решения. А вы мне все "почему накапливаются".

Я хотел сказать не "можно решить", а "уже решены". Ну то есть если вы работаете плюсовым программистом, у вас давным-давно есть свой хедер со своими типами, размер которых в битах вы знаете (ну или вы точно знаете какого размера у вас int для той платформы, для которой вы пишете), ваша IDE давным-давно настроена на include/lib пути, во всех ваших хедерах есть ifndef-гварды (вставляемые автоматически средствами IDE при создании хедера или же на автомате набранные руками), и вы пользуетесь удобной библиотекой (например Qt - не сочтите за рекламу, как пример просто хорошо подошло)), не вызывающей у вас ненависти. А еще у вас есть какой-нибудь makefile или его аналог чтобы собрать проект без IDE в любом требуемом виде. Зато в C++ есть разные другие проблемы, которые решить никак нельзя, и вот они-то и должны вызывать в вас желание перейти на яву/дотнет/что там еще. Обычно эти проблемы возникают из-за того, что в плюсах гораздо проще выстрелить себе в ногу, и где-то у вас это таки получилось. Как результат, ваша программа может крашиться каким-то нечеловеческим образом, и вы сколько-то времени пытаетесь понять, почему где-то кто-то влез в чужую память. И вот несмотря на эти нерешаемые проблемы, плюсами пользуются - для скорости, для расширения уже написанного плюсового кода, для того чтобы почувствовать себя всемогущим (можно выполнить свой код до инициализации CRT, бва-ха-ха) или от безысходности (когда есть только плюсовый компилятор для какой-то платформы, например).

Сейчас пишу на С++ проги для курса по системному программированию. Но наткнулся на БлэкБокс с кКомпонентным Паскалем - наследник Оберона. Весьма рекомендую Сайт Информатика-21.

Я программирую в средах Delphi, Visual C++ и FoxPro в ОАО "Когалымнефтегеофизика". Для графики наилучший - Delphi, для "железа" - Visual C++. А на FoxPro - по служебной необходимости.

Занимаюсь изучением методологий ITIL/ITSM, для последующей разработки ИС адаптированной к Российским реалиям. Начинал, как наврное и многие с FoxPro 2.0 (DOS), потом был VFP6, потом перешел на Delphi. Так уж сложилось, что в основном разрабатывал/поддерживал софт на базе реляционных СУБД. Сейчас планирую переключится на WEB 2.0. Смотрел C# - все хорошо, но MS со своей политикой привязывания к рабочей станции откровенно раздражает. смотрел Java - все тоже вроде бы нормально и платформенный и много OpenSource интересных проектов, раздражает некоторая тормознутость. Сейчас изучаю Ruby on Rails пока все нравится. Нужно снижать время на технические тонкости а концентрироваться исключительно на проблеме которую решаешь.

Интересусь Ruby on Rails, но только приступаю к его изучению. Вариант с Rails показался мне более перспективным, чем пробовать вспоминать PHP.

Меня заинтриговала эта новая система Ruby on Rails. Может ли кто-либо посоветовать где взять литературу и инсталяшки? А еще лучше ссылки в Интернете с учебниками и инсталяционными пакетами.

http://ru.wikipedia.org/wiki/Ruby_on_Rails Все абсолютно свободно и доступно для скачивания, литературу лучше читать сразу первоисточник на English. Все что переведено на русский уже устарело, полезно почитать только на начальном этапе обучения.

Премного благодарен. Обязательно загляну.

Приходится использовать Matlab, хотя не равнодушен к SciLab Для прикладной разработки много всего приходилось использовать, но люблю писать на Python.

C# и WPF. Последний очень тяжело дается. Уж не знаю почему. C++ знаю, но у меня несколько другие задачи, поэтому не использую. Интересуюсь SilverLightом, но пока нет на него времени.

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

— кормлюсь знанием этих вещей…
а перспектиными считаю все мелкософтовское (C#, SilverLight...)

Сейчас пишу на PHP, параллельно изучаю С/С++, хотелось бы перейти на С, он больше соответствует моим интересам.

Работал пол года с C#. Удобный, очень простой в освоении. Имеет явные преймущества перед С++. Минус скорости работы приложений компенсируется скоростью разработки, поэтому выходит, что дешевле купить дополнительное железо, чем тратить время.

Java медленно развивается, а ME вообще застыл как будто О_о
Ruby конфетка:)

Попробуйте Python, — мощный и гибкий и есть возможность делать вставки на C. Сам юзаю python и очень доволен =)

Единственный минус питона это, пожалуй то, что необходим интерпретатор.

Для программирования МК использую Assembler. И еще мне очень нравиться Python — очень мощный язык!

Предпочитаю VB6, частенько пишу на C++.
Последнее время понравилось в Flash на Actionscript, хочу написать игрушки для людей с нарушениями моторики, например из-за ДЦП, уже пару шутеров написал, сейчас до ума довожу.
Раньше много на Perl писал.
Ещё пытаюсь освоить Lisp и Prolog.

Довел до ума то?)

Actionscript забросил вместе с шутерами)
Сейчас в основном перешёл на VB.net
Как и раньше частенько на С++ пишу.
Понравилcя PHP.
Lisp стал понимать довольно глубоко, и он оказал влияние
на стиль программирования. Очень рекомендую его изучать!