Programowanie - poczatek

[royback]

Witam wszystkich.Bardzo chcialbym nauczyc sie programowania lecz zupelnie nie
wiem od czego zaczac i z czego sie uczyc. Pomuzcie prosze od czego zaczac i z
kad brac informacjie?

Na wszelki wypadek podam swoj adres email [e-mail]

[sebektabaka]

Zależy od jakiego języka chchesz zacząć. proponowałbym c++. kup książkę
"Symfonia c++" Jerzego Grębosza. to jest bardzo dobra ksiązka. ja tez od niej
zaczynalem :)

[piotrpilinko]

Ja bym jednak nie proponował na początku ani c++, ani c, a raczej coś, co wybacza błędy, jakie popełniają początkujący programiści - pascala (albo adę95) - bo kompilator głośno krzyczy, kiedy pisze się poza tablicą itp. poza tym ma wbudowaną silniejszą kontrolę typów od c/c++. Ewentualnie assembler - przynajmniej potem wiadomo co wyprawiają kompilatory. Podobno "Symfonia..." jest niezła dla początkujących - nigdy nie przeczytałem, lepsza jest specyfikacja ANSI (o ile już zna się ten język), a potem "50 sposobów efektywnego programowania" dla c++ i stl. I jeszcze zdecydowanie coś do projektowania (inżynieria oprogramowania), bo bez tego marny będzie programista...

[alsor]

Aby się nauczyć C++, to trzeba znać C.
Aby opanować C, to dobrze jest znać ogólne zasady tworzenia algorytmów
oraz struktury danych:
Algorytmy + Struktury danych = Programy

A to ostatnie jest tytułem książki.

[student22]

Czesc,

Asembler - to porazka - jak go zobaczysz to po 5 minutach stwierdzisz, ze
programowniae nie jest dla Ciebie
Pascal - niby ok, ale to bylo dobre 20 lat temu - nie wiem po co uczyc sie
czegos, co juz w przemysle jest coraz rzadziej stosowane -> przegladnij sobie
ogloszenia o prace

Ja polecalbym C/C++ albo jave.

[piotrpilinko]

Pascal jest przejrzysty jeśli chodzi o algorytmy (czego nie można powiedzieć o
c). Także dużo wybacza początkującym programistą. A jeśli chodzi o wydajność,
to dobrze używany nie jest gorszy od c (a czasami nawet daje bardziej
zoptymalizowany kod). Natomiast przyznaję, że moja znajomość z tym językiem
skończyła się na drugim roku studiów (jakieś 7-8 lat temu).
Asembler się przydaje, żeby zobaczyć, cóż ten kompilator dla nas wygenerował i
co się może wykrzaczyć (a może się wiele, bo nie zawsze operacje, które wydają
się być atomowymi takimi się okazują)...

W przemyśle stosowany jest głównie c++ (i to najchętniej z kompilatorami gcc),
bo daje duże możliwości pisania kodu, którego można używać wielokrotnie bez
integracji w raz napisany kod...

[jach-mann]

Pascal jest wspaniały do nauki. Moim zdaniem jest najprostrzy i tu kolega dobrze
radzi weź się za pascala. Zgadzam się też z tym, że pascala już się nie używa do
pracy, ale używa się go do nauki ponieważ widać wszystko gramatycznie o co
chodzi składnia jest tak zbudowana, że w żadnym innym języku lepiej tego nie
zrozumiesz, a następnie możesz się wziąść za inne języki wszystko przed Tobą
przecież.Człowiek całe życie się uczy i głupim umiera hehe ;))) Pozdro

w obronie uzyteczności pascala

[negevmc]

jach-mann napisał:

> Pascal jest wspaniały do nauki. Moim zdaniem jest najprostrzy i tu kolega
> dobrze radzi weź się za pascala. Zgadzam się też z tym, że pascala już się
> nie używa do pracy....

