Czy widzisz zastosowanie „programowania arkuszy kalkulacyjnych”? [Zamknięte]

Jakiś czas temu natknąłem się na koncepcję użycia arkuszy kalkulacyjnych (mam na myśli komórki i formuły, a nie kod makr) jako sposób na określenie logiki programowania. Chodzi o to:

• utwórz arkusz kalkulacyjny z jasno zdefiniowanym przepływem obliczeń (które czasami lepiej pasują do paradygmatu arkuszy danych „przepływu danych” zamiast stylów programowania proceduralnego lub obiektowego)

• zdefiniuj komórki wejściowe

• zdefiniuj komórki wyjściowe

• skompiluj całość w samodzielną klasę wykonywalną (lub funkcję, procedurę, ...)

• używaj go w normalnym kodzie w ramach szerszego projektu oprogramowania

• użyj arkusza kalkulacyjnego jako kodu źródłowego, który będzie utrzymywany w miarę upływu czasu

Chodzi o wykorzystanie tej techniki w przypadku problemów, które naprawdę pasują do modelu, i że doprowadziłoby to do naturalnie dobrze udokumentowanego i łatwego w utrzymaniu kodu. Chcę wiedzieć, czy doświadczyłeś / -aś tej techniki i do czego. Przykładową aplikacją, która przyszła mi do głowy, są kalkulatory taryf ubezpieczeniowych, które są zwykle opracowywane, tworzone i zatwierdzane przez aktuariuszy na arkuszach Excela, a dopiero później kodowane (to bolesny proces) w trudnej do utrzymania logice programowania.

Chociaż nie jest to dokładnie styl „budowania arkusza kalkulacyjnego, kompilowania go w kodzie”, o który pytałeś, rozszerzenie przepływu danych Cells do CLOS wykorzystuje podobny model: że formuły wyrażające przepływy danych i transformacje będą reprezentacją „materiału źródłowego” / „ of record "do projektowania obiektów / klas. Rozważ to alternatywny sposób na zbudowanie tego, o co prosiłeś.

I dla zabawy: makro arkusza kalkulacyjnego

które czasami lepiej pasują do paradygmatu arkuszy danych „przepływu danych” zamiast stylów programowania proceduralnego lub obiektowego

Szczerze mówiąc, nie mogę sobie wyobrazić żadnych obliczeń w świecie rzeczywistym, w których to dotyczy. Programowanie „przepływu danych” można z łatwością wykonać w wielu współczesnych językach programowania (spójrz na LINQ w świecie .NET lub operatorów przetwarzania list Perla i Pythona) i, według mojego doświadczenia, daje to znacznie łatwiejszy do utrzymania kod niż kilka „formuł arkusza kalkulacyjnego” z trudnymi do utrzymania odniesieniami do komórek.

Z drugiej strony ja i moi koledzy stworzyliśmy wiele aplikacji opartych na arkuszu kalkulacyjnym (konkretnie MS-Excel), w których Excel był używany jako przyjazne dla użytkownika narzędzie do szybkiego wprowadzania danych / tworzenia masek wprowadzania, lub do tworzenia sformatowanych danych wyjściowych lub obu. We wszystkich tych przypadkach obliczenia lub przetwarzanie tych danych nie zostało wykonane (lub tylko częściowo wykonane) za pomocą formuł programu Excel, ale przez kod programu, ponieważ formuły programu Excel nie były wystarczająco mocne lub całkowicie niewłaściwe narzędzie (i wierz mi, mamy duża wiedza na temat tego, co jest możliwe w przypadku formuł programu Excel, a czego nie jest).

Odkąd przeczytałem ten artykuł , zastanawiałem się nad tą koncepcją. Myślę, że jest zdecydowanie stosowanie dla niego.

Jedna rzecz w optymalizacji takiej rzeczy, arkusz kalkulacyjny jest bardzo podobny do przestrzeni pamięci. Jest również bardzo podobny do przestrzeni wyświetlania i drukowania (jak w x, y). Tam też jest wiele korzyści.

Kiedy zauważyłeś łatwość konserwacji, otworzyło mi to wiele pomysłów. Nie wiem, co można tam skompilować, a funkcje językowe, biblioteki itp. Mogą być dość uciążliwe. Mimo to może być gdzieś w tym przyszłość.

