Programmierung am PC welche Sprache

Man sollte definitiv Brainfuck benutzen.

Oder aber man wägt es für die jeweilige Anwendung ab. C# ist für viele 
Anwendungen gut geeignet, allerdings weniger wenn du zum Beispiel eine 
Treiberkomponente brauchst.

Ich empfehle die nutzung OS spezifischer features zu vermeiden, es ist 
unnötigt und macht den code fast unportierbar.

Fange zunächst simpel an, ich empfehe C und Consolenanwendungen. Dabei 
kann man grundlagen wie Speicherverwaltung und lebensdauer von 
Variablen, Pointer und Pointerarithmetik, und das aufbauen von 
Datenstrukturen lernen. Dann kennst du bereits eine Compiler basierte 
Sprache mit statischer Typisierung. Lerne danach Java, die Sprache 
zwingt förmlich zur Objektorientierung, und Dinge wie Pointer und 
Speicherverwaltung werden vor einem verborgen, indem alles eine Referenz 
auf Objekte ist welche von einem Garbage collector verwaltet werden. 
Java ist am ehesten eine Compreter sprache mit statischer Typisierung. 
Lerne danach Python, eine scriptsprache, dynamisches typensystem. Danach 
gest du wieder zu C, aber verwendest das Wissen zu OOP. Vergiss C#, C++, 
etc. das sind nur Berge von wahllos angehäuften Sprachfeatures, es 
dauert ewig bis man alle kennt, und das schwierigste ist herauszufinden, 
welches man verwenden sollte.

PS: Desktopanwendung ist eine Untermenge von Anwendung, falls du nicht 
ersteres gemeint haben sollte.

Wenn es etwas mit GUI sein soll und nur Windows als OS gewünscht ist, 
dann C#, ansonsten C++ mit QT für plattformübergreifende Programme. 
Braucht man keine GUI, dann sind meine Favoriten Python, Go oder Rust. 
In der Reihenfolge von einfach nach komplex und von langsam nach 
schnell.

Daniel A. schrieb:
> C und Consolenanwendungen...grundlagen wie Speicherverwaltung
> und lebensdauer von Variablen, Pointer und Pointerarithmetik, lernen.

Daniel A. schrieb:
> danach Java, ..... und Dinge wie Pointer und
> Speicherverwaltung werden vor einem verborgen,

Siehst du da nicht auch einen Widerspruch?

me schrieb:

> Auf welches Pferd sollte man setzen.

Es kommt darauf an, was Du für Anwendungen schreiben möchtest.

Reinhard #. schrieb:
> Daniel A. schrieb:
>> C und Consolenanwendungen...grundlagen wie Speicherverwaltung
>> und lebensdauer von Variablen, Pointer und Pointerarithmetik, lernen.
>
> Daniel A. schrieb:
>> danach Java, ..... und Dinge wie Pointer und
>> Speicherverwaltung werden vor einem verborgen,
>
> Siehst du da nicht auch einen Widerspruch?

Nein, unterschiedliche Sprachen haben unterschiedliche Sprachfeatures 
und Eigenschaften, es ist gut möglichst unterschiedliche zu kennen. Also 
solche mit und solche ohne Speicherverwaltung, solche mit und solche 
ohne statische Typisierung, solche die Compiliert werden und solche die 
Interpretiert werden. Es geht darum unterschiedliche Konzepte 
kennenzulernen. Und C empfehle ich für den Anfang deshalb, weil der 
umstieg von Speicher selber verwalten zu Garbage collector einfacher ist 
als umgekehrt. Wenn ich es mir recht überlege fehlt bei den Sprachen 
noch eine rein Funktionale. Auch wenn verschiedene Spachen auf 
unterschiedlichen Konzepten und Ideen aufbauen, kann man das wissen 
häufig auf die jeweils anderen Sprachen übertragen. So kann man z.B. 
auch in C funktional oder OOP-Artig Programieren, aber man muss die 
Ideen und Konzepte dahinter verstehen um zu wissen wann das Sinnvoll ist 
anzuwenden. Ein guter Programmierer kann auf ein aktuelles Problem 
sämtliche vergangene Erfahrungen anwenden, selbst wenn diese damit nicht 
viel zutun zu haben scheinen, aber dafür muss man erst unterschiedliche 
Erfahrungen sammeln.

