https://github.com/MatlabCompat/MatlabCompat.jl
On Wed, Apr 29, 2015 at 3:10 PM, Simon Danisch <[email protected]> wrote: > I haven't read the full discussion, but I think there is a very elegant > solution for these problems (pretty sure it has been mentioned somewhere). > Just internally use very Julian functions which make the best of multiple > dispatch and non abbreviated names. > Then just define a compatibility package, which defines the short, > un-Julian names, which than call the Julian functions. > I think there have been voices for a Matlab compatibility package before ;) > Emancipation from Matlab while coming up with an own, consistent naming > convention, without annoying people coming from Matlab seems to be very > desirable > We just need a hero to create some PRs to make this happen ;) > > Am Samstag, 25. April 2015 12:43:44 UTC+2 schrieb François Fayard: >> >> Hi, >> >> I would like to talk about naming convention. I think it's fine to have >> short names in a langage with few keywords such as C (memcpy), but a >> langage such as Julia that wants to be also high level with a huge standard >> library needs convention because the langage might become very large. I >> find the convention used by Mathematica the best ever made. Nothing is >> shortened except a few exceptions and consistent use of CamlCase. On the >> other hand, Matlab is probably one of the worst thing that happen in terms >> of naming: no consistency at all! I suspect that Cleve Moler who started >> Matlab not used LAPACK but also the Fortran 77 naming convention which was >> only there only for technical reasons ;-) >> >> I've seen that the naming convention for function in Julia looks like the >> same as in Python: everything must be lowercase, and don't use underscore. >> Let's look at different naming conventions, the first one being the one >> used by Julia. >> >> 1) daysinmonth() >> 2) daysInMonth() >> 3) days_in_month() >> >> I find the first one the most difficult to read. I tend to prefer the >> last one, but the second one is also easy to read. The fact that Julia uses >> the first one and the fact that many names are shortened, makes reading >> code with functions you've never seen a pain. For instance reading a name >> "iso..." my mind does not understand if we at talking about a function that >> returns a Bool ("is" suggests that) or something that has been standardised >> (ISO). Using the second naming convention would make things easier. Also it >> would prevent people using underscores as we have in the standard library >> without any clear reason. >> >> I don't find any disadvantage for the second naming convention over the >> first one. So why do people use the first one? >> >> >> >> >> >> >> >>
