Andrei Alexandrescu Wrote: > Michel Fortin wrote: > > On 2010-02-19 09:11:11 -0500, Andrei Alexandrescu > > <seewebsiteforem...@erdani.org> said: > > > >> If you could provide a list of silly named symbols that could be a > >> dealbreaker for a prospective D user, please let me know. Thanks. > > > > I don't think there are really any 'silly' names (except perhaps iota), > > it's just that many don't do exactly what you think they do on first > > reading. > > The lengthy post below talks about _one_. If there are "many", you > should be able to effortlessly list a handful. > > > For instance, the other day I was working with input ranges and > > needed a way to take N elements from the range and put them aside to > > work on them later. So I defined my own function "take" for that. > > > > To me, "take" means you take one or more element and they aren't in the > > range anymore afterwards. > > > > If you look at std.range, you'll find the same function 'take', but it > > does its job lazily. That's great, except when you don't expect it. > > I'd contend that _you_ don't expect it. Others may as well think it's > not copying, otherwise it'd be called "takeCopy" or "setAside". > > At the end of the day you can't expect to fly blind through an entire > library. "take" could be defined with a number of arguably good > semantics. Phobos picked one. (By the way per popular request I reversed > the order of arguments such that method notation works.) > > > Andrei
I think Michel raised a good point and Kenny did provide a list in a different post. I think that having lists of function names that people here don't like is silly and not productive. IMO, the problem is not in the names themselves but rather it's a bigger picture issue of lack of consistency and strict naming scheme for phobos. let's take a look at popular language that are widely used: they all have very detailed schemes which make it easier to start using the language right away which makes it easier to adopt. you _can_ look at e.g. Ruby code and have a general understanding what the code does without reading the docs. The fact of the matter is that programmers do expect to be able to get as much information as possible from the code itself before going to the docs. RTFM simply won't do. you think managers care about the code? you think they want to spend time on their programmers reading TDPL? of course not. They want the job done as quickly as possible. D is counter productive for that ATM.
