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

[Павел Васильев]

Кому надо быстро формочки наделать - то для такой RADости есть дельфи.

Быстро формочки говорите? Без контролов в простеньких прогах модальные и немодальные формы можно быстро насоздавать, да, но в  специальном софте обычно разработка GUI  часто является наиболее сложным делом, поскольку математика подключается из уже  созданных надёжных либ. Вы как рекомендуете на хвалёном вами Обероне создавать сложные MainMenu с иконками и разными стилями интерфейса (например, c тёмной темой) , многочисленными стандартными диалогами Open/Save файлов разных форматов, с деревьями просмотра типа TTreeView, готовыми компонентами драйверов к 32 типам баз данных и т.д.и т.п. И это всё на формочках. Возможно вы этим всем владеете, но в Обероне этого ничего нет или есть убогое подобие VCL. Чтобы освоить основные методы создания GUI на Delphi нужны годы, а к тому же появляются постоянно новые пакеты компонентов, напрмер, для работы с вебом или 3д графикой. Так что ваш Оберон или что вы там ещё советуете, это, мягко выражаясь, грубо говоря, бесполезное занятие.

[yacc]

Вы как рекомендуете на хвалёном вами Обероне создавать сложные MainMenu с иконками

Я и не предлагаю - для этого дельфи есть.

Так что ваш Оберон или что вы там ещё советуете, это, мягко выражаясь, грубо говоря, бесполезное занятие.

Вы точно прочитали что я про него сказал ?

многочисленными стандартными диалогами Open/Save файлов разных форматов, с деревьями просмотра типа TTreeView,

Давайте я вас удивлю - все это делается ... на WinAPI поэтому что эти компоненты - системные - что диалоги открытия/сохранения, что TreeView что развернутые меню.

[CyberManiac]

Вы как рекомендуете на хвалёном вами Обероне создавать сложные MainMenu

Тем, кто создаёт MainMenu в третьем десятилетии третьего тысячелетия, нужно дюбель в голову забивать. Топором. Лезвием топора. И пару раз обязательно промахнуться. Потому что на нубуке с тачпадом раскрыть ублюдочную менюшечку, дойти до третьего уровня вложенности и не пожелать аффтару менюшечки подохнуть в жутких мучения - это нужно быть йогом 80-го уровня.

[Павел Васильев]

Потому что на нубуке с тачпадом

А многие ли программисты, да и юзеры, пользуются тачпадом? Гораздо удобней на большом экране работать с мышкой и клавой, на что и рассчитаны гуи тех же оффисных десктопных программ разработчиков Майкрософт. Им вбивайте дюбеля. Во-вторых, для плоховидящих и слабозрячих владельцев смартфонов есть другие готовые шаблоны GUI, под стандарты экранов. Или можете слелать огромные значки или  ряд TImages в TActionMenuBand, да или просто на топ панели, брошенной на форму. Вариантов много, всё зависит от того что вы собираетесь создавать, примитивную но полезную утилиту или бесполезную  программу со сложным взаимодействием кибер маньяка с компом. Это надо понимать.

[Vladimir3621]

Чтобы освоить основные методы создания GUI на Delphi нужны годы

Вы это сейчас серьезно или гипербола? Основной метод создания GUI в Delphi один - перетащить и бросить

[CyberManiac]

Потому что на нубуке с тачпадом

А многие ли программисты, да и юзеры, пользуются тачпадом? Гораздо удобней на большом экране работать с мышкой и клавой, на что и рассчитаны гуи тех же оффисных десктопных программ

Если программист диктует мне, что ради его поделки я должен купить отдельный компьютер со всеми его хотелками - нехай идёт на северный сексуальный полюс и там героически погибнет.

[Павел Васильев]

Если программист диктует мне, что ради его поделки я должен купить отдельный компьютер со всеми его хотелками - нехай идёт на северный сексуальный полюс и там героически погибнет.

Обычно программисты, в софтверной компании, создают продукты с прицелом на рынок пользователей и для наиболее распространённой ОС, каковой в настоящий момент для настольных компьютеров является Windоws, с большим отрывом от прочих операционных систем. Так что моду на интерфейсные морды, в переводе на русский GUI, задаёт компания Microsoft. Вы конечно можете их послать на полюс и перейти на Линух, но там в целом всё гораздо хуже и ассортимент программ гораздо беднее.

[CyberManiac]

Если программист диктует мне, что ради его поделки я должен купить отдельный компьютер со всеми его хотелками - нехай идёт на северный сексуальный полюс и там героически погибнет.

