🚀 go-pugleaf

Dnia Sun, 1 Dec 2002 02:55:59 -0800
"lucek" <ezenroth@wp.pl> pisze:

> Wiem juz za co lubicie pythona ;-) ale do jakich problemow(projektow)
> warto go urzywac? Wiadomo, ze czasami lepsza jest java a czasami
> c++... kiedy lepszy jest python?

Dopóki nie chodzi o pisanie sterowników do sprzętu - zawsze.

-- 
~$ rm -f /bin/Laden
I po kłopocie!

-- 
Serwis Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Jarek Zgoda" <jarek@usun.gazeta.pl> wrote in message
news:20021201114649.48cd9271.jarek@usun.gazeta.pl...
> Dnia Sun, 1 Dec 2002 02:55:59 -0800
> "lucek" <ezenroth@wp.pl> pisze:
>
> > Wiem juz za co lubicie pythona ;-) ale do jakich problemow(projektow)
> > warto go urzywac? Wiadomo, ze czasami lepsza jest java a czasami
> > c++... kiedy lepszy jest python?
>
> Dopóki nie chodzi o pisanie sterowników do sprzętu - zawsze.
E tam przesadzasz chyba... czy jest tak szybki jak c++?

Lucek

Dnia Sun, 1 Dec 2002 03:30:53 -0800, lucek napisał(a):
>> Dopóki nie chodzi o pisanie sterowników do sprzętu - zawsze.
> E tam przesadzasz chyba... czy jest tak szybki jak c++?
Pewnie, ze nie. Szybkosc to cena jaka placisz za wszystkie zalety pythona.
Nie oznacza to oczywiscie, ze jest on koszmarnie wolny, ale na pewno nie
jest "tak szybki jak c++". W kazdym razie - faktycznie - dopoki nie
trzeba pisac czegos "systemowego" _mozna_ smialo uzywac pythona(albo 
dowolnego innego jezyka wysokopoziomowego).

-- 
[ ] gminick (at) underground.org.pl  http://gminick.linuxsecurity.pl/ [ ]
[ "Po prostu lubie poranna samotnosc, bo wtedy kawa smakuje najlepiej." ]

In article <ascpru$rqa$1@news.tpi.pl>, lucek wrote:
> Wiem juz za co lubicie pythona ;-) ale do jakich problemow(projektow) warto
> go urzywac? 
>Wiadomo, ze czasami lepsza jest java a czasami c++
C++ kiedy???? od czego??? :-)

> ... kiedy lepszy jest python?

Zawsze, gdy nie musisz operować szybko i/lub na bardzo niskimim
poziomie. Czyli Python niezbyt się nadaje do:

- bezpośredniej obsługi sprzętu, ale tym i tak zajmuje się kernel
- przetwarzania dużej ilości tekstu "znak po znaku"
- przetwarzania dużej ilości innych danych (np. dźwięku czy obrazu 
  w realtime).
itp.

Ale to nie znaczy, że programów robiących takie rzeczy nie należy pisać
w pythonie. Zwykle robi się tak, że krytyczne funkcje implementuje się 
w C (np. filtry audio), a wszystko opakowuje w program w pythonie.
Przeważnie okazuje się, że te krytyczne funkcje już są zaimplementowane
w jakiejś bibliotece, do której jest moduł w pythonie, więc nic w C
programować nie trzeba :-)

Java jest lepsza tam, gdzie miejsce użycia tego wymaga (np. aplety na
stronie WWW), ale i tutaj jak się chce, to można pythona użyć (Jython).

W niektórych przypadkach lepsze od pythona będą języki specjalizowane
(np. do przetwarzania tekstu często lepszy jest awk, bo dużo szybszy).
Ale w większości przypadków Python jest dobrym rozwiązaniem. Nie piszę
że najlepszym, bo to zależy między innymi od preferencji i sposobu
myślenia programisty. 

Pozdrowienia,
        Jacek

"Jacek Konieczny" <jajcus@bnet.pl> wrote in message
news:slrnaujtds.mm1.jajcus@nic.bnet.pl...
> In article <ascpru$rqa$1@news.tpi.pl>, lucek wrote:
> > Wiem juz za co lubicie pythona ;-) ale do jakich problemow(projektow)
warto
> > go urzywac?
> >Wiadomo, ze czasami lepsza jest java a czasami c++
> C++ kiedy???? od czego??? :-)
Od innych jezykow... zalezy na czym nam zalezy. Np male aplikacje lepiej
pisac w javie(szczegolnie jesli zalezy nam na przenosnosci), ale jesli
chodzi o wieksze programy to zdecydowanie c++. Szybkosc programow napisanych
w javie czasami poraza, i to nie tylko uzytkownika ale i komputer :/

Lucek

Dnia Sun, 1 Dec 2002 03:30:53 -0800
"lucek" <ezenroth@wp.pl> pisze:

> > > kiedy lepszy jest python?
> > Dopóki nie chodzi o pisanie sterowników do sprzętu - zawsze.
> E tam przesadzasz chyba... czy jest tak szybki jak c++?

Jak chcesz, szybkości, to pisz w asemblerze. Ja wolę szybko pisac
programy, niż żeby mi szybko działały. Luzeria nawet nie zauważa
różnicy.

-- 
~$ rm -f /bin/Laden
I po kłopocie!

-- 
Serwis Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Dnia Sun, 1 Dec 2002 03:54:40 -0800, lucek napisał(a):
>> >Wiadomo, ze czasami lepsza jest java a czasami c++
>> C++ kiedy???? od czego??? :-)
> Od innych jezykow... zalezy na czym nam zalezy. Np male aplikacje lepiej
> pisac w javie(szczegolnie jesli zalezy nam na przenosnosci), ale jesli
> chodzi o wieksze programy to zdecydowanie c++.
Takie stwierdzenia z reguly wywoluja burze ;)
Gdzie nie pojdziesz, tam spotkasz rzesze ludzi, ktorzy, gdy
usylysza stwierdzenie "zdecydowanie c++" to wyciagaja od razu
kastety i noze, albo przynajmniej wspolczuja :)
Napisz cos wiekszego w pythonie, a tez bedziesz z obrzydzeniem
patrzyl na c++ 

-- 
[ ] gminick (at) underground.org.pl  http://gminick.linuxsecurity.pl/ [ ]
[ "Po prostu lubie poranna samotnosc, bo wtedy kawa smakuje najlepiej." ]

Dnia Sun, 1 Dec 2002 04:41:11 -0800
"lucek" <ezenroth@wp.pl> pisze:

> > > > > kiedy lepszy jest python?
> > > > Dopóki nie chodzi o pisanie sterowników do sprzętu - zawsze.
> > > E tam przesadzasz chyba... czy jest tak szybki jak c++?
> >
> > Jak chcesz, szybkości, to pisz w asemblerze. Ja wolę szybko pisac
> > programy, niż żeby mi szybko działały. Luzeria nawet nie zauważa
> > różnicy.
> Idac twoim tokiem rozumowania powinny byc dwa jezyki programowania:
> a)python,java,etc - dla tych ktorzy nie potrzebuja ultra szybkich
> programow b)asembler - dla tych co jednak nie lubia czekac 0,5 sec na
> otworzenie sie menu w programie :/
> Przesadzasz.

Bardzo dobrze pojmujesz mój tok rozumowania. I nie przesadzam.

-- 
~$ rm -f /bin/Laden
I po kłopocie!

-- 
Serwis Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Dnia: Sun, 1 Dec 2002 02:55:59 -0800, osoba lucek napisała:
> Wiem juz za co lubicie pythona ;-) ale do jakich problemow(projektow) warto
> go urzywac?
> ...

Ja uŻywam pythona do tworzenia aplikacji internetowych, przy pomocy
Zope.

-- 
Pozdrawiam,
Maciek

Dnia Sun, 1 Dec 2002 06:35:30 -0800
"lucek" <ezenroth@wp.pl> pisze:

> > Bardzo dobrze pojmujesz mój tok rozumowania. I nie przesadzam.
> Jestem ciekaw co na twoj tok rozumowania powiedzieli by programisci
> linuxa;p Jestem pewien, ze rozwazaja przesiadke na pythona ;p

A ja z kolei jestem ciekaw, czy przeczytałeś moją wcześniejszą
wypowiedź na temat programowania strowników sprzętu.

-- 
~$ rm -f /bin/Laden
I po kłopocie!

-- 
Serwis Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

