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.