Daniel A. schrieb:
> Ich empfehle die nutzung OS spezifischer features zu vermeiden, es
> ist
> unnötigt und macht den code fast unportierbar.

Wohin willst du denn was portieren?

"PC" meint Windows. Da gibt nichts anderes.
Wäre Linux gemeint, hätte der TO nicht gefragt, und ein Mac ist kein PC.

Oliver

Von Java habe ich wahnsinns Kopfschmerzen bekommen :-)

Da hängt einfach zuviel Scheiss hinter jedem Punkt und Wort im Programm. 
Man bräuchte ein sehr tiefes und mehrschichtiges, auch präzises 
Textgedächtnis das die verketteten Objekt-Teile virtualisieren kann.

Oliver S. schrieb:
> Daniel A. schrieb:
>> Ich empfehle die nutzung OS spezifischer features zu vermeiden, es
>> ist
>> unnötigt und macht den code fast unportierbar.
>
> Wohin willst du denn was portieren?

Es gibt auch noch Dinge außerhalb der Microsoft-Welt.

> "PC" meint Windows. Da gibt nichts anderes.

Ja, nee, klar.

> Wäre Linux gemeint, hätte der TO nicht gefragt, und ein Mac ist kein PC.

Welches System er programmieren will, hat er explizit geschrieben. Dazu 
muss man nicht mutmaßen, sondern nur sein Posting lesen und nicht nur 
die Überschrift. Das heißt aber nicht, dass er für immer und ewig 
ausschließlich für diese Plattform programmieren wollen wird. Man kann 
sich nun auf eine Plattform einschränken, weil man aktuell sowieso 
nichts anderes will, oder man kann etwas nehmen, das einem die 
Möglichkeit offen lässt, auch mal für einen Raspi oder das 
Android-Tablet Programme schreiben zu können. Ich halte letzteres für 
die weitsichtigere Entscheidung.

Samstagsaccount schrieb im Beitrag #5116480:
> Ich esse gerne Vanilleeis, Pistazieneis schmeckt auch interessant.

<BudSpencer>Pistazie hab ich nicht!</BudSpencer>
https://www.youtube.com/watch?v=PcJkHgsYHTE

Volle22 schrieb:
> Und gesundheitliche Probleme sind in Zusammenhang mit Java sonst nicht
> bekannt. Es ist auch kein Warnhinweis drauf.

Das kommt bestimmt vom Koffein.

Rolf M. schrieb:
> Es gibt auch noch Dinge außerhalb der Microsoft-Welt.

Klar. Nur, wie war genau die Ausgangsfrage?

Oliver

me schrieb:
> Welche Sprache C++, C# oder sonst sollte man verwenden, wenn man, unter
> Windows Betriebssystem, Anwendungen programmieren möchte?
>
> Ich tendiere zu Visual Studio C#.
> Qt mit C++ ist auch interessant.

Das kann man beides nehmen. Die Kernfrage ist aber nicht, unter 
welchem Betriebssystem Du programmieren willst, sondern für welches. 
Wenn Deine Anwendung eine GUI haben und einfach auf andere Systeme wie 
MacOS oder Linux portierbar sein soll, dann sind C++ und Qt sicher die 
bessere Wahl. Wenn Du hingegen ausschließlich für Windows entwickeln und 
bereits heute komplett ausschließen kannst, daß Du Deine Anwendungen in 
ein paar Jahren auch unter MacOS oder Linux nutzen oder anbieten 
möchtest, ist C# ebenso gut und zweifellos besser ins Windows-Ökosystem 
integriert.

Solche Fragen der Zielplattform und der Portierbarkeit sind dabei kaum 
zu unterschätzen. Mir ist im Laufe der Jahre mehr als ein Entwickler 
über den Weg gelaufen, der sich ein Loch in den Bauch geärgert hat, weil 
er seine Software für eine bestimmte Zielplattform entwickelt hatte und 
sie später auf einer anderen Zielplattform nutzen wollte. Da ist es viel 
angenehmer und weniger aufwändig, von vorneherein plattformunabhängig zu 
entwickeln, als nachträglich einen vorhandenen Quellcode zu portieren -- 
womöglich gar einen Quellcode in einer Sprache, die auf der neuen 
Zielplattform nicht oder lediglich teilweise verfügbar ist.

Ansonsten muß es heutzutage nicht mehr unbedingt eine kompilierte 
Sprache sein. Mit einer modernen Skriptsprache wie Python oder Ruby 
lassen sich plattformunabhängige GUI-Programme erstellen, die auch auf 
10 Jahre alten Rechnern problemlos und meistens so flüssig laufen, daß 
kein Anwender den Unterschied zu einem kompilierten Programm bemerkt. 
Nur bei umfangreichen Berechnungen oder Datenmengen kommen solche 
Programme noch an Grenzen -- solche Berechnungen oder Datenmengen können 
dabei allerdings einfach in nativ kompilierte Module ausgelagert werden.

Eine andere Alternative, die zunehmend Verbreitung findet, sind 
Programme mit einer Weboberfläche. Auch die lassen sich wunderbar mit 
einer modernen Skriptsprache entwickeln und haben den Vorteil, daß sie 
bei Bedarf schnell an das Netzwerk angebunden und darüber bedient werden 
können. Um die Zahl der benötigten Sprachen zu begrenzen, können dazu 
serverseitig Node.js und ECMAScript verwendet werden, aber es geht da 
auch jede andere Sprache.

Du siehst: Du hast die Qual der Wahl, eine Möglichkeit ist genauso gut 
oder schlecht wie jede andere. Ich persönlich würde dabei weniger Wert 
darauf legen, welche Sprache mir dabei als besonders leicht erlernbar 
erscheint oder die gefälligsten Werkzeuge bietet, sondern primär darüber 
nachdenken, wieviel Lern- und Entwicklungsaufwand ich investieren will 
(da haben die Skriptsprachen klare Vorteile), und wie und auf 
welche{r,n} Plattform(en) meine Software in ein paar Jahren genutzt 
werden soll.

HTH, YMMV.

Beim PC-Programmieren stellt sich auch die Frage nach der grafischen 
Schnittstelle. Braucht es DirectX oder OpenGL etc. ? Dann sucht man sich 
eine Sprache wo man das einbinden kann, vor allem in der 
Entwicklungsumgebung.

Edit: mit 3D-Grafikfunktionen kann man tolle Dinge machen bzw. sie dann 
anzeigen lassen.

Sheeva P. schrieb:
> me schrieb:
>> Welche Sprache C++, C# oder sonst sollte man verwenden, wenn man, unter
>> Windows Betriebssystem, Anwendungen programmieren möchte?
>>
>> Ich tendiere zu Visual Studio C#.
>> Qt mit C++ ist auch interessant.
>
> Das kann man beides nehmen. Die Kernfrage ist aber nicht, /unter/
> welchem Betriebssystem Du programmieren willst, sondern für welches.
> Wenn Deine Anwendung eine GUI haben und einfach auf andere Systeme wie
> MacOS

oder iOS oder Android portierbar sein soll, kann man auch mit Xamarin 
arbeiten. Avalonia UI wäre eine andere, etwas experimentellere, Option 
und unterstützt dazu noch Linux
https://github.com/AvaloniaUI/Avalonia (Win, Android, Mac, iOS, Linux).
XAML wie bei WPF, UWP oder Xamarin für's UI, Rest in einer .NET-Sprache.

