Нюанс в том, что человек, объясняющий некоторые вещи через религию, будет выполнять неверные действия, которые невыгодны с точки зрения эволюции. Бог меня бережет, поэтому можно шагнуть в пропасть - упал и разбился
Не понял. Можно было бы подумать (как это ни звучит запредельно цинично), что с точки зрения эволюции, как бы это сказать, нужно иногда обрывать ветки. Или Докинз, как раз, говорит об этом? Объясните, пожалуйста.
Мир остановился в развитии, нет новых технологий, моделей поведения — так что ли? Ведь это новое будет требовать и новых программных решений.
Простите, это, просто, моё собственное восприятие и отношение изменилось. Раньше я был ярый сторонник прогресса. Видел этот прогресс во всём. Теперь всё иначе. Теперь я вижу, что перед бизнесом (скажем так) всегда стояли (и будут стоять) одни и те же задачи. Новизна в чём? Хорошо, раньше был только текстовый интерфейс. (Ну, был распространён. Графический тоже существовал давно.) Были одни ОС-мы, оболочки, системы программирования, сами языки программирования. Теперь у нас только графический интерфейс. Не было сетей. Да! Они появились. Распределённые вычисления, клиент/сервер, трёхзвенная архитектура, BDE, OLE DB, ADO... А теперь ещё нас настиг блокчейн, мобильная разработка (привет старым-добрым мейнфремам и подключенным к нему тонким клиентам!). Да ещё и ИИ подкатил. Подкатил, так подкатил! (с)
Мы с Вами сильно расходимся в том, на что обращаем внимание. Вы видите больше динамическую составляющую, на процесс, на прогресс. Я же пытаюсь найти нечто постоянное в этом бурно меняющемся мире, некий инвариант, самосохраняющуюся структуру. Когда новое оказывается хорошо забытым старым. Например.
Мне никто ещё не ответил на вопрос, зачем программисты тратили множество человеко-часов на создание разного рода библиотек. И, кстати, продолжают создавать! Я смутно вспоминаю ещё библиотеку Turbo Professional (которая быстро на глазах трансформировалась в Object Professional) времён Turbo Pascal 5.0 и 5.5. Потом пришла библиотека Turbo Vision. Думаю, до сих пор можно найти программы, написанные на ней. Потом пришёл графический интерфейс, а с ним и OWL. И где теперь OWL? Довольно заметный след оставила библиотека VCL, но и этому пришло на смену DOTNET, ASP... А сейчас? Постоянно предлагаются новые программные решения. Постоянно появляются новые названия и аббревиатуры. Но задачи-то прежние! Как нужна была складская/торговая система, так и будет нужна. библиотеки, образовательные ресурсы, банковские приложения.
В чем же развитие? Почему нельзя один раз написать код и потом его всё время использовать? Кто-нибудь объяснит? Зачем писать код, который потом будет выкинут, потому что найдётся, видать, новое программное решение? А в чём новизна данного решения? В новых обстоятельствах и действующих лицах (включая web)? Почему, вообще, приходится что-то переписывать? Ведь главный источник затягивания любых сроков — это лавинообразное "наплывания" нового кода, который всё-время приходится писать. Можно ли действовать иначе, вот в чём вопрос.
Это какая такая наука? И это как получается — у вас будут тысячи и миллионы языков?
На западе эту науку называют Computer Science. И в рамках этой науки давно-давно установлено, что разработка приложений заключается в создании специализированного языка. Раньше под каждую задачу создавался свой язык. Для алгоритмического обеспечения — Алгол и подобные ему языки, для символьных вычислений — Рефал, для реализации математического обеспечения — Фортран. При этом, возникали разновидности, которые позволяли более эффективно решать частные задачи: Модула и Ада — модульность. Потом, ещё есть языки функционального программирования, в основу которых кладуться определённые идеи и понятия — понятия списка (Лисп), понятия рекурсивной функции (Форт), понятия категории (Хаскел)...
Сегодня мы видим засилие языков программирования общего назначения, в которых вся мощь переносится на библиотеки, предназначенные для решения частных задач. А Вы можете представить специализированные языки, созданные, например, отдельно для представления и управления пользовательским интерфейсом? Необходимость в таких языках побуждает вводить новые элементы в существующие языки, что не только утяжеляет сами языки (их компиляторы), но и затрудняет их изучение. И всё это — вместо того, чтобы создавать новые языки. В результате, всё-таки появляются новые технологические решения, но это уже задним числом. Современное программное обеспечение — это лоскутное одеяло.
Почему нужны различные языки программирования? Это можно ещё объяснить и так. Допустим, мы хотим создать систему. В обычной ситуации мы берём какой-то язык программирования и создаём на нём весь необходимый код. Вот он лежит в виде набора текстовых файлов, достаточно запустить транслятор, и приложение готово. А теперь добавьте сюда один промежуточный язык программирования — язык, на котором Вы описываете систему. Так вот, это описание — основа основ — "скармливается" транслятору на код целевой машины. Таких трансляторов может быть много — под разные вычислительные архитектуры, разные практические нужды. Это можно сравнить со схемой базы данных: на концептуальном уровне у вас имеются определённые объекты и определённые отношения между ними, на логическом уровне возникают таблицы и уже отношения между таблицами, но уже на физическом уровне определяется, как именно реализуется то или иное отношение. Так и при разработке системы, Вы не обязаны кодировать систему непосредственно в конечном виде. Например, вы знаете, что здесь должна быть переменная, но не знаете какая (какого типа). Вы описываете алгоритм обработки в общем виде. В реальности, конечно, Вы будете сразу делать всё в конечном виде. Но, зафиксировав однажды, тип переменной, Вы обречётся себя на большую возню с собственным кодом в случае, если тип переменной поменяется. В случае же разделения языков, вы просто поменяете какие-то опции при трансляции с кода языка верхнего уровня на язык нижнего уровня.
Заметим, что программистские конторы сами создают такое разделение немного искусственным образом, когда пишут внутренние библиотеки, позволяющие генерировать пользовательский интерфейс на лету, разрабатывая специализированный язык метаданных.
Другое дело — вопрос надёжности. Всё-таки, у таких подходов может что-то пойти не туда, "баг" на высоком уровне нанесёт больший урон, чем "баг" на низком уровне, "баг" в слое дополнительной абстракции попросту не даст программе сработать. Так что по старинке предпочитают не заморачиваться с абстракциями и "хардкорят" всё, что только можно. Это понять можно. Но за всё приходится платить. В том числе, и скоростью и непредсказуемостью разработки. Конечно, для создания дополнительного слоя абстракций (например, языка программирования) нужно время. Это правда. Но тут, как говориться, нужны реальные примеры: кто и в какой канторе по каком пути пошёл и к каким результатам пришёл. Однако, история об этом умалчивает. Я очень хотел бы послушать такие истории.
Зачем нужно развитие того, что является по построению достаточно полным?
Обратная совместимость чего с чем?
Межплатформенная совместимость? Этот вопрос исходит из того, что библиотека делается на неоктором существующем языке программирования, в то время, как наука чётко предписывает создание специализированного языка под решение каждой конкретной задачи, и уже трансляцию кода на этом языке к од целевой машины.
А, ведь, что такое интегрирование? Это суммирование измеримых объектов. А как мы получаем измеримые объекты? Правильно! Разбиваем исходный объект на очень маленькие кусочки и аппроксимируем эти кусочки правильными (заведомо измеримыми) объектами. Всего-то и требуется: найти в программировании такие элементарные операции, которые требуют (при прочих равных) заранее известного времени выполнения. Делов-то! ;-7
А Вы можете кратко описать эти приложения (если есть возможность ничего не разглашать)? В чём принципиальная разница между ними? И можно ли найти что-то общее (в плане реализации)?
Стоп. Почему, только 1? Если есть какая-то деятельность, подлежащая автоматизации, то там будет столько сценариев, сколько имеется предметных ситуаций.
Может ли полученное решение выделено в отдельную библиотеку и предоставлено сообществу для решения аналогичных задач?
Была ли возможность попробовать собрать решение на каких-то других библиотеках и технологиях, отличных от тех, которые используются в МТС?
Могут ли полученные результаты распространены вверх по иерархии приложений МТС? (Обобщить подходы и распространить их на решение других вопросов. Если. конечно, это имеет смысл.)
Но какую задачу легче выполнить сейчас, в конце первой четверти XXI века, - написать документацию или код?
Не заглядывая в статью (которая кажется, почему-то, довольно маленькой для такой темы), можно сказать так: одно без другого не существует. Если имеется продукт без документации, то что-то в этом не так. Можно ли сделать продукт. который не требует документации? Трудный вопрос. Наличие документации — это правило хорошего тона. Документации часто просто не хватает. От слова очень.
Не понял. Можно было бы подумать (как это ни звучит запредельно цинично), что с точки зрения эволюции, как бы это сказать, нужно иногда обрывать ветки. Или Докинз, как раз, говорит об этом? Объясните, пожалуйста.
Простите, это, просто, моё собственное восприятие и отношение изменилось. Раньше я был ярый сторонник прогресса. Видел этот прогресс во всём. Теперь всё иначе. Теперь я вижу, что перед бизнесом (скажем так) всегда стояли (и будут стоять) одни и те же задачи. Новизна в чём? Хорошо, раньше был только текстовый интерфейс. (Ну, был распространён. Графический тоже существовал давно.) Были одни ОС-мы, оболочки, системы программирования, сами языки программирования. Теперь у нас только графический интерфейс. Не было сетей. Да! Они появились. Распределённые вычисления, клиент/сервер, трёхзвенная архитектура, BDE, OLE DB, ADO... А теперь ещё нас настиг блокчейн, мобильная разработка (привет старым-добрым мейнфремам и подключенным к нему тонким клиентам!). Да ещё и ИИ подкатил. Подкатил, так подкатил! (с)
Мы с Вами сильно расходимся в том, на что обращаем внимание. Вы видите больше динамическую составляющую, на процесс, на прогресс. Я же пытаюсь найти нечто постоянное в этом бурно меняющемся мире, некий инвариант, самосохраняющуюся структуру. Когда новое оказывается хорошо забытым старым. Например.
Мне никто ещё не ответил на вопрос, зачем программисты тратили множество человеко-часов на создание разного рода библиотек. И, кстати, продолжают создавать! Я смутно вспоминаю ещё библиотеку Turbo Professional (которая быстро на глазах трансформировалась в Object Professional) времён Turbo Pascal 5.0 и 5.5. Потом пришла библиотека Turbo Vision. Думаю, до сих пор можно найти программы, написанные на ней. Потом пришёл графический интерфейс, а с ним и OWL. И где теперь OWL? Довольно заметный след оставила библиотека VCL, но и этому пришло на смену DOTNET, ASP... А сейчас? Постоянно предлагаются новые программные решения. Постоянно появляются новые названия и аббревиатуры. Но задачи-то прежние! Как нужна была складская/торговая система, так и будет нужна. библиотеки, образовательные ресурсы, банковские приложения.
В чем же развитие? Почему нельзя один раз написать код и потом его всё время использовать? Кто-нибудь объяснит? Зачем писать код, который потом будет выкинут, потому что найдётся, видать, новое программное решение? А в чём новизна данного решения? В новых обстоятельствах и действующих лицах (включая web)? Почему, вообще, приходится что-то переписывать? Ведь главный источник затягивания любых сроков — это лавинообразное "наплывания" нового кода, который всё-время приходится писать. Можно ли действовать иначе, вот в чём вопрос.
На западе эту науку называют Computer Science. И в рамках этой науки давно-давно установлено, что разработка приложений заключается в создании специализированного языка. Раньше под каждую задачу создавался свой язык. Для алгоритмического обеспечения — Алгол и подобные ему языки, для символьных вычислений — Рефал, для реализации математического обеспечения — Фортран. При этом, возникали разновидности, которые позволяли более эффективно решать частные задачи: Модула и Ада — модульность. Потом, ещё есть языки функционального программирования, в основу которых кладуться определённые идеи и понятия — понятия списка (Лисп), понятия рекурсивной функции (Форт), понятия категории (Хаскел)...
Сегодня мы видим засилие языков программирования общего назначения, в которых вся мощь переносится на библиотеки, предназначенные для решения частных задач. А Вы можете представить специализированные языки, созданные, например, отдельно для представления и управления пользовательским интерфейсом? Необходимость в таких языках побуждает вводить новые элементы в существующие языки, что не только утяжеляет сами языки (их компиляторы), но и затрудняет их изучение. И всё это — вместо того, чтобы создавать новые языки. В результате, всё-таки появляются новые технологические решения, но это уже задним числом. Современное программное обеспечение — это лоскутное одеяло.
Почему нужны различные языки программирования? Это можно ещё объяснить и так. Допустим, мы хотим создать систему. В обычной ситуации мы берём какой-то язык программирования и создаём на нём весь необходимый код. Вот он лежит в виде набора текстовых файлов, достаточно запустить транслятор, и приложение готово. А теперь добавьте сюда один промежуточный язык программирования — язык, на котором Вы описываете систему. Так вот, это описание — основа основ — "скармливается" транслятору на код целевой машины. Таких трансляторов может быть много — под разные вычислительные архитектуры, разные практические нужды. Это можно сравнить со схемой базы данных: на концептуальном уровне у вас имеются определённые объекты и определённые отношения между ними, на логическом уровне возникают таблицы и уже отношения между таблицами, но уже на физическом уровне определяется, как именно реализуется то или иное отношение. Так и при разработке системы, Вы не обязаны кодировать систему непосредственно в конечном виде. Например, вы знаете, что здесь должна быть переменная, но не знаете какая (какого типа). Вы описываете алгоритм обработки в общем виде. В реальности, конечно, Вы будете сразу делать всё в конечном виде. Но, зафиксировав однажды, тип переменной, Вы обречётся себя на большую возню с собственным кодом в случае, если тип переменной поменяется. В случае же разделения языков, вы просто поменяете какие-то опции при трансляции с кода языка верхнего уровня на язык нижнего уровня.
Заметим, что программистские конторы сами создают такое разделение немного искусственным образом, когда пишут внутренние библиотеки, позволяющие генерировать пользовательский интерфейс на лету, разрабатывая специализированный язык метаданных.
Другое дело — вопрос надёжности. Всё-таки, у таких подходов может что-то пойти не туда, "баг" на высоком уровне нанесёт больший урон, чем "баг" на низком уровне, "баг" в слое дополнительной абстракции попросту не даст программе сработать. Так что по старинке предпочитают не заморачиваться с абстракциями и "хардкорят" всё, что только можно. Это понять можно. Но за всё приходится платить. В том числе, и скоростью и непредсказуемостью разработки. Конечно, для создания дополнительного слоя абстракций (например, языка программирования) нужно время. Это правда. Но тут, как говориться, нужны реальные примеры: кто и в какой канторе по каком пути пошёл и к каким результатам пришёл. Однако, история об этом умалчивает. Я очень хотел бы послушать такие истории.
Не догнать нам черепаху. ;-(
Да. Тяжело стартапу. Стоит один в поле.
Вот и приходится мучиться. Вот бы однажды попытаться что-то-нибудь своё сделать на эту тему...
Теперь понятно, о чём речь. Спасибо за информацию к размышлению.
Не я здесь специалист. Но если я сделаю свою CRM-систему, то стану специалистом. Как-то так.
(в сторону) Меня раскусили. Как теперь жить? ;-?
Зачем нужно развитие того, что является по построению достаточно полным?
Обратная совместимость чего с чем?
Межплатформенная совместимость? Этот вопрос исходит из того, что библиотека делается на неоктором существующем языке программирования, в то время, как наука чётко предписывает создание специализированного языка под решение каждой конкретной задачи, и уже трансляцию кода на этом языке к од целевой машины.
Не (очень) получается, потому, что язык прорапмирования — это не совсем та декомпозиция, которая нужна. Речь идёт о типовых задачах.
И ещё. У меня нет ни лёгкости, ни результата. Я ничего не предлагаю. Лишь констатирую некоторые факты и обстоятельства.
Хотя... было бы здорово что-то предложить дельное, а не только слова.
А, ведь, что такое интегрирование? Это суммирование измеримых объектов. А как мы получаем измеримые объекты? Правильно! Разбиваем исходный объект на очень маленькие кусочки и аппроксимируем эти кусочки правильными (заведомо измеримыми) объектами. Всего-то и требуется: найти в программировании такие элементарные операции, которые требуют (при прочих равных) заранее известного времени выполнения. Делов-то! ;-7
Эту проблему, очевидно, решает готовая библиотека компонентов. Но никто не готов заниматься её созданием. Это и есть настоящая неразрешимая проблема.
Очень интересный вопрос!
Вы не уточните, что Вы понимаете под CRM-системой? Чтобы лучше понимать условия задачи. Будем считать это своеобразным пет-проектом. ;-)
А Вы можете кратко описать эти приложения (если есть возможность ничего не разглашать)? В чём принципиальная разница между ними? И можно ли найти что-то общее (в плане реализации)?
Стоп. Почему, только 1? Если есть какая-то деятельность, подлежащая автоматизации, то там будет столько сценариев, сколько имеется предметных ситуаций.
А почему этим должен заниматься стартап?
Собственно, возникает три вопроса:
Может ли полученное решение выделено в отдельную библиотеку и предоставлено сообществу для решения аналогичных задач?
Была ли возможность попробовать собрать решение на каких-то других библиотеках и технологиях, отличных от тех, которые используются в МТС?
Могут ли полученные результаты распространены вверх по иерархии приложений МТС? (Обобщить подходы и распространить их на решение других вопросов. Если. конечно, это имеет смысл.)
Не заглядывая в статью (которая кажется, почему-то, довольно маленькой для такой темы), можно сказать так: одно без другого не существует. Если имеется продукт без документации, то что-то в этом не так. Можно ли сделать продукт. который не требует документации? Трудный вопрос. Наличие документации — это правило хорошего тона. Документации часто просто не хватает. От слова очень.
(Да, тяжело такое читать на тяжёлую голову. Хочется прочитать, а тут... Ладно. Подождите. "Я ещё вернусь."(с)))
Вот почему очень нужны примеры. Хочется увидеть это уникальное.