Author: Пол Грэм

Языки программирования, подобно формам жизни, образуют эволюционное древо. На этом древе есть и тупиковые ветви, и некоторые из них уже известны. Кобол, несмотря на всю свою популярность в былые годы, похоже, не оставил интеллектуальных потомков.

Я считаю, что похожая судьба ждёт и Джаву. Люди спрашивают меня: "Как можно говорить, что Джаве не быть? Она уже стала успешным языком". И я не могу не согласиться с ними. Джава - успешный язык, если считать мерилом успеха площадь полок с учебниками Джавы в книжных магазинах или количество студентов, убеждённых, что знание Джавы поможет им найти работу. Я имел в виду другое. Мне кажется, Джава окажется таким же эволюционным тупиком, как Кобол.

Это лишь гипотеза. Я могу ошибаться. Но речь не о Джаве, сейчас я хотел бы поговорить об эволюции языков и побудить всех задуматься о том, на какой ветви эволюционного древа помещается язык Х. Смысл постановки такого вопроса заключается отнюдь не в том, чтобы через столетие наши бестелесные духи могли заявить, дескать, мы же предупреждали. Придерживаться основных ветвей эволюции может оказаться неплохой тактикой при выборе языка и сегодня.

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

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

Я считаю, что фундаментальные операторы - это самый важный фактор, влияющий на выживание языка в долгосрочной перспективе. Всё остальное может меняться.

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

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

Конечно, уже в самой постановке вопроса о том, какими станут языки программирования через сто лет, есть немалое допущение. А будут ли тогда вообще писать программы? Может быть, мы просто будем говорить компьютерам прямым текстом, чего от них хотим?

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

Может вызывать сомнения сама возможность прогнозирования того, какой станет техника через сто лет. Но не стоит забывать, что у нас за плечами почти пятьдесят лет истории программирования. Если обратить внимание на то, как медленно языки менялись до сих пор, попытки что-то предсказать уже не покажутся такими бесперспективными.

Скорость развития языков программирования так мала из-за того, что на самом деле языки не являются технологиями. Языки программирования - это форма записи. Программа представляет собой формальное описание проблемы, которую нужно решить с помощью компьютера. Так что по темпам развития языки программирования ближе к математической нотации, чем, скажем, к средствам траспорта или связи. Математическая нотация тоже эволюционирует, но не такими гигантскими скачками, как техника.
***

Из чего бы не делались компьютеры через сто лет, можно не сомневаться, что они будут гораздо быстрее, чем сейчас. Если действие закона Мура сохранится, компьютеры станут в 74 квинтиллиона раз быстрее. Это сложновато себе представить. Впрочем, по всей вероятности, закон Мура окажется несостоятельным. Всё, что должно удваиваться каждые восемнадцать месяцев, рано или поздно наталкивается на какой-нибудь фундаментальный предел.

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

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

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

Такое происходит не только с языками программирования. Это всеобщая историческая тенденция. Развитие техники даёт новым поколениям возможность делать вещи, которые раньше считались бы излишеством. Лет тридцать назад люди были бы потрясены, узнав, насколько обыденными станут в наше время междугородные телефонные звонки. А лет сто назад известие о том, что сейчас за один день посылка может преодолеть путь от Бостона до Нью-Йорка через Мемфис, поразило бы всех ещё сильнее.
***

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

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

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

Бывают примеры правильного расточительства, и бывает и неверная расточительность. Меня интересует полезное. Например, расточительство, которое вынудит тратить больше, но взамен позволит упростить устройство. Какую выгоду можно извлечь из огромных ресурсов нового быстрого аппаратного обеспечения?

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

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

Если считать основой языка набор аксиом, то дурно в погоне за эффективностью копить лишние аксиомы, которые не дают языку дополнительной выразительной силы. Эффективность важна, но мне кажется, что добиваться её следует иначе.

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

Поскольку скорость не важна в большинстве программ, как правило, можно не заботиться о подобных мелочах. Чем быстрее будут становиться компьютеры, тем вернее будет это утверждение.
***

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

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

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

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

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

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

Есть ещё более ошеломительные перспективы. Например, в языке Лисп, который в 1960 году изобрел профессор Маккарти, отсутствовали числа. Если рассуждать логически, то отдельная запись для чисел не нужна, ведь их можно представить в виде списков: число n может быть представлено как список из n элементов. Вычисления можно выполнять таким способом. Просто это невыносимо неэффективно.

В действительности, никто не предлагал реализовывать числа в виде списков. Фактически, реализация научной работы, которую Маккарти написал в 1960 году, вообще не планировалась. Это была чисто теоретическая попытка создания более элегантной альтернативы машине Тьюринга. Когда кто-то неожиданно взял работу Маккарти и превратил её в работающий интерпретатор Лиспа, числа, разумеется, не были представлены списками, они были представлены двоичными значениями, как и в любом другом языке.

Может ли развитие языков программирования зайти настолько далеко, что в них не будет чисел как фундаментального типа данных? (Я задаю себе этот вопрос не всерьез, а только ради того, чтобы подразнить будущее. Это похоже на гипотетическое столкновение неминуемого с недвижимым, только в нашем случае против невообразимо неэффективной реализации ставятся невообразимо огромные ресурсы). Думаю, может. Почему бы и нет? Будущее - штука несиюминутная. Если что-то позволяет уменьшить число аксиом в основе языка, это и есть та сторона, на которую следует делать ставки, когда t стремится к бесконечности. Если через сто лет идея окажется невыполнимой, то, может быть, через тысячу лет уже всё изменится.

(Расставлю точки над i: я не предлагаю вести все числовые вычисления действительно при помощи списков. Я предлагаю, чтобы прежде любых дополнительных упоминаний о реализации именно так определялась основа языка. На практике программы, ведущие вычисления, вероятно, будут представлять числа в виде двоичных значений, но это оптимизация, а не часть семантики основы языка.)
***

Многочисленные программные прослойки между приложением и аппаратным обеспечением - другой хороший способ израсходовать лишние такты. Эту тенденцию тоже можно наблюдать уже сегодня: многие новые языки программирования компилируются в байт-код. Эмпирически можно считать, что каждый уровень интерпретации понижает скорость вдесятеро. Такую цену приходится платить за гибкость.

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

В восьмидесятых годах идею повторного использования каким-то образом связали с объектно-ориентированным программированием, и сколь угодно многочисленные доказательства обратного, по-видимому, уже не избавят от этого клейма. Хотя иногда объектно-ориентированный код годится для повторного использования, таким его делает не объектно-ориентированность, а программирование "снизу вверх". Возьмём, например, библиотеки: их можно повторно использовать, потому что, по сути, они представляют собой язык. И неважно, написаны ли они в объектно-ориентированном стиле или нет.

Кстати, я вовсе не предрекаю гибель объектно-ориентированного подхода. Хотя, по моему мнению, за исключением некоторых специализированных областей применения, объектно-ориентированность ничего не даёт хорошим программистам, она очень привлекательна для больших организаций. ООП - это приличный способ написания путаного лапшеобразного кода, позволяющий строить программы в виде серии патчей. Большие организации всегда были склонны разрабатывать программное обеспечение таким образом, и думаю, этому и через сто лет не измениться.
***

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

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

Но в действительности вопрос в том, насколько высоко по лестнице абстракций сумеет взобраться параллелизм? Придётся ли прикладным программистам учитывать его существование через сто лет? Или он так и останется заботой создателей компиляторов, но практически не видим в исходном коде приложений?

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

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

И как в случае со специфическими реализациями структур данных это будет осуществляться на довольно поздних стадиях разработки - при оптимизации. Первая версия, как правило, будет игнорировать все преимущества, которые могут дать параллельные вычисления, в точности как игнорируются преимущества, полученные благодаря специфическому представлению данных.

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


© www.computerra.ru

Это сообщение отредактировал(а) foRaver - 6.8.2004, 15:42

Много воды... Причем здесь Java в начале не понял...
Представление чисел в виде списков длинны n очень удивило... хотел бы посмотреть на того кто так работает. Как резлизовать дробные числа?

Цитата

В конце концов, массивы - это лишь частный случай хэш-таблиц, в которых в качестве ключей используют множество целых чисел. А станем ли мы заменять сами хэш-таблицы списками?

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

В каком году это писали?

Цитата

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

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

Это сообщение отредактировал(а) Zandr - 9.8.2004, 07:38

