I'm probably going to be required to use an ALGOL or two (C, Java, or Python) in the second half of next year for some course work. If given the opportunity I'd prefer to understand them rather than attempting to use search and induction. Simplifying is a good aid to this. I know C has the 89 ANSI standard, but do these other two languages have anything close to an inalienable core? Perhaps some older version, or well defined subset?
C is pretty small, you don't need to limit yourself to an outdated version. I don't think it changed that much.
Java 7 was the last straightforward version, in Java 8 it got lambdas and all kind of magic like default methods in interfaces.
I can't give advice on Python other than to make sure you avoid Python 2 and focus on Python 3. But it is a mess and every new version introduces some new gimmick that makes things worse. Of course it doesn't even have a standardized version, whatever CPython implements is Python.
I agree with >>2 on C being compact enough that limiting is counterproductive. The C standard is VERY conservative about adding features. It's nothing like the feature creep C++ exhibits. I haven't looked into the latest additions but at least C99 adds a handful (not because only a few parts are useful but because there aren't to many additions to begin with) of features which are seriously useful. I have quite a bit of trust into the standards committee to keep it's reputation of not adding a ton of fluff.
>>2,3
It looks like C99 mostly concerned numerics, with some convenience changes like looser initializer syntax, designated initializers, compound literals, and flexible array members, also some things you might want to avoid using like variable length arrays and variadic macros. I see what you were saying about the language not changing much as this is considered a major release. I will keep your suggestion in mind going forward, I've acquired this version of the standard as well although truthfully with such small changes it seems almost irrelevant which I choose.
Java 7 was the last straightforward version
How backwards compatible is the Java Platform, would I be trivially able to run an application written in Java 7 on a recent release, or would the expectation be that I link to a recent release of the Java platform without using any of the newer features of the core language? (My current understanding is that the platform is too complex to understand given the time constraints anyway so it doesn't matter too much either way.)
I can't give advice on Python
Perhaps Python is not suited towards understanding.
Unfortunately, it seems likely I'll need to engage all three eventually, but I have some ability to phase them in. Assuming I'm able to reach an acceptable level of proficiency with some more general skills before the period in question I'll likely focus in the order of significance to my course load C initially, Java the year after that, and avoid engaging with Python as much as possible. I'm not particularly interested in learning different languages, especially two large languages, so overall this situation does not appeal to me.
Why would you avoid variadic macros? It's downright mindblowing what these are capable of and that's even before you start combining them with anonymous arrays. Mindblowing i tell you. Variable lengths arrays though... two words: Burn, fire.
>>5
I can't recall if this was some wisdom given to me by my forefathers or just an assumption based on the nature of the preprocessor, but I just had it in my head that it was something to be avoided.
What do you mean by "inalienable core"?
For me, the programming language is always replaceable. I'm more concerned about other matters of software development:
• how precisely can I define the user requirements
• is my core algorithm correct, is it possible to formally prove the core algorithm
• how readable is my code: can I comprehend my own code after six months of not seeing it
>>4,5
Why are C's variable length arrays bad?
At the very least because it's hard (impossible) to predict what the compiler will make from it. Having a VLA means having some data of unknown (at compile time) size on the stack. Unknown at compile time means there might be (and depending on the amount of VLAs and structure of surrounding code will be quite a bit) of runtime calculations needed to figure out where the fuck things are located in memory. You are almost always better off to just have an array of "sufficient" size and throw an error in case of bounds being violated. For longtime allocations there is obviously malloc and friends anyways.
I see. Well, i guess it should be (like most ancient wisdom) taken with a grain of salt. At least personally i wouldn't know what bad things could come from using them beyond the various pitfalls there is with macro usage in general.
This shows very well with the hatred for goto. At least in C goto is not generally bad. There of course is bad usage of goto but if used right it's sometimes the ideal solution. For example it's pretty obvious in relation to layered cleanup steps in functions where you'd otherwise be replicating portions of the same code over and over again. Goto is easily less error prone, more readable and most efficient there.
>>7
These are admirable. By inalienable core I meant a minimal but complete subset of the language violations of which would result in it being a different language.
>>9
My understanding was that there was a lot of undefined behavior or implementation specific violations of the standard making them difficult to use portably.
In regards to undefined behavior: That's entirely possible too. I've never really looked into the "real world" implications of using them as in about 20 years of writing C i've never felt the need for a variable sized array. There obviously might be cases i didn't run into but those are possibly quite niche.
In general there is a ton of ways to deal with situations where you might use a VLA. Mostly it's the use a reasonable fixed size array and forget about it (after including appropriate checks of course - those should have been there already anyways to avoid insane VLA sizes) but maybe your data is better organized in a linked list and your list allocator is tuned for your use case? You use your own "smart array" again tuned for your use case, your data will be reused so malloc is worth it and so on, and so on...
>>12
Truthfully all but the first seem much more complicated (not that this is the only thing to optimize for) than if VLAs worked. It doesn't matter too much however.
>>13
I figure you are talking of linked lists? That mostly depends on how they are used. Linked lists in general are pretty simple. If you are going for sequential access and manage to keep your elements in cache i doubt it'll be much of a difference. If you are talking about source complexity that's largely down to how they are implemented.
If done cleanly it will be mostly opaque (ie declare a pointer to your desired type initialized to NULL and pass a pointer to that to your allocator which spits out pointers to elements of said type, those element pointers can in turn passed to the destructor function, iterated using next/prev functions/macros or used like any other pointer of that type). There is nothing visible of the whole magic and if one whats to get fancy its all in a header ready to be force inlined and (partly) optimized away. A generic implementation is likely something about ~50 loc (including header) depending on how much extended functionality is required.
I can see how VLAs might appeal to high level programmers. From their perspective it's probably hard to imagine how something like this can be avoided or even be superfluous. Trust me, it's practically a non-issue. It's simply unneeded functionality with lots of downsides. Nothing more, nothing less.
Well, admittedly in this situation linked lists or ("smart") arrays mostly come down to how allocation is handled. If the usage is really simple that's where the most time will be spent. A competitive implementation would probably need some kind of pool to give out elements from to avoid any kind of real memory allocation and non-inlinable calls. That's not exactly going to fit into the 50 loc.
>>14,15
I was referring to all those mentioned but fixed arrays, even malloc seems more complex, especially because it sounds like you're talking about a lot of bispoke stuff (for locality of reference?). I'll take your word for it though. I'm weak and feel like shit so putting up a fight would probably be a good way to end up in the hospital.
>>16
Ah, probably avoiding unecessary allocations is more important than locality.
>>16
Don't worry. In probably 90%+ cases the correct answer is in fact fixed size arrays. It's just those maybe 10% where one of the other solutions becomes an option.
"Smart" arrays can be very efficient though if the default case is really a fixed size array of "sufficient" size and the whole logic (including whatever kind of allocation) just happens in the unlikely case "sufficient" wont actually cut it (like you start with X preallocated elements on the stack and if that runs out it gets extended to X*2 - how that's done exactly is of course a question in itself with pro/cons for each option). Basically a safety net that in general isn't used anyways.
>>17
Absolutely. Even if malloc often times won't result in an allocation in the stricter sense (ie just handing out a chunk of some preallocated memory) the function call alone is Bad with a major B. If it actually results in a system call all hope is lost.
"Allocation" can mean a lot of things though. When it really means dereference a pointer scan for an unset bit (often times a single instruction) multiplicate (or ideally shift because the chunksize is a power of 2) the result and add that to a pointer it's not to bad. Obviously still way more than not doing anything.
testing reply from emacs-nox
I find it fairly amusing that C# has a standard. Leave it to Oracle to make Microsoft look good! Anyway, it's looking like I may be able to avoid Java entirely with nearly all my work being in C, and supplementary work in Python. I've decided to not dedicate time to learning Python and focus on my already bloated curriculum of POSIX, C, Computer Architecture, and Data Structures/Algorithms starting in May. Wish me luck!