Which programming languages do you use most?

[xstream]

From most to least used:
PHP
Java
JavaScript
C
VB

[i_like_sparks]

I use mostly MATLAB for quick prototyping and C++ to make it fast.

[99wilksjam]

Good question!

I use PHP , HTML, JavaScript for web design and some backend stuff,

C++ for the odd program and then .NET sometimes. I would love to learn java, Maybe i'll invest in the time.

[perfect_disturbance]

I'm going to drop an esoteric one here ColdFusion (hey what can I say it's my day job)
When I get to choose
Python for web and system stuff.
Java for object oriented stuff
Perl for text processing.
C for embedded

Really there are a ton of great programming languages out there learn a bunch and you'll find out you like a few for different reasons.

[zapta]

Professionally i am doing mostly c++ and java. Sometimes for large cloud systems, sometimes for small mobile devices.

Two emerging languages I plan to learn are Go and Scala.

[cloudscapes]

C for 32bit micros.

Basic (bascom) for AVRs. I started on these before I learned C, so if I were to learn them again for the first time, it would surely be in C.

A tiny bit of VB when I need to make a quick tool to format data for me. Example, wrote a graphical tool that allowed me to draw out what kind of image I wanted on a 5x7 LED matrix, and it would spit out the nicely formated data and code I could simply paste in my "display driver". It's not "1 pin 1 led", it goes through rows and columns, so it was a little tricky.

[HackedFridgeMagnet]

climbed into ook, got damaged by brainfuck, can has teh Lolcodez, impressed with Piet.

http://net.tutsplus.com/articles/top-10-most-bizarre-programming-languages/

[true]

English.

[klox]

Anyone else program in Spanish?

[c4757p]

The last time I tried that, my family threatened me with a visit to the psychiatrist.

[kphannan]

I have to say quite a varied assortment:

Java - User facing applications (along with Objective-C)
C - Embedded
C++ - Embedded
Objective-C - iOS & Mac systems - some C / C++ for real low level stuff.
Bash - scripting - glue to hold projects together - automation
Perl - similar uses to Bash
PHP - websites

C / C++ is kind of a wash over which one for embedded programming.  The smaller the device the more I tend toward C.  ARM devices more C++.

[davemisbehave]

My first programming experiences were in TI-BASIC on the TI-83 calculator.
For micros I use assembly if efficiency is the highest priority. Else C.
On computers I use C and avoid C++ if possible, as i'm somewhat of a C purist.

[perfect_disturbance]

My first programming experiences were in TI-BASIC on the TI-83 calculator.
For micros I use assembly if efficiency is the highest priority. Else C.
On computers I use C and avoid C++ if possible, as i'm somewhat of a C purist.

Don't fear C++ It's just c with objects and objects rock.

[denizcan]

I say, a persons job is the job she/he has been doing for last 6 mounts..

For last 12 mounts, I've been using:
- C++ for %90, for any embedded project (I don't know if it is 90, but I feel like it..
- Assembly for critical sections
- Assembly for checking how C++ compiler is performing. (So far so good)
- Python for quick fixes
- .net (mono) for PC related, including Linux and OSX..

About C++, actually it is C compiler with additions of namespaces, templates, classes etc.. And for me, it is a lot more powerful than C.. The code written by it is much more reusable.. For me reuse is the much much more important than the performance and resource usage..

I always write nearly any part of project with C++, apart from reusability, it is syntactically better than c.. For instance:

core.init is better than initCore..
i2c1.start() is better than i2cStart, or startI2C..
uart.open() is better than openUart..
etc..

Actually you are writing in C++ if you are doing:
openUart(UART0);

you are passing a parameter that defines which resource to work on to driver software.. In C++ it is passed as this and C++ is better than you in doing that.. except from virtual methods, only addition is this.. if you are calling a static method, the generated code is same as C generates..

for instance, core.init compiles same to initCore..

I use overloading and inline methods frequently, which enables cleaner code..

Inheritance is really powerful, and also helpful.. For instance my SPI system is based on Spi and SpiNode class that are abstract.. Some MCU's have USART that may work as SPI and also dedicated SPI ports, or SSP.. All are diffent in hardware basis.. I subclassed Spi class for  USART driven, SPI driven and SSP driven separately. However, an SpiNode doesn't need to know if it's Spi is based on USART, SPI, or SSP or even software based.. It just calls port->shift(..), port->shiftAsync methods.. That's it..

You can do this:

Code: [Select]

// using usart0 as spi
usart0Spi.open();
MCP4921 dac;
dac.setPort(usart0Spi);
dac.setValue(1234);


Code: [Select]

// using spi0
spi0.open();
MCP4921 dac;
dac.setPort(spi0);
dac.setValue(1234);

As you can see all the code looks same.. usart0Spi and spi0 are already defined in library. if you use one variable, for instance usart0Spi, all related methods are automatically included by linker.. And your USART is in SPI mode when usart0Spi.open() is run.. isn't it nice?

one time, I used ADXL345 in SPI mode sharing same SPI with other sensor.. How on earth a hardware designer makes this mistake I don't understand. It enters into I2C mode when an SPI transfer occur with other chip.. I didn't have spare hardware based SPI port, and I was using ADXL as oscillation detection so it must be read fast.. I just wrote SoftwareSpi, moved the other chip to GPIO pins and both chips started working..

Isn't it worth?

[denizcan]

by the way, I think "C++ adds a lot of overhead" comes from template library and exceptions.. They are implemented really but really bad.. As if someone was playing with a toy. Just look at vector or queue class.. Ok, it is powerful, but how often are you going to use its power? None.. How much code it generates? A lot..

Exceptions are nearly useless on MCU. I mean, I except, concept is exception-al, however implementation makes it useless.. When you enable exceptions, it adds and adds tons of code, eats RAM.. When an exception occurs, rolling back takes ages.. I think it is designed by academics, and I think academics have no clue about practice..

If you don't use template library, exceptions etc, C++ is flawless.. For instance I just defined my Queue..

Code: [Select]

Queue<Short> q;
q.push(1);
q.push(2);
a = q.pop();
b = q.pop();

a = 1, and b = 2.. You can use same code for any valid type, even for structs.. How could you do this in C? If you look at the assembly it produces, you will regret saying "C++ is not for embedded"..

[andyturk]

by the way, I think "C++ adds a lot of overhead" comes from template library and exceptions.. They are implemented really but really bad.. As if someone was playing with a toy. Just look at vector or queue class.. Ok, it is powerful, but how often are you going to use its power? None.. How much code it generates? A lot..

Code space isn't an issue if you're deploying under Linux (or some other multitasking OS). STL may not be appropriate for your mcu, but it's still an incredibly useful and well implemented body of code. Don't write it off as a "toy", learn from it.

Exceptions are nearly useless on MCU. I mean, I except, concept is exception-al, however implementation makes it useless.. When you enable exceptions, it adds and adds tons of code, eats RAM.. When an exception occurs, rolling back takes ages.. I think it is designed by academics, and I think academics have no clue about practice..

Patience, young grasshopper.

C++ exception handling makes sense when you understand why it was added to the language. Exceptions are vastly better than explicitly checking an error return value after every function call, which is what some of us had to do in the old days. Yes, there's a lot of overhead with exceptions, but that's not because the language designers were silly academics, it's because writing "airtight" code is non-trivial--you have to check everything and check it all the time.

That said, I turn off exception handling for code intended to run on an embedded system--not necessarily because of the overhead, but because I'm not using the RAII idiom. Scoped resource allocation doesn't work that well when you've got a small amount of RAM to deal with. So instead of allocating objects and runtime with malloc/new, it's better to just make them static so you know exactly how much memory you need at link time (not including stack usage, of course). Thus, if you're not allocating stuff at runtime, you don't really need exceptions.

If you don't use template library, exceptions etc, C++ is flawless.. For instance I just defined my Queue [...]

Yep. Templates are cool. They're sort of like #define macros on steriods. Assuming you have access to a good compiler (e.g., GCC 4.7) they only get expensive if you end up with too many instantiations.

I'm working on a project that's using Eigen in an embedded environment, for some badass number crunching. Very cool stuff.

[denizcan]

Code space isn't an issue if you're deploying under Linux (or some other multitasking OS). STL may not be appropriate for your mcu, but it's still an incredibly useful and well implemented body of code. Don't write it off as a "toy", learn from it.

What makes you think that I have not learned from it? As I said, it is powerful, however most of the time you do not need that much power.. Simplicity is the key for me.. It might not be a problem if you think of PC environment, but it isn't for embedded. At least yet.. RAM is a scarce resource now.. When it is not, it might be appropriate. However, I again say, simplicity is the key..

C++ exception handling makes sense when you understand why it was added to the language.

Again what makes you think that I do not know the value of exceptions? Aside from making you free from error checking macros/statements, it also helps resource control etc etc.. On PC programming I always prefer exceptions to error codes. What I am saying: current implementation, I have phrase this in bold current implementation is not worth -again in bold- on embedded. It takes to much time to roll back. CPU is halted for just for a simple error. As you know in MCU application halting CPU is nearly unacceptable..

[westfw]

For instance I just defined my Queue

No you didn't; you just used a definition of Queue that someone else wrote, which could be appropriate for your deeply embedded microcontroller, or it could have sucked in a bunch of methods with several layers of abstraction (queues use containers, right?) that use dynamic allocation of memory to resize and issue exceptions under some circumstances.

(and did they really use "push" and "pop" for a FIFO queue?  OMG *why*?)

[edit] Oh, wait!

Code: [Select]

Queue<Short> q;
q.push(1);
q.push(2);
a = q.pop();
b = q.pop();Whose implementation of "Queue" is this?  It's not compatible with the standard definition, but perhaps since you said to avoid the STL, this is a custom version?

[0xdeadbeef]

The question is which language to use for what purpose.
For a PC program, I don't see any reason to use C anymore.  Depending on the situation, I would use Java or C#, while I'd mess with C++ only for time critical or low level stuff.
For a typical microcontroller project with realtime requirements and limited resources, C is the only sensible decision for anything from 8bit AVRs up to 32bit ARMs - at least in a commercial environment.
At the real low end (8bit PICs with like 128 bytes of RAM and just a few opcodes or some integrated peripheral controllers)  ASM is still the only way to go.

Using C++ for microcontroller projects with only a few dozen (or maybe even some hundres) kilobytes of integrated SRAM and realtime requirements seems usually like a bad idea. You can use encapsulation and inheritance, but some core features of object oriented programming like non-static object instances and polymorphism are usually not usable if RAM and performance counts. Generally, it's very hard to impossible to keep full control of RAM allocation in object oriented languages. And the risk to get a heap or stack overflow is unacceptable in an embedded system.

Of course in a small hobby project it might be acceptable to waste resources - after all hobby µC programmers also mess around with basic interpreters, SW float implementation and usually put all of their code in the main loop to avoid messing with interrupts and DMA transfers. But in a commercial environment where every Cent counts, wasting resources means wasting money.

[sjheiss]

climbed into ook, got damaged by brainfuck, can has teh Lolcodez, impressed with Piet.

http://net.tutsplus.com/articles/top-10-most-bizarre-programming-languages/

I'm glad someone mentioned Piet. I once was very into it briefly, and thought about further developing npiet, but lost interest before I started...

I mostly write in C/C++, for anything (when applicable, of course). In the past I've used C# and Java, mostly when learning to develop simple games. I would never recommend making a game in Java; the engines and libraries are terrible, as is their support and documentation.

I've used some x86 assembly (mostly MASM) when practicing reverse engineering of Windows programs. ASM is still my favorite, since I have a hard time understanding abstract concepts. With ASM you can see and control everything, and nothing is hidden in the background, unless you do some macro assembly, but even then it's still easy to understand.

I've used a tiny bit of Python, but don't remember any. In theory I like it, but don't really like interpreted languages. I also want to get into Haskell (which I'm disappointed no one mentioned), but for some reason I can't get myself to start.

[blewisjr]

I know many programming languages but they ones I use the most right now are...

AVR Assembler (AVRASM2)
C

I am still in assembler mode for learning Micro controller stuff but I do love C and use that for most of my little desktop applications when I write them which is not often at all.  At some point I will probably use C on a micro.  Probably when I switch to ARM or whatever 32 bit chip I decide on.

[denizcan]

For instance I just defined my Queue

No you didn't; you just used a definition of Queue that someone else wrote, which could be appropriate for your deeply embedded microcontroller, or it could have sucked in a bunch of methods with several layers of abstraction (queues use containers, right?) that use dynamic allocation of memory to resize and issue exceptions under some circumstances.

(and did they really use "push" and "pop" for a FIFO queue?  OMG *why*?)

[edit] Oh, wait!

Code: [Select]

Queue<Short> q;
q.push(1);
q.push(2);
a = q.pop();
b = q.pop();Whose implementation of "Queue" is this?  It's not compatible with the standard definition, but perhaps since you said to avoid the STL, this is a custom version?

What's your point? If we use C++, we have to use STL? If I say Queue, do I have to define a class that is compatible what guys before me does? Are all you have done is universal? Could we not define (in programming language sence, not mathmatical sence) our own implementation of any concept? I don't care what Queue means in the point of view of a Computer Scientist. What I care is how long it takes me to write virtualy bug free, resource friendly application. That's it.. If it is rewriting queue, tasking, hardware abstraction layer classes etc. etc.. which I have already done, so be it.. Try using your "standard" library on a MCU and see how resource eating useless monster it is..

[denizcan]

Using C++ for microcontroller projects with only a few dozen (or maybe even some hundres) kilobytes of integrated SRAM and realtime requirements seems usually like a bad idea. You can use encapsulation and inheritance, but some core features of object oriented programming like non-static object instances and polymorphism are usually not usable if RAM and performance counts. Generally, it's very hard to impossible to keep full control of RAM allocation in object oriented languages. And the risk to get a heap or stack overflow is unacceptable in an embedded system.

Of course in a small hobby project it might be acceptable to waste resources - after all hobby µC programmers also mess around with basic interpreters, SW float implementation and usually put all of their code in the main loop to avoid messing with interrupts and DMA transfers. But in a commercial environment where every Cent counts, wasting resources means wasting money.

Where do you get those ideas? Do you have on hands experience or just speculating? Do you have to use "non-static object instances"? Have you measured the cost of encapsualtion and inheritance?

Encapsulation:

Code: [Select]

class A
{
private:
  void doSomething();
};

what is the cost of private method?

Inheritance. Means children behave different. Most of the time it is done by switch clause and function pointers.. What is the cost of switch and function pointers? The best implementation is the same what C++ does..

non-static:
Do you always use new MyObject style object creation? What about this:

Code: [Select]

Byte radioBuffer[64];
CC1101Spi radio;
GpioInterrupt radioInterrupt;
int main()
{
  spi0.open();

  radioInterrupt.setPin(P1_1);

  radio.setPort(spi0);
  radio.setSelectPin(P1_2);
  radio.setInterrupt(radioInterrupt);
  radio.open();

  Event radioEvent;
  while (1)
 {
    radio.receiveAsync(radioEvent);
    // do something,
    // do other thing

    if (radioEvent.wait(100))
    {
      //packet received
      radio.readFrame(radioFrame);
      // handle packet

    }
    else 
      radio.stopAsync();
  }
}

This opens spi0, creates an GpioInterrupt. Binds both to CC1101Spi radio. Calls receiveAsync() which initiates reception, and sets the given callback when reception is completed, while radio is active it does other things, than waits for radio, if reception completed in 100ms, it reads frame, else it stops reception, and loops..

I want to show you that there is no need of dynamic allocation even in very complicated tasks.. If you don't need async behaviour it is just this

Code: [Select]

  if (radio.receive(radioBuffer, 100))
  {
    //frame received
  }

Still, Where is non-static behaviour?

[0xdeadbeef]

Well, maybe you should re-read my post again as you seem to have read things that I didn't write. E.g. I mentioned encapsulation and inheritance as positive examples which you can use without heavy costs. You seem to have read the opposite, so it's kinda hard to argue with people who don't even closely read the things they get upset about.

Anyway, as soon as you create an instance of a non-static object (which you do all the time in a normal object oriented program - most of the time without even noticing it), you allocate RAM and the constructor is called if there is one (else the object members are initialized as 0). If you consider a normal OOP scenario, where objects are created and destroyed all the time, this creates a significant overhead.
Besides, as I pointed out, dynamic allocation alone is a no-go in a typical microcontroller project.

[andersm]

Could we not define (in programming language sence, not mathmatical sence) our own implementation of any concept? I don't care what Queue means in the point of view of a Computer Scientist.

You obviously don't care about communicating with other developers either. I've run into a couple of programmers who insisted on inventing everything themselves and using their own nomenclature. Every time it was a pain trying to figure out what they actually meant when using supposedly standard concepts like "lists" and "queues" and so on. Didn't help that by ignoring all the litterature and work that had gone before them, their re-invented wheels were usually pretty bad.