berenger.mo...@neutralite.org wrote:
So, what you name an OS is only drivers+kernel? If so, then ok. But
some people consider that it includes various other tools which does
not require hardware accesses. I spoke about graphical applications,
and you disagree. Matter of opinion, or maybe I did not used the
good ones, I do not know.
So, what about dpkg in debian? Is it a part of the OS? Is not it a
ring 3 program? As for tar or shell?
Boy do you like to raise issues that go into semantic grey areas :-)
Not specially, but, to say that C has been made to build OSes only,
you then have to determine what is an OS to make the previous
statement useful. For that, I simply searched 3 different sources on
the web, and all of them said that simple applications are part of the
OS. Applications like file browsers and terminal emulators.
Without using the same words for the same concepts, we can never
understand the other :)
I'm pretty sure that C was NOT written to build operating systems -
though it's been used for that (notably Unix).
To quote from the first sentence of the Preface to the classic C book,
"The C Programming Language" by Kernighan and Ritchie, published by Bell
Labs in 1978 (pretty authoritative given that Ritchie was one of C's
authors):
"C is a general-purpose programming language ...."
Now there ARE "systems programming" languages that were created for the
specific purpose of writing operating systems, compilers, and other
systems software. BCPL comes to mind. PL360 and PL/S come to mind from
the IBM world. As I recall, Burroughs used ALGOL to build operating
systems, and Multics used PL/1.
LISP was interesting in that it was written in LISP (modulo a tiny
bootstrap) as was most of the o/s for both flavors of LISP machine (if
memory serves me - its been a while).
No, but I do understand why comparing text is slower than integers
on x86 computers. Because I know that an int can be stored into one
word, which can be compared with only one instruction, while the
text will imply to compare more than one word, which is indeed
slower. And it can even become worse when the text is not an ascii one.
So I can use that understanding to know why I often avoid to use
text as keys. But it happens that sometimes the more problematic
cost is not the speed but the memory, and so sometimes I'll use text
as keys anyway.
Knowing what is the word's size of the SQL server is not needed to
make things work, but it is helps to make it working faster. Instead
of requiring to buy more hardware.
On the other hand, I could say that building SQL requests is not my
job, and to left it to specialists which will be experts of the
specific hardware + specific SQL engine used to build better
requests. They will indeed build better than I can actually, but it
have a time overhead and require to hire specialists, so higher
price which may or may not be possible.
Seems to me that you're more right on with your first statement. How
can one not consider building SQL requests as part of a programmer's
repertoire, in this day and age?
I agree, it is part of programmer's job. But building a bad SQL
request is easy, and it can make an application unusable in real
conditions when it worked fine while programming and testing.
Sure, but writing bad code is pretty easy too :-)
I'd simply make the observation that most SQL queries are generated on
the fly, by code - so the notion of building SQL requests to "experts"
is a non-starter. Someone has to write the code that in turn generates
SQL requests.
For now, I should say that knowing the basics of internals allow to
build more efficient softwares, but:
Floating numbers are another problem where understanding basics can
help understanding things. They are not precise (and, no, I do not
know exactly how they work. I have only basics), and this can give
you some bugs, if you do not know that their values should not be
considered as reliable than integer's one. (I only spoke about
floating numbers, not about fixed real numbers or whatever is the
name).
But, again, it is not *needed*: you can always have someone who says
to do something and do it without understanding why. You'll probably
make the error anew, or use that trick he told you to use in a less
effective way the next time, but it will work.
And here, we are not in the simple efficiency, but to something
which can make an application completely unusable, with "random"
errors.
As in the case when Intel shipped a few million chips that
mis-performed arithmatic operations under some very odd cases.
No need for a problem in the chip. Simply doing things like "0.1f ==
1.0f/10.0f" in a moment you do not take care can cause problems. I
think that compilers warn about that however.
:-)
But now, are most programmers paid by societies with hundreds of
programmers?
(and whether you actually mean "developer" vs. "programmer")
I do not see the difference between those words. Could you give me the
nuances please? I still have a lot to learn to understand English for
precise terms.
The terminology is pretty imprecise to begin with, and probably varies
by country and industry. The general pecking order, as I've experienced
it is (particularly in the US military and government systems
environments, as well as the telecom. industry):
Systems Engineer: Essentially chief engineer for a project. (Alternate
term: Systems Architect)
- responsible for the big picture
- translate from requirements to concept-of-operations and systems
architecture
- hardware/software tradeoffs and other major technical decisions
Hardware Engineers (typically Electrical Engineers): Design and build
hardware (including computers, but also comms. networks, interfaces, etc.)
Software Engineers: Engineers responsible for designing and building
software. Expected to have a serious engineering degree (sometimes an
EE, often a Computer Science or Computer Engineering degree) and
experience. Expected to solve hard problems, design algorithms, and so
forth. Also have specific training in the discipline of software
engineering. People who's resume says "software engineer" have
typically worked on a range of applications - the discipline is about
problem solving with computers.
Developer: Vague term, generally applied to people who do the same
kinds of work as software engineers. But doesn't carry the connotation
of an EE or CS degree. Tends to be commonly used in product development
environments. In my experience, a lot of developers start out writing
code in their own field of expertise (doctors writing medical
applications, musicians writing music software, and so forth). People
with "developer" on their resume often have specialties associated with
the term - e.g., "game developer" - emphasizing an area of specialization.
Programmer: A term I've never actually understood. Basic use seems to
be "someone who knows how to program" or "someone who programs for
living." But.... I've personally never seen anyone hired purely as a
"programmer." (I've hired, and seen hired, a lot of developers and
software engineers, but never a pure programmer.) As far as I can tell,
the term is a carryover from the early days of large systems - where
"systems analysts" figure out what a system was supposed to do (i.e.,
did the engineering) and then directed programmers to write code. (Akin
to the relationship between a hardware engineer giving a design to a
technician, who would then build a prototype.)
Coder (or "code monkey"): A somewhat pejorative term for an unskilled
programmer - someone who might have taken a couple of "introduction to
programming" courses and now thinks he/she can write code.
For what it's worth - my observation is that the demand is for software
engineers and developers (i.e., skilled people who can solve real
problems). But... computer science curricula, at least in a lot of
schools, seems to be dumbing down -- a lot of places look more like
programming trade schools than serious engineering programs. Not a good
thing at all.
And, again, just a guess, but I'm guessing the huge percentage of
programmers these days are writing .NET code on vanilla Windows
machines (not that I like it, but it does seem to be a fact of life).
A lot of people also seem to be writing stored SQL procedures to run
on MS SQL.
Windows actually provides a stable environment, very good programming
tools ( visual studio is a really good IDE ), and when you write for
it, you know that most computers will be able to run your program.
Well sure - but, by definition, it's not cross platform, and I sure
wouldn't write server-side stuff to run on Windows (though many do,
including my current major client).
I probably wouldn't write a telecom. switch control program to run under
Windows, for example - and I expect visual studio wouldn't help a lot in
writing Erlang code (though I'm not sure there's a good IDE for Erlang).
Arguably, it is also easy to install stuff on windows.
I strongly disagree with that for most current linux-based OS, but I
remember my first installs of Debian. I was used to consoles, but I
had no knowledge of what tools I had to do anything, and no graphical
interface to learn basics from the Internet. Debian without Internet
was not usable for beginners at that time (installer provided
woody/potato at that time IIRC. I had my first successful use of
Debian with Etch... or was it Lenny? I only know that I know all those
version names for a reason or another, don't remember completely). So,
that linux-based reputation is not stolen, and since it is not used a
lot, it has not been reduced unlike the windows' one to be unstable
and full of security holes. And when people asks me what I am running
with, I have to reply it is a Debian, and insist on the fact I have
heavily customized it to avoid frightening them.
Those are probably the reasons why people programs with Microsoft's
"closed" technologies. But now, MS can argue that .NET is available on
linux too, and that SQL is standard ( but not procedures which are an
important part, of course ).
We can just hope that windows usage will continue to very, very slowly
regress to have more portable softwares.
Are you saying it's NOT easy to install stuff on Windows? (Note: I
agree, that many linux installs are also easy, but that wasn't the focus
of my comment.)
I expect that there are NOT a lot of people writing production code
to run on Debian, expect for use on internal servers. When it comes
to writing Unix code for Government or Corporate environments, or for
products that run on Unix, the target is usually either Solaris, AIX
(maybe), and Red Hat.
Of course. Things were you can have someone to force to fix something
with contracts. For Debian, I doubt that any contract to earn money is
made, so... but I would be really happy to have an opportunity to work
in programming outside of windows world. Sweet dream.
Lots of opportunities in the Solaris and Red Hat worlds! Probably SUSE
as well. I expect there are people hiring for Ubuntu-related work,
which is pretty close to Debian.
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52609dad.50...@meetinghouse.net
