Have you ever restricted yourself to using a subset of language features?

I plan to be in the upcoming weeks as I port Lua over to the DLR.

Lotus IBM introduced the getAllEntriesByKey method of the NotesView class in LotusScript R5, I didn't really start using it through unfamiliarity until a couple of years ago, now its a staple part of my programming as an alternative to getAllDocumentsByKey.

There is nothing wrong with getAllDocumentsByKey and I use it all the time but if the view your looking at has hundreds or even thousands of records (documents to a Notes Developer) then scanning the collection you get back can be very slow. If however the document value is a view column entry then scanning the viewEntryCollection you get back from getAllEntriuesByKey is way faster, doesn't make the older code wrong or even unusable, you just need to know when to use each one.

Last week I recoded a process that had to iterate through a collection that turned out could contain anywhere between 0 and 22,000 entries, for 200 records it took 60 seconds to run. The new code finished in 2 seconds (I added temporary timing code) and more importantly took the same amount of time for 500 documents, its a major win for ten minutes of work including unit testing. The method was was available to the developers years ago when they wrote the sub, but they either didn't know about it or more likely had no confidence/ did not understand the performance implications.

We can only use what we are familiar with and have confidence in. The more development work you do the more likely it is that you will widen your experience and be able to use more features of a language to deliver quality software to your customers.

We use XSLT heavily for many of our components. Most of the components are old) uses old parsers, which does not support XSLT 2.0, so we are still using XSLT 1.0 functions even though XSLT 2.0 provides many good functions.

In Verilog and VHDL (programming languages used to design chips), we always have to use the subsets that are "synthesizable" when designing the chip. The whole language can be used for test benches (unit tests).

While not strictly a "language feature" - one construct I avoid in C# is lock(this)

It's a leading cause of deadlock conditions in multi-threaded code since anyone can lock on the same reference.