Entwicklungsumgebung für Anwendungsentwicklung, empfehlung

Auch wenn du nicht plattformübergreifend programmieren willst, so hat 
man doch einige Vorteile, wenn man ein Tool nimmt, welches das 
ermöglicht. Einer ist, dass man dann später nicht umlernen muss.

Ich kenne dafür Qt. Gibt viele Tutorials und lässt sich unter Win wie 
auch unter Linux (und vermutlich Mac OS) nutzen. Der Code ist C++ 
(soweit ich das beurteilen kann) und eine GUI kann man gleich 
miterstellen.

Bei Visual Studio geht das bei C++ nicht so. Die GUI muss separat gebaut 
werden.

Wenns eh nur unter Windows laufen soll, ist Visual Studio dein Freund. 
Vielleicht schaust du dir da mal C# an.

Ansonsten kann ich auch Qt (C++) mit dem Qt Creator als IDE empfehlen. 
(Compiler kannst du dir da aussuchen, ob das der GCC sein soll, oder 
Visual Studio Compiler)
Python ist auch super und dafür gibt es auch Qt, nennt sich dann PyQt. 
Zugriff auf die serielle Schnittstelle gibt es in Python mit dem Modul 
PySerial.

Für Qt gibt es viele Tutorials, und es bringt auch sehr viele Beispiele 
mit.

Python kann man auch als exe verpacken, so dass dein Kunde kein Python 
installiert haben muss. Dazu gibt es verschiedene Programme, die das 
machen: cx_freeze, Py2Exe oder PyInstaller

Tja, da gibt es eben einen Widerspruch. Einerseits springt einem bei den 
genannten Anforderungen der Gedanke an Visual Studio und C# (Parallelen 
zu Java) natürlich mit dem Popo ins Gesicht, andererseits steht dem das 
hier

> und man nicht erst aufwändig auf dem Zielsystem irgendetwas installieren
> muss

evtl. (aus deiner Perspektive) entgegen. Von irgendwelchen 
Portable-Wrappern würde ich Abstand halten, die sehe ich als absoluten 
Notnagel an. Java kannst du dann schonmal vergessen (*). Eine halbwegs 
aktuelle Version des .NET-Frameworks dürfte auf deutlich mehr 
Windows-Systemen vorhanden sein als eine aktuelle JRE (und die 
Installation ist alles andere als aufwendig; dazu sind die neueren 
Versionen In-Place-Upgrades).

C++ und Qt verwende ich selbst und empfehle es (vielleicht darum? ;)) 
auch relativ häufig, aber hier ... C++ und Qt von Grund auf lernen - 
und dann noch gleich ein vernünftiges Produkt erstellen wollen? Ob das 
eine so gute Idee ist?

> dem Kunden zuliebe

Ich bezweifle ein wenig, dass die Sache mit der Installation eine so 
hohe Priorität hat. Man sollte dem Kunden (und dir) zuliebe eher auf die 
Softwarequalität schauen und Werkzeuge, mit denen du dir in deiner 
Situation diesbezüglich nicht selbst Steine in den Weg legst (z.B. durch 
die Komplexität von C++/Qt oder den Versuch, mit Java eine nicht-Bäh-GUI 
hinzubekommen).

Schau' dir doch mal das hier an (ich habe allerdings keine persönliche 
Erfahrung damit):
http://www.lazarus-ide.org/

(*) Die Sprache ist ganz ok und es gibt mit IntelliJ IDEA auch eine 
vernünftige IDE, aber ich verstehe trotzdem nicht ganz, wie du in diesem 
Fall ausgerechnet auf Java kommst.

Hallo Tom,

Tom schrieb:
> Ich möchte für mein Projekt eine PC Software schreiben, um das Gerät zu
> parametrieren und auszulesen.
>
> Nun bin ich am überlegen, ob ich Microsoft Visual Studio in der
> kostenfreien Variante nehme, oder Eclipse oder Netbeans. Oder doch etwas
> anderes?

Im Prinzip können sie alle dasselbe. Such Dir einfach eine aus und lern 
wie man sie bedient.

Ich persönlich würde grundsätzlich immer zu einem Produkt greifen, das 
nicht auf bestimmte Sprachen oder bestimmte Betriebssysteme festgelegt 
ist. Denn schließlich ist eine IDE meistens eine ziemlich umfangreiche 
Veranstaltung mit einer gewissen Lernkurve, und diese jedesmal zu 
wiederholen, nur um in einer anderen Sprache oder für ein anderes 
Betriebssystem zu entwickeln, scheint mir nicht die klügste Idee zu 
sein.

Aber letztlich kommt es nicht auf die IDE an, sondern darauf, wie gut Du 
mit ihr umgehen kannst. Und das liegt letztlich sowieso nur an Dir.

Liebe Grüße,
Karl

Mehmet K. schrieb:
> Mathias O. schrieb:
>> Ich empfehle auch Qt Creator. (...) Und als static kannste auch
>> kompilieren. Dann ist die Anwendung standalone. Und du musst nicht die
>> ganzen Dlls bereitstellen.
>
> Ich dachte, dafür sei eine Lizenz nötig, bei der man ein paar Scheine
> hinblaettern müsse. Oder habe ich da was falsch verstanden?
Alternativ kann er sein Projekt unter LGPL veröffentlichen, dann darf er 
auch kostenlos statisch linken.

Im Übrigen würde ich aber auch Qt empfehlen.

Hallo Bernd,

Bernd K. schrieb:
> Ein Wort: Lazarus.

Rette sich wer kann, die Missionare sind los!

Nein, im Ernst: welchen Teil von "Ich möchte in C++ oder Java 
programmieren" hast Du nicht verstanden? Und dem Hobbyisten mag Dein 
Spielzeug ja reichen, hier wird aber doch wohl eine Lösung für die 
professionelle Entwicklung mit entsprechend langen Wartungs- und 
Supportfenstern nachgefragt.

Liebe Grüße,
Karl

Karl Käfer schrieb:
> Hallo Bernd,
>
> Bernd K. schrieb:
>> Ein Wort: Lazarus.
>
> Rette sich wer kann, die Missionare sind los!

Nun lass ihn doch mal ein wenig für Lazarus werben, wo das Pascal'sche 
doch im Ranking eh nur mit der Lupe zu finden ist, siehe

http://3.f.ix.de/imgs/18/1/5/4/8/3/1/3/tiobejuli15-a2dadc4d75e30d2b.png

falls man dem Tiobe-Index glauben schenken kann, wo ich mir nicht ganz 
sicher bin.

> Nein, im Ernst: welchen Teil von "Ich möchte in C++ oder Java
> programmieren" hast Du nicht verstanden?

Der TE schrieb aber auch Zitat

" Ich bin da Gedanklich noch 10 Jahre zurück,
bei Delphi und VisualBasic. "

Also hat er doch bereits Erfahrung mit Delphi und könnte darauf 
aufbauen, anstatt sich nun mit C++ herumzuquälen.

> Und dem Hobbyisten mag Dein
> Spielzeug ja reichen, hier wird aber doch wohl eine Lösung für die
> professionelle Entwicklung mit entsprechend langen Wartungs- und
> Supportfenstern nachgefragt.

Ach komm. Was soll denn dieses Bashing gegen Lazarus! Ist Embarcadero 
etwa aus deiner Sicht eine Firma für Hobbycoder oder warum haben die 
sonst ein Delhi in nunmehr bereits Version XE8 im Portfolie? Lararus mag 
da vom Ausbau her nicht heranreichen, ist doch aber in kontinuierlicher 
Entwicklung und die Foren dazu sind gut besucht, d.h. es scheint 
ordentlich Interesse an Lazarus zu geben. Das kann man nicht bei jedem 
anderen "Nischenprodukt" sagen. Beispielsweise hat die U++ IDE (ein C++ 
Derivat für Windows Entwicklung; die mal eine Zeitlang mein Interesse 
geweckt hatte) wenn man genauer hinschaut viel weniger Resonanz. Ist das 
nicht erstaunlich?

Wenn der TE aber auch Java mit ins Kalkül einbezieht, was mich etwas 
wundert nach der Äußerung hier, Zitat

" Wichtig wäre mir, dass das Programm möglichst "Standalone" als 
"Portable
EXE" läuft und man nicht erst aufwändig auf dem Zielsystem irgendetwas
installieren muss, dem Kunden zuliebe! "

dann käme eigentlich auch C# in Frage. Aber das muss der TE selber 
herausfinden.

Hallo Spannungsregler,

LM317 schrieb im Beitrag #4202463:
> Nun lass ihn doch mal ein wenig für Lazarus werben, wo das Pascal'sche
> doch im Ranking eh nur mit der Lupe zu finden ist, siehe
[...]
> Ach komm. Was soll denn dieses Bashing gegen Lazarus! Ist Embarcadero
> etwa aus deiner Sicht eine Firma für Hobbycoder oder warum haben die
> sonst ein Delhi in nunmehr bereits Version XE8 im Portfolie?

Also haben wir hier eine Programmiersprache, deren Verbreitung man 
ohnehin "mit der Lupe" suchen muß, und welche obendrein noch in zwei 
verschiedene Entwicklungsstränge zerfasert ist. Hälst Du das für eine 
gute Basis für die Neuentwicklung einer kommerziellen Software? Ich 
halte es für einen Verstoß gegen die Grundsätze ordentlicher 
Unternehmensführung.

> Der TE schrieb aber auch Zitat
>
> " Ich bin da Gedanklich noch 10 Jahre zurück,
> bei Delphi und VisualBasic. "
>
> Also hat er doch bereits Erfahrung mit Delphi und könnte darauf
> aufbauen, anstatt sich nun mit C++ herumzuquälen.

Es war, wie gesagt, nach C++ oder Java gefragt. Daß der TO sogar 
explizit seine VB- und Delphi-Erfahrungen erwähnt, weist vor allem 
darauf hin, daß er sich von diesen Umgebungen lösen möchte.

Darüber hinaus ist modernes C++, insbesondere mit einem leistungsfähigen 
Framework wie dem im Thread bereits öfter empfohlenen Qt, keineswegs 
eine Qual -- ganz im Gegenteil.

Liebe Grüße,
Karl

Karl Käfer schrieb:
> Darüber hinaus ist modernes C++, insbesondere mit einem leistungsfähigen
> Framework wie dem im Thread bereits öfter empfohlenen Qt, keineswegs
> eine Qual -- ganz im Gegenteil.

Ganz egal was man hier nimmt, ob "modernes" C++, Java, Lazarus oder 
Xojo- überall dasselbe OOP Grundkonzept mit zwar allen seinen 
Möglichkeiten, aber aber auch überbordend komplexen Sprachmitteln, 
-konzepten und -fehlermöglichkeiten. Wie hieß es im Artikel "Nachgesüßt" 
der letzten ct so schön zum Thema "Das ist neu an C#6": "... gibt 
etliche neue Sprachkonstruktionen die das Programmiererleben einfacher 
machen" Wie absurd. Fortlaufend komplizierter wirds mit wachsendem 
Umfang der Sprachen. Aber wenn man erstmal betriebsblind geworden ist...
Anwenderforderungen nach Vereinfachung (z.B. hinten nur ne .exe) sind in 
dieser Komplexitätsverherrlichung eher Störenfriede.
Hat die spezifischen Wünsche des TO nach Datenbank/Netzwerk/RS232 
Zugriff in ihrer einfachstmöglichen Realisierungsform hier schon mal 
jemand thematisiert?

Hallo Moby,

Moby schrieb:
> Fortlaufend komplizierter wirds mit wachsendem Umfang der Sprachen.

Natürlich. Aber es liegt am Computing, das zunehmend komplizierter wird; 
das schlägt sich auch im Umfang von Sprachen und Werkzeugen nieder.

> Anwenderforderungen nach Vereinfachung (z.B. hinten nur ne .exe) sind in
> dieser Komplexitätsverherrlichung eher Störenfriede.

Die Frage ist doch immer nur, was man am Anfang hinein stecken und am 
Ende heraus bekommen will.

Vor allem ist es aber nicht die Verherrlichung, sondern die Welt, die 
komplexer wird. Hyperthreading und Mehrkern-Prozessoren sind heute zum 
Standard geworden; damit müssen Programmiersprachen umgehen können.

> Hat die spezifischen Wünsche des TO nach Datenbank/Netzwerk/RS232
> Zugriff in ihrer einfachstmöglichen Realisierungsform hier schon mal
> jemand thematisiert?

Diese Wünsche wurden indirekt thematisiert, indem dem TO ein Framework 
empfohlen wurde, das alle diese Dinge integriert: Qt. [1]

Liebe Grüße,
Karl


[1]
Datenbank:  http://doc.qt.io/qt-5/sql-driver.html
Netzwerk:   http://doc.qt.io/qt-5/qtnetwork-index.html
Serialport: http://doc.qt.io/qt-5/qtserialport-index.html

Karl Käfer schrieb:
> Natürlich. Aber es liegt am Computing, das zunehmend komplizierter wird;
> das schlägt sich auch im Umfang von Sprachen und Werkzeugen nieder.

Die "Natürlichkeit" ständig weiter aufzublasender Sprachen lass ich mir 
von niemand einreden. Viele zu programmierende Grundfunktionen bleiben 
die gleichen, allen Multithreadings und Manycore zum Trotz. Das muß 
alles nicht so kompliziert umzusetzen sein. Aber vermutlich braucht es 
eben wieder innovativer Firmen und Ideen, die sich bewußt Vereinfachung 
auf die Fahnen schreiben, wie Apple mit seinem Bedienkonzept oder 
Arduino bei Embedded...

Daniel A. schrieb:
> Meine
> lieblingslösung ist es, einfach alles selbst zu schreiben.

Meine auch.

> Ob qt5 geeignet ist kann ich gerade nicht überprüfen, da ich unter
> http://www.qt.io/licensing nur "Error establishing a database
> connection" bekomme

Das muß so sein. Die Welt wird schließlich immer komplexer ;-)

Daniel A. schrieb:
> Ich würde minimalistisch bleiben. Ein Texteditor, z.B. notepad(++),
> mingw, ein makefile und eine Konsole. Da eine standalone exe benötigt
> wird, und ich C++ mag, empfehle ich dieses weiter. Mir ist es wichtig,
> keine Dateien im in den Sourcen zu haben die zwingend benötigt werden,
> aber von einer IDE abhängig sind oder nicht vollständig verstanden
> werden. Deshalb rate ich von IDEs ab.
Im Prinzip stimme ich dem durchaus zu. Und im Embedded-Bereich setze ich 
das auch 100%ig so um

Für Anwendungen auf dem PC mit GUI möchte ich aber auch in endlicher 
Zeit mal fertig werden.

Bei Qt hängt exakt garnichts von der IDE ab, das geht per Kommandozeile 
und Makefile genauso. Dafür gibt es aber Codegeneratoren (moc, uic, rcc 
und qmake). Die wiederum nehmen einem viel Arbeit ab.
Man sollte sich natürlich vorher mal hinsetzen und lernen, wieso und 
warum es diese Codegeneratoren(*) gibt. Die Zeit dazu ist aber besser 
investiert, als jedes Fensterchen händisch zusammenzuprogrammieren...

(*) Und bitte, BITTE nicht schon wieder mit libsig++ erschlagen. moc 
macht mehr als nur Signals und Slots. Und die Implementierungen in 
libsig++ und boost sind auch eher dünn.

Moby schrieb:
> Hat die spezifischen Wünsche des TO nach Datenbank/Netzwerk/RS232
> Zugriff in ihrer einfachstmöglichen Realisierungsform hier schon mal
> jemand thematisiert?

Was wäre denn jetzt dein konkreter Vorschlag (Programmiersprache, GUI, 
DB, Netzwerk, RS232)?

R. Rebentrost schrieb:
> Was wäre denn jetzt dein konkreter Vorschlag (Programmiersprache, GUI,
> DB, Netzwerk, RS232)?

Keiner. Leider.
Ich hatte hier auch nur gehofft, daß sich im dunklen verzweigten OOP 
Einheits-Gestrüpp endlich wieder mal ein Lichtblick zeigt ;-(

Warum so zaghaft?
Am besten schreibt man doch alles in ASM. Nur so hat man Zugriff auf 
alles und ist auch dauerhaft beschäftigt.
Und dann müllt man auch keine Threads zu. Einfach wegen "keine Zeit".

Bastler schrieb:
> Warum so zaghaft? Am besten schreibt man doch alles in ASM.

Nur so zur Grundorientierung: Wir sind hier bei der PC-Programmierung, 
nicht bei den kleinen uCs.
Im Zweifelsfall würde ich blanke Polemik wie die Deine auch eher unter 
Müll verbuchen, aber wenns Dir so nen Spaß macht will ich Dir den nicht 
verderben ;-)

Wer polemisiert noch mal gegen OOP, das zu GUIs so passt, wie ein Deckel 
zum Topf?

Bastler schrieb:
> Wer polemisiert noch mal gegen OOP, das zu GUIs so passt

Da hast Du Recht. GUIs passen zu OOP.
Schon beim ersten Start von VS war ich echt begeistert, wie einfach und 
intuitiv sich endlich GUIs gestalten ließen. Auch die Zuweisung von 
Eigenschaften ist genial. Sobald es um die eigentliche, oft nur simple 
Funktionalität geht versinkt der geneigte Anwender dann aber recht 
schnell im OOP Meer mit seinen zehntausend kryptischen 
Formulierungsweisen, Sprach-, Bibliotheks- und Klassenelementen.
Meinen Respekt für den, der sich da durchboxt, um genau den richtigen 
Wortlaut für seine Programmlösung zu finden! Meine Zeit wär mir aber 
dafür zu schade.

Naja, wenn man sich in einem ereignisgesteuerten Umfeld wie einem GUI 
bewegt, dann braucht eben auch die UART-Schnitstelle eine 
ereignisorientierte API, sonnst paßt sie nicht. Und auch die OS API's 
für UART's sehen nicht mehr wie Intx unter DOS aus.
Mein Auto hat auch weder Anlaßkurbel noch manuelle Zündverstellung am 
Lenkrad (schon weils ein Diesel ist, der bekannterweise wegen Gewicht 
nur als Stationärmotor taugt), obwohl man vor 100 Jahren damit gut 
gefahren ist. Oldtimer dieser Art finde ich schön, aber deshalb lasse 
ich mir von deren Fahrern weder Klimaautomatik noch 
Geschwindigkeitsbegrenzer wegdiskutieren. Beide ist bequem, muß aber 
auch bedient und bezahlt werden. Klima gleich zweifach, über den 
Verbrauch.

Bastler schrieb:
> Naja, wenn man sich in einem ereignisgesteuerten Umfeld wie einem
> GUI bewegt, dann braucht eben auch die UART-Schnitstelle eine
> ereignisorientierte API, sonnst paßt sie nicht.

Daß ein Betriebssystem X- und damit meine ich jedes beliebige- einen in 
einfachsten Worten programmierbaren Zugang zur Hardware anbietet ist 
naturgesetzlich nicht verboten.
Aus der Eleganz heutiger GUI-Programmierung folgt mitnichten 
komplizierte Codierung der Funktion.
Und die Vergleiche von Hard/Software mit den Gegebenheiten eines Autos 
sind, so oft wie sie nett und unterhaltsam sein mögen, meistens genauso 
völlig daneben.

Egal. Die Dinge sind wie sie sind- was nicht ausschließt, sie sich 
besser zu denken.
Es nicht selbst besser tun zu können, aber das Gedachte trotzdem 
auszusprechen ist reichlich frech und unverfroren, ich weiß ;-)

Moby schrieb:
> Es nicht selbst besser tun zu können, aber das Gedachte trotzdem
> auszusprechen ist reichlich frech und unverfroren, ich weiß ;-)

Nein, aber reichlich kurzsichtig in diesem Fall.

Nase schrieb:
> Nein, aber reichlich kurzsichtig in diesem Fall.

Was an der Forderung, die Programmierung auf das nötige Maß zu 
vereinfachen kurzsichtig sein soll erklärst Du leider nicht. Ich 
fürchte, da gibts auch nichts zu erklären. Ich kann Dir aber sagen was 
ich für kurzsichtig halte: Die heute vorherrschende OOP Philosophie für 
das einzig und ewig Wahre zu halten!
Wie sagte schon der Linux-Vater zu C++? Es sei schlecht, weil es so 
viele schlechte Programmierer benutzen. Wie er das wohl gemeint hat? 
Welche Rückschlüsse schlechte Programmierleistungen wohl auf die 
Qualität der Sprache selber zulassen?

Man kann den Linus aber auch anders interpretieren: Mit C++ erzielen 
auch nicht ganz so gute Programmierer Ergebnisse, nur diese Leute sind 
eben nicht gut genug den Linux-Kernel zu bearbeiten. Sein wichtigeres 
Argument gegen C++ im Kernel sind die Exceptions, deren 
Implementierung nicht standardisiert ist. WinNT hat im Kernel auch eine 
eigene Art von Exceptions, die nichts mit der C++ Variante zu tun haben. 
Aber ist halt schön wenn man den eigenen Glauben zitieren kann.

Bastler schrieb:
> Aber ist halt schön wenn man den eigenen Glauben zitieren kann.

Sowas ist natürlich immer schön.
Daß OOP inklusive seiner Spielart C++ die PC Programmierung (vom 
GUI-Design mal abgesehen) unnötig verkompliziert und aufwendig macht ist 
freilich längst kein Glaube, sondern Tatsache.

Boris P. schrieb:
> Sollte das lustig sein?

Nö. Leider todernst.
Manch einer hat das System aber so verinnerlicht oder lebt gar davon, 
daß die Vorstellungsgabe zu nichts anderem mehr langt ;-(

Moby schrieb:
> Ich kann Dir aber sagen was
> ich für kurzsichtig halte: Die heute vorherrschende OOP Philosophie für
> das einzig und ewig Wahre zu halten!

Du kommst zu spät, der OOP Hype war in den 90ern. Heute weiß man längst 
dass sich nicht alle Probleme mit OOP lösen lassen. Die neuen 
Hochsprachen haben eine sehr abgespeckte Variante von OOP (z.B. Rust, 
Go) im Vergleich zu Java/C#/C++ etc. und unterstützen wieder mehrere 
Paradigma.

Moby schrieb:
> Bastler schrieb:
>> Aber ist halt schön wenn man den eigenen Glauben zitieren kann.
>
> Sowas ist natürlich immer schön.
> Daß OOP inklusive seiner Spielart C++ die PC Programmierung (vom
> GUI-Design mal abgesehen) unnötig verkompliziert und aufwendig macht ist
> freilich längst kein Glaube, sondern Tatsache.

Bullshit. Dumme Pauschalisierung die sich nicht beweisen lässt. Kehr 
bitte in deinen AVR/ASM Sumpf zurück, zu diesem Thema hast du nur eine 
Meinung, aber keine Fachkenntnis.

Sebastian V. schrieb:
> In der Liste ist C++ etwas fehl am Platz. Dort gab es schon immer freie
> Funktionen und wird es wohl auch immer geben. Im Gegensatz zu Java und
> C# wird einem OOP dort nicht aufgezwungen.

Ja habe erst danach gemerkt, dass man das so fälschlicherweise verstehen 
kann.

Moby schrieb:

> Daß OOP inklusive seiner Spielart C++ die PC Programmierung (vom
> GUI-Design mal abgesehen) unnötig verkompliziert und aufwendig macht ist
> freilich längst kein Glaube, sondern Tatsache.

Das ist ganz offensichtlicher Unsinn.

Tatsache ist vielmehr, dass OOP-Design die Programmierung ganz 
erheblich vereinfacht und beschleunigt. Wäre es anders, würde es kein 
Schwein benutzen, jedenfalls niemand, der seine Brötchen mit dem 
Programmieren verdient.

Der Nachteil an OOP ist einzig und allein, dass es nochmals deutlich 
mehr Redundanzen einführt, als es bereits die klassischen prozeduralen 
Hochsprachen (hier sei C mal als Fast-Hochsprache mit eingerechnet) 
getan haben.

Was also verkompliziert und verlangsamt wird, ist nicht die 
Programmierung, sondern das Programm.

Es ist aber nunmal so, die den Programmierer bzw. seinen Brötchengeber 
dieses Problem in den meisten Fällen überhaupt nicht berührt, weil es 
außer in sehr wenigen, ganz eng eingeschränkten Anwendungsbereichen fast 
nie konkrete Vorgaben des Auftraggebers zu diesem Thema gibt (die sind 
ja schon meistens völlig überfordert damit, die gewünschte 
Funktionalität vollständig und logisch konsistent zu beschreiben).
Wenn die Scheiße zu langsam ist, wird eben einfach ein schnellerer 
Rechner gekauft, das kommt den Auftraggeber sehr viel billiger als 
hochgradig performance-optimierte Software.

Allerdings: Das Ganze funktionierte so lange recht gut, solange die 
Rechner jedes Jahr signifikant schneller und trotzdem noch billiger 
wurden. Aber diese Zeiten sind seit einiger Zeit vorbei, wie sogar Intel 
nunmehr öffentlich anerkennen musste. Moore's law gilt nicht mehr.

Und damit eröffnen sich wieder viel mehr Schaffensfelder für Leute, die 
neben dem ganzen Hochsprachen-Brimborium nie die Basics vergessen haben 
und die in der Lage sind, neue Hardware-Entwicklungen zu assimilieren, 
Jahre bevor es dafür C- (und noch später: richtige Hochsprachen-) 
Abstraktionen gibt. Allerdings: wer in diesem Sektor mitmischen will, 
der muß immer am Ball bleiben. Mit gut abgehangenen x86-Asm-Kenntnissen 
aus DOS-Zeiten oder gar 
Z80/6502/68k-Homecomputer-Jugenderfolgserlebnissen alleine kann man da 
nix reißen. Das alles kann höchstens eine brauchbare Grundlage sein, mit 
solch einem Background kann man neuere Entwicklungen besser und 
schneller verstehen. Viel mehr nützt es aber nicht.

Und C und C++ muß man trotzdem können, selbst wenn man das haßt wie die 
Pest (wie das bei mir der Fall ist). Es ist bei der Komplexität heutiger 
Anwendungen einfach nicht mehr möglich, alles selbst zu entwickeln 
(schon garnicht: vollständig in Assembler), jedenfalls wenn man deutlich 
vor dem Wärmetod des Universums fertig werden will. Und was zugeliefert 
wird, kommt in C oder C++ oder C#, und man muß in der Lage sein, daran 
anzudocken (und die vielen subtilen Fehler darin zu finden, nachdem man 
i.d.R. schon viel zuviel Zeit damit zugebracht hat, die Fehler im 
eigenen Code zu finden...)

Ach ja, fast vergessen: Sobald größere Datenmengen in's Spiel kommen, 
ist es auch sehr nützlich, Programmiersprachen der "vierten Generation" 
gut zu beherrschen, speziell natürlich SQL. Das ist wieder ein völlig 
anderes Konzept (mit dem i.d.R. sowohl OOP- als auch klassische 
prozedurale Programmierer ihre liebe Not haben). Das Konzept wirklich zu 
kapieren, hat bei mir noch viel länger gedauert als OOP.

Und bei funktionalen Sprachen muß auch ich weitgehend passen. Zum Glück 
ist auch sowas immer mit einer C-Schnittstelle "nach unten" 
ausgestattet. Denn so schick und bequem so eine Sprache für mathelastige 
Akademiker auch sein mag, letztlich muß doch das Programmierer-Fußvolk 
helfen, der Sache Flügel zu verleihen, weil Computer zum Glück halt doch 
ziemlich doof sind...

c-hater schrieb:
> Tatsache ist vielmehr, dass OOP-Design die Programmierung ganz erheblich
> vereinfacht und beschleunigt.

Ja. Große Projekte. Die sich für die Abbildung in einem OOP Design 
eignen. Im Vergleich zu früherer prozeduraler Entwicklung.
Das steht freilich in keinem Kontrast zu dem, was ich im Kleinen 
bemängle: Die Auswahl an Konzepten. An Sprachelementen. An Konstrukten 
aller Art. Dies alles in der richtigen Weise anzuwenden ist Aufwand. Der 
zuoft nicht getrieben wird/werden kann und in den torvaldschen 
schlechten C++ Programmierern mündet.
Wenn ich mir anschaue, welches intransparente Bimbamborium in Windows 
für das Ansprechen der seriellen Schnittstelle getrieben wird. Um 
wieviel einfacher und übersichtlicher war das noch unter DOS.
Ist es eigentlich wahr, daß Win8/10  Apps der Zugriff auf die Serielle 
aus irgendwelchen obskuren Sicherheitserwägungen heraus erschwert / 
unmöglich wurde bzw. nur noch über Umwege möglich ist?
Dieses mit Selbstbeschäftigung vollgepumpte System wird nochmal an 
seinen Regularien, Sicherheitsbeschränkungen und 
Programmiererentmündigungen ersticken...
Geht natürlich alles Hand in Hand mit den sprachlich aufgeblähten 
Programmiersprachen- mit dem Ergebnis jenes hohen Programmieraufwands, 
der sich im schwereren Findenkönnen der richtigen "Sprachregelung" für 
ein konkretes Problem äußert.

Hallo,

Moby schrieb:
> Karl Käfer schrieb:
>> Natürlich. Aber es liegt am Computing, das zunehmend komplizierter wird;
>> das schlägt sich auch im Umfang von Sprachen und Werkzeugen nieder.
>
> Die "Natürlichkeit" ständig weiter aufzublasender Sprachen lass ich mir
> von niemand einreden. Viele zu programmierende Grundfunktionen bleiben
> die gleichen, allen Multithreadings und Manycore zum Trotz. Das muß
> alles nicht so kompliziert umzusetzen sein.

Es sieht nur dann kompliziert aus, wenn man es nicht versteht.

> Daniel A. schrieb:
>> Meine
>> lieblingslösung ist es, einfach alles selbst zu schreiben.
>
> Meine auch.

LOL. Na dann viel Spaß mit Euren selbstgeschriebenen Betriebssystemen, 
Webbrowsern und dem Not-invented-here-Syndrom.

Liebe Grüße,
Karl

Hallo TriHexagon,

TriHexagon schrieb:
> Die neuen
> Hochsprachen haben eine sehr abgespeckte Variante von OOP (z.B. Rust,
> Go) im Vergleich zu Java/C#/C++ etc. und unterstützen wieder mehrere
> Paradigma.

Das tut C++ auch.

Liebe Grüße,
Karl

Hi.

Danke für euer Feedback.

Im August beginnt das Projekt.
Dann habe ich bis Jahresende Zeit für die Konzeption und Erprobung. Ab 
nächstem Jahr soll ich dann mit der eigentlichen Erstellung der Software 
beginnen.


Folgendes Anforderungen sind hinzugekommen bzw verschärft worden:

-Quellcode darf nicht so ohne Weiteres sichtbar sein, also durch 
richtige Kompilierung oder ähnliches verdeckt sein. Mit reinen 
Scriptspachen kann ich also schonmal nicht arbeiten. GPL, LGPL ist auch 
nicht möglich.
Das Kommunikationsprotokoll mit der Anlage soll nämlich nicht auf dem 
Silbertablett serviert werden.

-Wenn Frameworks benutzt werden und diese getrennt installiert werden 
müssen, dann nur solche, die so gängig und verbreitet sind, dass eine 
signifikante Chance besteht, dass sie ohnehin schon vorhanden sind, bzw 
man sie vorraussetzen kann. (Im Firmenumfeld)

Das .NET Framework z.B. wüde diese Bedinung erfüllen, ein JRE würde auch 
noch genehmigt werden.

-Libs müssen einkompiliert werden oder so mitgeliefert werden, dass die 
Software dennoch "Portable" und ohne Installer von einem USB Stick 
arbeiten kann, der bei der Anlage mitgeliefert wird.

-Plattformübergreifend muss nicht. Ob es unter Linux oder MacOS läuft 
ist egal, wird auch nicht bezahlt wenn ich dafür Zeit aufwenden würde.
Aber es muss unter Windows XP bis Windows 10 lauffähig sein.

-Die Entwicklungsumgebung bzw Lizenzen für Libs dürfen Geld kosten. Nur 
während der Evaluierungsphase bis nächstes Jahr nicht. Im Produktiven 
Einsatz dann schon. Auch vierstellige Beträge wären kein Problem für den 
Auftraggeber.

Mfg Tom

Momentan tendiere ich aufgrund der Anforderungen wirklich am ehesten zu 
C++  und die Verwendung von Microsoft Visual Studio.

Da dort wirklich eine richtig kompilierte EXE raus kommt und es unter 
Windows auch relativ problemlos standalone lauffähig ist ohne dass man 
erst groß etwas nachinstallieren muss.

Tom schrieb:
> Ich möchte mit C++ oder Java programmieren.

Eine Alternative, die man vielleicht im Blick haben sollte, ist 
JavaScript. Eine richtig runde Umsetzung für Desktopapplikationen habe 
ich zwar noch nicht gefunden, aber vielversprechende Ansätze (z.B. 
node-webkit) gibt es schon.

Der Vorteil ist, dass der Ansatz unheimlich flexibel ist. JavaScript 
gibt es fast für jeden Zweck, von der Webanwendung über Server (node) 
zur Mobile-App. Und man kann inzwischen auch Programmcode in fast jeder 
Sprache auf das System übersetzen.

Die Community ist auch riesig. Und es stehen eine Menge Entwickler 
dahinter, weil ja quasi jeder Internetnutzer in Javascript entwickelte 
Software nutzt.

Die Sprache ist (meiner Meinung nach) zwar irgendwie eine Krücke, aber 
das ist wahrscheinlich auch einer der Gründe, wieso sie sich so weit 
durchgesetzt hat. Wie bei C eben auch ;-)

Nachteil ist logischerweise die Performance, wobei Firmen wie Apple, 
Google und Microsoft schon sehr dahinter sind, schnelle virtuelle 
Maschinen zu entwickeln.

Tom schrieb:
> Außerdem benötige ich mit meinem Programm Zugriff auf eine Datenbank,
> ich brauche Netzwerkkommunikation (FTP u.ä) und Zugriff auf die RS232
> Schnittstelle.

Ist alles mit node.js möglich.

Hallo Tom,

Tom schrieb:
> -Quellcode darf nicht so ohne Weiteres sichtbar sein, also durch
> richtige Kompilierung oder ähnliches verdeckt sein. Mit reinen
> Scriptspachen kann ich also schonmal nicht arbeiten.

Das ist ein Irrtum. Für Python, zum Beispiel, gibt es eine Software 
namens "py2exe", mit der aus Python-Dateien native .exe-Programme 
erzeugt werden können. Ist eher etwas für Könner, und da der Interpreter 
in die erzeugte .exe integriert wird, wird die ziemlich groß.

Python und Perl, um nur zwei Beispiele zu nennen, können außerdem als 
kompilierter Bytecode ausgeliefert werden, ohne Quellcode.

> GPL, LGPL ist auch nicht möglich.

Das ist ein beliebtes Mißverständnis. Selbstverständlich kannst Du eine 
LGPL-Bibliothek benutzen und deren unveränderten Originalcode 
mitliefern. Den Quellcode Deines eigenen Programms, das die 
LGPL-Bibliothek lediglich benutzt, kannst Du weiterhin privat halten. 
Siehe dazu auch unter [1] und dort unter "Developing with the LGPL".

Ansonsten sind die Lizenzkosten (ich hörte von ca. 3.000 USD für einen 
Entwickler) für eine kommerzielle Einzellizenz nicht nur moderat, 
sondern vor allem ihr Geld wert. Die besondere Stärke von Qt liegt IMHO 
vor allem in der Ersparnis bei der Entwicklungszeit. Die 
Plattformunabhängigkeit ist auch nett, aber IMHO sind die eigentlichen 
Vorteile die Effizienz und die Geschwindigkeit der Entwicklung.

> Das Kommunikationsprotokoll mit der Anlage soll nämlich nicht auf dem
> Silbertablett serviert werden.

Ich persönlich finde so etwas, ehrlich gesagt, bescheuert. Warum sollte 
man dem Kunden nicht die Möglichkeit einräumen, seine eigene Hardware 
mit der Software seiner Wahl zu benutzen? Man muß das ja nicht supporten 
oder kann kostenpflichtigen Entwicklersupport dafür anbieten.

Darüber hinaus gibt es natürlich die Möglichkeit -- und das ist auch die 
einzige Möglichkeit, das Protokoll wirksam vor Reverse Engineering zu 
schützen -- die Kommunkation verschlüsseln. Das ist rechtlich und auch 
technisch der einzige wirksame Schutz.

> -Wenn Frameworks benutzt werden und diese getrennt installiert werden
> müssen, dann nur solche, die so gängig und verbreitet sind, dass eine
> signifikante Chance besteht, dass sie ohnehin schon vorhanden sind, bzw
> man sie vorraussetzen kann. (Im Firmenumfeld)

Da Autodesk, Adobe und verschiedene andere Hersteller die 
Qt-Bibliotheken nutzen, besteht auch eine gewisse, wennglich nicht 
unbedingt sehr hohe Wahrscheinlichkeit, daß sie bereits installiert 
sind.

> -Die Entwicklungsumgebung bzw Lizenzen für Libs dürfen Geld kosten. Nur
> während der Evaluierungsphase bis nächstes Jahr nicht.

Das wäre bei Qt kein Problem.

Liebe Grüße,
Karl


[1] http://www.qt.io/FAQ

