ФАНТАЗИИ, ФАНТАЗИИ.
Мармот, подозреваю, что этим постом я могу несколько навредить себе, но азарт – сильнее.
Во-первых, о твоих комментариях моего поста. В принципе я согласен по всем пунктам твоих замечаний. Прошу только учесть два обстоятельства –то, что мои знания о программировании весьма скромные, и что там я постил «навскидку». На этом мои оправдания заканчиваются.
Программа и данные сливаются в одно понятие, становится очень просто автоматически анализировать семантику кода и генерить код в runtime
Безусловно, такого не делает, на сколько мне известно, пока ещё ни один компилятор;). Но вот скажи, не преобладает ли здесь (и только здесь), когда ты говоришь о крутости генерации кода в runtime, «цеховой» интерес и стереотип. Не о том ли ты, что это круто с точки зрения возможности передачи лисп «конверта» на удалённую машину, для того, что бы выполнить там генерацию и, собственно, выполнения кода? Разумеется, я имею здесь в виду чисто концептуальный аспект. Пусть живёт жава.
Если ты «не договариваешь» ЭТО, то ведь мы пытаемся говорить в этом топике «глобально». Не привязываясь пока к прикладным ветвям отраслям, что ли, технологий.
С формой типа (setq a (+ b c)) все проблемы возникают из-за инерции мышления, согласись, семантически нету разницы между вызовом функции или сложением и/или присваиванием.
1) Соглашусь.
2) По поводу привычности-непривычности для меня лично такой вопрос ВООБЩЕ не стоит. Поскольку часто (к сожалению, почти всегда) вопрос ставится несколько иначе.
Теперь о статье. Впечатление может быть разным, в зависимости от того, что уже известно об этом авторе. Я, конечно, только что посмотрел, кто это. Считай, что это моё мнение о статье, как если бы мне положили на стол листок со статьёй без «автора».
Нет «подозрений» в части его знания сабж. Мне только не нравится мемуарный стиль изложения. В России так пишет профессура (на пенсии). Мы с автором статьи люди разных культур и устоев. У нас просто не принят такой лёгкий стиль изложения технических аспектов. Принят - если только это популярная литература, типа «Наука и жизнь». Мне больше импонирует стиль изложения, например статей в MSDN.
Очень даже не злая шутка:
Вспоминая «золотые времена», можно сказать: «Работа товарища представляется интересной и перспективной. Рекомендуется доработать и улучшить. Рекомендуем продолжить исследования. Следующий раз заслушать товарища через …. Прошу голосовать, товарищи. Кто за?».
Теперь собственно язвительность в части некоторых утверждений автора статьи и злые шутки по поводу стиля построения статьи технического плана. Затем я выскажусь.
What kind of programming language will they use to write the software controlling those flying cars?
Ясно. Про бортовые компьютеры. Готовлюсь услышать дальше о битах, джампах и др. асмовском безобразии.
We can see this happening already.
Нет никакого, dead-end. Не наблюдается. Кто это позволит? Не MS ли, с его неуёмным аппетитом, и подростковой активностью созревающего мужчины. Счёт-то на миллиарды.
When I say Java won't turn out to be a successful language, I mean something more specific: that Java will turn out to be an evolutionary dead-end, like Cobol.
Конечно, уйдёт, всё уйдёт. Прописные истины ни кому не интересны.
Если говоришь: «Яве хана, C++ хана», то необходимо аргументировать. А так, шаманство. Общие рассуждения «дарвиниста».
Второе, что хочу отметить - автор несколько заблуждается относительно смерти Cobol, по крайне мере в Канаде. На самом деле, есть в Канаде потребность в программерах Cobol. Да-да. Откуда знаю – не скажу.
The Fortran branch, for example, seems to be merging with the descendants of Algol.
Ну, так и назвать бы надо достойного «наследника» (ков), а то так, голословно просто «шашечки» какие-то получаются.
Any programming language can be divided into two parts: some set of fundamental operators that play the role of axioms, and the rest of the language, which could in principle be written in terms of these fundamental operators.
Автор говорит здесь и чуть ниже о «фундаментальности»
операторов, что мол всё остальное –само-собой получится. Не получится, поскольку даже в моём сурогатно-извращённом представлении минимальным «набором» является множество типов данных и операций над ними.
В части
операторов многие алгоритмические языки схожи. Что с того? Java вообще имеет С - подобный синтаксис (смешно – я ведь не знаю джавы) . Из схожести операций не вытекает необходимо и достаточно схожести языков программирования.
Any – в начале абзаца, и декларации, как бы «гарантирует» автора (как ему кажется) в логичности всех его дальнейших построений. Ничего подобного. Никаких авансов вам, дорогой товарищ, не будет.
I think the fundamental operators are the most important factor in a language's long term survival.
Ну, да int нельзя складывать со строкой.
The rest you can change. It's like the rule that in buying a house you should consider location first of all. Everything else you can fix later, but you can't fix the location.
Ой мама родная. Ну, и дела наши философские, вот уже до аналогии с
хауз доехали. Я на Канадском форуме и здесь я в гостях, поэтому рот закрыл. Креплюсь.
I have a hunch that the main branches of the evolutionary tree pass through the languages that have the smallest, cleanest cores. The more of a language you can write in itself, the better.
Это только «hunch», как и говорит автор. Примеры – в студию. Если говоришь, что смол-коре родит всё остальное в языке XXI века, так приведи примеры. «The more of a language you can write in itself, the better» - кроме того, ЭТО где-то мы уже слышали. Мож сослаться на «соавторов»?
Won't we just tell computers what we want them to do?
Заметка в «Науке и жизнь». (шутка)
Languages evolve slowly because they're not really technologies.
Программирование, как процесс изготовления коммерческого продукта с одной целью - заработать – это технология. Программировать можно технологично, или нетехнологично. Делая вашу фирму благополучной, или превращая её в школу программирования для нетехнологичных программистов.
Languages are notation.
Ну, а что…. В принципе и согласится можно. Но только что из этого?
I learned to program when computer power was scarce. I can remember taking all the spaces out of my Basic programs so they would fit into the memory of a 4K TRS-80.
Когда деревья были большими…. Точно надо было с С начинать, а не с Бейсика. (злая шутка)
Most data structures exist because of speed. For example, many languages today have both strings and lists. Semantically, strings are more or less a subset of lists in which the elements are characters. So why do you need a separate data type? You don't, really. Strings only exist for efficiency. But it's lame to clutter up the semantics of the language with hacks to make programs run faster. Having strings in a language seems to be a case of premature optimization.
«Most data structures exist because of speed.» -
Мне удобнее работать со структурированными данными. Автор настолько крут, что мыслит сразу в шестнадцатиричном коде. Ясно дело – ему структуры не нужны. (очень злая шутка)
Дальше в этом абзаце!!! не могу комментировать – уже разболелось сердце.
The right way to solve that problem, I think, is to separate the meaning of a program from the implementation details. Instead of having both lists and strings, have just lists, with some way to give the compiler optimization advice that will allow it to lay out strings as contiguous bytes if necessary
Да это прямо лисп-повец какой-то!!!
Ну, а про
some way to give the compiler optimization – это вообще изящно. Подумаешь, какая мелочь – просто
some way.
(1) the hundred-year language could, in principle, be designed today, and (2) such a language, if it existed, might be good to program in today. When you see these ideas laid out like that, it's hard not to think, why not try writing the hundred-year language now?
Рады стараться. Ух…
Мои соображения:
1) надо бы подумать о мотивации. А зачем? А почему язык XXI века должен быть каким-то особым?
2) какие задачи надобно решать? То, что не будет ситуации, когда присутствует только единственный язык (все языки ушли в небытие, остался один горемышный) – на мой взгляд, ясно. Надоб определиться о каких задачах, а значит и языковых средствах мы говорим. И это действительно посильно аналитикам уже сегодня (автор той статьи призывает начинать уже сегодня). Анализировать тенденции развития технологий, прогнозировать то, какие задачи появятся. Тогда аналитики могут сказать математикам и программистам – «копайте здесь».
3) профан или почто профан я в написании программ. В части написания языков программирования - вообще ничего не понимаю (примеры из книжек по С по написанию интерпретатора Бейсика – не в счёт). Однако думаю, что бОльшая роль будет математиков. Мы не знаем, какие будут носители информации. Мы не знаем, что можно будет складывать? Будет ли представление чисел только двоичным? Что можно будет легко хранить, извлекать, преобразовывать из запоминающих устройств – только числа или реализации неких абстракций.
4) спроектируют ли объектно-ориентированный язык, позволяющий реализовать объекно-ориентированный код? Да-да. Как известно, нет пока ещё ОО-кода и ООП существует только на стадии компиляции. В рантайм никаких объектов не существует. Есть отдельно сегмент кода, сегмент данных в которых «объекты» не живут. Живут vtbl, которые компилятор строит более или менее умно в зависимости от этих самых компиляторов. Если честно, я даже не знаю сейчас, надо ли это? Например, то что COM-подобные технологии, претендующие на "настоящие объекты" – вещь!!! (по крайней мере для меня) – это точно. Если это будет похожим образом реализовываться компилятором (т.е. в рантайме будут жить и размножаться объекты), может, это приоткроет пути решения многих задач (лёгкое мультипрограммирование, кросс-платформенность)?
Как думаете?
PS. Не судите меня строго. Смотрел вчера «Джуманджи» (хороший фильм). Отсюда и фантазии.
