ďťż
 
program magazynowy ďťż
 
program magazynowy
Zobacz wiadomości
 
Cytat
A gdyby tak się wedrzeć na umysłów górę, / Gdyby stanąć na ludzkich myśli piramidzie, / I przebić czołem przesądów chmurę, / I być najwyższą myślą wcieloną. . . Juliusz Słowacki, Kordian
Indeks BCB i MySQL subiekt gt fototapeta
 
  Witamy

program magazynowy



Sebastian Bialy - 11-08-2007 00:03

  Przemyslaw Osmanski wrote:
> Pobudka ;) Mamy srodek (blizej konca) 2007 ;) Borland wydzielil z siebie
> spolke corke o nazwie CodeGear ktora zajmuje sie tylko rozwojem
> srodowisk programistycznych, a Borland reszta ALM.

Mają jakieś inne cele poza pączkowianiem ? Tzn jakąś wizję co dalej z
Delphi/BCB ?

> VCL nie jest ".net compatibile" i nie bedzie.

Czyli już idzie do piachu.

> Delphi .NET jest natywne
> dla .NET + przeniesienie calego VCL na platforme .NET.

Czyli nie rozumiem: masz dodatkową warstwę pomiędzy kodem a .NET ? A po co?

> Chyba o zaletach takiego rozwiazania nie trzeba pisac, bo mam nadzieje
> ze sa oczywiste.

No własnie ani w ząb nie są.

>> Pokaż mi jakieś frameworki pracujące z abstrakcyjnymi danymi na delphi.
> Pierwszy z brzegu - RemObject "Vinci"

No i o to chodzi. Skoro ktoś to popełnił to po jaką ch... robić to ma
MySQL zamiast na po prostu bazie danych. Poczytam i zobaczę co to ale
coś mi się wydaje że to samo znajdę w Javie :)

> Ale mamy
> przenosnosc na .NET i co za tym idzie na wszysko na co .NET jest
> przenosny.

Ufff, to kamień z serca że mogę sobie przenieść tą aplikajcę na
Windowsa. O to chodziło.

> Kiedys byl jeszcze Kylix...

Był? O ile pamiętam mocno niekompatybilny z Delphi.

>> delphi jest co pozwoliło by odwrócić tendencję uciakania w Jave/.NET
>> wiekszości firm.

> A odwrotnie, co takiego niby jest w Javie co mialoby powodowac owe
> tendencje.

Zaplecze w postaci ogromnej ilości ludzi tworzących w tym kod od mikro
urządzeń po wypasione systemy. Nowocześniejszy koncepcyjnie sposób
używania. Obiektowość wszędzie wymuszająca często brak tandetnych
rozwiązań znanych z delphi typu Label1.Caption="foo".

> O .NET celowo nie pisze, bo to nie srodowisko. W .NET mozna
> pisac w dowolnym jezyku ktory je wspiera, wiec ucieczka z Delphi do
> Delphi.NET to zadna ucieczka.

Inaczej. Ucieczka z Delphi .NET do C# .NET to żadna ucieczka. Zważywszy,
że Delphi ma mizerną przyszłość trzeba być mocno przekonanym do swoich
racji, żeby rozpoczynać projekt w Delphi zamiast C# .NET.

>> Pokaż mi jeden element mający kluczowe znaczenie dla designu i
>> implementacji który znajdę w Delphi a nie znajdę w Javie/.NET.

> Nie ma takiego, tak samo jak nie ma go w odwrotna strone. Jesli jest
> inaczej, to pokaż takie element.

Pfff. Zależy do czego. Ja na przykład podam Swinga. Ktoś inny
Hibernate/Spring. Ktoś jeszcze inny przenośność z palca (oczywiście nie
w .NET). Jest sporo rzeczy gdzie Delphi pozostanie w tyle. Raz ze
względu na głupią decyzję w postaci Pascalo podobnego języka, dwa ze
względu na przyklejenie się do technologii MS na tyle mocno, że
separacja nie udała się (Kylix).

> Zartujesz? QT z tego co wiem nie jest elementem srodowiska
> programistycznego, wiec jak juz porownujesz srodowiska to je porownuj a
> nie dodatki.

Środowisko Delphi składa się praktycznie wyłacznie z GUI. W sumie jak
zeskrobać farbę to w środku nie ma nic specjalnego. Delphi dorobiło się
już np. wersjonowania kodu w SVN czy czegoś podobnego ? Bo _darmowe_
środowiska konkurencyjne silnie się rozrosły - np. Eclipse czy NetBeans.

> Bo moge sobie np. dodac do Delphi DevExpress'a (zreszta tak
> mam) i QT zostaje daleko w tyle.

W czym daleko w tyle?

> Co do wzorca, to masz tak taki, jaki sobie przyjmiesz i zaimplementujesz.
> A jesli juz to Delphi jest chyba jednym z lepszych pakietów do
> wytwarzania oprogramowania w trybie prototypowania aplikacji.

Bo da się łatwo napisać zmiane koloru formy po pacnięciu w przycisk? A
tak, faktycznie. To teraz zapytam: czy da się w delphi łatwo
zaimplementować kontrolę drzewa nie mając wsparcia w postaci
Model-Widok. W sensie przejrzyśie i obiektowo. No i tutaj Qt jest o
jakąś epokę do przodu. Acz fakt, żależy jakie aplikacje się pisze.

>> Oczywiście jest fatalnym. Znacznie lepszy jest Delphi. Z całą masą
>> książek tłumaczących jak zrobić, żeby po kliknięciu zrobiło się
>> czerwone tło. A nie zajmujących się pierdołami typu dekorator, fasada
>> i inne zbędne rzeczy. Tak, Delphi jest zdecydowanie bardziej dydaktyczne.

> Gratuluje podejscia "dydaktycznego". Jesliby w ten sposob uczyc
> kogokolwiek programowania, to programistów byloby kilka razy mniej.

Nie, było by kilka razy mniej "drag 'n' drop operators" w delphi.

> Najpierw nalezy sie nauczyc myslec w odpowiedni sposob, a pozniej brac
> sie za bardziej powazne sprawy.

Czyli jak? Zaczynać pisanie aplikacji od wybrania interfejsu graficznego
narzędzia developerskiego? Ja bym zaczął od projektu jądra liczącego
transakcje księgowe, zależności obiektowych, szkieletu bazy danych,
modelu dosepu urzytkowników. Ale ja się nie znam.

> Jakos nie kreciloby mnie pisanie wprawkowych klas jako pierwsze zadania
> z programowania. Wolalbym konkret, chocby jak owe czerwone tło. Bo widac
> efekty.
> Widac mamy inne podejście.

Oczywiście. Niektórzy muszą mieć czerwone tło na formie w jednej linije.
I dla nich powstało Delphi. Inni muszą mieć obiektowy model bazy danych
z separacją od GUI. I dla nich Delphi nie powstało. Zgadnij którzy
zarabiają więcej i pracują przy ciekawszych projektach ?





vit - 11-08-2007 00:03

 
Użytkownik "Jedrzej Dudkiewicz" <jedrzej.dudkiewicz@poczta.interia.pl>
napisał w wiadomości news:f9hd6k$mvt$1@news.supermedia.pl...
>> b) jedna z setki baz danych SQLowych - MySQL. A czemu nie po prostu
>> JAKAŚ baza danych SQL? Przecież abstrakcja bazy danych do czystego SQL
>> nic nie kosztuje. Czemu akurat MySQL? A jak sobie kupie internetową
>> bazdę danych z pełnym backupem w internecie to już sobie nie skorzystam?
>
> Na pl.comp.lang.c jakis czas temu byla rozmowa, z ktorej wniosek byl mniej
> wiecej taki, ze abstrakcja od konkretnej bazy danych to wlasnie
> abstrakcja.
>
> JD
>

MySQL, czy Postgres postawię sobie na Linuxie. Po cholere kupowac KOLEJNA
licencje MS zeby stawiac serwer bazy danych? (np. MSSQL).




Damian 'legion' Szuberski - 11-08-2007 00:03

  On 2007-08-10, Przemyslaw Osmanski wrote:
>> c) Koncepcja typu "wszystko można zrobić na komponencie wizualnym"
>> prowokuje do "stawiania serwera TCP na Form1" i generuje aplikacje
>> absolutnie bez separacji gui<->logika.
> W kazdym jezyku/srodowisku mozna zrobic potworka, jesli sie nie umie
> porzadnie zabrac za projekt. A to ze BCB jest latwiejsze dla
> poczatkujacego, prawdopodobnie skutkuje tym, że wiecej jest zle
> zrobionych projektow. Jednak nie wynika to z uzywania srodowiska.
BCB nadaje się jedynie do szybkiego wyklikania projektu na studia. W
momencie kiedy do projektu musisz dołączać inne biblioteki, chcesz
odseparować 'czysty' kod od borlandowych wstawek czy porządnie debugować
kod wyrasta szereg problemów. Ten 'kompilator' jest po prostu za ciasny
a zaczynanie pisania w nim aplikacji (sic!) biznesowej to *porażka*.
Chyba że chcesz się obudzić z projektem w którym żałosne TFormy
poprzetykane są klasami obliczającymi stan magazynu...

