Using Python for conceptual learning or jump straight into C?

C++ is terrible. The "only use a subset" is the only right way to use it, IMO.
Well, a lot of things about C++ are less then ideal. If I have the choice, I always prefer C over C++. For desktop GUIs, I really like Qt, which forces me to use C++, but I also like the fact Qt allows -fno-rtti -fno-exceptions :)

Recently, a lot of people realize exceptions weren't a great idea after all (and I think they are a particularly bad idea in C++), things like railway-oriented programming and other functional styles are trending. But criticism of exceptions is much older: http://www.lighterra.com/papers/exceptionsharmful/
 
C is good because you will learn how computer works but may give you with too much of hacking mentality (instead of software engeneering), C++ is brain fuck and might be delusional, and Python is likely to give you a lot of vicious.

IMO, the best language to learn programming is Ada[1] because it will force you to do and think things right (software engineering-wise), otherwise you will not be able to write anything that run. OCaml is also a good one. ;)

[1] but better use Debian for that because that is the OS with the best out-of-the-box Ada support.
 
If you're just learning how to code, definitely start with Python. Python's advantage is its minimal syntactical overhead and automatic formatting allow the student to focus on programming concepts as opposed to syntax. In other words, Python gets out of your way.

Once you get that down, then by all means move on to C.

This won't be a short or quick process, and besides learning the language you're also gonna have to learn the FreeBSD development methods and culture, which may be even more challenging than the language per se. You'll also have to learn about the system(s) you're hoping to develop for.
All the best!
 
Here are few steps for anyone who is seriously interested in so called computer related sciences.
Study and learn:

Calculus One (at least)
Basic Electronics Theory
Basic Electronics Circuits
Basic Digital Electronics
Integrated Circuits
Digital Controllers
CPU/ALU Instructions



Then you can learn low level assembled computer code to understand how digital circuits and their logic work. After you master and understand the basics, you can decide which high level computer language you want to learn, such as C, that will teach you how to program and control computer system to do some useful things. When you get handy with all the above, you should enter College or University program that may help you become Professional Software Engineer who can tackle any software related project(s), in any computer software language.
 
Thanks for the suggestion. I figured USB would be the least difficult interface to work with. I'll probably start there.

Yikes! Please look at USB standards before you make that leap; it's very, very demanding. USB specs are notorious for adding standards before standards. Just look at usb 3.2 v 4.0. It's a standard where manufacturers can pick & choose what to implement.

As to coding language, if you're writing device level drivers then you have no choice; it's C. Once you know C you can expand to C++ and its massive verbosity. C++ will also give you more acces to the application layer of a gui as it seems the most common language for widget toolkits.

C is not as scary as some would say, with the only proviso being its handling of memory access via pointers and this is where SirDice's opinion of knowing assembly really does help, but short of that remember in C everything is just a memory location; a function, a variable, a pointer, a structure and so on.

<scandalous troll> python's a toy language good for teaching OO concepts </scandalous troll> :eek:
 
In order to learn, you need to practice, to experiment, in order to make sense out of new notions, to check the correctness of your understanding and to effectively memorize.

My advice is to choose a concrete project first and to learn the language used to develop it. The more non-IT knowledge you have about the chosen project's domain, the easier your learning will be because the IT notions you'll learn will immediately make sense to you in a concrete and familiar way.

It doesn't matter which language you start with, once you know how to learn one, you can learn any other as well.

Also keep one thing in mind: learning to code is not your main activity, you don't have much time to spend on it and this time comes at the end of a work day. The more meaningful your learning, the more sustainable and successful.
 
And thank you Beastie7 for continuing to participate in this thread so actively. It's been a joy to see your reactions to such big and ambitious suggestions and differing viewpoints.

No problem. :) Im glad I was able to incite a constructive discussion amongst the members here in the forums, and am thankful for the feedback. It's really encouraging
 
I would break up learning C/C++ into four stages.

1. Standard C with structs and pointers and classic FILE* I/O.
2. C++ with object oriented structs (class).
3. STL for strings, containers, iterators and streams.
4. Templates.

Using a well defined template library is easy enough but writing your own requires much more thought.

Many people think FreeBSD is C only. Not so. I was looking at the source for devd the other day. It is C++.

I think C is easier to learn for someone who has already learned on form of assembly.
 
So I've been contemplating the idea of learning to code to help out with the project and address some aspects of it I feel are lacking. Presumably one would learn C if they'd like to get into contributing to FreeBSD. However, I'm torn as to how I should approach this. I understand C could be a difficult language as a first one, but my interest in contributing to FreeBSD sort of overshadows that notion. On the other side, I'd hate to get frustrated and give up on my attempts to learn due to my lack of prior programming experience. Should I "learn programming" first with a something like Python, or is a C good candidate as a first language as well? I imagine I could save myself the time by just using one language, but I also would like to learn programming concepts, correctly, with the least amount of friction.

Any thoughts?

Thanks.
Actual professional programmer here.
I'd recommend python.
Why?
To actually learn programming, you need to program (and encounter problems) A LOT.
Python gives you the benefit of not having to know every single detail from the start.
Even 'bad' python can get you actual useful results. The keyword here is useful. You need lots of little projects. Python lets you accomplish those projects.
With C, you need to force yourself in the beginning to even come up with projects that seem realistic and it's usually a bit more complicated. So the danger of being overwhelmed and giving up is way bigger than with python.

Good luck!
 
C is not difficult to learn and is the language you ultimately want to use. Learning C will also teach you a lot about how computers work. Just get a copy of this classic and beautiful book and work through the problems:
'The C Programming Language' by Kernighan & Ritchie
Good luck!
 
Python is not a proper programming language but a script on the same junk level as Javascript. Both cannot ensure that your data stays valid, so you end up with NAN's in arrays and your data result is bs.

Only C++ and C99 guarantee that you data stays valid at all times and you get protected by compiler errors and program crashes.
 
Python is not a proper programming language but a script on the same junk level as Javascript. Both cannot ensure that your data stays valid, so you end up with NAN's in arrays and your data result is bs.

Only C++ and C99 guarantee that you data stays valid at all times and you get protected by compiler errors and program crashes.

You jest, but C really makes one think twice whether a fancy feature is actually worth implementing.
 
With C, you need to force yourself in the beginning to even come up with projects that seem realistic and it's usually a bit more complicated.

In any language, C included, you can begin with writing a very simple, yet useful program. An example of such simple program is a filter (read stdin, parse, transform, write stdout).

You can do lots of useful things with filters, and Unix commands illustrate this - just have a look at some shell scripts and count the number of pipe characters used to combine cat, grep, sed, cut...
And a simple filter fits in a single source file, whatever the language.

The difficult part in software development is to correctly analyze the problem to solve, not to code.
 
The difficult part in software development is to correctly analyze the problem to solve, not to code.
You got it. The discussion which languages to use for teaching is ancient. A lot of stuff that was said in this thread is nonsense, but I don't feel like arguing with it. Because it is irrelevant.

The single biggest task in software development (or system building) is to learn how to interact with other people. How to find out what they want, what pressures are driving them, how they make decisions, how to share information. Come to agreements on what the problem is that needs to be solved, what the requirements and the resource/schedule situation is, what the risk/reward tradeoffs are. All of this has nothing to do with C versus Python. This is why I say that the two most important books about software engineering are "Mythical Man-Month" and "Peopleware".

The second biggest task in software development is to find out what needs to be done, and why. Write down the requirements, write down the schedules, write down the "speeds and feeds" (what other systems the intended product needs to interact with). Be clear about what the economic benefit is, and what factors that depends on. Without clear use cases and a clear requirements documentation, there is no point even opening an editor to work on source code.

Once we know what we are doing and why, the rest follows somewhat automatically. We need an overall design, we need a breakdown into components, we need detailed designs for the components, we need to think through testing and quality assurance, we need to write test cases. When I say "write", I don't mean in a programming language, I mean in documents. We need everyone involved to review these documents, and come to an agreement.

The remaining 20% of the task are coding. There are zillions of very smart hackers on the planet who can code. Sadly, there are very few software engineers who can design and socialize systems that actually accomplish what needs to be done, efficiently and trouble-free. Learning how to code (whether it is C, Python, or Snobol) is the least of the worries.
 
The single biggest task in software development (or system building) is to learn how to interact with other people. How to find out what they want, what pressures are driving them, how they make decisions, how to share information. Come to agreements on what the problem is that needs to be solved, what the requirements and the resource/schedule situation is, what the risk/reward tradeoffs are. All of this has nothing to do with C versus Python. This is why I say that the two most important books about software engineering are "Mythical Man-Month" and "Peopleware".

Well, sorry, I disagree. This is not about programming, this is about making money.

Programming is a craft. It is the craft to make a computer do some things in a way that it does not break apart and that we can rely on it during the manned Jupiter mission. Just like the blacksmith's metal-work is the craft to make horse-shoes in a way that they do not break apart.

"Speeds and feeds and schedules" are something different, and independent from the former. This is called project management, and a project manager is not expected to have any coding skills. He is not even expected to know what a computer is. He is only expected to ascertain the money-making.

When we talk about programming, we talk about empowerment. Today we are surrounded by gadgets, and to most people these gadgets are "magical", meaning, they have no idea how these work. But these gadgets tend to make decisions, and so people are subdued to foreign decisions where they do not understand how these come to pass. That way, people are mentally trained to become slaves.

Learning to program is the way out of the trap. It is the way to understand how these "magical" things are achieved, and thru understanding to regain empowerment. This is not about getting a job and blablabla, this is about being even able to develop self-confidence (in contrast to the shallow illusion of a big ego).

When we stop to distinguish that properly, and when we start to say that the actuall skill of the programmer is not the craft but the businesscrap, then we are right here where we are, where we can no longer fly to the moon (or build an airport, or handle a flu): in guaranteed zeroskill land.
 
Of course, a developer needs technical expertise to do his/her job.

But human factors are always the root cause of project failures - or failure to deliver on time, on budget. The most common are:

- Inflated ego / manipulation
- Political maneuvers / hatred / rivalry
- Poor communication skills

In a large company, it usually start with an airy-fairy vision of some manager with no field experience (and not willing to have any), then architects make technical choices on the basis of the vendor's fame (when the project will appear bound to fail, the architect will say: "I have chosen the leader, it's not my fault, it's the developers'.").

And at the bottom of the hierarchy, developers are supposed to deliver working software...

You get it: instead of learning to code, they'd better pass a PhD in Advanced Wizardry!

And of course, it doesn't stop here. Developers are usually reluctant to meet end users (when they're allowed to do so, which is seldom the case) and communicate with other departments by email, CCing half of the company. They also tend to be somewhat haughty with production engineers, which doesn't really help...

And when some piece of software is eventually delivered, late and well over budget, end users complain that it not only doesn't help, but complicates their job, causing frictions with customers.

When they are lucky, they just don't use it and the application is discretely uninstalled 6 months or a year later.
 
Jeez louise, people, please stop confusing poor beastie7 talking about projects and personal inter-communications. He hasn't even decided on a language yet. ?‍♂️

For crying out loud, all he wants is an insight into what's a better language to focus on... o_O

But seriously:

It's really not a decision you have a choice in. If you want to write device drivers or any code remotely to do with the kernel then it's C. Period.

In a proper structured course or book on C, it will begin by going through the keywords, assignment, functions, tests, then arrays (stack based), "strings", I/O, data types etc. Only after a thorough understanding of program flow and C basics should it begin hitting you with heap based stuff (like free/malloc) and, what most people dread most about C, * pointers *.

Any book that starts with a discussion on double indirection and dynamic structure creation is most assuredly too advanced.

I will not beat around the bush here, you have a VAST amount of learning to do. If you were conversant with another language and had written code in it, I would suggest converting that code into C as a way of learning (if possible).
As you don't then I would suggest you get yourself into an introductory course at a local university or whatever aptly named tertiary institution exists in your area.

Failing that, take a look at a first year university course on C and see what text books they use and buy them. Most of these have exercises and tests at the end of each chapter to test your knowledge.

Don't take this the wrong way, but because you're a complete n00b ;) you should aim to do some introductory course to find out if both programming and programming in C is for you.

I tutored C back in the day and saw quite a few smart kids give up and change university course streams because they couldn't take to programming.
 
  • Like
Reactions: bjs
what most people dread most about C, * pointers *.

Pointers are not so dreadful. I teach Java (among other topics) and found it quite helpful to my students to draw the memory layout of objects, and to explain how a program is compiled. With a couple of drawings on a whiteboard, a whole lot of notions become obvious to explain and to understand.

I also found out that people with no prior development experience have less trouble learning an object-oriented language than former mainframe developers.

I live in Luxembourg, a heavily multilingual country where children learn 3 languages at school. Some of them coming from another country speak a fourth language at home and they'll learn one more in high school. If you don't tell them it's difficult, they will just learn those 3/4/5 languages quite easily and naturally.
 
One of the fundamental reasons for choosing Scheme is the lack of syntax.

The number and placement of parentheses in those "no-syntax" constructs are actually quite difficult to remember.

But try coding that in Java and explain, why do I need to do
Code:
import java.io.*;
import java.lang.*;

You need some kind of module system and therefore imports in every language. Unless you arguing for global visibility for everything, of course.
 
The authors have spent fifteen years developing HtDP
One of the fundamental reasons for choosing Scheme is the lack of syntax.
When in Racket a student could type
Are you now recommending HtDP, Scheme, or Racket?

So I've been contemplating the idea of learning to code to help out with the project and address some aspects of it I feel are lacking.
Keep in mind the goal of OP: helping out with the FreeBSD project. Learning some obscure language no one uses, will not help achieve that goal.

To OP: You can start with either Python or C. Learning Python is easyer and I believe you will be able to write working programs faster. If you want to write some small tools/scripts, Python is the way to go. If you want to tinker with existing code, it depends on the code you want to tinker with. Start with Python, write small scripts and when they turn out to be too slow, you can learn C and rewrite them.
 
I don't think the theoretical approach is very helpful.

Once, when I came upon a bunch of obvious bugs, I dared to ask why that particular piece of software hadn't been theoretically verified (it was the time when developers weren't yet in the ivory tower). The reaction was disgust: how could one be so aloof in theoretical computing?
In fact the opposite is true: I'm 100% from practice. And in practice, you should take 20% of the time to make the damned thing work, and the other 80% to find all the cases where it will not work properly. And I don't care how this is done, only that it is done.

In the end, there will be some people who just want to code a cool game. And there will be other people who will recognize that these 80% have to be done. And no theoretical education will change that. I think, what would change it, is, when the people's very lifes would depend on that software working (that's the idea behind the Jupiter mission).
 
Back
Top