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.
- 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.
A feature without quality documentation is a feature I cannot rely upon. (Or if I wrote it, one that I cannot expect other people to use.)
When faced with such things, I avoid them, and implement richer features myself using basic ones that are well documented.
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.
I’m going to save this because it sums up the problem perfectly
Feature richness as a user, documentation as a developer.
Oh, and integers only.
As can be seen, nobody reads the documentation:-P
Nah I ignored that because responding with just a number is boring and leads to no real discussion. A poll would have been better if that’s what was needed.
I likewise did not respond with just a number, bc this way was funnier 🤣
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.
Feature thoughtfulness.
This. I’d rather have fewer, better working features.
3
If the documentation is good enough, I don’t mind implementing the lacking features if needed. But I work in small codebases in R, which have good docs and is feature rich, so maybe I’m a little spoiled.
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.
The 2 most important things in a language for me, is that everything must be an object, no real numbers and that 2 + 2 = 22
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.
Like all things in life there is balance that must be maintained. A language with few features but super detailed documentation is ultimately going to be less useful than a language with more features but not as strong documentation.
Obviously you want perfect documentation and full features but it just isn’t realistic so you have to balance things to your requirements. So I went with 5 because the balance between language features and documentation is going to change based on requirements.
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.
Write the code in such a way that you need minimal, if any, documentation. Takes a bit of extra thinking, but once you start leaning into it, it’s really nice.
