czego nie lubicie w perlu?
hubert depesz lubaczewski - 05-03-2007 00:01
czego nie lubicie w perlu?
pewien koleś ostatnio napisał, że aby wiedzieć co sie używa i czemu
trzeba umiec podać 5 rzeczy których sie nienawidzi w używanym języku.
(http://use.perl.org/~brian_d_foy/jou...2556?from=rss).
możecie napisać co was denerwuje w perlu?
mnie:
1. stricty są domyślnie wyłączone. powinny być domyślnie włączone z możliwością
(albo i nie) wyłączenia.
2. mylące prototypy. nie służą do tego do czego się myśli, że mają służyć. a
nie ma takich prawdziwych - np. z typowaniem.
3. potężny, ale wkurzający w obłudze debugger
4. zmienne $|, $$ (no ta akurat najmniej), $/, $?, $@ itd. ja wiem, że
jest 'use English', ale czemu nie jest tak domyślnie? nic to nie
kosztuje!
5. "frameworki obiektowe". spiffy, class-insideout i inne. a i tak da
się uzyskać zmiennych czy metod prywatnych (są jakieś objeścia - jak
chociażby 'my sub ' w spiffy'm, ale ani to ładne ani efektywne.
depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
Adam Osuchowski - 05-03-2007 00:01
hubert depesz lubaczewski wrote:
> możecie napisać co was denerwuje w perlu?
Moje kamyczki do tego ogródka:
1. To, że po if/while/for/foreach jest wymagany blok nawet jeśli zawiera
pojedynczą instrukcję (choć wiem, że prawdopodobnie jest to wymuszone ze
względu na jednoznaczność składni).
2. Wymóg stosowania my() do zmiennych lokalanych wewnątrz bloków. Zamiast
tego prostsza by była jakaś pragma ustawiająca, że domyślnie zmienne bez
pełnego kwalifikatora pakietu byłyby traktowane jak zmienne leksykalne
(wiem, że jestem leniem i nie chce mi się pisać za każdym razem tego
,,my'' ale Larry podobno też jest ;-)).
3. Brak możliwości nazywania parametrów formalnych funkcji.
4. To samo co u Ciebie w punkcie 5. Jeśli już w założeniu języka miało
nie być ścisłego podejścia obiektowego to po co dorabiać kulawą
funkcjonalność zewnętrznymi modułami.
5. Dość bałaganiarski XS. W zasadzie to inne języki mają elegantsze API
do C (choć spotkałem się też z dokładnie przeciwnymi opiniami).
6. To, że wciąż nie ma kompletnego i stabilnego Perla 6, który by rozwiązał
wiele z moich obecnych bolączek, a prace nad nim trwają i trwają i końca
nie widać (to w zasadzie jest zarzut nie do samego języka ale do
developerów).
Pewnie by się znalazło jeszcze parę pomniejszych rzeczy które mnie
denerwują, ale to te które przyszły mi do głowy na poczekaniu.
Vava - 05-03-2007 00:01
On Sun, 04 Mar 2007 18:54:17 +0100, hubert depesz lubaczewski
<depesz@depesz.com> wrote:
> pewien koleś ostatnio napisał, że aby wiedzieć co sie używa i czemu
> trzeba umiec podać 5 rzeczy których sie nienawidzi w używanym języku.
> (http://use.perl.org/~brian_d_foy/jou...2556?from=rss).
>
> możecie napisać co was denerwuje w perlu?
>
> mnie:
> 1. stricty są domyślnie wyłączone. powinny być domyślnie włączone z
> możliwością
> (albo i nie) wyłączenia.
Eeee.. To byśmy mieli Pythona ;-P
Gdyby stricty były defaultowo włączone, to tworzenie czy to
jednolinijkowców, czy krótkich skryptów do rozwiązania konkretnej sytuacji
było by upierdliwe... Co z problem zrobić sobie szablon w ulubionym
edytorze?
> 2. mylące prototypy. nie służą do tego do czego się myśli, że mają
> służyć. a
> nie ma takich prawdziwych - np. z typowaniem.
>3. potężny, ale wkurzający w obłudze debugger
No tego to nie rozumiem. Dostałeś z perlem debugger i się wściekasz? Wiele
języków tego nie daje...
Są wygodne (zarówno tekstowe, jak i graficzne), darmowe debuggery pod
większość platform...
> 4. zmienne $|, $$ (no ta akurat najmniej), $/, $?, $@ itd. ja wiem, że
> jest 'use English', ale czemu nie jest tak domyślnie? nic to nie
> kosztuje!
Mało kto wpadłby na pomysł nazywania własnych zmiennych $##$% (a jeśli, to
sam jest sobie winien).
Ja tam wolę zajrzeć do perlvar, jak potrzebuję jakiejś mniej popularnej
zmiennej wbudowanej, niż wkuwać na pamięć wszystkie odpowiedniki z
English, lub zerkać tam co chwilę, by przypadkiem nie stworzyć własnej
zmiennej $NR, cy cuś...
> 5. "frameworki obiektowe". spiffy, class-insideout i inne. a i tak da
> się uzyskać zmiennych czy metod prywatnych (są jakieś objeścia - jak
> chociażby 'my sub ' w spiffy'm, ale ani to ładne ani efektywne.
Dość dobrą prywatność masz w inside-out.
A po co lepsza? Mi się podoba perlowe założenie, że do czyjegoś domu nie
wchodzę nieproszony nie dlatego, że boję się, że właściciel będzie do mnie
strzelał, a dlatego, że jestem tak wychowany ;-)
A swoją drogą widziałem już #declare private public ;-)
A co mi się nie podoba?
1. Zbytnia niskopoziomowość obsługi wątków, przez co trzeba pilnować, by
kod był thread safe. Co gorsza to wymusza przekładania nogi za głowę przy
obsłudze DBI, czy Tk, które threadsafe nie są...
2. Wrzucenie w core (zamiast w niezależne moduły) mechanizmów, które są
BARDZO rzadko używane, takich jak tie, format, continue, ?regexp?, etc...
3. Zrzucenie bardzo niskopoziomowych zachowań na system/biblioteki C,
zamiast realizować to w interpreterze... Albo przynajmniej w razie, gdyby
system nie dostarczał swych rozwiązań, to robić wewnętrzną emulację...
Chodzi mi o rzeczy takie jak fcntl(Win), flock(Mac), fork(Mac), open(XXX
'|-') (Mac, Win), setsid (Win), etc.
4. Zalezność działania pack/unpack/vec od architektury... Pisanie rzeczy z
binarną komunikacją, jest przez to udręką :-(
5. Chyba nie nadaję się jeszcze na language advocacy, bo nic mi w tej
chwili na piątą pozycję do głowy nie przychodzi ;-)
Pozdrawiam
--
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas
Adam Osuchowski - 05-03-2007 00:01
Vava wrote:
> Eeee.. To byśmy mieli Pythona ;-P
Python byłby całkiem niezłym językiem gdyby nie te wcięcia...
> Gdyby stricty były defaultowo włączone, to tworzenie czy to jednolinijkowców,
> czy krótkich skryptów do rozwiązania konkretnej sytuacji było by upierdliwe...
Zgadza się. Perl miał dobrze działać a nie ładnie wyglądać.
> 2. Wrzucenie w core (zamiast w niezależne moduły) mechanizmów, które są BARDZO
> rzadko używane, takich jak tie, format, continue, ?regexp?, etc...
To są skutki pierwotnych założeń Perla jako języka do obróbki tekstu i
tworzenia raportów. Do core'a zostało wrzucone to co było najczęściej
wykorzystywane do tego celu i tak już zostało. Ja bym za to wywalił z
core'a do zewnętrznego modułu część POSIXowych syscalli (wszystko co
operuje na socketach i IPC) i funkcji z rodziny get*ent i get*byname.
> 4. Zalezność działania pack/unpack/vec od architektury... Pisanie rzeczy z
> binarną komunikacją, jest przez to udręką :-(
Są gwarantowane 32- i 16-bitowe wartości w formacie big-endian i low-endian.
Nie wystarcza Ci to?
Szymon =?iso-8859-2?Q?Sok=F3=B3?= - 05-03-2007 00:01
On Sun, 4 Mar 2007 19:09:21 +0000 (UTC), Adam Osuchowski wrote:
> 1. To, że po if/while/for/foreach jest wymagany blok nawet jeśli zawiera
> pojedynczą instrukcję (choć wiem, że prawdopodobnie jest to wymuszone ze
> względu na jednoznaczność składni).
Zawsze możesz postfiksowo, znaczy zamiast
if(warunek) {jednainstrukcja}
użyć
jednainstrukcja if warunek;
--
Szymon Sokół (SS316-RIPE) -- Network Manager B
Computer Center, AGH - University of Science and Technology, Cracow, Poland O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982 F
Free speech includes the right not to listen, if not interested -- Heinlein H
kuna - 05-03-2007 00:01
Chyba tego, ze za bardzo nie ma w nim przyszlosci i bardzo waskie grono
w nim siedzi.
Maciej Misiak - 06-03-2007 00:04
> On Sun, 4 Mar 2007 19:09:21 +0000 (UTC), Adam Osuchowski wrote:
>
> > 1. To, że po if/while/for/foreach jest wymagany blok nawet jeśli zawiera
> > pojedynczą instrukcję (choć wiem, że prawdopodobnie jest to wymuszone ze
> > względu na jednoznaczność składni).
>
> Zawsze możesz postfiksowo, znaczy zamiast
> if(warunek) {jednainstrukcja}
> użyć
> jednainstrukcja if warunek;
Ja się tego raz dwa oduczyłem kiedy takie na przykład komunikaty błędów:
print "Nieprawidlowy format parametru abc, powinien byc ABSOLUTE albo RELATIVE"
if $abc!~/^(ABSOLUTE|RELATIVE)$/
zaczęły mi chować ifa za prawy brzeg ekranu. Zmieniłem na
if(warunek)
\t{jedna instrukcja}
--
grizzley
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Maciej Misiak - 06-03-2007 00:04
1. Mało kto oprócz mnie lubi i się przekonał do perla. "...bo dziwny...", "...bo
w .NET to kulawo jakoś, ale od razu napisałem aplikację, a w Perlu w życiu nie
napiszę...", "...bo te głupie $_$!$@$#...", "uff, wypociłem te trzy linijki w
pół godziny, działa, teraz mogę wrócić do fajnego C++...". Bleee...
Też prototypów nie lubię, ale są bardziej wkurzające rzeczy:
2. Ify jednolinijkowe potrzebujące klamerek.
3. Kropka domyślnie nie pasuje do <enter>.
4. Tablice tablic? Tablice hashy? Hashe tablic? Że tego się nie da skopiować
normalnym przypisaniem. I ciągle trzeba ludziom tłumaczyć, czy teraz [] czy {}
czy (). A potem trzeba tłumaczyć, dlaczego $$ref{'abc'} to jest logiczna
konstrukcja, taka sama jak $hash{'abc'}. A i tak nie rozumieją.
5. Nie da się fajnie bawić dwa razy przy tym samym zadaniu w perlgolfie :>
--
grizzley
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Michal Jankowski - 06-03-2007 00:04
"Maciej Misiak" <grizzleyWYTNIJTO@op.pl> writes:
>> Zawsze możesz postfiksowo, znaczy zamiast
>> if(warunek) {jednainstrukcja}
>> użyć
>> jednainstrukcja if warunek;
>
> Ja się tego raz dwa oduczyłem kiedy takie na przykład komunikaty błędów:
> print "Nieprawidlowy format parametru abc, powinien byc ABSOLUTE albo RELATIVE"
> if $abc!~/^(ABSOLUTE|RELATIVE)$/
> zaczęły mi chować ifa za prawy brzeg ekranu. Zmieniłem na
> if(warunek)
> \t{jedna instrukcja}
jednainstrukcja
if warunek;
MJ
Maciej Misiak - 06-03-2007 00:04
> "Maciej Misiak" <grizzleyWYTNIJTO@op.pl> writes:
>
> >> Zawsze możesz postfiksowo, znaczy zamiast
> >> if(warunek) {jednainstrukcja}
> >> użyć
> >> jednainstrukcja if warunek;
> >
> > Ja się tego raz dwa oduczyłem kiedy takie na przykład komunikaty błędów:
> > print "Nieprawidlowy format parametru abc, powinien byc ABSOLUTE albo RELATIVE"
> > if $abc!~/^(ABSOLUTE|RELATIVE)$/
> > zaczęły mi chować ifa za prawy brzeg ekranu. Zmieniłem na
> > if(warunek)
> > \t{jedna instrukcja}
>
> jednainstrukcja
> if warunek;
Wywróciło mi mózg na lewą stronę :) Czytać od prawej do lewej już jest ciężko,
ale od dołu do góry to przesada :)
--
grizzley
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Bartek Jakubski - 06-03-2007 00:04
On Mar 4, 6:54 pm, hubert depesz lubaczewski <dep...@depesz.com>
wrote:
> pewien koleś ostatnio napisał, że aby wiedzieć co sie używa i czemu
> trzeba umiec podać 5 rzeczy których sie nienawidzi w używanym języku.
> (http://use.perl.org/~brian_d_foy/jou...2556?from=rss).
To nie tylko jakiś tam "koleś", to znana postać (autor książek i "The
Perl Review" m.in.) :-)
>
> możecie napisać co was denerwuje w perlu?
>
brian potem zaznaczył, że chodzi o "hate", a nie "annoyances".
Ja mam jedną taką rzecz, ale naprawdę przeszkadzającą w pracy czasem:
* duży narzut czasowy wywoływania metod (w mniejszym stopniu funkcji).
Michal Jankowski - 06-03-2007 00:04
"Maciej Misiak" <grizzleyWYTNIJTO@op.pl> writes:
>> jednainstrukcja
>> if warunek;
>
> Wywróciło mi mózg na lewą stronę :) Czytać od prawej do lewej już
> jest ciężko, ale od dołu do góry to przesada :)
warunek and jednainstrukcja;
8-)
MJ
=?ISO-8859-2?Q?Ma=B3gorzata?= Krakowian - 06-03-2007 00:04
> "Maciej Misiak" <grizzleyWYTNIJTO@op.pl> writes:
>
> >> Zawsze możesz postfiksowo, znaczy zamiast
> >> if(warunek) {jednainstrukcja}
> >> użyć
> >> jednainstrukcja if warunek;
> >
> > Ja się tego raz dwa oduczyłem kiedy takie na przykład komunikaty
> > błędów: print "Nieprawidlowy format parametru abc, powinien byc
> > ABSOLUTE albo RELATIVE" if $abc!~/^(ABSOLUTE|RELATIVE)$/
> > zaczęły mi chować ifa za prawy brzeg ekranu. Zmieniłem na
> > if(warunek)
> > \t{jedna instrukcja}
>
> jednainstrukcja
> if warunek;
>
> MJ
>
a ja lubie zamiast if uzyc czasem (aby kod byl mniej czytelny) && i ||
--
Malgorzata Krakowian
--
Archiwum grupy: http://niusy.onet.pl/pl.comp.lang.perl
Stachu 'Dozzie' K. - 06-03-2007 00:04
On 04.03.2007, hubert depesz lubaczewski <depesz@depesz.com> wrote:
> pewien koleś ostatnio napisał, że aby wiedzieć co sie używa i czemu
> trzeba umiec podać 5 rzeczy których sie nienawidzi w używanym języku.
> (http://use.perl.org/~brian_d_foy/jou...2556?from=rss).
>
> możecie napisać co was denerwuje w perlu?
>
> mnie:
> 1. stricty są domyślnie wyłączone. powinny być domyślnie włączone z możliwością
> (albo i nie) wyłączenia.
Right. Choć w jednolinijkowcach strict raczej byłby niewygodny.
> 2. mylące prototypy. nie służą do tego do czego się myśli, że mają służyć. a
> nie ma takich prawdziwych - np. z typowaniem.
Typowanie? Perl to język z prawie w pełni dynamicznym typowaniem (z
wyjątkiem odróżniania od siebie kodu, skalarów, tablic, haszy i globów).
> 3. potężny, ale wkurzający w obłudze debugger
DDD?
> 4. zmienne $|, $$ (no ta akurat najmniej), $/, $?, $@ itd. ja wiem, że
> jest 'use English', ale czemu nie jest tak domyślnie? nic to nie
> kosztuje!
Nie wiem, ja tam lubię te zmienne.
> 5. "frameworki obiektowe". spiffy, class-insideout i inne. a i tak da
> się uzyskać zmiennych czy metod prywatnych (są jakieś objeścia - jak
> chociażby 'my sub ' w spiffy'm, ale ani to ładne ani efektywne.
Sądzę że by się dało na domknięciach. Tylko po co? Oznaczasz
w dokumentacji metody jako prywatne i jeśli ktoś z nich korzysta, to sam
sobie winien. "Nie wchodzę do czyjegoś domu nie dlatego, że w drzwiach
leży i warczy ogromny pies, a właściciel celuje we mnie ze strzelby,
tylko dlatego, że mnie tam nie proszono."
--
<Kosma> Niektórzy lubią dozziego...
<Kosma> Oczywiście szanujemy ich.
Stanislaw Klekot
Stachu 'Dozzie' K. - 06-03-2007 00:04
On 04.03.2007, Adam Osuchowski <someone@somewhere.com> wrote:
> hubert depesz lubaczewski wrote:
>> możecie napisać co was denerwuje w perlu?
>
> Moje kamyczki do tego ogródka:
>
> 1. To, że po if/while/for/foreach jest wymagany blok nawet jeśli zawiera
> pojedynczą instrukcję (choć wiem, że prawdopodobnie jest to wymuszone ze
> względu na jednoznaczność składni).
Right.
> 2. Wymóg stosowania my() do zmiennych lokalanych wewnątrz bloków. Zamiast
> tego prostsza by była jakaś pragma ustawiająca, że domyślnie zmienne bez
> pełnego kwalifikatora pakietu byłyby traktowane jak zmienne leksykalne
> (wiem, że jestem leniem i nie chce mi się pisać za każdym razem tego
> ,,my'' ale Larry podobno też jest ;-)).
Problem: jak się odwołać do zmiennych z bloku wyżej? A jeśli przypadkiem
użyje się nazwy takiej samej jak w bloku wyżej?
> 3. Brak możliwości nazywania parametrów formalnych funkcji.
Ja używam konstrukcji
#v+
sub funkcja {
my ($arg1, $arg2, $dalsze_argumenty, ...) = @_;
# ...
}
#v-
> 5. Dość bałaganiarski XS. W zasadzie to inne języki mają elegantsze API
> do C (choć spotkałem się też z dokładnie przeciwnymi opiniami).
Okropny. Czytając dokumentację czułem się, jakbym znowu się uczył
assemblera.
> Pewnie by się znalazło jeszcze parę pomniejszych rzeczy które mnie
> denerwują, ale to te które przyszły mi do głowy na poczekaniu.
Zbyt ciężkie wywołania funkcji. Widać to ślicznie na odrobinkę bardziej
skomplikowanej gramatyce przepuszczonej przez Parse::Yapp.
--
<Kosma> Niektórzy lubią dozziego...
<Kosma> Oczywiście szanujemy ich.
Stanislaw Klekot
=?ISO-8859-2?Q?Zbigniew_Kempczy=F1ski?= - 06-03-2007 00:04
Użytkownik Stachu 'Dozzie' K. napisał:
>>3. Brak możliwości nazywania parametrów formalnych funkcji.
>
>
> Ja używam konstrukcji
> #v+
> sub funkcja {
> my ($arg1, $arg2, $dalsze_argumenty, ...) = @_;
> # ...
> }
> #v-
Mi do gustu przypadł sposób:
sub funkcja {
my $p = {
-class => 'pole',
-text => 'Date: ',
-name => 'date',
-disable => '',
-width1 => '30%',
-width2 => '70%',
@_,
};
--
=============================
Zbigniew Kempczyński
http://it.marton.pl/wegorz/
=============================
Stachu 'Dozzie' K. - 06-03-2007 00:04
On 05.03.2007, Zbigniew Kempczyński <Z.Kempczynski@NOSPAMmarton.pl> wrote:
> Użytkownik Stachu 'Dozzie' K. napisał:
>
>>>3. Brak możliwości nazywania parametrów formalnych funkcji.
>>
>>
>> Ja używam konstrukcji
>> #v+
>> sub funkcja {
>> my ($arg1, $arg2, $dalsze_argumenty, ...) = @_;
>> # ...
>> }
>> #v-
>
> Mi do gustu przypadł sposób:
^^-- "mnie", bo tu akcent przypada
> sub funkcja {
> my $p = {
> -class => 'pole',
> -text => 'Date: ',
> -name => 'date',
> -disable => '',
> -width1 => '30%',
> -width2 => '70%',
> @_,
> };
Też fajne, zwłaszcza że z miejsca daje parametry domyślne.
--
<Kosma> Niektórzy lubią dozziego...
<Kosma> Oczywiście szanujemy ich.
Stanislaw Klekot
Adam Osuchowski - 06-03-2007 00:04
Stachu 'Dozzie' K. wrote:
> > 2. Wymóg stosowania my() do zmiennych lokalanych wewnątrz bloków. Zamiast
> > tego prostsza by była jakaś pragma ustawiająca, że domyślnie zmienne bez
> > pełnego kwalifikatora pakietu byłyby traktowane jak zmienne leksykalne
> > (wiem, że jestem leniem i nie chce mi się pisać za każdym razem tego
> > ,,my'' ale Larry podobno też jest ;-)).
>
> Problem: jak się odwołać do zmiennych z bloku wyżej? A jeśli przypadkiem
> użyje się nazwy takiej samej jak w bloku wyżej?
Np. tak jak jest to w Perlu 6, za pomocą metapakietu OUTER::, choć zapewne
można też jakoś inaczej (za pomocą notacji prefiksowej albo coś w tym stylu).
> Ja używam konstrukcji
> #v+
> sub funkcja {
> my ($arg1, $arg2, $dalsze_argumenty, ...) = @_;
> # ...
> }
> #v-
Też tak robię, ale zawsze to by było mniej pisania gdyby było to w
prototypie funkcji, że nie wspomnę o uproszczonym wtedy, automatycznym
dokumentowaniu listy funkcji na podstawie kodu źródłowego.
Stachu 'Dozzie' K. - 06-03-2007 00:04
On 05.03.2007, Adam Osuchowski <someone@somewhere.com> wrote:
> Stachu 'Dozzie' K. wrote:
>> > 2. Wymóg stosowania my() do zmiennych lokalanych wewnątrz bloków. Zamiast
>> > tego prostsza by była jakaś pragma ustawiająca, że domyślnie zmienne bez
>> > pełnego kwalifikatora pakietu byłyby traktowane jak zmienne leksykalne
>> > (wiem, że jestem leniem i nie chce mi się pisać za każdym razem tego
>> > ,,my'' ale Larry podobno też jest ;-)).
>>
>> Problem: jak się odwołać do zmiennych z bloku wyżej? A jeśli przypadkiem
>> użyje się nazwy takiej samej jak w bloku wyżej?
>
> Np. tak jak jest to w Perlu 6, za pomocą metapakietu OUTER::, choć zapewne
> można też jakoś inaczej (za pomocą notacji prefiksowej albo coś w tym stylu).
A potem coś w rodzaju $OUTER::OUTER::OUTER::OUTER::zmienna? Do mnie to
jakoś nie przemawia.
--
<Kosma> Niektórzy lubią dozziego...
<Kosma> Oczywiście szanujemy ich.
Stanislaw Klekot
Jacek Fedorynski - 06-03-2007 00:04
Vava wrote:
>> 1. stricty są domyślnie wyłączone. powinny być domyślnie włączone z
>> możliwością
>> (albo i nie) wyłączenia.
>
> Eeee.. To byśmy mieli Pythona ;-P
To w Pythonie w ogóle jest coś takiego jak use strict? Już nie mówię
defaultowo?
Pozdrawiam,
Jacek Fedoryński
"I z twarzą na wschód zrobiłem jeden krok. Skończyłem. Rozpoczynaj."
teodozjan - 07-03-2007 00:07
Mi najbardziej brakuje darmowego kompilatora dla windows(takiego do
exe).
Z tego co wyczytałem na wikipedii <http://en.wikipedia.org/wiki/
Perl_6> Perl6 będzie obiektowy, z prostymi typami z zmiennych. Więc
część problemów odpadnie.
moldovenu - 07-03-2007 00:07
>> 1. stricty są domyślnie wyłączone. powinny być domyślnie włączone z
>> możliwością
>> (albo i nie) wyłączenia.
>
> Eeee.. To byśmy mieli Pythona ;-P
Jest w pytonie domyślne deklarowanie zmiennych?
Tzn. żeby uniknąć tego typu pomyłek:
fbhughxx = 13
fbhugnxx = fbhughxx + 4
IMHO to jeden z powodów, dla którego mimo wszystko wole perla niż pythona ;)
--
adam
moldovenu - 07-03-2007 00:07
> możecie napisać co was denerwuje w perlu?
Głównie to, co powoduje że jest cienki jak barszcz do dużych projektów:
1. brak narzędzi do zarządzania większą ilością kodu. To wynika z
chaotyczności języka, przekazywania argumentów jako tablic itd. - koniec
końców brakuje czegoś w rodzaju eclipsa/netbeana czy innego ide.
2. Toporny debugger. Tzn. debugger jest ok bo działa, ale nie ma dobrego
interfejsu. A ptkdb stoi w miejscu od lat. Tp6 miał lepszy debugger.
3. chaotyczna, nadmiarowa składnia (ify, odwrotne ify, unlesy, and/or
zastępujące ify itd.) czyli TIMTOWTDI
4. PODy zajmują za dużo miejsca i nie są tak praktyczne jak
javadoc/phpdoc. W rezultacie nie chce się ich używać => ciężko
dokumentować kod.
5. niemożność włączenia wybranego zestawu reguł PBB na zasadzie pragmy,
jak use strict /ale to może się zmieni/ ;)
swego czasu jak się zastanawiałem nad tym, to tyle napisałem:
http://mountains.ws/portfolio/programming.html
Z ogólnego narzekania, dodałbym jeszcze niską czytelność kodu, nieco
dinozaurowe community i brak realnych perspektyw na perla 6, który IMHO
ma mniej wspólnego z obecnym perlem niż python ;)
> 5. "frameworki obiektowe". spiffy, class-insideout i inne. a i tak da
> się uzyskać zmiennych czy metod prywatnych (są jakieś objeścia - jak
> chociażby 'my sub ' w spiffy'm, ale ani to ładne ani efektywne.
zmienne prywatne masz na skalarze blesowanym. Metody... hmm... jak widzę
te przeróżne haki i kolejne dziesiątki modułów usiłujące ten problem
rozwiązać... wygląda to jak rozwalona, wielokrotnie połatana droga. Nie
zachęca do jazdy.
--
adam
Adam Osuchowski - 07-03-2007 00:07
moldovenu wrote:
> Głównie to, co powoduje że jest cienki jak barszcz do dużych projektów:
Niestety z przykrością muszę Ci przyznać rację. Perl stracił swoją
szansę przez zbyt długie stanie w miejscu. Minęło 13 lat od wydania
wersji 5 i prawie nic się nie zmieniło. W tamtym czasie Python był w
powijakach, PHPa w ogóle nie było i Perl miał szansę na bycie porządnym
językiem ogólnego przeznaczenia. Tymczasem minęło sporo czasu, inne
języki się rozwinęły, poszły do przodu, a na Perla 6 faktycznie nie ma
realnych szans. Smutne to ale prawdziwe i chyba faktycznie jest mu
pisany los języka głównie do niewielkich skryptów administracyjnych,
sprytnych jednolinijkowców i golfa.
Kacper Perschke - 07-03-2007 00:07
W artykule <esjegn$tsu$1@news.onet.pl> moldovenu napisał:
>> [...]
> Głównie to, co powoduje że jest cienki jak barszcz do dużych projektów:
Od razu odpowiadam i Adamowi Osuchowskiemu.
To, że wy czegoś nie robicie, to nie znaczy, że kto inny tego nie robi.
http://groups.google.com/group/pl.co...c4ab8bb8694283
KAcper
--
Mail => www.rot13.com
moldovenu - 07-03-2007 00:07
Kacper Perschke wrote:
> W artykule <esjegn$tsu$1@news.onet.pl> moldovenu napisał:
>>> [...]
>> Głównie to, co powoduje że jest cienki jak barszcz do dużych projektów:
>
> Od razu odpowiadam i Adamowi Osuchowskiemu.
>
> To, że wy czegoś nie robicie, to nie znaczy, że kto inny tego nie robi.
>
> http://groups.google.com/group/pl.co...c4ab8bb8694283
To, co pisałem, właśnie wynika z kilkuletniej praktyki przy dużych
(kilka MB kodu źródłowego) projektach w perlu. Nieco wiecej w linku.
Niepodważalną zaletą perla jest cały czas duża liczba bibliotek w
CPANie. To działa, jest sprawdzone i prosi się, by używać.
Co do perla 6 - trafiłem chyba jesienią przypadkowo na kolejne info o
nim. Czytam, czytam, fajnie, fajnie... eee, tylko że to było info z 2003
roku. I w zasadzie nic w tym czasie się w perlu nie zmieniło. A do
pythona czy ruby razem wziętych książek na safari jest tyle, co do
perla. To też o czymś świadczy.
Jakbym miał zaczynać nowy, duży projekt - prawdopodobnie wybrałbym
pythona, jako najlepsze połączenie możliwości perla z przejrzystością
javy. Ruby to prawdopodobny następca perla (zwartość), tylko że jego
największą wadą jest dla mnie... zbyt duże podobnieństwo do perla ;)
Java znowu jest przegadana, troche podobnie jak php.
/pozdrowienia dla innych grzebiących w dziesiątkach tysiący kodu perla/
--
adam
Martin Lukasik - 07-03-2007 00:07
> Ja się tego raz dwa oduczyłem kiedy takie na przykład komunikaty błędów:
> print "Nieprawidlowy format parametru abc, powinien byc ABSOLUTE albo
> RELATIVE"
> if $abc!~/^(ABSOLUTE|RELATIVE)$/
> zaczęły mi chować ifa za prawy brzeg ekranu.
Trzeba kupic monitor, ktory obsluguje wyzsze rozdzielczosci ;-)
m.
--
Marcin Lukasik, marcin na milea kropka pl
http://milea.pl -- sieci bezprzewodowe
``Be who you are and say what you feel, because those who mind don't matter
and those who matter don't mind.''
Adam Osuchowski - 07-03-2007 00:07
Kacper Perschke wrote:
> To, że wy czegoś nie robicie, to nie znaczy, że kto inny tego nie robi.
>
> http://groups.google.com/group/pl.co...c4ab8bb8694283
Ja nie twierdzę, że nikt nie pisze dużych projektów w Perlu, ale czy nie
zauważyłeś, że jednak inne podobne języki zaczynają w tym segmencie
dominować mimo iż kiedyś nie miały takiej przewagi? Zdziwiłbym się,
gdyby się okazało, że Perl absolutnie nie jest już używany do większych
przedsięwzięć bo nie jest z nim tak źle, ale trend spadkowy mimo wszystko
daje się zaobserwować. Może są jakieś hermetyczne środowiska o których
nie wiem i w których Perl jest podstawowym narzędziem projektowym
(podobnie jak to ma miejsce z niedocenianym często Smalltalkiem), ale
IMHO w ogólnych zastosowaniach pałeczkę przejął Python, a w przypadku
zastosowań webowych PHP.
Maciej Misiak - 07-03-2007 00:07
> > Ja się tego raz dwa oduczyłem kiedy takie na przykład komunikaty błędów:
> > print "Nieprawidlowy format parametru abc, powinien byc ABSOLUTE albo
> > RELATIVE"
> > if $abc!~/^(ABSOLUTE|RELATIVE)$/
> > zaczęły mi chować ifa za prawy brzeg ekranu.
>
> Trzeba kupic monitor, ktory obsluguje wyzsze rozdzielczosci ;-)
Oj bo wezmę zaraz coś ciężkiego... :P To niech będzie coś poważnego:
$ret_hash{$current_key} .= err("subnetworkType($found[2])", "should be
TOPO_SINGLETON, TOPO_CHAIN, TOPO_PSR, TOPO_OPEN_PSR, TOPO_SPRING,
TOPO_OPEN_SPRING or TOPO_MESH") if
$found[2]!~/^TOPO_SINGLETON|TOPO_CHAIN|TOPO_PSR|TOPO_OPEN_PSR| TOPO_SPRING|TOPO_OPEN_SPRING|TOPO_MESH$/
Na to chyba bym musiał mieć coś 40-calowego...
--
grizzley
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Szymon =?iso-8859-2?Q?Sok=F3=B3?= - 07-03-2007 00:07
On 6 Mar 2007 18:11:31 +0100, Maciej Misiak wrote:
>>> Ja się tego raz dwa oduczyłem kiedy takie na przykład komunikaty błędów:
>>> print "Nieprawidlowy format parametru abc, powinien byc ABSOLUTE albo
>>> RELATIVE"
>>> if $abc!~/^(ABSOLUTE|RELATIVE)$/
>>> zaczęły mi chować ifa za prawy brzeg ekranu.
>>
>> Trzeba kupic monitor, ktory obsluguje wyzsze rozdzielczosci ;-)
>
> Oj bo wezmę zaraz coś ciężkiego... :P To niech będzie coś poważnego:
>
> $ret_hash{$current_key} .= err("subnetworkType($found[2])", "should be
> TOPO_SINGLETON, TOPO_CHAIN, TOPO_PSR, TOPO_OPEN_PSR, TOPO_SPRING,
> TOPO_OPEN_SPRING or TOPO_MESH") if
> $found[2]!~/^TOPO_SINGLETON|TOPO_CHAIN|TOPO_PSR|TOPO_OPEN_PSR| TOPO_SPRING|TOPO_OPEN_SPRING|TOPO_MESH$/
>
> Na to chyba bym musiał mieć coś 40-calowego...
To trzeba kupić klawiaturę, w której Enter się nie zacina :->
Ja formatuję kod tak, że nie wyłazi poza kolumnę 80 (tak, nawyk z czasów
kart perforowanych ;->)...
--
Szymon Sokół (SS316-RIPE) -- Network Manager B
Computer Center, AGH - University of Science and Technology, Cracow, Poland O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982 F
Free speech includes the right not to listen, if not interested -- Heinlein H
Stachu 'Dozzie' K. - 07-03-2007 00:07
On 06.03.2007, moldovenu <moldovenu@spamu.niet.interia.pl> wrote:
>> możecie napisać co was denerwuje w perlu?
>
> Głównie to, co powoduje że jest cienki jak barszcz do dużych projektów:
>
> 1. brak narzędzi do zarządzania większą ilością kodu. To wynika z
> chaotyczności języka, przekazywania argumentów jako tablic itd. - koniec
> końców brakuje czegoś w rodzaju eclipsa/netbeana czy innego ide.
Możesz wyjaśnić, co dokładnie przydatne jest w kobylastych IDE?
Integracja z Subversion, kiedy ja potrzebuję gita albo svk?
System budowania, w który użytkownik nie powinien ingerować, bo może
stracić zmiany albo środowisko nie poradzi sobie w mieszanym
(automat-manual) makefile'u, a użycie co dziwniejszych targetów
(kopiowanie plików na zdalne maszyny, uruchamianie programu pod PVM
i tym podobne) jest proste jak trzydzieści metrów drutu kolczastego
w kieszeni? A może edytor, który nie potrafi nawet zwijać kodu w takich
granicach, jakich potrzebuję, w zamian oferując zwijanie pojedynczych
bloków {}, do czego _niezbędna_ jest myszka?
Jedynie refaktoryzacja mnie przekonuje. Ale to z kolei wolałbym mieć
w osobnym narzędziu.
> 2. Toporny debugger. Tzn. debugger jest ok bo działa, ale nie ma dobrego
> interfejsu. A ptkdb stoi w miejscu od lat. Tp6 miał lepszy debugger.
DDD nie istnieje, jak rozumiem? Poinformujesz opiekunów projektu?
Inna sprawa, że wierszowi poleceń, nawet z Term::ReadLine::Gnu, dużo
brakuje do gdb.
> 3. chaotyczna, nadmiarowa składnia (ify, odwrotne ify, unlesy, and/or
> zastępujące ify itd.) czyli TIMTOWTDI
Używaj Pythona. Tam jest tylko jedna słuszna metoda robienia czegoś.
> 4. PODy zajmują za dużo miejsca i nie są tak praktyczne jak
> javadoc/phpdoc. W rezultacie nie chce się ich używać => ciężko
> dokumentować kod.
Right. Za dużo pustych linii wokół =tagów. Ale poza tym to niewielki
problem. Co więcej, to żaden wysiłek przygotować parser używający choćby
"#*" jako dokumentacji. Narzędzie szacuję na parędziesiąt wierszy kodu.
> 5. niemożność włączenia wybranego zestawu reguł PBB na zasadzie pragmy,
> jak use strict /ale to może się zmieni/ ;)
>
> swego czasu jak się zastanawiałem nad tym, to tyle napisałem:
> http://mountains.ws/portfolio/programming.html
#v+
I'm afraid mod_perl will no more have it's "5 minutes" especially in
late-growing web markets like Poland. Too complicated to use compared to
PHP. Not so many features (sharing data in processes/threads) compared
to Java. Not so popular and served only with Apache.
#v-
Zestaw argumentów podobnie bzdurny jak "Linux nie nadaje się do użytku,
bo nie ma tylu sterowników co Windows, nie jest tak prosty w użyciu jak
MacOS, nie ma tak stabilnego ABI jak Solaris i nie ma takiego wsparcia
technicznego jak HP/UX". Znaczy z każdego konkurencyjnego projektu
weźmiemy to, czego nie umie mod_perl.
> Z ogólnego narzekania, dodałbym jeszcze niską czytelność kodu,
Nie umiesz pisać czytelnie w tym języku, to nie pisz w ogóle. Zasada
prosta. Niska czytelność to nie właściwość Perla, tylko programisty.
Perl zakłada, że programista nie kretyn i wie, co robi. Python i Java
mają inne założenia, może któreś z nich będzie ci pasować?
--
<Kosma> Niektórzy lubią dozziego...
<Kosma> Oczywiście szanujemy ich.
Stanislaw Klekot
Stachu 'Dozzie' K. - 07-03-2007 00:07
On 06.03.2007, Adam Osuchowski <someone@somewhere.com> wrote:
> Kacper Perschke wrote:
>> To, że wy czegoś nie robicie, to nie znaczy, że kto inny tego nie robi.
>>
>> http://groups.google.com/group/pl.co...c4ab8bb8694283
>
> Ja nie twierdzę, że nikt nie pisze dużych projektów w Perlu, ale czy nie
> zauważyłeś, że jednak inne podobne języki zaczynają w tym segmencie
> dominować mimo iż kiedyś nie miały takiej przewagi?
Podstawowy problem: w dużych przedsięwzięciach często biorą udział
cretin-programmers, a takich też trzeba brać pod uwagę przy doborze
narzędzi. Perl zakłada, że programista dobrze wie co robi -- i to jest
właśnie minus w wielu przypadkach.
--
<Kosma> Niektórzy lubią dozziego...
<Kosma> Oczywiście szanujemy ich.
Stanislaw Klekot
Stachu 'Dozzie' K. - 07-03-2007 00:07
On 06.03.2007, Szymon Sokół <szymon@bastard.operator.from.hell.pl> wrote:
> On 6 Mar 2007 18:11:31 +0100, Maciej Misiak wrote:
>
>>>> Ja się tego raz dwa oduczyłem kiedy takie na przykład komunikaty błędów:
>>>> print "Nieprawidlowy format parametru abc, powinien byc ABSOLUTE albo
>>>> RELATIVE"
>>>> if $abc!~/^(ABSOLUTE|RELATIVE)$/
>>>> zaczęły mi chować ifa za prawy brzeg ekranu.
>>>
>>> Trzeba kupic monitor, ktory obsluguje wyzsze rozdzielczosci ;-)
>>
>> Oj bo wezmę zaraz coś ciężkiego... :P To niech będzie coś poważnego:
>>
>> $ret_hash{$current_key} .= err("subnetworkType($found[2])", "should be
>> TOPO_SINGLETON, TOPO_CHAIN, TOPO_PSR, TOPO_OPEN_PSR, TOPO_SPRING,
>> TOPO_OPEN_SPRING or TOPO_MESH") if
>> $found[2]!~/^TOPO_SINGLETON|TOPO_CHAIN|TOPO_PSR|TOPO_OPEN_PSR| TOPO_SPRING|TOPO_OPEN_SPRING|TOPO_MESH$/
>>
>> Na to chyba bym musiał mieć coś 40-calowego...
>
> To trzeba kupić klawiaturę, w której Enter się nie zacina :->
> Ja formatuję kod tak, że nie wyłazi poza kolumnę 80 (tak, nawyk z czasów
> kart perforowanych ;->)...
A mój nawyk cięcia na 78 kolumnie? Na pewno nie pochodzi z tamtych
czasów, bo PC-ta mam od lutego 2k ;)
Mnie zwyczajnie niewygodnie się czyta linie dużo dłuższe niż 80 znaków.
Podobno człowiek nie może tyle objąć wzrokiem na jeden raz.
--
<Kosma> Niektórzy lubią dozziego...
<Kosma> Oczywiście szanujemy ich.
Stanislaw Klekot
teodozjan - 07-03-2007 00:07
On 6 Mar, 11:07, moldovenu <moldov...@spamu.niet.interia.pl> wrote:
> 1. brak narzędzi do zarządzania większą ilością kodu. To wynika z
> chaotyczności języka, przekazywania argumentów jako tablic itd. - koniec
> końców brakuje czegoś w rodzaju eclipsa/netbeana czy innego ide.
>
<http://e-p-i-c.sourceforge.net/>
Wtyczka do eclipse jest, ale uczciwie mówiąc nie wiem jak działa.
Ogólne perlowe wishlisty
Najbardziej perla uratowałoby środowisko typu Visual_* choćby płatne.
Miejsce gdzie, czy składnia jest taka czy inna nie ma większego
znaczenia. Ale do tego perl musiałby stać się w pełni obiektowy. Mini-
zabaweczka w postaci vptk istnieje, który działa, ale to trochę za
mało.
Należy pamiętać, że perl ma CPAN, który sprawia, że składnie skryptów
jest całkiem proste. Skrypty z CPAN robią praktycznie wszystko, jeden
na przykład przeszukuje dokumenty openoffice.
http://mail.python.org/pipermail/tut...er/008784.html
=?ISO-8859-2?Q?Edward_Knia=BFycki?= - 07-03-2007 00:07
teodozjan napisał(a):
> [...]
> Najbardziej perla uratowałoby środowisko typu Visual_* choćby płatne.
> Miejsce gdzie, czy składnia jest taka czy inna nie ma większego
> znaczenia. Ale do tego perl musiałby stać się w pełni obiektowy. Mini-
> zabaweczka w postaci vptk istnieje, który działa, ale to trochę za
> mało.
> [...]
A ActivePerl Pro Studio, lub choćby Komodo IDE nie spełniają tego kryterium?
Ed.
--
Pisząc do mnie usuń zbędne słowo z adresu
Twelve Hungry Mammoths - 07-03-2007 00:07
On Tue, 06 Mar 2007 19:40:37 +0100, Stachu 'Dozzie' K.
<dozzie@dynamit.im.pwr.wroc.pl.nospam> wrote:
>>
>> Głównie to, co powoduje że jest cienki jak barszcz do dużych projektów:
>>
>> 1. brak narzędzi do zarządzania większą ilością kodu. To wynika z
>> chaotyczności języka, przekazywania argumentów jako tablic itd. - koniec
>> końców brakuje czegoś w rodzaju eclipsa/netbeana czy innego ide.
na wstepie wyjasnie, ze na codzien uzywam eclipse do kodowania w Javie,
wiec przez IDE wlasnie to rozumiem.
> Możesz wyjaśnić, co dokładnie przydatne jest w kobylastych IDE?
znam dowcip o muchach, ale IMHO to, ze znakomita wiekszosc zawodowych
programistow korzysta z nich na codzien swiadczy, ze duzo fajnych
ficzerow, ktore usprawniaja i przyspieszaja prace. z kilkudziesieciu
programistow, ktorych znam, nie slyszalem, zeby ktokolwiek _nie_ korzystal
na codzien z IDE.
tu pojawiaja sie tez kwestie jezykowe. np. Java jest pewnie duzo bardziej
podatna na IDE-owosc, ze wzgledu na latwosc przetwarzania zrodel i
koszmarny stopien przegadania. Java ma tez zreszta duzo bardziej wypasione
IDE ze wzgledu na popularnosc.
> Integracja z Subversion,
integracja z systemem kontroli wersji bardzo sie przydaje, szczegolnie
przy nietrywialnych konfliktach czy intensywnym korzystaniu z bardziej
zaawansowanych ficzerow, jak branche czy tagi. szczerze mowiac nie
wyobrazam sobie korzystania z commandline'owego klienta cvs do tego typu
zadan. pewnie sie da, ale na 100% w IDE bedzie latwiej i szybciej.
> kiedy ja potrzebuję gita albo svk?
jezeli korzystasz z tak egzotycznego systemu, ze nie ma wtyczek dla
popularnych IDE to coz... Twoj wybor. dla mnie przy wyborze takich
narzedzi jak np. system kontroli wersji wsparcie dla niego w IDE stanowi
waznych czynnik. szczegolnie, jezeli ten system ma byc uzywany przez
zespol, nie samotnego strzelca.
> System budowania,
odpalany jedna kombinacja klawiszy (Ctrl-B) albo wogole automatycznie
zamiast przechodzenia do osobnego okienka i szukania odpowiedniego
polecenia (conajmniej trzy kombinacje (Alt-Tab - strzalka - enter pod
warunkiem, ze caly czas wykonujemy jedno i to samo polecenie). biorac pod
uwage, ze ja projekt buduje kilkadziesiat razy dziennie, wole jedna
kombinacje.
> w który użytkownik nie powinien ingerować, bo może
> stracić zmiany albo środowisko nie poradzi sobie w mieszanym
> (automat-manual) makefile'u, a użycie co dziwniejszych targetów
> (kopiowanie plików na zdalne maszyny, uruchamianie programu pod PVM
> i tym podobne) jest proste jak trzydzieści metrów drutu kolczastego
> w kieszeni?
ponioslo Cie. kazde szanujace sie IDE potrafi odpalic makefile'a,
antfile'a, mavena czy dowolny inny skrypt lub program. a jak uzytkownik
potrafi spieprzyc cos w IDE, to w skrypcie zwykle rownie latwo mu to
przyjdzie (-:
> A może edytor, który nie potrafi nawet zwijać kodu w takich
> granicach, jakich potrzebuję,
tzn. w jakich?
> w zamian oferując zwijanie pojedynczych
> bloków {}, do czego _niezbędna_ jest myszka?
eclipse potrafi wiecej. ja nie uzywam zwijania (oprocz sekcji importow),
wiec ciezko mi wyrokowac, czy to dobre jest. na pewno nie jest tak
wypasione jak w vimie <-: i na pewno nie czyta w myslach.
> #v+
> I'm afraid mod_perl will no more have it's "5 minutes" especially in
> late-growing web markets like Poland. Too complicated to use compared to
> PHP. Not so many features (sharing data in processes/threads) compared
> to Java. Not so popular and served only with Apache.
> #v-
>
> Zestaw argumentów podobnie bzdurny jak "Linux nie nadaje się do użytku,
> bo nie ma tylu sterowników co Windows, nie jest tak prosty w użyciu jak
> MacOS, nie ma tak stabilnego ABI jak Solaris i nie ma takiego wsparcia
> technicznego jak HP/UX". Znaczy z każdego konkurencyjnego projektu
> weźmiemy to, czego nie umie mod_perl.
znow Cie ponioslo. kolega nie napisal, ze Perl nie nadaje sie do uzytku,
tylko ze moze sie spoznic na swoje 5 minut. na swoje tzw. okno
marketingowe.
poza tym Perl _jest_ bardziej skomplikowany niz PHP. watki _sa_ lepiej
zrobione w Javie. polemizuj z tymi tezami, a nie ze swoimi wymyslami nt.
Linuxa i Windows. (nie wypowiadam sie nt. Apache, bo sie nie znam, ale
podejrzewam, ze sa tez inne serwery.)
>> Z ogólnego narzekania, dodałbym jeszcze niską czytelność kodu,
>
> Nie umiesz pisać czytelnie w tym języku, to nie pisz w ogóle. Zasada
> prosta. Niska czytelność to nie właściwość Perla, tylko programisty.
> Perl zakłada, że programista nie kretyn i wie, co robi.
w prawdziwym zyciu (w odroznieniu od bezproduktywnych dyskusji w usenecie)
masz stycznosc takze z kodem pisanym przez kretynow. czasem musisz go
uzyc, czasem zrozumiec, czasem niestety nawet konserwowac.
nie mowie, ze kazdy jezyk powinien byc tak faszystowski jak Java, ale
warto czasem pamietac, ze programowanie to nie tylko sport indywidualny
czy wyczynowy. czasem trzeba grac zespolowo (-:
> Python i Java
> mają inne założenia, może któreś z nich będzie ci pasować?
LOL, uwazasz to za obelge?
pzdr
szeryf
teodozjan - 07-03-2007 00:07
On 6 Mar, 21:44, Edward Kniażycki <e.t.kzbe...@gmx.net> wrote:
> teodozjan napisał(a):> [...]
> > Najbardziej perla uratowałoby środowisko typu Visual_* choćby płatne.
> A ActivePerl Pro Studio, lub choćby Komodo IDE nie spełniają tego kryterium?
>
> Ed.
> --
> Pisząc do mnie usuń zbędne słowo z adresu
Komodo wygląda na bardzo dobrą aplikację ,ale nie widzę w niej
możliwości rysowania sobie interfejsu graficznego. Producenci nie
umieścili w reklamie?
Vava - 07-03-2007 00:07
On Tue, 06 Mar 2007 20:27:14 +0100, teodozjan <teodozjan@gmail.com> wrote:
> On 6 Mar, 11:07, moldovenu <moldov...@spamu.niet.interia.pl> wrote:
>> 1. brak narzędzi do zarządzania większą ilością kodu. To wynika z
>> chaotyczności języka, przekazywania argumentów jako tablic itd. - koniec
>> końców brakuje czegoś w rodzaju eclipsa/netbeana czy innego ide.
>>
>
> <http://e-p-i-c.sourceforge.net/>
> Wtyczka do eclipse jest, ale uczciwie mówiąc nie wiem jak działa.
Eclipse jest ostatnim narzędziem jakiego chciał bym używać... Już bym
wolał użyć Visual Studio, a ta deklaracja ledwo mi przez klawiaturę
przechodzi... ;-) Jak już muszę coś w javie, to wolę NetBeans, choć i to
żre pamięć jak termity balsę///
> Ogólne perlowe wishlisty
>
> Najbardziej perla uratowałoby środowisko typu Visual_* choćby płatne.
> Miejsce gdzie, czy składnia jest taka czy inna nie ma większego
> znaczenia. Ale do tego perl musiałby stać się w pełni obiektowy. Mini-
> zabaweczka w postaci vptk istnieje, który działa, ale to trochę za
> mało.
http://www.activestate.com/products/komodo_ide/
+
http://www.activestate.com/products/perl_dev_kit/
Czego Ci w tym zestawie (popatrz też co będzie w PDK 7 - obecnie w jednej
z końcowych wersji beta) brakuje?
Kiedyś ActiveState oferowało perlową wtyczkę do VS.NET (próbowałem wersji
ewaluacyjnej, działała nawet, nawet, jeśli w ogóle można tak powiedzieć o
czymkolwiek związanym z VS...). Ale jakoś tak półtora roku temu zostało to
zarzucone, czego jakoś mi nie brak... ;-P
Acha - darmowe Komodo Edit też jest całkiem fajne i do mniejszych rzeczy
(gdzie jedna osoba pracuje nad kodem) w zupełności wystarcza...
> Należy pamiętać, że perl ma CPAN, który sprawia, że składnie skryptów
> jest całkiem proste. Skrypty z CPAN robią praktycznie wszystko, jeden
> na przykład przeszukuje dokumenty openoffice.
>
> http://mail.python.org/pipermail/tut...er/008784.html
To, czego mi brakuje, to wtyczki do IBM/Rationa Rose, robiącej szkielet
klas perlowych na podstawie diagramów, analogicznie, jak to można zrobić
dla javy, C++, ady, czy vb...
Tak, wiem... Umbrello ma takie coś i dla hellowordlware nawet do działa
;-), ale niestety daleko temu do funkcjonalności z Rose'a :-(
Pozdrawiam
--
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
Strona 1 z 4 • Znaleźliśmy 136 postów • 1, 2, 3, 4
|
=?ISO-8859-2?Q?Re=3A_Informatyka=2C_Java=2C_EJB=2C_Ajax=2C?== ?ISO-8859-2?Q?_Spring=2E_Czy=BFby_to_koniec_=B6wiata=2C_czy? ==?ISO-8859-2?Q?_te=BF_nasze_uczelnie_b=EAd=B1_uczy=B3y_w_k?== ?ISO-8859-2?Q?o=F1cu!_czego_praktyczne?=
=?iso-8859-2?q?Informatyka,_Java,_EJB,_Ajax,_Spring=2E_Czy=BF by_to_koniec_=B6wiata,_czy_te=BF_nasze_uczelnie_b= EAd=B1_uczy=B3y_w_ko=F1cu!_czego_praktycznego_=2E= 2E=2E=2E?=
=?ISO-8859-2?Q?b=B3=B1d_w_bazie=2C_nie_wiem_od_czego?==?ISO-8859-2?Q?_zaczac_szukanie?=
=?iso-8859-2?Q?=5Blama=5D_Mapa_-_od_czego_zacz=B1=E6=3F?=
do czego uzywac perl-a? czy warto poznac ten jezyk
[ORACLE] - Czego używcie do monitorowanie swoich baz?
replikacja w Mysql 5.0.27- czego brak ?
Od czego zacząć robienie strony ?
Aplikacja dla laboratorium - czego użyć
[mySQL] Sprawdzenie, czego jest najwiecej
zanotowane.pldoc.pisz.plpdf.pisz.pltejsza.htw.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