> ??? Cos mi sie wydaje ze Delphi to znasz ze slyszenia, albo zatrzymales
> sie na rozwoju wersji tez w okolicach 5-6.
Co do delfi - argumenty jak wyżej.

>> Nawet C++ z jakąs sensowną biblioteką GUI i boost (ale to za trudne na
> Tutaj nalezaloby rozwazyc na jaka platforme ma byc przeznaczony program.
> Nie nalezy zakladac ze wszystko ma dzialac na linuksie, albo ze ma byc
> przenosnie. Czasami warto uzyc natywnego GUI.
Zrób takie założenie a projekt masz utopiony na samym początku. Bo po
jakimś czasie okazać się może że jednak na Linuksie ale wtedy program
będzie miał x kloców i przepisywanie tego będzie utopią.

> Nie bylbym taki pewien, czy java jest dobrym jezykiem dydaktycznym...
Na pewno lepszym od C++ (za dużo detali i kruczków). Co do delfi - n/c

--
Damian Szuberski




=?iso-8859-2?Q?Pawe=B3_Kierski?= - 11-08-2007 00:03

  vit w wiadomości <f9i1og$5in$1@atlantis.news.tpi.pl> pisze:
>
> Użytkownik "Jedrzej Dudkiewicz" <jedrzej.dudkiewicz@poczta.interia.pl>
> napisał w wiadomości news:f9hd6k$mvt$1@news.supermedia.pl...
> >> b) jedna z setki baz danych SQLowych - MySQL. A czemu nie po prostu
> >> JAKAŚ baza danych SQL? Przecież abstrakcja bazy danych do czystego SQL
> >> nic nie kosztuje. Czemu akurat MySQL? A jak sobie kupie internetową
> >> bazdę danych z pełnym backupem w internecie to już sobie nie skorzystam?
> >
> > Na pl.comp.lang.c jakis czas temu byla rozmowa, z ktorej wniosek byl mniej
> > wiecej taki, ze abstrakcja od konkretnej bazy danych to wlasnie
> > abstrakcja.
> >
>
> MySQL, czy Postgres postawię sobie na Linuxie. Po cholere kupowac KOLEJNA
> licencje MS zeby stawiac serwer bazy danych? (np. MSSQL).

Po cholerę w ogóle myśleć MySQL vs. MSSQL, gdy chodzi o "bazę SQL"?
Czy to będzie jedna, druga, czy trzecia, to można zdecydować się
później. Wracając do analogii z montowaniem samochodu - to jak
decydować na etapie projektu o marce używanych śrubek, czy kolorze
obić siedzeń.

--
Paweł Kierski
news@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)





=?ISO-8859-2?Q?Rafa=B3?= Maj - 12-08-2007 00:08

  Jacek Czerwinski <1wzkw331554z4$.1cxpnmeotuxhu$.dlg@40tude.net> Wednesday, 8
August 2007 19:13

> A programy (do magazynu) młodych fascynatów technologią to widziałem,
> nawet miłe w dotyku, technologcznie też niezłe. Ku...y zaczęły latac w
> powietrzu dopiero 31 grudnia.

Zaokrąglenia? :)




vit - 12-08-2007 00:08

 
Użytkownik "Paweł Kierski" <news@pkierski.net> napisał w wiadomości
news:776722200.20070810213814@pkierski.net...
> vit w wiadomości <f9i1og$5in$1@atlantis.news.tpi.pl> pisze:
>>
>> Użytkownik "Jedrzej Dudkiewicz" <jedrzej.dudkiewicz@poczta.interia.pl>
>> napisał w wiadomości news:f9hd6k$mvt$1@news.supermedia.pl...
>> >> b) jedna z setki baz danych SQLowych - MySQL. A czemu nie po prostu
>> >> JAKAŚ baza danych SQL? Przecież abstrakcja bazy danych do czystego SQL
>> >> nic nie kosztuje. Czemu akurat MySQL? A jak sobie kupie internetową
>> >> bazdę danych z pełnym backupem w internecie to już sobie nie
>> >> skorzystam?
>> >
>> > Na pl.comp.lang.c jakis czas temu byla rozmowa, z ktorej wniosek byl
>> > mniej
>> > wiecej taki, ze abstrakcja od konkretnej bazy danych to wlasnie
>> > abstrakcja.
>> >
>>
>> MySQL, czy Postgres postawię sobie na Linuxie. Po cholere kupowac KOLEJNA
>> licencje MS zeby stawiac serwer bazy danych? (np. MSSQL).
>
> Po cholerę w ogóle myśleć MySQL vs. MSSQL, gdy chodzi o "bazę SQL"?
> Czy to będzie jedna, druga, czy trzecia, to można zdecydować się
> później. Wracając do analogii z montowaniem samochodu - to jak
> decydować na etapie projektu o marce używanych śrubek, czy kolorze
> obić siedzeń.

racja
>
> --
> Paweł Kierski
> news@pkierski.net
> dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
> albo koniecznie chcesz obejść moje filtry 8-)
>




Przemyslaw Osmanski - 14-08-2007 00:06

  Stachu 'Dozzie' K. pisze:

>> Kiedys byl jeszcze Kylix...
>
> ...który nie dość że kiepsko działał, to jeszcze nie był w pełni
> kompatybilny z Borland C++Builderem i z Delphi.

Dlatego tez, dyplomatycznie, nie rozwinąłem tego wątku ;)




Przemyslaw Osmanski - 14-08-2007 00:06

  Damian 'legion' Szuberski pisze:
>> ??? Cos mi sie wydaje ze Delphi to znasz ze slyszenia, albo zatrzymales
>> sie na rozwoju wersji tez w okolicach 5-6.
> Co do delfi - argumenty jak wyżej.

Przykro mi, to zadne argumenty dla Delphi. To co przedstawiłes powyżej,
to jedynie obiegowe teorie osob ktore z Delphi i z praktyka za duzo nie
miaja wspolnego.
Pozatym, w powyzszym nie bylo _zadnych_ powaznych i konkretnych
argumentow. Raczej wszystko wynikalo z nieznajomosci srodowiska.

pozdrawiam,
Przemek O.




Przemyslaw Osmanski - 14-08-2007 00:06

  Sebastian Bialy pisze:
> Mają jakieś inne cele poza pączkowianiem ? Tzn jakąś wizję co dalej z
> Delphi/BCB ?

Po pierwsze Borland, juz kilka razy zmienial nazwe, wiec zapewne to
jakis ich wewnetrzna potrzeba. Koniec koncow nic sie nie zmienilo, i nic
w planach sie nie zmienia.

>> VCL nie jest ".net compatibile" i nie bedzie.
> Czyli już idzie do piachu.

Wiesz cos wiecej? Win32 przestaje od ktoregos dnia dzialac? Jesli nie,
to ciekawe to stwierdzenie.

>> Delphi .NET jest natywne dla .NET + przeniesienie calego VCL na
>> platforme .NET.
> Czyli nie rozumiem: masz dodatkową warstwę pomiędzy kodem a .NET ? A po co?

Czyli to ze moze obslugiwac .NET w trybie natywnym + mozliwosc prostego
przeniesienia aplikacji VCLowych na platforme .NET z wykorzystaniem
komponentow VCL.NET.

> No własnie ani w ząb nie są.

Ok, rozumiem w takim razie, ze jak przenosisz aplikacje na nowa
platforme, to przepisujesz ja od zera?
Wiec chcialbym Cie poinformowac, ze mozna to zrobic prosciej, wybierajac
narzędzie lub produkt firmy, ktora sie zatroszczy o latwe przeniesienie
Twojej aplikacji... :/

<CIACH CALOSC>

>> Najpierw nalezy sie nauczyc myslec w odpowiedni sposob, a pozniej brac
>> sie za bardziej powazne sprawy.
>
> Czyli jak? Zaczynać pisanie aplikacji od wybrania interfejsu graficznego
> narzędzia developerskiego? Ja bym zaczął od projektu jądra liczącego
> transakcje księgowe, zależności obiektowych, szkieletu bazy danych,
> modelu dosepu urzytkowników. Ale ja się nie znam.
>
>> Jakos nie kreciloby mnie pisanie wprawkowych klas jako pierwsze
>> zadania z programowania. Wolalbym konkret, chocby jak owe czerwone
>> tło. Bo widac efekty.
>> Widac mamy inne podejście.
>
> Oczywiście. Niektórzy muszą mieć czerwone tło na formie w jednej linije.
> I dla nich powstało Delphi. Inni muszą mieć obiektowy model bazy danych

