Discussion:
Programowanie wizualne
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
g***@gmail.com
2019-03-20 13:19:11 UTC
Permalink
Jeśli kogoś by to interesowało, oto nagranie przedstawiające prototyp
wizualnego edytora kodu (Lispa, oczywiście), nad którym ostatnio pracowałem:



Pozdrawiam
Maciej Sobczak
2019-03-21 06:58:58 UTC
Permalink
Post by g***@gmail.com
Jeśli kogoś by to interesowało, oto nagranie przedstawiające prototyp
http://youtu.be/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
g***@gmail.com
2019-03-21 08:19:30 UTC
Permalink
Post by Maciej Sobczak
Post by g***@gmail.com
Jeśli kogoś by to interesowało, oto nagranie przedstawiające prototyp
http://youtu.be/oxeB-8k-DBA
Bardzo fajne. Naprawdę. Podoba mi się też wizualizacja grafu, dobre do DSLi. Taka wizualizacja przydałaby się też dla podwyrażeń.
- 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
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/
Maciej Sobczak
2019-03-22 06:43:59 UTC
Permalink
Post by g***@gmail.com
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ł.
Post by g***@gmail.com
(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.
--
Maciej Sobczak * http://www.inspirel.com
g***@gmail.com
2019-03-22 07:03:13 UTC
Permalink
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
2019-03-25 07:02:12 UTC
Permalink
Post by g***@gmail.com
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.
Post by g***@gmail.com
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.
Post by g***@gmail.com
ale z logicznego punktu widzenia nie jest konieczne.
A jednak.
Post by g***@gmail.com
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ć?
Post by g***@gmail.com
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ę.
--
Maciej Sobczak * http://www.inspirel.com
g***@gmail.com
2019-03-25 08:46:05 UTC
Permalink
Post by Maciej Sobczak
Post by g***@gmail.com
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.
Post by Maciej Sobczak
Post by g***@gmail.com
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ę.
Post by Maciej Sobczak
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.
Post by Maciej Sobczak
Post by g***@gmail.com
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.
Post by Maciej Sobczak
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)
Post by Maciej Sobczak
Post by g***@gmail.com
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
2019-03-26 08:51:14 UTC
Permalink
Post by g***@gmail.com
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ś...
Post by g***@gmail.com
Post by Maciej Sobczak
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ść.
Post by g***@gmail.com
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
Post by g***@gmail.com
albo
wyrażenie - podwyrażenia
o tym za chwile
Post by g***@gmail.com
albo
katalog - podkatalogi (i pliki)
i linki twarde oraz symboliczne? Kto by się spodziewał?
Post by g***@gmail.com
W filozofii jest taki pomysł, który nazywa się "zasadą kompozycjonalności"
Oczywiście.
Post by g***@gmail.com
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.
--
Maciej Sobczak * http://www.inspirel.com
g***@gmail.com
2019-03-26 09:27:16 UTC
Permalink
Post by Maciej Sobczak
Post by g***@gmail.com
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)
Post by Maciej Sobczak
Post by g***@gmail.com
Post by Maciej Sobczak
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.
Post by Maciej Sobczak
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)
Post by Maciej Sobczak
Post by g***@gmail.com
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
Post by g***@gmail.com
albo
wyrażenie - podwyrażenia
o tym za chwile
Post by g***@gmail.com
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.
Post by Maciej Sobczak
Post by g***@gmail.com
W filozofii jest taki pomysł, który nazywa się "zasadą kompozycjonalności"
Oczywiście.
Post by g***@gmail.com
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:

Loading Image...
Loading Image...

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
Post by Maciej Sobczak
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
2019-03-26 19:31:10 UTC
Permalink
Post by g***@gmail.com
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
2019-03-27 06:57:31 UTC
Permalink
Post by g***@gmail.com
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.
Post by g***@gmail.com
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.
Post by g***@gmail.com
Post by Maciej Sobczak
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.
Post by g***@gmail.com
Zasadniczo się zgadzam. (Choć nie jestem pewien, czy bym chciał pisać
programy na automaty komórkowe).
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.
Post by g***@gmail.com
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.
Post by g***@gmail.com
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
fir
2019-03-21 11:11:46 UTC
Permalink
Post by g***@gmail.com
Jeśli kogoś by to interesowało, oto nagranie przedstawiające prototyp
http://youtu.be/oxeB-8k-DBA
Pozdrawiam
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)
g***@gmail.com
2019-05-28 13:22:17 UTC
Permalink
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.
g***@gmail.com
2020-05-02 20:57:58 UTC
Permalink
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:



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
2020-05-03 18:53:07 UTC
Permalink
Post by g***@gmail.com
http://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
g***@gmail.com
2020-05-03 21:32:53 UTC
Permalink
Post by Maciej Sobczak
Post by g***@gmail.com
http://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.
Post by Maciej Sobczak
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.
Post by Maciej Sobczak
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.
Post by Maciej Sobczak
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
2020-05-04 21:40:55 UTC
Permalink
Post by g***@gmail.com
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ę.
Post by g***@gmail.com
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).
Post by g***@gmail.com
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.
Post by g***@gmail.com
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.
Post by g***@gmail.com
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.
Post by g***@gmail.com
Ż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.
Post by g***@gmail.com
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...
Post by g***@gmail.com
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
g***@gmail.com
2020-05-05 08:38:47 UTC
Permalink
Post by Maciej Sobczak
Post by g***@gmail.com
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)
Post by Maciej Sobczak
Post by g***@gmail.com
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.
Post by Maciej Sobczak
Post by g***@gmail.com
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ć.
Post by Maciej Sobczak
Post by g***@gmail.com
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
Post by Maciej Sobczak
Post by g***@gmail.com
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 :]
Post by Maciej Sobczak
Post by g***@gmail.com
Ż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.
Post by g***@gmail.com
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:


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)
Post by Maciej Sobczak
Post by g***@gmail.com
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:


Post by Maciej Sobczak
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
2021-08-23 12:28:05 UTC
Permalink
Post by g***@gmail.com
Post by Maciej Sobczak
Post by g***@gmail.com
http://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.
Post by Maciej Sobczak
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



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
2021-09-11 18:27:25 UTC
Permalink
Post by Maciek Godek
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


Maciek Godek
2021-09-28 06:44:17 UTC
Permalink
Post by Maciek Godek
Post by Maciek Godek
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
http://youtu.be/oOHg74HYau4
Wczoraj organizatorzy ICFP wrzucili wreszcie pełne demo, które przedstawiłem na warsztatach:


Maciek Godek
2021-09-29 15:27:30 UTC
Permalink
Post by Maciek Godek
Post by Maciek Godek
Post by Maciek Godek
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
http://youtu.be/oOHg74HYau4
http://youtu.be/FlOghAlCDA4
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:



Sądzę, że ta prezentacja całkiem dobrze ilustruje to, co i ja bym chciał wyeksplorować ze swoim środowiskiem.
Maciek Godek
2021-10-28 11:03:11 UTC
Permalink
Post by Maciek Godek
Post by Maciek Godek
Post by Maciek Godek
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
http://youtu.be/oOHg74HYau4
http://youtu.be/FlOghAlCDA4
Ostatnio miałem też prezentację ("na żywo") o programowaniu na telefonie:

Maciek Godek
2023-08-02 13:41:41 UTC
Permalink
Post by Maciek Godek
Post by Maciek Godek
http://youtu.be/FlOghAlCDA4
http://youtu.be/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:



W miarę aktualne statusy publikuję też co miesiąc na mastodonie:
https://functional.cafe/@PaniczGodek
Maciek Godek
2023-08-11 14:27:42 UTC
Permalink
Post by Maciek Godek
Post by Maciek Godek
Post by Maciek Godek
http://youtu.be/FlOghAlCDA4
http://youtu.be/nGba4J-ThEk
Gdyby ktoś był zainteresowany statusem projektu, to w kwietniu miałem na jego temat prezentację
http://youtu.be/TymwS5N95aY
Opublikowałem też bardziej rozbudowane demo mające wyjaśniać podstawowe założenia projektu:


Arnold Ziffel
2023-08-19 01:38:54 UTC
Permalink
Post by Maciek Godek
http://youtu.be/bedP4m9FV8k
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
2023-09-10 18:36:29 UTC
Permalink
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ć?
--
Maciej Sobczak * http://www.inspirel.com
heby
2023-09-10 19:08:05 UTC
Permalink
Post by 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ł
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.
Post by Maciej Sobczak
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
2023-09-11 10:22:12 UTC
Permalink
Post by 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ć.
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)
Post by Maciej Sobczak
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.
Post by Maciej Sobczak
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.
Post by Maciej Sobczak
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
2023-09-11 20:38:38 UTC
Permalink
Post by Maciek Godek
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?
Post by Maciek Godek
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.
Post by Maciek Godek
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.
Post by Maciek Godek
Post by Maciej Sobczak
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ę.
--
Maciej Sobczak * http://www.inspirel.com
Maciek Godek
2023-09-11 21:50:20 UTC
Permalink
Post by Maciej Sobczak
Post by Maciek Godek
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ą.
Post by Maciej Sobczak
Post by Maciek Godek
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.
Post by Maciej Sobczak
Post by Maciek Godek
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
Post by Maciej Sobczak
Post by Maciek Godek
Post by Maciej Sobczak
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)
Post by Maciej Sobczak
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
2023-09-12 20:45:46 UTC
Permalink
Post by Maciek Godek
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.
Post by Maciek Godek
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ń.
Post by Maciek Godek
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
Post by Maciek Godek
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ć.
Post by Maciek Godek
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.
Post by Maciek Godek
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.
Post by Maciek Godek
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.
Post by Maciek Godek
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.
Post by Maciek Godek
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.
Post by Maciek Godek
(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.
Post by Maciek Godek
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ć.
Post by Maciek Godek
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.
--
Maciej Sobczak * http://www.inspirel.com
Maciek Godek
2023-09-14 13:01:02 UTC
Permalink
Post by Maciej Sobczak
Post by Maciek Godek
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.
Post by Maciek Godek
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ą.
Post by Maciej Sobczak
Post by Maciek Godek
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.
Post by Maciej Sobczak
Post by Maciek Godek
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)
Post by Maciej Sobczak
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)
Post by Maciej Sobczak
Post by Maciek Godek
(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.
Post by Maciek Godek
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.
Post by Maciej Sobczak
Post by Maciek Godek
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
2023-09-24 11:50:27 UTC
Permalink
Wczoraj udało mi się spiąć funkcjonalność "ewaluatora wizualnego" w moim edytorze.
(Choć oczywiście roboty tam jest jeszcze co nie miara...)



Loading...