Сообщение Re[2]: Опять поднимают про low-code и помоечку для средняков от 17.09.2021 6:43
Изменено 17.09.2021 6:44 vdimas
Re[2]: Опять поднимают про low-code и помоечку для средняков...
Здравствуйте, Shtole, Вы писали:
S>Таким макаром можно разве что из хороших инструментов для разработчика получить плохие инструменты для разработчика.
Но хорошие для продвинутого юзера, каким стал конструктор 1С.
Программисты должны пилить кубики для таких конструкторов.
S>ЯП тупо лучше для записи алгоритмов.
Это если приходится сражаться тупо с шириной бит типов данных, лейаутом данных в памяти и прочей низкоуровневостью.
Если нет — то любой ЯП будет хуже обычного какого-нить графического симулятора, типа Simulink, графического редактора шейдеров и т.д.
S>Тут нужен совершенно другой подход.
Ничего другого, кроме автоматизации рутины, человек пока не придумал для повышения производительности своего труда.
S>Как говорят ТРИЗовцы: идеально, когда объекта нет, а выполняемая работа есть.
В инженерии базовые объекты должны быть готовы, внесены в номенклатуру, уметь легко стыковаться м/у собой.
S>Не надо грузить пользователя алгоритмами.
Ему их можно выдать готовыми. Пользователь пусть ползунки настроек крутит.
S>юзер формулу записывает в Экселе — он разве думает, что там какой-то алгоритм под капотом?
Формула — это уже алгоритм.
S>Нужны просто офисные продукты новых поколений. Не с таким дебильным UI, как сейчас.
Нормальный UI.
У тектового процессора лист бумаги, у электронной таблицы, неожиданно, таблица.
S>Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига».
Заблуждения...
Взять обычный MS Word 2013, как-то за примерно 40 минут накидал на ём всю графику на этой картинке:
http://files.rsdn.org/21096/MusicFX.png
Просто бросаешь примитивы, крутишь им рукоятки, "фотографируешь" экран, следующий.
Современные игровые движки взять — тоже сплошные готовые "кубики".
А взять какой-нить Архикад, где параметрические BIM-объекты можно описывать без программирования (еще лет 5 назад я немного упражнялся в программировании на GDL-языке), теперь это в прошлом. На приемлимом уровне первым это сделал Grasshopper, пощёлкай по видео ниже, посмотри на процесс "программирования" непрограммистами:
https://www.youtube.com/watch?v=uf0QhN1bZ2o
Это именно программирование, описание алгоритма.
Аналогичные системы есть не только для графики, есть для цифровой обработки звуков, а оно потенциально обобщается до цифровой обработки любых сигналов и т.д.
S>Таким макаром можно разве что из хороших инструментов для разработчика получить плохие инструменты для разработчика.
Но хорошие для продвинутого юзера, каким стал конструктор 1С.
Программисты должны пилить кубики для таких конструкторов.
S>ЯП тупо лучше для записи алгоритмов.
Это если приходится сражаться тупо с шириной бит типов данных, лейаутом данных в памяти и прочей низкоуровневостью.
Если нет — то любой ЯП будет хуже обычного какого-нить графического симулятора, типа Simulink, графического редактора шейдеров и т.д.
S>Тут нужен совершенно другой подход.
Ничего другого, кроме автоматизации рутины, человек пока не придумал для повышения производительности своего труда.
S>Как говорят ТРИЗовцы: идеально, когда объекта нет, а выполняемая работа есть.
В инженерии базовые объекты должны быть готовы, внесены в номенклатуру, уметь легко стыковаться м/у собой.
S>Не надо грузить пользователя алгоритмами.
Ему их можно выдать готовыми. Пользователь пусть ползунки настроек крутит.
S>юзер формулу записывает в Экселе — он разве думает, что там какой-то алгоритм под капотом?
Формула — это уже алгоритм.
S>Нужны просто офисные продукты новых поколений. Не с таким дебильным UI, как сейчас.
Нормальный UI.
У тектового процессора лист бумаги, у электронной таблицы, неожиданно, таблица.
S>Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига».
Заблуждения...
Взять обычный MS Word 2013, как-то за примерно 40 минут накидал на ём всю графику на этой картинке:
http://files.rsdn.org/21096/MusicFX.png
Просто бросаешь примитивы, крутишь им рукоятки, "фотографируешь" экран, следующий.
Современные игровые движки взять — тоже сплошные готовые "кубики".
А взять какой-нить Архикад, где параметрические BIM-объекты можно описывать без программирования (еще лет 5 назад я немного упражнялся в программировании на GDL-языке), теперь это в прошлом. На приемлимом уровне первым это сделал Grasshopper, пощёлкай по видео ниже, посмотри на процесс "программирования" непрограммистами:
https://www.youtube.com/watch?v=uf0QhN1bZ2o
Это именно программирование, описание алгоритма.
Аналогичные системы есть не только для графики, есть для цифровой обработки звуков, а оно потенциально обобщается до цифровой обработки любых сигналов и т.д.
Re[2]: Опять поднимают про low-code и помоечку для средняков
Здравствуйте, Shtole, Вы писали:
S>Таким макаром можно разве что из хороших инструментов для разработчика получить плохие инструменты для разработчика.
Но хорошие для продвинутого юзера, каким стал конструктор 1С.
Программисты должны пилить кубики для таких конструкторов.
S>ЯП тупо лучше для записи алгоритмов.
Это если приходится сражаться тупо с шириной бит типов данных, лейаутом данных в памяти и прочей низкоуровневостью.
Если нет — то любой ЯП будет хуже обычного какого-нить графического симулятора, типа Simulink, графического редактора шейдеров и т.д.
S>Тут нужен совершенно другой подход.
Ничего другого, кроме автоматизации рутины, человек пока не придумал для повышения производительности своего труда.
S>Как говорят ТРИЗовцы: идеально, когда объекта нет, а выполняемая работа есть.
В инженерии базовые объекты должны быть готовы, внесены в номенклатуру, уметь легко стыковаться м/у собой.
S>Не надо грузить пользователя алгоритмами.
Ему их можно выдать готовыми. Пользователь пусть ползунки настроек крутит.
S>юзер формулу записывает в Экселе — он разве думает, что там какой-то алгоритм под капотом?
Формула — это уже алгоритм.
S>Нужны просто офисные продукты новых поколений. Не с таким дебильным UI, как сейчас.
Нормальный UI.
У тектового процессора лист бумаги, у электронной таблицы, неожиданно, таблица.
S>Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига».
Заблуждения...
Взять обычный MS Word 2013, как-то за примерно 40 минут накидал на ём всю графику на этой картинке:
http://files.rsdn.org/21096/MusicFX.png
Просто бросаешь примитивы, крутишь им рукоятки, "фотографируешь" экран, следующий.
Современные игровые движки взять — тоже сплошные готовые "кубики".
А взять какой-нить Архикад, где параметрические BIM-объекты можно описывать без программирования (еще лет 5 назад я немного упражнялся в программировании на GDL-языке), теперь это в прошлом. На приемлимом уровне первым это сделал Grasshopper, пощёлкай по видео ниже, посмотри на процесс "программирования" непрограммистами:
https://www.youtube.com/watch?v=uf0QhN1bZ2o
Это именно программирование, описание алгоритма.
Аналогичные системы есть не только для графики, есть для цифровой обработки звуков, а оно потенциально обобщается до цифровой обработки любых сигналов и т.д.
S>Таким макаром можно разве что из хороших инструментов для разработчика получить плохие инструменты для разработчика.
Но хорошие для продвинутого юзера, каким стал конструктор 1С.
Программисты должны пилить кубики для таких конструкторов.
S>ЯП тупо лучше для записи алгоритмов.
Это если приходится сражаться тупо с шириной бит типов данных, лейаутом данных в памяти и прочей низкоуровневостью.
Если нет — то любой ЯП будет хуже обычного какого-нить графического симулятора, типа Simulink, графического редактора шейдеров и т.д.
S>Тут нужен совершенно другой подход.
Ничего другого, кроме автоматизации рутины, человек пока не придумал для повышения производительности своего труда.
S>Как говорят ТРИЗовцы: идеально, когда объекта нет, а выполняемая работа есть.
В инженерии базовые объекты должны быть готовы, внесены в номенклатуру, уметь легко стыковаться м/у собой.
S>Не надо грузить пользователя алгоритмами.
Ему их можно выдать готовыми. Пользователь пусть ползунки настроек крутит.
S>юзер формулу записывает в Экселе — он разве думает, что там какой-то алгоритм под капотом?
Формула — это уже алгоритм.
S>Нужны просто офисные продукты новых поколений. Не с таким дебильным UI, как сейчас.
Нормальный UI.
У тектового процессора лист бумаги, у электронной таблицы, неожиданно, таблица.
S>Более мощные, рассчитанные на самых продвинутых юзеров. Это, кстати, значит «меньше визивига», а не «больше визивига».
Заблуждения...
Взять обычный MS Word 2013, как-то за примерно 40 минут накидал на ём всю графику на этой картинке:
http://files.rsdn.org/21096/MusicFX.png
Просто бросаешь примитивы, крутишь им рукоятки, "фотографируешь" экран, следующий.
Современные игровые движки взять — тоже сплошные готовые "кубики".
А взять какой-нить Архикад, где параметрические BIM-объекты можно описывать без программирования (еще лет 5 назад я немного упражнялся в программировании на GDL-языке), теперь это в прошлом. На приемлимом уровне первым это сделал Grasshopper, пощёлкай по видео ниже, посмотри на процесс "программирования" непрограммистами:
https://www.youtube.com/watch?v=uf0QhN1bZ2o
Это именно программирование, описание алгоритма.
Аналогичные системы есть не только для графики, есть для цифровой обработки звуков, а оно потенциально обобщается до цифровой обработки любых сигналов и т.д.