BSD Foundation, Using plain C?

Hello,

Something very obscur to me. I was just wondering.

Why to use Perl or Python when you can use plain C?
Dennis would use C.

I wonder why today *BSDs aren't more focused on making an operating system, which is closer to its original common programming ideas.

I can give you example if you want, but you may think from your own daily use (see some *BSD packages).

The C Foundation and BSD-Programming origin are my opinion vital to *BSD.
BSD looks too much a Linux, but it is less closer than original first PDPs machines.

see source code of PDP-7 for instance.
(I am talking to a programmer).
 
I think you should reverse the question: why not use Perl or Python when you can use plain C?

Not everyone will be fluent with C, and in some cases Perl / Python (/ Java?) can help to reach a certain solution much quicker. I can simply code my Perl script and then run it, I don't have to bother with compiling, optionally linking, etc. I script, I chmod +x and I'm done.

For me this simply boils down to using the right tool for the job at hand. Sometimes that's a shell script, sometimes it's a Perl script and sometimes it's a C or Java program. And sometimes it's simply personal preference.
 
I think you should reverse the question: why not use Perl or Python when you can use plain C?

Not everyone will be fluent with C, and in some cases Perl / Python (/ Java?) can help to reach a certain solution much quicker. I can simply code my Perl script and then run it, I don't have to bother with compiling, optionally linking, etc. I script, I chmod +x and I'm done.

For me this simply boils down to using the right tool for the job at hand. Sometimes that's a shell script, sometimes it's a Perl script and sometimes it's a C or Java program. And sometimes it's simply personal preference.

Programmers MUST be fluent in C. This is basics.

Turbo C must be on curriculum of programmers in Japan, so why not in Europe?
 
Why to use Perl or Python when you can use plain C?
Perhaps because the same thing that takes 1000 lines (hard to debug and error-prone) in C would take 100 lines in Perl or Python, and 10 lines if you find the correct library that already solves most of the problem? Perhaps because the productivity of programmers in high-level languages is 10x higher than in low-level languages?

Dennis would use C.
I never asked Dennis what languages he would use for which problem. Sadly, we can't ask him any longer, he's gone. But he did work on a system that also had languages like ksh (written by his friend Korn) and awk (written by his friends Aho, Weinberger and Kernighan) available, and I would bet that for many problems, he used scripts.

Suggestion: Take a small programming problem, such as "write accounts receivable and billing, with interface to a part number database, a customer database, and an accounting database". Write the first solution in straight C, including all the string manipulation that is required. Then write it in a high-level language that has string processing, database interfaces, print formatting built in (like the old dBase language, or in Cobol with Codasyl interfaces, or RPG-3), and you will find that the solution in those languages is much easier, maintainable, faster to write, and less bug-prone. Just getting the string processing to work correctly without any memory leak bugs in C requires enormous discipline and attention to detail.

I wonder why today *BSDs aren't more focused on ...
Because they can't focus on a single thing. If you want a system for educational purposes, you are better of with Minix. If you want a system with X, you are better of with Y, and so on. The *BSD, by their nature, have to be a compromise.

By the way, you do know that it is perfectly possible to use (object-oriented) C++ in the kernel of the various Unix-like operating systems? I've written plenty of C++ code that implements kernel functions such as file systems.

see source code of PDP-7 for instance.
The first prototype version of Unix for the PDP-7 was not written in C. It was written in assembly. I don't remember when C came in, but it was about the same time they moved to a PDP-11. And the history of C is full of other languages, with names like "B" and "BCPL".

Programmers MUST be fluent in C. This is basics.
Actually, that is very doubtful, and a matter of great debate. Good programmers must first and foremost understand good software design, and good engineering practices. It is not clear that low-level languages (such as C or assembly), with their attention to minutiae, foster that thinking for beginners. At some point, a good programmer also has to understand how real-world computers actually work, but C doesn't describe the load/store/register/ALU/... architecture of modern CPUs terribly well.

The other question one has to consider here: do you want to educate programmers, software engineers, or computer scientists? These terms are not at all synonymous, and require different (but overlapping) skills. I think most CS and CE degree programs today use Java or python as the first language.

Disclaimer: I was taught programming before C was in widespread use, and learned PL/1, Pascal, 370 assembly, and Fortran and Cobol as high-level languages. With a lot of Basic and microprocessor assembly thrown in for small computers.
 
Actually, a colleague (who has a master's degree in electrical engineering) tells me that you can now get a EE degree without ever learning how to solder. At first, that sounds shocking. But then, as you think about it: a typical EE these days hardly ever has to solder something. Even if he is doing discrete circuits, those are simulated and designed on a computer, and then sent out to a manufacturing house.

Similar, I think that one can be a perfectly good programmer and software engineer without having ever programmed in assembly. On the other hand, a very solid understanding of OOA&D = Object Oriented Analysis and Design is absolutely necessary in today's world, unless one wants to just write small device drivers and javascript web pages. As is a good understanding of how a computer actually works, where the data goes, how fast it travels; the "speeds and feeds" or "cost and value". I'm not sure I see a place for learning C in all this.
 
I haven't read the thread but the reason for C is speed and small size. Stuff an operating system needs. You will never find anything else in a competent operating system except assembly except in areas where it doesn't matter.

I find it amazing when I talk to programmers and talk about the flow of data from processor to memory to disk via data lines etched on circuit boards and bits in memory and they have no clue what I'm talking about.

I have not done any serious electronic design since 1992 except one-off projects for the theatre and film. I've always been a sloppy solderer and was always grateful to have a technician to do that for me except, sometimes, for prototypes. But, as the designer, one needs to understand the issues around circuit board fabrication and the soldering involved. It's a sad statement on today's education that an EE does not need to learn essential fundamentals.
 
As someone who writes low-level software, C and assembler are a requirement. Take FreeBSD for instance. 95% of the kernel is written in C. The last 5% is written in assembler. Those assembler parts are in the CPU specific branches which allows C to have access to different processor features and constructs which is not defined in the language. You can use C++ in the kernel, but it's not efficient. Linus had a few words to say about that awhile back.

The below link has a bad language alert.

http://harmful.cat-v.org/software/c++/linus

One other thing... Sac State is Java heavy. However, since I am almost done, so far I have only needed Java in two different classes: Algorithms and Analysis, and Object Oriented Graphics. They do teach other languages though. Python, C, Scheme, and Prolog to name a few. It depends on what you are trying to do. One of the required courses, Computer Architecture & Organization, teaches Verilog. I also took the advanced CA&O class where we get to design and simulate a CPU.

They teach more than just coding, they teach how to write software. Now when I look back on some of my older code, it looks to be a sloppy mess compared to how I am coding now.
 
Programmers MUST be fluent in C. This is basics.

It entirely depends on what you're working on, high level or low level and how efficient you want/need to be. Try building a web application in C and you will quickly recognize there are way more efficient ways to do that. You could do it but beyond a certain level of complexity it just wouldn't be a good choice. Being able to effectively manage complexity is also a sign of a good software engineer — and one that's increasingly underrated. What's important is understanding how things work and how to design good software. But you don't need to know everything. Just as I'm sure you don't intimately know about the CPU firmware in the machine you're using. Because you really don't have to. Same as getting into a car, turning the key and drive. You don't need to know about the engineering concepts behind it. On the other hand, if you're an automobile engineer, you absolutely do.
 
Try building a web application in C and you will quickly recognize there are way more efficient ways to do that.
Well...actually...my business is founded on just that. And we do very well though it's a niche in a way.

We create high performance web sites for the entertainment industry mostly. Everything we do is in C from page generation to serving it up. In a way it's a niche but it's where all web sites should be if companies could find enough people to do what we do in C. While many complain about the speed of serving up pages, we coast along with smaller servers doing 10x the work.

But our clients are those not looking for web sites that look the same or work the same as everyone else's. No Wordpress here.
 
In a way it's a niche but it's where all web sites should be if companies could find enough people to do what we do in C.

Sounds like a nifty little operation. It's great that you're able to pull this off. It's also the exception. I would argue that this may be true for you but not generally. What I mean by "efficient" in this context is development time rather than resource usage. A well crafted C application will always outperform any scripting language, no question about it. But the effort to code, maintain and secure it will probably outweigh its performance properties except in large deployments with heavy load.
 
Actually, a colleague (who has a master's degree in electrical engineering) tells me that you can now get a EE degree without ever learning how to solder.
I had to learn at our local university that it's apparently possible to get a CS bachelor nowadays without actually learning to program.
No joke. I learnt that when a fresh CS bachelor in our club desperately asked for help with a simple text extraction problem worth 4, 5 lines of Perl script.

By the way, I haven't touched C seriously for years until recently.
I felt myself like doing assembly language. Tedious and cumbersome. Bleech!
Perl probably made me even more retarded as I was anyway...
 
What I mean by "efficient" in this context is development time rather than resource usage.
I don't disagree with you but I do always say that, too often, programs, and web sites specifically, are slapped together using "other people's code" in order to crank things out the door with as little thought as possible and, kid programmers today never want to think about anything so it fits right in line with with them. (Editorial smirk)

I also like to say that, if it weren't for the slap it together mentality, we might not need the CPU power, exorbitant amount of memory and disk space we see on Mom's home computer today (though 640KB would not be enough). As an example, we have some cheap e-commerce sites that don't get a lot of traffic but it is decent at times. They've been with us for years and all share the same old server with a 256GB hard disk and 512MB of ram but the pages blink on when you access them. No slow down here and we don't do anything special with them but use the same standard HTTP/HTML/JavaScript/etc, database and all put together with C and current with today's standards.

When I say all that, someone eventually comes along and says something about "reinventing the wheel", "don't repeat yourself", and "doing everything from scratch", and even, "You can't do that without X library and Y framework!!!", but smart programmers know about code re-use. (More editorial smirk)
 
Snurg I don't know which university that is but I always question that when you look at such "schools" that claim to be universities and colleges. I went to school for EE, not programming, but people forget that a Computer Science degree is in the field of Computer Science, not programming.
 
Perhaps because the same thing that takes 1000 lines (hard to debug and error-prone) in C would take 100 lines in Perl or Python, and 10 lines if you find the correct library that already solves most of the problem? Perhaps because the productivity of programmers in high-level languages is 10x higher than in low-level languages?

Unefficient coding, it is sure, with less lines (apparently), and just to spoil memory and resource.
So, why to use Perl when finally the programmer has 60 pct resource to waste.

There are many good examples that may show how much over-used is Perl.
 
drhowarddrfine
The problem I see is that learning theory only doesn't help much when one wants to actually practice a trade. See Phishfry's post above.
And, see herrbischoff's post (#11) what happens when things are being developed by pure theoreticists.

And regarding your post #15, it's actually some interesting truth in it. When one considers the resources (hardware, electricity) consumed by assembly (or C == near-assembly) programming products, one could contemplate how many nuclear power plants less would be needed if all the web stuff would be done in assembly instead of Perl, PHP, etc.
On the other hand, how little technology would be in actual use when there were no tools like NC machines that can mass produce things that only a few highly skilled masters of craft trades can produce without sophisticated tools...

Regarding Arkham University, I love H.P. Lovecraft's stories.

@Spartekus
I wonder how much of the gigahertzes and terabytes are actually being used in many cases. When hardware idles 99.9999% of the time it probably does not matter much when that "efficiency" gets reduced to 99.99%...
 
drhowarddrfine
The problem I see is that learning theory only doesn't help much when one wants to actually practice a trade. See Phishfry's post above.
And, see herrbischoff's post (#11) what happens when things are being developed by pure theoreticists.

And regarding your post #15, it's actually some interesting truth in it. When one considers the resources (hardware, electricity) consumed by assembly (or C == near-assembly) programming products, one could contemplate how many nuclear power plants less would be needed if all the web stuff would be done in assembly instead of Perl, PHP, etc.
On the other hand, how little technology would be in actual use when there were no tools like NC machines that can mass produce things that only a few highly skilled masters of craft trades can produce without sophisticated tools...

Regarding Arkham University, I love H.P. Lovecraft's stories.

@Spartekus
I wonder how much of the gigahertzes and terabytes are actually being used in many cases. When hardware idles 99.9999% of the time it probably does not matter much when that "efficiency" gets reduced to 99.99%...


Interesting...
More nuclear plants is likely THE solution to our informatic's evolution (devolution?).
 
Interesting...
More nuclear plants is likely THE solution to our informatic's evolution (devolution?).

Quick question: was your original question just meant as a rant fueled by a superiority complex because you believe by being a C programmer you have seen the light? Or are you truly interested in the actual practical reasons behind why scripting languages are used in certain instances instead of compiled ones like C – and are open to the answers even though you may disagree on a purely theoretical level?
 
Snurg There is "craft" and there is "a trade" and I may not be correct with the definitions but it falls back to my comment about "slapping things together" which I find so prevalent in the web dev industry.

I had a company approach us about re-doing their web site. It was last updated in 1999. His brother did web dev for simple "business card" sites using common CMS systems and he had done the programming for his current site. He asked how long it would take for us to put together a layout package/concept, I told him three weeks. "Three weeks!", he replied, "My experience is you should complete the whole thing in three weeks!".

Needless to say, I ended the conversation and left. We are craft, not trade. "Fast, cheap or good. Pick two.", as the saying goes.

herrbischoff I'm not trying to say you can't write good software without C. I'm saying the goals are different.
 
We create high performance web sites for the entertainment industry mostly. Everything we do is in C from page generation to serving it up. In a way it's a niche but it's where all web sites should be if companies could find enough people to do what we do in C. While many complain about the speed of serving up pages, we coast along with smaller servers doing 10x the work.

Are you doing CGI programming in C?
 
Quick question: was your original question just meant as a rant fueled by a superiority complex because you believe by being a C programmer you have seen the light? Or are you truly interested in the actual practical reasons behind why scripting languages are used in certain instances instead of compiled ones like C – and are open to the answers even though you may disagree on a purely theoretical level?

This is obviously a joke thread IMO (or written by someone who does not understand the concept of trade-offs).
 
There is "craft" and there is "a trade"

We’re homing in on the most important point. Craft vs. Trade. If you’re serious about what you do, if there’s a sense of purpose to what you do, you’re probably a craftsman. If you’re doing it because it’s your job, you’re closer to being a tradesman.

Like it or not (and you really don’t like it, it seems), tradesmen are in the vast majority. Which has always been and always will be that way. As long as there’s money and the need to earn it to live, it will be like that. Maybe even then it would be like this because not everyone wants to do a deep-dive for every little thing they do. In a perfect world maybe. However, time is finite. If you decide to spend it on expert-level C, obsessing over shaving milliseconds off processing time, that’s totally impressive and you’re probably a great craftsman. But as you so colorfully illustrated yourself: certain customers aren’t for you. Instead of explaining why it takes you this long to do things, you turn around and leave. It’s your prerogative. It’s also arrogant. The client has different needs, simpler. Not everything has to be on your level of technical sophistication. That’s why pragmatic solutions often prevail over technically pure ones.
 
Back
Top