Fog Creek Software
Discussion Board

Learning to program - Good idea?

I have been wanting to program for sometime.  Been reading various thing about what is going on in the industry.  I am currently a DBA of Sql Server.  I have decided to learn the 

My reasons are as follows:
1.  I know there are easier languages, but I want to learn one that has some low level details.
2.  I know there is more to the world than Windows and would like a language that is available on other platforms.
3.  I prefer to stay more towards the server side rather than client side, and I believe many components of server applications will continue to be written in C or C++ as opposed to some of the newer languages. 
4.  I thought someday I might be able to write some extended stored procedures or other things relating to my SQL Server work.

What do you think?  Is this as good a place as any to start?  Should I start with another platform with more ANSI C++?  Any thoughts are appreciated.


Ryan Ware
Saturday, April 20, 2002

I say start with a language that is easy and you will see results quickly. Python or Perl is fine. Most people give up because they get frustrated.

Saturday, April 20, 2002

The person who told you to learn Python is an idiot.

If you're already a SQL server DBA, learn to code T-SQL stored procedures (If thats what they still call it)  This is relevant you your skill set, and your existing knowledege will be leveraged as well.

Saturday, April 20, 2002

Yo Bella, you need to lighten up and quit calling people names...  I have a strong feeling you are less than 20 yrs old, considering the tone of your other posts...

John W.
Saturday, April 20, 2002

Start with Python or Perl; it's quick and easy to get results with these languages, and you won't get bogged down worrying about low-level stuff like memory management.

At some point, definitely learn some assembly (x86). You probably won't ever need to write it, but I believe it is essential to understand what high-level languages hide from you... Learn C, the lowest-common-denominator of all popular languages - it's very simple, but can get tedious for large projects. When you get frustrated with C's tedium, then move to C++...

Dan Maas
Saturday, April 20, 2002

There is no such thing as useless information.  Study what you like.

Yes, you might get frustrated with some aspects of C++ or C#, but even if you never get proficient you will still have learned something.

No guru ever took a linear path to programmer englightenment.

Saturday, April 20, 2002

I am the person who said to learn python or perl. T-SQL, as you suggest, is nothing. T-SQL is not programming and it cannot be leveraged. If you learn a language that does many things you can move to other languages that do similar things. Bella, once you get a couple years under your belt you will understand what I mean.

Saturday, April 20, 2002

The K&R C book is a good tutorial for learning how to program in C. Also "learning python" and "learning perl" are both very good tutorials. And, you could just learn T-SQL or whatever it is.  The big secret is that programming really isn't all that hard. Or perhaps I should say it isn't hard like quantum mechanics is hard, the fundamental concepts are all pretty simple. The hard part is dealing with the immense amount of random detail.

Er, and to actually answer your question...C++ .net is probably as good a place as any to start. The only thing I'd mention is that a lot of times learning that way, you are more learning how to drive visual studio IDE than you are actually learning programming concepts. But then again, knowing how to drive visual studio will probably be more useful in getting a job than actually knowing programming concepts, so ...just do whatever seems easiest. ;-)

Saturday, April 20, 2002

Just to clarify, Ryan stated that he is a SQL Server DBA, which means that he probably already knows T-SQL.  I can't imagine someone being a DBA and not knowing how to write a stored procedure.

What he said was that he could use C++ to write extended stored procedures, which aren't written in T-SQL.  Extended stored procedures are used when a stored procedure needs to communicate with something outside of the database.  I'm not sure about SQL Server 2000, but in SQL Server 7, C++ is the only language you could write them in.

Nick Hebb
Saturday, April 20, 2002

C++ is still the only language choice for stored procedures in SQL 2K.

However, there's one more factor not mentioned here yet that makes ANY .NET language a good fit for a SQL Server DBA: the next version of SQL Server ("Yukon", due out in the first half of 2003) will allow you to write stored procedures in any CLR language.

Yes, that's right: stored procedures in C++ or VB.NET or C# or ActiveWin Perl name it. They've already demoed this running to some folks.

So, Ryan, it sounds to me like C++ in the .NET environment is a good fit for your needs at this point. Go for it.

Mike Gunderloy
Sunday, April 21, 2002

A couple of counter-points to your reasons from
someone who once used to be a techno-snob and
claim that C++ was the only programming language
for real men and the true path to enlightenment.

(1) Low-level
I understand you desire for knowing how things
work under the hood, and having the ability to
be in control of the code.

However, the ability to do low-level operations
is a two-edged sword. It drains cognition power
to keep them in your head at the same time that
you're worrying about the task at hand.

The trick is to choose a language that lets you
do low-level things when you need to, but that
also do them for you when you don't want to.

Remember that there is a old adage that C does
not only allow you to shoot yourself in the foot,
but also encourage you to do it. :-)

If you don't have experience programming other
languages, you *will* find yourself wondering
why your program hangs until you realize that
you accidently overwrote the loop counter with
a array that went over it bounds. For example.

Nobody need to worry about registers and
interrupt control words unless they are making
a driver or an operating system. (Or perhaps a
database that is accessing a raw partition, but
that is borderline to an OS anyway)

I therefore never advise people to start in
*the* "lowest-level" OO language there is, but
rather to pick something a bit further up, like
C# or Java.

If you want to know how things work inside,
pick up a book on the virtual machine and use
ildasm/javap a couple of times to experiment.

(2) Portability

Simply writing programs in C++ doesn't make them
portable. Take that from somebody who has spend
time porting an application that was designed to
run on several Unices, to Windows. It is possible
to write a portable program, but it requires a
lot of thought.

There is a lot of other languages that is more
portable "out-of-the-box", due to the lack of a
requirement of them being as efficient as possible
on all platforms.

Speaking in the terms of portability, Java is
probably a better choice than C++. (but see (4))

Don't bother about the count of platforms upon
which a language is available, unless you think
you're ever going to program on the Amiga, BeOS
or OS/2. The two major families at this time is
Windows and Unix, and most likely to be so for
a foreseeable future, even on handhelds.

Managed C++ (aka C++.NET) contains a bunch of
extensions that will help create a bridge between
already existing (perhaps portable) C++ code and
the .NET framework. But anything written in the
managed C++ part will not be any more portable
than e.g. C#.

(3) Server-oriented
You don't say why you believe that C++ will be
used for server applications. Please elaborate.

I for one find it more likely that server
development will be done within the frameworks
of COM+ or J2EE, both which are based upon the
concept of managed code.

(4) Stored procedures
The nice people at Microsoft and Oracle have
decided to give us the option of writing stored
procedure in a full-blown programming language.
They do this by embedding the virtual machine
into the database engine. However, it requires
that you write *managed* code. (And I *do* know
that you can write stored procedures in an
unmanaged stored procedure as of today, but ask
yourself why people still prefer TSQL or PL/SQL
for the task)

If you restrict yourself to the managed subset
of C++, you take away all the value-added features
like templates, multiple inheritance and explicit
memory management. And you're basically left with
the downsides.

Take a look at how stored procedures in Oracle
can be written in Java. I bet that the SQL Server
solution is going to be a lot like this, even if
you're allowed to use *syntactically* different

Roland Kaufmann
Sunday, April 21, 2002

The question you probably should ask of any language is, What is the best source to learn it from?

I don't know C++, so I have no idea.  But that question certainly holds true for other languages.  In fact, great documentation is usually the best reason to learn a language, as those who swear by C or Scheme argue.

Sunday, April 21, 2002

"The big secret is that programming really isn't all that hard. Or perhaps I should say it isn't hard like quantum mechanics is hard, the fundamental concepts are all pretty simple. The hard part is dealing with the immense amount of random detail."

I find I know lots about programming concepts, but never actually do it because of exactly those reasons. I can be if I enjoy what I'm doing, but I never got into programming because I'm just not as obsessed with it as I am with other things. I can have intelligent conversations with programmers (except about things with obscure names) and have helped architect a number of programs, but as for learning programming, I write the "hello world" in any language and it just seems like too much to learn to actually get to the part where I'm doing something useful.

Sunday, April 21, 2002

Thanks for some great reply's.  I have some thinking to do.

To answer Roland:
"(3) Server-oriented
You don't say why you believe that C++ will be
used for server applications. Please elaborate."
I guess I didn't phrase that right, I meant to say I feel C or C++ will continue to be used when performance matters.  I am more interested in maybe one day writing little components to a larger peice of software.  I would prefer to let others do the UI and the bulk of the application in whatever language works best.  The components I am envisioning would be similar to what Joe talks about in regard to his work in VB and C++.  He writes C++ for peices that would be a bottleneck in VB. 

