berenger.mo...@neutralite.org wrote:
Le 18.10.2013 04:32, Miles Fidelman a écrit :
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).
I never said I agreed that C was designed to build OS only. Having to
manage memory does not make, in my opinion, a language made to write
OSes.
Didn't mean to imply that you did - sorry if I gave that impression. I
was commenting on the quoted text "to say that C has been made to build
OSs only" - and saying that (I think) we're in agreement that it wasn't
(and that we're in agreement with the author or C in this).
I never took a look, but are linux or unix fully written in C? No
piece of asm? I would not bet too much on that.
I wouldn't either. Though again, a quote from Kernighan & Ritchie (same
source as previously): "C was originally designed for and implemented on
the Unix operating system on the DC PDP-11 by Dennis Ritchie. The
operating system, the C compiler, and essentially all UNIX applications
(including all of the software used to prepare this book) are written in C.
I'll also quote from "The Unix Programming Environment" (Kernighan and
Pike, Bell Labs, 1984) - and remember, at the time Bell Labs owned Unix
- "In 1973, Ritchie and Thompson rewrote the Unix kernel in C, breaking
from the tradition that system software is written in assembly language."
Out of curiousity, I just took a look at
http://www.tldp.org/LDP/khg/HyperNews/get/tour/tour.html (a nice intro
the kernel) - and it explicitly mentions assembly code as part of the
boot process, but nowhere else
I expect, that outside of the boot loader, you might find some assembly
code in various device drivers, and maybe some kernel modules - but
probably not anywhere else (except maybe some very performance-critical,
low-level modules).
It was simply to argue that, even if it was true, then it does not
avoid it to be good to write applications, since, in more than one
people's opinion, OSes includes applications.
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 actually have less problems to write code that I can maintain when I
do not have to use SQL queries and stored procedures.
I simply hate their syntax. Of course, I am able to write some simple
code for sql-based DBs, but building and maintaining complex ones is
not as easy as building a complex C++ module. Or as an asm or C, or
even perl. Of course, it is only my own opinion.
Gee... I'd say just the opposite, but that's a matter of personal
experience. Personally, I won't touch C - I'm a big fan of high-level
and domain-specific languages for most things, and I guess I'd consider
SQL a domain-specific language of sorts. (Then again, I haven't written
a lot of code in recent years. I generally work at the systems level of
things.)
I'd simply make the observation that most SQL queries are generated
on the fly, by code
It is not what I have seen, but I do not have enough experience to
consider what I have seen as the truth. But I will anyway allow myself
a comment here, if some people wants to create a new language: please,
please, please, do not do something like powerbuilder again! This crap
can mix pb and sql code in the same source file and recognize their
syntax. It will work. But will be horrible to maintain, so please, do
not do that! (this language have really hurt me... and not only
because of that)
I've seen pretty much the opposite. Pretty much any web app with a
query interface is talking to some kind of back-end that translates GUI
interactions into SQL that in turn gets run against a database. (Just
consider searching for a book on Amazon - there's a lot of SQL being
generated on the fly by some piece of code.) Or for that matter,
consider Excel's wizard for importing from an SQL database - when you're
browsing a table in the GUI, something is generating the SQL that's sent
to the database.
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.
It seem you attach a lot of importance to schools ( that what I
understand in "computer science curricula" ) but I wonder: how do you
consider people who learned themselves, before even learning a craft
at school ( that's what wikipedia says when I start from the French
"métier" and then switch on English language. I understand that it
seems to be reserved for physical products in English, but, I like
that notion: "A craft is a pastime or a profession that requires some
particular kind of skilled work." which makes things different from a
simple job. ) ?
Would you name them coder, programmer, developer? Something else? Do
you consider they are always less efficient that people with high
degrees?
Well, yes.... engineering is a professional discipline, lots of
knowledge (both from books and practical) - generally, folks who work as
software engineers a degree in EE, or CS, or CE, or sometimes math.
Having said that:
- In the early days, say before 1980, that was less so - in those days,
practically nobody knew anything about computers; I know quite a few
people who dropped out of college and went right to work in the field,
and never looked back. (For that matter, Bill Gates comes to mind.)
These days, though it's a lot harder to get hired for anything without a
bachelor's degree - at least in the US (I know that education works a
little differently in Europe.)
- Also, a lot of people doing software development are NOT degreed
engineers (though it's pretty hard to get hired for anything in the US
without a bachelorate in something). What I'd call them really depends
on their level of skill - highly skilled, I'd call a developer. Lower
skilled, I'd call an amateur. (I don't really have a lot of use for
"programmers" or "coders" - knowing how to program or code is a pretty
useless kill unless you also know how to solve real problems with the code.)
My general observation is that you find more specialization in
developers than in software engineers - with developers typically coming
from some other background. For example, a researcher who writes some
code to analyze laboratory results in their field, then goes on to
develop commercial analytic software, picking up programming skills
along the way. Or a visual artist who goes into video game design.
They learn the programming skills they need to solve specific problems,
in their specific area of focus - but that doesn't make it possible for
them to solve a general computing problem.
It's certainly possible to learn stuff on one's own, but my observation
is that true depth and bredth requires some amount of formal education
from folks who are already knowledgeable. It's like anything - sure
there are self-taught violinists, but most who've achieved a serious
level of skill (much less public recognition) started out taking years
and years of lessons. Accomplished craftsmen (and women) have typically
studied and apprenticed in some form. I sure wouldn't trust a
self-taught doctor performing surgery on me - I'd want someone who went
to a good medical school, followed by a good internship and residency,
and a track record.
Are you saying it's NOT easy to install stuff on Windows?
Compared to other things I know, aka, deb packaging system, yes.
Considering you already have the archive binary, on windows you will
have to read lot of screens, or you will destroy your system in less
than 1 year, if you often add and removes applications, because when
you remove something which installed crap on your computer, it won't
remove it.
Sometimes, on Debian, I have to compile stuff myself... but it is the
same for windows.
And, finally, to install and configure programming related stuff, like
development libraries, on Debian you simply install them. They are
installed in correct places so it is automatically detected by tools
which needs them.
On Windows, when you will have finally installed it, you will have to
take care where you did, because you will need that information later,
and all softwares have their own preferences. Not to speak about the
fact that they usually install in "c:\program files\<company
name>\<software name>\". The company name is sometimes editor's one,
or developer's one. Random.
Installing stuff on windows is only easy when you only know windows in
modern OSes (this is to discard ms-dos ;) ).
Oh, and I did not mention that, on windows, installing a software
which depends on another software will need you to install manually
that other one. Which is why softwares often (but not always, I had
lot of errors claiming that something was missing) includes most (but
not always all) dependencies.
So, yes, generally, installing stuff on Windows is hard, compared to
the only other modern system I know: Debian.
Ok, but now we're talking an apples to oranges comparison. Installing
developers tools is a pain, no matter what environment. For fancy,
non-standard stuff, "apt-get install foo" beats everything out there,
and "./configure; make install" is pretty straightforward (assuming you
have the pre-requisites installed).
But when it comes to packaging up software for delivery to
users/customers; it sure seems like it's easier to install something on
Windows or a Mac than anything else. Slip in the installation CD and
click start. Not as common on Linux.
Miles
--
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/52614442.2090...@meetinghouse.net