Braces lead to mismatch bugs though... if/endif while/endwhile case/endcase would probably have been a better design choice.

Braces lead to mismatch bugs though... if/endif while/endwhile case/endcase would probably have been a better design choice.

Only if your tools suck. For some reason I just can't abide by endif. Maybe it's my irrational hate of VB which spreads to other languages with similar constructs.

You can even mix and match, e.g. call Lua scripts from C++ code.

C is an '...f' (scanf etc.) and '%' language while c++ is a '...stream' (ofstream) and 'c' (cstdlib) language even though not as frequent as ';'

I don't quite understand this bit.

i meant i've been seeing a lot of scanf, printf and other somethingf in c codes and a lot of #include <iostream>, ofstream, istream, fstream and other streams in c++. I wonder why c++ has so many streams.
What they have in common is the ';' at the end of statements

Braces lead to mismatch bugs though... if/endif while/endwhile case/endcase would probably have been a better design choice.

Only if your tools suck. For some reason I just can't abide by endif. Maybe it's my irrational hate of VB which spreads to other languages with similar constructs.

i some how prefer if blah = 2 then/do cout << blah; rather than if (blah == 2)
{ cout << blah; }.
It's somehow more explanatory to use do/then after an if statement.
The {} does make code look prettier.

I ended up doing a lot of work on a few projects in a language that was mostly based on Python, and then I just started using Python for most of my work.

Community is one of the biggest things I look for in a language. If the community is strong with lots of people asking and answering questions, then it makes it so much easier to run to google when something goes wrong with your own code. Odds are good that someone else has run into the issue and already found a solution that is at least similar to what you are stuck on.

I prefer syntax that is clean and clear. I would rather read three lines of code and be 100% sure what it is doing at a quick glance than look at one short line of code after not touching the language for a year and risk mixing up if I'm looking at a pointer or a reference. (While I generally love working in C, I frequently end up not touching it for ages and then end up having to keep a cheat sheet handy to remind myself of which symbols are what.)

The actual structure of the code doesn't really bother me, as long as it is logical and consistent.

I dislike languages that allow multiple ways to write statements, such as conditionals allowing a single line without needing {} around where any multi line entry would use them. (I've just found them to be the source of so many utterly stupid bugs over the years when someone quickly updates pre-existing code and doesn't think about how they're actually entering a mind numbingly small change.)

at this point, I am mostly using C, my scripting language, and some C++.

what I like in general:

being able to get stuff done, which mostly means C (and maybe C++);

being able to fiddle with stuff, ideally with a moderately fast iteration time (major drawback of C and C++ for larger projects, a little better with script code);

being able to interactively type code-fragments into the console (big script language advantage), or being able to edit and reload code without needing to rebuild the engine (or even necessarily exit and restart);

I mostly prefer C-like syntax (I know it well, and generally like the way it looks);

I also prefer not having code perform like crap (good for C and C++, bad for scripting languages);

I prefer not having to go through too many contortions to handle cross-language interfacing;

...

my scripting language is custom. it was originally based on JavaScript (as sort of a lazy knock-off), but at this point is closer to being a ActionScript3/C/C# hybrid.

granted, it figures I should like it to some extent, since I made it, but there are still things I don't like about it:

stupid declaration syntax issues;

performance is still pretty weak vs C;

despite the lots of work put into the FFI, it still falls a bit short of being "transparent" in many cases;

the actual VM architecture and internals are pretty much straight-up horrible (awful bytecode design, ...);

...

it still ends up mostly seeming like a "toy" vs all the rest of the engine getting much more serious work done in C and similar, mostly something largely constrained to high-level glue, bits of game-logic, bits of UI coding and simple "console programs", ...

it canonically uses JS/AS3 like declaration syntax, but also sort-of supports more C/Java/C# style declarations, but then leads to the apparent stupidity of having multiple ways to declare things ("var i:int;" vs "int i;", ...). (nevermind weirdness, like pointer types being declared as "*int" rather than "int*", ...). (nevermind the differences between C, Java, and C# style declaration parsing. like while cosmetically similar, each approaches the actual parsing part a bit differently...).

it is still a bit slow vs native C code speeds, but is fast enough to really justify optimizing it (not particularly significant in profiler).

for tests involving things like sorting and numerical array-handling, it gets within about 3x of C speeds, but is slower in other cases (cross-language function calls and interface method calls are slow, ...).

code effectively has to follow various rules to allow sharing code/data across language boundaries, so neither C nor script-code can use its "full glory" in places where cross-language interfacing is involved (though, the interface is, at least, mostly free of the need for glue/boilerplate).

I wanted to have it be more like the C <-> C++ interface, but it falls a bit short of this.

ex: there are restrictions on how shared structs may be represented (and how they should be allocated), issues involving the use of cross-language callbacks (may need to go and better address the whole "shove script functions into C-side function pointers" thing), ...

though, it works, and I have seen lots of things a fair bit worse...

arguably it is a bit debatable if it has all been worthwhile though.

well, and it also requires a fair bit of fiddly when copy/pasting code between languages to make everything work (IOW: copying globs of C into script-code and similar). but, the overall syntactic similarities makes this at least sort-of viable (vs if the languages had somewhat different syntax and the code had to be nearly entirely rewritten). in some cases, the script language makes concessions to "C-isms", like allowing "obj->field" and similar (otherwise, one will have to go replace all '->' with '.', where the script-compiler mostly treats them as equivalent, ...).

well, and there are a lot of the inherent limitations of doing stuff myself...

IOW: lots of time generally going into "making stuff" and addressing internal infrastructural issues and so on (like, rather than continuous rapid progress, a lot of time may go into fixing infrastructural problems or various bugs or similar, ...).

or such...

I searched around for stuff and saw array slicing. I like how it's done in python. You don need a for loop to display more than 1 element in an array.
D has it too but C and C++ don't.
It doesn't require more than 2 lines (or 3) to display an array compared to a for loop.

Braces lead to mismatch bugs though... if/endif while/endwhile case/endcase would probably have been a better design choice.

Only if your tools suck. For some reason I just can't abide by endif. Maybe it's my irrational hate of VB which spreads to other languages with similar constructs.

I agree. Plus it's pretty easy to avoid those bugs with a little discipline a clean code (too many nested braces smells). I had a bug like that twice. Since then I brace single liners too. No bugs like that ever since.

Anyway, I usually love the language I'm currently programming in. I haven't tried many "languages", but that few (assembly, C, Matlab m thing, Labview) taught me very different and important things. Except for VB (and it's buggy interpreters)...

It doesn't require more than 2 lines (or 3) to display an array compared to a for loop.

A C++11 range-based for loop does it in 2 lines. You can make it a one-liner, actually.

It doesn't require more than 2 lines (or 3) to display an array compared to a for loop.

A C++11 range-based for loop does it in 2 lines. You can make it a one-liner, actually.

but array slicing is still simpler and . . .
. . . my next question. For loops. This one really bugged me. Isn't there something that could replace 'for' because if i were to translate for (int i = 0; i<5; i++) when i first saw it, i would say' for int i is equal to 0 (end of incomplete sentence/statement like for God so loved the world that . . .). i is less than 5. Add i to 1. Three different sentence and whatever goes under ({}) is wrong.
It doesn't feel and sound as right as do blah while or repeat blah until (in lua).