Nie rozumiesz Ci sie do Ciebie pisze? Tu chodzi o naukę programowania a
nie o rozpoczynanie projektu graficznego! Jesli chcesz kogos na poczatek
faszerowac informacjami tego typu, to rozumiem, ze podwazasz wogole
nauke podstaw typu pętle, ify, specyfika programowania obiektowego itd
itp. Bo wazniejszy na poczatek jest model obiektowy tak? Projekt jadra,
zaleznosci itd itp. Ja wiem ze po pewnym czasie, uwaza sie te sprawy za
podstawy, jednak zapewniam Cie, ze nigdzie nauka programowania nie
rozpoczyna sie od tego.

> z separacją od GUI. I dla nich Delphi nie powstało. Zgadnij którzy
> zarabiają więcej i pracują przy ciekawszych projektach ?

Sluchaj, nie chce mi sie juz tego powtarzac po raz kolejny. Model masz
taki, jaki sobie zaimplementujesz. Jesli nie potrafisz tego pojac, to
dajmy sobie moze spokoj z dyskusja na ten temat. Delphi to srodowisko,
ktore ma _mozliwosc_ uzycia VCLa (a nie przymus).
Co do zarobkow, to wydaje mi sie, ze statystycznie biorac, programista
Delphi zarabia wiecej ;) Chocby dlatego, ze tych od javy/c/c++ jest
narąbane od groma i jeszcze troche, co zaniza stawki (szczegolnie przez
studentow robiacych za piwo). Programow do rozwijania w Delphi jest dosc
duzo, a programistow malo. I tutaj juz tylko ekonomia rynkowa dziala.

pozdrawiam,




Sebastian Bialy - 14-08-2007 00:06

  Przemyslaw Osmanski wrote:
> Po pierwsze Borland, juz kilka razy zmienial nazwe, wiec zapewne to
> jakis ich wewnetrzna potrzeba. Koniec koncow nic sie nie zmienilo, i nic
> w planach sie nie zmienia.

Czyli dalej czekają aż ktoś kupi? Albo inaczej: wypączkowali firmę bo
nikt nie chciał kupić?

>>> VCL nie jest ".net compatibile" i nie bedzie.
>> Czyli już idzie do piachu.
> Wiesz cos wiecej? Win32 przestaje od ktoregos dnia dzialac? Jesli nie,
> to ciekawe to stwierdzenie.

Myślę, że pójdzie do piachu podobnie jak wiele innych swego czasu
powszechniych technologii. Nie bez powodu MS promuje .NET i raczej API
GUI z windowsa nie będzie rozwijane lub nie będzie bardziej rozwijane od
..NET. Skończy się to gorszym wyglądam aplikacji Win32 w porównaniu z
..NET a to powolna agonia dla apliakcji.

> Czyli to ze moze obslugiwac .NET w trybie natywnym + mozliwosc prostego
> przeniesienia aplikacji VCLowych na platforme .NET z wykorzystaniem
> komponentow VCL.NET.

Jeśli w celu migracji to: po dwóch latach "migracji" z VCL na .NET
dostaniemyt aplikację, któa logicznie jest identyczna z napisaną w C#
ale jednocześnie napisana w niszowym języku. A więc koszty utrzymania
rosną, bo programistów natywnych .NET jest coraz więcej a do Delphi
zaczynają wymierać. Stąd podejrzenie, że wybranie .NET z Delphi nie ma
żadnego sensu skoro jak już ktoś musi .NET to weźmie C# bo: firma
robiąca C# ma jakąś wizję i język jest obiektowy itd.

> Ok, rozumiem w takim razie, ze jak przenosisz aplikacje na nowa
> platforme, to przepisujesz ja od zera?

Jeśli logike masz zawartą w GUI to i tak musisz. Jeśli logikę masz
odseparowaną od GUI to nie. Może się nawet okazać, że jest to w sumie
proste o ile projektant wiedział co czyni.

> Nie rozumiesz Ci sie do Ciebie pisze? Tu chodzi o naukę programowania a
> nie o rozpoczynanie projektu graficznego!

Chcesz mi powiedzieć, że autor wątku jest wpłaśnie przypakiem "nauka
programowania"? On ma znacznie większe plany. Czemu ma od razu spieprzyć
na początku?

> Jesli chcesz kogos na poczatek
> faszerowac informacjami tego typu, to rozumiem, ze podwazasz wogole
> nauke podstaw typu pętle, ify, specyfika programowania obiektowego itd
> itp. Bo wazniejszy na poczatek jest model obiektowy tak? Projekt jadra,
> zaleznosci itd itp. Ja wiem ze po pewnym czasie, uwaza sie te sprawy za
> podstawy, jednak zapewniam Cie, ze nigdzie nauka programowania nie
> rozpoczyna sie od tego.

ROTFL. Gratuluje nauki programowania _nie_ zawierającej obiektów od
początku. Ja znam paru takich ludzi. Faktycznie, for w jednym palcu.
Gorzej jak trzeba zakumać intruzywny smartpointer albo stos iteratorów.
Na szczeście pracują przy projektach w których for jest jednym z
trudniejszych elementów ... nie to, że nie da się ich przerobić w
obiektowych. Da się. Ale większym kosztem niż nauczenie obiektowości od
początku.

A swoją drogą to rozumiem, że lepiej jest spieprzyć na początku a potem
męczyć się w przepisywanie niż zrobić od razu ok?

> Sluchaj, nie chce mi sie juz tego powtarzac po raz kolejny. Model masz
> taki, jaki sobie zaimplementujesz. Jesli nie potrafisz tego pojac, to
> dajmy sobie moze spokoj z dyskusja na ten temat. Delphi to srodowisko,
> ktore ma _mozliwosc_ uzycia VCLa (a nie przymus).

Jesli nie przymus uzywania VCL to teraz pytanie co w delphi pozostaje
poza VCL i jego klikaniem po formach? Tzn rezygnując z VCLa to co
pozostaje co powali mnie na kolana i odwróci tendencję do wybierania .NET?

> Co do zarobkow, to wydaje mi sie, ze statystycznie biorac, programista
> Delphi zarabia wiecej ;) Chocby dlatego, ze tych od javy/c/c++ jest
> narąbane od groma i jeszcze troche, co zaniza stawki (szczegolnie przez
> studentow robiacych za piwo). Programow do rozwijania w Delphi jest dosc
> duzo, a programistow malo. I tutaj juz tylko ekonomia rynkowa dziala.

Widziałeś gdzies dużo programistów w C++? W C++, nie w C z klasami.
Takich kumających szblony, wzorce, boosta? Dawaj namiar, z chęcią bym
paru polecił komuś. Na razie nie udało się zawielu trafić w miejscu
gdzie mieszka koło miliona ludzi.




Przemyslaw Osmanski - 14-08-2007 00:06

  Sebastian Bialy pisze:
> Czyli dalej czekają aż ktoś kupi? Albo inaczej: wypączkowali firmę bo
> nikt nie chciał kupić?

Ręce opadaja...

> Myślę, że pójdzie do piachu podobnie jak wiele innych swego czasu
> powszechniych technologii. Nie bez powodu MS promuje .NET i raczej API
> GUI z windowsa nie będzie rozwijane lub nie będzie bardziej rozwijane od
> .NET. Skończy się to gorszym wyglądam aplikacji Win32 w porównaniu z
> .NET a to powolna agonia dla apliakcji.

Pewie że pójdzie, prędzej czy później. Jednak i jedno i drugie jest dość
odległe w czasie. Vista miała byc systemem natywnie .NETowym, jednak nie
jest. Sam M$ opoznil odejscie Win32...

> Jeśli w celu migracji to: po dwóch latach "migracji" z VCL na .NET

Skad te 2 lata wziąłeś? Plus jest wlasnie takie, ze nie robisz owej
"migracji" bo polega ona na odczytaniu projektu w Delphi.NET i ew
modyfikacji tego co niestandardowe.

> dostaniemyt aplikację, któa logicznie jest identyczna z napisaną w C#
> ale jednocześnie napisana w niszowym języku. A więc koszty utrzymania
> rosną, bo programistów natywnych .NET jest coraz więcej a do Delphi
> zaczynają wymierać. Stąd podejrzenie, że wybranie .NET z Delphi nie ma
> żadnego sensu skoro jak już ktoś musi .NET to weźmie C# bo: firma
> robiąca C# ma jakąś wizję i język jest obiektowy itd.

No tak a Pascal jest strukturalny i liniowy :/

> Jeśli logike masz zawartą w GUI to i tak musisz. Jeśli logikę masz
> odseparowaną od GUI to nie. Może się nawet okazać, że jest to w sumie
> proste o ile projektant wiedział co czyni.

Mnie tego nie musisz mowic, moja ironiczna (w tym zakresie) odpowiedz,
dotyczyla tego, ze nie widzisz zalety powstania VCL.NET w momencie
przechodzenia na .NET.

>> Nie rozumiesz Ci sie do Ciebie pisze? Tu chodzi o naukę programowania
>> a nie o rozpoczynanie projektu graficznego!

Ten "graficzny" to nie wiem skad mi się wziął... Chyba myslalem o czyms
innym...

> Chcesz mi powiedzieć, że autor wątku jest wpłaśnie przypakiem "nauka
> programowania"? On ma znacznie większe plany. Czemu ma od razu spieprzyć
> na początku?

Po przeczytaniu pierwszego posta z watku i jednej z odpowiedzi,
wywnioskowalem ze jest na tym etapie.

> ROTFL. Gratuluje nauki programowania _nie_ zawierającej obiektów od
> początku. Ja znam paru takich ludzi. Faktycznie, for w jednym palcu.
> Gorzej jak trzeba zakumać intruzywny smartpointer albo stos iteratorów.
> Na szczeście pracują przy projektach w których for jest jednym z
> trudniejszych elementów ... nie to, że nie da się ich przerobić w
> obiektowych. Da się. Ale większym kosztem niż nauczenie obiektowości od
> początku.

ROTFL. Gratuluje wciskania osobom ktore nie znaja podstaw programowania,
typu podstawienia, petle, operatory itd itp, teorii obiektowosci itp.
Pozatym, czy ktos powiedzial, ze na owych for maja skonczyc nauke?

> Jesli nie przymus uzywania VCL to teraz pytanie co w delphi pozostaje
> poza VCL i jego klikaniem po formach? Tzn rezygnując z VCLa to co
> pozostaje co powali mnie na kolana i odwróci tendencję do wybierania .NET?

Po pierwsze, nie wiem co moze Cie 'powalic na kolana',
Po drugie, nikt nie nakazuje Tobie przechodzic na VCLa i produkty Borlanda.
Po trzecie, od zawsze stosowana praktyka, jest to, ze jezyk dobiera sie
do zadania, i ew. czynnikiem dodatkowym, moze byc doswiadczenie w jakims
srodowisku. A produkt jaki sie osiagnie jest tylko odzwierciedleniem
umiejetnosci programisty. Tak samo zreszta, jak okreslanie jakiegos
jezyka/srodowiska jako złe z założenia...

> Widziałeś gdzies dużo programistów w C++? W C++, nie w C z klasami.
> Takich kumających szblony, wzorce, boosta? Dawaj namiar, z chęcią bym
> paru polecił komuś. Na razie nie udało się zawielu trafić w miejscu
> gdzie mieszka koło miliona ludzi.

Nie wiem jak to jest u Ciebie, ale swego czasu jak szukałem
programistów, to na ogloszenia odpowiadali głównie Ci szczycący się
znajomością C/C++ i Javy pomimo, ze ogłoszenie było wyraźnie skierowane
do programistów Delphi i C#.(Chyba ze maja oni jakis problem z czytaniem
;) ). Jednego dobrego programiste Delphi musialem sciagac z Warszawy...
Ale w sumie mnie na tym bardzo zależało.

pozdrawiam,
Przemek O.




=?ISO-8859-2?Q?Rafa=B3?= Maj - 14-08-2007 00:06

  Sebastian Bialy <f9p6a5$b45$1@atlantis.news.tpi.pl> Monday, 13 August 2007
10:55

> Widziałeś gdzies dużo programistów w C++? W C++, nie w C z klasami.
> Takich kumających szblony, wzorce, boosta? Dawaj namiar, z chęcią bym
> paru polecił komuś.

Tutaj jestem :) rafal.maj at op.pl

Ale szukam drugiego, aktualnie nie pracującego jeszcze i ciężko faktycznie.




Adam =?iso-8859-2?Q?Wi=B6niecki?= - 14-08-2007 00:06

  On 2007-08-13, Sebastian Bialy <heby@poczta.onet.pl> wrote:

> Widziałeś gdzies dużo programistów w C++? W C++, nie w C z klasami.
> Takich kumających szblony, wzorce, boosta? Dawaj namiar, z chęcią bym
> paru polecił komuś. Na razie nie udało się zawielu trafić w miejscu
> gdzie mieszka koło miliona ludzi.

kiepsko szukasz albo słabo płacisz :)

--
Adam Wiśniecki




Sebastian Bialy - 14-08-2007 00:06

  Adam Wiśniecki wrote:
> kiepsko szukasz albo słabo płacisz :)

Dokładnie o to chodzi :) Dobry programista C++ zarabia całkiem
przyzwoite pieniądze. Znaleźć tanio można chyba wyłacznie C z klasami.




Sebastian Bialy - 14-08-2007 00:06

  Przemyslaw Osmanski wrote:
> Pewie że pójdzie, prędzej czy później. Jednak i jedno i drugie jest dość
> odległe w czasie. Vista miała byc systemem natywnie .NETowym, jednak nie
> jest. Sam M$ opoznil odejscie Win32...

Jest to nieuchronne. Dlatego argumentacja że Win32 jest fajny lub warto
na niego jeszcze coś rzeźbić nowego do mnie nie trafia.

>> Jeśli w celu migracji to: po dwóch latach "migracji" z VCL na .NET
> Skad te 2 lata wziąłeś?

Wyssałem z palca.

> Plus jest wlasnie takie, ze nie robisz owej
> "migracji" bo polega ona na odczytaniu projektu w Delphi.NET i ew
> modyfikacji tego co niestandardowe.

Czyli VCL emuluje stare zachowanie na nowym .NET czy tak? Bo nie
wyobrażam sobie, żeby Delphi .NET potrafiło samoczynnie zrobić
refaktoring kodu wprost na .NET tym bardziej, że aplikacjie pisane w
Delphi w większości mają zaszytą logikę w części wizualnej. Skoro
emuluje to jedyny zysk jest taki, że masz od razu "prawie .NET ale po
staremu". Wadą jest fakt, że to dalej VCL z możliwościami i wadami VCL.
Jak by nie patrzeć: ja wole rozpocząć natywną plikajcę .NET w C# i nie
martwić się emulacją GUI i problemami z tego wynikającymi. Oczywiście
jest zupełnie inne pytanie czy w .NET warto pisać, bo to nieprzenośne.
Ale dalej nie widze zysku z rozpoczynaniu projektu w Delphi i pisaniu na
emulowanym VCL coś co można mieć z palca w .NET. Przypominam że autor
nie ma nic, chce rozpocząć nowy projekt. Dla niego argumentacja o
migracji jest średnio trafiona.

> No tak a Pascal jest strukturalny i liniowy :/

Nie jest tylko oczywiście. Ale jest w większości wypadków pisania w
Delphi właśnie taki. Bo i Delphi takie jest - mało obiektowe. Nawet VCL
używa obiektów ale nie jest jakoś bardzo obiektowy. Zwróć uwagę, że Java
choćby wymusza obiektowość nawet nie w związku ze składnią ale z
bibliotekami w języku. Tam wszystko jest obiektowe i dlatego świadomość
i umiejętność pisania obiektowego jest większa dla Javowca niż
drag'n'drop operatora Delphi. A trudno przecenić tą umiejętnośc nawet w
tępym programie księgowym.

> Mnie tego nie musisz mowic, moja ironiczna (w tym zakresie) odpowiedz,
> dotyczyla tego, ze nie widzisz zalety powstania VCL.NET w momencie
> przechodzenia na .NET.

Nie. Ja nie widzę zalet pisania w Delphi nowego projektu i potem
męczenia się z przechodzeniem na .NET kiedy można wziąść od razu .NET.
Cały czas kręcimy się wokół twojej sugesti "co w zamian". No wiec na
pewno nie Delphi.

> Po przeczytaniu pierwszego posta z watku i jednej z odpowiedzi,
> wywnioskowalem ze jest na tym etapie.

To by pisał o Hello World. Zakładam, że for ma opanowane skoro porywa
się na taką aplikację.

> ROTFL. Gratuluje wciskania osobom ktore nie znaja podstaw programowania,
> typu podstawienia, petle, operatory itd itp, teorii obiektowosci itp.

Obiektowość to już dawno nie jest teoria. To czysta praktyka. I wiesz
co, masz pecha, bo ja akurat tak edukowałem paru ludzi. I wiesz co, oni
naprawdę przeżyli. Ba, nawet zakumali. I dla nich jest oczywiste
dlaczego zamiast for( i=0 ...) należy wziąść iterator na kolekcje.

> Pozatym, czy ktos powiedzial, ze na owych for maja skonczyc nauke?

Jak wybierze Delphi to za daleko nie pojedzie. Poza żałosnym VCL reszta
tego "środowiska" jest szczątkowo obiektowa. A sam VCL raczej do
nowoczesnych nie należy.

> Po pierwsze, nie wiem co moze Cie 'powalic na kolana',

Cokolwiek co spowoduje, że program księgowy można napisać
lepiej/sprawniej/taniej/szybciej w Delphi a nie w .NET/whatever. Przy
czym zakładam, że potrafi on coś więcej niż wyświetlać tabelki z bazy
danych w kolorowych okienkach.

