Umfrage: Welche Programmiersprache als nächstes?

Wie ihr sicherlich mitbekommen habt geht die Weiterentwicklung ein wenig langsamer voran als geplant bei uns. Deswegen haben wir ab morgen einen neuen Mitarbeiter!

Seine erste Aufgabe wird es sein neue Programmiersprachen-Bindings zu erstellen und eine Dokumentation über die low level TCP/IP Kommunikation zu schreiben (damit man in Theorie jede Programmiersprache nutzen kann).

Die Frage ist jetzt natürlich: Welche Programmiersprachen soll er als erstes machen? Was hat die höchste Priorität?

Edit: Kleiner Disclamer: Wir behalten uns vor nicht die Reihenfolge die am Ende beim Poll rauskommt einzuhalten, wir Fragen hier ja nur einen kleinen Teil der Community (im Forum angemeldete deutschsprachige). Das Feedback was wir per Email etc. bekommen haben fließt zusätzlich noch ein.

Hallo,

ich persönlich fänd es noch interessant, die TF-Produkte in der Shell (Unix/Linux Konsole...) verwenden zu können. Aber ich vermute mal, dass das nicht häufig verwendet werden würde, oder was meint die Allgemeinheit so dazu?

(Ich meine natürlich nicht, dass ich Beispielsweise einfach ein C-Programm habe, dem ich in der Konsole beim Programmaufruf Eingabeparameter übergebe...Das geht ja auch so bereits. Ich meine damit eine Funktionsweise wie von cat, grep etc.)

Ich würde mir das so vorstellen: Man startet einen Deamon, und sobald der läuft, kann man alle Funktionen einzeln aus der Konsole starten.

Im Prinzip wäre das nichts anderes, als das man für jede Funktion ein kleines C-Programm hat, das quasi nur eine Aufgabe realisiert. Und dann muss man noch die Verbindung schaffen zwischen Shell und den Programmen (Was an sich kein Problem ist. Damit man das aber auf jedem Rechner eingerichtet bekommt, wäre es gut, dafür dann auch noch ein Installationsskript zu schreiben.)

Ist i-wie deutlich geworden, was ich meine?

Edit:

Ich weiß, das passt jetzt nicht so 100%ig in diesen Thread...

Gruß,

Fabian

shell find ich ne super idee!!

Die Shell ist ja keine Programmiersprache in dem Sinne.

Hier kann man ja in C oder python jeweils ein kleines Progrämmchen schreiben, das entsprechend die Parameter (IP-Adresse, Port, UID) übergeben bekommt und dann etwas zurückmeldet (z.B. Temperatur)

Das wiederrum kann man dann in Monitoring-Systeme wie Nagios super einbauen.

gmu

Mir ist schon bewusst, dass Shell-Sprachen Skriptsprachen und keine Programmiersprachen sind. Deswegen hatte ich schon darauf hingewiesen, dass das hier nicht so 100% rein passt.

Aber was du vorschlägst ist ziemlich ähnlich dem, was ich meinte. Für jede Funktion ein kleines Progrämmchen (dessen Inhalt quasi nur die Realisierung bzw. eigentlich nur Nutzung einer bereits implementierten Standard-Funktion ist). Aber das eigentliche Ziel war für mich, dass man dann die Brücke zur Shell (beispielsweise Bash) schlägt. Sinn: Man muss nicht jeder Miniprogramm einzeln umständlich aufrufen, sondern kann einfach den Shell-Befehl verwenden, der dann das eigentliche Progrämmchen aufruft. So in der Art eines Wrappers. Wisst ihr, wie ich das meine?

Eigentliches Produkt wäre also die Brücke zwischen der Shell und den Progrämmchen und dafür auch ein Installationsskript, welches diese "Brücke" installiert.

@Shell:

Wie würden die Callbacks in der Shell funktionieren?

Und wie granular sollte das sein? Ich befürchte das es einfach zuviel wird wenn man aus jeder Funktion von jedem Brick/Bricklet einen Befehl macht.

Was ich mir vorstellen könnte ist sowas:

tf brick dc set_velocity 150

tf bricklet temperature get_temperature # Gibt Temperature auf stdout aus

etc.

Der einzige Befehl den die Shell dann kennen muss ist "tf".

Das wäre glaube ich vergleichsweise schnell generiert, damit könnte man aber dann natürlich nur die getter/setter abbilden

Danke, dass du mich auf Deutsch übersetzt hast. Genau das meinte ich. Ich hätte einfach mal ein Beispiel bringen können :-)

Je nachdem was mit "Shell" gemeint ist: Ruby bringt IRB (Interactive Ruby Shell) mit. (Es gibt auch andere Ruby-Shells, mit fresh auch eine, die Ruby und Unix Shell verbindet.) Gäbe es eine Ruby Implementierung gäbe es also auch schon Shells :-)

Ich fände in dem Zusammenhang die Bash und eventuell noch die (relativ alte und immer weniger vorkommende) korn-Shell am wichtigsten.

Ich favorisiere immer noch eine direkte Einbindung in LabVIEW. Dies hätte gerade in Bereichen an Lehreinrichtungen, welche sonst wenig mit Programmieren zu tun haben, viele Vorteile und würde TinkerForge auch für diese Bereiche sehr interessant machen. Zudem ist LabVIEW im Bereich der Forschung und Lehre ohne hin an den Einrichtungen vorhanden (meist auch Matlab) und auch in der Industrie ist es sehr viel anzutreffen. Für private Anwendungen ist es meist zu teuer, darum dort eher seltener.

Mit einer solchen Einbindung, könnte sich die Hardware auch in Industrie, Lehre und Forschung etablieren ohne tiefgehende Programmierkenntnisse voraus zu setzen!

