Pull to refresh
1
0

Технолог по автоматизированной обработки информаци

Send message

Спорное суждение, по моему мнению, качественная работа оператора не зависит от инструмента, а напротив, зависит от сценариев обработки вводимых данных. Т.е. данная проблема лежит не в плоскости инструментария, а в плоскости дизайна и анализа сценариев работы оператора, а следовательно, с помощью какого инструмента, оператор вводит данные, react это или vue, или jsf, или jquery, или dojo, или excel, не имеет значение ;)

Да, nps и его webpack это особая история. Главное, как не ломай его, он будет работать)). Но нет смысла это все разворачивать для оператора, если есть простые инструменты, типа jsf и тому подобное. Где как раз сложные формы неплохо работают в связки полей и т.п.. в том числе где нет необходимости поддержания реактивого вывода данных с использование асинхронного взаимодействия пользовательских интерфейсов с системой обработки данных.

Поддерживаю ))) "В отличие от моделей работы над более масштабными системами, которыми являются React и Angular, поддержкой Vue, опенсорсного проекта, занимается один разработчик, Эван Ю. Проект финансируется по схеме краудсорсинга. Эван говорит, что это — одна из особенностей проекта, которая отличает его от остальных, так как это вдохновляет на написание кода более высокого качества, чем обычно, и на создание отличной документации."

Я бы выделил ещё один аспект применения того или другого инструмента: кто именно будет взаимодействовать с системой для ввода/вывода информации. Если система предназначена для работы оператора (внутренний пользователь в организации), задача которого ввод информации и принятие решения по результатам обработки, то здесь нет необходимости применять сложные инструменты, как react. А если система предназначена для внешнего пользователя, задача которого получить быстро и удобно нужную ему информацию, и далее минимальным взаимодействием с интерфейсом ввода/вывода, выполнить действие, то здесь лучше использовать такие инструменты как react.

Конечно. Основная мысль, которую я выделил для себя, это попытка сделать программирование настолько доступным, что программист, как профессия уже не нужна. "Программирование без программиста". Это и возмутило. Скорее всего я не понял ваш вопрос. "Почему?" Можете ли вы уточнить к чему именно был адресован этот вопрос?

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

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

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

Помню у нас в колледже статистики, экономики и информационных технологий, в туалете, была надпись: "Писать на стенах туалета, увы друзья не мудрено, среди говна мы все поэты, среди поэтов мы говно". Я тоже пишу промышленный код с 1999, но меня удивляют такие статьи. Я не понимаю, а куда делся здравый смысл инженера-программиста, и что за сервис, научить программировать за неделю. Куда делась высшая математика, алгебра, логика, статистка из программирования. С 99 года применялись ли правила к программам автора, такие как, рекурсия, рефлексия, полиморфизм, абстракция, фактические и формальные параметры и пр.. Даже, если, в новом мире, айти, это всего лишь продажная девка бизнеса, то никто и никогда не исключает инженерную культуру и здравый смысл инженера-программиста, основанного, в первую очередь, на науке. И вам этого желаю. ;)

Information

Rating
Does not participate
Date of birth
Registered
Activity