DRAKON.SU

Текущее время: Суббота, 20 Октябрь, 2018 07:33

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 45 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 15 Январь, 2017 17:42 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3784
Откуда: Москва
Язык ДРАКОН и тезис Олега Гарипова о трудностях Java-программистов

Сайт Олега Гарипова http://integratorsoft.com/

Я открыл тему, чтобы тезис Олега Гарипова не затерялся среди других вопросов. См.
viewtopic.php?p=99519#p99519

Тезис Олега Гарипова
Цитата:
9 миллионов Java-программистов и 4 миллиона Си-шарп-программистов испытывают на работе серьезные трудности. Эти трудности можно устранить или ослабить с помощью языка ДРАКОН
Слова Олега Гарипова произвели на меня очень сильное впечатление.

На нашем форуме такие слова звучат впервые. Согласен ли кто-нибудь с Олегом?

Олег сказал мне, что этот тезис доказан здесь:
http://integratorsoft.com/?mo=651381494 ... 5138149515

Но мне кажется, что текст по ссылке является неубедительным.
Цитирую:
Цитата:
CodeView (Basic Edition)

Getting a handle on complexity

Integrator CodeView (Basic Edition) offers code visualization within traditional integrated development environment tools such as Eclipse, Idea and Netbeans (IDEs). CodeView works as a plug-in for your IDE and you switch back and forth with a keystroke. CodeView helps Java developers maintain and troubleshoot code faster and easier.

CodeView generates a picture of the code, which shows the flow of the program. You see the whole at once and your mind grasps it easily. The "control flow" of a stack is the order of execution of the program lines; branches and calls are hard to follow in the IDE. CodeView simplifies understanding of the main and secondary flows of the algorithms, showing all binary yes/no choices, multiple choices, cycles, branches, calls, iterations, event handlers, comments and try/catch/finally exception handlers.

You can edit the diagrams generated by Integrator to change the code and save changes. Add comments, making it easy to understand later, or for others, such as newcomers to the team or business analysts.

Download Integrator CodeView (Basic Edition)

Navigation

CodeView includes powerful navigation capabilities. You can expand and collapse diagrams, scroll or move a hover window over the diagram to magnify portions. Method calls are displayed as straight arrows and are navigable in both directions. Related code files not shown on the picture can be added with a button until all the algorithms needed to solve an issue are shown. Hide modules you don't need with a keystroke. Save a picture once you are satisfied.

CodeView pictures are maps of the code modules and their connections and they can get large for complex projects. A standard HD monitor will show about 60 lines of code in readable form; you have to move around to see larger pictures. Print it on large paper as a PDF and then, in Adobe, chose Poster format to display how it will lay out. The code is readable down to 70% of full size. A printout works well for pair programming. Discuss the issues and make notes on the paper, then one person makes changes at the keyboard and the other holds the map to guide the changes.

2,000 lines of code creates a picture 3 meter wide by 2 meter high. You hang it on the wall, and teams can examine it together. Like maps, details require space. The large printout is a rich resource for learning new projects and refactoring legacy code.

Use cases

How do you gain insight into a particular use case, which involves many intricately connected algorithms? CodeView improves the traditional method of analyzing code line by line within the IDE, which requires hundreds of mouse clicks and keyboard shortcuts. Use search in CodeView or the IDE to locate the algorithms relevant to your issue. Now you can collaborate with others effectively; they can see the results of your work and understand the control flow of the use case.

Debugging

If you can find and fix a bug in the IDE, great! Fixing complicated bugs requires tracing code through many linked algorithms, setting up a test scenario and stepping through lines of code in chains of calls in the IDE. Even then you still may not locate the cause of the problem. CodeView displays the entire call stack of algorithms so that the whole sequence of execution is seen as a running ‘spotlight’ on an unchanging big picture.

Errors in the production environment are often captured as exception stack traces scattered in application logs, log4j, etc. Just copy a stack trace from the log and paste it into CodeView. All algorithms relevant to the errors are displayed in CodeView, each stack trace is marked by an individual color and all calls are displayed as arrows. There’s no better way to see what went wrong. (add link to a nice example, open in new tab.)

Learning a new project

A typical project has thousands of lines of code over hundreds of modules. Clicking in the IDE, reading code, clicking to called modules, following branches is exhausting and you still may not understand the control flow. You can see the flow and read the code In CodeView, so the whole begins to make sense much faster. When you work in the new project, Search gets you to the relevant module and CodeView shows you the modules around it, hence your exact location in the project. The big printout is invaluable for providing context and making notes.

