Java 8: novinky jazyka

Programovací jazyk Java přináší ve své 8 verzi řadu zajímavých novinek a také rozšíření možností jazyka směrem k funkcionálnímu programování. Zejména lambda výrazům a funkčním rozhraní se věnuje autor úvodního článku Java 8: novinky jazyka na blogu Frantovo.cz.

9.8.2014 22:47 | xkucf03 | Zajímavý článek

Komentáře

[SGOrava]

tak by mali vyzerať všetky články a nie len 3 možná 4 riadky :D

[Seraph]

Hezké, akorát zbytečně moc syntaktickych keců. Java konečně dohnala ostatní imperativní jazyky co se týče funkcionality funkcí. Čím dál, tím líp.Teď již jen začít využívat výhody OOP (RAII), a je konečně vše v pořádku.

[xkucf03]

RAII v Javě je od verze 7

[kralyk z abclinuxu]

U těch lambda funkcí mi trochu chybí nějaká zmínka o tom, jestli jsou lambdas zároveň i closures, příp. za jakých podmínek. To je u lambda funkcí imho většinou docela důležité...

V Javě 8 můžou rozhraní obsahovat i neabstraktní metody, tedy metody, obsahující implementaci, ne jen hlavičku.

To bylo nějakejch keců o tom, jak dědičnost implementace a multiple inheritance jsou největší zlo atd. atd. ... A po letech v tom Java jede taky. Mimochodem, tohle znamená, že už i Java teď umožňuje dreaded diamond, ne?

[xkucf03]

O tom se chci rozepsat v dalších dílech. Funkce může pracovat s proměnnými, které jsou final nebo alespoň efektivně final.

int x = 123;
final int y = 456;
int z = 789;

Function<Integer, Integer> fx = (i) -> i + x; // tohle nejde přeložit
Function<Integer, Integer> fy = (i) -> i + y; // y je (explicitně) final
Function<Integer, Integer> fz = (i) -> i + z; // z je efektivně final

x = 666; // důvod, proč x není efektivně final

To bylo nějakejch keců o tom, jak dědičnost implementace a multiple inheritance jsou největší zlo atd. atd.

Proti dědičnosti implementace jsem nikdy nic neměl – nepatřím zrovna k fanatikům, kteří dědičnost zavrhují a všechno by řešili kompozicí.

A po letech v tom Java jede taky. Mimochodem, tohle znamená, že už i Java teď umožňuje dreaded diamond, ne?

Umožňuje, ale kompilátor ti nedovolí přeložit nejednoznačný kód. V té třídě, kde se to spojuje, si musíš vybrat jednoho z předků, jehož metoda se použije, nebo si napsat její vlastní implementaci nezávislou na předcích.

public class Třída implements Aa, Ab {

	@Override
	public String metoda1() {
		return Aa.super.metoda1();
	}	
}

(metoda1() je implementována v obou rozhraních Aa i Ab)

[kralyk z abclinuxu]

Ok, dík za vysvětlení.

Proti dědičnosti implementace jsem nikdy nic neměl – nepatřím zrovna k fanatikům, kteří dědičnost zavrhují a všechno by řešili kompozicí.

Jj, já vím, to nemělo být na tebe (možná to tak vyznělo - pardon ).

Umožňuje, ale kompilátor ti nedovolí přeložit nejednoznačný kód. V té třídě, kde se to spojuje, si musíš vybrat jednoho z předků, jehož metoda se použije, nebo si napsat její vlastní implementaci nezávislou na předcích.

Jasný, čili je to v podstatě stejné jako v ostatních jazycích. Ono to nejspíš bude v Javě fungovat stejně/velmi podobně jako virtual inheritance v C++...

[Josef Kufner]

Proč fx() nejde? Vždyť tam není nic neobvyklého, co by jiné jazyky nezvládly.

Chápu správně, že když v PHP napíšu toto:

$x = 1;
$f = function($i) use (& $x) { return $i + $x; };
$x = 2;
echo "f(3) = ", $f(3), "\n";

Tak nedostanu "f(3) = 5", ale mám smůlu?

[Josef Kufner]

... při 1:1 přepisu do Javy.

[xkucf03]

Nejde o to zvládnout/nezvládnout. Samozřejmě, že by to šlo. Ale jde o to, jaký by to mělo vliv na čitelnost kódu, předvídatelnost výsledku.

Na tohle jsem narážel už v úvodu toho článku: jazyk, kde jde všechno možné != nejvhodnější jazyk.

[xkucf03]

Je to vlastně trochu jako používat globální proměnné – řídit se jimi uvnitř funkcí a měnit podle nich jejich chování – a pak si před voláním funkce nastavovat globální proměnné tak, aby ta funkce udělala, co chceš… jenže s tím vedlejším efektem, že v tu chvíli ovlivníš všechna použití té funkce (třeba v jiných vláknech) nebo jiné na první pohled nesouvisející věci. Což může vést k chybám, které se hodně těžko hledají a opravují.

Když už chceš takhle měnit chování funkce, tak vhodnější přístupy IMHO jsou:

• předat to jako parametr funkce (funkce o více parametrech)
• na objektu funkce¹ zavolat nějakou metodu a říct, jí, jak se teď má chovat:

f.setParametr(2); // změníme chování funkce
f.apply(3); // zavoláme funkci a vrátí nám 5

_{[1] ne na nějaké proměnné kdesi kolem, která s tou funkcí na první pohled nesouvisí – kdo to má vědět, že ovlivňuje chování té funkce?}

[Josef Kufner]

Jen tak přidávat parametry nejde, neboť volání té funkce je předepisuje. Navíc tahle část v Javě funguje (tedy alespoň podle článku).

Jde o zápis do vnějších proměnných. Například mám algoritmus na procházení grafem a předám mu funkci, kterou chci na každém vrcholu spustit. Jak mám dostat z této funkce výsledky výpočtu?

V PHP bych mohl napsat například toto:

$sum = 0;
$graph->walk(function ($node) use (& $sum) { $sum += $node->value; });
echo "Total: ", $sum, "\n";

[xkucf03]

Místo int proměnné můžeš mít objekt, který bude mít metody pro zvýšení a přečtení hodnoty, a proměnná, která na tento objekt ukazuje bude final.

[kralyk z abclinuxu]

Počkat, v Javě můžeš měnit objekt pomocí final ukazatele?

[xkucf03]

Objekt právě neměníš – jen ho používáš, voláš jeho rozhraní, metody.

[kralyk z abclinuxu]

Jo, ale ta funkce přistupuje k non-final this?

Když např. v C++ mám const pointer/referenci na objekt, můžu volat jen jeho const funkce, které mají const přístup k this.

[xkucf03]

final je právě ta proměnná, což znamená že odkazuje pořád na stejný objekt – vnitřní stav toho objektu se ale měnit může.

[kralyk z abclinuxu]

Aha. Takže ty ten objekt změnit nemůžeš, ale vlastně můžeš Javovská logika mně nepřestane fascinovat...

[xkucf03]

• Objekt se (uvnitř) mění sám, protože se měnit chce – ty pouze pracuješ s jeho rozhraním a děláš to, co ti dovolí (např. může mít jen metodu pro zvýšení hodnoty, ale ne pro snížení).
• Objekt/proměnná se nemění v tom smyslu, že je to pořád ta samá instance. Nemůžeš ji např. nastavit na null nebo místo ní podstrčit instanci jinou.

[kralyk z abclinuxu]

Chápu to, ale z toho final to dělá velmi slabé omezení. const/immutable v jiných jazycích typicky zaručují*, že stav objektu zůstane nezměněný. Což může být dost užitečné. V některých jazycích dokonce je immutable výchozí a deklaruje se naopak mutable.

_{*) s nějakou rozumnou spolehlivostí - ne, že by se to taky nedalo tak nebo onak obejít}

[mich]

V Javě je final prostě const pointer, žádná magie ani nelogičnost.

[kralyk z abclinuxu]

Právě že není. V C++ a dalších jazycích nedovolí const pointer měnit stav objektu. Zatímco final zabrání jen přepsání hodnoty pomocí = (afaik...?), ale to je celý.

Příklad i s lambdou:

#include <iostream>
using namespace std;

class Foo
{
private:
	int v;
public:	
	int value() const
	{
		return v;
	}
	
	int setValue(int value)
	{
		v = value;
	}
};

int main()
{
	Foo foo;
	foo.setValue(3);              // ok
	const Foo *constfoo = &foo;   // const pointer
	
	auto lambda = [constfoo](int x)      // capture constfoo
	{
		cout << x * constfoo->value() << endl;   // ok
		constfoo->setValue(15);                  // error - non-const member function
	};
	
	lambda(2);
}

[xkucf03]

A k čemu je mi odkaz na objekt, když nemůžu volat metody toho objektu? Mě nezajímá, co si ten objekt dělá uvnitř, jestli si nějak mění stav, to je jeho věc – od toho máme zapouzdření.

[kralyk z abclinuxu]

Ty ale můžeš volat metody toho objektu - ty které jsou const. IMHO se stává poměrně často, že člověk někam předává referenci na objekt s tím, že ví, že objekt nebude (neměl by být) nijak měněn. V takovém případě je dobrý použít const, protože to nedovolí nechtěnou změnu stavu objektu (a afaik to umožňuje i nějaké optimalizace).

[xkucf03]

Takže gettery udělám const a celý objekt pak taky předám jako const? To zní rozumně. Ono na tom C++ něco je (jen je jako celek strašně složité a rozsáhlé¹).

Akorát budu mít smůlu, když bych v tom getteru chtěl mít třeba počítadlo. A z těch const metod můžu volat zase jen const metody?

_{[1] což má za důsledek obrovskou variabilitu kódu v něm napsaného a obecně horší čitelnost}

[kralyk z abclinuxu]

jen je jako celek strašně složité a rozsáhlé

To naprosto souhlasim, učící křivka tohohle jazyka je příšerná a možností, jak si pod sebou podřezat větev, je bohužel hodně... Navíc existuje X různých stylů jak psát a každý ti řekne, že ten jeho je ten správný

Akorát budu mít smůlu, když bych v tom getteru chtěl mít třeba počítadlo.

Ano, to je určitý omezení.

A z těch const metod můžu volat zase jen const metody?

Přesně tak, to const u té member funkce v podstatě nastavuje konstantnost parametru this, takže volání non-const memberu s konstaním this je stejná situace jako v tom příkladu výše - v obojím nesouhlasí typ parametru. Je to podobný jako předat funkci místo integeru string.

[xkucf03]

Tak to se mi líbí

Otázka je, jak dostat do jazyka (třeba Javy) všechny tyhle hezké vlastnosti a přitom z toho neudělat takové monstrum, jako je C++. Kéž by se to někomu povedlo

[kralyk z abclinuxu]

Tak občas pokusy jsou... V Javě by asi šlo u třídy její "const" funkce vyčlenit do nějakého interfacu (tj. třeba třída Foo + rozhraní ConstFoo nebo tak něco) a předávat objekt přes tohle rozhraní. Ale je to trochu práce navíc...

[Ivan]

Uz od prvni verze Javy je "const" vyhrazene slovo jazyka. "Zatim" ale nema zadny vyznam. Z pohledu Javy by mi prisla zajimavejsi anotace @Immutable. (JSR 305).

[Filip Jirsák]

Myslím, že jedním z původních účelů anotací v Javě bylo umožnit rozšiřovat jazyk tímhle způsobem. Třeba anotace @Deprecated nebo @Override jazyk takhle rozšiřují – kompilátor díky nim hlídá další vazby v kódu. Různé knihovny přidávají další, třeba @NotNull/@Nullable – zrovna u tohohle mi není jasné, proč se taková anotace nestala součástí runtime knihovny, když už tam je java.util.Optional.

[mirec]

Alebo definovať počítadlo ako mutable.

[Ivan]

V celem C++ je dulezita zasada "vlastnictvi" objektu. Kdyz metode predam const referenci na string tak mam zajisteno, ze mi nikdo obsah toho stringu nezmeni. V Jave je to zajisteno tim, ze trida String je imutable. To "vlastnictvi" je dulezite nejen pro memory management, ale obecne pro navrh aplikaci.

Krome const jeste existuje "mutable", takhle oznacene prvky je mozne modifikovat i z const metod. Pouziva se to prave pro pocitadla, zamky, a caching hodnot z getteru.

[Šangala]

Akorát budu mít smůlu, když bych v tom getteru chtěl mít třeba počítadlo.

Ne tak docela, mutable to řízeně dovolí:

/*
 * use: g++ -pedantic -W const.cpp -o const.bin && ./const.bin
 */
#include <iostream>

class MyClass{
  private:
    mutable int counterGet;
    mutable int counterSet;
    int var;
  public:
    MyClass() : counterGet(0),counterSet(0),var(42){
    } 
    virtual ~MyClass(){
      /* nothing to do */
    }
    int getVar()        const {counterGet++; return var;};
    void setVar(int new_var)  {counterSet++; var=new_var;};
    
    int getCounterGet() const {return counterGet;};
    int getCounterSet() const {return counterSet;};
};

int main( int argc, const char* argv[] ){
  const MyClass constMyClass;
  MyClass myClass;
  
  std::cout << std::endl;
  std::cout << "const:" << std::endl;
  std::cout << "  constMyClass.getVar(): " << constMyClass.getVar()   << std::endl;
  /* not possible */
  /* constMyClass.setVar(10); std::cout << "  constMyClass.setVar(10)" << std::endl; */
  std::cout << "  constMyClass.setVar(10) - compilation not possible" << std::endl; 
  std::cout << "  constMyClass.getVar(): " << constMyClass.getVar()   << std::endl;
  std::cout << "  constMyClass.getCounterGet(): " << constMyClass.getCounterGet() << std::endl;
  std::cout << "  constMyClass.getCounterSet(): " << constMyClass.getCounterSet() << std::endl;
  
  std::cout << std::endl;
  std::cout << "no-const:" << std::endl;  
  std::cout << "  myClass.getVar(): " << myClass.getVar()   << std::endl;
  /* possible*/
  myClass.setVar(10); std::cout << "  myClass.setVar(10)" << std::endl; 
  std::cout << "  myClass.getVar(): " << myClass.getVar()   << std::endl;
  std::cout << "  myClass.getCounterGet(): " << myClass.getCounterGet() << std::endl;
  std::cout << "  myClass.getCounterSet(): " << myClass.getCounterSet() << std::endl;
  
  return 0;	
}

[xkucf03]

Pěkné

[Šangala]

Nejtypičtějším příkladem je asi, zamykání při multithreading, daný např. mutex je mutable aby (nejenom) všechny gettery mohli být thread-safe, ale stále const.

mutable je vhodné/určené na věci co nedefinují stav objektu, ale je třeba s tím šetřit.

[kralyk z abclinuxu]

ale je třeba s tím šetřit

+1

[mich]

To znamená, že autor třídy ji musí připravit k tomu, aby mohla být používána s const pointerem. Kdybys v tom příkladě výše neoznačil metodu value() jako const tak by ta třída byla s const nepoužitelná. Alespoň tak mi to příjde, znám jen čisté C, v C++ jsem dělal jen drobnosti.

[kralyk z abclinuxu]

Jj, je to tak.

[Filip Jirsák]

Podle mne je rozdíl v tom, že Javovské final je věc, kterou může kompilátor kontrolovat. const chápu tak, že je to nějaký příznak, který nastaví programátor - ale nijak není zaručeno, že ta metoda stav objektu skutečně nemění. Pokud chci v Javě něco takového, jako const, vytvořím pro to buď zvláštní interface, který bude mít jen to metody, které nemění stav, nebo potomka, který metody měnící stav bude mít přetížené a budou vyhazovat výjimku. Úplně stejně pak budu postupovat, pokud potřebuju nějak označit metody jiným příznakem - třeba ty, které je bezpečné volat vícevláknově.

[kralyk z abclinuxu]

V C++ const také kontroluje kompilátor, je to součást typu - non-cost typ je implicitne konvertibilní na const typ, ale zpět už pochopitelně ne. Že const proměnná/objekt nebude změněn je zaručeno, dá se to obejít pouze hacky jako const_cast, mutable nebo manipulací s pamětí na místě, kde je proměnná/objekt uložen.

[Filip Jirsák]

Takže z const metody není možné volat žádnou non-const metodu ani na jiném objektu? To asi musí být dost omezující, ne? Každopádně final field v Javě zaručuje jenom to, že se hodnota proměnné nastaví právě jednou – tj. v případě objektu ukazuje reference stále na tentýž objekt, ale nedává to žádné omezení na objekt samotný.

[kralyk z abclinuxu]

Takže z const metody není možné volat žádnou non-const metodu ani na jiném objektu?

Ne, s jinými objekty to nemá nic společnýho. Viz vysvětlení výše, specifikuje se tím, jestli je parametr this v předpisu member funkce const, nebo ne.

[xkucf03]

Takže když použiji kompozici a jeden objekt by měl zastřešovat více dalších objektů, tak změnu stavu těch vnitřních objektů mi to neohlídá?

[:::]

Pokud ten hlavni objekt obsahuje jen ukazatele na vnitrni objekty, tak ne. V tom pripade ti to ohlida jen ze nezmenis ten ukazatel.

Pokud obsahuje hodnotu tech vnitrnich objektu, tak jo.

[Filip Jirsák]

S jinými objekty to společné má. Když mám v aktuální instanci referenci na jiný objekt, tak const metoda na tom vloženém objektu buď může zavolat cokoli, a pak ta aktuální instance není zas tak moc immutable. A nebo const metoda nemůže volat nic jiného než zase const metody.

[kralyk z abclinuxu]

Aha, pochopil jsem to předtím jinak, ano, v const funkci jsou const všechny member proměnné (ať už vnořené objekty, reference, pointery, ...).

Jinak jak už poznamenal kolega mich, ekvivalent javovského final v C++ by byl Foo &const foo, tj. const se nedá k typu, ale až k té referenci, takže vznikne immutable reference na mutable typ. Nicméně afaik se to moc nepoužívá. Jde taky obohe skombinovat (tj. const reference na const typ), ale ani to se afaik moc nepoužívá...

[Filip Jirsák]

Takhle mi to dává smysl. Osobně se mi akorát nelíbí, že je to zadrátované v jazyce a nemůžu si vytvořit vlastní anotaci s jinou sémantikou. Ale chápu, že v osmdesátých letech měl Stroustrup jiné starosti...

[kralyk z abclinuxu]

Omlouvám se, member pointery/reference jsou const v tom smyslu final v Javě, to jsem si blbě pamatoval. Nicméně pokud člověk používá smart pointery (osobně raw pointery prakticky nepoužívám), tak ty const correctness zachovávají správným způsobem.

Jinak komu nestačí const, tak možnost vytvářet interfacy je samozřejmě taky. Nevim přesně, co jsou ty anotace v Javě, ale jestli to chápu správně, tak to bude podobné jako atributy v C++11...

[xkucf03]

vytvořím pro to buď zvláštní interface, který bude mít jen to metody, které nemění stav, nebo potomka, který metody měnící stav bude mít přetížené a budou vyhazovat výjimku

Potomek má nevýhodu, že na něj nemůžu konvertovat existující objekt. A rozhraní si zase může někdo přetypovat zpátky a používat všechny metody – je otázka, jestli být takhle paranoidní – třeba před reflexí se bránit moc nedá, to už je extrém, hack, ale přetypování je relativně standardní činnost, se kterou by se asi mělo počítat. Bezpečnější než rozhraní bude adaptér, který původní objekt obalí a zpřístupní jen vybrané metody.

[mich]

Promiň, možná jsem použil špatný název. Chtěl jsem říct, že toto v C++:

Foo * const constfoo = &foo;

Je ekvivalent tohoto v Javě:

final Foo constfoo = ...

[kralyk z abclinuxu]

Aha, jasný, tak to jo

[xkucf03]

final AtomicReference<Integer> počet = new AtomicReference<>(0);
počet.set(1);
int x = počet.updateAndGet(i -> i + 1);
int y = počet.getAndUpdate(i -> i + 1);
System.out.println(počet.get());

[Josef Kufner]

Co je toto za hnůj?

[xkucf03]

I proměnná může být objekt

final AtomicReference<Integer> počet = new AtomicReference<>(0); // int počet = 0;
počet.set(1); // počet = 1;
int x = počet.updateAndGet(i -> i + 1); // int x = ++počet;
int y = počet.getAndUpdate(i -> i + 1); // int y = počet++;
System.out.println(počet.get()); // System.out.println(počet);

[Josef Kufner]

No to jo, ale proč by někdo něco takového dobrovolně psal?

[Filip Jirsák]

Třeba kvůli bezpečnému přístupu z více vláken. Což je zrovna případ AtomicInteger v Javě.

[pavlix]

Proměnná snad bývá v programovacích jazycích běžně reprezentovaná objektem, ne?

[mankind_boost]

ano, nejčastěji v neobjektových jazycích

[pavlix]

Ano, jen bych spíše použil objektově neorientovaných jazycích nebo jazycích bez podpory OOP, ale osobně mám pocit, že lidé často používají OOP jako obecné označení pro to, jak funguje jejich oblíbený jazyk. Proto může mít javista pocit, že python není dostatečně objektově orientovaný, zatímco pythonista může mít pocit, že je víc objektově orientovaný než java.

[kralyk z abclinuxu]

To není moc dobré přirovnání... Closures většinou nejsou ani tak od toho, aby se jimi ovlivňovalo chování funkce (ačkoli to taky), ale aby funkce mohla ovlivňovat vnější prostředí. Většinou mají přístup pouze k omezenému prostředí, případně se v některých jazycích (např. C++) dá specifikovat, které přesně proměnné patří do closures a s jakým přístupem.

Jinak prasit se s tím smozřejm dá, je to jako s mnoha dalšími věcmi: Všeho s mírou.

[Saljack]

Jak se to ovlivňuje v C++?

[kralyk z abclinuxu]

#include <iostream>
using namespace std;

int main() 
{
	int foobar = 0;

	auto lambda = [&foobar]()
	{
		foobar = 3;   // <- Takhle
	};
	
	lambda();
	
	cout << foobar << endl;
	
	return 0;
}

[:::]

Drobna oprava

int main() 
{
	int foobar = 0;

	auto lambda = [&foobar]()
	               ^^^^^^^- Takhle
	{
		foobar = 3;
	};
	
	lambda();
	
	cout << foobar << endl;
	
	return 0;
}

[Saljack]

Jo no jo nějak mě to nedošlo díky za připomenutí.

[Ondrej Santiago Zajicek]

Většinou mají přístup pouze k omezenému prostředí, případně se v některých jazycích (např. C++) dá specifikovat, které přesně proměnné patří do closures a s jakým přístupem.

To je ale spis znouzectnost. Plne, neomezene closures jsou totiz nekompatibilni s tim, jak bezne jazyky implementuji lexikalni promenne a zasobnik volani. Prirozena implementace zasobniku volani pro jazyk s plnymi closures je takova, ze vnorene environements tvori spojovy seznam podrizeny GC. Takove closures maji 'tu spravnou' semantiku, ktera se od nich ocekava, ale vetsinou vyhody takoveho pristupu neprevazi nevyhody s tim spojene (napr. nizsi efektivita a daleko problematictejsi foreign function interface pri kombinaci s 'beznymi' jazyky), takze se to casto nejak osidi, aby se vlk nazral a koza zustala cela.

[x]

Vícenásobné dědičnosti je spousta druhů. V pořadí od menší po větší problematičnost: bezestavové traity, stavové traity, mixiny a C++.

[Grunt]

Už jedou?

[jirka]

java je zlo a děravé svinstvo, jenom blázen si to pustí do počítače.

[Rovano]

+1

Od *censored*, kteří ani neumějí udělat instalátor a updater pro jejich produkt, ani pořádné webové stránky, si jen pár *censored* píše něco v tom jejich produktu.

[xkucf03]

Nevím, jak ty, ale já si Javu instaluji přes standardní balíčkovací systém své distribuce. Ani s aktualizacemi nemám problém.

[Rovano]

Java je ale multiplatformní.

[Šangala]

A trpaslíci malí.

[kolcon]

Taky uprimne doufam, ze se z Perlu nestane Java...

[pavel]

Uvital bych, aby u takove zpravicky byl odkaz na oficialni stranky, ne na nejaky soukromy blog kdo mezi vyvojare ani nepatri.

Btw. Java to uz ma asi za sebou a zatim tezi jen ze setrvacnosti v relativne konzervativni korporatni sfere. U novych projektu jsem posledni dobou daleko vic videl C#, F#, Erlang nebo Scalu a u mobilnich Objective-C.

[mich]

1. Java 8 vyšla v Březnu. Tohle není zprávička o vydání Javy 8, ale o tom, že někdo napsal shrnutí novinek v češtině.
2. Je skvělé, že máš tak dobrý přehled o tom, co je teď in a cool. Proč nenapíšeš častěji svůj pohled na to co se bude příští měsíc používat? Můj kamarád včera napsal Hello World v F#, tak předpokládám, že do roka a do dne masově rozšíří a všechny ostatní jazyky světa vyhynou. Aneb už se těším až budou Java programy přepsány do jazyka, který se používá hlavně na Win platformě (C#, F#), případně až Java zemře kvůli Scale, která sama o sobě jede na JVM a její velkou výhodou je právě dostupnost Java knihoven z ní samotné.

[pavel]

1. Pak byl text zpravicky zavadejici a melo byt explicitne uvedeno, ze jde o neoficialni popis v cestine na soukr. blogu (kterym si zvysuje statistiku navstevnosti).
2. Nepisu o tom co je ted in a cool nebo co vyhyne, ale s cim jsem se posledni dobou setkaval u novych podnikovych aplikaci a startupu, zadny mini aplikace typu hello world. A rec byla o jazyku, nikoli platforme a poznamka o VM je tim taky postrada smysl. Me je to sumak, ale i indexy jako TIOBE neprimu ukazuji, ze Java ma na trhu trvale sestupny trend.

[Václav "Darm" Novák]

Vzhledem k tomu jak často se v korporátní sféře ještě používá Delphi bych se rychlé smrti Javy nebál. To dojíždění ze setrvačnosti bude trvat ještě pěkných pár let.

[pavel]

To ano, obzvlast ve stredni vychodni Evrope bylo oblibene.

[Semo]

Delphi je rozumne pouzitelny jazyk. Ale keby bolo vacsie povedomie kolko aplikacii bezi v CZ bankovnictve a CZ poistovnictve v Cobole, tak by sa u nehadali ludia o to ci Java alebo C++. Proti Cobolu je skoro vsetko slusnym jazykom, ale z Cobolu by sa pozvracal aj odolny jedinec.

[kralyk z abclinuxu]

Hmmm... Tak jsem kouknul na pár příkladu kódu v cobolu... No radši si jdu rovnou pro kinedryl...

[JS1]

No, myslim, ze pokud se podivas jen na par prikladu, tak je to celkem logicke. Ale nektere veci se v tom daji udelat pomerne elegantne, lepe nez v soucasnych jazycich.

[tve_stare_irc]

MY TE VIDIME!
rac se zas opet ukazat v herde.

[xaver]

Btw. Java to uz ma asi za sebou a zatim tezi jen ze setrvacnosti v relativne konzervativni korporatni sfere....

Heh tak dobre som sa uz davno nezasmial. Ani nemate potuchy kde vsade je java pouzivana a v akom rozsahu. Korporatna sfera je prave iba mala cast oblasti kde je java pouzivana. Ono totiz netreba brat javu iba ako jazyk ale ako celu platformu. Co sa tyka scaly tak to je iba modny trend a nastastie sa uz zacinaju objavovat ludia, ktory nahlas hovoria aku ma scala sprasenu syntax. Java tu s nami bude este pekny par desatroci takze sa nemusite bat.

[xkucf03]

Java to uz ma asi za sebou a zatim tezi jen ze setrvacnosti v relativne konzervativni korporatni sfere.

Po skoro deseti letech bych rád doplnil, že Java se používá stále :-)

[JS1]

Ne že by na nich bylo něco špatného, ale na Javě si nejvíc cením jednoduchosti jazyka.

Tohle mi uz rikalo vic lidi. Ale je to trochu omyl - Java neni jednoducha ani nahodou.

Kdyby nekdo opravdu touzil po jednoduchosti, musel by se totiz vzdat OOP.

[xkucf03]

A místo něj používat co?

[Josef Kufner]

OOP, které umí rozesílat zprávy všem a ne jen jednomu objektu. Pak také nějaký dobrý kompoziční framework, neboť dnešní OOP je dobré na vyrábění komponent, ale neskutečně blbé při jejich spojování dohromady.

[:::]

OOP, které umí rozesílat zprávy všem a ne jen jednomu objektu.