> Takie stwierdzenia z reguly wywoluja burze ;)
> Gdzie nie pojdziesz, tam spotkasz rzesze ludzi, ktorzy, gdy
> usylysza stwierdzenie "zdecydowanie c++" to wyciagaja od razu
> kastety i noze, albo przynajmniej wspolczuja :)
Ci ludzie sa glupi. Rozne narzedzia do roznych rzeczy... Po co pisac program
w c++ skoro mozna cos zrobic z powodzeniem w bashu?
Czasami potrzebny jest szybki kod wynikowy, a czasami liczy sie czas
produkcji aplikacji.
> Napisz cos wiekszego w pythonie, a tez bedziesz z obrzydzeniem
> patrzyl na c++
Nie warzne jest to czy bede patrzyl na c++ z obrzydzeniem. Wazne jest to,
zeby end userzy nie patrzyli na moj program z obrzydzeniem.

Thx,
Lucek

Dnia Sun, 1 Dec 2002 07:15:41 -0800
"lucek" <ezenroth@wp.pl> pisze:

> > A ja z kolei jestem ciekaw, czy przeczytałeś moją wcześniejszą
> > wypowiedź na temat programowania strowników sprzętu.
> I stand corrected.
> Nie wyobrazam jednak sobie pracy w takim kombajnie jak office, czy
> MSVC, ktory bylby napisany w jezyku sporo wolniejszym niz C++.

Jeżeli chodzi o MS Office... To pewnie nie wiesz, że jest napisany w
VBA... Tylko szkielet ma w VC++.

-- 
~$ rm -f /bin/Laden
I po kłopocie!

-- 
Serwis Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Uzytkownik "lucek" <ezenroth@wp.pl> napisal w wiadomosci
news:ascpru$rqa$1@news.tpi.pl...
> Hi!
>
> Wiem juz za co lubicie pythona ;-) ale do jakich problemow(projektow)
warto
> go urzywac? Wiadomo, ze czasami lepsza jest java a czasami c++... kiedy
> lepszy jest python?
IMHO java jest lepsza gdy zalezy programiscie na 100% przenaszalnosci kodu
a c++? well... chyba w jakichs embedded platformach gdzie liczy sie kazdy
bajt pamieci operacyjnej

>
> Lucek
>
>

Jarek Zgoda wrote:

> Jeżeli chodzi o MS Office... To pewnie nie wiesz, że jest napisany w
> VBA... Tylko szkielet ma w VC++.


Po pierwsze nie jest. Po drugie nawet gdyby był, to np. sam winword.exe 
  z MSO 2000, nie licząc dynamicznie ładowanych bibliotek, zawiera 
blisko 8 megabajtów natywnego kodu wykonywalnego, zatem ten "szkielet" 
stanowiłby ogromną wiekszość Office'a...

Dnia Sun, 1 Dec 2002 16:51:49 +0100, piter napisał(a):

>> Wiem juz za co lubicie pythona ;-) ale do jakich problemow(projektow)
> warto
>> go urzywac? Wiadomo, ze czasami lepsza jest java a czasami c++... kiedy
>> lepszy jest python?
> IMHO java jest lepsza gdy zalezy programiscie na 100% przenaszalnosci kodu
> a c++? well... chyba w jakichs embedded platformach gdzie liczy sie kazdy
> bajt pamieci operacyjnej

Na embedded pltformach to C i/lub ASM a nie rozpusta typu C++ ;-P

-- 
 -------------------------=[Krzysztof Luks][m00se<at>iq.pl]=----------+
^oo^       Szewc zabija szewca, bum tarara bum tarara... Szewc zabija |
('`)                                szewca, bum tarara bum tarara...  |
_/\_ [RG]                                         --=[mep.pl 0.0.6]---+

Użytkownik "lucek" <ezenroth@wp.pl> napisał:

>... kiedy lepszy jest python?

Zawsze :)

Adam Karpierz
karpierz@alpha.pl

> Czasami potrzebny jest szybki kod wynikowy, a czasami liczy sie czas
> produkcji aplikacji.
Pamietaj Lucek, ¿e na czas wykonywania siê aplikacji nie wp³ywa tylko i
wy³±cznie szybko¶æ kodu samego programu, ale równiez czas operacji
wejscia-wyjscia, czytania z baz danych i soketów, operacje systemowe... A
wiec operacje, które w pythonie, czy C trwaja dokladnie tyle samo. Poza tym
w jezykach wysokiego poziomu czesto lepiej skonstruowany i bardziej
przejrzysty jest szkielet aplikacji, i w konsekwencji to równiez przyczynia
sie do jej przyspieszenia. A C++ i tak nie jest szybki. Waznym aspektem jest
rowniez poprawnosc dzialania oprogramowania - a ta jest w pythonie o wiele
latwiejsza do uzyskania...
Pozdrowienia,
Tomek