Pascal to także Delphi, jedeno z najlepszych na rynku środowisk
programistycznych. Ludzie w Dlephi piszą, mnóstwo piszą.
Od lat produkuję oprogramowanie finansowe a w Delphi właściwie od chwili
gdy weszła na rynek (pierwsza połowa lat 90-tych). Jest to bardzo elegancki,
przejżysty i wydajny język - spadkobierca "edukacyjnego jedynie" wg Przedmówców
pascala.
Chciałbym tu wspomnieć o pewnej "pascalowej" zalecie polegajacej właśnie na
tym, że NIE wybacza błędów i krzyczy już przy kompilacji. Ale nie tylko ta cech
jest bardzo przydatna. To bardzo porządny i systematyczny język a to wymaga
takiego własnie sposobu pisania - porządnego i uporządkowanego. Oczywiście w
każdym języku można pisać bałaganiarsko lub porządnie ale są takie, które do
jednego lub drugiego wręcz zachęcają lub utrudniają.
Dlaczego jednak jest to takie istotne ? Mamy w firmie (istnieje około 30 lat)
gigabajty (nie myle się, właśnie giga) kodu źródłowego. Przez 30 lat przewinęło
się tysiące różnych programistów lub ludzi za takich się podających. Pisano
praktycznie we wszystkich możliwych językach i dla wielu róznych platform.
Twierdzę, iż kod w Delphi jest nie tylko najłatwiejszy do konserwacji (przez
inen niż autor osoby) ale także chyba najłatwiejszy i najefektywniejszy w
ponownym wykorzystaniu (ang: reusability).
To cechy często ważniejsze od szybkości (a i tak Delphi trudno prześcignąć),
nowoczesności, czasem mody bo one bardziej decydują o zyskach producenta
oprogramowania.

Marność widzę

[alsor]

Kiedyś próbowałem coś robić w tym Delphi,
ale wydał mi się lekko niewygodny, w niektórych sytuacjach.
Jest tam sporo obiektów - zamienników standardowych elementów windowsa:
TEdit, TListBox, itp.
Jednak są one trochę 'oszukane', gdyż nie posiadają wszystkich wariantów,
styli, które są zdefiniowane w ich windowsowych odpowiednikach.

Przykład: TTreeView
-nie można użyć pogrubionej czcionki dla wybranego węzła.
A jest taki styl: TVIS_BOLD
-automatycznie zmienia mi symbol + gdy usunę wszystkie elementy,
a nie powinien. Czasami się nie ładuje węzłów podrzędnych, aby optymalizować
pamięć itp. Wtedy zostawiam sobie + i dopiero po kliknięciu wypełniam
(dodaję) co trzeba.

Trudności w tworzeniu nowych obiektów (komponentów)
Należy utworzyć osobny plik pas dla każdej klasy, później rejestrować,
i dopiero wtedy można to użyć. Nie jest to konieczne, ale jeśli tego nie
zrobisz, to nici z wizualnego projektowania.

Prawie wszystkie funkcje w tych komponentach są 'private' - czyli niedostępne.
Aby mieć do nich dostęp, muszę tworzyć nowy komponent, który go dziedziczy.
A to tworzenie to makabra... i nowy plik w projekcie + rejestrowanko...

Program, który kiedyś robiłem w paskalu 7.0 miał lekko licząc 100 obiektów,
co tu daje 100 plików - tam nie było ich nawet 10.
----------------
Nie wiem, ale może ja czegoś nie wiem - jest jakaś ukryta maszyna w tym Delphi,
która robi te wszystkie organizacyjno-porządkowe drobiazgi?
Nie zauważyłem.

Do programowania w dużym zespole może to się nada w ostateczności,
jednak dla samodzielnego lub 2-3-osobowego zespołu - makabra.
C++ Builder nie lepszy - zamiast pascala jest c++, reszta identyczna z Delphi.

[negevmc]

alsor napisał:

> Kiedyś próbowałem coś robić w tym Delphi,
> ale wydał mi się lekko niewygodny, w niektórych sytuacjach.
> Jest tam sporo obiektów - zamienników standardowych elementów windowsa:
> TEdit, TListBox, itp.
> Jednak są one trochę 'oszukane', gdyż nie posiadają wszystkich wariantów,
> styli, które są zdefiniowane w ich windowsowych odpowiednikach.

Praktycznie nie ma używam oryginalnych komponentów. Wszystkie poprzerabiałem,
udoskonalałem czy raczej przystosowywałem itp. To niczego nie zmienia w mojej
fascynacji Delphi bo przeciez "jeszcze sie taki nie urodził co by wszystkim
dogodził ;-)". Pakiet dostajesz z kilkuset komponenatmi i ich kodem źródłowym -
reszta należy do Ciebie ;-)

> Przykład: TTreeView
> -nie można użyć pogrubionej czcionki dla wybranego węzła.
> A jest taki styl: TVIS_BOLD
> -automatycznie zmienia mi symbol + gdy usunę wszystkie elementy,
> a nie powinien. Czasami się nie ładuje węzłów podrzędnych, aby optymalizować
> pamięć itp. Wtedy zostawiam sobie + i dopiero po kliknięciu wypełniam
> (dodaję) co trzeba.
j.w. tree view mam całe swoje ;-)

> Trudności w tworzeniu nowych obiektów (komponentów)
> Należy utworzyć osobny plik pas dla każdej klasy
nic podobnego

> , później rejestrować,
fakt ale jak można wszystko wrzucic do jednego "pas" rejestrującego
to nie jest żadne utrudnienie bo nie tworzysz każdego dnia 100 komponentów.

> Prawie wszystkie funkcje w tych komponentach są 'private' - czyli niedostępne.
> Aby mieć do nich dostęp, muszę tworzyć nowy komponent, który go dziedziczy.
Po pierwsze nie wiem co to znaczy "prawie" . Są private i są public - zależy co
robią. Ale rozumiem Twoje trudności jeśli "rozwiązujesz" dostepność
funcji "private" za pomocą tworzenia nowego, dziedziczącego komponentu.
Nie Mój Drogi, tym sposobem nie "upublicznisz" niczego.

> A to tworzenie to makabra... i nowy plik w projekcie + rejestrowanko...
Więc chyba nie o tym samym Delphi mówimy. Nie w projeckcie, nie nowy plik i nie
rejestrowanko.

> Nie wiem, ale może ja czegoś nie wiem - jest jakaś ukryta maszyna w tym
> Delphi, która robi te wszystkie organizacyjno-porządkowe drobiazgi?
> Nie zauważyłem.
Delphi ma wady ale nie polegają one na braku tej maszyny.

> Do programowania w dużym zespole może to się nada w ostateczności,
> jednak dla samodzielnego lub 2-3-osobowego zespołu - makabra.
Jeśli się narzedzia nie zna to prawda, programowanie w nim to makabra.
Co do ostateczności prawdopodobnie masz rację: ponad 500 osobowa firma
z 200 mln USD obrotu rocznie i niemalże 30 letnim doswiadczeniem wybiera
Delphi w ostateczności ;-)))))

[bellicose]

> Ale rozumiem Twoje trudności jeśli "rozwiązujesz" dostepność
> funcji "private" za pomocą tworzenia nowego, dziedziczącego komponentu.
> Nie Mój Drogi, tym sposobem nie "upublicznisz" niczego.

Hehe, wyjąłeś mi to z ... klawiatury :-)

widzę nic!

[alsor]

Prywatnych nie upublicznię.
Tam powinno być protected zamiast private.

Przykład:

Zrobiłem taką, dość urozmaiconą tabelę przy pomocy TDrawGrid.
Wszystko by było wspaniale, gdyby nie zablokowany dostęp do
InplaceEdit - protected. Podczas edycji rubryki,
chciałem jedynie ograniczyć długość tekstu, który można wpisać,
jakoś tak:
grid.InplaceEdit.MaxText := 40,
albo chociaż tak:
SendMessage(grid.InplaceEdit.Handle, WM_LIMITTEXT, 40,0);

Niestety, moje wymagania były zbyt wygórowane.
Pewnie Borlandowcy uwzględnią je dopiero w Delphi 40.5

[negevmc]

alsor napisał:

> Zrobiłem taką, dość urozmaiconą tabelę przy pomocy TDrawGrid.
> Wszystko by było wspaniale, gdyby nie zablokowany dostęp do
> InplaceEdit - protected.

Zadziwiasz mnie prawde mowiac. Zrobiles urozmaicona table, wszystko byloby
wspaniale (wiec skad te zarzuty do Delphi) tylko ten wstretny InplaceEdit !!!
Przyjacielu, jesli zrobiles urozmaicona table w TDrawGrid to powinienes
doskonale wiedziec jak sobie poradzic z niedostepnoscia InplaceEdit.
Wymaga to kilku linijek kodu, i to samych deklaracji:
type
TMyDrawGrid = class(TDrawGrid)
public
property InplaceEditor;
end;

> grid.InplaceEdit.MaxText := 40,
> albo chociaż tak:
> SendMessage(grid.InplaceEdit.Handle, WM_LIMITTEXT, 40,0);

Po wspomnianym "upublicznieniu" obydwa te sposoby sa dostepne (po
wyeliminowaniu zawartych w nim bledow oczywiscie ale przeciez nie o nie tu
chodzi)

> Niestety, moje wymagania były zbyt wygórowane.
> Pewnie Borlandowcy uwzględnią je dopiero w Delphi 40.5
Borlandowcy nie uwzglednia prawdopodobnie Twych wymagan nawet w versji 50.1.A
(build 1430.22) poniewaz jest to zupelnie zbedne z powodow jak wyzej.

Jesli takie i tym podobne trudnosci dyskwalifikuja w Twoich oczach Delphi i
zmieniaja programowianie w niej (czy nim) w makabre to moim zdaniem masz
problem.
Przy okazji moglbys mi wytlumaczyc jakie cechy srodowiska programistycznego
sprawiaja, ze moze byc przydatny dla duzych zespolow a nie przydatny dla malych
(1-3 osobowych). Zastanawialem sie nad ta Twoja uwaga i nijak nie moge
zrozumiec co miales na mysli.

[alsor]

Definiowanie nowej klasy załatwia sprawę, ale jest to mało eleganckie.
Dla takiego trywializmu trzeba tworzyć nowe komponenty?
Najgorsze jest to, że dowiadujesz się o tym trochę za późno
(nie znam kodu VCL na pamięć i nie wiem jakie ma braki).

> Przy okazji moglbys mi wytlumaczyc jakie cechy srodowiska programistycznego
> sprawiaja, ze moze byc przydatny dla duzych zespolow a nie przydatny dla
malych
>

W zespole trzeba podzielić robotę na części, a Delphi wymusza taki podział
(te setki plików - dla każdego okienka osobny + nowe komponenty).
Poza tym, jak mówisz, należy przerobić/poprawić całą standardową bibliotekę
VCL. Dla dużego zespołu nie jest to problem - nakłady czasowe są niewielkie.
Samodzielny programista szybko tego nie zrobi (może w ogóle nie warto).

[negevmc]

alsor napisał:

> Definiowanie nowej klasy załatwia sprawę, ale jest to mało eleganckie.
Jest właśnie bardzo eleganckie ale nie będę się upierał bo elegancja to rzecz
gustu.

> Dla takiego trywializmu trzeba tworzyć nowe komponenty?
Cała filozofia OOP polega na tym czyż nie ?

> Najgorsze jest to, że dowiadujesz się o tym trochę za późno
> (nie znam kodu VCL na pamięć i nie wiem jakie ma braki).
Dokumentacja delphi wyraźnie mówi, że dostarczone komponenty, a szczególnie te
widoczne (jak edit, combo, grid itp) są tylko podstawą. Zaspakajają
najważniejsze potrzeby. Tak zresztą są tworzone aby można je było łatwo
rozbudowywać (doskonały jest Twój przykład, w którym InplaceEditor jest
protected. Wyobraź sobie, że piszesz komponent dla uzytu innego programisty i
nie chcesz aby był on widoczny. Zadeklarowanie go public psuje wszystko !).
Dużo komponentów jest tak napisanych, że podstawową klasa jest tzw. custom:
TCustomEdit, TCustomCombo a potem tworzona jest clasa TEdit, która praktycznie
zawiera tylko deklaracje public i published - upublicznia TCustomEdit, w którym
prawie wszystko jest protected. To jest mądra metoda - daje swobode
programiście w pisaniu zarówno aplikacji jak i komponentów "dziedziczących".

> W zespole trzeba podzielić robotę na części, a Delphi wymusza taki podział
> (te setki plików - dla każdego okienka osobny + nowe komponenty).
Nie widzę związku między pracą w zespole a wymuszoną ilością zbiorów.
Fakt, że każde okienko (TForm) musi być umieszczone w nowym .pas wydaje mi się
zaletą. Wprowadza porządek, od tego zresztą zacząłem - Delphi i pascal "lubi
porządek" dokonale sobie radzi z olbżymimi bibliotekami i wileloma "okanami" w
jednym projekcie. Możesz także łączyc całe projety w grupy i kompilować
dziesiątki dll czy exe jednocześnie. Zapewniam Cię, że "problem" setek zbiorów
to nie wada jak próbujesz wykazac a zaleta. Jak wspomniałem pracuje długo w
duzym zespole - wiem coś na ten temat.

> Poza tym, jak mówisz, należy przerobić/poprawić całą standardową bibliotekę
> VCL.
Nie jest to konieczne ale wygodne. Jeśli od początku będziesz używał TMyEdit,
TMyCombo etc, w trakcie pracy możesz łatwo je zmieniac i udoskonalać w
zalezności od potrzeb kolejnych projektów. To po rostu dobry zwyczaj, tego
wymaga filozofia OOP.

> Dla dużego zespołu nie jest to problem - nakłady czasowe są niewielkie.
> Samodzielny programista szybko tego nie zrobi (może w ogóle nie warto).
Pisałem programy w fortranie, cobolu, dbIII, clipperze, Natural, pisałem w C,
C++, VB i C# - ostatnio wobec kariery jaką robi .net
To prawda, nie pisałem chyba tylko w javie ale żaden z wymienionych przeze mnie
języków czy środowisk programistycznych nie dawał 100% rozwiązań dla wszystkich
problemów, ktore przede mna stawały. Także Delphi nie - i to jest jak
najbardziej naturalne. Jesteśmy rzemieślnikami (niektórzy artystami) a każdy z
nas potrzebuje tak jak szewc czy krawiec warsztatu, narzędzi, wprawy itp.
To sie zdobywa latami - nikt Ci tego nie da nawet jesli słono zapłacisz.
Czujesz niechęć do Delphi, miałeś inne przyzwyczajenia i nie spodobało Ci się -
masz rację - ale argumenty, które podajesz są śmieszne. Jesli nie masz czasu
(tzn. pieniędzy do zainwestowania w projekt) to pisz w Accessie. Ten stworzony
jest dla samodzielnych programistów. Nie wiem doprawdy czego wymagasz od
środowiska programistycznego , żeby za ciebie samo pisało programy ?
Najszybszy projekt jaki udało mi się napisać to 4 m-ce w średnio 10-osobowym
zespole. Można pisac poważne rzeczy szybciej ?
Prawdopodobnie mamy zupełnie inne "doświadczenia rynkowe" dlatego się nie
rzumiemy.

