C programming with FreeBSD

Relating to sam, the Acme clone (Anvil) looks really interesting.
I also did not mention Acme that understands sam commands.

He can install plan9port and get both, sam and acme, and also a lot of tools.

I personally use vi and emacs, vi always more, but for example for dealing with multi-line substitutions, emacs.
sam can also do it, with ed / vi is too complicated.

I am not happy, but that are the editors used since time immemorial, I am sure they will not spoil my files, and I am used to them.

I use ed inside of scrips when necessary. Not really for writing text.
 
Until recently the USA and the EU were heading to be much stricter with regards to accountability for commercial software. The US under Trump seems to be backpedalling to become regulation lite so maybe CISA won't carry through with what is was working on. In the EU the CRA has been enacted.

“I think you ought to know I’m feeling very depressed.”
“And then of course I’ve got this terrible pain in all the diodes down my left side..”
 
I had a copy of "The C Programming Language" by K&R. The title is a joke. It should read "The C Low Level Programming Language".
 
I had a copy of "The C Programming Language" by K&R. The title is a joke. It should read "The C Low Level Programming Language".
That's the book my college class used back in the 80s for teaching C. Regarding the title, I think it is totally appropriate, as C (is) a low level language. There is a fairly obvious and straight forward translation from C code to assembler assembler.

If you want high level abstractions then don't look to C. In C we believe "What you see is what you get." is a wussy concept. We prefer to think in "You asked for it. You got it." terms.
 
I had a copy of "The C Programming Language" by K&R. The title is a joke. It should read "The C Low Level Programming Language".
kent_dorfman766 already answered almost completely to that: C is low level; well, the lowest level a HOL can be.
Today everbody starts 'high', and maybe add assembler to their toolbox later. But fifty years ago it was often vice versa. So, you need to see it from the opposite point of view to better understand. If you come from assembler, only, and think of getting most basic data types, and control structures, so you don't have to create them everytime you need them over and over again, you will get to something pretty much like C.

By its nature come the pros and cons issues permanentely discussed today:
The more freedom a language provides, the more you can do with it, but the more effort is needed to create missing things, and the more you are on your own, and being responsible to create programs running safely.
(btw. I found an interesting article on HN yesterday: There is no memory safety without thread safety)

But I like to add three things to the KR:

1. It almost completely covered the C language as it comes by default, and at ANSI standard in the time the book(s) were published.

2. The "KR" isn't meant to make the reader a systems developer, but to give a (very solid) introduction into the language with the aim to be used as an everyday tool for the common Unix-user: If you're missing a tool for a job to be done, write it yourself.
Today everybody looks for the proper tool to get a job done. Thirty...fifty years ago there weren't - by far - that many tools available. The idea was: Any user also has to have a bit of at least basic programming skills. Programming as kind of "configuring" your system. That's why the KR deals a lot with what users could use for their daily work: handling text, and files, etc.

3. The "KR" provides a solid foundation you can build on not only into C, but also into programming.
If you already are an at least a bit experienced programmer, and look at the exercises, you may think: "Ludicrous! This is kindergarten. To be done in most noobish programming classes!" At least I thought so. 😁
Then I actually did the exercises (Not googling the results everytime you need to think of something. Really do it yourself! Completely.) Always only with what is known at the state according to the book's section. ("I want struct, and case!!" - No. Do it without it, if it wasn't part of the book, yet.)
Some of the excersise are really tough nuts to crack, as simply as they may look at the first glance.
You'll learn a lot - about C and programming.
It's a real solid class.

And as already said, it doesn't hurt to know a bit of C, even if you never going to program in it later, especially when you're dealing with unix[like] systems in my eyes a bit C basics are a must.

The KR provides a "solid license" to C, it's not a hacker's class.
And it's like driving cars:
The driving license only says your skill is sufficient enough to participate the public traffic on the road, it doesn't mean you are a good driver.
You have to drive a lot - while using your brains - to actually become one. 🥸
 
Today everbody starts 'high', and maybe add assembler to their toolbox later. But fifty years ago it was often vice versa.
Raises hand. I was dragged, kicking and screaming from assembly to using C in 1985.
a.jpg
 
agree to disagree. This discussion depends on learning in programming. I am one that started high, but not deep in any programming language, maybe that's why my opinion is what it is. Point well taken.
 
Why C pretty much underpins the entire computing platform is because it is both "high" and "low" in terms of where it sits. Other languages make a choice but C was designed very pragmatically to solve a problem between performance, portability and abstractions.

C was also unofficially called a "portable assembler". Its kind of the closest you can get to assembly before you lose portability. Some of the really old C (pre-standard) even kind of uses it as such.

(yes, so in some ways you could say that C has flaws of both high and low level languages. But its not like anything will be replacing it soon, so good luck!).
 
I sometimes think "C is to assembler as Perl is to C", as a 'rule of thumb'. Don't know how well that really stacks up though..! 😁
It would be an amusing classroom test to see how many got the final 'C' correctly. :)
 
"This is the way..."
Dude, you're referring to "modern" 80386 architecture.
I was talking pre-8088, which is pre-8086, which is pre-80286, so pre-pre-pre-pre-386 - dinosaurs!😁
(Thanks for the link to the book, pal! 👍)

This discussion depends on learning in programming.
I'm not sure which discussion you mean exactly.
This thread is about the first steps in C on FreeBSD, which in my eyes is pretty much
"Write a 'hello world' program, and make it run." (Which is also covered by the KR.)

I don't claim my point of view is right, especially not the only one, as kpedersen pointed out another, also right one.
But above all I don't want another "C sucks and need to die as soon as possible"-discussion again.
All I wanted was to give my two cents on how to get started on C programming (on FreeBSD), which I find is a good idea anyway, no matter if one's going to do programming in it later, or not.
And the KR does a really good job on that.
Since app. ~90%(?) of the system's source is written in C it doesn't matter if you like it, think it's a waste of time, or whatever one sees in C. As long as large, major parts are not rewritten in another language - btw. good luck with the discussion until a decision for the right language instead was made, alone 😁 - C is an unavoidable reality.

As I said above, I find it a good thing if any computer user had at least a little idea of what programming is. Especially on unix[like] systems IMO it's mandatory, 'cause it brings some understanding how the system works, and why it's configured how, etc.
So it makes pretty much sense (at least to me) if some one at least get some fundamental basics of the main programming language a system was written in.
 
Since app. ~90%(?) of the system's source is written in C it doesn't matter if you like it, think it's a waste of time, or whatever one sees in C. As long as large, major parts are not rewritten in another language - btw. good luck with the discussion until a decision for the right language instead was made, alone 😁 - C is an unavoidable reality.
There is nothing wrong with programming in other programming languages? I code in many other programming languages as well and I have for years. However if you read the operating system man pages you will see that *BSD/Linux/Unix operating system calls are written mostly to be called from the "C" language. You will understand *BSD/Linux/Unix operating systems much better if you know how to code using the "C" programming language. And sure, maybe someone, some day, will rewrite everything into a different programming language, that's fine too.
 
All overly complicated. All you need is a sharp pencil. And those punched cards where individual holes can be punched out by pushing with the point of the pencil. And then you memorize the EBCDIC punched card code (it's easy, single hole for digits, two holes for letters).

Oh wait, you were asking for the BEST possible editor? I just told you about the worst possible editor.
It is.
vi is good but it is not an WYSIWYG editor. the best editor has to be
ed. No hidden escape chars.
 
Last edited:
Back
Top