On Tuesday, November 17, 2015 at 10:34:03 PM UTC+10, Mauro wrote: > > Julia tries, and I think succeeds, in solving the two language problem. > The two language problem being that one uses one language for most > things but drops down to a fast language for bottlenecks and/or one > language to prototype one for production. > > This means that Julia has to cater to a wide range of programming style > and tastes: ranging from a throw-away script to big application code. > To pick up the not-integer-indexing example: this is probably in the > "throw-away-script" category. It seems it has been deemed too much so, > thus support was removed. In my big-application-code, I'd certainly > want not-integer-indexing to error. > > Note that this goes the other way too: people hoping for a more strict > approach, presumably to make big-application-code more maintainable (see > e.g. this thread discussing private-functions of modules: > https://groups.google.com/d/msg/julia-users/by3y9JEMra8/9xqvoy_xd6YJ) > > I think, the devs have found good middle ground in their design of Julia > so far. As Julia is evolving, discussions on these topics are important > (although not at infinitum...). >
Mauro, Nicely put, and note that Julia allows for this wide range of features by allowing features that are defined in packages to have the same "first class" capabilities and performance as built-in features. Those who have a need for real indexing are able to define a package providing the feature without any penalty just because it isn't "built-in", and in this case there is even an existing template for the package in the deprecated code. Cheers Lex > > Mauro > > On Tue, 2015-11-17 at 12:14, Christoph Ortner <[email protected] > <javascript:>> wrote: > > Hi Peter, > > > > I've had multiple discussions along similar lines over the past year, > since > > I started coding in Julia. I think I lost every single argument. > > Personally, I think you are right and I think this is an important > issue. > > However, Julia is open source, so the decisions are made by those who > > develop the language. They are naturally strong computer scientists and > > have different priorities from us. > > > > I'd love to contribute to developing Julia, but I simply don't have the > > time for it. It is just a question of priority: (1) I care enough to > make > > that time - at considerable expense to my research and family life; (2) > I > > just go with the flow and adapt. (3) I sigh wistfully and go back to > Matlab > > which it seems might start catching up again on performance. > > > > For now, I've gone with (2), but a lot will depend on how the language > > continues to develop. I agree with your sentiment that > >> Indeed, sometimes I feel as if I might as well be coding in C. > > Only *sometimes*, however, these sometimes can get very frustrating. > > > > All the best, > > Christoph >
