Чи бачите ви використання для програмування електронних таблиць? [зачинено]

Деякий час тому я натрапив на концепцію використання електронних таблиць (я маю на увазі комірки та формули, а не макрокод) як спосіб визначення логіки програмування. Ідея така:

• створити електронну таблицю з чітко визначеним потоком обчислень (які іноді краще підходять до парадигми електронних таблиць "потік даних" замість процедурних або об'єктно-орієнтованих стилів програмування)

• визначити вхідні комірки

• визначити вихідні комірки

• скласти всю річ у окремий виконуваний клас (або функцію, процедуру, ...)

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

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

Ідея полягає у використанні цієї методики для проблем, які справді вписуються в модель, і щоб це призвело до природно добре задокументованого та простого технічного коду. Мені цікаво дізнатися, чи відчували ви досвід використання техніки та для чого. Приклад програми, яка мені прийшла в голову, - це калькулятори страхових тарифів, які, як правило, складаються, створюються та затверджуються актуаріями на листах Excel і лише пізніше кодуються (це болісний процес) у певній складній логіці програмування.

Хоча про те, про який ви питали, не саме стиль "побудувати електронну таблицю, компілюйте її в код", розширення потоку даних Cells до CLOS використовує аналогічну модель: Формули, що виражають потоки даних та перетворення, є "поданням вихідного матеріалу" / " запису "для проектування об'єктів / класів. Розгляньте це альтернативний спосіб побудувати те, про що ви питали.

І просто для розваги: макрос електронних таблиць

які іноді краще підходять до парадигми електронних таблиць "потік даних" замість процедурних або об'єктно-орієнтованих стилів програмування

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

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

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

Одне з питань оптимізації такої речі, аркуш розширення дуже схожий на простір пам’яті. Він також дуже схожий на простір для відображення та друку (як у x, y). Багато пільг теж є.

Коли ви відзначили ремонтопридатність, це відкрило для мене багато ідей. Я не знаю, що є тут для компіляції з дійсно та мовними функціями, бібліотеками тощо. І все-таки десь у ньому може бути майбутнє.

У мене справді написані лише сценарії VB для електронних таблиць, зошитів та облікового «програмного забезпечення». Ніколи не робив виконувані програми з будь-якої електронної таблиці, за винятком інтерфейсу файлу Excel із програми C ++.

Так, проте я вважаю це скоріше "тестуванням електронних таблиць", а не "програмуванням електронних таблиць". Наприклад, нещодавно я працював над функцією для нашого проекту, яка передбачає проведення обчислення великої кількості записів бази даних. Розрахунок був порівняно простим, але важливим і тому потребував особливої ​​уваги при тестуванні. Крім того, формула, яку ми використовували, вимагала невеликої кількості адаптацій, щоб застосувати до нашої ситуації.

Я переглянув деякі обчислення вручну, щоб написати свої тести на одиницю, в той час як тестер, з яким я працював, створив електронну таблицю, як ви описали для використання в його тестах. Через адаптацію вихідної формули у нас не було незалежних тестових даних для порівняння, тому електронна таблиця забезпечила своєрідну перевірку стилю "подвійного запису", що дало нам впевненість у правильності коду.

Так, так, я вважаю, що ця методика є дуже корисною як джерело тестових даних для тих випадків, коли розрахунки, що займаються, легко здійснити в електронній таблиці, але в іншому випадку потрібно реалізувати в коді. Однак таку електронну таблицю не слід використовувати як "задачу логіки програмування", а лише необхідний кінцевий результат.

Електронна таблиця "програмування" - це тип програмування потоку даних.

У нас з цим мовна проблема, ми не повинні називати це "програмуванням", оскільки це набагато менше, ніж ми називаємо програмування, але це, безумовно, більше, ніж введення даних у програму.

Програмування потоку даних - це архітектура та дисципліна, де додаток являє собою мережу незалежних модулів, вони передають повідомлення (дані) один одному. Ця модель не застосовується до кожної проблеми, лише для тих, де є вихідні дані або потік (або їх більше), який йде через мережу обробки та виробляє вихідні дані / потоки. Дивіться список нижче.

Програмування потоку даних має кілька типів, давайте подивимося деякі:

• Електронна таблиця: вхідні номери обробляються формулами, потім числами та графіками результатів. Особливі характеристики: час екзекціонування "однократний", коли вхідне значення (компонент) змінюється, відповідна частина графіка обробки повторно запускається і виробляє вихід.
• Unix pipe: оболонка запускає кілька програм і посилає stdout-> stdin. Особливі характеристики: дозволено лише зв'язування в стилі труби, графік - це одна черга.
• Синхронізоване виконання: є тактовий годинник, який запускає обробку кадру або зразка із заданою частотою. Кожен компонент працює один раз тактовим циклом. Системи обробки відео та аудіо на прикладах, вони працюють із заданою швидкістю кадрів / вибірки.
• Асинхронне виконання: графік не працює, поки не відбудеться зовнішня подія. Потім він обробляє подію, генерує деякий вихід (чи ні) і переходить у стан очікування.

Повернення до вашого запитання: Я думаю, що так, корисно опублікувати додаток для передачі даних як окремий додаток. Я вже це зробив. Двічі .

Я та мій друг створили прототип системи DF для домашньої автоматизації. У нас немає редактора графіків, тому додаток не редагується користувачем, деякі параметри зберігаються у конфігураційному файлі, але нічого іншого. У нас є мова скриптів DF, яка "компілюється" в код C ++ (перелік створення компонентів та визначення повідомлень), який компілюється в нативний виконуваний файл. Модулі - це класи C ++ (інші класи, лише щоб отримати інформацію про нашу систему: Повідомлення, Диспетчер, Компонент (реферат), Порт (реферат), ConsumerPort, ProducerPort).

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

Я бачу лише одну складність у випадку використання електронних таблиць: оскільки кожне число та формула (потенційно: кожна комірка) є складовою, ваш графік не є остаточним. Коли ви додаєте рядок до простої програми sum (), це означає, що графік потоку даних змінено. Отже, вам доведеться "перепрограмувати" графік під час виконання, або ми повинні назвати це "метапрограмування". В Excel макрос зробив би цю роботу, але тоді ми втрачаємо чистоту потоку даних.

У мене є не надто поганий, але не ідеальний варіант. Я створив електронну таблицю, додаток AJAX з PHP. Вертикальна вісь - час (дні), лінії - складові. Є такі компоненти, як введення даних (рядок може редагуватися користувачем), середнє вертикальне значення, середнє значення горизонталі / сума та деякі статистичні розрахунки, що стосуються домену. З цим існує лише одна проблема: це "одновимірність". Поки я хочу просто суму і середню кількість і все, що я можу, я можу додати нові рядки та створити компонент, який обчислює матеріал. Але є сильне обмеження: стовпці - це завжди дні (я робив "перегляди за тиждень і місяць", де відображаються щоденні дані як сума / середня, але це все одно одновимірне). Я не можу його показати, це спільна робота і вимагає завдання PHP для запуску 7/24, це не підтримується моїм провайдером.

Отже, моя модель (яку найкраще можна охарактеризувати як "дні горизонтально") не в змозі впоратися з іншими проблемами.

У мене є ідея, як вирішити цю проблему: вкладки .

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

Кожна таблиця повинна мати свою зростаючу вісь: вертикальну, горизонтальну або нерухому. У вертикально зростаючих таблицях є компоненти рядків (як моя денна таблиця), де всі стовпці мають формулу "однакова", горизонтальні компоненти - компоненти стовпців, таблиці фіксованого розміру - це як і будь-яка електронна таблиця.

Отже, коли користувач додає новий рядок / стовпець, новий рядок / стовпець матиме ту саму формулу.

Крім того, у електронних таблицях я ненавиджу річ, що мені потрібно копіювати самі однакові формули 1000 разів, якщо у мене є 1000 рядків. Це джерело помилок (зберігання старої версії формули в деяких рядках), втрати пам’яті (зберігання тієї ж формули 1000x).

Можливо, я помиляюся, і в цій моделі є помилки з концепцією, але, сподіваюся, це була гарна думка.

Моя думка полягала б у використанні електронної таблиці для визначення логіки обчислень, і при цьому спробуйте налаштувати електронну таблицю таким чином, щоб зробити мову програмування зручною. Під дружнім я маю на увазі -> використання діапазонів назв / посилань замість координат cellXY та розбиття формули на більш дрібні частини.