eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming › Narzędzia do wizualizacji systemów Embedded
Ilość wypowiedzi w tym wątku: 43

  • 41. Data: 2021-04-13 17:50:24
    Temat: Re: Narzędzia do wizualizacji systemów Embedded
    Od: Maciej Sobczak <s...@g...com>

    > Jeżeli rzeczywiście niczego więcej nie potrzeba, to czas, który nie został
    wydatkowany na robienie dokumentacji, to czas zaoszczędzony.
    > A jeżeli potrzeba czegoś więcej, to ta potrzeba prędzej czy później da o sobie znać
    w jakimś procesie.
    > Pisanie dokumentacji po to, żeby była napisana dokumentacja, to kiepski pomysł.

    O, i ładnie zmieniliśmy temat. Bo teraz rozmawiamy o tym, czy dokumentacja jest
    potrzebna.
    Otóż ja nigdzie nie twierdziłem, że zawsze jest potrzebna. Jest cała masa projektów
    (i projekcików), gdzie się jej w ogóle nie robi i wszyscy są z tego zadowoleni.
    Zwłaszcza ci, którzy akceptują reverse engineering jako metodę poznawczą. Ale już o
    tym było.

    Więc nie kłócimy się o to, czy dokumentacja ma być, czy ma jej nie być. Kłócimy się o
    to, co jest a co nie jest dokumentacją.
    (tzn. ja mam coraz mniejszą ochotę się o to przepychać)

    > Znów mogę posłużyć się przykładem [...] podzieliłem się nim ze swoim przyjacielem

    No widzisz. Jak nie potrzebujesz dokumentacji, to jej nie rób. Do dzielenia się z
    przyjacielem lepsze jest piwo, niż dokumentacja.

    > > "Koń jaki jest, każdy widzi." Wiesz, skąd to zdanie pochodzi? Z bardzo poważnego
    źródła. Ale jednak z biegiem czasu zaczęliśmy wymagać więcej, więc nawet w tych
    poważnych źródłach już takich zdań nie ma.
    > Nie rozumiem.

    To było w pierwszej encyklopedii. Autor uznał, że nie ma potrzeby rozpisywać się na
    temat konia, bo przecież każdy wie, jak wygląda koń. Takie samodokumentujące się
    konie wtedy były. I nikomu to nie przeszkadzało.

    > > Bo nie jest dokumentacją.
    > Według JAKIEJ definicji?

    Według mojej. Serio. Napisałem już tyle na ten jeden temat, że mam dość tłumaczenia
    tego i się z tego. Jak nie dotarło, to poległem dydaktyktycznie i pokornie to
    przyjmuję. Pocieszam się, że może inni grupowicze skorzystali z tej dyskusji.
    Kod nie jest dokumentacją, ja nie umiem (lepiej) tłumaczyć, wypij piwo z
    przyjacielem.

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


  • 42. Data: 2021-04-13 22:57:42
    Temat: Re: Narzędzia do wizualizacji systemów Embedded
    Od: Maciek Godek <g...@g...com>

    wtorek, 13 kwietnia 2021 o 17:50:25 UTC+2 Maciej Sobczak napisał(a):

    > > Znów mogę posłużyć się przykładem [...] podzieliłem się nim ze swoim przyjacielem

    >
    > No widzisz. Jak nie potrzebujesz dokumentacji, to jej nie rób. Do dzielenia się z
    przyjacielem lepsze jest piwo, niż dokumentacja.
    > > > "Koń jaki jest, każdy widzi." Wiesz, skąd to zdanie pochodzi? Z bardzo
    poważnego źródła. Ale jednak z biegiem czasu zaczęliśmy wymagać więcej, więc nawet w
    tych poważnych źródłach już takich zdań nie ma.
    > > Nie rozumiem.
    > To było w pierwszej encyklopedii. Autor uznał, że nie ma potrzeby rozpisywać się na
    temat konia, bo przecież każdy wie, jak wygląda koń. Takie samodokumentujące się
    konie wtedy były. I nikomu to nie przeszkadzało.

    Nie były samodokumentujące się. Być może wiedza na ich temat była bardziej
    powszechna.
    Ale kod źródłowy tym rózni się od konia, że jest napisany (albo, jak to określa
    Wikipedia, "komunikowalny"). Tak jak dokumentacja.

    W każdym razie abstrahując od tego kontekstu historyczno-kulturowego, nadal nie
    rozumiem jak się to ma do naszej dyskusji.

    Ale może to jest kwestia różnicy perspektyw.
    Studiując logikę, nauczyłem się widzieć formalne języki jako coś, co ma służyć przede
    wszystkim do formułowania precyzyjnych i zwięzłych opisów, które w przypadku języka
    naturalnego byłyby rozwlekłe i niejednoznaczne.
    Ale rozumiem, że taka perspektywa jest odmienna od "normalnego" uczenia się
    programowania, gdzie mamy jakiś "język komputerowy", z którym musimy walczyć, żeby
    uzyskać taki efekt, jaki chcemy. W takich sytuacjach program często nie jest
    "komunikatem", tylko właśnie owocem walki; czymś, co trzeba "odszyfrować".

    Do tego dochodzi też kwestia samej nauki języka - pewne rzeczy w języku formalnym
    (tak samo zresztą jak w każdym innym języku) stają się zrozumiałe dopiero wtedy,
    kiedy nauczymy się biegle tym językiem posługiwać. Istotne jest też to, z jakim
    językiem się zmagamy: ostatnio trochę programuję w Javie, i jest to język tak
    toporny, że ciężko w nim cokolwiek wyrazić.

    Przypomniała mi się też anegdota związana z powstaniem Lispa, która w jakiś sposób
    wydaje się powiązana z tematem tej dyskusji.
    Była opowiedziana w eseju Paula Grahama "Hackers and Painters":

    McCarthy said: "Steve Russell said, look, why don't I program this eval ... and I
    said to him, ho, ho, you're confusing theory with practice, this eval is intended for
    reading, not for computing. But he went ahead and did it. That is, he compiled the
    eval in my paper into IBM 704 machine code, fixing bug, and then advertised this as a
    Lisp interpreter, which it certainly was. So at that point Lisp had essentially the
    form that it has today ..."

    > > > Bo nie jest dokumentacją.
    > > Według JAKIEJ definicji?
    > Według mojej. Serio. Napisałem już tyle na ten jeden temat, że mam dość tłumaczenia
    tego i się z tego. Jak nie dotarło, to poległem dydaktyktycznie i pokornie to
    przyjmuję.

    OK, według Twojej. Tak może być. Ale podasz tę definicję? Bo od początku dyskusji jej
    nie podałeś.
    Stwierdziałeś tylko, że "kod nie jest dokumentacją", powołując się na definicję z
    Wikipedii, z której taki wniosek nie wynika (a jeżeli wynika, to nie pokazałeś, w
    jaki sposób).
    Czy może Twoja definicja też jest "jak ten koń"? Że "czym jest dokumentacja wg
    Sobczaka, każdy widzi"?


  • 43. Data: 2021-04-16 11:26:03
    Temat: Re: Narzędzia do wizualizacji systemów Embedded
    Od: Maciek Godek <g...@g...com>

    wtorek, 13 kwietnia 2021 o 22:57:44 UTC+2 Maciek Godek napisał(a):
    > Przypomniała mi się też anegdota związana z powstaniem Lispa, która w jakiś sposób
    wydaje się powiązana z tematem tej dyskusji.
    > Była opowiedziana w eseju Paula Grahama "Hackers and Painters":

    Jeszcze mi się skojarzyła jedna rzecz. Na Quorze jest gość co się nazywa Gerry
    Rzeppa, który stworzył język programowania o nazwie "Plain English".
    Przykładowy program, z tej odpowiedzi
    https://www.quora.com/How-do-you-write-a-program-tha
    t-requests-a-number-of-numbers-and-then-displays-it-
    separately-Python-development/answer/Gerry-Rzeppa

    To run:
    Start up.
    Clear the screen.
    Put a one-line console at the top of the screen.
    Get a string of numbers from the user with "Enter some numbers".
    Loop.
    If the string is blank, break.
    Get a number from the string.
    Display the number anywhere below the console.
    Repeat.
    Refresh the screen.
    Wait for the escape key.
    Shut down.

strony : 1 ... 4 . [ 5 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: