eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming › Ada Tutorial - w Instytucie Lotnictwa
Ilość wypowiedzi w tym wątku: 39

  • 31. Data: 2019-05-13 12:05:39
    Temat: Re: Ada Tutorial - w Instytucie Lotnictwa
    Od: g...@g...com

    W dniu poniedziałek, 13 maja 2019 09:27:56 UTC+2 użytkownik AK napisał:
    > On 2019-05-13 08:40, Maciej Sobczak wrote:
    > >>> Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.
    > >>
    > >> Tak. Na przykład Verilog.
    > >
    > > No właśnie. Czemu nie VHDL?
    > >
    > >> Na codzień mam do czynienia z VHDL. To taka ada + troche ekstra składni.
    > >> Pisanie bezpieczne w tym języku polega głównie na obchodzeniu przez
    > >> programistów silnego typowania chałupniczymi workaroundami. Stąd
    > >> popularnośc Veriloga, można tam pisać co się chce a i tak sie jakoś
    > >> skompiluje. Ludzie nie potrzebują bezpicznych jezyków i ograniczeń.uktu dec
    > >> Ludzie są leniwi i potrzebują dodawać inta do stringa a wynik ma być
    > >> taki jak ma być i już.
    > >
    > > Bardzo ciekawa obserwacja.
    > > I jak to można naprawić?
    > >
    > > Tylko nie pisz, że "gdyby zatrudnili porządnych programistów....",
    > > bo to jest argument od czapy.
    >
    > Nie od czapy, ale sedno sprawy.
    > Jak w każdym rzemiośle oprócz materiału, narzędzi, maszyn itp..
    > o końcowej jakości produktu *w dużej mierze* decyduje właśnie dobry
    > fachowiec.
    > To, że branża IT o tym dawno zapomniała i wciąż udaje (wzorem prof.
    > Marciniaka), że każdego dobrego fachowca można zastąpić skonczoną
    > liczbą studentów, to jej problem główny. Jeśli tego nie zmieni
    > (nie wróci do korzeni) to tysiace MISR czy auto-weryfikatorów nie
    > pomoże.
    > Branża IT zapomniałą nawet jak sie "tworzy" fachowca:
    > Wpierw uczeń (dobrych kilka lat), czeladnik (dobrych kilka lat),
    > potem pracownik (ale bez możliwości spieprzenia - tam gdzie można
    > zepsuć wciaż dzała i wykonuje mistrz), dopiero z czasem (wciąż
    > pod nadzorem i przyzwoleniem mistrza - bo to on wie co jest
    > "krytyczne" a co nie) roboty "rynkowe". Po wielu latach dopiero
    > można założyć "własną kużnię".
    > A w IT? nawet uC?
    > Dwa lata po studiach to już Experienced Senior Developer ;)

    Mogę w tym kontekście polecić esej Paula Grahama:
    http://www.paulgraham.com/re.html

    Znam programistów, którzy mimo ponad 10 lat doświadczenia
    wciąż umieją mniej, niż ogarnięci studenci 1-go roku informatyki.

    Ale ogólnie branża wydaje się na tyle złożona, że proste maksymy nie mają tu prostego
    zastosowania. Może z czasem się to ustabilizuje.


  • 32. Data: 2019-05-14 00:53:15
    Temat: Re: Ada Tutorial - w Instytucie Lotnictwa
    Od: AK <n...@n...net>

    On 2019-05-13 12:05, g...@g...com wrote:
    > W dniu poniedziałek, 13 maja 2019 09:27:56 UTC+2 użytkownik AK napisał:
    >> On 2019-05-13 08:40, Maciej Sobczak wrote:
    >>>>> Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.
    >>>>
    >>>> Tak. Na przykład Verilog.
    >>>
    >>> No właśnie. Czemu nie VHDL?
    >>>
    >>>> Na codzień mam do czynienia z VHDL. To taka ada + troche ekstra składni.
    >>>> Pisanie bezpieczne w tym języku polega głównie na obchodzeniu przez
    >>>> programistów silnego typowania chałupniczymi workaroundami. Stąd
    >>>> popularnośc Veriloga, można tam pisać co się chce a i tak sie jakoś
    >>>> skompiluje. Ludzie nie potrzebują bezpicznych jezyków i ograniczeń.uktu dec
    >>>> Ludzie są leniwi i potrzebują dodawać inta do stringa a wynik ma być
    >>>> taki jak ma być i już.
    >>>
    >>> Bardzo ciekawa obserwacja.
    >>> I jak to można naprawić?
    >>>
    >>> Tylko nie pisz, że "gdyby zatrudnili porządnych programistów....",
    >>> bo to jest argument od czapy.
    >>
    >> Nie od czapy, ale sedno sprawy.
    >> Jak w każdym rzemiośle oprócz materiału, narzędzi, maszyn itp..
    >> o końcowej jakości produktu *w dużej mierze* decyduje właśnie dobry
    >> fachowiec.
    >> To, że branża IT o tym dawno zapomniała i wciąż udaje (wzorem prof.
    >> Marciniaka), że każdego dobrego fachowca można zastąpić skonczoną
    >> liczbą studentów, to jej problem główny. Jeśli tego nie zmieni
    >> (nie wróci do korzeni) to tysiace MISR czy auto-weryfikatorów nie
    >> pomoże.
    >> Branża IT zapomniałą nawet jak sie "tworzy" fachowca:
    >> Wpierw uczeń (dobrych kilka lat), czeladnik (dobrych kilka lat),
    >> potem pracownik (ale bez możliwości spieprzenia - tam gdzie można
    >> zepsuć wciaż dzała i wykonuje mistrz), dopiero z czasem (wciąż
    >> pod nadzorem i przyzwoleniem mistrza - bo to on wie co jest
    >> "krytyczne" a co nie) roboty "rynkowe". Po wielu latach dopiero
    >> można założyć "własną kużnię".
    >> A w IT? nawet uC?
    >> Dwa lata po studiach to już Experienced Senior Developer ;)
    >
    > Mogę w tym kontekście polecić esej Paula Grahama:
    > http://www.paulgraham.com/re.html
    >
    > Znam programistów, którzy mimo ponad 10 lat doświadczenia
    > wciąż umieją mniej, niż ogarnięci studenci 1-go roku informatyki.

    Ależ też znam.
    Takich jest z 10%. Reszta to jednak zjawisko dokładnie odwrotne.
    Braki pokrywane wybujałą pewnością siebie (tez typowe zjawisko
    socjologiczne).

    >
    > Ale ogólnie branża wydaje się na tyle złożona, że proste maksymy
    nie mają tu prostego zastosowania. Może z czasem się to ustabilizuje.

    Bzdury godocie. Branza jak kazda inna.
    Sa o badziej zlozone branze (lotnictwo, mechanika, fizyka/numeryka,
    chemia, nawet metalurgia, niektore biotechnologie).
    IT psuje od lat brak "rak do pracy" co powoduje nieustanne psienie
    "fachowcow" co zwieksza brak "rak do pracy" co.. i kolo sie zamyka.
    Mechanizmy (w tym psychologiczno/socjologiczne) sa dokladnie
    takie jak gdzie indziej.

    PS: Juz w pierwszej pracy (~1990), gdy zacznalo sie "ssanie" na
    fachowcow (malutkie wtedy w stosunku dzisiejszego, ale jednak) i
    zaczely dzialac "mechanizmy" wywiesilem sobie na biurkiem taki
    ogolny "roadmap":
    1. radosne planowanie
    2. chybione wykonanie
    3. szukanie winnych
    4. karanie niewinnych
    5. nagradzanie tych co nie brali udzialu

    To pozostaje aktualne i uniwersalne do dzisiaj.
    O czym to swiadczy? Ano o tym ze oprocz "zlych fachowcow"
    drugim "kamieniem u nogi "ciagnacym jakosc w IT w dol jest
    szeroko pojety management (inna/odlegla warta elektronow).

    AK


  • 33. Data: 2019-05-14 08:51:55
    Temat: Re: Ada Tutorial - w Instytucie Lotnictwa
    Od: g...@g...com

    W dniu wtorek, 14 maja 2019 00:53:20 UTC+2 użytkownik AK napisał:

    > > Ale ogólnie branża wydaje się na tyle złożona, że proste maksymy
    > nie mają tu prostego zastosowania. Może z czasem się to ustabilizuje.
    >
    > Bzdury godocie. Branza jak kazda inna.

    No widzisz.
    A gdybyś w latach 90., zamiast wieszać sobie na ścianie ironiczny plan szukania
    kozłów ofiarnych zrobił wyszukiwarkę opierającą się na ważeniu grafu ilością
    odsyłaczy, które prowadzą do danej strony, mógłbyś teraz być wśród najbogatszych
    ludzi na świecie.

    Gdybyś kilka lat później stworzył forum, w którym użytkownicy zamiast odpowiadać
    mogliby klikać "lubię to", byłoby Cię stać, żeby oddawać miliardy dolarów na
    dobroczynność.

    Branże w rodzaju lotnictwa mają bardzo wysoki próg wejścia, a błędy w nich popełniane
    mogą kosztować ludzkie życie. Serwisy do dzielenia się zdjęciami kotków nie mają tego
    problemu - tu w najgorszym razie użytkownik nie zobaczy kotka. (Albo jacyś wieśniacy
    dokonają samosądu. Ale to nie Twój problem)


  • 34. Data: 2019-05-14 09:55:17
    Temat: Re: Ada Tutorial - w Instytucie Lotnictwa
    Od: Maciej Sobczak <s...@g...com>

    > > Tylko nie pisz, że "gdyby zatrudnili porządnych programistów....",
    > > bo to jest argument od czapy.
    >
    > Nie od czapy, ale sedno sprawy.
    > Jak w każdym rzemiośle oprócz materiału, narzędzi, maszyn itp..
    > o końcowej jakości produktu *w dużej mierze* decyduje właśnie dobry
    > fachowiec.

    I tu jest właśnie różnica pomiędzy systemami krytycznymi a "normalnymi", gdzie
    obowiązują reguły rzemieślnicze (używam tego słowa w pozytywnym sensie
    "craftmanship", żeby nie było).

    Jeżeli masz firmę, która robi cokolwiek niekrytycznego, to od jakości programistów
    zależy jakość produktu tak samo, jak od jakości jakiegokolwiek innego rzemieślnika
    zależy jakość tego co tworzy. Tu jest pełna zgoda. Co więcej, od ich jakości zależy
    nawet to, jak bardzo możesz odpuścić temat weryfikacji. W idealnym przypadku możesz w
    ogóle nie robić żadnej weryfikacji, bo produkt będzie po prostu dobry i po prostu
    odniesie sukces. Tak samo, jak Linux odniósł sukces, chociaż jądro Linuksa w ogóle
    nie ma unit testów.

    Powtórzę na wszelki wypadek: jądro Linuksa nie ma unit testów.

    I najwyraźniej nie jest to żaden problem.

    Natomiast jak robisz system krytyczny, to podlegasz regulacjom, standardom i
    certyfikacjom. I ciekawostka jest taka, że np. w branży lotniczej standardy jakości
    nie obejmują bezpośrednio rekrutacji. Tzn. rekrutacja jest pod lupą w takim samym
    stopniu, jak np. zakup długopisów albo żarówek.
    Czyli w myśl tych standardów jakość produktu nie bierze się z genialności kodera
    klepiącego kod (jak ktoś się uważa za genialnego, to niech sobie Linuksa poklepie, z
    pożytkiem dla wszystkich). Jakość bierze się z *weryfikacji* a nie z klepania.
    Właściwie to w zgodzie ze standardami (!) można by generować kod losowo tak długo aż
    przejdzie weryfikację.

    Dlatego kod napisany przez genialnego programistę sam w sobie jest *bezwartościowy*.
    Słyszałem określenie "there is no quality built in" w odniesieniu do naklepanego poza
    procesem kodu i to dobrze określa obowiązujący stan umysłu.

    Jakość bierze się z weryfikacji a nie z klepania kodu. I jeśli jakości nie ma, to
    znaczy tylko tyle, że weryfikacja była słaba.

    Dlatego mądre internetowe stwierdzenia "gdyby zatrudnili dobrych programistów" po
    każdym upublicznionym fakapie, w którym zginęli ludzie, są od czapy. To nie ta
    branża.

    > To, że branża IT

    Tak. Zgadzam się. Tylko że IT i systemy krytyczne to są odrębne branże.
    No chyba że zaczniemy je integrować i na siłę stosować metody jednej w drugiej. Ale
    zgadnijcie dlaczego Google odpuścił temat autonomicznych pojazdów... Przecież nie z
    powodu jakości programistów.

    > A w IT? nawet uC?
    > Dwa lata po studiach to już Experienced Senior Developer ;)

    Tak. Jest takie zjawisko. I na razie nie widać, żeby to się miało odwrócić.

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


  • 35. Data: 2019-05-14 15:25:32
    Temat: Re: Ada Tutorial - w Instytucie Lotnictwa
    Od: Adam M <a...@m...com>

    On Tuesday, May 14, 2019 at 3:55:18 AM UTC-4, Maciej Sobczak wrote:
    > > > Tylko nie pisz, że "gdyby zatrudnili porządnych programistów....",
    > > > bo to jest argument od czapy.
    > >
    > > Nie od czapy, ale sedno sprawy.
    > > Jak w każdym rzemiośle oprócz materiału, narzędzi, maszyn itp..
    > > o końcowej jakości produktu *w dużej mierze* decyduje właśnie dobry
    > > fachowiec.
    >
    > I tu jest właśnie różnica pomiędzy systemami krytycznymi a "normalnymi", gdzie
    obowiązują reguły rzemieślnicze (używam tego słowa w pozytywnym sensie
    "craftmanship", żeby nie było).
    >
    > Jeżeli masz firmę, która robi cokolwiek niekrytycznego, to od jakości programistów
    zależy jakość produktu tak samo, jak od jakości jakiegokolwiek innego rzemieślnika
    zależy jakość tego co tworzy. Tu jest pełna zgoda. Co więcej, od ich jakości zależy
    nawet to, jak bardzo możesz odpuścić temat weryfikacji. W idealnym przypadku możesz w
    ogóle nie robić żadnej weryfikacji, bo produkt będzie po prostu dobry i po prostu
    odniesie sukces. Tak samo, jak Linux odniósł sukces, chociaż jądro Linuksa w ogóle
    nie ma unit testów.
    >
    > Powtórzę na wszelki wypadek: jądro Linuksa nie ma unit testów.
    >
    > I najwyraźniej nie jest to żaden problem.
    >
    > Natomiast jak robisz system krytyczny, to podlegasz regulacjom, standardom i
    certyfikacjom. I ciekawostka jest taka, że np. w branży lotniczej standardy jakości
    nie obejmują bezpośrednio rekrutacji. Tzn. rekrutacja jest pod lupą w takim samym
    stopniu, jak np. zakup długopisów albo żarówek.
    > Czyli w myśl tych standardów jakość produktu nie bierze się z genialności kodera
    klepiącego kod (jak ktoś się uważa za genialnego, to niech sobie Linuksa poklepie, z
    pożytkiem dla wszystkich). Jakość bierze się z *weryfikacji* a nie z klepania.
    Właściwie to w zgodzie ze standardami (!) można by generować kod losowo tak długo aż
    przejdzie weryfikację.
    >
    > Dlatego kod napisany przez genialnego programistę sam w sobie jest
    *bezwartościowy*. Słyszałem określenie "there is no quality built in" w odniesieniu
    do naklepanego poza procesem kodu i to dobrze określa obowiązujący stan umysłu.
    >
    > Jakość bierze się z weryfikacji a nie z klepania kodu. I jeśli jakości nie ma, to
    znaczy tylko tyle, że weryfikacja była słaba.
    >
    > Dlatego mądre internetowe stwierdzenia "gdyby zatrudnili dobrych programistów" po
    każdym upublicznionym fakapie, w którym zginęli ludzie, są od czapy. To nie ta
    branża.
    >
    > > To, że branża IT
    >
    > Tak. Zgadzam się. Tylko że IT i systemy krytyczne to są odrębne branże.
    > No chyba że zaczniemy je integrować i na siłę stosować metody jednej w drugiej. Ale
    zgadnijcie dlaczego Google odpuścił temat autonomicznych pojazdów... Przecież nie z
    powodu jakości programistów.
    >
    > > A w IT? nawet uC?
    > > Dwa lata po studiach to już Experienced Senior Developer ;)
    >
    > Tak. Jest takie zjawisko. I na razie nie widać, żeby to się miało odwrócić.
    >
    > --
    > Maciej Sobczak * http://www.inspirel.com

    Zgadzam się z szanownym kolegą w 100% ale powoli branżą lotnicza o której kolega
    pisze ze ścislą weryfikacja systemów krtycznych przestaje isnieć (nie wspomnę o
    branży samochodowej gdzie ścisła weryfikację systmów krytycznych odpuszczono sobie
    już dawno na zasadzie jeśli koszty odszkodowań są niższe od zysków to robimy tak by
    było taniej) - przykład ostatnie fiasko Boeinga - zaczyna sie projektowanie systemów
    przez ksiegowych a nie przez inzynierów.


  • 36. Data: 2019-05-15 08:09:11
    Temat: Re: Ada Tutorial - w Instytucie Lotnictwa
    Od: Maciej Sobczak <s...@g...com>

    > Zgadzam się z szanownym kolegą w 100% ale powoli branżą lotnicza o której kolega
    pisze ze ścislą weryfikacja systemów krtycznych przestaje isnieć (nie wspomnę o
    branży samochodowej gdzie ścisła weryfikację systmów krytycznych odpuszczono sobie
    już dawno na zasadzie jeśli koszty odszkodowań są niższe od zysków to robimy tak by
    było taniej) - przykład ostatnie fiasko Boeinga - zaczyna sie projektowanie systemów
    przez ksiegowych a nie przez inzynierów.

    Tak, jest problem. Ale akurat ostatnie fiasko Boeinga nie pokazuje, że cokolwiek się
    zaczęło, bo zjawisko zbytniego spoufalenia wykonawców (Boeing) z certyfikatorami
    (FAA) wcale nie powstało skokowo i w ostatnim czasie.
    I problem został rozpoznany a korekta oczywiście ma kierunek odwrotny, czyli
    likwidacja spoufalenia i spadek wzajemnego zaufania.
    Przykładowy komentarz:

    https://www.rt.com/news/454229-european-air-regulato
    r-doesnt-trust-faa/

    I zauważ, że w tym komentarzu nie ma ani słowa o wpływie księgowych na dalszy proces.
    Więc jest szansa, że jednak to nie księgowi będą mieć ostatnie słowo.

    Jak będzie w przyszłości - nie wiemy. Ale akurat branża lotnicza tym się różni od
    przykładowej moto, że jest absurdalnie czuła na ilość wypadków, w sensie pojedynczych
    zdarzeń, które przechylają szalę z jednego ekstremum w drugie. Jak się rozwali jeden
    samolot, to wszyscy udają, że to siła wyższa, na którą nikt nie miał wpływu; ale jak
    się rozwali drugi, to jest międzynarodowy kryzys. Dlatego kultura tworzenia systemów
    krytycznych w tej branży przetrwa dłużej. Tzn. dłużej, niż np. w moto.
    Jak długo i co będzie po niej - nie wiemy.

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


  • 37. Data: 2019-05-15 21:25:30
    Temat: Re: Ada Tutorial - w Instytucie Lotnictwa
    Od: AK <n...@n...net>

    On 2019-05-14 08:51, g...@g...com wrote:
    > W dniu wtorek, 14 maja 2019 00:53:20 UTC+2 użytkownik AK napisał:
    >
    >>> Ale ogólnie branża wydaje się na tyle złożona, że proste maksymy
    >> nie mają tu prostego zastosowania. Może z czasem się to ustabilizuje.
    >>
    >> Bzdury godocie. Branza jak kazda inna.
    >
    > No widzisz.
    > A gdybyś w latach 90., zamiast wieszać sobie na ścianie ironiczny plan szukania
    kozłów ofiarnych zrobił wyszukiwarkę opierającą się na ważeniu grafu ilością
    odsyłaczy, które prowadzą do danej strony, mógłbyś teraz być wśród najbogatszych
    ludzi na świecie.

    Mlokosie. Na czym wyszukiwarke?
    W tych latach (1987) byl COCOM i nawet zwykle kompilatory C sciagalo
    sie nielegalnie po nocach po roznych BBSach (bo Inetu _w ogole_ nie bylo
    wtedy). Te BBSy dzialaly z zawrotna szybkoscia 2400b/sec, a tu mi tu o
    jakiejs wyszukiwarce. Heh

    > Gdybyś kilka lat później stworzył forum, w którym użytkownicy zamiast odpowiadać
    mogliby klikać "lubię to", byłoby Cię stać, żeby oddawać miliardy dolarów na
    dobroczynność.
    >

    Heh. Poczytaj sobie np. o firmie Logotec. Wyprzedzala nie tylko Polske,
    ale i byla na topie w swiecie w zakresie mobilnych aplikacji (m.in.
    glowna nagroda Microsoftu za tworzene srodowiska developersiego
    do tworzenia aplikacji mobilnych).
    I co? I nie ma firmy. Dlaczego? Bo wtedy nie bylo komorek a handheldy
    z WinCE i Palm byly drogie, a siec miala raptem 9600b/sek (choc to
    ostatnie nie bylo przeszkoda).
    Skutkiem firma upadla choc jej Web@DDM (jestem pomyslodawca nazwy heh :)
    wyprzedzal "epoke".
    Znam jeszcze inne przypadki tego typu wiec Twoje "swiatle rady" zachowaj
    zarozumialy mlokosie dla siebie.

    > Branże w rodzaju lotnictwa mają bardzo wysoki próg wejścia, a błędy w nich
    popełniane mogą kosztować ludzkie życie.

    .. a tam zaczynalem w 1987. Wpierw jako tokarz, potem programista metod
    numerycznych (i nie tylko).
    Wiec przestan mnie mlokosie pouczac co powinienem a co nie.
    Pojecia nie masz co wtedy mozna bylo, a co nie i _jak_ nalezalo dzialac.

    AK


  • 38. Data: 2019-05-16 08:55:12
    Temat: Re: Ada Tutorial - w Instytucie Lotnictwa
    Od: g...@g...com

    W dniu środa, 15 maja 2019 21:25:35 UTC+2 użytkownik AK napisał:
    iejs wyszukiwarce. Heh
    >
    > > Gdybyś kilka lat później stworzył forum, w którym użytkownicy zamiast odpowiadać
    mogliby klikać "lubię to", byłoby Cię stać, żeby oddawać miliardy dolarów na
    dobroczynność.
    > >
    >
    > Heh. Poczytaj sobie np. o firmie Logotec. Wyprzedzala nie tylko Polske,
    > ale i byla na topie w swiecie w zakresie mobilnych aplikacji (m.in.
    > glowna nagroda Microsoftu za tworzene srodowiska developersiego
    > do tworzenia aplikacji mobilnych).
    > I co? I nie ma firmy. Dlaczego? Bo wtedy nie bylo komorek a handheldy
    > z WinCE i Palm byly drogie, a siec miala raptem 9600b/sek (choc to
    > ostatnie nie bylo przeszkoda).
    > Skutkiem firma upadla choc jej Web@DDM (jestem pomyslodawca nazwy heh :)
    > wyprzedzal "epoke".
    > Znam jeszcze inne przypadki tego typu wiec Twoje "swiatle rady" zachowaj
    > zarozumialy mlokosie dla siebie.

    To Ty stwierdziłeś, że branża (IT? uC?) to "branża jak każda inna".
    W latach 90. przyszli założyciele Googla uderzali do wielkiego molocha kapitałowego
    Yahoo!, który indeksował Internet. I co? I zostali odprawieni z kwitkiem.
    Nikt wówczas nie potrafił przewidzieć, co jest naprawdę potrzebne.
    (Może nie "nikt", ale bardzo nieliczni. Ale raczej "wydawało im się",
    niż "naprawdę wiedzieli")

    Kiedy Facebook debiutował na giełdzie, mój kolega twierdził, że to absurdalne, że
    jego wartość jest większa od wartości koncernu General Motors. Ale jakimś cudem
    doszło do tego, że Facebookowi udało się osiągnąć masę krytyczna użytkowników i
    zostać "portalem społecznościowym całego świata", a w rezultacie "kontrolować myśli"
    miliardów ludzi na świecie.

    Nie znam się na tym na tyle dobrze, żeby powiedzieć, dlaczego to Facebook, a nie np.
    grono.net, osiągnął taki sukces. Nie wiem, czy ktokolwiek się na tym zna (może tak?)

    Ale owszem, moje, jak je nazywasz, "światłe rady" można sobie otrzaskać o kant tyłka,
    i to jest właśnie ich sednem. Żeby odnieść sukces w tej branży, wystarczy akurat
    przypadkiem być we właściwym miejscu we właściwym czasie i rozumieć coś, czego nikt
    inny nie rozumie. Nie wiem, czy tak jest w każdej branży - ale wydaje się, że
    księgowi czy lekarze czy inżynierowie budownictwa nie są w podobnej sytuacji.


  • 39. Data: 2019-08-04 18:11:25
    Temat: Re: Ada Tutorial - w Instytucie Lotnictwa
    Od: Borneq <b...@a...hidden.pl>

    On 4/20/19 3:02 PM, Sebastian Biały wrote:
    > Ależ bardzo prosto. Ariane dupneła z powodu tego że ktoś w "bezpiecznym"
    > języku zrobił założenie że coś zmieci się w 16 bitach. Typowe myślenie
    > asemblerowca który wszędzie widzi bajty do oszczędzenia.

    Bezpieczeństwo języka ma znaczenie,
    wyobraźmy sobie że rakieta mam wykonać jakiś manewr a tu wyskakuje błąd
    "method NNN not found" bo oprogramowanie zostało napisane w
    interpretowanym Pythonie ;-)
    albo łazik ląduje na Księżycu, a tu włączyła się aktualizacja Windows.:))
    W skromniejszym przypadku: cenne są milisekundy a tu włącza się Garbage
    Collector.

    W takim Rust kompilator robi wiele sprawdzeń za nas.

strony : 1 ... 3 . [ 4 ]


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: