TechHui

Hawaiʻi's Technology Community

http://learncodethehardway.org/

 

Zed Shaw, the guy behind Ruby's Mongrel webserver and his new Mongrel2 language agnostic webserver, has started his new "Learn C the Hard Way" series.  He also authored the "Learn Python the Hard Way" series that was well received by the public.  

Views: 221

Replies to This Discussion

Zed and Pat are the only guys I know who use zero based lists in their writing.

 

0. Buy my book

1. Write good code

2. Achieve enlightenment

 

LOL.

 

Mongrel2's architecture is definitely worthy of study.

Looks like this book has a ways to go.  I have to wonder what's going to make it into that last chapter:  Thoughts On Improving C.  Personally, I think most of what I'd improve in C has already been done in C++.  I remember an interesting chapter in Ira Pohl's book, C++ For C Programmers, that was about C++ as a better C.  If you write C++ without using classes, you get the "better C" Pohl was talking about. Two of my favorites are (a) a boolean type and (b) default values for function parameters.

@John.. interesting.  I've heard of companies and organizations that use C++ without classes.  OOP is often overused, but I thought the logical choice would be to fall back on to C.  It's hard to see any benefits of classless C++ over C because that means even the STL isn't utilized because it's highly dependant on container classes.  Exception handling maybe?  Easier memory management with new and delete?

 

I'll put Pohl's book on my list of books to read :)

Stroustrup added a number of features in addition to classes:

- Booleans

- Operator overloading

- Signals (exceptions) - According to the Google Go developers, no longer cool

- Namespaces

- Function parameter default values

- Templates (for functions as well as classes)

- Better type checking by the compiler, removal of weird implicit conversions

- Better memory management

 

That being said, I don't understand why a shop would forbid the use of classes in C++. The recent backlash against OO programming is...well...weird, although I agree with Dan N. that it can be overused by those with new OO religion. There is no question that the abstractions and modularity facilitated by OO programming are useful. I don't know how anyone can argue with concepts like encapsulation or polymorphism. At this point some functional programmer will jump in and say "deep inheritance trees introduce unnecessary complexity and make concurrency hard." Yes, well, true - so don't create deep inheritance trees for highly concurrent systems.

Sorry -- I wasn't clear.  I didn't mean an organization, or individual, should refrain from using classes.  I meant that even without classes, C++ has improvements over C. 

I recognized the advantages of OO when I took a short class on it from Bertrand Meyer, the inventor of the Eiffel language and the author of arguably the best early book written on OO:  Object Oriented Software Construction.  This was back around 1989.  I was at HP at the time working on the Openview project.  I tried to get HP to use C++ on that project rather than C, but all I was able to do was get permission to use C++ for my own code.  So I wound up writing the only C++ in the first Unix release of Openview.

Eiffel had some advantages over C++, such as much better separation of class implementation from interface definition.  But it had the disadvantage of not working well with existing C code.  You pretty much had to do the whole project in Eiffel, at least back then.  I have no idea if Eiffel has survived.

Once Microsoft adopted C++ and pretty much hijacked it, and then Apple did the same thing with Objective C, things got a lot more complicated.  It became hard to separate the core language from the corporation's development environment.

And that complication was on top of that OO religion you mentioned.

Sorry -- I wasn't clear.  I didn't mean an organization, or individual, should refrain from using classes.  I meant that even without classes, C++ has improvements over C.

Ah - Yes, absolutely true.

re: Eiffel

True. Some of those ideas made it into Java and C#. My favorite thing about Eiffel was its implementation of design by contract - preconditions and postconditions.


True. Some of those ideas made it into Java and C#. My favorite thing about Eiffel was its implementation of design by contract - preconditions and postconditions.

I never programmed in Eiffel so I never quite understood that.  The way Meyer described it in the class, he seemed to be saying that you don't waste code testing your inputs, you just specify the requirements and it's up to the caller to meet them.  I asked him about this because it sounded like he was saying to just document your input requirements in your comment header and forget about validity checking.  This sounded like madness to me.  I hope he actually meant that the compiler would generate the validity checks automatically.  Was that it?

Thats odd because Eiffel has a "require" keyword that does exactly that - checks input to a routine. If the precondition is violated an exception is thrown.

He may have been referring to the fact you can turn off assertion checking in which case the preconditions, postconditions and invariants  end up being essentially rich API documentation.

 

Thats odd because Eiffel has a "require" keyword that does exactly that - checks input to a routine. If the precondition is violated an exception is thrown.
 

That's excellent!  And I assume the postcondition does something similar:  allowing you to specify what should be considered a good output of the function.  Is that right?

 

One thing I always thought was a great idea in Eiffel was Meyer's belief that you should not have different syntax depending on whether a value was supplied by computation or storage.  That is, the syntax should be the same if you are accessing  a public member variable or using a getter function.  That way you can change the implementation later without affecting the users of a class.  That's another idea I'd like to see in C/C++.  Meyer had a lot of good ideas that seem to have been ignored by other languages.  Java, for example, simply makes it a point of style that one should always use a getter from the very beginning.

That's excellent!  And I assume the postcondition does something similar:  allowing you to specify what should be considered a good output of the function.  Is that right?

Yes. Its a bit like having language level support for unit tests. Recent versions of Java and C# have added some design by contract features (see .NET's System.Diagnostics.Contract). In Java you can BS parameter rules using dynamic proxies and annotations.

I've always thought all these C family OO languages lacked some rather obvious enhancements to programmatic safety and usability. Why can't I declare a reference type to be non-nullable? Classes would either use a default constructor or a null object pattern. For that matter, why isn't non-nullable the default? Think how much safer programs would be if you virtually eradicated the much hated NullPointerException.

One thing I always thought was a great idea in Eiffel was Meyer's belief that you should not have different syntax depending on whether a value was supplied by computation or storage.  That is, the syntax should be the same if you are accessing  a public member variable or using a getter function.

Groovy gives you this verbatim. In C# getters and setters largely solve this problem. You can trivially declare a property: string Name { set; get; } and provide logic within the setter or getter at a later time. This would be accessed just like an instance variable (i.e. person.Name).

RSS

Sponsors

web design, web development, localization

© 2024   Created by Daniel Leuck.   Powered by

Badges  |  Report an Issue  |  Terms of Service