Nejaky priklad?

[Josef Kufner]

Jisté náznaky jsou například signály a sloty v Qt/C++ nebo delegáty v C#. Ale je to jen takový malý krůček správným směrem.

Když se někde vysvětluje OOP a používá se zasílání zpráv namísto volání metod, celkem často tam je k vidění, že nějaký objekt odeslal zprávu o své změně, ale už není popsané, komu byla zpráva určena, jen že na ní něco zareaguje. Tento vágní popis však nemá svůj protějšek ve skutečné implementaci a to je okamžik, kdy OOP ztratí svou eleganci vychválenou v tom vágním popisu.

[xkucf03]

A co ti brání mít objekt, u kterého se zájemci zaregistrují a on jim ty události bude přeposílat? Na to nepotřebuješ žádnou podporu v jazyce.

Bez přihlášení se k odběru událostí/zpráv, tak aby všechno chodilo všem, by to stejně nedávalo smysl.

[Josef Kufner]

Tady narážíš na tu druhou část, o kompozičním frameworku. Pokud se jeden objekt má někde zaregistrovat, musí vědět, že se má zaregistrovat, jak se má zaregistrovat, kde se má zaregistrovat a co má dělat, když ten druhý objekt zmizí, nebo když hodí nějakou chybu a jak ji vlastně hodí. A pokud chceš dostát pořádné dekompozici, tak by objekty neměly vědět o svém okolí, jen komunikovat skrze svá rozhraní. Takže se vlastně nikam zaregistrovat nemůže. Tohle musí obstarat kontejner, ve kterém objekt žije a pokud nemáš už jazykem daný interface a podporu, bude takový kontejner buď neskutečně složitý a nespolehlivý, nebo nepoužitelný.

[xkucf03]

Ten objekt se nemusí registrovat sám, prostě jen existuje a vystavuje svoje rozhraní. Pak jsou jiné objekty, které můžou emitovat události/zprávy. Tyhle objekty nemůžou posílat události jen tak do vzduchoprázdna. Takže už musí něco umět – musí mít třeba metodu pro zaregistrování posluchače. U nich se zaregistruje nějaký prostředník a bude přeposílat zprávy těm prvním objektům.

[mirec]

Perfektne vystihnutý dôvod prečo by sa java nemala používať na výuku OOP.

[xkucf03]

Jo, zatímco jinde to funguje sluníčkově samo a všechno se to propojí, jak chceš, aniž bys musel psát nějaké řádky kódu :-P

[xkucf03]

BTW: když si správně navrhneš ty třídy (dost pomůžou generika), tak pak můžeš dělat klidně něco jako:

m.connect(a.x(), b.x());

Kde m je objekt, který to řídí, zprostředkovává, a emituje události, b je přijímá a x je typ události. To všechno se silnou typovou kontrolou a bez nějakého dynamického šamanismu. A ten propojovací kód je taky hezky čitelný (i když to nemá vyloženě podporu v jazyce nebo nějaké DSL).

[kralyk z abclinuxu]

Perfektne vystihnutý dôvod prečo by sa java nemala používať na výuku OOP.

IMHO není snad ani tak problém v tom, že se začně u Javy, ale spíš v tom, že se Javou i skončí. Co se týče OOP, poprvé jsem k němu přičuchl u Object Pascalu / Delphi Co vy?

[K42]

Turbo Pascal 6

[pavlix]

Podobně, akorát myslím, že už to byla 7.0.

[kralyk z abclinuxu]

Pak jsou jiné objekty, které můžou emitovat události/zprávy. Tyhle objekty nemůžou posílat události jen tak do vzduchoprázdna.

Např. v tom Qt můžou. Příkaz emit prostě vyšle signál a jestli je k němu připojeno 100 nebo 0 jiných objektů je šumák.

Má to bezesporu svoje výhody, nicméně mně osobně tenhle koncept "zasílat zprávy kdykoli kamkoli" případně nějaké message busy zas tak extra skvělý nepřijde. Imho z toho celkem snadno může vyústit kód typu "spaghetti with meatballs". Navíc vzhledem k tomu, že signály se navazují v runtime, může být dost těžké dohledat, co kde vyvolává jakou činnost...

[xkucf03]

No právě, emitovat události někam do vzduchoprázdna s tím, že se to pak nějak magicky napojí a nasměruje, kam má, to je tak trochu prasárna. Tomu Qt se to ještě dá odpustit, svým způsobem je to výjimečný projekt, vlastní styl programování, nadstavba jazyka, ale moc si nedovedu představit, že by tohle byla běžná praxe a že by se ti v programu sešlo třeba pět knihoven, kde každá takhle nějak emituje svoje události do vzduchoprázdna a pak si je zase nějak magicky odchytává a zpracovává.

Proto mi přijde lepší ten model, kde emituješ událost směrem k nějakému prostředníkovi a ten už se postará o zbytek.

[pavlix]

Osobně nevidím na modelu událostí a registrací k událostem nic tak špatného. Fungují tak mnohá rozhraní kernelu i userspace služeb a nevidím důvod, proč by tak nemohly fungovat i komponenty v rámci jednoho procesu. Implementovat to specifickými connectory namísto obecného rozhraní mi přijde jako určitá forma masochismu, o kterém jsem si myslel, že je vlastní spíše nám céčkařům.

[xkucf03]

Osobně nevidím na modelu událostí a registrací k událostem nic tak špatného.

To já taky ne. Ale signály a sloty jsou o něco flexibilnější a líp se to řídí zvenku.

Při registraci posluchače často registruje ten objekt sám sebe (svoji vnitřní třídu), ale i když ho registruje (propojuje zdroj a cíl událostí) někdo zvenku, je potřeba uvnitř toho cílového objektu rozhodovat, co s danou událostí udělat – pokud máme od každého typu událostí jen jednu, je to jednoduché. Ale pokud máme např. typ události „tlačítko stisknuto“, musíme uvnitř toho posluchače mít větvení, které bude řešit, které tlačítko bylo stisknuto a co se tudíž má dělat.

Oproti tomu ten přístup, co jsem popisoval výše nebo:

a.x().connect(b.x());

umožňuje propojit libovolný zdroj událostí určitého typu s libovolným cílem stejného typu.

Resp. technicky to funguje podobně, jen je rozdíl v granularitě – navenek jsou vystavené jednotlivé posluchače (více pro stejný typ události) pro různé cílové akce – místo jednoho posluchače pro jeden typ události, kde by to větvení bylo až uvnitř něj.

[pavlix]

To já taky ne. Ale signály a sloty jsou o něco flexibilnější a líp se to řídí zvenku.

Měl jsem za to, že o nich se právě bavíme.

[Josef Kufner]

Ale pokud máme např. typ události „tlačítko stisknuto“, musíme uvnitř toho posluchače mít větvení, které bude řešit, které tlačítko bylo stisknuto a co se tudíž má dělat.

Ne. Žádné větvení tam právě není třeba, protože připojíš každému tlačítku na svou vlastní obsluhu.

[xkucf03]

OMFG, vždyť o tom právě píšu, že je to výhoda signálů/slotů resp, toho přístupu, co jsem psal výše:

m.connect(a.x(), b.x()); // nebo:
a.x().connect(b.x());

oproti klasickým posluchačům a případu, kdy přijímající objekt implementuje rozhraní daného posluchače (tím pádem umí přijímat daný jeden typ události) a pak si to větvení dělá uvnitř.