Eine Command-Line-Utility würde als Alternative gut reichen, um die Sprachen zu unterstützen für die es noch keine Bindings gibt.

Zum Steuern von digitalen Kameras ist sowas recht üblich: http://s10sh.sourceforge.net/; gphoto

Nicht zu verachten exiftools, auch eine sehr leistungsf. shell.

Als erstes wären mal XML Kommentare in den C# Bindings nett, da die Hilfe im Visual Studo dadurch viel besser wäre. Mit guten Kommentaren könnte man sich einiges an Wiki wälzen sparen.

Back2Topic: Als Zielgruppe könntet ihr euch mit einen Grafischen Editor wie in einen anderen Thread bereits angeregt die Schüler und Studenten holen welche nicht Programmieren lernen. Es gibt einige welche von den Bricks begeistert sind aber nicht Entwicklen wollen\können diese könnten mit Klickibunti GUIs die Angst vor Softwareentwicklung genommen werden.

@offtopic

Hab ich die JavaDoc bisher übersehen? Wenn nicht wäre es toll, wenn die demnächst noch dazu kommen würde

Ein Webservice wäre noch ganz schick, aber bitte mit Java implementieren damit es OS unabhängig bleibt.

Nifty,

inwiefern soll ein Webservice (WS) die Programmierung in jeder beliebigen Sparche unterstützen ?

Ein WS erfordert einen Host ? Welche Soft- oder Hardware soll das übernehmen ?

Und wie unterstützt der WS die Callbacks ?

@Nic

Der Brickd könnte das z.b. unterstützen.

Fast jede gängige Programmiersprache ist in der Lage gegen WebService zu laufen.

Callbacks kann man mit einem WS als Long Polling Call implementieren - wenn man unbedingt will.

@Nifity,

wenn ich Olaf richtig verstanden habe - siehe Thread BrickD für Android - wird man spätestens zum WLAN Modul auf den BrickD verzichten.

Ist so ein Long Polling Call zuverlässig genug für Echtzeitverarbeitung von Daten ?

Und werden durch das Soap-Protokoll hier nicht unnötig ein Datenoverhead (Envelopes) geschaffen ?

Und macht sich das so gut bei der Performance ?

Wäre es von den Entwicklern nicht möglich ne DLL zu erstellen, welche von allen anderen Sprachen angesprochen wird?

Finde die ganze Sache mit den Bricks sehr gut. Klein, praktisch, funktional. Als ich die einzelnen Module hier sah, sind mir spontan mehrere Anwendungsfälle auf der Arbeit und auch privat eingefallen. Bei dem Preis kann man die Teile auch für "Spielereien" anshaffen. Anwendungsfälle werden schon von allein kommen.

In meinem Fall, kann ich nur Visual Basic (6/.NET) Greife damit auch auf Hardwareteile, die aber noch lange nicht ausgeklügelt sind wie das System hier.

@insidERR: Die C# DLL sollte aus allen .NET Sprachen nutzbar sein!

Ist so ein Long Polling Call zuverlässig genug für Echtzeitverarbeitung von Daten ?

Und werden durch das Soap-Protokoll hier nicht unnötig ein Datenoverhead (Envelopes) geschaffen ?

Vermutlich würde niemand Echtzeit-verarbeitung mithilfe von Webservices machen und natürlich hat Soap overhead. Auf der Haben-Seite steht allerdings eine Plattformunabhängige Zugriffsmöglichkeit, insofern keine dumme Idee, da oft keine Echtzeit nötig ist (Wetterstationen, Lichtautomatik, etc.).

Es ist ja btw. schon strittig ob es ne gute Idee ist, Echtzeitverarbeitung unter Betriebssystemen wie Windows 7 oder Linux zu machen, beide bieten keine "hard realtime". Für sowas nutzt man dann eher Windows CE oder RT-Linux.

Hallo,

ich wäre für Qt wobei wenn die low level (tcp ip) doku fertig ist würde mir das evtl sogar reichen.

Alternativ auch gerne PHP.

Du kannst doch jetzt schon eine Qt-GUI mit den TF-Produkten verwenden. Beispielsweise könntest du doch in C++ programmieren, die GUI mit QT realisieren und im "Hintergrund" laufen die TF-Funktionen.

Oder was übersehe ich da? Sorry, falls ich da was Grundlegendes verchecke.

jein,

also mit Qt kannst du ja weit mehr machen als lediglich ein GUI bauen. Interessant wäre z.B. für jeden Brick / Bricklet eine Klasse zu haben. Das würde das Handling stark vereinfachen, da man keine callbacks mehr braucht. Ist dann alles via Siganl Slot machbar. Wie gesagt mit der entsprechenden Doku könnte man das zur Not auch selbst machen.

Ah ok, verstehe was  du damit erreichen willst. Ja das fänd ich wohl auch sehr praktisch...

Mag ja sein, dass Win selbst (noch) nicht RT-fähig ist, z.B. für Delphi/C++ gibt es seit einigen Jahren Frameworks, die RT Fähigkeiten ermöglichen: http://www.kithara.de/

Dazu will ich sicher keinen Webservice nötigen, sondern die Bindings für Delphi nutzen.

Also wozu einen Webservice ? Kann man die Energie dafür nicht lieber in die Bindings für die 3 wichtigsten Programmiersprachen investieren ?

Andererseits kann man Kunden nicht immer dazu zwingen, Betriebssysteme zu verwenden, die für mich als Entw. praktischer sind.

Aber nur um den größten gem. Nenner für alle zu finden und pauschal ein Webservice zu nehmen, für die Ansteuerung von Hardware-Kompon. wie die Bricks und Bricklets ist einfach zu grenzwertig.

Und zur poppeligen Ansteuerung von Hausautomation oder Wetterstationen braucht es nicht unbedingt WinCE oder Linux.