Code review

During code review, a printout of the code is easily read by several team members at once and shows any new code in the context of the flow. The details of the new code are easier to understand. There is no better way to discuss code and it is fun and efficient.

Drakon language

CodeView uses a graphical language called Drakon, a friendly and intuitive flow chart notation which is easy to grasp. Drakon is a powerful mathematically-proven language developed for the Russian space program. Their development team works on the software used to fly “Buran” - the reusable spacecraft. Drakon streamlines sharing, reviewing, discussing, fixing, enhancing and evolving algorithms by the entire project team involved in the process, including non-developers. The main features of Drakon are:

• Control flows top to bottom, which is predictable – better than the arbitrary arrangements of Western flow charts. The main flow of the algorithm is always on the left. It represents the main, most important case. In Russian, it is called шампур, literally ‘a skewer’, as if filled with kebab of operators.

• The flow appears clearly as straight lines, without any visual obstacles. In IDE view we do not see this flow at all, especially on multiple recursive if/else algorithms spanning several screens or in multiple files.

• With an “If” fork , operators on the expected path show on the left, in the main flow, and the other branch shows to the right. This is a more ergonomic view than the Java top to bottom flow of indented code. Complicated flows like chained "If" forks are clear in Drakon.

• Multiple Choices and exception handling Try/Catch statements. The flow leads into a given operator and answers the question “how did we get here during program execution?”

• For multi-threaded applications, concurrently running algorithms and thread starting points are displayed side by side, providing a better view.

Main features of CodeView

Source code can be changed directly in CodeView and the changes saved to the original file. Add comments by clicking on the operator and entering. Either natural language and code or both can be displayed. Comments are stored in the code file.

CodeView works as a plug-in for IDE’s such as Eclipse. You can toggle between CodeView and Eclipse editor with CTRL + ALT + C. Changes made in CodeView are reflected in the Eclipse editor and vice versa.

CodeView shows both Java (server side) and Java Script (client side) in the same picture. Other common programming languages are also supported; new languages are being added.

Integrator CodeView (Basic Edition) boosts productivity and promotes communication in development teams. Both developers & non-developers can analyze complicated software effectively. The big picture simplifies making changes and guarantees high quality of code. CodeView simplifies knowledge transfer to new developers on a project and promotes team collaboration. Please give it a try.

Big picture example with 3 traces of Java code


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 15 Январь, 2017 21:49 
Аватара пользователя

Зарегистрирован: Среда, 09 Ноябрь, 2016 00:33
Сообщения: 98
Откуда: Tallinn
в конце 90-х компанией Borland был выкуплен стартап Together Software который занимался инновационным по тем временам продуктом который позволял прямую и обратную конверсию кода в диаграммы UML, так что спрос и трудности есть и уже давно
https://youtu.be/FGRbEODa8Fg
но что бы понять как убирать трудности с помощью языка ДРАКОН, программист должен быть всеж весьма приличного уровня и можно сказать мыслителем, это нечастая штука сегодня


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Январь, 2017 03:27 

Зарегистрирован: Четверг, 02 Июль, 2015 13:47
Сообщения: 35
Дорогой Владимир Даниэлович, по вашей просьбе я составил список из трудностей, которые возникают перед программистами при использовании таких IDE как Eclipse и т.д.

IDE не облегчают, а затрудняют работу разработчиков в следующих важных случаях:

1. Маленькая программа, которая печатает "Привет, мир!", неплохо выглядит в Eclipse. А с большим, длинным файлом с тысячами строк кода работать трудно.
2. Чаще всего больших файлов еще и много, а со многими файлами работать еще труднее, чем с одним
3. Трудно понимать конструкции языка программирования, такие как if, if/else, if/if, try/catch/finally
4. Трудно проследить вызовы методов
5. Трудно проследить код и вызовы, относящиеся к данному use-case или тикету Jira
6. Трудно просмотреть результаты поиска кода, нужно нажать на каждое попадание, а их может быть много
7. Трудно взять трассировку стэка исключительной ситуации и определить ее причину
8. Трудно работать и с Java и с JavaScript в одном проекте
9. Трудно смотреть на значения переменных времени выполнения
10. Трудно осуществлять контроль над изменениями кода
11. Трудно производить обзор кода с коллегами программистами
12. Трудно обсуждать код с не-программистами


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Январь, 2017 06:16 

Зарегистрирован: Пятница, 15 Апрель, 2016 11:38
Сообщения: 118
Откуда: из СССР
Извините, но не могу с Вами согласиться.

А что и какие средства способны облегчить написание, общение как в своем кругу так и с не специалистами по большим проектам как не ИДЕ уровня Эклипс (NetBeans, Idea, etc.)?

Вы серьезно уверены, что текстовое представление скажем прямо "средненького" класса объемом в 1500строк (это как правило 1 файл) в виде одного графического файла на визуальном языке (любом!) будет "смотреться лучше"? Каких размеров потребуется "экран"? Или на отображение его 15-30 методов потребуется 15-30 схем-силуэтов И плюсом несколько и разного вида схем "взаимосвязи" методов и свойств класса промеж собой.. это точно "удобнее" в просмотре/общении?

Да и кстати, какие визуальные языки предлагают ТАКОЙ же набор средств "автоматизации" разработки как ИДЕ типа Эклипс? В частности:
1. Подсветка синтаксиса, автоформатирование кода .. как-бы есть или востребовано в существенно меньшей степени;
2. Автопоиск и автодонабор имен переменных .. сильно облегчает жизнь проектах больше "демонстрационных примеров" .. есть, в каком визуале?;
3. Автоматический контроль типов данных, параметров и т.д. .. где?
4. Возможность поиска всех вхождений данного символа (объекта, метода, свойства, переменной) по всему проекту .. есть, где?
5. Возможность быстрого перехода к месту определения символа .. тоже интересно где?
6. Контроль инициализации переменной, свойства .. тоже нет или я так и не нашел ни в одном "визуальном" средстве.. есть?

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

Исключительно как пример:
1. Была в моей практике такая железка как Д3-28, которая программировалась .. "автокодом", то бишь коды команд надо было заносить цифирьками в память компьютера .. ну не требовалось в общем-то что-то сложнее. Но, память росла и доросла до 128кбайт, добавлялась периферия .. и стало "сложновато". Сел делать Ассемблер-реассемблер (в эксплуатации с 1986 по 2001гг включительно). Разработка 8-и килобайтного кода у меня заняла 6 месяцев на "обдумывание" и написание на бумажке отдельных алгоритмов + 2 месяца на .. программирование. Точнее на процесс "переноса" программы в этот "калькулятор".
2. На базе этого Ассемблера-Реассемблера взялся делать компилятор с Ада .. недоделал, но не суть. Так вот, с его помощью синтаксический анализ и часть семантического анализа были написаны за .. 3мес. Сколько бы я возился без такового - даже не могу себе представить.
3. PHP-сайт, содержащий простенькую СРМ систему для работы сотрудников фирмы (Десяток use-case страниц + REST-Full api + СУБД таблиц на 30-40), с использованием готовых библиотек, скажем Yii (Zend, etc) + angular (JQuery, bacbone, etc) можно накатать за пару недель-месяц. И это с тестированием, документированием и дизайнерской версткой кода .. а на специальных библиотеках типа JUMLA интернет-магазин пишется так и вообще за "пару часов" в нормальной ИДЕ...

Так точно что нет никакой разницы и ИДЕ не помогают в разработке или я Вас неверно понял? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Январь, 2017 17:57 

Зарегистрирован: Четверг, 02 Июль, 2015 13:47
Сообщения: 35
Цитата:
А что и какие средства способны облегчить написание, общение как в своем кругу так и с не специалистами по большим проектам как не ИДЕ уровня Эклипс (NetBeans, Idea, etc.)?


Да, я и сам работаю на Eclipse много лет, но совершенно не знаю всех его функций, используя довольно ограниченный набор для совершения операций, необходимых для работы проекта. И конечно, Eclipse работает очень хорошо, все можно сделать. Неудивительно, учитывая огромный опыт вложенный в его разработку начиная с IBM Visual Age.

Цитата:
Вы серьезно уверены, что текстовое представление скажем прямо "средненького" класса объемом в 1500строк (это как правило 1 файл) в виде одного графического файла на визуальном языке (любом!) будет "смотреться лучше"?


C файлом в 1500 строк кода работать трудно.
Допустим, весь наш проект - один такой файл.

1. Окрываем его из Project explorer щелчком мыши. Что видим? Первые 30 строк, некоторые из которых не умещаются по ширине, потому не видим их окончания. Лучше чем ничего, к примеру import's свернуты, показаны одной первой строкой, ведь простой текстовый редактор показал бы только начало неинтересного списка из import's на первом экране.

