Abo
  1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Freie Softwareentwickler: Welche…
  6. Thema

sind denn alle Entwickler festgefressen....

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: sind denn alle Entwickler festgefressen....

    Autor: Jacques de Grand Prix 29.04.12 - 19:48

    Scala mit LLVM, sehr kühl. Danke für den Hinweis und die ausführlichen Antworten.

    Im aktuellsten Commit erwähnt der Entwickler übrigens, dass er eine Garbage Collection hinzugefügt hat. https://github.com/greedy/scala

  2. Re: sind denn alle Entwickler festgefressen....

    Autor: Trockenobst 29.04.12 - 20:37

    bugmenot schrieb:
    --------------------------------------------------------------------------------
    > es geht ja schließlich um imperativ vs. deklarativ.
    > Bloß weils deklarativ ist, muss man ja nicht auf Datenkapsellung oder
    > Polymorphie verzichten. Funktionales-OO ist überhaupt kein Problem.

    Der Punkt ist dass auch niemand mehr Java "prozedural" verwendet.
    Das kann man, aber muss man es? Ich glaube es gibt sogar noch "goto".

    Scala ist funktional, und dann soll man - weil es nicht anders geht - wieder
    die alten Sachen verwenden bis es durchgängig ist? Wieso gibt es die
    Builder, die Aktoren; Projekte wie "Lift"? Weil man eben nicht zurückgehen
    will. Aber das geht nicht 100%. Warum dann überhaupt beginnen?

    Das ist doch das Problem. Java ist selbst nicht wirklich durchgängig,
    die Strukturen sind auch nicht wirklich durchgängig, z.B. was die Generics
    angeht sind viele Bibliotheken noch nicht auf diesem Stand. Und das war
    vor 3 Jahren.

    > Auch gibt es genug Statistiken, die belegen das man Funktional nur ca. 1/4
    > vom Original-Code braucht. Ich kann das aus eigener Erfahrung bestätigen,

    Das hilft alles nichts, wenn das wichtigste Native Code ist. Das ist meine Ziel-
    richtung. Ich kann ja nicht mal pure Java auf IOS laufen lassen. Die ganzen
    Compiler und Co. sind supercrude. Backend: ja. Aber Mobile ist halt die
    Zukunft und da nützt nichts was auf der JVM basiert.

    Nicht ohne Deal zwischen Apple und Oracle. Der nie kommt.

  3. Re: sind denn alle Entwickler festgefressen....

    Autor: Trockenobst 29.04.12 - 20:42

    ShinGouki schrieb:
    --------------------------------------------------------------------------------
    > Scala ohne VM ist bereits angefangen, einfach mal nach: Scala + LLVM
    > suchen. Dieser Ansatz bringt Vorteile, Nachteile sowie große
    > herrausvorderungen z.B: Garbage Collection.

    Lustig wie man behauptet die Argumente sind schwach und dann kommt man
    mit Pre-Alpha Bastellösungen und sagt: Ja damit kannst Du das nächste
    Angry Birds oder die 1 Million Downloads Sparkassenlösung bauen.
    Come on. Wunschdenken bezahlt nicht die Rente. Experimente muss man
    sich leisten und der PayOff ist bei solchen Problemstellungen "Fraglich".

    Ideologie ist einfach keine Basis.

    > Man kann ganz sicher Scala in 1-2 Tagen so lernen das man es 'wie Java'
    > verwenden kann.

    Ich habe Groovy und funktionale Programmierung in einer Woche gelernt.
    Nur hilft das außerhalb der JVM Welt nichts.

    > Andere Sprachfeatures oder Syntax 'zucker' sorgen dafür das man sich in
    > funktionalen Sprachen nicht so ausschweifend ausdrücken muss wie in z.B
    > Java.

    Scala/Funktionale Programmierung hat massive Vorteile in Cluster/Netz/High-
    Thread Umgebung, wenn man große komplexe Prozesse zu managen hat.
    Closures, Actors etc. haben massive Vorteile in verteilten transaktionellen
    Modellen.

    Aber nicht jeder braucht diesen Hammer.

  4. Re: sind denn alle Entwickler festgefressen....

    Autor: Tapsi 29.04.12 - 20:53

    Kartoffel schrieb:
    --------------------------------------------------------------------------------
    > Wieso? Von entweder oder war ja nie die Rede ;)
    > Ganz klar die VM hat ein ganz dickes Defizit und das ist das man wahlweise
    > immer noch keinen nativen Code kompilieren kann.

    Das ist doch überhaupt keine Aufgabe einer VM. Wenn geht dieses Problem doch eher an die Adresse eines Java AOT Compilers. Ich verzichte eher auf nativen Code ( was zur Hölle soll eigentlich nativer Code sein? Du meinst wahrscheinlich prozessorspezifischen Code oder? ) und habe guten VM Byte Code den ich relativ unabhängig von der Hardware verteilen kann. Vor allem reiten ja immernoch viele auf der VM rum, obwohl diese mittlerweile ein echt gute Optimierungsverfahren für den Source hat und daher ziemlich performant ist.

    while not sleep
    sheep++

  5. Re: sind denn alle Entwickler festgefressen....

    Autor: Trockenobst 29.04.12 - 20:58

    Jacques de Grand Prix schrieb:
    --------------------------------------------------------------------------------
    > Verstehe auch nicht, was gemeint wurde mit "in Scala neuimplementieren".
    > Wahrscheinlich einfach nur unwissenheit darüber, dass alles auf der JVM
    > benutzbar ist. Sprachdesigner wie zum Beispiel Ola Bini (von Ioke und einer
    > anderen neuen) sprechen ja auch oft davon, dass man mit der JVM gleich ein
    > fertiges Ökosystem bekommt.

    Neuimplementieren nach funktionalen Gesichtspunkten.
    Und das klappt ja auch in Java nicht.

    Du hast Bibliotheken, die z.B. "Person" und "PersonList" Objekte haben,
    was aber seit der Generifizierung in Java 5 nicht mehr notwendig ist.

    Du hast dann List<Person> Objekte. Und dass ist in Scala für viele
    Dinge nicht verfügbar. Bestimmte Dinge sind einfach funktional
    besser zu lösen - warum gibt es sonst z.B. eigene Datenbankschichten
    in Scala, oder auch das "Lift" Webframework?

    Weil eben "irgendwas anderes nehmen" nur ein Hack ist. Ich hasse es
    auch, wenn ich z.B. in C++ C Biliotheken nehmen muss, die weder STL
    oder Boost-Standardobjekte verwenden. Das ist ein Systembruch.

    Bei einer Neulösung könnte ich mir mit Aussicht auf schrittweise
    Verbesserung tatsächlich diesen "Bruch" als temporär abtun. Aber das
    ist ja schon bei Java nicht so. Viele große Bibliotheken behalten mit
    einem Schulterzucken ihr "PersonList" Objekt bei.

    Es ist eben dann nicht logisch auf "irgendwas" neues zu setzen, sondern
    das ist ideologisch gepuscht. Das ist selbstverständlich erlaubt. Aber es
    ergibt sich nicht. Momentan ist man bei purem Java mit +100 MB an Libs
    besser aufgehoben als irgendeinen systemischen Hack zu machen.

    Siehe z.B. Scala Traits:
    http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-5

    Libs zu nehmen die nicht mit Traits optimiert sind, wirkt einfach ekelig.

    > vorgestern oder so) aus. Darin werden auch die Vorteile dieses Paradigmas
    > beschrieben: www.altdevblogaday.com

    Carmack ist ein Millionär der halt gerne rumexperimentiert.
    http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

    Nur: niemand hat behauptet das funktionale Programmierung schlecht ist.
    Ich beziehe mich hier auf die gelebte Realität vs. das was man alles für
    Hürden überspringen muss um zu einem Ergebnis zu kommen dass bestenfalls
    ein Wüstes zusammenstecken von Methodologien ist. Und wenn man das
    Ergebnis durch die Brille der Ideologie anschaut, das auch so kommuniziert
    werden muss - und nicht so tut, als wäre es nicht so.

    Ich finde z.B. meine Rückentwicklung von Java zu C++ einen leichten Rückschritt,
    speziell was Debugging und vor allem Memory und Threadverhalten angeht. Da
    muss man verflucht genau aufpassen was man tut, sonst kommt man in Error-
    höllen ohne Wiederkehr. Trotzdem ist es eben dass was der Markt vorgibt.

    Man muss sich ja nur ansehen wo Scala entwickelt worden ist und wie es entwickelt
    worden ist. Da hatten Leute unendlich Zeit und unendlich Ressourcen das Ding
    für ihre Zwecke so lange zu quälen bis es passte. Der normale Entwickler hat das
    eben nicht, und im Normalen Projekt passiert das auch nicht.

  6. Re: sind denn alle Entwickler festgefressen....

    Autor: Kartoffel 29.04.12 - 20:59

    Naja ob iOS dann wirklich "die" Zukunft sein wird werden wir sehen.
    LLVM ist interessant und sollte beobachtet werden.

    Ich habe Scala genutzt welche eine alte größere Java Jar angesprochen hat.
    Und ja du hast vollkommen recht (wie auch auch schon schrieb) Funktional kannst du deine alten Jars sowieso nicht nutzen. SWING und co. natürlich auch nicht, aber man kann für diverse algos Scalas Funktionalität sehr angenehm nutzen. Bsp. mit Higher Order Funktionen. (welches es übrigens auch in Vala gibt ;)

    Ob sich Scala mal im Mainstream durchsetzen wird weis ich nicht..... aber ich glaube an die Sprache weil sie auch sehr gut OO kann.

    @john carmack funktional in c++
    Das Funktional in C++ nicht sonderlich "spass" macht leuchtet mir ein ;-)

  7. Re: sind denn alle Entwickler festgefressen....

    Autor: Trockenobst 29.04.12 - 21:00

    Tapsi schrieb:
    --------------------------------------------------------------------------------
    > echt gute Optimierungsverfahren für den Source hat und daher ziemlich
    > performant ist.

    Das hilft nur nicht wenn sie für 50% der aktuellen Plattformen die relevant
    sind nicht verfügbar ist. http://en.wikipedia.org/wiki/IOS_SDK#Java

    Und komme mir nicht mit kruden Crosskompilern. Da haben sich schon ganz
    andere Leute ihre Haare vom Kopf gefrustet.

  8. Re: sind denn alle Entwickler festgefressen....

    Autor: Tapsi 29.04.12 - 21:01

    ShinGouki schrieb:
    --------------------------------------------------------------------------------
    >
    > Scala ohne VM ist bereits angefangen, einfach mal nach: Scala + LLVM
    > suchen. Dieser Ansatz bringt Vorteile, Nachteile sowie große
    > herrausvorderungen z.B: Garbage Collection.

    Mir fehlt da einfach der Riesenvorteil ( außer Vllt. das man keine Runtime braucht ) gegenüber der Verendung einer VM.

    > Ein Argument was schon einmal viel möchte xh nocheinmal unterstreichen :
    > den grossen Firmen ist herzlich egal mit welcher Programmiersprache ihre
    > Programme laufen, solange billig. Also bei kleinen Projekten wird man eher
    > mal Scala ausprobieren können als in bei großen legacy Anwendungen oder
    > anderen Team Projekten.


    > Scala im Einsatz:
    > Jeder der hier davon schwärmt. Hat sicherlich noch nicht das Vergnügen
    > gehabt Scala in einen vorhandenen Java 'Build-Prozess' einzubinden.
    >
    > Scala verändert die Möglichkeiten für Programmierer auf der JVM. aber bevor
    > entscheider daraus Vorteil ziehen können wird wohl trotzdem noch etwas
    > Zeit vergehen.

    Scala muss ja auch erstmal in realen Projekten Meter Beweis stellen, dass es gegenüber Java ausschlaggebende Vorteile hat. Das Problem bei kleinen Beispielen ist ja oft, dass sie halt klein sind und die größeren Probleme außer acht lässt. Ich bekam mal die Webung für Scala von nem Freund der meinte alles besser weil man keine Getter/Setter braucht. Ich weiß nicht wie es bei euch ist, aber dass kann doch kaum mehr als kleiner syntaktischer Zucker gemeint sein. Besonders da solche Sachen eh von IDEs selbst generiert werden.

    while not sleep
    sheep++

  9. Re: sind denn alle Entwickler festgefressen....

    Autor: Tapsi 29.04.12 - 21:04

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > Das hilft nur nicht wenn sie für 50% der aktuellen Plattformen die
    > relevant
    > sind nicht verfügbar ist. en.wikipedia.org#Java

    Da stand doch gerade noch IOS SDK?!?! Das Java auf geschl. Plattformen wie iOS nicht verfügbar ist kann man nicht Oracle vorwerfen und schon gar nicht der Spache selbst.

    EDIT: 50% ist ja voll,aus dem Himmel gegriffen und m.E. völlig falsch. Es ist auf mind. einer großen Mainstream Platform nicht verfügbar... das wäre richtig.


    > Und komme mir nicht mit kruden Crosskompilern. Da haben sich schon ganz
    > andere Leute ihre Haare vom Kopf gefrustet.

    Hmm ein gutes Konzept ist Streaming. Das sah ( in einem frühen Alphatest ) sehr viel versprechend aus. ;)

    while not sleep
    sheep++



    1 mal bearbeitet, zuletzt am 29.04.12 21:07 durch Tapsi.

  10. Re: sind denn alle Entwickler festgefressen....

    Autor: Jacques de Grand Prix 29.04.12 - 21:05

    Trockenobst schrieb:
    --------------------------------------------------------------------------------

    > Ich habe Groovy und funktionale Programmierung in einer Woche gelernt.
    > Nur hilft das außerhalb der JVM Welt nichts.

    Hast du auch sowas wie "Programming Groovy" von den Pragmatic Programmers gelesen? Da gibt es ein etwa 40-Seitiges Kapitel "Groovy for the Java eyes".

    Eine Woche hat das bei mir auch etwa gedauert, aber danach noch viel in der (eher miserablen) Groovy-Wiki und bei MrHaki nachgeguckt. Mit funktionaler Programmierung meist du nur Closures bzw. Funktionen höherer Ordnung, oder?

    Denn es ist halt realistisch Scala in ein bis zwei Wochen zu erlernen, mit den Besonderheiten der Funktionalen Programmierung. Richtig mit Rekursion und sowas wie Lazy Evaluation und von mir aus auch Monaden kommt man dann aber immer noch nicht zurecht.

  11. Re: sind denn alle Entwickler festgefressen....

    Autor: Kartoffel 29.04.12 - 21:15

    Tapsi schrieb:
    --------------------------------------------------------------------------------
    > Kartoffel schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wieso? Von entweder oder war ja nie die Rede ;)
    > > Ganz klar die VM hat ein ganz dickes Defizit und das ist das man
    > wahlweise
    > > immer noch keinen nativen Code kompilieren kann.
    >
    > Das ist doch überhaupt keine Aufgabe einer VM. Wenn geht dieses Problem
    > doch eher an die Adresse eines Java AOT Compilers. Ich verzichte eher auf
    Ach Gottchen.. dann eben Aufgabe der JRE.
    > nativen Code ( was zur Hölle soll eigentlich nativer Code sein? Du meinst
    http://de.wikipedia.org/wiki/Native-Code?title=Native-Code&redirect=no

    > wahrscheinlich prozessorspezifischen Code oder? ) und habe guten VM Byte
    > Code den ich relativ unabhängig von der Hardware verteilen kann. Vor allem
    > reiten ja immernoch viele auf der VM rum, obwohl diese mittlerweile ein
    > echt gute Optimierungsverfahren für den Source hat und daher ziemlich
    > performant ist.
    Wer hat den behauptet das die VM schlecht oder langsam sei? Ich glaub du missverstehst mich.
    Meine Meinung ist das einer der Hauptgründe warum sich Java nicht auf dem Desktop durchgesetzt hat die benötigte VM ist. Sprich sie muss vor allem beim ersten Programmstart langsam geladen werden. Zudem wäre nativer Code sofort schnell während Java oder Scala erst "ge-JIT-tet" werden muss.

    Ich finde diese hartnäckige "write once run anywhere" Ideologie falsch und behaupte mal das diese Ideologie daran schuld ist das sich Java auf dem Desktop nicht durchgesetzt hat. Was spricht dagegen javac -Target=windows oder javac -Target=Linux oder javac -Target=bytecode
    ?

    Das ganze erinnert mich irgendwie an Richard Stallman und seiner unabdingbaren Einstellung zu GNU.

  12. Re: sind denn alle Entwickler festgefressen....

    Autor: Tapsi 29.04.12 - 21:37

    Kartoffel schrieb:
    --------------------------------------------------------------------------------

    > Ach Gottchen.. dann eben Aufgabe der JRE.

    Ja was denn? Das sind zwei verschiedene Dinge.... du sagtest die VM sollte weg weil sie kein nativen Code erlaubt usw... was aber auch wieder falsch ist, da die JVM ( zumindest die HotSpot VM ) zur Laufzeit Maschinencode erzeugt. Ein guter Vorteil einer VM, dass man plattformunabhängigen Code erzeugt ( im Bezug auf die VM ) und diesen einfach verteilen kann und jede VM für sich für das zu Grunde liegende System optimierten Code erzeugen kann. Komfortabler als jede für jedes System einzelne spezialisierte Binärprogramme erstellen zu müssen (IMHO).


    > Wer hat den behauptet das die VM schlecht oder langsam sei? Ich glaub du
    > missverstehst mich.

    Dann Sry ;)

    > Meine Meinung ist das einer der Hauptgründe warum sich Java nicht auf dem
    > Desktop durchgesetzt hat die benötigte VM ist. Sprich sie muss vor allem
    > beim ersten Programmstart langsam geladen werden. Zudem wäre nativer Code
    > sofort schnell während Java oder Scala erst "ge-JIT-tet" werden muss.

    Mja das stimmt. Obwohl ich den Unterschied bei Anwendungsprogrammen kaum gravierend finde. Leider ist das Installieren eines Plugins immernoch das größte Problem von Java . Hier finde aber Projekte gut die eine VM in das Setup-Programm kapseln.. weil dies gerade für die meisten User dann wieder kein Problem darstellt Java Programme zu verwenden. Aber ich glaube Oracle hat diese Art der Verteilung vor kurzen verboten oder?


    > Ich finde diese hartnäckige "write once run anywhere" Ideologie falsch und
    > behaupte mal das diese Ideologie daran schuld ist das sich Java auf dem
    > Desktop nicht durchgesetzt hat. Was spricht dagegen javac -Target=windows
    > oder javac -Target=Linux oder javac -Target=bytecode
    > ?

    Ich dachte so etwas wollte man ja vermeiden plattformspezifischen Code schreiben zu müssen. ( Obwohl man es hier und da dann doch machen muss )
    Naja ich gehe davon aus dass man wirklich die Fragmentierung vermeiden wollte und eine für alle VM Implementierung gültige Spezifikation einer Sprache haben wollte wo Datentypen immer eine fest definierte Größe haben usw. . Von dem Standpunkt finde ich die Verwendung einer VM auch sehr klug.


    > Das ganze erinnert mich irgendwie an Richard Stallman und seiner
    > unabdingbaren Einstellung zu GNU.

    Kann ich nicht beurteilen... keine Anung :/

    while not sleep
    sheep++

  13. Re: sind denn alle Entwickler festgefressen....

    Autor: Kartoffel 29.04.12 - 22:15

    Man hat sich quasi aus der Desktop Akzeptanz herraus Fragmentiert ;-)

  14. Re: sind denn alle Entwickler festgefressen....

    Autor: ShinGouki 29.04.12 - 23:51

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > ShinGouki schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Scala ohne VM ist bereits angefangen, einfach mal nach: Scala + LLVM
    > > suchen. Dieser Ansatz bringt Vorteile, Nachteile sowie große
    > > herrausvorderungen z.B: Garbage Collection.
    >
    > Lustig wie man behauptet die Argumente sind schwach und dann kommt man
    > mit Pre-Alpha Bastellösungen und sagt: Ja damit kannst Du das nächste
    > Angry Birds oder die 1 Million Downloads Sparkassenlösung bauen.
    > Come on. Wunschdenken bezahlt nicht die Rente. Experimente muss man
    > sich leisten und der PayOff ist bei solchen Problemstellungen "Fraglich".
    >
    > Ideologie ist einfach keine Basis.
    >

    Ja genau das meinte ich ja bisher habe ich wirklich wenige Argumente für scala gehört, leider.
    > > Man kann ganz sicher Scala in 1-2 Tagen so lernen das man es 'wie Java'
    > > verwenden kann.
    >
    > Ich habe Groovy und funktionale Programmierung in einer Woche gelernt.
    > Nur hilft das außerhalb der JVM Welt nichts.
    Aha und was beinhaltet dieses 'funktionale Programmierung' dann? Der Punkt der Blogs von John Carmack und Michael Feathers ist ja das man Vorteile mit der funktionalen Programmierung hat, auch außerhalb der JVM.
    > > Andere Sprachfeatures oder Syntax 'zucker' sorgen dafür das man sich in
    > > funktionalen Sprachen nicht so ausschweifend ausdrücken muss wie in z.B
    > > Java.
    >
    > Scala/Funktionale Programmierung hat massive Vorteile in
    > Cluster/Netz/High-
    > Thread Umgebung, wenn man große komplexe Prozesse zu managen hat.
    > Closures, Actors etc. haben massive Vorteile in verteilten
    > transaktionellen
    > Modellen.
    Netz und High-Thread Umgebung hört sich interessant an, schon mal an sowas gearbeitet?
    > Aber nicht jeder braucht diesen Hammer.
    Nein den wir heißen ja auch alle anders.

    Grundsätzlich gefällt mir dieser Beitrag hier:
    https://forum.golem.de/kommentare/wirtschaft/freie-softwareentwickler-welche-programmiersprachen-angesagt-sind/welche-programmiersprache/62537,2982697,2982697,read.html#msg-2982697

    also der Anfang, es ist ENORM wichtig über den Tellerrand hinaus zuschauen. Es ist wichtig Begriffe zu lernen und eigene Erfahrungen im Zusammenhang zu machen.
    Funktionale Programmierung ist ein anderes Paradigma und dafür braucht es einiges an Zeit um sich darauf einzustellen:
    http://www.infoq.com/presentations/Functional-Thinking

    Und wer noch ganz mutig ist und Langeweile hat kann hier mal reinschauen:
    (und die sich dafür interessieren wie die Zukunf der Programmierung aussehen könnte)
    https://www.tele-task.de/archive/video/realhq/14029/

    https://github.com/damelang/nile

  15. Re: sind denn alle Entwickler festgefressen....

    Autor: ShinGouki 29.04.12 - 23:56

    Jacques de Grand Prix schrieb:
    --------------------------------------------------------------------------------
    > Trockenobst schrieb:
    > ---------------------------------------------------------------------------
    > -----
    >
    > > Ich habe Groovy und funktionale Programmierung in einer Woche gelernt.
    > > Nur hilft das außerhalb der JVM Welt nichts.
    >
    > Hast du auch sowas wie "Programming Groovy" von den Pragmatic Programmers
    > gelesen? Da gibt es ein etwa 40-Seitiges Kapitel "Groovy for the Java
    > eyes".
    >
    > Eine Woche hat das bei mir auch etwa gedauert, aber danach noch viel in der
    > (eher miserablen) Groovy-Wiki und bei MrHaki nachgeguckt. Mit funktionaler
    > Programmierung meist du nur Closures bzw. Funktionen höherer Ordnung,
    > oder?
    >
    > Denn es ist halt realistisch Scala in ein bis zwei Wochen zu erlernen, mit
    > den Besonderheiten der Funktionalen Programmierung. Richtig mit Rekursion
    > und sowas wie Lazy Evaluation und von mir aus auch Monaden kommt man dann
    > aber immer noch nicht zurecht.

    Monaden sind eigentlich nicht wirklich kompliziert nur erst einmal ungewohnt. Die oben genannten Quelen hören sich für diese Themen zumindest fragwürdig an ;)

  16. Re: sind denn alle Entwickler festgefressen....

    Autor: Tapsi 30.04.12 - 07:38

    Das befürchte ich auch :/

    while not sleep
    sheep++

  17. Re: sind denn alle Entwickler festgefressen....

    Autor: Coding4Money 30.04.12 - 08:41

    ShinGouki schrieb:
    --------------------------------------------------------------------------------
    > Ein Argument was schon einmal viel möchte xh nocheinmal unterstreichen :
    > den grossen Firmen ist herzlich egal mit welcher Programmiersprache ihre
    > Programme laufen, solange billig. Also bei kleinen Projekten wird man eher
    > mal Scala ausprobieren können als in bei großen legacy Anwendungen oder
    > anderen Team Projekten.

    Auch die großen Firmen haben es nicht immer leicht das passenden Know-How zu finden. Mich würde es da schon wundern, wenn eine größere Firma mit eigener IT-Abteilung ohne guten Grund auf eine Sprache setzt, die nur von einem Bruchteil der Entwickler wirklich beherrscht wird.
    Wenn ich da ein Java oder C# Programm habe, dann finde ich schon eher einen passenden Entwickler, als wenn ich jetzt einen Entwickler mit F# oder Scala-Erfahrung suchen muss.

  18. Re: sind denn alle Entwickler festgefressen....

    Autor: Tapsi 30.04.12 - 09:17

    Vollkommen Richtig... und es wäre schlicht zu teuer bei Problemen neue Leute zu finden bzw. die Kosten für die Weiterbildung der eigenen Mitarbeiter zu zahlen.

    while not sleep
    sheep++

  19. Re: sind denn alle Entwickler festgefressen....

    Autor: Freepascal 30.04.12 - 09:34

    > Die Antwort warum Scala nicht dabei ist, ist recht einfach zu beantworten.
    > Scala ist zu schwer zu erlernen. Man hat lieber eine Horde dummer
    > Java-Programmierer als eine Handvoll kreativer die Scala beherrschen. Ich
    > fand Scala schon anspruchsvoller als bissl Java zu lernen mMn.

    Sprachen sind immer einfach. Was anspruchsvoll sein kann, ist das Projekt, das man damit umsetzt. Wer irgendwelche Fähigkeiten von der eingesetzten Programmiersprache ableiten will, zeigt nur, dass er nicht viel Ahnung von Softwareentwicklung hat.

  20. Re: sind denn alle Entwickler festgefressen....

    Autor: Helicon 01.05.12 - 08:47

    Freepascal schrieb:
    --------------------------------------------------------------------------------
    > > Die Antwort warum Scala nicht dabei ist, ist recht einfach zu
    > beantworten.
    > > Scala ist zu schwer zu erlernen. Man hat lieber eine Horde dummer
    > > Java-Programmierer als eine Handvoll kreativer die Scala beherrschen.
    > Ich
    > > fand Scala schon anspruchsvoller als bissl Java zu lernen mMn.
    >
    > Sprachen sind immer einfach. Was anspruchsvoll sein kann, ist das Projekt,
    > das man damit umsetzt. Wer irgendwelche Fähigkeiten von der eingesetzten
    > Programmiersprache ableiten will, zeigt nur, dass er nicht viel Ahnung von
    > Softwareentwicklung hat.

    +1

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. STRABAG BRVZ GMBH & CO.KG, Stuttgart
  2. Universität Passau, Passau
  3. HYDRO Systems KG, Biberach
  4. Die Haftpflichtkasse VVaG, Roßdorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. D24f FHD/144 Hz für 149€ + Versand statt 193,94€ im Vergleich)
  2. (u. a. Acer KG241QP FHD/144 Hz für 169€ und Samsung GQ55Q70 QLED-TV für 999€)
  3. (u. a. mit Gaming-Monitoren, z. B. Acer ED323QURA Curved/WQHD/144 Hz für 299€ statt 379€ im...
  4. (u. a. Apple iPhone 6s Plus 32 GB für 299€ und 128 GB für 449€ - Bestpreise!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


SEO: Der Google-Algorithmus benachteiligt Frauen
SEO
Der Google-Algorithmus benachteiligt Frauen

Websites von Frauen werden auf Google schlechter gerankt als die von Männern - und die deutsche Sprache ist schuld. Was lässt sich dagegen tun?
Von Kathi Grelck

  1. Google LED von Nest-Kameras lässt sich nicht mehr ausschalten
  2. FIDO Google führt Logins ohne Passwort ein
  3. Nachhaltigkeit 2022 sollen Google-Geräte Recycling-Kunststoff enthalten

Nachhaltigkeit: Bauen fürs Klima
Nachhaltigkeit
Bauen fürs Klima

In Städten sind Gebäude für gut die Hälfte der Emissionen von Treibhausgasen verantwortlich, in Metropolen wie London, Los Angeles oder Paris sogar für 70 Prozent. Klimafreundliche Bauten spielen daher eine wichtige Rolle, um die Klimaziele in einer zunehmend urbanisierten Welt zu erreichen.
Ein Bericht von Jan Oliver Löfken

  1. Klimaschutz Großbritannien probt für den Kohleausstieg
  2. Energie Warum Japan auf Wasserstoff setzt

Ryzen 5 3400G und Ryzen 3 3200G im Test: Picasso passt
Ryzen 5 3400G und Ryzen 3 3200G im Test
Picasso passt

Vier Zen-CPU-Kerne plus integrierte Vega-Grafikeinheit: Der Ryzen 5 3400G und der Ryzen 3 3200G sind zwar im Prinzip nur höher getaktete Chips, in ihrem Segment aber weiterhin konkurrenzlos. Das schnellere Modell hat jedoch trotz verlötetem Extra für Übertakter ein Preisproblem.
Ein Test von Marc Sauter

  1. Agesa 1003abb Viele ältere Platinen erhalten aktuelles UEFI für Ryzen 3000
  2. Ryzen 3000 Agesa 1003abb behebt RDRAND- und PCIe-Gen4-Bug
  3. Ryzen 5 3600(X) im Test Sechser-Pasch von AMD

  1. Einrichtungskonzern: Ikea startet eigenen Geschäftsbereich für Smart Home
    Einrichtungskonzern
    Ikea startet eigenen Geschäftsbereich für Smart Home

    Der Einrichtungskonzern Ikea will mit einem eigenen Geschäftsbereich seine Smart-Home-Produkte voranbringen. Das Unternehmen will damit mehr bieten als nur gewöhnliche Möbel.

  2. Zoncolan: Facebook testet 100 Millionen Zeilen Code in 30 Minuten
    Zoncolan
    Facebook testet 100 Millionen Zeilen Code in 30 Minuten

    Das Entwicklerteam von Facebook hat ein eigenes Werkzeug zur statischen Code-Analyse erstellt und stellt nun erstmals Details dazu vor. Das Projekt habe Tausende Sicherheitslücken verhindert.

  3. US-Sanktionen: Huawei soll weitere 90 Tage Aufschub bekommen
    US-Sanktionen
    Huawei soll weitere 90 Tage Aufschub bekommen

    Der chinesische IT-Konzern Huawei bekommt wohl einen weiteren kurzfristigen Aufschub der US-Sanktionen, um weiter bei Zulieferern einkaufen zu können. Damit sollen Kunden von Huawei bedient werden können.


  1. 13:28

  2. 12:27

  3. 11:33

  4. 09:01

  5. 14:28

  6. 13:20

  7. 12:29

  8. 11:36