Überraschung bei Programmiersprache des Jahres

Die Betreuer des TIOBE-Index, der die Popularität von Programmiersprachen verfolgt, hat nun den Sieger für das Jahr 2013 festgelegt. Und das Ergebnis dürfte etwas überraschen: Transact-SQL. mehr... Quellcode, Code, Programmierung, Programmiersprache Quellcode, Code, Programmiersprache, Php, Source Code Quellcode, Code, Programmiersprache, Php, Source Code Free for Commercial Use / Flickr

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Ich finde mit C# kann man sehr angenehm entwickeln. Von den Möglichkeiten ist natürlich C++ ganz weit vorne.
 
@PranKe01: entwickeln mit c# ist schon sehr angenehm, doch für kommerzielle Dinge eigentlich total ungeeignet, da nicht richtig kompiliert wird und jede Assembly ganz leicht wieder in Source umgewandelt werden kann
 
@_c80_: das mit dem "nicht" kompilieren (also Erstellung eines Zwischencodes) hat auch große Vorteile, denn dadurch kann man im JITC für viele Maschinen besser optimieren und ist (theoretisch) Plattformunabhängig ohne neu zu builden (siehe Java - wobei nicht jede Java-VM einen JITC hat) Mit C# können auch komplizierte Dinge einfach gelöst werden. Das wiedererstellen des Source kann mit Obfuscator erschwert werden, jedoch sollte man sich ohnehin nicht auf soetwas verlassen (auch wenn eine Sprache in Maschinencode kompiliert wird kann diese gelesen werden - OllyDbg anwerfen und etwas Assembler lesen fertig) - Assemblies beeinhalten auch nur Op-Codes halt eben CIL statt MASM

;EDIT: manche JavaVMs haben einen JITC (nicht alle) - Danke an RalphS
 
@wischi: 1) Was bringt das bessere Optimieren, wenn es trotzdem noch deutlich langsamer ist als nativer Code? - Nichts! 2) Ein Obfuscator erschwert das Wiederherstellen in keinster Weise, der Code ist nur schlechter lesbar 3) OllyDbg liefert dir aber kein komplettes Projekt im Quellcode. Bei .net-Assemblies geht das problemlos.
 
@wischi: Java hat keinen JIT-Compiler? *kopfkratz*
 
@RalphS: Dachte alle Java VMs führen den ByteCode direkt aus. Stimmt aber nicht ganz die Antwort liegt dazwischen :-) Manche VMs haben einen JIT-Compiler, nicht alle. Aber danke für den Hinweis
 
@_c80_: Gerade für kommerzielle Dinge ist c#/.Net geeignet, weil sich durch die Einfachheit und Interoperabilität die Produktivität stark eröht. Was die Disassemblierung angeht, so kommt es zum einen darauf an, in welchem Bereich deine Software eingesetzt wird (z.B. in großen Konzernen mit Wartungsverträgen, Festpreisen etc. ist ein Schutz nicht unbedingt zwingend notwendig, da es dort in der Regel SLA's gibt, die solche Dinge Regeln) Für den komerziellen Einsatz im Privatanwenderbereich bietet .Net bereits ein intergriertes Lizenzmodell, welches zur Entwurfszeit greift. Weiterhin gibt es kostenfreie Obfuskatoren zur Verschleierung und komerzielle Drittanbietersoftware, welche ein Disassemblieren verhindern.
 
@heidenf: Das integrierte Lizenzmodell kann leicht umgangen werden und Obfuskatoren stellen eh kaum ne Hürde dar aber gib doch mal bitte ein Beispiel für "komerzielle Drittanbietersoftware, welche ein Disassemblieren verhindern" das würde mich sehr interessieren. Ich nutze normalerweise C/C++ Code in DLLs in meinen C#-Programmen um sie vor RE zu schützen
 
@heidenf: Naja, das mit der Produktivität ist so eine Sache. Die riesige Klassenbibliothek des .net-Frameworks ist Fluch und Segen zugleich. Aufgrund ihrer Komplexität und weil es eine ziemlich große BlackBox ist, bremst sie nämlich auch so manches mal. Dadurch hält man sich immer wieder ewig an kleinen Details auf. Ich sehe in der Firma insgesamt jedenfalls nicht, dass unsere WPF/.NET/C#-Spezialisten produktiver wären als unsere VB6-Spezialisten. Tendenziell ist eher das Gegenteil der Fall.
 
