W dniu poniedziałek, 28 stycznia 2013 11:28:57 UTC+1 użytkownik M.M. napisał:
> W dniu poniedziałek, 28 stycznia 2013 10:14:05 UTC+1 użytkownik Andrzej Jarzabek
napisał:

> Trudno opracować jakiś miarodajny sposób w ocenie zagadnienia.

Ale można to zagadnienie łatwo przetransformować: zdefiniujmy zbiór cech, jakich
oczekujemy od języka pod kątem wsparcia dla pisania poprawnych programów i kolejno
odkreślając checkboksy porównajmy parę języków. Nie trzeba pisać żadnego programu,
żeby to wykonać, wystarczy analiza specyfikacji, idiomów, itd.
Takie porównania były robione i regularnie są robione chociażby przez branżę
safety-critical. Hint: Java jest na rynku od +15 lat. Żaden system sterowania
czymkolwiek istotnym (samoloty? pociągi?) nie został napisany w Javie, natomiast w
C++ owszem. Jest to oczywiście wbrew wszelkim rynkowym tendencjom, ale skoro jest
wbrew, to tym bardziej istotne są powody, żeby tak było.

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

do góry

W dniu wtorek, 29 stycznia 2013 09:44:11 UTC+1 użytkownik Maciej Sobczak napisał:
> W dniu poniedziałek, 28 stycznia 2013 11:28:57 UTC+1 użytkownik M.M. napisał:
>
> > W dniu poniedziałek, 28 stycznia 2013 10:14:05 UTC+1 użytkownik Andrzej Jarzabek
napisał:
> > Trudno opracować jakiś miarodajny sposób w ocenie zagadnienia.
> Ale można to zagadnienie łatwo przetransformować: zdefiniujmy zbiór
> cech, jakich oczekujemy od języka pod kątem wsparcia dla pisania
> poprawnych programów i kolejno odkreślając checkboksy porównajmy
> parę języków.
Intuicyjnie zgadzam się z Tobą, jednak sama intuicja jakoś mnie nie
zadowala. Dla większości cech można podać argumenty za i przeciw. Obawiam
się, że jeśli nie wskażemy sposobów pomiarów, to będziemy mogli dyskutować
bez końca.

Weźmy np. takie wielodziedziczenie. Ktoś powie że niebezpieczna konstrukcja.
Drugi ktoś się rąbnie gdy będzie musiał wklepać kod, jakiego by nie
musiał wklepywać, gdyby miał wielodziedziczenie.


> Nie trzeba pisać żadnego programu, żeby to wykonać, wystarczy
> analiza specyfikacji, idiomów, itd.
Do pewnego stopnia masz rację, to wystarczy. W przypadku czy kod
maszynowy, czy asembler, czy język wysokopoziomowy każdy się zgodzi.
Natomiast w przypadku bardziej szczegółowych cech chyba panuje
zgoda wśród programistów?


> Takie porównania były robione i regularnie są robione chociażby przez
> branżę safety-critical.
Nie wiem jak oni to robią. Biorą zestaw cech i głosuje kilka osób w jakim
stopniu dana cecha wpływa na poprawę bezpieczeństwa języka? Ja bym
się bał że tacy ludzie ulegają wpływom, może ma to jakiś charakter
marketingowy?


> Hint: Java jest na rynku od +15 lat. Żaden system sterowania czymkolwiek
> istotnym (samoloty? pociągi?) nie został napisany w Javie,
Po pierwsze nie jestem tego pewny, a po drugie dla mnie nic z tego
nie wynika. Może javy nie wybiera się do tego typu zadań z zupełnie
innych powodów? Brak narzędzi na daną platformę, programiści z branży
lepiej znają C++, ADĘ, czy co tam jeszcze, albo GC w javie może się
uruchomić gdy urządzenie nie może czekać bo system jest RT?

> natomiast w C++ owszem. Jest to oczywiście wbrew wszelkim rynkowym
> tendencjom, ale skoro jest wbrew, to tym bardziej istotne są powody,
> żeby tak było.
Jeden z moich systemów co prawda nie może zabić ani urwać ręki, ale
zęby może wybić, może nieźle nastraszyć, albo zdemolować trochę
drogiego sprzętu. Napisany jest w C++. Gdyby był napisany w Javie,
myślę, żeby działał tak samo. Wybór podał na C++ i asmebler (a
przed chwilą pisałem że asembler jest niebezpieczny!) , bo mieliśmy
większe doświadczenie w tych językach.

Tak czy inaczej, muszą być sposoby pomiaru, bo inaczej ciężko się
przekonywać.


Pozdrawiam

do góry

On 29/01/2013 08:44, Maciej Sobczak wrote:
> W dniu poniedziałek, 28 stycznia 2013 11:28:57 UTC+1 użytkownik M.M. napisał:
>> W dniu poniedziałek, 28 stycznia 2013 10:14:05 UTC+1 użytkownik Andrzej Jarzabek
napisał:
>
>> Trudno opracować jakiś miarodajny sposób w ocenie zagadnienia.
>
> Ale można to zagadnienie łatwo przetransformować: zdefiniujmy zbiór cech, jakich
oczekujemy
> od języka pod kątem wsparcia dla pisania poprawnych programów i kolejno odkreślając
checkboksy
> porównajmy parę języków.

I co potem, policzysz checkboksy? Poza tym kto ma decydować, które cechy
dokładnie się znajdą na tej liście, a które nie?

> Takie porównania były robione i regularnie są robione chociażby przez branżę
safety-critical.

Masz gdzieś przykład?

> Hint: Java jest na rynku od +15 lat. Żaden system sterowania czymkolwiek istotnym
(samoloty?
> pociągi?) nie został napisany w Javie, natomiast w C++ owszem.

Java się nie nadaje do systemów czasu rzeczywistego, natomiast C++
owszem. W żaden sposób nie rzutuje to na łatwość popełniania błędów czy
ich ewentualne konsekwencje w jedym i drugim.

do góry

On 29/01/2013 01:59, Roman W wrote:
> On Mon, 28 Jan 2013 18:45:53 +0100, darekm <d...@e...com> wrote:
>> Można odwrócić pytanie. Co by było gdyby te duże programy pisano w
>> języku z dynamicznym typowaniem
>
> Przecież wiadomo: syf, kila i mogila.

Podobno ktoś w latach 80-tych napisał w Smalltalku jakiś większy system,
który nie był do dupy.

do góry

W dniu wtorek, 29 stycznia 2013 19:41:34 UTC+1 użytkownik Andrzej Jarzabek napisał:

> I co potem, policzysz checkboksy?

Niezależnie od wybranej metody, coś będzie trzeba policzyć. :-)

> Poza tym kto ma decydować, które cechy
> dokładnie się znajdą na tej liście, a które nie?

Może ci sami goście, którzy potem będą tego języka używać? Coś jak z wyborem
samochodu na flotę firmową - siadamy, piszemy wymagania, rozglądamy się po rynku,
liczymy checkboksy. To chyba jedyna w miarę obiektywna metoda, inne (np. osobiste
sympatie prezesa) oczywiście też się stosuje w praktyce, ale o nich nie ma po co
dyskutować.

> > Takie porównania były robione i regularnie są robione chociażby przez branżę
safety-critical.
>
> Masz gdzieś przykład?

Hasła do gugla: language assessment for safety critical

Całkiem ciekawe rzeczy wyskakują już na pierwszej stronie.

> > Hint: Java jest na rynku od +15 lat. Żaden system sterowania czymkolwiek istotnym
(samoloty?
> > pociągi?) nie został napisany w Javie, natomiast w C++ owszem.
>
> Java się nie nadaje do systemów czasu rzeczywistego, natomiast C++
> owszem.

Dlaczego i dlaczego? I to są właśnie te checkboksy. Określamy wymagania i wybieramy z
dostępnych możliwości.

> W żaden sposób nie rzutuje to na łatwość popełniania błędów

Ale rzutuje na możliwość efektywnego zrealizowania projektu. Marna pociecha, że w
jakimś języku można (a można?) zrobić system, który jest poprawny, ale się nie
nadaje. Pozostaje podjąć wysiłek w obrębie tych języków, które się nadają.

Poza tym, w takich dyskusjach zwykle pada argument (aż dziw, że nie padł) o RT Java.
Podobno problem nienadawania się tam znika, ale o faktycznie zrealizowanych systemach
nie słyszałem.

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

do góry

On 30/01/2013 09:12, Maciej Sobczak wrote:
> W dniu wtorek, 29 stycznia 2013 19:41:34 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
>> I co potem, policzysz checkboksy?
>
> Niezależnie od wybranej metody, coś będzie trzeba policzyć. :-)

No chyba że metoda jest "po uważaniu".

>> Poza tym kto ma decydować, które cechy
>> dokładnie się znajdą na tej liście, a które nie?
>
> Może ci sami goście, którzy potem będą tego języka używać?

Są dwa problemy. Pierwszy teoretyczny: skoro nie wiadomo jaki język
zostanie wybrany, to nie wiadomo, kto będzie go używać. Bo np. w
zależności od wybranego języka będzie go używać ten, co go zna.

W praktyce oczywiście często jest tak, że najpierw są ludzie, a potem
jest projekt - np. dany program zaczyna tworzyć firma, która wcześniej
istniała i kogoś tam zatrudnia. Ale w związku z tym pojawia się
praktyczny problem taki, że ci ludzie i tak wybiorą to, co znają i czego
używa się w firmie, i cała zabawa z chekboxami nie ma zabawy, bo zawsze
da się wybrać takie, żeby wygrało to, co ma wygrać.

> Coś jak z wyborem samochodu na flotę firmową - siadamy, piszemy wymagania,
> rozglądamy się po rynku, liczymy checkboksy.

Nieco chybiona analogia, bo jak ktoś potrafi prowadzić jeden samochód,
to potrafi prowadzić każdy samochód.

>>> Takie porównania były robione i regularnie są robione chociażby przez branżę
safety-critical.
>> Masz gdzieś przykład?
>
> Hasła do gugla: language assessment for safety critical
>
> Całkiem ciekawe rzeczy wyskakują już na pierwszej stronie.

Ostrożnie z takimi radami, bo każdy żyje w swojej guglowej bańce i każdy
widzi co innego jak wpisze.

Mnie na przykład na to hasło nie dało na pierwszej stronie żadnych
linków o porównywaniu języków, czy to checkboxamiczy inaczej (z
wyjątkiem jakiegoś jednego artykułu za paywallem), natomiast grzebiąc
znalazłem coś takiego:

http://grouper.ieee.org/groups/plv/HISTORICAL-LINKS/
Derek%20Reinhardt%20MSc%20SCSE%20Thesis%20%28Release
%20Version%29.pdf

Ten schemat GSN jest od biedy jakimś odpowiednikiem checkboxów, ale jak
się popatrzy na opis GSN pod
http://www.goalstructuringnotation.info/documents/GS
N_Standard.pdf, to
można znaleźć takie zdanie:

"0.4.12 It is important to recognise that GSN simply provides a means of
documenting an asserted argument. The use of GSN itself does not
establish the truth of that argument."

I tyle na ten temat.

>>> Hint: Java jest na rynku od +15 lat. Żaden system sterowania czymkolwiek istotnym
(samoloty?
>>> pociągi?) nie został napisany w Javie, natomiast w C++ owszem.
>>
>> Java się nie nadaje do systemów czasu rzeczywistego, natomiast C++
>> owszem.
>
> Dlaczego i dlaczego? I to są właśnie te checkboksy. Określamy wymagania i wybieramy
z dostępnych możliwości.

Real time i safety critical to nie to samo. Kodeki video i gry FPS też
się pisze w C++, chociaż nie są safety critical. Nie wiem czy istnieją
systemy safety critical, które nie są systemami czasu rzeczywistego,
teoretycznie jestem sobie w stanie to wyobrazić (jakieś obliczenia
inżynieryjne?), ale w praktyce nie wiem jak jest.

>> W żaden sposób nie rzutuje to na łatwość popełniania błędów
>
> Ale rzutuje na możliwość efektywnego zrealizowania projektu.

Wiele rzeczy może na to wpływać (np. to, czy się akurat zatrudnia ludzi
znających dany język), ale nijak ma się to do tematu "czy w jednych
językach popełnia się więcej błędów niż w innych".

> Poza tym, w takich dyskusjach zwykle pada argument (aż dziw, że nie padł)
> o RT Java. Podobno problem nienadawania się tam znika, ale o faktycznie
> zrealizowanych systemach nie słyszałem.

Nie znam, to się nie wypowiadam.

do góry

W dniu środa, 30 stycznia 2013 10:12:15 UTC+1 użytkownik Maciej Sobczak napisał:
> > I co potem, policzysz checkboksy?
> Niezależnie od wybranej metody, coś będzie trzeba policzyć. :-)
> > Poza tym kto ma decydować, które cechy
> > dokładnie się znajdą na tej liście, a które nie?
> Może ci sami goście, którzy potem będą tego języka używać?
Raczej minie się to z celem. W praktyce wybór języka to
optymalizacja wielokryterialna. Ochrona przed błędami jest
tylko jednym z wielu aspektów. Nie sądzę aby przeciętna
osoba która używa języka była w stanie coś sensownego
powiedzieć.

Pomysł z checkboxami byłby dobry, ale checkboxy by musiał mieć
chociaż liniowe wagi. Ustalenie wag wydaje się równie trudne
jak problem w oryginalnej postaci i pętla się zamyka.

Pozdrawiam

do góry

W dniu środa, 30 stycznia 2013 19:58:00 UTC+1 użytkownik Andrzej Jarzabek napisał:

> >> Poza tym kto ma decydować, które cechy
> >> dokładnie się znajdą na tej liście, a które nie?
>
> > Może ci sami goście, którzy potem będą tego języka używać?
>
> Są dwa problemy. Pierwszy teoretyczny: skoro nie wiadomo jaki język
> zostanie wybrany, to nie wiadomo, kto będzie go używać. Bo np. w
> zależności od wybranego języka będzie go używać ten, co go zna.

Bo *z założenia* wykluczamy podwyższanie kwalifikacji, szkolenia, itd.?
Ja bym nie wykluczał.

Zwłaszcza, że mówimy o branżach, gdzie decyzje mają dłogofalowe efekty. Taki samolot
albo satelita ma czas życia +15 lat (albo i 40), więc należy wziąć pod uwagę również
taki drobiazg, że ci goście co projekt zaczną, prawdopodobnie nie będą go kończyć
[*]. Wtedy fakt, że *ktoś* *dzisiaj* zna tylko JavaScripta ma mniejszą wagę, niż się
zwykle sądzi.

[*] Co ciekawe, tak może być w każdym projekcie oprócz zaliczeniowych.

> Ale w związku z tym pojawia się
> praktyczny problem taki, że ci ludzie i tak wybiorą to, co znają i czego
> używa się w firmie, i cała zabawa z chekboxami nie ma zabawy, bo zawsze
> da się wybrać takie, żeby wygrało to, co ma wygrać.

Tak, jest to problem, który jest trudny do wyeliminowania. Ale tak będzie z każdą
inną metodą.

> > Coś jak z wyborem samochodu na flotę firmową - siadamy, piszemy wymagania,
> > rozglądamy się po rynku, liczymy checkboksy.
>
> Nieco chybiona analogia, bo jak ktoś potrafi prowadzić jeden samochód,
> to potrafi prowadzić każdy samochód.

Zawsze myślałem, że wykształcony programista też jest zdolny do jakiejś tam
intelektualnej mobilności.

> > Hasła do gugla: language assessment for safety critical
>
> Mnie na przykład na to hasło nie dało na pierwszej stronie żadnych
> linków o porównywaniu języków, czy to checkboxamiczy inaczej (z
> wyjątkiem jakiegoś jednego artykułu za paywallem), natomiast grzebiąc
> znalazłem coś takiego:
>
> http://grouper.ieee.org/groups/plv/HISTORICAL-LINKS/
Derek%20Reinhardt%20MSc%20SCSE%20Thesis%20%28Release
%20Version%29.pdf

Jest to jakiś input.

> "0.4.12 It is important to recognise that GSN simply provides a means of
> documenting an asserted argument. The use of GSN itself does not
> establish the truth of that argument."
>
> I tyle na ten temat.

Każda metoda ma swoje wady. Metoda z checkboksami przynajmniej próbuje być
obiektywna.

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

do góry

On 2013-01-31 10:14, Maciej Sobczak wrote:
> W dniu środa, 30 stycznia 2013 19:58:00 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
>>>> Poza tym kto ma decydować, które cechy
>>>> dokładnie się znajdą na tej liście, a które nie?
>>
>>> Może ci sami goście, którzy potem będą tego języka używać?
>>
>> Są dwa problemy. Pierwszy teoretyczny: skoro nie wiadomo jaki język
>> zostanie wybrany, to nie wiadomo, kto będzie go używać. Bo np. w
>> zależności od wybranego języka będzie go używać ten, co go zna.
>
> Bo *z założenia* wykluczamy podwyższanie kwalifikacji, szkolenia, itd.?
> Ja bym nie wykluczał.
>
Wydaje mi sie mylisz podwyzszanie kwalifikacji z przekwalifikowaniem
sie. Bo znajomosc jezyka a dobra znajomosc jezyka to dwie rozne sprawy.


Pozdrawiam

Marek

do góry

W dniu czwartek, 31 stycznia 2013 21:29:48 UTC+1 użytkownik Marek Borowski napisał:

> > Bo *z założenia* wykluczamy podwyższanie kwalifikacji, szkolenia, itd.?
> > Ja bym nie wykluczał.
>
> Wydaje mi sie mylisz podwyzszanie kwalifikacji z przekwalifikowaniem
> sie.

W takim razie wystąpiło nieporozumienie. Dla mnie programista to zawód. Język
programowania to narzędzie. Nauka nowego języka to poszerzenie/podwyższenie
kwalifikacji w tym samym zawodzie. Coś jak nauka obsługi nowego rodzaju młotka.

Przekwalifikowaniem się byłaby nauka umiejętności typowych dla innego zawodu z myślą
o wykonywaniu tego innego zawodu (np. nauka prowadzenia tramwaju).

Inaczej: "programista" to zawód; "programista Javy" to ograniczenie.

(Tak, oprócz ideałów znam też realia.)

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

do góry