After seeing this post I just thought it would be an interesting discussion. Obvious limits apply of ‘you have to have at least some documentation,’ so I’m not talking about something where there is none, and the feature set minimum would be less a question of whether you could complete X arbitrary project and more ‘does the feature set make it easy to do everything?’ You could essentially write everything in assembly, but would you want to?

On an arbitrary 1-10 scale, (1 being ‘I’ll build the features from nothing as long as the docs are good’ and 10 being ‘Who needs documentation? I’ll happily read through the undocumented code until I find the ones that make magic happen.’) where do your preferences lie?

Oh, and integers only. You can be nuanced in your ideas but no 5.5s allowed.

  • Rimu ( rimu@piefed.social ) 
    link
    fedilink
    English
    arrow-up
    7
    ·
    1 year ago

    Without good documentation it’s impossible to do anything.

    Frameworks and libraries (and their docs) are more important than language features, because who wants to reinvent the wheel?

    Community is more important than anything. No point building something if you can’t find help or collaborators or people who make frameworks & libs.

  • TehPers ( TehPers@beehaw.org ) 
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    1 year ago

    For programming languages? I don’t need many features as long as what exists is enough to do everything I need. In fact, the less, the better (or you end up with C++'s regex/Python’s urllibN/etc).

    I guess that means that I’d end up more on the documentation side, though my reason isn’t because I want the most documented language of all time, but because I want the fewest built-in features.

    This is why I mostly write Rust when given the option. I write a lot of Python, but I hate the standard library so much. There’s the urllib stuff, plus there’s a bunch of deprecated stuff in the base64 module, plus I can’t stand Python’s implementation of async (coroutines are cool but asyncio is miserable to use imo).

    Edit: Oh, and nobody’s giving integers only when nuanced answers are more interesting to discuss.

  • schmudde ( schmudde@beehaw.org ) 
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    3

    Coming from Lisp, people are always expanding and updating the language.

    But also some Lisps, like Common Lisp and Emacs Lisp, are byzantine. So documentation is pretty important.

  • Depends on the intuitiveness of the UX. When it comes to API, as both a developer and an end user I would rather have it fully documented than have to spend hours digging through forums to figure out if something is even supported.

    With that said, as much as I hate it, features lead to sales. When someone is shopping for a product they look at what it can do and whether it meets their needs. They don’t care how well documented something is. If it can’t do what they need they will look elsewhere.

    1. I already know multiple languages with an okay feature set and great documentation. I’m only going to spend the time and effort learning a new language if it’s something legitimately new with a compelling feature set. Bad documentation is just a natural cost of being on the cutting edge. I might find the lack of documentation frustrating but without good features I won’t engage at all.
  • Bad documentation was one of two reasons for me to steer clear of Iced and looking at Slint instead. The other being that the feature set didn’t match but not as in less features but a different focus.

    Edit: GUI frameworks, but the same goes for languages. Or even moreso, since at least half of a language is the concept/philosophy.