Kod: Zaznacz cały
open FILE, "sth.txt" or die $!
Nie prównywałbym Scala z C++, Scala to raczej następca Javy (jest też wersja .NET), posiada dodatkowo możliwość uruchamiania programów jako skryptów. Jedną z ważniejszych cech tego języka jest łatwość korzystania z zewnętrznych modułów (w szególności Javy). Nie wiem czy jest wsparcie w odwrotnym kierunku.Czyli Scala to takie ubogie C++0x kompilowane do vm javy (C++0x (a w GCC od 4.4) też zgaduje typ (typ "auto"))? Masz jakieś informacje o osadzaniu interpretera Scala w kodzie C++? Na szybko nic nie znalazłem, a bez tego język skryptowy jest dla mnie bezużyteczny.
Czyli z tego wniosek, że i tak odróżnianie zasięgu odbywa się za pomocą wcięć w kodzie. Niepisanie dodatkowo nawiasów to kwestia przyzwyczajenia i dobrego edytora (choć przynaję, że przy kopiowaniu kawałków kodu bez użycia nawiasów klamrowych w pythonie jest to trudniejsze, bo trzeba to robić uważnie aby zachować zasięg)Czytelność to zdecydowanie nie mniejsza ilość znaczków (wcięcia temu przeczą ;p). A liczyć {} nie musisz, jeśli nie jesteś masochistą i robisz wcięcia - wtedy (gdy nie jesteś masochistą) bloki {} są dużo lepsze niż te z białych znaków.
No i też czas potrzebny na napisanie aplikacji będzie znacznie dłuższy od napisania jej w języku skryptowym (np. Python - PyGTK, PyQt4).
Można tutaj wieleTak liczy się umiejętność programowania obiektowego, ale jeszcze bardziej w cenie jest dziś (i zawsze będzie) programowanie wydajnych programów i dlatego ruby jest niszą i niszą pozostanie, a do poważniejszych zastosowań będzie się stosować javę (czy to na stronach jako jsp czy jako aplikacje), i c++.rack pisze:Ja powiem tak,
C ani C++ do nauki programowania się nie nadaje ... dziś liczy sie umiętność programowania obiektowego.
Boehm GC i w C/C++ też nie musisz się martwić... zresztą myślisz, że z jakiego GC korzystają interpretery ruby (nie wszystkie, ale kilka tak) - Boehm GC jest włączony do GCC (biblioteka gc).rack pisze:... tym, że java stoi o krok wyżej w tej hierarchi bo nie musisz babrać się sam z pamięcią (ma poza tym jeszcze kilka innych udogodnien).
Lua miał chwilowy epizot jako język skryptowy w grach (tak jak i python), i faktycznie łatwo go się osadza (podobnie łatwo jak inne języki stosowane w grach jak np. python, gamemonkey, angelscript czy nawet java (przez jni))... ale ma wiele wad przeciętnego języka skryptowego i praktycznie wszyscy się już wycofali z korzystania z Lua. Z wymienionych języków do osadzania najlepszym wyborem jest angelscript, jeśli ma się pisać w obrębie firmy - jeśli ma być dla innych osób, a nie dla siebie, to python, bo zna go wiele osób - linuksowych gier które pewnie znasz np. seria Penumbra korzysta z angelscript. Większość gier jednak korzysta z języków wbudowanych w silnik jak np. UnrealScript - jednak większość one korzystaja z mocnego typowania i zalet języków c/c++ (jak pisze się komercyjnie, nie ma miejsca na te "udogodnienia"/utrudnienia).rack pisze: Jeżeli mowa o osadzaniu jakiegoś języka w C++ to polecam Lua ... To najlepsze z mozliwych rozwiązań, uznane i stosowane od lat ...
Czyli coś jak Libhover z Eclipse Linux Tools Project (pluginy dla linuksa dla programistów C++ pisane przez redhat)rack pisze:Ruby ma coś co się nazywa ri, czyli dokumntację metod i klas pod ręką , właczając przykłady użycia ...
Świat nie stoi w miejscu i C++ też się zmienia - zaraz zostanie wydana nowa specyfikacja języka C++0x - Świat nie wychodzi z tego, a nawet się umacnia (i C++ jest tak ugruntowany w rynku, że nie wiadomo czy i kiedy będzie zagrożony - nawet języki jak D (łączące zalety języków kompilowanych ze skryptowymi) się nie spopularyzowały - po prostu jako język kompilowany ma taką dominację, że można powiedzieć, że inne języki nie istnieją - inne języki mogą być tylko jako nisza w kompilowanych do pośredniego kodu, lub skryptowe) tylko powstają nowe dziedziny w których można sobie pozwolić na takie języki skryptowe (np. strony internetowe).rack pisze:Moim zdaniem wszystko jest lepsze na początek od C++ i Javy. Świat z roku na roku wychodzi z tego ... nie warto się w to teraz pchać ....
)Assembler do dzisiaj jest używany mimo, że nikt w nim nie pisze aplikacji użytkowych i tak będzie zapewne w przyszłości, że języki kompilowane będą ciągle używane, ale nie do programów użytkowych. Pewnie to miałeś na myśliZgadzam się, że wydajność aplikacji to rzecz nader istotna, z drugiej jednak strony, nie wierzę ze za jakiś czas nie doczekamy się znacznie szybszych procesorów (jak wiadomo prace nad nimi trwają i mają się dobrze... choć niektórzy mówią ze dochodzimy do kresu możliwości. Nie wierzę ,człowiek nie potrafi zatrzymać się w miejscu ...). W takiej sytuacji być może spadek wydajności spowodowany uzyciem języka skryptowego będzie pomijalny ... Dziś to brzmi jak herezja, jednakże takie głosy daje się słyszeć tu i ówdzie ... Języki skryptowe są znacznie bliższe cżłowiekowi niz maszynie, dzięki czemu pisze się po prostu szybciej ... to co napisano przez ostatnie 30 lat teraz może być pewnie napisane w kilka ... Podejżewam, że za kilka czy kilkanaście lat moc obliczeniowa procesorów na tyle wzrośnie, że większośc ludzi nie będzie sobie truć głowy językami kompilowanymi ...
Należy też pamiętać że interpretery też nie stoją w miejscu i pojawiają się takie rzeczy jak JIT, które poprawiają wydajność języków skryptowych.W takiej sytuacji być może spadek wydajności spowodowany uzyciem języka skryptowego będzie pomijalny
Procesory dużo szybsze nie będą (granica możliwości krzemu już prawie osiągnięta, co widać od co najmniej kilku lat (częstotliwość nie jest zwiększana)) - będzie ich po prostu więcej (rdzeni), co jednak nie idzie zawsze razem ze wzrostem wydajności (nie wszystkie algorytmy da się rozłożyć na wątki). Nie będzie pomijalny - jest jeszcze tyle rzeczy i algorytmów, które nie dają się wykonać nawet na najlepszych superkomputerach (wykonywałyby się przez tysiące lat), że nie ma się o co martwić, że kiedyś wydajność będzie za duża i będzie można olać ją.rack pisze: Zgadzam się, że wydajność aplikacji to rzecz nader istotna, z drugiej jednak strony, nie wierzę ze za jakiś czas nie doczekamy się znacznie szybszych procesorów (jak wiadomo prace nad nimi trwają i mają się dobrze... choć niektórzy mówią ze dochodzimy do kresu możliwości. Nie wierzę ,człowiek nie potrafi zatrzymać się w miejscu ...).
W takiej sytuacji być może spadek wydajności spowodowany uzyciem języka skryptowego będzie pomijalny
Są bliższe człowiekowi... dopóki nie zrobi się błędu i będzie trzeba szukać gdzie... to co napisano przez ostatnie 30 lat teraz można napisać w kilka w C/C++ - po prostu powstały nowe algorytmy, technologie, badania i teraz jest ogólnie dostępna wiedza do której się przez lata dochodziło.rack pisze:Języki skryptowe są znacznie bliższe cżłowiekowi niz maszynie, dzięki czemu pisze się po prostu szybciej ... to co napisano przez ostatnie 30 lat teraz może być pewnie napisane w kilka
Póki co idzie się w stronę przeciwną i aby wykorzystać moc domowych klastrów (kart graficznych) trzeba się cofnąć do ASM lub języków pochodnych od C (Ati STREAM, CUDA, OpenCL)... i nie spodziewałbym się na Twoim miejscu pójścia dużo wyżej z poziomem.rack pisze:Podejżewam, że za kilka czy kilkanaście lat moc obliczeniowa procesorów na tyle wzrośnie, że większośc ludzi nie będzie sobie truć głowy językami kompilowanymi ...
Bibliotek dla pythona czy ruby nie przepisuje się do C/C++... bo tam są już odpowiedniki, lub lepsze, a tworzy się wrappery na biblioteki natywne pisane w C/C++ do języków skryptowych... bo twórcy tych bibliotek olewają te języki i piszą tak jak mainstream (praktycznie wszystkie biblioteki, poza pojedynczymi wyjątkami) i programiści piszący w tych językach przygotowują z opóźnieniem wrapper na bibliotekę, żeby mieć w swoim języku możliwości takie jak w c/c++.rack pisze:Zresztą nawet dziś, to co ma być skompilowane może być spokojnie napisane w C i wrzucone dowiązane do aplikacji w języku skryptowym ... Bibliotek napisanych dla Pythona czy Ruby nie przepisuje się na C ... a większośc tych z C i C++ ma już dowiązania do tych nowych języków skryptowych ... Trend jest moim zdaniem jasny, oddalamy się od języków dla komputera za cenę wydajności ...
false - c++ tak długo się utrzymał właśnie ze względu na szybkość i to jest jego jednym z głównych atutów.Ogólnie, java czy C++ z Boostem nie są złe ... one po prostu nie dorastają do dzisiejszych czasów i podejrzewam ze z roku na rok będzie im coraz trudniej nadąrzyć .. ilość starego kodu jest coraz większa ... a atut szybkości będzie tracił swój blask z czasem.
to jest niedościgniony wzór uczy myśleć rozwiązywanie problemów a nie język programowaniaroberto234 pisze:Pascal nauczy cię myśleć. Nie zastanawiasz się czy jak zrobisz szpagat komend coś ci z tego wyjdzie tylko piszesz
ten sam problem można rozwiązać przecież w C++, Java, PASCAL, a nawet jakby się uparł JavaScript:craz:Możesz napisać jakie "szpagaty" miałeś na myśli? Akurat to co podałeś jest bardzo podobne w każdym języku (tylko co najwyżej czytelniej zapisane), np.roberto234 pisze:Pascal nauczy cię myśleć. Nie zastanawiasz się czy jak zrobisz szpagat komend coś ci z tego wyjdzie tylko piszesz
Jeżeli cos=iles wtedy zrób
czyli
If a=1 then writeln('cos');
Ale przynajmniej piszesz w jednym pliku;) W C++ zwykle musisz pisać często w dwóch miejscach w dwóch różnych plikach;)A to właśnie jakieś dziwne szpagaty wychodzą w pascalu (żeby jedną rzecz zrobić musisz pisać w wielu miejscach w kodzie na raz (osobno dopisujesz zmienną do var, osobno piszesz etc.)).
Nie jest to do końca prawda - częstotliwości taktowania, co prawda nie rosną, ale wydajność owszem - mój c2d 3GHz liczy liczbę PI dwa razy szybciej nić P4 o tej samej częstotliwości (algorytm jest jednowątkowy, więc ilość rdzeni jest nieistotna).Procesory dużo szybsze nie będą (granica możliwości krzemu już prawie osiągnięta, co widać od co najmniej kilku lat (częstotliwość nie jest zwiększana))
Boost. Już wiem, dlaczego programy w C++ są takie szybkie. W czasie gdy program się kompiluje, programista może przeczytać dobrą książkę o algorytmach i potem może lepiej zoptymalizować program.i tona innych rzeczy znanych z boost
Ale dużo buzzwords... W każdym razie, piszesz tak, jakby wydajność była jedyną istotną cechą programów. A tymczasem dla użytkownika w większości przypadków ważniejsza jest funkcjonalność, ergonomia, niezawodność, a języki niskiego poziomu, takie jak C++, często utrudniają osiągnięcie tych celów. Po co mi komunikator internetowy wykorzystujący SSE? To tak jak zakładanie tarcz hamulcowych BREMBO do meleksa...Trend jest taki sam od wielu lat - wchodzi coś nowego (shadery(asm ->glsl/hlsl/cg (języki oparte na C)), jednostki obliczeniowe (asm->cuda/opencl(oparte na C)), nowe procesory (asm (rozszeżenia jak sse,mmx...)->nagłówki dla C/C++)...) to programuje się z użyciem ASM, później pisze się w C, a dopiero po tym w C++ (chociaż najczęściej zatrzymuje się na C, bo C++ zawiera C)... i na tym koniec!
) I do tego to się w sumie sprowadza . Jedni mają zacięcie do C++ inni nie ... Ja akurat nie mam, odkąd nauczyłem się języków skryptowych, nigdy nie myślałem o powrocie do kompilowanych ... Ot i cała filozofia, po prostu jestem leniem i co gorsza wcale się z tym nie kryję. Nie mam tez dobrej pamięci, więc trzymam wszystko w bazie danych ... 
Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 24 gości