Skip navigation

Monthly Archives: August 2013

I’ve watched the 3D printer scene for a while now… it’s getting pretty tempting to buy (or put together) one.

Here’s a site that has a pretty comprehensive list of 3D printers and their price-tag.

http://www.3ders.org/pricecompare/3dprinters/

3Ders

In other areas of the 3D printer world:

There are plans to invent a sub $100.00 model though it isn’t there yet.

And there are even plans for 3D printer/CNC milling machines.

“Which programming language should I learn first?”

A question that’s been debated for 25.6 years… or so.

Most online discussions go back and forth about what the “best” first programming language to learn is.

 

My opinion: You should learn the language that fits best with what you are trying to carry out now.

 

If you are testing and need rapid prototyping and quick’n’dirty code, stick with interpreted languages.

If you have the luxury of time and know a bit more about what your constraints and end goal is (or if interpreted languages are too slow) move on to high level languages.

If you are working with very limited resources or have strict constraints (or if you need solid speed and efficiency in the product) then learn low-level languages. Most won’t need this level.

 

(For a primer on what interpreted, high and low-level languages are then please watch the below video by The Ben Heck Show.)

———————————————————————————————

To summarize the video, in general there are three levels to programming languages.

Interpreted languages (e.g. python, Perl) are easier to read for beginners, compiled at runtime and are generally slower.

High level languages (e.g. C, C++) are harder to read, compiled into machine code and are generally slower to create, quicker to run.

Low level languages (e.g. Assembly, Machine Code) are not human readable, are much more specific to the application/processor and are the quickest to run.

That is a very general description but it is a nice overview.

Don’t blink. Blink and you’re dead. They are fast. Faster than you can believe. Don’t turn your back. Don’t look away. And don’t blink.

Good luck.

-Tenth

Only 1 week into my experiment with mobile programming with IDEOne and DeuterIDE and everything seems to be working as expected with an added bonus.

I definitely have to remember, and properly type everything in as there is no auto-complete. This is as expected.

IDEOne+DeuterIDE

The added benefit comes from the interaction between DeuterIDE and IDEOne. IDEOne creates a copy of any version of the program each time I compile with DeuterIDE (which I have linked to IDEOne from last post). This copy of the program could be perfect (probably not) or it could have many errors, bugs and typos.

That may not sound like a benefit but when I get to a desktop/tablet computer at a later time and go to IDEOne online I can go through all the older iterations of the program. The added benefit is that I get the opportunity to fix errors in my code.

In some cases I’ve already fixed the code once before and I should remember how to fix it – if I don’t remember how then I get to learn it again which hopefully sticks with me this time. In other cases I look into documentation to better understand what I am working with and fix the error while learning something new.

At this time I am quite satisfied with IDEOne plus DeuterIDE for mobile programming practice.

%d bloggers like this: