5 ms·

"and Phoenix is so full of magic (which isn't a good thing)" Can you explain something more about why you think this is not a good thing? Is it like Laravel (

• headmelted 6y ago
  “Magic” in any language is always bad. It makes for great demos but it basically means “this just works so you don’t need to know how it works”. The problem is you always need to know how your tools work, often sooner rather than later, as you inevitably end up with edge cases and bugs in your application that simply can’t be resolved without that understanding.
  • technicolorwhat 6y ago
    Where does one draw the line between magic and a lack of user understanding? I never got this argument. Isn't magic you as a user not understanding how it works? I mean, classes in c are pretty magic, the this pointer is magic. Type checking, loops, trampoline jumps. A car is pretty much magic yet people use it every day. Is it magic when it does something convenient for you based on conventions without you writing the steps? As long as 'magic' is clearly explained in the docs I don't see how it's different from a layer of abstraction like a compiler or a car.
    • michaelcampbell 6y ago
      > Where does one draw the line between magic and a lack of user understanding? There is no line; that's the definition. (I'm agreeing with you here, btw) It's a blub issue; if one doesn't understand it, it's derisively called "magic". So you don't get this argument because it's totally based on the observer. I use Django at work and I hate it because it's magic all over the place. And I recognize that me saying it is simply I haven't had the time or impetus to go figure out the stuff I don't have figured out yet, so I can bucketize all that as "magic".
      • vendiddy 6y ago
        Maybe magic isn't the distinction to make. On the extreme, our processors are magic and I've never understood how exactly they work. I've had a similar experience in Ruby where metaprogramming was used in favor of objects with functions. When I had issues, it was very hard to debug. Maybe it comes down to the quality of the abstraction. I think the point of a good abstraction is you don't have to go down to the layer below.
        • RandoHolmes 6y ago
          > Maybe magic isn't the distinction to make. Or maybe this is a board full of programmers who love to fret over unimportant minutia. The idea has a well understood meaning, just use that meaning. Yes, maybe somewhere on the edges it's fuzzy, learn to live with fuzzy.
          • vendiddy 6y ago
            Sure, words will always have fuzziness, but there is benefit to substituting fuzzy terms with clearer terms. Words help influence thinking, so fuzzy words can lead to fuzzy thinking. If we are debating an API design and a colleague says "it's too much magic", is that bad thing? If I write deliverEmail(email) and the e-mail "magically" gets sent, what's wrong with that? On the other hand, if we debate the abstraction itself--for example behavior doesn't match user expectations--then we can do better at improving the API design.
    • Touche 6y ago
      You're conflating abstractions with magic. They are not the same. Magic is not just an abstraction we don't bother to understand. Magic is magic. A car is not magic. It does exactly what it purports to do and nothing else. David Blaine levitating is magic. It works in a very limited set of circumstances and no more. It works to amuse some spectators. It doesn't work to, for example, cross the Hudson River, despite outward appearances. Similarly, in programming we use "magic" to describe something that seems to defy what the underpinning (language, framework, etc.) would allow. We know that it's using some trick to pull off what it's doing, and that trick likely has constraints that won't allow the magic to ever become a true abstraction. Note that I'm not calling Phoenix magic as I haven't used it enough to know
    • RandoHolmes 6y ago
      No, magic is when you actually do understand and it gets in your way as a result. For example, I actually do understand http, but doing anything not explicitly designed for by the framework of choice can be painful. It's not that I don't understand the underlying tech, it's that the "magic" is expecting a specific use case that I don't want to do.
      • headmelted 6y ago
        This is it in a nutshell. Also applies to scenarios where a developer does not understand something not because they don't want to, but because the vendor has actively tried to obscure how it works and is asking you to take it as a given that it will always just work "by magic" for every use case, which invariably nothing ever does.
  • vendiddy 6y ago
    Where do you draw the line? When do you learn about the JVM in a Java environment? At what point should you dig into be Ruby source code? At some point you have to treat the abstraction below you as a black box. I've personally found it helpful to accept the black box and only dig in after I've gained more experience or at the point I feel like a lack of understanding is getting in my way.
    • antris 6y ago
      > Where do you draw the line? When the abstraction can be considered 100% leak-proof in practical terms. Also, if you have alternative tools when you encounter a case where "X" doesn't fit, you do not need to learn about "X" as long as you have "Y". But when a solution is presented as "this must always be used", the solution should have been around for a long time with a track record of never breaking. If that's where the abstraction is, it's usually solid enough to not go any deeper. In my experience, most developers don't talk about "magic" as if it's the same thing as "abstraction". "Magic" usually means an abstraction that leaks under non-trivial conditions.
  • dnautics 6y ago
    I would say for Phoenix, with 90% of the magic... if you don't like it it's relatively easy to cut and paste your way through an override, so there's that. A lot of it is there for your safety, it abstracts things that "you are likely to get wrong if you try to write it yourself". The only thing I couldn't figure out how to override was streaming uploads.
  • MaxBarraclough 6y ago
    > It makes for great demos but it basically means “this just works so you don’t need to know how it works”. But this describes all manner of legitimately useful features. Garbage-collection, for instance, or dynamic-dispatch, or closures, or await/async. As technicolorwhat and vendiddy already said, it's also poorly defined. In languages like Haskell, or SMT-solving languages, the programmer might know very little about how the language is implemented. > you inevitably end up with edge cases and bugs in your application that simply can’t be resolved without that understanding You can run into trouble if you have an incomplete understanding of your programming language, but this isn't particular to 'magic' abstractions.
  • jrochkind1 6y ago
    > “Magic” in any language is always bad. only because we reserve the use of the word "magic" for the times we find it bad/unsuccesful. When it's good/successful, we call it "powerful, mature, and robust high-level abstractions and APIs". That "magic" is always bad is just a syllogism because a value judgement on the success of the abstractions or APIs is built into the term as used. Abstractions that are confusing, or unexpected, or inconsistent internally or with the platform they live on, or especially leaky or buggy, or in practice hard for beginner developer-users to develop proper mental models to guide use around and to understand how to debug the use of -- get called "magic". But nobody set out to provide such abstractions, they set out to provide nice, polished, predictable, simple to understand, consistent, powerful tools at the right level of abstraction for the domain -- when someone thinks they've failed, with abstractions at a fairly high level or higher than the speaker thinks is appropriate for the domain -- they call it 'magic'.
    • headmelted 6y ago
      I don't think that's what is meant by "magic" in terms of code, at least it's never been my own understanding. "Magic" is not something the developer doesn't understand, it's something the developer cannot possibly understand, because you didn't document it properly (or at all).
      • jrochkind1 6y ago
        I think that's an extention of what I'm talking about. Either way, so was it intentional? Does anyone sit down and say "I'm going to create something poorly documented that no developer can possibly understand, so that they'll call it magic, this is my goal today"? Nope. "magic" is poor execution of something, one way or another. It's a category of something done unsuccesfully, not some kind of difference in kind of thing. This matters for how we talk about 'magic', like, you shouldn't have put all that magic in there, did you think we want magic? No, nobody wants something poorly documented and nobody thinks they do. Nobody sets out to make something unsuccessful, "magic" is a failure.
• latch 6y ago
  Whether or not this is a problem comes down to two factors: 1 - How ok are you with just accepting things as documenting, like having to put `use HelloWeb, :controller` in each controller. Personally, I _had_ to understand what this was doing and how, but I imagine some people don't care so much. 2 - Do you need / want to do anything outside what's an idiomatic Phoenix. As a simple example, I think Plug.Parser is wrong to raise an exception when invalid json is given to it (shitty user data is hardly "exceptional" and I don't need error logs with poor signal to noise).
  • ericmj 6y ago
    > As a simple example, I think Plug.Parser is wrong to raise an exception when invalid json is given to it (shitty user data is hardly "exceptional" and I don't need error logs with poor signal to noise). Plug sets the status code for parser errors to 400: https://github.com/elixir-plug/plug/blob/v1.10.4/lib/plug/parsers.ex#L38 https://github.com/elixir-plug/plug/blob/v1.10.4/lib/plug/pa... You should check the `:plug_status` field of the exception and only log/report the error if it's in the 5xx range.
  • tonyarkles 6y ago
    Re: 1. I had the same concern, but the nice thing is that when you get to the point where you gotta know what’s happening, the file with the :controller code is right there in the auto-generated file in lib. You can just open it up and see! Re: 2, your entire plug chain is accessible and configurable if you don’t like the defaults. I’ve never tried to modify the specific behaviour you’re referring to, but my other experience with modifying plus behaviour has generally been pretty smooth.
• conradfr 6y ago
  I would say do at least one small project or tutorial without Phoenix but in any case Phoenix is a web framework with routes, controllers, templates etc you won't get lost there. You'll lose some things (no built-in auth but there's libs) and win some (easy websockets and pub/sub). Also LiveView is fun.
  • thdrdt 6y ago
    LiveView is the reason my eye caught Elixir/Phoenix. Currently I am working with Blazor (C#) and I really like that you can forget about Javascript (most of the time). I believe Blazor, LiveView and others are the future for webdev.
• Kiro 6y ago
  How is Laravel hell to maintain? Fwiw, I think Laravel has much less magic than RoR or the PHP equivalent CakePHP which is all about magic.
  • thdrdt 6y ago
    One example: a lot of objects are composed at runtime. So only at runtime you will know what the properties are.