[Seraph]

Signály v QT nejsou vůbec magické. Když k sobě člověk nespojí slot objektu A a signál objektu B, prostě signál nedojde. A ne, není těžké dohledat jak je co spojené. Stačí se kouknout na volání funkce connect(). Naopak toto posílání signálů je geniální, je to skutečně objektově orientované programování. Zavání to ale již AO paradigmatem. Na druhou stanu AO a OO jsou dost podobná paradigmata...

[kralyk z abclinuxu]

A ne, není těžké dohledat jak je co spojené. Stačí se kouknout na volání funkce connect().

Jo, jenže connect() může být v kódu praticky kdekoli, klidně někde úplně jinde, než kde jsou definované ty zúčastněné objekty. Navíc těch connectů může bejt větší množství a dále se může situace komplikovat použitím disconnect(), QSignalMapper a dalších vymožeností.

[Ivan]

Java je jednoducha (az primitivne jednoducha) co se tyce syntaxe jazyka. Diky tomu se snadno parsuje a snadne se cte. To ze exituji veci jako frameworky JEE, dependency injection a prisery ktere vam za behu programu prepisuji bytecode v JVM je vec druha. V Jave z kontextu pochopite co je metoda, promenna anebo jmeno tridy.

V C++ nekdy nemate sanci ani zjistit co je operator (natozpak rozlisit mezi jmenem tridy a jmenem metody). Viz muj oblibeny hnus:

#if FIRST_MEANING
   template<bool >
   class foo
   { };
#else
   static const int foo = 0;
   static const int bar = 15;
#endif

static int foobar( foo < 2 ? 1 < 1 : 0 > & bar );

[Conscript89]

Nesmyslny prasarny se daji psat (temer) v kazdym jazyce. Jen v nekterych jazycich je kazdy kod vzdy prasacky (napr. brainfuck).

[Šangala]

Proto ho taky přepisujeme do Ook!.

[Radek Miček]

Java je jednoducha (az primitivne jednoducha) co se tyce syntaxe jazyka. Diky tomu se snadno parsuje a snadne se cte.

Znaková sada Unicode k jednoduchosti a snadné čitelnosti zrovna nepřispívá. Např. (specifikace, část 3.8):

Two identifiers are the same only if they are identical, that is, have the same Unicode character for each letter or digit. Identifiers that have the same external appearance may yet be different.

A pak jazyk není jen syntax.

[xkucf03]

Děláš, jako kdybys na takový kód narážel denně. Je fakt, že já někdy píšu česky a to jsem za exota navíc háčky a čárky na první pohled poznáš.

Ale tu spoustu vlastností a konstrukcí nabízených C++ lidi reálně používají a každý používá trochu jinou podmnožinu, takže abys byl obecně schopný číst C++, musíš umět úplně všechno.

[Radek Miček]

Děláš, jako kdybys na takový kód narážel denně.

Problém je, že v některých jazycích může dojít k problémům velmi snadno:

public class Boo {
    static int Сena = 1;
    public static void main(String[] args) {
        int Cena = 2;
        System.out.println(Сena);
    }
}

Program samozřejmě vypíše 1, ale proč? S ASCII je podobných problémů mnohem méně.

[xkucf03]

Ale proč by to někdo psal? Leda naschvál, ze zlomyslnosti. V tom je ten rozdíl. Ale ty věci z C++ lidi používají běžně a s dobrými úmysly – vlastně to jsou často i dobré věci – jen jich je prostě hodně.

Totéž třeba ten Perl – občas si v něm něco napíšu, docela jsem si ho i oblíbil a dobře mi slouží. Používám jen jeho malou podmnožinu. Ale číst něco po jiných? To už tak snadné není.

P.S. z té proměnné s velkým písmenem na začátku mě bolí oči. Fuj.

[Radek Miček]

Ale proč by to někdo psal?

Stačí jednou identifikátor zkopírovat z internetu a podruhé ručně napsat.

[xkucf03]

Proč by to psal někdo blbě na ten Internet? Teď pominu že jen tak kopírovat cizí kód je blbost. Spíš bys to kopíroval třeba z interní wiki, ale tam by to musel zase špatně napsat leda nějaký zlomyslný kolega, tohle fakt není normální.

Když něco zkopíruješ z webu, tak ti budou pasovat ty proměnné na ty, které už tam máš, že dojde k té záměně? Spíš by se stalo, že tam takovou proměnnou nemáš a když ji napíšeš ručně, tak to nepůjde zkompilovat, IDE ti podtrhne chybu a ty si všimneš, že jsi zkopíroval chybný text.

A nevím, proč se tu vlastně hádáme, když C++ unicode v identifikátorech umožňuje, stejně jako mnohé další jazyky.

[Radek Miček]

Problémy budou i s češtinou:

public class Boo {
    public static void main(String[] args) {
        int čau = 2;
        int čau = 1;
        System.out.println(čau);
    }
}

[xkucf03]

Jo a taky se plete 1 a l a když přeházíš písmenka uvnitř slova, tak, aby začátek a konec zůstaly stejné, tak to většina lidí přečte jako to původní slovo.

Kritika Javy je často nesmyslná, ale zatím asi vedeš

[kralyk z abclinuxu]

Imho je tahle kritika namístě, stejným problémem trpí např. i JavaScript/ECMAScript.

Na střední jsme kdysi byli nuceni pracovat s jakousi (českou) výukovou knihovnou v Javě, která diakritiku používala. Zuřil jsem.

[Radek Miček]

Jo a taky se plete 1 a l a když přeházíš písmenka uvnitř slova

Jenže 1 a l můžete rozlišit pomocí fontu, ale v příkladu s čau to udělat nemůžete, protože oba identifikátory jsou ekvivalentní - viz Unicode Standard Annex #15 - Unicode Normalization Forms (část 1.1):

The Unicode Standard defines two equivalences between characters: canonical equivalence and compatibility equivalence. Canonical equivalence is a fundamental equivalency between characters or sequences of characters that represent the same abstract character, and when correctly displayed should always have the same visual appearance and behavior.

Kritika Javy je často nesmyslná, ale zatím asi vedeš.

Dík, a to jsme teprve ve 3. kapitole standardu z 19.

[Ivan]

ok oznavam. Ale i kdyz je to pekne hnusny, tak kdyz v Eclipse kliknu na tu promennou tak se mi kurzor prenune na jeji deklaraci. V pripade C++ toho dosahnou jen tak, ze mi kompilator behem prekladu vygeneruje metadata. Syntaxe jazyka ma vliv i na to jak konfortni IDE k nemu vznikne. A v tom je Java (bohuzel) napred - prochazet cizi zdrojaky v C++ je proste mnohem narocnejsi.

[pavlix]

A v tom je Java (bohuzel) napred

Nemyslím si, že by tu šlo o nějakou časovou osu ani že by byl jasně nastavený trend, ke kterému by všichni směřovali.

[xkucf03]

Ano, vzhledem k historickému dědictví těch jazyků to často není možné a asi se toho nedočkáme nikdy.

[pavlix]

Což ostatně nás, kteří žádné IDE nepoužíváme, moc netrápí :).

[mirec]

Blbosť. Osobne používam na dopĺňanie frontend kompilátora (áno preste ten parser ktorý používa kompilátor), takže všetky vlastnosti jazyka ktoré vie kompilátor vie teraz aj môj editor bez ohľadu na komplexnosť jazyka. Doba kedy si každé IDE muselo písať vlastný parser a synchronizovať sa so štandardom jazyka je dávno preč.

[kralyk z abclinuxu]

Ale i kdyz je to pekne hnusny, tak kdyz v Eclipse kliknu na tu promennou tak se mi kurzor prenune na jeji deklaraci. V pripade C++ toho dosahnou jen tak, ze mi kompilator behem prekladu vygeneruje metadata.

C++ IDE tohle umí taky.

[Ivan]

A muzu sezeptat ktery? Zatim jsem nepotal IDE ktery by si rozumelo se sablonama.

[Šangala]

Specifikuj přesněji, bo i na proměnou deklarovanou jako ttyp<int> mi to normálně pomocí F3 skočí.

[xkucf03]

Např. v Qt Creatoru můžeš napsat tohle

list<string> l;
l.push_front("text");    
int i = l.front();

a IDE proti tomu nic nenamítá – chybu ti oznámí až kompilátor.

Zatímco třeba u Netbeans a Javy by ti IDE oznámilo chybu už během psaní a taky by ti při doplňování nabízelo jen ty metody, které dávají v daném kontextu smysl (vrací typ nebo podtyp proměnné, do které přiřazuješ, nebo parametru metody, který plníš atd.)

[Šangala]

Jo tak to nic nenamítá ani Eclipse Luna.

(Ale přece nebudu psát kraviny :))

[mirec]

Příloha:

• cpp.png (18444 bytů)

V notepade môžem napísať do úsoboru MojaSuperBlbost.java:

"wtf" = "ftw";

A notepad proti tomu nič nemá.

[mirec]

Ešte ak by to niekoho zaujímalo tu mi na pozadí beží clang, takže doplňanie aj so šablónami a auto a podobnými novými vychytávkami funguje absolútne bez problémov. Problémy v kóde tak isto rieši clang. Prechrúme to všetko čo kompilátor. Dopĺňanie mám nastavené tak trochu fuzzy (stačí napísať časť slova, nemusí byť na začiatku, prežije aj keď v nejakom slove vynechám pár znakov a napíšem povedzme len začiatočné a posledné písmeno). Fakt nie je fér porovnávať QtCreator s ich mizerným code modelom a eclipse. Mimochodom QtCreator má ako alternatívny code model clang.

[Ivan]

Tohle je pekny. Taky pouzivam neco podobnyho na psani: Emacs + gccsense. Ale na prochazeni zdrojaku jsem jeste nic efektivniho nenasel.

[Zdenek Henek]

treba tohle ? http://opengrok.github.io/OpenGrok/

[kralyk z abclinuxu]

a IDE proti tomu nic nenamítá – chybu ti oznámí až kompilátor.

Tak C++ IDE opravdu nemají ve zvyku hledat chyby a principielně to imho ani není možný.

Osobně mi to ale naprosto vyhovuje, u Eclipse mě štvalo, že jsem psal kód a v průběhu psaní mi IDE neustále zvýrazňovalo nějaký chyby prostě proto, že kód nebyl ještě úplný.

[Šangala]

Mě tedy IDE (Eclipse) 90% chyb odhalí i bez kompilace…

Když mi něco vadí, tak to vypnu

[Ivan]

Treba tohle

// prazdna trida = nil
class Empty {};

// ze dvou trid vybere tu ktera neni prazdna
template<class A, class B>
class TraitsSelector
{
public:
	typedef A selected;
};

template<class B>
class TraitsSelector<Empty, B>
{
public:
	typedef B selected;
};

// base class pro dedeni vlastnich Traits
template<class ImplTraits>
class CustomTraitsBase
{
public:
	typedef Empty AllocPolicyType;
	typedef Empty StringType;
};

// base Traits, obsahuje implicitni prirazeni typu
template< template<class ImplTraits> class UserTraits >
class TraitsBase
{
public:	
	typedef typename TraitsSelector< typename UserTraits<TraitsType>::AllocPolicyType,
					 DefaultAllocPolicy
					>::selected  AllocPolicyType;

	typedef typename TraitsSelector< typename UserTraits<TraitsType>::StringType, 
					 std::string
					 >::selected StringType;
};

// tady podedim a definuju vlastni alokator
template<class ImplTraits>
class MyUserTraits : public CustomTraitsBase<ImplTraits>
{
public:
	typedef MyUserAllocPolicy AllocPolicyType;
};

// MyLexerTraits - kdyz se to vsechno spoji tak:
// MyLexerTraits::AllocPolicyType ::= MyUserAllocPolicy
// MyLexerTraits::StringType ::= std::string
typedef TraitsBase<MyUserTraits> MyLexerTraits;

typedef BaseLexer<MyLexerTraits> MyLexer;

MyLexer lex;

Ted mam promennou lex ktera odsahuje prvky typu StringType, coz je vlastne std::string. Nikdo o tom ale nevi. Stejne tak nikdo nevi ze MyLexer obsahuje vlastni alokator a pres IDE (CDT) se nijak nedostanu k implementaci jeho metod.

[mirec]

Mne to funguje.

[Šangala]

Buď mi něco uniklo nebo to fungovat nemůže bo nemáš deklaraci BaseLexer.

[Ivan]

Nic ti neuniklo - prave naopak umis se rychle orientovat v kodu :) BaseLexer je trida (sablona definovana jinde) cely je to vykously z vetsiho kusu kodu a hodne zjednoduseny. Editor tohodle webu je na me zlej a nechce mi povolit psat mensitka ani do tagu pre a code, takze jsem to po chvili vzdal.

 

template<class ImplTraits>
class  BaseLexer
{
public:

typedef typename ImplTraits::AllocPolicyType AllocPolicyType;

typedef typename ImplTraits::StringType StringType;

StringType const& get_filename() const;

private:

StringType m_filename;

}

BaseLexer je trida ktera opravdu neco dela(ma metody a prvky). V realu cela ta saskarna s Traits slouzi k tomu abych ji mohl vnutit typy, se kteryma pracuje, konstanty, ktery ovlivni jeji chovani a treba i predka od kteryho dedi.

[Šangala]

Příloha:

• eclipse-juno.png (93482 bytů)

Tak jsem si to schválně zkopíroval doplnil to co schází a v eclipse juno viz příloha.

PS: 

& " < >

na webu píšeme jako

& " < >

[Ivan]

Tak jsem to vyzkousel a mas pravdu Luna o zvlada o poznani lip.

PS: co je to za skin? Chvili jsem si myslel, ze je to vim.

[Šangala]

Jen jsem vyřízl část na ukázku - tedy jen editor, a barvičky editoru (stejně jako „skin“) jsou kompletně „moje“ už 300 lat přenášené s verze do verze…

[Ivan]

Jako byste to privolali. Dneska mi "psali" z Eclipse, ze jim to taky funguje. Bug 404028

[kralyk z abclinuxu]

Příloha:

• qtc.png (79095 bytů)

Qt Creator taky nemá problém Dokonce ví, že ImplTraits jsou v tomhle případě MyLexerTraits ...

[kralyk z abclinuxu]

Příloha:

• qtc.png (88587 bytů)

fix'd

[kralyk z abclinuxu]

Qt Creator má obstojný code model. S šablonama si víceméně rozumí. Většinou mi nebyl schopen napovídat funkce objektu uloženého ve smart pointeru. Ale jinak většinu bežných věcí dohledá, member funkce napoví, atd. Umí přejmenovávat lokální proměnné a pomocí hledacího panelu i member proměnné/funkce, vč. použtí v závislých souborech. Při volání funkce napoví parametry, když je více přetížených funkcí, nabídne výběr kterou doplňovat. Při definici member funkce v .h umí vytvořit stub pro implementaci v .cpp, při změně argumentů member funkce v .h nebo .cpp umí synchronizovat změnu do toho druhého souboru.

V podstatě mezi C++ v Qt Creatoru a Javou v Eclipsu/NetBeans subjektivně nevidím moc velký rozdíl v použitelnosti code modelu, vyjma těch smart poitnerů (o nich se teď diskutovalo na ML, tak se to třeba zlepší) a pár dalších specielních případů.

MSVC je na tom trochu hůř, IIRC měl např. problémy s přetíženými funkcemi a s funkcemi se stejným jménem, ale definovanými v jiných .h nebo něco takového. Ale jinak se v zásadě taky dá používat, ačkoli úplně pohodlné to není. Oproti QtC je dost pomalej.

[Filip Jirsák]

Problémy budou i s C:

#include<stdio.h>

main()
{
    int xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxoxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx = 1;
    int xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxoxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx = 2;
    printf("%d", xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxoxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx);

}

Nečitelný kód lze totiž napsat v libovolném jazyce.

[xkucf03]

Další díl: Java 8: coalesce – hledáme neNULLové hodnoty

[xkucf03]

Další díl: Java 8: Stream API

[kralyk z abclinuxu]

Most developers are religious about technology

[JS1]

Na to je jednoduchy lek: Naucit se nebo aspon trochu poznat vic jazyku, nejlepe ruznych paradigmat a syntaxi (ja doporucuji: C, Java, Javascript, Python, sh, Common Lisp, Haskell, Prolog, Forth, assembler, VHDL - lze zamenit za podobne podle vkusu).

Totez v podstate doporucuje ateista Dan Dennett u skutecneho nabozenstvi: Chtel by, aby se deti ucily vsechna hlavni nabozenstvi. K tomu se muzou ucit co chteji. Takze v tomhle jsou skutecne pobozni lide horsi, protoze ani ten Dennettuv navrh se jim moc nelibi. Na druhou stranu neznam zadneho programatora, ktery by seriozne protestoval proti "indoktrinaci" studentu vyse uvedenym seznamem.

[xkucf03]

Na to je jednoduchy lek: Naucit se nebo aspon trochu poznat vic jazyku, nejlepe ruznych paradigmat a syntaxi (ja doporucuji: C, Java, Javascript, Python, sh, Common Lisp, Haskell, Prolog, Forth, assembler, VHDL - lze zamenit za podobne podle vkusu).

Jak moc do hloubky bys doporučoval jít? Za jak dlouho se to dá stihnout?

Např. já dělám převážně v té Javě (jaké překvapení), pak SQL (včetně procedurálního), XML (a související jazyky), skriptování v Perlu a Bashi, občas nějaký JavaScript nebo Python, když musím, a pak trochu C a C++ …a to je asi tak všechno, pro co jsem našel nějaké praktické využití. Pro ty ostatní jazyky (Common Lisp, Haskell, Prolog, Forth, assembler, VHDL) jsem ho zatím nenašel – co s tím? Mám si v tom cvičně střihnout nějaký projekt? Nebo si o tom přečíst knihu, když zatím ani netuším, co bych v tom napsal? Možná by ještě tak byla nějaká motivace pro EmacsLisp kvůli psaní doplňků pro editor, ale u těch ostatních jazyků fakt nevím. To už si spíš najdu čas na C++, tam mám aspoň představu, co bych v tom chtěl napsat.

[JS1]

Podle me tezko muzet najit konkretni vyuziti pro jazyk, ktery vubec neznas. Ale hlavne, to neni o tom na ten jazyk prejit, ale spis o to nahlednout jiny zpusob uvazovani - lidi, kteri ho pouzivaji.

IMHO staci poslechnout si na to tema nejakou prednasku, precist si tutorial a zkusit si napsat par radek. Proste jde o to pochopit trochu to jine paradigma. (Ja jsem to takhle udelal.)

Konkretne, na Common Lisp doporucuji prednasku Practical Common Lisp a stejnojmennou knizku. Eventualne trochu si prolistovat On Lisp. Alternativne, zkusit Scheme a precist si SICP. Na Haskell bych doporucil Learn Yourself a Haskell a pozdeji clanky All About Monads a Typeclassopedia. Dobry je taky treba projekt Euler, zkusit si par uloh v tom jazyce. U Forthu bych doporucoval literarni Jones Forth (vyzaduje i minimalni znalost x86 assembleru), eventualne knizku Thinking in Forth. Na VHDL je nejlepsi zkusit naprogramovat nejake FPGA - ma to taky svoje kouzlo - vsechno se deje paralalne a ty to jen spojujes. To se da zkombinovat i s nejakym tim assemblerem. Prolog jsem zatim nezvladl, ale snad se k nemu doberu, takze zatim nic nemohu doporucit.

A vidis, SQL jsem zapomnel - tusil jsem, ze tam neco chybi.

[kralyk z abclinuxu]

No, s tím Prologem bych to moc nepřeháněl, imho ti to nepřinese tolik jako ty ostatní jmenované (jestli vůbec něco). Měli jsme to ve škole asi semestr, možná dva, imho je to v podstatě jen ne moc intuitivní rozhraní k prohledávání do hloubky.

[JS1]

To mas mozna pravdu, ale aspon trochu znat bych to chtel. Na nektere ulohy se to muze celkem dobre hodit.

[pavlix]

Na úlohy by se ten možná jazyk hodil, ale ještě by byla potřeba slušná implementace s možností nějakého rozumného debuggingu, aby to celé dávalo dohromady smysl.

[Radek Miček]

SICStus má docela hezké IDE SPIDER.

[JS1]

Takze ktery Prolog doporucujes? Tenhle? Co SWI-Prolog?

[pavlix]

Co SWI-Prolog?

To je strašná věc.

[Radek Miček]

Nebál bych se ani jednoho. Výhodou SICStus Prologu jsou nástroje – např. nástroj pro hledání nedeterminističnosti nebo IDE. Na druhou stranu ani jejich absence nezabránila vzniku rozsáhlých aplikací v SWI-Prologu.

[kralyk z abclinuxu]

Na úlohy by se ten možná jazyk hodil, ale ještě by byla potřeba slušná implementace s možností nějakého rozumného debuggingu, aby to celé dávalo dohromady smysl.

Hlavní věc je, IMHO, že to nemá smysl jako samostatný jazyk / samostatný program. Užitečnější by to bylo jako knihovna integrovatelná s programem v některém z obecně použitelných jazyků, který by Prolog používal jako DSL podobným způsobem jako se používají regexpy, SQL apod.

[Radek Miček]

Měli jsme to ve škole asi semestr, možná dva, imho je to v podstatě jen ne moc intuitivní rozhraní k prohledávání do hloubky.

Dnešní implementace v podstatě obsahují 3 jazyky: Prolog, CLP a CHR.