Pozdrawiam

[alsor]

> Dokumentacja delphi wyraźnie mówi, że dostarczone komponenty,
> a szczególnie te
> widoczne (jak edit, combo, grid itp) są tylko podstawą.

Standardowe elementy: EDIT, LISTBOX, BUTTON, COMBOBOX,... oraz
tzw. common controls: TREEVIEW, LISTVIEW, TOOLBAR, TOOLTIP...
są całkowicie i poprawnie zdefiniowane przez system operacyjny Windows.
Jeżeli ktoś, próbując ułatwić/zautomatyzować obsługę tych elementów,
tworzy ich obiektowe zamienniki, to nie powinien zmieniać, ograniczać ani
ukrywać/blokować niektórych ich właściwości.
To że, twórcy Delphi tak zrobili, a następnie bezczelnie informują:
"Uwaga! Dajemy szmelc.", nienajlepiej o nich świadczy.

Kiedyś w Paskalu i Borland C++ była biblioteka obiektów OWL,
tam wszystko chodziło poprawnie.
Później zrobili Delphi, a w nim zamiast udoskonalonej wersji dobrego OWL,
jest jakieś spartaczone VCL.

> Fakt, że każde okienko (TForm) musi być umieszczone w nowym .pas wydaje mi
się
> zaletą. Wprowadza porządek, od tego zresztą zacząłem - Delphi i pascal "lubi
> porządek" dokonale sobie radzi z olbżymimi bibliotekami i wileloma "okanami"
w
> jednym projekcie.

Często tworzy się proste okna dialogowe, w których użytkownik wpisuje lub
poprawia kilka danych (np. dane kontrahenta albo nazwa towaru + jednostka...)
Wtedy całe programowanie sprowadza się do zainicjowania kilku edit, listbox,
itp. po otwarciu okna, a przed zamknięciem - pobranie tych danych do jakiejś
bazy.
Będzie to, zazwyczaj kikanaście linii kodu.
Jeśli mam takich okienek kilkanaście, to ładuję to w jeden plik i jest pięknie,
a w Delphi tworzę pliczki po 200 bajtów każdy - po co mi to?

> To sie zdobywa latami - nikt Ci tego nie da nawet jesli słono zapłacisz.
> Czujesz niechęć do Delphi, miałeś inne przyzwyczajenia i nie spodobało Ci
>się

>Nie wiem doprawdy czego wymagasz od
>środowiska programistycznego , żeby za ciebie samo pisało programy ?

Niechęć to ja czuję do ludzi, którzy robią coś byle jak: zamiast udoskonalać
dobre i sprawdzone rozwiązania, wymyślają 'lepsze', takie które ja muszę
sprawdzać.

[negevmc]

alsor napisał:

> Standardowe elementy: EDIT, LISTBOX, BUTTON, COMBOBOX,... oraz
> tzw. common controls: TREEVIEW, LISTVIEW, TOOLBAR, TOOLTIP...
> są całkowicie i poprawnie zdefiniowane przez system operacyjny Windows.
> Jeżeli ktoś, próbując ułatwić/zautomatyzować obsługę tych elementów,
> tworzy ich obiektowe zamienniki, to nie powinien zmieniać, ograniczać ani
> ukrywać/blokować niektórych ich właściwości.
> To że, twórcy Delphi tak zrobili, a następnie bezczelnie informują:
> "Uwaga! Dajemy szmelc.", nienajlepiej o nich świadczy.

Ależ właśnie w akapicie, którego początek cytujesz wyjaśniłem po co.
Podstawowe klasy "custom" mają ukryte niemalże wszystko, daje to dużą swobodę
w tworzeniu nie tylko aplikacji ale i kolejnych bardziej wyspecjalizowanych
komponentów.

> Często tworzy się proste okna dialogowe, w których użytkownik wpisuje lub
> poprawia kilka danych (np. dane kontrahenta albo nazwa towaru + jednostka...)
> Wtedy całe programowanie sprowadza się do zainicjowania kilku edit, listbox,
> itp. po otwarciu okna, a przed zamknięciem - pobranie tych danych do jakiejś
> bazy. Będzie to, zazwyczaj kikanaście linii kodu.
> Jeśli mam takich okienek kilkanaście, to ładuję to w jeden plik i jest
> pięknie, a w Delphi tworzę pliczki po 200 bajtów każdy - po co mi to?

Po to żebyś miał całkowitą swobodę w wyborze jednego z okienek w następnej
aplikacji a nie ładował ich całej dziesiątki tylko dlatego, że są w jednym w
pliku.

[alsor]

Mówisz, że robicie kopy programów w Delphi.
Możesz podać kilka przykładów.
Jakiej wielkości, jakiego rodzaju są to programy:
graficzne edytory, bazy danych, jakieś symulacje, coś z internetem;
na indywidualne zamówienia, czy też sprzedawane w setkach sztuk.

Chodzi mi głównie o zorientowanie się: 'co można realnie wycisnąć z tego Delphi'

[negevmc]

alsor napisał:

> Mówisz, że robicie kopy programów w Delphi.
> Możesz podać kilka przykładów.

> Jakiej wielkości,
W sensie ilości kodu to są setki MB. Trudno ocenić bo firma jest rozproszona
po klientach i po świecie. Mamy bazę standardowych bibliotek ok 100 MB kodu
ale wszystko razem oceniam na ponad 1GB.

W sensie ilości i wielkości klientów podaje tylko w Izraelu:
Bank Israel, First International Bank, Bank Leumi, Bank Mizrahi, Bank Discount,
Bank Mercantile Discount, ELAL (linie lotnicze), Soltam (była fabryka broni
teraz garnków ;-), Amdocs (jeden z wiekszych na świecie producentów
oprogramowania bilingowego)

w sensie ilości obsługiwanych danych:
Zależy od klienta, największe bazy danych są rzecz jasna w bankach.
W Banku Discount np Oracle zajmuje 2.5 TGB (T=tera). Oczywiscie faktyczna ilośc
danych jest mniejsza bo zarezerwowano "na wyrost". Projekt jest stosunkowo nowy
i dane zajmują tam 700 GB. Każdego dnia obrabianych jest tam kilkset milionów
recordów. Oczywiście , ze to wszystko jest mozliwe to nie zasługa Delphi a
Orcala ;-)

> Jakiego rodzaju są to programy:

W bankach nasze aplikacje zbierają i obrabaiją dane z filii z całego świata,
produkują zestawienia, raporty i takie tam. Zajmujemy się ponadto "risk
managment" polega to głównie na planowaniu inwestycji giełdowych najprościej
mówiąc wejście to dane z giełd światowych (głównie blumberg) oraz inwestycje
banku , na wyjściu sa prognozy zysków i strat - dość zaawansowane algorytmy.
U kilku klientów mamy taki zwykły ERP (kadry, ksiegowość, zaopatrzenie)
W ELALu ciekawa aplikacja produkująca codzienne zestawienia i raporty lotów
wraz z ich kosztami i opłacalnością oraz symulacja opłacalności lotów.
W Banku Leumi oprócz wyżej wymienionych jes także duża aplikacja internetowa do
obsługi klienta zarówno w filii banku jak i w domu. Choć nie jest w całości
nasza to mamy w niej duzy udział i to w Delphi.

> graficzne edytory, bazy danych, jakieś symulacje, coś z internetem;
> na indywidualne zamówienia, czy też sprzedawane w setkach sztuk.

Jak widać głownie bazy danych i wyłącznie zamówienia indywidualne.
Jak łapiemy klienta możemy mu zaproponować praktycznie wszystko czego potrzebuje
od ERP, poprzez risk managment, do bardzo indywidualnych i wyspecjalizowanych
narzędzi. Zespoły programistów siedzą u klientów po kilka lat.


> Chodzi mi głównie o zorientowanie się: 'co można realnie wycisnąć z tego
> Delphi

Oczywiście nie wszystko napisane jest w Delphi, które istnieje zaledwie od
początku lat 90-tych.
Duża część to Natural (głównie unixowe servery) ale middleware (komunikacja
między windowsowym clientem a serwerem Unix/NT) oraz cały client napisany jest
w Delphi, także znane mi aplikacje internetowe.

Firma jest na całym świecie dośc spora, nawet w samym Izraelu Consist to nie
jedna firma (choć jeden wlaściciel) tylko dwie, trudno mi jest więc znać
wszystkie pola jej działania.

Ile da się "wycisnąć" ? trudno powiedzieć, to nie zależy jak wiadomo od języka
czy nawet programisty ale od umiejetności sprzedaży.
Celem jest napisać jak najszybciej jak najmniejszym kosztem a potem sprzedać i
żeby się nie psuło ;-) - to jasne. w latach 90-tych firma podjęła decyzje o
wykorzystaniu Delphi i do dzisiaj nikt tego nie żałuje a jak napisąłem w jedym
z poprzednich wątków - na wysokość obrotu nie mamy co narzekać.

Wiecej o firmie i jej filiach znajdziesz tu:
www.consist.com

[pthread]

Witaj,
Ja pracuje 2 lata w firmie z ~11 letnim stazem, sredniej wielkosci. Zaczynalem
na studiach od symfonii c++ oczywiscie oraz Visual Studio 5.0 / potem 6.0, MFC,
kupowalem ksiazki i czytalem, wypozyczalem czytalem, i oczywiscie duzo pisalem.
Na poczatek wg mnie polecam jakikolwiek jezyk i proste kawalki kodu ktore cie
uciesza jak napiszesz.
Nie trzeba duzo kasy, wczoraj sciagnalem kolejne 20 ebookow do C# ktorych
jeszcze nigdy nie widzialem a to sa normalne knigi takie jak w ksiegarni.
Jezyki ktore wg mnie warto wziac pod uwage: C/C++, .NET (VB,C#,ASP), Java, PHP,
JavaScript...i caly web. Oczywiscie powinienes wgryzac sie w bazy MSSql &
Oracle & MySql oraz generalnie w technologie: XML, Krytptografia, UML etc oraz
w systemy (to wazne przy wdrozeniach) - Win, Lin.
Wazne wg mnie rownolegle rozwijac sie piszac pod linucha nie wiadomo co ci sie
trafi w przyszlosci (mi trafil sie prj) a radosc pisania pod linuchem wielka,
naprawde polecam, nie ma porownania do win.
Co do Delphi to niestety moje doswiadczenia sa negatwne. Napisalem troche kodu
na studiach w delphi ale moja firma generalnie przenosi caly soft na 'lepsze'
jezyki. Wydaje mi sie ze z jednego powodu. Kod w delphi 4.0 nijak sie ma do
nowych rozwiazan borlanda (nie sledze wlasciciela) - firmy ktora miala
wachniecie z tego co slyszalem przez co stracila klientow, ale moge sie mylic
co do aktualych zastosowan (widzialem newest ver i nawet mi sie podobala).
Problem jest niestety z tym ze bedziesz musial podjac decyzje w co sie pakowac
na calosc, pracowalem rowniez w firmie piszac w Java i wiem ze albo
wybierzesz 'proste' kodowanie pod win i bedziesz sie w tym specjalizowal albo
wybierasz Jave. Wg mnie wszystkie rozwiazania Javy to kilka jezykow razem
wziete i braknie czasu w zyciu na zglebienie calosci.

Powodzenia
Pozdrawiam