bugmaker писал(а):
С - не может устареть. В своей нише ему пока замены нету. И наверное уже не будет. С++ из-за кучи врождённых дефектов никогда особо широко не использовался.
Ну-ну. Ассемблер, следуя этой логике, тоже не может устареть.
А то, что С++ никогда особо широко не использовался -- это просто замечательно
bugmaker писал(а):
Это всё есть уже в лиспе, которому от роду лет 50 наверное. Там кстати, есть и то, чего в перечисленных просто нету.
Ничто не ново под Луной. Ни
объекты в Лиспе, ни
контейнеры там же... Между прочим, утверждение касалось не новизны этих черт в истории программирования, а характерности их присутствия в современном языке. (Например, того, как развивались механизмы распределения памяти -- common в Фортране, controlled в PL/1, malloc() в С, new в С++, и сборка мусора сейчас.)
bugmaker писал(а):
А вот это есть только в самых примитивных навроде VB,..
Люблю снобизм! А между прочим, в ряде отношений VB был революционным решением, фактически установившим новый стандарт...
bugmaker писал(а):
Цитата:
В некотором смысле, начинается авторское манипулирование програмными объектами в момент разработки.
Эту мысль я несколько недопонял честно говоря... В любом случае, до окончания этапа разработки манипулировать чем-то - напрасная потеря времени. Можно "доманипулироваться" до того, что процесс разработки придётся начать заново.
Поясняю. Когда Вы задаете через IDE аттрибуты кнопки, Вы фактически конфигурируете программный объект времени выполнения программы. Он может быть статическим (если кнопка существует в одном экземпляре) или клонироваться (например, несколько экземпляров формы). Более того, многие из задаваемых характеристик могут модифицироваться на лету. И все вместе это чем-то напоминает self (язык программирования). Немного продолжая, можно представить себе подобное конфигурирование и других объектов в программе. Отчасти, и оно уже реализовано (например, такие contol'ы как таймер или БД).
bugmaker писал(а):
Цитата:
спросить систему разработки, как она поняла написанную (или, точнее, разработанную) программу
Это как? Программа в принципе не может допускать двоякого толкования. Несоответствие понятий машины и разработчика о том, что должна делать программа, выявляется в процессе отладки.
Ну, во-первых, до отладки еще дожить надо. А пока программа не компилируется, а компилятор выдает что-то нечленораздельное, лично мне очень хочется задать ему вопрос: "ну хорошо, объясни мне, как ты понял эту конструкцию? Что я имел в виду, я знаю, теперь скажи, как ты ее разобрал..." Например, это весьма актуально с мнгоуровневыми template'ами и передачей/переопределением типов. (И все это станет еще интереснее, когда мы начнем писать
auto ix = container.begin() )
bugmaker писал(а):
Извесно, в программировании не появилось ничего принципиально нового за последние 50-60 лет
Когда
известно, дальше не доказательно
. Можно пожелать Вам попис
ать даже не на Фортране, а хотя бы на Алголе-58.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Я тоже считаю перспективными направлениями функциональное программирование и метапрограммирование, включая смешанные вычисления, generics всех сортов и многое другое. Вам нравиться красить "мир людей в черно-белый цвет", развешивать ярлыки "модный" et cetera -- Бог с Вами. Я наблюдаю, как в удачных языках господствует смешение парадигм. Например, в Python немало элементов функционального стиля, и они все больше усиливаются. И это обогащает палитру программиста (по сравнению с чисто ОО языками вроде Ruby). Абстрагирование же не обязательно ведет к функциональному подходу, скорее generic / template программированию, позднему связвыанию (binding).
(Полнота lambda-исчисления, как и полнота машины Тьюринга не убеждают меня что за функциональным программрованием светлое будущее. Вопрос не в том, можно ли выразить, вопрос -- как удобно выражать. Я же по душевной простоте предпочитаю инфиксный + многоместной add(). А много ли Вы видели языков с правильно определенным сравнением? (
) И ведь встречается в жизни...)
В конце концов, ЯП -- всего лишь инструмент для решения задачи. Соответственно, он и выбирается под задачу. И одна из них -- увеличение читаемости, понятности программ. write-only languages типа Forth могут существовать в весьма узких экологических нишах, когда компактность и быстродействие важнее всего остального.Там -- они короли (в стране слепых и кривой король). Можно, наверное, сказать, что ЯП лишь зеркало, в котором мы хотим отразить предметную область.
С этой точки зрения становятся видны недостатки
чисто функционального подхода. Слишком уж во многих задачах мы имеем дело со структуризацией объекта (определеие К-алгебры или формального языка через грамматику тому пример). Но
строго объектная парадигма тоже не выход. Мы начинаем спотыкаться о нее как только нам нужно определить, скажем, групповую операцию -- вдруг выясняется, что инфикный плюс -- эта аттрибут пары, а совсем не одного из объектов, как учит Smalltalk. """Nothing is ever easy."""
![$\left[ {\begin{array}{*{20}c}
1 & 2 & 3 & 4 & 5 \\
6 & 7 & 8 & 9 & {10} \\
1 & 2 & 3 & 4 & 5 \\
6 & 7 & 8 & 9 & {10} \\
1 & 2 & 3 & 4 & 5 \\
\end{array} } \right]\left[ {\begin{array}{*{20}c}
1 & 2 \\
1 & 2 \\
1 & 2 \\
1 & 2 \\
1 & 2 \\
\end{array} } \right]$](https://dxdy-03.korotkov.co.uk/f/a/3/f/a3fd6698299ef48ec2ba95123ad4d2e282.png "$\left[ {\begin{array}{*{20}c}
1 & 2 & 3 & 4 & 5 \\
6 & 7 & 8 & 9 & {10} \\
1 & 2 & 3 & 4 & 5 \\
6 & 7 & 8 & 9 & {10} \\
1 & 2 & 3 & 4 & 5 \\
\end{array} } \right]\left[ {\begin{array}{*{20}c}
1 & 2 \\
1 & 2 \\
1 & 2 \\
1 & 2 \\
1 & 2 \\
\end{array} } \right]$")
. Результат транспонировать и каждый элемент разделить на сумму всех элементов, затем отобразить графически. Код можно записать в одну строку, но я нарисую в две:
