Programming languages

blaisepascal · Post by **blaisepascal** » Fri Mar 19, 2010 11:21 pm

chrismb wrote:
Tom Ligon wrote: I do not miss Fortran.
Just gimme a language that I can toss complex variables around in, with ease, then I will consider it suitable for engineering purposes!

You mean like Scheme, which has had support for complex variables as first-class numbers since at least the early 1990's?

Diogenes · Post by **Diogenes** » Sat Mar 20, 2010 12:12 am

DeltaV wrote:
Tom Ligon wrote:I do not miss Fortran.
Spaghetti code is a choice, not a requirement. You can write clean, blazingly fast, structured, modularized code with Fortran90 or newer. It excels in fast number crunching for array data and deeply nested loops, and add-on libraries for things like OpenGL are easier to use than those for C and its ++/#/.... spawn. I don't miss the punched cards either, and I haven't used a goto since the 70s.

Tom Ligon wrote:C does nothing useful without headers and libraries that are almost never standardized. By the time you install enough of these to get your code running, you wind up with a porker full of unused junk with unpredictable habits, slow to compile, and a memory hog.
Fully agree.

Lately I bought Mathematica Home Edition (only ~$300, but a very Draconian license, use it for personal enlightenment only). I've only scratched the surface of what it can do, but within a few days I was doing some interactive 3D visualizations, using about 10 lines of code, that compare roughly to ones I'd done in Fortran using ~10000 lines. To be fair to Fortran, about 95% of those 10000 lines dealt with setting up and implementing the GUI in the Windows event loop. Mathematica is under-appreciated. I hope they don't go the MATLAB route and bloat it with too many "features". Unlike MATLAB, their user support has not yet migrated to India.

I take it you use OpenGL ? I've looked at it, but all the Graphical programing i've done was in DirectX. I'm actually pretty disgusted with it. Microsoft keeps coming out with a New Version, and the code I wrote for the older version Wouldn't work without being almost completely re-written. After DirectX 8, I quit bothering to update.

Ever mess with DirectX ?

hanelyp · Post by **hanelyp** » Sat Mar 20, 2010 4:41 am

DirectX has a fatal flaw from my viewpoint, it's tied to a specific OS. OpenGL, with the right support libraries, works with all the major systems. As far as predictable and portable C code, the right selection of libraries and compiler help a lot. Using SDL and building with GCC, I've written multimedia code that has less than a dozen source lines that need to be patched between M$ windoze and linux outside the support libraries. The same code should build and run with few if any patches on OS-X. As for configuring the build to a target system, I wrote a script in perl to search installed libraries for matches. Porting the app to winCE required a different C compiler and a few more patches.

DeltaV · Post by **DeltaV** » Sat Mar 20, 2010 5:49 am

Diogenes wrote:I take it you use OpenGL ?

I was deeply into it about 5 years ago, but have gotten a little rusty. The older I get, the less I want to mess with distracting details when trying to visualize something, which is why I've now switched to Mathematica.

I still recommend OpenGL over DirectX*. A good resource is
http://www.opengl.org/
and for beginners (using Windows) I recommend starting with GLUT,
http://www.opengl.org/resources/libraries/glut/
to get the hang of it. You'll need to switch to a library made for your language of choice to exercise the finer points, but GLUT is a good place to start. In the last 5 years, a better intro may have appeared, I don't know.

*[Edit] My OpenGL executables have run fine over 3 or 4 versions of Windows. I try to minimize use of OpenGL extensions, just in case some particular video card/driver doesn't exactly follow standards. During development, most of my crashes occurred in video drivers.

Diogenes wrote:Ever mess with DirectX ?