Maybe I should spend some time with C and Linux.  I am just getting idea's.  I guess I just need to jump in and play to see what I do like. 

I have taken some of my qualities as a DBA and extrapolated them to what language I would like to learn.  I like speed and performance and like to hunt down and kill bottlenecks in SQL, whether it be through solving hardware or software bottlenecks - C or C++ seems like a language to do that sort of thing.  I also want to understand the internal workings of DBMS's better.  Since I assume most are written in C or C++ that also points me to this language.  If I am off base or misinformed feel free to correct me.

Ryan Ware

Ryan Ware
Monday, April 22, 2002

I don't think anyone has pointed this out yet, but is almost an OxyMoron.  Unless I'm mistaken,  ALL .NET code is sandboxed, meaning you don't have access to the memory unless you specificly unbox a section of your code.  All of the libraries you'll be using will be .NET libraries, and so the power and "Low-levelness" of C++ will be negated because your coding it for .NET  If your going to learn C++, learn real C++. If you want to do .NET programming, use C# or VB or javascript for that matter. 

Vincent Marquez
Monday, April 22, 2002

C/C++ is probably the best choice if you need
intense performance, like in large-scale number
crunching. Or a database engine for that matter.

But most of the time you don't need that kind
of performance. I have seen benchmarks where
an MSIL program written in C# was within 10%
of a comparable native program written i C++.

Proponents of C always like to compare to VB,
because VB is known to be notoriously slow
despite having the same backend as an earlier
version of Microsoft's C++ compiler. (That is
because the frontend insert a lot of "junk"
in addition to your own code).

There is a couple of languages that I think
fill the ground in-between, like Delphi, C#
and Java. Most optimizations come from choosing
a better algorithm -- not cutting corners
(although you can squeeze the last ounce by
doing that when you've run out of good ideas)

I may however have subconsciously been
misinterpreting your intent as to *why* you
want to learn programming. I assumed you
wanted to diversify your job skills.

If the intent is to broaden your horizon, you
could indeed do something "wacky" like making
a Linux daemon or teach yourself Standard ML.
Just don't expect to cash in on that -- yet.
Profound skills do however have tendency to
make use of themselves eventually.

Please take this the right way: I am not
against using C++ per se; I just don't think
it is a good language to *start* programming
in. People who do that tends to get frustrated
by the amount of detail they will have to put
their mind to before they are able to fully
grasp existing code.

Those who start out with a "toy" language on
the other hand get bored because they don't
feel capable of writing "real" programs.
(I will probably induce a fatwa upon myself
by saying that I include VB in this group...)

So my advice was really that you should find
a decent language and teach yourself good
programming practice. Then you can start to
dig deeper. Prepare for the future, but don't
jump into it too fast.

But if you want to study other people's code,
C++ may be the way to go. Just be prepared to
wade through some really ugly stuff.

Roland Kaufmann
Monday, April 22, 2002

Don't learn Java first. It's not a bad language, but I firmly believe that it is the WORST language to learn first. The reason is this: because it does not clearly differentiate between pointers and non-pointers in the code, say, like C and C++ do with * and &. Or perl with \. I believe that this makes it more difficult to learn to do complex things in, because you don't see how things interact.

C and C++ /will/ frustrate you while learning, and if they don't, then you really should be programming an OS or something :). But they let you see what's going on. Java hides it and I've seen many many newbies confused with that. I haven't used many other languages, such as Python, so I won't comment on those.

But don't try Java first. By all means, try it. But Don't do it first.

Mike Swieton
Tuesday, April 23, 2002

Contrary to most learning text that go to great lengths to
explain the difference between 'primitive' types and classes,
I have found it better to think of them as final classes
with some syntactic sugar attached that allows you to call
their methods with inline operators. Numbers etc. can be
thought of as static members of this class (in a double
sense), so they already exists without being explicitly
initialized (by you).

The trick is to realize that these classes are immutable,
so what you get out of the operations are references to
*other* objects (i.e. other numbers etc.)

As an added bonus, the parameter passing mechanism actually
starts to make sense. :-)

Roland Kaufmann
Wednesday, April 24, 2002

*  Recent Topics

*  Fog Creek Home