Вы придираетесь к словам: <? — > в третьей версии заменили на <? — ?>.
Суть от этого не изменилась: PHP изначально был создан как язык инъекций в язык HTML, что было отражено в его названии (FI == Form Interpreter).
Синтаксис обёртки инъекций специально подбирался с тем, чтобы он не конфликтовал с нативным языком HTML. Видите ли, если вы будете выводить JPEG файл с инъекциями PHP или код C, как в предыдущем примере, вы не будете застрахованны от конфликтов синтаксиса вставок с синтаксисом аутпута между вставок:
никто не гарантирует в JPEG файле отсутствие возникновения последовательности <? (с произвольным набором байтов после этого и падением интерпретатора на них), как и отсутствие в программе на C строки
printf("<?%s","death of interpreter");
Тоже самое, впрочем, относится и к обычному тексту, не оформленному согласно правилам HTML разметки (XML появился несколько позже первой версии PHP/FI). Для того, чтобы инъекции PHP не конфликтовали с прочим контентом файла, если он не написан на HTML, необходимо было специально учитывать наличие вставок на PHP.
Теперь с удовольствием выслушаю ваши возражения насчёт исторического предназначения конструкции <? — ?> и её практического применения в настоящее время.
Историческое предназначение конструкции — переключение интерпретатора PHP в режим pass through
В PHP первых (да и вторых) версий данной конструкции не было.
Это раз. Два — где-то написано, что HTML — это часть PHP? Я ещё раз процитирую фразу:
Другой пример — это PHP, который делится на HTML часть (все *ML языки являются декларативными), описывающий структуру данных для визуализации, и PHP часть, предназначенную для описания действий по заполнению структуры данными.
Я, обычно, использую принцип оптимума Паретто по метрикам стоимость разработки, стоимость модификации для неимплементированных требований, частота изменения конфига, количество разных форматов конфигов и сложность изучения структуры конфигов.
Извините, а откуда появилось такое ощущение? Вроде бы я нигде не утверждал, что программирование на высокоуровневых языках — это плохо. Скорее даже наоборот — это позволяет писать код быстрее.
Но как теперь это соотносится с тем, что вся история ЯП — это синтаксический сахар?
Ну это же элементарно! Вначале фича появляется, как синтаксический сахар в языке, потом она реализуется как синтаксическая особенность языка более позднего поколения.
Когда появился первый ассемблер точно я не знаю, но вот Fortran и Ассемблеры долго считались конкурирующими подходами к программированию, пока транслятор фотран не уделал какой-то вручную написанный код по скорости выполнения программы.
Главное свойство регистра не то, что оно используется для хранения и обработки (перфокарта, или там магнитная лента, тоже могут использоваться), а то, что у него есть номер (или идентификатор), по которому к нему можно получить доступ
Собственно, а можно ссылку на определение, где явно указывается, что регистр должен быть именованным? И чем вам не нравится адресация по смещению от текущего положения в МТ?
mov RETHERE, FA[0]; RETHERE:
f: ...; jmp FA[0];
Ага, а теперь цепочку CALL с возвратом управления к вызывающему операнду. Собственно, к вопросу о стековом языке.
pop и push — это инструкции процессора, и это не синтаксических сахар, это изменение семантики ассемблера, который теперь умеет генерировать новый код
pop и push далеко не сразу стали инструкциями процессора, если вы посмотрите на первые машины в архитектуре фон Неймана, то там были регистры, была адресация памяти, но не было стеков. Pop и push появились, как инструкции процессоров в ответ на развитие языковых запросов программистов.
Бредите вы, потому что вы говорите, в тексте: «Всё началось».
Ок, ок — были машины и до Z3, были аналоговые компьютеры, не было разделения памяти и вычислений. В архитектуре фон Неймана всё началось с регистровых языков — такая формулировка вас устроит?
Если вы говорите о языках программирования, не ассемблерах, которые не считались языками, а назывались автокодами, то их история началась с Fortran и Lisp. Ассемблеры — это нечто посрединке всего этого праздника программирования.
Если не сложно, дайте, пожалуйста ссылку, что ассемблеры начались позже. По моим данным, фортран возник в 1954-57 годах как первый практический язык высокого уровня. Разработал язык IBM, он же и выпустил первый компилятор языка в машинные коды.
В котором прямо написано: вспомним машину Тьюринга, там регистры.
Тут я действительно не понимаю вашего возмущения. Регистр — последовательное логическое устройство, используемое для хранения символов и выполнения преобразований над ними. Частным случаем реализацией регистра можно считать ячейку ленты МТ в купе с записывающей головкой. Что не так?
И пишете: mov a, FA[1]; mov b, FA[2]; mov ..., FA[X].
Угу, а возврат из подпрограммы как реализуете? К вопросу о рекурсии, кстати, ага.
И при чём тут ссылка на стековые языки?
Стековый язык — это любой язык, использующий стеки для передачи данных в подпрограммы и возврата из них значений.
А причем тут незнание структуры конфига? конфиг, его структура может дополнять входные данные со всей метаинформацией до полного случая
Добавляя в программу конфиг мы добавляем в программу знание о его структуре. С этим утверждением вы согласны? Таким образом, добавляя конфиг мы неизбежно увеличиваем количество информации, которую нужно программе обработать.
Увеличение количества данных может привести к уменьшению правил преобразования. Пример я приводил выше.
Давайте разберём ваш пример:
Например имеем конечный ряд цифр ai, которые преобразуются в bi, по правилу f(a,i), но крайние элемент имеет исключение. При переходе к бесконечному ряду, правило сохраняется, но конечные исключения можно выкинуть.
Вы предлагаете инвариантное преобразование ряда, при котором удобство преобразования этого ряда повышается и правила преобразования можно записать в более лаконичной форме.
При этом вы выносите само инвариантное преобразование за пределы программы и, почему-то, не учитываете необходимость производства его с оригинальным источником данных. Тем не менее, если смотреть на программу, как на сумму функционала, приводящего данные ai в форму bi (и исключительно из этой фиксированной начальной формы в другую фиксированную конечную форму), то делая более удобной среднюю часть (преобразование) необходимо помнить о преобразовании ai в промежуточную форму (бесконечный ряд) и промежуточного результата (бесконечного ряда с исключениями) в bi.
Если осуществлять эти преобразования в нотации правил материнской программа, то сумма правил как минимум не уменьшится. Если вносить в программу конфиги, то отвественность за преобразование данных просто переложится на пользователя, заполняющего конфигами данные.
Суть от этого не изменилась: PHP изначально был создан как язык инъекций в язык HTML, что было отражено в его названии (FI == Form Interpreter).
Синтаксис обёртки инъекций специально подбирался с тем, чтобы он не конфликтовал с нативным языком HTML. Видите ли, если вы будете выводить JPEG файл с инъекциями PHP или код C, как в предыдущем примере, вы не будете застрахованны от конфликтов синтаксиса вставок с синтаксисом аутпута между вставок:
никто не гарантирует в JPEG файле отсутствие возникновения последовательности <? (с произвольным набором байтов после этого и падением интерпретатора на них), как и отсутствие в программе на C строки
Тоже самое, впрочем, относится и к обычному тексту, не оформленному согласно правилам HTML разметки (XML появился несколько позже первой версии PHP/FI). Для того, чтобы инъекции PHP не конфликтовали с прочим контентом файла, если он не написан на HTML, необходимо было специально учитывать наличие вставок на PHP.
Теперь с удовольствием выслушаю ваши возражения насчёт исторического предназначения конструкции <? — ?> и её практического применения в настоящее время.
Это раз. Два — где-то написано, что HTML — это часть PHP? Я ещё раз процитирую фразу:
m.facebook.com/story.php?story_fbid=3910662120875&id=1109015257&_ft_=fbid.3910662120875
«It has now evolved to the point where it is a simple programming language embedded inside HTML files.»
Вопросы?
Ну это же элементарно! Вначале фича появляется, как синтаксический сахар в языке, потом она реализуется как синтаксическая особенность языка более позднего поколения.
Язык регистровых машин
en.wikipedia.org/wiki/Assembly_language#Historical_perspective
en.wikipedia.org/wiki/FORTRAN_Assembly_Program#FORTRAN_assembly_program
ну и так далее.
Собственно, а можно ссылку на определение, где явно указывается, что регистр должен быть именованным? И чем вам не нравится адресация по смещению от текущего положения в МТ?
Ага, а теперь цепочку CALL с возвратом управления к вызывающему операнду. Собственно, к вопросу о стековом языке.
pop и push далеко не сразу стали инструкциями процессора, если вы посмотрите на первые машины в архитектуре фон Неймана, то там были регистры, была адресация памяти, но не было стеков. Pop и push появились, как инструкции процессоров в ответ на развитие языковых запросов программистов.
Ок, ок — были машины и до Z3, были аналоговые компьютеры, не было разделения памяти и вычислений. В архитектуре фон Неймана всё началось с регистровых языков — такая формулировка вас устроит?
Если не сложно, дайте, пожалуйста ссылку, что ассемблеры начались позже. По моим данным, фортран возник в 1954-57 годах как первый практический язык высокого уровня. Разработал язык IBM, он же и выпустил первый компилятор языка в машинные коды.
Тут я действительно не понимаю вашего возмущения. Регистр — последовательное логическое устройство, используемое для хранения символов и выполнения преобразований над ними. Частным случаем реализацией регистра можно считать ячейку ленты МТ в купе с записывающей головкой. Что не так?
Угу, а возврат из подпрограммы как реализуете? К вопросу о рекурсии, кстати, ага.
Стековый язык — это любой язык, использующий стеки для передачи данных в подпрограммы и возврата из них значений.
Добавляя в программу конфиг мы добавляем в программу знание о его структуре. С этим утверждением вы согласны? Таким образом, добавляя конфиг мы неизбежно увеличиваем количество информации, которую нужно программе обработать.
Давайте разберём ваш пример:
Вы предлагаете инвариантное преобразование ряда, при котором удобство преобразования этого ряда повышается и правила преобразования можно записать в более лаконичной форме.
При этом вы выносите само инвариантное преобразование за пределы программы и, почему-то, не учитываете необходимость производства его с оригинальным источником данных. Тем не менее, если смотреть на программу, как на сумму функционала, приводящего данные ai в форму bi (и исключительно из этой фиксированной начальной формы в другую фиксированную конечную форму), то делая более удобной среднюю часть (преобразование) необходимо помнить о преобразовании ai в промежуточную форму (бесконечный ряд) и промежуточного результата (бесконечного ряда с исключениями) в bi.
Если осуществлять эти преобразования в нотации правил материнской программа, то сумма правил как минимум не уменьшится. Если вносить в программу конфиги, то отвественность за преобразование данных просто переложится на пользователя, заполняющего конфигами данные.