Plus he will be able to use F# easily since it is derived from OCaml.
Replacing Python
41–50 of 144 posts
Re: Replacing Python
#42I find it suspicious that Java or Scala didn't make the list. Java may not be sexy but it checks many boxes... And I suspect that Scala would have been a serious contender in brevity too.
If I need to install the JVM just to try your software, then it's going to remain untried - however many design patterns you've managed to cram into it.
Re: Replacing Python
#43I think the important insight from these articles is not which language the author ends up using (OCaml[1]), but rather which languages he's managed to rule out by now. In particular, I think it's good advice to avoid both ATS (however much I like dependent types) and Go, both for completely different reasons. You probably wouldn't want to use Rust in the short term either. [1]: http://roscidus.com/blog/blog/2013/09/…
Can you think of some niches/circumstances where ATS might be worth using? EDIT: might it be possible to develop ATS programs that are easily called from other languages? ATS seems to have strong ties to C, so maybe one could call ATS code like one calls C code, or call C code that is a thin wrapper around the ATS code? Then you hopefully could have efficient, statically verified (to a high degree) code that can be u…
I've always thought it would be a perfect language for things like aerospace. NASA, for example, uses unsafe languages like C and compensates for that with extremely rigorous processes. Of course, this means that it takes forever to get anything done.
I can't help thinking that using a better tool like ATS would actually increase productivity without compensating safety. If anything, the types would provide an extra sanity check! Of course, just using ATS won't be enough--most of the existing checks and reviews will still be necessary, but I do think it would be some improvement.
Re: Replacing Python
#44I think the important insight from these articles is not which language the author ends up using (OCaml[1]), but rather which languages he's managed to rule out by now. In particular, I think it's good advice to avoid both ATS (however much I like dependent types) and Go, both for completely different reasons. You probably wouldn't want to use Rust in the short term either. [1]: http://roscidus.com/blog/blog/2013/09/…
> So it seems extremely shortsighted to choose a language because it's easy to learn and similar to what you already know! But the benefits are that many new people will be able to pick it up quickly and easily. Other people's code will be easy to understand and maintain. So it's good for everyone in the long run. Being able to express complicated ideas in simple ways is very valuable. If you think it's an advantage…
In other words, Go is yet another "lowest common denominator"language,a spiritual successor to Java.
If you're not working with the lowest common denominator, Go is not for you.
Re: Replacing Python
#45Earlier quoted context omitted.
>The reason seems to be that programmers use the expressivity of the former (which seems to be of a particular nature or natures: functional construct, higher-order types, meta-programming) to model their own thought-process, which may be hard to replicate for someone else maintaining the code. I agree with that. Working on code in a large and ever changing team is very difficult, and it seems to benefit from less ab…
Wouldn't it be better to avoid calling the V() default constructor every time the function is called? You never know, it might have some long-winded side effect... template R defaulted(const V& val, const R& default_val) { const static V v0; return val == v0 ? default_val : val; }
There was a time (before C++11) when not even local static variable initialization was guaranteed to be thread safe. And there are a few other reasons why it is discouraged: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
So it's basically defensive programming, but I agree with you that it's probably too defensive nowadays.
Re: Replacing Python
#46Perhaps the title should be "Why Python is good enough." Between this post and the preceding one ( http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... ), the takeaway for me is that the author didn't find sufficient benefit in any of the candidate languages to justify switching an existing product--perhaps not even a new product. It's true that Python can leave you with hidden crash bugs in unusual code p…
The other thing is his only complaint (slowness) isn't really a problem. If you have a critical hot spot in your server code, extract it, implement it in C / C++, and use ctypes to call it.
Re: Replacing Python
#47Anybody knows or have any reasonable guesses when Rust will be ready?
I hope some time next year, but see recent discussion of it at https://news.ycombinator.com/item?id=6454455.
Re: Replacing Python
#48I find it suspicious that Java or Scala didn't make the list. Java may not be sexy but it checks many boxes... And I suspect that Scala would have been a serious contender in brevity too.
C# was excluded for being too slow to start. JVM-based languages would not fare any better.
I can't say I've had that problem myself. They are quite startup heavy but typical c# console apps start up on an ssd based system in ~150ms and 700ms on rust disks.
If you're calling something thousands of times, fast process startup times are good. This isn't the model windows uses though which is the primary target of c#.
Re: Replacing Python
#49The first Python example throws up a big red flag: manually parsing command line arguments instead of using argparse. Why reinvent the wheel when there is a standard library to handle it? Likewise, asserting that "For storing general records, Python provides a choice of classes and tuples" completely ignores one of Python's fastest and most powerful data types: dictionaries. Lastly, in get_value, the nest of ifs is u…
Over the last decade, there's probably been half a dozen "standard" command line parsing tools. getopt being the classic, then we had optparse and that got deprecated, then we got argparse. And there there's e.g. twisted.usage and the pretty cool docopt.
In this case the author wants to parse "program [optional args]" and does that in a few lines of code. You seriously think that's a "big red flag" ?
Do you also believe the author does not (despite having created the zero install tool 10 years ago) know Python has dictionaries?
This is a blog post where the author evaluates a number of languages/environment to replace his particular Python needs -- do you think that him not using a new standard library module invalidates his finding?
Re: Replacing Python
#50I find it suspicious that Java or Scala didn't make the list. Java may not be sexy but it checks many boxes... And I suspect that Scala would have been a serious contender in brevity too.
If I need to install the JVM just to try your software, then it's going to remain untried - however many design patterns you've managed to cram into it.
Why, because the JVM is too big?