jak zapisac do stalych?

0

witam chcialbym zrobic zeby pkt byly zapisywane w programie i jak wyjdzie sie z niego i wejdzie wyswietlone zostana jako juz zmienione poprzednim razem
np a =10
doadam w programie + 10 i a bedzie 20 co zrobic zeby zostalo na stale te dwadziescia

tak przypisuje wartosc punktowa

        if(pkt>=pierwsze){pom=pierwsze; pierwsze=pkt; pom2=drugie; drugie=pom; pom=trzecie;  trzecie=pom2; pom2=czwarte; czwarte=pom; piate=pom2;}

        else if(pkt >=drugie){pom2=drugie; drugie=pkt; pom=trzecie; 
            trzecie=pom2; pom2=czwarte; czwarte=pom; piate=pom2;}

        else if(pkt >=trzecie){ pom=trzecie; 
            trzecie=pkt; pom2=czwarte; czwarte=pom; piate=pom2;}   
        else if(pkt >=czwarte){pom2=czwarte; czwarte=pkt; piate=pom2;}

        else if(pkt >=piate){piate=pkt;}
        
0

Zapisać do pliku, a potem z niego odczytać?

0

plik, baza danych

0

a nie da się bez tego? hmm a może mógłby ktoś powiedzieć jak zapisać i odczytać? i chyba trzeba by było Zamienic na string na int a później na odwrót?

0

no, ale na logikę jak ? :)

gdzieś to przecież musisz zapisać jeśli chcesz zamknąć program.

odczyt do pliku to poczytaj o FileWriter, Strumieniach itp

to się wydaje na początku wydaje pogmatwane ale takie nie jest.

0
Fixus napisał(a)

odczyt do pliku to poczytaj o FileWriter, Strumieniach itp to się wydaje na początku wydaje pogmatwane ale takie nie jest.

Jest zagmatwane i to cholernie, tony wrapperow i dekoratorow. Na poczatku sie wydaje zagmatwane, na koncu rowniez, tyle ze sie przyzwyczailes. Zobacz np. Pythona jak tam wyglada dostep do plikow.
Nie mowie ze to jest zla architektura ktora zrobili, te dekoratory - gdy trzeba masz pelna kontrole. Mowie, ze mogliby dorobic jakas fasade dla niezbyt skomplikowanych apliacji / nie do konca power users.

0

Najprostsze pisanie do pliku jest proste.

try
{
    FileWriter out=new FileWriter("test.abc");
    // lub
    FileWriter out=new FileWriter("test.abc",true);
    out.write("coś ciekawego");
    // lub
    out.append("coś ciekawego");
    out.close();
}
0

To teraz pokaz kod ktory wczytuje linijka po linijce, w petli.

0

Aha, zapisujemy i odczytujemy w UTF8. Jestesmy srednio zaawansowanymi programistami, ale swiadomymi problemow kodowania, i chcemy aby nasz plik z polskimi i chinskimi znakami mozna bylo tak samo odczytac pod xp, vista jak i 7. No i jeszcze jakies Unixy.

Bez zastanowienia sie w tym i poprzednim przypadku razem masz 3 wrappery:
a) file input stream
b) InputStreamReader ktory bierze stream z a) oraz kodowanie
c) buffered reader ktory dekoruje b)

Python:

with open('test.txt', encoding = 'utf8') as file:
for line in file:
print(line)

Zauwaz ze tutaj w tych 3 linijkach masz od razu zapewnione zamkniecie pliku bez wzgledu na to czy bedzie wyjatek czy nie. Nie zapomnij wiec w przykladzie Javy dodac try / catch / finally (niepotrzebne skreslic).

0

Jak sobie życzysz

import java.io.*;

