1. 3

    Brutalism as an architectonic style is disgusting and oppressive as shit (intentionally). I spent quite a bit of time in a brutalist building, I felt like shit. Like how did intentional hostility ever become a trend?

    1. 10

      While the term certainly originates from concrete, the author is not trying to advocate making websites out of concrete (figuratively). I think the main point can be seen in the paragraph mentioning Truth to Materials. That is, don’t try to hide what the structure is made out of - and in the case of a website it is a hypertext document.

      This website could be seen in that light. It is very minimally styled and operates exactly how the elements of the interface should (be expected to). The points of interaction are very clear.

      The styling doesn’t even have to be minimal, but there is certainly a minimalism implied.

      1. 9

        I respect your opinion, but I personally really enjoy brutalist architecture. I like the minimalism and utilitarian simplicity of the concrete exteriors, and I like how the style emphasizes the structure of the buildings.

        1. 2

          I think if you added a splash of color it would make the environment much more enjoyable while still embracing the pragmatism and the seriousness.

        2. 5

          It isn’t intentionally being oppressive or hostile. It represents pragmatism, modernity, and moral seriousness. However it doesn’t take a large logical jump to realize that pragmatism, modernity, and moral seriousness could feel oppressive. In the same way to the architects who designed brutalism, the indulgent designs of 1930’s-1940’s might feel like a spit in the face if you’re struggling to make ends meet. Neither were trying to hurt anyone, yet here we are.

          1. 3

            I consider the 1930s designs (as can be seen in shows such as Poirot) to be rather elegant styling. But I also see the pragmatism that was prompted with the war shortages.

            I am not a great fan of giant concrete structures that have no accommodation for natural lighting, but I also dislike the “glass monstrosities” that have been built after brutalist designs.

            I find myself respecting the exterior of some of the brick buildings of the 19th Century and possibly early 20th. Western University in London Canada has many buildings with that style.

            Some of the updates done to the Renaissance Center in Detroit have mitigated some of the problems with Brutalist - ironically with a lot of glass.

            1. 2

              This might be true of Brutalism specifically, but (at least some) modern (“Modern”, “Post-modern”, etc.) architecture is deliberately hostile.

            2. 3

              I found this article on that very topic pretty interesting.

              1. 2

                In my home town, the public library and civic center (pool, gymnasium) are brutalist. It was really quite lovely. Especially the library was extremely cozy on the inside, with big open spaces with tables and little nooks with comfortable chairs.

                1. 1

                  My pet theory is that brutalism is a style that looks good in black-and-white photographs at the extent of looking good in real life. So it was successful in a time period when architects were judged mainly on black-and-white photographs of their buildings.

                1. 8

                  Check out Oberon http://www.projectoberon.com/.

                  In 300 pages, and starting with an FPGA (you can get one for relatively cheap), you build a CPU on for the FPGA, a compiler targeting said CPU, an OS using said language, a simple UI and simple network stack for said OS.

                  1. 3

                    You confuse readibility with style. Style should be consistent but readibility means good abstractions.

                    1. 1

                      I recently had an encounter with a code base filled with duplicative code, excessive logging, poor abstractions and long methods. Oh, and 50-100 (pretty printed) lines of SQL compressed down to 4 lines of concatenated strings.

                      It was typically 2-6 lines of logging, 2 lines for try/catch, 4-6 lines for some braces and then maybe 1-2 lines of logic filled with chained method calls to things that should have been readily accessible. Repeat that for a few hundred lines and you’ve got yourself a “run” method ! Time to move on to the next class.

                      There were no primitives to work with. Just masses of code globbed together. It was impossible to read. @_@

                    1. 3

                      I’m working on some tonality models for this music composition app that’s like an IDE for music. You should sign up here https://docs.google.com/forms/d/1-aQzVbkbGwv2BMQsvuoneOUPgyrc6HRl-DjVwHZxKvo if you wanna be notified when I launch it.

                      1. 7

                        While there are language-specific tools that help immensely (such as cscope), for me nothing has ever really beaten just knowing find/grep/silversearcher type tooling thoroughly, alongside a couple of shell macros.

                        Even monster-sized codebases fit easily in RAM and with a multithreaded grep like silversearcher (ag), navigating to strange and unknown parts takes only a few moments. Combine your newly discovered directories with a few hacky shell macros like in https://gist.github.com/dw/81f9b8cc0d957c41a7b2f6dc85b53358 and you’re all set.

                        1. 3

                          The rgrep command in Emacs is really nice for that kind of searching.

                          1. 1

                            check out ripgrep https://github.com/BurntSushi/ripgrep its memetastic

                          1. 5

                            What a weird argument. Part of writing solid C code is testing it. As far as I know, nobody writes bug free code in any language.

                            1. 13

                              I gave the author the benefit of the doubt and assumed they were talking about working with tests. I think the point still stands.

                              1. 6

                                It’s not. Different languages have different classes of bugs. Those in C/C++ tend to have disastrous consequences.

                                1. 9

                                  Such statements would be less hyperbolic if people recognized that only a small subset of C bugs belong in that class of potentially-disasterous and exclusive to C, and that only a small subset of such bugs make it through code review and testing, and that a small subset of these bugs are actually exploitable in the real world.

                                  Bugs in C programs get publicized really often because there’s a crapton of such code out there in active use. But that kind of publicity doesn’t give people any sense of scale, and the issue is blown completely out of proportion. If that weren’t enough, the discussion will derail into UB and people assume a deliberately adversial compiler that literally tries to turn every instance of UB into an exploitable bug. It almost sounds as if the standard somewhere said that compilers are not permitted to let the code behave in any reasonable manner in the face of UB…

                                  1. 17

                                    if people recognized that only a small subset of C bugs

                                    That mostly don’t exist when using a type-safe, memory-safe language in most of your code. It’s impossible to write idiomatic code in them with the same errors resulting in something more than an exception. Most hackers aiming for code injection in such languages try to hit the runtimes or libraries that are written in C or C++. Says a lot.

                                    Meanwhile, there were operating systems written in SPARK Ada, Modula-3, Java, and Rust whose unsafe portions were kept to a much lower percentage with rest immune to entire classes of vulnerabilities. Microsoft’s VerveOS made those parts safe with proven assembly the rest of the OS (in C#) interfaced to. I bring these up to preempt the common counter of the lower parts having to be written in C/C++ because they’re the only thing that can handle low-level stuff. I get that false claim a lot in these discussions.

                                    1. 4

                                      Just as a simple example, the very common failures to properly parse input strings and firewall them from e.g. SQL databases are language independent.

                                      1. 7

                                        We’re talking about whether using a different language improves security by removing an entire class of bugs. The status quo Im countering are C and C++ bugs leading to code injection that controls the machine. You side-step that evidencw to counter that people building web or database apps can have an extra problem.

                                        So what. That average programmers are producing things immune to many forms of code injection by default is already better than C/C++ situation where even veterans get hit by those bugs periodically. And if you’re concerned about SQL injection, there’s similarly methods to immunize against it in apps. Ur/Web, Opa, and Spectre are examples of languages or platforms foing stuff like that.

                                        So, the empirical evidence shows these other languages and preventative methods knock out lots of peoblems. That’s a net gain as secure coding is rare skill. From there, there’s still stuff to watch for.

                                    2. 1

                                      a small subset of C bugs belong in that class of potentially-disasterous and exclusive to C

                                      Could you elaborate on this class? What are the typical disastrous gotchas exclusive to C? Is there a list on a paper or somewhere?

                                      1. 4

                                        Buffer overflow (including those induced by C’s strange string semantics) and use-after-free are the big common ones; also integer overflow can immediately be a security bug in C. Switch fall-through is not quite unique to C but close. I’m sure there are more that we’d notice if we fixed those.

                                    3. 1

                                      That argument would require some specifics and data - not the “I can’t write C/C++ without testing” presented in the article.

                                  1. 4

                                    btw i think that there should be a machine learning tag because I think that ML definitely belongs here but there’s no tag.