That is an increase in complexity of code and time of implementation. I lack the knowledge to advise you on that, as I am not as versed in the usage model as you are.
Actually, neither of those is a major concern. The real issue is, literally, screen space. Or perhaps more accurately, mental space.
The thing is, I'm trying hard to avoid the classic "Microsoft disease" -- including every possible feature, with the result that *finding* the features you actually want becomes more difficult. So features have to fight for their lives, less because they are hard to implement and more because they increase the amount that a user might have to understand in setting up a Space.
And yes, the implication is that Querki is trying to be lowest-common-denominator in many ways -- again, in a very Appleish sort of way. There are going to be a hell of a lot of features in this tool, so I want to make sure they are the *necessary* features, so as not to overwhelm users. (This is part of why I'm so focused on use cases: no feature gets into the system unless it's justified by a use case, and no use case gets implemented unless I believe I have specific people who will want to use it.)
Note that the Scala end of things is largely irrelevant. This is, indeed, near-trivial to implement in Scala. But end users aren't working in Scala, they working in what amounts to a database/language/UI implemented *in* Scala. While that will use a lot of Scala structures under the hood, I'm not assuming that the end-user view has much of anything to do with that -- we're going to focus on what the users need, and figure out how to map that to the underlying language and database.
no subject
Actually, neither of those is a major concern. The real issue is, literally, screen space. Or perhaps more accurately, mental space.
The thing is, I'm trying hard to avoid the classic "Microsoft disease" -- including every possible feature, with the result that *finding* the features you actually want becomes more difficult. So features have to fight for their lives, less because they are hard to implement and more because they increase the amount that a user might have to understand in setting up a Space.
And yes, the implication is that Querki is trying to be lowest-common-denominator in many ways -- again, in a very Appleish sort of way. There are going to be a hell of a lot of features in this tool, so I want to make sure they are the *necessary* features, so as not to overwhelm users. (This is part of why I'm so focused on use cases: no feature gets into the system unless it's justified by a use case, and no use case gets implemented unless I believe I have specific people who will want to use it.)
Note that the Scala end of things is largely irrelevant. This is, indeed, near-trivial to implement in Scala. But end users aren't working in Scala, they working in what amounts to a database/language/UI implemented *in* Scala. While that will use a lot of Scala structures under the hood, I'm not assuming that the end-user view has much of anything to do with that -- we're going to focus on what the users need, and figure out how to map that to the underlying language and database.