On Tue, 14 Jan 2014 12:48:03 -0800 (PST), g...@g...com
wrote:

>W dniu wtorek, 14 stycznia 2014 21:15:27 UTC+1 użytkownik Wojciech Muła napisał:
>> On Monday, January 13, 2014 4:19:37 PM UTC+1, g...@g...com wrote:
>>
>> > Mysle, ze gdyby w projektach tego rodzaju system typow
>> > naprawde dawal tak wielkie korzysci, to by go tak latwo
>> > nie zmarginalizowano.
>>
>> On nie jest marginalizowany.
>
>Gdybym mial zgadywac, zgadywalbym, ze coraz
>wiecej nowo powstajacych systemow informatycznych
>nie korzysta ze statycznych systemow typow.
>Gdybym mial zgadywac, zgadywalbym rowniez,
>ze w coraz wiekszej ilosci systemow zdarzaja
>sie bledy niedopasowania typu w czasie
>uruchomienia, ktorych mozna by bylo uniknac,
>stosujac metody sprzed 40 lat :)
>

Ze niby jakie?...

>> Do rzeczy typu tysiąc pięćsetny unikalny
>> system blogowy PHP, czy Ruby wystarczy.
>> Gdy gra zaczyna się o wydajność,
>> zajętość pamięci, to języki kompilowane
>> wygrywają z definicji.
>
>Z tym tez bywa roznie. Po pierwsze, nic nie
>stoi na przeszkodzie, zeby kompilowac PHP
>albo interpretowac C.
>Po drugie niekiedy tanszym rozwiazaniem
>jest kupno szybszego sprzetu albo wiekszej
>ilosci pamieci. Po trzecie statyczny system
>typow na pewno nie jest sposobem na
>zwiekszenie wydajnosci czy zmniejszenie
>zajetosci pamieci, tylko na zwiekszenie
>niezawodnosci oprogramowania przez unikniecie
>pewnej klasy bledow.
>
>> BTW PHP5[1] umożliwiaja od jakiegoś czasu stosowanie type hintingu
>> w parametrach funkcji/metod. Co prawda to się dzieje w runtime, ale
>> to jakaś forma kontroli typów. W Pythonie też zdaje się coś takiego chcą.
>
>Ja im sie wcale nie dziwie. Bo statyczna kontrola
>typow jest miodzio (a PHP, jako ze ukradl skladnie
>z C, ma naturalne predyspozycje syntaktyczne
>do anotacji).

Gosciu, czy ty kiedys programwoales profesjonalnie, czy tylk oze
sluchu?


ja nmam za soba milion z hakiem linii Smalltalka i cwierc miliona
Prologu. Oczywiscie, nei sam, w zespole. W Smalltalku, po oddaniu
stsremu do uzytku, tzrech programistow bylo przydzielonych non stop do
wylapywania bledow, srednio 25 miesiecznie, TYLKO I WYLACZNEI
spowodowanych dynamicznym typowaniem. Zreszta, jeden z tworcow
Smalltalka dam powiedzial ze neichcialby laciec samolotem ktorego
software bylby napsiany w Smalltalku - bo w tarkcie ladowania nagle
mogloby sie pojawic "doesNotUndrestand"

Jezyki nei typowane dobre sa dla hobbystow. Neistetty,l w pzremysle
sie nei nadaja. To ze kts je stosuje, to nei moja wina.

Typowany C kest leoszy niz bylby nietypowany, tylk oszkoda ze ten
system typow jest do niczego

A.L.

do góry

>
> Zgodze sie, ze na tle innych powszechnie uzywanych jezykow
>
> C jest wyjatkowo wymagajacy pod wzgledem wiedzy, jaka musi
>
> posiasc programista, zeby moc w nim bezpiecznie programowac,
>
> i ma to do siebie, ze potrafi zaskakiwac (z powodu takich
>
> cech, jak np. koniecznosc recznej alokacji pamieci czy
>
> sprawdzania zakresow, czy obecnosc funkcji bibliotecznych,
>
> ktore same moga przepelniac bufory).
>
>
casty, pointery, niesprawdzanie zakresów, czy
moze nawet malloc/free jako zrodło błedów są
chyba jednynie popularna blablaniną (nie jestem
moze zupelnie pewien ale ja pisze w c i nie mialem chyba NIGDY błedu zwiazanego z
castem i mw tyle
samo w zwiazku z pozostalymi kwestiami tj problem wogole nie istnieje, czy tez nie
istnial,
dokladniej to jak sie uruchamia kod na wskaznikah
to w etapie rozruchowym mozna miec pare bledów runtime (co mi sie akurat zdarzylo ale
po etepie
rozruchowym juz raczej nie - dokladnie nawet nie wiem bo niezwykle jednak rzdko pisze
kody na wskaznikach) generalne ijednak z mojego osobistego
doswiadczenia wynika ze to cale blablanie o niebezpieczeństwach c jest nie warte
czasu
na jego czytanie

malloc i free tez nie uzywam tak ze nie wiem,
gdybym uzywal to pewnie bym sobue napisał wrapper
ktory by mi sprawdzał czy tylezaalokowano co zdealokowano

natomiast bledy w bibliotekach to owszem sa
to pewnie powazne błedy (na przykład to jesli biblioteka jak ktos na pl.c.l.c
okreslil produkuje pamiec itp, albo scanf które mozna wywalic inputem itp

sczerze mowiac dla mnie przy pisaniu bledy wogole nie sa problemem nie na tyle by
warto bylo o nich
wspominac (czasem sie trafi cos na czym zmarnuje ze
dwie godziny ale w sumie rzadko)

gorsza kategoria jest np taki przypadek ze cos nie chce działać (na przyklad ostatnio
opencl - ale to
scisle nie jest kategoria błedów tylko problem przebijania sie przez dokumentacje i
konfiguracje czy cos takiego ;\ :C

do góry

>
>
>
> Typowany C kest leoszy niz bylby nietypowany, tylk oszkoda ze ten
>
> system typow jest do niczego
>

jaki blad moze wywolac w programie 'słaby' system typow w c, po etapie rozruchowym?

do góry

W dniu środa, 15 stycznia 2014 00:37:19 UTC+1 użytkownik A. L. napisał:
> On Tue, 14 Jan 2014 02:22:11 -0800 (PST), g...@g...com
>
> wrote:
>
>
> >Jednak w moim odczuciu przyklady, ktore byly podane pod
> >linkiem, ktory wkleil A.L., majace dowodzic, ze system
> >typow jezyka C nie jest bezpieczny, byly raczej sztuczne
> >i moglyby byc problemem tylko dla osob, ktore maja uzywac
> >systemu typow, nie wiedzac w ogole, czym on jest.
>
> jakei sztuczne? Ze wszystko mzoe byc 'pointer to void"?...

nikt nikomu nie kaze uzywac 'pointer to void'

do góry

W dniu środa, 15 stycznia 2014 00:43:20 UTC+1 użytkownik A. L. napisał:
> On Tue, 14 Jan 2014 12:48:03 -0800 (PST), g...@g...com
> wrote:
>
> >Gdybym mial zgadywac, zgadywalbym, ze coraz
> >wiecej nowo powstajacych systemow informatycznych
> >nie korzysta ze statycznych systemow typow.
> >Gdybym mial zgadywac, zgadywalbym rowniez,
> >ze w coraz wiekszej ilosci systemow zdarzaja
> >sie bledy niedopasowania typu w czasie
> >uruchomienia, ktorych mozna by bylo uniknac,
> >stosujac metody sprzed 40 lat :)
> >
>
> Ze niby jakie?...

Statyczna kontrole typow.

> >> Do rzeczy typu tysi�c pi��setny unikalny
> >> system blogowy PHP, czy Ruby wystarczy.
> >> Gdy gra zaczyna si� o wydajno��,
> >> zaj�to�� pami�ci, to j�zyki kompilowane
> >> wygrywajďż˝ z definicji.
> >
> >Z tym tez bywa roznie. Po pierwsze, nic nie
> >stoi na przeszkodzie, zeby kompilowac PHP
> >albo interpretowac C.
>
> >Po drugie niekiedy tanszym rozwiazaniem
> >jest kupno szybszego sprzetu albo wiekszej
> >ilosci pamieci. Po trzecie statyczny system
> >typow na pewno nie jest sposobem na
> >zwiekszenie wydajnosci czy zmniejszenie
> >zajetosci pamieci, tylko na zwiekszenie
> >niezawodnosci oprogramowania przez unikniecie
> >pewnej klasy bledow.
> >
> >> BTW PHP5[1] umo�liwiaja od jakiego� czasu stosowanie type hintingu
> >> w parametrach funkcji/metod. Co prawda to siďż˝ dzieje w runtime, ale
> >> to jaka� forma kontroli typ�w. W Pythonie te� zdaje si� co� takiego
chcďż˝.
>
> >
>
> >Ja im sie wcale nie dziwie. Bo statyczna kontrola
> >typow jest miodzio (a PHP, jako ze ukradl skladnie
> >z C, ma naturalne predyspozycje syntaktyczne
> >do anotacji).
>
> Gosciu, czy ty kiedys programwoales profesjonalnie, czy tylk oze
> sluchu?

???
Nie wiem, jak mam traktowac to pytanie. Odbic pileczke?
Zapytac, czy przypadkiem nie przegapiles w szkole zajec
z czytania?

> ja nmam za soba milion z hakiem linii Smalltalka i cwierc milion
> Prologu. Oczywiscie, nei sam, w zespole. W Smalltalku, po oddaniu
> stsremu do uzytku, tzrech programistow bylo przydzielonych non stop do
> wylapywania bledow, srednio 25 miesiecznie, TYLKO I WYLACZNEI
> spowodowanych dynamicznym typowaniem. Zreszta, jeden z tworcow
> Smalltalka dam powiedzial ze neichcialby laciec samolotem ktorego
> software bylby napsiany w Smalltalku - bo w tarkcie ladowania nagle
> mogloby sie pojawic "doesNotUndrestand"
>
> Jezyki nei typowane dobre sa dla hobbystow. Neistetty,l w pzremysle
> sie nei nadaja. To ze kts je stosuje, to nei moja wina.

Calkowicie sie zgadzam.

do góry

W dniu wtorek, 14 stycznia 2014 22:27:08 UTC+1 użytkownik R.e.m.e.K napisał:
> Dnia Tue, 14 Jan 2014 12:19:13 -0800 (PST), g...@g...com
> napisał(a):
> >> ps. Macieju, czy zdajesz sobie sprawe z kim piszesz?
> >
> > Chyba nie zdaje. Jakze bym mial?
>
> To najwiekszy troll ostatnich lat, wystepujacy po kilkoma ksywami, srajacy
> bzdetami na wielu grupach i obrzucajacy wszystkich obelgami o podlozu
> politycznym.
> Zasada jest taka, ze zadaje pytanie i nie czyta odpowiedzi lub ich nie
> rozumie i bulgocze do znudzenia. Szkoda czasu.

Bardzo dziekuje za ostrzezenie, ale:

* jezeli ktos chce mnie obrzucac obelgami o podlozu politycznym
i mogloby mu to dac ukojenie, to niech sobie pouzywa, bo mi to
naprawde ani troche nie przeszkadza (a czasem nawet moze dawac mi
bodziec do zastanowienia sie nad soba samym)

* uwazam, ze to mnie samemu powinno zalezec na tym, zeby moje
wyjasnienia byly jak najbardziej zrozumiale, bo wyjasnianie
jest umiejetnoscia, ktora uwazam za cenna. jezeli ktos nie
rozumie tego, co do niego mowie, to uwazam, ze powinienem
nad soba bardziej popracowac, choc oczywiscie jezeli ktos
nie chce z mojego wyjasnienia skorzystac, to to juz nie jest
moj problem

* do tej pory rozmowca sprawial wrazenie, jakby czytal i
rozumial (a przynajmniej probowal rozumiec) odpowiedzi,
wiec pod tym wzgledem ma u mnie kredyt zaufania

Dlatego nie martwilbym sie zbytnio na zapas :)

do góry

On Tue, 14 Jan 2014 15:53:16 -0800 (PST), g...@g...com
wrote:

>W dniu środa, 15 stycznia 2014 00:37:19 UTC+1 użytkownik A. L. napisał:
>> On Tue, 14 Jan 2014 02:22:11 -0800 (PST), g...@g...com
>>
>> wrote:
>>
>>
>> >Jednak w moim odczuciu przyklady, ktore byly podane pod
>> >linkiem, ktory wkleil A.L., majace dowodzic, ze system
>> >typow jezyka C nie jest bezpieczny, byly raczej sztuczne
>> >i moglyby byc problemem tylko dla osob, ktore maja uzywac
>> >systemu typow, nie wiedzac w ogole, czym on jest.
>>
>> jakei sztuczne? Ze wszystko mzoe byc 'pointer to void"?...
>
>nikt nikomu nie kaze uzywac 'pointer to void'

No pewnie.Tylk oze uzywaja

A.L.

do góry

W dniu 2014-01-14 21:48, g...@g...com pisze:
[...]
> Po trzecie statyczny system
> typow na pewno nie jest sposobem na
> zwiekszenie wydajnosci czy zmniejszenie
> zajetosci pamieci, tylko na zwiekszenie
> niezawodnosci oprogramowania przez unikniecie
> pewnej klasy bledow.

Statyczna kontrola typów daje duże pole do popisu dla optymalizacji
przez kompilator. Vide - rozwijanie szablonów w C++. Czyli jest jednym
ze sposobów na zwiększenie wydajności. Choć pewnie częściej jest
stosowany w celu poprawy niezawodności.

Tak na marginesie - nie spodziewałem się n-tej dyskusji o wyższości
Świąt Bożego Narodzenia nad Świętami Wielkiej Nocy.

Jak piszę skrypt w Pythonie, w którym obrabiam JSONa, to wielce sobie
chwalę dynamiczne typowanie i wkładanie czegokolwiek do słowników, list
itp. Ale jak piszę większy program, to chciałbym wyrzucić z głowy to, co
w małym skrypcie jestem w stanie zapamiętać ("Czy tu była liczba, czy
napis...?"). Czyli skorzystać z silnego typowania, żeby to kompilator
(albo interpreter - bez różnicy) za mnie pamiętała i przypominała, gdy
się pomylę.

--
Paweł Kierski
n...@p...net

do góry

z kolei ten głupek uwział się razem z Kviatem na mine i ciągle syfią w moich
wątkach - olać...

do góry

W dniu środa, 15 stycznia 2014 08:03:30 UTC+1 użytkownik Paweł Kierski napisał:

> Statyczna kontrola typ�w daje du�e pole do popisu dla optymalizacji
> przez kompilator. Vide - rozwijanie szablon�w w C++.

Rozwijanie szablonów nie za bardzo ma związek z systemem typów. Raczej z brutalnym
inline'owaniem a to można robić również z typami dynamicznymi.

Natomiast statyczny system typów jest użyteczny chociażby przez sam fakt, że można z
góry wygenerować odpowiednie instrukcje asemblera, które będą na pewno dobre do
wykonania jakiejść operacji. Np. dodawanie zmiennych, o których z góry wiadomo, że są
32-bitowymi liczbami całkowitymi, można zwykle zrobić jedną instrukcją zamiast
tysiącem instrukcji, które najpierw pracowicie sprawdzają, jakie typy mają te zmienne
i czy przypadkiem nie chodzi o sklejanie napisów.

Na dalszym poziomie statyczny system typów można wykorzystać do *eliminacji*
operacji, nawet takich, które są wymagane przez język. Np. jeśli w danym języku jest
sprawdzanie zakresów przy indeksowaniu tablic, to statyczny system typów cząsem
pozwala kompilatorowi tego sprawdzenia nie robić. Podobnie z innymi sytuacjami
brzegowymi, jak dzielenie przez 0, itp.
Problem z językiem C polega na tym, że no niby ma statyczny system typów, ale tak
kiepski, że nie da się go na tym "dalszym poziomie" wykorzystać ani do optymalizacji
ani do wykrywania potencjalnych błędów.

> Tak na marginesie - nie spodziewa�em si� n-tej dyskusji o wy�szo�ci
> �wi�t Bo�ego Narodzenia nad �wi�tami Wielkiej Nocy.

Dlaczego? Podobnie jak te swięta, tego typu dyskusje są zjawiskiem okresowym. :-D

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

do góry