> Po drugie, nikt nie nakazuje Tobie przechodzic na VCLa i produkty Borlanda.

Dokładnie. Dlatego rozstałem się 2 lata temu z BCB stwierdzająć, że nie
warto dalej tracić szarych komórek obchodząć błędy kompilatora i marny
debugger. Już nawet gcc dawno temu przerosło jakościowo kod generowany
przez BCB. No chyba że w nowych BCB coś się zasadniczo zmieniło.

> Po trzecie, od zawsze stosowana praktyka, jest to, ze jezyk dobiera sie
> do zadania, i ew. czynnikiem dodatkowym, moze byc doswiadczenie w jakims
> srodowisku.

Więc dobierzmy go do zadania. Delphi jest jednym z kandydatów. BCB
również. IMHO obydwa padają w konkurencji z Javą lub .NET. Argumentów
jest bez liku, wiele padło w tej dyskusji.

> A produkt jaki sie osiagnie jest tylko odzwierciedleniem
> umiejetnosci programisty. Tak samo zreszta, jak okreslanie jakiegos
> jezyka/srodowiska jako złe z założenia...

Nie. Oczywiscie można napisać to w asemblerze. Albo w Fortranie. Ale nie
jest do dobre rozwiązanie choćby z powodu takiego jak cała otoczka
języka. Goytowe wzorce i biblioteki rozwiązujące typowe problemy. Delphi
poza okienkami i bazami danych (obydwa w ograniczonym zakresie) nie ma
nic innego w tle co było by godne uwagi. Środowiska do programowania i
języki jak choćby NetBeans/Java dawno mają znacznie więcej i taniej.
Zarówno pod kątem developingu jak i runtime. Gdzie jest tez zysk w
Delphi który powoduje że jest to killer-app dla .NET/Java ?

> Nie wiem jak to jest u Ciebie, ale swego czasu jak szukałem
> programistów, to na ogloszenia odpowiadali głównie Ci szczycący się
> znajomością C/C++ i Javy pomimo, ze ogłoszenie było wyraźnie skierowane
> do programistów Delphi i C#.(Chyba ze maja oni jakis problem z czytaniem
> ;) ). Jednego dobrego programiste Delphi musialem sciagac z Warszawy...
> Ale w sumie mnie na tym bardzo zależało.

Mała uwaga: z doświadczenia nieswojego wiem, że lepszy jest _dobry_
(podkreślam) programista C++ posadzony za NetBeans/Delphi niż dobry
programista Delphi posadzony za C++. Zupełnie inne style myślenia -
wynikające z zupełnie innych styli programowania.




ZbyszekZ - 16-08-2007 00:01

  On Aug 9, 2:47 am, "vit" <vitek...@Interia.pl> wrote:
> > Pomijając inne kwestie - chcesz być konkurencyjny i miec indywidualne
> > podejscie do klienta za zarobki <1200zl/rok? :)
>
> Przyznasz, ze glowka pracuje ;-)

I ręce pracują i nogi a najgorszy jest żołądek - najszybciej chce
jeść, a najeść się za 100 zł / miesiąc to dosyć trudne.

--
ZZ@private




ZbyszekZ - 16-08-2007 00:01

  On Aug 13, 12:00 pm, Przemyslaw Osmanski <przeme...@cos.gdzies.pl>
wrote:
> Sebastian Bialy pisze:
>
> > Czyli dalej czekają aż ktoś kupi? Albo inaczej: wypączkowali firmę bo
> > nikt nie chciał kupić?
>
> Ręce opadaja...
>

A nogi całkiem poniżej pasa.
Gratuluję Przemku cierpliwości przy zderzeniu z betonem :-)

A co do meritum sporu padło w tej dyskusji kilka razy:
NARZEDZIE DOBIERA SIE DO ZADANIA

Jak się zdefiniuje wszystkie konieczne wymagania to się okaże co jest
potrzebne.

--
ZZ@private
PS1. Delphi wprowadziło model-view-contoler ok. roku 1997, wraz z
Delphi 2
PS2. Pierwszą warstwą abstrahującą typy danych jest biblioteka VCL
PS3. Borland robi dobre narzędzia ale ma problemy innej natury




Sebastian Bialy - 16-08-2007 00:01

  ZbyszekZ wrote:
> Gratuluję Przemku cierpliwości przy zderzeniu z betonem :-)

No bez przesady :) zadziorny jestem, ale z betonu to jeszcze nie :P

> Jak się zdefiniuje wszystkie konieczne wymagania to się okaże co jest
> potrzebne.

Może starczy "nawet" Access ... ja tylko zwracam uwagę że sugerowanie
narządu programistycznego o zagadkowej przyszłości i średniej jakości
nie jest najlepszym pomysłem szczególnie dla początkujących.

> PS1. Delphi wprowadziło model-view-contoler ok. roku 1997, wraz z
> Delphi 2

<ziew>. Jakieś chyba słabo popularne wśród drag'n'drop operators skoro
nie ma śladu (no, może pare) w sieci czegokolwiek na ten temat w związku
z VCL/Delphi (choć pytanie czy to niedociągnięcie autorów wikipedii):

http://en.wikipedia.org/wiki/Model-view-controller.

Chyba się jednak nie przyjeło. Zapewne dlatego że Delphi nie wymusza
takiego stylu programowania.

> PS2. Pierwszą warstwą abstrahującą typy danych jest biblioteka VCL

Hmm.. a tego nie rozumiem. VCL ma coś w rodzaju std::vector< foo >? Może
chodzi Ci o Variant? A może o jakąś inną "warstwę"? Możesz rozwinąć?

> PS3. Borland robi dobre narzędzia ale ma problemy innej natury

Borland robił. Pare lat temu. Dzisiaj już jest troche zapóźniony. Reszta
świata mocno się rozwineła. Dzisiaj drag'n'drop na formę mają wszyscy.
Poza tym drag'n'drop to w zasadzie nie ma nic specjalnego w środku.
Konkurenci .NET/Java mają bardziej rozwinięte zewnątrzne biblioteki
wspomagające pisanie kodu i logiki. Swoją drogą skończy się pewno na
tym, że Delphi przekształci się w jeszcze jeden język dla .NET bez
specjalnych cech wyróżniających go od reszty.




ZbyszekZ - 16-08-2007 00:01

  On Aug 15, 11:14 pm, Sebastian Bialy <h...@poczta.onet.pl> wrote:
> ZbyszekZ wrote:
> > Gratuluję Przemku cierpliwości przy zderzeniu z betonem :-)
>
> No bez przesady :) zadziorny jestem, ale z betonu to jeszcze nie :P
>

Raczej jednak zmień zdanie o sobie.
W XXI wieku narzędzie programisty ma minimalne znaczenie, tak samo jak
biblioteki, vectory i co tam jeszcze.
Jesli chodzi o warsztat programisty to jest on bardzo dobrze
zautoamtyzowany i jesli tylko wiadomo co trzeba zrobic to sie zrobi.
Problemem jest ustalenie co, a nie jak, juz nie mowiac o czym.

> > Jak się zdefiniuje wszystkie konieczne wymagania to się okaże co jest
> > potrzebne.
>
> Może starczy "nawet" Access ... ja tylko zwracam uwagę że sugerowanie
> narządu programistycznego o zagadkowej przyszłości i średniej jakości
> nie jest najlepszym pomysłem szczególnie dla początkujących.

Uzasadnij dlaczego sugerowanie sie swoimi umiejetnosciami przy
podejmowaniu nowego zadania jest zlym pomyslem?
Sugerujesz, ze jak nowy problem to trzeba zwiekszac ryzyko przez
wprowadzenie jednoczesnie nowego jezyka bez innych powodow? Dosyc bym
powiedzial brawurowe (robie sie delikatny na stare lata)

>
> > PS1. Delphi wprowadziło model-view-contoler ok. roku 1997, wraz z
> > Delphi 2
>
> <ziew>.

<ziew>

>
> > PS2. Pierwszą warstwą abstrahującą typy danych jest biblioteka VCL
>
<ziew>

> > PS3.

<ziew>

Nudzisz o kompletnie nieistotnych szczegolach.
Jak chcesz pogadac o Borlandzie to ... albo lepiej nie, bo całkiem sie
z BSC pokłócę ;-)

--
ZZ@private




Sebastian Bialy - 17-08-2007 00:02

  ZbyszekZ wrote:
> W XXI wieku narzędzie programisty ma minimalne znaczenie, tak samo jak
> biblioteki, vectory i co tam jeszcze.

Hmmm to dość kontrowersyjne podejście. A co ma znaczenie? Można mieć
świetny projekt, ale jeśli nie masz gotowych rozwiązań podanych na tacy
w środowisku to projekt padnie. Chyba nie zamierzasz na nowo pisać
wszystkiego skoro "biblioteki nie mają znaczenia"? Przypomina mi to
pracę jednego kolegi rzeźbiącego w Delphi od 4 lat. Napisał sobie
całkowicie na nowo bibliotekę której potrzebował marnując koło roku choć
można znaleźć identyczną funkcjonalnie w Javie. Powód był prosty: w
czasie wyboru języka nie przewidziano wszystkiego. I nagła potrzeba
rozbiła się o braki w języku podnosząc znacznie koszty projektu.