Обычно программисты, в софтверной компании, создают продукты с прицелом на рынок пользователей и для наиболее распространённой ОС, каковой в настоящий момент для настольных компьютеров является Windоws, с большим отрывом от прочих операционных систем. Так что моду на интерфейсные морды, в переводе на русский GUI, задаёт компания Microsoft.

А до Микрософта, внезапно, это ещё лет 10 назад дошло. У них везде сплошной Ribbon и никаких многоуровневых меню. А провальный MDI они уже четверть века, как закопали.

Вы конечно можете их послать на полюс и перейти на Линух

Членукс не нужен.

[Павел Васильев]

У них везде сплошной Ribbon и никаких многоуровневых меню

Опять же как раз в  Ribbon  и есть сложные многоуровневые меню, почитайте отзывы по запросу "недостатки интерфейса Ribbon". Я сам когда-то пробовал им воспользоваться в своём проекте. Взял на Github его точную реализацию  на Delphi. Но потом выкинул по причине чрезмерной и ненужной сложности поддержки. Классический Gui и меню со значками для мышки и быстрыми клавишами удобней. В дизайне не надо много уровней лепить, действуй по предлагаемому в IDE шаблону и всё будет понятно. Кстати, в VStudio, VS Code и Rad Studio нет никаких ribbons.

[Vladimir3621]

Вы конечно можете их послать на полюс и перейти на Линух, но там в целом всё гораздо хуже

Это точно. Вышеупомянутая проблема с SentenceTransformer, как оказалось, была вызвана тем, что когда-то в винде было известно как dll-hell, который к настоящему моменту в ней довольно успешно победили. А в убунте с питоном он живет и процветает. На сервере вместо библиотеки transformers 4.57.1 оказалась установлена 4.57.3 и понеслась душа в рай.

[neon]

go6poro BPEMEHu cyTOK.

Приношу извинения (т.е., понимаю, что "в чужой монастырь со свои уставом не ходят").
Не в моих правилах "навязываться". Но "Сократ/Платон мне друг, но истина дороже".
И, кроме того, уж коль скоро эта тема все еще НЕ в архиве (не закрыта для комментов), то ее потенциал, думается, не исчерпан.


Цитирую (от 16 Дек 2022 [12:29:05]):
==========
При подготовке к действу было скачено много материалов, отрыто приличное колличество полезных ресурсов. Ввиду возраста самого языка вызвало удивление множество учебных пособий по Паскалю. Даже выяснилось, что проводятся Олимпиады для школьников по нему.
Я не знаю, что получится из этой затеи и получится ли, вообще.
Время покажет.
Тем, кто считает, что это глупая затея и пустая трата времени, просьба не писать здесь. Я буду просить модераторов удалять сразу весь офтоп.
==========

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

Ясное дело, что во всем должен быть баланс: "Затрачиваемые ресурсы и получаемый результат".
Но это уж - личное дело каждого (кто и чего хочет и может - в плане своих временнЫх ресурсов).
Думаю, что в этом вопросе нет (да и не может быть) одного рецепта для "всех и каждого".

Но тем не менее считаю, что совсем не так уж и плохо - формировать/адаптировать "инструментальное окружение" под себя, если есть такая возможность.

И вот в плане создания своего собственного интерпретатора (в контексте синтаксисов: Pascal, C++, VB и jScript и все в "одном флаконе") - сейчас, как раз, достаточно легко и быстро реализуемо.
Ну, для иллюстрации.
Тот, кто имеет БАЗОВЫЕ навыки работы в среде Embarcadero RAD Studio (Delphi), имеет возможность легко создать (начальная, но полноценная заготовка для дальнейшего ее развития) СВОЙ полноценный интепретатор.
По времени. Если в первый раз, то часов за 5-8. Если опыт (этого) уже есть, то на спор - за час/два.

И, кстати, о GUI.
Использовать Delphi для создания GUI-форм (а это далеко не худший вариант), а затем - их вызов из СВОЕГО интерпретатора (с назначением соответствующих обработчков событий,  в рамках заданной логики и в СВОЕМ интерпретаторе) - тоже далеко НЕ СверхЗадача (сам начал это использовать еще лет 15 назад, если не раньше, во-всяком случае, еще в Delphi-5).
Хотя, конечно, здесь требуется уже более высокий уровень знаний среды разработки, чем "базовый".

