W dniu poniedziałek, 4 maja 2020 23:40:59 UTC+2 użytkownik Maciej Sobczak napisał:
> > Tutaj jedyna wartość dodana to "wiedza z eksperymentu".
>
> OK. To jest jak najbardziej wartość dodana. Tzn. na razie jest to dług techniczny,
ale niech będzie, że jest to inwestycja w eksplorację.

Jako dług techniczny to rzeczywiście trochę jest (a trochę nie jest).
Nie jest, bo mogę to w każdej chwili wyrzucić, i nie będzie bolało.
Ale jest, bo rzeczywiście doszedłem do etapu, że rozwijanie tego stało się bolesne (i
nie chodzi o to, że małe literki i drobniuteńka klawiatura dotykowa, tylko
architektura kodu jest taka, że jak chcę wprowadzić zmianę, to muszę przeglądać w
kilku miejscach)

> > Docelowo zaś: jest nadzieja, że dla różnych zastosowań zwiększy to efektywność
różnych interakcji za pośrednictwem Smartfona.
>
> OK. Ale dlaczego tylko smartfona? Nie będę mógł skorzystać z tego pomysłu machając
myszką na desktopie? Chciałbym.
> Inaczej mówiąc - nie traktuj wspomnianego wcześniej kibelka jako docelowego
use-case'a. Nawet jak już wszyscy będą mieć po trzy telefony, to jednak praca
inżynierska nadal odbywać się będzie na dużym ekranie (i słusznie).

Jasne, ale też sądzę, że to może być dobry punkt wyjścia.

Wcześniejszy prototyp był na myszkę, i widać, że oba są jakoś do siebie podobne.

Za to przy okazji prac zauważyłem, że na przykład aplikacje pisane w bibliotece
ncurses całkiem dobrze się obsługuje na ekranie dotykowym. Ale da się na Androidzie
odpalić też X serwer, i muszę powiedzieć, że obsługa natywnych aplikacji GUI pisanych
na myszkę na ekranie dotykowym to jakiś koszmar.

> > Ja sobie myślę o nieco bardziej "telefonowych" use case'ach: że rysuję sobie
guziki na ekranie i je rozmieszczam jak mi wygodnie, i przypisuję sobie do nich różne
funkcje.
>
> 20 lat temu robiły to różne Buildery i inne Visuale. To się nazywało RAD.

No, tylko tam też była radykalna separacja kodu od interfejsu.
A ja szukam sposobu, żeby jakoś jedno z drugim zintegrować.

> > Może na przykład rysowanie diagramu przepływu sterowania na telefonie okaże się
lepszym pomysłem?
>
> Znowu ślepa uliczka. Rysowanie diagramu ogólnie jest lepszym pomysłem, nie tylko na
telefonie.

Tzn. moje doświadczenie jest takie, że komputery stacjonarne wolę obsługiwać głównie
z klawiatury, bo to jest efektywne. Rysowanie myszką jest raczej nieefektywne -
ewentualnie składanie diagramów z gotowych elementów.

Dlatego myślę sobie, że może jeśli zoptymalizuję się na bardziej spartańskie warunki,
to łatwiej będzie można się później "rozpasać".

Ciekawostka jest taka, że jak wrzuciłem video na twittera, to ktoś odpowiedział czymś
takim:
https://twitter.com/crabl/status/1256722620814364678

> > Na pewno największą motywacją dla mnie jest w tej chwili wizualizacja danych.
>
> Tak. Ale podchodzisz do tego od strony edycji. Wizualizację można zrobić bez
edycji.

To prawda. Edycja jest dla mnie nie mniej istotna, niż wizualizacja :]

> > Że na przykład (-1, 1), (1, 1), (1, -1), (-1, -1) mówi mi stosunkowo niewiele,
ale już coś w rodzaju
> >
> > +------+
> > | |
> > | |
> > | |
> > +------+
> >
> > (kwadrat, na wypadek gdyby się źle sformatowało) mówi mi nieco więcej.
>
> Tak. Przy jakiejś tam metodzie wizualizacji. Bo akurat narysowałeś wielokąt
rozpięty na zadanych punktach. A może to miał być graf?
> Ale zgadzam się, że wizualizacja jest potrzebna.
>
> > I nie chodzi mi o to, że chcę mieć obrazek, tylko że dla każdego rodzaju danych,
z którymi pracuję, chciałbym mieć wyspecjalizowany edytor do pracy z tym właśnie
rodzajem danych. Albo nawet kilka wyspecjalizowanych edytorów.
>
> Dobry pomysł.
> A tak nie jest? Mam edytor do plików graficznych, inny edytor do plików
dźwiękowych, jeszcze inny do kodu, inny do arkusza kalkulacyjnego, inny do schematów
elektrycznych...

