Usually the use prerequisite situation is "this script processes strings and is getting too big and unwieldy for bash"
Ask HN: When has switching the language/framework made an important difference?
101–110 of 152 posts
Re: Ask HN: When has switching the language/framework made an important difference?
#102Yes, switching something heavy on cpu (mostly real mathy computations) from python 2 to Go - we could keep working eith current number of CPU cores/boxes and not having to like, double our expenses.
Re: Ask HN: When has switching the language/framework made an important difference?
#103Earlier quoted context omitted.
Like what?
Julia, C++ with libraries, Python with Cython or Numba, etc. You could also get much faster if most of your work is matrix multiplication if you make use of libraries like ViennaCL and a modern C++ compiler.
Julia is regarded as the modern replacement for Fortran, but it isn't quite there yet.
The major problem with Fortran is that there is (sadly) nearly no documentation on modern idioms, and occasionally you have to dive in legacy code, which can be... scary, to say the least. Otherwise, it was upgraded really well, without losing performance.
Re: Ask HN: When has switching the language/framework made an important difference?
#104Earlier quoted context omitted.
> The guy who wrote it thought it would be great to optimize the code in some ways, but clearly overdid it. But then I suppose a rewrite would undo those optimizations and solve the problems.
Well, that is as long as we don't introduce other leaks in the rewrite. Our team is mostly made of mathematicians and business-focused engineers, so for us C++ was somewhat inappropriate. My point is trading a little bit of performance for a lot of clarity and safety was a good move.
Re: Ask HN: When has switching the language/framework made an important difference?
#105Earlier quoted context omitted.
I'm guessing that moving from C++ to C++ (i.e., a rewrite in the same language) would also have helped a lot.
Actually that particular C++ was very well written. It had been written by a single very disciplined person over 3 years, following a lot of very strict conventions. So, no it was not really messy in there. But it was big and memory leaks are hard to find. The main problem is that there was some low level funky stuff happening that we didn't have a good grip on. The guy who wrote it thought it would be great to optim…
> The guy who wrote it thought it would be great to optimize the code in some ways, but clearly overdid it.
I feel that C++ is a language that entices decent developers to try and 'optimise'. We have the same issue in some of our lower level stuff including pointer arithmetic and other 'optimisations' that might have saved a couple of kb/mb of memory 20 years ago when the code was written but today only makes the code difficult to read and to modify.
Re: Ask HN: When has switching the language/framework made an important difference?
#106Earlier quoted context omitted.
The problem of old languages like perl and Ada is not lack of libraries, but lack of good developers that know how to write idiomatic code. Performing caching at the application level is so trivial in Perl that I do not see how a caching at ORM level could give any benefit.
> I do not see how a caching at ORM level could give any benefit. I don't know anything about the Python libraries as such but if they implement pluggable modules like memcache, redis, SysV SHM, etc., for the caching, then you can chop and change as required without having to make any application level changes[1]. Which is also handy for testing because you can supply your own mock cache module to do ... whatever. [1…
I strongly disagree: I'd rather debug something wrong with the lone application level change which added the cache support at the application level, rather than have to enter the long and deep rabbit hole of the path the code takes at the point I ask for a resultset and I get something from the DB-backed ORM, or from a global memcache, or blah.
But then again, I happily develop on mostly-Perl codebase(s) ;)
Re: Ask HN: When has switching the language/framework made an important difference?
#107Well I'll provide a somewhat different story where the lack of change has caused quite a loss in productivity. At my current employer's a big part of the codebase is in Perl and the boss is a fan of the language, so we keep using it. The problem is, Perl is pretty much dead, and most of the packages out there on CPAN feel like they've been built 10 years ago. Not to mention, the language itself lacks what I would cal…
The problem of old languages like perl and Ada is not lack of libraries, but lack of good developers that know how to write idiomatic code. Performing caching at the application level is so trivial in Perl that I do not see how a caching at ORM level could give any benefit.
… and they're getting fewer and fewer by the year, at least for Perl :|
Re: Ask HN: When has switching the language/framework made an important difference?
#108https://github.com/Microsoft/visualfsharp/issues/2766#issuec...
Re: Ask HN: When has switching the language/framework made an important difference?
#109We're starting to develop greenfield APIs in Scala (with Play) rather than PHP (with Laravel) and we've noticed new developers without experience in either language have a surprisingly similar time-to-productivity. Here are some major factors: PHP's dynamic typing combined with Laravel's magical approach makes discoverability hard. A developer can't trace through a request by starting from a controller method and nav…
Thanks for posting that. Where would a PHP programmer go to get a foothold in Scala web development?
We began working with Scala very slowly, only using it for small internal projects until we were more familiar with the language and stack.
We also avoided heading too deep into category theory territory in the beginning. Libraries like Cats and Scalaz are not allowed (currently).
Re: Ask HN: When has switching the language/framework made an important difference?
#110Earlier quoted context omitted.
Fortran is an excellent language. I enjoy the fact that people think it's too old and/or difficult to learn, because neither of those are true. It's a great fit especially when the problem domain is heavily numerical in nature.
My big problem with Fortran is finding a modern tutorial written for an audience that doesn't already know some previous version of Fortran.
One of the disadvantages of Fortran is that it caters to a very non-sexy segment of the programming population, by that I mean that UX/UI is not of great concern - a lot of learning materials I come across reflect that. Unless you find a textbook, you'll probably end up looking through undergraduate/graduate engineering lectures, or some presentation from a national lab (see below).
First question, do you have access to a compiler? On all Linux distros I'm aware of, you can get the gnu fortran compiler fairly easily (some variation of gcc-fortran, gfortran, etc.). On Windows you can either boot up a VM, or use something like the MinGW toolchain (https://sourceforge.net/projects/mingw-w64/), which is a port of gcc compilers to windows. I have no experience with Mac and/or BSD.
Some learning materials I just came across on Google, which don't seem to cater to people with prior Fortran experience:
http://www.hpc.lsu.edu/training/weekly-materials/2014-Spring...
https://www.tacc.utexas.edu/documents/13601/162125/fortran_c...
http://www.dsf.unica.it/~fiore/f03t.pdf
Some more advanced topics:
http://people.ds.cam.ac.uk/nmm1/fortran/paper_10.pdf
http://people.ds.cam.ac.uk/nmm1/fortran/paper_11.pdf
http://people.ds.cam.ac.uk/nmm1/fortran/paper_12.pdf
http://people.ds.cam.ac.uk/nmm1/fortran/paper_13.pdf
http://people.ds.cam.ac.uk/nmm1/fortran/paper_14.pdf
http://people.ds.cam.ac.uk/nmm1/fortran/paper_15.pdf