Sardar'у - А вас не удивит число в виде функции принадлежности. А то математика уже готова. Вы не в курсе? Число как обьект со свойствами. Это что, для Вас новость ? Вопрос на засыпку - а что такое алгебра ?
А если память организована в виде нейронной ассоциативной сетки, то чем с ней работать ?

Zandr'у "процессы разветвляются во всех современных осях" - а ты кто по жизни ? Разветвляются или разделяются - есть разница ? Вообще, наезжать на личность вместо нормальной критики - это, как бы это тебе по академгородковски выразится - нэкрасыво.

Теперь по делу. Java ведь не принесла ничего нового в сущности. Реализация чистого ООП, также как шарп. А уж когда имеешь дело с конкретными реализациями, например в Matlab, то хочется сказать: лучше чтоб тебя не было. Ну, это детали. Вообще, языки, похоже, развиваются в двух направлениях: 1. математическая 2. прикладная-бытовая. Ну с первыми все понятно, пока есть математика, будут языки программирования ее. И все более приспосабливаясь к уровню и традициям именно математики. Пример - языки матпакетов. А вот со вторым направлением, мне кажется будет интересней. Я потоптался в сети на тему создания исскуственного интеллекта, так тамошние гуру утверждают, что лет через 50 нечто подобное будет создано. Вряд-ли этот ИИ будет программироваться такими примитивными средствами как современные языки. Скорее это будет некий компромис между естественным языком и формальным. Мы делаем машины и машины делают нас. Сейчас уже делают элементную базу для нейрокомпьютеров, так неужели их будут обучать на C++. Кстати вот небольшой пример - если кто нибудь думает, что противоракета решает дифференциальные уравнения для вычисления движения своей и цели, то сильно ошибается. На это просто нет времени. А как она действует - это большое ноухау. Вольфрам, основатель одноименной компании утверждал примерно следующее - человечество зациклилось на решении задач имеющих точное решение. Между тем, имеется масса задач требующих просто "хорошего" решения, и точное в них едва-ли возможно. И таких задач БОЛЬШЕ. И современные языки для них не подходят. Так, что можно почти уверенно предположить, что современные языки не проживут и пару - тройку десятков лет. Ничто не вечно под луной. Этот принцип еще никто не обманул.

Уважаемый Guest , ваши рассуждения вполне логичны, методы тоже заурядны: много воды, критика на современные наработки и никаких новых перспективных идей
Мое мнение о статье самое негативное, автор не вложил своей мысли, а просто написал текст "прочесть и забыть".

Цитата

Теперь по делу. Java ведь не принесла ничего нового в сущности.

Я приму вашу оценку если вы действительно знакомы с Java, а не прочитали пару книжек "Java за 24 часа" Я видел столько откровенных ламеров пытающихся дать "экспертную" оценку какому либо языку. Сотрясение воздуха не более.
Мне Java нравится, это очень изящный язык. Я также хочу изучить C#, Lisp и Python - так что бы выражаться на этих языках, а не давать им "пустую" оценку. Человек знающий вряд ли скажет абстрактно о языке "он не хороший", а расскажет о задачах в которых язык удобен или не удобен

О будущих наработках - поживем увидим . Будет новое - выучим, не понравитьтся - не будем использовать. Воевать что лучше а что хуже - удел ярко выраженых "не проффесионалов" - каждый выбирает то с чем работать сам(или ему в этом помогает начальник ) Так что:

Цитата

А если память организована в виде нейронной ассоциативной сетки, то чем с ней работать ?

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

Если вы автор статьи то... статья просто никакая... но это оценка не профи , так что её смело можно называть "сотрясанием воздуха"

Цитата

Sardar'у - А вас не удивит число в виде функции принадлежности. А то математика уже готова. Вы не в курсе? Число как обьект со свойствами. Это что, для Вас новость ? Вопрос на засыпку - а что такое алгебра ? А если память организована в виде нейронной ассоциативной сетки, то чем с ней работать ?

А вот тут, уважаемый Guest поподробнее. Я нахожу такие подходы крайне интересными...

Цитата

Zandr'у "процессы разветвляются во всех современных осях" - а ты кто по жизни ? Разветвляются или разделяются - есть разница ? Вообще, наезжать на личность вместо нормальной критики - это, как бы это тебе по академгородковски выразится - нэкрасыво.