Never tried it. I wanted to be independent of Microsoft as far as possible wrt graphics. OpenGL is implemented on a given system as either HW-accelerated (video-card specific drivers, faster, but driver quality and strict conformance to the OpenGL standard may vary) and non-HW-accelerated Generic (there was also a generic version put out by Sun, I think, supposedly better). Microsoft grudgingly added the generic OpenGL to Windows several versions back, after enough people complained, but as of Win2000 (maybe XP too) my experience with it was that it was crippled. I could never get light source positions to work right for code using the Windows generic implementation. I preferred the HW-accelerated drivers anyway, but, for portability, wanted a fall-back in case the the HW initialization failed. The Windows generic implementation always yielded a "headlamp" light source, no matter what I tried. I'm guessing MS did this intentionally, to favor DirectX.

DeltaV · Post by **DeltaV** » Sat Mar 20, 2010 6:00 am

...and I haven't used a goto since the 70s

I just remembered where I did, so make that the 80s.

DeltaV · Post by **DeltaV** » Sat Mar 20, 2010 6:20 am

DeltaV wrote:
Tom Ligon wrote:C does nothing useful without headers and libraries that are almost never standardized. By the time you install enough of these to get your code running, you wind up with a porker full of unused junk with unpredictable habits, slow to compile, and a memory hog.
Fully agree.

I was maybe a little too hard on "C" (I do hate header files though, and the kitchen sink listings). I've actually written some very fast graphics code and also real-time embedded code with Turbo C++ and MS VC++, but used no features that could not be found in any good, structured language (no OOP, pointers, etc.). Avoid the bells and whistles, stick to core functionality (makes code faster, more robust, more portable). Admittedly, these were not something, say, web-related, so this strategy worked well. The Turbo C++ manual had a picture of fly (insect) taxonomy used to illustrate some concept (polymorphism?), maybe that's what permanently turned me away from ++, #, etc.

kunkmiester · Post by **kunkmiester** » Sat Mar 20, 2010 7:03 am

I've been getting into microconrollers, for robotics, and there seems to be little support for them in mainstream.

the arduino is based around Atmel chips, and is probably currently the best hobby setup so far, there's a Java based IDE derived from Processing, and a C# I haven't looked at yet, but that's the best. Anything else is either industry oriented, and somewhat chip specific, or is convoluted. It doesn't help that the architecture is different on every family(and even within).

The big deal is not only do you have to write and compile a program, you have to load it to the chip. Few IDEs are designed for that, and so usually you have to use another program, which adds complication for someone who just wants to see something running around. Not much help for it though.

I'm also looking at a startup project that could definitely use reasonable multi-threading, or a semblance thereof. Few microcontrollers have built in support for it.

This thread was both discouraging and encouraging. It seems there are easier languages than C++ to be working in, but there's little to help do what I want with them, which means working in the more common languages, and C++ has been tending to look like Greek to me lately.

icarus · Post by **icarus** » Sat Mar 20, 2010 11:34 am

kunkmiester: you want to look into Eclipse IDE ...

http://www.eclipse.org/

Tom Ligon · Post by **Tom Ligon** » Sat Mar 20, 2010 2:50 pm

Delta V,

I have Turbo C 2.0 around here someplace, but have not done much with it. I expect it writes cleaner compiled code than most because of Borland's approach. When they wrote their first version of it, they did a really good job of it and proceeded to overhaul Turbo Pascal to be compatible, including making it Object Oriented. They use the same user interface and are supposed to compile to nearly indistinguishable machine language.

This was back in the day of limited memory and a few MHz of clock speed. They took the delightfully old-fashioned idea that one should make the best use of memory and speed. The compiler reviewed the code and stripped out any subroutines that were never called. I was simply blown away with how compact and fast the resulting programs were. Both Turbo Pascal and Turbo C should share this characteristic.

One of the EMC2 programmers worked for a while at a company that wrote Oracle database tools. They had a successful program that was due for a new release. Before starting, they decided to upgrade to the newest release of C compiler. She said they first decided to try it out by re-compiling the original software, which had come in at about 5 megabytes on the old compiler.

They punched the button, the thing churned for a while, and out popped 30 megabytes of crap. It did run, but they had no idea what the extra 25 magabytes was supposed to do.

I was personally disgusted by a browser that would not communicate error messages I knew very well my dialup modem was generating. I would hear the line hang up and get a dial tone. The browser would pop up a message saying that it could not find the website, and maybe I should check the spelling. The modem was definitely capable of detecting a hang-up and dial tone, and produced appropriate status bytes, but the freaking programmers were too damned lazy to pass this rather useful information along. So now we get General Protection Faults, or else "an error occurred at address blah-blah (meaningless unless running from the compiler so you can track back to the actual line where the problem occurred). Failure to error-trap and to produce meaningful error messages would have earned a failing grade when I was studying this stuff.

More than a decade later, the problem can only have gotten worse. Nobody has a clue what is in some of these libraries and headers any more.

You can get around it by sticking to really primitive classes, but if you start to rely on layers of old work, you have no idea what you are including.

MSimon · Post by **MSimon** » Sat Mar 20, 2010 3:45 pm

DeltaV wrote:
...and I haven't used a goto since the 70s
I just remembered where I did, so make that the 80s.

I use them all the time. But I write in assembler. ;-)

BenTC · Post by **BenTC** » Sat Mar 20, 2010 4:14 pm

kunkmiester wrote:I'm also looking at a startup project that could definitely use reasonable multi-threading, or a semblance thereof. Few microcontrollers have built in support for it.

All the power of Linux on an ARM microcontroller. Eclipse IDE.
http://www.embeddedarm.com/products/boa ... ct=TS-7550#
Check out the Hardware & Software tabs, as well as the Schematic and HALT Report on the Resources tab, and the Peripherals link at the top of page.

Disclaimer: I haven't used these guys - but I've been wanting to for a couple of years.

Tom Ligon · Post by **Tom Ligon** » Sat Mar 20, 2010 4:22 pm

Everybody uses GO TO statements. They just mask them using high-level program structures.

You don't really think elegant CASE statements compile without resorting to JUMP or JUMP REL instructions, do you?

MSimon · Post by **MSimon** » Sat Mar 20, 2010 4:23 pm

BenTC wrote:
kunkmiester wrote:I'm also looking at a startup project that could definitely use reasonable multi-threading, or a semblance thereof. Few microcontrollers have built in support for it.
All the power of Linux on an ARM microcontroller. Eclipse IDE.
http://www.embeddedarm.com/products/boa ... ct=TS-7550#
Check out the Hardware & Software tabs, as well as the Schematic and HALT Report on the Resources tab, and the Peripherals link at the top of page.

Disclaimer: I haven't used these guys - but I've been wanting to for a couple of years.

The Z-80 Forth I'm writing will eventually get ported to ARM (it was my original target).

Diogenes · Post by **Diogenes** » Sat Mar 20, 2010 5:30 pm

MSimon wrote:
DeltaV wrote:
...and I haven't used a goto since the 70s
I just remembered where I did, so make that the 80s.
I use them all the time. But I write in assembler.

I'm with MSimon. I prefer to use assembly.

My advice to anyone doing Robotic like projects is to Pick a processor, learn the architecture and instruction set, then write everything in assembly.

Lately, most of my projects have been using the PIC 16F690 processors, (because they're cheap, reliable, and easy to program with a PC) but i'm always looking out for something better. I actually hate the PICs Instruction set, and lack of instructions, but i've managed workarounds for all the projects i've used them on so far.

Of course this processor is only useful for relatively simple tasks. If you need something that has megabytes of memory and storage, you are probably going to have to put together a system.

kunkmiester · Post by **kunkmiester** » Sat Mar 20, 2010 5:58 pm

I have an ARM based single board, that has a 100Mhz processor, among other advantages, but it's pretty much programming a computer, and anything I write for it I'd imagine I'd be doing linux or DOS based. Atmel promises to be much simpler, and it will be recycled a few times.

I suppose learning assembler wouldn't be too bad with just the one chip, but it'll be a pain in the butt to write anything really fancy for it. I'll have to look into eclipse.