> Eine andere Alternative, die zunehmend Verbreitung findet, sind
> Programme mit einer Weboberfläche. Auch die lassen sich wunderbar mit
> einer modernen Skriptsprache entwickeln und haben den Vorteil, daß sie
> bei Bedarf schnell an das Netzwerk angebunden und darüber bedient werden
> können.

Brauchen dann einen Browser und erhöhen damit die Angriffsoberfläche der 
Anwendung...

> Um die Zahl der benötigten Sprachen zu begrenzen, können dazu
> serverseitig Node.js und ECMAScript verwendet werden, aber es geht da
> auch jede andere Sprache.
>
> Du siehst: Du hast die Qual der Wahl, eine Möglichkeit ist genauso gut
> oder schlecht wie jede andere. Ich persönlich würde dabei weniger Wert
> darauf legen, welche Sprache mir dabei als besonders leicht erlernbar
> erscheint oder die gefälligsten Werkzeuge bietet, sondern primär darüber
> nachdenken, wieviel Lern- und Entwicklungsaufwand ich investieren will
> (da haben die Skriptsprachen klare Vorteile),

(Welche) Vorteile gegenüber was?
"Skript"-Sprachen sind mittlerweile recht erwachsen und komplex geworden 
(oder haben verbesserte Ableger), zudem schlägt man sich zunehmend eher 
mit div. Frameworks/Libraries etc. herum, die man mittlerweile benötigt, 
wenn man auch mal fertig werden und nicht alle Räder neu erfinden 
will...

Oliver S. schrieb:
> Rolf M. schrieb:
>> Es gibt auch noch Dinge außerhalb der Microsoft-Welt.
>
> Klar. Nur, wie war genau die Ausgangsfrage?

Mein Posting nicht gelesen, oder nur nicht verstanden?

Rolf M. schrieb:

> Mein Posting nicht gelesen, oder nur nicht verstanden?

Hallo,

kannst Du das bitte noch mal als Video posten ?

Duck und wech :-)

Michael

Im Grunde genommen ist das völlig egal.

Programmieren ist nicht das Beherrschen von C++, C#, Java oder sonst 
einer Sprache.
Programmieren ist die Kunst, logisch zu denken und die Aufgabenstellung 
angemessen abstrahieren zu können.

Verglichen mit der gesprochenen Sprache muss man erst das Sprechen 
lernen (Lauterzeugung) und kann dann erst eine Sprache 
(Grammatik/Vokabeln) lernen.
Welche da dann für dich am besten geeignet ist, ist abhängig davon, 
wohin es dich zieht.

C++ / Java sind wohl vergleichbar mit Englisch/Spanisch. Weit verbreitet 
und relativ universell. Trotzdem gibt es Bereiche, in denen man damit 
nicht wirklich weit kommt (z.B. in China oder Russland) und eine andere 
Sprache sinnvoller wäre.

Ich würde mich an deiner Stelle an C# orientieren, dein Ziel ist ja 
Primär Software für Windows.
Damit hast du Erfolge und kannst das Programmieren (im Sinne der 
Lauterzeugung) lernen.

Eine weiter Sprache zu lernen ist nur* eine Änderung der Syntax. (im 
Sinne der Grammatik/Vokabeln)
Die Grundprinzipien bzw. Grundstrukturen sind letztlich bei allen 
Sprachen ähnlich. (im Sinne der Lauterzeugung)


* natürlich stark verharmlost

Rolf M. schrieb:
> Oliver S. schrieb:
>> Rolf M. schrieb:
>>> Es gibt auch noch Dinge außerhalb der Microsoft-Welt.
>>
>> Klar. Nur, wie war genau die Ausgangsfrage?
>
> Mein Posting nicht gelesen, oder nur nicht verstanden?

Gelesen und verstanden. Was nichts dran ändert, das die Argumentation 
irrelevant ist.

Programmieren für PC unter Windows ist 99% Benutzeroberfläche, und 1% 
sonstige Funktionalität. Da wird im Falle eines Falles nichts portiert, 
sondern schlicht neu geschrieben.

Oliver

Hallo,

ich glaube man sollte hier erwähnen, dass unter Windows die Sprachen 
C++, C# und VB.net auf die gleichen dot.net Bibliotheken zugreifen und 
somit der gleiche Funktionsumfang zur Verfügung steht. Nur die Syntax 
variiert.

Gleichzeitig ist das alles sehr Windows-spezifisch, d.h. es gibt kaum 
weitere Plattformen, wo das ohne wesentliche Anpassungen läuft.

Trotzdem gibt es selten die Möglichkeit der freien Wahl, vor allem, wenn 
mehrere zusammen an Projekten arbeiten sollen, da sollte die Sprache so 
gewählt werden, dass die Mehrheit der Mitarbeiter genug Erfahrung hat, 
um die Projekte zu stemmen.

Gruß,
Michael

Ziemliche Anfängerfrage aber warum scheint Python eher nicht für 
GUI-Programme verwendet zu werden? Ist das historisch begründet oder 
gibt es Eigenschaften, die Python eher ungeeignet machen?

Python ist sehr nett für kleinere Skripte zum Automatisieren 
wiederkehrender Aufgaben.
Deutlich mehr Komfort als die guten alten Shellskripte.

Aber ein wirklich großes Projekt mit GUI und allem drum und dran würd 
ich damit jetzt nicht umsetzen wollen. Been there, done that.
Bzw: stopped that. Hat aus mehreren Gründen nicht wirklich Spaß gemacht.

Michael A. schrieb:
> Hallo,
>
> ich glaube man sollte hier erwähnen, dass unter Windows die Sprachen
> C++, C# und VB.net auf die gleichen dot.net Bibliotheken zugreifen und
> somit der gleiche Funktionsumfang zur Verfügung steht. Nur die Syntax
> variiert.
>
> Gleichzeitig ist das alles sehr Windows-spezifisch, d.h. es gibt kaum
> weitere Plattformen, wo das ohne wesentliche Anpassungen läuft.

Siehe oben... Xamarin, wenn neben Windows-Desktop auch Android, iOS, 
macOS unterstützt werden soll.
Z.B. Avalonia wenn daneben noch Linux mit .NET-Core unterstützt werden 
soll. .NET-Core wird offiziell auf Windows, macOS und div. 
Linux-Distributionen unterstützt
https://github.com/dotnet/core/blob/master/release-notes/2.0/2.0-supported-os.md
(für Arch gibt's natürlich auch ein AUR)
C++ und Windows: Wer mag kann dort immer noch direkt gegen das 
Win32-APIs programmieren oder die MFC nutzen oder Qt oder irgendwas 
anderes ohne .NET nehmen. Zusätzlich geht aber auch Windows Runtime 
(WinRT C++/CX) oder .NET (C++/CLI). Allerdings: .NET-Core unterstützt 
z.Z. kein C++

David G. schrieb:
> Ziemliche Anfängerfrage aber warum scheint Python eher nicht für
> GUI-Programme verwendet zu werden? Ist das historisch begründet oder
> gibt es Eigenschaften, die Python eher ungeeignet machen?

Python wird für eine ganze Reihe von GUI-Programmen verwendet, auch für 
mittlere und große Projekte. Eine kleine Auswahl findest Du hier: [1].

[1] https://en.wikipedia.org/wiki/List_of_Python_software

Le X. schrieb:
> Aber ein wirklich großes Projekt mit GUI und allem drum und dran würd
> ich damit jetzt nicht umsetzen wollen. Been there, done that.
> Bzw: stopped that. Hat aus mehreren Gründen nicht wirklich Spaß gemacht.

Da mir das immer noch Spaß macht, würde ich mich freuen, mehr über Deine 
Gründe zu lesen. Danke.

Sheeva P. schrieb:
> Da mir das immer noch Spaß macht, würde ich mich freuen, mehr über Deine
> Gründe zu lesen. Danke.

Es gab vor einiger Zeit irgendwo hier einen dicken Python-Thread in dem 
die Vor- und Nachteile von einigen Usern, darunter auch hochgeschätzte 
Mods, zu Genüge durchgekaut wurden.
Wenn mich nicht alles täuscht warst du da auch involviert.
Keinen Bedarf dass alles nochmal neu auszufechten.

Sagen wir so, es kommt viel zusammen warum ich damit, abseits von 
kleinen Skripten, nicht warm wurde.

Georg schrieb:
> David G. schrieb:
>> Ziemliche Anfängerfrage aber warum scheint Python eher nicht für
>> GUI-Programme verwendet zu werden?
>
> Phyton hat den Nachteil, dass erst mal Phyton (der Interpreter)

Entschuldige, aber es heißt Python. Wie in "Monty Python" (danach ist 
die Sprache benannt) oder der Schlange, die das Logo der Sprache ziert.

> auf dem
> System installiert werden muss - aber das gilt für viele andere, v.a.
> interpretierte Sprachen genauso, etwa Basic oder Java. Wenn man also
> möchte, dass das jeder DAU zum Laufen bekommt, sollte man eine
> Installationssoftware mitliefern, die bei Bedarf auch Phyton
> installiert. Einfacher ist es natürlich, wenn man nur eine einfache EXE
> liefert, die auf anklicken läuft, aber das geht heute nur noch bei
> wenigen Sprachen.

Ja, und eine davon ist Python. Mit py2exe kann man seine Python-Software 
zusammen mit dem Interpreter in eine .exe-Datei einpacken, die sofort 
und ohne weitere Voraussetzungen läuft. Dasselbe für MacOS/X mit py2app. 
Mit cx_freeze und PyInstaller lassen sich Standalone-Executables für 
mehrere Plattformen erzeugen, natürlich auch für Windows und MacOS/X. 
Zudem gibt es nuitka, das Python-Code in portablen, nativen C++-Code 
übersetzt, und noch ein ähnliches Projekt, dessen Namen ich aber leider 
vergessen habe.

Georg schrieb:
> Einfacher ist es natürlich, wenn man nur eine einfache EXE
> liefert, die auf anklicken läuft, aber das geht heute nur noch bei
> wenigen Sprachen.

Das geht auch mit "Pure-Basic". Für mich ist das wie gemacht. Man kann 
Kommandozeilen Programme oder auch welche mit grafischer Oberfläche 
schreiben. Es gibt eine gute Hilfedatei mit Beispielen, es gibt diverse 
Foren dafür und man kann die Programme auch für Linux lauffähig 
übersetzen.

Vor Allem sind die Quelltexte frei von Zeichensalat und damit keine 
Quelle von Extrem-Fehlersuching



-Feldkurat-

Feldkurat K. schrieb:
> Das geht auch mit "Pure-Basic". Für mich ist das wie gemacht. Man kann

Haha, so ein Zufall. Der zufällig mit dir in einem Haushalt lebende Paul 
mag auch Basic! Paul, du machst dich echt lächerlich... Und bevor du 
wieder fragt, was ich von dir will: Ich erwarte eigentlich nur, dass 
Erwachsene Leute nicht so ein Theater spielen.

Georg schrieb:
> Arc N. schrieb:
>> wenn neben Windows-Desktop auch Android, iOS,
>> macOS unterstützt werden soll
>
> Alternativ eine Website erstellen mit JScript, ev auch PHP, Phyton und
> was es noch so gibt.

Html/JS lokal, Sciter 1) oder von mir aus CEF oder Electron könnte man 
ja noch verstehen, aber Client und Server?

> Dann braucht man nur einen Browser, v.a. bei
> JScript, und damit läuft das gewünschte auf allen Systemen, für die es
> einen HTML-Browser gibt, das sind auch völlig exotische wie alte
> Unix-Systeme oder IBM Grossrechner usw. usw., und das alles ohne
> zusätzlichen Aufwand wie neu compilieren.

und die im Falle von Client/Server dann auch den Vorteil der (wie oben 
schon mal geschrieben) deutlich größeren Angriffsoberfläche mit dem 
Vorteil des erhöhten Ressourcenbedarfs verbinden.

1) https://sciter.com/

O.T.
Da D. schrieb:
> Haha, so ein Zufall. Der zufällig mit dir in einem Haushalt lebende Paul
> mag auch Basic! Paul, du machst dich echt lächerlich... Und bevor du
> wieder fragt, was ich von dir will: Ich erwarte eigentlich nur, dass
> Erwachsene Leute nicht so ein Theater spielen.

Eigentlich geht Dich das gar nichts an -aber einem so neugierigen Patron
muß ich dann doch mal ein Licht anzünden.

Pass gut auf: Paul hat seinen eigenen Haushalt. Wir haben lediglich eine 
gemeinsame Bastelbude, weil wir dort unsere Elektrowerkzeuge, Meßgeräte 
etc. zusammen"geschmissen" haben.

Wenn Du etwas zum eigentlichen Thema zu sagen hast, dann sag es. 
Ansonsten: versuche mir aus dem Weg zu gehen!

-Feldkurat-

Feldkurat K. schrieb:
> Pass gut auf: Paul hat seinen eigenen Haushalt. Wir haben lediglich eine
> gemeinsame Bastelbude, weil wir dort unsere Elektrowerkzeuge, Meßgeräte
> etc. zusammen"geschmissen" haben.

Lol.

Beobachter schrieb:
> Das ist jetzt aber nur die halbe Wahrheit! Einer der Mods hat vor kurzem
> mal durchblicken lassen, dass Feldkurat/Paul B. auch vom gleichen PC
> aus posten.


Nicht einer der Moderatoren hat "durchblicken" lassen. Von mir kam die 
Erklärung des Rätsels. Such selbst danach -mir ist das zu viel.

-Feldkurat-

Arc N. schrieb:
> und die im Falle von Client/Server dann auch den Vorteil der (wie oben
> schon mal geschrieben) deutlich größeren Angriffsoberfläche

Und wenn Du es noch hundertmal schreibst, bleibt es trotzdem Unfug.

Oliver S. schrieb:
>> Mein Posting nicht gelesen, oder nur nicht verstanden?
>
> Gelesen und verstanden. Was nichts dran ändert, das die Argumentation
> irrelevant ist.

Das sehe ich - wie schon geschrieben - anders.

> Programmieren für PC unter Windows ist 99% Benutzeroberfläche, und 1%
> sonstige Funktionalität. Da wird im Falle eines Falles nichts portiert,
> sondern schlicht neu geschrieben.

Wenn man eben gleich was portables gewählt hat, muss man gar nicht neu 
schreiben. Aber auch wenn man was neu schreibt, ist es einfacher, wenn 
man dazu die gleiche Sprache und die gleiche API nutzen kann, statt das 
alles neu lernen zu müssen.

Sheeva P. schrieb:
> Arc N. schrieb:
>> und die im Falle von Client/Server dann auch den Vorteil der (wie oben
>> schon mal geschrieben) deutlich größeren Angriffsoberfläche
>
> Und wenn Du es noch hundertmal schreibst, bleibt es trotzdem Unfug.

Nur kurz zur Verdeutlichung:
Client = Browser, HTML+JS+irgendwelche Libraries
Server = PHP + Libraries

Dann gehen die Daten grob folgenden Weg:
User-Input im Browser -> Client-OS -> Libs -> Browser -> Libs -> 
Anwendung macht was und es geht zum Server
Anwendung -> Libs -> Browser -> Libs -> Client-OS -> Netzwerk -> Server
im Server
Server-OS -> Libs -> PHP -> Libs -> Serveranwendung und der Spaß geht 
wieder zurück
Serveranwendung -> Libs -> PHP -> Libs -> Server-OS -> Netzwerk und 
wieder wie oben
Client-OS -> Libs -> Browser -> Libs -> Anwendung

Klassische Desktopanwendung:
User-Input in der Anwendung -> Client-OS -> Libs -> Anwendung macht was 
und es geht über Libs zum OS und über die Libs zur Anwendung zurück

Quizfrage: Wo kann mehr schief gehen...

JScript bezeichnet ausschliesslich eine schlechte Programmiersprache von 
Microsoft, die aus einer sehr frühen Version von JavaScript hervor ging. 
Bitte schreibt JavaScript oder ECMAScript wenn ihr dasselbige meint, und 
nicht JScript.

Georg schrieb:
> Arc N. schrieb:
>> Dann gehen die Daten grob folgenden Weg:
>
> Wenn man das unbedingt so haben will, schon, aber das muss ja nicht
> sein. Man kann durchaus eine HTML-Datei mit JScript-Funktionen
> schreiben, die keine Server-Funktionalität aufruft und auch direkt von
> der lokalen Festplatte gestartet werden kann. Will man eine
> 1-Datei-Anwendung erstellen, zwingt einen auch niemand zur Verwendung
> von CSS.

Deshalb hatte ich weiter oben schon mal geschrieben: "Html/JS lokal, 
Sciter 1) oder von mir aus CEF oder Electron könnte man ja noch 
verstehen, aber Client und Server?"

> Das ist überhaupt die schlankste Form von Anwendung, man braucht nur
> einen Browser, OS ist egal.

Browser würde ich nicht unbedingt als schlank bezeichnen ;)
UXSS (Universal Cross-Site Scripting) ist auch ein nettes Problem, dass 
es nur im Browser gibt

Duennwandiger Troll schrieb:
> Vergiss das Portieren. Von Windows auf ein windows phone ?

Nee, von PC-Windows auf Smartphone-Android. Einfach neu kompilieren, und 
ab in den App-Store damit ;)

Oliver

Arc N. schrieb:
> Browser würde ich nicht unbedingt als schlank bezeichnen ;)

Die aktuellen Versionen des .NjET-Framework haben einen Umfang von etwa 
4,5 Gigabyte. Zum Vergleich hat ein aktueller Firefox vielleicht 100 
MB...

> UXSS (Universal Cross-Site Scripting) ist auch ein nettes Problem, dass
> es nur im Browser gibt

CSRF, XSS und UXSS sind in jeder Software ein Problem, wenn sie eine 
aktive Komponente benutzt. Ob ich dabei die WebBrowser-Klasse von .NET, 
WebKit aus Qt oder einen nativen Webbrowser benutze, spielt keine Rolle.

Ist schon so aber was ist so problematisch daran? Du kannst dich in 
jeder Sprache verschreiben. Deswegen gibt es ja IDEs die autocomplete 
haben und dir die Objektumgebung zeigen
Zudem sagt dir Python ganz genau wo eine Variable nicht definiert wurde 
und dann siehst du für gewöhnlich eh direkt wenn du dich verschrieben 
hast.
Oder sehe ich da irgendetwas nicht?

David G. schrieb:
> Zudem sagt dir Python ganz genau wo eine Variable nicht definiert wurde

Wenn du versuchst, eine Variable zu lesen:

1

>>> a = 42

2

>>> b = a

3

>>> b = aa

4

Traceback (most recent call last):

5

  File "<stdin>", line 1, in <module>

6

NameError: name 'aa' is not defined

> Oder sehe ich da irgendetwas nicht?

Eine falsche Zuweisung kann verlorengehen:

1

>>> bb = 23

2

>>> print(b)

3

42

Clemens L. schrieb:

> Eine falsche Zuweisung kann verlorengehen:
>

1

>>> bb = 23

2

>>>> print(b)

3

> 42

Ah ok stimmt! Daran habe ich nicht gedacht.

David G. schrieb:
> Clemens L. schrieb:
>
>> Eine falsche Zuweisung kann verlorengehen:
>>

1

>>> bb = 23

2

>>>>> print(b)

3

>> 42

>
> Ah ok stimmt! Daran habe ich nicht gedacht.

Deswegen nimmt man einen ordentlichen Editor und natürlich pylint(1). 
;-)