Будущее Lazarus как конкурента Delphi в Enterprise-секторе

[yantux]

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

Как вы это себе представляете рисовать высокорганизованные конструкции? Можете привести примеры?

Этот интерес удовлетворит iec1131.

Нет, то, что я увидел, меня не удовлетворяет. Ты сам написал, что там рисуется алгоритм, а не программа. Эти языки не позволяют прыгнуть вверх по сложности проектов. По крайней мере, не сильно. Сейчас столько возможностей создавать программы в более удобной для человека парадигме, но тупо опускаются до структурного программирования.
Но ведь есть же агент-ориентированная, предметно-ориентированная, которые могут идеально лечь на графику. Да та же объектная, в конце-концов.[/quote]

Можете привести пример языка, который позволяет прыгнуть вверху по сложности проектов? Можете привести пример сложного проекта и его требования к языку?

Путь развития средств разработки идёт в направлении упрощении освоения процесса программирования. А iec1131 ориентирован на вполне свою сферу - АСУ ТП. Т.е. простые алгоритмы, которые легко рисуются тем же школьником.

Добавлено спустя 52 минуты 44 секунды:
Re: Будущее Lazarus как конкурента Delphi в Enterprise-секторе
У Altera в Quartus есть возможность рисовать схемную логику в виде блоков (похож на fbd iec1131). Но там тоже особо сложного тоже не обрисуешься, хотя по своему наглядно и это преимущество в быстроте осознания кода.

Добавлено спустя 5 минут 26 секунд:
Re: Будущее Lazarus как конкурента Delphi в Enterprise-секторе
Глядя на java и всё остальное, я особого прогресса не вижу. Даже наоборот. Создаётся ощущение, что всё больше торморзит и потребляет ресурсов. Т.е. эффективность программирования падает. Это проблема.

Паскаль я бы не стал выкидывать. Думаю, в отношении паскаля может не помешала бы новая среда разработки, которая бы совмещала вертикальное рисование алгоритма и горизонтальное аля fbd последовательное выполнение кода, естестенно опираясь на паскаль без прослоек и промежуточных трансляций.

[alexey38]

Путь развития средств разработки идёт в направлении упрощении освоения процесса программирования. А iec1131 ориентирован на вполне свою сферу - АСУ ТП. Т.е. простые алгоритмы, которые легко рисуются тем же школьником.

Я бы не согласился с Вашей фразой про простые алгоритмы в АСУ ТП, которые рисуются школьником. Безусловно, что есть простые процессы, которые просто автоматизируются и программируются. Но есть и сложные. Кстати, АСУТПшники говорят, что для бухгалтерии могут писать любые школьники с 6 класса, т.к. там арифметика. То есть я предлагаю не акцентировать где проще, а где сложнее.

Языки типа iec1131 обязательно применяются в тех сферах, где программисты не могут разобраться в предметной области в виду ее сложности (нужно знать досконально и глубоко отдельные разделы физики и математики), поэтому прибегают за помощью к технологам, которые не владеют языками программирования. Для понимания алгоритма (программы) на графических языках из iec1131 нужно обучение на 1-2 дня. И это плюс этих языков. Программа на этих языках проверяется как самими программистами, так и технологами. В задачах автоматизации бухгалтерских и делопроизводственных задач такие языки применяются реже, т.к. программистам легче освоить предметную область и не обязательно код программы выдавать на проверку к бухгалтеру.

Я сам лично занимался и занимаюсь, как программированием для АСУ ТП (производство) и АСУ П (бухгалтерия и бизнес-процессы), так и иногда стою на стороне технологов (заказчиков АСУ ТП), и руководящего состава предприятия (заказчиков АСУ П). Обладая неким опытом и со стороны программистов и со стороны заказчиков АСУ, могу сказать, что классическое программирование на языках типа Паскаля (Дельфи) является достаточно оптимальным. Можно написать реально большие проекты, которые потом получается сопровождать. На графических языках такое невозможно, т.к. наглядность теряется при достижении некоторого объема кода, эквивалентного 20-30 строкам кода. Многовложенный код тоже плохо читается графически. Поэтому у графических языков очень узкая ниша - визуализация отдельных процессов и отдельных алгоритмов, в которых сам по себе код мало что значит, нужно сверить код и некие знания из другой области.

[Лекс Айрин]

Как вы это себе представляете рисовать высокорганизованные конструкции? Можете привести примеры?

Как раз над этим и думаю. И у меня здесь чисто шкурный интерес.

Можете привести пример языка, который позволяет прыгнуть вверху по сложности проектов? Можете привести пример сложного проекта и его требования к языку?

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

Паскаль я бы не стал выкидывать. Думаю, в отношении паскаля может не помешала бы новая среда разработки, которая бы совмещала вертикальное рисование алгоритма и горизонтальное аля fbd последовательное выполнение кода, естестенно опираясь на паскаль без прослоек и промежуточных трансляций.

Паскаль и я бы не стал сбрасывать со счета. И, кстати, не отказался бы от промежуточного языка, но так чтобы он пегко преобразовывался в паскаль или другой ЯВУ. Т.е. графика здесь вторична.

Глядя на java и всё остальное, я особого прогресса не вижу. Даже наоборот. Создаётся ощущение, что всё больше торморзит и потребляет ресурсов.

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

могу сказать, что классическое программирование на языках типа Паскаля (Дельфи) является достаточно оптимальным.

А Вы не путаете язык с его реализацией? Сам язык практически не изменился с 90х. По крайней мере, полученные тогда еще навыки не приходится ломать. А вот то, что для простенькой программы приходится писать кучу левого (стандартного) кода...

На графических языках такое невозможно, т.к. наглядность теряется при достижении некоторого объема кода, эквивалентного 20-30 строкам кода. Многовложенный код тоже плохо читается графически.

Это не говорит о том, что сама идея плоха. Скорее о том, что реализация (подход к отображению) хромает.

[debi12345]

Первый раз слушу про такие языки визуализации задач. Обычно для прототайпинга используют высокоуровневые скриптовые языки - TCL/TK, Python/TK(Qt),.. Отладив на них базовую бизнес-логику безо всяких "наворотов", можно писать уже нормальный код - на C++, Pascal,..

[alexey38]

А вот то, что для простенькой программы приходится писать кучу левого (стандартного) кода...

Я участвовал в составе небольшой группы (2-3 человека) в написании довольно сложных проектов. Первые проекты начинал с 1993-94 годов, когда стандартные библиотеки были очень слабы. Стандартный код пишется раз и отнимает не так много времени. Время уходит, когда нужно достичь универсальности, тогда стандартный код начинает пухнуть.

Добавлено спустя 2 минуты 48 секунд:
Re: Будущее Lazarus как конкурента Delphi в Enterprise-секторе

Это не говорит о том, что сама идея плоха. Скорее о том, что реализация (подход к отображению) хромает.

Это не особенность реализации, это особенность человеческого мышления. Человек очень медленно переваривает большие схемы, чем бы они не были нарисованы (хоть карандашом), но очень быстро схватывает маленькие. В части текстов человек одинаково легко читает листовку и книжку из 1000 страниц.

Добавлено спустя 7 минут 10 секунд:
Re: Будущее Lazarus как конкурента Delphi в Enterprise-секторе

Как раз над этим и думаю. И у меня здесь чисто шкурный интерес.

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

Я говорю, что обычному человеку легче написать текст, чем схему. Схемка из 2-3 квадратиков делается быстро, но в ней мало толку и смысла. А нарисовать более сложную схему никто быстро не может.

[Лекс Айрин]

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

Это для одного проекта. Но ведь так в каждом. Стандартным я назвал код типа:

Код: Выделить всё

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms, Unit1, virtualtreeview_package
  { you can add units after this };

{$R *.res}

begin
  RequireDerivedFormResource := True;
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Скажите, кто-нибудь переписывал этот код? Переопределял объект(класс) Application?

Я говорю, что обычному человеку легче написать текст, чем схему. Схемка из 2-3 квадратиков делается быстро, но в ней мало толку и смысла. А нарисовать более сложную схему никто быстро не может.

С этим я согласен, более того, такие схемы вредны. И именно поэтому говорю, что современные графические языки неудобны. Потому что это схемы.
Но современная программа это же набор картинок. Почему, допустим, нельзя нарисовать это самое окно (пусть даже нестандартной формы), сказать, что это "объект окно", задать на нем часть и объявить ее "объект заголовок". причем, у обоих есть свой набор возможностей. и обращаться с ним не как с TForm1. Caption:="что-то там", а Хотя бы как Caption:="что-то там", при этом, если надо, утянув полный путь с соответствующего объекта? Но ведь нет, проще писать ручками многокилометровые пути. Почему мы должны объяснять компилятору даже то, что легко указать? Или нарисовать. Потому файлы и пухнут. Визуальное же проектирование позволит убрать нафиг эту всю... беллетристику. Причем, половина работы уже сделана, но все упираются в структурное программирование, хотя сложность при этом возрастает неимоверно.

Отладив на них базовую бизнес-логику безо всяких "наворотов", можно писать уже нормальный код - на C++, Pascal,..

То есть, как я понимаю, писать программу дважды?

[Brainenjii]

Я говорю, что обычному человеку легче написать текст, чем схему. Схемка из 2-3 квадратиков делается быстро, но в ней мало толку и смысла. А нарисовать более сложную схему никто быстро не может.

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

Скажите, кто-нибудь переписывал этот код? Переопределял объект(класс) Application?

Я. Постоянно переопределяю

[Лекс Айрин]

Я. Постоянно переопределяю

Ну хоть не зря этот код существует.

[alexey38]

Стандартным я назвал код типа:

На его написание путем copy-paste я трачу примерно 5 секунд.

Добавлено спустя 4 минуты 42 секунды:
Re: Будущее Lazarus как конкурента Delphi в Enterprise-секторе

