D vs. C++

Tak dla własnej ciekawości zastanawiam się, czy ten pierwszy język jest wart uwagi. Co sądzicie?? Prosił bym też o argumenty dlaczego ten a nie inny.

Moim zdaniem jest wart uwagi. O D zostało dużo napisane, także D vs C++.

Kilka linków

• http://www.digitalmars.com/d/2.0/comparison.html
• http://www.digitalmars.com/d/2.0/cppstrings.html
• http://www.digitalmars.com/d/2.0/cppdbc.html
• http://www.digitalmars.com/d/2.0/cppcomplex.html
• http://gim.jogger.pl/2007/11/09/wstep-do-wstepu-o-programowaniu-w-d/
• http://www.zyxist.com/pokaz.php/poznaj_d

Ciekawe czy ma szanse na zagrożenie C++ ( za 2-4 lata ):P

Moim zdaniem małe. Rzeczej będzie sobie funkcjonował w niszy obok. Czemu?

1. Oferuje bardzo niewiele ponad standard C++0x.
2. Nie zawiera ani jednego "power feature", który mógłby pociągnąć marketing.
3. Większość możliwości pokrywa się z C++, ale D nie jest z nim kompatybilny... Nie wykorzystasz nawet istniejących obiektowych bibliotek C++, bo model obiektu w D jest inny. Jeśli już zrywać kompatybilność, to trzeba dać coś w zamian. Dużo w zamian. Reflection, GC i kontrakty to mało w świecie, gdzie inne języki mainstreamowe to już mają (C#, Java).

E, te argumenty "za" są kapkę naciągane.

1. Jest szybszy od C++.

e tam, dyskusyjne jak cholera. W pewnych zastosowaniach może szybszy minimalnie, w reszcie ten sam. A w jeszcze innych pewnie jest rozwalany przez Javę, a jeszcze innych przez... [tu wpisz swój język]. W szybkości na głowę bić nie może, bo w końcu to właśnie C++ stawia na szybkość, czasem kosztem innych aspektów.

2. Zachowuje częściową kompatybilność z C i C++, ale jak przystało na nowszą wersję nie jest całkowicie kompatybilny.

częściową? Nie jest wcale kompatybilny z C++. Jest zgodny z C na poziomie binarnym, ale to w zasadzie żadne większe osiągnięcie, bo każdy znany mi język natywny jest zgodny z C na poziomie binarnym.

3. Kompiluje się do kodu natywnego w przeciwieństwie do C# i Java.

ale dokładnie tak samo jak C++, i multum innych języków natywnych - i to raczej z tymi może konkurować. Pytanie, czy ma czym.

4. W przeciwieństwie do C/C++ posiada "garbage collector"

lepiej powiedzieć: wbudowany GC, bo zewnętrzne GC to mają i C i C++. Ale czy to jest ta kluczowa sprawa? Ten przełom? Jak się chce pisać z GC, to można, to nic nowego, na nikim to już nie robi wrażenia. To wychodzi na to, że D jest takim "C++ z GC". Trochę ubogo, chociaż C++ zaczynał jako "C z klasami"... ;)

PS. Ja lubię D, może nawet coś na jego temat uważam, ale twoje argumenty by mnie do niego nie przekonały, gdybym już wcześniej przekonany przez innych nie został.

Java i C# też dają się kompilować natywnie. Nie jest to może popularne, ale takie cuda jak Excelsiors JET działają b. dobrze.

Do tego dokumentacja bibliotek D (np. Tango) nie dorasta do pięt np. Javowej dokumentacji czy też dokumentacji C#.

D nie wnosi nic nowego, różnice pomiędzy C++ a D nie są na mierę różnic tychże i np. Common Lispu. Kilka bibliotek osadzonych jako część języka, zmieniony model kilku rzeczy (czyniąc język bardziej niespójnym niż C++, a to sztuka), tyle... Co do wydajności - nie istnieje coś takiego jak wydajność języka! Istnieje jedynie wydajność środowiska wykonawczego i wygenerowanego kodu - całość zależy od jakości kompilacji. Dla przykładu w wielu wypadkach Haskell (GHC lub eksperymentalny kompilator JHC) czy wspomniany Common Lisp (powiedzmy, że dobrze użyty SBCL) przebijają D wydajnościowo, o poziomie abstrakcji i czytelności nie wspomnę.

GC nie jest ściśle zintegrowany z językiem na poziomie takim jak w dwóch wspomnianych przed chwilą językach, jest nielepszy od tych dostępnych dla C++. Nie pamiętam aby GC z D mógł się w którymkolwiek miejscu mógł równać z tym z uporczywie wspominanego przeze mnie CLu.

Przepraszam bardzo ale kompilacja do bytekodu to jakiś argument przeciwko Javie, C# czy dowolnemu innemu językowi (...jak CL)? Dla wszystkich trzech języków istnieją natywne kompilatory, ale nie o to chodzi - istnieje coś takiego jak JIT, co pozwala potencjalnie osiągnać większą wydajność kodu niż w przypadku bezpośredniej natywnej kompilacji. O przenośności binarek nie wspomnę. Na przełomie lat '80 i '90 popularnym językiem aplikacji biznesowych był Smalltalk, język który teoretycznie musi pracować pod kontrolą maszyny wirtualnej... kilkanaście lat temu nikomu nie przeszkadzało użycie VM, teraz po znacznym przyspieszeniu sprzętu i rozwinięciu technologii wirtualizacji nagle zaczyna to być minusem?

Zgodność na poziomie binarnym z C jest osiągalna i dla języków nienatywnych, a " Zachowuje częściową kompatybilność z C i C++" to i Haskell, vide GHC. Nie jest to więc osiągnięcie...

To ma być język, który będzie miał to czego "zabrakło"w C, ale przydały by się strumienie ( takie jak w C++ cin, cout, etc. )

To jakiś żart? Jak dla mnie to Objective-C miał zdecydowanie więcej tego czego "zabrakło" w C. Porównanie z C jest w ogóle nietrafione - C to przenośny assembler, język średniego poziomu uwalniający od zależności od konktretnej sprzętowej architektury, D zaś to typowy język wysokiego poziomu. Szczerze? To samo co o D napisaleś to w odniesieniu do C to można napisać o prawie wszystkich natywnych HLL.

Dokumentacja? Do dokumentacji Haskella, np. bibliotek GHC sporo brakuje... inny przykład - boost.

Wszystkie argumenty winerfresha są naciągane - nieistniejąca szybkość języka, natywność kompilacji, która nic nie wnosi, kompatybilność z C, którą posiada większość języków, GC o jakości tego, jaki ma lub mozna zastosować w niemal każdym języku, w tym krytykowanym C++.
D brakuje zaś bibliotek (gdzie jest boost?!) czy wsparcia w ogóle. Ten język pozostanie ciekawostką ze względu na lepsze i bardziej ustabilizowane alternatywy.
Czekam na jakieś konkrety, może ktoś mnie przekona do częstszego pisania w D, bo póki co - większych korzyści nie zauważyłem, co najwyżej zabawa.

(a za tamten cyrk z C++ przepraszam, 'świętowałem rewolucję październikową'...)

winerfresh napisał(a)

4. W przeciwieństwie do C/C++ posiada "garbage collector"

Nie wiem czy to plus czy minus. Wg. mnie minus, taki feature nie jest potrzebny przy prawidlowo zaplanowanej architekturze programu, w przypadku gdy ta architektura jest zjebana nawet garbage collector nie pomoze. po prostu taki gc wspomaga lenistwo.

