Autor Wątek: Język D  (Przeczytany 52094 razy)

Offline Sabre

  • Użytkownik
    • Go geek!

# Czerwiec 10, 2009, 15:07:08
D to zdecydowanie najlepszy język z tych, w których nikt  nie programuje :-P To nie jest krytyka - to fakt. Ten jezyk naprawde ma wszystko - z wyjatkim wsparcia jakiejs korporacji. Wiem jak to brzmi, ale bez tego D pozostanie tym, czym jest teraz - ciekawostka. A byłaby to duża strata - to naprawde wspanialy jezyk z potencjalem.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline JCoder

  • Użytkownik

# Czerwiec 12, 2009, 23:36:39
Problem w tym, że wcale nie ma wszystkiego. C# czy Scala mają dużo więcej fajnych rzeczy w języku. Np. dynamiczne ładowanie klas. Zresztą jest multum innych języków, które są dużo ciekawsze niż D (D to takie pomieszanie Javy, C# i C++), np. Ruby i Python. :P

Offline Dab

  • Redaktor
    • blog

# Czerwiec 13, 2009, 01:10:18
Ale jako jedyny z wymienionych kompiluje się do natywnego kodu, więc bez flejmu, ok? :)
« Ostatnia zmiana: Czerwiec 13, 2009, 01:13:28 wysłana przez Dab »

Offline vashpan

  • Użytkownik
    • Strona

# Czerwiec 13, 2009, 13:52:42
Problem w tym, że wcale nie ma wszystkiego. C# czy Scala mają dużo więcej fajnych rzeczy w języku. Np. dynamiczne ładowanie klas. Zresztą jest multum innych języków, które są dużo ciekawsze niż D (D to takie pomieszanie Javy, C# i C++), np. Ruby i Python. :P

Dynamiczne ladowanie klas to raczej nie jest "feature" jezyka a korzysc z maszyny wirtualnej i glownej specyfikacji C# na CLR. AFAIK w specyfikacji C# nie ma nic o jakims ladowaniu klas. Aczkolwiek moge sie mylic :) Poza tym C# moze byc kompilowany do natywnego kodu ( w zasadzie ;) ) ( system Singularity i kompilator Bartok )

Offline JCoder

  • Użytkownik

# Czerwiec 13, 2009, 14:55:33
Python też może być kompilowany do kodu natywnego - Jython -> klasy JVM -> Excelsior JET lub GCJ -> natywne binarki.
Trochę karkołomne, ale powinno się udać :) .NET IronPython podobnie.


Śmieszne jest to, że się niektórzy tak podniecają "statyczną kompilacją do kodu natywnego" bo to naprawdę nie ona odpowiada za wysoką wydajność. Jak napiszesz program w D korzystający ze wszystkich super udogodnień D, jak np. GC, czy kontrakty, to mimo całej kompilacji do kodu natywnego, wydajność będzie gorsza niż dobrych VMów. Oczywiście w grach tego się nie będzie używać bo programistów będzie bolał każdy tracony % wydajności. Chcę użyć GC i innych udogodnień zwiększających stabilność i ułatwiających poprawianie błędów, wezmę Javę lub C#. Nie chcę GC, napiszę program niskopoziomowo w C lub C++, bo to już znam i ma dobre wsparcie. Na D jest tu trochę mało miejsca.

Offline nameczanin

  • Użytkownik
    • devlog

# Czerwiec 13, 2009, 15:30:41
Cytat: JCoder
Śmieszne jest to, że się niektórzy tak podniecają "statyczną kompilacją do kodu natywnego" bo to naprawdę nie ona odpowiada za wysoką wydajność.
Obawiam się, że to nie tylko o wydajność chodzi. Wiele szarych userów ma wiele przeciwko jeżeli musi instalować .NET Framework czy Java Runtime Environment. "A na co mi to?!" <--- częste.

Zresztą, z DirectX nie było inaczej. Ale producenci gier dołączali go na swoje płytki i sam się instalował jak go nie było. Takie coś powino być i tutaj.


Cytat: JCoder
Jak napiszesz program w D korzystający ze wszystkich super udogodnień D, jak np. GC, czy kontrakty, to mimo całej kompilacji do kodu natywnego, wydajność będzie gorsza niż dobrych VMów.
Yyyyyyy? Nie wiem czy nie zauważyłeś że ten kod jest kompilowany do statycznych instrukcji i wykonują się tylko one, są z góry założone. W ten sposób feature'y języka nie mają żadnego znaczenia. Co do GC -> wiele gier (także właśnie pisanych w C++!) używa czegoś takiego jak menadżery zasobów i to praktycznie to samo jest... Także nie wiem skąd Twój pogląd, że natywne progsy D mają być takie słabe. Nie uważam, że Java jest wolna, ale nie potwierdzam, że D musi być wolny - bo nie musi jak Ty to uważasz.


Cytat: JCoder
Oczywiście w grach tego się nie będzie używać bo programistów będzie bolał każdy tracony % wydajności.
W grach właśnie się to przydaje baaardzo. Masz coś bardzo przeciwko, widzę, temu, że D ma opcjonalny GC.

Cytat: JCoder
Chcę użyć GC i innych udogodnień zwiększających stabilność i ułatwiających poprawianie błędów, wezmę Javę lub C#. Nie chcę GC, napiszę program niskopoziomowo w C lub C++, bo to już znam i ma dobre wsparcie
Kurcze, wybierasz języki do swoich programów kategorią "czy ma GC"? Słusznie, ale jeżeli to jest Twój główny aspekt wyboru...


Cytat: JCoder
Na D jest tu trochę mało miejsca.
Jeżeli "miejsce" jest metaforą użyteczności, to D ma tutaj szerokie miejsce. Argumenty - myślę - powyżej.

Offline vashpan

  • Użytkownik
    • Strona

# Czerwiec 13, 2009, 18:23:44
Wbrew pozorom wlasnie kompilacja statyczna odpowiada za wydajnosc.

Wielu ludzi mowilo ze kompilacja JIT jest/bedzie lepsza i potencjalnie moze generowac wydajniejszy kod, jednakze, bazujac na empirycznym doswiadczeniu i paru swoich eksperymentach - to grube nagiecie faktow, owszem metody sa kompilowane do kodu maszynowego, ale jest on gorszy niz kod skompilowany statycznie. Proste programy w C#, w calosci skompilowane do kodu maszynowego, czy to przez ngen'a czy nie, maja po prostu gorszy kod i gorsze optymalizacje, co mnie niezmiernie zdziwilo. A do tego dochodzi jednak narzut VM, bo co by nie bylo - on istnieje, glownie pamieciowy, ale wydajnosciowy takze ( poprzez rozne sprawdzania ) GC to akurat najmniejszy pikus.


Co do jezyka D: kontrakty w ogole nie sa kompilowane w wersji release ( jezeli nie powiemy inaczej ), podobnie jak rozne sprawdzanie runtime, jak chociazby kontrola rozmiaru tablic. GC jak bylo wspomniane mozna wylaczyc/usunac/napisac swoj - bo jest czescia biblioteki standardowej. D nie ma tez zadnego runtime' u oprocz standardowej biblioteki ( podobnie jak C++ )  Z innych "super udogodnien" pozostaja te zwiazane ze skladnia samego jezyka, gdzie narzutu nie ma wcale. Jednakze trzeba przyznac ze GC w D nie grzeszy wydajnoscia i jest wolniejszy od tych z Javy i C#, glownie dlatego ze nie jest na VM, nie takiej kontroli nad srodowiskiem. Na pewno jest to wada.

Jeszcze co do wydajnosci to warto podkreslic ze kompilatory Digital Mars na pewno nie optymalizuja kodu tak dobrze jak GCC czy MSVCP... Aczkolwiek nawet pomimo tego, jezyk D nie odstaje za bardzo od tego samego kodu napisanego w C++

Offline Kos

  • Użytkownik
    • kos.gd

# Czerwiec 13, 2009, 18:25:54
A co mają "ficzery językowe typu kontrakty" do wydajności? Kompilujesz release, wyłączasz asserty, nie ma tematu. Unit testy też są złe, bo "długo trwają i spowalniają program"? :)

Cytuj
Obawiam się, że to nie tylko o wydajność chodzi. Wiele szarych userów ma wiele przeciwko jeżeli musi instalować .NET Framework czy Java Runtime Environment. "A na co mi to?!" <--- częste.

Zresztą, z DirectX nie było inaczej. Ale producenci gier dołączali go na swoje płytki i sam się instalował jak go nie było. Takie coś powino być i tutaj.
Trafna uwaga. To "i tutaj", które wspominasz, AFAICR jest rozwiązane przez np. Java Web Start. Natomiast jeśli chodzi o takie rzeczy jak redisty VS, których brak wyrzuca nic nieznaczący błąd, lub .NET (j.w., tylko błąd bardziej treściwy), to zgadzam się z Tobą. Duże niedopatrzenie ze strony MS, że o to nie zadbali.



@topic: Sam widzę D jako "język podobny do C++ z fajniejszą składnią, bardziej dzisiejszym podejściem do wielu problemów oraz systemem szablonów z kosmosu".
System szablonów z kosmosu = dużo zabawy dla metaprogramistów (ktoś zrobił raytracer działający w compile-time), pozostałe dwa = szybsze i wygodniejsze programowanie.
Szybsze i wygodniejsze programowanie = większa produktywność. A czym się powinniśmy sugerować wybierając język pod dany problem, jeśli nie produktywnością, jaką osiągniemy tworząc zadowalające nas rozwiązanie?

Poza tym fajniejsza składnia to w tym przypadku łatwo parsowalna składnia, co też odbija się na toolach. Poczekajcie, aż chłopy od Descenta skończą klepać rewrite dla drzewka składni i będą mogli podpiąć masę fajnego kodu do refactoringu z Javy (kto kodował w Javie pod Eclipse, ten wie). Będziemy wtedy rozmawiać, który język ma lepsze toole, hihi :-)

Ludzie, ten język ma ile... dwa lata? A już jest o nim coraz głośniej, nawet u nas. Dajmy mu rozwinąć skrzydła, kto wie czy za 5-10 lat nie będzie popularny w branży i nie zacznie wypierać C++ jak onegdaj C++ zastąpił C? Według mnie jest na tyle fajny, że w masie zastosowań z pewnością by mógł.


Btw, ostatnio przez parę miesięcy kodowałem po trochu we wszystkim, tylko nie w C++. Gdy się do niego przysiadłem, moje pierwsze wrażenie brzmiało: "Aaa, to był ten dziwny język, w którym trzeba rozdziabywać każdy moduł na dwa osobne pliki, łolaboga!" :)

edit->
Cytuj
Jeszcze co do wydajnosci to warto podkreslic ze kompilatory Digital Mars na pewno nie optymalizuja kodu tak dobrze jak GCC czy MSVCP...
Ale jest przecież rozwijany GDC, który korzysta z dobrodziejstw pakietu gcc, więc nie jest to znowu taki duży problem.
« Ostatnia zmiana: Czerwiec 13, 2009, 18:28:10 wysłana przez Kos »

Offline JCoder

  • Użytkownik

# Czerwiec 13, 2009, 20:14:26
Cytuj
Wielu ludzi mowilo ze kompilacja JIT jest/bedzie lepsza i potencjalnie moze generowac wydajniejszy kod, jednakze, bazujac na empirycznym doswiadczeniu i paru swoich eksperymentach - to grube nagiecie faktow, owszem metody sa kompilowane do kodu maszynowego, ale jest on gorszy niz kod skompilowany statycznie.

Nie musi być wcale gorszy. Po prostu OBECNE kompilatory HotSpot są jeszcze za młode / słabe. Dobry kompilator HotSpot / JIT jest napisać dużo trudniej niż optymalizator statyczny. Do tego kompilatory C/C++ istnieją o wiele dłużej. VMy nadal przyspieszają z wersji na wersję (patrz np. tu:
http://lingpipe-blog.com/2009/03/30/jdk-7-twice-as-fast-as-jdk-6-for-arrays-and-arithmetic/). Kompilatory C++ stoją w miejscu - tu już nic nowego zrobić się nie da, co najwyżej dostrajać najniższe warstwy do nowych modeli procesorów.

Obecnie HotSpot w wielu przypadkach jest lepszy, tylko równoważone jest to przez dodatkowe sprawdzenia. Zobacz, ile z tych benchmarków testuje proste obliczenia numeryczne na tablicach. W takich benchmarkach kod zarządzany jest od razu na straconej pozycji - tzn. kompilator musi napracować się dużo bardziej niż w przypadku C++ aby wycisnąć tę samą wydajność, bo dochodzi choćby eliminowanie tych sprawdzeń, co się nie zawsze udaje.

Jednak jest też druga strona medalu, której prawie nikt nie benchmarkuje (przynajmniej nie widziałem w sieci) - kwestia pisania kodu modularnego, wielowątkowego. I tutaj już kompilatory C++ mają dużo gorzej - np. nie potrafią tak agresywnie inlineować pomiędzy modułami (w tym funkcji wirtualnych), nie potrafią usuwać nadmiarowych blokad (ostatnio coraz ważniejsze przy procesorach wielordzeniowych), nie potrafią automatycznie przenieść alokacji niektórych obiektów ze sterty na stos. Przy małych benchmarkach to nie jest problem napisać kod tak, aby to nie miało znaczenia (a miały znaczenie rzutowania czy tablice), przy realnych dużych programach, gdzie często korzysta się z prekompilowanych bibliotek i linkowania dynamicznego, już takie rzeczy mogą mieć znaczenie.

A, no i w przypadku języków dynamicznych jak Ruby czy Python napisanie kompilatora statycznego produkującego wydajny kod w ogóle jest niemożliwe. Tutaj VMy to przyszłość.

Wracając do języka D, to na pewno dużym plusem jest pozbycie się tych cholernych plików nagłówkowych. Natomiast cała reszta to kosmetyka, a przy okazji nie można korzystać z bibliotek w C++ (choć "biblioteka w C++" to raczej oksymoron - nie ma ustandaryzowanego ABI, to nie można robić prawdziwych bibliotek, jak w C). Dla mnie remis i nie ma sensu się przenosić. Ale zobaczymy jak to się rozwinie. W końcu C++ też wsparcia korporacyjnego nie miał.
« Ostatnia zmiana: Czerwiec 13, 2009, 20:19:31 wysłana przez JCoder »

Offline świrus

  • Użytkownik
    • Tu trolluje

# Czerwiec 13, 2009, 20:31:00
Kompilatory C++ stoją w miejscu - tu już nic nowego zrobić się nie da, co najwyżej dostrajać najniższe warstwy do nowych modeli procesorów.
Da się, lecz problemem jest to że nie opłaca się tego pisać.

Offline _MtZ_

  • Użytkownik

# Czerwiec 13, 2009, 21:55:58
JCoder ma tu naprawdę sporo racji. Ja w D nie pisałem, ale przeglądałem listę cech tego języka i ogromną większość z nich znajdę w innych językach (tych mających jakieś "plecy" za sobą :) ). Byćmoże D to fajny język. Byćmoże niedoceniany, ale nie wyobrażam sobie aby wyszedł poza ramy "ciekawostki". Jak to ładnie JCoder określił "Na D jest tu trochę mało miejsca." Jeśli miałbym do wyboru 50 najpopularniejszych języków, to D byłoby wysoko, ale napewno za C++, C#, Javą czy Ruby. Jakby to powiedziała moja znajoma: "Szału nie ma" :)

Offline vashpan

  • Użytkownik
    • Strona

# Czerwiec 13, 2009, 22:41:06
@JCoder: Kiedys nawet chyba o tym pisalem, ale raz na uczelni znalazlem ksiazke o Javie z 1996 roku i juz tam autor przywidywal swietlana przyszlosc dla kompilacji JIT i ze juz "lada dzien" bedzie szybsza niz kompilacja statyczna. To bylo 13 lat temu... ;) Taka mala ironia moze, ALE:

Ja osobiscie tez chcialbym zeby istniala uniwersalna maszyna wirtualna i mogl pod nia pisac we wszystkich jezykach jakie mi sie zamarza ( CLR i .NET Framework najblizej temu ) i byla wydajniejsza niz skompilowany kod maszynowy. Obysmy tego doczekali :)


_MtZ_ - jeszcze raz: ogromna liste tych cech owszem znajdziesz w innych jezykach, ale D jest kompilowany do kodu maszynowego, tzn. ze mozesz sobie korzystac z tych cech piszac system operacyjny, badz wypasiony silnik do gry ;)

Jak dla mnie to ze D jest uproszczonym skladniowo C++ to juz wystarczajacy powod zeby z C++ powoli rezygnowac. O reszcie napisal Kos... :)

Offline _MtZ_

  • Użytkownik

# Czerwiec 14, 2009, 12:11:18
Ja się kłócić nie będę, bo D nie znam i chciałem żebyście poznali opinię programisty patrzącego z dystansu na ten język.

A co do pisania systemów operacyjnych w C# to polecam ten projekt: http://www.gocosmos.org/index.en.aspx (Jako ciekawostkę :) )

« Ostatnia zmiana: Czerwiec 14, 2009, 23:48:23 wysłana przez _MtZ_ »

Offline lukaszw

  • Użytkownik

# Czerwiec 14, 2009, 15:36:23

Offline JCoder

  • Użytkownik

# Czerwiec 14, 2009, 22:18:14
A mógłbyś zapodać kod i metodykę testów? Bo inaczej to mało przekonywające jest :D