Programowanie wizualne

[godek....@gmail.com]

Jeśli kogoś by to interesowało, oto nagranie przedstawiające prototyp
wizualnego edytora kodu (Lispa, oczywiście), nad którym ostatnio pracowałem:

https://www.youtube.com/watch?v=oxeB-8k-DBA

Pozdrawiam

[Maciej Sobczak]

> Jeśli kogoś by to interesowało, oto nagranie przedstawiające prototyp
> wizualnego edytora kodu (Lispa, oczywiście), nad którym ostatnio pracowałem:
>
> https://www.youtube.com/watch?v=oxeB-8k-DBA

Bardzo fajne. Naprawdę. Podoba mi się też wizualizacja grafu, dobre do DSLi. Taka wizualizacja przydałaby się też dla podwyrażeń.

Natomiast muszę też podzielić się goryczą związaną z używaniem narzędzi i notacji graficznych w większej skali, bo ona pokazuje granicę stosowalności takich rozwiązań. Otóż gdy pojawia się zespół albo dłuższa (czy w ogóle jakakolwiek) historia projektu, na czoło potrzeb wysuwa się efektywność tych dwóch czynności:

- diff
- merge

Jeżeli te dwie nie działają absolutnie sprawnie i bez zgrzytów, to metoda/narzędzie/notacja nie nadaje się do użytku. Te dwie czynności ledwo (!) opanowaliśmy przez ostatnie 4 dekady dla plików tekstowych (a konkretnie: o strukturze sekwencji linii tekstu), ale dla notacji graficznych właściwie wcale. To jest kierunek, w którym potrzebny jest przełom, ale go nigdzie nie widzę. Może tutaj jakiś research?

Niemniej, żeby nie było, że tylko krytykuję - naprawdę fajne. :-)

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

[godek....@gmail.com]

Dzięki :)

Akurat jeżeli idzie o diffowanie i merge'owanie, to też trochę o tym myślałem. Moim zdaniem to, że nasze języki programowania są oparte na tekście, a nie na strukturze, jest sporym utrudnieniem (i pojawiają się idiotyczne diffy w rodzaju tego że ktoś gdzieś dodał nową linię albo że się zmieniły końcówki linii na CRLF, albo że ktoś woli spacje a ktoś inny tabulacje).

Z ciekawszych wpisów to kiedyś natknąłem się na to:
http://fazzone.github.io/autochrome.html

oraz źródło inspiracji tegoż:
http://thume.ca/2017/06/17/tree-diffing/

i jeszcze coś podobnego z innego źródła:
https://github.com/plande/ydiff

oraz tu:
http://jelv.is/cow/

[fir]

no spoko, ostatni miesiac slabo spie i nie mam do tego glowy ale ogolnie fajnie jest pogadac czasem o tworzeniu realnych programow (na comp.lang,c maja np taka manie ze gadaja tylko o jezyku a to robienie programow jest czyms czym czleowiek sie powinien zajmowac)

[Maciej Sobczak]

> Moim zdaniem to, że nasze języki programowania są oparte na tekście, a nie na strukturze, jest sporym utrudnieniem

Ale też pozwala zunifikować zestaw narzędzi do pracy z kodem. O ile jeszcze można sobie wyobrazić, że ktoś na swoim komputerze chce sobie zainstalować osobne narzędzie do każdego swojego ulubionego języka, to wiele takich narzędzi działa w połączeniu np. z repozytoriami. Taki git diff na zdalnym serwerze robi robotę, bo nie wnika, w jakim ulubionym dialekcie LISPa ktoś coś napisał.

> (i pojawiają się idiotyczne diffy w rodzaju tego że ktoś gdzieś dodał nową linię albo że się zmieniły końcówki linii na CRLF, albo że ktoś woli spacje a ktoś inny tabulacje).

To, czy taki diff jest idiotyczny, zależy od kontekstu. A nie chcemy obciążać tym kontekstem zdalnej infrastruktury. Ot, taka sytuacja.

Rozwiązaniem może być projektowanie języków tak, aby dały się sensownie diffować. Czy wtedy ogon merda psem? Nie wiem, bo język też jest narzędziem (tak jak ten diff!) a nie celem.

[godek....@gmail.com]

Moim zdaniem to, o czym mówisz, wynika z głęboko zakorzenionego przekonania, że plik tekstowy to podstawowa jednostka przechowywania informacji.
Owo przekonanie jest co prawda zakorzenione w implementacji uniksa i jego różnych klonów, ale z logicznego punktu widzenia nie jest konieczne.
Ja jestem zdania, że jest wręcz szkodliwe, bo to sprawia, że każdy program (włączając w to języki programowania) wymyśla swoje własne sposoby na reprezentowanie drzewiastych struktur.
W moim odczuciu to powoduje wielkie problemy z integracją, bo zamiast oglądać różnice w strukturze, jesteśmy zmuszani do oglądania różnic w serializacjach struktur.

[Maciej Sobczak]

> Moim zdaniem to, o czym mówisz, wynika z głęboko zakorzenionego przekonania, że plik tekstowy to podstawowa jednostka przechowywania informacji.

Ale z praktycznego punktu widzenia (czyli w kontekście istniejącej infrastruktury do przetwarzania tych plików), tak właśnie jest.

> Owo przekonanie jest co prawda zakorzenione w implementacji uniksa i jego różnych klonów,

Zdumiewające, jak łatwo wszyscy obwiniają Uniksa o wszystko. Ludzie używają plików tekstowych od kilku tysięcy lat. To właśnie wcześniejszy zapis wizualny zamieniono na pliki tekstowe, czyli na sekwencje znaków, bo tak było praktyczniej. I to nawet na długo przed wynalezieniem czcionki drukarskiej, kiedy to praktyczna wartość takiego zapisu okazała się być nośnikiem cywilizacyjnego przyśpieszenia.
Dzisiaj praktyczna wartość plików tekstowych nadal wynika z istniejącej infrastruktury i dostępnych metod przetwarzania, ale tym razem w postaci diffów i merge'ów.

