You are here

Pages

So today, after 6+ years of PHP and ~2 years of C++ and 1+ year of vb6, I've started learning Python...

And I'm having a blast!

As someone that's recently spent time learning C# and ASP.net, it's really great to find the entry level door that everyone can fit through. Even if it is for a language that takes me back to the glory days of learning programming in Turbo Pascal on the 286's in high school. Actually, that's looking to be my preferred method now

Truly, it's amazing how a good book (that's free) can aid in the process. As a seasoned programmer, it's nice to work with simple programs to learn to use a language instead of trying to make sure I get through the tons of information about data types and all the other little details and just get into the meat of it.

Sure, this book might be aimed at people who haven't programmed before, but as someone that has done a lot of PHP and has spend enough time learning other languages, it's been a very liberating change.

Today is one of those days that has reminded me of how much fun programming can be. Sometimes, keeping it simple keeps it fun

So, if you had any desire to ever learn how to program, this is where I would usher you off to Invent With Python.com and tell you that you have absolutely no excuse.

And if you are a programmer, when was the last time you actually remember smiling while writing code? C'mon! Share!

"You're right, I should never argue The IT Crowd with you. You can be Moss, and I'll be Roy." - Bonus_Eruptus | trueheart78.com | Pile.Ninja: trueheart78

Anyone know of a good e-book on Django? A book on doing REST wih Django? I'm in Hawaii currently. I have a long trip home (the trip was purchased on points) and I have a job interview next week for a job doing Python. I know Python, but I haven't used it since my last job. A year. Since then I've been working on a web service in my spare time (a startup project) using PHP. I figured on the way home I'd rewrite it in Django/Python, but need to download a good e-book to reference on the plane. Any ideas?

Anyone know of a good e-book on Django? A book on doing REST wih Django? I'm in Hawaii currently. I have a long trip home (the trip was purchased on points) and I have a job interview next week for a job doing Python. I know Python, but I haven't used it since my last job. A year. Since then I've been working on a web service in my spare time (a startup project) using PHP. I figured on the way home I'd rewrite it in Django/Python, but need to download a good e-book to reference on the plane. Any ideas?

"Fine. Take her out to lunch and then at an opportune lull in the conversation poke your finger directly in her anus. Chances are she'll leave you alone after that. If not, hey buttsex!" - ColdForged
========
EVE - Promethean Starter/Persephone Starter

Just gotta be careful with the way the * is parsed, which is why some prefer to have it aligned with the variable instead of the type to make it clearer in this case. I prefer to align it with the type and just avoid writing mixed declarations on one line.

It fits with the way I read and think about the code. I view it primarily as an "int pointer", not as an int at the other end of a pointer, so it makes sense to consider it part of the type from that point of view.

A lot of more old skool C hacker types (who still use Kernigan and Ritchie style) like to put it with the instance name. With C++, I like to have the various types all clearly set out (for when I have to cast them or whatever), so I prefer to keep it with the type.

Also, constructions like int *foo, *bar; aren't initialising the variables, so I'd prefer to have them on separate lines and initialised in any way.

I also prefer const int* rather than int const *, just so I can distinguish const int * const, int* const, and const int* easily.

