Wahl der Programmiersprache für ein Projekt / Erfahrungen?

Hallo!

k_e_x schrieb:
  • C/C++ ggf. mit Qt oder GTK als GUI?
  • Java?
  • Go?
  • Swift?
  • Rust?
Zum Vergrößern anklicken....

C++ mit QT und GTK mit C oder C++ funktioniert super. Sowas wie QT Creator (wenn man IDEs mag) ist nett.

Zu Java schweige ich mal.

Go ist etwas, was ich ganz gerne habe, aber ich glaube nicht, dass es (derzeit) deinem Anforderungsprofil entspricht. Gründe: Auch wenn du QT und GTK-Bindings hast ist das nicht ganz so ausgereift, wie du vielleicht magst. Ich glaube nicht, dass es generell viele Go-Programmierer gibt, die ähnliches tun, wie du. Insofern müsstest du dir viel selbst bauen (was ja durchaus Spaß machen kann).

Swift ist sehr, sehr stark auf iPhone-App-Entwicklung fokussiert und selbst da raten viele Leute davon ab, weil zu neu und eventuell nur ein Trend. Kann aber dazu sonst nicht viel sagen.

Mit Rust wird einiges an Low-Level-Programmierung gemacht und es gibt auch diverse GUI-Frameworks. Allerdings eben recht neu, kleine Community und ähnlich wie bei Go wahrscheinlich viel zum komplett selbst bauen.

Was deine anderen Anforderungen betrifft.
  • Alle sind Cross-Platform (Go bis hin zu Plan9)
  • GUI, mit allem Möglich, allerdings wirst du mit C/C++ am Besten fahren
  • Stabil - Alle Sprachen werden in Production eingesetzt. Was Stabilität angeht sind Rust und Swift wohl weiter unten angesiedelt (weil neuer), dann Go (auch weil das Projekt von Anfang an sehr starken Fokus auf eine fertige Spezifikation und Kompatibilität hatte) in der Mitte und C/C++ und Java dürften die Stabilisten Sprachen sein.
  • Kommunikation mit USB: Denke das geht mit allen genannten Sprachen einigermaßen gut. Nur bei Swift weiß ich nicht, wie das geht.
  • Der Punkt mit der Auslieferung als Binärdatei. Da fällt Java wohl weg? Swift weiß ich nicht, Go definitiv (als einzelne Datei - in Go ist ein statisches Binary ohne irgendwelche externen Abhängigkeiten der Standardfall und Cross-Compiling ein Traum) und Rust auch.
  • Einfachheit von Code: Bei C, C++ und Java hast du den Vorteil, dass die das wohl beherrschen/lesen können. Go hat den Vorteil, das es eine kleine, sehr schnell erlernbare Sprache ist. Swift ist komplexer und bei Rust kommt, selbst wenn die Sprache nicht per se schwierig ist, hinzu dass man bestimmte Konzepte verstehen muss.
  • Zum letzten Punkt kann ich leider nicht viel sagen.
Alles in allem würde ich wohl bei einem derartigen Projekt C/C++ nehmen. Tatsächlich abraten würde ich aber nur von Swift.

Wenn du Rust nehmen willst. Es gab mal jemanden, der Rust an der Uni für OS-Entwicklung verwendet hat. Dazu sei angemerkt, dass das schon ein Weilchen her ist und sich seit damals sehr viel getan hat.
 
Viel wichtiger als die Frage der Sprache ist die Klärung von Dokumentation.
Wenn ich eine umfangreiche Dokumentation hat (die auch gern mal 50% der reinen Programmierarbeit betragen darf) ist es doch im Prinzip egal, welche Sprache ich nutze.
 
bananenBrot schrieb:
Viel wichtiger als die Frage der Sprache ist die Klärung von Dokumentation.
Wenn ich eine umfangreiche Dokumentation hat (die auch gern mal 50% der reinen Programmierarbeit betragen darf) ist es doch im Prinzip egal, welche Sprache ich nutze.
Zum Vergrößern anklicken....
Im Prinzip schon, es wird nur niemand COBOL lernen wollen, wenn das verwendet werden sollte ;)
 
Fuer die Hardwareumsetzung wuerde ich eher auf Verilog/System Verilog setzen. Vhdl ist fuer FPGA Programmierung meistens zu umstaendlich und mit OpenCl bekommst du die direkte Hardwareansteuerung nicht hin. So wie sich das anhoert kommst du um eine HDL Sprache erst mal nicht herum. Es gibt zwar Loesung wie Xilinx HLS, aber selbst da muss einiges an know-how einfliessen. Wir haben fuer die Auslese der Testsysteme meistens 1Gbit/10Gbit Ethernet oder USB Controller von Cypress mit eigenem
Microcode genutzt, was meistens ganz simple Protokolle waren. Alles darueber wurde dann in C++ mit Qt, oder jetzt neu in Python geloest. Mit wxpython laesst sich dann auch noch schnell eine GUI drumherum bauen damit Studenten das auch schnell bedienen lernen. Meistens ging es dabei eh um die Analyse der Sensordaten und nicht um deren Auslese. ;)

Viel Java geschrieben habe ich selbst nicht, aber die meisten Anwendungen, die ich kenne kann man in die Tonne kloppen, also davon wuerde ich bei solchen Projekten definitiv die Pfoten von lassen. Wenn es realtime Anwendungen sind, kommst du um eine sehr Hardware nahe Sprache wie C/C++ sowieso nicht herum. Um schnell ein Testsystem aufzusetzen ist Python vermutlich die beste Wahl.
 
Hi,

Kamikaze schrieb:
Wie ich schon sagte, bei FPGAs geht inzwischen auch OpenCL. Das ist nicht nur einfacher zu programmieren als VHDL, das Fitting wird dadurch auch einfacher.
Zum Vergrößern anklicken....

Ich bin daran interessiert mit FPGAs zu experimentieren. Mit VHDL habe
ich schon ein bisschen im Kontext mit Devices von *ltera und Konsorten
experimentiert und war angesichts des Oekosystems, seitens *ltera und
Konsorten, leicht angewidert, da quasi das Progarmmieren von FPGAs im
Kontext mit FreeBSD nicht wirklich moeglich ist (bzw. wurde ich schon mit
Qu*rt*s und C*cl*one im Kontext mit VHDL gefoltert).

Gibt es Boards bzw. Komponenten, die ich fuer das Programmieren von
FPGAs mit OpenCL im Kontext mit FreeBSD verwenden kann?

Existiert Literatur oder ein paar (empfehlenswerte) Paper bzgl. das
Programmieren von FPGAs mit OpenCL?

Ich hoffe, dass das jetzt nicht off-topic ist, aber die Stichworte OpenCL und
FPGA haben mich dann doch neugierig gemacht, weil ich auf der Suche nach
einer Oase mit Trinkwasser in einer (sehr tristen und kargen) Wueste bin. :D
 
Quartus habe ich auf FreeBSD bisher noch nicht probiert, aber Xilinx ISE laeuft mit dem linuxulator ganz okay auf FreeBSD. Etwas frickelig ist die Anbindung des Jtag Controllers. Da muss man dann selbst Hand anlegen.

Altera bietet einiges an OpenCL Material fuer FPGAs an. Xilinx hat soweit ich weiss nur mal irgendeinen Demonstrator. Grundsaetzlich fuehrt aber erstmal um HDL kein Weg vorbei, zumindest um die Interfaces zu schreiben.
 
Das Thema ist relativ neu und *BSD kannst Du bei dem Thema knicken:
https://www.altera.com/products/design-software/embedded-software-developers/opencl/overview.html

