On Tuesday, March 26, 2019 at 10:27:17 AM UTC+1, g...@g...com wrote:
> Drzewiaste struktury to coś, czym jak do tej pory najłatwiej się nam,
> jako ludziom, operuje. Z jakichś względów raczej mamy "drzewa rozbioru
> składniowego", a nie "dowolne grafy rozbioru składniowego".
> (Choć może to pomysł dobry i wart eksploracji. Może kiedyś będą grafy)

Dobrym i praktycznym przykładem na zastosowanie grafów do
opisu wyrażeń są binary decision diagrams. Ale to jednak
trochę nisza.

w.

do góry

> Drzewiaste struktury to coś, czym jak do tej pory najłatwiej się nam,
> jako ludziom, operuje.

I to jest fair. Ale jak pokazałem, bardzo szybko prosimy o więcej. Stąd te słabe
wskaźniki, linki symboliczne, itd.

> Z jakichś względów raczej mamy "drzewa rozbioru
> składniowego",

Bardzo trafna uwaga. I ma to zapewne związek z liniowym (tzn. 1D) charakterem mowy.
Nie komunikujemy się w 2D, tylko w 1D, stąd jedyną strukturą jest zagnieżdżenie i
stąd też drzewiaste rozkłady składniowe. I stąd też zapewne drzewiasta algebra.
Czyli piszemy to, co da się powiedzieć. Ma to jakiś sens. Ale ze strukturą świata
związku nie ma żadnego.

> > i linki twarde oraz symboliczne? Kto by się spodziewał?
>
> I niekompatybilności z systemami, które tego nie obsługują,

Dlatego takich systemów nie używamy.

Ale wróćmy na chwilę do tej filozoficznej koncepcji kompozycji, z której też ma
wynikać drzewiastość czegokolwiek.

Otóż, jak każdy wie, koń ma:
- 2 nogi przednie,
- 2 nogi tylne,
- 2 nogi lewe,
- 2 nogi prawe.

Tu nie chodzi o dowcip i o pytanie, ile nóg ma koń. Chodzi o to, że kompozycja jest
czasem arbitralnym wyborem obserwatora, dostosowanym do tego, co próbuje osiągnąć.
Różni obserwatorzy będą mieć różne kompozycje, bo będą ich potrzebowali do różnych
celów. Ale chyba zgadzamy się, że koń ma ciągle te same nogi, niezależnie od
obserwatorów. Dlatego powiedziałbym, że struktury drzewiaste bardziej opisują cel
istnienia modelu, niż modelowany obiekt. Stąd też skłonność różnych formatów do
dryfowania w stronę słabych wskaźników, linków symbolicznych, itd., bo im więcej
chcemy wiedzieć o modelowanym obiekcie, tym bardziej on się okazuje być
niedrzewiasty.

> Zasadniczo się zgadzam. (Choć nie jestem pewien, czy bym chciał pisać
> programy na automaty komórkowe).
> Pewną inspiracja są dla mnie te obrazki:
>
> https://pbs.twimg.com/media/B4nvfRvCYAAL0K0.jpg
> https://pbs.twimg.com/media/Db43WFTV0AARyTc.jpg

No właśnie, bardzo dobre przykłady. Albo np. obiekt, w którym przetwarzanie zależy od
kierunku napływu danych. W naturze pełno takich zjawisk.

> Dziś jeszcze natrafiłem na taki, dość interesujący projekt
> https://github.com/disconcision/fructure

Nadal piszemy jak mówimy, czyli 1D z zagnieżdżeniami.

> Tworem najbardziej przypominającym diff przed wynalezieniem komputera
> była errata. Ale istota jest taka, że to nie tekst (ciąg linearny)
> umożliwia tworzenie diffów, tylko struktura właśnie (diffy operują
> na liniach, a erraty zazwyczaj na stronach i akapitach).

Słuszna uwaga. Ale z obrazkami właściwie w ogóle nie działa. To jest, w obecnej
chwili, poważna wada formatów wizualnych.

--
Maciej Sobczak * http://www.inspirel.com

do góry

