We'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…
I'm bookmarking this as a case study. You should comment here more often esp when these topics come up. :)
A few years ago, I rewrote an `R` script into Fortran, for better than order-of-magnitude speed increase. The script optimized the placement of samplers in a building, in order to maximize the probability of detecting airborne pollutants, or to minimize the expected time required to detect. The rewrite cut the runtime down from 2-3 days to sub-hour. Some of the speedup was intrinsic to the interpreted/compiled divide…
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.
Seems focus is on positive differences, but I have seen the reverse a lot; switching native to web because 'everyone is doing it', switching PHP to 'something that doesn't suck', migrating off c# because 'M$' and many others that really hurt (and killed) projects. I did see projects improve as well but that was almost always because it was code from an 'old' team where the framework and programming language was not optimal (to say it lightly) for the new team.
Switching to React Native allowed our team of 6 to become a team of 2 and still go twice as quickly. It's not just the cross-platform capabilities - React is also just really great.
I have to wonder if the other 4 members of your team were as happy about the switch...
Ha! There is plenty to work on and they have skills for other apps and the platform. They are not-laid off or anything. This tech change was about leverage to spend our time wisely.
I’ll say it again. If the natural language of your problem domain is linear algebra and/or matrices (tensors), Fortran is the perfect tool.
Why is it better than C(++) for this?
Because of the libraries.
You say you can get matrix libraries for C++. And you're right, you can. But with Fortran, you can get (for example) functions that will solve Hermitian matrices, which run faster than solving regular matrices. Or special routines for sparse matrices, which run faster and use less memory. Or...
And you could write every one of those in C++. But the Fortran ones have 30 years of debugging and optimization on them. They're solid. You can't get that by writing your equivalent in C++.
Moving a large C++ codebase to C# has helped us a lot. The legacy code had memory leaks that caused random crashes. It was also long to build, and wouldn't build in 64 bit. The C# version seemlessly let us run the code in either 32 or 64 bit. C# is also a much more readable language, and has a lot of great tools for refactoring and profiling. And C#'s performance is almost as good as C++ in many areas, so all in all…
I'm guessing that moving from C++ to C++ (i.e., a rewrite in the same language) would also have helped a lot.
I'm guessing that moving from C++ to C++ (i.e., a rewrite in the same language) would also have helped a lot.
I'd guess that a same-language rewrite would have helped a lot for any non-trivial project mentioned in this Ask HN.
I’ll say it again. If the natural language of your problem domain is linear algebra and/or matrices (tensors), Fortran is the perfect tool.
Why is it better than C(++) for this?
Because Fortran was purpose-built for manipulating array-based data while C++ is a general-purpose programming language. That means Fortran is optimized for this problem domain starting at the _grammar of the language_ while C++ can provide at best access to a locally optimized set of libraries. Those libraries might be quite good, but the comparative experience is still like trying to drive a Phillips-head screw using a flat-head screwdriver.
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 one experience trying to read fortran code is this climate model: http://climatemodels.uchicago.edu/isam/isam.doc.html If most fortran code looks like that then I think the language deserves a reputation for being arcane and cumbersome.
That is an example of 'legacy' FORTRAN (when it was still written in all-caps). I agree, reading through that is not a great time.
edit: That being said, there are some really well-written projects that have shown me what good modern Fortran looks like [1-3].
Developer ergonomics is underrated. Having an easy to understand system that has no magic, and in 90% of the work has no dependency chains that you have to hold in your head can really help people avoid bugs by being able to focus on the intent and execution rather than the framework quirks.
I agree. Do you have a platform/framework that does this for you?
I have it for some applications. For smaller (Think more in terms of the code state than the conceptual/business state, because when the code state is readable and understandable and low-overhead, it leaves you all the brain space to think about the problemset. No matter what, working on establishing patterns, share them with other people working on the same codebase, and make them better over time - build only enough tests so that you can cleanly refactor whole files, while not bogging everything down in the details. If you are ever afraid of changing a file (except at top level tooling), even in production, you're doing something wrong, because the potential footprint of your changes should be as low as possible.
I would not recommend Scala anymore unless you're a small team with smart devs eager to learn it. My project is not so small, and the average developer is not interested in spending the time to really learn the language and functional style. So in the end, we have code that not everyone reads and writes well, an ecosystem that is years behind Java, and tons of incompatibilities between Scala versions as it's still no…
Can you speak more specifically regarding the ecosystem being behind? I'm a recent addition to the Scala development world and love it. That being said I'm eager to listen to any opposing viewpoints.