Karl Käfer schrieb:
> Ansonsten sind die Lizenzkosten (ich hörte von ca. 3.000 USD für einen

$4200 pro Jahr, glaube ich ($350 pro Monat im Abo).

Moby schrieb:

> Wenn ich mir anschaue, welches intransparente Bimbamborium in Windows
> für das Ansprechen der seriellen Schnittstelle getrieben wird. Um
> wieviel einfacher und übersichtlicher war das noch unter DOS.

Huch? DOS konnte serielle Schnittstellen selber eigentlich garnicht 
sinnvoll nutzen, weil es nur auf die (sehr rudimentären) BIOS-Routinen 
zurückgegriffen hat. Genau deswegen hat doch jedes verschissene 
Teminalprogramm damals(TM) seine eigenen Treiber dafür mitgeliefert...

Und was das Windows-API dazu anbietet, ist erstens kein bissel 
objektierientiert und zweitens sehr nahe an dem, was für ein 
Nicht-Echtzeit-OS überhaupt an Unterstützung für Anwendungen möglich 
ist. Für nahezu jeden "normalen" Anwendungsfall kann man die meiste 
Arbeit auf den Treiber verlagern. Mit ein bissel Tricksen kann man im 
Userspace sogar fast sowas wie Echtzeit erreichen (wenn sonst nix los 
ist im System).

Allerdings: System.IO.Ports.SerialPort (.net) ist ein furchtbare 
Krankheit. Da waren Programmierer am Werk, die vom Win32-API keine 
Ahnung haben und auch sonst recht unfähig sind... Ich würde MS 
empfehlen, die Wichser zu feuern. Hat MS allerdings bereits getan, ohne 
auf meine Empfehlung zu warten. Schlimm nur: deren Nachfolger sind noch 
viel blöder. Der mittlerweile ja zugängliche Quellcode von .Net4 spricht 
da Bände. Da wurde z.B. die "uncatchable" Exception beim Entfernen eines 
in Benutzung befindlichen (USB-)Ports einfach auskommentiert. Ein Bug, 
der seit .net2.0 bekannt und dokumentiert ist, wurde dadurch gelöst, daß 
wenigstens einfach nicht mehr die Anwendung irreperabel abschmiert. OK, 
ist immerhin ein Fortschritt gegenüber dem vorherigen Zustand, man kommt 
immerhin dazu, selber etwas unternehmen zu können, aber das kann's ja 
wohl nicht wirklich sein...

> Ist es eigentlich wahr, daß Win8/10  Apps der Zugriff auf die Serielle
> aus irgendwelchen obskuren Sicherheitserwägungen heraus erschwert /
> unmöglich wurde bzw. nur noch über Umwege möglich ist?

Nein.

Hallo Inschenör,

Inschenör schrieb:
> Tom schrieb:
>> Ich möchte mit C++ oder Java programmieren.
>
> Eine Alternative, die man vielleicht im Blick haben sollte, ist
> JavaScript. Eine richtig runde Umsetzung für Desktopapplikationen habe
> ich zwar noch nicht gefunden, aber vielversprechende Ansätze (z.B.
> node-webkit) gibt es schon.

Gute Idee, aber: warum dann überhaupt eine Desktop-Applikation? Fat 
Clients werden ja ohnehin in der Unternehmens-IT nicht mehr gerne 
gesehen, weil sie ein Provisioning benötigen. Das kann man sich sparen, 
wenn man gleich einen kleinen HTTP-Server entwickelt, welcher nur ein 
paar wenige statische HTML-, CSS- und JS-Dokumente sowie die Daten 
dynamisch als JSON ausgibt. Daran kann man dann auch noch andere 
Software zur Weiterverarbeitung der Daten hängen, und alle sind 
glücklich: der Hersteller, weil er sein Hardwareprodukt und seine 
Serversoftware verkaufen kann, und der Kunde, weil er seine Daten so 
flexibel und umfangreich nutzen kann, wie er wünscht. Und 
mehrbenutzerfähig ist die ganze Veranstaltung dann gleich dazu, dann muß 
man sich nurmehr ein paar Gedanken über Arbeitsplatzlizenzen machen.

Liebe Grüße,
Karl

Hallo Frank,

Frank schrieb:
> Karl Käfer schrieb:
>> Ansonsten sind die Lizenzkosten (ich hörte von ca. 3.000 USD für einen
>
> $4200 pro Jahr, glaube ich ($350 pro Monat im Abo).

Danke für die Info.

Liebe Grüße,
Karl

Ich programmiere seit Jahren beruflich mit Java.
Java kennt Portables jar Dateien die eine jre installation vorausgesetzt 
standalone lauffähig sind.
Java hat eine jdbc Schnittstelle, die von vielen frei verfügbare jdbc 
Treiber vieler Datenbankhersteller implementiert wird. Nicht jeder DB 
Treiber implementiert die volle API, das ist aber eh advanced, weil hier 
DB Unterschiede zum tragen kommen.
GUI gibts nativ natürlich auch.
Frameworks sind eigentlich nicht nötig, nützliche third party libraries 
kommen als jar daher, welches man leicht in die Portables integriert 
oder auch extern voraussetzt. Viele und gute 3rd party libraries finden 
sich mit guter Reputation (Apache/Eclipse Projekte )
und sind lizensmäßig gut aufgestellt für Firmen. (MIT z.B)
Eclipse als IDE für Java ist ein Heimspiel, wenig konfigurieren und 
durchstarten.
Gibt fuer Plain Java Anwendungen sicherlich auch andere IDEs, die besser 
sein mögen.
Über Obfuskierung in Java kann ich nichts sagen, ebenso serielle 
Schnittstelle.

>Das Kommunikationsprotokoll mit der Anlage soll nämlich nicht auf dem
Silbertablett serviert werden.
Security by Obscurity :O

>kein GPL/LGPL
grotesk
>Windows XP bis Windows 10
muesste man die Anforderungen einer aktuellen jre checken.
ist schon grotesk

Das letzte grotesk wollte ich nicht schreiben. Naja ist jetzt eh egal.

c-hater schrieb:
>> Ist es eigentlich wahr, daß Win8/10  Apps der Zugriff auf die Serielle
>> aus irgendwelchen obskuren Sicherheitserwägungen heraus erschwert /
>> unmöglich wurde bzw. nur noch über Umwege möglich ist?
>
> Nein.

Naja da ist schon was dran, da Metro-Apps in einer Sandbox abgesichert 
laufen und Torturen wie diese hier nötig werden:
http://ioi.solutions/serial-port-access-metro-style-app/

Boris P. schrieb:
> Mit Verlaub: das ist Unfug. Du kannst auch in einer Windows Universal
> App ganz einfach und ohne Umwege auf den SerialPort zugreifen.

Der Zugriff dieser Apps ist eingeschränkt. Informier Dich mal genauer.
Den geflissentlichen Hinweis "Keep in mind that Microsoft Store wont 
allow such apps" hast Du wohl auch übersehen.

Boris P. schrieb:
> Von einer
> "Tortur" kann da nicht die Rede sein.

Zu welchem Wahnsinn ein einfaches fopen/fread/fwrite/fclose <file> heute 
herangereift ist kann offensichtlich nur noch der Außenstehender 
wahrnehmen... Man könnte belustigt darüber den Kopf schütteln was 
'Insider' heute für normal halten, wenn man nicht selber gerne weiter 
auf einfache althergebrachte Art seine klassischen Schnittstellen würde 
ansprechen wollen- und nun zu diesen Klassen/Sprach-Ratespielchen nach 
der richtigen Formulierung gezwungen wird.

Ein prinzipielles Open(COMx), Print X nach (COMx), Read Y von (COMx), 
Close(COMx) reicht doch beispielsweise. Immer und überall. Aber das wär 
sicher zu einfach, stimmts Boris?

Im übrigen könnte Windows solchen vielgetätigten Ein/Ausgaben mit etwas 
mehr Vorarbeit/entsprechenden Funktionen entgegenkommen. Selbstredend 
mit einer einfachen Ansprache derer durch den Anwender. Da sind dann 
allerdings andere OS-Funktionen der tausendfachen Protokollierung und 
Überwachung wichtiger, stimmts Boris?

Boris P. schrieb:
> Ich verstehe also nicht so ganz, worauf du hinaus willst?

Dann studier doch nochmal die netten Spirenzchen, die im Beispiel für 
die Universal-Apps getrieben werden. Aber ich weiß ja, Du hälst das für 
normal ;-)

Boris P. schrieb:
> PS: Du bist mir noch das Beispiel (siehe weiter oben) schuldig!

Du meinst
> Was wäre denn z.B. eine Anwendung, die ohne OOP-Paradigmen
> schneller/einfacher/wartbarer zu implementieren wäre

?

Da ist meine Meinung: Jede. Auf OOP-Paradigmen ist man im Grundsatz 
niemals angewiesen. In der Praxis freilich schon, weil gegenwärtig 
alles darauf aufbaut.

Boris P. schrieb:
> Wie zum Beispiel?

Stell Dich nicht dumm.
Der ganze dort zur Schau gestellte Aufwand natürlich.

Boris P. schrieb:
> (da das für mich alles normal ist, nehme ich diese natürlich nicht als
> solche wahr...)

Genau so ist es vermutlich. ;-)

Boris P. schrieb:
> OK, du hast dich soeben disqualifiziert...

Soll ich jetzt überrascht sein? Na schon klar ;-)
Aber solang Du echt Spaß an OOP hast bitte gerne.
Ich mags gern so einfach wie möglich.

Boris P. schrieb:
> Du scheinst nicht zu
> verstehen, was da gemacht wird?

Nein. Das gebe ich zu.
Aber was heißt das jetzt?
Daß ein Außenstehender nicht erkennen könnte, eine unnütz komplexe 
Kodierung für ein einfaches Problem vor sich zu haben?

Moby schrieb:
> Aber solang Du echt Spaß an OOP hast bitte gerne.
> Ich mags gern so einfach wie möglich.

Was soll den an OOP so verdammt komplex sein? Sag es uns doch bitte. Ich 
würde gerne mal ein paar Beispiele (vorallem wie man es ohne besser 
macht) von dir sehen, denn gesehen haben wir allesamt gar nix von dir, 
außer dein ständiges Gemaule über OOP und Hochsprachen. Offensichtlich 
aber ohne Substanz.

Moby schrieb:
> Daß ein Außenstehender nicht erkennen könnte, eine unnütz komplexe
> Kodierung für ein einfaches Problem vor sich zu haben?

Wie soll man Probleme der OOP verstehen, ohne OOP zu verstehen?

TriHexagon schrieb:
> Wie soll man Probleme der OOP verstehen, ohne OOP zu verstehen?

Nö nicht Probleme der OOP- sondern schlicht die 
Probleme=Aufgabenstellungen des Alltags ;-)

TriHexagon schrieb:
> Gemaule über OOP und Hochsprachen. Offensichtlich
> aber ohne Substanz.

Ganz ohne Substanz gehts nicht, aber bitteschön für o.g. Probleme kein 
Gramm Codesubstanz mehr als nötig ;-)

Boris P. schrieb:
> Im Kern mögen viele Probleme ja einfach sein, aaaber: ...

Soweit ich den Code zu den Win10-Uni Apps überblicke gehts da erst mal 
nur drum, überhaupt den einfachstmöglichen Zugang zu COMx zu 
realisieren, nix weiter. Das dort gezeigte kryptische Kauderwelsch ist 
natürlich 1a sonnenklar simpel verständlich. Für Experten...

> - Was, wenn du erst mal einige Infos vom OS abfragen musst?

Dann frag ich halt. Übergebe meine gewünschten COM-Parameter und erhalte 
Bool für möglich/unmöglich.

> - Wenn du eine umfangreiche und kontextabhängige Fehlerbehandlung
> benötigst?

Dafür liefert Open/Read/Write/Close ne boolsche Erfolgsmeldung und ich 
verzweige entsprechend.

> - Wenn so viel wie möglich asynchron laufen soll, um Zeit zu sparen?

In dem Punkt erwarte ich das erwähnte Entgegenkommen von Windows.
Abfrage von COM-Buffern/automatische Ausgaben als schlichte 
Auftragsvergabe.
Muß das sonderlich kompliziert formuliert werden?

> - Wenn es so generisch sein soll, dass du Teile der Implementierung
> jederzeit austauschen kannst?

Lässt sich auch mit einfachsten Compile-Bedingungen realisieren.

> - Wenn du sogar zur Laufzeit noch die Implementierung durch eine andere
> erstezen können möchtest?

Nennt sich bedingte Verzweigung ;-)

> - Wenn automatisierte Unit-Tests mit Mockups durchgeführt werden
> sollen?

Gut, da muß ich passen.

Alles in allem sehe ich keine Begründung dafür, simple Dinge wie 
File/COM IO sprachlich so kompliziert zu gestalten. Habt ruhig den 
Eindruck, ich will (Eure geniale OOP) nicht verstehen. Der Eindruck 
ist aber durchaus beidseitig.

Wo genau ist denn jetzt überhaupt euer Problem? Wer nicht OOP nutzt darf 
immer noch prozedural entwickeln. Das geht in fast allen 
Programmiersprachen.

Und wer DOS für das beste Betriebssystem hält, kann es auch immer noch 
benutzen. Es gibt sogar ein halbwegs aktuelles DOS.

Und man kann auch GUI-Programme in Assembler programmieren (menuet-OS).

Man verwendet eh das, was der Auftraggeber möchte. Und wenn man das 
selbst ist, kann man machen, was man will.

Aber es macht überhaupt keinen Sinn, sich über ein Konzept auszukotzen, 
das man sowieso nicht verwenden will, oder anderen mit Gewalt ein 
Konzept aufzwingen zu wollen.

Warum steigst du eigentlich nicht in die Softwareentwicklungs-Branche 
ein?

Deine Denkweise/Herangehensweise/was auch immer scheint ja allen 
etablierten Konzepte der Softwareentwicklung hochgradig überlegen zu 
sein. Wer weiß vielleicht bist du der eine Messias. So wie sich das 
anhört würdest du die gesamte Branche revolutionieren. Na wie wärs?

TriHexagon schrieb:
> Was soll den an OOP so verdammt komplex sein? Sag es uns doch bitte.

Danke, sehr amüsant.
Was soll denn an Computern und ihrer Programmierung so kompliziert sein?
Man studiert das ein paar Jahre und dann weiß man's doch. Alles einfach 
wenn man nur weiß wie... Deshalb gibts auch kein schwierig und komplex, 
kein kompliziert und intransparent. Himmel Herrgott.

Wird Dir nun klar, was an Deiner Frage faul ist?
Oder drückt sie etwa doch eine gewisse Überheblichkeit aus?
Magst Du bitte zur Kenntnis und ernst nehmen, daß es Leute gibt, die 
durchaus programmieren, aber OOP nichts abgewinnen können?
Magst Du bitte mal zur Kenntnis und ernst nehmen, wie sich wirklich 
ausgewiesene Experten a la L.Torwalds zu OOP-Spielarten wie C++ äußern?

Inschenör schrieb:
> Wer nicht OOP nutzt darf
> immer noch prozedural entwickeln. Das geht in fast allen
> Programmiersprachen.

Das hoffe ich auch für die Zukunft.
Entgegen anderslautenden Behauptungen halte ich prozedural immer noch 
für intuitiveren Klartext als dieses intransparente Abstrahieren a la 
OOP.

Moby schrieb:
> Wird Dir nun klar, was an Deiner Frage faul ist?
> Oder drückt sie etwa doch eine gewisse Überheblichkeit aus?

Du bist doch derjenige der immer allen erklären will das OOP alles 
verkompliziert. Da ist es doch legitim zu fragen, warum das so sein 
soll. Wenn man dann aber erst mal erfährt, dass derjenige sich zwanghaft 
weigert zu lernen was das ist und wie es funktioniert, aber dennoch 
verteufelt, dann kann man schon mal zynisch werden.

Moby schrieb:
> Magst Du bitte zur Kenntnis und ernst nehmen, daß es Leute gibt, die
> durchaus programmieren, aber OOP nichts abgewinnen können?

Ja tue ich doch. Ich bin der letzte der jmd. OOP aufzwingen will und für 
kleine Programme prozedurale Programmierung bevorzugt. Dennoch sehe ich 
nicht ein was das Theater immer sein soll, was du in diesem Forum 
ständig veranstaltest.

Moby schrieb:
> Magst Du bitte mal zur Kenntnis und ernst nehmen, wie sich wirklich
> ausgewiesene Experten a la L.Torwalds zu OOP-Spielarten wie C++ äußern?

Torvals Äußerungen zielen größtenteils auf die Kernel Entwicklung ab. 
Und ja er kann sogar C++ etwas abgewinnen. Und OOP ist wie erwähnt auch 
im Kernel. Auch sollte man nicht unerwähnt lassen, dass seine Äußerungen 
wohl recht umstritten sind.

Moby schrieb:
> Das hoffe ich auch für die Zukunft.
> Entgegen anderslautenden Behauptungen halte ich prozedural immer noch
> für intuitiveren Klartext als dieses intransparente Abstrahieren a la
> OOP.

Wieso wartest du auf die Zukunft? Du kannst doch heute schon prozedural 
entwickeln. Du musst also nicht warten, sondern kannst heute schon los 
legen.

Interessante Diskussion. QT ist ein super Lösungsvorschlag, den man nur 
unterstützen kann.

Prinzipiell ist aber glaube ich ziemlich egal, was du nutzt. Mit einem 
Werkzeug wie Portable Apps (http://portableapps.com/download) kannst du 
dir eine Gesamt-Exe auch mit verschiedensten Abhängigkeiten 
zusammenbauen, die dann wirklich vom Stick läuft.

Also wenn du lieber C# oder irgendwas anderes programmieren willst, was 
dir die Softwarewartung später erleichtert, dann könnte dir das helfen.

Kannst natürlich C++ machen und alles gegen die Win32-Umgebung nativ 
linken.

Sebastian V. schrieb:
> Ich weiß auch nicht was du so extremst gegen OOP hast. OOP muss ja nicht
> gleich ein haufen Klassen mit riesigen Vererbungsbäumen und Zeugs sein.

Muss ja nicht?
Es ist "ein haufen Klassen mit riesigen Vererbungsbäumen und Zeugs"!
Der zu studieren und zu durchwühlen ist für alle ganz konkreten 
Windows-Vorhaben, nicht unbedingt für ein zusammengekünsteltes Beispiel.

Ich bringe in der Rubrik PC-Programmierung auch nicht Assembler gegen 
die etablierten OOP Sprachen in Stellung.
Aber Assembler zeigt in der Mikrocontrollerwelt sehr schön, wie sich 
auch mit einem Minimum an Instruktionen, Sprachmitteln, Textbedarf, 
Konventionen, Abhängigkeiten- sprich einem Minimum zu dokumentierender 
Werkzeugeigenschaften pfeilschnelle ultrakompakte Programme ganz 
natürlich prozedural und im Bausteinprinzip schaffen lassen. Für Windows 
schaffen ließen, denn um dies auf Windowsprogrammierung zu übertragen 
fehlen eben a) die nötigen Programmierwerkzeuge / Programminfrastruktur 
für b) viel einfachere Windows-Schnittstellen.

Ob ein einer Sprache der komplexen OOP mächtiger Insider zu realisieren 
vermag, daß sein Lösungsweg sprachlich letztlich viel zu kompliziert 
ausfällt? Antwort: Keine Chance... Das ist die Crux der Innensichten.

Ausdrucksmittel/Flexibilität und Komplexität sind zwei Seiten derselben 
Medaille. Benötigt ein Problem diese Flexibilität im Prinzip nun gar 
nicht (und das sind sehr viele Aufgaben) ist schwuppdiwupp die 
Komplexität viel ausgeprägter als nötig. Die der OOP Lösung meine ich.

Cooles Argument: weil ich es nicht kenne, bin ich nicht verblendet, kann 
ich beurteilen, daß es nichts taugt.
 Schön dich nur in diesem Forum zu erleben. Berufsalltäglich hätte ich 
vermutlich längst den Pfad der Diskussion verlassen. Obwohl, den ein 
oder anderen (Teil-) Moby hab ich in meinem Umfeld. Aber die stehen 
nicht ständig in meinem Büro und müllen mich akustisch zu.

Bastler schrieb:
> kann
> ich beurteilen, daß es nichts taugt.

In mehrfacher Hinsicht (willentlich) falsch wiedergegeben.

a) Ich beurteile nicht, es ist schlicht für jeden ersichtlich, daß
b) nicht etwa etwas nichts taugt, sondern es sprachlich zu kompliziert 
formuliert ist.

> Berufsalltäglich hätte ich
> vermutlich längst den Pfad der Diskussion verlassen.

Hoffentlich mit der gleichen Erkenntnis b) ...

Bastler schrieb:
> Aber die stehen
> nicht ständig in meinem Büro

Das Forum / dieser Thread ist also Dein Büro, in dem Du Dich 
gezwungenermaßen aufhalten mußt. Ach sooo...

Ja, andere Sichtweisen können schon recht schmerzhaft sein.
Man kann das mit "Zumüllen" verunglimpfen.
Man könnte auch versuchen, diese nachzuvollziehen.
Aber ich hatte ja schon befürchtet, Insidern mit Mühen für und Stolz auf 
Ihre Sprache ist das unmöglich.

Schmerzhaft ist nicht deine Sichtweise der Dinge, denn die kann man 
akzeptieren ohne sie für richtig zu halten. Es ist vielmehr die 
Penetranz mit der sie immer wieder vorgebracht wird. Und wenn mir das 
allein auf den Wecker gehen würde, dann ok. Aber es wird von dir jeder 
Thread der sich mit Themen befaßt, die du ablehnst, zugemüllt.
BTW, was du als "sprachlich zu kompliziert" beschreibst, ist dann ein 
anderes mal was, das as ganz wenig Code riesige Programm erzeugen soll. 
Immer so hindrehen wie's grad paßt. Den "Pfad der Diskusion verlassen" 
hast du offenbar nicht kappiert: ich würde eine solche Nervensäge 
rausschmeisen. Aber ja, hier ist nicht mein Büro, hier kann ich einfach 
das machen, was ich oft tu: nicht lesen! Nur, es ist auch keine Kanzel 
zu Predigt der einfachsten Programmierweise.

Moby schrieb:
> Aber Assembler zeigt in der Mikrocontrollerwelt sehr schön, wie sich
> auch mit einem Minimum an Instruktionen, Sprachmitteln, Textbedarf,
> Konventionen, Abhängigkeiten- sprich einem Minimum zu dokumentierender
> Werkzeugeigenschaften pfeilschnelle ultrakompakte Programme ganz
> natürlich prozedural und im Bausteinprinzip schaffen lassen.

Also ich kriege das auch in C hin. Ist wohl eine Frage des persönlichen 
Könnens. ;-)

Moby schrieb:
> Ob ein einer Sprache der komplexen OOP mächtiger Insider zu realisieren
> vermag, daß sein Lösungsweg sprachlich letztlich viel zu kompliziert
> ausfällt? Antwort: Keine Chance... Das ist die Crux der Innensichten.

Wenn die Programmierer ihre Lösung einfach finden, passt doch alles. Nur 
diese "Innensicht" ist entscheidend. Ein Laie oder Anwender muss es doch 
gar nicht interessieren, wie die Sprache aussieht.

Moby schrieb:
> Für Windows
> schaffen ließen, denn um dies auf Windowsprogrammierung zu übertragen
> fehlen eben a) die nötigen Programmierwerkzeuge / Programminfrastruktur
> für b) viel einfachere Windows-Schnittstellen.

Ich finde die Schnittstellen, die man bei .NET angeboten kommt, wirklich 
super einfach. Einfacher geht es ja wohl kaum. Alternativ Lazarus, das 
habe ich mir als alter Pascal-Fan mal angeschaut, wirklich super 
einfach.

Ich gebe zu, wie ich damals aus der Turbo-Pascal-Welt gekommen bin und 
auf Visual Basic 6 umgestiegen bin (das wurde damals eben noch in der 
Schule unterrichtet) habe ich mir sehr schwer mit dem Konzept der 
ereignisbasierten Programmierung getan. Das Programm läuft ja nicht mehr 
linear ab, wie soll das denn gehen? Irgendwann hat es dann aber "Klick" 
gemacht und dann war es plötzlich super einfach und viel verständlicher. 
Dass das VBasic dann auch objektorientiert war (in Pascal habe ich die 
Features nicht gekannt und auch nicht genutzt), habe ich anfangs gar 
nicht gemerkt. Für mich war es einfach ganz natürlich und intuitiv, 
GUI-Elemente als Objekte anzusprechen.

Moby schrieb:
> Ich bringe in der Rubrik PC-Programmierung auch nicht Assembler gegen
> die etablierten OOP Sprachen in Stellung.
> Aber Assembler zeigt in der Mikrocontrollerwelt sehr schön, wie sich
> auch mit einem Minimum an Instruktionen, Sprachmitteln, Textbedarf,
> Konventionen, Abhängigkeiten- sprich einem Minimum zu dokumentierender
> Werkzeugeigenschaften pfeilschnelle ultrakompakte Programme ganz
> natürlich prozedural und im Bausteinprinzip schaffen lassen. Für Windows
> schaffen ließen, denn um dies auf Windowsprogrammierung zu übertragen
> fehlen eben a) die nötigen Programmierwerkzeuge / Programminfrastruktur
> für b) viel einfachere Windows-Schnittstellen.

Und genau da ist dein Denkfehler. Du glaubst, dass was auf einem 
winzigen 8-Bit AVR Mikrocontroller für Software gilt, gilt genauso für 
ein universelles n GHz Monster mit zig tausend Peripherie, das eben 
möglichst alle Anforderungen, die man heute so hat, erfüllen soll. Da 
ist die Peripherie schon zig tausend mal komplexer als die vom popeligen 
AVR oder ARM Cortex. Beliebig erweiterbar soll es sein. Die Peripherie 
soll dann auch noch möglichst genau und auf jedem PC gleich von einer 
Anwendung angesteuert werden können. Dann kommt noch sowas wie 
Sicherheitsanforderungen dazu. Keine Anwendung darf das System lahm 
legen oder Manipulieren können. etc. etc. . Eine Wollmilchsau also.
Mit Assembler von keinem Menschen auf der Welt kontrollierbar.

Boris P. schrieb:
> Hast Recht, was hier passiert blickt garantiert kein Mensch:var myPort =
> new SerialPort("COM1", 9600);
> myPort.Open();
>
> if(myPort.IsOpen)
>   myPort.Write("Hello World!");
>
> ^^ Oh Mann...

Da hast du deine einfache und flexible Programminfrastrukur, dank OOP 
und Hochsprache ganz einfach.

Inschenör schrieb:
> Ist wohl eine Frage des persönlichen
> Könnens. ;-)

... für fraglichen Aufwand ;-)

> Wenn die Programmierer ihre Lösung einfach finden, passt doch alles. Nur
> diese "Innensicht" ist entscheidend. Ein Laie oder Anwender muss es doch
> gar nicht interessieren, wie die Sprache aussieht.

Ja. Dann passt vielleicht alles. Für Dich.
Nicht für jemand, der gern schnell ein eigenes Win-Programm bräuchte und 
erstmal vor dem OOP-Berg steht. Nochmal, auch wenns Gast "Bastler" zu 
den Ohren rauskommt: Es müsste nicht so aufwendig zu programmieren sein.

Man vergleiche mal komplexes Win-OOP mit einem komplexen Raspberry.
Damit kann man hochflexibel hundertausend Sachen erledigen.
Aber ist das die optimale Lösung für eine Anwendung, wo ein kleiner Tiny 
schon gelangt hätte?

> Irgendwann hat es dann aber "Klick"
> gemacht und dann war es plötzlich super einfach und viel verständlicher.

Ich will Dir den Klick und die folgende Begeisterung keinesfalls 
absprechen. Mein Eindruck aber ist immer wenn ich sowas höre: Es ist die 
Begeisterung an der Komplexität, an der Herausforderung, am kryptischen 
der Programmierermacht, die dem Nebenmann und Amwender nicht mehr 
verständlich ist. Also mehr ein psychologischer Effekt.

Mit genügend Lernaufwand macht es überall "irgendwann" Klick. Die Frage 
vor dem Hintergrund einer konkreten Aufgabe ist (fürs Hobby) auch, ist 
dieses "irgendwann" nicht vielleicht zu lang?

Von den komplexen Fehlermöglichkeiten mit komplexen Programmiersprachen 
wollen wir erst gar nicht anfangen... Aber sicher doch. Dafür gibts ja 
wieder neue und immer wieder neue Werkzeuge ;-)

> Dass das VBasic dann auch objektorientiert war (in Pascal habe ich die
> Features nicht gekannt und auch nicht genutzt), habe ich anfangs gar
> nicht gemerkt. Für mich war es einfach ganz natürlich und intuitiv,
> GUI-Elemente als Objekte anzusprechen.

Ja. Die GUI-Programmierung ist besser und darin sehe auch ich einen 
Fortschritt. Das hatten wir aber schon.

TriHexagon schrieb:
> Mit Assembler von keinem Menschen auf der Welt kontrollierbar.

Wieder falsch unterstellt. Ich sehe Asm aus den vielfach genannten 
Gründen nicht als DIE Lösung für die Win-Programmierung, Aber es zeigt, 
wie viel mit relativ wenig zu erreichen ist.
Zuweilen führen die großen Asm-Vorteile Schnelligkeit und Kompaktheit 
aber dann doch zur Überwindung aller Hindernisse. Ein paar Beispiele für 
so geschriebene Betriebssysteme gibt es immerhin.

> Boris P. schrieb:
>> Hast Recht, was hier passiert blickt garantiert kein Mensch:var myPort =
>> new SerialPort("COM1", 9600);
>> myPort.Open();
>>
>> if(myPort.IsOpen)
>>   myPort.Write("Hello World!");
>>
>> ^^ Oh Mann...
>
> Da hast du deine einfache und flexible Programminfrastrukur, dank OOP
> und Hochsprache ganz einfach.

Mag für sich einfach ausschauen wenn man es vor sich hat, das WIE kennt.
Und demonstriert schon in diesem Fall die kompliziertere Schreibweise.
Nun versuchs mal damit bei den neuen Metro-Apps :-)

Moby schrieb:
> Und demonstriert schon in diesem Fall die kompliziertere Schreibweise.

War ja klar...

Troll.

Moby schrieb:
> ... für fraglichen Aufwand ;-)

Ja, da hast du Recht. Für mich ist das Leben zu kurz, um mich ewig in 
Assemblerinstruktionen einzulesen. Da programmiere ich lieber in etwas, 
was ich eh kann.

Moby schrieb:
> Ja. Dann passt vielleicht alles. Für Dich.
> Nicht für jemand, der gern schnell ein eigenes Win-Programm bräuchte und
> erstmal vor dem OOP-Berg steht. Nochmal, auch wenns Gast "Bastler" zu
> den Ohren rauskommt: Es müsste nicht so aufwendig zu programmieren sein.

Also Visual Basic damals war denkbar einfach. Da konnte man in 5 Minuten 
starten. Mit Lazarus ist es heute auch nicht anders. Ich sehe da kein 
Problem, keinen Aufwand, gar nichts.

Moby schrieb:
> Man vergleiche mal komplexes Win-OOP mit einem komplexen Raspberry.
> Damit kann man hochflexibel hundertausend Sachen erledigen.
> Aber ist das die optimale Lösung für eine Anwendung, wo ein kleiner Tiny
> schon gelangt hätte?

Also den Raspberry hat man in 5 Minuten am laufen. Da hast du vom Tiny 
noch nicht einmal das Datenblatt geladen, geschweige denn eine 
Assembler-Instruktion gelernt. Komplexer ist der Raspberry nicht, weil 
man den einfach in einer simplen Sprache wie Python programmieren kann. 
Für Anfänger geht es nicht einfacher. Und für Gelegenheitsprogrammierer 
gilt das erst Recht. Einen Python-Code kann man wie Text lesen und man 
begreift das sofort. So ähnlich ist das mit Visual Basic oder Lazarus 
auf GUI.

Moby schrieb:
> Ich will Dir den Klick und die folgende Begeisterung keinesfalls
> absprechen. Mein Eindruck aber ist immer wenn ich sowas höre: Es ist die
> Begeisterung an der Komplexität, an der Herausforderung, am kryptischen
> der Programmierermacht, die dem Nebenmann und Amwender nicht mehr
> verständlich ist. Also mehr ein psychologischer Effekt.

Nein, die Begeisterung kam von der Erkenntnis, dass das so super simpel 
ist, viel leichter zu verstehen als ein starrer Programmablauf. Der 
Programmcode von ereignisgesteuerten Programmen ist so viel einfacher 
und superleicht zu verstehen.

Moby schrieb:
> Mit genügend Lernaufwand macht es überall "irgendwann" Klick. Die Frage
> vor dem Hintergrund einer konkreten Aufgabe ist (fürs Hobby) auch, ist
> dieses "irgendwann" nicht vielleicht zu lang?

Das war ja der Witz. Es war null Lernaufwand dahinter. Das war eine 
Sache von einer Sekunde. Eben ein "Klick" im Kopf. Es war einfach nur 
die Erkenntnis: Ach ja, wenn ich auf den Button klicke, wird die 
Funktion ausgeführt. So einfach war das. Alles andere kam von alleine, 
weil es so simpel ist.

Genau deswegen ist VBA ja auch so erfolgreich. Das ist so simpel, dass 
im Prinzip jede Sekretärin Programme dafür schreiben kann.

Moby schrieb:
> Von den komplexen Fehlermöglichkeiten mit komplexen Programmiersprachen
> wollen wir erst gar nicht anfangen... Aber sicher doch. Dafür gibts ja
> wieder neue und immer wieder neue Werkzeuge ;-)

Keine Ahnung wovon du redest.

Moby schrieb:
> Ja. Die GUI-Programmierung ist besser und darin sehe auch ich einen
> Fortschritt. Das hatten wir aber schon.

Ja, und GUI-Programmierung ist in seiner Natur objektorientiert. 
Prozedurale GUI-Programmierung wäre ein Bruch in der Denkweise, was die 
Komplexität extrem erhöhen würde.

Bernd K. schrieb:
> HIER WIRD ES DEUTLICH!
>
> Moby, genau mit diesen Zeilen hast Du anschaulich auf den Punkt gebracht
> und sehr schön erklärt warum Du nicht mal ansatzweise verstanden hast
> welche PROBLEME auftreten werden und in welche HÖLLE man sich begibt
> wenn man Deiner Herangehensweise folgt und damit Software bauen will die
> nur marginal umfangreicher und flexibler werden soll...

Dann erklär erst mal was Du hier an Behauptung in die Welt setzt.
Deutlich wird so erst mal gar nix.

> Knightrider-Lauflicht in asm auf nem AVR

Nun unterschätze nicht so überheblich die Möglichkeiten, die sich mit 
einem AVR auftun... Embedded ist ja oft sogar komplexer und 
herausfordernder als schnöde Win-Programmierung. Gekocht wird im übrigen 
überall nur mit Wasser.

Inschenör schrieb:
> Moby schrieb:
>> ... für fraglichen Aufwand ;-)
>
> Ja, da hast du Recht. Für mich ist das Leben zu kurz, um mich ewig in
> Assemblerinstruktionen einzulesen. Da programmiere ich lieber in etwas,
> was ich eh kann.

Es sind gar nicht viele...
Ich empfehle Asm auch nicht für Win-Programmierung.

> Also Visual Basic damals war denkbar einfach. Da konnte man in 5 Minuten

Ja damals. Da war manches noch einfacher, schneller, kürzer :-)

> Nein, die Begeisterung kam von der Erkenntnis, dass das so super simpel
> ist, viel leichter zu verstehen als ein starrer Programmablauf. Der
> Programmcode von ereignisgesteuerten Programmen ist so viel einfacher
> und superleicht zu verstehen.

Das freut mich für Dich, auch wenn ich das "superleicht" jetzt nicht 
wirklich ernst nehme. Es sind in der Tat nur Lapalien, die in diesem und 
vielen weiteren Foren zur OOP Programmierung diskutiert werden.
Mein Raspberry Beispiel hast Du auch nicht wirklich verstanden.

> Das war ja der Witz. Es war null Lernaufwand dahinter.

Das genau ist der Witz: Null Lernaufwand. Mach Dich nicht lächerlich.
Und schau mal, mit der Erkenntnis des Prinzips allein ist es nun 
wirklich nicht getan.

> Genau deswegen ist VBA ja auch so erfolgreich. Das ist so simpel, dass
> im Prinzip jede Sekretärin Programme dafür schreiben kann.

Bestimmt. Jede die ich kenne macht sowas :-)

> Ja, und GUI-Programmierung ist in seiner Natur objektorientiert.
> Prozedurale GUI-Programmierung wäre

... die optimale Ergänzung.

Moby schrieb:
> Es sind gar nicht viele...
> Ich empfehle Asm auch nicht für Win-Programmierung.

AVR-Assembler ist genauso schlimm.

Moby schrieb:
> Ja damals. Da war manches noch einfacher, schneller, kürzer :-)

Und daran hat sich bis heute nichts geändert. Wie gesagt, niemand zwingt 
einen dazu, komplexe Konstrukte (die gar nichts mit dem Grundgedanken 
von OOP zu tun haben) zu verwenden.

Moby schrieb:
> Das freut mich für Dich, auch wenn ich das "superleicht" jetzt nicht
> wirklich ernst nehme.

Ist es aber. Wie gesagt, fast jede Sekretärin kann damit umgehen.

Moby schrieb:
> Mein Raspberry Beispiel hast Du auch nicht wirklich verstanden.

Nein, ich habe nicht verstanden, was an einem Raspberry komplex sein 
soll. Gerade für Anfänger ist das Ding perfekt, um einfache Anwendungen 
umzusetzen. Problematisch wird es erst dann, wenn man schwierige 
Nebenbedingungen (z.B. Echtzeitanforderungen) hat.

Moby schrieb:
> Und schau mal, mit der Erkenntnis des Prinzips allein ist es nun
> wirklich nicht getan.

Doch, ist es. Natürlich basierend darauf, dass ich vorher schon ein 
wenig Grundkenntnisse über die einfachsten Sprachelemente wie Schleifen 
und If-Abfragen hatte. Aber mehr braucht man für simple GUI-Programme 
nicht. Mein größtes Programm war damals ein MP3-Player mit eigener 
Playlist-Verwaltung, was später auch noch Audio-CDs brennen konnte. Und 
das ging mit meinen rudimentären Programmierkenntnissen unheimlich gut.

Moby schrieb:
> ... die optimale Ergänzung.

Hahahaha. Guter Scherz. Was ist wohl komplizierter:

1

Label1.Text = "Mein Text"

oder

1

SetText(&MyLabel, "Mein Text")

Du sagst jetzt natürlich, dass das erste schwieriger ist, aber jeder 
Nicht-Troll wird eine andere Antwort nennen.

Andreas S. schrieb:
> auf verlorenem Posten

... bewusstes Mißverstehen permanent korrigieren zu müssen vielleicht.
Aber gesagt ist eigentlich alles (werden sich beide Seiten denken :-)

Moby schrieb:
> ... bewusstes Mißverstehen permanent korrigieren zu müssen vielleicht.

Genau, es gibt nicht einen Geisterfahrer, sondern hunderte ;-)

Die Idee von Andreas mit dem Blog finde ich gut. Vielleicht findest du 
ja einen oder zwei Leser.

Andreas Schwarz schrieb:
> Kommt mal bitte wieder zum Thema zurück.

Ich probier's mal gerade. ;)

Weil eingangs zu lesen war MS Visual Studio in der kostenfreien Variante 
einzusetzen. Ich hab die MS Visual Studio 2015 Community Edition mal als 
ISO gesaugt probeweise installiert. Was mich etwas überrascht hat, dort 
wird auch ein vollständiges MFC mitgeliefert. Verschenkt MS nun die 
Microsoft Foundation Classes Lib?

> Weil eingangs zu lesen war MS Visual Studio in der kostenfreien Variante
> einzusetzen. Ich hab die MS Visual Studio 2015 Community Edition mal als
> ISO gesaugt probeweise installiert. Was mich etwas überrascht hat, dort
> wird auch ein vollständiges MFC mitgeliefert. Verschenkt MS nun die
> Microsoft Foundation Classes Lib?

Beitrag "Visual Studio Community Edition"

Gilt so auch für VS 2015, soweit ich weiß.

Rabenhorst schrieb:
> Gilt so auch für VS 2015, soweit ich weiß.

Hast du meinen Beitrag wirklich gelesen? Wohl eher nicht.

Du kannst die MFC kostenlos benutzen und für deine Zwecke anpassen, wenn 
du die Bedingungen erfüllst. Der Quellcode der MFC (und ATL) wird auf 
Wunsch zusammen mit VS CS installiert (...\VC\atlmfc\src).

> Hast du meinen Beitrag wirklich gelesen? Wohl eher nicht.

Doch. Isch'wör! Zuerst hat mich das gram­mati­ka­lisch merkwürdige 
Konstrukt "ein vollständiges MFC" irritiert. Auch semantisch ist es 
durchaus fragwürdig, da mir bisher noch nie Halb- oder Viertel-MFC 
begegnet sind, lediglich die Bibliotheken in Binärform und deren 
Quellcode.
Nachdem ich - jeden möglicherweise abfällig wirkenden Kommentar 
vermeidend - dieses Hindernis überwunden hatte, folgte bald die Frage, 
ob "MS nun die Microsoft Foundation Classes Lib verschenkt".
Da "verschenken" in diesem Zusammenhang kein eindeutiger und 
lizenzrechtlich sinnvoller Begriff ist, habe ich einen Beitrag verlinkt, 
in dem die Nutzungsbedingungen zusammengefasst werden. So war das.

Rabenhorst schrieb:
> Du kannst die MFC kostenlos benutzen und für deine Zwecke anpassen, wenn
> du die Bedingungen erfüllst. Der Quellcode der MFC (und ATL) wird auf
> Wunsch zusammen mit VS CS installiert (...\VC\atlmfc\src).

Meine Frage ist berechtigt, denn ich kann nach der Installation das 
Gefühl nicht loswerden, dass mir einfach nur erst mal eine 
30-Tage-Testversion von Visual Studio 2015 Pro. freigeschaltet wurde und 
folglich natürlich auch alles erst mal ohne Einschränkungen 
funktioniert. Was aber passiert nach 30 Tagen?

Mir ist jedenfalls vollkommen neu, dass gerade die MFC nun jedermann für 
lau benutzen können soll. Da fehlt mir irgendwie der Glauben dazu 
aufgrund bisheriger Erfahrungen.

Tu MFC wieder dahin, wo dus herhast. Das ist einfach nur Krampf. 
Ehrlich.

Der Trick ist "30 Tage Test". Das kann lange genug sein, um die schon 
gesammelte Erfahrung damit als höherwertig als den Kaufpreis erscheinen 
zu lassen. Das passiert genau so bei den 30-Tage-Office-Tests, wo dann 
die panische Frage hochkommt: "wo muß ich zahlen, um das weiter nutzen 
zu dürfen. Hat was von Drogen. Und das MFC verschenkt wird, könnte an 
ihrer besonderen Qualität liegen. Schon vor über 15 Jahren, als ich das 
letzte mal beruflich Win32 Programne schrieb, war ATL die bessere Wahl. 
Es sei denn man brauchte eine Lib, die nur als DLL vorlag und auf MFC 
basierte. Templates kommen als Source, da hat man weniger Probleme mit.

LM317 schrieb im Beitrag #4210783:
> Was aber passiert nach 30 Tagen?

Nix, VS CE ist keine Testversion. VS Pro und Enterprise gibt es als 
Testversionen (allerdings 90 Tage benutzbar, nicht nur 30).  Die 
Community Edition entspricht VS Pro und ist unter - für MS-Verhältnisse 
ziemlich großzügigen - Bedingungen kostenlos. Das steht doch alles im 
verlinkten Beitrag. Und Quellcode als "Testversion" wäre in diesem Fall 
erst recht komisch.

> Mir ist jedenfalls vollkommen neu, dass gerade die MFC nun jedermann für
> lau benutzen können soll.

Na ja, das war vor rund 9 Monaten mal neu.

>Da fehlt mir irgendwie der Glauben dazu aufgrund bisheriger Erfahrungen.

Einer hat eben bloß "Developers, developers, developers" gerufen, der 
andere Typ dagegen tatsächlich etwas getan.

Nase schrieb:
> Tu MFC wieder dahin, wo dus herhast.

Da ist was dran. :-)

OK, laut dem Blog von Martin Richter

http://blog.m-ri.de/index.php/2015/06/09/die-mfc-ist-seit-der-veroeffentlichung-der-community-edition-von-vs-2013-auch-kostenlos-verfuegbar/

gibt es MFC inzwischen wohl doch für lau.

Ich hab mir die Community erstmalig installiert und das auch nur ohne 
den ganzen Web Kram. Doch auch so ist das Teil ein schieres Monster an 
Möglichkeiten verglichen mit bisherigen Express Editionen. Heißt aber 
nicht, dass es vom Start her träge wirkt, nur halt sehr, sehr 
umfangreich. Wenn man nur mal ab und an ein paar kleine überschaubare 
GUI-Exe Tools "zusammenfrickeln" ;) möchte, bin ich mir nicht sicher, ob 
man nicht lieber (s)bei einer der Express-Edition bleiben sollte.