Программируете ли вы на Паскале?

Да даже в AVR такое есть типа st X+, r16 или st -X, r16

Там есть операции вида память-память?

Действие не должно возвращать результата, или же возвращать булевый результат - получилось или нет

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

Нет.

Вы самокритичны.

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

Имхо, суть не в том. Суть в том, что «Действие не должно возвращать результата, или же возвращать булевый результат - получилось или нет» — это бессмыслица, которую юзер сгенерировал ад хок прямо сейчас. За ней ничего не стоит, никакого устойчивого принципа в проектировании языка. Потому что принцип не сформулирован.

Нет, чел. Сначала не суметь прочитать и понять внятный текст с развёрнутым объяснением, а потом начать детский перевод стрелок — это твоя проблема, не моя.

Ну и поставить Go в один ряд с Cи++ — это тоже нечто.

Так понятнее тем читателем, кто недостаточно знаком грамматикой Си.

За ней ничего не стоит, никакого устойчивого принципа в проектировании языка

Ну почему же, за ней вполне просматривается современный подход, в духе CQRS. В частности в современных языках есть тенденция разделять мутабельне и иммутабельные вещи. Человек интуитивно пытается натянуть сову на глобус.

Нет.

Вот в этом суть. Возможности Си хорошо ложатся на трансляцию в систему команд PDP-11. Мы можем объявлять переменные как register. Мы можем с помощью таких указателей проводить операции вида память-память.

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

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

Но на языки типа Си и Паскаля это никак не ложится.

«Человек интуитивно пытается натянуть сову на глобус.», да, получается, так.

Вот в этом суть. Возможности Си хорошо ложатся на трансляцию в систему команд PDP-11

Это не так важно. Даже если операция идёт через аккумулятор, всё равно получается оптимальный код. На самом деле ты можешь рассматривать 2 инструкции как одну, это всего лишь условность.

Операции типа += тоже упрощают кодогенерацию.

Компиляция вообще условность, она ведь по определению не меняет СМЫСЛ программы.

Но всё меняется, когда у тебя 64 килобайта на всё… =)

А свойства - это и есть вызов правильных обработчиков в правильный момент. Просто оформленное как будто это переменная. Но, конечно, всё может случиться в криво написанном коде - не важно, собственный ли это код или недоработка LCL/VCL или ещё чего-нибудь. Но, кстати, да, с размерами окна получается изменение их вместо одного этапа в два. В большинстве случаев это не проблема (моргания в 90 % случаев никто и не заметит), но если проблема - можно это и решить использованием того же BoundsRect.

Ну да, указатели - они такие указатели. А С - язык промежуточного уровня (уже далеко не ассемблер, но все структуры данных подстраиваются максимально под процессор). Так или иначе, от баловства с указателями в Паскале в итоге решили отказаться (хотя можно подобное делать до сих пор - лишь чуть посложнее). Но это ещё один камень на чашу весов Паскаля для невнимательных - представляете, куда можно залезть из-за невнимательности с указателями? И если это будет память программы (хотя бы иногда - иначе segfault), то обеспечена совершенно непредсказуемая работа программы.

Но, кстати, да, с размерами окна получается изменение их вместо одного этапа в два.

Спешу заметить - это был Ваш пример использования properties. Но проблема фундаментальна - нужно вводить понятие и механизмы atomic transactions, что умножает на ноль саму идею «пусть оно выглядит как переменная, а всё что нужно случится auto-magically».

В большинстве случаев это не проблема (моргания в 90 % случаев никто и не заметит),

Это далеко не самое страшное что может произойти. Я могу Вам сходу нарисовать несколько сценариев где последствия подобного рода non-atomic updates будут просто катастрофическими.

Это далеко не самое страшное что может произойти. Я могу Вам сходу нарисовать несколько сценариев где последствия подобного рода non-atomic updates будут просто катастрофическими.

И что за сценарии? Пока ничего серьёзного, помимо неоптмальности действий и гипотетического моргания окна я не заметил. Найдёте «катастрофический» сценарий - проверю, возможно, для него уже сделали «защиту от дурака».

Тоже самое можно сказать про вызов любой функции.

Тоже самое можно сказать про вызов любой функции.

Я уверен - Вы даже не поняли о чём я. Скажу лишь одно слово (а вдруг?) - «инвариант».

Эта всё та же плата за выразительность.

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

В языках типа Си++ и Объектный Паскаль я не вижу никакого смысла в проперти. Это просто сахар, который добавили «чтобы было, потому что можем». Типа прямой вызов геттеров и сеттеров делал код нечитабельным? Ну-ну.

Смысл в подражании Visual Basic.

Ну вот, допустим, вы вызвали setwidth(), то с инвариантами все хорошо?

Ну вот, допустим, вы вызвали setwidth(), то с инвариантами все хорошо?

Конечно нет. Инвариант - пропорция.

Свойства нужны для реализации визуального программирования.

Отнюдь нет.

Отнюдь нет.

Конечно да, в постановке задачи про «окошко» - по формулировке.

С чего вы взяли что пропорции должны сохраняться?

все структуры данных подстраиваются максимально под процессор

Какие структуры под какой процессор?

С чего вы взяли что пропорции должны сохраняться?

Повторюсь - хотелось окошко зазумить ровно в 2 раза. Жду решений на «пропертях».

Добавить свойство zoomv ?

Ниже уже предложили.

Free Pascal очень радует кросс платформенностью компилируемых таргетов.

Интересно, кто какие транспайлеры знает в синтаксис Free Pascal?

А вообще ведь Хакса позволяет создавать на OCaml дополнительные кастом трансляторы в почти любые ЯП. IMHO было бы очень супер увидеть в Хаксе новые таргеты типа Free Pascal и Rust.

Оказывается, такое уже предлагали ещё несколько лет назад:

https://community.haxe.org/t/started-pascal-target/1653/29

Нет, не нужны.

Мне в другую сторону было бы интереснее - из FreePascal в Оберон. И это тоже «несколько лет назад предлагалось» мной же, но предлагать и сделать - это немного разное. Хотя языки более-менее близки, но variant records, absolute и прочая мешаются, т.к. в Обероне метаданные и сборка мусора, а значит, смысл каждого байта должен быть известен в любой момент времени рантайм-среде, а не только программисту.

Вы бредите.

Вы неправы (как обычно).

Проперти МОЖНО использовать в визуальном программировании, а можно и не использовать.

И кстати что Вы вкладываете в понятие визуального программирования? Создание гуев? Создание гуев в дизайнерах гуев? Метапрог? Разверните пожалуйста свою мысль, WTF «визуальное программирование» и зачем там именно проперти, чем скажем не подходят геттеры/сеттеры (особенно ирландские), сообщения или коллбэки.

В каком геометрическом месте точек любое понятие или сущность является инвариантом?

Я прав почти всегда. Это во первых. А во вторых в данном случае обсуждается object pascal и без свойств сделать визуальное программирование в нем невозможно. На крестах тоже, кстати, поэтому в борланд с++ тоже добавлен их аналог.

Define визуальное программирование.

Ну почему, сделать возможно. Просто будет хуже. Для персистентности - да, там они в рамках концепции необходимы, другое дело, что можно сделать гуй и без персистентности (как в tcl/tk, где он изначально, можно сказать, императивный).

Вы бредите. Проперти это тупо синтаксический сахар для вызова методов.

Как синтаксический сахар может быть необходимым для реализации чего-либо?

Не только.

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

в данном случае обсуждается object pascal и без свойств сделать визуальное программирование в нем невозможно

Второй раз повторяю вопрос - что Вы вкладываете в понятие визуальное программирование? Или это тоже секретный секрет?! И жду доказательства что там без проперти никак.

На крестах тоже, кстати, поэтому в борланд с++ тоже добавлен их аналог.

Не поэтому вовсе, а потому что билдер был крестовый оберткой/копипастом с дельфей. Не брешите пожалуйста.

Ок. Раз пошла такая пьянка. Покажите мне код в котором никак нельзя обойтись без циклических конструкций.

Это так не работает, я первым спросил. Итак, я в ТРЕТИЙ раз прошу у Вас две простых вещи:

1. Что Вы понимаете под визуальным программированием?

2. Докажите что без проперти там нельзя обойтись.

1. Читайте определение в словаре. У нищих слуг нет!
2. Обойтись можно даже без транслятора, теоретически.

1. Я спрашивал что именно Вы вкладываете в это понятие, телепаты все в отпуске.

2. Это все еще не доказательство, даже не близко.

1. Я Вам ответил.
2. Здесь тоже ответ был. У Вас проблемы с пониманием?

С третьего раза (!!!) Вы написали полную фигню которая даже формально на ответ не тянет. И Вы ещё что то говорите про проблемы с пониманием?!

Если под визуальным программированием Вы понимаете делание гуя в граф.утилите, то нет - проперти там не обязательны, это не более чем сиетаксическй сахар. Примером является Qt - слоты и сигналы, пропертями это можно обмазывать, а можно и нет.

Итого - Вы не умеете формулировать свои мысли, Вы понятия не имеете что такое доказательство, Вы не умеете признавать свои ошибки (которые Вы делаете постоянно - уже вторая серия марлезонского балета). Если Вы и правда имеете хоть какое то отношение к числодробилкам, особенно к расчётам на прочность и оптимизации конструкций, Вас надо немедленно уволить за профнепригодность (и это я сейчас совершенно не шучу). Все таки в такой серьёзной области ошибки проектировщика могут заканчиваться техногенной катастрофой…

С третьего раза (!!!) Вы написали полную фигню которая даже формально на ответ не тянет. И Вы ещё что то говорите про проблемы с пониманием?!

Вы реально забанены в гугле и до сих пор не смогли посмотреть определение?

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

Циклические конструкции тоже синтаксический сахар?

Примером является Qt - слоты и сигналы, пропертями это можно обмазывать, а можно и нет.

QT ни разу не аналог, т.к. требует специальный препроцессор, в отличие от Object Pascal.

Итого - Вы не умеете формулировать свои мысли

Нет, не так. Вы просто не компетентны в обсуждаемом вопросе.