2. Подсвечено большое количество слов, таких как package, import, public, class, static, void, final, throws. Часто они не имеют никакого отношения к главному алгоритму, мясу так сказать в пироге этого файла.

3. Линейки прокрутки, scroll bars - логически они работают хорошо для перемещения куда угодно. А практически получается много щелчков мыши или долгое таскание ползунка для того чтобы перейти из одного места в другое. При этом у нашего коллеги может закружится голова, особенно когда для того чтобы показать что происходит в коде нужно перетащить ползунок 10 раз, каждый раз полностью уничтожая тот кусок, который мы только что видели на экране в течение нескольких минут, демонстрируя ползущий и мелькающий рывками с разной скоростью текст, который он пытается читать, не зная, когда же мы найдем глазами искомый текст, который может появиться в любом месте экрана.

4. Чаще всего файл содержит несколько методов, которые вызывают друг друга. Нужно 10 раз ткнуть, иногда control+ткнуть и выбрать из подкласса, чтобы увидеть что происходит, опять таки строго "по одному", в строго определенной последовательности. Посмотрим на другой use case, ткнем еще 10 раз, но в другой последовательности. Заблудиться довольно легко.

5. Можно конечно искать control+f, control+h , но нужно 10 раз нажать, чтобы посмотреть по одному все найденные места.

6. И вот мы покрутили линейки прокрутки, понажимали на вызываемые методы, поискали - отличная работа, приятная усталость. Зато теперь возможно в голове у нас гораздо лучшее преставление об этом коде, некоторые его элементы мы запомним даже на долгие годы. Тогда как другие элементы можем и проигнорировать совершенно, а вернуться туда куда надо для того, чтобы взглянуть еще раз не так-то просто.

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

Цитата:
... и стало "сложновато"
... Разработка ... заняла 6 месяцев + 2 месяца
... недоделал
... 3 мес


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Январь, 2017 20:02 

Зарегистрирован: Пятница, 15 Апрель, 2016 11:38
Сообщения: 118
Откуда: из СССР
В Эклипсе, как и других мультиплатформенных средах, да уже и не только в них, любой код метода, комментарий можно свернуть и увидеть на экране (у меня влезает около 60строк ваще-то) все те самые 30-40 методов такого класса весом в 1500, а то и более байт.

Если весь проект состоит из одного такого класса, то разговор ни о чем. Проекты, с которыми работаю последнее время содержат по 30-50 подкаталогов, в каждом из которых по 20-50 таких классов. И это, ещё раз "не предел". Вот с классами, в файлах по 10-15тыс. строк .. Эклипс да, начинает существенно тормозить на 4-х ядерном 3.2Мгц компе с 8 гектарами оперативной памяти, поэтому предпочитаю иные ИДЕ и почти не работаю в Эклипс, есть лучше, по крайней мере на мой вкус и предпочтения, но они - платны (благо дело "контора платит"). впрочем, это по большей части дело вкуса и привычки, ибо многие среды имеют практически все что требуется для серьезной работы.

Далее, разворачивая метод, в подсветке увидим выделенным ровно то, что хотим подсветить (настраивается на раз). Надо служебные слова - пожалуйста, надо имена переменных, вызванных методов, внешних процедур .. тоже можно выделить их, наоборот затенив ключевики.
Надо разложить все с отступами? Легко. Настраиваемое автоформатирование кода вам в помощь.
Надо перейти на динамически вызванный метод? Жмем кнопку класса в автодокументированном комментарии(! не коде!) и переходим в его класс. Кстати, в отдельном окне можно видеть все его свойства, переменные и т.д..
Хочется увидеть все места где этот метод, переменная вызваны/использованы в большом проекте? Точно также - одно нажатие мышкой или комбинации клавиш.
Хочется увидеть кто такой умный вчера тут правил? Опять же тычемся мышкой и получаем описание последнего коммита в репозиторий: автор, дата, пояснения, что конкретно изменил и надо ли всё вернуть "взад"
А также легко в том же ИДЕ имеем прямой доступ к коду на нескольких языках, доступ к структуре и содержимому вашей БД, хоть на Мускуле, хоть на Сибейз или оракле .. богатый набор драйверов, подключаемся и работаем как через специализированную ИДЕ. Принципиальных отличий нет.

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

Так всеж-таки .. какого размера требуется экран для представления визуальным средством класса на 1500 строк и 30-40 методов (50 строк на метод)? :)
...
В то время и на той машине, никаких "ИДЕ" не существовало "в принципе", кроме этого самописного Ассемблера-реассемблера .. да и он тянул разве что на примитивный блокнот. Но, я привел соотношение трудозатрат на его написание и написание с его помощью .. разница очень велика. По крайней мере сам факт того, что он проработал в боевом применении вплоть до 2001г и "ушел вместе с машиной".

Но, Вы не ответили на поставленный вопрос: какого размера должен быть экран или что там, чтобы отобразить такой класс в визуальной среде разработки? 2х2 метра? Больше? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Январь, 2017 21:38 

Зарегистрирован: Четверг, 02 Июль, 2015 13:47
Сообщения: 35
Цитата:
какого размера должен быть экран или что там, чтобы отобразить такой класс в визуальной среде разработки?

Смотря какую программу использовать для отображения 1500 строк кода. Если Eclipse, то с 1 экраном в 60 строк, нужно 25 таких экранов, получаем 60 см в ширину, 10 метров в высоту. Другой вариант: 3 на 2 метра, если экраны поставить 5 на 5. Тогда мы увидим весь код модуля в Eclipse в виде столбцов. Контора платит, потому что даже такой большой экран дешев по сравнению с годами разработки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Январь, 2017 23:15 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 472
Вроде бы хорошо Arhat109 хвалит современные IDE. Правильно.
Можно классики рефачить, к определению методов переходить...
Но только вот нет щастья. :(

А почему?

А потому, что программа состоит не из классов.
Программа состоит из входа, канала обработки и выхода.
Во вход поступают данные и сигналы. Потом они проходят через канал обработки. И наконец, они (данные и сигналы) выходят из выхода.
Обратно через канал обработки идёт обратная связь.
Это основной принцип. Он прослеживается во всех программах, что я видел.

Пример 1: сервер с веб-сервисом.
Вход: обработчик HTTP-запросов.
Канал обработки: JSON-парсер, код авторизации, flood-gate, бизнес-логика, данные в памяти, данные в базе данных.
Выход: данные в памяти, данные в базе, журнал. Обратная связь поступает опять же в обработчик HTTP-запросов.

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

Петля прямой и обратной связи - это букварь, элементарное ку. Основы системного подхода.
Этого в современных IDE нет!

Я спрашиваю авторов IDE:
1. Как найти входы?
2. Как найти выходы?
3. Как проследить движение команд и данных через систему?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Январь, 2017 05:33 

Зарегистрирован: Пятница, 15 Апрель, 2016 11:38
Сообщения: 118
Откуда: из СССР
Этого - нет, согласен. Разве что интегрированные UML средства .. но и они "не айс". Мне кажется, что в этом плане ДРАКОН - лучше охватывает часть вопросов по диаграммам действия.

P.S. Хвалить взялся, поскольку не была развернута претензия к современным ИДЕ. Можно совместить тезисы в защиту и первоначальные претензии:

IDE не облегчают, а затрудняют работу разработчиков в следующих важных случаях:

1. Маленькая программа, которая печатает "Привет, мир!", неплохо выглядит в Eclipse. А с большим, длинным файлом с тысячами строк кода работать трудно.

.. значительно легче чем без ИДЕ .. (может есть где ещё лучше, но тогда требуется уточнение автора)

2. Чаще всего больших файлов еще и много, а со многими файлами работать еще труднее, чем с одним
.. см. выше. труднее, как и со всяким бОльшим делом. Не зависит от ИДЕ или вообще средства, "общее утверждение" ..

3. Трудно понимать конструкции языка программирования, такие как if, if/else, if/if, try/catch/finally
.. это не так ..

4. Трудно проследить вызовы методов
.. это не так ..

5. Трудно проследить код и вызовы, относящиеся к данному use-case или тикету Jira
.. зависит от точности формулировки в багтрекерах, самого багтреккера и авторах формулировок, вопрос шире чем претензия к ИДЕ ..

6. Трудно просмотреть результаты поиска кода, нужно нажать на каждое попадание, а их может быть много
.. не обязательно. Можно рассмотреть "весь список", можно получить аннотации по найденному "где" оно найдено, без тыканий. Вчера замерил: PHP Storm выдача из 250 попаданий анализируется примерно за 1-3 минуты в незнакомом проекте, что полезно, что взято из сторонних библиотек и к вопросу не отностится". Как-то так.

7. Трудно взять трассировку стека исключительной ситуации и определить ее причину
Отладочные комплекты в разных ИДЕ могут существенно различаться как от ЯВУ, так и быть вообще заменены иным плагином. Тут не в курсе, ибо этой стороной ИДЕ давно не пользовался за ненадобностью (правильное написание кода практически исключает процесс отладки)

8. Трудно работать и с Java и с JavaScript в одном проекте
.. это не так ВОВСЕ. Наиболее общие тут как раз PHP-IDE имеют одинаково развитые средства для: PHP, JS, JAVA, SQL, HTML, CSS, JSON, XML и др. Могут автоконтролировать изменения сторонних библиотек и выкачивать их обновления самостоятельно, поддерживая актуальную версию в разработке Composer, etc. ..

9. Трудно смотреть на значения переменных времени выполнения
.. вопрос организации процесса отладки. С/С++ поддержка в ИДЕ меня устраивает "более чем". ..

10. Трудно осуществлять контроль над изменениями кода
.. нет! Очень легко. Поддержка практически всех версий репозиториев от старых SVN до супер новых и распределенных типа GIT, сильная помощь в слиянии одновременных изменений merge, ведении и временном переключении веток, одновременная разработка в нескольких ветках (ой, а можно тут по-быстрому вставить - легко), а также кто делал, что делал, когда делал ..

11. Трудно производить обзор кода с коллегами программистами
.. не понято что трудного с коллегами. Прямо сейчас работаю над очень небольшим проектом на ПХП из 10-ка каталогов по 10-30 файлов по 800-2000 строк кода. Простенькая CRM-система, Yii2.0 + angular1.5 + ещё 3-5 сторонних библиотек по мелочи (не входит в указанный объем, лежит отдельно), примерно 20-30 use-case "итого". Полноценный фасетный поиск по 28-и параметрам главной сущности и примерно половины подчиненных сущностей БД (около 10 таблиц) + подчинение 2-го уровня, реализовано на Yii + прямая табличная верстка без angular сделано за .. 3 дня, если не считать времени ознакомления с этой частью Yii 2.0 (+2 дня). Да, надо сказать что автор, то бишь коллега уволился не оставив в коде ни одного комментария. Разбор незнакомого исключительно силами ИДЕ и краткому "напутственному рассказу". Если бы не мощь ИДЕ .. в какой стадии "охвата проекта" я бы находился сейчас? Прошел месяц. :)