Jarek Zgoda <jarek@usun.gazeta.pl> wrote:
> Dnia Sun, 1 Dec 2002 07:15:41 -0800
> "lucek" <ezenroth@wp.pl> pisze:

>> > A ja z kolei jestem ciekaw, czy przeczytałeś moją wcześniejszą
>> > wypowiedź na temat programowania strowników sprzętu.
>> I stand corrected.
>> Nie wyobrazam jednak sobie pracy w takim kombajnie jak office, czy
>> MSVC, ktory bylby napisany w jezyku sporo wolniejszym niz C++.

> Jeżeli chodzi o MS Office... To pewnie nie wiesz, że jest napisany w
> VBA... Tylko szkielet ma w VC++.
	... roznie moze byc, jesli aplikacja jest przejrzysta
o wiele lepiej mozna ja logicznie dopracowac. Czlowiek o ograniczona
bestia, wszystko co pozwala mu lepiej ogarnac problem, nawet przejrzysty
kod, moze pomoc mu ogarnac wiecej i przspieszyc aplikacje. Z powazaniem
								Adam Przybyla

Mariusz K. Grzeca <mgrzeca@sokrates.mimuw.edu.pl> wrote:
> Jarek Zgoda wrote:

>> Jeżeli chodzi o MS Office... To pewnie nie wiesz, że jest napisany w
>> VBA... Tylko szkielet ma w VC++.


> Po pierwsze nie jest. Po drugie nawet gdyby był, to np. sam winword.exe 
>  z MSO 2000, nie licząc dynamicznie ładowanych bibliotek, zawiera 
> blisko 8 megabajtów natywnego kodu wykonywalnego, zatem ten "szkielet" 
> stanowiłby ogromną wiekszość Office'a...
	... roznie to bywa, poniewaz to closed source, mozemy gdybac.
Jako przyklad duzej szybkiej aplikacji moge podac wyszukiwarke
ultraseek, dzieki dopracowaniu calego kodu w Pythonie udalo im
sie zrobic bardzo szybki produkt. Z powazaniem
								Adam Przybyla

lucek wyprodukował[ao]?:

> "Jarek Zgoda" <jarek@usun.gazeta.pl> wrote in message
> news:20021201114649.48cd9271.jarek@usun.gazeta.pl...
>> Dnia Sun, 1 Dec 2002 02:55:59 -0800
>> "lucek" <ezenroth@wp.pl> pisze:
>>
>> > Wiem juz za co lubicie pythona ;-) ale do jakich problemow(projektow)
>> > warto go urzywac? Wiadomo, ze czasami lepsza jest java a czasami
>> > c++... kiedy lepszy jest python?
>>
>> Dopóki nie chodzi o pisanie sterowników do sprzętu - zawsze.
> E tam przesadzasz chyba... czy jest tak szybki jak c++?

Najpierw musisz wiedzieć, do czego ci ta szybkość potrzebna. W
większości przypadków do niczego. Tam, gdzie rzeczywiście jest, bierzesz
C/C++ i piszesz moduł do Pythona :)

Pozdrawiam,
Baczek
-- 
Marek Baczyński aka Baczek UIN:57114871 RLU:201791 http://republika.pl/imbaczek
1010011010 - The binary number of the Beast

On Sun, 1 Dec 2002 03:30:53 -0800, "lucek" <ezenroth@wp.pl> wrote:

>E tam przesadzasz chyba... czy jest tak szybki jak c++?

W jakim sensie szybszy? Chodzi o czysty kod czy o szybkość tworzenia
kodu też? Jeśli uwzględnisz także to drugie, to prostota, automatyczne
odśmiecanie pamięci i b. łatwe debugowanie powodują, że tworzenie kodu
w Pythonie  jest wiele szybsze (i oczywiście o wiele bardziej
międzyplatformowe).

Jesli zaś chodzi o pewne kluczowe fragmenty, gdzie jest wymagana max.
wydajność kodu, programujesz w C++, dołączasz do Pythona jako
bibliotekę i już. Czasem nawet nie trzeba pisać takich bibliotek, bo
są gotowe. Np. genialnie proste i szybkie parsowanie XML
(http://pyana.sourceforge.net) oparte na bibliotece Xalan w C++.

Tomek Meka <tmeka@gmx.net> wrote:
>> Czasami potrzebny jest szybki kod wynikowy, a czasami liczy sie czas
>> produkcji aplikacji.
> Pamietaj Lucek, ?e na czas wykonywania si? aplikacji nie wp?ywa tylko i
> wy??cznie szybko?? kodu samego programu, ale równiez czas operacji
> wejscia-wyjscia, czytania z baz danych i soketów, operacje systemowe... A
> wiec operacje, które w pythonie, czy C trwaja dokladnie tyle samo. Poza tym
> w jezykach wysokiego poziomu czesto lepiej skonstruowany i bardziej
> przejrzysty jest szkielet aplikacji, i w konsekwencji to równiez przyczynia
> sie do jej przyspieszenia. A C++ i tak nie jest szybki. Waznym aspektem jest
> rowniez poprawnosc dzialania oprogramowania - a ta jest w pythonie o wiele
> latwiejsza do uzyskania...

Jesteś pewien z tą poprawnością działania?
Nie znam Pythona, ale mam złe doświadczenia z językami z dynamicznym
systemem typów. Pisałem trochę w Smalltalku i w różnych językach
skryptowych: Lua, bash, awk, itp.. Może i w tych językach można szybciej
wklepać lub modyfikować kod, niż np. w C++, Javie albo Ocamlu,
ale brak statycznego typowania powoduje powstawanie błędów,
które wychodzą (albo i nie) w trakcie działania programu.

Trudno mi znaleźć jakieś uzasadnienie dla typów dynamicznych.
Może chodzi o rozmiar kompilatora/interpretera? Niech mnie ktoś oświeci.

-- 
Arek Paterek

"Arek Paterek" <a.paterek@students.nospam.mimuw.edu.pl> wrote in message
news:asl60i$5nn$1@kenny.mimuw.edu.pl...

> Trudno mi znaleźć jakieś uzasadnienie dla typów dynamicznych.
> Może chodzi o rozmiar kompilatora/interpretera? Niech mnie ktoś oświeci.

Zalety są takie, że w ten sposób można uprawiać w znacznie
milszy sposób to, co C++ oferuje poprzez templaty.

Stach

Krzysztof Stachlewski <kstc@box43.pl> wrote:
>> Trudno mi znaleźć jakieś uzasadnienie dla typów dynamicznych.
>> Może chodzi o rozmiar kompilatora/interpretera? Niech mnie ktoś oświeci.

> Zalety są takie, że w ten sposób można uprawiać w znacznie
> milszy sposób to, co C++ oferuje poprzez templaty.

W Ocamlu i SML-u mam typowanie statyczne i typy polimorficzne.
Jedno się z drugim nie gryzie.

-- 
Arek Paterek

"Arek Paterek" <a.paterek@students.nospam.mimuw.edu.pl> wrote in message
ews:asl9iv$hla$1@kenny.mimuw.edu.pl...
> Krzysztof Stachlewski <kstc@box43.pl> wrote:
> >> Trudno mi znaleźć jakieś uzasadnienie dla typów dynamicznych.
> >> Może chodzi o rozmiar kompilatora/interpretera? Niech mnie ktoś oświeci.
>
> > Zalety są takie, że w ten sposób można uprawiać w znacznie
> > milszy sposób to, co C++ oferuje poprzez templaty.
>
> W Ocamlu i SML-u mam typowanie statyczne i typy polimorficzne.
> Jedno się z drugim nie gryzie.

Przyznam, że tych języków akurat nie znam.
Jak się te typy polimorficzne objawiają?

Stach

"Arek Paterek" <a.paterek@students.nospam.mimuw.edu.pl> wrote:

> Trudno mi znaleźć jakieś uzasadnienie dla typów dynamicznych.
> Może chodzi o rozmiar kompilatora/interpretera? Niech mnie ktoś oświeci.

Powodow jest sporo. Moze kiedy bede mial wiecej czasu napisze...


Tymczasem cytuje dsisiejszy referacik, mojego ulubionego postera - Erik'a
Naggum'a, ktory porusza pewien (dosc waski) aspekt systemu typow (nie wazne
w tym momencie, czy ma racje, czy nie ;-)):


***
* "marcel haesok" <novuriche@attbi.com>
| I was reading C# book by Jeffery Richter. Quote: "Delegates ensure that
| the callback method is type-safe (in keeping with one of the most
| important goals of the DOTNET Framework)"

  This is a peculiar case of post hoc, ergo propter hoc argumentation.
  It is not type-safe /because/ of the delegates.  The delegates have been
  designed this way because the language implements type-safety that way.

| which seems to suggest that "type-safety" is a big issue in real
| programming world.

  It is.  But just like the most dangerous man in the world has decided to
  scare almost 300 million people out of their wits in the name of national
  security and safety, stripping them of freedoms and rights at a pace that
  rivals the enemy back when another president defined the four freedoms in
  response to not dissimilar threats 60 years earlier, the concept of "type-
  safety" can also be thought of in terms of the freedoms you give up, or in
  terms of the differences in implementation.  Where one president promises
  his people freedom of speech and freedom from fear in response to threats
  (very much like Lisp offers freedom of expression when solving the problem
  of type safety in response to dangerous program errors), another clamps
  down on the freedom of expression and severely limits what the population
  may say and offers them fear in response to threats (very much like C++ is
  extremely restricting and has its users live in perennial fear of abuse of
  the necessary type-casting operators).

  It should be obvious from the above that it is not the threat itself that
  defines the response, but the "personality" of the language (president).
  The idiot will cave in to the fear and cannot see other solutions than to
  abridge the freedoms of those he obviously believes he provides "safety"
  in so doing.  The intelligent will transcend the fear and determine the
  most pacifying strategy, the one showing the most strength and power and
  understanding of the threat involved, and then take advantage of it.

| Lisp, on the other hand, from the readings I've done here, seems noted
| for its "dynamism" of type.  IE, "type-versatility" of some sort.......

  It is in fact your understanding of "type safety" that is so limited that
  you are not even aware of it.  Please consider a brief study of logic so
  you avoid committing so many annoying fallacies.

  Some languages are "statically typed", which means that the /compiler/ is
  the last element of the entire production line from programmer to system
  execution of the binary that knows the type of anything -- the execution
  environment deals only with bits that have no type at all.  (Recall that
  a bit is a bit is a bit (not unlike a rose), but what it means depends on
  what the observer wants it to mean.)  If you want type safety in a system
  where the compiler is the last to know, you must ensure that the compiler
  does indeed know, which is an incredibly complex task.  Some languages
  are therefore "dynamically typed", which means that the type information
  /does not evaporate/ during processing.  Think of compilation as cooking.
  Dynamic typing means the steak is juicy and still a little red, like red
  meat is supposed to be.  Static typing means you burnt it to a crisp.
  Dynamic typing means that the /object/ carries the type information.
  Static typing means that storage container carries it and the object
  inside it has lost its type information.

  Some people, when they look at dynamically typed languages from the
  statically typed language vantage point, seem to believe that since the
  storage containers are no longer marked and the compiler cannot ensure
  that only the appropriate kinds of objects are put into them, all hell
  must break loose.  This despite the glaring fact that "object-oriented"
  programming in these languages introduce some measure of run-time type
  information.  I have a hard time actually imagining what went wrong with
  people who think this way.  It is so short-sighted, so devoid of any
  thinking skills, so utterly /absent/ of intelligence, that one can only
  marvel at the ability of the human species to produce this kind of people
  and yet not destroy itself.

  Just because you do not know does not mean that you can draw any form of
  useful conclusions about that which you do not know.  I wonder why this
  is not drilled into the heads of people in kindergarten.  In a dynamically
  typed language, the storage containers are much more generic than the
  storage containers in the statically typed languages.  You do not have to
  re-introduce the type information to the compiler when you pick an item
  out of a collection in a properly designed language!  The object already
  carries type information around with it.  Storage containers in Lisp can
  hold objects of any type.  The notion that a container for type T1 can
  hold an object of type T2 is pretty fundamental to the "object-oriented"
  crowd, yet when it comes to actually implementing it fully, they acquire
  an amazing array of delusions about efficiency which they either ignored
  or did not even consider when they were talking their heads off about the
  amazing power of object-orientation, possibly because their understanding
  of "object-orientation" is based in "encapsulation" and "inheritance" and
  /not/ based on type-specific discrimination, which is far more important.

  For some readers, there is evidently a /qualitative/ difference between
  addition of numbers of various types and sending "messages" to objects of
  various genealogy from a common ancestor.  It appears to me that the only
  cause for this rather amazing improvidence is the misguided notion that
  it cannot be a "class" (or type) unless it stores some data in a
  container.
  Thus an /integer/ cannot be a class, functions are not defined on
  /numbers/ because the "number" is not a structure that contains a virtual
  function pointer table.  Instead of thinking about types and functions on
  types, the inverse notion that the type owns the function cannot but cause
  the most heinous malabstraction.

