Не хочу показаться занудным, но топик не про функцию, а про оператор. Ничего не имею против аналогичной функции. Да собственно, и против нового оператора тоже. И уж тем более ничего не желаю запрещать :)
Спасибо, что хотите помочь мне в решении моих личных проблем. Сейчас так мало искренних и тактичных людей, готовых помочь разобраться в тёмных закоулках чужой души (и разума).
Если бы мне для чего-то понадобилось выражение с условием, то я бы предпочел что-то более привычное, например - функцию, которую вы упомянули ранее:
x := IfThen( Left < 100, 22, 45 );
Я читал обсуждение этой возможности и особенности её работы, а также аргументы сторон, так что просто примите этот комментарий, как моё предпочтение, а не как возможность снова указать на мои личные проблемы, которые я не отрицаю, но не готов тут обсуждать с кем-либо.
Предположим, что по каким-то причинам (отладка, расширение функциональности) необходимо добавить оператор, который бы выполнялся при срабатывании первого условия. В случае "традиционного" написания это делается прозрачно, с помощью блоковых скобок "begin end". Новая нотация предполагает, что в этом случае...нужно переписать этот кусок кода под старую нотацию.
Рассуждения на тему различного смысла можно было бы продолжить при условии, что эти различия смысла можно как-то выразить в записи алгоритма (в блок-схеме например).
Историю про "экономию" на нажатиях клавиш при написании исходников я слышу со времени появления языка С. Эта история про ленивых программистов. И она хорошая - потому как хорошие программисты должны быть ленивыми. Видимо, я недостаточно хорош/ленив (нужное подчеркнуть) :).
Ещё раз перечитал топик и комментарии. И теперь могу более точно сформулировать проблему новомодного синтаксиса (и это не только про заявленный вариант IF и не только про Delphi): при его использовании получается так называемый "необслуживаемый код" - лаконичный, эстетически приятный, но в случае необходимости его отладки или проверки - "необслуживаемый". Казалось бы, в чем проблема? Написал хороший код, проверил и не трогай. В теории - да. На практике - есть как минимум две проблемы: отсутствие автоматических модульных тестов и отсутствие документирования. И хотя это уже другая тема - культура программирования (поэтому заранее прошу прощения за офтоп), но связь таки имеется: использование подобных языковых конструкций повышает риски для проектов с недостаточно развитой культурой написания кода. А так как Delphi имеет низкий порог вхождения и огромные возможности для быстрого роста и развития проектов, то получаем... то, что заслуживаем :)
Зачем портить хорошую вещь? Не нравится язык - используй другой, который нравится. Я уже молчу про то, что Delphi из среды разработки перекрестили в язык программирования. Видимо, так проще объяснять особенности реализации Object Pascal в данном конкретном месте.
А раз так, то делайте, что хотите: сокращайте, заимствуйте... главное - оставляйте обратную совместимость с исходным языком, главное достоинство которого - близость к алгоритмическому языку.
Благодарю автора за актуальную статью с практическими советами, доступными каждому мыслящему человеку. Вот только...
Сидит гвоздем концепция перехода количества в качество. В данном случае качество это проявляется сугубо индивидуальное. У кого-то депрессия, у кого-то эйфория. Или коктейль из вышеупомянутого.
И, опять же из личных наблюдений: давят не знания, а неструктурированная информация. Ум пытается использовать всё, что ему попадается, но в нашей реальности это - главная опасность. Описанные компенсаторы - это автоматическая система клапанов, снижающая давление. Но давление можно снизить на уровне принятия решений подключения к тем или иным источникам информации. И скорректировать скорость поступления данных в соотвествии со скоростью создания (осознания) знаний. Со временем эта скорость замедляется естественным образом, так как возрастает "сложность конструкции". Возможно, что в какой-то момент нужно признаться самому себе, что качественных изменений уже не будет, что внутренняя модель мира построена, и теперь можно лишь наслаждаться проделанной работой, время от времени внося в пирамиду собственных представлений косметические изменения.
P.S. Местами автор изволил провоцировать приверженцев тех или иных концепций познания мира (что заметно подняло число комментариев), не буду рефлексировать по этому поводу, а лишь замечу, что, возможно, наш мир может быть одновременно и очень сложным, с бесконечным числом элементов и связей, и очень простым, доступным для понимания даже ребёнку. Парадоксальным настолько, что споры о нем будут продолжаться и после окончания времени его существования.
После редактирования материал стал гораздо лучше восприниматься. Не знаю, в чем именно дело, но структура документа улучшилась.
Однако у меня остались возражения относительно практического применения этой теории. И дело тут не в математике (к ней претензий нет), а в восприятии и возможности использования человеком при проектировании информационных систем (и лично мной - в частности, так как я сторонник объектного подхода, в том числе - в проектировании данных).
Проведу аналогию с химией, физикой и реальной жизнью. С точки зрения физики все дело в связях электронов, в их орбитах, энергетических уровнях и т.д. И это - правильный ответ. Но с точки зрения химии удобней пользоваться более высокой степенью абстракции (молекулярной), чтобы описывать химические реакции, которые приводят к нужному результату. А на бытовом уровне удобный уровень абстракции ещё выше (белый порошок из красной баночки).
На мой взгляд ваши исследования будут интересны, но весьма узкому кругу специалистов, например, разработчикам памяти для компьютеров с принципиально новой архитектурой или физической реализацией. А программистам-прикладникам это ненужно и непонятно. Это усложняет им жизнь, а не облегчает.
Статья получилась сложная для восприятия. И вот почему. 1) отсутствие ожидаемой структуры изложения 2) стилевая неопределенность целевой аудитории
Рассуждения об эффективности применения данной теории на практике несмотря на наличие реализации в виде различных прикладных решений носят скорей рекламный характер, так как оторваны от суровой реальности и спекулируют на идее бесконечного роста доступной памяти физических систем ради повышения производительности в синтетических тестах.
Ну и немного философии. Новые теории должны быть простыми, иначе их полезность становится неоправданно дорогой. В данном случае теория гораздо сложней реализации. По крайне мере так это выглядит.
Статья очень спорная, а значит автор затронул проблему на стыке представлений о том, что такое "хорошо" и что такое "идеально". На мой взгляд вопрос о новых устройствах ввода цифровой информации заслуживает внимания, а также исследований, в том числе - практических. Мне было бы интересно узнать продолжение этой истории.
Сам я использую стандартную клавиатуру (почти стандартную - KBS-8 AntiRSI от A4Tech ), но интуитивно чувствую, что отдал бы предпочтение устройству с лучей физической совместимостью.
Вызвал интерес 30-ти клавишные симметричные клавиатуры, но у меня сомнения относительно конфигурации и числа клавиш, вызванные разной длиной пальцев и особенностью анатомии большого пальца.
Техника набора с применением "аккордов" напоминает технику игры на фортепиано, отсюда есть предложение - использовать кнопки с датчиком силы нажатия, что позволит печатать заглавные символы теми же клавишами, что и прописные, но чуть сильней их нажав.
Ещё одним "измерением" может стать время удержания клавиши в нажатом состоянии (по аналогии с музыкантами - стоккато / легато).
Так что в идеале я бы хотел опробовать динамическую (2 градации силы нажатия) клавиатуру для одной руки (левой) с 11 клавишами (по две клавиши для мизинца и безымянного пальца, по три для среднего и указательного и одну для большого), различающую 2 градации времени нажатия (точка-тире) с поддержкой аккордов для ввода данных.
А в другую руку - мышь. Хотя, строго говоря, если интерфейс не связан с графикой или компьютерными играми, он должен обходиться и без мыши, с удобной навигацией по элементам меню с помощью кнопок.
Альтернативы есть, хотя и не полностью отвечают описанной в статье концепции. http://myvisualdatabase.com/ru/ Но на роль убийцы он точно не подходит, так как уже пол года находится в заморозке.
Не хочу показаться занудным, но топик не про функцию, а про оператор. Ничего не имею против аналогичной функции. Да собственно, и против нового оператора тоже. И уж тем более ничего не желаю запрещать :)
Спасибо, что хотите помочь мне в решении моих личных проблем. Сейчас так мало искренних и тактичных людей, готовых помочь разобраться в тёмных закоулках чужой души (и разума).
Если бы мне для чего-то понадобилось выражение с условием, то я бы предпочел что-то более привычное, например - функцию, которую вы упомянули ранее:
Я читал обсуждение этой возможности и особенности её работы, а также аргументы сторон, так что просто примите этот комментарий, как моё предпочтение, а не как возможность снова указать на мои личные проблемы, которые я не отрицаю, но не готов тут обсуждать с кем-либо.
Предположим, что по каким-то причинам (отладка, расширение функциональности) необходимо добавить оператор, который бы выполнялся при срабатывании первого условия. В случае "традиционного" написания это делается прозрачно, с помощью блоковых скобок "begin end". Новая нотация предполагает, что в этом случае...нужно переписать этот кусок кода под старую нотацию.
Рассуждения на тему различного смысла можно было бы продолжить при условии, что эти различия смысла можно как-то выразить в записи алгоритма (в блок-схеме например).
Историю про "экономию" на нажатиях клавиш при написании исходников я слышу со времени появления языка С. Эта история про ленивых программистов. И она хорошая - потому как хорошие программисты должны быть ленивыми. Видимо, я недостаточно хорош/ленив (нужное подчеркнуть) :).
Ещё раз перечитал топик и комментарии. И теперь могу более точно сформулировать проблему новомодного синтаксиса (и это не только про заявленный вариант IF и не только про Delphi): при его использовании получается так называемый "необслуживаемый код" - лаконичный, эстетически приятный, но в случае необходимости его отладки или проверки - "необслуживаемый". Казалось бы, в чем проблема? Написал хороший код, проверил и не трогай. В теории - да. На практике - есть как минимум две проблемы: отсутствие автоматических модульных тестов и отсутствие документирования. И хотя это уже другая тема - культура программирования (поэтому заранее прошу прощения за офтоп), но связь таки имеется: использование подобных языковых конструкций повышает риски для проектов с недостаточно развитой культурой написания кода. А так как Delphi имеет низкий порог вхождения и огромные возможности для быстрого роста и развития проектов, то получаем... то, что заслуживаем :)
"Модно, стильно, молодёжно..."
Зачем портить хорошую вещь? Не нравится язык - используй другой, который нравится. Я уже молчу про то, что Delphi из среды разработки перекрестили в язык программирования. Видимо, так проще объяснять особенности реализации Object Pascal в данном конкретном месте.
А раз так, то делайте, что хотите: сокращайте, заимствуйте... главное - оставляйте обратную совместимость с исходным языком, главное достоинство которого - близость к алгоритмическому языку.
Благодарю автора за актуальную статью с практическими советами, доступными каждому мыслящему человеку. Вот только...
Сидит гвоздем концепция перехода количества в качество. В данном случае качество это проявляется сугубо индивидуальное. У кого-то депрессия, у кого-то эйфория. Или коктейль из вышеупомянутого.
И, опять же из личных наблюдений: давят не знания, а неструктурированная информация. Ум пытается использовать всё, что ему попадается, но в нашей реальности это - главная опасность. Описанные компенсаторы - это автоматическая система клапанов, снижающая давление. Но давление можно снизить на уровне принятия решений подключения к тем или иным источникам информации. И скорректировать скорость поступления данных в соотвествии со скоростью создания (осознания) знаний. Со временем эта скорость замедляется естественным образом, так как возрастает "сложность конструкции". Возможно, что в какой-то момент нужно признаться самому себе, что качественных изменений уже не будет, что внутренняя модель мира построена, и теперь можно лишь наслаждаться проделанной работой, время от времени внося в пирамиду собственных представлений косметические изменения.
P.S. Местами автор изволил провоцировать приверженцев тех или иных концепций познания мира (что заметно подняло число комментариев), не буду рефлексировать по этому поводу, а лишь замечу, что, возможно, наш мир может быть одновременно и очень сложным, с бесконечным числом элементов и связей, и очень простым, доступным для понимания даже ребёнку. Парадоксальным настолько, что споры о нем будут продолжаться и после окончания времени его существования.
После редактирования материал стал гораздо лучше восприниматься. Не знаю, в чем именно дело, но структура документа улучшилась.
Однако у меня остались возражения относительно практического применения этой теории. И дело тут не в математике (к ней претензий нет), а в восприятии и возможности использования человеком при проектировании информационных систем (и лично мной - в частности, так как я сторонник объектного подхода, в том числе - в проектировании данных).
Проведу аналогию с химией, физикой и реальной жизнью. С точки зрения физики все дело в связях электронов, в их орбитах, энергетических уровнях и т.д. И это - правильный ответ. Но с точки зрения химии удобней пользоваться более высокой степенью абстракции (молекулярной), чтобы описывать химические реакции, которые приводят к нужному результату. А на бытовом уровне удобный уровень абстракции ещё выше (белый порошок из красной баночки).
На мой взгляд ваши исследования будут интересны, но весьма узкому кругу специалистов, например, разработчикам памяти для компьютеров с принципиально новой архитектурой или физической реализацией. А программистам-прикладникам это ненужно и непонятно. Это усложняет им жизнь, а не облегчает.
Статья получилась сложная для восприятия. И вот почему.
1) отсутствие ожидаемой структуры изложения
2) стилевая неопределенность целевой аудитории
Рассуждения об эффективности применения данной теории на практике несмотря на наличие реализации в виде различных прикладных решений носят скорей рекламный характер, так как оторваны от суровой реальности и спекулируют на идее бесконечного роста доступной памяти физических систем ради повышения производительности в синтетических тестах.
Ну и немного философии. Новые теории должны быть простыми, иначе их полезность становится неоправданно дорогой. В данном случае теория гораздо сложней реализации. По крайне мере так это выглядит.
Статья очень спорная, а значит автор затронул проблему на стыке представлений о том, что такое "хорошо" и что такое "идеально". На мой взгляд вопрос о новых устройствах ввода цифровой информации заслуживает внимания, а также исследований, в том числе - практических. Мне было бы интересно узнать продолжение этой истории.
Сам я использую стандартную клавиатуру (почти стандартную - KBS-8 AntiRSI от A4Tech ), но интуитивно чувствую, что отдал бы предпочтение устройству с лучей физической совместимостью.
Вызвал интерес 30-ти клавишные симметричные клавиатуры, но у меня сомнения относительно конфигурации и числа клавиш, вызванные разной длиной пальцев и особенностью анатомии большого пальца.
Техника набора с применением "аккордов" напоминает технику игры на фортепиано, отсюда есть предложение - использовать кнопки с датчиком силы нажатия, что позволит печатать заглавные символы теми же клавишами, что и прописные, но чуть сильней их нажав.
Ещё одним "измерением" может стать время удержания клавиши в нажатом состоянии (по аналогии с музыкантами - стоккато / легато).
Так что в идеале я бы хотел опробовать динамическую (2 градации силы нажатия) клавиатуру для одной руки (левой) с 11 клавишами (по две клавиши для мизинца и безымянного пальца, по три для среднего и указательного и одну для большого), различающую 2 градации времени нажатия (точка-тире) с поддержкой аккордов для ввода данных.
А в другую руку - мышь. Хотя, строго говоря, если интерфейс не связан с графикой или компьютерными играми, он должен обходиться и без мыши, с удобной навигацией по элементам меню с помощью кнопок.
Альтернативы есть, хотя и не полностью отвечают описанной в статье концепции.
http://myvisualdatabase.com/ru/
Но на роль убийцы он точно не подходит, так как уже пол года находится в заморозке.