Базовый Дзен

в 13:07, , рубрики: s-basic, дзен, Программирование

Насколько я могу судить, по статистике многие пишут свою первую статью по принципу «я-то знаю как правильно жить», а те, кто поопытнее — с позиции «ух-ты, смотрите, что я тут накопал». В общем — постараюсь не сильно портить статистику.

Я хочу просто оставить маленькую пометку на полях: вы все правы. Но, зачастую, этого никто не замечает. Но так как пост в одну строчку слишком мал, то придётся его немного развернуть.

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

Дзен достигается в тот момент, когда язык становится частью сознания, когда мысль может течь так же, как и логика языка. Впрочем, было бы самонадеянно говорить, что это «42», всё-таки мой опыт — это Q-basic, S-basic, C# (понюхал), PHP, SQL — в хронологическом порядке, так что сужу я всё-таки со своей колокольни.

Если можете описать лучше — буду рад прочитать.

SQL — прямолежная система. Минимум циклов, прямое выражение мысли, грабли прямо под ковриком.
C# — взаимодействие с системой, которое мне показалось похожим на море, из которого выпрыгивают киты, где море — это окружение, а выныривающие киты — используемые ресурсы.
PHP — песочница, наполенная железным конструктором, с розеткой.
Basic (истинный) — «всё есть массив, а что не массив — адресация в (массиве) памяти».
Basic (все, что не требуют писать номер строки) — суть то же, что и ПХП.

И, в целом, обычный холивар зачинается именно из-за того, что решение в целом адекватно, но дзен решения не соответствует тому, который подходит автору негативного комментария.

Так что, прежде чем сказать «что за хрень», сначала я себя спрашиваю: «а почему так?». И иногда — я не могу сказать ничего плохого, ведь если средства языка или конкретной программы предполагают иной дзен — то моё восприятие уже не является корректным.

Взаимоисключающие параграфы

Однако, так как над проектом работают разные люди, в нём могут и должны появиться элементы не сооблюдающие единый стиль. Пример — версии HTML, который от простого языка разметки изменился (эволюционировал/деградировал) в интересную смесь из CSS и внутренних элементов с различным содержанием. В целом, лично меня корёжит вместо

<br>

писать

<br />

так как кроме случая автозамены в IDE это не даёт решительно ничего, а дзен изначального HTML в лично моём понимании — ломает.

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

Но, повторюсь, судья из меня никакой, это больше наблюдение. И, скорее всего, как минимум в чём-то я ошибаюсь.

Базовый дзен

И, как я говорил выше, согласно статистике, большинство начинающих авторов пишут в духе «я знаю лучше» и обещал не сильно портить статистику. Ну так вот…

Во многих книгах по программированию писалось: «при нумерации строк указывайте номера с шагом не в 1, а в 10 — так будет легче редактировать листинг».

Но почему именно так?

Загадка: «какой размер карты в первых Сим-Сити и Цивилизации и ограничение VB-скрипта в современном Excel?»

Ответ:
100х100, 50х200, 10000.

В чём смысл:
Максимальный номер строки в ZX-Spectrum так же 10000, при этом можно запихать и 0-строку, т.е. 10001 элемент. То есть: ограничение выставлено вручную.

То есть: номера строк в истинном Бейсике — это позиции элементов массива. Как и карта в Цивилизации.

Что это даёт? В целом ничего, кроме мироощущения: всё стоит строго на своём месте. Если нужно изменить работу программы — можно заменить (а-ля include) какой-нибудь элемент массива и не перезагружать всю программу. С другой же стороны, это приучает воспринимать программу как единую структуру, у каждого из модулей которой есть определённое твёрдое место в реальности, определяемое даже не функциональностью, а непосредственно смыслом.

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

Возвращаясь к рекомендации писать номера строк «через 10».

С опытом мне пришлось по душе несколько иное нумерование: x000 — глава программы, x00 — часть, x0 — блок инструкций, х — элемент. При этом: 0 — REM (описание блока); 1, 5 или 1,3,5,7,9 — IF; 1, 2, 4..8 — линейные элементы.

Таким образом, возьмём рандомный номер строки:

  • «4208», т.е. 4-2-0-8, т.е. 4 глава, 2-я часть, 0-блок (ага, описание), 8 строка (последовательная, скорее всего — описание 2-го блока, а то и багрекинг).
  • «3586», т.е. 3-5-8-6, т.е. 3 глава, 5-я часть, 8-блок, 6 строка (последовательная, скорее всего — инструкиця, комментарий лежит в строке «ххх0», т.е. «3580»).
  • «2145», т.е. 2-1-4-5, т.е. 2 глава, 1 чать, 4 блок, 5 строка (возможен блок IF! Комментарий в строке «ххх0», т.е. «2140».)

Архитектура моего кода в таких условиях была такова: блок инициализации -> главный цикл -> выбор нужного блока -> запрос нужных действий -> возврат указателя в цикл. Таким образом, часть «20хх» зачастую являлась «субциклом», который перенаправлял указатель на «2х00» или «2хх0», в зависимости от детализации. Строка 2хх9 — RETURN.

Но тут одна маленькая проблема.

Эта система (на ZX-Spectrum 48k) не воспринимала перевод строки и написать блок кода внутри строки было невозможно. Что и поставило крест на подобной гибридной схеме среды программирования, когда БД встроена в движок программы, а сама программа изначально преставляет собой эдакую маленькую ОС, где блоки кода — приложения. Что мне, как последнему из Могикан, несколько грустно и обидно.

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

Скрещивая ежа с ужом

Как же это можно использовать сейчас, на том же PHP?

Во-первых, я обожаю массивы. Мне нравится знать где какое значение может находиться. А с учётом плавающих глюков хостера и отсутствия доступа на боевой сервер — это единственный (как мне понимается) способ разнести ради тестируемости элементы программы, обеспечить удобство разжучкования (дебага), хотя и жертвуя памятью в значительной степени.

Во-вторых, был найден простейший способ сделать код удобным для навигации: брекеты с комментарием в «нулевой» строке. Сворачиваясь, они создают приятную глазу структуру, давно знакомую и привычную мне композицию, где первой строкой идёт комментарий к блоку, а затем — инструкции. По нажатию alt+0 код превращается в почти что вики-страничку, где долистав до нужного коммента можно прочитать нужный кусочек кода.

Повторюсь: это замедляет выполнение программы. Но ведь за всё надо чем-то платить, а контроль всегда порождает бюрократию.

Да, я ретроград и не собираюсь отказываться от привычек до тех пор, пока они помогают мне. И я не говорю что это — правильно, я просто говорю, что это работает. И, ИМХО, люди недооценили те возможности, которые им давал истинный Бейсик, а поддавшись тлетворному влиянию более примитивных языков оставили самый болезненный минус (размер массива), убрав главную особенность («всё есть массив!»).

А язык без собственного дзена — как китайские воздушные шарики.

Автор: Wano987

Источник

Поделиться новостью

* - обязательные к заполнению поля