12. Трудно обсуждать код с не-программистами
.. с не программистами КОД - обсуждать незачем. Вот так категорично. С ними можно обсуждать алгоритмы в самом общем виде, структуры данных, способы взаимодействия "входы/выхода" программы с внешними, "непрограммными устройствами", в т.ч. и "пользователями" и т.д.

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

P.S. Даже больше скажу в защиту современных средств разработки ПО: я, начинавший когда-то давно в цифре, да ещё и двоичной, потом освоивший перфокарты и перфоленты .. клавиатур не было .. потом пересевший за клавиатуру и монитор .. во время моих трудовых будней появились и С++, и JAVA и много чего ещё ..

Сейчас, считаю что профессия программист практически полностью утрачена разрабами в возрасте от 30 лет и младше ИСКЛЮЧИТЕЛЬНО благодаря развитым инструментам и средствам поддержки процесса разработки. Современный программист - это просто пользователь таких систем, зачастую даже не вникающий ни в их организацию, ни в "сторонние библиотеки", которые сообщество программистов производит с просто чудовищной скоростью.

И это хорошо видно по вакансиям: посмотрите кто требуется? А ровно те, кто отлично знает и имеет опыт .. средства разработки, те или иные библиотеки и т.д. Кому сейчас нужны вопросы правильной алгоритмизации, оптимизации кода, правильного проектирования, написания программ не требующих тестирования, разве что на синт. ошибки, которые в ИДЕ и совершить то не так просто .. а НИКОМУ. Автоматика ПО для разработчиков сделает это всё за него. По сути разработку сейчас ведет само ИДЕ, а программист .. он так, кнопки жать. Да даже типовые интерфейсы crud можно ваять автоматически, тыкая кнопки "надо чтобы было это и то и связывалось с этим вот так"..

P.P.S. Извиняюсь за многа букв .. старею видимо. Наболело.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Январь, 2017 09:47 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3784
Откуда: Москва
Arhat109 писал(а):
P.P.S. Извиняюсь за многа букв ... Наболело.
Владимир, спасибо за ваш подробный комментарий.
Тема сложная. Тема новая.

Ее нужно очень подробно, тщательно и аргументированно обсуждать.
Владимир, еще раз спасибо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Январь, 2017 10:32 

Зарегистрирован: Пятница, 15 Апрель, 2016 11:38
Сообщения: 118
Откуда: из СССР
Перечитал тему ещё раз. Ну .. видимо слишком категорично взялся защищать современные ИДЕ поскольку не заметил что претензии не столько к их функционалу, сколько это больше не претензии, а даже пожелания как УЛУЧШИТЬ ИДЕ.

Поддержу Степана Митькина полностью: да, в современных ИДЕ нет инструментов для отслеживания потока исполнения "от входа до выхода". Достаточно часто приходится тратить существенную часть времени на поиск "откуда ноги растут" и того или иного тикета в багтреккерах, как раз по причине сложного процесса розыска входа-выхода.

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

Мне кажется что задача решаема:
1. На уровне класса есть его детальное описание, оно содержит автодокумент, его понимает ИДЕ .. собрать описания и на их основе построить списки где тут входы и что на выходе;
2. На уровне приложения всегда есть точки входа (main к примеру для С/С++), для клиент-сервер точно также есть свои "точки входа" .. и "выход" часто находится там же где и вход;
3. Некоторую сложность представляют исключения, но и они по телу файлов достаточно хорошо расписаны и парсятся (ИДЕ все равно строит дерево сущностей и зависимостей).

Можно ли на этом знании построить визуальное представление?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Январь, 2017 13:52 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 776
Язык Дракон, как и любая идея, не поможет Java-программистам в решении их бед.
Скорее всего лишь их отвлечет от решения бед.

Надежда только на существующие инструментальные среды на основе Дракона.
Инструментальные среды и надо обсуждать с точки зрения Java-программиста и его общения с заказчиком, разработчиком (постановщиком) и пользователем программного обеспечения.

Примером опоры на ИС Дракон является деятельность А.А. Араптанова и С.Д. Ефанова.
Олег Гарипова предлагает свою инструментальную среду.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Январь, 2017 17:30 

Зарегистрирован: Четверг, 02 Июль, 2015 13:47
Сообщения: 35
Arhat109 писал(а):
2. Чаще всего больших файлов еще и много, а со многими файлами работать еще труднее, чем с одним
.. см. выше. труднее, как и со всяким бОльшим делом. Не зависит от ИДЕ или вообще средства, "общее утверждение" ..


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

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

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

Получается - IDE показывает экран с кодом, но это совсем не то, что нам сейчас нужно.
А для того, чтобы показать то что нужно, есть тысячи команд в главном и контекстном меню и подменю разнообразных элементов IDE, точное знание того, как и в какой последовательности применить эти действия 10'ки раз с вариациями, именно в этом проекте со всеми его особенностями, чтобы ответить на один простейший вопрос о движении через канал обработки, описанном Степаном.

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

Выстраиваются закладки с именами файлов - в том порядке, в котором мы дабл-кликали при открытии кажется, то есть произвольном.
Просматривая код, нужно скакать между закладками точными тычками мыши, точно зная в какое место кода приведет тычок на ComponentManager, а не на ControllerFactory, после дальнейшего точного скроллинга конечно.
Есть конечно alt+стрелка влево, вернуться назад, алт+стрелка вправо вперед - но только в 1 последовательности, чаще всего не такой, как ожидаемая, то есть неудобной.
Если файлов больше 10'ка, все их имена становится не видно сразу, закладки свертываются, а в ведь в нашем проекте много файлов, сотни!

Каждый раз дважды нажав на один файл, он выскакивает так, чтобы затмить собою все доселе виденное на экране.
Можно конечно растащить 2 окошка и увидеть код в 2 файлах одновременно, но при этом в каждом окошке - только 1 порция из 30 строк, позиция ползунка скачет туда сюда, и к тому же он обладает всеми недостатками для 1 файла, рассмотренными выше.
Растащить 4 окошка можно, но они становятся слишком маленькими. А 10 окошек? Попробуйте сделать это в Eclipse вживую, при обсуждении кода с менеджером, начальником бизнес систем и CТO, и не забудьте сделать селфи для форума drakon.su во время овации.

Один разработчик образно описал работу в IDE так: "Я в глухом дремучем лесу ночью с малюсеньким фонариком, пытаюсь разобраться, как соединены корни и деревья".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Январь, 2017 19:00 

Зарегистрирован: Пятница, 15 Апрель, 2016 11:38
Сообщения: 118
Откуда: из СССР
Миссия невыполнима, ибо нельзя впихнуть невпи*мое, ж извините за вольный пересказ Козьмы Пруткова. За сим - откланиваюсь.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 17 Январь, 2017 22:58 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 472
Arhat109 писал(а):
Можно ли на этом знании построить визуальное представление?

Думаю, можно. Допустим, у нас есть некий компонент Ларёк.

В нём есть процедуры, которые среда распознаёт как входы:
- публичные методы
- возвращаемые лямбды/callback'и
- callback'и, пропихивыемые в другие компоненты

Есть объекты, которые среда распознаёт как выходы:
- ссылки на посторонние компоненты
- внутренние объекты, имеющие ссылки на посторонние компоненты
- callback'и, принимаемые от других компонентов

Есть внутренние, приватные алгоритмы.
Есть структура данных (без излишних классовых границ).

Вложение:
20170117204131.png
20170117204131.png [ 69 КБ | Просмотров: 7724 ]

Каналы обработки можно просматривать двумя способами:
1. Начиная со входов.
2. Начиная с выходов.
Вот пример разбора начиная со входа:
Вложение:
20170117204123.png
20170117204123.png [ 71.5 КБ | Просмотров: 7724 ]

Тут главное что: никогда выход не прячется внутри вызова метода.
Выходов много, и они все торчат.

Диаграммы лежат тут:
https://drakon-editor.com/ide/doc/examples/41


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Январь, 2017 07:57 

Зарегистрирован: Пятница, 15 Апрель, 2016 11:38
Сообщения: 118
Откуда: из СССР
Здравая идея и может помочь улучшить ИДЕ в целом и разработку сложных приложений.

.. но перечитайте вдумчиво вчерашний пост автора темы! При росте проекта Вы услышите ровно тоже самое: "дерево исполнения слишком велико и не вмещается в экран .. приходится тыкать скроллер многа раз чтобы охватить незначительную часть всего древа .. на экране умещается только первые 5-10 выходов, а за остальными надо снова крутить скроллер .. в проекте много схем исполнения и они собраны в визуальную схему-каталог, которую надо тыкать кнопкой, чтобы развернуть то или иное поддерево схем и в нем прокрутить скроллер чтобы добраться до последней схемы в поддереве и так каждый раз.."

Миссия невыполнима2. :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Январь, 2017 09:09 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 230
Откуда: Россия, Стерлитамак
"Разделяй и властвуй" с
Просто надо теги/подсистемы/слои использовать и фильтровать. Вряд ли в этом случае будет много входов/выходов


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Январь, 2017 09:42 
Аватара пользователя

Зарегистрирован: Среда, 09 Ноябрь, 2016 00:33
Сообщения: 98
Откуда: Tallinn
описание блоков, входов и выходов это уже метауровень, поэтому я скажем и начал в проекты пихать майнд мапы которые позволяют описать данное и иметь линки на конкретные файлы имплементирующие и входы и выходы


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Январь, 2017 10:06 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 472
adva писал(а):
Просто надо теги/подсистемы/слои использовать и фильтровать.

Рад, что проблема решена. Поделитесь, как именно!
Приведите, пожалуйста, примеры.

Цитата:
поэтому я скажем и начал в проекты пихать майнд мапы которые позволяют описать данное и иметь линки на конкретные файлы имплементирующие и входы и выходы

Очень нужны ваши примеры. Пожалуйста, поделитесь опытом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 18 Январь, 2017 10:55 
Аватара пользователя

Зарегистрирован: Среда, 09 Ноябрь, 2016 00:33
Сообщения: 98
Откуда: Tallinn
Цитата:
Очень нужны ваши примеры. Пожалуйста, поделитесь опытом.

ну к примеру вот майнд мап от небольшого фреймворка для парсинга бинарных файлов, майнд мап позволяет описать функциональные места и дать ссылку на них в поекте (они обозначены как дискетки и при клике на них в проекте открывается нужный файл), позволяет быстро понять что в проекте к чему и с чем связано, так же Гертъян Виленга из оракла сделал видео на тему https://youtu.be/7TUU25dsOfM


Вложения:
jbbp.png
jbbp.png [ 90.68 КБ | Просмотров: 7705 ]
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 45 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2018, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB