[sdiy] Programming Language Recommendation
Pete Hartman
pete.hartman at gmail.com
Fri Dec 4 21:35:36 CET 2020
I read Thinking In Java and part of Thinking in C++ back in the day, and
I'd agree they're very well considered. I would imagine Thinking in C
would be just as good.
I had replied off-list, but I also am a fan of this book:
http://ptgmedia.pearsoncmg.com/images/9780131774292/samplepages/0131774298.pdf
which talks about some of the less than obvious things you might need to be
concerned with in C.
Thanks
Pete
On Fri, Dec 4, 2020 at 12:49 PM <sleepy_dog at gmx.de> wrote:
>
> It's true it's old,
>
> I was just remembering this one, not as old:
> https://archive.org/details/ThinkingInC
>
> The Bruce Eckel "thinking in..." books had a good reputation in the 2000's.
> I haven't looked into this particular one.
>
> Also, the Dr. Dobb's Journal archived articles might be of some use.
> Andre Koenig also frequently wrote there.
> This now also is a bit old, but a lot of valuable programming articles
> there that may not all be dependent on "outdated" ways of doing things
> (let's say, some things today don't have to be as cumbersome and round 3
> corners to get the same result)
>
> https://www.drdobbs.com/
>
>
>
> Am 04.12.2020 um 17:22 schrieb Tony Sidaway:
>
> When I started learning C in the late 1980s Koenig's monograph "C traps
> and pitfalls" was very useful. I'm not really sure it would be so much use
> now as the language has changed somewhat under the influence of
> standardisation and convergence with popular features from other languages.
>
> C++ is a pretty good choice for low powered processors, and frankly I
> don't see any great advantage to C in such tightly constrained environments
> when we can see that Arduino sketches, written in C++, scale quite well
> right down to all but the smallest 8-bit AVR chips. If people are squeezing
> a bootloader, a C++ runtime and a useful Arduino sketch into 8kb of flash
> (just 4192 AVR instruction words) in the ATtiny85 used in Digispark boards,
> I don't think C++ can be that much of a liability.
>
> On Fri, 4 Dec 2020, 14:22 Steve, <sleepy_dog at gmx.de> wrote:
>
>> If you want to go the C route, you might find this useful. Although this
>> is for an outdated language version, the basic pitfalls still apply.
>>
>> http://literateprogramming.com/ctraps.pdf
>>
>> Some of that of course also applies in C++ as they are closely related.
>>
>> If you actually do already know C++ well, there's really nothing to be
>> said against using a sane subset of it on bare metal "MCU" targets.
>> You need to know what (not) to use and do, of course. (I *could*
>> elaborate)
>> Programming "OO" in the way it was taught in Java intro prog class at
>> uni, probably not.
>>
>>
>> I hardly ever bother doing anything in pure C these days, unless it's for
>> a really small target.
>> For reference, on a stm32 with 8 KB RAM and 64 KB flash, I might still
>> use C++ and can get a decent amount of functionality in there.
>> I don't remember a project, but 4K / 32K, I wouldn't be afraid either.
>> (but may use still less of C++)
>>
>> I make more or less extensive use of features that need at least C++11,
>> preferably C++14, if not 17, and which current C does not offer.
>> The number of contexts where "constexpr" can be used increased from
>> verison to version of what today some call "modern C++",
>> and this particular feature alone has tremendous impact on my "embedded"
>> projects - it is the savior from the much hated preprocessor macro
>> insanity. (I still use that, but in much fewer, special contexts)
>> Compile-time computation and real constants, that's what almost tips me
>> over to using the word "beautiful" w.r.t. the C++ language. In a limited
>> context, mind you :D
>>
>>
>>
>> - Steve
>>
>>
>> *Von:* "Shawn Rakestraw" <shawn at epicpoolsga.com>
>> Thanks Jay, I actually installed a VirtualBox with Ubuntu tonight and
>> started learning C. It is a lot like C++. Hopefully I can pick up on the
>> basics of it pretty quick. At the moment I have been a little confused
>> about the * and ** next to variable names. Also the & variable names. I
>> found some resources about it and realize they indicate pointers or
>> something. I'm just not following the reason to have a pointer instead of
>> the variable. I'm sure it will become clear as I continue to learn.
>>
>> On Thu, Dec 3, 2020, 3:11 PM Jay Schwichtenberg <jschwich53 at comcast.net>
>> wrote:
>>
>>> I was an embedded/bare metal HW/SW engineer and will say working with
>>> embedded ARM uCs C.
>>>
>>> C++ usually complicates things and is overkill for run of the mill
>>> embedded stuff. Don't know if it is still true but at one time the C++
>>> libraries had a lot of bloat and took up a lot of storage. I've also found
>>> C++ harder to debug when people start overloading and abstracting things.
>>>
>>> If you do need to run object based code you can in C. Take all the data
>>> for an object and put it into a structure and then pass a pointer to the
>>> structure around through the code. This is more or less the equivalent of a
>>> 'this structure' that objects have in C++. The data is isolated to a single
>>> object and just use a new structure with different data for another object.
>>> Also follow C++ and make you own constructors and destructors to setup and
>>> shutdown things.
>>>
>>> Jay S.
>>> On 12/2/2020 6:45 PM, Shawn Rakestraw wrote:
>>>
>>> Please don't go into extreme detail (unless you really want to). I ask
>>> too many simple questions and I feel bad that everyone spends great amounts
>>> of time with it.
>>>
>>> I am thinking about programming ARM chips like the STM32 for something
>>> like Braids. I know that I will not be making my own Braids module anytime
>>> soon, but I would like to start thinking about the language I need to
>>> learn. I know the most about C++. I also realize that my question may be
>>> better asked as what libraries should I load / study up on.
>>>
>>> Thanks guys/gals
>>>
>>>
>>> _______________________________________________
>>> Synth-diy mailing listSynth-diy at synth-diy.orghttp://synth-diy.org/mailman/listinfo/synth-diy
>>> Selling or trading? Use marketplace at synth-diy.org
>>>
>>> _______________________________________________
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org
>>> http://synth-diy.org/mailman/listinfo/synth-diy
>>> Selling or trading? Use marketplace at synth-diy.org
>>
>> _______________________________________________ Synth-diy mailing list
>> Synth-diy at synth-diy.org http://synth-diy.org/mailman/listinfo/synth-diy
>> Selling or trading? Use marketplace at synth-diy.org
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
>> http://synth-diy.org/mailman/listinfo/synth-diy
>> Selling or trading? Use marketplace at synth-diy.org
>>
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20201204/782f09eb/attachment.htm>
More information about the Synth-diy
mailing list