W czym sie programuje w CERN

http://www.pracuj.pl/praca/software-engineer-architect-project-manager-dolnoslaskie,oferta,2105976

No jak widać nie jest to C++ :P
Nie wymagają również tytułu naukowego, wystarczy "equivalence".

No jak widać jest to Java :) Rozsądny wybór.

To trochę bardziej skomplikowane. W CERN 90% kodu powstaje w Javie. W praktyce wszystko co może być przydatne poza CERN i nie jest specjalistycznym softem. Przykład to biblioteka Colt: http://acs.lbl.gov/software/colt/ do obliczeń numerycznych. Pozostałe 10% kodu powstaje w ASM, C, ALGOLu, FORTRANie i jest to kod do sterowania elektroniką czy integracyjny ze starym kodem. Co ważne w CERN w praktyce caly kod jest na licencjach otwartych. Można zatem brać i się uczyć.

In overlapping areas, it is competitive or superior to toolkits such as STL, Root, HTL, CLHEP, TNT, GSL, C-RAND / WIN-RAND, (all C/C++) as well as IBM Array, JDK 1.2 Collections framework (all Java), in terms of performance (!), functionality and (re)usability

Może wreszcie onaniści C++ przestaną pierdzielić jak to Java jest wolna i nadaje się tylko do klepania CRMów.

Wibowit napisał(a)

No jak widać jest to Java :) Rozsądny wybór.

dziwisz się? rozpędzają hadrony, a tu segmentation fault, bo jeden programista nie objął 100% kodu testami ;)

C-- napisał(a)

Wibowit napisał(a)

No jak widać jest to Java :) Rozsądny wybór.

dziwisz się? rozpędzają hadrony, a tu segmentation fault, bo jeden programista nie objął 100% kodu testami ;)

Rozpędzają hadrony, a tu NullPointerException bo jakiś debil nie upilnował.

Lepszy NPE z pełnym stacktracem i messagem niż segmentation fault z d**y i bez wiadomości. No chyba, że ktoś odpala programy w C++ cały czas pod debuggerem, ale wtedy wydajność jest sporo niższa niż Javy.

@Demonical Monk, tylko, że przed NPE można się zabezpieczyć na kilka sposobów. Począwszy od testów poprzez analizę statyczną, a na mechanizmach "smart catch" kończąc.

NullPointer w javie powoduje awarię jednego wątku.
Segfault w C++ wywala całą aplikację.

Od wersji pierwszej wersji Javy były wątki, więc komentarz totalnie z d***.

Lepszy NPE z pełnym stacktracem i messagem niż segmentation fault z d**y i bez wiadomości. No chyba, że ktoś odpala programy w C++ cały czas pod debuggerem, ale wtedy wydajność jest sporo niższa niż Javy.

Akurat w C++ można sobie zrobić Core Dumpa i analizować post-mortem. Co nie zmienia faktu, że wcześniej cały proces się wypierdzieli.

Jeśli by się przejmować bezpieczeństwem na poważnie można by było wziąć jakiś język z kontraktami (http://en.wikipedia.org/wiki/Design_by_Contract)
np. http://en.wikipedia.org/wiki/Spec_sharp żeby Javowcy nie byli górą ;)

No i na tej samej stronie wiki którą podałeś jest mnóstwo linków do Javowych frameworków do kontraktów. Poza tym kontrakty co najwyżej wzmacniają statyczną kontrolę. Ciekaw jestem jak dużo błędów to eliminuje (bo wydaje mi się, że dość mało gdyż zawartość zmiennych rzadko może być ustalona na etapie kompilacji).

Wibowit napisał(a)

Lepszy NPE z pełnym stacktracem i messagem niż segmentation fault z d**y i bez wiadomości. No chyba, że ktoś odpala programy w C++ cały czas pod debuggerem, ale wtedy wydajność jest sporo niższa niż Javy.

A kiedy sie nuczysz tak pisac zeby nie bylo segmentation fault?

Chcesz powiedzieć, że robisz programy bez błędów? To chyba płacą ci szczerym złotem.

Obecnie przy programowaniu rozproszonym stosuje się architektury typu fault-tolerant/ self-healing. Zrobienie czegoś takiego w Javie jest IMO dużo łatwiejsze niż w C++ dzięki rozbudowanemu systemowi wyjątków.

Poza tym dochodzą np wycieki pamięci. Też napiszesz, że w twoich programach wycieków nigdy nie było?

Samemu można pisać zajebisty kod i być najlepszym programistą na świecie.
Co z tego jak w firmie dadzą ci sypiący się kod z wyciekami, do łatania utrzymywania?

No i na tej samej stronie wiki którą podałeś jest mnóstwo linków do Javowych frameworków do kontraktów.

Jasne, przecież nie twierdzę że w javie się nie da. Po prostu chciałem pokazać coś z drugiej strony, peace.

Poza tym kontrakty co najwyżej wzmacniają statyczną kontrolę. Ciekaw jestem jak dużo błędów to eliminuje (bo wydaje mi się, że dość mało gdyż zawartość zmiennych rzadko może być ustalona na etapie kompilacji).

Wydaje mi się że NPE może być nawet w 100% wyeliminowane - do dereferencji obiektu potrzebna jest wiedza że jest nie-nullable - czyli oznaczony !. Ale nie pisałem w tym nawet małego projektu więc nie wiem na ile można 'ominąć' statyczną kontrolę.

No, NPE można wyeliminować nie używając w ogóle nulli :) Null jest w obecnych językach chyba tylko ze względu na kompatybilność/ przyzwyczajenie. Null references - the billion dollar mistake.

Prawda, ale większość dereferencjowanych nulli to nie pola ustawione na null tylko pola nigdy nie ustawione na nic innego (po stworzeniu obiektu wszystkie pola == null).

Fakt, prawdopodobnie można by to wywalić jako relikt przeszłości ale czasami jest to mimo wszystko wygodne... Zazwyczaj jeśli wartość jakiegoś pola da się ustawić w konstruktorze to jest ono tam ustawiane. Jeśli się nie da albo nie chce (np. leniwe ładowanie) pisanie testu == null jest wygodniejsze niż tworzenie np. null objecta (wzorzec) który służyłby tylko do sprawdzania obj is Obj.Null a którego używanie i tak byłoby równoznaczne z błędem (używanie niezaładowanego contentu?)

Null Object przede wszystkim ma typ oraz może implementować puste metody.

Przecież wiem o co chodzi we wzorcu Null Object :) <b= Pomysłu na sensowną sytuację gdzie zwracanie nulla to najlepszy pomysł raczej nie mam (zwodnicze). Ale miałem na myśli coś innego - null jako prywatne pole potrafi być wygodny. a może jednak mam.></b>

Pierwszy podawany przeze mnie przykład - leniwe ładowanie np. obrazka. Masz klasę MyImage zawierającą pole string oznaczające ścieżkę do obrazka (wiem, nieszczególnie ładne rozwiązanie ale chodzi mi o pokazanie problemu a nie wymyślanie 100% realistycznego przykładu). Wiesz że obrazki często tworzysz ale często nie trzeba będzie korzystać z ich danych.
Można to zrobić prosto - np. (sporo kodu pisane z palca więc może być parę literówek etc)

class MyClass
{
    Bitmap imageData;
    string path;

    public MyClass(string path)
    {
        this.path = path;
    }

    Bitmap DoSthAndGetData()
    {
        if (imageData == null) imageData = LoadBitmap(path);

        return DoSth(imageData);
    }
}

Można też zrobić mniej prosto:

interface Doable
{
    void Do();
}

class DoableImage : Doable
{
    Bitmap bmp;

    void Do() { /* Do */ }
}

class NullDoable : Doable
{
    void Do() { }
}

class MyClass
{
    string path;
    Doable do;

    public MyClass(string path)
    {
        this.path = path;
        this.do = new NullDoable();
    }

    Bitmap DoSthAndGetData()
    {
        if (do == NullDoable.Instance) do = new ImageDoable(path); // null object nie służy niczemu innemu niż sprawdzeniu zmiennej.

        return do.Do();
    }
}

PS. Jeśli użycie jakiegoś pola kompletnie nie ma sensu w danym stanie obiektu to mimo wszystko IMO lepiej żeby program się wysypał i ładnie zapisał do logów wszystkie informacje o błędzie niż żeby program zrobił to samo (czyli nic) a o błędzie wiadomo tylko tyle że wystąpił.

PPS. Żeby nie było - nie krytykuję Null Objecta bo czasami potrafi bardzo uprościć pewne rzeczy, tylko zwracam uwagę że może się zdarzyć sytuacja kiedy nie będzie najlepszym wyjściem.

To jak reprezentować wartość, która jest nieznana, jeśli nie przez null?

somekind:
Poczytaj o Null Object Pattern, albo o klasie Option ze Scali.

MSM:
Akurat użycie Null Objecta, aby zaimplementować leniwą wartość jest niezbyt udane. W Scali (i jakimkolwiek języku z wbudowanymi leniwymi wartościami) wygląda to tak:

class Hello(val name: String) {
  lazy val prompt = "Good morning, " + name + "!"
}

object Main extends Application {
  val hello = new Hello("Jackson")
  println(hello.prompt)
}

ATSD:
Nulla wymyślił w 1965 Hoare przy okazji wprowadzenia języka ALGOL 65. Wcześniej jak widać tej pomyłki nie było. COBOL chyba nie ma NULLi, z tego co na szybko na necie znalazłem.

Wibowit napisał(a)

Nulla wymyślił w 1965 Hoare przy okazji wprowadzenia języka ALGOL 65. Wcześniej jak widać tej pomyłki nie było. COBOL chyba nie ma NULLi, z tego co na szybko na necie znalazłem.

Kiedyś, żeby reprezentować puste wartości używało się np. magic number, null w takiej sytuacji jest dużo lepszym rozwiązaniem, także i teraz. Stosowanie Null Object Pattern np. dla reprezentacji pustej wartości typu float byłoby chyba sporą przesadą. On ma sens przy stricte obiektowym programowaniu, aby uniknąć wywoływania metod na nieistniejącym obiekcie. A takiego problemu w 1965r. prawdopodobnie nie było.

Masz na myśli float prymityw (którego nie da się zanullować) czy float opakowany (przy którym Null Object powinien się sprawdzić)?

Można by np wbudować w język obsługę Null Object Pattern, np odpowiedni trait/ interfejs Nullable[T], który byłby reprezentowany przez odpowiedni singleton. Zamiast object == null można by wstawić object.isNull albo coś w ten deseń.

Kod napisany na szybko, bez większego zastanowienia:

trait Nullable[T] {
  def isNoll = false
}

trait NullObject[T] extends Nullable[T] {
  override def isNoll = true
  def noll = this.asInstanceOf[T]
}

class Klasa(val wartość: Int) extends Nullable[Klasa] {
  def dodaj(druga: Int) = wartość + druga
}

object Klasa extends Klasa(0) with NullObject[Klasa] {
  override def dodaj(druga: Int) = 0
}

object Main {
  def main(args: Array[String]) {
    val lista = List(new Klasa(5), new Klasa(8), new Klasa(0), Klasa.noll)
    println("Test 1")
    lista.map(_.dodaj(3)).foreach(println)
    println("Test 2")
    lista.filter(!_.isNoll).map(_.dodaj(3)).foreach(println)
  }
}

Wibowit napisał(a)

Masz na myśli float prymityw (którego nie da się zanullować) czy float opakowany (przy którym Null Object powinien się sprawdzić)?

Miałem na myśli 4 bajty pamięci, które w różnych językach reprezentowały liczbę zmiennoprzecinkową, na długo zanim Java istniała. Ogólnie chodziło mi o uzasadnienie wprowadzenia i stosowania null, zarówno 45 lat temu, jak i teraz.

Można by np wbudować w język obsługę Null Object Pattern, np odpowiedni trait/ interfejs Nullable[T], który byłby reprezentowany przez odpowiedni singleton. Zamiast object == null można by wstawić object.isNull albo coś w ten deseń.

Na szczęście w .NET jest to od lat: http://msdn.microsoft.com/en-us/library/b3h38hb0.aspx

Miałem na myśli 4 bajty pamięci, które w różnych językach reprezentowały liczbę zmiennoprzecinkową, na długo zanim Java istniała. Ogólnie chodziło mi o uzasadnienie wprowadzenia i stosowania null, zarówno 45 lat temu, jak i teraz.

inta czy floata nie da się zanullować. Każda wartość ma jakieś znaczenie. Zanullować można co najwyżej wskaźnik.

Na szczęście w .NET jest to od lat: http://msdn.microsoft.com/en-us/library/b3h38hb0.aspx

To mi nie wygląda na Null Object Pattern, nawet mimo sporej dawki cukru składniowego. Bardziej mi to wygląda na odpowiednik klasy Option[T] ze Scali. Jedyna różnica to chyba tylko to, że podobno .NET używa tylko jednego bita na rozróżnienie pomiędzy Some[T]/ None. Null Object posiada domyślne implementacje metod.

A gdzie onaniści .net? Czemu .net nie używa się w cern? Ktoś może wie?

Strzelam że wszystko stoi na nixach, dlatego nie używa się .neta.

Framework .net jest przeznaczony do szybkiego pisania programów biznesowych, aplikacji webowych itd. To są zupełnie inne dziedziny, zupełnie różne od tego, co jest używane w CERN.