Witajcie. Znalazłem na necie język programowania D, poczytałem troche o nim na wiki ale nic ciekawego się nie dowiedziałem o nim. Czemu jest on tak mało popularny skoro data powstania jest wyznaczona jako '2007 rok' ?
I czym się różni o C++ i co o tym języku sądzicie ; )
A ile języków programowania znasz? Są ich tysiące, nie dziwne, że tylko niektóre są masowo używane.
Nie jest używany bo to tylko ciekawostka, do niczego nie potrzebna i nie za bardzo użyteczna.
A co się stało z "systemowym" (bez assemblera) językiem programowania Go od Google?
a masz własne zdanie na ten temat? Czytałem ten artykuł już jakiś czas temu, co nie zmienia faktu, że na Go nie natknąłem się ani na CodeProject, ani na StackOverflow ani w sumie nigdzie indziej
D niestety nie zdobył jak na razie popularności mimo iż ma parę istotnych różnic pomiędzy D a C++:
Część z wyżej wymienionych możliwości można uzyskać w C++ poprzez używanie bibliotek, ale często wiąże się z pewnymi niewygodami lub niekompatybilnością pomiędzy kompilatorami.
Ja bardzo bym się cieszył gdyby ten język zyskał popularność przynajmniej na poziomie Delphi, gdyż ma w sobie spory potencjał i pozwala tworzyć prosty ładny i dość wydajny kod.
No właśnie wydajność trochę kuleje względem C++, tzn D jest kilkadziesiąt procent wolniejszy. Nie zdziwiłbym się, gdyby był wolniejszy od najszybszych implementacji Javy (tzn np Sunowskiej).
@up - nie język jest wolniejszy tylko kompilator tworzy wolniejszy kod. To bardzo duża różnica! I niezbyt zaskakująca wziąwszy pod uwagę że kompilatory C++ są od kilku(dziesięciu) dobrych lat rozwijane przez firmy (microsoft/intel) nie szczędzące środków albo społeczności (GCC) nie szczędzące czasu. A D jest na razie mocno niszowy, niestety.
Ja bym się również cieszył gdyby D zyskał na popularności, ale obawiam się że na to nie ma wielkich nadziei, niestety.
W zasadzie to jeżeli kompilatory będą odpowiednio dobre to wybór języka nie będzie miał wpływu na czas wykonania. Wystarczy wyposażyć kompilator w sztuczną inteligencję tak, aby zorientował się o co chodziło programiście i wygenerował optymalny kod dla rozpoznanego problemu :P
Niestety daleko nam do takiego scenariusza, ale przecież kod LLVM, GCC czy JVM jest otwarty i można z niego czerpać całymi garściami.
Wibowit napisał(a)
Niestety daleko nam do takiego scenariusza, ale przecież kod LLVM, GCC czy JVM jest otwarty i można z niego czerpać całymi garściami.
Więcej, kompilatory LLVM i GCC mają możliwość rozszerzania ilości obsługiwanych języków poprzez frontendy. Do LLVM jest ldc, który jest słabo rozwijany ostatnimi czasy (jak niestety większość projektów, co jest spowodowane mocnymi zmianami między wersją 1.x i 2.x języka oraz brakiem wsparcia ze strony programistów) oraz gdc (https://bitbucket.org/goshawk/gdc/wiki/Home), który jest dość prężnie rozwijany, obsługuje najnowsze wersje języka.
Samo D miało (z racji nie rozwijania już się ono przedawniło) narzędzie do budowania projektów o nazwie DSSS. Trza by było je odświeżyć, bo było naprawdę proste w uzyciu, przenośne i posiadało ogromne możliwości. Jednak największą wadą D jest słabo zrobiona biblioteka standardowa oraz w wersji 1.0 podział na dwie społeczności, jedna preferowała domyślnego Phobosa (bardziej funkcyjny i składniowo przypominający bibliotekę standardową C, konwencja nazewnicza bardziej w stylu C/C++), a druga społecznościowe Tango (bardziej obiektowa i przypominająca bibliotekę standardową Javy, co dotyczyło również zastosowanej konwencji nazewniczej co mi się nie podobało :/), które były w dość dużym stopniu niekompatybilne. W wersji 2.0 nie ma tego "problemu" bo nie ma wersji Tango do D2.0.
q: poprawilem literowke
Ile języków kompilowanych bezpośrednio do kodu natywnego (tzn bez dynamicznej rekompilacji równoległej z wykonywaniem kodu, tak jak np w Javie) zostało w ciągu ostatnich 10 - 20 lat spopularyzowanych? Wydaje mi się, że prawie żaden. Za to powstało sporo języków zarządzanych.
Nawet taki trochę zlamiony język jak Java ma już wirtualną maszynę, która generalnie generuje kod tak samo szybki jak rozwijane przez wieki kompilatory C/ C++.
Komu będzie się chciało używać D, skoro Java jest szybsza, wygodniejsza (np jeśli programujemy w Scali, która przecież lata na Javie) i super łatwo przenośna? Gdyby wymyślili jakąś kolejną zarządzaną platformę, ale np jeszcze wydajniejszą od Javy i/ lub zżerającą mniej pamięci i/ lub mająca więcej fajnych właściwości poprawiających skalowanie się kodu i wydajności kodu, bez starych błędów czy niedociągnięć (np w Javie denerwuje type erasure, brak typów bez znaku itd) to pewnie zdobyli by sporo zwolenników.
Wystarczy wyposażyć kompilator w sztuczną inteligencję tak, aby zorientował się o co chodziło programiście i wygenerował optymalny kod dla rozpoznanego problemu
Na szczęście nie trzeba do tego inteligencji, bo wystarczy seria w większości trywialnych przekształceń.
Hmm, chodziło mi o np przypadek analogiczny do takiego, gdy ktoś klepie sortowanie bąbelkowe, ale kompilator rozpoznaje problem i zamienia to na sortowanie szybkie. Z tym, że kompilator miałby podmieniać nie tylko algorytmy, ale także np reprezentacje danych. Jakoś nie widzę tu serii trywialnych przekształceń.
Na szczęście nie trzeba do tego inteligencji, bo wystarczy seria w większości trywialnych przekształceń.
Sugerujesz, że kompilatory już wykonują tą "serię prostych przekształceń"? Jak na razie rzadko kompilatorowi udaje się wygenerować optymalny kod nie wspominając już o optymalizacjach, o których mówi Wibowit.
Jak na razie rzadko kompilatorowi udaje się wygenerować optymalny kod nie wspominając już o optymalizacjach, o których mówi Wibowit.
"Optymalny kod" (czytaj: najlepszy z możliwych) to chyba właśnie optymalizacje o jakich mówił Wibowit ;)
Kiedyś się zastanawiałem nad takim czymś - tylko nie miałem na myśli tworzenia inteligentnego kompilatora istniejącego języka a raczej inteligentny język (czemu? Bo to niezbyt sensowne - inteligentna kompilacja C++ wyglądałaby tak: C++ --(rozpoznanie intencji)--> Opis intencji programisty --(generowanie algorytmów)--> Kod maszynowy).
Problem polega na tym że już nawet samo zagadnienie opisania intencji jest skomplikowane ;). Np. (c&p z wiki)
procedure bubbleSort( A : lista elementów do posortowania )
n = liczba_elementów(A)
do
for (i = 0; i < n-1; i++) do:
if A[i] > A[i+1] then
swap(A[i], A[i+1])
end if
end for
n = n-1
while n > 1
end procedure
Nie ma wiele wspólnego z prawdziwym celem programisty jakim jest posortowanie tablicy.
Nie mówiąc już nawet o prawdziwej istocie problemu czyli 'wymyśl algorytm sortujący n elementów w jak najmniejszym czasie i złożoności pamięciowej'...
0x200x20 napisał(a)
Sugerujesz, że kompilatory już wykonują tą "serię prostych przekształceń"?
Mnóstwo: iniline'owanie funkcji, usuwanie nieosiągalnego kodu i zmiennych, upraszczanie wyrażeń, dewirtualizacja metod wirtualnych, usuwanie zbędnych ramek stosu, rozwijanie pętli, optymalizacje na poziomie asemblera.
http://en.wikipedia.org/wiki/Compiler_optimization
Nawiązując do @up, zrobiłem sobie kiedyś wikibooka na ten temat (co ciekawsze artykuły z Wikipedii eksportowane do .pdf) - jeśli kogoś interesuje
software_optimisation.pdf
Articles
#Compiler optimization 1
Analisis 12
#Escape analysis 12
#Alias analysis 13
#Shape analysis (program analysis) 15
#Pointer analysis 17
#Return value optimization 18
#Copy propagation 21
#Constant folding 21
#Common subexpression elimination 24
#Tail call 25
#Inline expansion 31
Loop optimisation 35
#Loop optimization 35
#Loop unwinding 37
#Loop nest optimization 43
#Software pipelining 47
Dynamic 52
#Adaptive optimization 52
#Peephole optimization 53
#Object code optimizer 56
Do tego co mówisz — by kompilator poprawiał źle napisany kod — jeszcze nam daleko. I niekoniecznie jest to potrzebne.
Właśnie niekoniecznie chodziło mi o źle napisany kod. Bardziej o kod deklaratywny, jak np Prolog. Nie znam się jakoś dobrze na Prologu, ale umożliwia on np zapisanie jakichś warunków, a potem uzyskanie odpowiedzi na nie. Problem w tym, że Prolog stosuje zwykły brute-force z back-trackingiem, zamiast sztucznej inteligencji czy czegoś w tym stylu.
Można pisać kod np:
posortowany(X) = dla każdego i od 0 do |X| - 2: X(i) < X(i + 1)
permutacje(X) = zbiór{dla każdego x z X dołącz: x + permutacje(X - x)}
sortuj(X) = wybierz zbiór z permutacje(X) aby spełniał relację posortowany
I mamy już funkcję sortuj(X). Można to zastosować bezpośrednio i generować wszystkie permutacje, ale chodzi mi właśnie o to, aby tutaj kompilator znalazł lepszą metodę niż generowanie permutacji wprost.
Słyszałem kiedyś taką historię o Prologu (albo innym języku, nie pamiętam już, ale to chyba był Prolog), w której miał być on receptą na wszelakie bolączki związane z programowaniem. Ludzie mieli właśnie nadzieję, że uda się napisać kompilator, który będzie znajdował optymalne rozwiązania dla postawionych deklaratywnie problemów. Niestety nie udało się. Generalnie (wg mnie) napisanie takiego kompilatora jest równoważne ze opracowaniem sztucznej inteligencji, a jeżeli ją opracujemy to raczej szybko prześcignie naszą :)