> Jesli chodzi o warsztat programisty to jest on bardzo dobrze
> zautoamtyzowany i jesli tylko wiadomo co trzeba zrobic to sie zrobi.

W pewnym sensie taką automatyzację uzyskasz tylko do zadań trywialnych.
Trudniejsze projekty nie są łatwe do automatyzacji. Np. program księgowy
będzie wymagał testów jednostkowych logiki liczącej. Bo nie wyobrażam
sobie pisania go bez testów. Tutaj można rzeźbić własne rozwiązania, ale
są też języki wspierające tą koncepcję. Wydaje mi się, że łatwiej
wybrać jakiś wspierający. Nie rozmiem więc dlaczego wybór
języka/środowiska ma nie mieć znaczenia.

> Nudzisz o kompletnie nieistotnych szczegolach.

:D Mamy dość rozbierzne pojęcie o istotności elementów języka. Dla mnie
fakt, że std::vector< foo > x; x[4] jes typu foo ma kolosalne znaczenie
dla utrzymania i bezbłędności kodu.




Przemyslaw Osmanski - 17-08-2007 00:02

  Sebastian Bialy pisze:
> Jest to nieuchronne. Dlatego argumentacja że Win32 jest fajny lub warto
> na niego jeszcze coś rzeźbić nowego do mnie nie trafia.

Ja to widze troche inaczej. Jestem po wiekszej czesci obligowany do
uzywania tego co uzywaja klienci. Ich oprogramowaniem, ich sprzetem itd
itp. Niestety .NET jak i inne jezyki pseudokompilowane (do kodu
posredniego) sa wolniejsze w porownaniu z natywnym kodem. Wiec póki co
zostaje na win32. Oczywiscie musze sie przygladac .NETowi, ale powiedzmy
sobie szczerze, ze dopiero jego druga wersja do czegos konkretnego sie
nadawala, a tak naprawde to trzecia jest warta uwagi.

> Czyli VCL emuluje stare zachowanie na nowym .NET czy tak? Bo nie
> wyobrażam sobie, żeby Delphi .NET potrafiło samoczynnie zrobić
> refaktoring kodu wprost na .NET tym bardziej, że aplikacjie pisane w
> Delphi w większości mają zaszytą logikę w części wizualnej. Skoro
> emuluje to jedyny zysk jest taki, że masz od razu "prawie .NET ale po
> staremu". Wadą jest fakt, że to dalej VCL z możliwościami i wadami VCL.

Tak, bo o to chodzi w przenosnosci... Idac tym tropem, zastosowanie
alternatywnego GUI dla Windowsa tez dziala na zasadzie emulacji :)

Co do logiki programu w Delphi, to juz kilkakrotnie napisalem, ze jesil
ktos pisze taka aplikacje w sposob uniemozliwiajacy rozdzielenie GUI od
logiki to naprawde nie ma wiekszego pojecia o pisaniu poza klikaniem.
Natomiast nie ma problemu zeby pisac w sposob ktory umozliwia taka
separacje. Zreszta wiekszosc aplikacji 'powaznych' jest tak pisana, a
samo GUI poza przypadkami w ktorych musi byc recznie zaprojektowane,
jest generowane dynamicznie. Wiec juz z tego powodu nie do konca mozna
zrobic takie sztywne powiazanie o ktorym piszesz.

> Jak by nie patrzeć: ja wole rozpocząć natywną plikajcę .NET w C# i nie
> martwić się emulacją GUI i problemami z tego wynikającymi. Oczywiście
> jest zupełnie inne pytanie czy w .NET warto pisać, bo to nieprzenośne.
> Ale dalej nie widze zysku z rozpoczynaniu projektu w Delphi i pisaniu na
> emulowanym VCL coś co można mieć z palca w .NET. Przypominam że autor
> nie ma nic, chce rozpocząć nowy projekt. Dla niego argumentacja o
> migracji jest średnio trafiona.

Nie ma tez informacji o checi przenosnosci, wiec argumentacja o
nieprzenosnosci .NETu tez jest chybiona. W tym momencie nalezaloby
wybrac srodowisko i jezyk w ktorym autor czuje sie najlepiej.

> Nie jest tylko oczywiście. Ale jest w większości wypadków pisania w
> Delphi właśnie taki. Bo i Delphi takie jest - mało obiektowe. Nawet VCL
> używa obiektów ale nie jest jakoś bardzo obiektowy. Zwróć uwagę, że Java

Jest, tylko ze nie 'świeci' tą obiektowościa jak java na lewo i prawo.

> choćby wymusza obiektowość nawet nie w związku ze składnią ale z
> bibliotekami w języku. Tam wszystko jest obiektowe i dlatego świadomość
> i umiejętność pisania obiektowego jest większa dla Javowca niż
> drag'n'drop operatora Delphi. A trudno przecenić tą umiejętnośc nawet w
> tępym programie księgowym.

A u sie zgodze. Faktycznie niewymagalnosc podejscia czysto obiektowego
rozleniwia i uczy zlych nawykow na poczatku (jesli chodzi o Delphi).
Choc faktycznie wszystko co piszemy jest zaszyte w obiektach. Byc moze
ten typ programowania powinien sie nazywac - obiektowo-zdarzeniowym.
Niemniej, nie wyobrazam sobie pisania aplikacji bez podejscia klasowo
obiektowego i rozlacznosci logiki od gui, a pracuje wlasnie w Delphi :)
Wiec argumenty ze sie nie da, ze nie mozna, wkladamy miedzy bajki.

> Nie. Ja nie widzę zalet pisania w Delphi nowego projektu i potem
> męczenia się z przechodzeniem na .NET kiedy można wziąść od razu .NET.
> Cały czas kręcimy się wokół twojej sugesti "co w zamian". No wiec na
> pewno nie Delphi.

Widze, ze piszac projekty, wyznajesz zasade: "Program dziala wolno? Kup
sobie Pan lepszy komputer!". Coz, ja jestem przyzwyczajony do innego
podejscia. Program mozna zoptymalizowac i zmusic do szybszego dzialania
na inne sposoby, niz kupno nowego komputera. A niestety ogladajac nowe
programy coraz czesciej wydaje mi sie, ze ta umiejetnosc zostala
zatracona na rzecz nie do konca potrzebnej przenosnosci (dla samej w
sobie) i pewnego poziomu abstrakcyjnosci.

> Obiektowość to już dawno nie jest teoria. To czysta praktyka. I wiesz
> co, masz pecha, bo ja akurat tak edukowałem paru ludzi. I wiesz co, oni
> naprawdę przeżyli. Ba, nawet zakumali. I dla nich jest oczywiste
> dlaczego zamiast for( i=0 ...) należy wziąść iterator na kolekcje.

Jak uczysz kogos czytac to tez zaczynasz od encyklopedi? Czy moze jednak
od pojedynczych literek?
Jak to pierwsze, to w sumie nie dziwie sie, dlaczego niektorzy czytaja
wyrazami...

> Jak wybierze Delphi to za daleko nie pojedzie. Poza żałosnym VCL reszta
> tego "środowiska" jest szczątkowo obiektowa. A sam VCL raczej do
> nowoczesnych nie należy.

Powtarzasz sie, a argumentow poza ogolnikami jak nie ma tak nie ma.

> Cokolwiek co spowoduje, że program księgowy można napisać
> lepiej/sprawniej/taniej/szybciej w Delphi a nie w .NET/whatever. Przy
> czym zakładam, że potrafi on coś więcej niż wyświetlać tabelki z bazy
> danych w kolorowych okienkach.

Dla mnie? Znajmosc jezyka i srodowiska ( i to nie tego sprzed kilku lat).

> Więc dobierzmy go do zadania. Delphi jest jednym z kandydatów. BCB
> również. IMHO obydwa padają w konkurencji z Javą lub .NET. Argumentów
> jest bez liku, wiele padło w tej dyskusji.

Dla mnie nie ma zadnych, a pierwszy przeciw to taki i ze i java i .NET
nie daja kodu natywnego. Dla mnie to wystarczy, bo nie lubie spowalniac
oprogramowania przez wykonywanie na wirtualnych maszynach
pseudokompilowanego kodu.

> języka. Goytowe wzorce i biblioteki rozwiązujące typowe problemy. Delphi
> poza okienkami i bazami danych (obydwa w ograniczonym zakresie) nie ma
> nic innego w tle co było by godne uwagi. Środowiska do programowania i
> języki jak choćby NetBeans/Java dawno mają znacznie więcej i taniej.

Hmm... Troche mieszasz. Piszesz ze niby Delphi nie ma bibliotek.
Pierwsza wieksza (i darmowo) jest chocby jcl, tona komponentow (ktore
tez sa bibliotekami, tylko troche łatwiejszymi w obsludze).