To prawda. Tyle że jedyna forma integracji pomiędzy tymi edytorami to że mogę sobie
przełączać pomiędzy oknami tych edytorów. Do tego z reguły uruchamianie tych edytorów
trwa dłuższą chwilę, i każdy jest raczej rozbudowaną kobyłą.

Co wiecej, nie mogę sobie zawrzeć takiej wizualizacji np. w teście jednostkowym
(że "takie coś na wejściu" daje mi "takie coś na wyjściu", gdzie przez "takie coś"
rozumiem jakąś formę wizualizacji danych)

Ostatnio wklejałem link do tej prezentacji:
https://www.youtube.com/watch?v=Pot9GnHFOVU

Tutaj jest w moim odczuciu nawet dobrze zaimplementowane to, co "mi się widzi"

Tylko że ja bym chciał też trochę coś innego. Chciałbym móc podglądać, w jaki sposób
na różnych etapach wykonania programu "wyglądają" dane wejściowe, tzn. w jaki sposób
są przekształcane.

Docelowo myślę sobie, że mając takie coś do dyspozycji, można by było widzieć
wykonanie programu jako animację. Myślę, że szczególnie dobrze nadaje się do tego
model podstawieniowy.

Swego czasu robiłem prezentację o programowaniu funkcyjnym, i zostały mi po niej
takie slajdy:
https://github.com/panicz/writings/raw/master/talks/
hackerspace/fun/intro.pdf

jeżeli pójdziesz do slajdu 34 i odpalisz tryb pokazu slajdów, i zaczniesz przerzucać
slajdy strzałką w prawo, to dostaniesz taką animację.

Strasznie się wtedy napierdzieliłem w LaTeXu, żeby to jakoś wyglądało, ale wyobrażam
sobie, że dobre środowisko mogłoby pozwolić generować takie animacje za darmo (i
można by było wizualizować nie tylko listy, ale również "dowonle formy", a w
szczególności grafy, bo grafy mnie w tej chwili najbardziej interesują od strony
praktycznej)

> > Ja mam taką nadzieję, że może iteracyjnie uda się dojść do takiej sytuacji, że
tworzenie kodu na ekranie dotykowym będzie nie mniej efektywne od tworzenia go z
poziomu klawiatury.
>
> To może krok albo kilka do tyłu. Dlaczego chcesz tworzyć *kod*?
> Może to właśnie kod jest ograniczeniem, a nie metoda jego wprowadzania?
> Może np. graf jest lepszy od kodu? Wtedy nie trzeba myśleć o nowej metodzie
wprowadzania kodu, tylko o nowej metodzie wyrażenia jakiejś intencji, jak np.
następstwo zdarzeń. W tej koncepcji niech kod zostanie kodem (bo tak jest dobrze i
nie trzeba tego poprawiać) ale niech też istnieją inne artefakty inżynierskie, które
nie są kodem.

No nie wiem.
Kiedyś pracowałem "sobie" nad programem do opisywania reguł gier planszowych, i
stworzyłem do tego język, w którym np. opis szachów wyglądał tak:
https://bitbucket.org/panicz/slayer/src/default/demo
s/schess/rules/chess.ss

Pytanie, czy to jeszcze jest kod, czy już nie jest?

Wśród programistów lispowych funkcjonuje taka mantra, że "kod to dane, a dane to
kod", i ja też raczej myślę o tym w ten sposób.

Chciałbym mieć różne możliwości wprowadzania danych, w tym różne możliwości
wprowadzania kodu.

Swego czasu ktoś mi chyba na Twitterze albo na Quorze podsunął projekt "programowania
intencjonalnego", który był w latach 90. rozwijany w Microsofcie:

https://www.youtube.com/watch?v=tSnnfUj1XCQ

> I do tych innych będzie można zrobić inne edytory. I to może być autentycznie
lepsze, niż obecne opisywanie tych wszystkich innych koncepcji kodem, tak jakby kod
był jedyną metodą zapisywania czegokolwiek.

No u mnie tak naprawdę nie ma nawet kodu. Aktualnie są po prostu pudełka w pudełkach,
i w niektórych ewentualnie można znaleźć litery.

Docelowo bym chciał, żeby można było użyć tych "pudełek w pudełkach" do opisywania
reguł rządzących zachowaniami innych rodzajów pudełek. I wtedy być może będzie można
użyć niektórych spośród tych innych rodzajów pudełek do opisania pudełek, przy pomocy
których będzie można lepiej opisywać reguły rządzące zachowaniami pudełek.