Видите ли вы использование для «программирования электронных таблиц»? [закрыто]

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

• создать электронную таблицу с четко определенным потоком вычислений (которая иногда лучше подходит для парадигмы электронных таблиц «поток данных» вместо процедурных или объектно-ориентированных стилей программирования)

• определить входные ячейки

• определить выходные ячейки

• скомпилировать все это в отдельный исполняемый класс (или функцию, процедуру, ...)

• использовать его в обычном коде в более широком программном проекте

• использовать электронную таблицу в качестве исходного кода, который будет поддерживаться с течением времени

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

Хотя это не совсем стиль «создания электронной таблицы, компилирования ее в код», о котором вы спрашивали, расширение потока данных Cells для CLOS использует аналогичную модель: формулы, выражающие потоки данных и преобразования, являются представлением «исходного материала» / « записи "для объекта / дизайн класса. Считайте, что это альтернативный способ построить то, о чем вы спрашивали.

И просто для удовольствия: таблица макроса

которые иногда лучше подходят для парадигмы «потока данных» электронных таблиц вместо процедурных или объектно-ориентированных стилей программирования

Честно говоря, я едва ли могу придумать какие-либо реальные расчеты, где это применимо. Программирование «потока данных» может быть легко выполнено многими современными языками программирования (посмотрите на LINQ в мире .NET или операторы обработки списков в Perl и Python) и, по моему опыту, это приводит к гораздо большему количеству поддерживаемого кода, чем куча «формул электронных таблиц» с трудно поддерживаемыми ссылками на ячейки.

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

С тех пор, как я прочитал эту статью, я все время думал о концепции. Я думаю , что, безусловно , использование для него.

Одна вещь об оптимизации такой вещи, электронная таблица очень похожа на пространство памяти. Это также очень похоже на пространство отображения и печати (как в x, y). Там тоже много преимуществ.

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

Я действительно только написал VB-скрипты для электронных таблиц, дневников и бухгалтерского "программного обеспечения" в основном. Никогда не создавал исполняемые приложения из каких-либо электронных таблиц, кроме файлового интерфейса Excel из приложения C ++.

Да, однако я думаю об этом больше как о «тестировании электронных таблиц», а не «программировании электронных таблиц». Например, недавно я работал над функцией для нашего проекта, которая включает в себя вычисление большого количества записей в базе данных. Расчет был относительно простым, но важным и поэтому требовал особого внимания. Кроме того, формула, которую мы использовали, требовала небольшой адаптации, чтобы соответствовать нашей ситуации.

Я выполнил некоторые вычисления вручную, чтобы написать свои модульные тесты, в то время как тестер, с которым я работал, создал электронную таблицу, которую вы описали для использования в его сквозных тестах. Из-за адаптации формулы источника у нас не было никаких независимых тестовых данных для сравнения, поэтому электронная таблица обеспечивала своего рода проверку стиля «двойной бухгалтерии», которая давала нам уверенность в правильности кода.

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

«Программирование» электронных таблиц - это тип программирования потока данных.

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

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

Программирование потока данных имеет несколько типов, давайте рассмотрим некоторые из них:

• Электронная таблица: входные числа обрабатываются по формулам, затем результаты и графики. Особые характеристики: время обработки - «однократный», при изменении входного значения (компонента) соответствующая часть графика обработки перезапускается и выдает результат.
• Канал Unix: оболочка запускает несколько программ и связывает stdout-> stdin. Особые характеристики: разрешено только связывание в стиле конвейера, график представляет собой одну очередь.
• Синхронизированное выполнение: есть часы, которые запускают обработку кадра или выборки с заданной частотой. Каждый компонент запускается один раз в такт. Видео и аудио системы обработки примеров, они работают с заданной частотой кадров / дискретизации.
• Асинхронное выполнение: график находится в режиме ожидания, пока не произойдет внешнее событие. Затем он обрабатывает событие, генерирует некоторый вывод (или нет) и переходит в состояние ожидания.

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

Я и мой друг создали прототип системы DF для домашней автоматизации. У нас нет редактора графиков, поэтому приложение не может быть отредактировано пользователем, некоторые параметры хранятся в файле конфигурации, но не более того. У нас есть язык сценариев DF, который «компилируется» в код C ++ (список создания компонентов и определений сообщений), который компилируется в собственный исполняемый файл. Модули представляют собой классы C ++ (другие классы, просто чтобы получить некоторую информацию о нашей системе: Message, Dispathcer, Component (abstract), Port (abstract), ConsumerPort, ProducerPort).

Кроме того, мы были поражены преимуществами системы DF: мы сделали приложение для последовательного анализатора в течение 2 минут, или мы сделали тестовую программу на месте , которая мигает лампами один за другим (документации не было) на идентификаторах оборудования). Мы создали компоненты MIDI и джойстика просто для удовольствия, я также создал для них легкий орган (см. Http://homeaut.com/under_construction/ ).

Я вижу только одну трудность в случае электронных таблиц: поскольку каждое число и формула (потенциально: каждая ячейка) является компонентом, ваш график не является окончательным. Когда вы добавляете строку в ваше простое приложение sum (), это означает, что график потока данных изменяется. Итак, вы должны «перепрограммировать» график во время выполнения, или мы должны назвать его «метапрограммирование». В Excel макрос выполнял бы эту работу, но тогда мы теряли бы чистоту потока данных.

У меня есть не слишком плохое, но не идеальное решение. Я сделал электронную таблицу, приложение AJAX с бэкэндом PHP. Вертикальная ось - время (дни), линии - компоненты. Существуют такие компоненты, как ввод (строка может редактироваться пользователем), вертикальное среднее, горизонтальное среднее / сумма и некоторые статистические вычисления по конкретным областям. Есть только одна проблема: это «одномерный». Пока я хочу только сумму, среднее и прочее, я могу добавлять новые строки и создавать компонент, который вычисляет материал. Но есть сильное ограничение: столбцы всегда дни (я сделал недельные и месячные "просмотры", которые отображают ежедневные данные в виде суммы / среднего, но они все еще одномерные). Я не могу показать это, это совместная работа, для запуска которой требуется 7/24 серверная задача PHP, она не поддерживается моим хост-провайдером.

Таким образом, моя модель (которую лучше всего описать как «дни по горизонтали») не может справиться с другими проблемами.

У меня есть идея, как решить эту проблему: вкладки .

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

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

Таким образом, когда пользователь добавляет новую строку / столбец, новая строка / столбец будет иметь ту же формулу.

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

Возможно, я ошибаюсь, и в этой модели есть концептуальные ошибки, но я надеюсь, что это заставило задуматься.

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