Umfrage: Welche Programmiersprache als nächstes?

[Nifty]

@Nic

Die wenigsten hier werden harte Echtzeit Fähigkeiten benötigen, die meisten werden mit Reaktionsfähigkeiten im ms Bereich locker klar kommen.

 

Dafür kann man z.b. mit .Net & WebServices innerhalb von ein paar Minuten eine Komplette Websteuerung von z.b. Steckdosen oder ähnliches auf die Beine stellen - und das ganze ohne irgendwelche Librarys dazu packen zu müssen.

 

Die die andere Bedürfnisse haben gehen halt weiterhin direkt mit an den Brickd ran.

[Nic]

Auch richtig, aber die Türen sollten zu Beginn für alles offen sein.

Und bitte erst an die Essentials denken und als Bindings anbieten. Im Anschluss daran und damit kann man ja gerne Webservices und sonstige Exoten bauen.

 

Wäre schade wenn Tinkerforge nur innerhalb von Schule, Uni und Hobby-Kiste ernst genommen wird.

Hier schlummert durchaus Potenzial für industrielle Lsg.

 

PS: Wenns unbedingt einen Webservice sein soll, dann ev. in REST Architektur und nicht als SOAP-Dienst.

http://jnb.ociweb.com/jnb/jnbNov2004.html

http://en.wikipedia.org/wiki/Representational_state_transfer

[insidERR]

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

Hi "borg".

Hab grad deine Antwort im englischen Forum gefunden (@AuronX

Yes, you should be able to use the .dll of the C# Bindings in VB.net. But there is currently no documenation on how to do this and no sample code etc.)

Schade, dass es dafür noch keine Beispiele gibt.

Habe die Tinkerforge.dll in VB.net eingebunden, kann aber trotzdem damit nichts anfangen.

Hoffe, es findet sich hier jemand, der was basteln und der Gemeinschaft zugängig machen kann.

[AuronX]

Sobald ich meine eigenen Bricklets habe werd ich mir mal ne kleine VB-Umgebung aufsetzen und versuchen die C#-Beispiele nach VB.Net zu übersetzen (im Wiki denke ich, oder?).

 

Musst du aber ein wenig warten, weil ohne jemals mit den kleinen Teilen gearbeitet zu haben will ich dann doch lieber nicht dokumentieren

[Nic]

@insidERR

 

Wäre C# eine Alternative ?

Wir werden eher mit PHP, Ruby Bindings mittelfristig zu rechnen haben als für VB.

Der Schritt von VB.net zu C# sollte nicht so groß sein wie z.B. von VB.net nach C++ oder Java.

Für mich war die Umstellung von Delphi zu C# und VisualStudio nicht die Welt.

Zumal VisualStudio als kostenlose Express-Version für C# gibt.

 

Die kleinen dokum. Beispiele hier im Portal helfen durchaus um einen schnellen Einstieg in C# zu finden.

[AuronX]

@Nic: Wie gesagt, es gibt Bindings für VB.Net! Denn die C#-Bindings sollten das Problemlos unterstützen. Was fehlt ist lediglich die entsprechende Doku.

 

Allerdings gebe ich dir gerne recht, dass es nie eine schlechte Idee sein kann sich C# anzuschauen

 

edit: ich nehme alles zurück und behaupte das gegenteil! Folgendes Problem: Das Benutzen von C#-DLLs in VB.Net funktioniert nur, wenn die DLL auch CLS-compliant ist (das ist der gemeinsame Sprachstandard von z.B. C# und VB.Net). Allerdings sind unsigned integers (uint) nicht Teil der CLS. Wenn jetzt also eine C#-Bibliothek Funktionen anbietet die ein uint erwarten, dann kann man diese aus VB.Net gar nicht nutzen, weil VB.Net kein uint kennt. Wenn ich das gerade richtig überblicke nutzt die aktuelle Bibliothek an 267 Stellen uint oder ushort als Parameter oder Rückgabewert. Damit ist die Bibliothek so nicht in VB.Net nutzbar. Ich kann im Moment nicht einschätzen, ob und wie gut es möglich ist diese Vorkommen durch andere Datentypen zu ersetzen. Dazu würde ich dann aber demnächst zumindest meine Meinung äußern können

 

Viele Grüße Jan

 

ergänzende Kurzanalyse: Es gibt auf jeden Fall Methoden wo ushort nicht notwendig ist. Beispiel: BrickletAnalogOut.SetVoltage(ushort voltage).

Laut Spezifikation sind für voltage Werte von 0-5000 erlaubt. Das bedeutet zweierlei Dinge:

1. Sowohl der Wertebereich von short also auch der von ushort umfassen den vollen Bereich der Spezifikation

2. ushort bietet den (scheinbaren) Vorteil, dass man keine ungültigen negativen Spannungen angeben kann. Allerdings ist es noch immer möglich höhere als die spezifizierten Spannungen anzugeben. Insofern wäre m.E. ein Range-check sowieso von Vorteil, wenn man den macht, dann kann man auch direkt für beide Grenzen (0 und 5000) testen und ggf. eine Exception werfen.

[photron]

AuronX, danke für den Hinweis.

 

Wir können die C# Bindings CLS-compliant machen, denke ich. Da C# unsigned Typen unterstützt würden wir diese ungern durch die nächst größeren signed Typen ersetzen (so wie das in den Java Bindnings ist, weil es da nicht anders geht).

 

Daher wäre eine Idee, dass jede Methode die nicht CLS-compliant ist einen CLS-compliant Überladung bekommt. Zum Beispiel für BrickIMU würde aus

 

public void SetAccelerationPeriod(uint period);

 

dann

 

[CLSCompliantAttribute(false)]
public void SetAccelerationPeriod(uint period);
[CLSCompliantAttribute(true)]
public void SetAccelerationPeriod(long period);

 

In der Hoffnung, dass das so geht (ich hab's noch nicht getestet) und z.B. in VB.net die CLS-compliant Variante aufgerufen wird und diese sich nicht mit Der Überladung in die Quere kommt. Falls nicht würde die CLS-compliant Variante noch einen Anhang an den Methodennamen bekommen.

 

Siehst du sonst noch Probleme außer die unsigned Typen?

[AuronX]

Zumindest zeigt mir mein Visual Studio keine anderen als die genannten Warnungen zum Thema CLS, ich denke also, dass das alles sein sollte.

 

Spontan würde ich übrigens denken, dass die korrekte Schreibweise [CLSCompliant(false)] sein müsste, also ohne Attribute. Möglicherweise geht aber auch beides.

 

Verstehe ich es richtig, dass ihr nur bei den Methoden wo der Wertebereich es notwendig macht zwei Überladungen anbieten wollt? Oder soll es für jede Methode eine zweit-Überladung geben? (beispielsweise wäre sie ja bei SetVoltage im AnalogOut nicht nötig, weil der maximal 5000mV kann)

 

Viele Grüße

Jan

[photron]

Verstehe ich es richtig, dass ihr nur bei den Methoden wo der Wertebereich es notwendig macht zwei Überladungen anbieten wollt? Oder soll es für jede Methode eine zweit-Überladung geben? (beispielsweise wäre sie ja bei SetVoltage im AnalogOut nicht nötig, weil der maximal 5000mV kann)

 

Alle Methoden die unsigned Typen verwenden bekommen eine CLS-compliant Überladung. Da die Bindings generiert werden und der Generator den Typ  der Parameter kennt (aber nicht den wirklich genutzten Wertebereich) ist dies so einfacher zu lösen. Dies führt auch dazu dass die Bindings für C# im Prinzip so bleiben wie sie jetzt sind und nur für vollständige CLS-Compliance für andere .Net Sprachen erweitert werden.

[insidERR]

@Nic

für mich war es schon ne Überwindung von VB6 auf .NET umzusteigen. (allerdings will ich jetzt VB6 nicht mehr nutzen, sondern nur VB2010)

Auch wenn die Denkweise bei den Programmiersprachen ähnlich und hauptsächlich die Syntax anders ist, will ich nicht zweigleisig fahren und für ein paar Anwendungen ne Programmiersprache lernen und alles andere weiter in VB.NET schreiben.

Da warte ich lieber, bis einige klugere Köpfe hier aus Gnade und sportlichem Denken was brauchbares veröffentlichen. 

[Nic]

@photron

Ich vermute mal Du bist der neue "Unsichtbare 3" bei Tinkerforge !?

 

Bei den C# Bindings ist mir noch aufgefallen, diese seltsame Verwendung von out-Parametern in einigen Gettern. Ev. könnte man das durch Funktionen und Rückgabewerte ändern. Ich glaube AuronX hat dazu einen neuen Thread eröffnet.

[Loetkolben]

 

Was sollte die naechste Programmiersprache sein? Fuer meinen Geschmack ist php gut und ich freue mich drauf, ABER:

 

Es sollte was simples geben. So einfach die Hardware fuer einen Anfaeger ist, so kompliziert ist die Software! Neben einer Programmiersprache an sich, muss man auch die Einbindung der Hardware hinbekommen und hat dann immer noch nichts Grafisches.

 

Ein Grund fuer den Erfolg des modernen Windows (ab W95) war visual Basic. Da konnte sich auf einmal jeder Anfaeger ein grafisches Programm zusammenclicken und es funktionierte.

 

Ich kann mir vorstellen, dass ein Anfaenger erstmal was laufen haben moechte. Irgendwie. Der Brick Viewer ist da schon super!! Nach 10 Minuten ist das erste Erfolgserlebnis da. Das ist wichtig!

Deshalb bitte den Kommentar neben dem Viewer "The Brick Viewer is for testing purposes and not absolutely necessary." aendern in "The Brick Viewer is for fast testing and showing the first results. Recommend to use first"

 

Eine gute Loesung habe ich nicht. Eine eigene Baukastensprache die man sich samt grafischen Elementen zusammenclicken kann ist sicher am Ziel vorbei, aber vielleicht kann jemand entsprechende Elemente fuer eine Windows Visual (Basic) Sprache erstellen. Es muss ja nicht das Tinkerforgeteam selbst sein.

 

Der Loetkolben.

 

 

[ArcaneDraconum]

Also für kurze Funktionsprüfungen ist der BrickViewer klasse. Was noch klasse wäre, wenn dort schon ein Logging eingebaut wäre. Also die Werte aller angeschlossenen Bricklets in einem wählbaren Intervall ausliest und in einer Datei ablegt.

[haentschman]

Delphi holt auf... wobei man Pascal noch dazurechnen sollte.

[Nic]

@haentschman

 

Ahh, endlich jemand der sich für Delphi interessiert, dachte schon ich bin hier alleine

Bist Du in Delphi fit ?

[Plenz]

Ich würde generell eine einfach und schnell zu lernende Sprache bevorzugen. Eine solche ist BASIC. Da brauche ich nicht zu wissen, was Klassen und Methoden sind. BASIC ist universell und überall:

- in der C-Control von Conrad

- im CHDK-Tool für Canon-Kameras

- in der Homematic Haussteuerung (objektorientiertes BASIC)

 

PRINT "Hello World!"

 

ist eine einzige Zeile. Keine Bibliotheken zu laden, keine Module zu definieren. Einfacher geht's nicht.

[AuronX]

Dann empfehle ich dir (das schon unterstützte) Python.

 

Python bietet viele gute Eigenschaften für Anfänger:

- kein Zwang zur Objekt-orientierung (aber dennoch die möglichkeit wenn man will)

- ich würde behaupten ähnlich einfach wie BASIC

- kann verdammt mächtig sein (also auch dann noch nützlich wenn man schon was gelernt hat)

- dadurch, dass whitespace teil der syntax ist lernt jeder anfänger seinen code zu formatieren

 

Noch schnell zum Hello World:

print("Hello World")

[haentschman]

@Nic

Ahh, endlich jemand der sich für Delphi interessiert, dachte schon ich bin hier alleine

Bist Du in Delphi fit ?

... denke schon. Alles kann man nicht wissen  Seit 10 Jahren intensiv von D5 bis XE.

 

Certified Delphi® Developer 2011

[detg]

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).

 

Steckt doch nicht so viel Energie in die API für spezielle Programmiersprachen. Dokumentiert lieber die Low-Level TCP/IP-Schnittstelle und lasst den Rest die Community erledigen.

 

Ich bräuchte (wenn ich mich dafür entscheide, mit TinkerForge zu arbeiten) eine API für ActionScript (Flash und AIR). Aber die baue ich mir dann schon selber und würde sie auch im Quelltest zur Verfügung stellen. Aber erst mal muss dokumentiert sein, wie man das macht. Und zwar so verständlich, dass sich  das schnell umsetzen lässt.

 

[photron]

Die TCP/IP Dokumentation ist schon fertig. Hier der generelle Teil

 

http://www.tinkerforge.com/doc/Software/IPConnection_TCPIP.html#ipcon-tcpip

 

und hier z.B. die für das Linear Poti Bricklet

 

http://www.tinkerforge.com/doc/Software/Bricklets/LinearPoti_Bricklet_TCPIP.html#linear-poti-bricklet-tcpip

 

Wenn dir da was fehlt, was nicht verständlich oder detailliert genug ist oder sonstige Probleme damit sind dann sag Bescheid oder frag.

[Nic]

@haentschman

 

Thema. Delphi-Bindings:

Hättest Du ev. Lust zusammen die Delphi-Portierung voran zu bringen ?

Den Framework, den ich bisher erreicht habe, unterstützt prima, die TCPIP Connection, Anmelden eines Devices, und das Callen der Funktionen. Jedenfalls was das Steuern des Stepper-Bricks und IO-Bricklet angeht. Offen sind eig. nur noch das threadsichere Queueing und Callbacks. Die Portierung ist in D7.

 

Allerdings wäre das alles obsolet, falls von TF diesbezgl in kürze was fertig gestellt wird. Ich habe zwar nach einem Veröffentlichungstermin nachgefragt, aber keine Antwort erhalten.

[Christian]

Allerdings wäre das alles obsolet, falls von TF diesbezgl in kürze was fertig gestellt wird. Ich habe zwar nach einem Veröffentlichungstermin nachgefragt, aber keine Antwort erhalten.

 

ja nich schlecht was ihr so treibt . Ihr könnt sowas natürlich auch gut ins Wiki bringen und da gemeinsam dran weiterarbeiten und eure "Arbeit" hier demonstrieren. Seit heut gibt’s sogar Code-Highlighting

 

Gruß

Christian

[photron]

Allerdings wäre das alles obsolet, falls von TF diesbezgl in kürze was fertig gestellt wird. Ich habe zwar nach einem Veröffentlichungstermin nachgefragt, aber keine Antwort erhalten.

 

Im Moment bin ich mit generellem Aufräumen beschäftigt. Die nächsten Bindings werden für Ruby. Also keine Sorge, dass wir da morgen fertige Delphi Bindings präsentieren.

 

Sind deine Delphi Bindings bisher von Hand programmiert oder hast du auch schon einen Generator gebaut?

 

Am liebsten wäre es mir natürlich wenn ich für die zukünftigen offiziellen Delphi Bindings auf deine bisherige Arbeit aufsetzen könnte

[Nic]

@photron

Die Delphi-Bindings sind von Hand strukturell auf Basis der C#-Bindings erstellt. Auf Code-Generator ist soweit also nur indirekt Rücksicht genommen. Die Brick-Hauptklasse der IPConnection ist quantitativ komplett, Brick-Stepper erstmal nur die wichtigsten Fkt. wie DriveFor, Backw, Enable/Disable etc.

 

Ich schlage vor, ich lasse mein Ergebnis zuerst mit Hilfe der Delphi-Experten - ev. hat haentschman

Interesse - in einem Code-Review Korrektur lesen. Und stellen anschließend dann eine erste Beta ins Wiki, bzw. Forum oder wo auch immer.

 

Die Arbeit für Dich würde sich erstmal dann nur noch darauf beschränken, die Bindings der übrigen Bricks und Bricklets hinzuzufügen, und das in den Code-Generator einzubinden. Wenn ich mit den Delphi-Bindings also wie o.g. Unterstützung von Userseite bekommen könnte, wäre eine Beta nach dem WE möglich.

 

Es wäre vorteilhaft, wenn wir auch eine Übersicht hier im Forum hätten, die Hinweise auf Programmierkenntnisse der User zeigt. Ev. innerhalb im Profil festlegbar !?

[FabianB]

Guter Einwand. Programmierkenntnisse und evtl. sowas wie Beruf wäre vllt interessant. Wer beruflich mit solchen Sachen zu tun hat, könnte sich dann auch direkt mal outen.

 

EDIT:

 

Man kann das auch alles in "Persönlicher Text" ins Profil schreiben. Das wird auch links angezeigt. Vielleicht lässt es sich einfach darüber regeln.