Akurat GC pełni jeszcze wiele innych zadań niż tylko zwalnianie pamięci, do tego 'masowa' ręczna alokacja występuje tylko w językach ze wskaźnikami. Aktualnie odśmiecanie nie tylko odzyskuje pamięć ale defragmentuje i optymalizuje ułożenie danych z punktu widzenia cache'u procesora. Automatyczne zarządzanie pamięcią z niczego nie zwalnia - nadal trzeba myśleć nad sensownym zaprojektowaniem algorytmów, w nich przecież zawarte jest całe rozłożenie obiektów, ważne z punktu widzenia ew. alokacji. GC potrafi zagwarantować ciagłość pamięci co ma spore znaczenie (vide kilka wątków w dziale Delphi o braku pamięci po sporej ilości alokacji i zwolnień małych obiektów). GC lub automatyczna, statyczna dealokacja pamięci występuje w praktycznie każdym języku wyższego poziomu. Przy GC nie zwalnia się zwykle obiektów ręcznie ale bindy obiektów wypada czasami zerować, tak samo jak i sensownie dobierać zakres istnienia obiektu - w językach, które czysto funkcyjne nie są nie można jednoznacznie określić, że coś będzie już niepotrzebne do czasu wyjścia poza zakres. Automatyczne zarządzanie pamięcią potrafi w cwany sposób wykorzystać 'zwolniony' obiekt przy tworzeniu nowego obiektu tego samego typu... A jak się to ma do D to już niestety inna sprawa.

Automatyczne zarządzanie pamięcią pozwala ładnie spaprać program, fakt. Szczerze? Zawalenie architektury przy ręcznym zarządaniu pamięcią może nie być tak bolesne. GC potrafi bardzo wiele, ważne jest żeby umieć to sensownie wykorzystać, bezkrytyczne tworzenie setek dodatkowych obiektów o wielokrotnie za długim czasie życia to niestety typowa polska rzeczywistość...

To tyle litanii do GC. No, może jeszcze jedno - kilka mniejszych programów narzędziowych przepisałem dla zabawy z C++ na Haskella, efekt - mniejsze zużycie pamięci mimo pakowania obiektów, dzięki leniwej ewaluacji i świetnemu GC GHC, wydajność zaś niewiele mniejsza, co wynika raczej z faktu czystej funkcyjności. Wniosek? Pisz sensownie a na GC zyskasz, burdel zaś przyniesie poważne straty... czyli jak wszędzie w informatyce.

A, jeszcze jedno - to zuo ma pewien plus z punktu widzenia biznesu: fakt istnienia GC w języku i umiejętność prawidłowego wykorzystania tego w projekcie zmniejsza ilość poprawek i przyśpiesza rozwój oprogramowania. Ot, wyższa abstrakcja.

Hmm jeszcze moze co kompilacji C# do postaci natywnej - zawsze myslalem ze to niemozliwe, a tu prosze:

http://www.xenocode.com/Products/Postbuild/Features.aspx

Native executable generation
Compiles assemblies into native x86 executables, allowing .NET applications to run immediately on machines without the Framework installed. (Windows 9x and NT4 targets not supported.)

Soft komercyjny, ale ciekawe jak to sie sprawuje :> Chyba raczej próbuje pakowac do exeka te czesci frameworka, ktore sa wykorzystywane, chociaz tez zawsze uwazalem to za niemozliwe

Gdyby D był kompatybilny z C++ to może i by mógł zaistnieć. Język nie jest taki młody, a popularność wciąż znikoma.

EgonOlsen napisał(a)

winerfresh napisał(a)

4. W przeciwieństwie do C/C++ posiada "garbage collector"

Nie wiem czy to plus czy minus. Wg. mnie minus, taki feature nie jest potrzebny przy prawidlowo zaplanowanej architekturze programu, w przypadku gdy ta architektura jest zjebana nawet garbage collector nie pomoze. po prostu taki gc wspomaga lenistwo.
Oj Egon, chyba nie pisałeś zbyt wiele z GC. Zupełnie się zmienia filozofia pisania - wszystko można przez referencję przekazywać i zawsze ta referencja będzie OK. Nie zwalniasz obiektów bo i po co ci dodatkowy 1Kb pamięci, wystarczy odśmiecać w sensownych momentach. Jak chcesz użyć jakiegoś obiektu tylko raz, to np. w C# jest słowo kluczowe using. W ogóle nie martwisz się pamięcią, nie ma czegoś takiego jak wyciek pamięci. Sporo to wszystko przyspiesza projektowanie i pisanie kodu. Inaczej projektuje się klasy.
Różnica jest duża, może nie kolosalna ale całkiem spora.

