Live data from Hacker News

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

news.ycombinator.com

31–40 of 152 posts

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

#31
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 navigating through a codepaths with the support of their IDE. Our application code uses typehints almost exclusively, which helps. But whenever the code you're debugging drops into the framework (or PHP), you'll need to break out your browser and spend time a great deal of time reading documentation to understand how to use the function. For example, certain functions in Laravel accept no arguments in the function signature, but the function body calls PHP methods to dynamically parse function arguments.

We spend a fair amount of time documenting all the framework and language-level magic constructs. If we've dropped the ball on documentation (which happens often) a new developer is at the mercy of coworkers to explain where the framework (or language) magic happens.

On the plus side, Laravel's batteries-included approach significantly speeds our time to MVP.

Scala's category theory approach to functional programming is not easy for new developers to understand at first glance. While most of our code (framework or otherwise) is now easily navigable with an IDE, developers now need to spend time understanding concepts such as for comprehensions, monads and ADTs. However, most functional concepts are understandable without the help of coworkers, which means a new dev can rely on Google to help understand a concept, rather than relying on a coworker.

Once knowledge of syntax has been attained, Scala's strong type system makes development far easier. We can communicate semantics through types and monads (such as Either, Future, Option and domain-specific ADTs), and incorrect code is immediately flagged by the IDE. A new developer making a change to a database schema may now change a database column name, recompile, and be presented with a list of every bit of code they've broken.

Using types to represent the semantics of our domain has been incredibly powerful, and makes potential bugs much easier to spot when reading the code. For example, rather than checking a user's subscription status inside a method, we can require a "SubscribedUser" type in our method signature. With this type in place, a new developer can no longer accidentally call that method with an "UnsubscribedUser".

Perhaps most importantly, the long term benefits of Scala's strong type system are incredibly valuable. We're a software agency, so our large projects experience development in phases. It may be 6-12 months before our team circles back to a large project for major development. In that time, we've forgotten all the quirks and gotchas of that particular framework and language, and Scala's strong static type system significantly decreases regressions during the new development effort.

In summary, new developers have a similar learning curve for each language/framework. And in the end, Scala's long term maintainability is more valuable than Laravel's speed to MVP.

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

#32
Change languages is the only way so far, to step-out serious blind-spots in the previous language. Is a shame that langs are rarely fixed, only added more and more features without learning anything in the process. Devs are so change adverse that is not even funny.

I have done a lot of business/enterprise development (a very hostile space to innovation and working solo or with very small teams), and have done small-to-largeish (from my POV) rewrites in several languages.

From:

- Fox 2.6 to Visual FoxPro. A breaking change in a lot of ways, a total win in the process. Not just because the app was native windows now.

- From Fox to Delphi. Now I discover the beauty of Pascal and improve the app and deployment scenario. Static types is a net win overall. My other love is python, probable code faster on it, but have FAR LESS trouble with strong type systems.

(However take a me some years in note how bad all languages are aside the DBase Family in talk with databases, but other wins distract me from that...)

- Visual Fox to .NET (1.0, 1.1 with both Visual Basic and C#) was a total net loss. A Massive increase in code size, yet the (desktop) apps were way slower than Visual FoxPro, even more than Delphi (but my boss not let me use Delphi).

The web was also terrible in performance and complexity. Sadly back in the day I was unaware of how do web properly and drink all the MS KoolAid on this.

This sink the project and almost the company. Only saved returning back to full FoxPro.

- To Python. I move several things to python, mainly .NET stuff. How boy, how big was the win. The net reduction in code size and the clarity of the code!

Also, (web) apps way faster. Take .NET some years in learn the way here, so...

- To RDBMS (Heck, even sqlite): Still big wins when someone else try to use a nosql/desktop datase (in my space, NOBODY is Facebook. With no exception, step-out of a RDBMS is one of the biggest mistakes)

- To F#: I return to .NET past year (because MS do a lot of the right moves to fix old mistakes!!!) and again a lot of reduction in code size, removing of problematic logic obscured by years of OO-only code. Still not happy about the way lower quality tooling, but enduring it even in Xamarin Mobile because I see the benefit.

I wish I could use swift for Android, so F#/.NET is my only sane option left...

----

Mainly, move from a lang to another that is not similar, help in see the problems with the old one. Learn new or better ways to solve stuff, and get access to different toolsets and mindsets. This payback when returning back to the old, too, when this ideas are migrated.

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

#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 call essential features like exception handling, classes, etc (which has to be tacked on by using "shims" from CPAN like Moose or Try::Tiny)

At some point I had a particular issue in one of our apps where it would be making tons of DB queries and we need to cache them. In Python land there are plenty of packages that give me transparent caching at the ORM level. In Perl land? Oh yeah this post on a mailing list from 2007 about someone having the same problem, and a bit of untested code that may or may not work.

I gave up on that particular issue and it'll probably never get fixed, but let's just say that have we been using an "alive" language things would've gone much smoother.

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

#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 to pull the whole thing off while maintaining functional parity. In the end, there wasn't much of a change in performance, but C# proved to be a much more productive development platform than VB6 in terms of tooling, ability to refactor, use automated test tools, etc., so the team's velocity increased significantly over the next few years.

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

#35
post #30

Several years ago, our team refactored a large Java control system into a Ruby based one. The Ruby actually performed faster, scaled better, and was much easier to understand and maintain. The ergonomics of Ruby enabled clearer thinking about the problem, leading to the better results. More recently, we've replaced Python, Ruby, and Java based systems with golang based ones. Not having to lug around a VM and associat…

Out of interest, to what degree do you think the improvement in comprehensibility is from the new ecosystem vs performing a rewrite with learnings from the original write?

In the first case, we inherited the codebase. However, it was clear that too much attention was paid to low level stuff such as threading, etc. Ruby allowed us to more easily focus on the problem with more of a micro services approach. The Java monolith we replaced was emblematic of its time. Frameworks piled on libraries piled on other things. A lot of complexity to achieve the intended function.

The move to golang has been really interesting. The language really does seem to scale well with teams. Its great to be able to pick up even code that you would expect to be complicated, such as the golang tls library, and be able to understand it. The much easier to use concurrency and fantastic standard library mean there's a lot less looking around for which framework to use or which approach to apply.

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

#36
post #15

Earlier quoted context omitted.

This isn't surprising to me at all. Having the creator of a framework working with a team using a framework is a huge benefit, almost regardless of the framework quality (within reason). And that's not a dig at intercooler's quality (I've never used intercooler, and am no fan of Angular), but I do think it's a huge confound. Meaning, if I had access to creator of framework A on my team, and was choosing between frame…

If you like framework B more than A by too much, it seems unlikely to me that you'd have the creator of framework A on your team.

Really? Was it really unclear to you that I was presenting a hypothetical to illustrate a point and not practical advice?

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

#38
post #30

Earlier quoted context omitted.

Out of interest, to what degree do you think the improvement in comprehensibility is from the new ecosystem vs performing a rewrite with learnings from the original write?

In the first case, we inherited the codebase. However, it was clear that too much attention was paid to low level stuff such as threading, etc. Ruby allowed us to more easily focus on the problem with more of a micro services approach. The Java monolith we replaced was emblematic of its time. Frameworks piled on libraries piled on other things. A lot of complexity to achieve the intended function. The move to golang…

I want to explicitly call out an important point here. They inherited the original codebase and were able to understand the domain problems and what the original solution got wrong AND what it got right. Pretty much any language or framework they chose to rewrite the application in should have seen similar benefits (even if rewritten in Java). I've seen several projects where a rewrite was given to a entirely new team and those projects tend to be as complex or more so than the original (and tend to take a long time to ship)

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

#39
post #23

The SPARK people at AdaCore found a bug in the reference implementation of Skein just rewriting it in SPARK: http://www.adacore.com/knowledge/technical-papers/sparkskein...

Interesting. And the tl;dr for the bug is: byte_count := (n+7) / 8; When n is near max size, it overflows to a small number, then (small number) / 8 = 0 the fix is to restrict n to [0,MAX-7)

One can do it without restricting the range as well, if the full range of inputs is needed.

In C:

    (n / 8) + !!(n % 8);
Post reply on HN