Gdyby miało się to okazać dla kogokolwiek interesujące, to pod koniec czerwca wraz z
Yasuyukim Maedą z Japonii będziemy na Politechnice Warszawskiej opowiadali o naszych
wizualnych środowiskach do edycji programów lispowych.

Maeda w podobnym czasie co ja stworzył bardzo podobny program (choć wydaje się, że
miał do tego nieco inne motywacje), a owoc jego pracy można obejrzeć tutaj:
https://twitter.com/maeda_/status/110470501550605926
5

Gospodarzem spotkania jest grupa "Monadic Warsaw". Więcej szczegółów odnośnie
spotkania można znaleźć tutaj:
https://www.meetup.com/Monadic-Warsaw/events/2617022
03/

Wszystkich zainteresowanych serdecznie zapraszam.

do góry

Właśnie opublikowałem kolejny prototyp edytora strukturalnego, tym razem dostosowany
do ekranów dotykowych i napisany w Javie na Androida (na kibelku)

Nagranie prezentujące działanie edytora można znaleźć tutaj:

https://youtu.be/BmZ39IfElzg

Kod znajduje się tu:

https://github.com/panicz/grasp-android

(Jest tam też plik .apk, jakby ktoś chciał sobie zainstalować, przy czym zastrzegam,
że nic użytecznego się z tym nie da zrobić)

do góry

> Nagranie prezentujące działanie edytora można znaleźć tutaj:
>
> https://youtu.be/BmZ39IfElzg

Fajnie, ale nie eliminuje konieczności używania klawiatury - a skoro klawiatura jest
potrzebna, to jest też dostępna a jak jest dostępna, to taką funkcję można napisać
normalnymi metodami wielokrotnie szybciej.

I mamy naturalne pytanie: jaka jest wartość dodana?
Dlaczego mam chcieć to mieć?

Spróbowałem wymyślić jakiś use-case z użyciem nie telefonu, tylko np. tablicy
interaktywnej na spotkaniu, gdzie się pisze wymagania systemowe.
Ale na takim spotkaniu i tak jest jakiś ochotnik z normalną klawiaturą. I pisze
szybciej, niż ktokolwiek by narysował. A reszta kiwa, że napisał to co chcieli.

Więc może odwrotnie - nie programowanie wizualne, tylko wizualizacja programu (albo
wymagań albo czego tam)? Bo ja nie mam nic przeciwko łączeniu form - tylko że
rysowanie nie jest chyba efektywną metodą pisania programu.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu niedziela, 3 maja 2020 20:53:09 UTC+2 użytkownik Maciej Sobczak napisał:
> > Nagranie prezentujące działanie edytora można znaleźć tutaj:
> >
> > https://youtu.be/BmZ39IfElzg
>
> Fajnie, ale nie eliminuje konieczności używania klawiatury - a skoro klawiatura
jest potrzebna, to jest też dostępna a jak jest dostępna, to taką funkcję można
napisać normalnymi metodami wielokrotnie szybciej.

Zgadza się. Jest to prawdopodobnie najbardziej nieefektywna metoda programowania od
czasów kart perforowanych.

> I mamy naturalne pytanie: jaka jest wartość dodana?
> Dlaczego mam chcieć to mieć?

Tego z całą pewnością nie chcesz mieć.
Tutaj jedyna wartość dodana to "wiedza z eksperymentu".
Dla mnie jest to pierwszy krok (nawet jeśli drugi raz postawiony) w pomyśle
radykalnego odejścia od "tekstowości" programowania.

Na tym etapie nie ma to jednak absolutnie żadnej wartości praktycznej.

Docelowo zaś: jest nadzieja, że dla różnych zastosowań zwiększy to efektywność
różnych interakcji za pośrednictwem Smartfona. Ale na tym etapie to tylko nadzieja.

> Spróbowałem wymyślić jakiś use-case z użyciem nie telefonu, tylko np. tablicy
interaktywnej na spotkaniu, gdzie się pisze wymagania systemowe.
> Ale na takim spotkaniu i tak jest jakiś ochotnik z normalną klawiaturą. I pisze
szybciej, niż ktokolwiek by narysował. A reszta kiwa, że napisał to co chcieli.

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.

Docelowo chciałbym wprowadzić inne reprezentacje programu, niż ta pudełkowa (która
moim zdaniem ani nie jest łatwa w edycji, ani czytelna). To jednak jest dopiero
"punkt wyjścia" albo "wspólny mianownik".

Może na przykład rysowanie diagramu przepływu sterowania na telefonie okaże się
lepszym pomysłem?

Na pewno największą motywacją dla mnie jest w tej chwili wizualizacja danych.
Ż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.

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.

> Więc może odwrotnie - nie programowanie wizualne, tylko wizualizacja programu (albo
wymagań albo czego tam)? Bo ja nie mam nic przeciwko łączeniu form - tylko że
rysowanie nie jest chyba efektywną metodą pisania programu.

Myślę że to zależy od zagadnienia.
Na przykład, Emacs ma tryb do edycji Lispa o nazwie "paredit", i osoby, które go
używają, chwalą się, że im to wielce ułatwia prace z kodem.

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. A swoją nadzieję opieram na tym, że jeżeli będę miał dość
elastyczny system do tworzenia interfejsów, to może zdołam "narysować" (czy raczej
"opracować") sobie interfejs, z którego edycja programów będzie łatwa.

do góry

> 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ę.

> 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).

> 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.

> 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.

> 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.

> Ż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...

> 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.
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.

--
Maciej Sobczak * http://www.inspirel.com

do góry

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.

do góry

niedziela, 3 maja 2020 o 23:32:55 UTC+2 g...@g...com napisał(a):
> W dniu niedziela, 3 maja 2020 20:53:09 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Nagranie prezentujące działanie edytora można znaleźć tutaj:
> > >
> > > https://youtu.be/BmZ39IfElzg
> >
> > Fajnie, ale nie eliminuje konieczności używania klawiatury - a skoro klawiatura
jest potrzebna, to jest też dostępna a jak jest dostępna, to taką funkcję można
napisać normalnymi metodami wielokrotnie szybciej.
> Zgadza się. Jest to prawdopodobnie najbardziej nieefektywna metoda programowania od
czasów kart perforowanych.
> > I mamy naturalne pytanie: jaka jest wartość dodana?
> > Dlaczego mam chcieć to mieć?
> Tego z całą pewnością nie chcesz mieć.
> Tutaj jedyna wartość dodana to "wiedza z eksperymentu".
> Dla mnie jest to pierwszy krok (nawet jeśli drugi raz postawiony) w pomyśle
radykalnego odejścia od "tekstowości" programowania.
>
> Na tym etapie nie ma to jednak absolutnie żadnej wartości praktycznej.
>
> Docelowo zaś: jest nadzieja, że dla różnych zastosowań zwiększy to efektywność
różnych interakcji za pośrednictwem Smartfona. Ale na tym etapie to tylko nadzieja.

Niedawno ukończyłem kolejny prototyp, który będę przedstawiał w najbliższy piątek na
warsztatach Scheme'owych na ICFP.
Jest już funkcjonalny w tym sensie, że można w nim już otwierać i zapisywać pliki.
Usprawniłem znacząco techniki pracy z wyrażeniami, i już jest "prawie przyjemnie".

Nagrałem też demo analogiczne do poprzedniego

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

To, co na poprzednim demie zajęło 3 minuty, w nowym edytorze zajmuje mi mniej niż
połowę tego czasu, tzn. ok. 1:20.
Na klawiaturze ekranowej napisanie tej definicji zajęło mi ciut poniżej minuty, więc
już się zaczyna robić porównywalnie.

(Nie zmienia to faktu, że na klasycznej klawiaturze zajmuje mi to kilkanaście sekund)

do góry

poniedziałek, 23 sierpnia 2021 o 14:28:06 UTC+2 Maciek Godek napisał(a):

> Nagrałem też demo analogiczne do poprzedniego

Ostatnio zdołałem też spiąć edytor z ewaluatorem, i choć jeszcze przede mną dużo
pracy, mam z tego dużo radochy

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

do góry