| Is LISP type-safe?

  Suppose I argue that the core purpose of the family is to ensure that the
  offspring can grow up in safety and comfort and that the core purpose of
  society is to enable families to provide such measures to their offspring,
  which is a brief summary of the Republican position.  Suppose I wish to
  /implement/ this by extending the embrace of the familty to the entire
  popularion and therefore secure the state-supplied safety and comfort
  through state ownership of all means of production, which is a brief
  summary of the Communist position.  Are Republicans Communists?

  If the only way you can imagine type safety is through state control and
  loss of freedom, then you will have to conclude that the implementation
  thereof does not matter, and since all political schools of thought have
  been concerned with the physical and extended safety of the population
  (sometimes through exclusivity as to what constitutes the "population"),
  there can be no difference between them.  If, however, you aim for a much
  more abstract understanding of "safety" and grasp that it can be taken
  care of at a different level than controlling all people (or objects), by
  letting individual people (objects) remain free to be what they want, the
  world suddenly looks very different.  In a world where people believe that
  only control over other people can produce safety, you get a suspicious
  lot who are far from safe, but instead fear those they cannot control (as
  happened in other countries that tried GWB's censorship and surveillance
  methods).  In a world where people trust that those who violate contracts
  (both social and legal) can be punished and damages repaid, the need for
  individual suspicion and fear has no place.  Just as the right to bear
  arms was a necessity at a time when the police could scarcely care less
  (even if they had had the resources) and the gun control crowds primarily
  wanted to disarm the lower classes for fear of armed uprising, institution
  of a /working/ police force that the population actually trusts to protect
  them obviates the need for personal armories, a programming language that
  provides /no/ safety infrastructure, body (core) dumps in response to any
  violation, and a direct threat to anyone who carelessly trusts a stranger,
  /should/ have been obsoleted by a language that offers an infrastructure
  that maintains security and trustworthiness.

  Static typing in programming languages is closely akin to the need to bear
  arms and the purported need to do all this anal compile-time checking is
  precisely to keep the lower classes in check, the uneducated hoodlums who
  program for food and wipe your windshield for cash and whose code more
  likely than not will do something you would rather it refrain from.

  Dynamic typing in programming languages means you can trust even code that
  you would not in the static typing world, because it is so much harder to
  lie successfully.  In the static typing world, you need someone else (the
  compiler) to tell you that the code you talk to is OK before you can trust
  the /data/ it gives you, and some of the most insidious backstabbers you
  can think of imagine some draconian measure like "Palladium" because they
  are unable to escape the confines of their mental models, which produced
  the virus vehicles they think they can halt by running them off the road,
  and it all goes downhill from there.

  The moral of this story that I want you to take with you is that there are
  more /times/ to get type safety than compile-time.  It is in fact a /lot/
  easier to get true type safety if you do /not/ do it at compile-time, but
  people who are massively inept at programming think that if they can catch
  some bugs at compile-time, that somehow makes all the remaining bugs less
  important and hard to catch.  This is in fact wrong.  Empirically, people
  who believe their compilers will catch bugs for them because it enforces a
  ridiculously irrelevant aspect of the task of programming, produce /more/
  bugs than people who do their testing right and do not believe in a class
  society for bugs (such that they can ignore or repress some bugs).

--
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

***

mp

In article <asvk2c$dga$1@news.tpi.pl>, Michal Przybylek wrote:
> Tymczasem cytuje dsisiejszy referacik, mojego ulubionego postera - Erik'a
> Naggum'a, ktory porusza pewien (dosc waski) aspekt systemu typow (nie wazne
> w tym momencie, czy ma racje, czy nie ;-)):
[CIACH]

Ta grupa nalezy do hierarchi pl.*. I prosiłbym tego się trzymać. Jak
ktoś będzie chciał, to znajdzie sobie post na innej grupie. Tutaj
wystarczyłby jakiś link. Szczególnie, że to był dość długi artykuł.

Pozdrowienia,
        Jacek