1. 42
  1.  

  2. 34

    tl,dr: author and friends smugly laughed off old-school wheel reinvention to focus on superficial things, now are regretting their lack of understanding and control.

    The above isn’t an entirely fair summary of the article, but given parts like this…

    started to see jolt-cola drinking wizards unconcerned about their appearance being replaced with skinny-jeans-wearing bearded hipsters

    …and this…

    We could focus more on the things we always felt were important, but never practiced — typography, great design, responsiveness, and elegant data design.

    …and this

    Forward thinking concepts from other areas of language design like aiming for more modular, immutable, compositional, simpler less dependent code makes so much sense for the web — but we are stuck in a voice of OOP and inheritance and meta-programming that encourages lazy thinking and lazy software.

    I know this is mean, but I smirked when I read this.

    In the last part, for example, the author seems to just be cargo-culting the new-old hotness pilfered from functional languages without understanding why that’s good. If the author understood the benefit of immutable and referential transparent code, then they should’ve listed an Erlang-family language in their later Swift/Go/Rust appeal. If the author understood OOP, they’d know that the JVM has quietly just been kicking ass in that role for like 15 years.

    Author doesn’t even mention NodeJS or PHP frameworks like Laravel, even though they scratch the same itches the author complains about earlier.

    Seriously, this is what happens when people prefer “opinionated software” to learning their goddamn craft.

    1. [Comment removed by author]

      1. 6

        Its still going to end up the same way that Ruby/Rails did. At their cores, both projects are trying to save you from something over enabling you to do something.

        1. 13

          Please, do explain.

          1. 7

            Elixir made a bunch of design decisions that required to them to wrap much of the Erlang standard library. This wouldn’t be a huge problem, except for the fact they are also revising what they expose to promote interfaces they feel are appropriate. These interfaces normally don’t mesh well with Erlang (E.G. going between Elixir’s binary based strings and Erlang’s list of characters), requiring a understanding of both languages to be able to interop. Talking to a large number of Elixir devs, they have expressed a almost vitriolic hatred towards any usage of Erlang period. So, for them and a large segment of the community, Elixir saves you from Erlang. Phoenix does a similar thing, except it goes and builds layers on top of Elixir to further remove you from the Erlang world. So in a sense, both tools give you an Erlang like experience without the need to really understand what that experience is. In its current form, the tools try to “save” you from a “confusing” ecosystem.

            1. 3

              I don’t agree with your point, but at least I know where you’re coming from now. You could describe Elixir as saving programmers from Erlang-the-language; I could describe Elixir as enabling programmers to access Erlang-the-platform without writing code that looks like Prolog got into a car crash with ML in the 1980’s. There are plenty of Elixir devs with a distaste for Erlang-the-language, but the love for Erlang-the-platform is most of what brought us here.

              To use your example, Elixir’s use of binary strings enabled programmers to easily manipulate strings on the Erlang platform without using 16 times as many bytes as necessary. Few would seriously defend Erlang’s linked list strings. Erlang’s binary syntax is very clunky for expressing and working with character strings. Do you begrudge Elixir for improving on that?

              I think the main difference between the Ruby/Rails and Elixir/Phoenix worlds is the amount of magic that is considered acceptable. Elixir is a low-magic language, and Phoenix is a low-magic framework.

              1. 3

                There are plenty of Elixir devs with a distaste for Erlang-the-language, but the love for Erlang-the-platform is most of what brought us here.

                Which is fine, but this argument becomes very hard to deal with, because, if you accept that both languages produce functionally equivalent products, its a matter of personal preference. I’ve found that these discussions tend to end poorly with nobody feeling satisfied by the conclusion.

                Few would seriously defend Erlang’s linked list strings. Erlang’s binary syntax is very clunky for expressing and working with character strings. Do you begrudge Elixir for improving on that?

                I don’t begrudge Elixir for trying to improve, I just wish that more of the community was in a place to understand the reasoning behind these changes over repeating “Erlang strings sucks” mantra.

                I think the main difference between the Ruby/Rails and Elixir/Phoenix worlds is the amount of magic that is considered acceptable. Elixir is a low-magic language, and Phoenix is a low-magic framework.

                While in its current form this is true, I don’t think this will stay true for very long if the Rails community moves over in force. Looking at other languages that have included a macro system as powerful as Elixir’s the only one that came out unscathed was Lisp. That was due to its homoiconic nature, something that Elixir lacks. It feels ripe for abuse, the same way every other macro system is and the same way metaprogramming was abused in ruby. Any tool that gives you the power to create DSLs also lets you create leaky abstractions and I fear that the community will only realize this when its too late.

                1. 5

                  …if you accept that both languages produce functionally equivalent products, its a matter of personal preference.

                  Straight into the Turing Tarpit! In which everything is possible, but nothing of interest is easy.

                  I just wish that more of the community was in a place to understand the reasoning behind these changes over repeating “Erlang strings sucks” mantra.

                  It doesn’t take a 10x rocket surgeon to understand the reasoning behind treating character strings as binary blobs. And it sounds like you have a low opinion of the community and its individuals.

                  That was due to its homoiconic nature, something that Elixir lacks.

                  Elixir is homoiconic, it just has multiple syntaxes – the “external” one most people write, and the “internal” one which is just a desugared version of the first one. It’s similar to the approach taken in OCaml. Contrast to Lisp, which is homoiconic with a single syntax, and forces the developer to write in the internal format. Also contrast to e.g., Scala, which is not homoiconic, and whose macros operate on already-compiled ASTs.

                  1. 3

                    And it sounds like you have a low opinion of the community and its individuals.

                    For what it’s worth, I think the concern about bringing over the “more magic” mentality of Rails is completely justified. Excessive metaprogramming and wheel reinvention is a special type of cancer.

                    1. 1

                      It doesn’t take a 10x rocket surgeon to understand the reasoning behind treating character strings as binary blobs. And it sounds like you have a low opinion of the community and its individuals.

                      My comment wasn’t intended as a point of malice, but to illustrate the fact that members of the elixir community are promoting the language by making these kinds of statement without understanding the decision making behind them.

        2. 1

          PHP frameworks like Laravel

          I’m tempted to say Laravel is the nicest MVC framework I’ve used so far. If it were only written in a different language I think it would be perfect.

          1. 1

            Sometimes there is value in re-implementing something yourself, just so you can understand it better.

            Another thing i prefer now are low level libraries that make few assumptions about your overall systems, it is far easier to stitch them together in the end (avoid frameworks).

          2. 9

            I do feel for the author, because I deal with similar pain points too. I’ve found that the biggest point of contention that I have with Rails and other frameworks / libraries / languages, which choose to focus on speed of initial usage, is that they actively encourage people to skip over any introspection and decision making around their usage. For example, ActiveRecord models have a shocking tendency to grow in size unless you and / or your team is willing to maintain the diligence to refactor them aggressively. I don’t lay this as a fault of ActiveRecord, per se, but really a fault of the evangelization and community that sprung up around Rails.

            Rails has always had a strong overarching voice. This helped drive adoption in its nascent stages, but in the long run I feel its cost it a large amount of flexibility. At the end of the day, Rails came from Basecamp and was driven by Basecamp’s needs and desires. Where I think the fault lies in all of this is the tendency for people to follow these strong voices in lieu of making their own decisions.

            A lot of the problems that i’ve run into or had to tackle in a professional setting boiled down to a choice that was wrong or has become wrong. Many of these choices that where wrong, came from a convention promoted by someone in the community. I feel that developers can get led away from the best solution for their current problem by this. I also believe, that this isn’t a problem, per se, but exposes the “real” problem that has lead Rails to this point.

            I think, as developers, we need to be skeptical of any promoted solution. There is never going to be a panacea, no matter how much we try or how much we believe. Now, that doesn’t mean we should stop trying, but it means we need to change the way we evaluate the tools and techniques we bring when asked to solve a problem.

            The author’s comparisons with node.js are fitting. It too suffers from the same charisma and community driven problem that Rails suffers from. I think more generally though any language will suffer from this once its community reaches a certain size and drops to a certain skill level. My fear now is as we hear the heraldic cries from new languages and communities we will repeat the same mistakes. As the next line of challengers gears up for the fight to become the new hip and vogue choice, I just ask that we all stop and think. As time as shown, nothing in computing truly dies and the choices we make today will be around much longer than any of us care to believe.

            1. 10

              What we need to do is capture the lessons learned from these platforms and document them.

              Young developers will fall for each new generation of tripe that comes through, but at least we’ll have the prior documentation of platform anti-patterns for them to find when they are ready.

              A few ideas:

              • Software engineering principles transcend the delivery medium. Claiming your medium is so new that it’s exempt from proper engineering practice is the mark of a charlatan.

              • Celebrity culture is actively harmful to technical development

              • Internet Points (Github stars, Twitter mentions, etc) do not correlate with quality.

              1. 4

                What we need to do is capture the lessons learned from these platforms and document them.

                I don’t know if it’s a thing anymore, but this seems apt to go into the c2 wiki - call it “cultural design patterns”. These are design patterns, and they are harmful patterns.

                1. [Comment removed by author]

                  1. 4

                    As someone who participated in it a long time ago and left while it was still thriving, if you have any insight into what happened, I’m interested.

                    1. [Comment removed by author]

                      1. 5

                        The replacement, while an interesting concept at first (federated wiki) is a usability train wreck.

                        1. 3

                          That’s very interesting. Thank you!

                        2. 2

                          The community is dead because the C2 wiki has been frozen – pages can no longer be edited. As I remember it, this was due to spam that Ward didn’t want to spend effort fighting against. I think it happened a while after Ward created his federated wiki project, and was not directly related.

                2. 4

                  It’s super easy to cast aspersions at articles like this, but, aside from the hand waving about hipster beards and new languages, I largely agree with the author.

                  I have never been able to wrap my head around Rails, largely because of the amount of sheer metaprogramming induced MAGIC involved.

                  I also think the point about Ruby’s expressiveness and its community’s love of metaprogramming making working with the framework easy but not simple is spot on.

                  1. 3

                    I hated ruby on rails from the moment I used it for many of the reasons the author lists. Difficult to debug, keeping up with all the security problems, the way gems just pile up on a project and require lots of work to keep the latest versions of each gem working with your app, it was for me a frustrating mess.

                    1. 5

                      Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern thinking, build a community with simple as a core design goal, and save web development from itself?

                      Haskell web development is starting to see some light more and more by the day. The author says his big concern is trying to debug programs - which Haskell does well, because of referential integrity (and -Wall when you compile :)

                      1. 4

                        How so? I still feel like the ecosystem is missing a lot of off-the-shelves libraries and has so for years. When will it take up steam?

                      2. 2

                        What does lobsters think about Django? I rarely hear it mentioned, but I’ve tried it on a couple small toy projects and it seemed nice enough. The only thing that bugs me is that I’m not sure I understand it’s model. It doesn’t seem to be MVC, and the whole concept of “apps” is foreign to me. Does anyone have a good description of how the Django paradigm is supposed to work?

                        1. 4

                          It’s considered heavyweight; it has a unique design pattern paradigm. It’s sort of a Major Thing that your entire stack is built around. Flask is thinner and is preferable for smaller projects.

                          I’d rather use Rails, myself; Python feels like its getting pushed into only the scientific computing community over time.

                          1. 4

                            I primarily use django for backend development when it is a work related project. I transitioned away from django rendering templates to it serving a REST api using django rest framework. I find it pleasant to work with, test and debug but that might come from familiarity. I personally like the ORM and try to avoid writing any SQL in django projects by hand. For some smaller things I have used flask which is a more ‘lightweight’ framework. I think django is in somewhat of a transition period away from trying to do everything in the MVC model to allowing you to make more decisions, looking at the roadmap and announcements the addition of things like channels and more REST features seems to show that it is moving to what I would loosely call a ‘modern web’ approach.

                            1. 2

                              I used django in the past (admittedly a long time ago), and I recall it working well. I remember the documentation being very good. I have also heard good things about the django rest framework from a couple of past colleagues.

                              That said, I personally tend to prefer more minimalistic options like falcon, flask, or bottle. I am also not a big fan of ORMs in general, but I have heard of people using django and writing sql by hand too – ymmv I assume.

                              1. 2

                                I’ve used Django professionally and inherited code from a Django creator. It’s pretty similar to Rails, but built on the deep assumption that your app has a lot of public read-only users (who are probably not logged in) with a small, completely-trusted set of read/write admins. This is really obvious in the built-in admin panel, but it echoes through the form builder, views, routing, templating, caching, apps, etc. I didn’t recognize it while working on a CRUD app with lots of read/write users, but as soon as I touched a publishing site it was like the whole thing sung in sympathetic resonance with a background noise I only just realized I’d been hearing the whole time.

                                “Apps” are what they sound like. Django reifies the concept because of the hassle that went into standing up a webserver to serve python apps in the early 2000s and because it was built for the case where your same trusted admins publish multiple sites.

                                1. 1

                                  I thought the same for a long time, however I’ve come to realise this is probably more of a shortcoming in documentation than anything. Django has a great built in permissions system out of the box, the thing it lacks is a simple way to manage those permissions without using the admin page or rolling one yourself. You can set read/write/edit/delete permissions on models or, with a library, instances of the models as well.

                                  An project I ran for a while at the university was a discussion board similar to stack overflow for students. We had multiple permission levels (students, TAs, course staff etc) and all of that was managed within Django. Coming back to Django rest framework they have a good permissions model as well which I use quite extensively these days to restrict actions / visibility of data based on user attributes.