Guten Morgen. 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? Ich möchte mit C++ oder Java programmieren. Plattformübergreifend muss es nicht werden, es reicht wenn es unter Windows läuft. 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! Außerdem benötige ich mit meinem Programm Zugriff auf eine Datenbank, ich brauche Netzwerkkommunikation (FTP u.ä) und Zugriff auf die RS232 Schnittstelle. Ich habe leider keine aktuellen Erfahrungen im Bereich GUI-Anwendungsentwicklung. Ich bin da Gedanklich noch 10 Jahre zurück, bei Delphi und VisualBasic. Habe bisher auch ehr mit Perl und Python Scripten auf der Linux Konsole gearbeitet. Grüße
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
Tom schrieb: > 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! Das würde eher gegen Java und auch ein bisschen C# sprechen. Java braucht die Java Runtime Enviroment und C# braucht das .NET Framework. Das .NET Framework kommt zwar je nach Windows Version vorinstalliert und die JRE haben meistens auch schon viele drauf. Wenn man in C++ die Runtime Library statisch linkt hat man noch die wenigsten Abhängigkeiten.
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.
Ich empfehle auch Qt Creator. Ich nutze es auch zum programmieren von AVRs. Als Compiler habe ich Mingw. Und als static kannste auch kompilieren. Dann ist die Anwendung standalone. Und du musst nicht die ganzen Dlls bereitstellen.
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
Wenn du Delphi kennst, versuch es doch mal mit Lazarus (Free Pascal Compiler). Am Schluß gibt ein .exe . Der Compiler ist im Großen und Ganzen auch für andere Platformen erhältlich (Linux, Apple).
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?
Das stimmt auch. Aber anscheinend hat oder wird er Kunden haben. Also gewerblich. Also bekommt er auch dafür Geld. Dann kann er sich das auch leisten.
:
Bearbeitet durch User
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.
Wenn die IDE ein par Euro kosten darf, bitte mal "Xojo" ansehen. !!! Erst ansehen, dann meckern !!! Es ist ein Basic-Dialekt, der aber hinsichtlich OOP keinerlei Wünsche offen lässt. Kann durch Plugins erweitert werden, die aber nur für wirkliche Spezial-Aufgaben erforderlich sind, z.B. OCR oder Barcodes erzeugen. Die "große" Vollversion gestattet zudem volles Crosscompiling für Windows, Mac, Linux, als "Web-APP" und neuerdings sogar für iOS. Ergebnis (für Win/Max/Linux) ist ein Ordner mit der EXE/APP und einem weiteren LIB-Unterordner. KEINE Installation (auf keiner Plattform), nur draufkopieren und starten.
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
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. Ein weitaus gravirenderes Problem ist es Libraries zu finden mit Lizenzen die diese auch Kommerziel uneingeschränkt nutzbar machen. Meine lieblingslösung ist es, einfach alles selbst zu schreiben. 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.
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.
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. Sollte das lustig sein? Oder versuchst du tatsächlich derart dreist hier zu trollen?
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.
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. 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.
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: > Manch einer hat das System aber so verinnerlicht oder lebt gar davon, > daß die Vorstellungsgabe zu nichts anderem mehr langt ;-( Mag sein. Vielleicht kannst du mir ja mal ein bisschen auf die Sprünge helfen: Was wäre denn z.B. eine Anwendung, die ohne OOP-Paradigmen schneller/einfacher/wartbarer zu implementieren wäre?
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: > 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. Wir haben wenige farben. Was nun? Eine classe pro Farbe und von Farbe ableiten? Oder eine Templateclasse? Enums und Konstanten sind nicht teil des OOP Konzepts! > 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. Dann verwendest du OOP falsch. Die vererbung in OOP reduziert redundanz. > Was also verkompliziert und verlangsamt wird, ist nicht die > Programmierung, sondern das Programm. Dann machst du etwas falsch, dieses konzept hat keine Verlangsamung zur folge. Die Java umsetzung schon, in c++ nicht. > 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. Lebe den grundsatz "Software kostet nichts!", Es kostet entweder die Arbeit, oder der Kunde ist das Produkt. > 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. Abwarten: quanten, licht und fermionencomputer. > 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...) Alles selbst zu machen in endlicher Zeit ist problemlos Möglich, aber woher nimmt man sich diese? Fehlerhafte Frameworks mag ich auch nicht, aber abgesehen von c# sind die Programmiersprachen unschuldig. > 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. SQL ist veraltet, gerade bei bigdata ist nosql angesagt. > 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... Abwarten, die zukunft wird kommen, dass ist sicher.
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.
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. Hast Recht, was hier passiert blickt garantiert kein Mensch:
1 | var myPort = new SerialPort("COM1", 9600); |
2 | myPort.Open(); |
3 | |
4 | if(myPort.IsOpen) |
5 | myPort.Write("Hello World!"); |
^^ Oh Mann... Moby schrieb: > der sich im schwereren Findenkönnen der richtigen "Sprachregelung" für > ein konkretes Problem äußert. Man sollte natürlich ein bisschen Ahnung von der Materie haben. Das ist bei allen Dingen im Leben so. Aber keine Angst: das kann man lernen. So schwierig, wie du glaubst, ist das garnicht ;-) Versuch's doch einfach mal. Vielleicht verstehst du dann, warum heutzutage kaum noch ein Weg an OOP vorbei führt.
:
Bearbeitet durch User
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/
Moby schrieb: > 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/ Mit Verlaub: das ist Unfug. Du kannst auch in einer Windows Universal App ganz einfach und ohne Umwege auf den SerialPort zugreifen. Das Beispiel, das du da anführst, macht auch nichts anderes. Von einer "Tortur" kann da nicht die Rede sein. Hier ein etwas kürzeres Beispiel für eine Windows 10 App: https://github.com/dotMorten/NmeaParser/wiki/Using-in-a-Windows-Universal-App-%28SerialPort%29 PS: Du bist mir noch das Beispiel (siehe weiter oben) schuldig!
:
Bearbeitet durch User
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?
Moby schrieb: > 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. Es ging darum, ob der Zugriff aus einer Win 10 App möglich ist. Und das ist er, uneingeschränkt. Ob Microsoft in seinem Store sowas haben möchte oder nicht steht auf einem anderen Blatt... Moby schrieb: > 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? Stimmt genau! Und genau so ist es doch (z.B. in C#): SerialPort.Open(...) SerialPort.Write(...) SerialPort.Read(...) SerialPort.Close(...) Ich verstehe also nicht so ganz, was du mir sagen willst? PS: Du bist mir noch das Beispiel (siehe weiter oben) schuldig!
:
Bearbeitet durch User
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 ;-)
Moby schrieb: > die netten Spirenzchen Wie zum Beispiel? (da das für mich alles normal ist, nehme ich diese natürlich nicht als solche wahr...)
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. ;-)
Moby schrieb: > Da ist meine Meinung: Jede. OK, du hast dich soeben disqualifiziert... Moby schrieb: > Der ganze dort zur Schau gestellte Aufwand natürlich. Der ist durchaus sinnvoll und gerechtfertigt. Du scheinst nicht zu verstehen, was da gemacht wird?
:
Bearbeitet durch User
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: > Daß ein Außenstehender nicht erkennen könnte, eine unnütz komplexe > Kodierung für ein einfaches Problem vor sich zu haben? Im Kern mögen viele Probleme ja einfach sein, aaaber: - Was, wenn du erst mal einige Infos vom OS abfragen musst? - Wenn du eine umfangreiche und kontextabhängige Fehlerbehandlung benötigst? - Wenn so viel wie möglich asynchron laufen soll, um Zeit zu sparen? - Wenn es so generisch sein soll, dass du Teile der Implementierung jederzeit austauschen kannst? - Wenn du sogar zur Laufzeit noch die Implementierung durch eine andere erstezen können möchtest? - Wenn automatisierte Unit-Tests mit Mockups durchgeführt werden sollen? - ... Dann wird auch die einfachste Sache ein bisschen aufwändiger. Und OOP hilft bei den meisten der obigen Punkte.
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.
Moby schrieb: > Entgegen anderslautenden Behauptungen halte ich prozedural immer noch > für intuitiveren Klartext als dieses intransparente Abstrahieren a la > OOP. Darf ich mal anmerken, dass moderne Programmiersprachen ETLICHE Paradigmen auf einmal bieten? Man muss sich da nicht für eins entscheiden ;-) Mit C# entwickle ich typischerweise prozedural, OOP und funktional in einem. Das spielt wunderbar zusammen...
:
Bearbeitet durch User
Moby schrieb: > 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. Klar ist alles trivial. Ein komplettes OS kann man ja auch mal in einer Woche in Assembler hinzaubern. Natürlich komplett ohne Bugs und super effizient weil nur genau das gemacht wird was nötig ist. 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. Als einfaches Beispiel nehmen wir mal 3D Koordinaten. Da baut man sich einmal eine Klasse die 3 floats oder so speichert und implementiert ein paar Operatoren und künftig kann man a+b schreiben wenn man die Koordinaten von a und b komponentenweise addieren möchte. Das ist natürlich unglaublich kompliziert... Viel komplizierter als 3 lose Variablen die so im ASM Code rumfliegen und wo ich jedes mal 3 Add-Befehle hinschreiben oder irgendein Makro aufrufen muss wenn ich damit rechnen will. PS: structs in C sind in gewissem Sinne auch schon OOP. Aber dir ist ja auch C schon zu kompliziert.
:
Bearbeitet durch User
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.
c-hater schrieb: > Moore's law gilt nicht mehr. Huh? Schon wieder? Die letzten 42 Dutzend Mal als das angeblich passiert sein sollte war es falscher Alarm, bist Du sicher daß diesmal wirklich alles anders ist?
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: >> - 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 ;-) 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 als ein Knightrider-Lauflicht in asm auf nem AVR. Du hast mit diesen wenigen Zeilen den exakten Stand Deiner Unkenntnis und Erfahrungslosigkeit genauestens dokumentiert, der maximale Radius Deiner kleinen Welt kann nun auf wenige Meter genau bestimmt werden.
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.
Kommt mal bitte wieder zum Thema zurück. Moby, für deine Thesen solltest du vielleicht ein Blog aufmachen - hier im Forum stehst du mit ihnen jedenfalls auf verlorenem Posten. Sieh das bitte ein, und hör auf jeden Thread damit abdriften zu lassen.
:
Bearbeitet durch Admin
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ß.
:
Bearbeitet durch Admin
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 grammatikalisch 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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.