public class ReadAndWrite
{
    public static void main(String[] args)
    {
        try
        {
            FileWriter out=new FileWriter("Test.txt");
            for(int i=1;i<=33;i++)
            {
                out.write("wiersz nr "+i+"\n");
            }
            out.close();
        }
        catch(Exception e)
        {
            System.out.println(e);
        }
        try
        {
            BufferedReader in=new BufferedReader(new FileReader("Test.txt"));
            while (in.ready())
            {
                System.out.print(in.readLine()+"\n");
            }
            in.close();
        }
        catch(Exception e)
        {
            System.out.println(e);
        }
    }
}

0

Nie chodzi o to ze ja tego nie umiem. Chodzilo mi o to zebys pokazal jak to jest proste. To co napisales to po prostu poezja.

Dodatkowo, masz blad. Zarowno przy wczytywaniu jak i zapisywaniu, linijka po linijce sobie piszesz / czytasz, i na koncu masz close(). Wszystko ladnie w try / catch. A co sie stanie np podczas pisania, gdy przy zapisie dostanieszs wyjatek? Kod leci do bloku catch, a plik nie zostanie zamkniety. To samo w czytaniu. Jak chcesz to porzadnie obsluzyc, musisz close() dac w finally, ot, cos takiego:

import java.io.*;
 
public class JustWriteIHaveNoStrengthToDoTheReadAsWell
{
    public static void main(String[] args)
    {
       FileWriter out = null;
        try
        {
            out=new FileWriter("Test.txt");
            for(int i=1;i<=33;i++)
            {
                out.write("wiersz nr "+i+"\n");
            }
        }
        catch(Exception e)
        {
            System.out.println(e);
        }
        finally {
            if (out != null) // udalo sie otworzyc plik
            {
                 try
                {
                     out.close();
                 }
                 catch (IOException exc)
                 {
                      // ignorujemy, chcemy aby oryginalny wyjatek zostal rzucony
                      // jseli byl przy pisaniu, chcemy aby on zostal rzucony, a nie przypadkowo
                      // IOExc powstaly przy zamknieciu
                  }
            }
        }
    }
}

Piekny idiomatyczny kod.

Nie wspomne ze nie podales kodu na unicode, ale zakladam ze zaczales pisac zanim dodalem tego drugiego posta.

0

Dodam tylko ze taki bledny kod jak Twoj pisza progamisci bez wzgledu na poziom. Nawet Joshua Bloch (pewnie kazdy javowiec wie kto to) w swojej Effective Java uzyl kodu ktory jest bledny, co zreszta sam przyznaje w swoim proposal w projekcie Coin aby wspierac 'resource mangery' dla plikow (a'la with w pythonie, using w C#, cokolwiek pragniesz w scali (jest kilka opcji), i wiele innych w innych jezykach).

To jest tylko dowod na to, ze ktorys z poprzednikow nieco sie zagalopowal twierdzac ze to jest latwe, i tylko na poczatku sprawia problemy. Sadze ze Josh Bloch napisal duzo kodu i jednak zrobil taki blad. A jego wspolautor go nie zauwazyl...

0

JDK 7 to znacznie ułatwia:

// Tradycyjnie:
try (FileWriter out = new FileWriter("test.txt")) {
    for(int i = 1;i <= 33; i++) {
        out.write("wiersz nr " + i + "\n");
    }
} catch (IOException ex) {
    // obsługa
}

Path file = new File("test.txt").toPath();
Charset charset = Charset.forName("UTF-8");

try (BufferedWriter out = Files.newBufferedWriter(file, charset)) {
    for(int i = 1;i <= 33; i++) {
        out.write("wiersz nr " + i + "\n");
    }
} catch (IOException x) {
    // obsługa
}

String line = null;
try (BufferedReader reader = Files.newBufferedReader(file, charset)) {
    while ((line = reader.readLine()) != null) {
	System.out.println(line);
    }
} // nie potrzeba catch ani finally, wyjątek rzucany wyżej

// Jeszcze prościej:
for (String line : Files.readAllLines(file, charset))
    System.out.println(line);

Skomplikowane? Wszystko to samo w DWÓCH linijkach, nie licząc obsługi wyjątków.
Ogólnie warto zajrzeć do klasy java.nio.files.Files.

0

Tak, przeciez napisalem ze Josh Bloch w Coin napisal proposala, i to jest wlasnie taki 'spimpowany' try. Jednak poczytaj tu i tam jakie to ma nastepstwa - nie wszystko jest piekne i ladne jak mialo byc, ze wzgledu na backwards compatibility, ktore jave zabija.
Ale ogolnie masz racje - powiedz mi teraz jeszcze, ile lat na to czekamy, my, programisci Javy?

0

Co do Files.readAllLines - to wczytuje caly plik na raz i zwraca liste linijek. Malo przydatne w praktyce dla jakiegokolwiek wiekszego pliku, co nawet dokumentacja tej metody jasno i wyraznie mowi, sprawdz.

Analogiczny kod w Pythonie zwraca 'generator' ktory jest tak jakby leniwym iteratorem - linijka po linijce sa wczytywane (z mozliwym lookahead) jedna po drugiej. Wiec nadal jesli chodzi o przejrzystosc nie ma porownania.

Zeby nie bylo, jestem programista glownie Javy, ktora lubie, szczegolnie lubie JVM za to ze umozliwia uruchomienie app w wielu jezykach, w tym i Python i Ruby. Dlatego ubolewam nad bieda tego jezyka i tym, ze jest dinozaurem wsrod seksownych jezykow. A wszystko to przez JCP ktore i tak jest zombie, wymaga kupe czasu i jej wyniki sa przestarzale zanim jeszcze osiagna wersje final (wszystkie JPA i inne EJB, ktore funkcjonalnoscia z Hibernate, natywnym EL czy Spring nie maja sie co rownac).

0

Ale ogolnie masz racje - powiedz mi teraz jeszcze, ile lat na to czekamy, my, programisci Javy?

Myślę, że programistom Javy wcale to nie jest potrzebne - ten język zawsze był rozwlekły i ciężki. Jak na razie nie czytałem niczego konkretnego o JDK 7, ale nie widzę powodu, by zaraz się na to przenosić. Nowe zmiany są raczej czysto kosmetyczne, a wprowadzają jedynie więcej cukru do języka (switch ze stringiem < pattern matching). Zawsze można wybrać któryś z tych seksownych języków, o których mówisz i zyskiwać jeszcze na interopie z Javą.

0

Dokladnie tak samo uwazam. Javy juz nic nie uratuje ;d a na pewno nie marne proby typu Project Coin czy te 4 pomysly na wsparcie closures. Od tego sa inne jezyki.

Ale nikt mi nie wmowi, i niech lepiej nie mowi nowicjuszom, ze ta obelga ktora nazywa sie java.io jest wcale nie taka zla i trudna - wyprostowanie tego nieprawdziwego stwierdzenia bylo moim celem. Jelsi ktos nie zna innych podejsc i jezykow, to niech nawet sie nie odzywa, bo nie ma z czym porownac. I niech nie pokazuja ludziom zlego kodu.

0

tak śledzę ten wątek i wychodzi na to, że JAVA to czyste zło :)

0
iooi napisał(a)

Myślę, że programistom Javy wcale to nie jest potrzebne - ten język zawsze był rozwlekły i ciężki.

Mysle, ze programisci Javy czesto gesto nie znaja nic innego, nie maja porownania, i wydaje im sie ze czegos nie potrzebuja. Jednak okazuje sie ze potrzebuja, ci co bardziej rzutcy jednak pracuja nad NIO2 i Twoja klasa Files, aby inni nie cierpieli tak jak teraz.
To ze Ty uwazasz ze ktos czegos nie potrzebuje nic nie znaczy, poza tym, ze nie znasz alternatyw i jestes niechetny je poznac, bo przeciez Java to i tamto w ten sposob. Jak sie okazuje, nawet doswiadczenia 'programisci' Javy nie znaja swojego jezyka, jak zostalo pokazane w tym watku - nie potrafia poprawnie obslugiwac plikow i zamykac tak aby nie bylo wyciekow. Tacy programisci jednak, moim zdaniem, szczegolnie potrzebuja takiej pomocy jak wprowadza JDK7.

