4 ms·

The more I program, the more I am convinced that owning flow of control is one of my primary jobs as a programmer. If I surrender this to a framework, there ar

by skohan 7y ago

The more I program, the more I am convinced that owning flow of control is one of my primary jobs as a programmer. If I surrender this to a framework, there are a lot of decisions I can't make with regard to performance, and I have a lot less certainty about when and in what order exactly things are executed. There are of course some exceptions, but in general I want libraries to provide me simple, synchronous functions, and it's my job to figure out how to spread them out over the hardware.

toshk 7y ago
On the level of practical risk: on the security level libraries are much more risky imo. A good framework for most project i've seen will lead to a more structured and secure codebase. Probably precisely because there is less room for creativity. For instance Laravel is very structured: orm, auth routes, controllers system etc., where express.js let's you do whatever. And almost all Expressjs or other Nodejs projects i've joined were a mess and had security issues, something as simple as CSRF tokens, or not allowing redirects to external domains, are often forgotten or not fully implemented. Doesn't mean I don't sometimes prefer a library approach, but the developer(s) need to be a lot more qualitative.
- indeyets 7y ago
  oh, Laravel is actually an excellent example. It has a lot of hidden "magic" knowledge inside and it takes many months to get a good understanding of how it works. Until then it is trivial to make bad decisions based on this wrong knowledge. Lack of proper IDE support (because of laravel's dynamic nature) doesn't help. And yes, I know about laravel-ide-helper. It has it's issues too
kevsim 7y ago
This hits home for me right now. I'm currently battling some performance problems related to a lot of "magic" that happens when using the Apollo GraphQL framework and am strongly considering ripping it apart and taking back control of what happens and when.
- nift 7y ago
  Would be super awesome if you could share what you find! Having the same issues here - and I have a real time accepting that stuff becomes slow when you wanna return over 1k records. Sometimes way less for advanced things. Read: nested objects. But that slow? Come on. I also use nestjs and there it seems updates to how to resolve a field has made it tons faster l, purely looking at the trace. And I know that it won't be as fast as regular old json due to the checking but that slow? Must be something someone can do :)
  - kevsim 7y ago
    Large queries with lots of nesting is exactly the situation I'm in. Perform a mutation and boom - very slow response from useQuery().
- jordiburgos 7y ago
  Is Apollo GraphQL helping you more than REST + queries?
  - kevsim 6y ago
    I think it helped us to go really fast at first. Observable queries and subscriptions made it relatively easy to make the site feel very live and collaborative. Not sure how much help it is now as some of the magic is causing performance challenges
cageface 7y ago
I’ve been working in some largish Rails codebases lately and this is exactly the problem I have. When I’m looking at a screenful of code I have no idea who is calling what, what’s in scope and from where, and what the shape of any of my data is. In my opinion the productivity benefits of these kinds of frameworks evaporate and go negative pretty quickly once you move very far beyond what they provide out of the box.
- choward 7y ago
  I think a lot of that has to do with Ruby not having real modules and everything being global.
  - 3pt14159 7y ago
    Yeah. I prefer Rails, but I'm fluent in python too, and the lack of explicit module importing was a mistake in my opinion.
masswerk 7y ago
You could make a point that programming is managing flow control.
dTal 7y ago
Good luck using any sort of GUI toolkit then. Virtually every single one requires you to sacrifice the very top level of your program to some sort of "MainLoop()" function. (I agree with your main point, and the above fact causes a quasi-allergic reaction in me which causes me to avoid GUI programming - despite graphics being one of my favorite topics.)
- OJFord 7y ago
  Instead of using something you're quasi-allergic to, you could work on one you're not?
  - p_l 7y ago
    Rhw issue is that it's not exactly possible, especially on Mac, where your initial thread is sacred and for OS use only. Windows and Linux UI libs need a main loop somewhere, but it can live on any thread and in fact doesn't need to be structured the same.
- traverseda 7y ago
  Try the "imgui" library?
  - eliasnaur 7y ago
    Sadly even imgui cannot get around the fact that many operating systems (macOS/iOS/Android) force you to give up your main thread. Linux and, perhaps surprisingly, Windows are good guys in this regard.
hinkley 7y ago
In a similar vein: boilerplate code is fine in the main control flow. It’s okay if it takes twenty lines of code to set up your library, as long as it’s not the same 20 lines for everybody in production. Frameworks tend to avoid any boilerplate in the imperative core but then multiply I throughout the rest of the project. Possibly due to chronology.
kovac 7y ago
How can a library providing only sync functions a good thing? Lots of IO is inherently async and it makes little sense for a library developer to go out of his way to make it synchronous only for the callers to make things asynchronous again. If something is async, it's async. You deal with that. Also, I don't see why one would even consider using a framework if squeezing out every bit of performance from your hardware is that important. I can't imagine writing a Web app without some framework in the interest of time it takes to develop. Then writing a hundred of the same stuff again? You just have to ensure you don't use a bloated framework which is akin to not choosing a bloated library. Unless you are working on a device layer, it's not our job to spread things over the hardware. Unless you have direct access to memory, you can't do this anyway with most of the languages designed to develop apps. I think the primary goal of an app developer is to implement the business logic correctly and securely in a reasonable time. I agree with the OP that libraries should be preferred but I don't see a problem especially with performance in the domains frameworks are used.

by skohan 7y ago

toshk 7y ago

On the level of practical risk: on the security level libraries are much more risky imo. A good framework for most project i've seen will lead to a more structured and secure codebase. Probably precisely because there is less room for creativity. For instance Laravel is very structured: orm, auth routes, controllers system etc., where express.js let's you do whatever. And almost all Expressjs or other Nodejs projects i've joined were a mess and had security issues, something as simple as CSRF tokens, or not allowing redirects to external domains, are often forgotten or not fully implemented. Doesn't mean I don't sometimes prefer a library approach, but the developer(s) need to be a lot more qualitative.

indeyets 7y ago
oh, Laravel is actually an excellent example. It has a lot of hidden "magic" knowledge inside and it takes many months to get a good understanding of how it works. Until then it is trivial to make bad decisions based on this wrong knowledge. Lack of proper IDE support (because of laravel's dynamic nature) doesn't help. And yes, I know about laravel-ide-helper. It has it's issues too

kevsim 7y ago

This hits home for me right now. I'm currently battling some performance problems related to a lot of "magic" that happens when using the Apollo GraphQL framework and am strongly considering ripping it apart and taking back control of what happens and when.

nift 7y ago
Would be super awesome if you could share what you find! Having the same issues here - and I have a real time accepting that stuff becomes slow when you wanna return over 1k records. Sometimes way less for advanced things. Read: nested objects. But that slow? Come on. I also use nestjs and there it seems updates to how to resolve a field has made it tons faster l, purely looking at the trace. And I know that it won't be as fast as regular old json due to the checking but that slow? Must be something someone can do :)
- kevsim 7y ago
  Large queries with lots of nesting is exactly the situation I'm in. Perform a mutation and boom - very slow response from useQuery().
jordiburgos 7y ago
Is Apollo GraphQL helping you more than REST + queries?
- kevsim 6y ago
  I think it helped us to go really fast at first. Observable queries and subscriptions made it relatively easy to make the site feel very live and collaborative. Not sure how much help it is now as some of the magic is causing performance challenges

cageface 7y ago

I’ve been working in some largish Rails codebases lately and this is exactly the problem I have. When I’m looking at a screenful of code I have no idea who is calling what, what’s in scope and from where, and what the shape of any of my data is. In my opinion the productivity benefits of these kinds of frameworks evaporate and go negative pretty quickly once you move very far beyond what they provide out of the box.

choward 7y ago
I think a lot of that has to do with Ruby not having real modules and everything being global.
- 3pt14159 7y ago
  Yeah. I prefer Rails, but I'm fluent in python too, and the lack of explicit module importing was a mistake in my opinion.

masswerk 7y ago

You could make a point that programming is managing flow control.

dTal 7y ago

Good luck using any sort of GUI toolkit then. Virtually every single one requires you to sacrifice the very top level of your program to some sort of "MainLoop()" function. (I agree with your main point, and the above fact causes a quasi-allergic reaction in me which causes me to avoid GUI programming - despite graphics being one of my favorite topics.)

OJFord 7y ago
Instead of using something you're quasi-allergic to, you could work on one you're not?
- p_l 7y ago
  Rhw issue is that it's not exactly possible, especially on Mac, where your initial thread is sacred and for OS use only. Windows and Linux UI libs need a main loop somewhere, but it can live on any thread and in fact doesn't need to be structured the same.
traverseda 7y ago
Try the "imgui" library?
- eliasnaur 7y ago
  Sadly even imgui cannot get around the fact that many operating systems (macOS/iOS/Android) force you to give up your main thread. Linux and, perhaps surprisingly, Windows are good guys in this regard.

hinkley 7y ago

In a similar vein: boilerplate code is fine in the main control flow. It’s okay if it takes twenty lines of code to set up your library, as long as it’s not the same 20 lines for everybody in production. Frameworks tend to avoid any boilerplate in the imperative core but then multiply I throughout the rest of the project. Possibly due to chronology.

kovac 7y ago

How can a library providing only sync functions a good thing? Lots of IO is inherently async and it makes little sense for a library developer to go out of his way to make it synchronous only for the callers to make things asynchronous again. If something is async, it's async. You deal with that. Also, I don't see why one would even consider using a framework if squeezing out every bit of performance from your hardware is that important. I can't imagine writing a Web app without some framework in the interest of time it takes to develop. Then writing a hundred of the same stuff again? You just have to ensure you don't use a bloated framework which is akin to not choosing a bloated library. Unless you are working on a device layer, it's not our job to spread things over the hardware. Unless you have direct access to memory, you can't do this anyway with most of the languages designed to develop apps. I think the primary goal of an app developer is to implement the business logic correctly and securely in a reasonable time. I agree with the OP that libraries should be preferred but I don't see a problem especially with performance in the domains frameworks are used.