Hallo,
ich quäle mich die ganze Zeit mit der Frage, welche Programmiersprache
es denn werden soll.
Mit meinem bissl C und meinem bissl VBA komm ich ja jetzt schon
teilweise bei der Synthax nicht ganz hin. Mal eine } bei C vergessen,
mal eine { bei Basic hinzugefügt etc....
Wie sieht das bei Euch aus? Bleibt Ihr einer Sprache treu?
BASIC: VB.Net, VBA, Basic 4 Android, PIC Basic Pro, etc..
C: C, C++.net, C#.net, Android NDK, etc..
Oder seid ihr Multilingual?
Liege ich mit meiner Vereinfachung richtig C/Basic oder unterscheiden
sich die Sprachen doch nochmal so stark, dass ich Sie vom Schreibstyl
her komplett neu lernen muss?
Grüße und Danke für Antworten
PICSIM schrieb: > Wie sieht das bei Euch aus? Bleibt Ihr einer Sprache treu? Ist doch nie und nimmer Praktikabel. Einen µC kann man nicht mit Python/PHP programmieren; eine Webanwendung in C geht zwar, ist aber ein Krampf. Da wären: C (nur auf µC), Python, PHP, Javascript, Grundzüge von Java, TI-Basic :( und Reverse Polnish Lisp
naja, die .net-Sprachen sind doch anders... zwar is die Grundsynthax ähnlich, aber die Bibliotheken sind komplett anders (logischerweise) und c# hat haufenweise neue Sprachkonstrukte... Und Standard-C ist nicht Objektorientiert. Ansonsten hast du die Pascal-Derivate vergessen, und es gibt haufenweise Sprachen die garnich in solche "Gruppen" passen... Ansonsten ist für mich das Mischen kein echtes Problem, Schusselfehler macht man mal (Semikolons in Sprachen die keine brauchen, i++ in Sprachen dies nicht können, ...), es ist eher, dass man öfter nachgucken muss wie denn die Bibliotheksfunktionen nun grade waren (Java vs C# vs Python vs Delphi, wobei die letzteren beiden da eher nicht das Problem sind). Gute Entwicklungsumgebung hilft dabei aber ungemein, da sie sich sofort beschwert...
Hier meine erlernten Programmiersprachen im Laufe des Ingenieurlebens... ALGOL PL1 Fortran Assembler Z80 Assembler Z8 Basic Pascal C Assembler AVR Zurückblickend würde ich sagen, dass die Programmierung immer gleich aufgebaut war und ist. Es geht immer um mathematische Algorithmen. Ob der Befehl heute „Print“ heißt und vor 20 Jahren „Output“ ist dabei unerheblich. Die Benutzung von hunderttausend Klassenbibliotheken und DotNet Kram hat eh wenig mit Programmierung zu tun. Ich würde mal prognostizieren, dass sich in 20 Jahren kein Mensch mehr für DotNet interessiert. Schleifen, rekursive Anweisungen, Zeiger, ... wird es dann aber immer noch geben. Wenn du aber nicht programmieren möchtest, sondern eine „bunte GUI“ (so heißt das wohl) zusammenschieben möchtest, dann brauchst du natürlich auch die letzte flippige Programmiersprache dazu. Mathematische Algorithmen sind dabei kontraproduktiv :-)
Soll also ein klares Ja für Multilingual sein? Okidoki
Algol habe ich auch zuerst gelernt, danach Pascal. Da war die Umstellung nicht so groß. Ich habe das Gefühl, daß die heutigen Programmiersprachen (speziell C) so eine häßliche Sytax haben, daß man einen Quelltext kaum noch überblickt. Normalerweise formuliere ich ein Programm erst auf Papier in einem deutschsprachigen Pseudocode. Dann konnte man das recht schnell in Pascal oder auch in Basic-Quelltext verwandeln. Das geht heute kaum noch, vor allen Digen nicht mit diesen OOP-Sprachen (VisualXXX) Heute verbringe ich Stunden damit, die richtige Syntax für eine Zeile zu suchen... :-( MfG Paul
Paul Baumann schrieb: > Heute verbringe ich Stunden damit, die richtige Syntax für eine Zeile > zu suchen... Das nennt man Fortschritt. PICSIM schrieb: > Soll also ein klares Ja für Multilingual sein? Das sollte heißen, das ständige Kommen und Gehen von Programmiersprachen mit etwas Abstand und gesundem Menschverstand zu betrachten.
Ich glaube, wie multilingual ein Bastler ist oder sein sollte, hängt davon ab, was er bastelt. Beispiele: - Ein Bastler, der nur reine Elektronik ohne Mikrocontroller macht, darf durchaus alingual sein. - Ein Bastler, der mit Mikrocontrollern spielt, aber bspw.mit PC-Programmierung nichts am Hut hat, ist typischerweise monolingual, und programmiert je nach Geschmack in C, Assembler oder Basic. - Ein Bastler, der nur auf dem PC programmiert, ist ebenfalls monolingual nimmt aber als Programmiersprache eher C++, Java, oder C#. - Fortgeschrittene PC-Programmierer sind bilingual und haben in ihrem Repertoire oft eine Sprache für hohe Ausführungsgeschwindigkeit (z.B. C++) und eine für hohe Entwicklungsgeschwindigkeit (z.B. Python). - Fortgeschrittene Bastler mit kombinierten µC/PC-Anwendungen sind deswegen meist trilingual. - Mit steigender Lebenserfahrung werden einige Programmiersprachen altmodisch, und der Bastler will sie nicht mehr sehen. Dann lernt er eine neu und steigert dadurch seine Multilingualität weiter. Angst, dass die Programmiersprachen irgendwann ausgehen, braucht er keine zu haben. Es gilt ja sowieso die Devise: "Learn a programming language every year" Hiermit kann der Bastler den Vorgang noch etwas beschleunigen: http://pragprog.com/titles/btlang/seven-languages-in-seven-weeks
Es ist nie schlecht mehrere Sprachen zu beherrschen. Dann kann man je nach Problem, die geeignetste auswählen. Vielleicht kennt jemand das Sprichwort: "Wenn man als Werkzeug nur einen Hammer hat, sieht jedes Problem wie ein Nagel aus" meine Liste: c µC, DSP c++ µC, PC, eher Kommandozeilen, im Job: Entwicklung PC-Prototypen C# PC, GUI-lastige Sachen java PC, portable oder GUI-lastige Sachen Delphi PC, kleine GUI-lastige Sachen (seltener) Perl PC, Mini-CMD-Tools, Verarbeitung großer Text-Datenmengen, Webseiten SQL PC, Verarbeitung großer Datenmengen, Webseiten asm µC - versuch ich zu vermeiden. asm PC - überflüssig VBA MS-Excel-Makros :( matlab/octave numerische Berechnungen gnuplot Datenvisualisierung Maxim CAS
Yalu X. schrieb: > Hiermit kann der Bastler den Vorgang noch etwas beschleunigen: > > http://pragprog.com/titles/btlang/seven-languages-in-seven-weeks Der Ansatz, auch andere Paradigmen zu lernen, ist zwar gut und richtig und das Buch ebenfalls, aber einem "Bastler" u.a. Scala, Ruby, Haskell oder Prolog d.h. völlig fremde Paradigmen im Schnellverfahren vorzusetzen, dürfte eher suboptimal sein, zumal einige der vorgestellten Sprachen imo alles andere als geeignet sind, diese Paradigmen zu lernen. Besser wäre da Standard ML oder Verwandte, Smalltalk/Ruby und zum Schluss vielleicht noch etwas Prolog. Joe G. schrieb: > Hier meine erlernten Programmiersprachen im Laufe des Ingenieurlebens... ... > Zurückblickend würde ich sagen, dass die Programmierung immer gleich > aufgebaut war und ist. Wenn man nur einen Hammer kennt oder wie hier nur ein Paradigma, das imperative, mag das so aussehen...Es gibt noch andere... > Die Benutzung von hunderttausend Klassenbibliotheken und > DotNet Kram hat eh wenig mit Programmierung zu tun. Anders lässt sich heute keine Software in angemessener Zeit und mit angemessenem Aufwand mehr entwickeln. Gerade die Bibliotheken entscheiden heute über Erfolg oder Misserfolg (nicht nur des einzelnen Projekts...). > Ich würde mal prognostizieren, dass sich in 20 Jahren kein Mensch mehr > für DotNet interessiert. Software die in/mit Java, C#, VB etc. entwickelt wurde/wird, wird es in 20 Jahren immer noch geben, so wie es heute mit Cobol, Fortran und C der Fall ist. Selbst wenn die Software, wie heute schon möglich, automatisch in eine andere Sprache übersetzt wird, behebt das nicht die Fehler im Design und/oder wandelt unwartbaren, nicht mehr oder schlecht erweiterbaren Code in das Gegenteil um. D.h. auch dann wird es darauf hinauslaufen, dass entweder, falls Geld und Zeit vorhanden sind, eine Neuentwicklung gestartet wird oder, was wesentlich wahrscheinlicher ist, die Codebasis bis zum geht nicht mehr "weiterverwendet" wird. > Schleifen, rekursive Anweisungen, Zeiger, ... wird es dann aber immer noch geben. Z.T.... > Wenn du aber nicht programmieren möchtest, sondern eine „bunte GUI“ (so > heißt das wohl) zusammenschieben möchtest, dann brauchst du natürlich > auch die letzte flippige Programmiersprache dazu. Mathematische > Algorithmen sind dabei kontraproduktiv :-) Für kleine GUIs, vielleicht, bei größeren Sachen, ist es reine Mathematik, auch wenn sie nicht unbedingt als solche wahrgenommen wird...
Ich bin auch ehr Multilingual ausgerichtet: C+Bascom für µC: Bascom wenn es flott entwickelt sein soll, nicht Ressourcen lastig etc C wenns profesioneller sein soll- Ethersex z.B. atm^^ C# als Hauptsprache für den PC: muss nichts Rechenintensives machen, gute GUI und Datenbankanbindung ist da wesentlich wichtiger, ausserdem unterstützt Visual Studio sehr sehr gut! Java (JSP)+PHP für Webseiten Pascal bzw MuPAD, für mathematische Geschichten(habe aus der Schule noch das CAS) Je mehr man kann, desto breiter ist man aufgestellt, und desto besser weiß man, wie man was am besten löst. Vorallem geht es flotter Aber das mit dem Semikolon mache ich auch gerne in Bascom, oder das $ vergessen in php
Arc Net schrieb: >> Die Benutzung von hunderttausend Klassenbibliotheken und >> DotNet Kram hat eh wenig mit Programmierung zu tun. > > Anders lässt sich heute keine Software in angemessener Zeit und mit > angemessenem Aufwand mehr entwickeln. Gerade die Bibliotheken > entscheiden heute über Erfolg oder Misserfolg (nicht nur des einzelnen > Projekts...). Da stimme ich dir voll zu! Der Programmierer hat keine Bibliothek zur Berechnung von Eigenwerten und Eigenformen gefunden und wollte das Projekt mit der gewählten Programmiersprache deshalb sterben lassen. Auf die Idee SELBST ein kleines Unterprogramm zur Berechnung zu schreiben ist er nicht gekommen. Diese mathematischen Algorithmen waren ihm entweder fremd oder sie ließen sich nicht so einfach mit der Maus zusammenschieben :-(
> Ist der Hobbybastler Multilingual veranlagt?
Ich würde sagen: Nein. Eine handvoll Programmiersprachen beherrsche ich
mittlerweile, habe mich mit der Zeit allerdings vom Bastlertum (fast)
gänzlich verabschiedet (oder ich lasse mich jetzt bezahlen fürs Basteln,
kann man sehen wie man will;)...
Hätte ich nur die Möglichkeit Abends oder am Wochenende Elektronik zu
machen, wäre ich wohl bei ASM (ich mags einfach) für uC und VB fürn PC
geblieben.
Vlad Tepesch schrieb: > Vielleicht kennt jemand das Sprichwort: > "Wenn man als Werkzeug nur einen Hammer hat, sieht jedes Problem wie ein > Nagel aus" In den 60 zigern sollte die KYBERNETIK alle technischen und ökonomischen Probleme wissenschaftlich exakt und in kurzer Zeit lösen. Mit den Programmiersprachen Lisp und Prolog war man in den 80 zigern von der künstlichen Intelligenz nur noch einen Hauch weit entfernt. Dann waren Expertensysteme DIE Lösung zur Bewältigung aller komplexer Aufgaben. Vielleicht kennt jemand das Sprichwort: „Es wind nicht alles so heiß gegessen, wie es gekocht wird“
Joe G. schrieb: > ... Ich verstehe den Zusammenhang zwischen dem Quote meiner Aussage und der deinigen nicht.
Nun du wolltest sagen, dass jede Programmiersprache mehr oder weniger gut für ein spezielles Problem verwendet werden kann, sozusagen immer ein Spezialwerkzeug statt eines universellen Hammers darstellt. Ich wollte sagen, dass ich schon viele Spezialwerkzeuge (Programmiersprachen) habe kommen und gehen sehen. Übrig geblieben sind robuste Mehrzweckwerkzeuge (Hammer).
Joe G. schrieb: > Da stimme ich dir voll zu! Der Programmierer hat keine Bibliothek zur > Berechnung von Eigenwerten und Eigenformen gefunden und wollte das > Projekt mit der gewählten Programmiersprache deshalb sterben lassen. Auf > die Idee SELBST ein kleines Unterprogramm zur Berechnung zu schreiben > ist er nicht gekommen. Diese mathematischen Algorithmen waren ihm > entweder fremd oder sie ließen sich nicht so einfach mit der Maus > zusammenschieben :-( Kleines Unterprogramm? Simple Eigenwertprobleme lassen sich zwar auch symbolisch recht einfach lösen (passende Sprache vorausgesetzt), allgemein sieht das aber deutlich anders aus. Da geht's nicht nur darum geeignete Algorithmen zu finden, sondern auch darum diese so zu implementieren, dass sie stabil, robust und zumeist auch schnell sind und das ist nicht trivial und mal eben so mit einem kleinen Unterprogramm lösbar. Buchempfehlung: J. H. Wilkinson, The Algebraic Eigenvalue Problem ISBN 9780198534181
Arc Net schrieb: > Kleines Unterprogramm? > Simple Eigenwertprobleme lassen sich zwar auch symbolisch recht einfach > lösen (passende Sprache vorausgesetzt), allgemein sieht das aber > deutlich anders aus. Das war doch nur ein Beispiel. Ich hätte auch Dgl, oder Matrixinversion, oder Volumenintegral, oder, oder sagen können. Oft habe ich einfach den Eindruck, immer wenn es keine Bibliothek dafür gibt geht es nicht weiter.
Vlad Tepesch schrieb: > "Wenn man als Werkzeug nur einen Hammer hat, sieht jedes Problem wie ein > Nagel aus" Jo solch ein Exemplar habe ich mit im Büro sitzen, sein Hammer heißt EXCEL. Der hat sich sogar schon eine Art Dissambler mit Excel gebastelt. Ganz toll sind auch mehrfach verknüpfte Dateien/Tabellenblätter. ^^ Zurück zum Thema: Im laufe der letzten Jahre habe ich auch einige Programmiersprachen sprechen gelernt. Angefangen mit AmigaBasic, C/C++, ASM für 8051, Java, Pascal, VBA, PHP, Labview. Mittlerweile beschränke ich mach auf C - µC-Programmierung Java - GUI, Webseiten (JSP), Datenbank Labview - GUI und um schnell mal was zusammen zu klicken Also laut Yalu -> fortgeschrittener Bastler. :D Yalu X. schrieb: > - Fortgeschrittene Bastler mit kombinierten µC/PC-Anwendungen sind > deswegen meist trilingual. Dank diesem Forum demnächst C++ mit Qt für GUI und mal schauen was man sonst noch so anstellen kann. ;)
Joe G. schrieb: > Das war doch nur ein Beispiel. Ich hätte auch Dgl, oder Matrixinversion, > oder Volumenintegral, oder, oder sagen können. Oft habe ich einfach den > Eindruck, immer wenn es keine Bibliothek dafür gibt geht es nicht > weiter. Da könnte man auch antworten, oft hat man einfach den Eindruck, dass der Aufwand, der nötig ist um so was sauber zu lösen, massiv unterschätzt wird. Einfach mal ansehen welche Verfahren zur numerischen Lösung der genannten Probleme angewandt werden (müssen)... Und da wären wir wieder bei den Sachen von oben: Wenn's wirklich schnell sein muss bleiben nur die üblichen Verdächtigen übrig...
Hilfe das bereitet mir noch echte Magenschmerzen. Also ich will in die Trilinguale richtung gehen. (wie empfohlen) Zwar aus anderen Gründen wie in der Erklärung aber egal. VBA und C sind gesetzt. Nur was kommt als drittes? Favoriten sind: C++, C#, Java Meine Grobeinschätzung: C++: am kompliziertesten, kann auch Android!!!, mit .Net günstig zu nutzen, Geschwindigkeit mir egal, hab ich mich schonmal mit beschäftig, am nächsten an C dran C#: MS-Produkt :(, kein Android!, MS-Office programmierung!, soll einfach sein, läuft nur auf windoof was mir reicht, neu Java: für mich vollkommen neu, Android, Internet.... also relativ umfangreich,kein MS Office!!!
Bei mir schaugt eher so aus: C(++) => AVRs (und in der Arbeit PICs, grmpfh) FreeBasic/Python => Aufm PC (Vor allem Python ist auf Linux äußerst praktisch) Ansonsten noch ein bisschen PHP-gebastel Für GUI-Anwendungen hab ich noch nix so richtiges... :( Mal Python+QT angucken... Ob das jetzt Multilingual ist - k.a. - Kann wohl jeder so sehen wie er will Aber wohl eher nicht...
Also ich benutze: C / Assembler : µC Controller C / C++ : Schnelle Berechnungen ohne GUI, oder mit SDL / OpenGL C++, Java, Python: GUI Programmierung (je nach Bedarf mit SDL / pygame, wxWidgets) Python, Bash Scripting: Kleine Skripte um PC <--> µC Datenaustausch/ Synchronisierung zu machen PHP, Python: Webseiten serverseitig Javascript: Webseiten clientseitig SML, Lisp: Vorallem akademisch um Sachen auszuprobieren Ansonsten: XML, SQL, etc wo notwendig. Ich würde vorallem versuchen die verschiedenen Arten von Sprachen kennenzulernen, und nach der 3. oder 4. Sprache sollte es eigentlich kein Problem mehr sein bei Bedarf weitere Sprachen zu lernen. Als Grundklassen verstehe ich: maschinennah: Assembler prozedural / imperativ: C, BASIC, Pascal, Fortran objektorientiert: C++, Java, C# funktional: Lisp, SML, Haskell Bei den moderneren Sprachen (Java, C#, Python) finde ich es sehr angenehm, dass viele Grundlibraries schon vorhanden sind (XML, Netzwerk, etc...) während man für exotischere Open Source Projekte meist doch recht schnell auf C / C++ zurückfällt (OpenCV, Robot Operating System, ...)
PICSIM schrieb: > C++: > am kompliziertesten, kann auch Android!!!, mit .Net günstig zu nutzen, Nein. Mit .Net lässt sich C++ nicht nutzen. Es gibt zwar "C++/CLI" bzw. "Managed C++", aber beides sind .Net-Sprachen und kein C++.
Ok JAVA oder C# Kriterien: Einsatzmöglichkeiten (Web, Android, Datenbanken, MS Office) evtl Kosten Support (Forum) Lernbarkeit
Meine Favoriten: C mit etwas elegantem C++ gewürzt und wenns schneller laufen soll inline Assembler dazu. C# und Java ist mir zu langsam und abstrakt und ich kann nicht richtig reindebuggen. Perl ist für Obfuskation zuständig, PHP ist fast wie C und der Rest ist in Details anders, aber meistens langsamer oder größer oder beides. Warum mag ich C/C++; die geforderten Klammern zwingen den Programmierer übersichtlicher zu coden, jedenfalls meistens. Das Wichtigste für mich ist eine komfortable IDE mit API-Hilfeanbindung für das Zielsystem und schnell mal zur Definition/Deklaration springen zu können ist auch was wert. User Interface Programmierung ist ein anderes Thema. Das würde mich auch mal von anderen Kollegen interessieren.
Joe Redfish schrieb: > Das Wichtigste für mich ist eine komfortable IDE mit API-Hilfeanbindung > für das Zielsystem und schnell mal zur Definition/Deklaration springen > zu können ist auch was wert. Meistens programmier ich meine µC noch mit Textpad, aber ansonsten verwende ich eigentlich Eclipse für Java, Python, PHP, C und C++ sowie XML und CSS, Eclipse ist zwar noch nicht meine Traum IDE, aber es ist schon sehr praktisch ein einheitliches Layout für soviele verschiedenen Sprachen und Betriebssysteme zu haben.
Verwirrter Anfänger schrieb: > Meistens programmier ich meine µC noch mit Textpad, Ich habe leider auch noch keine gute IDE für die AVRs gefunden Bascom ist nutzbar, hoffe mal ehr auf AVR Studio 5, was ja aufm Visual Studio aufsetzten soll? Kennt jemand was gutes für den Hobby-C-AVR-Bereich (Kosten überschaubar) am besten Unterstützung STK 500 & etc.
PICSIM schrieb: > Ok JAVA oder C# > > Kriterien: > > Einsatzmöglichkeiten (Web, Android, Datenbanken, MS Office) > evtl Kosten > Support (Forum) > Lernbarkeit Wenn Android bzw. Smartphone ein wichtiges Kriterium ist bleibt nur Java übrig, C# ist ausschlisslich Windows (wenn man mal von Mono absieht). Java läuft auf so ziemlich jedem aktuellen Smartphone auch viele ältere Handys haben eine VM. Datenbanken und Web (Client & Serverseitig) gehen mit Java ziemlich gut. Was du aber mit MS Office meinst ist mir nicht ganz klar. Bei den Kosten und Support unterscheiden sich beide kaum, beides gibt es kostenlos, C# in Form der Express-IDEs. Marcus B. schrieb: > Kennt jemand was gutes für den Hobby-C-AVR-Bereich (Kosten überschaubar) > am besten Unterstützung STK 500 & etc. Ich habe bisher immer CodeBlocks verwendet, Software fürs flashen/STK 500 musst du aber selbst einbinden. Werde demnächst aber wohl auch auf Eclipse umsteigen.
Stichwort VSTO. Ich denke, dass wird irgendwann VBA ablösen. Dies gibt es aber auch noch bei Visual Studio Professional, was ja bekanntlich was kostet. http://en.wikipedia.org/wiki/Visual_Studio_Tools_for_Office Also sehe ich das jetzt richtig, dass sich JAVA und C# im Sinne von Web- und Datenbankanwendungen und GUI nicht viel nehmen. JAVA ist dann mehr für Android, wobei man C# mit Office verknüpfen kann. BTW: Lerne ich nicht so oder so bei beiden immer neu? Es ist doch bestimmt etwas anderes hinsichtlich der Programmierung, ob ich jetzt Web-Anwendungen, Datenbanken oder sonst was programmiere. Ich glaub ich bastel mir mal in beiden ein Hello World ;) Bei JAVA wäre Eclipse als IDE eine gute Wahl richtig? Danke!
Du machst den gleichen Fehler den du am Anfang angesprochen hast. Du willst EINE neue Sprache für komplett unterschiedliche Anforderungen: Wenn du irgendwelche Erweiterungen für Office machen willst brauchst du dafür eine MS spezifische Sprache. Wenn du Android programmieren willst brauchst du eine passende Sprache. Im einen Fall ist das evt. Java, im anderen vieleicht C# C# und Java ähneln sich in der Synatx, wenn man eine kann ist die andere relativ gut erlernbar. Was du völlig übersiehst ist der Paradigmenwechsel, Sowohl C# als auch Java sind objektorientiert. Du kennst bisher nur prozedural. Bis du wirklich objektorientiert denkst und sauber designest vergeht mindestens ein Jahr mit viel Übung. Das ist die Crux an C++, man kann immer noch prozedural programmieren und in dem Zeitraum in dem ich mich damit beschäftigen musste waren nahezu 100% aller Programme ein wüstes Gewurstel aus C und C++. Bei großen Projekten mit hunderten von Modulen und mehreren 100.000 Zeilen Code kein Spass! Mein Tipp: Was ist dir wichtiger, Android oder MS-Office? Nimm das passende und lerne die richtig (vor allem OO-Design). Die andere wird dann nicht mehr so schwer sein.
Udo Schmitt schrieb: > Das ist die Crux an C++, man kann immer noch prozedural programmieren > und in dem Zeitraum in dem ich mich damit beschäftigen musste waren > nahezu 100% aller Programme ein wüstes Gewurstel aus C und C++ Das ist ein Grund warum ich vor ein paar Jahren von C++ weggegangen bin und Java gelernt habe. In Java gibt es dieses Gewurstel einfach nicht. Ein anderer Grund waren die M$-Vergewaltigungen an C++ (z.B. MFC). PICSIM schrieb: > Es ist doch > bestimmt etwas anderes hinsichtlich der Programmierung, ob ich jetzt > Web-Anwendungen, Datenbanken oder sonst was programmiere. Jain, die grundsätzliche programmierung bleibt gleich. Du wirst andere Klassen für Web und Datenbanken verwenden. Ausserdem wirst du bei Web mit HTML und evtl. XML bennötigen und bei Datenbanken solltest du Kenntnisse über SQL haben. Java bietet sogar die Möglichkeit ein Programm zu schreiben und es unverändert auf den Desktop zu verwenden, als Applet in eine Webseite einzubinden oder auf dem Smartphone auszuführen. Das ist allerdings keine Übung für einen Anfänger :D PICSIM schrieb: > Bei JAVA wäre Eclipse als IDE eine gute Wahl richtig? Eclipse hat den Vorteil du kannst es für C/C++ und Java verwenden.
> Oder seid ihr Multilingual? Programmiersprachen haben ihre Vor- und Nachteile. Bei der erstmaligen Auswahl kann man diese Eigenschaft schlecht einschätzen. Erst wenn man sie länger nutzt, dringen die praktisch bedeutsamen Eigenschaften ins Bewußtsein. Dann dauert es manchmal nicht mehr lange, bis eine andere Sprache mit anderen Eigenschaften für anstehende Aufgaben verlockender erscheint. Manche mögen Monate brauchen, bis sie dieses Stadium erreichen, andere vielleicht Jahre. Das hängt von der Intensität der Nutzung und der Komplexität der Programmiersprache sowie den Anforderungen der eigenen Projekte ab. Wer ständig ähnliche Projekte umsetzt, mag mit "seiner" Sprache sein Leben lang glücklich bleiben. Wer ständig auf neue Weise gefordert wird, vermutlich nicht. Wie sich diese Umstände in seinem Fall entwickeln werden, weis ein Einsteiger im Regelfall nicht. Erfahrungen Anderer sind daher ohne genaue Kenntnis dieser Umstände wenig hilfreich. Das zeigen bereits die bisherigen Antworten, die den Einsatzzweck der jeweils genannten Programmiersprachen andeuten. Sinnvoller sind Fragestellungen wie: Aufgrund welcher Eigenschaften eignet sich die Programmiersprache X für Projekte des Typs Y besonders und welcher Aufwand ist mit ihrem Erlernen und ihrer Handhabung verbunden? > Liege ich mit meiner Vereinfachung richtig C/Basic oder unterscheiden > sich die Sprachen doch nochmal so stark, dass ich Sie vom Schreibstyle > her komplett neu lernen muss? Früher hat man vor BASIC als erster Programmiersprache gewarnt (Stichwort Spaghetti-Code). Man würde sich den Programmierstil fürs Leben verderben. Ich bilde mir ein, bei Anwendungsoftware im Bürobereich noch heute zu erkennen, ob der Entwickler am Anfang seiner Karriere als BASIC-Programmierer gestartet ist. Moderne BASIC-Varianten haben nachgebessert bis hin zu klickbaren Entwickungsoberflächen, so dass ihr Einsatz bei geringen semantischen Anforderungen (Daten rein - Verarbeitung - Daten raus) oder dem Wunsch nach geringen Entwicklungsaufwand sinnvoll erscheint. Das gilt aber nur im Rahmen ihres Anwendungsbereiches. Für hochperformante Anwendungen oder für leistungsschwache Hardware würde man wohl andere Alternativen ins Auge fassen wollen. Weiß man vorher, dass man maschinennah programmieren muß, z.B. für Hardwaretreiber oder Kernelprozeduren oder Geräten mit kleinen Daten- und Programmspeicher oder für leistungsschwache CPUs, wird man eher C als BASIC wählen wollen. Je extremer die Anforderungen ausfallen, umso eher wird man sogar ganz oder teilweise auf Assembler setzen wollen. C wird von manchen Programmierern überspitzt formuliert als aufgebohrter Assembler bezeichnet. C ist ein ganz anderes Kaliber als BASIC. C fällt deutlich maschinennäher aus als moderne BASIC-Varianten. Mit C wird man stärker gezwungen, abstrakt zu denken und bis ins Detail konsequent vorzugehen. Hinzu kommt, dass die Maschinennähe der Sprache vieles umständlicher macht, als in BASIC. Wer in C programmiert, muß sich um viel mehr Details kümmern, als in BASIC. Das mag abschrecken. Der Mehraufwand beim Entwickeln schlägt sich aber auch in einem deutlich effektiveren Ergebnis nieder. Das richtige Vorgehen muß aber auch erlernt werden. Heute ist es modisch geworden, objekt-orientiert zu programmieren. Ich finde, damit verlagert man nur die Komplexität aus der Phase der Entwicklung in die Phase des Testens. Moderne BASIC-Variante bieten objektorientierte Features, C nicht. Wer mit C objektorientiert programmieren will, muß sich mit C++ anfreunden. In der Entwicklergemeinde ist C++ ob seiner Besonderheiten umstritten. Als Kriterium der Wahl zwischen C und BASIC würde ich dieses Feature nicht als den entscheidenden Faktor ansehen wollen. Es kommt eben auf die eigenen Vorlieben an, derer man sich im Verlaufe der Zeit bewußt wird. C-Code sieht kryptisch aus. Moderner BASIC-Code ist langatmig. Was davon gefällt, bleibt Geschmackssache. Von dieser Frage die Wahl zwischen beiden abhängig zu machen, wäre verfehlt, weil beide Sprache für andere Anwendungsbereiche entworfen sind. Wer C beherrscht, wird kaum Schwierigkeiten haben, später einmal BASIC zu lernen. Die Schwierigkeit, BASIC zu erlenen, besteht dann eher darin, die dort vorhandenen Komfortfunktionen auswendig zu lernen. Der umgekehrte Weg wird sicher schwieriger ausfallen. Erst mit einer Programmiersprache wie C (oder anderer Alternativen ohne BASIC & Konsorten) lernt man das Wesen der Programmierung im Kern kennen und ist für alle zukünftig kommenden Anforderungen gut gerüstet. Wer nur BASIC kennt, wird manchmal erst mal schlucken müssen, um im Einzelfall einen gangbaren Weg zu finden. Das soll aber nicht darüber hinweg täuschen, dass beide Programmiersprachen prinzipiell geeignet sind, alle lösbaren Probleme zu bewältigen (Stichwort Turing-Vollständigkeit).
Also ich bin der Meinung, man sollte seine Nase mal in alle Paradigmen stecken. Somit sollte man aus folgenden Sprachen mal mindestens mit einer mal ein wenig gespielt haben: (Die Beispiele in den Gruppen sind nicht vollständig und nur eine grobe Einordnung) "Maschinennahe unstrukturierte Sprachen": (altes) BASIC (mit Zeilennummern!), Assembler Prozedurale Sprachen: Pascal, C (vor C unbedingt Assembler machen) Funktionale, Symbolische Sprachen: Lisp, Prolog Objektorientierte Sprachen: Smalltalk, Erlang "C++"-objektorientierte Sprachen: C++ (vorher unbedingt Assembler lernen), C#, OOPascal, Java "Getting Things Done"-Sprachen: bash, perl, awk, sed, VBA, Python Es geht nicht darum, dass man die Sprachen bis ins letzte Detail beherrscht, sondern darum, dass man genügend darüber weiß, welche Sprache man für ein gegebenes Problem sinnvoll anwenden kann. Was ich für nicht sinnvoll halte ist es, momentanen Trends hinterher zu laufen. In 10 Jahren schaut die Welt wieder ganz anders aus. Modesprachen erkennt man häufig daran, dass sie versuchen, andere Sprachen zu kopieren. Das ist der Grundstock. Für Beruf und Hobby kann man sich natürlich noch in ein paar der Sprachen detailiert einarbeiten. Ich persönlich mag die Pascal-Schiene, damit komme ich gut zurecht, besonders seit dem ich meistens nur noch Textdateien verarbeite. Für GUI nehme ich den Delphi Klon Lazarus.
M. K. schrieb: > Wenn Android bzw. Smartphone ein wichtiges Kriterium ist bleibt nur Java > übrig, C# ist ausschlisslich Windows (wenn man mal von Mono absieht). Smartphone ist nicht einfach Java... iOS = ObjectiveC, Android = Java (C++ für native Anwendungen), webOS = JavaScript + HTML (C++ für native Anwendungen), Symbian = C++/Qt, BlackBerry = Java (C++), WP7 = C#/VB/F# Android, iOS und webOS könnte man auch mit C# (bzw. fast allen CLI-Sprachen) programmieren (monoTouch, monoDroid, monoWebOS). Andere Cross-Platform-Tools nutzen dagegen z.B. HTML + JavaScript (appcelerator, UnityMobile, PhoneGap), Rhomobile z.B. Ruby und sowohl Android, als auch z.B. iOS oder WP7 haben WebBrowser-Controls einbinden d.h. man kann auch dort sehr viel mit HTML erschlagen. JavaME kann man dagegen getrost in die Tonne treten, da es hoffnungslos veraltet ist und die Möglichkeiten der aktuellen Systeme nicht vernünftig nutzt und kaum noch verbreitet ist. Android + RIM + iOS sind z.Z. die Marktführer, Symbian verliert nur noch Marktanteile, RIM verliert z.Z. in fast allen Märkten, selbst iOS verliert in einigen Märkten. Wenn man jetzt nicht nur aus reinem Interesse Apps entwickeln will, stellt sich die Frage was man macht: In die "Haifischbecken" von Android und iOS oder in die (mehr oder weniger stabilen) Nischen der anderen Systeme. http://www.guardian.co.uk/technology/2011/apr/18/smartphone-market-android-win-nokia-rim-lose > Datenbanken und Web (Client & Serverseitig) gehen mit Java ziemlich gut. Falls man mal LINQ und/oder SL eingesetzt hat, will man nicht mehr zu Java zurück...
Arc Net schrieb: > Smartphone ist nicht einfach Java... Das war jetzt auf die beschränkte Auswahl C# oder Java bezogen. Arc Net schrieb: > Android, iOS und webOS könnte man auch mit C# (bzw. fast allen > CLI-Sprachen) programmieren (monoTouch, monoDroid, monoWebOS). M. K. schrieb: > C# ist ausschlisslich Windows (wenn man mal von Mono absieht). Arc Net schrieb: > Falls man mal LINQ und/oder SL eingesetzt hat, will man nicht mehr zu > Java zurück... Kenne ich nicht, kann ich also nichts zu sagen.
OK, also hol ich mir jetzt für meinen Status 2011 noch nen Tutorial für Assembler und nen Buch für JAVA. Dann bin ich Multilingual ;) "Maschinennahe unstrukturierte Sprachen": -> Assembler (comming soon) Prozedurale Sprachen: -> C Funktionale, Symbolische Sprachen: Pah! Objektorientierte Sprachen: Pah! Pah! "C++"-objektorientierte Sprachen: -> Java (comming soon) "Getting Things Done"-Sprachen: -> VBA
PICSIM schrieb: > Funktionale, Symbolische Sprachen: > Pah! > > Objektorientierte Sprachen: > Pah! Pah! > > "C++"-objektorientierte Sprachen: > -> Java (comming soon) Was genau möchtest du damit zum Ausdruck bringen? Ist Pah!Pah! die OO-Variante von Pah! oder was? ;)
wobei er sich aus Christian Berger schrieb: > "Getting Things Done"-Sprachen: > bash, perl, awk, sed, VBA, Python die schlechteste rausgesucht hat: PICSIM schrieb: > "Getting Things Done"-Sprachen: > -> VBA weibei man bei sed ja nicht wirklich von Sprache sprechen kann. dennoch gehört es mit grep und perl zu meinen must have programmen
@PICSIM: Probier' mal LISP oder SCHEME, damit lernst du einen vollkommen anderen Zugang als mit C und Konsorten.
Zwie Blum schrieb: > @PICSIM: Probier' mal LISP oder SCHEME, damit lernst du einen vollkommen > anderen Zugang als mit C und Konsorten. naja - praktischer Nutzen quasi gleich null
Um die Frage das TO zu beantworten: Ich bin Hobbybastler durch und durch, mein Job hat nichts mit Elektronik und Programmieren zu tun. Ursprünglich PC Programmierung gemacht bevor ich mit uC angefangen habe. Mein Leib und Magensprache ist C++, für meine AVRs und Arms habe ich auf C "umgelernt". Da sind ja doch viele kleine Unterschiede. Am PC nutze ich daneben noch Java, das kommt immer auf die konkrete Fragestellung und, ich gebe zu da bin ich Faul, ob für ein Problem schon Libraries oder ähnliches vorhanden sind. Assembler auf den uCs fasse ich nur mit spitzen Fingern an, wenn es für Optimierungen absolut notwendig ist und um mal zu debuggen. Ganze Programme schreibe ich damit nicht. Wenn der Controller für mein C Programm zu klein ist, nehme ich den nächst größeren. Ansonsten habe ich noch ein paar Erfahrungen mit Pascal / Delphi und Basic wobei ich vor allem mit letzterem nie warm geworden bin - da sieht auch sauberer Code irgendwie immer total unstrukturiert für mich aus. Zurzeit lese ich noch Spaßeshalber "Land of Lisp" - einfach weil dieses Buch gut geschrieben ist und LISP ganz anders ist als mein üblicher Horizont.
Vlad Tepesch schrieb: > weibei man bei sed ja nicht wirklich von Sprache sprechen kann. Doch natürlich ist sed auch eine Sprache. Mehr noch: Sie ist sogar Turing-vollständig: http://en.wikipedia.org/wiki/Sed#History ;-) Vlad Tepesch schrieb: > Zwie Blum schrieb: >> @PICSIM: Probier' mal LISP oder SCHEME, damit lernst du einen vollkommen >> anderen Zugang als mit C und Konsorten. > > naja - praktischer Nutzen quasi gleich null Ich würde sagen, mit Scheme hat man ähnlich viele Möglichkeiten und Einschränkungen (aber natürlich nicht die gleichen) wie bei VBA. Ich würde beides nicht lernen, aber wenn ich müsste, dann eher noch Scheme. Mit "richtigem" Lisp (Common Lisp) sind die Möglichkeiten schon wesent- lich weitreichender. Und da man als Hobbybastler keine Vorgaben vom Chef bzgl. der Wahl der Programmiersprache hat, warum sollte man nicht Lisp verwenden? Einige Freaks, für die beim Programmieren der Weg das Ziel ist, tun das ja durchaus.
naja, mal eben eine gui? ein wenig textprocessing mit regulären ausdrücken? uart-Kommunikation mit dem µC? für keinen dieser Standardanwendungsfälle ist scheme (CL kenne ich nicht) wirklich praktisch die Sprachen haben sicher im akademischen bereich ihre berechtigung, oder um damit algorithmische Probleme zu lösen, aber für die Praxis sehe ich da keine große Bedeutung. Da fällt mir das wieder ein: http://xkcd.com/224/ einfach genial! Man beachte auch den Tooltip-Text ;)
Mir gefällt der da besser: http://xkcd.com/297/ "Praktisch" liegt im Auge des Betrachters. Der Witz bei LISP liegt ja eben darin, dass der übliche Weg nicht zum Ziel führt :-)
Vlad Tepesch schrieb: > naja, mal eben eine gui? > ein wenig textprocessing mit regulären ausdrücken? > uart-Kommunikation mit dem µC? > > für keinen dieser Standardanwendungsfälle ist scheme (CL kenne ich > nicht) wirklich praktisch Wie ich oben geschrieben habe, sind die Möglichkeiten von Scheme schon etwas eingeschränkt, aber das trifft eben auch für VBA zu. Um Scheme mit VBA vergleichen zu können, muss man eine Scheme-Implementation betrachten, die wie VBA zum Schreiben von Erweiterungen für bestehende Anwendungen dient, also z.B. Guile. Als Erweiterungssprache hat Guile ganz ähnliche Fähigkeit en wie VBA. Der Hauptunterschied liegt (neben dem völlig anderen Sprachkonzept) darin, dass man mit Guile keine und mit VBA nur MS-Office-Anwendungen erweitern kann.
Also wenn jemand mal SCHEME probieren möchte, dem kann ich http://racket-lang.org/ ans Herz legen. Doku gibt's hier: http://docs.racket-lang.org
PICSIM schrieb: > Ist der Hobbybastler Multilingual veranlagt? Ja, würde ich sagen. Bisher wurde es nicht genannt, aber man darf nicht vergessen dass hinter den Symbolen eines Elektronikplans ebenso eine Sprache steckt. Hinzu kommt, dass wohl jeder Bastler nochmal eine eigene Symbolik beim Skizzieren von Projekten verwendet.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.