Pytanie jest takie - czy piszac taki kod na wczytanie linijka po linijce, po raz N-ty, powinienes sie zastanawiac nad tym jak i co i kiedy zamykac? Czy powinienes napisac te 3 linijki, przetestowane przez kogos innego, i skupic sie na tym co jest Twoim zadaniem - przeprocesowanie tych linijek? Przeprocesowanie w tym przypadku to bylo wypisanie na ekran, jest program ktory to robi pod Unixami, nazywa sie 'cat', wiec wcale nie jest to przyklad z d**y wziety. Porownaj ile % kodu w tym przypadku to narzut bezsensownego, wtornego i bledogennego zajmowania sie plikami.

Przepraszam wszystkich za moje zdanie, i juz nie bede, bo zaraz jakis flame poleci.

0

Te kilka linijek można wyklepać w IDE w jakimś template. Okej, fajnie, że dodali wrappery zmniejszające długość kodu o 0.001% - w Javie tych linijek jest tyle, że to i tak niewiele zmienia. Nie mówię, że takie smaczki są niepotrzebne programistom Javy, ale raczej, że Javie są niepotrzebne.
Mimo to, jeśli już są, to zawsze warto korzystać.
Co do Files.readAllLines - mhm, trochę bez sensu, w Javie równie łatwo można by to zaimplementować leniwie.

0

Stary, nie czaisz bazy - to jest tylko przyklad, ktory akurat sie nawinal, te cale strumienie. W kazdym innym miejscu masz setki i tysiace takich przykladow. Ale nie ma co gadac, tylko trzeba isc kodowac, sa tysiace linii do napisania. Glownie klamry. I ify.

Files.readAllLines - moze i w Javie da sie napisac leniwie, ale dlaczego nie zostalo tak napisane? Widocznie nie da sie wystarczajaco generycznie. Ok, mozesz sobie napisac. Ale dlaczego masz to robic Ty? W kazdym projekcie ktory tego potrzebuje? (Tak wiem ze mozna napisac sobie liba i go wlaczac do projektu. Ale czasami ludzie zmieniaja prace, i takiego liba nie wolno normalnie wziac ze soba - wszystko co napiszesz w pracy nalezy do firmy, a wyniesienie jara to kradziez kodu. Freelancerzy maja troche inaczej, ale z mojego doswiadczenia wynika ze to i tak sa oblatani ludzie ktorzy wybieraja narzedzie do zadania, a nie jeden jezyk ktory zalatwia wszystko. I ma klamry.)

Fixus napisał(a)

tak śledzę ten wątek i wychodzi na to, że JAVA to czyste zło :)

Nikt tego nie powiedzial.

0

Ale mówiliśmy akurat o trudności w obsłudze tych strumieni. Przecież cała biblioteka standardowa nie jest tak "fatalnie" napisana.
Sam język Javy nie pozwala na wiele i dlatego nie jest taki zwięzły i prosty, jakkolwiek starano by się go odświeżyć. Od tego są inne języki.

0

Napisalem wczesniej, ze te dekoratory nie sa zle, na pewno nie fatalne, daja pelna moc. Jednak, jest to dluga i ciezka droga mocy prawowitego Jedi; czego brakuje to mozliwosc tymczasowego przejscia na ciemna strone aby zrobic w paru linijkach to co w danej chwili jest potrzebne, np jakis prototypik. Niech te dekoratory zostana; niech dodadza fasady.

Co do reszty biblioteki - jest wiele tragicznych API w Javie, np. java.util.Date oraz java.util.Calendar. Super przestarzaly Swing plus tony java.awt ktory ma klasy dla eventow i layoutow, ale reszty sie juz nie uzywa (chodzi mi o java.awt.Button i inne). Przetwarzanie kolekcji wymaga za kazdym razem pisanie petli for each lub while z iteratorem, java.util.Collections i jej statyczne metody niewiele pomagaja (na szczescie jest google-collections czy nowsze google-guava, ale tam tez same statiki bo inaczej sie nie da; mieli z Javie dorobic 'rozszerzanie interfejsow' z domyslnymi implementacjami aby utrzymac kompatybilnosc wsteczna, ale padlo bo 'za duzo za nowe'). java.util.logging i ich kadlubkowe loggery, ktore sa konfigurowane w pliku raz na typ, nie raz na instancje. Nie chce mi sie dalej wymieniac bo za dlugi post wyjdzie.

Kazda z tych funkcjonalnosci ma jakas bilioteke ktora mozna sciagnac z zewnatrz (JodaTime, wspomniane google, logback, slf4j, poroniona commons-logging, ...). Do tego, kazdy jar moze miec inna licencje.

Ale nie chodzi tu o biblioteke standardowa; chodzi o jezyk ktory jest z poprzedniej epoki. Czy ktos z czytajacych ten watek i moje wypociny potrafi porzadnie, poprawnie programowac z genericsami? Mnie wielokrotnie przerastaja, moze glupi jestem. Czy to jest dobra funkcjonalnosc? Nie, zostala uposledzona juz przy incepcji, gdy powiedziano ze wspolistnieja z raw types, nie sa reifikowalne itp itd, aby byla kompatybilnosc wstecz. Jeden z czlonkow zespolu (Martin Odersky, tworca Scali) na wykladzie na ktorym bylem zapytany o to przeprosil za to co zrobili.

Nie jestem jedyny ktory ma z tym problem. Dlatego powstaja inne jezyki, jak wiele wspomnianych. JBoss teraz wymysla jakis nowy (project Ceylon) ktory wyglada ciekawie, ale ma pewne 'odchylenia od normy' i dla ludzi ktorzy siedza tylko i wylacznie w Javie jest nie do zaakceptowania.

@iooi: przyznaj sie jesli masz odwage, w ilu jezykach programowania potrafisz cos konkretnego napisac? Nawet traktujac jazyki z kategori c-pochodnych/podobnych jako osobne - maja co prawda ten sam paradygmat i podobne podejscia, nic tam nie ma odswiezajacego (no moze C/C++ i wskazniki, i elementy programowania funkcyjnego ze wskaznikami na funkcje / metody). Z tego co mowisz wynika ze znasz tylko Jave, w przeciwnym wypadku bylbys swiadomy jej brakow.

Szkoda ze Wibowit sie nie dolaczyl ze swoimi przykladami w / argumentami za Scala - to jest dopiero ciekawy jezyk, dajacy wielkie mozliwosci. Poucz sie, poznaj, poprogramuj, i wroc do Javy. Zbierze sie na wymioty.

0

Sam piszę w Scali i przecież właśnie o to mi chodzi - Java jest przestarzała, ale nie można zrobić z niej nowego języka i zmienić przy tym myślenie wszystkich znacznej części programistów Javy - jak komuś brakuje porządnych genericsów, pełnej obiektowości, dobrze zaprojektowanych kolekcji, łatwej wielowątkowości, przyjemnego podejścia do funkcyjności, to niech wybierze inny język (np. Scalę, chociaż ta nie do końca ma to wszystko - choćby generyki skopane przez JVM). To tak, jakby obrażać się za to, że w C nie ma gc.
A właśnie, co do Scali, to ta też praktycznie nie oferuje porządnego api do obsługi strumieni (oprócz jednej małej, przyjemnej klasy do wczytywania, niżej kod). Raczej trzeba używać klas Javowych / zewnętrznych bibliotek.

for (line <- Source.fromFile("test.txt", "utf-8").getLines)
  println(line)
1
  1. Piszecie, żeby dodać do Javy kope pomocniczych funkcji, wymieniacie google-guava, JodaTime, etc Same te dwie biblioteki zajmują w sumie ponad 6 MiB, podczas gdy instalka JRE offline zajmuje 16 MiB. Ilu programistów ma chęć i potrzebę używania tych bibliotek? Ja np nigdy JodaTime nie używałem, więc zwiększanie JRE o 20 % z tego powodu to byłaby wg mnie tragedia. Każdy programista ma pewnie z megabajt swoich często używanych funkcji, gdyby tak każdy chciał je dorzucić do JRE to chyba wiadomo co by się stało.

  2. Pokazujecie jakieś cukry z Pythona co do iteracji po pliku, a potem narzekacie, że w innych językach tego nie ma. No cóż, korzystanie z plików w ten sposób to i tak przeżytek, jak słusznie zauważyliście (sami napisaliście, że używa się managerów). Ale i tak można to opakować w jakąś klasę przecież.

  3. JVM działa na jakichś tam OSach, a więc jest przez te OSy ograniczany. Dlatego trzeba explicite zarządzać zasobami, czy to bezpośrednio czy też we wrapperze/ managerze. Obojętnie czy używamy Pythona, Javy, Scali, C#, Haskella, Clojure, itp i tak musimy użerać się z tymi samymi podstawowymi utrudnieniami.

Oto kilka rzeczy, które są wspólne dla większości/ wszystkich (zależnie) obecnych platform, a których nie byłoby w moim wyidealizowanym świecie:

  • zarządzane explicite zasoby typu pliki czy połączenia TCP - zamiast tego można używać baz danych i protokołów komunikacji bezpołączeniowej (typu UDP),
  • wskaźnik null i błędne wskaźniki - zamiast null można zastosować Option (dostępnego np w Scali) czy Null Object Pattern lub inne rozwiązania (np wyjątki) (poczytajcie opinię o nullu od jego twórcy, Hoare: http://en.wikipedia.org/wiki/Pointer_(computing)#Null_pointer ),
  • wątki, które są źródłem różnych zakleszczeń, błędów kolejności dostępu itp - zamiast tego same procesy, np mechanizm mailboksów czy aktorów dostępnych w Erlangu czy Scali, przy dobrej implementacji na najniższym poziomie (czyli wykluczających istnienie obecnie stosowanych w OSach mechanizmów wielowątkowości) mogłoby to być nawet wydajniejsze od wątków, a znacznie ułatwiają abstrakcję wymiany informacji; aktorzy mogą istnieć zarówno na jednym komputerze jak i na osobnych, mechanizmy są takie same, zarządzanie jest praktycznie transparentne dla programisty,
  • współdzielony (przez procesy) mutowalny stan,
  • globalny, statyczny i mutowalny stan,
  • formaty plików - zamiast tego można wszystko serializować; wymagałoby to wspólnego formatu serializacji i wspólnego formatu bajtkodu do obsługi tych zserializowanych plików,
  • brak wbudowanego zwięzłego, elastycznego i wydajnego mechanizmu wstrzykiwania zależności,

Platforma Java czy .NET to nie są jakieś cuda, mają bardzo dużo wspólnych bolączek i myślę (mam nadzieję), że za kilkanaście lat zostaną wyparte przez coś co pozwoli pisać bardziej zwięzły i elastyczny kod.

Język Java praktycznie się nie rozwija, ale za to np Scala bardzo dynamicznie i z powodzeniem można by coś samemu w Scali poprawić czy coś zaproponować. Zawsze to jakiś krok w dobrym kierunku. Gdyby Haskell był obiektowy i był oparty na kodzie zarządzanym to wtedy byłby dla mnie bardzo interesujący. (Haskell jest bardzo wysokopoziomowy, a mimo tego wydajny. Niemutowalność pozwala np na łatwe skuteczne i ogólne automatyczne zrównoleglanie kodu - bardzo fajna sprawa, bo pozwala skupić się na funkcjonalności, a nie na explicite zarządzaniem współbieżnością, jak np w OpenCLu czy nawet normalnych wątkach.) Ale tak ogólnie to obecnie dla mnie nr 1 jest Scala, nawet mimo tego, iż dziedziczy sporo złego po platformie Java.

Z drugiej strony język Java właśnie przez swoją prostotę jest bardzo łatwy do nauczenia. Scala jest dość skomplikowana, mogłaby być jeszcze bardziej, gdyby nie ograniczenia JVMowe (np brak obsługi genericsów w JVM). I tu jest problem: język Java jest prosty, ale kod jest rozdmuchany; język Scala jest trudny (w nauczeniu się), ale za to kod jest zwięzły i czytelny oraz sporo rzeczy jest walidowane na etapie kompilacji (statyczne typowanie). Nie widać jakoś znacznej poprawy poziomu programistów. To że programistów przybywa w sporym tempie z roku na rok niczego nie poprawia, bo i tak większość to lamusy. Z drugiej strony rośnie złożoność tworzonych sytemów, przez co opłaca się zatrudniać tych lepszych.

Im trudniejsza rzecz jest do zaimplementowania, tym bardziej jest opłacalne wybieranie trudniejszych w nauce, acz bardziej produktywnych języków. Dopisanie kilku klas do projektu składającego się ze 100 klas jest dużo prostsze (generalnie) niż dodanie kilku klas do wielkiej krowy - dla nowicjusza w projekcie. Czytałem, że produktywność, mierzona w liniach kodu na jednostkę czasu, jest mniej więcej podobna dla każdego języka. Z tego prosty wniosek: im bardziej zwięzły język, tym większa realna efektywność, mierzona w funkcjonalnościach na jednostkę czasu. Wydawać by się więc mogło, że wobec tego mniej zwięzłe języki będą wypierane przez te bardziej zwięzłe. I tak chyba jest. Gdyby popatrzeć na TOP 10 (czy TOP 5) najpopularniejszych języków w danym roku, to generalnie co rok średnia zwięzłość tych języków się zwiększa (a przynajmniej tak mi intuicja podpowiada). Ze Scalą jest trochę inaczej niż z większością innych języków, gdyż Scala jest z założenia skalowalnym językiem (SCAlable LAnguage), a więc być może tutaj relatywna zwięzłość nie jest stała.

Reasumując: wg mnie opłaca się iść w stronę trudniejszych, acz bardziej zwięzłych języków w przypadku większych czy też bardziej skomplikowanych projektów. Oczywiście aktualnie Scala jest moim faworytem, bo:

  • opiera się na JVM i dobrze współpracuje z Javowym kodem, a to jest nie do przecenienia ze względu na wszędobylskość Javy,
  • jest bardzo zwięzła, czytelna i elastyczna oraz w dużej mierze funkcjonalna - to mówi samo za siebie,
  • mimo powyższego jest w pełni obiektowa, a prawie wszyscy myślą obiektowo, w tym ja,
  • jest statycznie typowana, co jest sporą zaletą w przypadku skomplikowanych projektów, zwłaszcza jeśli wymaga się wysokiej stabilności - statyczne typowanie pozwala na przeprowadzenie mnóstwa rodzaju testów na etapie kompilacji (oczywiście kontrola typów jest automatyczna), a wiadomo przecież, że testowanie jest lepsze niż szukanie błędów na ślepo,
  • ma dobrą wydajność, średnio co najmniej kilka razy wyższą niż Python, Ruby, PHP czy podobne, oczywiście po zJITowaniu,

Tadam! Ale się rozpisałem, to by się nadawało na jakiegoś bloga :)

0
Wibowit napisał(a)
  1. Piszecie, żeby dodać do Javy kope pomocniczych funkcji, wymieniacie google-guava, JodaTime, etc Same te dwie biblioteki zajmują w sumie ponad 6 MiB, podczas gdy instalka JRE offline zajmuje 16 MiB. Ilu programistów ma chęć i potrzebę używania tych bibliotek? Ja np nigdy JodaTime nie używałem, więc zwiększanie JRE o 20 % z tego powodu to byłaby wg mnie tragedia. Każdy programista ma pewnie z megabajt swoich często używanych funkcji, gdyby tak każdy chciał je dorzucić do JRE to chyba wiadomo co by się stało.

Widac ze nigdy nie musiales sie uzerac z datami. Gdybys musial, to bys wiedzial co to JodaTime. JDK 7 / 8 bedzie miec nowe API wzorowane wlasnie na tej bibliotece. Nie mowie zeby dorzucic tego liba. Mowie zeby tego starego wyjebac. Ja pracowalem jakis czas w telekomunikacji, pisalem miedzy innymi system billingowy (nie w Polsce), gdzie obsluga dat to podstawa. Np. ktos dzwoni o 2.59 w nocy i gada przez 2 minuty, i nagle jest 4.01, poniewaz tego dnia akurat nastapila zmiana czasu. Musisz wycenic 2 minuty, nie 1h2m. To tylko poczatek. Z czym innym niz JodaTime lepiej nie podchodzic.
Co do google-collections / guava to jak chcesz. Ale w standardzie nie masz np. mozliwosc wykonac czegos co w scali robisz kolekcja.map(jakasFunkcja), z guava masz.

Wibowit napisał(a)
  1. Pokazujecie jakieś cukry z Pythona co do iteracji po pliku, a potem narzekacie, że w innych językach tego nie ma. No cóż, korzystanie z plików w ten sposób to i tak przeżytek, jak słusznie zauważyliście (sami napisaliście, że używa się managerów). Ale i tak można to opakować w jakąś klasę przecież.

Nie wiem czego nie zrozumiales, ale ten przyklad w pythonie to wlasnie korzysta z resource managerow. Klasa implementuje protokol (2 metody), Twoje klasy moga rowniez, nic prostszego.
Co do opakowania w klase juz powiedzialem - musisz ta klase najpierw napisac, ale pewnie w kazdej firmie na nowa. A co z testowaniem? Utrzymaniem? I przyklad z plikami jest tylko tym, przykladem, ktorych jest pelno. W obecnych czasach 16 czy 160 na serwer to zadna roznica prawde mowiac (sdk i tak ma 70), a dla klientow RIA Java praktycznie nie istnieje.

Wibowit napisał(a)
  1. JVM działa na jakichś tam OSach, a więc jest przez te OSy ograniczany. Dlatego trzeba explicite zarządzać zasobami, czy to bezpośrednio czy też we wrapperze/ managerze. Obojętnie czy używamy Pythona, Javy, Scali, C#, Haskella, Clojure, itp i tak musimy użerać się z tymi samymi podstawowymi utrudnieniami.

Nie rozumiem o czym mowisz. Sam programujesz w Scali, wiec wiesz ze pewne rzeczy da sie zrobic o wiele prosciej niz w Javie (ok, praktycznie wszystko da sie zrobic latwiej i wiele szybciej). Nie czaje tego motywu ;d Przyklad z plikami podalem, aktory w Erlangu zamist deadlockow i dzielonej pamieci itp itd pokazuje, ze mozna miec latwiej.

Python nie Python, to byl tylko przyklad z mojej strony, ma swoje problemy, ale znacznie mniej niz niektore inne platformy. Jak zreszta wszystko. Ale mozna cierpiec mniej lub wiecej.

Reszte musze jeszcze przeczytac ;d Co do wydajnosci, bo widze ze dotknales tematu, to nie o to chodzi, mam to w zasadzie w nosie. Czesto pisze sie aplikacje gdzie to nie ma praktycznie znaczenia, bo Pani Zdzisia nie zauwazy roznicy czy to 5 czy 100 ms, a i tak baza danych jest waskim gardlem. Pisze sie i tak czasem inne aplikacje gdzie szybkosc jest wazna, i wtedy bierze sie cos innego.

Dla zainteresowanych Scala polecam na poczatek ta serie: http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-1.

1 użytkowników online, w tym zalogowanych: 0, gości: 1