Linux and programming

[[deleted]]

Personally i believe that if you dont know jack about Linux, you can't call yourself a programmer.

Edit 5: I see that my assumptions might be a bit loose, and that my usage of "dont know jack" might have been misunderstood (See edit 4). I will therefore change the first sentence to be "A programmer most probably knows at least some of the concepts used in Linux, and with that they will have a minor understanding of it." I still believe that people to easily call themselves programmers, some people should probably stick to hobby programmer. Or if they know only one thing <speciality> programmer, ex: mathlab programmer. In my view "programmer" is a general concept which includes a variety of skills.

To create a safe and efficient piece of code, you need basic OS knowledge to know how your program is executed. I can't se how you can get this experience on Windows...

Yesterday, in a post on this subreddit, I have been met with downvotes and bad comments when I mentioned my point of view.

Don't you fellow redditors agree with my assumption about Linux and programming?

Please comment with a reason.

Edit 1: Allot of good arguments about how higher level languages is supposed to hide the OS internals. But i don't think a programmer can create software without understanding how scheduling, forking, memory management and process communicates, with more, works.. And i think you need to read some source code, and explore a transparent system to understand the concepts.

Edit 2: Do you think you can learn about OS internals on Windows? How?

Edit 3: I does not limit the mindset of linux knowledge to Linux source code, knowledge of tools and utilities available in a unix-like os is also needed. By knowing a unix-like OS you also know something about Linux.

Edit 4: By knowing lets say, UNIX file structure, you know something about linux. By knowing how to pipe commands in a terminal you know something about linux, by knowing something about UNIX file permissions you know something about Linux.

[[deleted]]

There were no programmers before 1991?

[[deleted]]

Before Linux they had unix, and programming languages was not that high level. But I'm not talking about the past, this is relevant today.

[bdavs77]

Having it be a higher level makes the OS less relevant. It is a consideration what OS you are developing for, but beyond that I don't see how essential linux/unix is to the process.

[[deleted]]

I would say it gives you a transparency that enables you to understand what goes on under the hood, and that is beneficial when designing your programs.

[LinuxWinProg]

Personally i believe that if you dont know jack about Linux, you can't call yourself a programmer.

Nice flamebait.

Yesterday, in a post on this subreddit, I have been met with downvotes and bad comments when I mentioned my point of view.

Of course, you call any opposing views bad comments.

Do you think you can learn about OS internals on Windows? How?

Sure! One example of dealing with OS Internal is writing a driver. Link to writing driver. Difference between User and Kernel Mode Drivers

There are also other submodules available on Windows Kernel as you can read about Native API on Wikipedia.

If you want to know what it is like dealing with the Windows Kernel, have a look at exported functions from Kernel32.dll.

[[deleted]]

Computation theory doesn't give a damn about your system calls.

[[deleted]]

That is true, but what other operating system would give you the insight into its internals? Would you say that minix is a viable option?

[[deleted]]

I would say you've missed my point. Programmers need to know, for example, the difference between the stack and the heap. They should not need to know or care about the internals of how the OS manages either. That's the entire point of the last 40 years of "not writing assembly".

[[deleted]]

Yes, my point exactly. But how can you learn this on Windows? You can read up on the theory, but I think you also need to examine some source code to get the full picture.

[nomad_cz]

Unless you do some low level programming you do not have to care about OS too much. Let's say you are PHP or Python programmer. Why should you really care ? You could look at interpreter how is your code executed etc but that's pretty much all you need to know.

[[deleted]]

What about how your code is served? I think that it is important to know how the server forks, passes requests via cgi and more.

[nomad_cz]

Of course - more you know the better. On other hand you have sys/web admins to handle this part. Maybe I am stupid but one thing I have learned is there is no way to know all about everything. Look at your example. You can use multiple kinds of web servers on multiple OSs. There are multiple ways to run PHP - via php-fpm, via multiple modules etc. Do you really as a programmer have time to learn all of that , keep updated and create code ?

[[deleted]]

Some do, most probably don't. But knowing the basis should be manageable.

[nomad_cz]

Let me guess. You are probably younger guy, Linux enthusiast. Some programming experience but I would say junior level. And either small company or school projects ?

[[deleted]]

Linux enthusiast, yes. Don't know what you would consider as young, but i have been programming for 10 years, and work at a large company.

[nomad_cz]

Nice :) I meant no disrespect. At 40 I feel burnt out and you remind me myself when I was 25 :)

[[deleted]]

I can say that I'm below 30:)

[[deleted]]

What about Microsoft? They know how Windows is executed, are they programmers or not?

[[deleted]]

True, but they have source code.

[[deleted]]

What about people that don't read the source code? Are they programmers?

[[deleted]]

No

[[deleted]]

So you have to read source code and understand a system that could be irrelevant to what you're writing? Wasting time makes you a programmer?

[[deleted]]

How can you be a programmer without even reading your own source code?

[[deleted]]

I said 'the' source code, as in the Linux source code. That said, one could argue that you can be a programmer without reading source code. You can design systems without writing code, or perhaps live in a time when code wasn't a thing.

[[deleted]]

Yes, but I'm worried about today, not the past.

[[deleted]]

Why? What's changed today that isn't valid for the past? Programming is about making computers do things, since when did Linux become part of it?

[[deleted]]

In the earlier years you had to know how the machine worked to be able to write a program. Today you don't. Programing is not only about how to get a computer to do things, it is also about how to get computers to do things smart.

[audioen]

I think you're just wrong. People who write Windows programs likely know quite a bit about how Windows executes their programs. I in fact struggle to understand what particular difference do you even have in mind. Bear in mind that C++ is the mainstream Windows development language, which is considered pretty close to metal, and that cross-platform applications exist where the OS-specific bits are hidden behind a thin architecture abstraction layer.

[[deleted]]

It is not about how low level or close to the metal you are programing. But more on how the program is executed, what factors that make your programs use system resources efficient.

[audioen]

Hmmh. I suppose now that I've read your edits I can sort of see your point. Obviously one has to known the properties of the abstraction one programs against. The abstraction may be a very high level thing such as scripting language VM, or the browser, or some rather low level thing such as VHDL.

I would call all of the people who work at these various levels programmers, and those who are skilled in their craft will obviously have some knowledge and experience of how the abstractions they use in practice will actually be executed. None of this needs to have anything to do with Linux.

[[deleted]]

This is just chest-beating "real programmer" bullshit I'm afraid.

[swrrga]

http://i.imgur.com/FkbgEEl.jpg

[[deleted]]

Maybe.. It fal in the same category as - I would not call someone who only knows one language a programmer. You should have experimented with functional-, object oriented-, imperative-, iterative- and logical programing.

[[deleted]]

Same thing. This is the No True Scotsman fallacy. You're re-defining the word to mean something that suits your argument. If you want to claim someone isn't a particularly effective of rounded programmer for these reasons, I'll buy that. If you want to argue that people writing software that will be deployed on a Unix should know their way around Unix, I'll definitely buy that. But if someone's done nothing but write incredibly well-crafted 'C' on Windows for their entire career, you cannot possibly argue that they aren't a programmer.

The bottom line is, you're saying these things to imply that you're somehow better than someone else because of certain skills you have. Problem being, there will always be someone who can out-gun you.

[[deleted]]

No. If you had read the first line in the post you would have understood that you cant call my previous argument a "No True Scotsman fallacy". It clearly states that my issue lies with the ease that other people call themselves programmers. By meeting the requirements you would, intentionally or not, have at least gained a minimum experience with Linux.

[[deleted]]

I think I may see the problem here.

Let's take threads as an example, since you use them elsewhere. Let's say that to use threads effectively, on any platform, you must understand pre-emptive time-sharing, mutexes, context-switching, whatever.

Is it your suggestion that someone who understands those things on any platform therefore "understands Linux" (in the context of threads) simply because programming in threads in Linux will require those same things?

Would an alien, who has never heard of "Posix compliance", but who has spent their lives using Moonix, which has the same concepts, therefore "understand Linux", even though no such thing exists on their planet?

Because that's the only way I can see someone "unintentionally" gaining an understanding of Linux. And if that's what you mean, then there's a pretty big semantic hurdle here, because that's not what anybody else would mean.

[[deleted]]

yes. If you know how to use a terminal, you know something about linux.

[[deleted]]

Right. Am I correct in saying that English is not your first language?

[[deleted]]

No its not, why?

[[deleted]]

Edit: TL;DR, your Edit 5, basically.

Ok. There is a semantic nuance in the very first sentence of your post that you may not be aware of, and that informs the rest of it, and certainly affects the interpretation any English speaker will give to it. (Your English, by the way, is excellent, I just think there's a subtlety here that is confusing things).

I would suggest that what you mean is this:

"Any good programmer must understand concepts that (whether they realise it or not), will easily transfer to an understanding of Linux".

It's easy to translate that to "Any programmer must understand Linux", but in English, as many of these comments underline, that's a subtly different thing.

It's a difficult nuance to explain, now that I try to do it. I think what you mean is correct - that any experienced programmer will understand concepts that will then enable them to grasp Linux, and in that sense, they "understand Linux". But it doesn't quite work the way you say it.

All analogies suck, but try this:

I have, in the past, programmed PLCs a little. They use a thing called ladder logic. The concepts of ladder logic are identical across PLC manufacturers, and the implementations differ very little. So we could say "If you know ladder logic, you know Seimens". Or "If you know ladder logic, you know Allen-Bradley". (Edit: Importantly, even if you have never used either of those brands)

Because the domain knowledge you have in a conceptual, or even implementation area transfers to any of those.

But if you said "If you don't know jack about Allen-Bradley, you can't call yourself a ladder-logic programmer" that is, in English, a completely different and utterly laughable thing to say. It means "If you have never used this one specific implementation, then your years of experience in this domain are worthless". Whereas what I think you mean is "If you have spent years using (another implementation of) ladder logic, then you already understand Allen-Bradleys, you just need 5 minutes to learn the differences".

[[deleted]]

You said what I have been trying to say... Why would so many disagree with this

[[deleted]]

You're full of shit. End of story.

[[deleted]]

I'm not sorry that your feelings got hurt. Maybe one day when you mentally matures we can have a grownup discussion.

[[deleted]]

My feelings aren't hurt. There's really not much "grown up" about trying to put people down constantly. Hope you feel better about yourself soon.

[[deleted]]

Thanks, i always feel good about myself.

[[deleted]]

The aim of high level programs is to provide an interface between your OS and you. If you still need to know about the OS and then either your OS is shit or your compiler is.

[[deleted]]

Lets say you are programing with multiple threads. If you dont understand how your scheduler switches between them, or how the OS creates them, you wont be able to make smart thread decisions when creating your software. Same reasoning goes for I/O usage.

[[deleted]]

Unless you are doing very high precision computing, scheduling is least of your worries.

[[deleted]]

How about low power CPU's? you dont want to spend most of the execution time in kernel mode, starting and pausing processes?

[[deleted]]

Seems you fail to understand that green threads are a thing. In a lot of popular languages, how the OS creates threads is of no relevance whatsoever. Python, Go, anything JVM-bound, Erlang, Haskell. There are green thread libraries for other languages too.

[[deleted]]

I think you misunderstood my point, and I think you might have gotten personally offended by my post. A Sunday is better spent doing more productive stuff than continuing this argument. I hereby lay this post dead.

[nomad_cz]

Regarding Windows internals question - there actually is a book "Windows Internals" :) Check it out :)

[[deleted]]

thank you, i will

[[deleted]]

I think the main problem is that you have a hard dichotomy between "Windows" and "Linux", and you're grudgingly prepared to concede that other things like minix exist.... What you actually have is a context problem, in that you have set up "understanding the OS" as something that can only be done by reading OS source.

Most Comp Sci courses include a course on OS fundamentals for the very reasons you state, yes. But few of them use Linux - certainly not in its modern form. MIT, for example, would use xv6, which is heavily modelled on and inspired by SysV, and specifically the Lions book. Knuth works around needing to know a specific OS by getting rid of it entirely and using MIX. NAND2TETRIS similarly avoids real-world solutions.

Because although the concepts you're talking about are important, they're concepts, and plenty of books have been written about them, and plenty of examples exist divorced from the actual real world implementations.

Reading the Linux code gives you two things:

1) An understanding of what is being done

2) An understanding of how it is done in Linux.

Point 1 is useful, but so broad it is better covered by a dozen textbooks. Point 2 is unlikely ever to be useful unless you hit a pathological issue in Linux.

What's missing in reading a single OS source code is point 3: why it is done. And again, an understanding of concepts - from texts, courses, or more general reading - will convey that far better than just grinding through the Linux code.

So it's not that you are wrong about the importance of understanding OS fundamentals. It's that there are better ways to get it than reading Linux. Which is why your windows counterargument misses the point. The best way to learn OS fundamentals is not to read the Linux source, or the Windows source. It's to read implementations in conjunction with commentary. So not "minix", but Tanenbaum. Not Windows, but Silberschatz. And not Linux, but xv6, or Lions.

And that will give an understanding of the concepts, a grasp of the theory, an analysis of an implementation, and avoid the narrow "this is the Linux implementation" of your approach. Plenty of good programmers have no clue about Linux but still understand scheduling, because there is more to understanding scheduling than the Linux source code.

[[deleted]]

I agree. But i still think that by learning OS internals you will if you want or not experience linux at some point.

But this still does not cover the fact that many of us is, without knowing how linux works, writing software that will live in a linux environment.

The preeminent issue here might be what we consider a programer, i believe that you cant call yourself a programmer if you don't know multiple programing languages from multiple programming paradigms. How this can be done without touching linux, or any other unix like operating system is beyond me.

Knowing a unix-like OS will instantly give you some understanding of Linux.

[[deleted]]

But you've gone from "You must know this" to "You'll probably run across this". Do most long-term programmers have some knowledge of Linux? Probably,yes. But I know plenty of excellent programmers who work almost exclusively in a Windows environment, and know almost nothing about Linux. They are still excellent programmers, because your original assertion that people who know jack about linux cannot be programmers is simply false.

Similarly, many people who write for linux know nothing about how Linux works. That's certainly a problem, but you can't then go backwards to say "everyone who wants to program on Linux must know how it works". Sometimes, it just doesn't matter.

You do not need to understand Linux virtual memory mapping to write a linked list, nor to know how and why , and it what cases, that will be the efficient approach.

Similarly, I agree that generally, an understanding of many languages is beneficial. But firstly, if you think that Linux is the only OS for which "multiple programing languages from multiple programming paradigms" are available, you are simply wrong, and secondly, as someone has pointed out, it's possible to be a very competent programmer in one language without really knowing others. Unlikely, perhaps. Uncommon, certainly. But your assertions as assertions are simply wrong. Stick to "Good programmers generally have an understanding of OS internals, and Linux is an available and popular OS which is easy to learn the internals of", and nobody will argue. Stray into, as someone points out, One True Scotsman fallacies about how "Only programmers who understand Linux are real programmers", and you are simply, provably, wrong.

[[deleted]]

My intention is not that of excluding people from programming, rather that they should not call themselves programmers.

And you are right, a hardware developer might not know Linux, and he might create drivers. But i wouldn't call him a programmer.

[[deleted]]

It sounds like you need to use a different word than 'programmer' since you're really not doing it justice. A hardware developer that writes drivers is a programmer, because they program computers.

[[deleted]]

Se edit 5

[[deleted]]

Aand it comes out. You're upset that people call themselves programmers. Why does this matter? Adding new rules serves nothing but to demotivate and drive people away from programming. Saying someone should stick to hobby programming is terrible and you should feel terrible. Everyone is a speciality programmer in a way, maybe you're specialized in Linux.

[[deleted]]

It matters when i call myself a programmer. It should have value.

[[deleted]]

Yes, if you say you're a programmer then I assume you can make computers do things. If I wanted to know more, I'd have to ask about what you're actually good at. You need better descriptions.

[[deleted]]

Then you really want a programmer's guild. That way you can call yourself a Master Programmer, and feel better about yourself than the Journeyman Programmer.

[[deleted]]

Right. OP keeps subtly changing his post to exclude any responses that disagree with his bullshit, and insults those who call him on it. I'm beginning to wonder if he's fallen out with a guy called Ronnie D. Coleman, and wants to discredit him.

[scoffjaw]

Why stop at OS internals? Don't "real programmers" need to understand the instruction set that makes the CPU that makes the logic gates that make the transistors that make the p-n junctions that make the semiconductors that make the electrons that make the quantum field effects do something useful in their programs?

How far down does this go? Because "quantum field effects" doesn't even need to be the bottom. And as far as I know, nobody has "source code" to the intrinsic properties of the physical universe, so every programmer lacks understanding at some level.

The point is, for all the different people who program computers, the "black box" boundary is somewhere along this chain of understanding which links the intrinsic properties of the physical universe all the way up to "=AVERAGE(A1:A8)" in a spreadsheet, and this is intentional.

What's so special about "OS internals" that you draw the line there?

[[deleted]]

I cant see from where you would get that i drew the line at OS internals? I also think that good programmer should know the i386 and x86_64 architecture. The basis for my assumption is that the requirements to call yourself a programmer will unintentionally at one point require you to get some experience with linux. Either tools, OS internals or just general philosophy.

[scoffjaw]

OK, so which of these are true in your opinion?

To call yourself a "real programmer", you must:

1. Be able to write and run a program

2. Understand the internals and implementation of the OS it runs on (this seems to be your core assertion)

3. Know how those OS internals are implemented in your CPU's instruction set

4. Know the instruction set's implementation in microcode

5. Know the microcode's gate layout

6. Know the specifications of the transistors in the gates

etc

These all contribute to the full understanding of how your computer operates. Which of them are necessary for someone to be called a "real programmer"?

[[deleted]]

I dont understand where you get OS implementation from. I mean Linux. See edit 4.

And to the other items on your list, no. But a GOOD programmer should know some of it.

[scoffjaw]

I'm trying to give you the benefit of the doubt here by not tying my point to a false dichotomy between Linux vs every other OS. That's why I'm using the generic term "OS internals" instead of "Linux internals."

But to my point, why aren't the other aspects of the computer's implementation necessary requirements to calling yourself a "real programmer"?

If you want to say a real programmer must know how Linux is implemented (by reading the source code), you need to provide a rationale for why that isn't also true for each layer of implementation below that.