I can kind of sort of read basic C and C++ and I regularly get subjected to assembly but don't understand any of it.

I've never actually programmed or been able to attempt it, though.

Please specify what sort of Assembly, but i bet you imply some sort of x86

This one.

C++, fairly exclusively. Have dabbled around with Java and Python and Actionscript 3, but the former was a couple years ago, and the latter two I only even touch because my less technically-inclined friend often wants help and insists on using such abominations. They're still a pain in the ass for me to read or do anything at all in.

Could probably get into assembly easily enough, though.

Post has been edited 2 time(s), last time on Jul 3 2012, 7:18 am by EzDay281.

Latex isn't really a programming language, it's a markup, like HTML.

Mostly C/C++, Visual Basic, PHP, HTML/CSS. Used to be way more familiar with JavaScript, but haven't done anything in a while. Dabbled in SQL stuff (PHP) and C# (XNA). I've played with x86, but I'm not terribly familiar with it. I'm more familiar with z80 (TI-83+ ). I'm assuming you're referring specifically to x86, though.
I think I've done some LUA somewhere, but I didn't mark it ... If I marked everything I've touched the list would be enormous.

I'm confident that I can use pretty much anything (as long as it isn't too ridiculous or novelty), though my skill level in each is probably pretty low (amateur!).

What about Actionscript : [

Slip it into the other category.

I wrote a few smaller programs to learn the basics of the language and give an introduction to COBOL in my paper. So I know the divisions, fixed reference format, picture symbols, control structures (if & procedures), program calling with parameters (+ call by reference/content) & basic commands for data manipulation and calculations.
So I could write some programs. I'm basically missing file in-output in the linkage section and data field manipulations, I guess, but that isn't that hard after you learned the basics I listed.

I wouldn't want to use it for a real program, but there are tons of COBOL programs existing and running in the world in firms with mainframes and their COBOL programmers are retiring.
Implementing bigger math functions in scbw triggers felt more complex.

SCBW triggers are rudimentary event-driven programming. And it's very weak as a tool, requiring very complicated procedures to do simple computations.

Which actually encourages development of logic and design skills, at least to do complex things in a robust manner using the limited tools at your disposal.

Dealing with SC triggers in my maps has actually strengthened my design skills quite a bit.

I assume he's thinking of some form of x86 as well. I have also worked in ARM and AVR though.

I feel like all object-oriented imperative languages are roughly equivalent at some point, but I checked those which I have actually worked in (but seriously, how different is C# from C++?).

In addition, I have hardware design experience in VHDL and Verilog, though they are not really programming languages per se (but much more so than HTML).

Just enough that it is absolutely obnoxious to try and do anything at all with C#. ;o

Yeah, there's a significant difference. C# is very closely related to Java, so unless you think Java and C++ are very related, you can't make the comparison for C# and C++.

C++, for instance, is complete crap with handling collections, and C# is amazing at it.

Pascal, R, SAS, C++. The only one I consider myself reasonably good at is R though.

C++ doesn't have garbage collection because the idea is that it's too important to leave to a compiler for people to ignore. So it's not "crap" at collections, C++ and C# have just vastly different design intentions.

I think he means stuff like lists or dictionaries, not garbage collection.

I meant as far as actually using collections, it seems to be a lot more work in C++ than C# in most scenarios. For example, say I have a Person object with a Cash property (decimal) and a Country property (enum). I have a collection of People, and I want to get all U.S. citizens with at least 50.0 cash and give them $5 more. Here's the entities in C#:


As for the actual code:

Or, if you prefer to be more succinct, you can do it all like this:

Granted, I only know a little C++, but I can't imagine it being more succinct than that. You would need to declare your iterator, specify the begin and end of the for loop, etc., etc. If you needed to use that filtered list again (like, say I wanted to print to the console the sum of those people's cash), in C# you'd already have the variable ready in the first implementation, but in C++ you'd have to either filter it again (dumb idea) or declare a new list variable and add each desired person in the for loop to that new variable. C++ would be more optimized in this example because you'd only iterate over the collection once, though I could easily rewrite the C# code to do the same:

All-in-all, I find working with collections in C# to be much more flexible than C++. I go by "the best code is no code at all," though, so that's why I prefer succinctness (less room for error). That's why I said C++ is crap at collections by comparison.

Post has been edited 1 time(s), last time on Jul 9 2012, 2:13 am by Roy.

I asked Lanthanide whether I should have included C# with C/C++; he said no, so that's the reason I didn't.

And it's good you didn't, they are not the same at all. C# is M$ making their own java, basically.