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

do góry

> 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

do góry

W dniu czwartek, 21 marca 2019 07:59:00 UTC+1 użytkownik Maciej Sobczak napisał:
> > 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

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/

do góry

W dniu środa, 20 marca 2019 14:19:14 UTC+1 użytkownik g...@g...com napisał:
> 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

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)

do góry

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

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

do góry

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.

do góry

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

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

do góry

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_compositi
onality
(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 :)

do góry

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

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

do góry

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/109371062207
0460417

> 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-Go
dek

do góry