Но ведь нет, проще писать ручками многокилометровые пути. Почему мы должны объяснять компилятору даже то, что легко указать?

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

Использую современное IDE, с установленными дополнениями, на написание всего подобного нужно нажимать некоторые кнопки, и длинные пути будут подставляться сами по себе. А при нормальной структуре самой программы вообще никакие длинные пути не нужны будут. Так что тут скорее нужно менять стиль программирования, а не изобретать велосипеды.

Добавлено спустя 9 минут 22 секунды:
Re: Будущее Lazarus как конкурента Delphi в Enterprise-секторе

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

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

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

[Лекс Айрин]

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

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

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

Это, заметьте, не я сказал, а Вы! То есть, несмотря на любовь к клавиатуре, Вы пользуетесь Графической оболочкой. Вы, по большому счету, рисуете программу. И, кстати, как вы напишете без длинных путей, если сама логика GUI это заставляет делать? При том, что, допустим, объект это что-то, как изначально представлялось, цельное и мы не должны входить в него снаружи!

А в место этого объекты это просто усложненный (даже не навароченный) вариант типа "Record". И подход к их использованию соответствующий. Получается, что возросла не мощность языка, а его сложность.

Просто чтобы описать задачу в текстовом виде это нужно уметь делать.

Вот только проблема в том, что, по своей сути, программа распятый гипертекст.

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

Человек, в зависимости от типа сознания, как только не думает. И словами, и фразами, и ощущениями. Я, допустим, умею воспринимать текст на 2-3 уровнях. Или думать мелодию.

[B4rr4cuda]

Или думать мелодию.

[шутка]
Я тоже так хочу, дайте рецептик вещества? =)
[/шутка]

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

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

[alexey38]

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

Человек, в зависимости от типа сознания, как только не думает. И словами, и фразами, и ощущениями. Я, допустим, умею воспринимать текст на 2-3 уровнях. Или думать мелодию.

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

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

Добавлено спустя 1 минуту 51 секунду:
Re: Будущее Lazarus как конкурента Delphi в Enterprise-секторе

То есть, несмотря на любовь к клавиатуре, Вы пользуетесь Графической оболочкой. Вы, по большому счету, рисуете программу.

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

Добавлено спустя 1 минуту 12 секунд:
Re: Будущее Lazarus как конкурента Delphi в Enterprise-секторе

Вот только проблема в том, что, по своей сути, программа распятый гипертекст.

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

[yantux_netbook]

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

Понимание взаимосвязи между данными у меня пришло на основании iec1131 fbd и блок-схемами в среде Quartus для ПЛИС Altera. Нарисовать взаимосвязь между различными типами данных нарисовать проще, чем набить эту взаимосвязь в тексте или точнее сказать этот способ лучше комбинировать с вводом текста.

В отношении алгоритма, программы наоборот. Её набить проще. Однако, я бы сделал исключение для опера case.

Есть ещё пример из среды Delphi/Lazarus: в свойствах объекта с помощью графических средств можно указать взаимосвязь между объектом и событием.

[alexey38]

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

Иллюстративно показать взаимосвязь графически будет проще и нагляднее. Например, имеем квадратик (таблица БД) имеем другой квадратик (визуальный компонент TDBGrid) и мы от одного квадратика рисуем стрелочку к другому квадратику. Получаем очень наглядное изображение. Но когда мы хотим детализировать, то таблица содержит 20 полей со своими английскими идентификаторами и своим порядком, и имеем TDBGrid с 30 колонками, где 15 соответствуют 15 полям таблицы БД в ином порядке, чем в БД, и еще 15 - это вычисляемые поля (некие логические или арифметические операции с исходными полями таблицы БД с визуализированным результатом), то в графическом виде мы получаем очень сложную схему с кучей пересекающихся стрелочек с подписями и т.п. Текстовая таблица будет намного нагляднее.

[Лекс Айрин]

Некоторые люди не имеют талантов, а другие их имеют.

Неправильно. Все имеют таланты, но не все могут их осознать и развить.

Речь о выражении структурированной логической информации, и именно в этой категории, человек думает словами.

Надо же. Интересно, почему тогда большая часть современных инструментов использует WYSIWYG как основной режим? Зачем тогда такой компонент как TreeView? А как же ситуация когда я чувствую, что ошибка есть, но не осознаю какая? Даже обычный текст, да будет тебе известно, редко кто читает словами. Чаще по нескольку слов сразу, а то и целыми предложениями.

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

ПОДДЕРЖИВАЕТ? Сейчас и НАПИСАТЬ программу не всегда получается правильно без глобального бетатестинга! А все именно потому, что ее автор(ы) не всегда представляет все, что пользователь может с ней сотворить.

В отношении алгоритма, программы наоборот. Её набить проще. Однако, я бы сделал исключение для опера case.

Визуально, имхо, стоит представлять объекты, ссылки и, да, оператор case. Точнее, взаимосвязи между ними. Уже при написании метода туда стоит "провалиться", открыв его текст в отдельном окне. Все остальное легко проделать и в текстовом редакторе.