Thread View: pl.comp.objects
11 messages
11 total messages
Started by ethouris
Fri, 06 Oct 2006 16:35
Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: ethouris
Date: Fri, 06 Oct 2006 16:35
Date: Fri, 06 Oct 2006 16:35
238 lines
10851 bytes
10851 bytes
Postanowilem odswiezyc nieco temat, skoro i tak ruch jest niewielki.
Z nudów, przeczytalem sobie ten artykul
http://people.cs.uchicago.edu/~jacobm/pubs/templates.html
i musze przyznac: tak, jest smieszny.
Wlasciwie najbardziej rozbawil mnie ponizszy fragment:
> For one thing, templates hurt the C++ compiler's ability to generate
> efficient code. It might surprise you to hear that, considering that
> C++ is "efficient" while functional languages like ML and Scheme are
> "inefficient," but it's true. C++ templates hide your intentions
> from the compiler: did you mean type abstraction? Did you mean a
> syntax extension? Did you mean constant-folding or compile-time code
> generation? The compiler doesn't know, so it has to just blindly
> apply the copy-and-paste strategy and then see what happens. In ML
> or Scheme, though, aside from the individual benefits described
> above, the simple fact that you're telling the compiler what you
> want to achieve lets it optimize for you much more effectively.
Tu autor zdaje sie zapominac o kilku sprawach.
Jezyk ML jest jezykiem nieco wyzszego poziomu, niz C++. To
oznacza np., ze ML pozwala na symboliczny zapis algorytmu,
a kod z niego wygenerowany to nie jest translacja podanych
wyrazen na kod maszynowy, tylko generowanie kodu maszynowego,
który ma robic to samo najtanszym kosztem. W C++ po prostu
tak sie nie pisze - co nie zmienia równiez faktu, ze optymalizacje
w kompilatorach C++ sa równiez wykonywane na kilku poziomach.
Skoro te same optymalizacje sa stosowane dla funkcji z ustalonymi
typami, to dlaczego mialoby to wygladac inaczej w przypadku funkcji
"wygenerowanych" z wzorca?
Na dodatek, nie rozumiem dlaczego tak czesto jest podnoszony
argument o "generowaniu" funkcji z wzorców funkcji w C++. Przeciez
dokladnie taka sama "generacja" nastepuje w przypadku funkcji
inline, a tym bardziej wzorca funkcji inline. Czym sie te dwie ostatnie
rzeczy róznia? A trzeba tu tez wziac pod uwage, ze w przewazajacej
wiekszosci wzorce funkcji robi sie jako inline, z uwagi na nie
rozwiazany
w C++ problem dostepu do wzorców funkcji pomiedzy jednostkami
kompilacji.
> But from a broader perspective, realizing that templates are really
> just a C++ version of Lisp macros geared towards generating type
> declarations rather than extending C++'s syntax helps you understand
> the wider history of programming languages rather than just knowing
> the flavor of the month (which is rapidly becoming the flavor of
> last month!)...
Slusznie. Ale co z tego?
Autor podnosi równiez kwestie bezpieczenstwa typów, czyli:
fun f(a,b) = a + 2*b
powoduje, ze funkcja przyjmuje i zwraca typy, powiedzmy, liczbowe
(a niech tam, zalózmy nawet, ze calkowite). To powoduje, ze uzycie
tej funkcji z typem innym, niz calkowity, daje blad kompilacji. Blad
polega tutaj na tym, ze uzyto typu innego, niz calkowity, chociaz
w deklaracji nikt jawnie nie zazadal, ze typ ma byc calkowity...
i to ma byc rozwiazanie lepsze, niz w C++, gdzie taka funkcje moge
zastosowac sobie dla dowolnych typów, które moga miec "najlepszy
wspólny" i zawierac definicje tych operatorów?
Dalej:
fun f(a,b) = a + 2*b
fun g(x) = x
fun h(a,b) = g(f(a,b))
Tu w funkcji 'g' mamy tzw. "typ polimorficzny". Czym to sie zatem
rózni
od napisania w C++:
int f( int a, int b ) { return a + 2*b; }
template<class T> T g( T x ) { return x; }
int h( int a, int b ) { return g( f( a, b ) ); }
Chyba tylko tym, ze naszym zadaniem jest dostarczyc deklaracje funkcji,
a jakie ona bedzie miala typy argumentów i typ wartosci zwracanej
dowiemy
sie podczas kompilacji. Dlaczego tak jest lepiej, tez sie nie
dowiedzialem
z tego artykulu, jesli mam byc szczery.
Przyklad z sygnatura, który podal, doskonale z kolei wpasowuje sie
w reguly wzorców w C++. Stosujac skladnie koncepcji, które maja
byc w przyszlym standardzie C++, mozemy nawet zrobic niemal
wierna kopie ponizszego przykladu:
signature PRINTABLE = sig
type t
val printT : t -> unit
end
functor List(T : PRINTABLE) =
struct
datatype List = ListNode of T.t * List | Empty
exception EmptyList
(* ... other functions as before ... *)
fun print (ListNode (i,_)) = T.printT i
end
Czyli:
concept PRINTABLE { typename t; static void printT( t ); }
template<PRINTABLE T>
struct List
{
vector<ListNode<T>> list; // pominmy, bo to akurat inna sprawa :)
void print( const ListNode<T> & node ) { return T::printT( node.i );
}
};
Odnoszac to teraz wszystko do Javowych generyków, wyglada na to, ze
zarówno C++, jak i Java wziely wiele koncepcji programowania
generycznego
z ML, z ta tylko róznica, ze wyciagnely z ML zupelnie inne czesci i
rozwinely
na swój wlasny sposób.
Zwracam tu uwage na to, ze w przypadku Javy wszelkie sprawdzanie, czy
okreslony typ posiada pewne wlasciwosci, opiera sie na klasach i
interfejsach.
Co w praktyce oznacza, ze nie da sie wykorzystac okreslonej
funkcjonalnosci
generycznej dla typów, które byly stworzone wczesniej, niz koncepcje
wymagane
przez owa funkcjonalnosc - trzeba do tego celu robic rózne dodatkowe
opakowania, nawet jesli te opakowania beda polegaly na tym, ze po
prostu
wywolamy metody o dokladnie tych samych nazwach przekazujac jej te
same argumenty.
C# zreszta stosuje dokladnie ta sama metode (fragment wywiadu z
Andersem
Hejlsbergiem na Artimie):
Anders Hejlsberg: What you are really asking is, what can you say in
terms of constraints? Constraints, like any other feature, can become
arbitrarily complex if taken to their ultimate extreme. When you think
about it, constraints are a pattern matching mechanism. You want to be
able to say, "This type parameter must have a constructor that takes
two arguments, implement operator+, have this static method, has these
two instance methods, etc." The question is, how complicated do you
want this pattern matching mechanism to be?
[...]
Bill Venners: You did the constraints by type, not by signature.
Anders Hejlsberg: Yes.
Bill Venners: So the type must either extend a class or implement
interfaces.
Anders Hejlsberg: Yes.
[...]
Bruce Eckel: Well, yes, I started seeing C++ templates as sort of a
weak typing mechanism. And when you start adding constraints on top of
that, you're going from the weak typing to the strong typing. It always
gets more complex when you add strong typing. It's a spectrum.
Anders Hejlsberg: The thing you realize about typing is that it's a
dial. The higher you place the dial, the more painful the programmer's
life becomes, but the safer it becomes too. But you can turn that dial
too far in either direction.
Interesujace w tej calej dyskusji jest to, ze w zasadzie wszyscy
dyskutanci,
niezaleznie od pogladów, zdaja sie wyglaszac kuriozalne stwierdzenie,
ze
"strong typing" oznacza bezpieczenstwo. Jednoczesnie stwierdzajac, ze
wzorce w C++ maja "weak typing", co odbieralbym raczej jako pejoratywne
okreslenie, bo w terminologii C++ jako przeciwienstwo "strong" (w
róznych
kontekstach) uzywano raczej "vague", a nie "weak". Jest to wierutna
bzdura - silne typowanie jest po prostu typowaniem bardziej scislym,
w którym, niezaleznie czy celowo, czy nie, ograniczamy mozliwosci
uzytkownika pod wzgledem tego, co on moze z tym zrobic. Nie ma to
nic wspólnego z jakimkolwiek bezpieczenstwem: typowanie po
sygnaturze jest bezpieczne w tych ramach, w jakich wymaga tego
sygnatura. Nikomu wiecej nie jest potrzebne, bo nie zostanie w zaden
sposób wykorzystane.
W tej dyskusji z kolei pominieto równiez fakt, ze po czesci ten
sposób
uprawiania generyzmu jest dostepny w ML-u i rozwiazanie tam wlasnie
zastosowane (konkretnie chodzi o sygnatury) rózni sie wyraznie od
tego,
co jest w Javie i C#.
Co mozna zauwazyc wspólnego dla tych obu dyskusji? Obie przy opisach
spraw techniczno-projektowych dotyczacych implementacji generyzmu
skupiaja sie na jednym konkretnym stwierdzeniu: jak bardzo chujowy jest
C++ (choc oczywiscie nikt z dyskutantów nie pokusil sie o podanie
jakichs
przykladów z praktyki, które moglyby powodowac problemy).
Jacob Matthews wspomnial w swojej dyskusji o Javie dokladnie w jednym
miejscu: zeby pokazac, jak wyglada róznica miedzy sygnaturami i
funktorami
w ML-u i Javowymi interfejsami w kwestii programowania generycznego.
Niby
wszystko ok, tyle ze na koniec rzuca kuriozalnym stwierdzeniem:
"This system gives you more abstraction power than C++ templates or
Java interfaces while providing type-safety."
Po pierwsze, co maja wspólnego "Java interfaces" i "C++ templates", w
istocie
blizsze ML-owej metodzie opartej na sygnaturach, niz Javowe generyki?
Po drugie - gdzie tu jest w C++ problem z "type safety"? Na dokladnie
tej
samej zasadzie moge stwierdzic, ze w ML-u jest problem z type safety
w kwestii tej pierwszej funkcji, bo NIE MA JAWNIE NAPISANEGO TYPU.
Dokladnie tak samo w C++ nie ma jawnie okreslonej koncepcji (w biezacym
standardziej).
Co, skadinad, nie wiem, czym sie rózni od funkcji przyjmujacej "typ
polimorficzny" w ML-u.
Wszystko to wyglada w ten sposób, ze jezyki maja swoje jakies-tam
okreslone wlasciwosci zwiazane z implementacja generyzmu. Ale jak
na razie nie zauwazylem, zeby ktos prowadzil rzeczowa dyskusje o tym,
jak wyglada porównanie tych wlasciwosci i jak wygladaja praktyczne
konsekwencje ich realizacji. Za to wszyscy z luboscia uprawiaja tani
marketing, w którym wielce merytoryczne stwierdzenie p. Lewandowskiego
"Szablony w C++ to straszne badziewie" wcale nie odbiega poziomem od
tego, co prezentuja panowie Jacob Matthews i Anders Hejlsberg.
Re: Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: A.L.
Date: Fri, 06 Oct 2006 16:52
Date: Fri, 06 Oct 2006 16:52
33 lines
2179 bytes
2179 bytes
On 6 Oct 2006 09:35:06 -0700, "ethouris" <ethouris@gmail.com> wrote: >Postanowilem odswiezyc nieco temat, skoro i tak ruch jest niewielki. > >Z nudów, przeczytalem sobie ten artykul > >http://people.cs.uchicago.edu/~jacobm/pubs/templates.html > >i musze przyznac: tak, jest smieszny. > >Wlasciwie najbardziej rozbawil mnie ponizszy fragment: > >> For one thing, templates hurt the C++ compiler's ability to generate >> efficient code. It might surprise you to hear that, considering that [...] >marketing, w którym wielce merytoryczne stwierdzenie p. Lewandowskiego >"Szablony w C++ to straszne badziewie" wcale nie odbiega poziomem od >tego, co prezentuja panowie Jacob Matthews i Anders Hejlsberg. Dziekuje za wspomnienie. Szablony to starszne badziewie i nic wiecej niz makrogeneracja. A C++ w ogole do dupy. No to jak, Panie Kolego, ustalil Pan w koncu co jest lepsze: Swieta Wielkiej Nocy, czy Bozego Narodzenia? Proponuje aby oszczedzil Pan swoj intelekt i zamiast zajmowac sie pierdolami jak wyzej zajal sie czyms powaznym. A taka powazna rzeczz na przyklad: Intel wypuscil chip 4-prodesorowy (quad core). W robocie sa 8 i 16 "corowe". Czym sie to bedzie programwoalo aby wykorzystac fakt ze sie ma 16 procesorow na jednym chipie? C++ templates?... Wolne zarty. A.L.
Re: Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: Jacek Pietraszek
Date: Sat, 07 Oct 2006 16:52
Date: Sat, 07 Oct 2006 16:52
18 lines
1736 bytes
1736 bytes
A.L. <alewando@fala2005.com> napisal: > Proponuje aby oszczedzil Pan swoj intelekt i zamiast zajmowac sie > pierdolami jak wyzej zajal sie czyms powaznym. A taka powazna > rzeczz na przyklad: Intel wypuscil chip 4-prodesorowy (quad core). W > robocie sa 8 i 16 "corowe". Czym sie to bedzie programwoalo aby > wykorzystac fakt ze sie ma 16 procesorow na jednym chipie? C++ > templates?... Wolne zarty. Hm, a jakie obecnie sa mozliwosci przydzielenia procesu do konkretnego core'a? Nie zajmowalem sie programowaniem wieloprocesorowym od czasu s.p. transputerow, ale to bylo w roku 1989, wiec troszke wody uplynelo. No to jak: sa jakies biblioteki, wsparcie API w systemie lub cos innego? A co z mechanizmami synchronizacji? -- Pozdrawiam, Jacek
Re: Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: A.L.
Date: Sat, 07 Oct 2006 19:30
Date: Sat, 07 Oct 2006 19:30
24 lines
1958 bytes
1958 bytes
On Sat, 7 Oct 2006 16:52:29 +0000 (UTC), Jacek Pietraszek <nobody@nospam.cyf-kr.edu.pl> wrote: >A.L. <alewando@fala2005.com> napisal: >> Proponuje aby oszczedzil Pan swoj intelekt i zamiast zajmowac sie >> pierdolami jak wyzej zajal sie czyms powaznym. A taka powazna >> rzeczz na przyklad: Intel wypuscil chip 4-prodesorowy (quad core). W >> robocie sa 8 i 16 "corowe". Czym sie to bedzie programwoalo aby >> wykorzystac fakt ze sie ma 16 procesorow na jednym chipie? C++ >> templates?... Wolne zarty. > >Hm, a jakie obecnie sa mozliwosci przydzielenia procesu do >konkretnego core'a? Nie zajmowalem sie programowaniem >wieloprocesorowym od czasu s.p. transputerow, ale to bylo >w roku 1989, wiec troszke wody uplynelo. No to jak: sa jakies >biblioteki, wsparcie API w systemie lub cos innego? >A co z mechanizmami synchronizacji? Nie ma. W prasie pisza ze potzrebna jest reqolucja na miare programowania obiektowego. Czescia tej rewolucji bedzie rowneiz to ze :informatycy z wykszatalceniem domowym" beda mieli trudnosci z zarobieniem na chleb (to nie moja opinia, tylko prasy). A.L.
Re: Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: A.L.
Date: Sat, 07 Oct 2006 20:15
Date: Sat, 07 Oct 2006 20:15
29 lines
2306 bytes
2306 bytes
On Sat, 07 Oct 2006 21:51:11 +0000, Andrzej 'Rudy' Dąbrowski <a.r.dabrowskiSPAM@gmail.com> wrote: >A.L. narzeźbił(a): > >>>Hm, a jakie obecnie sa mozliwosci przydzielenia procesu do >>>konkretnego core'a? Nie zajmowalem sie programowaniem >>>wieloprocesorowym od czasu s.p. transputerow, ale to bylo >>>w roku 1989, wiec troszke wody uplynelo. No to jak: sa jakies >>>biblioteki, wsparcie API w systemie lub cos innego? >>>A co z mechanizmami synchronizacji? >> >> Nie ma. W prasie pisza ze potzrebna jest reqolucja na miare >> programowania obiektowego. Czescia tej rewolucji bedzie rowneiz to >> ze "informatycy z wykszatalceniem domowym" beda mieli trudnosci z >> zarobieniem na chleb (to nie moja opinia, tylko prasy). > >A możesz rozwinąć trochę te powiązanie między "rewolucją synchornizacji" >(głupia nazwa), a zagładą "informatyki domowej"? Jakiś link albo cokolwiek >innego... w sumie to interesujące, chociaz nie wiem jak odnieść te dwa >fronty do siebie nawzajem. Niemozliwy beidzie paradygmat "code first, think later", jak rowniez niezbedne bedzie uzycie roznego rodzaju metod formalnych przy projektowaniu systemow i ich weryfikacji. Na poczatek proponuje zajzrec do ksaizki Hoare na temat CSP. Link podawalem jakis czas temu. A.L.
Re: Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: Andrzej 'Rudy' Dąbrowski
Date: Sat, 07 Oct 2006 21:51
Date: Sat, 07 Oct 2006 21:51
21 lines
2022 bytes
2022 bytes
A.L. narzeźbił(a): >>Hm, a jakie obecnie sa mozliwosci przydzielenia procesu do >>konkretnego core'a? Nie zajmowalem sie programowaniem >>wieloprocesorowym od czasu s.p. transputerow, ale to bylo >>w roku 1989, wiec troszke wody uplynelo. No to jak: sa jakies >>biblioteki, wsparcie API w systemie lub cos innego? >>A co z mechanizmami synchronizacji? > > Nie ma. W prasie pisza ze potzrebna jest reqolucja na miare > programowania obiektowego. Czescia tej rewolucji bedzie rowneiz to > ze "informatycy z wykszatalceniem domowym" beda mieli trudnosci z > zarobieniem na chleb (to nie moja opinia, tylko prasy). A możesz rozwinąć trochę te powiązanie między "rewolucją synchornizacji" (głupia nazwa), a zagładą "informatyki domowej"? Jakiś link albo cokolwiek innego... w sumie to interesujące, chociaz nie wiem jak odnieść te dwa fronty do siebie nawzajem. -- Pozdrawiam, Andrzej
Re: Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: Marcin Stefaniak
Date: Sun, 08 Oct 2006 19:55
Date: Sun, 08 Oct 2006 19:55
30 lines
2396 bytes
2396 bytes
A.L. <alewando@fala2005.com> napisał(a): > >> Nie ma. W prasie pisza ze potzrebna jest reqolucja na miare > >> programowania obiektowego. Czescia tej rewolucji bedzie rowneiz to > >> ze "informatycy z wykszatalceniem domowym" beda mieli trudnosci z > >> zarobieniem na chleb (to nie moja opinia, tylko prasy). > > > >A możesz rozwinąć trochę te powiązanie między "rewolucją synchornizacji" > >(głupia nazwa), a zagładą "informatyki domowej"? Jakiś link albo cokolwiek > >innego... w sumie to interesujące, chociaz nie wiem jak odnieść te dwa > >fronty do siebie nawzajem. > > Niemozliwy beidzie paradygmat "code first, think later", jak rowniez > niezbedne bedzie uzycie roznego rodzaju metod formalnych przy > projektowaniu systemow i ich weryfikacji. Na poczatek proponuje > zajzrec do ksaizki Hoare na temat CSP. Link podawalem jakis czas > temu. Prasa, jak zwykle, kłamie... Wiekszość tej "informatyki domowej" to nie są systemy które muszą działać rewelacyjnie szybko, i pojedynczy procesor im już wystarcza. A te rzeczy, które są procesorochłonne będą zapakowane w komponenciki, na przykład kodeki, łatwe do wbudowania w swój system zrobiony "po domowemu". pozdrawiam, Marcin Stefaniak -- Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Re: Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: A.L.
Date: Sun, 08 Oct 2006 20:14
Date: Sun, 08 Oct 2006 20:14
32 lines
2585 bytes
2585 bytes
On Sun, 8 Oct 2006 19:55:37 +0000 (UTC), "Marcin Stefaniak" <matmis@WYTNIJ.gazeta.pl> wrote: >A.L. <alewando@fala2005.com> napisał(a): > >> >> Nie ma. W prasie pisza ze potzrebna jest reqolucja na miare >> >> programowania obiektowego. Czescia tej rewolucji bedzie rowneiz to >> >> ze "informatycy z wykszatalceniem domowym" beda mieli trudnosci z >> >> zarobieniem na chleb (to nie moja opinia, tylko prasy). >> > >> >A możesz rozwinąć trochę te powiązanie między "rewolucją synchornizacji" >> >(głupia nazwa), a zagładą "informatyki domowej"? Jakiś link albo cokolwiek >> >innego... w sumie to interesujące, chociaz nie wiem jak odnieść te dwa >> >fronty do siebie nawzajem. >> >> Niemozliwy beidzie paradygmat "code first, think later", jak rowniez >> niezbedne bedzie uzycie roznego rodzaju metod formalnych przy >> projektowaniu systemow i ich weryfikacji. Na poczatek proponuje >> zajzrec do ksaizki Hoare na temat CSP. Link podawalem jakis czas >> temu. > >Prasa, jak zwykle, kłamie... > >Wiekszość tej "informatyki domowej" to nie są systemy które muszą działać >rewelacyjnie szybko, i pojedynczy procesor im już wystarcza. A te rzeczy, >które są procesorochłonne będą zapakowane w komponenciki, na przykład kodeki, >łatwe do wbudowania w swój system zrobiony "po domowemu". Ja nie mialem na mysli "informatykow domowych w domu", ja mialem na mysli "informatykow domowych w przemysle". A.L.
Re: Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: ethouris
Date: Sun, 08 Oct 2006 21:10
Date: Sun, 08 Oct 2006 21:10
26 lines
2344 bytes
2344 bytes
A.L. wrote: > A taka powazna > rzeczz na przyklad: Intel wypuscil chip 4-prodesorowy (quad core). W > robocie sa 8 i 16 "corowe". Czym sie to bedzie programwoalo aby > wykorzystac fakt ze sie ma 16 procesorow na jednym chipie? Językiem z dobrym kompilatorem? > C++ templates?... Wolne zarty. Nie rozumiem. A w czym to niby przeszkadza/nie pomaga, jaki to ma w ogóle związek? Będzie się programowało w tym, w czym ludzie lubią programować i do czego powstaną kompilatory i biblioteki, które będą umiały z tego skorzystać. Tak było zawsze i nie sądzę, żeby się to zmieniło nawet wobec takich faktów. Nie widzę jednak związku tutaj z C++ - język jak język, tak jak i inne, które są dzisiaj w użyciu. Ważniejsze są metody programowania i sposoby ich implementacji przez poszczególne języki i biblioteki. Jeśli już dyskutować w kontekście takich faktów, to najwyżej o tym, czy określone języki będą potrafiły odpowiednio wyrażać te metody programowania i ewentualnie dlaczego nie, czy dlaczego koszmarnie i niewygodnie. Związku jednak z wzorcami C++ nie widzę tutaj żadnego.
Re: Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: Miros/law L. Baran
Date: Mon, 09 Oct 2006 07:41
Date: Mon, 09 Oct 2006 07:41
13 lines
1515 bytes
1515 bytes
PT A.L pisze:
> Ja nie mialem na mysli "informatykow domowych w domu", ja mialem na
> mysli "informatykow domowych w przemysle".
Toż połowa tzw. przemysłu wtedy stanie ;->
Jubal
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, http://hell.pl/baran/tek/, alchemy pany! ] [ The Answer ]
Give me the Luxuries, and the Hell with the Necessities!
Re: Jeszcze o C++ templates i ich zwiazku z.... ML i Lispem
Author: A.L.
Date: Mon, 09 Oct 2006 12:43
Date: Mon, 09 Oct 2006 12:43
13 lines
1382 bytes
1382 bytes
On Mon, 9 Oct 2006 07:41:42 +0000 (UTC), "Miros/law L. Baran" <baran@hell.pl> wrote: >PT A.L pisze: >> Ja nie mialem na mysli "informatykow domowych w domu", ja mialem na >> mysli "informatykow domowych w przemysle". > >Toż połowa tzw. przemysłu wtedy stanie ;-> > Tak na oko, wiecej niz polowa... A.L.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads