>> a) существуют ли языки позволяющие:
>> 1) для класса/функции/участка нити алгоритма указывать какая требуется оптимизация ?
> Можно костылями - для каждого .o свои ключи оптимизации указывать. На уровне
> языка - это не совсем его задача, тут разве что кейворды
> типа inline..o это слишком глобально, у моего вопроса уши растут из "почему ассемблерные вставки до сих пор повышают производительность?" ибо по факту асм-вставка и есть прямое указание компилятору "как оптимизировать этот кусок" в виде "ничего не трогай, просто перепиши как тут буква в букву"
>> 2) для функции указать компилятору при каких ограничениях входных значений функция быстра
>> или указать что работает как o(f(n)) или сам компилятор способен ли
>> это определить ?
> Сам определить? Такие требования скорее для ИИ, а его нет. А учет
> в алгоритме, при каких параметрах функция быстра - собственно, и есть
> работа программиста. Чем-то отдаленно напоминающее есть в функциональных языков (задание
> функций по входным значениям), например, в Haskell
в математике теория алгоритмов весьма же развита, из программы часто можно построить её граф выполнения, можно оценить трудозатраты на выполнение участка графа (это к вопросу об ИИ компилятора)
работа программиста - перевод ТЗ заказчика с русского на язык понятный компьютору, чтоб он по этому ТЗ мог выдать результат в понимаемом заказчиком виде
выбор же варианта алгоритма под конкретную задачу не сложнее тупого перебора всех возможных вариантов алгоритмов решающих конкретную задачу с учётом нужных условий
а вот на сколько хорош алгоритм и в каких условиях - этим занимается математика (а не программист, если говорить по серьёзному)
но не существует в математике готовых алгоритмов на все случаи жизни, только поэтому программист не является совсем ремесленником а таки и творцом нового - учёным-математиком, создаёт новый алгоритм по "переводу тыканья мышкой клавиш в годовой отчёт с графиками"
однако алгоритмы сортировки массива созданы и детально разобраны математиками и по факту программисту остаётся только выбрать лучший для его задачи - а это работа "ремесленника" которую способен осуществить компьютор (хотяб методом тупого перебора всех возможных вариантов алгоритма сортировки), но компьютор не в состоянии выбрать "предпочтения" которые может иметь программист в своём глобальном алгоритме "годового отчёта"
>> 3) в объектной модели при создании объектов использовать интерфейс (а не непосредственно
>> класс) с указанием компилятору требований необходимой реализации чтоб сам компилятор выбрал
>> из наличествующих реализаций конкретный класс под требования ?
> Это как? Сам пошел в аналог CPAN и скачал нужные модули? =)
> Вообще всё сообщение по требованиям смахивает на кнопку "сделайте мне хорошо"
> (т.е. работу за меня).
почти - посмотрел все инклуды (инклуды модулей, неймспейсов, аль ещё какие) - нашёл все реализации требуемого интерфейса и выбрал нужный основываясь на пожеланиях указаных программистом
это вполне рабочая кнопка "сделать мне хорошо" - такая же как современное автодополнение в ИДЕ
>> b) отдельно - есть ли языки программирования с "алгоритмическим" (типо блоксхемно-описательным)
>> стилем ?
> Вообще-то все попытки создать такое провалились. Известный пример - UML. Ну и
> правильно - мышление должно быть текстовым.
на сколько я понял UML по факту не предназначен именно для программирования
я вобще тут подумал-прикинул - для любого языка можно сделать прямое отображение код-блоксхема и блоксхема-код, всё упирается в наличие готового инструмента и качество кодогенератора из блоксхемного описания
тут уже встал вопрос - почему компиляторы не переводят программы в алгоритмическое описание (точнее почему это описание не является каноническим "исходным кодом" для последующей оптимизации и кодогенерации для всяких llvm)
и с какого перепуга мышление должно быть текстовым ? графическую информацию об общем виде гораздо проще воспринимать и передавать чем в текстовом
потому же кстати и существуют графические конфигурялки что в них можно "окинуть взглядом" сразу большую часть картины и при этом не обязательно вникать и переводить символьную информацию в понимание
текстовой формат удобен для формального описания формальных признаков - конкретики
кстати если требуется описать конкретный стол - фотография куда лучше подойдёт для этих целей, но если требуется указать "просто стол" или "класс столов" то тут текстовой путь куда короче - "письменный стол" или "парта со скошеной столешницей"