@TiKu: Meine Erfahrung ist genau andersherum!
 
@TiKu: .NET ist keine Blackbox (mehr). Die meisten Bereiche des .NET Frameworks sind offiziell als Quellcode zu haben und neue Technologien wie ASP.NET, WCF, WebAPI werden unter MSPL freigegeben. .NET ist jedenfalls bei der Ressourcen-Planung die am effizientesten zu entwickelnde Software. Java Entwickler werden meist mit Faktor 0.35 verrechnet (1=100%) (sprich, von 40h Wochenzeit werden nur 35% in effektiven Code gewandelt, der nachher im Produkt landet) - das ist ein fataler Wert! Bei .NET liegt der Wert mit 0.65 fast doppelt so hoch. Liegt aber auch mit an der wahrscheinlich besten IDE, die es auf dem Markt gibt. Trotzdem gibt es Bereiche die im .NET einfach fatal falsch/schlecht/schlampig implementiert wurden (zB System.IO, weswegen ich immer via PInvoke CreateFile und FindFirstFile etc verwende).
 
@TurboV6: Nimm die BlackBox mal nicht wortwörtlich. Ich weiß, dass der Quellcode prinzipiell verfügbar ist. Aber überblickst du den? Weißt du ohne längere Analyse wie bestimmte Bereiche aufgebaut sind und wie sie im Detail funktionieren? Klar, man sammelt mit der Zeit seine Erfahrungen. Aber ich erlebe es halt immer wieder, dass man auch als Vollprofi Stunden oder gar Tage damit verbringt, irgendeinem seltsamen Phänomen in der Klassenbibliothek auf die Schliche zu kommen. Sowas gibt es bei nativer Programmierung zwar auch, aber irgendwie deutlich seltener.
 
@TiKu: naja ich mach c# seit 2001 - ich kenn mich in meinem 'Zuhause' schon ganz gut aus ;)
Aber man muss vieles aus der damaligen Entstehungszeit verstehen, dass man den managed-Aufbau nachvollziehen kann; ja.
 
@TurboV6: Mit der Effizienz kann ich bestätigen. Ich habe früher Prozessleitsysteme für die chemische Industrie entwickelt, damals noch mit NextStep / Openstep und Objective-C. Diese Sprache war damals schon sehr fortschrittlich, aber als wir vor gut 10 Jahren auf .Net / C# /Visual Studio umgestiegen sind, haben wir, was die Produktivität angeht nochmal eine ordentliche Schippe draufgelegt. Bei .NET passt einfach alles zusammen. Für alles mögliche gibt es eine API. Auch wenn Java und Objective-C ebenfalls sehr gute Programmiersprachen sind, so fühlt sich C# nicht zuletzt durch seine Interoperabilität der verschiedenen Programmiersprachen und der herrvorragenden IDE einfach runder an. Das einzige, was ich mir wünschen würde ist, dass MS mehr in Richtung Mono Projekt ginge und aktuelle Framework Versionen auch mal für Unix und Co. bereitstellen würde. Auch wenn das aufgrund von COM, P-Invoke und den ganzen Verdächtigen nicht ganz einfach und viel Arbeit sein dürfte.
 
@heidenf: der Wunsch der Mono-Community ist, dass sich MS aus der Entwicklung raus haelt. Daher bringt MS ja immer nur unregelmaessig Finanzspritzen und keinen Code.
 
@TurboV6: Mag sein, aber im Mono Bereich tut sich einfach nichts mehr. Dort dümpelt man immer noch auf Teilmengen des 2.0 Frameworks rum. Aber immerhin läuft Mono sogar auf meinem Qnap :-)
 
@TurboV6: Ich sollte mich wirklich mal wieder ein wenig mehr mit Mono beschäftigen. Ich lese gerade, dass das Projekt eingestellt und von Xamarin übernommen wurde. Sogar schon vor zwei Jahren. Wie die Zeit vergeht ...
 
@heidenf: mhh??? C#5.0 wird doch vollstaendig unterstuetzt. Nur natives und Oberflaechenzeug wie WCF oder WPF geht halt nicht. Aber sogar ASP.NET ist meines Wissens komplett portiert ?!
 
@TurboV6: Wie gesagt, meine letzten Informationen sind schon etwas älter. Vielleicht hat sich ja wirklich mal einiges getan. Werde morgen (bzw heute) mal einen ausführlicheren Blick drauf werfen.
EDIT:
Ich bin einigermaßen entzückt! Mit der aktuellen Version kann man offenbar schon ziemlich viel anfangen: http://tinyurl.com/yf7kc8l
 
@_c80_: Man kann auch OpenSource Produkte verkaufen. Kommt nur auf die Lizenz drauf an.
 
@_c80_: falsch. Es gibt schon seit einigen Jahren Lösungen für die komplette Verschleierung von Code ILCode. Obfscatoren sind mal das erste Hindernis, um "normale User" vom Code fern zu halten. Die professionelle Variante ist dann NET Encryption.
 
@TurboV6: Wie schon erwähnt ist Verschleierung fast nutzlos gegen fähige Angreifer aber bitte gib doch mal nen Link für "Die professionelle Variante ist dann NET Encryption"
 
Ich gehöre seit kurzem zur Python Fraktion, und ich hasse es!
 
@hhgs: Bei mir ist es Smalltalk seit Kurzem...und ich werd auch noch nicht ganz warm damit =)
 
@hhgs: und warum?
 
@mywin: Ich komme einfach nicht damit klar, ich kann mir die Befehle nicht merken. Und vieles erscheint mir unglaublich umständlich. Vielleicht habe ich auch einfach noch nicht die richtige Lektüre gefunden bzw. eine nette Seite mit Tutorials & Co.
 
@hhgs: Hab aktuell ähnliche Probleme bei F#, es ist einfach so anders als C#. Wenigstens kann ich in F# noch leicht C-Styled coden :D
 
@hhgs: Lass mich raten, du kommst von einer C-Sprache? :D
 
@Knerd: Erraten! :-D
 
Ich arbeite zurzeit sehr gerne mit C# & PHP zusammen, damit kann man ganz tolles zeugs zusammen basteln! Batch & VBS nutze ich auch sehr gerne ab und zu für kleinere projekte.
 
Hehe, nicht mal nur SQL, sondern gleich T-SQL. So schlecht kann Microsoft ja dann doch nicht sein. :o)
 
Es geht nix über reinen Maschinencode. Aufwendig aber effizient.
 
@skyjagger: Ja effizient für eine Umgebung :-) Je effizienter und spezifischer, desto weniger portabel. Und je abstrakter und flexibler desto portabler aber langsamer. Ist mit allem so. Die meisten Sprachen haben eine gute Daseinsberechtigung man sollte nur nicht den Fehler machen und verallgemeinern ^^ Und versuchen mit Maschinencode eine Graphische portable Desktop-App zu schreiben oder mit Java/C# einen Ring-0 Treiber.
 
@wischi: Nein portable ist anders, ich weiß das. Aber nichts würde die Hardware so effektiv nutzen können. Gerade bei Smartphones ist die Vielfalt ja noch überschaubar. Gerade für die Hersteller sollte es kein Problem sein die eigene Hardware entsprechend anzusprechen :)
 
@skyjagger: gerade im smartphonemarkt ist die variation von nötigen/möglichem maschinencode weit vielfälltiger als auf dem desktopmarkt....arm instruktionssätze gibt es etliche, manche auch mit leichten abwandlungen, dazwischen finden sich auch noch die ein oder andere ia32 prozessoren
 
Hab grad mal meinen ollen Casio FX-850P wiederbelebt: Mit 64k lässt es sich auch mit BASIC ganz wunderbar programmieren :-)
 
@beeelion: Pfft, 64 kB... In meiner Schulzeit war man mit 32 kB schon gut dran, die meisten hatten 16 kB. Hat dennoch für allerlei Programme und Spiele gereicht...
 
@TiKu: Zu meiner Schulzeit hatte unser "Lehrrechner" 2k Arbeitsspeicher und 128KB ROM. Dann konnte man Stundenlang tippen um irgendeine Meldung über die 7SegmentLED anzeigen zu lassen :D
Das war noch Handarbeit pur
 
vbs und bat lassen sich auch gut programmieren, kommt immer darauf an, was man machen will
 
In letzter Zeit ist mir Prolog sehr ans Herz gewachsen wobei das hier wohl eher etwas außer Konkurrenz steht
 
Was ist mit Pascal? *Ironie aus*
 
JS FTW :)
 
@mywin: Ich glaube wir waren noch nie einer Meinung, aber hier stimme ich dir zu, JS ist eine echt klasse Sprache :)
 
T-SQL, Respekt :D Ich bin inzwischen komplett mit C#, JS und F# zufrieden :) Letzteres steht für 2014 auf der Liste zu lernen ^^ F# ist zwar sehr anders als C#, aber es hat auch seine Vorteile :) Auf der Arbeit muss ich leider mit C++ rumhantieren -.-
 
@Knerd: Friss diese AccessViolation und nimm noch direkt dieses "unresolved external Symbol" mit ;D. Ja C++ ist schon furchtbar ;)
 
@Suchiman: Vor allem wenns dann Borland 6 ist ;)
 
@Knerd: Auch wenn ich manchmal den Komfort von C# vermisse, mag ich C++ doch recht gerne - weil man mehr Kontrolle hat. Borland C++ ist aber wirklich ein Graus, schon allein wegen der IDE. Aber hast du bzw. deine Firma vielleicht noch eine Lizenz übrig vom BCB6? Wir könnten noch eine gebrauchen und die sind inzwischen ziemlich schwer zu bekommen.
 
@TiKu: Nope :D Wir haben das auch nur, weil ein Update auf 2009 nicht ging ;)
 
@Knerd: Hehe, wir stehen vor einem ähnlichen Problem. Ein Freelancer hat vor vielen Jahren mal für uns eine Komponente in BCB4 entwickelt. An der müssten wir nun eigentlich mal was ändern. Nach ersten Recherchen wäre eine Portierung auf eine aktuelle BCB-Version arg aufwendig und fällt damit flach. Auf BCB6 wäre der Aufwand dagegen wohl akzeptabel und wir könnten dann für alle BCB-Projekte die selbe BCB-Version verwenden. Ich mach 3 Kreuze wenn die BCB-Projekte endlich auf was modernes portiert oder beerdigt wurden...
 
@TiKu: Bei uns läuft momentan das Refactoring auf .net :D
 
@Knerd: Bei uns auch, aber erstmal für die Unmengen von VB6-Code. Der BCB-Kram muss seltenst geändert werden und läuft einfach, deshalb steht das in der Prio weit unten, zumal noch nicht ganz klar ist, in welcher Form diese Teilprojekte überhaupt weitergeführt werden.
 
@Knerd: F# macht doch wirklich nur in sehr spezialisierten Gebieten sinn. Oft ist C# völlig ausreichend von der effektiven Ausführung und ist dabei viel leichter wartbar. Zudem lassen sich bei C#, wenn man die Hintergrunde der Methoden kennt, ja sowieso noch enorm viel rausholen. Viele arbeiten mit List<T> und wissen nicht, dass HashSet<T> viel performanter ist und dabei die gleichen Grundmethoden bietet (Suche zB mit Aufwand O(n), O(log(n)) etc...)
 
@TurboV6: F# macht den Code bedeutend kürzer ;) Und da es einfach .net ist, kann man es super in .net benutzen. Alleine schon wenn du WebRequests raus jagen willst, das ist bedeutend weniger Code als mit C#.
 
@Knerd: naja Du sparst bei F# und WebRequest genau eine Zeile...
Aber genau das ist der Trugschluss an F#: es ist _nicht_ fuer unmanaged/handleoperationen gedacht - es ist sogar kontraproduktiv! Der WebRequest verwendet Handles, die so schnell wie moeglich wieder freigegeben werden sollten, da diese begrenzt sind (Resultat: OutOfMemoryException).
Bei F# verhaelt sich der GC aber viel diskreter, weshalb die Handles beim Dispose-Verhalten leider nicht wieder sofort freigegeben werden. Fazit: ersparnis quasi annaehernd 0, dafuer schlechteres Ressourcen-Verhalten.
Ich verwende F# fuer Laufzeitberechnungen, Parsen/Suchen von und in Dateien oder eben fuer die Abbildungen von Algorithmen - aber niemals fuer Ressourcen-Code!
 
@TurboV6: Ich spare mehr, denn der ganze Klammeroverhead fällt weg. Die Methoden für JSON wenn es um PCLs geht sind in F# sehr gut gemacht. Dazu nehme ich nicht direkt WebRequests sondern die HttpClient-Klasse aus, System.Net.Http.
 
@Knerd: naja im Endeffekt vergewaltigst Du eine funktionale Sprache und hebst ihre Nachteile heraus, da dir der Stil gefaellt ;-)
 
@TurboV6: Tu ich das? Schau dir mal das Video von der PDC zu F# von Luca Bolognese an ;)
 
@Knerd: ja kenn ich, is bissle trend etc. Jedes mal wenn ein 'Grosser' eine Technologie zeht isse fuer 3-9 Monate das nonplus-ultra. Ich seh ja als Forenmod fuer .NET wie die Trends kommen und gehen. T4 war am Anfang auch mega gehyped, jeder wollts machen und dann isses wieder auf nen normales Niveau abgeklungen.
F# hat seine Daseinsberechtigung; aber eben im Finanz- und Wissenschaftssektor. .NET und Micro-Performance-Improvements is halt Kaese. ;)
Paar Dinge machts wie gesagt sinn; kannst aber an einer Hand abzaehlen. Mach nen paar hundert Handles mit F# auf... ;) aber wenns bei dir so passt is ja gut.
 
@TurboV6: Naja, die Technologie ist von 2009 ;) Das ist eine PCL, die auch wieder nicht viel macht. Daten vom WebService holen und dann das JSON in Klassen werfen. Da gibt es einige Sachen die C# nicht hat, vor allem was List und Seq angeht. Seit .net 4.5 hat sich allerdings der async Vorteil erledigt ^^
 
@Knerd: async gabs ja schon seit der TPL, die ja jetzt auch in c++ vor dem Konsortium steht. Was der Compiler mit async/await aber macht empfinde ich als Fluch: jeder denkt er kann ploetzlich MultiThreaded programmieren. Geht natuerlich in die Hose und die tauchen bei ins im Forum auf...Json in .NET isn schlechter Witz. Verwende nur Json.NET von newtonsoft.
 
@TurboV6: Json.NET kannst du aber bei PCL knicken. Als ich dieses Jahr auf der CeBit mir einen Vortrag zu async/await angeschaut habe, war einer der ersten Sätze, es ist kein vollwertiges Multithreading. Die System.Web.Extensions sind ganz gut, JsonSerializer etc. Ansonsten bietet F# das hier: http://fsharp.github.io/FSharp.Data/index.html
 
@Knerd: dieses Jahr, war gestern Cebit? :D
Der Compiler macht aus async einfach nen normalen Task. Und Task verwendet den Standard Task Scheduler. Das ist schon alles echt. Nur es wird so dermaßen vereinfacht, dass keiner mehr Bock hat zu kapieren, was da ueberhaupt passiert und sich wundert, wieso er Thread-Zugriffsverletzungen um die Ohren geworfen bekommt; oder ungueltige Daten wegen unsynchronisierten Parallelzugriffen.
 
@TurboV6: Gut, das ist wahr. Man sollte sich natürlich auch mal anschauen was dahinter steht ;) Gott, ich bin noch in 2013 :D Muss man sich halt einlesen, das einige dazu zu faul sind zeugt von einigem. Btw. das aktuelle F# Projekt ist auch mehr Proof of concept und bisher macht sich F# recht gut. Wobei ich vermute, dass ich in einer Woche den Code weg werfe, als netter Versuch abstemple, und das ganze in C# mache ^^
 
@Knerd: Das wird Dir aber alles nichts nützen, wenn Du auf den MS SQL Server zugreifen willst. Dann brauchst Du T-SQL, nicht C#, nicht F#, nicht C++ und auch nicht JAVA.
 
@RalphS: ADO.net EF ;) Die meiste Apps die ich habe, sind nicht Performance kritisch ;)
 
@Knerd: Mh? Braucht man da kein SQL? Konnte mich mit ADO noch nie anfreunden. ;o)
 
@RalphS: ADO ist so ziemlich das maechtigste Werkzeug im ORM-Bereich; deswegen wirds oft als Basis oder als Referenzbeispiel verwendet/missbraucht.
 
@TurboV6: Ah, okay. Bin eher der Datenbankhans und ärger mich eben mit SQL in seinen Variationen rum. Finde von denen T-SQL aber wirklich eine der netteren.
 
@RalphS: ADO abstrahiert alles. Es arbeitet auch mit Oracle, postgreSQL oder mysql: mit allem die einen ADO Provider bereitstellen. Abbau der Abhaengigkeiten.
Und man kann einen DB-Spezi das Schema erstellen lassen ohne, dass der Entwickler integriert sein oder Fachwissen haben muss.
Man muss aber wissen wie es funktioniert, sonst baut man sich sein Grab. Stichwort Materialisierung.
 
@TurboV6: Aha, also mehr oder weniger vollständig gekapselt. Na, wie gesagt, ich habs nicht so mit ADO -wenn man damit mehr oder weniger alles an der DB machen kann, obwohl man kein SQL kann, ist das doch prima. :o) Bloß, ehrlich gesagt kann ich es mir kaum vorstellen. "Kommandozeile", ie Direktzugriff, ist mE immer mächtiger als irgendwas Vorgekapseltes. Allerdings hast Du natürlich Recht: SQL heutzutage heißt MS-SQL, DB2, Oracle-SQL, MySQL (mglw inzwischen mit Abweichungen zu MariaDB, keine Ahnung), Postgres... Entwicklerhorror pur, keine Frage.
 
@RalphS: naja es gibt eben von MS abstrakte Basis-Klassen von denen andere Hersteller nachher erben koennen bzw. Ihre Innerein implementieren koennen.
Dadurch arbeitet der Entwickler nur noch mit Objekten und kann auch Abfragen auf Objekte oder auf Collections jagen (Stichwort Linq) und die entsprechenden Implementierungen jagen den Befehl optimiert auf das jeweilige DBMS.
Im seltenen optimalen Fall quasi null overhead. Ich selbst halt von sql nichts mehr und verwende bei allen nicht-acid- Anforderungen nur noch nosql.
 
@TurboV6: *lach* Und ich halt NoSQL für die größte Schandtat, seit es Datenbanken gibt. Ist natürlich eine Frage des Anwendungsgebietes... meins ist es gottseidank nicht. ;o) Nein, ich bin mit RDBMS durchaus zufrieden und RDBMS heißt SQL (auch wenn ich die OO-Ansätze von Postgres durchaus interessant finde).
 
@RalphS: naja bin wie weiter oben gesagt eben Entwickler/Consultant fuer .NET Webbereiche und hab mich auf hoch-performante und -verfuegbare Systeme auf .NET Basis spezialisiert. Und an NoSQL komm im BigData Business keine andere Technologie ran, ausser der Kunde hat nen paar Millionen, die er unbedingt als Gewinnausgleich noch ausgeben muss. Ausnahme ist eben ACID.
Wenn SQL dann verwend ich MSSQL (yay!) oder bei zwei Kunden (leider) Oracle ;)
 
@TurboV6: Na, dann kennst ja die Eigenheiten von MySQL - Dinge-die-eigentlich-nicht-gehen-dürften-aber-trotzdem-tun sodaß man mit Pech inkonsistente Daten hat. Ich sag nur GROUP BY. :D Ich persönlich bin Backender... Frontend mach ich nur wenn ich muß, und dann sehen die aber auch so aus. ;o) Oracle ist okay, wenn man sich nicht mit der GUI rumschlagen muß - Graus :( --- dann braucht man doch wieder SQL, und Oracle ist da doch etwas.... eigen. :)
 
@RalphS: mysql Auftraege nehm ich nur an, wenn es um Portierungen auf mssql/nosql geht. Ansonsten lehn ich ab :D
 
meine Sprache des Jahres 2013 war ganz klar LSL ... und natürlich BASIC - in Dialekten der alten 8-Bitter
 
@Der_da: http://de.wikipedia.org/wiki/Linden_Scripting_Language Reden wir hiervon? :D
 
@Knerd: ja
 
Musste als ich den Titel gesehen hatte erst an PL/SQL denken, puh!
 
Also ich bin - privat wie auf der Arbeit - ein Java-Fan. Leider hat Oracle die Sprache spürbar negativ beeinflusst - aber trotzdem mag ich sie (bislang jedenfalls). Außerdem gefällt mir C# sehr, da es sehr ähnlich aber näher an Windows dran ist. Dabei gefallen mir aber die XAML und WPF Geschichten kaum bis gar nicht. Ansonsten nutze ich noch bash und awk - damit lässt es sich gut in Linux skripten.
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles