» Самый перспективный язык программирования

zeroandruxa
А Жаба типа хуже чем C#.NET? Ну это вы загнули, по-моему они вполне даже альтернативы, и пока трудно сказать что лучше...

Цитата:

Я считаю что С# - язык, который в будущем вытеснит С++ так как является обобщением нескольких языков

Скорее не так. Microsoft (в очередной раз) предложила международный стандарт (на этот раз) API. Со своей стороны (и в качестве примера) она реализовала его в виде надстройки над WinAPI под названием .NET Application Framework. Если это дело выгорит, то получится типа "очень классно": можно писать код и не думать, под какую платформу. Просто компилишь, и оно работает. Везде. Подобная стандартизация уже прошла на ура с Plug-n-Play-ем, COM-технология тоже кое-кому понравилась. В общем ИМХО намерения именно такие.
Другое дело, что новый API не функциональный, а объектный - вот это самое то, "чего так долго все ждали". Действительно, сколько можно работать в терминах функций, структур, указателей, когда на дворе уже 21-й век, и все вовсю юзают ООП, в частности, лобают классовые обёртки над этим функциональным API. В лице всяких там MFC, VCL, etc. Так пусть API сразу будет объектный.
Далее. Над C++ всегда довлели два незыблемых закона: совместимость на уровне исходных текстов с plain C и т.н. "нулевая стоимость неиспользования". Если кто не знает, поясню. Это означает, что программист не платит за возможности языка, которые не использует. Например, если он заюзал полиморфизм, он платит за это некоторым снижением производительности за счёт замены прямых вызовов (виртуальных) методов на косвенные и как следствие этого - практической невозможностью их встраивать, которые иначе легко бы встраивались, даже без подсказок inline в прототипах. Кроме того, он платит увеличением размера полиморфных классов и чуть ли не втрое увеличением размера указателей на виртуальные методы. Однако, такие возможности стОят того, и программист, используя их, сознательно идёт на эти жертвы. Если программист использует исключения, то он тоже соглашается с тем, что программа будет работать чуть медленнее (правда, исчезающе мало, по крайнем мере на x86) при обычном исполнении и гораздо сильнее при собственно возникшем исключении, однако сохранение инвариантов, обеспечиваемое деструкторами, каковые гарантировано будут вызваны для всех объектов, которые при этом выходят из области видимости - это стОит того, тем более, что без исключений достижение того же эффекта потребовало бы от программиста значительных усилий, и не факт, что получится эффективнее. Можно продолжать, но суть, думаю, ясна: если я не использую динамический полиморфизм (есть ещё статический), то мои классы никогда не будут увеличены никаким vptr и все методы (кроме как вызываемые через указатели) будут вызываться прямо и при возможности встраиваться; если я не использую в своей программе исключения, то даже этой исчезающе малой потери производительности не будет в принципе. И т.п. Это второе правило, во-первых, позволяет и дальше рассматривать C++ как подходящий для решения задач, для которых традиционно использовались plain C и ассемблер - ведь он остаётся качественно прогнозируемым в плане стоимости тех или иных конструктивных решений, воплощаемых в коде, - во-вторых, препятствует стандартизации (но не внесению в каких-нибудь конкретных реализациях в виде расширения) в язык возможностей, которые невозможно или крайне сложно реализовать в соответствии с принципом нулевой стоимости - например того же сборщика мустора, - в-третьих, заставляет немалое количество пунктов стандарта переводить в разряд "зависящих от реализации" или "неопределённого поведения", т.к. разные платформы могут иметь те или иные особенности - например, если имеется аппаратная поддержка проверки диапазонов и (анти)переполнений при арифметических вычислениях, то реализация такой проверки будет дёшева, в противном случае, такая проверка возможна только программная, и следовательно стандартизировать обязательность такой проверки нельзя.
Микрософт же, с одной стороны имеет чёткое представление, какой она видит .NET, и следовательно способна точно сказать, что такие-то и такие-то возможности C++ не помешали бы, но они никогда в нём не появятся, зато другие его возможности для .NET не нужны или легко заменяются на другие, а в таком виде, как они реализованы в C++ они будут неэффективы для .NET. Вот потому-то она и замутила новый язык, который по её мнению лучше всего отражает потребности .NET.

P.S. Что касается политики Микрософт, это всё моё ИМХО, понятное дело, а отнюдь не официальная точка зрения кого бы то ни было.

Язык программирования D http://digitalmars.com/d/
Кто знаком — что скажите?

Познакомился с D по Вашей ссылке.
Правильная попытка сделать C+++, стряхнув узы совместимости с некоторой замшелостью С, C++.

Жаль, не стали рубить полностью сук.

1)Как была обратная польская запись, так и оставили в D.
2)Отказались от Namespaces, перешли к концепции импорта модулей, однако
деление модуля на секции (интерфейсная, реализации, инициализации, финализации,
как в Delphi) так и не сделали.

Цитата:

обратная польская запись

простите за глупый вопрос, но что это?

Цитата:

деление модуля на секции

инициализация и финализация — это же конструктор и деструктор, разве нет? а можно ссылочку на теоритические материалы по вопросу «деление модуля на секции»?

кстати основной плюс D — это совместимость с модулями C, можно к программе на D прилинковать модули, написанные на С (но не на С++)

oan42
Меня интересует один вопрос. Никаких наездов и ничего личного, просто хочу узнать мнение. Дельфи тупиковая ветка развития, почему многие пишут на Дельфи? Почему? Там же кроме Борланда никто не развивает это направление. Я правда и сам пишу в основном в C++ Builder'e, среда та же, язык другой. Но я пишу в нём только потому-что есть наследие от предыдущего программиста. Есть в планах переписать программы на Яву. Чем и займусь в ближайшие полгода. Можно было бы и на Visual С++ сделать, или C#, но это не суть, главное не застревать в борландовском болоте... Хмм, как вариант можно было бы кроссплатформенный компилятор С++ взять, с кросплатформенной же графической библиотечкой... Но дельфи... Поражаюсь такой популярности...

когда-то давным-давно Microsoft и Borland заключили соглашение, по которому первая стала развивать язык бейсик, а вторая паскаль — дельфи наверное стала популярной потому, что паскаль изучали в школе, кроме того производительность у дельфи хорошая

Quark Fusion
Я считаю нельзя учить на учебном языке, так как многие потом на нём и остаются. Вот нельзя ведь научить ездить на велосипеде, человека, которому предстоит ездить на машине, нужно сразу учить на машине.

QuarkFusion
Язык Си далек от форта в части обратной польской записи,
но и в нем определение типа переменных идет в обратном порядке,
вначале тип, потом имена переменных.

То же и в языке D:
int count, i; //Обратная польская запись

Желательно было сделать так:

count, i: int;

деление модуля на секции
http://program.rin.ru/razdel/html/306.html

XDiaBLo
Не люблю агитировать за Delphi

1) В давние времена была договоренность между Borland и MS по вопросу раздела
рынка pascal и basic, отсюда отсутствие серьезных конкурентов в данных нишах.
2) Lazarus эмулирует Delphi на основе кроссплатформенного Free Pascal.
3) Откуда уверенность, что Дельфи тупиковая ветка развития?

Мне кажется Delphi однозначно не будет тупиковой веткой.
И поражатся популярности Delphi не стоит, она того заслужила, я думаю причины этого уже все давно изветстны.
То что сейчас моногие переходят на с Delphi на С#, конечно ослабило позицию Borland но ни в коем случае не убило. Тем более это поспособствует новому поиску оригинальных удобных решений чтобы продукт был интересным на фоне продуктов от MS.

oan42
Ну как, взяли язык созданный в учебных целях, и давай его использовать для написания серьёзных приложений? Ну не маразм ли? Ну ладно, допустим если и не тупиковая, но если мне даже C++Builder кажется тупиком, я считаю есть решения и получше, например C++/QT, Java, C#...

C++ был, есть и будет
=> +1

Цитата:

Я считаю нельзя учить на учебном языке, так как многие потом на нём и остаются.

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


Цитата:

int count, i; //Обратная польская запись

ой, да без разницы как писать мне например нравится как в бейсике «dim i as Integer» — просто и ясно, «оперделить i как целое»

Добавлено:

Цитата:

деление модуля на секции
http://program.rin.ru/razdel/html/306.html

это всё условности, в D тоже можно так программировать
Код: module c.stdio; // this is module stdio in the c package

import std.stdio; // import module stdio from the std package
import foo, bar; // import modules foo and bar

void main()
{
writefln("hello!\n"); // calls std.stdio.writefln
}

Quark Fusion
Язык нельзя рассматривать в отрыве от платформы разработки (IDE, компоненты,
либы, плагины, форумы, книги и т.п. ) и специфики приложения.

IMHO, основные двигатели прогресса:
- CodeGear Developer Studio.
- Microsoft Visual Studio.

Цитата:

Язык нельзя рассматривать в отрыве от платформы разработки

почему? вот к примеру для С++ есть множество разных платформ, а для платформы .NET — множество разных языков программирования

Добавлено:

Цитата:

(IDE, компоненты,
либы, плагины, форумы, книги и т.п. )

не являются языками программирования, а компоненты,
либы, плагины можно вообще комбинировать на разных языках
одну и ту же IDE можно использовать в разных целях, возьмём к примеру Eclipse
если изучили C++ и Basic, то вам не составит труда освоить C# и Java

Пардон, хотел сказать, перспективность языка нельзя рассматривать в отрыве от платформы разработки.

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

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

Цитата:

Язык нельзя рассматривать в отрыве от платформы разработки (IDE, компоненты,
либы, плагины, форумы, книги и т.п. ) и специфики приложения.

А язык java, PHP? Это ведь тоже языки программирования.

Quark Fusion

Цитата:

вообще я не понимаю как можно сваливать в одну кучу языки типа C++ и Java — последние используют для работы VM и производительность у них на порядок ниже, а требования к оперативной памяти — выше
C++, D, Delphi — компилируются в быстрый машинный код, а Java, C# и вся группа .NET — в виртуальный байт-код, а ASP.NET вообще вроде не язык программирования

Коллега проверял производительность? И вообще, в каких приложениях имеется в виду производительность? Игры? Или приложения связанные с бизнес-логикой? Или с вычислениями? Тут не всё так однозначно, и во многих случаях Java будет быстрее чем С++.

Сугубо моё мнение, но само понятие "Самый перспективный язык программирования " это понятие на уровне "продайте мне 1 кг. еды". Я уже не очень молод, и застал ещё аналоговые машины, ЕС и СМ тем более. Какие только языки не ходили в этих "самых". Фортран, Алгол, Кобол, Ада ... Жизнь и руководство ставит задачи, которые надо решать с минимальными временными затратами, это судьба любого программиста. Порой поражаюсь, как молодые перцы упорно сидят на одном языке, словно их приклеили к нему на всё жизнь. Есть языки без знания которых называть себя программистом просто бред, это С и ассемблер, а остальное от лукавого. 8 лет ваял на C++ Builder'e, жизнь и фирмачи заставили перейти на VBnet, надо будет перейду на другой. Программист в первую очередь образ жизни и мышления, а остальное от лукавого. Посмотрите на лучших футболистов, сегодня Италия, завтра Испания, послезавтра Англия, совсем состарятся или ещё что, то могут и в Россию с Китаем и в Эмираты.

Кто что может сказать про перспективу Ruby ?

А я очень молод! И придерживаюсь того же мнения что и OldCAM Начинал изучать программирование с basica, pascal. Сейчас в основном употребляю то что позволит решить ту или иную задачу с минимальными трудозатратами. Рисую сложные скрипты на форте в nncron, балуюсь макросами на вижуал басике в экселе, экономические задачи решаю конечно-же на 1С. На Delphi пишу свою прогу, потому что его знаю больше чем C++ и там есть такая штуковина как KOL. Что будет завтра не знаю... Надо будет что-то новое решить и будет для этого лучший инструмент буду его изучать и решать задачу. А разговоры по поводу перспективности того-или иного языка думаю стоит отложить до лучших времен, которые в принципе вряд ли когда наступаят...
ПОКА УЧИМСЯ - ЖИВЕМ, если НАШЛИ "ПЕРСПЕКТИВНЫЙ ЯЗЫК ПРОГРАММИРОВАНИЯ НА КОТОРОМ ОСТАНОВИЛИСЬ", значит мы просто умерли!!! IMHO

Цитата:

Тут не всё так однозначно, и во многих случаях Java будет быстрее чем С++.

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


Цитата:

Порой поражаюсь, как молодые перцы упорно сидят на одном языке, словно их приклеили к нему на всё жизнь. Есть языки без знания которых называть себя программистом просто бред, это С и ассемблер, а остальное от лукавого.

Я тоже поражаюсь как можно использовать только один язык, есть языки, на которых можно быстро написать программу, но она не будет блистать скоростью, а есть те, на которых писать дольше и труднее, но программа будет работать на порядок быстрее. Выход — пишем библеотеку на одном языке и подключаем к программе на другом.
Без знания ассемблера жить вполне возможно, он нужен только для экстремальной оптимизации, но в первую очередь надо убедиться, что алгоритм дальше не оптимизируется.
Остальные языки, типа JavaScript, PHP, Java, Perl, ActionScript и т.п. — от лукавого? Их знание зачастую необходимо, особенно если вы работаете с командой, использующей этот язык.


Цитата:

в основном употребляю то что позволит решить ту или иную задачу с минимальными трудозатратами

Самый перспективный язык это тот, который позволяет как компилировать быстрый код, так и использовать VM для интерпретации (пример — VB6), поддерживает ООП и программирование на низком уровне, содержет поддержку различной логики, типа комплексных чисел, сам управляет памятью, отслеживает ошибки в исходном и откомпилированном коде и т.д.
К сожалению, до такого уровня пока ни один язык не развился. Поэтому мы вынуждены одновременно использовать 2-3 языка для решения порой одной задачи.

Quark Fusion
Ну может не будем говорить так однозначно? Знаешь, была такая фраза, медленно запрягать, но быстро ездить? Так это про Java. На С++ ты компилишь к примеру под 386 проц, чтоб работало на большинстве машин, а виртуальная машина Java компилит под проц на котором непосредственно запускается, используя его на полную катушку, и используя всякие фичи. То есть как раз запускается не спеша, а работает быстро (про графику речи не идёт, это отдельный вопрос). Для задач с болшим количеством вычислений подходит лучше чем С++. Но движок игры я бы таки стал делать на С++. То есть не всё так однозначно как тебе кажется! И я в принципе согласен что под каждую задачу нужно подбирать подходящий инструмент.
Среды и языки в(и на) которых я программировал: Turbo Pascal, Turbo C++, Delphi, C++Builder, Turbo Assembler, Macro Assembler, NetBeans(Java), Visual Studio(C#,C++,Visual Basic), Turbo Prolog, REXX, WSH+Visual Basic, Visual Basic + ArcObject, PL/SQL ну может ещё что забыл упомянуть... В общем я знаю о чём говорю, и согласен что нужно выбирать инструменты под конкретную задачу, в принципе потому я и работал в таких разнообразных средах... Но никогда больше не говори мне что Java "однозначно медленнее" C++.

Добавлено:
Забыл кое-что сказать
Quark Fusion

Цитата:

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

Это опять же ошибочное мнение. Ты уверен что сумеешь оптимизировать лучше чем современные компиляторы? Зря ты так сильно уверен. Качественные компиляторы ты вряд-ли переплюнешь.

Цитата:

С++ ты компилишь к примеру под 386 проц, чтоб работало на большинстве машин, а виртуальная машина Java компилит под проц на котором непосредственно запускается, используя его на полную катушку, и используя всякие фичи.

Чтобы Java компилировала код вроде специальная компилирующая VM нужна, что-то незамечал у SUN'овской какого-то ускорения после запуска. И потом всё равно остаётся код, контролирующий возникновение ошибок и правильность операций.
В С++ ты компилируешь под любую платформу, оптимизировать программу можно под все процессоры совместимых платформ — это уже дело программиста как он задаст параметры компиляции, Gentoo Linux к примеру вообще сама из исходного кода программы компилирует с заданием оптимальных параметров оптимизации под проц, на котором работает.


Цитата:

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

почему вы так уверены? имхо наличие ненужных проверок правильности операций, которые можно было провести еще до компиляции замедлит вычисления. Попробуйте написать видеодекодер на Java и посмотрите сможет ли он хотя бы наполовину приблизиться к оптимизированным декодерам, написанных на С++ с ассемблерной оптимизацией.


Цитата:

Но никогда больше не говори мне что Java "однозначно медленнее" C++.

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

Единственное, что приходит в голову, так это активное использование встроенных в язык оптимизированных алгоритмов вместо написания собственных, но тогда получается что ваша программа практически ничего сама и не вычислияет.
Использование библиотеки с этими алгоритмами в другом языке даст тот же самый результат, что и в Java.
Для корректного сравнения двух языков надо дать им равноценный набор внешних библиотек, в том числе и тех, что идут вместе с языком.
Вот пример программы, которая занимается только тем, что «скармливает» данные обработчику regex и оказывается в 254 раза быстрее простенького аналога на C без обработчика regex.
А вот сравнение С++ с Java



Цитата:

Это опять же ошибочное мнение. Ты уверен что сумеешь оптимизировать лучше чем современные компиляторы? Зря ты так сильно уверен. Качественные компиляторы ты вряд-ли переплюнешь.

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

Цитата:

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

А почему ты уверен, что после такого ручного вмешательства получится быстрее? Ты способен лучше оптимизатора расположить куски кода, фрагменты структур (классов?) и массивы по секциям исполняемого модуля так, чтобы в вызываемой функции или в цикле минимизировать кэш-промахи и предотвратить иногда возникаемый т.н. cache-trashing?
А может ты обладаешь большей прозорливостью в плане проектирования загруженности ступеней конвеера у процессора? В количестве, скажем, штук эдак 20-и?
Давай, уберём одну "лишнюю" быструю инструкцию, чтобы следующая попала не на первый декодер, который способен был бы декодировать её за один такт, а на третий, который этого не сможет, и вся последующая цепочка нарушит последовательность, так замечательно распланированную оптимизатором вплоть до конца третьей полной кэш-строки.
Ещё мы заменим вот эти три команды одной, которая будет даже на первом декодере (причём из-за того, что третий, на который она попала "в естественном потоке", её просто пропустит из-за своей неспособности её обработать, а значит вхолостую простоит целый такт, и в целом конвеер обеднеет по меньшей мере на одну - если повезёт - инструкцию) декодироваться более одного такта, а остальные два декодера, выполнив свою работу (и то, если будут способны, т.к. дальше, вполне возможно, оптимизатор поставил многотактную инструкцию, запланированную им на первый декодер) будут простаивать ещё два такта, т.к. вне очереди инструкции только исполняются, но отнюдь не декодируются. А кроме того, смещается адрес начала цикла, который получается не выровненным по границе кэш-строки, а значит при возврате к началу цикла 64-байтная кеш-строка читается почти что вхолостую, т.к. из неё испольуются только последние два байта.
Вот эта команда вообще лишняя - уберём её вообще. И даже на всякий случай заполним NOP-ами её прежнее месторасположение. А то, что она за четыре такта до реальной надобности предзагружала данные в кэш первого уровня из кеша второго, а кроме того ещё и подготавливала "переименованный регистр" для буфера неупорядоченного исполнения, чтобы он без штрафов мог отобразиться на ECX, так это ничего, переживём.
Тогда научи меня, плз. Или ты согласен немного выиграть "здесь" и поболе проиграть вот "там"?

Цитата:

А почему ты уверен, что после такого ручного вмешательства получится быстрее?

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

Цитата:

по секциям исполняемого модуля

это еще зачем? речь идёт об оптимизации узких мест а не всего модуля в целом.

Цитата:

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

Вы что такое профилирование знаете?

Мда, с товарищем уже даже спорить не хочется, так как убедить хотя бы призадуматься невозможно в принципе...