Изучаю Паскаль. Присоединяйтесь.

[yacc]

Вы рассматриваете какие-то простые случаи, когда для решения нужен массив и только.

Для решения вычислительных счетных задач этого достаточно.

Если счетную задачу писать в терминах классов типа TList то ее наглядность и простота сразу исчезает.

[neon]

А зачем интерпретатор паскаля ?
Скрипты лучше писать на Lua и движок тонкий.

Думаю, что это НЕ принципиально (какой именно синтаксис используется).
   1. "На вкус и цвет товарищей нет";
   2. Тема же - Pascal...  :-)  ;
   3. Во всем должен быть здравый смысл. Например, если на проекте используется Pascal (и среда Delphi), а также, ведется поиск Паскаль-программистов, то логично ориентироваться на интерпретатор Pascal.


Насчет Lua.

Lua (в диалекте LuaU) я использовал довольно много и часто (пока Роблокс не заблокировали) последние года 2-3, наверное.
Делал внуку и его одноклассникам различного рода соревновательные, виртуальные миры "познавательного характера" (типа: полоса препятствий на время прохождения).
Ну, там, например: "катапульта" (бросание тел под углом к горизонту) - надо попасть в мишень, задавая соотв параметры.
Посадка с орбиты на планету спасательной капсулы (в примитивном варианте, ест-нно) - надо НЕ разбить капсулу.
Взвешивание монет (с целью поиска фальшивки).
Разные викторины, прыжки на батутах (с учетом воздействия сил в разных градиентах).
И т.д.
Особенно, на период летних каникул.
Ясное дело, что за призы - дети же (в качестве призов - различные уникальные игровые поделки на микропроцессорах Arduino).
:-)

Что могу сказать. Я "думаю" на Pascal. И хотя очень часто и очень много приходится использовать разные языки, но я (поневоле) отношусь к ним предвзято НеПоОченьДоброму...  :-)
К LuaU - тоже. То есть, мое мнение здесь немного предвзято, наверное.

Но! Он (LuaU) очень гармонично встроен в саму среду Роблокс.
И его использование там, очень даже удобно (хотя там и нет ООП, но есть модульность, где можно эмулировать, в том числе, и ООП).
В общем, разработчики Roblox - "угадали" с Lua (как СОСТАВНОЙ частью своей Системы).

И даже есть DLL-ки (под Windows), где "упакован" интерпретатор Lua.

Но (по моему, сугубо личному делу) он очень слаб для решения серьезных задач.
С Паскалем даже и сравнивать нечего.

И, опять же (извините, но в качестве примера приведу AstrobloQ и FastScript).

Уж если нужно встраивать в AstrobloQ свой интерпретатор, то по всем "показателям" для этого лучше использовать FastScript.

Хотя бы потому, что он встраивается на уровне исходников (никаких DLL-к, DCU-шек и других "черных ящиков") и компилируется вместе со всем проектом в среде Delphi (как обычная библиотека с ПОЛНОСТЬЮ открытым исходным кодом).

И в FasctScript доступны 4 языка одновременно: Pascal, С++, jScript и VB.
И не нужно "заставлять" Пользователя выбирать какой-то один.
Вы можете, например, один скрипт написать на Pascal, а другой на С++.
И из скрипта С++ вызвать процедуру/функцию из Pascal-скрипта. И наоборот.
А можете, также, в Скрипте обратиться к какому-то своему функционалу в Delphi-проекте (и наоборот).
Это довольно гибко...
И, кстати, разработчик декларирует, что программист может самостоятельно добавить свой язык программирования, выполнив это по определенным правилам (но это уже довольно сложная задача, я попробовал, но у меня не пошло - здесь нужно глубокое понимание самой темы: ЯП и их создание).

Пиариться - это плохо (и даже, не прилично).
Поэтому, только в качестве аргумента...

Мне пришлось пройти путь от "Проминь-2" (где были штырьки).
Через Fortran; Basic; Ассемблер; Fort; Focal; Rebus (dBase, FoxPro); Pascal; Modula-2; C; SQL; 1C; PHP; jScript; Erlang; Lua.
Ну и слегка пощупал Python.

Некоторые (из выше перечисленного) я использовал профессионально и довольно плотно (вплоть, даже, до написания книги).
А некоторые - только в поисках "своего" языка.
Большинство из них я сейчас уже не смогу сходу и применить, пожалуй (надо книги поднимать и вспоминать).

В итоге - "думаю" я на Pascal.
А использую тот язык (или группу языков), который мне видится наиболее оптимальным для конкретного проекта.

УЯП`а пока что нет (и вряд ли будет при моей жизни, хотя, конечно, никогда не говори "никогда").

А один язык (на серьезном проекте) - не прокатывает.
Как минимум - два (Вы же сами их и указали ранее: SQL и еще какой-то).

[Vladimir3621]

При чем тут динамическое выделение памяти? Пишу медленно, жирным шрифтом: в TP5.5 динамических массивов не было.

Если есть динамическое выделение памяти, которое в стандартном паскале ОТСУТСТВУЕТ, то динамический массив для доступа и работы с ним организовать - можно.
Даже при отсутствии динамического массива как типа.


Turbo Vision использовал для динамического выделения указатели и те самые процедуры выделения и освобождения памяти.

Послушайте, гражданин, давайте вы сначала прочитаете те посты, на которые отвечаете, а потом постараетесь понять прочитанное? И только потом, тоже хорошо обдумав, напишете ответы. Еще раз: динамических массивов не было, работа с динамической памятью - была. Тот финт ушами, что вы выше упомянули, проистекающий из чьей-то тупости или необразованности, проистекал именно из-за отсутствия первого и незнания второго (или неумения им пользоваться). Все. Да, пряморукие и грамотные программисты запросто могли реализовать динамические массивы, связанные списки, очереди и все, что угодно, но только пряморукие и грамотные, т.к. "искаропки" этого всего не было. Возможность написать что-то вроде TByteArray = Array of Byte, а потом в процессе выполнения задавать нужный размер массива, появилась гораздо позже.

[yacc]

Да, пряморукие и грамотные программисты запросто могли реализовать динамические массивы, связанные списки, очереди и все, что угодно, но только пряморукие и грамотные, т.к. "искаропки" этого всего не было.

Еще раз - в классическом паскале ISO 7185  ОТСУТСТВУЕТ сама возможность динамического выделения памяти и средствами самого языка это сделать НЕВОЗМОЖНО. В стандартной библиотеке паскаля ISO 7185 это тоже - ОТСУТСТВУЕТ .
Не знаю, как "пряморукие" программисты напишут это выделение

А вот в ТP уже есть стандартная функция GetMem - т.е. никакие unit для нее не нужны как и для стандартной Length - это сразу в стандартной библиотеке.

[Vladimir3621]

О господи... А это-то тут причем? Вы же сами написали, что речь TP 5.5 идет. Вы еще про сортировку слиянием вспомните, которая была единственно доступной в ранних ЭВМ, а потом благополучно забыта как кошмарный сон. И еще. Вы правда не понимаете в чем разница между использованием динамических массивов и работой с динамическим выделением памяти?

[yacc]

Еще раз - для работы с динамическими данными достаточно динамического выделения памяти. Динамический массив как тип - не требуется.
Разница только в том, что по-обычному, как с типовым заранее выделенным массивом, с динамическим выделением памяти работать не получится, но само по себе работать с динамическими данным - получится.
Требуется в первую очередь именно работа с динамическими ДАННЫМИ.

[yacc]

Но (по моему, сугубо личному делу) он очень слаб для решения серьезных задач.
С Паскалем даже и сравнивать нечего.

А зачем программе сложный скриптовый язык ?
Писать программу на ООП да так, чтобы она еще и интерпретировала внутри себя скрипты на ООП - это скорее перебор, опять же усложняет разработку и тестирование, скажем в части наследования и перегрузки операций - зачем ?
Единицы, кому это почему-то реально нужно, ввиду самой сложной постановки задачи и требованию к тому, чтобы разработчики были квалифицированы - могут и сами скриптовой движок сделать в том синтаксисе, в каком нужно.
Ну или просто прикрутят, скажем Питон к программе на паскале.

[Vladimir3621]

Еще раз - для работы с динамическими данными достаточно динамического выделения памяти. Динамический массив как тип - не требуется.
Разница только в том, что по-обычному, как с типовым заранее выделенным массивом, с динамическим выделением памяти работать не получится, но само по себе работать с динамическими данным - получится.
Требуется в первую очередь именно работа с динамическими ДАННЫМИ.

Послушайте, перестаньте уже чушь писать - речь идет вообще о другом. Я вам про Ивана написал, а вы за мной гоняетесь уже битых два часа и зачем-то про болвана рассказываете. Причем, когда я вам пытаюсь объяснить, что мы про Ивана разговариваем, вы это игнорируете и с удвоенным напором про болвана дальше чешете. Не знаете, что такое динамические массивы, так и скажите, давно бы уже тему закрыли.

Динамический массив как тип - не требуется.

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

[yacc]

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

[Vladimir3621]

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

А, дядя Петя... Ну, тогда вопрос исчерпан, конечно. Мде, а я-то тут как со знающим общаюсь

ЗЫ
Тем, кто действительно желает хорошо владеть паскалем, особенно его подмножествами, пошедшими от OP, но не знает про динамические массивы, рекомендую ознакомится например с этим - https://freepascal.ru/download/book/doc_ref/index.html?dynamicarrays.html

[yacc]

Я в курсе что есть динамические массивы и очень хорошо знаю, что в 90-х их в TP не было.
Что абсолютно не мешало работать с динамическими данными. В том числе в Turbo Vision в версии TP6, в которой этих самых динамических массивов тупо не было.

[Vladimir3621]

Я в курсе что есть динамические массивы и очень хорошо знаю, что в 90-х их в TP не было.
Что абсолютно не мешало работать с динамическими данными. В том числе в Turbo Vision в версии TP6, в которой этих самых динамических массивов тупо не было.

Дааааа? Я кому выше писал, что их до BP7 включительно не было? Видимо Павлу с neon'ом А это кто написал:

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

Не, наверное не вы Динамические массивы в OP появились начиная с Delphi чуть ли не 5 версии, в 7 точно были Во Free Pascal, как видите примерно тогда же: в версии 1.1 они уже присутствуют и вовсю поддерживаются компилятором

[yacc]

Не, наверное не вы

Не я.
Мне дельфи неинтересна.
Я уже выше писал что из Виртовоского наследия мне интересен только Оберон.

[Vladimir3621]

Ну да, конечно, мы это уже поняли

[neon]

А зачем программе сложный скриптовый язык ?

Вопрос - отличный и очень интересный.
Чтобы на него ответить аргументированно -  лучше всего использовать конкретный, иллюстрирующий пример.
Но там будет "много" иллюстраций и слов" (относительно, конечно, но для формата форума - уж точно).

Давайте сделаем так.
Чтобы не "дробить" и "не засорять" форум я подумаю.
Сформирую документ в PDF-формате, выложу его в свое облако.
И сюда скину ссылку.

А вот вопросы/ответы и конструктивные критику/предложения - уже можно сделать и здесь.
На форуме.

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

В общем - я озадачился...
:-)

[yacc]

Но там будет "много" иллюстраций и слов" (относительно, конечно, но для формата форума - уж точно).

Для задачи, что у вас стоит, понятно почему - pdf я смотрел.
Вопрос был скорее - зачем остальным разработчикам ПО в других сферах ?

[neon]

Вопрос был скорее - зачем остальным разработчикам ПО в других сферах ?

Ну, тогда давайте так.
Я здесь вкратце напишу.
И если этого будет достаточно, чтобы понять, то и еще лучше (не придется мне тратить доп. время).

Предположим, у Вас (как Пользователя) есть некая Система (неважно, как она реализована, для Вас - это черный ящик).
Откуда-то она у Вас появилась. У Вас есть достаточно подробная документация по ней.
Кто ее разработчик, существует ли еще этот разработчик - неизвестно (да для Вас это и не интересно)

У Вас появилась задача: сделать, например, Склад.
Вы берете документацию (по Системе).
И в терминах этой задачи (склад) ИНТЕРАКТИВНО (в терминах предметной области) создаете там соответствующую информационную модель.
Я не спец по складам...
Но допустим, что там есть такие объекты типа: "Помещения", "Стеллажи", "Полки", "Ящички", "Бирочки" и т.д.
Каждый из этих типов имеет свойства, ест-нно.
И какие-то (если грубо) методы - это я уже - в привычных для программистов терминах ООП (это не совсем корректно, но приемлемо).
Более того, они как-то между собой взаимодействуют (если упала полка, то упали и ящики, если стеллаж переместили, то все, что внутри "переехало", а что-то упало и "разбилось" - мало ли).

Ну так вот.
Вы создаете (в терминах предметной области) ИНТЕРАКТИВНО соответствующую информационную модель этого Склада.
Затем, создаете (опять же интерактивно) соответствующие события (в терминах, которые Вам, как пользователю, понятны).
И... для каждого события пишете соответствующий скрипт (который будет исполняться, "когда надо").
Кроме событий, могут потребоваться различного рода выборки, отчеты и т.д.
И Вы их тоже создаете.
Далее, если в процессе эксплуатации что-то меняется, Вы легко Ваше прикладное решение адаптируете под новые условия (разработчик Системы Вам не нужен).

------------
Теперь.
У Вас появилась задача: "Учет продуктивных интервалов на месторождении с целью учета запасов сырья. С учетом перетоков, различного рода воздействий для интенсификации добычи и самой добычи, а также естественной миграции флюидов и т.д. - там много, чего".
К "Складу" эта задача никакого отношения не имеет (там все намного сложнее)...
Но Вы прекрасно знаете эту предметную область
Ну, Вы просто в этой же адаптивной ИС выполняете такие же действия, как и со "Складом".
И все дела.

Ну и т.д. (в идеальном случае - без каких-либо ограничений).

Предусмотреть ВСЕ ЭТО заранее разработчики такой адаптивной ИС не могут в принципе (по определению).
А значит, и соответствующую обработку НеИзвестноКакихОбъектов с НеИзвестноКакимиСвойствами и НеИзвестноПоКакимАлгоритмам они тоже не могут.
Вот здесь без встроенного интерпретатора скриптов - не обойтись.

Полезно это? Безусловно.
Нужно ли это?
Да вот, кто его знает... Тут уж "на вкус и цвет товарищей нет" .
Как говорят (иной раз): "ну, если я все сделаю сразу хорошо и ничего не будет ломаться, то за что же я зарплату потом получать буду?"
:-)


Продолжение ниже.

[neon]

Продолжение.

А теперь, представим, что Разработчик - не одиночка.
А фирма (которая разработала такую ИС).

Но ведь она (в своем составе) может содержать Аналитиков, работа которых будет заключаться в создании ПРИКЛАДНОГО решения для задачи, поставленной Заказчиком.
Система-то уже есть.

Для Заказчика - она "черный ящик".
Да Заказчика она (сама по себе) и не интересна.
Ему, главное, чтобы все работало так, как ему надо.
А если что-то поменялось (у него), то все требуемые изменения максимально оперативно и максимально дешево были внесены в ЕГО ПРИКЛАДНОЕ решение.
Но интерактивно изменить ИнформМодель и какое-то кол-во скриптов - все ж таки проще и для Подрядчика.
Ну, а это уже: цена, время, престиж и т.д.

Т.е., Разработчик адаптивной ИС использует СВОЮ Систему, как инструмент для разработки ПРИКЛАДНЫХ решений для Заказчиков.
А поскольку жизнь на месте не стоИт, то программисты Разработчика могут спокойно и без аврала УЛУЧШАТЬ СВОЮ Систему.
Ну а ее применение (создание и сопровождение прикладных решений) - это уже дело аналитиков (внедренцев).

Ну, вот, примерно так...

Выгодно (экономичеки) для всех?
Несомненно.
Трудно все создать и выстроить?
Ну уж далеко не легко - это уж точно.

Но... У каждого свои предпочтения.

==========

Если этого достаточно, то я (к моему счастью) тратить время на "иллюстрирование" не буду.
:-)

[yacc]

Предусмотреть ВСЕ ЭТО заранее разработчики такой адаптивной ИС не могут в принципе (по определению).
А значит, и соответствующую обработку НеИзвестноКакихОбъектов с НеИзвестноКакимиСвойствами и НеИзвестноПоКакимАлгоритмам они тоже не могут.
Вот здесь без встроенного интерпретатора скриптов - не обойтись.

Если данные хранятся в СУБД, а так зачастую и делают, то система, вероятно, расширяема без ООП скриптового языка.

А если не в базе, то и просто скриптов может быть недостаточно. Я приводил пример выше PSS vs Siril. Полагаю, что даже добавить API плагинов чтобы их вообще можно было использовать - а если он есть, то можно и скриптом вызывать - не так уж просто, если архитектура изначально монолитная и не предназначена для такого гибкого применения. Придется много переписывать.

К приложениям на Паскале это тоже относится.

[neon]

Если данные хранятся в СУБД, а так зачастую и делают, то система, вероятно, расширяема без ООП скриптового языка.

Это уже - вопросы технической реализации.
Подходы есть разные...
Кто-то это делает через МИВАРы.
А кто-то по другому.
Это уже (в концептуальном плане) - не так уж и важно...