Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Самый перспективный язык программирования

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Открыть новую тему     Написать ответ в эту тему

Самый перспективный язык программирования
 ОтветГолосаПроценты
Java60
10.56%
C#108
19.01%
Asp.net2
0.35%
C++212
37.32%
Visual Basic.net19
3.35%
Delphi96
16.90%
что то другое71
12.50%
Гости не могут голосовать, зарегистрируйтесть!Всего Голосов: 568
XDiaBLo



Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Quark Fusion

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

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

Всего записей: 244 | Зарегистр. 13-05-2004 | Отправлено: 11:36 05-01-2007
OldCAM



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

Всего записей: 963 | Зарегистр. 23-06-2004 | Отправлено: 13:12 05-01-2007
n0px

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Кто что может сказать про перспективу Ruby ?

Всего записей: 69 | Зарегистр. 22-10-2005 | Отправлено: 17:37 05-01-2007
NeeDiGeo

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

Всего записей: 52 | Зарегистр. 07-09-2006 | Отправлено: 17:48 05-01-2007
Quark Fusion



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

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

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

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

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

Всего записей: 146 | Зарегистр. 21-12-2006 | Отправлено: 22:50 05-01-2007
XDiaBLo



Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
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

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

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

Всего записей: 244 | Зарегистр. 13-05-2004 | Отправлено: 19:43 06-01-2007
Quark Fusion



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

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

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

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

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

 

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

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

Всего записей: 146 | Зарегистр. 21-12-2006 | Отправлено: 01:22 07-01-2007
Qraizer



Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

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

Всего записей: 613 | Зарегистр. 08-08-2006 | Отправлено: 22:26 08-01-2007 | Исправлено: Qraizer, 22:52 08-01-2007
Quark Fusion



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

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

Всего записей: 146 | Зарегистр. 21-12-2006 | Отправлено: 03:16 09-01-2007
XDiaBLo



Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Мда, с товарищем уже даже спорить не хочется, так как убедить хотя бы призадуматься невозможно в принципе...

Всего записей: 244 | Зарегистр. 13-05-2004 | Отправлено: 07:04 09-01-2007
Qraizer



Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

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

Цитата:

Цитата:
по секциям исполняемого модуля
это еще зачем? речь идёт об оптимизации узких мест а не всего модуля в целом.
Если б это было так просто... Моя цитата:
Цитата:
Или ты согласен немного выиграть "здесь" и поболе проиграть вот "там"?
Проверять-то нужно поглобальней, чем просто тот кусочек, который "патчится".
Цитата:
Вы что такое профилирование знаете?
А то. Стал бы я тогда такой длинный пост делать.
Я не спорю с тем, что не всегда оптимизатор способен лучше тебя просчитать узкие места. Но то, что он куда как большее количество факторов учитывает, чем способен это сделать человек при приемлемых трудозатратах - вот в этом меня придётся убеждать. Да и не все критичные факторы я перечислил. Есть ещё предсказание ветвлений, переупорядочивание подвыражений, подмена элементарных операций, оптимизация нагрузки на двухканальную шину... Что-то ещё наверняка есть, чего я не знаю. В общем, "из спортивного интереса" я б с ним соревноваться не стал. Если припечёт, тогда может быть, но я на своём веку достаточно насмотрелся на оптимизированный код в отладчике, чтобы без достаточного обоснования не заниматься этим.

Всего записей: 613 | Зарегистр. 08-08-2006 | Отправлено: 07:05 09-01-2007 | Исправлено: Qraizer, 07:08 09-01-2007
Quark Fusion



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Проверять-то нужно поглобальней, чем просто тот кусочек, который "патчится".
зачем? профилирование позволяет найти именно те кусочки, которые нужно оптимизировать, от оптимизации кода, не влияющего на скорость, толку особого всё равно не будет.

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

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

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

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

О чём призадуматься? О том что Java быстро «ездит», как вы говорили? Я вам даже пример независимого тестирования привёл, на котором видно, что Java в несколько раз медленне C++, неговоря уже о десякратном требовании к  оперативной памяти. Если вдруг в системе станет нехватать памяти при работе несольких программ, то падение производительности будет куда существенней, чем при нехватки ресурсов процессора.
 
 
Добавлено:
Основной аргумент в пользу Java это то, что её код может работать под разными платформами и не требует никаких дополнительных затрат для этого. Никаких других плюсов над прочими языками я не вижу. На её синтаксис жалуются многие, скорость оставляет желать лучшего, а требования к памяти просто огромные.
 
Добавлено:
Хочу процитировать Boris Kolar:
Цитата:
My advice: use the best or the most popular language for the platform.
Don't bother with "slightly better but less popular" category. So, if
you target .NET, use C# (most popular) or Boo/Nemerle (best), don't
bother with VB.NET, J# and others.
 
If you target JVM, use Java (also take a look at Scala - I don't like
it too much because it seems more complex than necessary).
 
If you must have fast startup times, or must integrate with OS API, use
C++ (most popular) or D (best). Maybe Eiffel is also worth considering.
D is not (yet) very good for real-time programming (see all garbage
collection, deterministic finalization threads for reasons), but Walter
will likely fix that soon.
 
I personally use D for OS-integrated projects and Java for all others.
If Boo for JVM (or native) existed, I would definitely use Boo (I'm almost
tempted to write JVM port of Boo myself).
в переводе, если вы выбираете язык под конкретную платфору, то берите либо самый популярный язык, либо же самый оптимальный, если вам нужен быстрый запуск программы, то следует отказаться от Java или .NET
 
Добавлено:
В качестве самого перспективного языка программирования я считаю D
Цитата:
Gregor Richards has found a way to compile D code to JVM compatible  
programs, that can be run in a JVM. So, if this is taken a bit further,  
maybe we can even say "D runs in a VM, too, if you want".
так что есть вероятность получить как быстрый и удобный язык, так и все преимущества Java.
 
Добавлено:
http://www.codu.org/nestedvm-gdc/

Всего записей: 146 | Зарегистр. 21-12-2006 | Отправлено: 08:44 09-01-2007
OldCAM



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Quark Fusion
Как говорят в Черноморске "Kolar конечно голова", но не может являться истинной в последней инстанции, тем более Ваш перевод более чем волен.

Всего записей: 963 | Зарегистр. 23-06-2004 | Отправлено: 10:13 09-01-2007
Quark Fusion



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
перевод был в форме обобщения — видно же, что в оригинале слов намного больше

Всего записей: 146 | Зарегистр. 21-12-2006 | Отправлено: 10:17 09-01-2007
XDiaBLo



Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Quark Fusion
Я сам умею читать по английски, перевод воистину оригинален =))) Ладно, я сам попробую некоторое тестирование производительности провести. Если сделаю, то результат предоставлю.

Всего записей: 244 | Зарегистр. 13-05-2004 | Отправлено: 12:27 09-01-2007
Quark Fusion



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ну не «в переводе», а «обобщая» — просто я когда писал передумал переводить

Всего записей: 146 | Зарегистр. 21-12-2006 | Отправлено: 12:38 09-01-2007
XDiaBLo



Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Quark Fusion
Думаю результаты тестирования предоставлю нескоро, так как хочу хорошенько разобраться, и поиздеваться над большими числами. Потестирую пока только вычисления с большими числами... Сравню Java и C++. Самому интересны результаты =) Потом может продолжим тестирование и в других областях, если кому-то интересно. Сравнивать буду только скорость выполнения, занимаемая память меня мало волнует, так как не для КПК ведь пишу, и не для всяких микрочипов встроенных в бытовую аппаратуру %)

Всего записей: 244 | Зарегистр. 13-05-2004 | Отправлено: 15:07 09-01-2007
Quark Fusion



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
занимаемая память меня мало волнует
ну вот так всегда, занимаемая память разработчиков мало когда волнует, они почему-то считают что для их программы будет выделен отдельный высокопроизводительный сервер
 
Добавлено:
кстати, попробуйте откомпилировать программу на С++ компилятором от Intel или GCC 4.1 — скорость может вырасти, а программу на Java надо протестировать на серверной VM и на десктопной

Всего записей: 146 | Зарегистр. 21-12-2006 | Отправлено: 15:40 09-01-2007
Qraizer



Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
"Движенья нет!" - сказал мудрец брадатый.
Другой смолчал и стал пред ним ходить.
Сильнее он не смог бы возразить.
Хвалили все ответ замысловатый.
© Пушкин, вроде. А спорим на шаблонах выражений в C++ я одной левой любой ассемблерный алгоритм сделаю? Пусть потом докручивают перспективный D сколько угодно.

Всего записей: 613 | Зарегистр. 08-08-2006 | Отправлено: 19:44 09-01-2007
Quark Fusion



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
А в D есть mixins и ассемблерные вставки тоже, и что значит «сделаете»? по скорости выполнения?

Всего записей: 146 | Зарегистр. 21-12-2006 | Отправлено: 06:15 10-01-2007 | Исправлено: Quark Fusion, 06:17 10-01-2007
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Самый перспективный язык программирования


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru