-
11. Data: 2012-05-09 21:07:03
Temat: Re: 'abstrakcje' a zwartosc
Od: "R.e.m.e.K" <g...@d...null>
Dnia Wed, 9 May 2012 17:47:36 +0000 (UTC), f...@g...pl napisał(a):
> i nie jest to jakas specjalna abstrakcja) - mi chodzi
> o jakies wieksze oszczednosi/abstrakcje ogolnie skracajace
> 'zwykle' kody
Np. generyki
--
pozdro
R.e.m.e.K
-
12. Data: 2012-05-09 21:30:27
Temat: Re: 'abstrakcje' a zwartosc
Od: " " <f...@g...pl>
R.e.m.e.K <g...@d...null> napisał(a):
> Dnia Wed, 9 May 2012 17:47:36 +0000 (UTC), f...@g...pl napisaĹ(a):
>
> > i nie jest to jakas specjalna abstrakcja) - mi chodzi
> > o jakies wieksze oszczednosi/abstrakcje ogolnie skracajace
> > 'zwykle' kody
>
> Np. generyki
>
imo raczej znikoma przydatnosc - przypadkow fragmentow
kodow ktore to by moglo skrocic jest chyba jeszcze mniej
niz w przypadku definiowanych operatorow dla vektorow i
macierzy (mi w zyciu nie trafil sie przypadek w ktorym
moglyby przydac mi sie owe generyki)
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
-
13. Data: 2012-05-09 22:21:49
Temat: Re: 'abstrakcje' a zwartosc
Od: " M.M." <m...@g...pl>
<f...@g...pl> napisał(a):
> R.e.m.e.K <g...@d...null> napisał(a):
>
> > Dnia Wed, 9 May 2012 17:47:36 +0000 (UTC), f...@g...pl napisaĹ(a):
> >
> > > i nie jest to jakas specjalna abstrakcja) - mi chodzi
> > > o jakies wieksze oszczednosi/abstrakcje ogolnie skracajace
> > > 'zwykle' kody
> >
> > Np. generyki
> >
>
> imo raczej znikoma przydatnosc - przypadkow fragmentow
> kodow ktore to by moglo skrocic jest chyba jeszcze mniej
> niz w przypadku definiowanych operatorow dla vektorow i
> macierzy (mi w zyciu nie trafil sie przypadek w ktorym
> moglyby przydac mi sie owe generyki)
No ale co jeszcze może skracać kod i jeszcze poprawiać jego
czytelność?
Biblioteki tak na pewno robią - ale nie chodzi Ci o to.
foreach vs for - też nie chodzi o to bo to tylko mniej znaków.
Może szukasz czegoś takiego jak octave? W octave np. metodę
najmniejszych kwadratów zapisuje się bardzo zwięźle. W octave
jeden znaczek to cała macierz, czasami nie trzeba używać ani
klamerek do wskazywania indeksu w macierzy, ani pętli pętli.
Pozdrawiam
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
-
14. Data: 2012-05-09 22:26:13
Temat: Re: 'abstrakcje' a zwartosc
Od: "t.o." <r...@w...pl>
Użytkownik <f...@g...pl> napisał w wiadomości
news:joegkj$1dp$1@inews.gazeta.pl...
> R.e.m.e.K <g...@d...null> napisał(a):
>
>> Dnia Wed, 9 May 2012 17:47:36 +0000 (UTC), f...@g...pl
>> napisaĹ(a):
>>
>> > i nie jest to jakas specjalna abstrakcja) - mi chodzi
>> > o jakies wieksze oszczednosi/abstrakcje ogolnie skracajace
>> > 'zwykle' kody
>>
>> Np. generyki
>>
>
> imo raczej znikoma przydatnosc - przypadkow fragmentow
> kodow ktore to by moglo skrocic jest chyba jeszcze mniej
> niz w przypadku definiowanych operatorow dla vektorow i
> macierzy (mi w zyciu nie trafil sie przypadek w ktorym
> moglyby przydac mi sie owe generyki)
>
chłopie, Ty chyba nic w życiu nie napisałeś jeżeli wygłaszasz takie opinie
tx
-
15. Data: 2012-05-10 00:38:08
Temat: Re: 'abstrakcje' a zwartosc
Od: "R.e.m.e.K" <g...@d...null>
Dnia Wed, 9 May 2012 19:30:27 +0000 (UTC), f...@g...pl napisał(a):
>> Np. generyki
>>
>
> imo raczej znikoma przydatnosc - przypadkow fragmentow
> kodow ktore to by moglo skrocic jest chyba jeszcze mniej
> niz w przypadku definiowanych operatorow dla vektorow i
> macierzy (mi w zyciu nie trafil sie przypadek w ktorym
> moglyby przydac mi sie owe generyki)
Jak w koncu z tym swoim programowaniem wygrzebiesz sie z pierwszej polowy
lat '90 to odkryjesz jak przyjemne moze byc uzywanie nowoczesnych jezykow i
narzedzi. Poki co strzelasz sobie w stope kazdym komentarzem.
--
pozdro
R.e.m.e.K
-
16. Data: 2012-05-10 02:13:56
Temat: Re: 'abstrakcje' a zwartosc
Od: Andrzej Jarzabek <a...@g...com>
On 09/05/2012 16:30, zażółcony wrote:
>
> Imo to nie tak ...
> Tworzenie abstrakcji to nie żadne czary-mary, które sprawiają,
> że w jednej linijce kodu implementujesz wiele wymagań użytkownika.
> Jest wiele wymagań - będzie dużo kodu. Chyba że ...
Akurat języki się potrafić dość znacznie tym, jak zwięzły kod można w
nich pisać, tylko że nie ma to wiele wspólnego ani z wysokopoziomowością
języka, ani z abstrakcją w kodzie.
Java na przykład jest językiem wysokopoziomowym, a jest mocno rozwlekła.
> Chyba że są to wymagania 'powszechne' a nie specyficzne, zwiazane
> n. z modą na to, by okienka wyglądały tak samo. Wtedy ktoś Ci
> to zrobi i powie, jak masz to użyć.
Ale też chyba nie jest takie rzadkie, żeby abstrakcja redukowała ilośc
kodu przez unikanie zduplikowania. Tyle że z drugiej strony ta sama
abstrakcja potrafi też zwiększyć ogólną ilość kodu, i według mnie
średnio raczej zwiększa, niż zmniejsza.
Zwięzłość abstrakcji polega na czym innym: nie, że ogólnie piszesz mniej
linijek kodu, tylko że dana treść jest wyrażona mniejszą ilością linijek
kodu. Owszem, to dlatego, że te linijki wołają kod napisany gdzie
indziej, ale właśnie o to chodzi, że zawartość tego kodu cię w danym
momencie nie obchodzi. Jeśli masz na przykład pętlę, w której pobierasz
Komunikaty ze ZrodloKomunikatow i przekazujesz do
PrzetwarzaczKomunikatow, to masz tę logikę wyrażoną w trzech linijkach.
Bez abstrakcji miałbyś w tej pętli np. wywołania bazodanowe, mapowanie
komunikatów, reguły przetwarzania i co tam jeszcze - dajmy na to
kilkaset linijek. Trzy linijki są bardziej zwięzłe niż kilkaset CBDU.
-
17. Data: 2012-05-10 07:40:58
Temat: Re: 'abstrakcje' a zwartosc
Od: " " <f...@g...pl>
M.M. <m...@g...pl> napisał(a):
> <f...@g...pl> napisał(a):
>
> > R.e.m.e.K <g...@d...null> napisał(a):
> >
> > > Dnia Wed, 9 May 2012 17:47:36 +0000 (UTC), f...@g...pl napisaĹ
(a)
> :
> > >
> > > > i nie jest to jakas specjalna abstrakcja) - mi chodzi
> > > > o jakies wieksze oszczednosi/abstrakcje ogolnie skracajace
> > > > 'zwykle' kody
> > >
> > > Np. generyki
> > >
> >
> > imo raczej znikoma przydatnosc - przypadkow fragmentow
> > kodow ktore to by moglo skrocic jest chyba jeszcze mniej
> > niz w przypadku definiowanych operatorow dla vektorow i
> > macierzy (mi w zyciu nie trafil sie przypadek w ktorym
> > moglyby przydac mi sie owe generyki)
>
> No ale co jeszcze może skracać kod i jeszcze poprawiać jego
> czytelność?
>
wydaje sie ze abstrakcyjne wychwycenie jakiejs
przenikajacej kody szablonowosci i poziej jakies krotkie
jej wyrazanie mogloby poskracac/poautomatyzowac kody -
z tym ze poki co jak patrze na kody to taka szablonowosc
jakos nie rzuca sie na oczy , wyglada jakby funkcje w sumie
byly dosyc rozne i malo podobne
> Biblioteki tak na pewno robią - ale nie chodzi Ci o to.
> foreach vs for - też nie chodzi o to bo to tylko mniej znaków.
>
> Może szukasz czegoś takiego jak octave? W octave np. metodę
> najmniejszych kwadratów zapisuje się bardzo zwięźle. W octave
> jeden znaczek to cała macierz, czasami nie trzeba używać ani
> klamerek do wskazywania indeksu w macierzy, ani pętli pętli.
>
> Pozdrawiam
>
>
>
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
-
18. Data: 2012-05-10 07:51:17
Temat: Re: 'abstrakcje' a zwartosc
Od: " M.M." <m...@g...pl>
<f...@g...pl> napisał(a):
> wydaje sie ze abstrakcyjne wychwycenie jakiejs
> przenikajacej kody szablonowosci i poziej jakies krotkie
> jej wyrazanie mogloby poskracac/poautomatyzowac kody -
> z tym ze poki co jak patrze na kody to taka szablonowosc
> jakos nie rzuca sie na oczy , wyglada jakby funkcje w sumie
> byly dosyc rozne i malo podobne
Czy do tego celu nie służą po prostu procedury i dobra parametryzacja?
Pozdrawiam
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
-
19. Data: 2012-05-10 10:56:05
Temat: Re: 'abstrakcje' a zwartosc
Od: zażółcony <r...@c...pl>
W dniu 2012-05-10 02:13, Andrzej Jarzabek pisze:
> On 09/05/2012 16:30, zażółcony wrote:
>>
>> Imo to nie tak ...
>> Tworzenie abstrakcji to nie żadne czary-mary, które sprawiają,
>> że w jednej linijce kodu implementujesz wiele wymagań użytkownika.
>> Jest wiele wymagań - będzie dużo kodu. Chyba że ...
>
> Akurat języki się potrafić dość znacznie tym, jak zwięzły kod można w
> nich pisać, tylko że nie ma to wiele wspólnego ani z wysokopoziomowością
> języka, ani z abstrakcją w kodzie.
>
> Java na przykład jest językiem wysokopoziomowym, a jest mocno rozwlekła.
>
>> Chyba że są to wymagania 'powszechne' a nie specyficzne, zwiazane
>> n. z modą na to, by okienka wyglądały tak samo. Wtedy ktoś Ci
>> to zrobi i powie, jak masz to użyć.
>
> Ale też chyba nie jest takie rzadkie, żeby abstrakcja redukowała ilośc
> kodu przez unikanie zduplikowania. Tyle że z drugiej strony ta sama
> abstrakcja potrafi też zwiększyć ogólną ilość kodu, i według mnie
> średnio raczej zwiększa, niż zmniejsza.
Jest różnie, raz w tę, raz we wtę.
Imo autor wątku zawęził znaczenie/celów stawianych tworzeniu abstrakcji,
zafiksował się na jednym, czyli "zwięzłość kodu". A tych celów/zadań
jest znacznie więcej, wymienię tu dwa, które mi przychodzą do głowy:
1. Podział odpowiedzialności
2. Ochrona kodu przed 'czeskimi' błędami - tak by np. jak najwięcej
błędów było wychwytywanych na etapie kompilacji, a nie w runtimie.
Ad 1.
Podział odpowiedzialności pomiędzy komponenty systemu jest kluczowy
w produkcji złożonego oprogramowania, nad którym np. pracuje wiele
osób. Podział odpowiedzialności/rozdział implementowanych wymagań
pomiędzy komponenty umożliwia z kolei:
- sprawną identyfikację miejsc w kodzie, minimalizację zmian
implementacyjnych, szacowanie ryzyka, ograniczanie ryzyka - kiedy
wymagania się zmieniają (zarządzanie zmianą)
- budowę, zarządzanie, uruchamianie testów jednostkowych
- podział odpowiedzialności wśród ludzi i kontrolę - np. w wydzielonych
podsystemach technicznych maja prawo grzebać tylko niektórzy, jest to
związane z dużym ryzykiem itp itd. Reszta 'klepie' szablonowe procedury
biznesowe
- z tym ostatnim wprost powiązane jest np. zmniejszenie kosztów szkoleń
nowych pracowników, bo nie muszą wiedzieć wszystkiego
- także jest z tym związana łatwiejsza komunikacja programistów z
analitykami/użytkownikami
Ad 2.
Bardzo typowe, czeskie błędy powstają na styku różnych języków
programowania, 'oczywisty' i powszechny przykład: literówki w
zapytaniach SQL schowanych w stringach w językach wyższego poziomu.
Kompilator Javy, choćby się skichał - nie wykryje literówki
w słowie kluczowym "SELECVT". Problem ten rozwiązuje się
na wiele sposobów, np. O/R mapping (cała technologia różnych
abstrakcji), które eliminują konieczność pisania wielu prostych
zapytań i/lub techniki zapisu zapytań SQL za pomocą języka wysokiego
poziomu - patrz np. takie pomysły, jak "Jacle"
http://code.google.com/p/jacle/
Warto zauważyć, że w tym ostatnim przypadku kod wcale nie staje się
zwięźlejszy, a wrecz odwrotnie (BTW. SQL należy do czołówki pod względem
zwięzłości zapisu wymagań.
-
20. Data: 2012-05-10 14:57:07
Temat: Re: 'abstrakcje' a zwartosc
Od: zażółcony <r...@c...pl>
W dniu 2012-05-10 10:56, zażółcony pisze:
> http://code.google.com/p/jacle/
> Warto zauważyć, że w tym ostatnim przypadku kod wcale nie staje się
> zwięźlejszy, a wrecz odwrotnie (BTW. SQL należy do czołówki pod względem
> zwięzłości zapisu wymagań.
E, tu tochę jakby przestrzeliłem w bok z tym przykładem 'jacle',
chodziło bardziej o wysiłki takie, jak tu:
http://www.jroller.com/Solomon/entry/writing_sql_the
_oo_way
Kurcza, była jakaś biblioteka, która to robiła, ale nie mogę znaleźć ...
No ale generalnie ten sam kierunek: tworzenie zapytań sqlo podobnych
z wykorzystaniem składni Java.