Co do kompilacji IL do postaci natywnej - nie sądzę, aby jakoś sensownie przyspieszyła program. Testował ktoś ?

Najważniejszą zaletą GC w porównaniu z ręcznym zarządzaniem jest moim zdaniem lepsza modularność kodu - tj. słabsze zależności między modułami, szczególnie zależności od implementacji. Ciężko w takim C udokumentować funkcję przyjmującą/zwracającą wskaźniki bez bardzo dokładnego opisania, co z tymi wskaźnikami robi (implementacja wywoływanego), albo co z nimi trzeba lub nie wolno robić (implementacja wywoływacza). Prowadzi to do bardzo trudnych czasem dylematów - kto jest właścicielem tego obiektu i niepotrzebnego kopiowania (na wszelki wypadek) - szczególnie w projektach zespołowych. Język w zaden sposób tego nie kontroluje, nie można nawet tego rozsądnie oznaczyć inaczej jak przez komentarz.

W Javie czy C# dostajesz obiekt to robisz z nim co chcesz. Możesz sobie np. zbuforować na przyszłość bez ryzyka, że coś Ci zajedzie ten obiekt free/deletem. Owszem, nadal możesz coś skopać, ale konsekwencje są dużo bardziej przewidywalne niż SIG_SEGV.

winerfresh napisał(a)

Znalazłem coś takiego http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=gdc&lang2=gpp i wychodzi, że D jest porównywalny z C++.

Czy Ty czytasz co do Ciebie piszemy? To jest porównanie wydajności kodu generowanego przez dwa konkretne kompilatory, nie istnieje wydajność języka, było pisane co najmniej 2 razy!

winerfresh napisał(a)

Jednak stanowi bardziej chyba zagrożenie dla M$ C#, który jest o wiele mniej przenośny od D.

A co Microsoft obchodzi pseudoprzenośność D? C# z założenia jest przenośny pomiędzy platformami, do których Microsoft dostaczy .NET Framework, inne go nie interesują.

winerfresh napisał(a)

Wprawdzie powstało Mono, ale jest jeszcze niedopracowane tak jak D

Mam wrażenie, że chciałeś coś innego napisać, ale... skoro mono będące niezależną od Microsoftu, po części amatorską, implementacją jest tak samo niedopracowane jak D to czy można tutaj mówić o konkurencji? Porównuj D z C# 3.0 pracującym na oryginalnym .NET 3.5 albo w ogóle.

winerfresh napisał(a)

Sądzę, że te dwa języki będą ze sobą konkurować jak tylko zostanie dopracowane D.

Wiesz, to ma sens jeżeli przyjmiemy, że C# stanie w miejscu zostawiając pole i czas na dopracowanie D, a tak się nie stanie. Do tego binarkę .NET można na różnych architekturach sprzętowych odpalić, D za Chiny. Hm, mam pomysł, pokaż mi działające sensowne jądro systemu operacyjnego napisane w D, w C# już jest - argumentacja w rodzaju tej, którą stosujesz.

winerfresh napisał(a)

Można tam znaleźć m.in. gtkD ( implementację GTK do D ), Yage ( silnik 3D ) i Wombat ( wygląda na coś co ma być konkurentem dla ASP.NET ).

To jakieś osiągnięcie? W Common Lispie powstało kilka gier 3D, jest coś takiego jak Lambda-GTK czy K-PAX, nie widzę sensacji. Natomiast D nie ma niczego w mechanice jezyka porównywanego z CLOSem i MOPem, do tego prostszy GC (niż w części implementacji CLu)...
Gdyby powstał nowy dialekt Lispu posiadający rozbudowaną bibliotekę standardową (a'la Ruby) z sensownym wsparciem funkcyjności (ręczne bindowanie argumentów czy komponowanie funkcji za pomocą lambdy jest mało ciekawe), całkowicie obiektowy (czyli ew. minimalne poprawki do takich klamotów jak MOP i CLOS) to miałby większą szansę się przebić niż taki D, mimo niezbyt przystępnej na poczatku składni.

Kombinujesz jak koń pod górę z tymi swoimi argumentami, nadal nic rzeczowego. To co napisałeś to równie dobrze można i o innych językach napisać, np. Java zdecydowanie bardziej by tutaj pasowała.

(Tak, wiem, że porównuję język statycznie typowany z dynamicznie typowanym).

winerfresh napisał(a)

2. Zachowuje częściową kompatybilność z C i C++, ale jak przystało na nowszą wersję nie jest całkowicie kompatybilny.
3. Kompiluje się do kodu natywnego w przeciwieństwie do C# i Java.
4. W przeciwieństwie do C/C++ posiada "garbage collector"

PS.
To ma być język, który będzie miał to czego "zabrakło"w C, ale przydały by się strumienie ( takie jak w C++ cin, cout, etc. )

2. W CL masz CFFI, vide biblioteki C w CL
3. Lisp też, od jakichś 40 lat.
4. Lisp też, od niemal 50 lat.

CL ma strumienie (od ponad 25 lat), i przeglądając to porównanie warto zauważyć, że ma niemal wszystkie ficzery D, będąc przy tym w wieku C++.

boski "ogierze", CL ma przecież statyczne typowanie na życzenie, więc można rozpatrywać je tak samo :P

I w ten oto sposób dodekamie sam siebie w łeb pier***nąłeś, wykazując, że w/w "ficzery" nie zapewnią językowi popularności, nawet jeśli mu damy 40 lat na walkę o rynek. Skoro CL tym świata nie zawojował, to jak niby ma to zrobić D? I co to niby w ogóle za "ficzery" i nowości w D, jeśli są to rzeczy znane od 40-50 lat? :|

CL ma nawet więcej:
Można zrobić program, który sam się pisze poprzez makra?
Można w tym D napisać własny specjalizowany dialekt?
Nie mówiąc o tym, że GC w D to zabawka w porównaniu z tym co ma CL, Java czy .NET.
A i taka drobnostka: brak dyn. ładowania klas, czyli żegnajcie kontenery IoC, ORMy i inne fajne cuda ;)

Ranides napisał(a)

I w ten oto sposób dodekamie sam siebie w łeb pier***nąłeś, wykazując, że w/w "ficzery" nie zapewnią językowi popularności, nawet jeśli mu damy 40 lat na walkę o rynek. Skoro CL tym świata nie zawojował, to jak niby ma to zrobić D? I co to niby w ogóle za "ficzery" i nowości w D, jeśli są to rzeczy znane od 40-50 lat? :|

Bo tu nie o ficzery chodzi, Java przejęła rynek jeszcze w fazie, gdy była naprawdę fatalna (teraz jest nawet użyteczna). Czemu Lisp nie zawojował mainstreamu? Bo ludzie nie podejmują nawet wysiłku, żeby go poznać - nie ma co ukrywać, że Pascal to nie jest poważny język, Delphi też nie jest wiele lepsze, ale tutaj na forum właśnie o tym traktuje większość wątków. Czemu? Bo ktoś im powiedział, że Pascal to język edukacyjny, a Delphi jest fajne i łatwe, oni w to uwierzyli, bo czemu mieliby nie uwierzyć, tak samo większość ludzi wierzy we wszystko, co się im mówi na tematy, o których nie mają pojęcia. Problem właśnie polega na tym, że języki B&D niszczą umysł i sprawiają, że delikwent nie potrafi się przerzucić na nic innego - vide artykuł Djikstry o BASICu. Popularność sama się napędza - więcej ludzi pisze więcej bibliotek, więcej bibliotek zachęca większą liczbę ludzi do testowania języka, debugowania bibliotek, a stabilne i dobre biblioteki zachęcają ludzi do korzystania z języka w celach produkcyjnych.

Ludzie nie mają zwykle pojęcia, że coś takiego jak Lisp istnieje (ja długo nie miałem), a jak już się dowiedzą, to zwykle mają do niego stereotypowe podejście - starocie, dziwna składnia, za dużo nawiasów, nikt tego nie używa. Mnie osobiście do zainteresowania się skłonił życiorys RMSa, eseje Paula Grahama (szczególnie polecam Revenge of the Nerds i Beating the Averages, zresztą wszystkie warto) i ostatecznie Hacker Howto ESRa (chyba każdy zna, najwyraźniej jednak wszyscy pominęli wzrokiem/poznaniem to, co ESR pisze o Lispie). Poznanie całej składni zajmuje kilka minut (nawet nie mówię jeden wieczór, jak to jest przy większości innych języków, ale po prostu kilka minut), poznanie różnic kilka dni, nauczenie się języka (stylu, metod) kilka miesięcy, nauczenie się czarowania kilka lat. Jednak szybko się odkrywa, że to jest jedyny tak naprawdę piękny język. Czerpiąc ze zbioru cytatów Paula Grahama:

"I have heard more than one LISP advocate state such subjective comments as, "LISP is the most powerful and elegant programming language in the world" and expect such comments to be taken as objective truth. I have never heard a Java, C++, C, Perl, or Python advocate make the same claim about their own language of choice."

• A guy on Slashdot.

Wracając do głównego pytania, czemu nie zdobył rynku. Ależ zdobył rynek, w swoim czasie. Potem jednak przegrał z innymi językami w wyniku pewnych nieszczęśliwych zbiegów okoliczności i pewnych błędów, których można było uniknąć. Czemu dzisiaj nie jest popularny, a na przykład Ruby tę popularność zyskał: naprawdę nie wiem, skoro sam twórca Rubiego powiedział,

"Some may say Ruby is a bad rip-off of Lisp or Smalltalk, and I admit that. But it is nicer to ordinary people."

• Matz, LL2

Czemu nie zdobył popularności? Bo ludzie tacy jak Ty mówią o nim, nie mając tak naprawdę o nim pojęcia (bo to niemożliwe, by mając znajomość w temacie głosić takie herezje) - nie znam nikogo, kto po dobrowolnym kontakcie z Lispem mówi, że to zły język, znam z kolei ludzi, którzy mówią to (albo raczej mówią, że nie spełnia ich oczekiwań, że ma parę rzeczy broken by design, że mogło być zdecydowanie lepiej) o PHP/Perlu/Javie/C/C++ . Kolega lubiący klacze z mojego obozu (chodzi mi o tego, który się wypowiadał w tym wątku, bo między Lispem a końmi jest nieuchwytna korelacja :P) pewnie podobnie by się wypowiadał o Haskellu (akurat Ty o tym pewnie wiesz, ale nie tylko my tutaj rozmawiamy). Jestem absolutnie przekonany, że gdyby CL miał chociaż w połowie taką społeczność jak Python czy nawet Ruby, to sprawa by wyglądała zupełnie inaczej - dzisiaj lispofili (:P) w Polsce można policzyć na palcach obu rąk i jednej nogi, może nawet tylko obu rąk. Ile ludzi zna Ruby? Setki. Skutkiem tego jest moja nachalna ewangelizacja, taka, jaką robi Paul Graham - nikt się nie zainteresuje Lispem, bo mu tak poleci kolega/nauczyciel/przeczyta na forum/whatever, bo prawdopodobieństwo, że jego mentor będzie go znał, jest znikome, może też znać go tylko stereotypowo, co jest jeszcze gorsze, bo zniechęci takiego newbie do zainteresowania się tym językem. Może jeżeli ktoś przeczyta to, co pisze, pomyśli "może coś w tym jest, skoro on pisze o tym z takim zapałem", więcej ludzi zainteresowanych pociągnie za sobą reakcję łańcuchową. Trzeba krzyczeć głośno, by przebić się przez barierę ignorancji.

