Threads for amw-zero

  1. 1

    It always goes back to the difference between web “sites” and web “applications.” The web was not built for applications, it was built for static content, i.e. sites. We’ve layered on feature after feature to incrementally bring the web towards being an application platform.

    The only way I’ll “use the platform” is if the platform APIs you’re talking about support building applications.

    The article was written in a very tempered manner, and I appreciate that, so I’m not arguing. I’m just saying, even after all these years, there are not great standard APIs for building applications.

    1. 1

      Maybe there’s a tag related to proof assistants but I couldn’t find it.

      1. 2

        formalnethods

        1. 1

          Ah thank you.

        2. 1

          TLA+ does support automated proofs with TLAPS, but it looks like they aren’t actually proving things here. They’re doing model checking.

        1. 5

          Something about async/await is nice but it’s not like it solves any major problems. In fact, isn’t that exactly how it’s marketed, as syntax sugar?

          For both sides of this debate, there are a million arguments for or against what’s more ‘readable’ but it’s subjective, and even if it weren’t the difference is fairly minimal. So I’m not persuaded to avoid either way really.

          1. 7

            I think async/await syntax is objectively more readable. It’s less indentation and less context you need to keep in your head while observing a given piece of code.

            1. 1

              It rather depends on how you write it. I’ve seen promise chains that read like a beautiful DSL and promise chains that would make you weep in horror; I’ve seen async/await used to elegant effect and async/await written like someone wanted to use exceptions as a tool for murder.

              There’s nothing objective about it, any more than imperative code is “objectively” more readable than FP code. Background and local style both dominate other effects,

          1. 2

            I think the question of ‘what is the ideal frontend architecture’ can’t be answered without thinking about the backend as well. After all, the frontend is generally just a cache of the system / backend state. So it makes sense to design the whole architecture at once.

            For example, choosing something like GraphQL changes your whole backend architecture. Or microservices vs monolith - this affects your frontend too.

            So really, full stack architecture is about building a data caching and update system with multiple layers.

            For me, I want that data caching system to be decoupled from the actual design of the appearance of views / pages. By this I mean, I prefer the full stack portion to be designed together, and to make the actual user interface a humble object which just calls into this ‘application kernel.’

            1. 10

              Call me an optimist, but we have achieved amazing things in the last 40 years. Many of them are indirect or not mainstream, but still amazing.

              The first indirect thing we have is really strong type systems. Every single useful feature in type systems came out of PL research, even if we don’t all use Standard ML or Haskell.

              An example of a off-mainstream amazing achievement is sel4. Ok, it’s still a lot of work to formally verify a relatively small micro kernel, but we did it.

              Project Everest has gotten verified cryptographic software into mainstream browsers.

              TLA+ is getting used at Amazon and Elasticsearch.

              Tools like Jepsen apply property-based testing to real world projects.

              There are practical successes everywhere, even if the average project doesn’t use research ideas directly.

              1. 4

                I think many of those fields are not part of the author’s definition of “software engineering research”.

                I’d be surprised if they tried to argue that we have made very little progress in programming languages , cryptography, or formal methods.

                1. 2

                  Right. What other research fields are there really? Almost everything boils down to PLs or formal methods in some way.

                  1. 7

                    Databases, engineering practices, distributed systems, CS education, most things involving performance, defect detection, version control, production surveys? Those are just the research fields I recently read papers in.

                    1. 1

                      Nice, I was honestly having trouble thinking outside of the research that I tend to look at.

                      1. 5

                        Also, “software engineering” is a specific research area about the methods by which software is produced.

              1. 9

                This pattern of implementing things in a higher-level / easier language and then lowering for performance is also a common one in the computer vision space! It’s often much easier to prototype things in something like MATLAB before moving to OpenCV with C++. The MATLAB version lets you make sure that the concepts work or are even worth pursuing further, and then you go to OpenCV when you want it to actually run fast and be usable in other contexts.

                1. 7

                  Also, in the Rust world this makes me think of the often-recommended pattern of avoiding references, cloning liberally, sprinkling RefCell and Rc all over the place, and only once you’ve got it working and right, starting to reduce the unnecessary allocations.

                  1. 3

                    Yes for sure, I think we need more of this to make reliable systems! I mentioned the analogy to TeX here:

                    http://www.oilshell.org/blog/2020/05/translation-progress.html

                    And how the Go compiler was translated from C to Go. It’s very similar because it’s not arbitrary C – you can’t translate say bash or sqlite to Go with their translator. Similarly our translator is not for arbitrary Python – it’s for the (statically typed) subset that we use.

                    1. 2

                      This is all very cool! I’ll add that in the formal methods world, there’s also a fun approach of model-based code generation, where you write some model that you prove useful properties of, then generate code from that model, and prove that the generated code maintains all the stuff you proved about the model!

                      I’ve actually contributed to a project that did this, though I was a developer and target language expert and definitely not one of the formal methods people doing the proofs. Fun stuff!

                      1. 3

                        Yes for sure! That is kind of what I was getting at with the C++ bits at the end.

                        When many people see C++ now, they think “ewww” unsafe. But the point is that if the C++ is generated from the Python “model”, then it retains its semantics!

                        As the post says, you can’t express use-after-free, double-free, or any kind of memory unsafety in Python, so the generated C++ won’t have it.

                        I guess it’s hard to explain without examples …

                        1. 1

                          Whoa - do you have anything else to share about a project like that? Any posts or anything?

                          This is the exact approach that I’m taking with a programming language that I’m developing. It feels like a workflow that actually has a ton of potential, especially for people who care about quality (that’s how I ended up thinking about this).

                          1. 1

                            Unfortunately no this wasn’t an open source project and I’m not able to say any specifics about it.

                            Your project looks really cool though! I’d like to add it to my list of languages implemented in Rust if that’s alright with you!

                            1. 2

                              Ah, I understand. Adding to your list is cool with me!

                      2. 2

                        This pattern of implementing things in a higher-level / easier language and then lowering for performance is also a common one in the computer vision space!

                        Why not implement in a high level but also performant language like Rust, Ocaml, Swift, etc?

                        1. 6

                          Nothing beats the expressiveness of using a DSL or a language that’s more suited to a particular domain. The languages you mentioned are all general purpose, which means they have a ceiling on how expressive they can be for any given domain.

                          1. 4

                            Yes exactly, thank you for the great answers! :) That’s what I meant in the post by by “getting leverage” if the “middle language” fits the problem domain.

                            I find that if you program mostly in one language it’s hard to see this … You “think” in that language; it becomes your world. But if you use many languages then you always see the possibility of fitting the language to the domain more closely.

                            1. 1

                              Sure, but writing in one of them has got to win over writing in python/Ruby first and then rewriting in C++…

                              1. 5

                                Maybe. I know this was in a reply to a comment talking about writing both versions, but this article is about generating the lower-level code. So it’s not being implemented twice.

                            2. 2

                              I don’t do computer vision stuff anymore, but the answer is almost certainly lack of libraries. MATLAB and OpenCV have a lot of APIs that any other language would need to match to be usable, not to mention the amount of existing research code in MATLAB or OpenCV which you just “just use” if you’re working in the same language.

                              1. 3

                                Also I was doing this work ~8 years ago, in 2014, so Rust wasn’t even 1.0 yet.

                          1. 25

                            I laughed at the headline since if you look at my open source libraries you’ll find a few files bigger than that: https://github.com/adamdruppe/arsd/ simpledisplay is 21.8k, nanovega.d is 15.1k, minigui.d is 14.4k, cgi is 11.1k…

                            I find larger files easier to work with than collections of smaller files, all other things equal, and I like having complete units of functionality.

                            But “all other things equal” does a lot there - the article’s description of “It looked like the entire file would execute through from top to bottom”… That’s what is really scary: not the size of the file, but rather that this appears to be a large single function. See, if I open simpledisplay.d, I’m not looking at the whole file. I’m just interested in SimpleWindow.close() or EventLoop.impl. The rest of the file isn’t terribly important; I open it, jump straight to the function I want to work on, and do what needs to be done. Then the individual function is pretty ordinary.

                            So I push back against file size by itself as mattering - a file is just a container. You actually reason about functions or classes or whatever so that’s what you want to keep easy to follow (and note that smaller is not necessarily easier to follow, I also prefer long, simple code to short, clever code, and I’d prefer direct local use to indirect things through multiple layers).

                            1. 9

                              I find larger files easier to work with than collections of smaller files, all other things equal

                              That’s interesting, I’m very much the opposite: I try to keep my source files under 500 lines, and each file has a specific purpose like one class, or a set of constants used in one module. Makes it a lot easier to jump to a specific part of the code, by just clicking on a filename or tab. And when I search I’m limited to the appropriate context, like the specific class I’m working on.

                              What is it you prefer about single big files?

                              1. 8

                                I’m also team big files. I hate how many subjective decisions you have to make when you split things across files “Hey we split up foo and bar, now where do we put this function that was used by both foo and bar? Into foo.js, bar.js, or helpers.js?” or “Hey do we group models together and controllers together, or do we group by feature?”.

                                Whatever organizational decisions you make, some of them will ultimately prove unsatisfying as your codebase evolves and you’ll face the constant temptation to spend a bunch of energy reorganizing, but reorganizing your code across files doesn’t actually make your code more modular or more adaptable or improve it in any way other than maybe making it a little bit more navigable for somebody whose muscle memory for navigating codebases revolves around filenames.

                                I default to large files because it requires the least energy to maintain.

                                1. 7

                                  I’ve had this idea for a while - why can’t a filesystem or text editor support “views,” or different groupings of the same underlying files. Example: view code by business function, or view code by technical concern e.g. “show me all web controllers.”

                                  1. 2

                                    It seems what you really want is to store all “source code” in a database instead.

                                    When you think about it, how can it be possible that storing program code in a bunch of plain text files (ASCII, UTF-8) is in any way optimal for comprehension and modification? Text files are very much a least-common-denominator representation. We continue to use it because of the ecosystem of operating systems, version control, text editors and such allow us to use and interchange this information. So there is a very good reason why they persist to this day.

                                    But I can imagine some kind of wacky Matrix-y (in the William Gibson, Vernor Vinge sense) 3D representation of programs, which makes great use of colored arrows, shapes and more to represent program operations and flow.

                                    Do I have the slightest idea of where to start making such a programming “language”, and what exactly it looks like? No, I do not. Until we have better 3D systems (something akin to a floating hologram in front of me), that allows me to easily grab and manipulate objects, I don’t think I’d want to use such a system anyway. But this is the direction I think things will go in… eventually. That will likely take a long time.

                                    Also, do we want to design a programming system that is optimized for human comprehension? Or something that is optimized for AI to use?

                                    1. 2

                                      Also, do we want to design a programming system that is optimized for human comprehension? Or something that is optimized for AI to use?

                                      Well, my vote is always for humans. I have no stock in AI-produced code every being a good thing.

                                      It seems what you really want is to store all “source code” in a database instead.

                                      Actually now that I think about it, NDepend is pretty similar to this. Warning: that page autoplays a video with sound.

                                      1. 2

                                        It seems what you really want is to store all “source code” in a database instead.

                                        So…Smalltalk? Lucid Common Lisp?

                                        1. 1

                                          Those are heading in the right direction, but I’m thinking about something more comprehensive. The link from /u/amw-zero about NDepend is very interesting.

                                    2. 3

                                      I’m not sure all or even most of these decisions are subjective - I think that ideally one would want to reduce coupling throughout, and to limit the visibility of implementation details.

                                      I tend to think in terms of build system DAGs - it profoundly annoys me when everything needs to get rebuilt for no actual good reason. Which is another reason to prefer smaller files, I think - less rebuilding of code.

                                      1. 3

                                        I agree. For one, I don’t think the decisions are subjective or objective in itself . But the fact that I do have to spend time thinking about code before I start is a clear benefit to me, not a disadvantage. Yes, sometimes it’s annoying, but mostly in pays off in, as you say, simpler code, clearer boundaries, less stuff tied into one big implementation.

                                        1. 2

                                          Splitting things into classes or modules can limit coupling/visibility. Some programming languages enforce one-module-per-file, but many (golang, ruby) don’t and in these languages there is no encapsulation benefit to putting things in different files.

                                          Optimizing the build is a good point, though. If that’s the criterion for file divisions, and not subjective developer feelings about what belongs where, that eliminates the problem for me…

                                        2. 1

                                          At some point in my career, I realized I had crossed a threshold where the writing & testing of the code was no longer the hard part: the hard part is organizing the code so it “makes sense” for what it’s doing, and I’ll be able to figure it out in 5 years when I come back to it.

                                          My mental line is 500 lines, too. Once I hit that, and I don’t immediately know how to break it up, it’s usually a sign that I need to take a hike and think about the structure at a higher level. Most of the time, this mental refactoring unlocks a lot of future features, and the invested “thinking” time pays itself off multiple times over.

                                          (None of this is a new insight, btw. I think it’s been written about since before the transistor.)

                                        3. 3

                                          What is it you prefer about single big files?

                                          Basically everything. It is easier to find what I’m looking for, since I can just search inside the file rather than having to find more. Perhaps if I used an IDE and project files I’d feel differently, but I don’t. And even if I did, sometimes I browse projects online, and online, you often click links that lead to single files to see in the web browser. So it is easier to work with here and easier to browse online. It is also easier for users (which includes me doing a quick ad-hoc build or test run): I can say “download cgi.d and list it on your build command” and it just works for them, no complication in mirroring the directory and figuring out which list of files belong in the build, etc. D’s encapsulation is set at the file layer too, so I can actually define smaller, better defined API surfaces this way than with a variety of files, since the implementations are all wrapped up, without being tempted to expose package protection or similar to share bits that need to be shared across files (or worse yet, marking something public because I need it from a different file in my own project instead of committing to supporting it long term to the users, which is what I think public SHOULD me).

                                          When working with other people’s projects, I find the file organization almost never helps. I can never guess where something is actually found from the directory/file organization and just have to grep -R it.

                                          So I believe in the old gmail slogan: don’t organize, search! And then you start working on a more abstract level - classes, functions, etc. - instead of files anyway, so just take one more complication out of the way.

                                          1. 0

                                            Perhaps if I used an IDE and project files I’d feel differently, but I don’t.

                                            It’s not just in IDEs. Any good programming editor ought to offer a file hierarchy view and support multi-file search. I can’t even imagine doing nontrivial coding without that, just like I can’t imagine not having Undo.

                                            I don’t mean to sound condescending, but it really is worth it to look into more powerful tools.

                                            1. 1

                                              What possible benefit could I get from merging my file browser into my editor? I have a file browser, I have an editor, they know how to talk to each other.

                                              1. 0

                                                In the magic land where your file browser works as well with your editor as in an IDE, I’m sure you are correct. 🦄

                                          2. 2

                                            I generally like the large file as well, if I don’t have really good navigation in my IDE, because it puts that much more within easy reach of the search function of my editor. And since I spend a lot more time looking for and reading code than jumping confidently to places in a codebase that biases me to wanting longer files.

                                            1. 4

                                              Does your IDE not have good ‘search this entire project’ support?

                                              1. 1

                                                Yes, thus my statement “when I have good IDE navigation support.” The logical conclusion of that is Smalltalk where there are no files. But if I am sitting in a terminal with cli tools and vi, large files are easier since I don’t have to keep Ctrl+z’ing to run grep and fg’ing again.

                                            2. 2

                                              There’s no right / wrong answer here, because obviously people’s individual brains are different. But lots of small files absolutely kills my productivity, because working on large pieces of functionality ends up requiring changing 5-10 files. There’s no good way to look at 10 files simultaneously, I don’t care how large your monitor is. So the benefit of larger files is that all of the code that I need to understand something is localized within something that’s on my screen right now, and it’s pretty easy to use something like the sidebar in Sublime or VSCode to scroll quickly to the part of the file that you need. Or text search for a specific function name to jump right to it. The benefit is not really needing to do anything to find the code that I need.

                                              Also:

                                              Makes it a lot easier to jump to a specific part of the code, by just clicking on a filename or tab

                                              This isn’t unique to the small-file approach, if your IDE / editor has “jump to definition” support, it works just as well within a file. Like I said, while this can be subjective and you may prefer one way or the other, I find this often with people who prefer small files - there’s no actual tangible reason or benefit, it just feels more organized (to proponents) when code is factored into small pieces.

                                              It may be a limitation of our tools, but I find too many files to be a cognitive cost. After a while I have too many editor tabs open, I can’t get to the part of code that I wanted without backtracking, etc. And, what is the downside of larger files? “Large things are bad” is not an axiom. “Large files are bad because they are large” is circular logic.

                                              All that being said, I don’t care all that much. I can navigate around most codebases whatever the structure.

                                              1. 2

                                                There’s no good way to look at 10 files simultaneously

                                                There’s also no good way to look at 11k lines simultaneously :)

                                            3. 7

                                              The problem is not, in my experience, large files, but the lack of separation of concerns. Large file sizes can be a symptom of a lack of separation of concerns but they’re the symptom, not the problem. I started work on clang in 2008 because I was working on GNUstep and wanted to use the shiny new Objective-C features that Apple had shipped. Apple had their own fork of GCC and no one merged their changes into the main branch[1] and so Objective-C on non-Apple platforms had a NeXT-era feature set.

                                              I looked at GCC to see how much effort it would be to update it. All of the Objective-C code in GCC was contained in a single file, objc-act.c, which was around 10K lines. It didn’t have any clear separation between the compiler stages and it was littered with if (next_runtime) everywhere. Some of the new features needed a new runtime, so all of those would need auditing and extending to provide a different implementation and become exciting switch cases.

                                              At the time, clang had mostly working codegen for C (it miscompiled printf implementations, but a lot of C code worked). It also had parsing and semantic analysis support for Objective-C, but no code generation. I started by adding an abstraction layer separating the language-specific parts from the runtime-specific parts. That’s still there: there is an abstract CGObjCRuntime class with a bunch of different subclasses (Apple has two significantly different runtimes and a bunch of different variants of the newer one, so has made a lot of use of this abstraction). For a while, clang had better support for Objective-C on non-Apple platforms than on macOS.

                                              Clang now has a bunch of source files that are larger than objc-act.c, but they’re cleanly layered. Parsing, semantic analysis, and IR generation are all in separate files. Objective-C runtime-agnostic IR generation is mostly in one file, Apple runtimes in another, non-Apple runtimes in a third. If you want to navigate the codebase and modify the Objective-C support, it’s easy to find the right place.

                                              [1] The FSF used to point to Objective-C as a big win for the GPL. I consider it a great example of failure. NeXT was forced to open source their GCC changes but not their runtime, which made the changes useless in isolation. Worse, the NeXT code was truly awful. If NeXT had offered to contribute it to GCC, I strongly suspect that it would have been rejected, but because the FSF had made such a big deal about forcing NeXT to release it, it was merged.

                                              1. 4
                                                andy@ark ~/d/zig (master)> wc -l (find src/ -name '*.zig') | sort -nr
                                                 186923 total
                                                  23226 src/Sema.zig
                                                  11146 src/AstGen.zig
                                                   7805 src/codegen/llvm.zig
                                                   6745 src/clang_options_data.zig
                                                   6716 src/link/MachO.zig
                                                   6586 src/translate_c.zig
                                                   6359 src/arch/x86_64/CodeGen.zig
                                                   6187 src/type.zig
                                                   5554 src/Module.zig
                                                   5247 src/value.zig
                                                   5181 src/Compilation.zig
                                                   5171 src/arch/arm/CodeGen.zig
                                                   5134 src/main.zig
                                                ...
                                                

                                                shrug

                                                1. 1

                                                  Maybe some of those source files are too big and ought to be broken up into smaller subcomponents?

                                              1. 1

                                                There’s probably a happy middle ground in between one-file-per-function / object and 11k LOC mega disasters. For example, if a task really just takes 3k LOC, then let it be just that, no need to break it up artificially just to adhere to some dogmatic line limit.

                                                That’s kind of the point of the The Life of a File talk by Evan Czaplicki.

                                                1. 4

                                                  This is just so awesome and inspiring to read. I want to first share, I’ve never ever been interested in building a programming language or in PL theory. I really thought it was a solved field, and we’re just making incremental improvements. But a few things recently have led me to think about the workflow described here, that being creating a language at the center of your workflow which is a DSL for your architecture.

                                                  Again, as someone who had no prior interest in PL design, this is the most important concept for me, and it’s the one that I think might actually be compelling for other people too:

                                                  Oil is many times smaller than bash in terms of its source code.

                                                  Even in the most well-factored architectures there can be both boilerplate and cognitive overhead. Take something simple like REST vs. GraphQL in a web app. Whichever one you choose, you have to write a whole bunch of code for each new piece of data that you add to the domain model. That’s code that has nothing to do with the domain, aka “accidental complexity.” Building a language allows you to generate that code from a specification of the essential complexity alone (or at least your approximation of that ideal via your language design). This is the “two halves” that are referenced in this post: the domain language, and the specifications that use that language.

                                                  I totally agree with the author, I’d rather focus on the specification level, i.e. focusing on the essential behavior of the application. And modern web development is full of nothing but tedium and boilerplate. There’s a push toward simplification of architectures again (e.g. LiveWire / Hotwire and moving back to more work on the server), but this still doesn’t seem like the simplicity ideal.

                                                  So, I started playing around with creating a language based on that idea, with a goal of building web applications. It’s still really immature, so I almost feel guilty bringing it up, but why not: https://github.com/amw-zero/sligh. Having a language to express the core specification of an app opens up a lot of doors, like generating a single property-based test that checks that the generated code is semantically equivalent to the specification. My thinking is that this can eliminate a ton of effort with testing as well, since I believe so much testing effort is spent on testing state spaces that are much larger due to the increased number of concerns that the implementation level has. This of course isn’t a new idea, formally verified projects such as sel4 have been verifying that implementations refine / simulate specifications for years.

                                                  Anyway - really cool to see someone thinking about and sharing a similar idea, and have it work out on a larger project. Good luck with the funding goal and keep posting!

                                                  1. 3

                                                    Yes I am a stickler about code size! I guess you could call me traumatized from working with hundreds of thousands of lines of C and C++ professionally …

                                                    The funny thing is that we think of these things as “DSLs” now, but eventually they will just become “programming”.

                                                    It used to be that a “for loop” was an exotic concept in “automatic programming” (I should dig up some citations for this). Assembly language was “manual programming”, and “for loops” were magic that saved you all this boilerplate !


                                                    Yes the web space is very interesting right now in terms of language design. (And I think underrepresented on lobste.rs) It’s fascinating to me how many new language projects have sprung up – Svelte as you mention on your page, Elm, Hack on the server side, etc.

                                                    I also find the web very Unix-y in terms of its combination of DSLs – HTML, JS and CSS all interleaved. And now TypeScript and more.

                                                    I’d definitely like to read some blog posts about how the language is designed! And particularly comparisons to other solutions in the space. I found that these kind of surveys of other projects really clarified my thinking about the shell, and what I want to do. Explaining and defending it in lobste.rs / reddit / HN threads definitely makes you sharpen the ideas and arguments ! :) It’s a lot of work but it’s been worth it.

                                                  1. 11

                                                    I’ve been learning Rust the past couple weeks strictly for hobbyist reasons. I’m coming from the dynamic typing world of Python and JavaScript. While I’m familiar with the strongly typed paradigms of C and Java, I figured spending my time in Rust would be more beneficial.

                                                    There are a lot of individual things I like in Rust, but programming in it in general feels like I’m trying to learn a new sport and I can’t quite seems to get my sense of balance. E.G., “I’ve been out on the water a hundred times now, so why can’t I comfortably stand on the surfboard now?” type of feeling. If that makes sense.

                                                    I’ll keep plowing forward with it though. I’ve got The Rust Programming Language book from No Starch Press, and I have been spending a lot of my time in the Rust Book online. I’ll find my balance, I just wish I could find it sooner than later.

                                                    1. 13

                                                      While I’m familiar with the strongly typed paradigms of C and Java

                                                      C is barely type at all, and Java is a weird hybrid of a poor type system and just being dynamically typed anyway. I wouldn’t call either “strongly typed”.

                                                      1. 4

                                                        C is barely type at all, and Java is a weird hybrid of a poor type system and just being dynamically typed anyway. I wouldn’t call either “strongly typed”.

                                                        Maybe I should have chosen “static” instead, as I also referred to “dynamic” typing rather than “weak” typing. Or maybe type safety would have been even a better comparison? Shrug.

                                                        1. 22

                                                          I wouldn’t worry too much, internet fights about what counts as “static” or “strong” or “typed” are generally not worth your time.

                                                          1. 9

                                                            The key here is that there is no single definition of “strong” or “static” types. It is a spectrum. For example, Rust has algebraic data types, C++ does not. They are both static and strong in the broad sense, but algebraic data types mean that you can express more things at the type level.

                                                            It’s not like saying “I’m familiar with C, so I know everything that can be done with static types,” is accurate, I think is the point of this response.

                                                            1. 2

                                                              It’s not like saying “I’m familiar with C, so I know everything that can be done with static types,” is accurate, I think is the point of this response.

                                                              Indeed.

                                                        2. 6

                                                          I get what you’re saying and if I may suggest two things which have helped me pick up rust: writing a small but complete CLI application and watching live or recorded streams (for instance Ryan Levick or Jon Gjengset are formidable tutors)

                                                          1. 4

                                                            Maybe you should listen to your gut. Rust is a relatively new language, it is not clear it will stand the test of time.

                                                            1. 8

                                                              That’s fair. However, even though I’m struggling to find my balance, I find learning it exciting. I think I’d rather learn as much of the ins and outs as I can and walk away with an informed opinion than bail early. At least I’m having fun, even if I keep falling off the surfboard.

                                                              1. 6

                                                                I hope you stick with it. It is a relatively hard-to-master language, IMHO. Java, or an GC language doesn’t force you to think about ownership the way Rust puts that front and center. The ownership model has a dramatic effect on the kind of datastructures you can and should design. And it effects the way in which you use and share data across the entire application.

                                                                I believe the tradeoff is worth it, because you can catch certain classes of memory safety bugs at compile time, which can lurk undetected for years in other codebases. These are the kind of bugs that cause big problems later.

                                                                1. 2

                                                                  I hope you stick with it.

                                                                  I plan on it.

                                                                  It is a relatively hard-to-master language, IMHO. … The ownership model has a dramatic effect on the kind of datastructures you can and should design. And it effects the way in which you use and share data across the entire application.

                                                                  This might be the balance I’m struggling to find. A lot of my compiler errors are related to owneship and I keep having to come back to the docs to remind myself how it works.

                                                            2. 2

                                                              I made a similar jump. It informed how I learned TypeScript and then made a whole lot more sense once I learned Haskell. Some tidbits that would’ve helped me follow.

                                                              Static typing, especially in something like TypeScript, can be thought of as an elaborate linter. At times it can be restrictive, but surprisingly often it’s leading you towards better code.

                                                              Strong static typing as in Rust’s case is like static typing but where your types are accurate to what will be there at runtime, so you’re probably going to need to do some validation or casting at your application boundaries. In Rust’s case also there’s no duck typing, you can’t just carry around data the compiler doesn’t know about at compile-time.

                                                              Traits are interfaces for shared abstractions across types. I really struggled with this until I saw typeclasses in Haskell. I think learning something relatively simple there like Functor can be instructive. It’s not entirely unlike extending prototypes in JavaScript, but here the compiler can use that information at compile-time to let you write functions which constrain input to support certain things, like for example an Eq constraint would mean “I’ll accept any input for which I can test equivalence”.

                                                              1. 1

                                                                There is always duck typing if you want it, in any language. The best way in rust IMO is trait objects, but you can even get Java-style dynamic typing if you want (with possible a single use of unsafe in the library providing it).

                                                            1. 24

                                                              In the “Why PHP?” Section:

                                                              The answer is simple: because it was there. I’m self-taught, and I don’t have much in the way of formal training. Except maybe for the occasional online course I’ve taken, I have no piece of paper with a stamp on it from a prestigious university that says I can tell computers what to do.

                                                              This is the crux of it, and there’s a lot of implicit things going on in these sentences. First off, there is a clear jab at people who do have degrees and formal training. “Prestigious” is used pejoratively and sarcastically here. This wasn’t the author’s path, so they resent people who did take that path. Of course when you are self taught, you skew towards any tool that can get you up and running the easiest and quickest. Note how I said “up and running” - it’s not the tool that is best in the long run, it’s the tool that gets you a picture on the screen the quickest. By the way, there’s value in that too, but I wouldn’t base all of the dimensions of my evaluation just on something “being there.” Availability is valuable, but it’s not the only valuable quality.

                                                              This is a viewpoint that’s very common in the industry, I personally meet a lot of people who share this mindset. I don’t think it’s entirely wrong, but I think it’s a very limited way of thinking, and the people who hold it tend to be self-righteous like this. I understand that PHP might have been your path, and it might have worked for you. But a tone like this reeks of criticizing and minimizing other people’s path. I get that they feel defensive because people are attacking PHP, but I don’t think that’s causing this philosophy, I think this is many people’s true philosophy under the hood, this was just an excuse to write about it.

                                                              Where does this philosophy come from though - can anyone name any popular programming language that was designed for “CS graduates?” Python? Java? Javascript? These are the most pragmatic and un-academic languages on Earth. The pragmatists and proudly un-educated have won, why are they claiming to be the ones that are being persecuted?

                                                              Btw, if it’s important to anyone, I don’t have a CS degree, I studied Electrical Engineering. I definitely took CS electives, but I also consider myself mostly self-taught in terms of actual programming and CS. But I don’t knock the academic side of CS, on the contrary I think it’s responsible for every single good idea that makes its way into “practical” programming languages.

                                                              1. 12

                                                                I don’t necessarily have a problem with people using something that gets content on a screen quickly. But I don’t accept the excuse that self-taught means you can’t or shouldn’t grow beyond that. I’m self taught. I don’t even have a college degree and yet I learned Haskell. I can write Rust code. I started out in PHP but I outgrew it eventually. Anyone who can become an expert in PHP can do the same.

                                                                It’s fine to get payed to write PHP. There is code out there that needs maintaining in PHP. But PHP earned it’s reputation as a deeply unsafe language to develop in and even with the improvements the language has made much of that unsafe core still remains.

                                                                1. 5

                                                                  While the author of the article is being contemptuous to those with more educated backgrounds, I think you’re doing a bit of the converse here. Programming is as wide as humanity itself; if there’s a way for a computer (for some definition of computer) to accept input and provide output, I can guarantee you that someone will have probably programmed it. There doesn’t need to be a single, good path to programming. Whether your path involves writing PHP, unsafe C, or Haskell, it doesn’t really matter.

                                                                  1. 3

                                                                    It’s difficult in a comment forum to give an appropriately nuanced take on stuff like this. I didn’t intend to come off as contemptuous. If you get hired to help maintain a PHP codebase then the responsible appropriate thing to do is to work on PHP code. There is no shame or condemnation for it.

                                                                    Sometimes though I think people get stuck or pigeonholed as “PHP developer” or “Python developer” and never learn other tools or approaches. I want to encourage those people that they can be more than just $LANG developer. There are better tools than PHP out there that you can use when you get the opportunity. Learning to protect yourself from the flaws of a given language is a valuable skillset. There is no shortage of work for people who became experts in avoiding the pitfalls.

                                                                    But ,when you have the opportunity, it is hugely valuable to be able to choose a language with less pitfalls. Where the defensive programming is less about defending against the language itself and more about defending against the environment your software has to run in. Being able to choose those languages is also a valuable skillset that no one should feel is out of their reach.

                                                                    1. 1

                                                                      But ,when you have the opportunity, it is hugely valuable to be able to choose a language with less pitfalls. Where the defensive programming is less about defending against the language itself and more about defending against the environment your software has to run in. Being able to choose those languages is also a valuable skillset that no one should feel is out of their reach.

                                                                      Great explanation of this idea.

                                                                      1. 1

                                                                        It’s difficult in a comment forum to give an appropriately nuanced take on stuff like this. I didn’t intend to come off as contemptuous. If you get hired to help maintain a PHP codebase then the responsible appropriate thing to do is to work on PHP code. There is no shame or condemnation for it.

                                                                        I figured which is why I tried to keep my reply soft. I agree with everything you just said.

                                                                  2. 11

                                                                    Also, a CS degree doesn’t teach you programming anyway. It’s not meant to. It teaches you CS (or at least tries to). You probably self teach some programming along the way but it’s harly a focus of coursework.

                                                                    1. 5

                                                                      I don’t think that’s universally true. The first two years of required classes for a CS degree at the universities around me (US) were heavily focused on programming (Java… C++…), and failing any of those would have meant no CS degree.

                                                                    2. 8

                                                                      But a tone like this reeks of criticizing and minimizing other people’s path.

                                                                      I don’t entirely agree with your interpretation, but I will note for sake of irony that this is more or less how un-credentialed (in the sense of not having a degree in CS or other “relevant” field) developers feel for pretty much their entire careers. There’s a huge and powerful trend in tech hiring of prioritizing people who have a degree from one of the handful of trendy top universities, and a feedback loop wherein people who work at major companies help develop and teach “how to pass our interview” courses at those universities. The result is that if you are not someone who has a CS (or other “relevant”) degree you are constantly the odd one out and near-constantly being reminded of it.

                                                                      I still feel this coming up on 20 years in to the industry and with a résumé that largely lets me avoid a lot of the BS in interviewing/hiring.

                                                                      1. 4

                                                                        I still feel this coming up on 20 years in to the industry and with a résumé that largely lets me avoid a lot of the BS in interviewing/hiring.

                                                                        (I’m hoping this comment isn’t too off-topic.) I certainly agree. I myself come from one of those trendy elite CS universities (though it’s been a good while at this point) and am well credentialed, but I’ve started to use large numbers of junior engineers out of good schools to usually be a light negative signal when applying for a company. The culture of hiring in software is such that companies often overselect for credentials while ignoring effectiveness, at least in my opinion.

                                                                        1. 2

                                                                          There’s a huge and powerful trend in tech hiring of prioritizing people who have a degree from one of the handful of trendy top universities

                                                                          This depends entirely on your experience. I’ve never seen this trend, I’ve seen quite the opposite - a large chunk of people I work with don’t come from a CS or engineering background. Nor do I see anyone being hired over someone else because of where they went to school.

                                                                          1. 3

                                                                            The fact that you’ve never seen FAANGs go on-campus at certain universities (but not others) to recruit, help develop “how to pass the interview” curriculum to be taught at certain universities (but not others), etc., doesn’t mean that it doesn’t happen or that it doesn’t have an effect both on their resulting workforce/company culture and on everyone who emulates their hiring (which is unfortunately a large chunk of the industry).

                                                                            1. 1

                                                                              Let me repeat what I said:

                                                                              This depends entirely on your experience.

                                                                        2. 7

                                                                          can anyone name any popular programming language that was designed for “CS graduates?”

                                                                          My glib answer: yes. Go. From Rob Pike, the creator: “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”

                                                                          More seriously, I think this “self-taught persecution” attitude is related to imposter syndrome and the increasing credentialism in society. A former coworker of mine tended towards a self-defense attitude and I chalk that up to his not having a CS degree as a developer (he did, however, have formal training as a jazz musician).

                                                                          It’s also not as if PHP is alone in this hate—C is probably hated just as much, if not more, than PHP.

                                                                          1. 3

                                                                            Yet if you know C well, you’re probably seen as much better “programmer” then if you knew PHP well. But yeah, perceptions.

                                                                            1. 3

                                                                              Rent seeking isn’t hate. C dominates everything. So if you invent a new programming language, there’s only two paths to being successful. You can either (1) appeal to the new generation of young people to learn your language instead of C. That’s how PHP and Node did it. Or (2) you can run PR campaigns vilifying C until you’ve convinced enough VPs to convert their departments. That’s how Java did it.

                                                                            2. 4

                                                                              I agree with everything you said here. I even share your perception that many people seem to be insecure and/or defensive about not having a CS background or not really understanding some of the popular concepts we read about in blog posts, etc. Like you said: The “pragmatists” won- what are they worrying about?

                                                                              In some ways, computer programming is very much like engineering– engineering jobs/tasks/people fall on a wide spectrum of “how academic” from “glorified assembly line work” all the way to “indistinguishable from pure science research.” And attitudes similarly span that spectrum. That’s not a bad thing–just an observation.

                                                                              What’s extra frustrating to me is that it’s now turned a corner where if you do criticize a language like PHP, you’re seen as an irrational troll who just thinks you’re smarter than everyone else. It’s become anti-cool to shit on PHP, even though it’s still literally the least capable backend language being used today besides maybe Python (no async, no threads, no generics in its tacked-on type system, object equality is not customizable and will crash your program if you have a ref cycle, etc).

                                                                              1. 3

                                                                                As a developer that has experience building web backends in PHP but also some experience with Go, Python, Ruby (w/ Rails) and Rust, I wonder what language you deem capable as a backend language that still provides the same level of abstraction as, say, Laravel or Symfony. Rails obviously comes to mind, but what else is there (if Python w/ Django is out of the question)?

                                                                                1. 3

                                                                                  Keep in mind that I’m not trying to evangelize “the one true backend language” or anything like that. My main point was just to gripe that there are still (what I consider to be) legitimate criticisms of PHP as a (backend) programming language, but whenever I point them out as reasons that I might suggest someone avoid starting a project in PHP, I’m met with more skepticism and defensiveness than I think is justified.

                                                                                  The secondary point is that I truly believe that PHP is strictly inferior to other backend programming languages. What I mean by that is that we all work differently and have different preferences: some people will like dynamically typed languages, some will like statically typed; some like OOP, some like FP. That’s all great. Scala is a very different language than Go, which is a very different language than Clojure. But if you look at “modern” PHP projects and “best practices” advice, it’s almost literally the same thing as the “best practices” for Java 7 in 2010, except that PHP doesn’t have good data structures in its standard library, has no threading or async, no generics, etc. And if you compare modern PHP with a recent version of Java… oh, boy! Java now has ADTs, Records, Streams, and a few other really nice additions that make writing code a little less painful.

                                                                                  So, it’s not just that I think PHP is a bad language, it’s that it’s, IMO, a less capable subset of another language. If it were actually different, then I might just shrug it off as a preference thing. I mean, PHP even stole the class semantics right from Java (single inheritance, interfaces, static methods, abstract classes, final keyword, etc).

                                                                                  I know people love Laravel, but my contention isn’t that Laravel isn’t good (I don’t honestly have much experience with Laravel, but I have worked with Symfony). But Laravel is not PHP. I’m talking about the language. If there’s something written in PHP that’s so valuable to your project that you choose to work with it, that’s great. But in my opinion, the sane attitude should be one of “Well, I guess it’ll be worth it to deal with PHP so that we can use XYZ.” and not “PHP is a good language and @ragnese is just an anti-PHP troll. What backend language could possibly want async IO or easy fire-and-forget tasks, anyway?”

                                                                                  1. 3

                                                                                    I don’t like rails either for slightly different reasons. I would rather develop in Go if I’m creating a backend web service than Python, Ruby, or PHP. I don’t find that I usually need much more abstraction than say gorilla most of the time. And Go doesn’t suddenly surprise me with strange behavior as often.

                                                                                    1. 2

                                                                                      The person they’re asking definitely doesn’t use Go though, because of:

                                                                                      no generics in its tacked-on type system

                                                                                    2. 3

                                                                                      Phoenix in Elixir is pretty good — very batteries-included, high-velocity, and extremely good with async/concurrency/parallelism. I don’t know if “object equality is not customizable” applies, it’s immutable with value-based equality at all points, so…

                                                                                      The tacked-on type system is pretty awful (Dialyzer is well worse than, say TypeScript, mypy, or Sorbet) but I don’t think it’s strictly worse, considering what you get from the framework/library.

                                                                                      1. 2

                                                                                        Based on their complaints (“no async, no threads, no generics in its tacked-on type system, object equality is not customizable and will crash your program if you have a ref cycle, etc”), and assuming they’re not using a really esoteric language, I’m willing to bet they use Scala, Java, C#, or Rust. I’m definitely curious about this too.

                                                                                        Whether or not those have a web framework that competes with Laravel, I’m not sure. That’s also not the measure of success though, for example if people are working with a lot of services a monolithic web framework isn’t as important or even desired. That’s one other thing to consider here - I think it’s accurate to say that PHP is synonymous with building monolithic web apps, and not everyone builds monolithic web apps.

                                                                                  1. 1

                                                                                    Basically Out of the Tar Pit. Seems like a good direction to go down.

                                                                                    1. 2

                                                                                      Meteor provides a very similar model; clients subscribe to queries, and the results of those queries are replicated from the database to in-memory tables on the clients. It is indeed a very, very nice architecture.

                                                                                      1. 1

                                                                                        I always thought Meteor was interesting too. Why does it feel like it totally disappeared?

                                                                                      1. 6

                                                                                        I’m glad to see this option because I’m interested in declarative UIs in general.

                                                                                        On the other hand, a top problem with UIs (in Rust and elsewhere) is lack of accessibility. Getting a11y right is a difficult and time-consuming task, so it is understandable that new / experimental UIs are not able to prioritize a11y, but it makes actually using any of these UI frameworks for production software ethically questionable.

                                                                                        I suspect the Rust community in the near future would be better served by pouring effort into making one or two UI libraries accessible (perhaps druid, which is also declarative ui?) rather than making more and more UI libraries that exclude people. That said, if a shared accessibility approach like accesskit is able to make many different UI libraries accessible, that would be a very pleasant outcome, allowing more diversity in UIs while including people who rely on a11y.

                                                                                        1. 2

                                                                                          Hi! Author here. I would suggest you contribute to access kit (or similar) so I’d have something mature to use. cheers!

                                                                                          1. 5

                                                                                            Forgive me if I misinterpret your brief and casual comment, but this seems like an example of a toxic habit in the open source community: responding to criticism with “well, why don’t you fix it?”

                                                                                            I understand the impulse, and it’s not inherently bad. If framed well, invitations to contribute and improve software can be empowering. Among the strengths of FOSS are:

                                                                                            • the ability to study how a program works. This includes seeing where a11y concerns arise, and where they could be addressed.
                                                                                            • the ability to add fixes yourself. In a friendly community-oriented project, those fixes can easily be contributed upstream. Even given a hostile, uncooperative upstream, the community can exercise the right to fork and maintain their own fixes elsewhere.

                                                                                            This means that people who are interested in an issue like a11y can learn to program in a practical fashion, even if in a limited way just to “scratch their itch”, and make the software work for them. This sort of agency is impossible in the world of proprietary software, where you have no choice but to lobby the software company and hope they think helping you is profitable.

                                                                                            Unfortunately, such recommendations to write code yourself are often framed poorly, in an off-putting fashion that sounds more like “I do not care about your concerns and I am uninterested in welcoming you to the community.” Rather than reading like an invitation to make the world better for all, it reads like gatekeeping (if you can’t code, your opinion doesn’t matter) and dismissal.

                                                                                            This is especially damning in the context of accessibility, where sometimes participating in something like software development is physically impossible, because the tools necessary for collaboration do not take accessibility needs into account.

                                                                                            Right now, tools developed using your UI library would contribute to that problem.

                                                                                            1. 3

                                                                                              Hey, I’d love to do accessibility. The is just a really early version of this library. There’s also no internationalization yet. It’s totally an experimental proof-of-concept, and got more attention than I expected.

                                                                                              1. 2

                                                                                                Wait - you hijacked OPs post to talk about your agenda for accessibility, and they are the toxic one? Accessibility is a good thing. But your comment had absolutely nothing to do with their post. You were talking about accessibility in general, and guilt tripped a person trying something out in a new project.

                                                                                                They are right. If this is something that you are so passionate about, go ahead and fix the problem. Don’t put down other people’s work.

                                                                                                1. 1

                                                                                                  If this project had been posted without a software license, someone might have commented about repos lacking licenses being a general problem on GitHub. Would this have nothing to do with the project?

                                                                                                  1. 1

                                                                                                    Strawman argument, because that’s not what you did here. You didn’t reference the posted project in any way.

                                                                                                    Remember, it’s easy to criticize. Your comments are low-effort. If you want to improve accessibility, it’s not a very good strategy to criticize tiny proof of concept libraries. A better strategy would be to devote time, and most importantly code, towards your goal.

                                                                                          1. 2

                                                                                            Without any exaggeration, there is no platform that’s worse at building user interfaces than the default web. If you change the state of the app via a form, the entire screen re-paints. SPAs saved the web. You can’t even show a spinner without persistent process state. SPAs took the web from a platform where you just glue strings together to a platform for actual software.

                                                                                            1. 1

                                                                                              I don’t agree. Lots of websites are centered around showing some documents, more or less and they are not necessarily entire applications. Even then not reloading the whole page does not imply using an SPA.

                                                                                              1. 1

                                                                                                But it does imply that you’re not using the default browser behavior. Turbolinks is the classic example. The second you start keeping the page around and only modifying a portion of it, you’re admitting that you want more control over your client side state and that the default browser rendering behavior doesn’t work for you.

                                                                                                We can talk about what the best code pattern is for making it simpler because once you get into the world of client-side state inevitably more code is required. But that’s completely different than lying to ourselves saying that we’re using default web technologies.

                                                                                            1. 2

                                                                                              Ruby is an incredible language. The fact that it’s so closely tied to Rails is such a double-edged sword. No one would know what Ruby is without Rails, yet Ruby itself is so much more.

                                                                                              I don’t know why, but Ruby truly is the most joyful language to use for me. I don’t use it at work anymore, because I really prefer static typing at work. But, if I need to use a language as a bicycle of the mind, I always reach for Ruby. It’s as close to pseudocode as is humanly possible I believe, it has a great standard library, and support for trailing closures is so incredibly underrated even though some languages do also have it. Chaining functions also just feels like the best way to write code in my opinion as well:

                                                                                              1.upto(10)
                                                                                                .map { |i| i + 1 }
                                                                                                .select { |i| i > 2 }
                                                                                                .reduce(0) { |sum, i| sum + i }
                                                                                              

                                                                                              It will always be my favorite language to use for personal stuff and scripts.

                                                                                              1. 2

                                                                                                Even better, support for enumerable methods has improved over the versions. You can replace that whole .reduce with a .sum and assuming you swap the .select and .map (which I’m not assuming is the intended case here) you can use .filter_map instead. The brevity of the language while not being totally arcane is really wonderful.

                                                                                              1. 3

                                                                                                The content is great, and this is also one of the nicest looking blogs I’ve ever seen. It may be slightly too stylish, if that is a thing, but everything is still very readable so I can’t completely complain.

                                                                                                1. 2

                                                                                                  The most important reason to learn Haskell is that it’s rooted in formal logic. In my opinion, this is what we should be teaching in CS curriculums. I honestly don’t believe FP is the best way to write programs, but it’s the best way to analyze programs, because of its logical foundations.

                                                                                                  I wrote more about this here: Quality and Paradigm: The Assembly Language of Reasoning and the Domain-Specific Language of the Machine.

                                                                                                  1. 9

                                                                                                    I’m puzzled by what is driving the seemingly relentless churn in web development technologies.

                                                                                                    Surely economics would converge on a set of technologies and practices that both enable developers to leverage skills across many different clients, thus increasing productivity, and also ensures that clients have a deeper pool of developers to access for updates, rewrites etc.

                                                                                                    Instead is seems as if everyone involved is staring helpless at a whirling maw of seemingly pointless innovation, which can only be comprehended by hyperactive newcomers to the space that are quickly burned out, leaving smoking unmaintainable wrecks in their wakes to be replaced by a rickety structure of shining newness.

                                                                                                    1. 9

                                                                                                      I believe the root is pretty simple: we try and hide the difficulty of making software with convenient patterns and abstractions, but the core difficulty keeps poking through. Take the most recent hype-cycle that culminated with React. React was supposed to hide the complexity of updating a persistent, mutable DOM state with a declarative description of what the state should be.

                                                                                                      It actually does achieve that for the most part, but there is no way to avoid understanding how rendering and reconciliation actually work because you eventually either need to optimize performance or fix subtle bugs caused by implementation details. For example, this subtle point about useState initializing the state only on the initial render of the component can lead to subtle bugs. This just happened to me a couple weeks ago: you can’t initialize state with data from the network because it is temporarily not present, and you will be stuck with an undefined state. The answer is, of course, to avoid rendering this component with a conditional check higher up in the tree.

                                                                                                      It’s not tragic, but an example of how our abstractions never seem to fully get rid of problems. Once we realize that, we try and create new patterns and create a new hype-cycle. For example I see Svelte gaining some mindshare traction now. In fact, I even find the compiler-based approach appealing.

                                                                                                      My point is: we build really large logical systems, logic is inherently hard to scale, and we are still in the phase of the industry where we are seeking perfection and have hope. So we keep trying new things.

                                                                                                      1. 4

                                                                                                        This is probably it. A web app is inherently a distributed system (server and client) and an interactive system, neither of which are things taught in basic programming. Any abstraction that tries to hide either of these facts is just moving the complexity around.

                                                                                                        1. 2

                                                                                                          Thanks a lot for this reply. I am basically webdev illiterate (despite having had a site since the early 2000s) and I do realize that the interaction between user, network, browser and backend can be insanely complex. Your explanation clarified this a bit.

                                                                                                          1. 2

                                                                                                            I agree. We’re all hoping that the next tool is going to magically make the work easy, but the reality is that complex systems are complex and difficult to work with. If you’re trying to model a complex real-world business in software, there’s no real way around that.

                                                                                                          2. 4

                                                                                                            I’m puzzled by what is driving the seemingly relentless churn in web development technologies.

                                                                                                            Why do systems programmers have such a relentless churn of tools and programming languages? Why wouldn’t simple economics lead them to converge on a single set of technologies and practices and then keep them, unchanging, forever?

                                                                                                            And sarcasm/snark aside, one of the biggest drivers in frontend web development is the increasing push to have the browser become the universal GUI runtime, rather than having to maintain different apps using different UI toolkits and often different programming languages for every different operating system/device type.

                                                                                                            1. 2

                                                                                                              It’s a good question and I think the answers are something like those floated in the comments on this post https://lobste.rs/s/f0vwr5/most_websites_are_implicitly_designed

                                                                                                              1. 2

                                                                                                                Capitalism prohibits long-term stability of any tool provided in this market. To insure stability is to prevent profits from being made (be it in the form of support contracts, more “contractors” who have domain experience in a tool they’ve created to fix a problem of the market or something the middle).

                                                                                                                1. 2

                                                                                                                  I’ve said this often, but the problem with web development is not necessarily that it’s harder than other things, but it’s more tedious. And part of that is that people just can’t seem to stick to their frameworks and libraries for a certain amount of time. Yes, we all know that the browser landscape changes faster than kernel APIs, but I’ve hardly seen any “hey, we bumped our framework from 2.x to 3.x and it’s mostly a rewrite BUT WE HAVE A MIGRATION PATH”. Not looking at you, angular. No, for some reason it always needs to be a complete new thing, for seemingly no good reason.