3 ms·

The advantage of frameworks is to have a "common language" to achieve some goals together with a team. A good framework hides some of the stupid mistakes you wo

by vladms 8mo ago

The advantage of frameworks is to have a "common language" to achieve some goals together with a team. A good framework hides some of the stupid mistakes you would do when you would try to develop that "language" from scratch. When you do a project from scratch, if you work enough on it, you end up wishing you would have started differently and you refactor pieces of it. While using a framework I sometimes have moments where I suddenly get the underlying reasons and advantages of doing things in a certain way, but that comes once you become more of a power user, than at start, and only if you put the effort to question. And other times the framework is just bad and you have to switch...

sodapopcan 8mo ago
The problem with this is that it means you have to read guides which it seems no one wants to do. It drives me nuts. But ya, I hate when people say they don't like "magic." It's not magic, it's programming.
- coldtea 8mo ago
  Most however are surely capable of understanding a simple metaphor, in which "magic" in the context of coding means "behavior occuring implicitly/as a black box". Yes, it's not magic as in Merlin or Penn and Teller. But it is magic in the aforementioned sense, which is also what people complain about.
- WJW 8mo ago
  Oh no! Reading! Sorry for the snark but why is this such a problem?
  - fragmede 8mo ago
    Because people won't do it.
    - WJW 8mo ago
      Sounds like a them problem. If they can't be bothered to learn how to use their tools, it won't be a surprise that they then won't know how to use them. A free advantage to those of us that do dedicate the time to read the docs I guess.
      - sodapopcan 8mo ago
        At least in web development it really seems to have become widely accepted, at least at many places, that people aren't expected to be anywhere near experts in the tools they use every day.
- monkpit 8mo ago
  Magic refers to specific techniques used in programming, an people generally dislike these techniques once they have formed any opinion.
  - bryanrasmussen 8mo ago
    do people generally dislike magic once they have formed an opinion, or is it just that people who dislike magic are more prone to voicing that opinion, why, if magic is disliked by people experienced enough to form opinions, does it keep coming back around? I would suppose the people who create "magic" solutions have at least voiced an opinion that they like magic and the people who take up those solutions the same, for the record I too dislike magic but my feeling is that I am somewhat in the minority on that.
    - sodapopcan 8mo ago
      There is a HUGE difference between framework/library "magic" and business logic "magic." When framework/library "magic" is documented it's awesome, you just need to take the time to learn it.
- bryanrasmussen 8mo ago
  https://medium.com/luminasticity/laborers-craftsmen-and-artists-70be689c0ee7 https://medium.com/luminasticity/laborers-craftsmen-and-arti... in my experience among personality types of programmers both laborers and artists are opposed to the reading of guides, I think the laborers due to laziness and the artists due to a high susceptibility to boredom and most guides are not written to the intellectually engaging level of SICP. Craftsmen are naturally the type to read the guide through. Of course if you spend enough time in the field you end up just reading the docs, more or less, because everybody ends up adapting craftsmen habits over time.
  - sodapopcan 8mo ago
    I don't disagree, but the fact that it's not required to border on expert, or be willing to put in the work to get there, of a framework or library you are going to be working heavily in a pretty broken thing about our industry. But you know, as people have been posting lately: not AI therefore irrelevant.
jv22222 8mo ago
I used Claude to document, in great detail, a 500k-line codebase in about an hour of well-directed prompts. Just fully explained it, how it all worked, how to get started working on it locally, the nuance of the old code, pathways, deployments using salt-stack to AWS, etc. I don't think the moat of "future developers won't understand the codebase" exists anymore. This works well for devs who write their codebase using React, etc., and also the ones rolling their own JavaScript (of which I personally prefer).
- bossyTeacher 8mo ago
  > I used Claude to document, in great detail, a 500k-line codebase in about an hour of well-directed prompts Yes, but have you fully verified that the documentation generated matches the code? This is like me saying I used Claude to generate a year long workout plan. And that is lovely. But the generated thing needs to match what you wanted it for. And for that, you need verification. For all you know, half of your document is not only nonsense but it is not obvious that it's nonsense until you run the relevant code and see the mismatch.
  - jv22222 8mo ago
    Yes, since I spent over 10 years writing it in the first place it was easy to verify!
    - sodapopcan 8mo ago
      This is a key piece of information you left out of your original post.
      - deleted 8mo ago
        [deleted]
- vladms 8mo ago
  To make a parallel to actual human language: you can understand well a foreign language and not be able to speak it at the same level. I found myself in that situation with both foreign languages and with programming languages / frameworks - understanding is much easier than creating something good. You can of course revert to a poorer vocabulary / simpler constructions (in both cases), but an "expert" speaker/writer will get a better result. For many cases the delta can be ignored, for some cases it matters.
goatlover 8mo ago
It's funny how Lisp has been criticized for its ability to create a lot of macros and DSLs, then Java & JavaScript came along and there was an explosion of frameworks and transpiled languages in JVM, Node or the Browser.
- bitwize 8mo ago
  "The problem with Scheme is all of the implementations that are incompatible with one another because they each add their own nonstandard feature set because the standard language is too small." Sometimes with an added subtext of "you fools, you should have just accepted R6RS, that way all Schemes would look like Chez Scheme or Racket and you'd avoid this problem". Meanwhile in JavaScript land: Node, Deno, Bun, TypeScript, JSX, all the browser implementations which may or may not support certain features, polyfills, transpiling, YOLOOOOO
toss1 8mo ago
So, use the framework for the prototype and maybe thru v1.x, then after you have better understanding of how it is actually used in the field and what architecture and patterns would work best in your team's situation, fully write the real app yourself (or, if the framework really works best, keep using it). I've found taking the throwaway approach a bit further down the line pays big benefits; delaying full commitment to a particular path until you have a lot more information tends to work better.

by vladms 8mo ago

sodapopcan 8mo ago

The problem with this is that it means you have to read guides which it seems no one wants to do. It drives me nuts. But ya, I hate when people say they don't like "magic." It's not magic, it's programming.

coldtea 8mo ago
Most however are surely capable of understanding a simple metaphor, in which "magic" in the context of coding means "behavior occuring implicitly/as a black box". Yes, it's not magic as in Merlin or Penn and Teller. But it is magic in the aforementioned sense, which is also what people complain about.
WJW 8mo ago
Oh no! Reading! Sorry for the snark but why is this such a problem?
- fragmede 8mo ago
  Because people won't do it.
  - WJW 8mo ago
    Sounds like a them problem. If they can't be bothered to learn how to use their tools, it won't be a surprise that they then won't know how to use them. A free advantage to those of us that do dedicate the time to read the docs I guess.
    - sodapopcan 8mo ago
      At least in web development it really seems to have become widely accepted, at least at many places, that people aren't expected to be anywhere near experts in the tools they use every day.
monkpit 8mo ago
Magic refers to specific techniques used in programming, an people generally dislike these techniques once they have formed any opinion.
- bryanrasmussen 8mo ago
  do people generally dislike magic once they have formed an opinion, or is it just that people who dislike magic are more prone to voicing that opinion, why, if magic is disliked by people experienced enough to form opinions, does it keep coming back around? I would suppose the people who create "magic" solutions have at least voiced an opinion that they like magic and the people who take up those solutions the same, for the record I too dislike magic but my feeling is that I am somewhat in the minority on that.
  - sodapopcan 8mo ago
    There is a HUGE difference between framework/library "magic" and business logic "magic." When framework/library "magic" is documented it's awesome, you just need to take the time to learn it.
bryanrasmussen 8mo ago
https://medium.com/luminasticity/laborers-craftsmen-and-artists-70be689c0ee7 https://medium.com/luminasticity/laborers-craftsmen-and-arti... in my experience among personality types of programmers both laborers and artists are opposed to the reading of guides, I think the laborers due to laziness and the artists due to a high susceptibility to boredom and most guides are not written to the intellectually engaging level of SICP. Craftsmen are naturally the type to read the guide through. Of course if you spend enough time in the field you end up just reading the docs, more or less, because everybody ends up adapting craftsmen habits over time.
- sodapopcan 8mo ago
  I don't disagree, but the fact that it's not required to border on expert, or be willing to put in the work to get there, of a framework or library you are going to be working heavily in a pretty broken thing about our industry. But you know, as people have been posting lately: not AI therefore irrelevant.

jv22222 8mo ago

I used Claude to document, in great detail, a 500k-line codebase in about an hour of well-directed prompts. Just fully explained it, how it all worked, how to get started working on it locally, the nuance of the old code, pathways, deployments using salt-stack to AWS, etc. I don't think the moat of "future developers won't understand the codebase" exists anymore. This works well for devs who write their codebase using React, etc., and also the ones rolling their own JavaScript (of which I personally prefer).

bossyTeacher 8mo ago
> I used Claude to document, in great detail, a 500k-line codebase in about an hour of well-directed prompts Yes, but have you fully verified that the documentation generated matches the code? This is like me saying I used Claude to generate a year long workout plan. And that is lovely. But the generated thing needs to match what you wanted it for. And for that, you need verification. For all you know, half of your document is not only nonsense but it is not obvious that it's nonsense until you run the relevant code and see the mismatch.
- jv22222 8mo ago
  Yes, since I spent over 10 years writing it in the first place it was easy to verify!
  - sodapopcan 8mo ago
    This is a key piece of information you left out of your original post.
    - deleted 8mo ago
      [deleted]
vladms 8mo ago
To make a parallel to actual human language: you can understand well a foreign language and not be able to speak it at the same level. I found myself in that situation with both foreign languages and with programming languages / frameworks - understanding is much easier than creating something good. You can of course revert to a poorer vocabulary / simpler constructions (in both cases), but an "expert" speaker/writer will get a better result. For many cases the delta can be ignored, for some cases it matters.

goatlover 8mo ago

It's funny how Lisp has been criticized for its ability to create a lot of macros and DSLs, then Java & JavaScript came along and there was an explosion of frameworks and transpiled languages in JVM, Node or the Browser.

bitwize 8mo ago
"The problem with Scheme is all of the implementations that are incompatible with one another because they each add their own nonstandard feature set because the standard language is too small." Sometimes with an added subtext of "you fools, you should have just accepted R6RS, that way all Schemes would look like Chez Scheme or Racket and you'd avoid this problem". Meanwhile in JavaScript land: Node, Deno, Bun, TypeScript, JSX, all the browser implementations which may or may not support certain features, polyfills, transpiling, YOLOOOOO

toss1 8mo ago

So, use the framework for the prototype and maybe thru v1.x, then after you have better understanding of how it is actually used in the field and what architecture and patterns would work best in your team's situation, fully write the real app yourself (or, if the framework really works best, keep using it). I've found taking the throwaway approach a bit further down the line pays big benefits; delaying full commitment to a particular path until you have a lot more information tends to work better.