From: "yapann" <yapann odwa.pl>
Subject: Re: wątpliwość ad. systemowych przypadków użycia
Użytkownik "radoslaw tereszczuk" <tereszczuk it1.pl> napisał w wiadomości
news:c48d1$46448600
> celem jest produkcja oprogramowania za kture klient zaplaci :O)
celem jest produkcja oprogramowania, za które klient zaplaci i I UTRZYMANIE,
za które klient zaplaci.
> zawsze kazdy przypadek uzycia wiaze sie z wykorzystaniem elementuw
> implementacyjnyh
nie podważam użycia elementów 'implementacyjnych', jeśli nalezy się do
takich obiektów odnieść, tylko fakt opisywania / projektowania rozwiązań.
> a to ze jakas metodologia czegos zabarania to niekoniecznie sensowny powud
'metodologia' (PU) nie zabrania (nie uniemożliwia) - zagadneiniem jest
zastosowanie technologii: przeznaczenie PU: co POWINNA modelować, a czego
nie (w obszarze specyfikacji wymagań systemowych metodą PU)
>> Jesteś pewien, że jest to w _jakimkolwiek_ przypadku pożądane?
> tak
? w jakim?
>> Konsekwencją mieszania tych dówch typów jest stan, gdzie twórca PU
>> narzuca (świadomie lub nie) pewne aspekty projektowe - co ogranicza
>> architekta / kodera.
> to tylko jedna z mozliwosci
hmm ... to AŻ jedna z możliwości.
> pewnei ze analityk nie jest od arhitektury
> ale nie mozna powiedziec zeby przypadki uzycia nie mogly miec z nia nic
> wspulnego
mogą - jeśli się uprzeć, by produkt był słabo rozwijalny, słabo zarządzalny,
słabo modyfikowalny, słabo skalowalny, etc.
From: "Adam Karpierz" <karpierz NOOOOSPAAAAMpython.pl>
Subject: Re: ECLiPSe Prolog na licencji open source
""Piotr Dembiński"" <pdemb gazeta.pl> wrote:
> W przypadku assemblera nie ma takiej możliwości -- dowolny assembler
> przetłumaczy instrukcje zapisane w postaci mnemoników (plus ew. makr)
> zawsze w ten sam sposób. Dlatego właśnie moim zdaniem assembler jest
> językiem maszynowym, nawet jeśli obsługuje makra.
To jednak zbyt abstrakcyjny jezyk.
To sie i tak przeklada na gonitwe elektronow obijajacych sie o
bariery potencjalu w tranzystorach.
Prawdziwy jezyk maszynowy to graf przeplywu elektronow.
AK
From: A.L. <fela 2005.com>
Subject: Re: Koniec Javy?
On Thu, 10 May 2007 16:39:23 +0000 (UTC), Wojciech Muła
<wojciech_mula poczta.null.onet.pl.invalid> wrote:
>Ktos na tej grupie, AFAIR jeden z Adamow, napisal, ze jak cos jest
>wypuszczane na licencji open-source, to znaczy ze produkt przestal
>generowac zyski. Zrodla Javy zostaly otwarte. Czy to koniec, Sun
>postawil krzyzyk?
>
>w.
Wydaje mi sie, o ile wiem, ze Java jako taka nigdy nie przynosila
firmie Sun zysku. Wydaje mi sie, ze jak idzie o "open source" to java
nie jest open source w calym tego slowa znaczeniu, a Sun jest dosyc
malo entuzjastyczny w tej sprawie.
A.L.
From: "Adam Karpierz" <karpierz NOOOOSPAAAAMpython.pl>
Subject: Re: Groovy
"A.L." <fela 2005.com> wrote:
> A okres powodzenia mial, albowiem gdy ow okres powodzenia sie zaczal,
> nie mial zadnego konkurenta.
Kiedys Pan pisal o problemie technicznym typu
duzy image i mala komponentowosc/pliginowatosc.
Ze tez to mialo wplyw.
AK
Rejestracja domen
From: jarekr <jhratajski popraw.literowki.pzcota.otne.pl>
Subject: Re: Do Panow: Przybylka, Maleckiego, Wojewodzkiego
A.L. napisał(a):
>
> Ja twierdze ze nie odzwierciedlaja, z tego samego powodu dla ktorego
> nie mozna napisac programu komputerowego odrozniajadego dobra ksiazake
> od zlej, dobry film od zlego czy dobry samochod od zlego. "Metryki" w
> postaci sredniej dlugosci rozdzialu w ksiazce, dlugosci paragrafu,
> dlugosci zdan i czestosci uzycia slow nic o ksiazce nie mowia - a
> wlasnei takie metryki "jakosci" uzywa zie przy ocenie oprogramwoania.
>
Czasem wystarczy spojrzeć na format okładki.
> Oprogramowanie to produkt inzynierski, taki sam jak samochod i jego
> jakosci nie da sie podsumowac przy pomocy kilku liczb. Ani
> kilkudziesieciu. Gdyby tak bylo, przemysl samochodowy w Detroit nie
> musialby kapitulowac przed Japonczykami.
>
Dom jest podobnego stopnia skomplikowanym produktem ( do tego jeszcze
mniej powtarzalnym ) - a przy każdym głupim kredycie bank wysyła
rzeczoznawcę, który przy użyciu kilku arkuszy excela wystawia
"metryczkę". (i to zarówno jeśli dom jest tylko na papierze, jest
zrobiony do połowy, lub jest dogasającym pogorzeliskiem )
Wszystkie banki w naszym kraju tak robią - zresztą procedura wyceny jest
dość ustandaryzowana i prosta. I faktycznie taka metryczka niewiele mówi
o tym jak w takim domu się będzie mieszkać w szczególności nic o
sąsiadach. A jednak drobny fistaszek tu i tam w tym excelu i 10-100 tys
PLN w jedną lub w drugą stronę idzie. A że jest tych fistaszków sporo -
więc można do nich łatwo nabrać szacunku ;-)
Jakos ten system funkcjonuje i jest komuś potrzebny.
--
http://www.99-bottles-of-beer.net/language-java-866.html
From: "yapann" <yapann odwa.pl>
Subject: wątpliwość ad. systemowych przypadków użycia
mam wątpliwość odnośnie idei systemowych (nie biznesowych) przypadków
użycia:
Otóż generalnie PU służą udokumentowaniu funkcjonalnych wymagań systemowych,
z punktu widzenia użytkownika i pożądanego skutku (CO - a nie JAK (tzw
'czarna skrzynka')).
W książce 'Writing Effective Use Cases' autorstwa A.Cockburn czytam, iż
innym, prawidłowym przeznaczeniem PU jest udokumentowanie projektu systemu
(tzw 'biała skrzynka'): 'team might document the final design with the same
use case form.'
Budzi to moją ogromną wątpliwość o tyle, iż na stronie ibm czytam, że PU
systemowy ma dokumentować zachowanie systemu, nie projektować system:
'System use cases elaborate the system requirements. The purpose of the
system use-case model is to document requirements from a stakeholder's
perspective, not to design how to satisfy the requirements.'
(http://www-128.ibm.com/developerworks/rational/library/apr07/english/).
Jakkolwiek pozornie nie ma problemu (jedno drugiemu nie przeszkadza, niechby
PU były środkiem wyrazu dla różnych perspektyw pewnych rzeczy), to nigdzie
nie ma mowy o tym, że należy wskazać, czy dany PU dokumentuje wymagania
użytkownika (CO), czy też dokumentuje projekt systemu (JAK), co jest
(powinno chyba być) absolutnie rozłączne (???) - brak takiej informacji może
moim zdaniem prowadzić w krzaki. W szczególnośći spotykam się z analitykami
tworzącymi hybryd wymienionych dwóch zastosowań, często nieświadomi tego
faktu, co poważnie podważa w moich oczach użyteczność / zastosowanie
powstałych PU.
Czy ktoś mógłby się wypowiedzieć odnośnie poruszonego przeze mnie problemu
systematyki PU?
From: "Adam Karpierz" <karpierz _NOSPAM_python.pl>
Subject: Re: Groovy
Użytkownik "Aleksander Galicki" <tretete WYTNIJ.gazeta.pl> napisał:
>> No coz. Pan woli.
>> Mnie sie nie chce nic nikomu udowadniac :)
>> Za stary jestem.
>
> Ale wtedy widownia to nalezycie oceni :)
Oh ale Pan trafil !
Najbardziej w d.. w zyciu to mam wlasnie wszelkie widownie
i ich opinie :)
> Cienka to retoryka: zbyc adwersarza porownaniem do radzieckiego
> naukowca. O pchlach nic mi zreszta nie wiadomo. Wole radziecka matematyke.
Nie widzi Pan absurdu w swym 'logicznym' wywodzie o static typing w Pythonie
?
> Zreszta, to dziwne - wycial Pan cytaty, bardzo sensowne,
Nic nie wycinalem.
Nie zwyklem powtarzac bezsensownie cytatow z poprzedneigo postu
> PJE - ktory mowil
> dokladnie to samo co ja: "While Python is more powerful as a language,
> Java
> beats the crap out of it in the area of standards and specifications like
> JDBC, JNDI, and OSGi, to name just a few.[...]
> But when I'm done, my implementation and interfaces are still not a
> standard
> in the Python world. Nobody is going to know about what I did, and the
> next
> guy over is going to either do the same thing I did, or throw together
> their
> own little thing. Individually, perhaps, we are all productive, but our
> collective productivity is lower in the Python community, because we are
> all
> forced to reinvent 'IWheel', up until there's a 'Wheel' implementation in
> the
> standard library"
> Jeszcze raz Pan to wytnie i zignoruje?
Panie Kochany, przestan Pan truc znow o wycinaniu.
Ale merytorycznie.
Eby sie myli (kiedy to Eby pisal ?).
Python ma bindingi do wiekszosci standardow
czy duzych frameworkow komponentowych.
Dojrzale dosc bindingi.
O interfaces to juz nawet nie wspomne.
Zope interfaces od kilku lat juz sa defacto standardem
w powazniejszych aplikacjach pythonowych.
Co wiecej, o ile mnie pamiec nie myli PyProtocols
i zope interfaces sa z soba zgodne.
Po prostu dekoratory w Pythonie (ogolny mechanizm)
na ktorych oparte sa zope interfaces wyparly PyProtocols
(szkoda bo PyPrtocols byly ogolniejsze - tyle ze nieco trudniejsze).
>> Akurat Python jest typowym przykladem: znajdz gotowe
>> To typowy glue language _w zalozeniach_.
>
> Ale w innym jezyku, bo w Pythonie to najczesciej znajdziesz jakies
> niestandardowe, wyciosane na kolanie, rozwiazanie. Do szybkiego hakowania
> to
> OK, ale nie pisania duzego softu.
Panie kochany, Pan widzial Pythona w ogole ? :)
Oczywiscie zalezy _jak_sie pisze.
C++ tez IMHO do pisania duzego softu sie nie nadaje
a jednak. sie w nim pisze mimo ze glownie zle.
> By the way: co sie w Pythonie skleja? Chyba kawalki w C++.. Bo do
> sklejania
> rzeczy ze swiata Javy czy .NET to sie inne rzeczy bardziej nadaja.
> Niestety, ale w swiecie Javy latwiej sie to robi w Groovy, niz w
> Jythonie.
Bzdura.
Robi sie identycznie bo Grovvy to.. taka odmaina Jythona jak
odmiana Javy jest C#
Groovy i Jython maja ten sam binding do Javy i w obu sie robi
to identycznie latwo.
No.. przesadzilbym
Jyton mi sie tutaj batrdziej podoba bo ma scislej o wiele
odseparowane typy Javy od Pythonowych a w Grooviem zbyt to sie
zamazuje.
Glowna zaleta Jythona nad Grovym jest
1. prostrzy 'klej' czyli jezyk
2. wieksza dojrzalosc (pomimo ze Jython jes w wersji beta
od lat ale kto zna Hugunina ten wie ze jego beta o wiele
lepsze niz niejedne 3.56
Glowna zaleta Groviego nad Jythonem jest wbudowany w
jezyk standardowy typechecking (choc nie wiedziec czemu
nei stanardowy - to duzy blad Grooviego).
> W mojej firmie wiekszosc javowcow preferuje Groovy - lepiej dopasowany
> do Javy jako platformy.
> Moze to mniej elegancki jezyk, ale do sklejania zadnej szczegolnej
> elegancji nie potrzeba.
Wlasnie do sklejania _trzeba_ prostoty.
Skrajnej prostoty aby sie nie uczyc nie wiadomo po co "wypasionego"
sklejacza.
Dobry klej jest niewidoczny a nie cieknacy bokami.
Jython ma _tylko_ to potrzeba (pelny binding do Javy i swoje
Pythonowe moduly podstawowe) i nic wiecej.
> Mamy kawalki w Jythonie, ale jak bedzie cos nowego
> sie sklejac, to sie wybierze Groovy, najprawdopodobniej.
Zycze szczescia :)
Nic nie mowie.!
Moze wersja 1.0 jeszcze goraca (luty chyba) jest juz
super stabilna :)
>> W nim wiekszosc jest _gotowe_.
>> Albo wprost (standard lib) albo jako binding do juz gotowego.
>
> Jaka wiekszosc?
> W porownaniu do Javy czy .NET to w Pythonie prawie nic nie ma.
Tu sie Pan zwyczajnie osmieszyl.
W Pythonie _ma_ nic nie byc.
Wlasnie o to chodzi zeby poza podstawowa biblioteka
(IMHO i tak za bardzo rozbudowana _nic nie bylo_) .
> O tym wlasnie pisal PJE, ale Pan to wycial.
(Po raz ostatni Pan prosze o nie trucie bez sensui o wycinaniu)
> Wlasnie dlatego taki typowy biznes nie wybiera Pythona - pisanie softu w
> nim zwykle konczy sie wlasna implementacja IWheel w setkach roznych
> wersji.
> I to ze Python, rzekomo, jest more powerful niczego niestety nie
> zmienia.
> Bo jako _platforma_ jest ubogi.
Nie no Panie Galicki, smiech mnie ogarnia
Niech no Pan wiecej juz lepiej nie pisze na temat Pythona :(
>> W Pytonie _nic_ sie wlasciwie nie pisze ale sie skleja
>> z juz gotowych kawalkow.
>
> Chandlera probowali napisac - jajo wyszlo.
Ze co ? Nie ma juz chandlera ?
> Ale w Google to ponoc pisza w tym - nie sklejaja.
To zle jesli wszytsko pisza od zera.
Tyle ze nei sadze aby zatrudneinie w Google
GvRa bylo po to aby na nowo wymyslac kolo.
To zbyt powaznych czlek na zabawy :).
>> Jak dla mnie to kolejne bzdury.
>> Za duzo 'pary' tam idzie w Pythona aby traktowac w/w powaznie.
>>
>
> Ale co bzdury: Google pisze i w C++ i w Pythonie i w Javie. Ale to
> _baardzo_
> szczegolna firma. Jak im ktos odbierze advertisement to nie zdziwie sie
> jesli
> zdechna w trzy miga. Ale na razie moga pozwolic zatrudniac najlepszych ze
> swiata i Javy i Pythona (i produkowac mase pol-upieczonych pomyslow,
> applikacji i bibliotek, jak dzieci)
Hehe :)
AK
From: Mariusz Lotko <imie.nazwisko wp.pl>
Subject: Re: Do Panow: Przybylka, Maleckiego, Wojewodzkiego
jarekr wrote:
> Mariusz Lotko napisał(a):
>> Przypadek użycia dla trywialnego narzędzia do wychwytywania durnych
>> błędów? Proszę bardzo. Jesteś programistą w firmie X i któregoś pięknego
>> dnia przychodzi do Ciebie szef i mówi: "Alex, team odpowiedzialny za
>> produkt Y nie radzi sobie, od dzisiaj Ty jesteś za ten produkt
>> odpowiedzialny." No więc zaglądasz sobie do kodu Y i patrzysz, że kod
>> jest koszmarny. Są błędy mniejsze i większe, ale jest ich tyle, że po
>> prostu nie sposób nad tym zapanować. I co robisz? Bierzesz narzędzie,
>> które potrafi znaleźć błędy, "które dobry programista znajdzie w 10 min."
>> i puszczasz na takim źródle. Puszczasz tak długo, aż lista błędów
>> zwrócona przez "trywialny program do analizy" jest bliska 0. Wtedy kod
>> jest prawdopodobnie na tyle czytelny, że możesz się zabrać za "poważne
>> błędy", których automat nie wykrył.
>
> Najzabawniejsze, że to przypadek z życia wzięty - z życia Alexa :-)
Ja też tego z księżyca nie wziąłem. Widać taka nasza programistyczna
dola ;-)
--
Mariusz Lotko
From: pdemb gazeta.pl (=?iso-8859-2?q?Piotr_Dembi=F1ski?=)
Subject: Re: czy przypadek =?iso-8859-2?q?u=BFycia?= jest wymaganim
"yapann" <yapann odwa.pl> writes:
> Użytkownik "ToJaJarek" <tojajarek gmail.com> napisał w wiadomości
>
>> Po tzrecie polecam ksiązkę Cocbourna :
> :-) właśnie w niej jest takie sformułowanie, które mi zgrzytło, więc
> zastanawiam się, czy dobrze je czytam:
>
> "If you are writing use cases as requirements, you should keep two
> things in mind. They really are requirements. You shouldn't have to
> convert them into some other form of behavioral requirements."
>
> btw - b. nietrywialna książka, szacuneczek.
Rozumiem. Autor potrafi tworzyć tautologie, czyli nietrywialna.
Kosmetyki naturalne
From: pdemb gazeta.pl (=?iso-8859-2?q?Piotr_Dembi=F1ski?=)
Subject: Re: ECLiPSe Prolog na licencji open source
"radoslaw tereszczuk" <tereszczuk it1.pl> writes:
>> Co do języka maszynowego, to IMO assembler jest maszynowy.
>
> http://pl.wikipedia.org/wiki/J%C4%99zyk_maszynowy
Tak, ale zauważ, że w przypadku kompilatorów i interpreterów języków
programowania, które nie są językami maszynowymi, zawsze istnieje
pewien poziom abstrakcji, który skutkuje w możliwości odmiennego
zinterpretowania lub przetłumaczenia napisanego programu przez różne
interpretery lub kompilatory.
W przypadku assemblera nie ma takiej możliwości -- dowolny assembler
przetłumaczy instrukcje zapisane w postaci mnemoników (plus ew. makr)
zawsze w ten sam sposób. Dlatego właśnie moim zdaniem assembler jest
językiem maszynowym, nawet jeśli obsługuje makra.
--
http://www.piotr.dembiński.prv.pl
From: "yapann" <yapann odwa.pl>
Subject: Re: wątpliwość ad. systemowych przypadków użycia
Użytkownik "Mariusz Lotko" <imie.nazwisko wp.pl> napisał w wiadomości
>> 'team might document the final design with the
> Być może wcale nie chodzi o dokumentowanie _rozwiązań_ projektowych za
> pomocą use-case'ów, a raczej udokumentowanie przypadków użycia, które
> są możliwe w zaprojektowanym systemie.
zapewne, aczkolwiek nadal będzie to ALBO walidacja (czy tam kolejna
iteracja) analizy funkjonalnej i udokumentowanei zmian, ALBO dokumentacja
rozwiązań danego zagadnienia, co należałoby zaznaczyć literalnie, imo. Po
co? A po to na przykład, żeby było przełożenie na testy funkcjonalne i te
pozostałe (niefunkcjonalne, statyczne, i takie tam). Komentarze?
> żeby
> np. tester mógł zaprojektować testy.
From: ethouris <ethouris gmail.com>
Subject: Re: Groovy
On 12 Maj, 01:44, "Adam Karpierz" <karpierz _NOSPAM_python.pl> wrote:
> U=BFytkownik "ethouris" <ethou... gmail.com> napisa=B3 w wiadomo=B6ci
>
> > > PS: Jezykiem beztypowym to jest np Tcl.
> > > Tam wszystko jest stringiem.
> > Bzdura.
>
> > J=EAzyk Tcl jak najbardziej posiada typy (z tym tylko, =BFe w zakresie
> > j=EAzyka nie mo=BFna tworzy=E6 w=B3asnych). Zasada EIAS tak naprawd=EA =
polega
> > tylko na tym, =BFe ka=BFdy obiekt Tcl-owy (a wi=EAc nale=BF=B1cy do jed=
nego z
> > Tcl-owych typ=F3w) jest automatycznie serializowalny, tzn. zawsze mo=BFe
> > by=E6 przekonwertowany na string i odwrotnie.
> > No i oczywi=B6cie nie mo=BFna
> > tych typ=F3w jawnie weryfikowa=E6 w programach.
>
> Taaa, nie moge tworzyc nie moge werifikowac, w ogole ich
> nie widze
> No to gdzie te typy ?
Typy nie powoduj=B1, =BFe mo=BFesz je widzie=E6, tylko =BFe okre=B6lone ope=
racje
r=F3=BFni=B1 si=EA w zale=BFno=B6ci od tego typu. Nikt nie powiedzia=B3, =
=BFe masz
mie=E6 mo=BFliwo=B6=E6 nazwania tych typ=F3w, czy te=BF pobrania z danego o=
biektu
informacji o tym, jakiego ten obiekt jest typu. Proponuj=EA zrobi=E6 sobie
ma=B3=B1 powt=F3rk=EA z podstawowych wiadomo=B6ci o programowaniu.
To tak po pierwsze dla ustalenia uwagi.
> Sektor przestan prosze pierdzielic od rzeczy.
> Typow w Tclu nie ma i nie bylo nigdy.
Troch=EA nie do ko=F1ca.
> W Tclu _wszytsko_ jest stringiem
Obiekty klas zdefiniowanych za pomoc=B1 biblioteki Itcl r=F3wnie=BF?
> i gadanie o jakis
> wewnetrznych optymalizacjach majacych na celu
> poprawe szybkosci swoistego _autointerpretera_
> jakim jest Tcl to jawne wprowadzanie ludzi w blad.
> Nawet te optymalizacyjne zabiegi sa dopiero od Tcl8.0
> a w Tcl7.6 ich jeszcze nie bylo.
Zgadza si=EA, ale to nie zmienia faktu, =BFe s=B1 od 8.0.
> Natomiast Tcl7.6 i 8 sa zgodne w sensie jezyka.
Bzdura. 8.0 jest wstecznie zgodny z 7.6, nic ponad to.
Przyk=B3adowo, w Tcl 7.6 wyra=BFenie expr { "s" =3D=3D "s" } powodowa=B3o
wyj=B1tek. W 8.0 normalnie zwraca true. To ma by=E6 twoim zdaniem zgodno=B6=
=E6
w sensie j=EAzyka?
A w jaki cudowny spos=F3b operator =3D=3D wie, kt=F3r=B1 wersj=EA por=F3wna=
nia ma
wybra=E6 dla argument=F3w, skoro - jak twierdzisz - w Tcl-u nie ma typ=F3w?
Inna sprawa - w jaki spos=F3b komenda incr sprawdza, czy czasem warto=B6=E6
zmiennej do inkrementacji nie jest zmiennoprzecinkowa?
> > Aczkolwiek jest to zupe=B3nie niepotrzebne, bo w Tcl-u si
> > =EA po prostutego nie robi.
>
> Nie robi sie bo sie po prostu nie da.
No fakt, =BFe si=EA nie da, bo nie zrobiono mechanizm=F3w, kt=F3re by na to
pozwala=B3y, tylko pytanie - po co one mia=B3yby istnie=E6.
> Ni ma na czym badac tego typu.
Jest na czym. Na obiektach. Tylko nie ma po co.
Typy s=B1 badane przez operacje wykonywane wewn=EAtrznie. I to wystarczy.
Zawsze mo=BFna z nich skorzysta=E6.
Faktem jest, =BFe je=B6li np. w zmiennej powstanie nagle warto=B6=E6, kt=F3=
ra
mo=BFe by=E6 warto=B6ci=B1 okre=B6lonego typu, to dostaje taki w=B3a=B6nie =
typ. W
zwi=B1zku z tym, warto=B6=E6 0x10 b=EAdzie zawsze typu integer, nawet je=B6=
li
powsta=B3a przez "set x {0x}; append x 10".
Typ nie oznacza jakiego=B6 magicznego identyfikatora przypisanego
okre=B6lonemu obiektowi, tylko charakterystyk=EA sposobu przeprowadzania
na nim operacji lub niemo=BFno=B6ci ich przeprowadzenia.
> > Je=B6li np. potrzebujemy wykona=E6 operacj=EA dodawania na
> > dw=F3ch warto=B6ciach, a jedna z nich jest stringiem nie konwertowalnym=
na
> > liczb=EA, to leci wyj=B1tek (note: odmiennie, ni=BF np. w Perlu, w kt=
=F3rym
> > "jeden" =3D=3D "dwa" zwraca true).
>
> Ta , leci wyjatek bo parserek czyli komenda [expr ]
> nie umie zewaluowac argumentu.
Je=B6li m=F3wimy o takim wyra=BFeniu jak { $p+2 }, to =F3w "parserek"
zadzia=B3a=B3 ju=BF dawno, w momencie gdy ostatni raz nadawano warto=B6=E6
zmennej p. W takim przypadku sprawa jest prosta - pr=F3buje si=EA wykona=E6
operacj=EA + na $p i 2, gdzie $p nie jest typu integer ani float.
> Ten argument jest jednak zwyklym stringiem.
Ten argument jest obiektem Tcl-owym, kt=F3ry co najwy=BFej posiada
zapami=EAtan=B1 ostatni=B1 reprezentacj=EA jako string (bo ma j=B1 ka=BFdy
obiekt). Reprezentacja ta jest jednak produkowana na nowo, je=B6li
zmieniono warto=B6=E6 w spos=F3b zgodny z typem tego obiektu, a nie =BF=B1d=
ano
dotychczas odczytu stringa z tego obiektu (bo i nie zawsze si=EA =BF=B1da:
wyra=BFenie expr nie =BF=B1da, wyra=BFenie [list] r=F3wnie=BF nie =BF=B1da).
> Nie ma tak zadnego tworzenia obiektow typu int long
> string itp.
String jest dla Tcl-a czym=B6 w rodzaju "typu ortogonalnego": mo=BFna nim
reprezentowa=E6 warto=B6=E6 ka=BFdego obiektu Tcl-owego. I poza tym jest je=
den
tylko typ ca=B3kowity (bo nie rozumiem, po co mia=B3oby by=E6 wi=EAcej w
j=EAzyku skryptowym).
> Po prostu jest zwykle parsowanie _stringu_
> Bo w Tcl _wszytsko_ jest stringiem.
Nie jest to ju=BF prawda od Tcl-a 8.0
> > ale i w takim j=EAzyku nie widz=EA koniecznej potrzeby posiadania
> > mo=BFliwo=B6ci sprawdzania typu.
>
> Sektor prestan truc juz bez sensu.
> W jezykach bez statyvznej kontrolo typow trzeba
> _szczegolnie_ o ta kontrole zadbac.
W j=EAzyku bez statycznej kontroli typ=F3w =BFadna kontrola typ=F3w nie ma
sensu. J=EAzyk taki nale=BFy traktowa=E6 tak samo, jak beztypowy. Je=B6li
chcemy wykona=E6 operacj=EA, to wykonujemy j=B1; je=B6li ona mia=B3aby si=
=EA nie
uda=E6, to rzuci wyj=B1tek.
A je=B6li takie regu=B3y j=EAzyka powoduj=B1, =BFe nie da si=EA w nim pisa=
=E6 du=BFych
aplikacji - c=F3=BF, niekt=F3rzy odkryli to ju=BF wiele lat wcze=B6niej.
> Tu masz przyklad z brzegu:
>
> docstring(a=3D"frobination count")
> typechecker(a=3DNumber, b=3DNumber, _return=3DNumber)
> constrain_values(a=3Drange(3,9), b=3D[4,8,12])
> def foo(a, b):
> # the code
I to typechecker(a=3DNumber, b=3DNumber, _return=3DNumber) ma by=E6 lepsze=
od
hipotetycznego takiego podej=B6cia?:
def Number foo( Number a, Number b ):
# the code
Adamie nie roz=B6mieszaj mnie.
R=F3=BFnica nie polega na tym, =BFe ludzie ch=EAtnie u=BFywaj=B1 tylko tego=
, czego
u=BFywa=E6 musz=B1 i u=BFywa si=EA =B3atwo i naturalnie. Czym=B6 takim w=B3=
a=B6nie jest
statyczna kontrola typ=F3w w C++ i niestety to jest jeden z powod=F3w, dla
kt=F3rych C++ zbiera ci=EAgi od zwolennik=F3w od=B6miecania, czy te=BF
rezygnacji w=B3a=B6cicielstwa do obiekt=F3w: T* pisze si=EA =B3atwiej, ni=
=BF
shared_ptr<T>.
Wi=EAc je=B6li chcesz mi powiedzie=E6, =BFe tego typu rzeczy stan=B1 si=EA
kiedykolwiek dominuj=B1c=B1 w =B6wiecie Pythona metod=B1 na weryfikacj=EA t=
yp=F3w,
to jeste=B6 po prostu niepoprawnym optymist=B1.
> > W j=EAzyku skryptowym przyk=B3adowo mog=EA mie=E6
> > "co=B6" pobrane z jakiego=B6 =BCr=F3d=B3a i nie interesuje mnie czy w p=
ostaci
> > liczby ca=B3kowitej, czy stringa, ale interesuje mnie jednak, czy to, co
> > dosta=B3em, to liczba.
> [...]
> > Sprawdzam tylko czy [string is integer $liczba] i to mi
> > wystarczy.
>
> Taaa.
> Czyli sobie zapuszacm znow parserek i sobie patrze czy
> sie wywalil.
Parserek by=B3 tam zapuszczony ju=BF dawno temu. To, co sprawdza [string
is integer], to typ obiektu.
> Jesli sie nei wypierdzielil na [exp $x + 0] to znaczy ze liczba
> No ooo w sumie mozna :)
Tak te=BF, owszem, mo=BFna - chocia=BF stosowa=B3bym to rozwi=B1zanie tylko=
w
razie braku wyboru, czyli gdybym nie mia=B3 [string is integer].
From: "Adam Karpierz" <karpierz NOOOOSPAAAAMpython.pl>
Subject: Re: Koniec Javy?
"Wojciech Mu3a" <wojciech_mula poczta.null.onet.pl.invalid> wrote:
> Ktos na tej grupie, AFAIR jeden z Adamow, napisal, ze jak cos jest
> wypuszczane na licencji open-source, to znaczy ze produkt przestal
> generowac zyski. Zrodla Javy zostaly otwarte. Czy to koniec, Sun
> postawil krzyzyk?
Ja tak napisalem
ale.. to moje prywatne obserwacje :)
Moim zdaniem Javie nic nie grozi bo dawno
osiagnela mase krytyczna ktora ja ochroni.
AK
From: A.L. <fela 2005.com>
Subject: Re: Groovy
On Wed, 9 May 2007 00:47:18 +0200, "Adam Karpierz"
<karpierz _NOSPAM_python.pl> wrote:
>Uzytkownik "A.L." <fela 2005.com> napisal:
>
>> Wie Pan, pan zaczyna juz reagowac, bo ktos sie wyraza
>> niedostatecznie pochlebnie o Panskim ukochanym Pythonie.
>
>Panie Szanowny, mnie totalnie wisi czy ktos
>sie pochlebnie czy niepochlebnie wyraza o Pythonie.
>Niech Pan sobie wyobrazi ze nawet mi bardziej odpowiada
>gdy sie ktos niepochlebnie wyraza i go nie uzywa.
>
>Mnie tylko razi jak ktos tak jak Pan wyciaga
>daleko idace wnioski odnosnie calych USA
>ze swojego malego podworka.
>To jest typowa demagogia.
>
Zgadzam sie. I niech Pan te rade przylozy do siebie, pameitajac ze
moje podworko male, ale od panskiego jakby wieksze.
>> Jak zas idzie o przemysl amerykanski, to pracujac w nim od mniej
>> wiecej 10 lat obawiam sie ze mam wiekszy widok na to co sie stosouje a
>> co sie nei stosuje niz ma Pan.
>
>Ma Pan maly widoczek.
>Jak kazdy z nas.
>Niech Pan nie robi ze swojej lornetki teleskopu.
>Ja ze swojej nie robie.
>
>> P.S. Pythonmem pzrestalem sie interesowac gdy "udoskonalono"
>> go tak aby mozna w nim bylo programwoac funkcyjnie.
>
>Znow Pan wykazuje nieznajomosc Pythona
>Jest dokladnie odwrotnie niz Pan tu mowi :).
>W Pythonie _nie da sie_ programowac funkcyjnie.
>Owszem sa glupie proby ale sa kulawe i tepione przez GvR.
>
>> Python zaczal byc jezykiem Krory Ma Wszystko I Mozna
>>W Nim Robic Cuda Z Klasami. Ja ten
>> proces naztywam "Perlizacja jezyka".
>
>Usmiechnac sie mozna tylko.
>Prosze sie dokladnie zapoznac z Pythonem i jego rozwojem.
>Lub nie: ale wtedy polecam zasade: milczenie niekiedy jest zlotem
>Tyczy ona zarowno technikow jak i profesorow.
Przeciez napisalem ze Pythonep przestalem sie interesowac iles tam lat
temu.
A.L.
Sklep z biżuterią
From: "Aleksander Galicki" <tretete WYTNIJ.gazeta.pl>
Subject: Re: Groovy
Adam Karpierz <karpierz _NOSPAM_python.pl> napisał(a):
> Użytkownik "Aleksander Galicki" <tretete WYTNIJ.gazeta.pl> napisał:
>
> > Co ciekawe: to juz bylo przerabiane, na Smalltalku. Przy tym Smalltalk byl
> > znacznie popularniejszy niz Python i Ruby kiedykolwiek beda. I sporo
> > duzych
> > aplikacji w tym powstalo.
>
> Przeczy temu historia Simuli
> Jako jezyk stattycznie typowany i to ze szczelnym systemem typow
> upadl na rzecz Smalltalka i chorego dziurawegow sensie typow C
> i beztypia Tcl.
> Innym przykladem jest Eiffel.
> W swoim czasie sztandarowy jezyk modern OOP.
> Wzor !
> Statyczny system typow. Ba ! Rygorystyczny DbC
> No i upadl na rzecz jakiegos 'beztypowego' VB.
>
> Rowniez Pascal przegral z beztypim xBasem wszelkim chocby.
W ten sposob do zadnych wnioskow nie dojdziemy zupelnie. Simula i Eiffel
nigdy nie byly mainstream. Smalltalk - byl. Sam fakt statycznego czy
dynamicznego typowania nigdy nie byl argumentem ostatecznym - Smalltalk byl
przeciez po Algolu. Niemniej - srodowisko Smalltalka przeimigrowalo do Javy,
a Microsoft migruje z beztypowego VB do C#. Trend jest taki: silne i
statyczne typowanie.
A.
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
From: Piotr Kobzda <pikob gazeta.pl>
Subject: Re: Groovy
Seweryn Habdank-Wojewódzki wrote:
> To dobrze, że pytają. Potem już nie będą pytać, a człowiek będzie się o to
> denerwował, bo bez pytania zrobią co uznają za stosowane - np. przetną ojcu
> przewody ;-).
Pozostaje jednak wciąż pytanie bez odpowiedzi, jak? Prąd pokopie, tak,
czy siak... No chyba, że przewidzę to w swoim policy-file'u:
grant signedBy "myfamily" {
permission java.security.AllPermission;
};
;-)
>
>> Podobnie oszukuje kompilator, tyle, że oszustwo w przypadku binariów C++
>> najczęściej przechodzi płazem.
>
> Możesz to rozwinąć?
Ale co tu jeszcze rozwijać? W przypadku C++ #definem "oszukany" został
kompilator. Poinformowałeś go, że binara, do których kompilowany kod
się odwoła, to obiekty z polami public, a prawda jest inna. Podobnie
możesz zrobić z Javą, czyli zastąpić prawdziwą postać klas z runtime,
"oszukaną" ich wersją i skompilować swój kod. (BTW -- nie potrzeba do
nawet sztuczek w postaci sed'a, wystarczy prościutka transformacja
bajtkodu).
Wtedy zarówno kompilat z C++, jak i Javy nie pasuje do właściwego kodu
binarnego, do którego się odwołuje.
Z tą różnicą, że ten Javowy z oryginalną bibloteką, (nie)stety, ale
działać nie będzie.
>
>> A no widzisz, po to właśnie jest cała ta ochrona kodu w Javie, aby nawet
>> jeśli ktoś się uprze i napisze, jak to nazwałeś "badziewie", to i tak ja
>> mogę być bezpieczny, że nie ma dostępu do chronionych spraw mojego kodu,
>> choćby i tylko w opcode-ach pisał.
>
> Czyli? Odpala w swoim wnętrzu druga JVM? Kiedy dochodzi do wniosku, że kod
> jest ok? Jak przekazuje informacje pomiędzy Twoim kodem, a kodem obcym?
Nie ma żadnej drugiej JVMy, to wszystko jest w jednej, wymaga tego
specyfikacja języka. Wystarczy poczytać, pokazałem już gdzie. Jaki
sens widzisz w tym, abym to tu wyłuszczał?
piotr
From: Wojciech =?iso-8859-1?Q?Mu=B3a?=
Subject: Re: ECLiPSe Prolog na licencji open source
Adam Karpierz wrote:
> _Maszynowym_ ? Chyba przesadzasz.
> A nawet zdrowo.
Asemblery maja swoja nisze w niszy. ;)
w.
From: "Adam Karpierz" <karpierz NOOOOSPAAAAMpython.pl>
Subject: Re: Bookstore
"A.L." <fela 2005.com> wrote:
>W zasadzie wojny jezykowe mnie nie interesuja, albowiem jezyki sa
> zupelnie niewazne - wazne jest srodowisko, frameworks i biblioteki.
No i wlasnie w nich Python nie jest slaby.
> Jezeli Python bedzie mial funkcjonalnosc taka jak J2EE albo lepsza, to
> ewentualnie sie nim zaciekawie. Poko co, odkrywanie kola jest
> kosztowne.
Tak tak. Wie Pan J2EE to ciezko dorownac.
Szkoda Pan czasu na Pythona czy inne takie.
> Miara popularnosci jezykow (kiepska bo kiepska, ale OK) jest dla mnie
> wizyta w bookstorze. Ksiegarnie zamawiaja ksiazki stosujac dosyc
BTW: Jakie ksiazki do Groviego Pan widzial ? Chetnie kupie.
Sie znow usmialem.
Panie Andrzeju jets lepsza (i rzeczywista) miara
Ilosc ofert pracy.
Oczywiscie ona nie swiadczy o jakosci jezyka
ale jak najbardziej o jego rzeczywistej popularnosci
na rynku.
Ja na razie widzialem _jedna_ oferte pracy dla programisty
Grooviego.
Pan naprawde powinien sie wysilic w ocenie innych.
Pan to robi zbyt prymitywnie, bo przyjal ze ja sie
klopocze rozwojem Grooviego
Ja sie natomiast z tego ciesze bo przeciez
Groovy to nieco spieprzony ale zywcem Python !
Wiec Pania starania 'ozlocenia' niestabilnego swiezego
jak budyn Grooviego mnie tylko smiesza.
Obserwuje tylko jak obaj z Panem Galickim popieracie cos
co u innych tepicie i wysmiewacie:
owczy ped za czyms nowym niesprawdzonym.
Przeczycie samym sobie.
AK
From: pdemb gazeta.pl (=?iso-8859-2?q?Piotr_Dembi=F1ski?=)
Subject: Re: Do czego =?iso-8859-2?q?por=F3wna=E6_konstrukcj=EA_du=BFego?= systemu informatycznego
DarekM <darekm emadar.com> writes:
>>> Pytanie było o proces tworzenia a nie używania. A nawet jeżeli to
>>> należy porównywać używanie z zamieszkiwaniem. Też wiele analogii
>>> można znaleźć.
>> OIDP dziedziną nauki traktującą o systemach w sposób niezależny
>> natury i przeznaczenia tych systemów jest teoria systemów. Czyli
>> zarówno systemy miejskie, jak i systemy komputerowe można
>> rozpatrywać w kategoriach teorii systemów, a w konstrukcji oraz
>> konserwacji tych systemów stosować zdobycze inżynierii systemów.
>
> No i ...
> Tak, istnieje taka nauka. Tylko co z tego wynika dla pytacza. Same
> osiągnięcia są dosyć dyskusyjne. Przyjmując jednak że są całkowicie
> prawdziwe to pewnie są tak użyteczne jak prawo Ohma przy
> konstruowaniu telewizora a prawa Newtona do budowy dźwigu. Po drugie
> przypuszczam że większościowym beneficjentem byłaby sama teoria
> systemów a nie rozwiązanie problemu, tzn. na podstawie
> przeprowadzonych działań można by coś nieco wnieść do teorii,
> w drugą stronę transfer wiedzy jakoś wydaje mi się mało
> prawdopodobny. Może jedynie terminologia była by pomocna, o ile
> pytacz nie dysponuje własną systematyką.
Jest jeszcze teoria analogii. ZTCW to teoria analogii zajmuje się
m.in. możliwościami symulowania jednych zjawisk przy pomocy innych,
posiadających właściwości na określonym poziomie abstrakcji
analogiczne.
--
http://www.piotr.dembiński.prv.pl
Biżuteria artystyczna
From: "yapann" <yapann odwa.pl>
Subject: Re: wątpliwość ad. systemowych przypadków użycia
Użytkownik "Mariusz Lotko" <imie.nazwisko wp.pl> napisał w wiadomości
news:f2bn06
> Tak. Właśnie po to, żeby tester miał odniesienie do rzeczywistego
> przypadku
> użycia, tzn. takiego z jakim będzie pracował użytkownik, a nie takiego
> niedopracowanego z początku zastanawiania się "co to my chcemy zrobić".
nie znajduję w tym odpowiedzi na zacytowane przez ciebie moje pytanie/a, być
może będe musiała sprecyzować je inaczej. Natomiast poproszę o rozwinięcie
tego, co napisałeś, gdyż co rozumiem dotąd z tego, to truizm, iż PU powinien
być aktualny i wystarczająco szczegółowy, by służył za podstawę miarodajnego
testu.
Innymi słowy nie zajmujemy się tym , czy PU jest 'rzeczywisty'
(świeży/kompletny/ukończony/odzwierciedla docelowe wymaganie) - w
postawionym przeze mnie problemie istotne jest to, że PU jako dokument
wymagań f. będzie podstawą do testy systemowego (/ akceptacyjnego), podczas
gdy PU jako dokument rozwiązań byłby podstawą dla wytworzenia jakiegoś testu
rozwiązania (zapewne typu biała-skrzynka), i nalezy to literalnie
rozdzielić, nazwać i nie mieszać pod żadnym pozorem, ale może ja źle
rozumuję?
(że nie wspomnę poprzednio wypowiedzianej wątpliwości - jaki niby test mam
utworzyć na podstawie PU dokumentującego zarówno funkjonalność jak i
rozwiązania?)
ps:
Może się mylę, ale jeśli to, co chcemy zrobić zmienia się po zrobieniu tego,
znaczy że robimy coś innego. Wymaganie nie powinno ulec zmianie z powodu
jego realizacji (bądź powinno ulec walidacji w iteracyjnym procesie).