My favorite programming language? That would be Focal.

You never forget your first.

 

My favorite programming language? That would be Focal.

You never forget your first.

If I were just beginning to program, at my age, I'd use BiFocal and advance to Progressive.

 

...
I suppose the ability to create polls on this forum isn't very useful, since all polls have a bias.
...

A number of forums that I frequent have the option to create polls and it is useful, just not for the purposes of polling.

Polls on forums seem to be a very good way of achieving two things

1. Getting people to read a list of options and then debate those choices, which is I guess what you were looking for.
2. Getting people to debate the nature of online polls

 

The hell you say! My documentation control and RMA systems, as well as much of my production data/analysis is done with PHP on a LAMP stack. Wrote it all myself.

So what does that have to do with electronics? I'm sure you use these tools in support of you job, but they seem very generic in nature. I use Xcel and Access to support my job, but I wouldn't consider these electronics tools.

And why do you need your own RMA system?

(I assume by RMA, you're talking about Revision Management?)

 

So what does that have to do with electronics?

In my shop, everything.

I'm sure you use these tools in support of you job, but they seem very generic in nature.

Actually, they are quite specific....I wrote them to solve exact problems with respect to my research/design/development/manufacturing activities.

I use Xcel and Access to support my job, but I wouldn't consider these electronics tools.

I would. An Excel (actually Libraoffice Calc) spreadsheet is far more useful to me than spice simulation. It's a heckuva tool that is an integral part of my design/development process. But, unless you're into a lot of macros, I wouldn't consider writing an Excel spreadsheet "programming". This assertion, of course, will be argued by somebody.

And why do you need your own RMA system?

(I assume by RMA, you're talking about Revision Management?)

RMA=Return Material Authorization. My Document Control System does revision control/change management.

It's custom for the same reason why my document control software is custom. There is *nothing* available (at reasonable cost) that does what I need it to do.

A good engineer can make his own tools when he has to. Once, this was a requirement of the job. Today's engineers, just like everyone else, are spoiled.

 

Actually, they are quite specific....I wrote them to solve exact problems with respect to my research/design/development/manufacturing activities.

Oh, I'm sure your tools were created to address specific issues related to your efforts. I just don't consider things like Document Control to be electronics, but a generic and necessary element of most any creative process. In other words, what would prevent me from using your document control system, with minimum modifications, in my (hypothetical) spirit distillation systems design business?

I would. An Excel (actually Libraoffice Calc) spreadsheet is far more useful to me than spice simulation. It's a heckuva tool that is an integral part of my design/development process. But, unless you're into a lot of macros, I wouldn't consider writing an Excel spreadsheet "programming". This assertion, of course, will be argued by somebody.

I don't say this often about tools, but I love how macros integrate with these tools. I use them on almost every job.

RMA=Return Material Authorization. My Document Control System does revision control/change management.

Thanks for clearing that up.

A good engineer can make his own tools when he has to. Once, this was a requirement of the job. Today's engineers, just like everyone else, are spoiled.

I agree about creating his own tools, though I would always try to find something that works before I make something. Not sure about the spoiled part though

 

Let me put it this way: All else being equal, if I had a choice of projects where one is best coded in C, and the other is best coded in .asm, I'd choose the second. Not because I am better at .asm than C, but because, to me, .asm is more fun (i.e. it is my "favorite language").

And, "favorite" is subjective. Let us not argue about such things (lest I inform you that your choice of wine with that particular filet mignon is incorrect).

It freaked me out once i realized I have to relearn for each new MCU.
18F PIC assembly is quite pathetic if you shuffle data with the 2 FSRs and use the auto increment/decrement options. I wrote a source for a particular task, it looked quite complicated, then showed it to someone, who particulary wasnt willing to relearn the particular assembly instruction set.

useless piece of source code, fail.

Then I changed over to C when trying out USB PICs.

OK I made a 1K LCD clock years ago, its an effervescent complex array of sources maybe 20 files.

Now I use SD card, TFT, USB...a lot of C source is needed. How would that look like in assembler?

I've stopped completely using it, even simple LED 7seg stuff with 16f54 is done in C exclusively.

 

How about BCPL?

I've analyzed it. It seems to be the author has built in a lot of doors for every special situation.
the concept is quite modern looking- generate some intermediate code, then pass that to a run-time engine.

But I wasnt able to see a benefit to using C language.

For what it is worth I moved away from C++ / Windows applications- its changing every year or so, dont want to relearn all the time.

 

My documentation control and RMA systems, as well as much of my production data/analysis is done with PHP on a LAMP stack. Wrote it all myself.

OK, so PHP isn't necessarily as far removed from electronics as I thought.

If any forum admins happen to be reading this, please don't edit the poll. I was being too picky about the choices on it. Since my last post, I realized that editing it could potentially change the results, because the languages in the "Other" category would change.

 

On a completely different topic: What happens if someone on this forum creates a conversation, invites some members to it who don't join it, and then leaves the conversation? Does it just get deleted?

I'm asking this because I had created a conversation last week about editing this poll that wasn't joined and now I wanted to delete it. I left the conversation, and now I can't find it, but will the members that I invited still see it?

 

It freaked me out once i realized I have to relearn for each new MCU.
18F PIC assembly is quite pathetic if you shuffle data with the 2 FSRs and use the auto increment/decrement options. I wrote a source for a particular task, it looked quite complicated, then showed it to someone, who particulary wasnt willing to relearn the particular assembly instruction set.

useless piece of source code, fail.

Then I changed over to C when trying out USB PICs.

OK I made a 1K LCD clock years ago, its an effervescent complex array of sources maybe 20 files.

Now I use SD card, TFT, USB...a lot of C source is needed. How would that look like in assembler?

I've stopped completely using it, even simple LED 7seg stuff with 16f54 is done in C exclusively.

My .asm code for a typical project is between 10K and 20K lines of source code, distributed amongst various libraries that I've developed over the years and code specific to the application. This is professional stuff, not "blink an LED".

Yea, it freaks me out as well whenever a compiler update breaks my previously perfect code, or a third party library interface has changed, or the development suite that supported my choice of compiler is no longer maintained. Life just sucks for all of us.

 

OK, so PHP isn't necessarily as far removed from electronics as I thought.

If any forum admins happen to be reading this, please don't edit the poll. I was being too picky about the choices on it. Since my last post, I realized that editing it could potentially change the results, because the languages in the "Other" category would change.

Just speaking to the choice of languages on the poll, there are some languages that used a LOT in electronics that aren't on there -- for instance, Verilog and VHDL. Then there are scripting languages such a Tcl/Tk that are used a lot.

 

On a completely different topic: What happens if someone on this forum creates a conversation, invites some members to it who don't join it, and then leaves the conversation? Does it just get deleted?

I'm asking this because I had created a conversation last week about editing this poll that wasn't joined and now I wanted to delete it. I left the conversation, and now I can't find it, but will the members that I invited still see it?

This is better asked in the Feedback and Suggestions Forum.

 

My .asm code for a typical project is between 10K and 20K lines of source code, distributed amongst various libraries that I've developed over the years and code specific to the application. This is professional stuff, not "blink an LED".

Yea, it freaks me out as well whenever a compiler update breaks my previously perfect code, or a third party library interface has changed, or the development suit that supported my choice of compiler is no longer maintained. Life just sucks for all of us.

sure I got it. 10 to 20K is not much for assembler. One time I wrote a 300K source for x86.
Often professional assembler programmers develope their own techniques and syntax and way of doing things, for sure highly efficient, but its just baffling, even if you really want to understand the source code. Commenting and structuring are often poor, and almost everything is non-standard.

I did for instance use a C source for FAT filesystem, played with it a little, and then it worked on a PIC32.
Isolating the hardware dependent parts in assembler takes a lot of discipline- where's the point when the instruction set is MCU specific anyway?

Some time I started work for a 8080 emulator- each CPU instruction needs a few lines C. There is nothing that cant be done with C. Currently I lack motivation to dig down deeper.

 

sure I got it. 10 to 20K is not much for assembler. One time I wrote a 300K source for x86.
Often professional assembler programmers develope their own techniques and syntax and way of doing things, for sure highly efficient, but its just baffling, even if you really want to understand the source code. Commenting and structuring are often poor, and almost everything is non-standard.

I did for instance use a C source for FAT filesystem, played with it a little, and then it worked on a PIC32.
Isolating the hardware dependent parts in assembler takes a lot of discipline- where's the point when the instruction set is MCU specific anyway?

Some time I started work for a 8080 emulator- each CPU instruction needs a few lines C. There is nothing that cant be done with C. Currently I lack motivation to dig down deeper.

You are not going to sucker me into a C vs .asm debate. Been there, done that.

I've seen bad code in both languages. Most of it right here in this forum.

 

I am impressed with your computer graphing skills. Why do we need a graph?

John

 

I am impressed with your computer graphing skills. Why do we need a graph?

John

It can be helpful to visualize the data, or if someone wants an image to summarize the results. I suppose for this poll it doesn't make as much sense as others I've seen it done for, since the results aren't very meaningful.

@jpanhalt: Which graph do you prefer? I can delete the other one.

 

I think you may have missed my point.

Assembly is still a valid MCU language. You did not include that as an option. You got 19 responses from 253,129 members ( a response rate of 0.0075%). The approximate coefficient of variation considering a Poisson distribution of your data is 23%. Your data are meaningless. Why prolong the agony by posting a graph? Did you not understand the comments in posts #36, 43 and others?

John

 

I think you may have missed my point.

Assembly is still a valid MCU language. You did not include that as an option. You got 19 responses from 253,129 members ( a response rate of 0.0075%). The approximate coefficient of variation considering a Poisson distribution of your data is 23%. Your data are meaningless. Why prolong the agony by posting a graph? Did you not understand the comments in posts #36, 43 and others?

John

Sorry, I deleted my post containing the graphs.

@jpanhalt: I'm curious why more members (including yourself) didn't vote in the poll? Is it because Assembly wasn't included as an option? If more people had voted, the results wouldn't be quite as meaningless.

 

I think you may have missed my point.

Assembly is still a valid MCU language. You did not include that as an option. You got 19 responses from 253,129 members ( a response rate of 0.0075%). The approximate coefficient of variation considering a Poisson distribution of your data is 23%. Your data are meaningless. Why prolong the agony by posting a graph? Did you not understand the comments in posts #36, 43 and others?

John

(tjohnson: Please don't take any of the following as pointed at you directly -- it's meant as a general statement with all the caveats that go along with generalizations.)

There is a strong tendency for people to run with data even if they know the data is meaningless. We don't know how to quantify the validity of the data but we know how to make pretty pictures and how to crank averages and order totals, so we tend to make pretty pictures, crank averages, and order totals while forgetting about the issue of the underlying validity of the data and other pesky issues that we don't know how to deal with. Worse, the pretty pictures, the averages, and the ordered totals then get presented to people that have no basis upon which to even question the fundamental soundness of the underlying data and they perpetuate the "analyses" further up the food chain. The end result is that major decisions at very high levels often get made on the basis of fundamentally flawed data and the meaningless conclusions that grew from it.