 Someone just "Oh, hell, I'm just too lazy to write my own programming language" at me. I always thought that THAT was the lazy option, it seems to be infinitely more work to learn some insane build toolchain, navigate vestigial compiler flags, jump through the hoops of using and learning some framework so that after weeks of sifting through documentation you can build some half working thing that will have to be maintained across the temperament of some maintainer somewhere. How's that lazy 16 comments
@noa well yeah, if you're going to be building a language with tools you don't understand, that'll be a tricky ordeal.  @neauoire :cwy: :clippy: :blobsweats:  @neauoire I *do* kinda think you're better at design than a lot of folx, hehe. The not-inventing-a-lang option means you don't need to do any design work: you just need to solve the problems that come up from the toolchain etc as you go! @tty you could also iterate through the language design in a similar way to how you're learning a framework, the more you better understand the problem you're trying to solve, you can either learn some new library function, or shape the language to address that issue. @neauoire I wonder what it would be like if most people wrote languages instead of libraries. I think it would make sharing code a lot harder? And there's such a huge body of basic code needed just to make internationalization and accessibility happen, it'd be rough for each person to need to implement it themselves. And of course a language tends to need a community in order to survive & thrive, which might be a lot harder if everyone wrote their own langs. @tty I think it's the opposite, because so few people actually write accessiblity code due to heavy use of libraries, people don't know how easy it can be, or at least it could be if more people were actually working on the problem space instead of trying to connect ad hoc modules. @neauoire I'm surprised to hear you say so, actually! To me, the prospect of figuring out how to add unicode (or some other i13n scheme) and also all of the a11y that modern OSes provide to a uxn program sounds incredibly daunting! :o  @neauoire Depends on what you will be writing in your language of choice and what your deadlines are. I'm very glad I know Python because of its massive collection of high quality modules. There is no way I'm reimplementing all of that in a bespoke language. Also, good languages let you write good embedded domain specific languages, so making your own from scratch becomes unnecessary. Lisp is a famous example, but (G)ADTs in Haskell are IMHO even better. @neauoire fwiw, I also reject the word "lazy" in general. The author usually means something else. @neauoire using someone else's language for sure feels like gur path of least resistance compared to writing one's own, i don't think it's quite lazziness, but i recon some of gur early bumps in gur road are enough to deter allot of folks, especially in gur case of people wanting to use [LIBRARYGOESHERE] in their projects.  @neauoire but ughhh.... Then you'll need to learn the assembly/binary for the target architecture...? And if you use llvm to handle that you'll still need that ir building blocks and write them in c or something... Often to me if I needed to use a lightweight script I just use some lua and call it a day  @neauoire Thatβs akin to inventing a speaking language with all the grammatical rules to go with it! Plus letters, slang, getting a keyboard (virtual & physical) designed & made, etcetera. Both take up far more resources & time than people realize. Just as it is more efficient (time & energy wise) to use an established language to communicate, so it is more efficient to use an established programming language. |
Gregory's Server
@neauoire i would love to write a language, but currently my programming is accumulated rather than learnt as such, and every time ive tried making a language more complex than brainfuck ive had to put effort into learning tooling that ive just not bothered with before. so the latter is something of a prerequisite to the former