Honestly I just say screw it and don't do multiple variable declarations on one line. You'd be surprised how much more readable the code is this way, and honestly it rarely saves enough space to matter (as if LOC matters anymore, don't fill up your 10MB hard drive!)

The conceit behind C's declaration syntax is that the declaration mirrors the syntax for using the declared symbol. Given "foo" above, saying "*foo" will yield an int (the type of the declaration). This explains why the syntax for declaring a function pointer is so weird:

int *(*f)(double, char*);

There we have a function pointer to a function which accepts a double and a char*, and returns an int*.

This also gives us the array declaration syntax:

int *arr[20];

There we have an array of 20 pointers. The only really confusing part here is remembering whether prefix or postfix unary operators have precedence. (Postfix operators do.)

Anyway. In this broader context, aligning the asterisk with the identifier makes a great deal of sense.

The awesome part is that 'const' can be placed before or after the symbol, with occasionally different results. Just the other day I had to write "char const * const &" to satisfy a template function specialization. C++ is powerful, but the syntax could be better. For example, it's often necessary to inject "typename" in template type names just to tell the compiler that something is actually a type name. Worse, typedef doesn't help. For example:

The conceit behind C's declaration syntax is that the declaration mirrors the syntax for using the declared symbol. Given "foo" above, saying "*foo" will yield an int (the type of the declaration). This explains why the syntax for declaring a function pointer is so weird:

int *(*f)(double, char*);

There we have a function pointer to a function which accepts a double and a char*, and returns an int*.

This also gives us the array declaration syntax:

int *arr[20];

There we have an array of 20 pointers. The only really confusing part here is remembering whether prefix or postfix unary operators have precedence. (Postfix operators do.)

Anyway. In this broader context, aligning the asterisk with the identifier makes a great deal of sense.

In C++ I'm primarily concerned with the types of instances. The type of foo is int*, so in the sense that I am declaring a instance of a "pointer to an int" called "foo" I want it spaced that way. I regard most of the newbie mistakes in using pointers (e.g. not allocating them) as stemming from the int *foo style, which really only makes sense when you're stacking them up on a line.

Whereas I would regard that function pointer as being more clearly defined as

int* (*f)(double, char*);

rather than putting the two asterisks together. This way the asterisk for the return type (int*) and the one for the function pointer are grouped with the element they're referring to.

The compiler doesn't care about all of this, but I like to use a syntax that helps me know what type everything is everywhere.

complexmath wrote:

The awesome part is that 'const' can be placed before or after the symbol, with occasionally different results. Just the other day I had to write "char const * const &" to satisfy a template function specialization. C++ is powerful, but the syntax could be better. For example, it's often necessary to inject "typename" in template type names just to tell the compiler that something is actually a type name. Worse, typedef doesn't help. For example:

That's a facet of how C++ deals with template ambiguity. If you have a templated function on T, then T::f(a) could be calling a function f or initialising an instance T::f. So it makes you put typename in. I agree that typedef should be able to resolve it since the syntax dictates that only a type could go immediately after the typename keyword, but since it's inherited from C I guess they can't change the compiler syntax for it.

In C++ I'm primarily concerned with the types of instances. The type of foo is int*, so in the sense that I am declaring a instance of a "pointer to an int" called "foo" I want it spaced that way. I regard most of the newbie mistakes in using pointers (e.g. not allocating them) as stemming from the int *foo style, which really only makes sense when you're stacking them up on a line.

Later languages which are influenced by C's syntax agree with you. In D, for instance, the following declares two pointers:

int* a, b;

Go's declaration syntax is backwards compared to C, but is otherwise derived from it. The following declares two pointers:

var a, b *int

DudleySmith wrote:

complexmath wrote:

The awesome part is that 'const' can be placed before or after the symbol, with occasionally different results. Just the other day I had to write "char const * const &" to satisfy a template function specialization. C++ is powerful, but the syntax could be better. For example, it's often necessary to inject "typename" in template type names just to tell the compiler that something is actually a type name. Worse, typedef doesn't help. For example:

That's a facet of how C++ deals with template ambiguity. If you have a templated function on T, then T::f(a) could be calling a function f or initialising an instance T::f. So it makes you put typename in. I agree that typedef should be able to resolve it since the syntax dictates that only a type could go immediately after the typename keyword, but since it's inherited from C I guess they can't change the compiler syntax for it.

This is basically a consequence of how tortured the C++ grammar is. It is very telling that D's templates manage to avoid this ambiguity entirely. The following is basically equivalent to the C++ code above, except (as D doesn't have a precise equivalent to C++'s iterators) using a fictional templated type "foo" with an inner type "bar".

The awesome part is that 'const' can be placed before or after the symbol, with occasionally different results. Just the other day I had to write "char const * const &" to satisfy a template function specialization. C++ is powerful, but the syntax could be better. For example, it's often necessary to inject "typename" in template type names just to tell the compiler that something is actually a type name. Worse, typedef doesn't help. For example:

That's a facet of how C++ deals with template ambiguity. If you have a templated function on T, then T::f(a) could be calling a function f or initialising an instance T::f. So it makes you put typename in. I agree that typedef should be able to resolve it since the syntax dictates that only a type could go immediately after the typename keyword, but since it's inherited from C I guess they can't change the compiler syntax for it.

That reminds me of "C++'s most vexing parse," which is another huge issue. My point was simply that the syntax for C++ has a number of warts that, I suspect, are a result of the syntax being designed by people who don't write compilers and therefore didn't think of the ambiguities at the time. As MightyMooquack points out, these problems aren't intrinsic to what's actually being done, but more an issue of the specific C++ syntax for doing so.

That reminds me of "C++'s most vexing parse," which is another huge issue. My point was simply that the syntax for C++ has a number of warts that, I suspect, are a result of the syntax being designed by people who don't write compilers and therefore didn't think of the ambiguities at the time. As MightyMooquack points out, these problems aren't intrinsic to what's actually being done, but more an issue of the specific C++ syntax for doing so.

I don't know which compiler you're using (Microsoft, maybe?) but gcc allows you to typedef iterator types without inserting the typename keyword. That construct is all over our code. As I said, I don't typedef iterators very often myself, so I wasn't sure.

The gotchas and nasties in the C++ syntax are not due to the people who wrote it not knowing about compilers, but due to it needing to be back-compatible with C syntax, and being unable to properly escape from them without breaking the back-compatibility.

Since programming is a job and not a hobby any more for me, I've probably lost a lot of the joy I had when I programmed my Spectrum 25 years ago. Learning the shiny new language is not time-effective for me until such time as it makes commercial sense. I've got nothing against D (there are some languages that I regard as worthless academic wanking), but it is still pretty niche. I don't honestly see it taking off, since it isn't better enough than C++ to supplant it in industry. If you know how to write it properly, C++ is still the way you'd get a sizeable team to develop a large real-time embedded system.

I've been spending some spare cycles teaching myself Erlang, which has been a lot of fun and smiles. There are some posts on my blog about when I was first getting into it. I love the syntax and the philosophy behind it, although the dynamic typing is annoying at times.
I've started work on a really sh*tty telnet mud in it and that's been fun, but time consuming.
I've never learned Python, but a lot of my co workers love it, on the to do list.

"We are not afraid to follow truth wherever it may lead, nor to tolerate any error so long as reason is left free to combat it." - Thomas Jefferson

I don't know which compiler you're using (Microsoft, maybe?) but gcc allows you to typedef iterator types without inserting the typename keyword. That construct is all over our code. As I said, I don't typedef iterators very often myself, so I wasn't sure.

The gotchas and nasties in the C++ syntax are not due to the people who wrote it not knowing about compilers, but due to it needing to be back-compatible with C syntax, and being unable to properly escape from them without breaking the back-compatibility.

I'm using gcc. Try the code I pasted and see. Dependent template type definitions pretty much always need a 'typename' added. Just using "vector::iterator" will do it. And I disagree about C compatibility in this case. They could have chosen a different syntax for type initialization that didn't cause the parsing ambiguity, chose different template typelist markers that didn't cause that ambiguity, etc, and still been C-compatible. There are other examples of decisions that might have been different if those involved had more experience writing compilers, such as exported templates. Now, there are a bunch of compiler folks in the committee--the EDG folks, Bjarne (obviously, etc)--but design by committee is a tricky thing.

I've been spending some spare cycles teaching myself Erlang, which has been a lot of fun and smiles. There are some posts on my blog about when I was first getting into it. I love the syntax and the philosophy behind it, although the dynamic typing is annoying at times.
I've started work on a really sh*tty telnet mud in it and that's been fun, but time consuming.
I've never learned Python, but a lot of my co workers love it, on the to do list.

Found any good resources for getting started with Erlang? That's on my short list of languages to learn.

Quintin_Stone: Nice looking c*ck you got there, dimmerswitch.
BadKen: So what you're saying is that cops can look at my dick pics without a warrant.
*Legion*: my right hand spent most of those early-teen years in that grip position