Wait are you making the opposite claim? That one should eschew the "correct" formulation in favor of a bespoke one? Despite the stated (and hopefully obvious) difficulties that brings with maintenance, generalization, etc?

▲

mmis1000 4 days ago | parent | next [-]

You probably haven't see front-end projects that pulls tons of library for a simple sorting or grouping task. Sometimes even solvable with build-in array function alone. It's a true nightmare when you have to deal with that kind of projects.

▲

komali2 4 days ago | parent [-]

What, like lodash? Some of those hail from a time that we didn't have a good set of native methods. So the library is just legacy'd in. But I do agree, lodash performance compared to native functions is crazy bad.

▲

mwcz 4 days ago | parent [-]

Is that the case? I saw a talk by the author of lodash years ago and he touched on performance. The built-in functions are (or were?) implemented in JS, level terrain for a library like lodash to beat "native" performance. Lodash beat browser built-ins in some cases. The talk was ten years ago, though, so things may have changed. Perhaps more of the built-ins are written in C++ now.

Here's the talk: https://youtu.be/2DzaOnOyCqE?si=McCMjzGopzSCoaCi

▲

mmis1000 3 days ago | parent [-]

Ｉt's not really about the performance. It's about the readability. The performance don't even matter if you are just grouping dozens or hundreds items on the gui.

Abuse Lodash or Underscore everywhere means the code is not readable unless you know what is every used lodash function intended to do. Combing with weak type and undocumented business logic (and api types), it's a true nightmare experience to work with.

It's probably irrelevant in a personal project. But it's a headache if you are collaborating.

Sometimes it got even worse that original user don't know the exact specification of the utility function either. And the code works just by pure luck. (something like, the method work if all keys are numeric) It will give you a hard time to troubleshoot the problem if it happens.

▲

mwcz 3 days ago | parent [-]

"It's not really about the performance" the parent comment was about the performance of lodash.

▲

mmis1000 2 days ago | parent [-]

That's exact why I reply this though (or probably I should reply to your parent comment?). The place these get used are mostly performance insensitive location, it don't really do anything except ruins the readability. And the project is not that old either(It's a past es6-era project), I don't really get why it is used at all.

	▲	mwcz 2 days ago \| parent [-]
		I'm not a lodash stalwart or anything, but years ago when I used it heavily, it made navigating and manipulating large/complex/irregular objects much easier. It's LINQ for JavaScript. And it was very readable and consistent, since most functions in lodash have the same signature.

▲

torginus 4 days ago | parent | prev [-]

I'm sorry but after reading your comment I can't seem to be able to decide if you favor writing the dynamic programming version or pulling in the constraint solver.

Both are correct in the sense that they give the right output, and I don't think pulling in a huge library (maintained by who knows and for how long) is going to be beneficial for maintenace. And having a good understanding of both the precise requirements, and the algorithms used to solve them also helps maintenance.

It's just having two dozen lines tucked of code away in a function in the repo seems infinitely more maintainable to me then using some giant framework (of possibly unknown quality) to solve the issue.

This is a general argument I'm making, not just applying to this constraint solver/

▲

bubblyworld 3 days ago | parent [-]

There are other aspects to maintenance, like requirements change. In this case it's trivial to change or add new constraints to a constraint solver, whereas even small changes to a typical DP problem can require a total rethink of the approach. Extending the analogy to other kinds of dependencies left as an exercise for the reader.

Point being that software has many dimensions. Reducing the use of dependencies to fear of learning or thinking is a bit reductive in my opinion, even for stuff that seems simple initially.

▲

torginus 3 days ago | parent [-]

Imo, deepending on the desired quality of the result and the amount and complexity of bespoke requirements, the more of the former are present, the more strongly I consider rolling something bespoke.

With out-of-the-box libraries, the more custom requirements I have, the more trouble I tend to have supporting them, and trying to make something do a thing it wasn't designed for, can erase initial gains very quickly. At least this has been my experience over the years.

	▲	bubblyworld 3 days ago \| parent [-]
		I mean, it really depends. I'm writing models for some energy traders at the moment, and things were simple enough in the mvp that we could hand-roll our optimisations. But when we started having to map real contracts it got out of hand super fast. Linear constraints solvers have been a godsend, it makes adding new types of contacts and constraints really easy (and supports almost arbitrary kinds of optimisations). It's just never as easy as "don't do this" or "always do this". But yeah, I agree with your gist, right tools for the right job and all that. Most of the time you don't know all requirements up front and it can make sense to hedge your bets in the interest of speed until you do.