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

sind denn alle Entwickler festgefressen....

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

Neues Thema Ansicht wechseln


  1. sind denn alle Entwickler festgefressen....

    Autor: bugmenot 27.04.12 - 20:23

    ...auf imperativen-OO-Sprachen?

    warum nutzt denn niemand Scala/F# ?

    Ich denke mal der Nachteil an Funktionalen/Deklarativen Sprachen ist, dass man nur 1/4 an Codezeilen benötigt und man dank mangelnder "Gehirnverrenkung" weniger über sein Programm nachdenken muss. Das würde den Gewinn dieser Freiberufler natürlich ordentlich schmälern ;)

    Meine Meinung:
    Wer Scala beherscht, hat eine Lizenz zum Gelddrucken.

    btw: wo ist eigendlich JavaScript/JScript/ECMAScript (wie man das auch immer nennen möchte) ?
    Oder habe ich das im Artikel überlesen?

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

    Autor: Analysator 27.04.12 - 20:50

    Ich mochte funktionale Programmierung an der Uni ja echt gern (gut, wir mussten Racket nehmen, weil man damit ja "so viele tolle Konzepte sieht und weil Scheme geil ist"), aber außerhalb der KI oder so braucht man es halt nicht wirklich :(

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

    Autor: Lord Gamma 27.04.12 - 21:00

    In dem Artikel geht es um das, was nachgefragt wird. Ich denke die meisten Entwickler (mit 20 Jahren Berfufserfahrung!) beherrschen alle gängigen Paradigmen und die Sprachen sind dann sehr schnell erlernbar.

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

    Autor: pka 27.04.12 - 22:07

    Seh ich ähnlich, es ist zweitrangig was der Programmierer beherrscht wenn der der bezahlen soll noch nie was von der SPrache gehört hat wirds schwerer ihm das Geld aus den Rippen zu leiern.

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

    Autor: YAN 27.04.12 - 22:08

    >>Ich mochte funktionale Programmierung an der Uni ja echt gern (gut, wir mussten Racket nehmen, weil man damit ja "so viele tolle Konzepte sieht und weil Scheme geil ist"), aber außerhalb der KI oder so braucht man es halt nicht wirklich :(

    das ist einfach nur etwas Halbwissen über Lisp(wenn du in der Uni Racket gelernt hast, was es unter dem Namen ja noch nicht allzu lange gibt, dann bist du vermutlich noch nicht allzu lang dabei, zumindest in der funktionalen Programmierung), Lisp hatte in der Vergangenheit mal eine große Rolle in der KI gespielt, aber das ist nicht weswegen heute noch solche Sprachen entwickelt werden, die Frage ist auch in welchem Umfang racket behandelt wurde, nur grundlegende funktionale Konzepte ala HtDP Teaching Languages, oder tatsächlich in die vollen inkl. Makros etc. ?

    Wie auch immer, heutzutage werden funktionale Sprachen auch deswegen wieder stärker, weil man Hoffnungen in sie bezüglich der Nebenläufigkeit setzt, das ist aber noch nicht so lange ein großes Thema und Auftraggeber sind doch eher konservativ und übernehmen neue Dinge erst spät und selten.

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

    Autor: irgendwersonst 28.04.12 - 00:04

    bugmenot schrieb:
    --------------------------------------------------------------------------------
    > ...auf imperativen-OO-Sprachen?
    >
    > warum nutzt denn niemand Scala/F# ?
    >
    > Ich denke mal der Nachteil an Funktionalen/Deklarativen Sprachen ist, dass
    > man nur 1/4 an Codezeilen benötigt und man dank mangelnder
    > "Gehirnverrenkung" weniger über sein Programm nachdenken muss. Das würde
    > den Gewinn dieser Freiberufler natürlich ordentlich schmälern ;)
    >
    > Meine Meinung:
    > Wer Scala beherscht, hat eine Lizenz zum Gelddrucken.

    Es geht hier um Kundenwünsche und nicht um maximale Effizienz oder Vorlieben des Entwicklers.
    Es ist nunmal so, daß der Kunde, der Software in Auftrag gibt, auch gerne mitreden möchte und wenn er wie die meisten Menschen nicht besonders ausgeprägt abstrakt denken kann, dann ist OO einfach am besten für ihn nachvollziehbar. Nun zumindest nominell ^^;

    > btw: wo ist eigendlich JavaScript/JScript/ECMAScript (wie man das auch
    > immer nennen möchte) ?
    > Oder habe ich das im Artikel überlesen?
    Steht zwischen ABAP und Basic.

    https://ssl.facebook.com/help/contact.php?show_form=delete_account

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

    Autor: Analysator 28.04.12 - 00:37

    Schon recht "intensiv", also auch mit Makros und so. HtDP fand man sowieso "scheiße, da lernt ihr ja nur Grundlagen und gar nicht wirklich das, was funktionale Programmierung ausmacht".

    Und ja, dabei wurde auch vermittelt, "warum funktionale Sprachen toll sind". Und trotzdem ist es doch so, dass sie derzeit(!) in der Praxis(!!!) keinen besonders großen Stellenwert haben.

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

    Autor: YAN 28.04.12 - 01:30

    funktionale Sprachen in reinform nicht, aber funktionale Features haben in den letzten Jahren stark Einzug gehalten in Mainstreamsprachen, der Trend setzt sich fort, Closures gibt es nun quasi überall.

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

    Autor: pythoneer 28.04.12 - 08:17

    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.

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

    Autor: Tapsi 28.04.12 - 09:04

    Sagte hier einer schon ganz gut, ich schätze mal dass erstens viele ältere Programmierer noch mit dem Programmieren was sie anfangs gelernt hatten. Das dürfte dann C(++) und Java sein. Das führt ja i.d.R. auch dazu, dass Firmen auf diese Sprachen setzen, da a) diese an den Unis oft gelernt wird und b) viel Fachpersonal mit KnowHow über diese Sprachen existieren. Was nützt es mit mit Clojure programmieren zu können ( welche eine echt schöne Sprache ist... muss ich zugeben ), wenn kein Bedarf existiert... deshalb sind eher die Mainstream Sachen gefragt. Aber insgesamt hätte ich ECMAScript höher eingechätzt xD

    while not sleep
    sheep++

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

    Autor: Karlchen11 28.04.12 - 11:19

    @pythoneer

    Eine Programmiersprache erlent man in der Regel in 1-2 Tagen.
    Beherrschen und kommerziell einsetzen dann in 1-2 Jahren.
    Und jetzt troll Dich mit Deiner Unkenntnis.



    1 mal bearbeitet, zuletzt am 28.04.12 11:20 durch Karlchen11.

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

    Autor: Jacques de Grand Prix 28.04.12 - 13:47

    Karlchen11 schrieb:
    --------------------------------------------------------------------------------
    > Eine Programmiersprache erlent man in der Regel in 1-2 Tagen.
    > Beherrschen und kommerziell einsetzen dann in 1-2 Jahren.

    Die Sprachsyntax und das Featureset von Scala lernt man wohl eher erst in 1-2 Wochen. Nichtsdestotrotz ist dies kaum eine Zeithürde.

    Ich selber kann halbwegs Scala programmieren (hatte davor auch mal Erlang gelernt), benutzte es aber bisher in keinem Projekt, da ich Groovy vorziehe. Java indes, tue ich mir bei wirklich performancekritischen Dingen an, aber auf zum Beispiel Closures möchte ich nicht verzichten.

    Eine imperative OO-Sprache wie Groovy ziehe ich funktionalen wie Clojure und Scala wohl einfach vor, weil ich funktionale Programmierkonstrukte selten für Lösungen meiner Problemstellungen benutze/benötige.

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

    Autor: Trockenobst 29.04.12 - 02:38

    bugmenot schrieb:
    --------------------------------------------------------------------------------
    > ...auf imperativen-OO-Sprachen?
    > warum nutzt denn niemand Scala/F# ?

    Ich bin auf C++ zurückgegangen. Warum? Weil ich Anwendungen für Mobile
    Geräte schreiben möchte. Es wird in Java/Groovy geprototyped, und dann
    in C++ umgewandelt wenn man fertig ist.

    Damit erschlage ich IOS, Android, Bada, Blackberry und - so wie es aussieht -
    irgendwann Windows 8. Scala geht vielleicht irgendwie auf Android. Das wars.
    Dafür verschwende ich keine Zeit. Und im Backend tut Java. Es gibt die
    passenden getesteten Frameworks. Das muss ich alles nicht ändern.

    Auch sehe ich bei Kunden und im Postfach keine großen neuen Projekte, die
    man "logischerweise" mit Scala beginnen würde. Das war die Phase als Java im
    Backend groß geworden ist - und da hat jetzt ein wenig Staub angesetzt.
    Es gibt kaum Gründe dass *jetzt* alles wegzuwerfen. Vielleicht in paar Jahren?

    Nichtmal die Apache.org Java-Bibliotheken sind auf dem neuersten Java
    Stand - kein Mensch wird diese Massen an vorhandenen Code nach Scala
    migrieren. Jedenfalls nicht die nächsten 3-5 Jahre. Seeing is believing.

    Somit hat man immer irgendeinen "kruden" Bruch wenn es um fachliche
    Dinge geht. Wenn Scala mal ein paar Workflow, komplexe XML/XSL/Daten-
    parser, Datenbankzugriffsschichten wie Hibernate hat - und dies alles
    nach *funktionalen* Gesichtspunkten designt, getestet, in Millionen großen
    Projekten "in der Praxis" geprüft und für gut gefunden - dann wird Scala
    theoretisch eine Rolle spielen.

    Und dann sollte es bitte auch zukünftig auf dem "neuen PC", also Tablets
    und Handys mit mind 5. Betriebsysteme laufen. Das würde nur gehen,
    wenn es mindestens ein GCC Backend gibt, und das nicht nur in der JVM
    läuft. Eher unwahrscheinlich.

    Der PC stirbt langsam, in 5 Jahren werden 10x mehr Leute komplexe
    Anwendungen auf dem Mobilgerät benutzen, als den Desktop. Dort spielt
    die Musik.

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

    Autor: bugmenot 29.04.12 - 03:18

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > Dafür verschwende ich keine Zeit. Und im Backend tut Java. Es gibt die
    > passenden getesteten Frameworks. Das muss ich alles nicht ändern.

    Wer sagt denn das du in Scala deine Java-Libs nicht nutzen kannst. Letztendlich compiliert Scala in Java-Bytecode (genauso wie Java)
    -> mit Scala kann man also alles machen wie mit Java auch.

    Ich kann diese Abneigung nicht verstehen.

    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.

    Wenn man nur irgendwo eine Methode aufruft und dann irgendwie die Rückgabe speichert und abhängig von nem if den Wert in eine andere Methode gibt ist es auch wirklich Wurst was man nimmt. Aber sobalt der erste Operator ins Spiel kommt ist man funktional immer besser dran. (schneller, einfacher, logischer)

    Wenn man sich die letzten Jahre immer mal wieder irgendwelche Presentationen von wichtigen IT-Leuten angehört hat zu irgendwelchen Themen wie "Das haben wir neu in C# rein", "Das haben wir neu in Java rein" oder "So wird sich alles entwicklen" dann ist es immer das gleiche: Neue Funktionale Elemente in C#, Java, bla ...

    Auch wenn man sich einfach nur mit Leuten unterhält die Ahnung haben merkt man den Trend.

    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, hab dazu aber keinen Link oder Quelle, einfach mal glauben.

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

    Autor: Kartoffel 29.04.12 - 13:39

    Funktional kann die heilige Kuh sein muss es aber nicht immer. Was man im Zusammenhang immer mit Scala vergisst ist das es eine Hybrid sprache ist und wunderbar OO unterstützt. Wenn ich Oracle wäre und es nach mir gehen würde, dann würde ich

    -Java durch Scala ersetzen
    -Bytecode ohne VM lauffähig machen.
    (native compilieren)

    IMHO :-)

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

    Autor: Jacques de Grand Prix 29.04.12 - 13:44

    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.

    Weniger zu schreibener Quellcode wird auch schon stimmen, vor allem auf Grund von Closures, Pattern Matching und Type Inference. Weniger Quellcode ist aber nicht per se besser, es geht ja hauptsächlich darum, zu erkennen was man überhaupt nicht benötigt (KISS-Prinzip und YAGNI-Prinzip) und außerdem eine gute Kohäsion (engl. Cohesion) durch sprechende Variablen- und Methodennamen zu bekommen. Da kann man nicht in den Gedanken verfallen, weniger Quellcode durch einbuchstabige Bezeichner zu schreiben.

    Über funktionale Programmierung mit C (!) mehrt sich übrigens der kongeniale John Cammack (!!) in einem aktuellerem Artikel (von gestern oder vorgestern oder so) aus. Darin werden auch die Vorteile dieses Paradigmas beschrieben: http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

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

    Autor: Jacques de Grand Prix 29.04.12 - 13:48

    Jacques de Grand Prix schrieb:
    --------------------------------------------------------------------------------
    > in einem aktuellerem Artikel (von gestern oder vorgestern oder so) aus.
    > http://www..../2012/04/26/...

    Sprechende Linknamen sollte man aber auch schon lesen können: Vor drei Tagen meine ich natürlich :P

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

    Autor: Tapsi 29.04.12 - 16:24

    > ... ich Oracle wäre und es nach mir gehen
    > würde, dann würde ich
    >
    > -Java durch Scala ersetzen

    Warum? Ich glaube dass Scala auch noch nicht ausgereift genug ist um Java zu ersetzen. Spielt aber auch keine Rolle solange sie korrekten JVM Byte Code produziert kann es doch sogar Wumpe sein weit man programmiert.


    > -Bytecode ohne VM lauffähig machen.
    > (native compilieren)

    Verspielt man dann nicht den großen Vorteil den man durch die VM hat?


    > IMHO :-)

    Jo ^^

    while not sleep
    sheep++

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

    Autor: Kartoffel 29.04.12 - 16:31

    Tapsi schrieb:
    --------------------------------------------------------------------------------
    > > ... ich Oracle wäre und es nach mir gehen
    > > würde, dann würde ich
    > >
    > > -Java durch Scala ersetzen
    >
    > Warum? Ich glaube dass Scala auch noch nicht ausgereift genug ist um Java
    Sehe ich nicht so.
    > zu ersetzen. Spielt aber auch keine Rolle solange sie korrekten JVM Byte
    > Code produziert kann es doch sogar Wumpe sein weit man programmiert.

    >
    >
    > > -Bytecode ohne VM lauffähig machen.
    > > (native compilieren)
    >
    > Verspielt man dann nicht den großen Vorteil den man durch die VM hat?
    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.
    >
    >
    > > IMHO :-)
    >
    > Jo ^^

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

    Autor: ShinGouki 29.04.12 - 19:17

    Die schlagfertigen Argumente die hier verwendet werden sind ja vollends überzeugend.

    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.

    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.

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

    Funktionale Programmierung und kurz:
    Es ist ein Mythos das funktionale Programmierung bzw. Sprachen 'kurzen' bzw. Weniger Code brauchen als imperative. Als Quellen hierfür lege ich dem gediegenen Leser folgende Blog einträge näher :
    John Carmack on functional Programming with C++
    Michael Feathers : confluence OO - FP
    John Carmack sagt es explizit : funktionale Programmierung erfordert MEHR zu schreiben...
    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 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.

  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. CompuGroup Medical Deutschland AG, Kiel, Hamburg
  2. ruhlamat GmbH, Marksuhl
  3. Aareal Bank Group, Wiesbaden
  4. Dataport, verschiedene Standorte

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Alien 40th Anniversary Steelbook, Ash vs Evil Dead Collector's edition, Predator 1 - 4 Box...
  2. ab 0,89€ (u. a. enthalten Distraint 2, Rusty Lake Paradise, Nex Machina, Shantae: Half-Genie Hero)
  3. (u. a. The Division 2 für 36,99€, Just Cause 4 für 17,99€, Kerbal Space Program für 7,99€)
  4. (u. a. Sandisk Plus 1-TB-SSD für 88,00€, WD Elements 4-TB-Festplatte extern für 79,00€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Energie: Wo die Wasserstoffqualität getestet wird
Energie
Wo die Wasserstoffqualität getestet wird

Damit eine Brennstoffzelle einwandfrei arbeitet, braucht sie sauberen Wasserstoff. Wie aber lassen sich Verunreinigungen bis auf ein milliardstel Teil erfassen? Am Testfeld Wasserstoff in Duisburg wird das erprobt - und andere Technik für die Wasserstoffwirtschaft.
Ein Bericht von Werner Pluta

  1. Autos Elektro, Brennstoffzelle oder Diesel?
  2. Energiespeicher Heiße Steine sind effizienter als Brennstoffzellen
  3. Klimaschutz Großbritannien probt für den Kohleausstieg

Kickstarter: Scheitern in aller Öffentlichkeit
Kickstarter
Scheitern in aller Öffentlichkeit

Kickstarter ermöglicht es kleinen Indie-Teams, die Entwicklung ihres Spiels zu finanzieren. Doch Geld allein ist nicht genug, um alle Probleme der Spieleentwicklung zu lösen. Und was, wenn das Geld ausgeht?
Ein Bericht von Daniel Ziegener

  1. Killerwhale Games Verdacht auf Betrug beim Kickstarter-Erfolgsspiel Raw
  2. The Farm 51 Chernobylite braucht Geld für akkurates Atomkraftwerk
  3. E-Pad Neues Android-Tablet mit E-Paper-Display und Stift

Ricoh GR III im Test: Kompaktkamera mit Riesensensor, aber ohne Zoom
Ricoh GR III im Test
Kompaktkamera mit Riesensensor, aber ohne Zoom

Kann das gutgehen? Ricoh hat mit der GR III eine Kompaktkamera im Sortiment, die mit einem APS-C-Sensor ausgerüstet ist, rund 900 Euro kostet und keinen Zoom bietet. Wir haben die Kamera ausprobiert.
Ein Test von Andreas Donath

  1. Theta Z1 Ricoh stellt 360-Grad-Panoramakamera mit Profifunktionen vor
  2. Ricoh GR III Eine halbe Sekunde Belichtungszeit ohne Stativ

  1. Coradia iLint: Alstoms Brennstoffzellenzüge bewähren sich
    Coradia iLint
    Alstoms Brennstoffzellenzüge bewähren sich

    Zwei Züge, 100.000 Kilometer, keine Probleme: Nach zehn Monaten regulärem Einsatz in Niedersachsen ist das französische Unternehmen Alstom zufrieden mit seinen Brennstoffzellenzügen.

  2. Matternet: Schweizer Post pausiert Drohnenlieferungen nach Absturz
    Matternet
    Schweizer Post pausiert Drohnenlieferungen nach Absturz

    Blutkonserven oder Gewebeproben müssen unter Umständen schnell zu ihrem Bestimmungsort gebracht werden. Die Schweizer Post setzt für solche Transporte Drohnen ein. Doch nach vielen problemlosen Flüge ist ein Copter abgestürzt. Das Drohnenprogramm wurde daraufhin vorerst gestoppt.

  3. Nintendo: Akku von überarbeiteter Switch schafft bis zu 9 Stunden
    Nintendo
    Akku von überarbeiteter Switch schafft bis zu 9 Stunden

    Die Hinweise auf eine Hardwarerevision bei der Nintendo Switch sind bestätigt. Bei der neuen Version ist die Akkulaufzeit deutlich verbessert - sie übertrumpft nun sogar die vom Handheld Switch Lite.


  1. 19:06

  2. 16:52

  3. 15:49

  4. 14:30

  5. 14:10

  6. 13:40

  7. 13:00

  8. 12:45