A ogolnie to porownujesz gole srodowisko Delphi z innymi wyposażonymi w
liczne dodatki typu biblioteki GUI i inne.

> Mała uwaga: z doświadczenia nieswojego wiem, że lepszy jest _dobry_
> (podkreślam) programista C++ posadzony za NetBeans/Delphi niż dobry

Przy zalozeniu ze znaja tylko jeden jezyk programowania.

> programista Delphi posadzony za C++. Zupełnie inne style myślenia -
> wynikające z zupełnie innych styli programowania.

O czym Ty wlasciwie piszesz. Ty tak pisales programy w BCB? Wiec nie
przypisuj tego ogółowi, bo taki styl jest specyficzny dla poczatujacych
lub studentow (tych przeslizgujacych sie). Powazne aplikacje pisane sa z
pelna obiektowoscia i pelnym troj rozwarstwieniem.

pozdrawiam,
Przemek O.




ZbyszekZ - 17-08-2007 00:02

  On Aug 16, 7:28 am, Sebastian Bialy <h...@poczta.onet.pl> wrote:
> ZbyszekZ wrote:
> > W XXI wieku narzędzie programisty ma minimalne znaczenie, tak samo jak
> > biblioteki, vectory i co tam jeszcze.
>
> Hmmm to dość kontrowersyjne podejście. A co ma znaczenie? Można mieć
> świetny projekt, ale jeśli nie masz gotowych rozwiązań podanych na tacy
> w środowisku to projekt padnie.

Czyli co nie piszemy nic w kodzie, bo przecież SAP czy inne mają to
gotowe i to na znacznie wyższym poziomie?

> można znaleźć identyczną funkcjonalnie w Javie. Powód był prosty: w
> czasie wyboru języka nie przewidziano wszystkiego. I nagła potrzeba
> rozbiła się o braki w języku podnosząc znacznie koszty projektu.

Udowodnij prosze ze projektujac Jave czy inny C# wszystko
przewidziano.

>
> > Jesli chodzi o warsztat programisty to jest on bardzo dobrze
> > zautoamtyzowany i jesli tylko wiadomo co trzeba zrobic to sie zrobi.
>
> W pewnym sensie taką automatyzację uzyskasz tylko do zadań trywialnych.

Co dla kogo jest zadaniem trywialnym to dosyc trudne do okreslenia.
Dla mnie trywialne jest wprowadzenie obiegu dokumentów zmiany w sofcie
z zadbaniem o wazne detale takie jak ocena i zapewnienie budzetu,
kontrola stanu prac i wydatkow, przygotowanie we wlasciwym czasie
zasobow do testowania.

> Trudniejsze projekty nie są łatwe do automatyzacji. Np. program księgowy
> będzie wymagał testów jednostkowych logiki liczącej. Bo nie wyobrażam
> sobie pisania go bez testów.

Czego program ksiegowy bedzie wymagal?
A znasz ksiegowego lub ksiegowa ktora napisze Ci testy jednostkowe?
Bo jesli to Ty napiszesz testy do swojego kodu to poza tym ze kod robi
co Ty chcialesz niczego innego nie przetestujesz.

> Tutaj można rzeźbić własne rozwiązania, ale
> są też języki wspierające tą koncepcję. Wydaje mi się, że łatwiej
> wybrać jakiś wspierający. Nie rozmiem więc dlaczego wybór
> języka/środowiska ma nie mieć znaczenia.
>

Jesli chodzi o unit testy to faktycznie sa np. Delphi :-)))

> > Nudzisz o kompletnie nieistotnych szczegolach.
>
> :D Mamy dość rozbierzne pojęcie o istotności elementów języka.. Dla mnie
> fakt, że std::vector< foo > x; x[4] jes typu foo ma kolosalne znaczenie
> dla utrzymania i bezbłędności kodu.

Wytlumacz jakie to ma znaczenie dla magazyniera?

--
ZZ@private




Sebastian Bialy - 17-08-2007 00:02

  Przemyslaw Osmanski wrote:
> Ja to widze troche inaczej. Jestem po wiekszej czesci obligowany do
> uzywania tego co uzywaja klienci. Ich oprogramowaniem, ich sprzetem itd
> itp. Niestety .NET jak i inne jezyki pseudokompilowane (do kodu
> posredniego) sa wolniejsze w porownaniu z natywnym kodem.

http://www.kano.net/javabench/ jako kontrprzykład, pamiętaj że bytecode
może być ale nie musi. Zależy od implementacji, nie widze problemu z
kompilacją Javy do kodu natywnego. Co do powyższego testu nie wiem czy
jest wiarygodny, ale widziałem już wiele testów pokazujacych że
optymalizacja w locie może prześcignąć C++. I nawet w to wierze.

Ale mówiąc serio - w aplikacjach GUI chyba najiększe znaczenie ma
prawidłowy projekt. Szybkość środowiska jest drugorzędna choć przyznaje
że swing jest mocno w tyle.

> Wiec póki co
> zostaje na win32. Oczywiscie musze sie przygladac .NETowi, ale powiedzmy
> sobie szczerze, ze dopiero jego druga wersja do czegos konkretnego sie
> nadawala, a tak naprawde to trzecia jest warta uwagi.

Więc skąd ta migracja w dużej skali na .NET i ten wysyp ofert pracy?
Oczywiście ja też złośliwie twierdze że to jest nieprzemyślane ale ...
najwidoczniej da się z tym pracować na tyle skutecznie żeby opłacało się.

> Co do logiki programu w Delphi, to juz kilkakrotnie napisalem, ze jesil
> ktos pisze taka aplikacje w sposob uniemozliwiajacy rozdzielenie GUI od
> logiki to naprawde nie ma wiekszego pojecia o pisaniu poza klikaniem.

Masz rację oczywiście. Pytanie co ma Delphi lepszego w tym temacie od
takiej Javy. Bo jeśli nic lepszego to odpada potencjalny argument o
lepszości Delphi w tym względzie. A to że można to ja wiem.

> Natomiast nie ma problemu zeby pisac w sposob ktory umozliwia taka
> separacje. Zreszta wiekszosc aplikacji 'powaznych' jest tak pisana, a
> samo GUI poza przypadkami w ktorych musi byc recznie zaprojektowane,
> jest generowane dynamicznie. Wiec juz z tego powodu nie do konca mozna
> zrobic takie sztywne powiazanie o ktorym piszesz.

No wiesz, dynamicznośc to tylko mały element całości. Tu bardziej chodzi
o pewne techniki obiektowego programowania. Dla mnie największszym
zawsze przykładem będzie drzewo jako chyba najbardziej skompikowana
standardowa kontrolka GUI. Jeśli jest zrobione dobrze, to możesz uzyskać
dowolne efekty. Jesli jest zrobione marnie (np. na liczbowych handlach
elementów) to masz przekichane na starcie. Ja nie twierdze, że VCL jest
jakiś porażająco denny. Ale jest marny - popełniłem w tym pare
komponentów i jakoś mnie nie przekonał do obiektowości tak jak Swing. Z
resztą nie wiem czy dobrze pamiętam, ale gdzieś mi się obiło o oczy, że
VCL był elementem z którego Swing wyciągnął pewne koncepcje i dodał masę
nowych.

> Nie ma tez informacji o checi przenosnosci, wiec argumentacja o
> nieprzenosnosci .NETu tez jest chybiona. W tym momencie nalezaloby
> wybrac srodowisko i jezyk w ktorym autor czuje sie najlepiej.

Owszem, być może autor chce powiązać się z windowsem na stałe. Mono na
razie chyba w grę nie wchodzi bo są ciągle "za pół roku". Inna sprawa
czy to politycznie słuszna decyzja, bo może kiedyś będzie chciał program
wyposarzyć w interfejs webowy. I wtedy będzie dopiero kłopot mając
logikę biznesową w pascalu ...

> Jest, tylko ze nie 'świeci' tą obiektowościa jak java na lewo i prawo.

Świecenie jest mocno wskazane - to siła tego języka.

> Choc faktycznie wszystko co piszemy jest zaszyte w obiektach. Byc moze
> ten typ programowania powinien sie nazywac - obiektowo-zdarzeniowym.

Nie chodzi o fakt, że używasz class. Chodzi bardziej o to czy język
wprost ma gotowe kontenery z dostępem przez iteratory, wspomaga
tworzenie sensownej struktury zależności itd. Sam fakt, że tu i tam sa
jakieś class'y nic nie mówi o obiektowości języka (a w zasadzie środowiska).

> Niemniej, nie wyobrazam sobie pisania aplikacji bez podejscia klasowo
> obiektowego i rozlacznosci logiki od gui, a pracuje wlasnie w Delphi :)

Ależ wszystko można. Ale w delphi tak łatwo się pisze Label1:="dupa"...
Obawiam się że autor prędzej czy później taki właśnie kod wygeneruje -
bo można.