............................
Поэтому (извините за повтор), еще раз - не с целью НАВЯЗЫВАНИЯ "кому-то и чего-то".
А с целью: вдруг кому-то пригодится.
Пакет компонентов для Delphi:  FastScript.
Это, кстати, отечественная разработка. Платная (но по цене вполне доступная) и поставляется на 100% с исходниками.

Вот ссылка:
https://xn--90aia9aifhdb2cxbdg.xn--p1ai/products/fast-script

Может кому-то и потребуется, мало ли (жизнь на месте не стоИт).

Еще раз - извините
............................


--------------
C yBa}I{eHueM, bI (c) "Кин-Дза-Дза", "Race name in Galaxy PLUS"

[yacc]

Компилятор, фактически с исходниками, есть сразу в поставке Оберона.
Плюс много исходников других модулей.

[Павел Васильев]

А с целью: вдруг кому-то пригодится.
Пакет компонентов для Delphi:  FastScript.
Это, кстати, отечественная разработка. Платная (но по цене вполне доступная) и поставляется на 100% с исходниками.

Сама мысль создать что-то своё, отечественное, в виде интерпретатора языка Паскаль вполне здравая, хотя есть уже паскалевские скрипты, тот же DWS. А у вас ещё и платный пакет. Куда ставить, в Delphi Rad Studio? Кому-то это может и подойдёт, но это не радикальное решение. С нуля начинать желающих мало, у людей тысячи проектов и миллионы строк кода библиотек. Конвертор обеспечите без лишних глюков? Вряд ли ИИ поможет в этом деле.

[neon]

1. По поводу вот этого: "А у вас ещё и платный пакет" и вот этого "Конвертор обеспечите без лишних глюков?"
Прошу все в одну кучу не мешать.  :-)
Я - НЕ разработчик FastScript.
И вообще к ним имею отношение только, как пользователь (купивший у них этот пакет компонентов).

