re phi: zaraz Cię zjedzą M$-trolle:) Oczywiście masz rację z tymi benchmarkami i z podejściem do sprawy. Streściłbym to tak: umiejętności programisty a nie umiejętności kompilatora.
Ale Wam śmiesznie komentarze pouci
Poprzedni komentarz nie przeszedł, tym razem krócej: tadziu a próbowałeś porównać MS SQL 2007+ VS z Oracle Forms (Developer/2000) + Oracle 8i na Linuksie? Baza 1 TB, w obu przypadkach 3-4 miliony krotek w wielu tabelach. Podpowiem - we wszystkich badanych zagadnieniach (od łatwości projektu, przez integrację z bazą aż do szybkości pracy) Oracle deklasuje przeciwnika. A to rzekomo przestarzała technologia... Dzisiaj zamiast dobrego oprogramowania wygrywa przeciętność, źle okodowana, z fatalnym debugiem ale tworzona tanio, czyli byle jak. Do tego Microsoft się świetnie nadaje.
Jedno mnie zastanawia. Wszyscy piszą o nowych super technologiach, VS, C#, itp itd a nadal najlepiej działają porządnie napisane programy w C, technologii sprzed 30 lat. Gdy ten sam algorytm oprogramować w technologiach Microsoftu albo w prostym, twardym C pod Uniksem i puścić benchmark, to wygrywa oczywiście C. Czasami o rząd wielkości. Dlaczego w obliczeniach inżynierskich nadal używa się Fortrana? Bo działa dobrze, szybko i są do niego świetne biblioteki. Inny eksperyment - baza danych 1 TB z 3-4 milionami wierszy w kilkudziesięciu tabelach. Co będzie szybsze - VS + MS SQL Server 2008, czy Oracle Forms z pakietu Developer 2000 + baza Oracle 8i na Linuksie? Wygra Oracle, prawie deklasując przeciwnika we wszystkich kategoriach (integracja z bazą, szybkość wykonania, jakość kodu, prędkość pracy interfejsu oraz wydajność gotowej aplikacji). Dzisiaj zamiast dobrego oprogramowania wygrywa przeciętność, źle okodowana, z fatalnym debugiem ale tworzona tanio, czyli byle jak. Do tego Microsoft się świetnie nadaje.
wy tu tacy mądrzy, a prawda jest taka, że po prostu robić im się nie chce, nie debugują, nie optymalizują, napiszą i się cieszą, że się ich program uruchomił i będzie kasiorka ;]
myślę, że co najmniej setki czytelników tego forum napisało coś większego niż ja, (jako programiści, jako kierownicy, współwłaściciele, czy choćby w postaci publikacji, wykładów itp) tyle, że nie będą o tym pisać. A ci co piszą mogą napisać co tam poczują a nie co faktycznie robili.
@WolfMoon - ja pisałełem, nie dokładnie tak jak proponujesz ale parę w takiej skali napisałem hterogenicznych - jako lider a nie jako autor wyłączny, np. w Wiedniu pod AIX, gdzie dostałem wcześniej drugi certyfikat na masywne przetwarzanie równoległe PS2/Aix a później zarobiłem forsę na rozkręcanie, było to ładnych parę lat temu, później był linuks (Serwery i stacje i bazy danych, java, php), AS/400, później Windows z VS, C#, SQL, XAML, WPF, WCF, WF LINQ do wszystkiego, kilka rodzajów serwerów Microsoft, kilka rodzajów specjalizowanych serwererów do Office, do SharePoint itd... Teraz łączymy to wszystko, jednak Microsft coraz bardziej to dominuje, bo tak wychodzi z całokształtu kosztów (na MBA uczą tego każdego, nawet ograniczonego - można iść np. na MBA dla IT i zobaczyć na przykładach i policzyć jak mylne mogą być zdawałoby się oczywiste wnioski co do opłacalności gdy system darmowy i reszta opensource)
aby dobrze pracować trzeba też mieć dobre przerwy w pracy - a większość ideologicznych wrogów Windows jest wprost super w dawaniu mi odprężenia i upewnianiu w prawidłowości wybranej drogi (czyli nie decydowania się na jedyną możliwość i uczeni się szeroko a w wybranych miejscach głeboko i wtedy sięganiu wysoko). Ja mam sukcesy mimo, ze nie jestem nadczłowiekiem ani super kimśtam (adminem czy programistą czy współwłaścicielem). :)
No dobra, panowie informatycy. A teraz ręka do góry, który napisał coś bardziej skompilowanego niż kalkulator ? Zdajecie sobie sprawę, jak skompilowane potrafią być współczesne aplikacje? Nie mówię tutaj nawet o Wordzie czy Excelu, ale o systemach przetwarzających ogromne ilości danych, wykonujące olbrzymie ilości obliczeń. Skomplikowanie architektury takich systemów + ilość wątków/procesów jakie działają jednocześnie na takich maszynach jest nie do ogarnięcia przez pojedynczego człowieka. Czasami nawet zespół ludzi, dobrze wykształconych z dużym doświadczeniem nie jest w stanie przewidzieć wszystkich stanów w jakich może znaleźć się system, co jest następstwem właśnie wielowątkowości. O wyścigach pewnie każdy słyszał, ale czy każdy zna 100% metodę (poza ogólnikiem w stylu "optymalizacja i debug") aby się ich pozbyć? Zwłaszcza w systemach, na działanie których może mieć wpływ kilka tysięcy czynników zewnętrznych ?
@Gość - rozpacz braku argumentów jest porażająca. NIgdy nie twierdziłem, że jestem wielki, raczej uwaząm się za zwykłęgo, a atakujących tak marnie (bez zainstalowania i sprawdzenia, bez przeczytania i pouczenia się itd) za małych/ograniczonych z własnego wyboru.
Optymalizacja i Debug - zapomniane rzemiosła.
@tad - ciagle podkreslasz jaki to z Ciebie wielki informatyk, admin i wogole. Cos mi sie widzi ze Ty chyba jednak nie masz co robic bawiac sie w naczelnego komentatora. Wez sie lepiej do roboty
tak, ale nie tylko. Zawieszanie to rónież prolem braku dobrych architektów aplikacji, brak wystarczającej optymalizacji przydziału prac: które elementy i jak rozdzielić na grupę a które dać jednemu - co ułatwia/utrudnia unikanie problemów. Oczywiście języki programowania są też niebagatelne, podobnie jak metodologia, projekt, środowisko architektoniczne, deweloperskie, biblioteki wspomagające, architektura wspierająca/wymuszająca. Bardzo ważny jest zakres i poziom doszkolenia programistów z aktualnych rozwiązań i dobrych praktyk w współbieżności i ustanowione standardy niskopoziomowe i architektoniczne i sposby ich weryfikacji. Wszytko ma sens, o ile liderzy i zespoły są wystarczająco świadome tego co wiedzą i tego czego jeszcze nie wiedzą. A ich kierownik potrafi utworzyć gwarancje i przekonać zarząd do opłacalności podejścia poprawnego. Synchronizacja to nie tylko sztuka, to tez ogromna wiedza (może specjalność już czas tworzyć) i infratruktura narzedziowo-organizacyjna. Pokazane roziązanie może mieć za jakiś czas sens również biznesowy o ile będzie wystarczająco szeroko wystarczająco skuteczne jedocześnie umożliwiając tańsze i szybsze tworzenie aplikacji będących konkurencyjnymi do innych rozwiązań przy liczeniu wszystkich kosztów w poszczególnych cyklach księgowych. Na razie to tylko początki akademickie (jakby zestaw ideii + bardzo ograniczona alfa) a różnymi dobrymi chęciami piekło codzienności już dawno brukowali. Ja życzę im powodzenia, bo wtedy programiści zajmą się bardziej ambitnymi tematami a mniej szarymi zabijającymi wydajność pracy programisty upierdliwościami - tak jak to juz jest od początku komputerów: kolejne języki, kolejne architektury, kolejne środowiska, kolejne metodologie, kolejne wzory organizacji zespołów i firmy. Nic nowego, kolejny próba, w tym samym zbiorze. Takie rozwiązania mają wielki sens gdy programiści zarabiają dużo, dygy programiści zarabiają mało , można sobie pozwolić na linuksy, c++ javy itp wszędzie. gdyby programiści byli prawie darmo w ogromnej liczbie to nawet makroasemblery mogłyby być optymalne kosztowo za całokształt.
Następny kod zajmujący zasoby sprzętowe tylko po to aby omijać błędy programistów. Deadlock to jest błąd programisty a nie problem komputerów czy systemów operacyjnych. Oczywiście większość firm zamiast zainwestować w dobrego programistę woli płacić grosze jakiemuś pseudo specowi i potem są tego efekty. Synchronizacja wątków czy procesów jest jednym z podstawowych elementów w sztuce, zwłaszcza w dobie wielozadaniowych systemów operacyjnych.
Na pewno nie koniec, program mozna zawiesic na wiele innych sposobow, np. proba wykonania operacji bez ustawionego timeoutu, przez wycieki pamieci, odwolania to nieprawidlowych adresow pamieci.
Podstawowa kwestia przy zawieszaniu programow, to dobrze napisany program, zgodny z API danego systemu. Druga, to obsluga procesow przez sam system i wplyw na jego stabilnosc.
hmmm.. no to może w końcu coś się zmieni na plus :)