Czemu warto się uczyć Lispu - bo to jedyny język, który daje gwarancję, że za 30, 40, 50 lat wciąż będzie używany (o ile oczywiście w międzyczasie nie nastąpi jakaś gigantyczna rewolucja). Fortran (tak się programowało, gdy zamiast terminali były karty perforowane), BASIC (kto i po co go w ogóle wymyślił?), COBOL (dawny sztandarowy język code grinderów, dzisiaj zastąpiony przez Javę, na którego nauczanie powinien być odpowiedni paragraf w kodeksie cywilnym), MUMPS (uwierzcie mi, nie chcecie wiedzieć) odeszły w zapomnienie, pochodnia Perla (to może się wydać kontrowersjne) powoli się wypala, PHP chwieje się w posadach i tylko zmiana całego języka bez zmiany nazwy może go uratować, a Lisp jest jak szczyt górski - stoi gdzieś tam, wielki, monumentalny, tak łatwo nie zniknie i tylko czeka na rozgłos.

@Ranides: a pokaz mi jezyk z ficzerami ktore nie sa znane od 40-50 lat

@dodekam: Z czegos brak spolecznosci lispu wynika.
Mnie spartanska skladnia i monstrualna ilosc nawiasow przeraza, kod pisany w lispie do pieknych imo nie nalezy (porownaj sobie identyczny kod w lispie i haskellu )
Mysle ze spora wada jest tez brak spojnego ogarniajacego wszystkie niuanse jezyka
uogolnilbym Twoja terorie, warto sie uczyc jezykow funkcyjnych bo to w nich drzemie moc ;]

o D sie nie bede wypowiadal bo nie ma o czym, kiepski jezyk 'wysokiego' poziomu juz ciekawszy jest taki Facktor, bo prezentuje zupelnie odmienne podejscie do problemu

Odnośnie 50-letnich ficzerów:
http://dodek.jogger.pl/2008/10/26/co-sprawilo-ze-lisp-jest-inny/

No tak, filozofia deterministyczna mówi, źe wszystko ma jakieś przyczyny. Jednak w przypadku Lispu niekoniecznie bym ich szukał w samym języku. Wg. Paula Grahama brak popularności Lispu nie jest spowodowany jego niźszością czy brakami. a właśnie popularnością innych języków. Jak napisałem w poprzednim poście, popularność sama się napędza. Po prostu społeczność Lispu musi osiągnąć "masę krytyczną".

W gruncie rzeczy Lisp i Haskell prezentują odmienne podejście do elegancji kodu - piękno Haskella polega głównie na tym, źe kod jest logiczny i skondensowany, a funkcyjność jest bardzo spójna i elegnancka. W Lispie głównie chodzi o prostotę składni ("spartańskość" to nie do końca trafne słowo, lepsze jest "ascetyzm") i jej jednolitość. co umoźliwia dalsze upięlszanie składni.

Brak spójności to bardzo celny argument. Jak powiedział Steve Yegge "Lisp is not acceptable Lisp."

A co do funkcyjności - ja to wiem, Ty to wiesz, a sporo ludzi i tak utoźsamia funkcyjność z strukturalnością czy nawet proceduralnością.

D moim zdaniem nie jest aź taki znowy kiepski, jak kaźdy nowy język jest coraz bardziej podobny do Lispu...

Teraz już nie pozostaje mi powiedzieć niz innego jak 'LOL'. W UML wpasowuje się każde OOP, każdy nowszy większy system w C++ był najprawdopodobniej projektowany z jego pomocą. Ddoc to tez nie argument (i to u Ciebie już przeciwko C a nie C++/C#) - jest chociażby Doxygen. Jest to zewnętrzne rozwiązanie ale to żaden argument - ani jeden powazny język i tak nie może się obyć przy poważniejszym użyciu bez zewnętrznych narzędzi i bibliotek. Szczerze powiedziawszy to lepiej niż D w przypadku UMLu i generowania dokumentacji wypada chociażby Ruby.
Ech, dlaczego nie odnosisz się do postów, jakby nie patrzeć, swoich rozmówców? Dlaczego z postu na post wyłącznie rzucasz argumenty bez pokrycia? Dlaczego w każdej kolejnej wypowiedzi porównujesz D do innego języka skoro zrobiłeś wątek o przewadze D nad C++? W takim układzie kontynuowanie tego wątku jest bezcelowe.

vide artykuł Djikstry o BASICu.

Ze sie tak wtrace: czy Dijkstrze nie chodzilo przypadkiem o tego BASICa, w ktorym sie pisalo cos w stylu
100 blabla
200 costam
300 GOTO 600
...
500 GOTO 100
....
622 GOTO 511
...
xxx GOTO yyy
??? Tu raczej nie chodzilo o B&D a raczej o brak programowania strukturalnego ;)
Ale fakt, uczenie Pascala czy C(++) w szkolach jako pierwszego jezyka jest moim zdaniem idiotyzmem, juz lepiej by sie wzieli za Pythona (jesli chca czegos uzytecznego) czy tez jezyka Oz (z ksiazki "Programowanie: Koncepcje, techniki i modele", inglisz werszyn w pedeefie - uwaga, 3.4 Mb)
Jezyk imho jest 'dosyc' dziwny (przez probe wepchniecia don wszystkich mozliwych paradygmatow jezyk wyglada jak skrzyzowanie Pascala z Lispem i Haskellem, do orgii dolaczyly sie jeszcze Erlang i Prolog oraz jakas niesmiala aczkolwiek radosna tworczosc autorow jezyka. Jako ze kazdy z partycypantow zostawil po sobie tylko jeden czy dwa charakterystyczne elementy, calosc jest podobna do ciezko stwierdzic czego. Ale jak sie to pojmie, to mozna w tym pisac calkiem przyjemnie.) ale po nim nowego programiste juz nic nie bedzie w stanie zaskoczyc. Bedzie umial programowac deklaratywnie, funkcyjnie, wspolbieznie (ze zmiennymi przeplywu danych, z przesylaniem komunikatow, czy nawet stanem dzielanym jesli mu to az tak do szczescia potrzebne), imperatywnie (w tym obiektowo) czy tez logicznie. I w dodatku bedzie wiedzial, by uzywac najmniej ekspresywnego paradygmatu w jakim da sie komfortowo opisac problem (by uniknac niepotrzebnych, a nieuniknionych w innym razie bugow) a nie bedzie wszedzie pchal programowania obiektowego niczym ch**a miedzy drzwi bo mu powiedzieli, ze 'wszystko jest obiektem'.

No ale wracajac do tematu:
Slyszalem kiedys taki poglad, ze C++ to taka proba zrobienia z C jezyka wysokopoziomowego, jakby przybic do psa dodatkowe 4 nogi gwozdziami i mowic, ze to osmiornica. W takim razie imho D bylby wyposazeniem takiego potworka w aparat nurkowy i pomalowanie go na jakis ladniejszy kolor.
Zamiast dorabiac na sile nowe jezyki blizniaczo podobne do poprzednich nalezalo by sie imho skupic na pchaniu istniejacych w strone Lispa :D

Pytanie do kolegi winerfresha - czy przyznanie się do błędu jest czymś haniebnym? Tak się składa, że standardowo po posprzątaniu serwisu zajrzałem do logów edycji, trafiłem na coś ciekawego:

  winerfresh	09-12-2008 06:50:05	Post 498617 w temacie D vs. C++ został usunięty
  winerfresh	09-12-2008 06:49:22	Post 495005 w temacie D vs. C++ został usunięty
  winerfresh	09-12-2008 06:49:10	Post 497746 w temacie D vs. C++ został usunięty

Usunięte zostały posty, do których odnoszono się najczęściej, których treść była najbardziej krytykowana. Co ciekawe, posty te zostały napisane miesiąc temu.
Cóż, kolejny próbuje zatuszować swoją niekompetencję kasując wypowiedzi gdy sprawa przyschnie. Winerfresh, a nie zauważyłeś przypadkiem, że te posty i tak zostały zacytowane przez innych użytkowników?

Zapewne miło jest być fanatykiem po cichu wycofującym się ze swoich poglądów.

Zauważyłem