W dniu 2011-02-01 15:34, A.L. pisze:
> On Tue, 01 Feb 2011 14:09:45 +0100, "R. P."<r...@w...pl>
> wrote:
>
>> W dniu 2011-02-01 14:03, Krzysiek Kowaliczek pisze:
>>> Użytkownik R. P. napisał:
>>>>> #define programowanie systemowe
>>>>
>>>> kernel + programowanie około-kernelowe - ogólnie programowanie w trybie
>>>> jądra, a więc i też sterowniki urządzeń, etc.
>>>
>>> Czego niby brakuje w C++, Pascalu czy Adzie?
>>
>> Prostoty. C++ ze swoimi szablonami itp. narzędziami jest zbyt
>> skomplikowany do pisania oprogramowania systemowego w nim.
>>
>>>>> #define sprytne rzuty
>>>>
>>>> Magia typu void*. Nie ma co się rozpisywać. Jako programista
>>>> unixowy/linuxowy doskonale wiesz co mam na myśli.
>>>>
>>>
>>> Rozumiem że w programie dostajesz magiczne dane, ponieważ słaby
>>> system typów nie uratował Cię od pomyłki?
>>
>> Halo, przecież ja mówię cały czas o programowaniu systemowym, nie
>> aplikacyjnym!
>
> O programowaniu systemowym w Pacalu (a konkretnie w Concurrent
> Pascalu) pisal Per Brinch Hansen w ruku 1977 (Ksaiazka "Architecture
> of Concurrent Programs") i zrobil system operacyjnu SOLO napisany
> calkowice w Concurrent Pascalu. Wirth napisal system operacyjny w
> Moduli do computera Lilith, i system operacyjny Oberon w jezyku
> Oberon.
>
> Mit ze "systemy operacyjne tzreba pisac w C bo nei ma typowania i jest
> bliskiasemblerowi" jest jednym z najbardziej idiotycznych mitow jakie
> sie rozpowszechniaja, a jak juz pisalem, fakt ze wiele programow
> "systemowych" jest napisanych w nietypowanym i niepewnym (non safe) C
> jest sprawca wielu problemow.

Ja nie mówię, że C nie ma wad. Nie twierdzę, że jest najwspanialszy.
Tyle że stopień skomplikowania obecnych systemów operacyjnych
(najpopularniejszych: Unix, Linux i Windows) jest tak duży, że wywalenie
całego kernela który dotychczas był pisany w C i napisanie czegoś od
nowa w czymś innym jest praktycznie niewykonalne. Ile osobomiesięcy
byłoby potrzeba żeby tego dokonać? Sam sobie odpowiedz...

do góry

W dniu 2011-02-01 15:28, A.L. pisze:
> On Tue, 01 Feb 2011 10:46:17 +0100, "R. P."<r...@w...pl>
> wrote:
>
>> W dniu 2011-02-01 09:25, Krzysiek Kowaliczek pisze:
>>> Użytkownik R. P. napisał:
>>>> W Pascalu wskaźniki są bardziej "popsute" niż w C. Dają mniejszą
>>>> elastyczność. Siła C tkwi we wskaźnikach, w słabej typizacji. To się
>>>> idealnie nadaje do programowania systemowego.
>>>
>>> Pierwszy raz słyszę, że słaby system typów jest zaletą.
>>
>> W programowaniu systemowym tak, bo pozwala robić różne sprytne rzuty na
>> wskaźnikach. W programowaniu wysokopoziomowym jest wadą.
>
> Za taka wypowiedz, gdyby wypowiedzial ja student, wyrzucilbym go za
> drzwi. Jezeli wypowiada to profesjonalista, wzruszam ramionami i
> odchodze.
>
> Albowiem "sprytne rzuty" sa pzrede wszystkim zrodlem bledow.
> Systemowych.
>
> Wieksosc neisczesc spowodowana jest tym ze "programy systemowe"
> napisane sa w C z "chytrymi rzutami"

Zgadza się. Są źródłem błędów. Ale dzięki nim pisane oprogramowanie może
też być bardzo wydajne... O tym nie wspominasz.

do góry

W dniu 2011-02-01 15:36, A.L. pisze:
> On Tue, 1 Feb 2011 03:41:43 -0800 (PST), Andrzej Jarzabek
> <a...@g...com> wrote:
>
>>>>> W twoim podziale wstawienie w rodek C nie jest niczym uzasadnione.
>>>
>>>> Jak najbardziej ma znaczenie. J zyk C przyni s rewolucj , razem z
>>>> UNIXem. To od niego zacz a si nowa era programowania.
>>>
>>> Jaka "nowa era"?... C to popsuty Pascal.
>>
>> Nawet jeśli, to jakie ma to znaczenie?
>>
>
> Takei ma znaczenie, ze popsucie bylo dosyc fundamentalne, a
> rozpowszechnienei sie jezyka C bylo jednym z najwiekszych nieszczesc
> jakie dotknelo informatyke.

Ale to już się stało i się nie odstanie. Stworzysz teraz system
operacyjny od nowa, w czymś innym niż w C, który będzie mógł być
konkurencyjny z Unixem, Linuxem czy Windowsem?

do góry

On Tue, 01 Feb 2011 15:42:41 +0100, "R. P." <r...@w...pl>
wrote:

>Ale to już się stało i się nie odstanie. Stworzysz teraz system
>operacyjny od nowa, w czymś innym niż w C, który będzie mógł być
>konkurencyjny z Unixem, Linuxem czy Windowsem?

A cóżeś się tak przyczepił pisania od nowa. Czy ktoś każe tobie
przepisywać kernel od początku? Asemblerowatość C umożliwia
podlinkowanie gotowych elementów do prawie wszystkiego co się zwie
,,językiem programowania'' także nie ma żadnych niebezpieczeństw z tej
strony. Przeciw jest moda i, co za tym idzie, mała
popularność/znajomość innych języków.
--
Grzegorz Krukowski

do góry

W dniu 2011-02-01 16:08, Grzegorz Krukowski pisze:
> On Tue, 01 Feb 2011 15:42:41 +0100, "R. P."<r...@w...pl>
> wrote:
>
>> Ale to już się stało i się nie odstanie. Stworzysz teraz system
>> operacyjny od nowa, w czymś innym niż w C, który będzie mógł być
>> konkurencyjny z Unixem, Linuxem czy Windowsem?
>
> A cóżeś się tak przyczepił pisania od nowa. Czy ktoś każe tobie
> przepisywać kernel od początku? Asemblerowatość C umożliwia
> podlinkowanie gotowych elementów do prawie wszystkiego co się zwie
> ,,językiem programowania'' także nie ma żadnych niebezpieczeństw z tej
> strony. Przeciw jest moda i, co za tym idzie, mała
> popularność/znajomość innych języków.

Niebezpieczeństw nie ma, ale czy to ma sens, jak cały dotychczasowy
kernel powstał w C? Nie posypie się w nowym kawałku napisanym w języku
super-wysokiego poziomu, ale posypie się przy wywołaniu starych funkcji ;)

W kernelu ciągle znajodwane są jakieś dziury. We wszystkich popularnych
systemach. To jest niezaprzeczalny fakt. Nie bronię C. Pisałem tylko, ze
jest ważnym punktem w historii, bo stał się jezykiem niesamowicie
popularnym i napisano w nim zdecydowanie najwięcej linii kodu...

do góry

On 2011-02-01, R. P. <r...@w...pl> wrote:
>>> Wciąż
>>> triumfy święci C/C++ i Java.
>>
>> A co to ma wspólnego z "wysokopoziomowością" języka, jakkolwiek
>> definiowaną?
>
> Czy ja napisałem, że ma coś wspólnego z wysokopoziomowością? Raczej z
> popularności wynika to, że dużo bibliotek jest napisanych w C.

To po co wprowadzasz szum do dyskusji?

>>>> A assembler to daje ci co najwyżej dostęp do urządzeń I/O i trybów
>>>> procesora. Żadna to moc, tylko ordynarna praca z hardwarem.
>>>
>>> Ale cały base jest też napisany w C. Wszystkie podstawowe narzędzia
>>> unixowe, takie jak sort np. są w C.
>>
>> No i? Równie dobrze mogłyby być w Adzie. Gdzie jest ta moc assemblera,
>> którą dostajesz w C?
>
> To usiądź i napisz kernel w Adzie.

Widzisz jakiś problem techniczny w takim pomyśle?

> Przecież oprogramowanie systemowe się
> rozszerza, nie pisze się go od nowa. To co, połowa będzie w C a połowa w
> Adzie? W latach 80 zaczęto pisać kernele w C i tak już zostało. Nic nie
> wskazuje na to ,żeby to się miało zmienić.

Miałeś pokazać dlaczego C jest taki potężny, bo blisko mu do assemblera.
Nie miałeś dywagować na temat mniej więcej losowego wyboru języka,
w którym się pisze kernele.

>>> Usiądziesz teraz i
>>> przepiszesz linuxowego sorta w haskellu? Będzie szybszy od tego z base
>>> napisanego w C? :)
>>
>> Może mi jeszcze wyjedziesz z porównaniem wydajności programu robiącego
>> "while (1) ;" napisanego w assemblerze, C i Haskellu? W jaki sposób to
>> ma świadczyć o potędze jakiegoś języka (jakkolwiek byś tej potęgi nie
>> zdefiniował)?
>
> Pytam - czy twój sort w Haskellu będzie szybszy od systemowego sorta w C?

Najpierw objaśnij co by to miało pokazać. Pamiętaj że miałeś wykazywać,
że C jest a) potężne i b) wysokopoziomowe. Pojęcia potężności jeszcze
nie zdefiniowałeś, podobnie jak wysokopoziomowości.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2011-02-01, R. P. <r...@w...pl> wrote:
> W dniu 2011-02-01 15:28, A.L. pisze:
>> On Tue, 01 Feb 2011 10:46:17 +0100, "R. P."<r...@w...pl>
>> wrote:
>>
>>> W dniu 2011-02-01 09:25, Krzysiek Kowaliczek pisze:
>>>> Użytkownik R. P. napisał:
>>>>> W Pascalu wskaźniki są bardziej "popsute" niż w C. Dają mniejszą
>>>>> elastyczność. Siła C tkwi we wskaźnikach, w słabej typizacji. To się
>>>>> idealnie nadaje do programowania systemowego.
>>>>
>>>> Pierwszy raz słyszę, że słaby system typów jest zaletą.
>>>
>>> W programowaniu systemowym tak, bo pozwala robić różne sprytne rzuty na
>>> wskaźnikach. W programowaniu wysokopoziomowym jest wadą.
>>
>> Za taka wypowiedz, gdyby wypowiedzial ja student, wyrzucilbym go za
>> drzwi. Jezeli wypowiada to profesjonalista, wzruszam ramionami i
>> odchodze.
>>
>> Albowiem "sprytne rzuty" sa pzrede wszystkim zrodlem bledow.
>> Systemowych.
>>
>> Wieksosc neisczesc spowodowana jest tym ze "programy systemowe"
>> napisane sa w C z "chytrymi rzutami"
>
> Zgadza się. Są źródłem błędów. Ale dzięki nim pisane oprogramowanie może
> też być bardzo wydajne... O tym nie wspominasz.

Wydajność się zyskuje nie na fistaszkach w rodzaju oszczędzenia jednego
bajtu czy czterech cykli procesora, tylko na złożoności obliczeniowej
(asymptotycznej).

Tak, w jądrze systemu operacyjnego też.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Feb 1, 2:36 pm, A.L. <l...@a...com> wrote:
> On Tue, 1 Feb 2011 03:41:43 -0800 (PST), Andrzej Jarzabek
>
> >> Jaka "nowa era"?... C to popsuty Pascal.
>
> >Nawet je li, to jakie ma to znaczenie?
>
> Takei ma znaczenie, ze popsucie bylo dosyc fundamentalne, a
> rozpowszechnienei sie jezyka C bylo jednym z najwiekszych nieszczesc
> jakie dotknelo informatyke.

Nawet jeśli tak jest, to tylko potwierdza tezę o jego historycznej
istotności. :)

> >Abstrahuj c od tego, czy to dobrze, czy niedobrze, fakt jest taki, e
> >j zyk C ukszta towa przyzwyczajenia estetyczne wsp czesnego
> >programisty.
>
> I to jest wlasnei neiszczescie

Może i nieszczęście, ale jednak fakt.

do góry

W dniu 2011-02-01 16:36, Stachu 'Dozzie' K. pisze:
> On 2011-02-01, R. P.<r...@w...pl> wrote:
>> W dniu 2011-02-01 15:28, A.L. pisze:
>>> On Tue, 01 Feb 2011 10:46:17 +0100, "R. P."<r...@w...pl>
>>> wrote:
>>>
>>>> W dniu 2011-02-01 09:25, Krzysiek Kowaliczek pisze:
>>>>> Użytkownik R. P. napisał:
>>>>>> W Pascalu wskaźniki są bardziej "popsute" niż w C. Dają mniejszą
>>>>>> elastyczność. Siła C tkwi we wskaźnikach, w słabej typizacji. To się
>>>>>> idealnie nadaje do programowania systemowego.
>>>>>
>>>>> Pierwszy raz słyszę, że słaby system typów jest zaletą.
>>>>
>>>> W programowaniu systemowym tak, bo pozwala robić różne sprytne rzuty na
>>>> wskaźnikach. W programowaniu wysokopoziomowym jest wadą.
>>>
>>> Za taka wypowiedz, gdyby wypowiedzial ja student, wyrzucilbym go za
>>> drzwi. Jezeli wypowiada to profesjonalista, wzruszam ramionami i
>>> odchodze.
>>>
>>> Albowiem "sprytne rzuty" sa pzrede wszystkim zrodlem bledow.
>>> Systemowych.
>>>
>>> Wieksosc neisczesc spowodowana jest tym ze "programy systemowe"
>>> napisane sa w C z "chytrymi rzutami"
>>
>> Zgadza się. Są źródłem błędów. Ale dzięki nim pisane oprogramowanie może
>> też być bardzo wydajne... O tym nie wspominasz.
>
> Wydajność się zyskuje nie na fistaszkach w rodzaju oszczędzenia jednego
> bajtu czy czterech cykli procesora, tylko na złożoności obliczeniowej
> (asymptotycznej).
>
> Tak, w jądrze systemu operacyjnego też.
>

Gadasz jak typowy teoretyk. Ten sam algorytm o złożoności np. O(n)
napisany w języku wysokiego poziomu (np. w C++) może być kilkukrotnie
przyspieszony, gdy się go przepisze na C. W C++ dochodzą dodatkowe
narzuty (np. na funkcje wirtualne), to przecież oczywiste. Dlaczego
algorytm o czasie asymptotycznym O(n) w C może być kilkukrotnie szybszy
niż ten sam w C++? Wszystko rozbija się o tę magiczną stałą k. O(2n) =
O(5n) = O(kn).

do góry

W dniu 2011-02-01 16:34, Stachu 'Dozzie' K. pisze:
> On 2011-02-01, R. P.<r...@w...pl> wrote:
>>>> Wciąż
>>>> triumfy święci C/C++ i Java.
>>>
>>> A co to ma wspólnego z "wysokopoziomowością" języka, jakkolwiek
>>> definiowaną?
>>
>> Czy ja napisałem, że ma coś wspólnego z wysokopoziomowością? Raczej z
>> popularności wynika to, że dużo bibliotek jest napisanych w C.
>
> To po co wprowadzasz szum do dyskusji?

A ty agresję? He?

>
>>>>> A assembler to daje ci co najwyżej dostęp do urządzeń I/O i trybów
>>>>> procesora. Żadna to moc, tylko ordynarna praca z hardwarem.
>>>>
>>>> Ale cały base jest też napisany w C. Wszystkie podstawowe narzędzia
>>>> unixowe, takie jak sort np. są w C.
>>>
>>> No i? Równie dobrze mogłyby być w Adzie. Gdzie jest ta moc assemblera,
>>> którą dostajesz w C?
>>
>> To usiądź i napisz kernel w Adzie.
>
> Widzisz jakiś problem techniczny w takim pomyśle?

Widzę. Napisanie kernela tak funkcjonalnego jak kernel Linuxa od
początku to wiele osobolat.

>> Przecież oprogramowanie systemowe się
>> rozszerza, nie pisze się go od nowa. To co, połowa będzie w C a połowa w
>> Adzie? W latach 80 zaczęto pisać kernele w C i tak już zostało. Nic nie
>> wskazuje na to ,żeby to się miało zmienić.
>
> Miałeś pokazać dlaczego C jest taki potężny, bo blisko mu do assemblera.
> Nie miałeś dywagować na temat mniej więcej losowego wyboru języka,
> w którym się pisze kernele.

Chciałem jedynie wykazać, że jest ważnym punktem w historii informatyki.
Bardzo ważnym.

>>>> Usiądziesz teraz i
>>>> przepiszesz linuxowego sorta w haskellu? Będzie szybszy od tego z base
>>>> napisanego w C? :)
>>>
>>> Może mi jeszcze wyjedziesz z porównaniem wydajności programu robiącego
>>> "while (1) ;" napisanego w assemblerze, C i Haskellu? W jaki sposób to
>>> ma świadczyć o potędze jakiegoś języka (jakkolwiek byś tej potęgi nie
>>> zdefiniował)?
>>
>> Pytam - czy twój sort w Haskellu będzie szybszy od systemowego sorta w C?
>
> Najpierw objaśnij co by to miało pokazać.

To, że nie jesteś taki kozak, jak ci się wydaje :)
Bo byś lepszego nie napisał.

do góry