Grahamův problém v Javě je ukecaný. A vadí to?

Grahamův problém má ukázat, jak je nějaký jazyk expresivní. V některých jazycích stačí dva nebo tři řádky, v Javě jsem napočítal aspoň devět řádků. Vadí to?

V Javě vypadá řešení zhruba takto, když chceme být struční:

public class Accumulator {
 private int value;
 public Accumulator(int value) {
  this.value = value;
 }
 public int add(int i) {
  return value += i;
 }
}

Prakticky totéž ve Scale by bylo stručnější:

class MutableAccumulator(private var value: Int){
 def apply(i: Int) = {
  value += i
  value
 }
}

Ačkoli dám přednost Scale, musím uznat, že i Javové řešení je dobře čitelné. A jak je to s psaním? Sice nešetřím každý úder do klávesnice, ale nemám rád, když s sebou psaní kódu nese zbytečně velkou režii, která odvádí pozornost. Není to trochu problém?

Síla Javy je ale jinde. K Javě existují dobrá IDE. Napsal jsem v principu jen něco přes dva řádky, abytek řešilo celkem intuitivní cestou IDE. V mém případě IntelliJ IDEA, ale podobnou službu udělá i Eclipse nebo NetBeans. Tady je video (bez zvuku):

Pokud je to špatně vidět, doporučuji přepnout na vyšší kvalitu videa.
Nejde-li video přehrát, je ke stažení jako OGV.

Schválně jsem nastavil malé rozměry okna. Dá se na to koukat i z 3" mobilu. Až na rozměry okna ale je to pro mě normální nastavení. Nic navíc tam nezaclání, většina okna slouží k psaní kódu.

Jak vidíte na videu:

• Mám kód, který používá neexistující (neimplementovanou) třídu a neexistující metody. IDE mě na toto upozorní.
• Nechám tu zatím neexistující třídu vytvořit. (Alt+Enter)
• Přidám ručně private int n;
• Nakouknu se do mainu a vidím, že nesedí konstruktor. Nechám si tedy vygenerovat konstruktor z fieldů třídy. (Shift+Insert)
• Nakouknu se do mainu a vidím, že ještě chybí add. Nechám si tedy vytvořit metodu add (Alt+Enter), určím návratový typ a napíšu return n += i. Ostatní jen schválím
• V mainu teď nic není červené. Můžu spustit.
• Ještě jako bonus přidám getter a setter. (Možná se do akumulátoru nehodí, ale pro ukázku IDE...)
• Hmm, pojmenovat ten field n nebylo moudré. Nevadí, můžu jej přejmenovat (Shift+F6). Přejmenují se i metody getN a setN na getValue a setValue. Může se přejmenovat i parametr konstruktoru. Tady jsem to zamítl.
• Přidám i výpis hodnoty acc.getValue(). Napsal jsem ale jen acc.gV a IDE zbytek doplnilo.

Nabízí se tu otázky. Mohou kvality IDE nahradit všechny kvality jazyka? Nebo je to naopak a dobré IDE je tu jen od toho, aby pomohlo programátorovi strpět špatný jazyk?

Pravda tu bude asi někde uprostřed. Dobré IDE těžko vyřeší šílené konstrukce nějakého jazyka. Na druhou stranu, IDE se hodí i u příjemnějších jazyků. Typickým příkladem je přejmenování nějaké metody, které je potřeba řešit i všude, kde se ta metoda používá. IDE tuto změnu udělá napříč celým projektem.

Úplně ideální kombinaci jazyka a IDE jsem nenašel. Takovou podporu IDE, jakou má Java (toto video je jen stručný nástřel), jsem u jiného jazyka neviděl. Pokud si ale můžu vybírat jazyk, dám většinou přednost Scale. Podpora IDE se sice s Javou srovnávat nemůže, ale celkem to stačí. I díky tomu, že jde o příjemnější jazyk.