vitaut

A pub

I've used a lot of RST and from my experience the specification is very accurate. If there is some inconsistency, it should probably be considered as a bug and reported to Python docutils. What exactly is the problem with bullet lists? AFAICS they are pretty much the same in Markdown and RST.

I don't think there is anything in RST that encourages deep nesting level or verbose markup, on the contrary with default roles it can be more compact than Markdown. If you look at good documentation examples, like The Python Standard Library documentation (https://docs.python.org/3/library/index.html), nesting is very limited and the documentation source is very clean and readable.

Just to add, the book "AMPL: A Modeling Language for Mathematical Programming" by Robert Fourer, David M. Gay, and Brian W. Kernighan (yes, the "K" in K&R) is also freely available online: http://ampl.com/resources/the-ampl-book/chapter-downloads/ . It is not only a reference for the AMPL modeling language, but also a great introduction to mathematical optimization.

People outside of this field are often confused by this. That's why the term "mathematical optimization" is often used instead of "mathematical programming" nowadays.

Mathematical programming (optimization) has so many useful applications and I am very pleased to see this classical book on the topic available online.

Unfortunately because it has been written a while ago it doesn't cover algebraic modeling languages and examples are in Excel which is not an adequate optimization or teaching tool (even XKCD has something to say about it in his webcomic https://xkcd.com/1667/).

> Are we talking about a data scientist performing initial, exploratory analysis on a very small subset of data?

Yes, that's one example. Also when debugging one usually uses small data sets. There are plenty of cases where runtime is short.

I think the problem is that Julia is somewhat vague on how it should be used. If it stated explicitly that it is intended to be used in MATLAB-like fashion with one long-running instance that would save people from trying to use it as Python or other dynamic language.

Regarding the slowdown in development, perhaps it's a seasonal variation connected to GSoC. For example, notice a drop in postings since October in https://groups.google.com/forum/#!aboutgroup/julia-dev . This seems to be more or less consistent with the observation in http://www.davideaversa.it/2015/12/the-most-promising-langua..., but that's just a guess.

That routine is part of the C runtime which is used in Julia too, so it doesn't cause any difference.

Thanks, this looks better. I'll need to update the post.

> what scenario are you imagining where startup times would be a significant concern?

Starting a REPL or running a computation that doesn't take long time, adjusting parameters, re-running. Startup time may not be too big in absolute numbers but it's noticeable and adds up quickly especially if you start using more packages rather than toy programs that I used as an example.

The current Julia version is 0.4.5 =).

Go has a set of completely different issues but that's a topic for another post =).

This is actually a good point, but what about Unicode? Will `(UTF8String, Float64)` emit another function?

__sprintf_chk is shared between all calls to sprintf which is not true for Julia.

Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =).

The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd definitely like to see more influence of the first two and less from the last one.

I wouldn't be bothered about it either if the language, like Java, targeted more the development of long-running services rather than interactive applications (with some exceptions like mobile). But as far as I can see it is advertised for use in interactive applications, possibly as a Python alternative, where responsiveness is important.

Also C++ has Python-like formatting: https://github.com/fmtlib/fmt. Disclaimer: I'm the author of this library.

Since so many people obviously need this functionality, I've created a reusable Python version here: https://github.com/vitaut/neverhappen

Skype reliability has deteriorated considerably over the years. We have switched over to Google Hangouts which is more reliable and has better video quality.

Thanks for the suggestions. There has been some work to make formatting more customizable (https://github.com/cppformat/cppformat/issues/235). This will enable extensions like the ones you suggest while keeping the library itself lean. Generally useful extensions like thousand separators can be added to the core library of course. They are actually on my TODO list.

It's a bit sad that the formatting API hasn't improved in C over the years. Take this code, for example:

  printf("Local number: %" PRIdPTR "\n\n", someIntPtr);

which is quite unreadable to say the least. To address this issue I even wrote a small library (https://github.com/cppformat/cppformat) that allows you to write something like this instead:

  print("Local number: {}\n\n", someIntPtr);

It is written in C++ rather than C, because the latter doesn't have facilities (at least overloading is necessary) to implement such library.

Pretty sure that it's not intentional by the look of the waves that go through the side of the boat.

Looks very nice apart from some minor details like water going through the boat. And runs very smoothly on my old Linux laptop with a built-in graphics card.

It would be great if it was specified whether each library works offline for comparison. For example, Google Charts don't work offline.

> The C pitfalls you listed are easily avoided using C++ builtins like std::shared_ptr, templates, the STL, and the rest of the C++ standard library.

That was exactly my point.

> And I'd have to strongly disagree.

OK, let's agree to disagree.

> Well, if I use libraries to avoid C's pitfalls, that language will be safe, too.

I'm not talking about possibilities, but about libraries that are actually available and widely used.

> You might as well say the key to using C++ is to use Python or C instead.

And that might not be a bad idea. If you don't need the power of C++ or don't want to invest time in learning it, then you are better off using a simpler language such as Python, but probably not C for the reasons I pointed out earlier.

C++ is a complicated language, so I agree with your advice of using good learning resources and code review. I don't agree that the issues you mentioned are of the same level as the ones I was talking about. Missing a copy constructor is just not as big of a problem as, say, getting a segfault caused by misuse of varargs.

I don't always write dangerous code, but when I do I fully realize it =). And it has nothing to do with any of the features that you listed.

In fact "threading" in C++ is safer because of the availability of high-quality libraries providing task-based parallelism such as TBB, move semantics is used all the time in C albeit manually with pointer manipulation. It is true that not all of the features play well together, but it's nothing compared to the C pitfalls that I mentioned.

If you want to avoid dangerous interactions, don't overengineer your code, stick to the features you understand. This is true not only for C++, but for any language.

I wouldn't call it a pitfall. Boost is written by C++ experts who like to push the boundaries of what can be done with the language. This doesn't mean that you have to debug their code or overuse templates yourself and there is nothing in the language that encourage this. For common cases such as in the standard library, templates are pretty easy to use and trivial to debug with modern compilers.

With great power comes great responsibility.