> ale z logicznego punktu widzenia nie jest konieczne.

A jednak.

> Ja jestem zdania, że jest wręcz szkodliwe, bo to sprawia, że każdy program (włączając w to języki programowania) wymyśla swoje własne sposoby na reprezentowanie drzewiastych struktur.

A kto powiedział, że drzewiaste struktury są specjalne? Można nawet powiedzieć, że poza drzewami właściwie nie ma drzew, więc drzewo jako struktura nie zasługuje na specjalne traktowanie. Diagramy UML, schematy elektryczne, mapa drogowa, "Układ Kowalskiego", czy nawet drzewo (sic!) genealogiczne to w ogólności nie są drzewa. Więc po co je promować?

> W moim odczuciu to powoduje wielkie problemy z integracją, bo zamiast oglądać różnice w strukturze, jesteśmy zmuszani do oglądania różnic w serializacjach struktur.

To prawda. Ale lepszego (tzn. bardziej praktycznego) pomysłu obecnie nie widzę.

[godek....@gmail.com]

W dniu poniedziałek, 25 marca 2019 08:02:13 UTC+1 użytkownik Maciej Sobczak napisał:
> > Moim zdaniem to, o czym mówisz, wynika z głęboko zakorzenionego przekonania, że plik tekstowy to podstawowa jednostka przechowywania informacji.
>
> Ale z praktycznego punktu widzenia (czyli w kontekście istniejącej infrastruktury do przetwarzania tych plików), tak właśnie jest.

W sobotę miałem prezentację, której opowiadałem co nieco, i teraz mogę oficjalnie ujawnić linka do źródeł:
https://github.com/panicz/sracket (plik 5.rkt)

Do uruchomienia potrzebne jest środowisko Racket https://racket-lang.org/

Oczywiście, konwersja z postaci wizualnej do "zwykłego tekstowego lispa"
jest trywialna. (wystarczy wysłać komunikat "as-expression" do "głównego"
obiektu)
Ale poza tym nie ma fajerwerków: raczej trochę jeszcze temu brakuje
do w pełni sprawnego edytora.

> > Owo przekonanie jest co prawda zakorzenione w implementacji uniksa i jego różnych klonów,
>
> Zdumiewające, jak łatwo wszyscy obwiniają Uniksa o wszystko. Ludzie używają plików tekstowych od kilku tysięcy lat. To właśnie wcześniejszy zapis wizualny zamieniono na pliki tekstowe, czyli na sekwencje znaków, bo tak było praktyczniej. I to nawet na długo przed wynalezieniem czcionki drukarskiej, kiedy to praktyczna wartość takiego zapisu okazała się być nośnikiem cywilizacyjnego przyśpieszenia.

Może masz rację.

> Dzisiaj praktyczna wartość plików tekstowych nadal wynika z istniejącej infrastruktury i dostępnych metod przetwarzania, ale tym razem w postaci diffów i merge'ów.

Temat jest ważny, ale zwróciłbym uwagę, że diffy i merge są mimo wszystko
narzędziem awangardowym, nieznanym większości użytkowników komputerów.

> > Ja jestem zdania, że jest wręcz szkodliwe, bo to sprawia, że każdy program (włączając w to języki programowania) wymyśla swoje własne sposoby na reprezentowanie drzewiastych struktur.
>
> A kto powiedział, że drzewiaste struktury są specjalne?

Na przykład hinduski filozof Yaska z 4 wieku przed naszą erą.
Albo Platon. Albo John Locke, George Boole, Gottlob Frege,
John McCarthy, i właściwie każdy, kto używa w swoim projekcie
takich formatów serializacji, jak XML, YML czy JSON,
oraz każdy, kto definiuje gramatyki dla języków programowania.

> Można nawet powiedzieć, że poza drzewami właściwie nie ma drzew, więc drzewo jako struktura nie zasługuje na specjalne traktowanie. Diagramy UML, schematy elektryczne, mapa drogowa, "Układ Kowalskiego", czy nawet drzewo (sic!) genealogiczne to w ogólności nie są drzewa. Więc po co je promować?

Ja bym powiedział, że dlatego, że drzewa stanowią dla nas naturalną
formę organizowania złożoności. W praktycznie każdej działalności
człowieka możesz znaleźć schemat
układ - podukłady
albo
wyrażenie - podwyrażenia
albo
katalog - podkatalogi (i pliki)

W filozofii jest taki pomysł, który nazywa się "zasadą kompozycjonalności"
https://en.wikipedia.org/wiki/Principle_of_compositionality
(jest tam też link do większego artykułu ze stanfordzkiej encyklopedii)

> > W moim odczuciu to powoduje wielkie problemy z integracją, bo zamiast oglądać różnice w strukturze, jesteśmy zmuszani do oglądania różnic w serializacjach struktur.
>
> To prawda. Ale lepszego (tzn. bardziej praktycznego) pomysłu obecnie nie widzę.

No, ja mimo wszystko będę dalej eksplorował poletko programów
tworzonych poprzez zagnieżdżanie pudełek w pudełkach :)

[Maciej Sobczak]

> Temat jest ważny, ale zwróciłbym uwagę, że diffy i merge są mimo wszystko
> narzędziem awangardowym, nieznanym większości użytkowników komputerów.

Jednak myślę, że diff jest narzędziem bardziej powszechnym, niż Racket, który kazałeś zainstalować, żeby zobaczyć, co zrobiłeś...

> > A kto powiedział, że drzewiaste struktury są specjalne?
>
> Na przykład hinduski filozof Yaska z 4 wieku przed naszą erą.
> Albo Platon. Albo John Locke, George Boole, Gottlob Frege,
> John McCarthy, i właściwie każdy, kto używa w swoim projekcie
> takich formatów serializacji, jak XML, YML czy JSON,
> oraz każdy, kto definiuje gramatyki dla języków programowania.

Kucha. Te wszystkie wynalazki są wtórne względem tego, co opisują. Potem jest tak, ktoś jest przekonany, że modeluje drzewo a za chwilę potrzebne mu są wskaźniki silne i słabe, albo GC do sprzątania cykli, albo jeszcze coś. XML, YML czy JSON to też złe przykłady, patrz <a href="..."> albo dorobione po fakcie referencje do innych obiektów w JSON. To są właśnie te słabe wskaźniki, które okazują się być potrzebne, bo świat wcale nie chce być drzewiasty. Drzewiaste struktury to przypadki szczególne, trywializujące rzeczywistość.

> Ja bym powiedział, że dlatego, że drzewa stanowią dla nas naturalną
> formę organizowania złożoności. W praktycznie każdej działalności
> człowieka możesz znaleźć schemat
> układ - podukłady

i relacje między nimi, patrz dowolny schemat UML

> albo
> wyrażenie - podwyrażenia

o tym za chwile

> albo
> katalog - podkatalogi (i pliki)

i linki twarde oraz symboliczne? Kto by się spodziewał?

> W filozofii jest taki pomysł, który nazywa się "zasadą kompozycjonalności"

Oczywiście.

> No, ja mimo wszystko będę dalej eksplorował poletko programów
> tworzonych poprzez zagnieżdżanie pudełek w pudełkach :)

Bardzo dobrze. Na tym poletku warto też pomyśleć o uogólnieniach - bo wyrażenia są strukturami 1D z zagnieżdżeniami. Tymczasem nie ma powodu sądzić, że jest to jedyny użyteczny model obliczeniowy, a skoro mamy formy wizualne (pudełkowe czy jakieś inne) do ich reprezentacji, to być może warto się zastanowić nad wyrażeniami 2D. Żeby nie było, że to jakiś pomysł od czapy, to automaty komórkowe (np. gra w życie Conway'a) są w tych okolicach. A żeby nie było, że to to pomysł niepraktyczny, to przecież hardware jest tak realizowany od zawsze. Pytanie, czy da się tak robić software.

I tu wracamy do wyrażeń, że niby są drzewiaste. Moim zdaniem algebra taka jaką znamy jest wtórna względem wynalazku sekwencyjnego pisma. Ktoś napisał pierwsze wyrażenie algebraiczne w ramach ograniczeń takiej właśnie formy. I dobrze, bo dało się to drukować czcionkami a dzisiaj mamy diff i merge :-), ale to nadal jest wtórne.

[godek....@gmail.com]

W dniu wtorek, 26 marca 2019 09:51:15 UTC+1 użytkownik Maciej Sobczak napisał:
> > Temat jest ważny, ale zwróciłbym uwagę, że diffy i merge są mimo wszystko
> > narzędziem awangardowym, nieznanym większości użytkowników komputerów.
>
> Jednak myślę, że diff jest narzędziem bardziej powszechnym, niż Racket, który kazałeś zainstalować, żeby zobaczyć, co zrobiłeś...

"Kazałem" to mocne słowo.
Udostępniłem źródłą. Nie ma w nich silnej zależności od Racketa
(początkowo pisałem to dla swojego frameworka SLAYER, ale Racketa
łatwiej zainstalować. Mógłbym też przenieść do przeglądarki,
żeby było "powszechniej", i pewnie kiedyś tak zrobię, ale
nie jest to dla mnie priorytet)

> > > A kto powiedział, że drzewiaste struktury są specjalne?
> >
> > Na przykład hinduski filozof Yaska z 4 wieku przed naszą erą.
> > Albo Platon. Albo John Locke, George Boole, Gottlob Frege,
> > John McCarthy, i właściwie każdy, kto używa w swoim projekcie
> > takich formatów serializacji, jak XML, YML czy JSON,
> > oraz każdy, kto definiuje gramatyki dla języków programowania.
>
> Kucha. Te wszystkie wynalazki są wtórne względem tego, co opisują.

(Niemal) każdy opis jest wtórny względem tego, co opisuje.
Taka już jego uroda.

> Potem jest tak, ktoś jest przekonany, że modeluje drzewo a za chwilę potrzebne mu są wskaźniki silne i słabe, albo GC do sprzątania cykli, albo jeszcze coś. XML, YML czy JSON to też złe przykłady, patrz <a href="..."> albo dorobione po fakcie referencje do innych obiektów w JSON. To są właśnie te słabe wskaźniki, które okazują się być potrzebne, bo świat wcale nie chce być drzewiasty. Drzewiaste struktury to przypadki szczególne, trywializujące rzeczywistość.

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)

> > Ja bym powiedział, że dlatego, że drzewa stanowią dla nas naturalną
> > formę organizowania złożoności. W praktycznie każdej działalności
> > człowieka możesz znaleźć schemat
> > układ - podukłady
>
> i relacje między nimi, patrz dowolny schemat UML
>
> > albo
> > wyrażenie - podwyrażenia
>
> o tym za chwile
>
> > albo
> > katalog - podkatalogi (i pliki)
>
> i linki twarde oraz symboliczne? Kto by się spodziewał?

I niekompatybilności z systemami, które tego nie obsługują,
bo pomysł bynajmniej nie był oczywisty.

> > W filozofii jest taki pomysł, który nazywa się "zasadą kompozycjonalności"
>
> Oczywiście.
>
> > No, ja mimo wszystko będę dalej eksplorował poletko programów
> > tworzonych poprzez zagnieżdżanie pudełek w pudełkach :)
>
> Bardzo dobrze. Na tym poletku warto też pomyśleć o uogólnieniach - bo wyrażenia są strukturami 1D z zagnieżdżeniami. Tymczasem nie ma powodu sądzić, że jest to jedyny użyteczny model obliczeniowy, a skoro mamy formy wizualne (pudełkowe czy jakieś inne) do ich reprezentacji, to być może warto się zastanowić nad wyrażeniami 2D. Żeby nie było, że to jakiś pomysł od czapy, to automaty komórkowe (np. gra w życie Conway'a) są w tych okolicach. A żeby nie było, że to to pomysł niepraktyczny, to przecież hardware jest tak realizowany od zawsze. Pytanie, czy da się tak robić software.

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

Dziś jeszcze natrafiłem na taki, dość interesujący projekt
https://github.com/disconcision/fructure
+ animacja jak to wygląda w praktyce
https://twitter.com/disconcision/status/1093710622070460417

> I tu wracamy do wyrażeń, że niby są drzewiaste. Moim zdaniem algebra taka jaką znamy jest wtórna względem wynalazku sekwencyjnego pisma. Ktoś napisał pierwsze wyrażenie algebraiczne w ramach ograniczeń takiej właśnie formy. I dobrze, bo dało się to drukować czcionkami a dzisiaj mamy diff i merge :-), ale to nadal jest wtórne.

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

Co do istoty rozwoju pisma w wynalezienie algebry (i logiki),
to oczywiście jak najbardziej się zgadzam. Tylko temu pismu
zawsze towarzyszyła kaligrafia albo typografia.

Coś kiedyś trochę w tym temacie pisałem na kworze:
https://www.quora.com/How-do-you-think-code-as-used-in-programming-should-be-pronounced/answer/Panicz-Godek

[Wojciech Muła]

On Tuesday, March 26, 2019 at 10:27:17 AM UTC+1, godek....@gmail.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.

[Maciej Sobczak]

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

[godek....@gmail.com]

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/1104705015506059265

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

Wszystkich zainteresowanych serdecznie zapraszam.

[godek....@gmail.com]

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

[Maciej Sobczak]

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

[godek....@gmail.com]

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.

[Maciej Sobczak]

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

[godek....@gmail.com]

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

[Maciek Godek]

niedziela, 3 maja 2020 o 23:32:55 UTC+2 godek....@gmail.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)

[Maciek Godek]

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

[Maciek Godek]

Wczoraj organizatorzy ICFP wrzucili wreszcie pełne demo, które przedstawiłem na warsztatach:

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

[Maciek Godek]

Jeszcze mi się skojarzyło, że ubiegłej jesieni na konferencji Racketa dowiedziałem się o projekcie "interaktywnej składni" tworzonym dla środowiska programistycznego dr Racket:

https://www.youtube.com/watch?v=8htgAxJuK5c

Sądzę, że ta prezentacja całkiem dobrze ilustruje to, co i ja bym chciał wyeksplorować ze swoim środowiskiem.

[Maciek Godek]

wtorek, 28 września 2021 o 08:44:18 UTC+2 Maciek Godek napisał(a):

Ostatnio miałem też prezentację ("na żywo") o programowaniu na telefonie:
https://www.youtube.com/watch?v=nGba4J-ThEk

[Maciek Godek]

czwartek, 28 października 2021 o 13:03:12 UTC+2 Maciek Godek napisał(a):

> > https://www.youtube.com/watch?v=FlOghAlCDA4
> Ostatnio miałem też prezentację ("na żywo") o programowaniu na telefonie:
> https://www.youtube.com/watch?v=nGba4J-ThEk

Gdyby ktoś był zainteresowany statusem projektu, to w kwietniu miałem na jego temat prezentację
na European Lisp Symposium, i organizatorzy wrzucili niedawno nagranie na youtube:

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

W miarę aktualne statusy publikuję też co miesiąc na mastodonie:
https://functional.cafe/@PaniczGodek

[Maciek Godek]

Opublikowałem też bardziej rozbudowane demo mające wyjaśniać podstawowe założenia projektu:

https://www.youtube.com/watch?v=bedP4m9FV8k&feature=youtu.be

[Arnold Ziffel]

Maciek Godek <godek....@gmail.com> wrote:

> Opublikowałem też bardziej rozbudowane demo mające wyjaśniać podstawowe założenia projektu:
>
> https://www.youtube.com/watch?v=bedP4m9FV8k&feature=youtu.be

Tu już chyba i tak nikt nie został.

--
Przychodzi baba do lekarza:
- Panie doktorze, dziękuję za wspaniałe leczenie.
- Ależ ja leczyłem pani męża, nie panią!
- Tak, tak, ale ja po nim wszystko dziedziczę...

[Maciej Sobczak]

Ludzie przez kupę czasu wkładali mnóstwo wysiłku w proponowanie metod, które oddalają nas od formatu tekstowego, bo wszyscy jakoś zakładali, że format tekstowy jest dla nas obciążeniem albo ograniczeniem i dlatego lepiej, jak będziemy np. rysować zamiast pisać.
I może nawet tak by się ten świat dalej rozwijał, ale niestety AI i metody przetwarzania tekstu rozwinęły się na tyle, że format tekstowy znowu jest atrakcyjny. Bo łatwiej jest napisać prompt dla ChatGPT, niż go narysować.
Nie, nie chodzi o to, że wszyscy będą teraz programować przy użyciu GPT - ale też nigdy nie było tak, że wszyscy rysowali. Tu bardziej chodzi o to, czy jakiś format doceniamy i chcemy w niego inwestować, czy raczej od niego odchodzić.
A sytuacja wygląda tak, że teraz format tekstowy (wliczam w to gadanie do mikrofonu) jest znowu fajny.

Myślę, że możemy spodziewać się pewnego renesansu formatu tekstowego. Bo okazało się, że nie trzeba go porzucać, skoro można go lepiej/sprytniej przetwarzać.
A to z kolei może oznaczać mniejsze zainteresowanie (czyli mniejsze inwestycje) formatami graficznymi, wolniejszą adopcję modelowania, itd. Ewentualnie, to komputer może nam coś narysować.

Czyli - po co komu programowanie wizualne, skoro z komputerem można się po prostu dogadać?

[heby]

On 10/09/2023 20:36, Maciej Sobczak wrote:
> Ludzie przez kupę czasu wkładali mnóstwo wysiłku w proponowanie metod, które oddalają nas od formatu tekstowego, bo wszyscy jakoś zakładali, że format tekstowy jest dla nas obciążeniem albo ograniczeniem i dlatego lepiej, jak będziemy np. rysować zamiast pisać.
> I może nawet tak by się ten świat dalej rozwijał

Nie kojarzę jakiejś większej rewolucji programowania nie-tekstowego w
ostatnich latach. Owszem, było pełno drag'n'drop operators na rynku,
głównie z Delphi i trochę z C# oraz pojedyncze sztuki LabView, ale
trudno nazwać to rewolucją lub trendem. Wręcz okazało się, że ten sposób
"programowania" generuje skrajnie gównianej jakości kod którego nie da
się utrzymać i testować w sensowny sposób, więc budowanie w tym dużej
apliakcji to proszenie się o kłopoty. Kto miał resztkę mózgu w
managmencie, uciekł od tego przy pierwszym smrodzie dochodzącym z kodu.

> Czyli - po co komu programowanie wizualne, skoro z komputerem można się po prostu dogadać?

Nigdy nie było potrzebne, poza kilkoma niszami.

[Maciek Godek]

niedziela, 10 września 2023 o 20:36:32 UTC+2 Maciej Sobczak napisał(a):
> Ludzie przez kupę czasu wkładali mnóstwo wysiłku w proponowanie metod, które oddalają nas od formatu tekstowego, bo wszyscy jakoś zakładali, że format tekstowy jest dla nas obciążeniem albo ograniczeniem i dlatego lepiej, jak będziemy np. rysować zamiast pisać.

Wydaje mi się, że to stwierdzenie po pierwsze zawiera błędną generalizację, a po drugie jest bardzo nieprecyzyjne.
Co to znaczy "format nietekstowy"? Format, w którym nie wszystkie bajty są kodowane jako ASCII? Format, którego raczej nie da się przeglądać za pomocą notepada?
No to na przykład PDF jest takim formatem, i wydaje się dość popularny.

Jeżeli ściągniemy sobie projekt Scratcha na dysk, to jest to plik binarny, który jednak przy bliższych oględzinach okazuje się paczką zip, zawierającą w sobie zbiór plików tekstowych w formacie JSON.

Z kolei środowisko programistyczne dr Racket ma dość osobliwą cechę. Normalnie pracuje na plikach kodowanych w ASCII czy innym unikodzie, ale możemy do tekstu programu wkleić obrazek.
Tyle że wtedy jeżeli zapiszemy ten plik, to nagle staje się kodowany binarnie, i nie da się go edytować w żadnym innym edytorze tekstu (co wiele osób, w tym ja, uważa za raczej niefortunne).

W moich pracach nad GRASPem to, żeby formatem wymiany danych były pliki tekstowe, edytowalne w innych edytorach, jest jednym z moich priorytetów.

Co do "rysowania zamiast pisania", to wydaje się, że jest to fałszywa dychotomia.
Tzn. zarówno rysujemy, jak i piszemy (i tak raczej pozostanie)

> I może nawet tak by się ten świat dalej rozwijał, ale niestety AI i metody przetwarzania tekstu rozwinęły się na tyle, że format tekstowy znowu jest atrakcyjny. Bo łatwiej jest napisać prompt dla ChatGPT, niż go narysować.
> Nie, nie chodzi o to, że wszyscy będą teraz programować przy użyciu GPT - ale też nigdy nie było tak, że wszyscy rysowali. Tu bardziej chodzi o to, czy jakiś format doceniamy i chcemy w niego inwestować, czy raczej od niego odchodzić.
> A sytuacja wygląda tak, że teraz format tekstowy (wliczam w to gadanie do mikrofonu) jest znowu fajny.

Jeżeli gadanie do mikrofonu nazywasz "formatem tekstowym", to ja już nic nie rozumiem.

> Myślę, że możemy spodziewać się pewnego renesansu formatu tekstowego. Bo okazało się, że nie trzeba go porzucać, skoro można go lepiej/sprytniej przetwarzać.
> A to z kolei może oznaczać mniejsze zainteresowanie (czyli mniejsze inwestycje) formatami graficznymi, wolniejszą adopcję modelowania, itd. Ewentualnie, to komputer może nam coś narysować.

Szczerze powiedziawszy, format tekstowy nigdy donikąd sobie nie poszedł, więc trudno się spodziewać jego renesansu.

> Czyli - po co komu programowanie wizualne, skoro z komputerem można się po prostu dogadać?

W latach 70. i 80. głównym sposobem na interakcję z komputerem było korzystanie z wiersza poleceń.
Ale w roku 1984 Apple wypuściło Macintosha wraz z systemem okienkowym, i nagle okazało się, że z komputera może korzystać każdy.

[Maciej Sobczak]

> Co to znaczy "format nietekstowy"?

To jest bardzo fajne pytanie.
Dla mnie format tekstowy to taki, który można naturalnie podyktować komuś przez telefon (dlatego dalej nie rozróżniam pisania na klawiaturze od gadania do mikrofonu).
Przykładowo, poprzednie zdanie jest w formacie tekstowym. I nie wyciągaj ode mnie ścisłej definicji tego co jest "naturalne", bo nie będzie mi się chciało odpisać. W skrócie, czytanie na głos wartości kolejnych bajtów z pliku binarnego nie jest naturalnym przekazaniem jego treści, ale przeczytanie na głos tego zdania już jest i dlatego to zdanie jest tekstem. OK?

> Co do "rysowania zamiast pisania", to wydaje się, że jest to fałszywa dychotomia.
> Tzn. zarówno rysujemy, jak i piszemy (i tak raczej pozostanie)

No właśnie - mam wrażenie, że nie będziemy aż tak dużo rysować, jeśli będziemy mogli więcej powiedzieć (albo napisać). Właśnie o tą zależność mi chodziło.

> Jeżeli gadanie do mikrofonu nazywasz "formatem tekstowym", to ja już nic nie rozumiem.

Cała kupa ludzi korzysta z systemów typu speech recognition albo speech synthesis i bardzo dobrze rozumieją. Dzieci w szkole też już niczego nie czytają, bo wszystkie lektury mają w audiobookach. A polecenia głosowe to już chyba nawet zmywarki kumają.
Właśnie dlatego, że na poziomie komunikacji tekst i mowa to jest z grubsza to samo.

> > Czyli - po co komu programowanie wizualne, skoro z komputerem można się po prostu dogadać?
> W latach 70. i 80. głównym sposobem na interakcję z komputerem było korzystanie z wiersza poleceń.
> Ale w roku 1984 Apple wypuściło Macintosha wraz z systemem okienkowym, i nagle okazało się, że z komputera może korzystać każdy.

Nie, dalej nie każdy. Dalej potrzebne są kursy obsługi komputera, tak jak kiedyś. Okienka nie zastąpiły tekstu, wręcz przeciwnie - jak na ironię, to właśnie w okienku na komputerze Apple piszę ten tekst, w odpowiedzi na Twój tekst. Po, bez jaj, 40 latach tej okienkowej "rewolucji".
Ale mógłbym go też podyktować. Podobnie jak mógłbym kazać temu aplu, żeby mi Twojego posta przeczytał - i to jest cenniejsze, niż te okienka. A mogę to zrobić właśnie dlatego, że tekst i mowa to jest w zasadzie to samo.

Ale na pewno nie chciałoby mi się niczego w tej dyskusji rysować. Mówi się, że obraz jest wart tysiąca słów, ale nie mówi się o wysiłku, jaki trzeba włożyć, żeby ten obraz był tyle wart. Wydaje się, że tekst jest ciągle tańszy - a jeśli dzięki technice może być coraz łatwiej przetwarzany, to tym bardziej utrwala jego dominację.

[Maciek Godek]

poniedziałek, 11 września 2023 o 22:38:40 UTC+2 Maciej Sobczak napisał(a):
> > Co to znaczy "format nietekstowy"?
> To jest bardzo fajne pytanie.
> Dla mnie format tekstowy to taki, który można naturalnie podyktować komuś przez telefon (dlatego dalej nie rozróżniam pisania na klawiaturze od gadania do mikrofonu).
> Przykładowo, poprzednie zdanie jest w formacie tekstowym. I nie wyciągaj ode mnie ścisłej definicji tego co jest "naturalne", bo nie będzie mi się chciało odpisać. W skrócie, czytanie na głos wartości kolejnych bajtów z pliku binarnego nie jest naturalnym przekazaniem jego treści, ale przeczytanie na głos tego zdania już jest i dlatego to zdanie jest tekstem. OK?

Przez telefon można też szeptać albo śpiewać.
Trochę mi się też kojarzy podcast "Future of Coding", gdzie używają różnych efektów dźwiękowych, żeby np. mówić kursywą.

> > Co do "rysowania zamiast pisania", to wydaje się, że jest to fałszywa dychotomia.
> > Tzn. zarówno rysujemy, jak i piszemy (i tak raczej pozostanie)
> No właśnie - mam wrażenie, że nie będziemy aż tak dużo rysować, jeśli będziemy mogli więcej powiedzieć (albo napisać). Właśnie o tą zależność mi chodziło.

Ale szczerze powiedziawszy nie mam wrażenia, żebyśmy mogli powiedzieć więcej.
Powiedzieć możemy wciąż mniej więcej tyle samo. Ej Aj nie dodaje tutaj zbyt wiele.
Z kolei wyobrażam sobie, że taki np. Picasso mógł być bardziej przyzwyczajony do rysowania, i często mógł woleć coś narysować, niż opowiedzieć.

Jakiś czas temu widziałem jak ktoś zbudował prototyp takiego systemu okienkowego, gdzie wpisywałeś w jakieś pole np. "kalkulator" albo "arkusz kalkulacyjny" albo "procesor tekstu", i "sztuczna inteligencja" "sama" generowała działający (lepiej lub gorzej) program.

Rzecz jednak w tym, że zarówno kalkulator jak i arkusz kalkulacyjny a nawet (sic) procesor tekstu są w swojej istocie nietekstowe. To okienka, które się wyświetlają, i które wyglądają, i na które się naciska.

Nasze doświadczenie jest fundamentalnie nietekstowe. A jeżeli wydaje się, że jest inaczej, to jest klasyczny błąd potraktowania mapy jako terytorium.

> > Jeżeli gadanie do mikrofonu nazywasz "formatem tekstowym", to ja już nic nie rozumiem.
> Cała kupa ludzi korzysta z systemów typu speech recognition albo speech synthesis i bardzo dobrze rozumieją. Dzieci w szkole też już niczego nie czytają, bo wszystkie lektury mają w audiobookach. A polecenia głosowe to już chyba nawet zmywarki kumają.
> Właśnie dlatego, że na poziomie komunikacji tekst i mowa to jest z grubsza to samo.

Kiedyś natrafiłem na Quorze na taką odpowiedź (która bardzo mi się spodobała):
https://www.quora.com/How-do-I-convince-someone-that-there-is-no-difference-between-spoken-and-written-language-i-e-same-rules-apply/answer/Oscar-Tay-1

> > > Czyli - po co komu programowanie wizualne, skoro z komputerem można się po prostu dogadać?
> > W latach 70. i 80. głównym sposobem na interakcję z komputerem było korzystanie z wiersza poleceń.
> > Ale w roku 1984 Apple wypuściło Macintosha wraz z systemem okienkowym, i nagle okazało się, że z komputera może korzystać każdy.
> Nie, dalej nie każdy. Dalej potrzebne są kursy obsługi komputera, tak jak kiedyś. Okienka nie zastąpiły tekstu, wręcz przeciwnie - jak na ironię, to właśnie w okienku na komputerze Apple piszę ten tekst, w odpowiedzi na Twój tekst. Po, bez jaj, 40 latach tej okienkowej "rewolucji".
> Ale mógłbym go też podyktować. Podobnie jak mógłbym kazać temu aplu, żeby mi Twojego posta przeczytał - i to jest cenniejsze, niż te okienka. A mogę to zrobić właśnie dlatego, że tekst i mowa to jest w zasadzie to samo.

Nawet jeśli się zgodzimy, że tekst i mowa to w zasadzie to samo, pozostaje całe spektrum obszarów, w których oba są równie nieefektywne.

Przykładowo, spróbuj opisać tekstem zawartość instrukcji składania mebli z Ikei, albo instrukcji składania klocków LEGO. I potem spróbuj użyć tej instrukcji.

(zresztą żeby się przekonać, jak ograniczona jest ekspresywność tekstu i mowy, wystarczy wejść na youtube'a)

> Ale na pewno nie chciałoby mi się niczego w tej dyskusji rysować. Mówi się, że obraz jest wart tysiąca słów, ale nie mówi się o wysiłku, jaki trzeba włożyć, żeby ten obraz był tyle wart. Wydaje się, że tekst jest ciągle tańszy - a jeśli dzięki technice może być coraz łatwiej przetwarzany, to tym bardziej utrwala jego dominację.

Ale może to wcale nie wynika z inherentnej wartości tekstu, tylko stąd, że do posługiwania się tekstem jesteś bardziej przyzwyczajony?

Równie dobrze można by było powiedzieć, że nie ma sensu np. budować samolotów czy helikopterów, bo ludzie i tak w głównej mierze poruszają się po ziemi, a wynalazki w rodzaju samochodu tylko utrwalają dominację naziemnego przemieszczania się naszego gatunku.

[Maciej Sobczak]

> Przez telefon można też szeptać albo śpiewać.
> Trochę mi się też kojarzy podcast "Future of Coding", gdzie używają różnych efektów dźwiękowych, żeby np. mówić kursywą.

Kursywa to pikuś, gorzej z kolorami (podkreślanie składni? ale czad). Oczywiście te media mają różne możliwości, ale chodzi o rdzeń tej formy komunikacji.

> Ale szczerze powiedziawszy nie mam wrażenia, żebyśmy mogli powiedzieć więcej.

Możemy dzięki temu, że narzędzia coraz więcej rozumieją. Wtedy się okazuje, że np. nie musimy być ograniczeni sztywną składnią albo jakimiś narzuconymi arbitralnie szablonami poleceń.

> Z kolei wyobrażam sobie, że taki np. Picasso mógł być bardziej przyzwyczajony do rysowania, i często mógł woleć coś narysować, niż opowiedzieć.

To może faktycznie lepiej, że rysował, niż gdyby miała mówić tak, jak rysował. :-D

> Jakiś czas temu widziałem jak ktoś zbudował prototyp takiego systemu okienkowego, gdzie wpisywałeś w jakieś pole np. "kalkulator" albo "arkusz kalkulacyjny" albo "procesor tekstu", i "sztuczna inteligencja" "sama" generowała działający (lepiej lub gorzej) program.

No właśnie. W taki sposób tekst umacnia swoją dominację. Nie mówię nawet o tym, że łatwiej napisać "kalkulator", niż go narysować.

> Rzecz jednak w tym, że zarówno kalkulator jak i arkusz kalkulacyjny a nawet (sic) procesor tekstu są w swojej istocie nietekstowe. To okienka, które się wyświetlają, i które wyglądają, i na które się naciska.

Bo akurat tak sobie twórca tego narzędzia chciał. Ale ja częściej widuję prezentacje narzędzi, które na tekstową zaczepkę reagują jeszcze większą ilością tekstu, i to nawet całkiem przyzwoitego.

> Nasze doświadczenie jest fundamentalnie nietekstowe.

Być może. Ale tu mówimy (sic!) o komunikacji a nie o doświadczeniu. W szczególności o komunikacji z komputerem. Ja sobie mogę mieć wizualne doświadczenie kolorów, ale jak piszę w wymaganiach, że guzik do startowania jakiejś aktywności ma być zielony, to ten przekaz jest tekstowy.

> Kiedyś natrafiłem na Quorze na taką odpowiedź (która bardzo mi się spodobała):
> https://www.quora.com/How-do-I-convince-someone-that-there-is-no-difference-between-spoken-and-written-language-i-e-same-rules-apply/answer/Oscar-Tay-1

Zgadza się. Są ludzie, którzy mają problemy z mówieniem (nawet gdy piszą). Są też tacy, co mają problemy z pisaniem. Ale to nadal jest ten sam koncept komunikacyjny.

> Nawet jeśli się zgodzimy, że tekst i mowa to w zasadzie to samo, pozostaje całe spektrum obszarów, w których oba są równie nieefektywne.

Tak. I obraz wart tysiąca nieefektywnych słów nadal będzie nieefektywny.

> Przykładowo, spróbuj opisać tekstem zawartość instrukcji składania mebli z Ikei, albo instrukcji składania klocków LEGO. I potem spróbuj użyć tej instrukcji.

Ładny przykład. Można też wskazać, że jedno i drugie ma potencjalnie szerszą grupę docelową - i nie chodzi o złośliwość, tylko o fakt, że np. rysunku nie trzeba tłumaczyć na N języków a klockami bawią się też dzieci, które mogłyby tekstu nie przeczytać.
Ale jednak instrukcja obsługi lodówki (tak, takiej co to się otwiera drzwi, wyciąga piwo i zamyka) to gruba literatura.

> (zresztą żeby się przekonać, jak ograniczona jest ekspresywność tekstu i mowy, wystarczy wejść na youtube'a)

I płynnie wracając do tematu programowania wizualnego, nie wyobrażam sobie nagrywania kamerą kalamburów, żeby przekonać kompilator o co mi chodzi.

> Ale może to wcale nie wynika z inherentnej wartości tekstu, tylko stąd, że do posługiwania się tekstem jesteś bardziej przyzwyczajony?

Na pewno. Zwłaszcza, że zacząłem mówić zanim zacząłem programować.

> Równie dobrze można by było powiedzieć, że nie ma sensu np. budować samolotów czy helikopterów, bo ludzie i tak w głównej mierze poruszają się po ziemi, a wynalazki w rodzaju samochodu tylko utrwalają dominację naziemnego przemieszczania się naszego gatunku.

No akurat trafiłeś jak kulą w płot, bo faktycznie, dostępność szybkich połączeń kolejowych jest dla niektórych argumentem za tym, żeby mniej latać. I to nawet w niektórych państwach ma być uregulowane.

[Maciek Godek]

wtorek, 12 września 2023 o 22:45:48 UTC+2 Maciej Sobczak napisał(a):
> > Przez telefon można też szeptać albo śpiewać.
> > Trochę mi się też kojarzy podcast "Future of Coding", gdzie używają różnych efektów dźwiękowych, żeby np. mówić kursywą.
> Kursywa to pikuś, gorzej z kolorami (podkreślanie składni? ale czad). Oczywiście te media mają różne możliwości, ale chodzi o rdzeń tej formy komunikacji.
> > Ale szczerze powiedziawszy nie mam wrażenia, żebyśmy mogli powiedzieć więcej.
> Możemy dzięki temu, że narzędzia coraz więcej rozumieją. Wtedy się okazuje, że np. nie musimy być ograniczeni sztywną składnią albo jakimiś narzuconymi arbitralnie szablonami poleceń.

Swego czasu sporo na ten temat myślałem.
Jednym z powodów, dla których przylgnąłem do Lispa, jest właśnie to, że jest to język, w którym to ja decyduję, jak go używać, i nie jestem w żadnym stopniu ograniczony.
(No dobra, w jakiejś mierze jestem ograniczony jego tekstowością, ale mam nadzieję, że już niedługo)

Jeżeli jednak idzie o niedawny wysyp narzędzi opartych o AI, to do nich jestem raczej sceptycznie nastawiony - z mojego doświadczenia wydają się "rozumieć" mniej, niż statyczne analizatory kodu, a przez to, że przywracają do programowania niejednoznaczność języka naturalnego (+ te swoje różne halucynacje), mam wrażenie, że dziecko zostaje wylane z kąpielą.

> > Jakiś czas temu widziałem jak ktoś zbudował prototyp takiego systemu okienkowego, gdzie wpisywałeś w jakieś pole np. "kalkulator" albo "arkusz kalkulacyjny" albo "procesor tekstu", i "sztuczna inteligencja" "sama" generowała działający (lepiej lub gorzej) program.
> No właśnie. W taki sposób tekst umacnia swoją dominację. Nie mówię nawet o tym, że łatwiej napisać "kalkulator", niż go narysować.

Łatwiej przesunąć guzik myszką na ekranie, niż słownie wyjaśnić komputerowi, który guzik ma przesunąć i do którego miejsca.

> > Przykładowo, spróbuj opisać tekstem zawartość instrukcji składania mebli z Ikei, albo instrukcji składania klocków LEGO. I potem spróbuj użyć tej instrukcji.
> Ładny przykład. Można też wskazać, że jedno i drugie ma potencjalnie szerszą grupę docelową - i nie chodzi o złośliwość, tylko o fakt, że np. rysunku nie trzeba tłumaczyć na N języków a klockami bawią się też dzieci, które mogłyby tekstu nie przeczytać.

No właśnie, mi dokładnie chodzi o tę grupę docelową.
Mi nie chodzi o to, żeby rezygnować ze słów czy tekstu, tylko żeby ten tekst wzbogacić o obraz.
Łatwo wykazać, że tekst + obraz > tekst (a w najgorszym razie że tekst + obraz >= tekst)

> Ale jednak instrukcja obsługi lodówki (tak, takiej co to się otwiera drzwi, wyciąga piwo i zamyka) to gruba literatura.

Której i tak nikt nie czyta (i w której i tak są obrazki)

> > (zresztą żeby się przekonać, jak ograniczona jest ekspresywność tekstu i mowy, wystarczy wejść na youtube'a)
> I płynnie wracając do tematu programowania wizualnego, nie wyobrażam sobie nagrywania kamerą kalamburów, żeby przekonać kompilator o co mi chodzi.
> > Ale może to wcale nie wynika z inherentnej wartości tekstu, tylko stąd, że do posługiwania się tekstem jesteś bardziej przyzwyczajony?
> Na pewno. Zwłaszcza, że zacząłem mówić zanim zacząłem programować.

I pewnie jakby podsumować, to więcej czasu spędziłeś klepiąc w klawiaturę, niż nakładając farbę olejną na płótno.

> > Równie dobrze można by było powiedzieć, że nie ma sensu np. budować samolotów czy helikopterów, bo ludzie i tak w głównej mierze poruszają się po ziemi, a wynalazki w rodzaju samochodu tylko utrwalają dominację naziemnego przemieszczania się naszego gatunku.
> No akurat trafiłeś jak kulą w płot, bo faktycznie, dostępność szybkich połączeń kolejowych jest dla niektórych argumentem za tym, żeby mniej latać. I to nawet w niektórych państwach ma być uregulowane.

I ja się pod tym całym sercem podpisuję.
Ale sądzę, że pociągi nieprędko zastąpią loty transkontynentalne, i nawet że do akcji ratunkowych na zakorkowanych autostradach często efektywniej jest wysyłać helikoptery, niż kolejne samochody.

[Maciek Godek]

Wczoraj udało mi się spiąć funkcjonalność "ewaluatora wizualnego" w moim edytorze.
(Choć oczywiście roboty tam jest jeszcze co nie miara...)

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