What programming language should I use?
Dr_Acula
Posts: 5,484
I've been happily programming in vb6 and vb.net and C# for many years, but the world is changing and these programs won't run on Macs or Linux or Android. Or even some Windows computers!
What program should I use?
Here's what I want: I'd like an IDE which has a toolbar and I'd like to click "New Project" and grab a button, and a textbox, and then I'd like to click on the button and some skeleton code should appear, and I'd like to print "Hello World" in the textbox. I'd also like some syntax highlighting, auto indentation and auto finding of class methods if I type a . or :: or whatever. And then, once Hello World works, I'd like to to send that text out the serial port.
In front of me is an XP and a Win 8 machine and I'm running both side by side as I want the program to run in both. And I've got Ubuntu running on Virtual Box.
So - suggestions please!
Here's what isn't working. I tried moving from .net 2008 to 2010 and it failed on the XP machine (SP1 I think), and Microsoft is moving to .net 2012 now anyway. The .net framwork v 4 and 4.5 fails on XP, though runs fine on Win 8. There are some rather nasty forums over at Microsoft where there are endless complaints about Microsoft abandoning its most popular operating system (it is still XP) so I'm not alone here.
I had some hopes with Java on Jabaco but there is no intellisense and the compiler gave error messages even with a stripped down 3 line program.
I've played around with various C++ programs and maybe I can get into C++ but the files seem to all be in bits and pieces and I really like the auto completion of methods with the .net framework (something that is also missing in all the Propeller tools). I've got netbeans and code::blocks and a few other C++ packages but they seem more text based.
I tried Mono and it does install on both XP and Win 8. But it too seems to be text based. Maybe I'm missing something. So I found MonoDevelop which is a GUI front end and it works on Win 8, but on XP it fell over as it needed the latest .net 4.5. So that seems to be too close to Microsoft and hence is going to have all the problems of C# with inbuilt obsolescence.
In some ways, good old VB5 did the job. Simple forms and text boxes and code.
At the most fundamental level, what I am looking for is something that is not going to be rendered obsolete in a few years, and which can run on multiple operating systems like a Mac/Linux/Android. Thinking outside the square, with a touchscreen, the Propeller itself is capable of displaying the same pictures, so in a really ideal world, the language could also run on the Propeller.
Please hit me with some suggestions!
What program should I use?
Here's what I want: I'd like an IDE which has a toolbar and I'd like to click "New Project" and grab a button, and a textbox, and then I'd like to click on the button and some skeleton code should appear, and I'd like to print "Hello World" in the textbox. I'd also like some syntax highlighting, auto indentation and auto finding of class methods if I type a . or :: or whatever. And then, once Hello World works, I'd like to to send that text out the serial port.
In front of me is an XP and a Win 8 machine and I'm running both side by side as I want the program to run in both. And I've got Ubuntu running on Virtual Box.
So - suggestions please!
Here's what isn't working. I tried moving from .net 2008 to 2010 and it failed on the XP machine (SP1 I think), and Microsoft is moving to .net 2012 now anyway. The .net framwork v 4 and 4.5 fails on XP, though runs fine on Win 8. There are some rather nasty forums over at Microsoft where there are endless complaints about Microsoft abandoning its most popular operating system (it is still XP) so I'm not alone here.
I had some hopes with Java on Jabaco but there is no intellisense and the compiler gave error messages even with a stripped down 3 line program.
I've played around with various C++ programs and maybe I can get into C++ but the files seem to all be in bits and pieces and I really like the auto completion of methods with the .net framework (something that is also missing in all the Propeller tools). I've got netbeans and code::blocks and a few other C++ packages but they seem more text based.
I tried Mono and it does install on both XP and Win 8. But it too seems to be text based. Maybe I'm missing something. So I found MonoDevelop which is a GUI front end and it works on Win 8, but on XP it fell over as it needed the latest .net 4.5. So that seems to be too close to Microsoft and hence is going to have all the problems of C# with inbuilt obsolescence.
In some ways, good old VB5 did the job. Simple forms and text boxes and code.
At the most fundamental level, what I am looking for is something that is not going to be rendered obsolete in a few years, and which can run on multiple operating systems like a Mac/Linux/Android. Thinking outside the square, with a touchscreen, the Propeller itself is capable of displaying the same pictures, so in a really ideal world, the language could also run on the Propeller.
Please hit me with some suggestions!
Comments
Go Lang on the PC and propforth on the prop. Its not what you asked for, but its what you appear to want.
These will never be rendered "obsolete" since they are the simplest command line form of the most powerful tools. Any GUI is separate, optional, and just sits one top.
Keep It Simple Sir.
You may be asking for the sky.
You can use C++ together with the Qt GUI tool kit to do that button drag and drop thing in it's QtCreator IDE. That IDE runs on Windows Mac and Linux. So you can create GUI code on any of those platforms that can be compiled on any of the others. You can even use Qt creator on ARM processors like the Raspberry Pi running Linux. The SimpleIDE for propgcc is a fine example of this, it can be built and run on all the above platforms. I have even managed to get Qt programs to run on my Android phone but it was a bit of a struggle.
Start here: http://qt-project.org/
If C++ is too much then it is possible to use Qt with JavaScript using its new QtQuick/ QML features.
Or there is PyQt which allows Qt GUIs to be programmed in Python but I have never tried that.
Then there is WxWidgets which I have never used http://www.wxwidgets.org/
I have managed to create some simple GUI stuff with Mono develop, never tried it on Windows. I'm a bit wary of the MS and Oracle shackles though.
Braino,
Do you know something I do not? As far as I can tell there is no tool kit to build GUI programs with Go.
Maybe worth checking.
Massimo
sorry, that was a pre-coffee posting. I meant to convey that we don't really NEED any GUI in the programming interface, but if we decide we do we can build one on top of the command line. in my case i don't like the machine doing unknown stuff "for me" so a traditional? GUI tends to cause more problems than it solves.
if we are talking application GUI, i would still do just the minimum on the prop, since we have to be clever to design appropriate to prop, windows type gui doesn't quite fit.
Like you said, something like Qt as gui on rpi, talking to a prop that interfaces to peripherals would be a model where a gui starts to make sense.
another option in the works is an android app on a phone or tablet that talks to the prop. this is in the works for the little robot, but the first pass will use a simple terminal interface from phone to prop
if you go the python route, the uni at wolvehampton has python-CSP channels, which should (but have not been demonstrated yet) interface directly to propforth just as with the Go-channels
All in all, I would agree, put the GUI on something like the Pi or Android and let the Prop do what it is good at.
For sure you cannot pass a Go channel down a channel to PropForth and have it reply on that channel. Or can you?
I just stick my head in the sand, let the world change around me and chug along in BASIC. It was great in the '80's and it's still great now.
I just stick my head in the sand, let the world change around me and chug along in C. It was great in the '70's and it's still great now.:)
While I'm waiting, I use Forth because it is what it is or it is what you make it.
For the Demo (included in the download archive) the synchronous serial channels (plumbing) is implemented over the physical asynchronous serial link, since we need a physical wire to connect the prop to the PC. The single physical link carries anywhere from 1 to 32 logical channels, the throughput results for various workstations and numbers of channels are posted on the wiki page.
This is the DEMO just to show it works, and is not the final implementation. For example, if the channels were run over ethernet to a spinneret, it would go as fast as the ethernet, and we could have as many logical channels as we care to buffer.
When we move to RPI + prop, the connection will move from an async serial over micro USB to a synchronous serial directly between a prop pin and the RPI GPIO pin. In this case we can also go from PC to RPI via ethernet, and then from RPI to prop via channel. We haven't finalized this yet (Sal didn't send me the board, he loves soldering on live chips these days, and I don't) but he SAYS it goes crazy fast, as fast as the prop runs.
So, in order of your comments:
You would lose your bet;
There is a serial link, can be slow over RS232, fast over ethernet, or fastest directly to pins;
I'm pretty sure we CAN pass a channel from Go to propforth, since we do it all the time;
and I'm pretty sure it replies.
Remember the PHYSICAL channel replies via protocol; and there are at least two physical channels between processors, one for talking and one for listening.
Its actually pretty simple, it should be a piece of cake in C. Unless I still completely misunderstand the concepts. I'm not an expert in this stuff, I just read the test data.
EDIT - I just noticed I'm monopolizing the discussion talking about my stuff. Sorry bout that, I'll stop. I do want to see other folks suggestions.
I was kind of thinking in terms of Occam or XC on the Transputer or XMOS devices respectively. There you can do I/O on a channel and that channel can be a local thing linking two threads together in a processor or going out over a physical channel link to hook up two threads in two different processors. You don't have to add any other code or drivers in these cases.
As it stands, Go channels cannot go off chip without something being added in between, both hardware and software.
If you do go off chip then there are things that might break a Go program. For example you can pass reference to objects through Go channels and two goroutines can share access to the objects memory. That of course will not work between two processors with no shared memory. In Occam and XC threads are not allowed to share memory so moving threads from chip to chip or computer to computer would not break your code that way.
I've been successfully using python with wxPython as GUI. There are several GUI builders available which produce both python, C++, and xrc (internal xml based format, which can be used in to build the GUI for you). I found it easiest in the long run to use the xrc format and used use the standard xrced tool to build my GUIs
wxPython is based on wxWidgets another cross-platform GUI library using native look on each supported platform.
On windows and MacOS (I believe, never used it) you can even create 'stand-alone' programs ie not force other users to download/install all the need tools and libraries.
Use what you know. I really, really like C#. The only problem is that Visual Studio constantly changes, and I feel like I'm getting skewered every time I have to use a new version. Aside from that perspective, I believe Visual Studio has the best GUI tools. I've used Visual Studio projects with Mono-develop but not recently. The only real problem I faced with mono is that serial port support is only polled. Interestingly Qt is not much better in that respect across platforms.
BTW, you mentioned auto-complete. Qt does have auto-complete text box features, but I'm guessing you need something like intelli-sense. I added that kind of thing for SPIN in SimpleIDE, but most propeller people don't get it so that's DOA forever IMHO.
For my money, for the last 5 years, everything I wanted to do I could do with Spin, PASM and/or programming.org.... sorry, that last language doesn't seem to have a name, it is just "programming.org."
It started out as something else. "Wires" I think. Same folks that brought you the Arduino scourge. It is Italian and it is cross platform, handles data streams quite well and can talk to the Propeller over a serial line... and also gives you machine vision in 3D through a Kinect... sans xbox. What more could a guy want?
Rich
Avoid the obscure languages unless you like having no help. Worse most of them aren't cross platform and dominated by evangelists.
It's different if you're a hobbyist and just do embedded or retro systems. You don't have to follow the herd.
I think you mean "Processing", as here http://www.processing.org/
That language for sure does have a name, it's "Java". Processing is not a language in itself but rather a bunch of libraries and an IDE.
This is the same approach as the Arduino and it's language which is actually C++.
I find this dishonesty, or at least obfuscation, to be really annoying. I can see why they do it though, the libs and IDE hide all the gory parts of the languages from newcommers and if you don't say C++ or Java you don't frighten people away.
One thing that is niggling away at me is the ability to run 'big' programs on the Propeller. That means caching and C, and much as C isn't my first choice of language, it was the first language my 15yo son mentioned when I asked him to name a computer language.
I found some intriguing plugins for code::blocks that can do all the GUI 'hello world' with a button and textbox and most of the code pre-written. It is called "wxsmith" http://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Hello_world and while it is a 270Mb download (in addition to code::blocks) it does seem to do a lot of what I want. And it runs on linux. And in the settings of code::blocks I found a whole lot of autocompletion options (you can even set the delay in milliseconds before they pop up). Code::blocks is the engine for Catalina but GCC ought to work too, and the GUI widgets are more C++ than C.
Pity I had to leave for work
Some initial things checked out fine, and there are some tutorials around that look good. Where I think this could go is the ability to put some text boxes and buttons on a screen and compile and run on a PC, and then maybe download and run the *same* program on the propeller. It would be completely different code actually drawing text boxes but I know all that already works just fine on the propeller as I have that working for some simple html. The parameters for boxes like size and text and font all fit nicely in an object oriented 'class'. I think that could make debugging a whole lot easier as you could save a lot of time not having to download code.
IDEs like the .net framework were only designed to run on certain machines. I think the plugin nature of code::blocks makes it more able to handle running code on vastly different platforms and quickly changing from one to the other.
Exciting times ahead!
Disagree on this. It shouts propforth. Even if you go to the trouble and expense of external ram, the cost in execution overhead negates the speed advantage. Compare this to propforth working off an SD, using scripts, and paged assembler. The actual transfer is limited to the speed of the SD, but there is much less overhead, and you have to work within 32k in any case. Propforth is designed for handling this in that smallest efficient method. There's no bells and whistles, but do you want bells and whistles in your way when you are not using them 90% of the time?
David Betz's xbasic provides the ability to run 'big' programs on the Propeller with cached external memory code. https://code.google.com/p/xbasic/
mono runs .net programs.
most of my programming has addmitedly been on the win platform using visual studio 6, then later unmanaged vc.net, which may as well be vc6. the thing is i started using the win32 api in vb5 heavily, then when i got into games using the win32 api and direct x with straight c was the best approach. these days theres obselete mfc, wpf all sorts of ways to create gui apps on windows leaving good ol win32 GDI api, and vb6 rad gui apps obselete. what im getting at is even if you know windows GUI stuff the frame works change all the time. Is using QT and C good cross platform answer to this problem. I would like to write some C function to draw a button once and have it work everywhere. id also like it not to be the obselete way of doing it in a year or two. if you were a windows programmer the api was the most solid choice for along time but now with win8 and metro on top of years of other technology and 64 bits im thinking i code like an old man on my xp rig lol
Amazingly desipte having had PC class machines with GUI's for fourty years we still cannot do that simple task in any language. Despite all the efforts towards cross-platform software, languages, standards etc we seem to be getting further away from being able to do it rather than closer. Now you need different code in different languages for your button on many diverse platforms: Apple, Android, Windows, X Windows, etc etc.
The best answer at this time is HTML and JavaScript. At least with that combination your same button code would have been working for last 17 years and I suspect it would remain working for another couple of decades.
So actually JavaScript and HTML is my recommendation today. Put that button in your browser along with all your other GUI elements. Many browsers will run a page at full screen so it need not look like it's in a browser. Google Chrome has an "app" mode where it just runs your pagein a plain window and can look like a regular app on your desktop.
Ah, you say, I can't talk to my Prop from JS in a browser, or access files or many other things. Sure you can, just write a simple web server that runs on your PC to do all that and serve it up to the browser. That can be done in a few dozens of lines of JavaScript running under Node.js or in the Go language, for examples, which can get easy access to serial ports and other hardware on your PC.
I wish you a long lived button:)
I dont know if this sounds stupid or not but on the MS side of things I pine for the DOS/Win95 area, when writing a pure command line app was acceptable
I still think the closest to that long lived cross platform button in an actual application is going to be in a tool kit like Qt which works on Mac, Windows, Linux, and even Android. Qt will be around a while as it is the bases of the K Desk Top (KDE) on Linux. That button is only a few lines of C++. There are of course other tool kits like WxWidgets.
-Phil
@heater
so is qt pretty easy to use. you speak of stamina and when i think of C and the win32 api the word choice is perfect, having to create every window and widget then hook its messages makes for 10s of pages of c code just to get the simplest window made. im hoping something like qt would be a little more intuitive.
come to think of it embedded projects have resparked my fire for cs becuase its the only place left to get down and dirty and focus on a solution rather than a gui.
-Phil