2. По поводу этого: "С нуля начинать желающих мало, у людей тысячи проектов и миллионы строк кода библиотек.".
Полностью согласен.
Но... Когда-то был SuperCalc (кто еще помнит). А потом появился Excel и... все перешли на Excel. И никаких конверторов не было...
А в SuperCalc`е была куча прикладных задач (в множестве прикладных областей).
И перешли...

3. "Кто хочет, тот ищет средства. А кто не хочет - причины" (не помню уже, чьи слова).

Т.е., жизнь идет свои чередом.
И не мы ей диктуем, а она нам.

Поэтому: "на вкус и цвет - товарищей нет" - это в контексте того, что у каждого свои задачи, предпочтения и возможности.
Каждый выбирает себе сам.
Тут уж - что скажешь. Каждый решает сам.

Еще раз подчеркну, что я свой коммент здесь создал только в рамках первоначального определения тематики этой ветки форума.
И не более.

Если тема себя уже исчерпала или трансформировалась. То, что ж.
Значит, мои комменты здесь избыточны.

Так что - прошу (опять же) не интерпретировать мои комменты, как призывы к чему-то.
А лишь - "к сведению"

[neon]

Сказавши "А" ... придется сказать и "Б" (раз уж замутил)...
Вот если у кого-то есть/будут ТЕХНИЧЕСКИЕ вопросы и я буду способен на них ответить.
То буду рад (делиться - дело святое)

[neon]

Вот этот вопрос пропустил, извините: "Куда ставить, в Delphi Rad Studio?".

Delphi Rad Studio - это среда разработки.
Ест-нно, что все компоненты (в том числе и FastScript)  устанавливаются в среду.
И разработка СВОЕГО интерпретатора ведется тоже в этой среде.

Но результат (после компиляции исходного кода) - отдельный (полностью автономный) "голый" EXE-модуль (это, если под Windows).
Он не требует НИЧЕГО дополнительного. И не требует установки, ясное дело.
Лично я свой интерпретатор ношу на флешке (чтоб на любом компе под Windows можно было запустить и использовать).

Скрипты - обычные файлы в текстовом формате (по умолчанию), если Вы сами не приложите много усилий, чтобы хранить их в другом формате.
Но лично я (последняя буква в алфавите), если делаю адаптивную ИС (опять же,  под свои задачи), то храню скрипты, также, в виде объектов БД (текстовое поле).
Это для того, чтобы оперативно менять логику обработки данных, хранящихся в ИС (не ковырять очередной раз весь проект, не переписывать исходники и не компилировать исходный текст в исполняемый модуль).

Использую (в этом случае), как правило, postgresql (если "полноценная" БД).
А если локальная (для хранения и обработки каких-то моих данных), то SQLite.

Но я "живу в Windows". Разработчик декларирует, что все корректно и для Lazarus.
Но я не пробовал.

[peg59]

Вот если у кого-то есть/будут ТЕХНИЧЕСКИЕ вопросы и я буду способен на них ответить.

А зачем Паскаль? Он ведь уже есть. Тем более, интерпретатор. Как будто мало их, интерпретаторов (вообще интерпретаторов, не Паскаля). Да их как грязи.

[Павел Васильев]

Использую (в этом случае), как правило, postgresql (если "полноценная" БД).
А если локальная (для хранения и обработки каких-то моих данных), то SQLite.

А как вы организуете доступ к разным СУБД, коннект, запросы, администрирование своими средствами FastScript или с помощью драйверов и компонентов FireDAC? Это важный момент, FireDAC поддерживает работу с 32 типами  СУБД, включая MangoDB, на Паскале легко и непринуждённо.

[neon]

----------
Насчет FastScript.
Разработчик там реализовал полноценную поддержку стандартного ObjectPascal (в реализации RAD Studio Delphi).
И реализовал очень хорошо.
Каких-то специфичных средств, ограничений или жестко-определенных требований там нет (ну, или же я за долгое время просто об это не споткнулся).
Есть некоторые правила, которые необходимо соблюдать, когда Вы наращиваете СВОЙ интерпретатор СВОИМ функционалом.
Но они просты и четко определены (формализованы).
То есть, Вы сами решаете, какие объекты/компоненты (а также модули исходников, в том числе и свои библиотечные модули) из среды Delphi хотите включить в свой интерпретатор и каким именно образом.
В том числе и для доступа к СУБД.
Т.е., процесс разработки интерпретатора практически ничем не отличается от того, как ведется разработка обычного VCL-приложения в среде Delphi.
Вы пишете в среде Delphi свои процедуры и функции (как для любого приложения) и используете их в интерпретаторе.
А чаще всего - у каждого программиста уже есть свои библиотеки исходников из прошлых проектов. Значит, можно использовать их.
----------
----------
Насчет доступа к СУБД.
Для postgresql я предпочитаю использовать UniDAC.
Он (по-моему мнению) более удобен и гибок. Хотя, может это уже и привычка...
Для SQLite использую FireDAC.
И причем, я использую (в интерпретаторе) их оба сразу.
Причина: откуда же я могу знать условно "сейчас" то, что мне потребуется условно "завтра"?
----------
----------
Например.
Может, я делаю "умный дом" (ну, мало ли).
И использую (в качестве элементной базы) микроконтроллеры (например, Arduino).
А управлять я хочу "всем этим" - как мне удобно.
Если сижу возле компа - то с компа.
Если сижу "условно" на кухне, то с телефона.
А если у меня в руках телевизионный пульт - то с пульта.
А может у меня вообще "крыша поехала" и я решил пристроить к этому процессу экспертную систему.
И т.д. (мало ли, что в голову придет в процессе эксплуатации).
В этом случае, вероятно, надо ориентироваться на технологию DataSnap.
Где на сервере приложений как раз интерпретатор и будет полезен.
А там, ведь, для "местной автоматики" наверное эффективнее будет SQLite.
А для следующего звена (выше, в иерархии), где инфа накапливается, лучше (предположительно) использовать postgres (для дальнейшей обработки данных).
А значит, сервер приложений должен работать с обеими СУБД одновременно.
В общем - ситуации могут быть разные.
Этим интерпретатор и полезен, что можно оперативно подстраиваться под текущие условия эксплуатации.
----------

[neon]

В "двух словах" все не объяснишь.

Но если интересны именно детали, как реализован доступ к СУБД (у меня).
То я мог бы создать документ в формате PDF с конкретным простым иллюстрирующим примером, по шагам.
Другое дело, что его же надо как-то "доставить" сюда.
Самый простой вариант - могу кинуть в почту (кому интересно).
Но здесь светить свой e-mail я бы не хотел.
Да и другие - тоже вряд ли.

Так что, если интересно, кидайте в личку свои адреса.
Если будет хотя бы один желающий - я озадачусь и сделаю/задокументирую такой иллюстрирующий пример.
Не очень быстро (ибо есть же и текучка).
Но думаю, что за пару-тройку дней управлюсь (давно заметил, что если на программирование уходит день, то для хорошего документирования "для людей, а не для галочки", потребуется 3-4 дня).