Das Problem bei VHDL/Verilog ist, Du programmierst sehr hardwarenah. Du kannst da viele Fehler machen, die C/C++ wie Kindergeburtstag aussehen lassen (http://danluu.com/why-hardware-development-is-hard/):
Dan Luu schrieb:
The vast majority of statements you could write down don’t translate into any meaningful hardware.
Zum Vergrößern anklicken....

Das 2. ist, dass das Fitting nicht trivial ist. Du musst die Module manuell anordnen um möglichst kurze Kommunikationswege durch den Chip zu erzeugen. Wenn das nicht gelingt wird es nicht einfach langsam. Es funktioniert gar nicht oder Du hast bizarre Fehler, denn in einem Takt kommt ein Signal von einem Ende des Chips am anderen Ende nicht unbedingt an. Nachher musst Du da einen Bus dazu basteln der dann natürlich Latenz erzeugt.

Wenn Du Dich für OpenCL entscheidest wird alles einfacher. Du schreibst in einem C/C++ Dialekt und das Fitting macht die Toolchain für Dich, die quasi eine Grafikkarte als Template nimmt. Damit kommst Du natürlich nicht so weit wie mit VHDL, aber in der Regel halt doch weit genug und das in deutlich kürzerer Zeit.
 
Aaaah... danke! Mmmmhhh... dann muss ich mich wohl von
Xillinx und Verilog (erstmal) foltern lassen. Habe geradeeben
ein bisschen was bzgl. FreeBSD und Xilinx gefunden:
bzw.
Meine Zielsetzung ist mittels FPGA bzgl. DSP, siehe pdf, zu experimentieren.

Schade, dass Altera keine Komponenten fuer FreeBSD
basierte Entwicklung von Komponenten mit FPGA zur
Verfuegung stellt.

Edit: Noch was gefunden: http://www.clifford.at/icestorm/
 
Wenn dir VHDL lieber ist, kannst du das natuerlich auch mit der Xilinx Toolchain verwenden. Verilog, oder noch besser Systemverilog empfinde ich aber als deutlich einfacher. Natuerlich nur meine persoenliche Meinung.
Ich hab einige Jahre mit ISE auf FreeBSD zugebracht und muss sagen: Ja, es ist machbar, aber wenn du groessere Designs hast, dann merkt man doch schon einen Geschwindigkeitsunterschied. Am Ende wirft man das ganze dann zum Synthetisieren eh auf eine dicke SMP Maschine und die war dann mit Linux installiert. Die Simulationstools, sowohl isim als auch questasim liefen aber ganz gut auf Freebsd. (Natuerlich ist das leider etwas Gefummel, das ganze zum Laufen zu kriegen.)
Wenn du willst, kann ich dir aber mal meine Tools, die ich zum Flashen von dutzenden FPGAs parallel geschrieben schicken. Allerdings braucht man die nur fuer Virtex 5, oder hoeher. Spartans werden auch so mit xc3sprog unterstuetzt.

Es kann durchaus sein, das die Altera Tools auch auf FreeBSD laufen, das habe ich nie ausprobiert.
 
Können wir wieder zurückkommen zum richtigen programmieren.
Ich kann jeden nur sagen, seid froh das ihr richtige Sprachen benutzen könnt. In meinen Job durfte ich Actionscript(Flex) wieder herausholen, da funktioniert nicht mehr viel oder C# auf .Net 2.0. Classic Delphi ist da auch recht speziell, gerade wenn man moderne Programmierpraktiken gewohnt ist oder Anbindungen zu neuen Kram schaffen muss.
Ich mein, heute kommt man doch kaum ohne Dictionaries, Json oder UTF8 aus.
Dazu ist es auch kein Wunder das MS noch so viel Geld mit seiner Datenbank verdienen kann. Deren Kram funktioniert noch mit 15 Jahren alten IDEs und ich muss mir mühsam einen Schnittstelle zu MongoDB hacken und mich ggü. Kollegen erklären. Hallo, NoSQL, steht nicht für No SQL.
 
s-tlk schrieb:
Wenn dir VHDL lieber ist, kannst du das natuerlich auch mit der Xilinx Toolchain verwenden. Verilog, oder noch besser Systemverilog empfinde ich aber als deutlich einfacher.
Zum Vergrößern anklicken....

Es wird (zuhause) Verilog sein (bzw. werden), da ich VHDL als haesslich empfinde. :D

darktrym schrieb:
Können wir wieder zurückkommen zum richtigen programmieren.
Zum Vergrößern anklicken....

Ja. :)

C ist fuer mich Ultima Ratio fuer systemnahe Programmierung
eines Backends, welches am Sensor oder im Kontext von einer
Server gestuetzten Infrastruktur Daten verarbeitet.

Fuer eine GUI wuerde ich empfehlen eine Webapplikation zu
entwickeln, welche innerhalb eines Intranets erreichbar waere.

Warum Webapplikation? Weil "plattformunabhaengig" bzgl. dem
Implementieren eines Viewerpatterns.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben