Live data from Hacker News

Ask HN: When has switching the language/framework made an important difference?

news.ycombinator.com

111–120 of 152 posts

Re: Ask HN: When has switching the language/framework made an important difference?

#111
post #83
post #33

Well 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.

Well in my particular case it's a read-only app (there are no writes at all from the app itself so no need to worry about cache invalidation) so a caching ORM that can be a drop-in replacement would've been a huge win for less than one hour of dev time, and I could've done it in Python without any issues.

With this obsolete language the only way is to change pretty much all the app to do app-layer caching and that would've cost 20x times that, so we're not going to do it.

Re: Ask HN: When has switching the language/framework made an important difference?

#112

My team switched an entire application from C# (~350k loc) to F# (~30k loc). Smaller team, smaller code base, fewer bugs, complete implementation of requirements, clearer code. The whole of the F# code base was less than the number of blank lines in the C# code base and a lot more fun to read and write. https://github.com/Microsoft/visualfsharp/issues/2766#issuec...

Wow. I have been using C# for a long time and has dabbled in F# a little bit. And I know F# can help you reduce some boilerplate that C# requires but I have never seen reducing code base by 90 percent like in your case. Can you give us little bit more details? Eg 350k doesn't include blank lines, right? What did the application do? Is it a Windows service or a Web App or a command line program?

Re: Ask HN: When has switching the language/framework made an important difference?

#113

Earlier quoted context omitted.

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.

All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination. And all are worse performance-wise. 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…

> All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination.

There is some C++ code that is very bad out there but most C++ code maintained by normal people is passable. When I use it I use it as C with references.

> And all are worse performance-wise.

You are incorrect just by the facts of the situation [0][1][2]. This lie has stuck around so lazy people can pat themselves on the back for being lazy. "Yay we did it! We found the best language every! We don't need to learn anything new or update anything!".

The truth is a modern C/C++ compiler like GCC or clang/LLVM can generate far more efficient code than Intel's FORTAN compiler. Not only that but you have access to more performance and scalability libraries when you're not using the programming language equivalent of Latin. You're never going to get out of the MPI ditch that scientists have dug for themselves in a museum piece like FORTRAN. There will be no good abstractions, no well planned libraries, no in language support for newer hardware.

FORTRAN is going to be stuck in the 70s and 90s.

Languages like C++, Python's libraries, Julia, and other languages (like D/Go/etc) are going to evolve as industry needs them to. As we start being able to use less and less of the our computers abilities compilers, optimizers, and libraries are going to allow us to easily pick up the slack. You can already see this things like ViennaCL. GPUs, FPGAs and other tools are coming. MPI and FORTRAN can't be the only tool in your toolbox and if you're lying to yourself and burying your head in the sand in an attempt to pretend you can then good luck to you. You're wasting your budget, the taxpayer's money, and everyone's time on the supercomputer's queue because you don't want to try something new.

But it's fine. Who cares really. FORTRAN is the only language a scientist will ever need. I mean it is the fastest (even if it isn't) and it has the best compilers (even if they aren't the best and we waste thousands and thousands of dollars of taxpayer money to get them) and we know it and that's all that matters. Who cares about broader impact, portability, and future proofing.

[0] - http://benchmarksgame.alioth.debian.org/u64q/fortran.html

[1] - https://julialang.org/benchmarks/

[2] - http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Re: Ask HN: When has switching the language/framework made an important difference?

#114

Earlier quoted context omitted.

One can do it without restricting the range as well, if the full range of inputs is needed. In C: (n / 8) + !!(n % 8);

This is correct, and is sometimes necessary, but is a last-ditch save, since as written, it involves a branch. Much better if you can let the n+7 expand to a wider integer type. Or better yet, if you can ensure that it won't overflow in the first place -- which is what they did by restricting the type.

My x86-assembly has become very rusty, but couldn't it work like this, not using a branch:

(with eax being the unsigned 32-bit input word)

  xor ebx, ebx
  test al, 7
  stnz bl
  shr eax, 3
  add eax, ebx
(edit: replaced a movzx with an xor)

Re: Ask HN: When has switching the language/framework made an important difference?

#115
post #83
post #33

Well 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 lack of employers that want to pay for such developers.

Hence everything is being rewritten to Java(Script) and PHP.

Re: Ask HN: When has switching the language/framework made an important difference?

#116
Years ago I rewrote some liquid flow routing analysis in C# that was precisely one jillion times faster than the original code. This code was written in....a SQL stored procedure.

tl;dr Don't use SQL for recursive conditional logic.

Probably not a useful example huh?

Re: Ask HN: When has switching the language/framework made an important difference?

#117
As others have said earlier, if the new tools serve the problem domain better there will be significant gain.

My first game server was hand crafted with php/mysql. It did work and was able serve players, however moving to Erlang allowed two order of magnitude more players onto the same box, while the code maintainability increased as well.

Re: Ask HN: When has switching the language/framework made an important difference?

#118
post #78

> I'm curious about real world examples where a change has lead to a significant positive outcome in performance, code quality/maintainability, etc. Another example: same language, new framework: In a Python web app, we needed to have websockets. But at that time Django had no real websocket support. But there is future proof framework that does: aiohttp! Also one might argue that you can use old django with websocke…

Is the Django-websockets story ok now?

Not really. There is the "channels" project which brings it closer to proper websocket capabilities, but it still isn't great to work with. I tried using it for a production project and gave up as I encountered too many issues. Ended up rewriting the app in phoenix as we needed really solid websocket support. Phoenix makes websocket seriously nice to work with and we've found the performance to be quite impressive.

Re: Ask HN: When has switching the language/framework made an important difference?

#119

Earlier quoted context omitted.

Both Julia and Python use Fortran code under the hood to speed up matrix multiplication. Julia comes with OpenBLAS which is partially written in Fortran, and the following page of SciPy documentation indicates that a Fortran compiler is required for some NumPy modules: https://docs.scipy.org/doc/numpy-1.10.1/user/install.html "To build any extension modules for Python, you’ll need a C compiler. Various NumPy modules…

I would also say that no one in the scientific world should be writing ASM for their programs. Does that mean I'm also telling them not to use any compiled language? No.

ASM != Machine code.

That aside, you haven't explained why you think the languages you listed are better suited for scientists than Fortran. What are your issues with modern Fortran?

Re: Ask HN: When has switching the language/framework made an important difference?

#120
post #73
post #34

I was involved in the conversion of over 500k lines of Visual Basic 6 to C# motivated by Microsoft's EOL'ing of VB6. Most of it was a desktop application although part of it was a server component. We used an automated code conversion tool which did a surprisingly good job of handling the mindless parts. Some pieces such as the database interaction code had to be hand-ported. I was pretty surprised that we were able…

Interesting. Is the conversion tool internally developed? How did you handle semantics like -1 is true?

We used a code conversion tool from Artinsoft (now Mobilize.Net) and brought one of their consultants onsite for a week. The cost for that was in the low 5 figures, but our CTO (rightfully) recognized that as a bargain given the amount of developer time it would save us. The consultant helped us analyze the code conversion results and got us some custom builds of their tool to handle certain edge cases in our code. We had to make a pass over the converted code by hand for certain things such as changing from VB6 to C# coding conventions, etc., but as I recall, the overall effort was 3-4 months for a team of about 10 developers. That's not bad considering it was a critical part of our flagship product in ~2010 and MS had dropped support for the VB6 IDE.
Post reply on HN