The inventors of Unix don't use it any more, isn't that enough for you people.
No. I'll stop using Unix when something more useful to me
comes along. That hasn't happened yet, obviously.
Plan 9 could have been useful if Unix was bad enough to make
people migrate.
As it is, something that replaces Unix would have to have
enormous technical advantages,
no social or economical disadvantages
-- and a complete Unix compatibility subsystem.
I think Pike has written about that effect too,
somewhere...
Never, ever, ever, ever start a beginner programmer with Java. The OOP features are guaranteed to confuse the poor soul and turn him/her off to programming forever. The best option is to start a new programmer off with a traditional BASIC variant such as SmallBASIC. Such BASICs can be used to teach a new programmer about how software executes one line after another (don't laugh, this is a big problem for new coders), control structures, and how the computer stores/interprets numbers and strings.
?! Why on earth would someone care about BASIC in 2006?
I can only assume that you haven't tried any modern ('modern' as in
'recent', not necessarily groundbreaking) languages.
With the approach to learning you have,
Python seems like a perfect match.
A subset of it maps well to a traditional BASIC and (unlike in Java)
you can ignore the OOP crap.
Unlike BASIC, Python is not a dead language, is widely used today,
and works well for many tiny, small and medium-sized projects.
I only wish we still had command line interpreters around.
The interactive prompt is one of the best things about Python.
Disclaimer: I suppose I am a Python fanboy.
I expect Ruby, Lua and various other modern interpreted
languages fit your requirements, too.
All the options you listed [CVS, SourceSafe and Sourceforge] are for engineers only. If only engineers are involved in your design and development process, that's fine. For us, wiki is a great way to document our software development so that it is accessible not just to software developers, but also to documentation developers and tech support.
Version control is
not just for programmers.
It is applicable for almost all computer work,
for keeping history, creating an audit trail,
enable people to work together, and a great many other things.
It makes work easier and more fun.
Not using at least basic version control is barbaric,
and a waste of time and energy.
There is this widespread notion that version control is hard to learn,
or "for the programmers", or that "it takes time",
and (as you can observe) it pisses me off.
Your organization might still prefer a wiki, of course.
But please do so for valid reasons.
Write the logs to hundreds of thousands of unmarked CDROMs and chuck them down an elevator shaft for safe keeping...
Wouldn't work.
Part of the law is to do data retention;
another part is to provide a convenient interface to the data.
At least it is in the.se case,
but I suspect that the.uk and.se proposed laws are remarkably similar...
Really? This program used to compile in G++:
#include
int main(int argc, char *argv[]) { cout
And yet, now it doesn't. Why? Namespaces.
No. Broken compiler.
Including iostream (like you do) instead of iostream.h
was intended to mean "great, now I'm ready to migrate to the
std namespace; hit me!".
[...] If you are happy running a lightweight desktop on an ageing PC, fine. But realise that other people value their time. Other people hate watching the desktop while Firefox loads. Other people watch videos and listen to music. For you to sit behind your old-school box and pretend that 90% of the people out there are just like you is dumb.
I think it's your world view that's warped.
You mentioned some heavy tasks (OGG encoding, possibly video decoding) but
as for the rest:
PuTTY? Holy shit, there is nothing more lightweight.
Listening to music? Works just fine on a PII at 200MHz, if the player
or audio driver isn't extremely badly written.
I use old memory-starved 166MHz and 200MHz boxes a lot, for pretty complex work (including image editing).
I also use an Athlon 64 3000+ system for the same things.
The only difference that really stands out is the ogg encoding speed...
and I do value my time.
Are your win32 calls supported by WinXP and Win2000?(probably) How much effort would it take to port it to linux? Are you helping lock your organisation onto a single software platform?
In my experience, most organisations that do Windows programming
are quite happy to lock themselves to one OS, one toolchain, and one
proprietary set of APIs.
(And to be fair, I am quite happy doing pure Unix programming.
But at least there isn't a single vendor in that area, and the interfaces
are free.)
You design the application *then* you start making technical decisions about implementation - not the other way around.. there's already too much crap produced by people who *must* use the latest wizzy 'framework' and then design an app to use it regardless of the functional requirements.
I think you mean you make those choices *as part of* the overall design.
Based on reasoning, not (only) people's craving for new toys.
I don't know about you, but when I program in text, I'm thinking in terms of some kind of graphical structure.
And I think in terms of text, as in a textbook or a story.
I suspect this varies a lot between different people.
I nearly got into an argument with a tool vendor recently. He couldn't
imagine someone feeling productive when programming manually, using
a text editor.
I have a hard time getting anything useful out
of looking at colorful pictures, sequence diagrams and PowerPoint slides;
basically anything which doesn't use full sentences.
Meanwhile, I've noted that many people just blank out when they
receive a mail containing more than one paragraph...
However I would like to say that in most cases as a server Unix is better, there is still one place where it is lacking: usability. Sure a seasoned Unix expert understanding what he is doing and can perform plenty of magic, but a company is not always interested in hiring the most compentent person.
a) It's not "magic"; it's reading the documentation, understanding it
and using that understanding to do stuff.
b) Not "the most competent person" but "competent", period.
People who wouldn't be able to perform an admin task in Unix
shouldn't be let near a Windows server, either.
If you want to make reusable code, one thing you're going to have to do is generalize. Don't make ultra-specific functions that just do one ultra-specific thing, put in a couple of parameters to make your function more generic.
No! That way lies Madness.
Possible there are people who can pull this off,
but when I've observed people attempt to
write reusable code, they come up with something slow and buggy
which is so hard to understand that they won't reuse it anyway.
Reuse is hard.
For the kind of thing the original poster asked for,
I simply use copy-and-paste programming.
I keep all my source code in version control
(in CVS, which unlike SVN suits my needs well). If I need something
I think I might have coded before, I go look for it, find it,
copy it, and adapt it. The third time I do this, I might consider making it one single, reusable component.
At that time I know the problem pretty well, and can guess what
is general and what is specific about my problem.
In the company that I work, we had a problem recently in a big MFC multithreaded application [...] our programmers deleted C++ CWnd objects using 'operator delete', whereas they should have used 'DestroyWindow' insteadon (over 120,000 LOC) with memory.
[...] The fact that C++ does not have garbage collection has costed billions of dollars in the IT industry.
And doing big projects in MFC has cost nothing, I suppose...
Can you even do normal, modern C++ programming if you
have to interface to MFC? Isn't that the API which implements its
own nonstandard string class, for crying out loud?
In this specific case, I cannot see why someone in their right
minds would expose a delete operator for a class, if invoking it would be a silent runtime bug.
You know, we have the same system in Sweden, which is a tax for every TV owner which in turn pays for public access TV. Which I don't mind at all. Except that they are complicating matters way too much - and a lot of the money simply goes to administration and "catching the dodgers".
Reference, please. I cannot imagine that administrating the
fees costs much compared to buying rights to the Olympic games,
movies, producing own stuff, news programming...
and the non-fee-related bureaucracy, of course.
It sounds to me as if the management are quite happy with what they've got, it works well enough and they have some annoying techie lobbying to change half their infrastructure software.
Yes.
On the other hand, those managers should stop and think if it's really a good idea to lock yourself into an infrastructure -- just in case they will want to switch later.
There are good reasons to stick with one environment,
and there's the "because we were foolish enough to get locked
into a cascading series of proprietary software, file formats and protocols" reason.
So I guess there weren't any C++ compilers between 1997 when the language was standardised and some time around 2001 when the compiler vendors started catching up with the features that had been included in the spec?
Perhaps my copy of Borland C++ 4.5 from ~1994 isn't a C++ compiler at all, because the language hadn't been standardised when it was written?
If someone says "Pascal", I know they can mean any of
a dozen vendor-specific dialects. I expect and accept that.
Same thing with many other languages from that era.
C++ on the other hand was standardized
at some point. All compiler vendors worked in the same direction. C++ programmers have gotten used to the idea
that there is one standard. We expect to be able to
talk to other people about C++ and agree on what language we
mean.
Then Microsoft comes along with a C++-based language which
adds an important new object model, new operators and all,
and refer to it sometimes as C++/CLI, sometimes vaguely as C++.
Of course we are pissed.
Of course we see this as a threat to the C++ community.
Or at least do. But my point is, it depends on the language.
If I was a Pascal programmer I wouldn't feel as threatened.
In the case of C, I believe the competition between C89 and C99
has been harmful to the C programmers out there -- and yet
C99 brings useful features for everyone, not just
for some people whose target happens to be some specific virtual machine.
For me, moving to Java from C++ was a real relief. No more worrying about low-level memory management issues for the most part, I could focus on the problem domain.
Don't want to add too much to the Java--C++ flamewar,
but I have never felt I had to "worry about low-level memory management"
in C++. And I write a lot of it.
I think we had a memory leak at one point last summer,
in the crazy, inherited part of the code base...
Test coverage measurement is a really dilute quality assurance tool. It can show you parts of your code that are untested, but it doesn't say anything about whether the other parts of your code are tested.
Which is fine if you understand that.
My fear, if I should use such tools, is that they would produce semi-meaningful
figures (say, a percentage) and Management would learn about it,
and start measuring progress and performance based on them.
Once that happened, these semi-meaningful figures would control me...
We have no way of knowing what "ultra-stable" means...
the requirements are not clear to me, so I'm extrapolating a lot.
The best way, IMHO, to create working programs is to
make them simple, to the point of cutting away features.
You mention a GUI, database storage, distributed computing and
numeric programming. Mix those together and I promise
a disaster or a late project. If you can, make the GUI
a separate thing, not vital for using the thing. Same thing with the database stuff.
For the distributedness, CORBA has always seemed like a good way
to end up in a mess. Is it possible for you to split the computations
on process borders, and maybe use ssh to distribute the work?
At least for prototyping?
C++ is a good language for writing big stable applications,
but you need people who write modern C++.
C++ was a terrible language back in the mid-1990s, and many
people still use it that way.
Look for people who understand the RAII concept, and the standard library.
Avoid those that use C strings and C arrays, and have
new/delete sprinkled everywhere in their code.
And, come to think of it, avoid the Java programmers as well --
the people who always find an excuse to introduce abstract base
classes everywhere...
Hint: Trying to judge the software development market based on your Debian installation is futile.
Damn.;-)
Python -- Just because some college student coded a filesharing app with it doesn't make it a popular language. Nothing against the language, just that you probably won't find a job using it.
I think you're wrong. In my part of the world, Python pops up
more and more often. Conversations with my colleagues often include
a "oh, and for our $FOO stuff, we use Python" part.
In places that are not completely Microsoft-centric, and for things that
are in-house but more than a few lines of scripting glue,
Python is becoming a common language.
Python [...] being promoted as "cheaper than Java" probably won't attract the best coding talent.
Did somebody promote Python like that? "More fun and faster than Java, with the best parts of Perl" is more like the message I hear.
And I agree with it.
Slashdot Mirror
Yeah, I edit my /etc/X11/XF86Config-4 with emacs,
and /etc/network/interfaces with vi.
(It isn't Funny if it isn't true.)
No. I'll stop using Unix when something more useful to me comes along. That hasn't happened yet, obviously.
Plan 9 could have been useful if Unix was bad enough to make people migrate.
As it is, something that replaces Unix would have to have enormous technical advantages, no social or economical disadvantages -- and a complete Unix compatibility subsystem. I think Pike has written about that effect too, somewhere...
You're not Linux/BSD slanted, as far as I can tell. And even ancient Unices match almost all the items on your list.
Eric Raymond's The Art of Unix Programming sums up the meaning of "Unix" pretty nicely, by the way. And in great detail.
?! Why on earth would someone care about BASIC in 2006? I can only assume that you haven't tried any modern ('modern' as in 'recent', not necessarily groundbreaking) languages.
With the approach to learning you have, Python seems like a perfect match. A subset of it maps well to a traditional BASIC and (unlike in Java) you can ignore the OOP crap. Unlike BASIC, Python is not a dead language, is widely used today, and works well for many tiny, small and medium-sized projects.
I only wish we still had command line interpreters around.
The interactive prompt is one of the best things about Python.
Disclaimer: I suppose I am a Python fanboy. I expect Ruby, Lua and various other modern interpreted languages fit your requirements, too.
Version control is not just for programmers. It is applicable for almost all computer work, for keeping history, creating an audit trail, enable people to work together, and a great many other things. It makes work easier and more fun. Not using at least basic version control is barbaric, and a waste of time and energy.
There is this widespread notion that version control is hard to learn, or "for the programmers", or that "it takes time", and (as you can observe) it pisses me off.
Your organization might still prefer a wiki, of course. But please do so for valid reasons.
Wouldn't work. Part of the law is to do data retention; another part is to provide a convenient interface to the data. At least it is in the .se case,
but I suspect that the .uk and .se proposed laws are remarkably similar ...
Thank you! You just described the reason I love The Smiths.
Infact it's plainly neurotic.
Do healthy, happy, successful people enjoy music at all? If so, should I blame them for the new Toto record?
No. Broken compiler. Including iostream (like you do) instead of iostream.h was intended to mean "great, now I'm ready to migrate to the std namespace; hit me!".
I think it's your world view that's warped. You mentioned some heavy tasks (OGG encoding, possibly video decoding) but as for the rest:
I use old memory-starved 166MHz and 200MHz boxes a lot, for pretty complex work (including image editing). I also use an Athlon 64 3000+ system for the same things. The only difference that really stands out is the ogg encoding speed ...
and I do value my time.
In my experience, most organisations that do Windows programming are quite happy to lock themselves to one OS, one toolchain, and one proprietary set of APIs.
(And to be fair, I am quite happy doing pure Unix programming. But at least there isn't a single vendor in that area, and the interfaces are free.)
I think you mean you make those choices *as part of* the overall design. Based on reasoning, not (only) people's craving for new toys.
And I think in terms of text, as in a textbook or a story. I suspect this varies a lot between different people.
I nearly got into an argument with a tool vendor recently. He couldn't imagine someone feeling productive when programming manually, using a text editor.
I have a hard time getting anything useful out of looking at colorful pictures, sequence diagrams and PowerPoint slides; basically anything which doesn't use full sentences. Meanwhile, I've noted that many people just blank out when they receive a mail containing more than one paragraph ...
a) It's not "magic"; it's reading the documentation, understanding it and using that understanding to do stuff.
b) Not "the most competent person" but "competent", period. People who wouldn't be able to perform an admin task in Unix shouldn't be let near a Windows server, either.
No! That way lies Madness.
Possible there are people who can pull this off, but when I've observed people attempt to write reusable code, they come up with something slow and buggy which is so hard to understand that they won't reuse it anyway. Reuse is hard.
For the kind of thing the original poster asked for, I simply use copy-and-paste programming. I keep all my source code in version control (in CVS, which unlike SVN suits my needs well). If I need something I think I might have coded before, I go look for it, find it, copy it, and adapt it. The third time I do this, I might consider making it one single, reusable component. At that time I know the problem pretty well, and can guess what is general and what is specific about my problem.
Although if it is done right, it will probably not be percieved as an SF movie.
And doing big projects in MFC has cost nothing, I suppose ...
Can you even do normal, modern C++ programming if you have to interface to MFC? Isn't that the API which implements its own nonstandard string class, for crying out loud?
In this specific case, I cannot see why someone in their right minds would expose a delete operator for a class, if invoking it would be a silent runtime bug.
Reference, please. I cannot imagine that administrating the fees costs much compared to buying rights to the Olympic games, movies, producing own stuff, news programming ...
and the non-fee-related bureaucracy, of course.
Yes.
On the other hand, those managers should stop and think if it's really a good idea to lock yourself into an infrastructure -- just in case they will want to switch later.
There are good reasons to stick with one environment, and there's the "because we were foolish enough to get locked into a cascading series of proprietary software, file formats and protocols" reason.
If someone says "Pascal", I know they can mean any of a dozen vendor-specific dialects. I expect and accept that. Same thing with many other languages from that era.
C++ on the other hand was standardized at some point. All compiler vendors worked in the same direction. C++ programmers have gotten used to the idea that there is one standard. We expect to be able to talk to other people about C++ and agree on what language we mean.
Then Microsoft comes along with a C++-based language which adds an important new object model, new operators and all, and refer to it sometimes as C++/CLI, sometimes vaguely as C++. Of course we are pissed. Of course we see this as a threat to the C++ community.
Or at least do. But my point is, it depends on the language. If I was a Pascal programmer I wouldn't feel as threatened. In the case of C, I believe the competition between C89 and C99 has been harmful to the C programmers out there -- and yet C99 brings useful features for everyone, not just for some people whose target happens to be some specific virtual machine.
Don't want to add too much to the Java--C++ flamewar, but I have never felt I had to "worry about low-level memory management" in C++. And I write a lot of it.
I think we had a memory leak at one point last summer, in the crazy, inherited part of the code base ...
Which is fine if you understand that. My fear, if I should use such tools, is that they would produce semi-meaningful figures (say, a percentage) and Management would learn about it, and start measuring progress and performance based on them. Once that happened, these semi-meaningful figures would control me ...
For the distributedness, CORBA has always seemed like a good way to end up in a mess. Is it possible for you to split the computations on process borders, and maybe use ssh to distribute the work? At least for prototyping?
Damn. ;-)
Python -- Just because some college student coded a filesharing app with it doesn't make it a popular language. Nothing against the language, just that you probably won't find a job using it.
I think you're wrong. In my part of the world, Python pops up more and more often. Conversations with my colleagues often include a "oh, and for our $FOO stuff, we use Python" part. In places that are not completely Microsoft-centric, and for things that are in-house but more than a few lines of scripting glue, Python is becoming a common language.
Did somebody promote Python like that? "More fun and faster than Java, with the best parts of Perl" is more like the message I hear. And I agree with it.