welche Programmiersprache wird am meisten benutzt



  • Moment, das verstehe ich nicht ???
    Denn wen ich sage mich interessiert Windows und DB Programmierung oder Linux und BD dann habe ich keinen großen Auswahl ??
    Also mich interessiert c++ in weiten sinnen, momentan beschäftige ich mich mit MFC und DB. Also wenn ich sage breit gesehen c++ auch neue .net Technologie reicht es ?? und jetzt ist wieder die Frage vielleicht sind ( werden ) doch mehr java Leute gesucht usw. ??



  • Im Gegensatz zu der Meinung, die einige hier vertreten, dass man das nur für spezielle Sparten sagen kann, denke ich, dass das Gegenteil der Fall ist. Für spezielle Sparten habe ich noch keine Statistiken gesehen, was wo wann eingesetzt wird. Wenn man den ganzen Arbeitsmarkt betrachtet, kann man sich einfach die Statistiken angucken, die es überall gibt:

    http://www.jobstats.co.uk/jobstats.d/SKILL.html
    http://www.gulp.de/kb/tools/gulpometer/pdb.html#Programmiersprachen

    Ergenis: Java und C++ liegen sehr gut, Sprachen wie C# spielen keine wirklich relevante Rolle.



  • Gregor
    👍
    mindestens einer der mich versteht 😃



  • 98 % aller Software ist eingebettet ( Auto, Mikrowelle, Waschmaschiene, ect.). Eingebettete SW wird meist recht maschienen nah programmiert. D.h. mit Assembler, C o.ae.



  • xroads42 schrieb:

    98 % aller Software ist eingebettet ( Auto, Mikrowelle, Waschmaschiene, ect.). Eingebettete SW wird meist recht maschienen nah programmiert. D.h. mit Assembler, C o.ae.

    Ja, aber für diese 98% gibt es keine Jobs, oder warum tauchen die nicht in den allgemeinen Statistiken auf?



  • ShadeOfMine! Ehem, hier bei VW wird kräftig auch an neuen Host-DB2 Datenbanken fleissig Cobol-Code produziert, Storedprocedures in Cobol sind hier ein ungeschriebenes Gesetz. Ich arbeite an der zweiten großen Java-Applikation für VW, und jedesmal werden passend dazu auf dem Host Cobol-STPs programmiert. Blos kein SQL vom Client aus, hab es bisher nur einmal durchsetzen können, das ich in eine Tabelle per SQL-INSERT, -UPDATE und -DELETE über den Java-Client zugreifen darf. Alles andere ist den DB2-Spezies zu unsicher, weil man die STP-Aufrufe besser loggen kann. (wer hat wann was gelöscht)

    Java wird hier immer mehr favorisiert, aber nicht wegen der Platform-Unabhängigkeit... interessiert in Wirklichkeit keine Sau - ist eh alles Windows. Aber hier gibts ein VW-Framework in Java, welches alle Host-Protolle (CICS usw.) und die RSA SecureID unterstützt.

    Es gibt natürlich hier noch Projekte in anderen Sprachen, aber C++ ist eher out was "normale" Applikationen angeht.

    Letztendlich kommt es darauf an, wo man was machen will. Wer z.B. wie ich in Wolfsburg wohnt und VW als Kunden hat, muß halt Java oder Cobol drauf haben. In anderen Regionen Deutschlands mit anderen Kunden kann es schon anders aussehen.



  • Gregor schrieb:

    xroads42 schrieb:

    98 % aller Software ist eingebettet ( Auto, Mikrowelle, Waschmaschiene, ect.). Eingebettete SW wird meist recht maschienen nah programmiert. D.h. mit Assembler, C o.ae.

    Ja, aber für diese 98% gibt es keine Jobs, oder warum tauchen die nicht in den allgemeinen Statistiken auf?

    Ich stimme Dir zwar zu, daß ich die 98% auch für übertrieben halte. Bzw. die Angabe einer Prozentzahl ist ohne Aussage, wenn man nicht weiß um was es ging. Bezogen auf die Installationen kann das sogar sein - schließlich sind in fast jedem Motor inzwischen digitale Komponenten drin, die programmiert sind. Da kommt ein Schrittmotorprogramm leicht auf 1000000 Installationen, schon klar.

    Viel interessanter zu wissen wäre aber, wie groß der Entwicklerbedarf Embedded wäre.

    Daß diese Leute bei GULP nicht auftauchen halte ich aber für Auswirkung einer anderen Sache: Embedded-Entwickler sind oftmals Elektroniker, Inbetriebnehmer, Ingenieure, die keine klassische IT-Karriere haben. Sie passen auch nicht in das übliche Altersschema der Programmierer, die zwischen 20 und 35 sind - häufig sind die Altersgruppen eher im Bereich 40-50 vertreten, auch sind die Teams anders - es findet mehr eine klassische Trial&Error-Entwicklung statt, ohne Projektplan für die Software und Tools. Diese Jobs gibt es in der Tat sehr zahlreich, aber man würde in diesen Firmen nicht nach freien Entwicklern wie bei GULP suchen, das ist eine andere Welt + Philosophie. Dort hängen oftmals ganz Produktfamilien an einem einzigen Entwickler - fällt der tot um, war's das.



  • Artchi schrieb:

    ShadeOfMine! Ehem, hier bei VW wird kräftig auch an neuen Host-DB2 Datenbanken fleissig Cobol-Code produziert, Storedprocedures in Cobol sind hier ein ungeschriebenes Gesetz.

    Liege ich richtig, wenn ich annehme, dass Cobol deshalb verwendet wird, weil es bisher immer dafuer verwendet wurde?

    Letztendlich kommt es darauf an, wo man was machen will. Wer z.B. wie ich in Wolfsburg wohnt und VW als Kunden hat, muß halt Java oder Cobol drauf haben. In anderen Regionen Deutschlands mit anderen Kunden kann es schon anders aussehen.

    exakt. Genau darauf wollte ich hinaus.
    Wenn man sich fuer Was-Auch-Immer-Man-Bei-VW-Tun-Muss interessiert, hat man ein ganz anderes Spektrum von Sprachen zu beherrschen, als jemand der Webanwendungen schreiben will.



  • Hi,

    vielleicht wird irgendwann überall windows eingebettet sein, und wir Programmierun dann nur noch mit C#.Net 🙂



  • Und wenn C# sich bis dahin nicht drastisch weiterentwickelt hat geb ich mir die Kugel.



  • c++eus schrieb:

    vielleicht wird irgendwann überall windows eingebettet sein, und wir Programmierun dann nur noch mit C#.Net 🙂

    Ja, besonders im Realtime-Bereich ist Windows geradezu prädestiniert! 😃



  • Jester schrieb:

    c++eus schrieb:

    vielleicht wird irgendwann überall windows eingebettet sein, und wir Programmierun dann nur noch mit C#.Net 🙂

    Ja, besonders im Realtime-Bereich ist Windows geradezu prädestiniert! 😃

    Es gibt CNC-Maschinen die mit Windows als Betriebssystem arbeiten. Hochgenau und in Realtime 😉 (siehe z.B. SINUMERIK)



  • MaSTaH schrieb:

    Und wenn C# sich bis dahin nicht drastisch weiterentwickelt hat geb ich mir die Kugel.

    Jetzt übertreib aber nicht sondern informier dich über C#. Denn es ist (meiner Meinung nach) eine sehr praktische Sprache, in der viele Mängel von C++ beseitigt wurden.



  • c++eus schrieb:

    Denn es ist (meiner Meinung nach) eine sehr praktische Sprache, in der viele Mängel von C++ beseitigt wurden.

    Welche Maengel beseitigt C# denn?

    Garbage Collection? Geht aber zu kosten von Destruktoren.
    Kryptische Syntax? Ne, das ist in C# auch nicht besser.
    Fehlendes foreach? Yes, das hat es.
    Include Dateien murks? Jo, das kann C# besser - verhindert dadurch aber Tricks wie sie mit dem CPP moeglich sind.
    Bessere Library? Jo, gehoert aber weniger zu C# als zu .NET
    Komplexitaet? Naja, C# ist abgespeckt und deswegen leichter zu lernen, aber wirklich sauberer kann man in C# nicht programmieren.

    Und die Nachteile:
    Ne Menge murks von Java uebernommen, wobei C# meiner Meinung nach einige Java Probleme beseitigt, aber bei weitem nicht alle.

    Wuerde mich echt interessieren was deiner Meinung nach die Maengel von C++ sind, die C# besser macht. (Von der Library mal abgesehen, denn die ist in C++ wirklich mager)



  • Hi,

    es wurden einige Dinge eingeführt, die sehr sinnvoll sind. So wird z.B. zwischen einem int und einem bool unterschieden.
    So führt

    if(i = 1)
    {
    }
    

    zu einer Fehlermeldung.
    Auch sind die Eigenschaften sehr sinnvoll.
    Zu den Konstruktoren:
    Man kann auch Dispose() (Interface IDisposable) verwenden.
    Allerdings muss auf Seiten MS noch nachgebessert werden.
    #edit# es ist interpretiert und so (compilirete Dateien!) plattformunabhängig. Diesen Vorteil spielt es aber noch nicht aus.



  • c++eus schrieb:

    Auch sind die Eigenschaften sehr sinnvoll.

    Wo liegt denn da der Vorteil? Ich sehe da noch nichtmal eine nennenswerte Einsparung von Code. Es wird nur etwas implizit gemacht, was vorher explizit war, zum Selbstzweck praktisch. Ich kann da beim besten Willen keinen Vorteil entdeckten.



  • Hi,

    der eigentliche Zweck von Eigenschaften besteht ja darin:
    auf ein Feld zugreifen, und den Zugriff eventuell einschrenken. Wenn man z.B. eine Klasse Deklariert, die ein Gerät steuert (z.B. einen Videorekorder) und sie ein Feld

    bool zeitlupe;
    

    deklariert, dann sollte dieses Feld nur zum Lesen bereitgestellt werden. So wird das Feld nur von der Klasse intern verwendet werden. Wenn man einem Programm aber das Feld öffentlich bereitstellt, und dieses das Feld auf true setzt, dann könnte eventuell der Reorder beschädigt werden.
    In C++ wurde nun durch eine Methode auf das Feld zugegriffen. So musste der Benutzer der Klasse erst nachsehen, wie der Name der Methode ist.
    In C# ist der Zugriff nun uber den get Teil der Eigenschaft möglich. So ist der Name der Eigenschaft auch Standarisiert. Außerdem erkennt der Compiler automatisch, ob ein Lese oder Schreibzugriff erfolgt, und gibt bei einem Schreibzugriff autom. eine Fehlermeldung aus.
    Außerdem Erfolgt der Schreibzugriff so, als wenn die Variable öffentlich deklariert währe, nämlich über eine Zuweisung.



  • Ok, was macht man, wenn man auf die Idee kommt, den Zustand des Objekts anders darzustellen. Man hat dann plötzlich keine Variable "zeitlupe" mehr, sondern speichert das intern anders und würde normalerweise eine "Umrechnung" in der entsprechenden Getter/Setter-Methode machen. Wie macht man das nun bei den Eigenschaften?

    Abgesehen davon sehe ich noch immer keinen Vorteil.



  • Hi,

    in den get und set-Methoden kannst du auch anderen Code integrieren.



  • Das was du hier mit der variablen als Vorteil bezeichnest, wird in C# doch nur
    dem Interpreter überlassen, in C++ muss man das halt selber erledigen.
    Dass eine High-Level-Interpretersprache einem Arbeit abnimmt im vergleich zu
    einer low-level Sprache ist doch wohl selbstverständlich, oder?


Anmelden zum Antworten