Я? Я по жизни на гитаре играю и песни пою. Только я на личность не наезжал, и, извини, не предусмотрел твою повышенную ранимость... Перефразирую вопрос: чем сей великий муж зарабатывает себе на жизнь и в чем он проявил себя? На счет разделения процессов: есть такая нота... fork() называется вроде... Или автор не ее имел в виду? Если нет, то звиняйте - ослышался. По академгородковски было бы что-то вроде - "На самом деле, ...". Вырождается академ...

Цитата

Теперь по делу. Java ведь не принесла ничего нового в сущности. Реализация чистого ООП, также как шарп.

Кстати о чистом ООП в шарпе... (Часть "Is everything object?"). Думай о чем пишешь. А Java - действительно красивый, чистый язык. Со всякими приятными штуками (реальный crossplatform, механизм gc, ...) Да и под портативные устройства я бы лучше на JavaME кодил чем на Asm'е (На асме кодил три года под Z80).

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

На счет МатЛаба... Плохому танцору всегда есть на что пожаловаться.

Цитата

Вообще, языки, похоже, развиваются в двух направлениях: 1. математическая 2. прикладная-бытовая. Ну с первыми все понятно, пока есть математика, будут языки программирования ее. И все более приспосабливаясь к уровню и традициям именно математики. Пример - языки матпакетов. А вот со вторым направлением, мне кажется будет интересней.

Вообще, языки, похоже, развиваются в двух направлениях: 1. интерпретируемая 2. компилируемая. Ну с первыми все понятно, пока есть интерпретаторы, будут языки, интерпретируемые. И все более приспосабливаясь к уровню и возрастающей производительности именно компьютеров. Пример - JavaScript, PHP, Perl. А вот со вторым направлением, мне кажется будет интересней.

Могу еще несколько вариантов написать.

Млин, бред какой-то...

Через 100 лет все будет управляться силой мысли!!! :-)))) Думаешь о программе, а она пишется!!! Отсюда ясно, что будущее за такими языками как Пролог и Лисп!!!!
:-))))))))))))))))))))))))))))

Тема обсуждалась также здесь.

Цитата(Zandr @ 8.8.2004, 22:37)

Он по жизни-то кто вообще, мужик-то этот?

Пол Грем, lisp гуру, автор 2х книг по лиспу, пишущий в настояще время разновидность lispa Arc.
Человек ранимый, поэтому сильно воспринимает непопулярность лиспа и соответственно пытается отыграться на Java.
По его собственным словам, не написал ни одной Java программы, пролистал несколько книг по Java. Аргументы в борьбе с Java следующие: это не язык хакеров, хакеры его не любят, никто Java не любит (он сам у знакомых спрашивал), язык вообще бюрократичный ибо он обнаружил там
"много протоколов". Одним словом - дурак.

Цитата(Guest @ 9.8.2004, 05:12)

Java ведь не принесла ничего нового в сущности.

Чтобы говорить что-то, нужно прежде всего подучиться. Что Java принесла нового ?
Пожалуйста:

SDK
1. Чистый ОО язык, в отличие от C++.
2. Кроссплатформенность.
3. Прекрасные библиотеки; сравнивать с STL смещно.
4. Пакеты
5. Виртуальная машина
6. Апплеты, миграция в web.
7. Интерфейсы, избавление от multiple inheritance
8. Безопасность, "sand box"

J2EE
1. Сервлеты, тэг библиотеки, иной цикл жизни веб приложений
2. EJB - революционная технология
3. J2EE как платформа

Наверняка можно гораздо больше назвать, но не в этом суть.

Внесу свои 2 цента.

Разница между интерпретированием и компилированием - это вопрос оптимизации интерпретатора. Можно сказать, что компилятор - это сильно оптимизиррованный интерпретатор, который позволяет еще до запуска приложения перевести многие конструкции в machine code (ради скорости исполнения, а не ради самого machine code). Если выпустят процессор, который будет в железе Ruby код выполнять, Ruby ведь тогда станет компилируемым языком...

Языки движутся по двум направлениям: с математической основой и с практической. Первые живут дольше, т.к. архитектурно не связаны с сегодняшним днём. Таким языком является C++. Если из C++ убрать всё, что вешается через '#include', то единственной связкой с реальным миром останется представление "qweasd" как {'q', 'w', 'e', 's', 'd', '\0'} - да и то конструкция "строка" введена только для удобства написания быстрых "скриптовых" программ. В реальном софте всё грузится из ресурсов, и строки как "qweasd" попадаются крайне редко. Такие вещи как файлы не являются частью языка.

