Threads for evilissimo

  1. 1

    I wonder if we couldn’t have a way to have less descriptive error stacktraces. Eg move the Data to an external file like pdb files for visual studio or map files for minified js. Where debug symbols are move out of the binary. And instead have some minified version embedded where the data could be decoded using the file.

    However there probably comes still reflection into play too, so probably no :S

    1. 24

      When did we lose our way? When everything became about making money. I always describe my developer burnout to folks, and I always tell them “I got into it because it was fun, and a creative outlet.” Maybe I just need to start making geocities sites.

      Though, I don’t think we need to bring back jquery.

      1. 14

        The issue is saturation. If you want to have fun then develop for a less popular platform. There’s a ton of good, fun platforms to develop for with solid commuities surrounding them. You just have to find them.

        1. 2

          Agreed. Maybe discovery isn’t as easy but even on the current platform there are fun and interesting sites.

          I also like to wax nostalgia on the internet of old but I do not want to bring it back. Find the new weird, don’t try and recreate the old weird

          1. 4

            That’s a good point. Find the new weird. The internet is too young for us to go back to old weird already

            1. 5

              The new weird will probably look similar to the old weird (minus specific format-related glitches) though.

              Like, the new weird will probably use color and animation for expression, offend the sensibilities of people who expect the web to be ‘readable’ (i.e., for artistic statements to obey the same laws of propriety as marketing and documentation), contain surrealistic and scatological humor, and occasionally be intentionally annoying or hostile. These are all things the early web has in common with dada, outsider art, lettrism, oulipo, faxlore, etc. In other words, it’s part of the general tradition of democratized creative work, and one of those things that gets axed as soon as the work is coopted by the Spectacle.

              The new weird will break in different ways. We won’t use gifs because it uses less bandwidth to store actual videos these days, so we won’t have artifacts from 8 bit color or from transparency being inconsistent in a single frame or from the size changing for one frame (unless we go out of our way to reproduce those things). Hosting is cheaper per byte, so we won’t have failures related to files being deleted because we went over our megabyte of storage. We’ll have new and exciting failures.

        2. 10

          I’m building a greenfield web application with Haskell, Elm, Nix, Event-Sourcing, aaaaaaaand… jQuery!

          Nothing wrong with it :)

          1. 3

            I’m using intercooler for most stuff that I can these days, and it sits on top of jQuery (or zepto). So it’s definitely not going away for me yet.

            1. 2

              Ohh nothing wrong with jQuery ;) I guess I felt real good coding in javascript without having to include it!

            2. 3

              I use jQuery every day at work. It’s pretty funny considering the code base is only 3 years old or thereabouts. The stack is definitely considered “old” by some. I try to make the best of it. Sometimes I’ll just write plain JS and it feels oddly satisfying.

              1. 2

                “Writing is like prostitution. First you do it for love, and then for a few close friends, and then for money.” - Moliere.

                1. 1

                  ‘bring back’? It was never gone…

                  1. 1

                    yeah that’s true. one of my clients uses it in their front end stack. though whenever I work in a more modern codebase we end up not bringing it in.

                1. 1

                  Red Hat Enterprise Linux 7 redefined the operating system

                  Ow ouch that marketing speak

                  Yum 4, the next generation of the Yum package manager

                  Huh, what happened to dnf?

                  1. 1

                    Yum4 is dnf 4.x

                  1. 2

                    To some extent I agree, however if there is too much code in the constructor it also is quite often an indicator that the code should be refactored. The convenience of what the RAII principle is providing allows also to avoid coding and resource management mistakes/bugs. In c++ exceptions are considered to be used for exceptional circumstances, and they are quite expensive for binary size, at least I made that experience when I used to work on some bigger applications. On the other hand I have been writing a lot of python code in the last few years and exceptions are the defacto way to handle errors. And it’s very much not a problem to use exceptions for non exceptional use cases.

                    In C++ I rather would argue that the approach of acquiring resources during initialization makes sense because it reduces your need for introducing checks that could lead to wrong code paths especially in the destruction. When applied correctly your program will be more robust if you use the raii principle. I recommend reading the exceptional C++ books by Herb Sutter those are very much still one of the best sources in writing C++ code that is handling exceptions properly.

                    Complexity in constructors and destructors is something to avoid which is something as I understand is your main criticism to the principle.

                    1. 4

                      it’s very much not a problem to use exceptions for non exceptional use cases.

                      Agreed. Many dynamic programming problems are a good fit for backtracking with longjmp/“exceptions” which is how you’d write it in assembly anyway.

                      Lately (well, sometime in the last couple decades) I’m thinking “exceptions” aren’t a good use for exceptional situations either. That is to say, we’re using exceptions exactly backwards.

                      One of the best examples I’ve come up with is the out of disk space error. When you’re out of disk space, many programs will give up/crash – but consider the ergonomics of a CAD or video editing tool, that upon save starts moving this multi-gigabyte asset out to disk over what’s perhaps several minutes and then – oops! that partition is full.

                      If we unwind, the (temporary) file needs to be cleaned up(deleted), the user informed to make room somehow – none of these tasks are straightforward – all the file opens to save this large asset need to be in on it, which is often tricky if the file-saving was done by a different team than the UI team (who handles the exception, and thus deletes the files).

                      But what if we use a handler? We call the handler, from deep in the file saving code, and tell it “we’re out of disk space”. We can easily offer a callback to “retry”, and a list of any (temporary) file created so far so that they can be deleted (or moved onto another disk, or whatever). This could be provided by the UI team, but if not the operating system could have a crude “abort retry fail” dialog. We live in a multitasking world these days, so that’s probably good enough for a lot of enterprise applications – use goes and moves those files around and then resumes the save (by returning from the handler).

                      1. 6

                        That is exactly the approach taken by Common Lisp’s condition system (which is used for more than just errors, but also for general notifications. It’s extremely powerful, and an illustration of how Lisp really is an industrial-strength language for real problems.

                      2. 1

                        On the other hand I have been writing a lot of python code in the last few years and exceptions are the defacto way to handle errors.

                        I don’t speak parsel tongue, but if I recall correctly it’s a bit like Ruby on that front.

                        ie. The use of garbage collection means resource release can be indefinitely delayed, making RAII an unsuitable idiom.

                        The ruby equivalent is an “acquire resource/begin/yield resource/ensure release resource/end” sequence.

                        I think, I may be wrong, the python equivalent is a try finally sequence.

                        Alas, programmers are lazy, I often see cases where an exception for entirely other reasons results in a trip through the ensure(finally) block which will attempt to release a resource not yet acquired…

                        Personally I still think exceptions where the wrong mechanism. Rust’s tagged unions are actually pretty good.

                        recommend reading the exceptional C++ books by Herb Sutter

                        Which are full of fine fine fine print about how you can cut yourself with them if you miss a trick. Part of the reason for my recommendation above is you avoid having to review your code line by line against a laundry list of fine print.

                      1. 4

                        I think that one additional benefit of this approach is, that things that as a senior dev seem obvious and don’t seem to need documentation or commentary, might not be as straightforward as thought and the reviewer can help to point that out by questioning the approach.

                        It’s a win-win because as a seniority progresses one might loose the view of what the presumable status quo is. In the time before becoming a truely senior dev, I tended to over complicate things however learning later, that the real solution could be much more simple. When a junior points out that things are quite complicated, it might be a good pointer to revise the code to be more straightforward. This in turn should or could lead to a better understandable code base.

                        1. 15

                          Since the beginning clang was generating better error messages

                          GCC got better since though

                          1. 1

                            I wonder how failing code in serverless environments differs from code that fails in “serverful” environments According to the logic of the post that implies that there is something new that is required. TBH I can’t see the point