> Wiec argumenty ze sie nie da, ze nie mozna, wkladamy miedzy bajki.

Nie twierdzę że nie można. W assemblerze też można. I co z tego?

> Widze, ze piszac projekty, wyznajesz zasade: "Program dziala wolno? Kup
> sobie Pan lepszy komputer!". Coz, ja jestem przyzwyczajony do innego
> podejscia. Program mozna zoptymalizowac i zmusic do szybszego dzialania
> na inne sposoby, niz kupno nowego komputera.

A już na pewno na inne sposoby niż wybór kompilatora czy formy
wykonywania kodu. A swoją drogą podobny pogląd miało wielu programistów
C kiedy po raz pierwszy zobaczyli C++ - "co pan panie, to strasznie
powolne jest, ja tam wole (void*)ptr".

> A niestety ogladajac nowe
> programy coraz czesciej wydaje mi sie, ze ta umiejetnosc zostala
> zatracona na rzecz nie do konca potrzebnej przenosnosci (dla samej w
> sobie) i pewnego poziomu abstrakcyjnosci.

Przenośność nie służy tylko temu abyś mógł odpalać program księgowy na
Linuxie i Windowsie. Przenośność ma większą zaletę: być może z czasem
stworzysz/wyewoluujesz aplikacje kilent-server z dostępem zdalnym na
bazie sprawdzonej logiki. I zostaniesz z kupą kodu napisanym z niszowym
języku i potrzebą wciśnięcia tego na serwer który (olaboga!)
niekoniecznie jest windowsowy. Dlaczego chcesz od razu strzelić sobie
samobója tylko dla sentymentów dla jakiegoś języka? To już lepiej wziąść
BCB bo przynajmniej logikę da się jako-tako wyjąć. Swoją drogą widziałem
już projekt przenoszony z BCB na unixa w którym pisano masę kodu
emulującego AnsiStringa i kupę innych klas. Dziękuje, postoje.

Oczywiście można założyć że nigdy nie wyjmiemy tego na zewnątrz, zdaje
sobie sprawę. Ja również z tego że aplikacja prawdopodobnie nigdy nie
powstanie i rozmawiamy nad pustą trumną.

>> Obiektowość to już dawno nie jest teoria. To czysta praktyka. I wiesz
>> co, masz pecha, bo ja akurat tak edukowałem paru ludzi. I wiesz co,
>> oni naprawdę przeżyli. Ba, nawet zakumali. I dla nich jest oczywiste
>> dlaczego zamiast for( i=0 ...) należy wziąść iterator na kolekcje.

> Jak uczysz kogos czytac to tez zaczynasz od encyklopedi? Czy moze jednak
> od pojedynczych literek?

Uczę np. że jeśli mam kontener to aby przez niego przejśc należy wziąść
iterator i się przeiterować a nie brać for. Z prostej przyczyny, bo
jeśli weźmiesz std::list<foo> to w zasadzie ... nie ma innej metody.
Dlaczego mam uczyć jednego, szczególnego przypadku zamiast ogólnego,
działającego zawsze, i o dziwo o wyższej wydajności (!)? Absolutnie nie
rozumiem czemu należy na początku uczyć jak zrobić źle i niewygodnie
zamiast dobrze i wygodnie.

> Hmm... Troche mieszasz. Piszesz ze niby Delphi nie ma bibliotek.
> Pierwsza wieksza (i darmowo) jest chocby jcl, tona komponentow (ktore
> tez sa bibliotekami, tylko troche łatwiejszymi w obsludze).

Ależ jest zapewne na kilogramy tego wszystkiego na Delphi. Tylko
zastanawia mnie co będzie się i jak dynamicznie rozwijać zważywszy że
Borland usiłował (usiłuje?) komuś to Delphi sprzedać. Jaką masz
gwarancje, że za 2 lata w ogóle coś będzie ewoluować? A tak, Delphi
..NET. No i tu znowu: to po co Delphi skoro można C#?

> A ogolnie to porownujesz gole srodowisko Delphi z innymi wyposażonymi w
> liczne dodatki typu biblioteki GUI i inne.

Wiesz, goła Java jest całkiem bogata. I za friko. I ma GUI. Całkiem fajne.

>> Mała uwaga: z doświadczenia nieswojego wiem, że lepszy jest _dobry_
>> (podkreślam) programista C++ posadzony za NetBeans/Delphi niż dobry

> Przy zalozeniu ze znaja tylko jeden jezyk programowania.

Znajomośc (dobra) C++ w wielu wypadkach jest przepustką do znajomości
wielu innych języków (w tym o semantyce referencji) prawie bez nakładu
środków.




Sebastian Bialy - 17-08-2007 00:02

  ZbyszekZ wrote:
> Czyli co nie piszemy nic w kodzie, bo przecież SAP czy inne mają to
> gotowe i to na znacznie wyższym poziomie?

Nie piszemy tego co już dawno napisano za nas. Ja jakoś nie mam ochoty
wymyślać hash_multimapy od nowa mimo że to drobna pierdoła. Ja ją po
prostu biorę. Podobnie jak coraz więcej gotowych elementów
biblitecznych. To oczywiste.

> Udowodnij prosze ze projektujac Jave czy inny C# wszystko
> przewidziano.

Doskonale wiesz, że się nie da. Dziwi mnie tylko, że akurat trzeba wziąś
język w który nie dość że niewiele (a pewno nie więcej niż konkurenci)
oferuje to jeszcze pod znakiem zapytania stoi jego rozwój.

>>W pewnym sensie taką automatyzację uzyskasz tylko do zadań trywialnych.
> Co dla kogo jest zadaniem trywialnym to dosyc trudne do okreslenia.
> Dla mnie trywialne jest wprowadzenie obiegu dokumentów zmiany w sofcie
> z zadbaniem o wazne detale takie jak ocena i zapewnienie budzetu,
> kontrola stanu prac i wydatkow, przygotowanie we wlasciwym czasie
> zasobow do testowania.

Dokładnie to samo można by powiedzieć gdybyś produkował kapsle do piwa.
Tam też trzeba kontrolować stan prac itp. To można powiedziec o każdym
rozsądnym języku programowania więc nie rozumiem argumentu.

> A znasz ksiegowego lub ksiegowa ktora napisze Ci testy jednostkowe?

Nie ad-hoc. Ale tez testy jednostkowe niesłużą tylko do weryfikacji
wyników. Służą też do upewniania się że własnie moja niewinna zmiana nie
spieprzyła połowy obliczeń. I nawet wydaje mi się, że w tej roli są
znacznie ważniejsze.

> Bo jesli to Ty napiszesz testy do swojego kodu to poza tym ze kod robi
> co Ty chcialesz niczego innego nie przetestujesz.

No wiesz, to poniekąd można to zrobić znacznie sprawniej jak się nie ma
testów. Jeśli projektant dupa ...

>>:D Mamy dość rozbierzne pojęcie o istotności elementów języka. Dla mnie
>>fakt, że std::vector< foo > x; x[4] jes typu foo ma kolosalne znaczenie
>>dla utrzymania i bezbłędności kodu.
> Wytlumacz jakie to ma znaczenie dla magazyniera?

3x (wyssałem z palca) szybsze znalezienie buga. 2x (wyssałem z palca)
tańszy developing i utrzymanie kodu. A tak na serio - naprawdę uważasz
że nie ma różnicy w nieprzymierzając PHP i C++ w ilości błędów
popełnianych podczas implementacji? Bo to dość istotny parametr w
procesie developingu.
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • effulla.pev.pl



  • Strona 2 z 3 • Znaleźliśmy 128 postów • 1, 2, 3

    comp
    oracle -> oracle lub oracle -> mysql replikacja - programy [spam] sprzedam używane programy Adobe/Macromedia [spam sprzedam] Prezentacja =?ISO-8859-2?Q?zdj=EA=E6_z_w=B3=B1czeniem/wy=B3a?==?ISO-8859-2?Q?czeniem_-_jaki_program_polecacie_do_tego_?= Program do konwersji =?ISO-8859-2?Q?zdj=EA=E6_B=26W_-=3E_?==?ISO-8859-2?Q?kolor?= SQL Server 2005: początkujący programista T-SQL ma problem Import faktur do Insert Subiekt GT oraz Wapro Wf-Mag z innego programu =?iso-8859-2?Q?program_foxpro_i_win_vista_=3F_w_xp_dzia=B3a=B 3o.?= [Oracle] Czy znacie jakiś programik który wykonuje sie z lini poleceń do porównywania Schemy? =?ISO-8859-2?Q?[MS_SQL]_=A6ledzenie_zapyta=F1_wykonywanych_przez_program? = =?iso-8859-2?Q?Program_stwarzaj=B1cy_efekt_starego_zdj=EAcia= 3F?=
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • tejsza.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

    Valid HTML 4.01 Transitional

    Free website template provided by freeweblooks.com