Я вижу Java как язык с практической основой. Сейчас он в расцвете, через 10 лет - фиг знает... прикалывает меня фраза "избавили от multiple inheritance" - в C++ его никто не навязывает вроде Другой язык с практической основой - ASM. Java проживёт дольше ASM, т.к. часть парадигмы/идеологии/синтаксиса она взяла от C++. Эволюция Java сравнима с эволюцией Visual Basic. Когда-то простота использования ActiveX была коньком-горбунком VB, сегодня ActiveX Java'ы - это EJB.

C++ без своей библиотеки остаётся C++. Java становится нонсенсом.

- Ты проживешь без короля?
Солдат сказал: "Изволь"
- А ты без армии своей?
"Ну нет" - сказал король.
© советская басня

Вы никогда не думали, почему язык, созданный в 80-90х годах применим до сих пор с такой же лёгкостью в современных задачах? Те, кто будут говорить, что - нет, не применим, не соглашусь. Так говорят те люди, которые ищут библиотеки для работы вместо того, чтобы создать свои поверх native API. Такие люди судят об удобстве C++ по удобству MFC (или по удобству STL). Он может быть на 10-20% слабее, чем ориентированный на задачу язык, но он сохранит эти 10-20% везде. Ориентированный на задачу язык через 100 лет будет на 100% слабее, труднее.

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

На мой взгляд, сейчас есть две парадигмы (которые не хило диктуются синтаксисом) - C(++)-ная и LISP-овская. Со вторым я знаком крайне поверхностно, но и сверху исходит какой-то свет.

На Java можно быстро создавать приложения, выливать их в $income/year. На C++/LISP можно создавать новые абстракции, новые методы. Java может себя расширить? Могут все эти EJB быть созданными на Java же?

Именно поэтому C++ так "туго" идёт в перед (я имею в виду C++0x). Это сродни добавлением новых аксиом в ту же алгебру - х его з, чем это закончится... Люди любят работать с файлами, базами данных... - всё это модели сегодняшнего дня, и язык не должен быть с ними связан "душой", если он позиционирует себя как универсальный глобально, а не как универсальный сегодня.

С++ - карандаш. Java - лазер. Лазером рисовать "круче", но он, как правило, зафиксирован.

Весь этот текст - не на тему "что лучше". Спорить на эту тему сродни: что лучше - математика или dance-музыка? Кто сегодня пойдет на дискотеку, выберет музыку, кому приятно иметь дело с чем-то вечным и философским, выберут математику Первые рассматривают доход как основу (скорость написания проекта), вторые - внутреннюю философию и спокойствие, а доход как бонус (который зачастую оказывается сравнимым). Я лично предпочитаю второй путь ;)

P.S: Полу Грему респект.

Я тут смотрю, народ стал на шарп гнать нехорошо .
Товарищу, который высказался чуть выше меня: не надо говорить, мол пишите только на API, это гораздо лучше, чем пользоваться библиотеками, которые используют только ламеры. Хочешь реальный пример? Пожалуйста. Скажем, есть у тебя БД Access, и ты хочешь с ней работать. Ты написал программу и вдруг начальство просить тебя написать версию программы, работающую с MySQL. Что ты сделаешь? Будешь все переписывать? В .NET такая проблема решается заменой пары строчек. И в Java вроде бы тоже. Вот тебе и native API.

Компилятор - это программа которая принимает данные на одном языке, называемым входным языком, и порождает текст эквивалентной программы на другом языке назваемым выходным.
Например для компилятора Intel C++ Compiller входным языком будет язык описываемый ANSI C++. А выходным будет байткод процессора x86.

Интерпретатор - это устройство которое получает на вход программу на входном языке и данные, а на выходе выдает результат работы данной программы.
Интерпретатор может быть как полностью аппаратным, например процессор picoJave аппаратный интерпритатор байт кода JVM. Так и аппаратно-програмным, как JRE для платформы x86.

Паскаль повержен - впервые за много лет


Это сообщение отредактировал(а) Olej - 17.12.2016, 19:08