Naprawdę napisałem głównie skrypty VB do arkuszy kalkulacyjnych, dzienników ocen i „oprogramowania” księgowego. Nigdy nie tworzyłem aplikacji wykonywalnych z niczego opartego na arkuszu kalkulacyjnym, z wyjątkiem interfejsu plików programu Excel z aplikacji C ++.

Tak, jednak myślę o tym bardziej jako o „testowaniu arkusza kalkulacyjnego” niż o „programowaniu arkusza kalkulacyjnego”. Na przykład ostatnio pracowałem nad funkcją naszego projektu, która polega na przeprowadzeniu obliczeń na dużej liczbie rekordów bazy danych. Obliczenia były stosunkowo proste, ale ważne i dlatego wymagały szczególnej uwagi podczas testów. Ponadto zastosowana przez nas formuła wymagała niewielkiej adaptacji, aby mogła zostać zastosowana w naszej sytuacji.

Przejrzałem ręcznie niektóre obliczenia, aby napisać moje testy jednostkowe, podczas gdy tester, z którym pracowałem, utworzył arkusz kalkulacyjny, taki jak opisany przez ciebie, do użytku w jego testach kompleksowych. Z powodu dostosowania formuły źródłowej nie mieliśmy żadnych niezależnych danych testowych do porównania, dlatego arkusz kalkulacyjny zapewnia rodzaj kontroli stylu „podwójnego księgowania”, który dał nam pewność, że kod jest poprawny.

Tak, widzę tę technikę jako bardzo przydatną jako źródło danych testowych w przypadkach, w których obliczenia są łatwe do zaimplementowania w arkuszu kalkulacyjnym, ale w innych przypadkach muszą być zaimplementowane w kodzie. Jednak takiego arkusza kalkulacyjnego nie należy używać do „określania logiki programowania” jako takiej, a jedynie do wymaganych wyników końcowych.

Arkusz kalkulacyjny „programowanie” jest rodzajem programowania przepływu danych.

Mamy z tym problem językowy, nie powinniśmy nazywać go „programowaniem”, ponieważ jest to o wiele mniej niż programowanie, ale zdecydowanie więcej niż wprowadzanie danych do programu.

Programowanie przepływu danych to architektura i dyscyplina, w której aplikacja stanowi sieć niezależnych modułów, które przesyłają sobie nawzajem komunikaty (dane). Ten model nie ma zastosowania do każdego problemu, tylko dla tych, w których istnieją dane źródłowe lub strumień (lub jest ich więcej), który przechodzi przez sieć przetwarzania i wytwarza dane wyjściowe / strumienie. Zobacz listę poniżej.

Programowanie przepływu danych ma kilka typów, zobaczmy kilka:

• Arkusz kalkulacyjny: liczby wejściowe są przetwarzane według formuł, a następnie liczb wyników i wykresów. Cechy szczególne: czas wykonania jest „jednorazowy”, gdy zmienia się wartość wejściowa (komponent), odpowiednia część wykresu przetwarzania jest odtwarzana ponownie i generuje wynik.
• Potok Unix: powłoka uruchamia kilka programów i łączy stdout-> stdin. Cechy szczególne: dozwolone jest tylko łączenie w stylu potoku, wykres jest pojedynczą kolejką.
• Zsynchronizowane wykonywanie: istnieje zegar, który uruchamia przetwarzanie ramki lub próbki na określonej częstotliwości. Każdy element działa raz na cykl zegara. Systemy przetwarzania wideo i audio przykłady, działają z określoną częstotliwością klatek / próbką.
• Wykonanie asynchroniczne: wykres jest w stanie bezczynności, aż do wystąpienia zdarzenia zewnętrznego. Następnie przetwarza zdarzenie, generuje dane wyjściowe (lub nie) i przechodzi w stan bezczynności.

Powrót do pytania: Myślę, że tak, warto opublikować aplikację do przepływu danych jako samodzielną aplikację. Już to zrobiłem. Dwukrotnie .

Ja i mój przyjaciel stworzyliśmy prototypowy system DF do automatyki domowej. Nie mamy edytora grafów, więc aplikacja nie może być edytowana przez użytkownika, niektóre parametry są przechowywane w pliku konfiguracyjnym, ale nic więcej. Mamy język skryptowy DF, który jest „kompilowany” do kodu C ++ (lista tworzenia komponentów i definicji komunikatów), który jest kompilowany do natywnego pliku wykonywalnego. Moduły to klasy C ++ (inne klasy, tylko po to, aby uzyskać informacje o naszym systemie: Message, Dispathcer, Component (abstract), Port (abstract), ConsumerPort, ProducerPort).

Byliśmy również zaskoczeni zaletami systemu DF: stworzyliśmy aplikację do seryjnego sniffera w ciągu 2 minut lub stworzyliśmy program testowy na miejscu , który miga lampy jedna po drugiej (nie było dokumentacji na identyfikatorach sprzętu). Stworzyliśmy komponenty MIDI i joypad dla zabawy, stworzyłem też z nich lekki organ (patrz http://homeaut.com/under_construction/ ).

Widzę tylko jedną trudność w przypadku arkuszy kalkulacyjnych: ponieważ każda liczba i formuła (potencjalnie: każda komórka) jest składnikiem, twój wykres nie jest ostateczny. Dodanie wiersza do prostej aplikacji sum () oznacza zmianę wykresu przepływu danych. Musisz więc „przeprogramować” wykres w czasie wykonywania, inaczej powinniśmy nazwać go „metaprogramowaniem”. W programie Excel zadanie to wykona makro, ale wtedy utracimy czystość przepływu danych.

Mam niezbyt złe, ale nie idealne rozwiązanie. Zrobiłem arkusz kalkulacyjny, aplikację AJAX z zapleczem PHP. Oś pionowa to czas (dni), linie są składowymi. Istnieją elementy, takie jak dane wejściowe (linia może być edytowana przez użytkownika), średnia pionowa, pozioma średnia / suma oraz niektóre obliczenia statystyczne specyficzne dla dziedziny. Jest z tym tylko jeden problem: jest to „jednowymiarowy”. Tak długo, jak chcę tylko sumę, śr. I tak dalej, mogę dodawać nowe wiersze i tworzyć komponent, który oblicza rzeczy. Ale istnieje silne ograniczenie: kolumny są zawsze dniami (wykonałem „widoki” tygodnia i miesiąca, które wyświetlają dzienne dane jako suma / śr., Ale nadal są jednowymiarowe). Nie mogę tego pokazać, jest oparty na współpracy i wymaga zadania zaplecza PHP do uruchomienia 7/24, nie jest obsługiwany przez mojego dostawcę hosta.

Zatem mój model (który najlepiej można opisać jako „dni w poziomie”) nie jest w stanie poradzić sobie z innymi problemami.

Mam pomysł, jak rozwiązać ten problem: zakładki .

Gdy utkniesz w programie Excel i musisz utworzyć inną tabelę, możesz użyć odrębnego obszaru na tej samej karcie lub otworzyć inną kartę. Również odwoływanie się między kartami jest niewygodne, wolę pierwszą metodę. Myślę, że zakładki powinny być wyświetlane na tym samym ekranie, podobnie jak nie nakładające się okna.

Każdy stół powinien mieć oś rosnącą: pionową, poziomą lub stałą. Pionowe tabele wzrostu mają komponenty liniowe (jak mój dzienny arkusz kalkulacyjny), w których wszystkie kolumny mają „tę samą” formułę, komponenty poziome mają komponenty kolumnowe, tabele o stałych rozmiarach są jak każdy arkusz kalkulacyjny.

Tak więc, gdy użytkownik doda nową linię / kolumnę, nowa linia / kolumna będzie miała tę samą formułę.

Ponadto w arkuszach kalkulacyjnych nienawidzę tego, że muszę skopiować te same formuły 1000 razy, jeśli mam 1000 wierszy. Jest źródłem błędów (utrzymywanie starej wersji formuły w niektórych liniach), marnowania pamięci (przechowywanie tej samej formuły 1000x).

Może się mylę i w tym modelu występują błędy koncepcyjne, ale mam nadzieję, że było to dobre i pobudzające do myślenia.

Moim pomysłem byłoby użycie arkusza kalkulacyjnego do zdefiniowania logiki obliczeń, a robiąc to, spróbuj skonfigurować arkusz kalkulacyjny w taki sposób, aby uczynić go przyjaznym dla języka programowania. Przez przyjazny rozumiem -> używanie zakresów nazw / referencji zamiast współrzędnych cellXY i dzielenie formuł na mniejsze części.