Syntax

[cmontella]

RFC Link - https://github.com/witheve/rfcs/blob/master/proposed/syntax.md

[bertrandrustle]

@RubenSandwich An "s" suffix doesn't consistently indicate plurals in English. Some English words are pluralized by suffixing "es", some are the same in plural form as singular (fish, sheep), some require a different spelling of the word altogether (goose -> geese, lady -> ladies, leaf -> leaves), and some are even more irregular (child -> children, syllabus -> syllabi). Native English speakers have a difficult enough time with many of these, and for non-native speakers it's worse.

There are also contexts in which you need a pluralized variable name to indicate a single value, as with Eve's aggregates: burgers = sum(burgers given burgers), and contexts in which you want a singular name to hold a set: list = [#element].

Also, naming conventions that aren't enforced by compilers remain conventions, i.e. in practice they don't get used.

[ibdknox]

@RubenSandwich that's correct, order of blocks is totally up to you (order in blocks as well!), so I believe we actually have something potentially even better than knuth's original literate programming - you don't need to transform the md into something that can be compiled, it is itself compilable. Basically, we cut out the middle man.

There aren't any collections in Eve. As such, you can think of evaluation as always being a tuple at a time. In your example, bob will get bound to one object that matches that pattern and then we'll match any other corresponding patterns one at a time. You can think of it as having nested loops around each pattern. You're never really working with a collection, instead you're automatically iterating over all combinations of matches. Aggregates are the one place where you do need to think about the set of things you're working over. With them, you explicitly describe what values make up the set you want to aggregate (that's what given does). Even in the aggregate case though, what you're getting out is a single value at a time.

In general, we made it so that you only need to think about the cardinality in two places: aggregates as described above and actions. In the latter, cardinality is based on the variables used in the mutation. For example:

match
  bob = [#person @bob]
  chris = [@chris]
  hat = [#hat]
bind
  [#friend person: bob, person: chris]
  chris.wearing += hat

There are two mutations happening here, one where we're adding a new friend object to the system that includes bob and chris, the other where chris has a wearing property set to anything tagged hat. For every matching element of chris and bob, we'll get one friend object and for every hat chris will get a new wearing attribute. In both cases you don't really need to think about whether these have multiple matches or not, you are declaratively stating fact. Any person named bob is a friend of anything named chris and chris is wearing anything that's a hat. If you wanted to say that chris was wearing a specific hat, or I'm talking about a specific bob then you have to add more information to the pattern to make that clearer. Most programs are written to abstract operations over collections, not individual things. Eve let's you do that while thinking about a single item at a time, instead of juggling loops or map/reduce.

[ibdknox]

As a side note, it's interesting that a lot of our answers are going to be "you don't really need to think about or worry about that." Many aspects of traditional programming that you have to keep in your head (e.g. how many times a loop runs) are either not present in Eve or are of much lesser importance. There's a difficult task there: how do we help people "let go" of those worries?

[yazz]

@cmontella I guess my ideal programming language would be one that used only a - z and 1 - 9 if possible, as that would make it so friendly for typing. Also, I think about iphone coding and ipad coding where special characters are even harder to type

[joshuafcole]

In the case if programming on a tablet or mobile device, Conventional text based languages are really too cumbersome. We expect that as we expand our sights to a more general userbase and a wider diversity of devices that we'll need to tailor our UX to match. Mobile programming is a big passion around the office though, so we'll definitely have more to say on the subject down the road.

On Mon, Aug 8, 2016 at 12:49 AM, Zubair Quraishi notifications@github.com wrote:

@cmontella https://github.com/cmontella I guess my ideal programming language would be one that used only a - z and 1 - 9 if possible, as that would make it so friendly for typing. Also, I think about iphone coding and ipad coding where special characters are even harder to type

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/witheve/rfcs/issues/4#issuecomment-238164832, or mute the thread https://github.com/notifications/unsubscribe-auth/AATKDlYLw2q2ExiZ2jDU8WQLSL1peNTXks5qdt-IgaJpZM4JQNTQ .

[yazz]

@joshuafcole makes sense that mobile dev will be GUI only!

[Eucalyptus2013]

Any thoughts?

You can 'commit global', can you 'bind global'?

Can you restrict a match to a specific bag? For example, 'match session' to match with the facts stored in the session bag. I ask this question for performance reason. If you know that a fact is stored in a specific bag, is it slower to query all the bags? I know there are two bags currently (session and global) but maybe in the future the user could create its own bags.

[ibdknox]

@Eucalyptus2013

You can 'commit global', can you 'bind global'?

No, but that's because bind global isn't necessary. When you use commit, you're writing state down in a log and you want to talk about things like lifetime or visibility, whereas with bind you're describing a pure function over the committed state. As a result, the lifetime or visibility of bound mutations is determined by the lifetime and visibility of the facts in the log. If you can see the base objects and properties needed to satisfy the match, you can see the result. This makes binds sort of simultaneously global and local, because the committed state that you see is the composition of the global bag and your session bag.

Can you restrict a match to a specific bag?

Not yet, but it's something we definitely want to support, though not really for performance reasons. The cost of looking in one bag vs looking in two isn't going to make too much of a difference. Being able to place facts in arbitrary bags and then explicitly control their composition lets you do all sorts of crazy things though - from loading multiple datasets and exploring them in composition and individually, to forking datasets and doing what-if analysis. It's also a mechanism that can allow you to do interesting things like have one instance of Eve write into a specific bag and have another instance read it (this is how we're making our testing infrastructure work). The syntax for this hasn't really been laid out yet though.

[Eucalyptus2013]

In the clock.eve example:

Clock

draw a clock hand

  match
    hand = [#clock-hand angle length]
    x2 = 50 + (length * sin[angle])
    y2 = 50 - (length * cos[angle])
  bind
    hand <- [#line, x1: 50, y1: 50, x2, y2]

draw a clock

  match
    [#time hours minutes seconds]
  bind
    [#svg viewBox: "0 0 100 100", width: "300px", children:
      [#circle cx: 50, cy: 50, r: 45, fill: "#0B79CE"]
      [#clock-hand @hour-hand angle: 30 * hours, length: 30, stroke: "#023963"]
      [#clock-hand @minute-hand angle: 6 * minutes, length: 40, stroke: "#023963"]
      [#clock-hand @second-hand angle: 6 * seconds, length: 40, stroke: "#ce0b46"]]

There is no commit so I don't know if the clock hands are in the session or global (I suppose in the session). Do I need to add a commit global to share the clock hands with other users?

[shamrin]

@Eucalyptus2013:

Do I need to add a commit global to share the clock hands with other users?

There's no need to share clock hands with other users, because (quoting @ibdknox):

with bind you're describing a pure function over the committed state

In the clock example, committed state is [#time …]. It was "committed" by Eve server. Obviously, #time is already global and shared between users. Yes, all users are calculating there own clock hands. But the hands all look the same, because #time is shared.

At least that's how I understand it.

[ibdknox]

Yep! @shamrin has it right.

In general, you don't want to share UI elements, you want to share the data needed to draw those UI elements. In this case that's time, which as @shamrin pointed out is globally defined already.

[wtaysom]

A little more on basic names. Now that we have the easy to explain match/bind/commit replacing obscure [unindented]/maintain/freeze, perhaps we're ready to clear up "object", what we call those key-value pairs attached to a unique ID.

Words take on their meaning from the connotations a community associates with them. To us developers, "object" connotes encapsulation, inheritance, methods, and a many other concepts that Eve exists to help supersede.

What to call it instead? Entity, record, form, pattern, selection?

For me "entity" rings a bell. Like @bertrandrustle, I'm familiar with "EAV" (Entity-Attribute-Value). So "key-value pairs attached to a unique ID" triggers "entity", entity relationship diagrams, RDF (hope that isn't triggering for any of you). Try reading the code snippet where @benjyhirsch talks about dot syntax. Does his use of the word "entity" do anything but clearly suggest a uniquely IDed Eve DB thing?

What about "record" as suggested by @RubenSandwich? A record is what gets recorded. The most basic record is a single line item, row in a table, fact, Entity-Attribute-Value triple. An Eve entity (yay, alliteration) is characterized by all the records we have of it, all the facts we know about it. You may be reminded of Datomic, which also uses "entity" as does the Wolfram Language.

What about the more exotic suggestions? A form omits particulars. A pattern has blanks. A selection is a collection matching a pattern. The things (explicitly or implicitly) living in the Eve DB are distinct from the syntax we use to refer to them individually and as sets.

Consider the Objects section in the RFC. Here "object" is used ambiguously: as a pattern "a set of attribute:value pairs", a selection "all the entities that match", facts "all the facts matching", and also as an entity "the object, allowing you to ... mutate attributes".

We may benefit from expunging "object" from our Eve vocabulary.

[bertrandrustle]

What are termed "objects" in Eve are really abstractions of two different things.

• The first abstraction represents a direct reference to an EAV (due to set semantics, potentially multiple EAVs) and can be denoted in the syntax with a variable -- e.g. foobar in the following:

  match
  foobar = [#foo #bar]  // The right-hand side doesn't directly reference an EAV
  bind
  foobar.value := 0

  or with a literal:

  bind
  [@baz #foo value: 42]

• The second abstraction represents application of destructuring and consists of a pattern that may include bindings:

  match
  [#foo value not[#bar]]  // Matches and binds
  quux = if value = 42 then true
         else false

In Clojure there's a clear conceptual distinction between the proverbial map and the territory. The Clojure analogue of the second abstraction above is called a binding form, and it can match against different data structures such as lists and vectors, but crucially, isn't itself referred to simply as a list or vector -- one may however talk of a specific instance of binding form as a "destructured list" or "list destructuring" for example.

So the second abstraction in Eve could also be formally called a binding form, and informally, destructured object (just for the sake of illustration, assuming the term "object" isn't entirely expunged). Doing so would solve part of the problem with the current "object" nomenclature.

[yazz]

I think calling them records make sense. Then people using Eve who I think will mostly be data scientists will understand what a record is because they know databases

[bertrandrustle]

In the case of the first abstraction I describe above, the strongest candidates to replace "object" as the name for direct references to EAVs are probably entity (associated with EAVs), record (associated with relational databases), and fact (associated with logic programming/databases).

[yazz]

the only problem with entity is that only non computer science people know what an entity is - and even I'm not sure

[yazz]

fact is nice, but why not stick to record, as then people will automatically "anchor" their knowledge on to a known concept. With something as different as Eve we need to make sure that there are many anchoring points so that it is easily learnable

[joshuafcole]

@wtaysom: Thanks for joining in the conversation. I'm generally in agreement with your thoughts on some of the more exotic names we've discussed. I think many of them carry some baggage that we'd have to overcome and replace with our own meaning if we were to adopt them. Unfortunately, while entity and pattern are my personal favorite combination thus far, I agree with @zubairq's concern that entity is not really in vernacular. While our initial thrust is targeted towards developers, we don't want to paint ourselves into a corner. There are some reasonable arguments to be made along the lines of alternate documentation for different user groups, but each is associated with its own issues that must then be weighed along with those of the terms themselves.

As a side note, I only really see two types of things being called objects in Eve right now. These are "patterns" (the shapes of objects that occur in match bodies) and concrete objects (which are a set of (potentially filtered) EAVs for a given entity). @bertrandrustle did a great job of highlighting those here. The other two cases (selection and facts that match) are in my opinion sub-cases of concrete objects. Even if the object is comprised of only a subset of an entities EAVs, it still defines a--more general--entity in its own right. If that explanation doesn't make sense though, we may need to find a better way of mapping our semantics to terms.

[cmontella]

@zubairq

We have some reservations about "entity" being understandable, as Josh said. It evokes a sci-fi extra terrestrial vibe to some people. I like record in general, but I also don't like how it's a verb and a noun which are homographs. It just makes it a little confusing to read when both words are everywhere e.g. "record a record".

[yazz]

@cmontella

I just asked 5 people at work about the terms you mentioned. Here is the gist of it:

• entity = Entity Relationship diagrams.... that's an abstract thing isn't it? People here didn't say the scifi reference much
• record = That's used in SQL and databases. One person answered that a record is something people used to use to play music
• homograph = I can't repeat the answers here

I guess the answer is not to use record as a verb. Save a record. Store a record. Many good alternatives

[yazz]

I guess I am heavily against inventing new terms for things which can be described with existing terms, as every new term is another "barrier" for end users which will prevent them from using Eve

[bertrandrustle]

@joshuafcole's comment made me realize I need to revise the characterization of EAVs put forth in my earlier comment. While de-conflating two different things that go by the same name of "objects" I ended up conflating EAVs and entities which are also two different things.

So, for the moment let's set aside developer syntax-level abstractions to address semantic-level abstractions of the Eve platform.

Strictly defined, an EAV (Entity-Attribute-Value) is a tuple holding one attribute, one value, and one entity reference. (Eve actually extends the EAV model to EAVBTU -- Entity-Attribute-Value-Bag-Tick-User -- but it isn't necessary to get into that here.) Multiple EAVs may contain the same entity ID, and an entity is really just a representation of those as a group. Since each EAV tuple occupies a row in the database, a single entity might be spread across several rows. So an entity is an abstraction encompassing one or more EAVs related by entity ID.

To sum this up visually:

              +--
              |  (f82b,  name,  "Bob")     <-- EAV
Entity f82b --+  (f82b,  tag,   "person")  <-- EAV
              |  (f82b,  tag,   "pilot")   <-- EAV
              +-- ^--ID  ^--attr ^--value

              +--
Entity 0ac7 --+  (0ac7,  name,  "Joe")     <-- EAV
              +-- ^--ID  ^--attr ^--value

(Note: Above ID values are contrived examples.)

Now, returning to the level of the developer syntax, the first entity in the above diagram would be represented by the object [@Bob #person #pilot], but under the hood it's really three EAV tuples spread over three rows in the Eve DB. Likewise, the second entity would be represented by the object [@Joe] and is backed in the database by a single EAV tuple.

[yazz]

Warning... negative spoiler: I think I should wait a few weeks before I come back to this conversation as the language in this thread (not the Eve syntax) seems to have evolved into Klingon as far as I can see. I thought Eve was about bringing programming to the masses.... yet we are still talking so technically in our posts.... or am I missing something here?

[RubenSandwich]

@cmontella My vote is still record as it is in the common vernacular and has concrete associations. It is unfortunate that it is a noun and a verb, but I mostly have see/heard it as a verb in the domain of audio/video which is a domain separate from yours. Furthermore 'record a record' is confusing on it's own and I think should be avoided when communicating.

@zubairq I can understand your disappointment, but I think it is important that solid and logical names be used so Eve can be something approachable to those without prior programming experience and to that end these discussions need to happen. However with that said, I do fear that the future name of 'objects' could easily turn into a bikeshedding issue. (And maybe you feel that is already has.)

[yazz]

@RubenSandwich My vote is with "record" too.. you are spot on about the bikeshedding issue though, I am definitely guilty of that, as end users will probably only use the GUI anyway, and never see the syntax... my apologies! When I said Klingon I was referring to this "Multiple EAVs may contain the same entity ID, and an entity is really just a representation of those as a group. Since each EAV tuple occupies a row in the database, a single entity might be spread across several rows. So an entity is an abstraction encompassing one or more EAVs related by entity ID"... this sounds like IT Architecture Astronauts talking at a big company meeting..... I just hope we can talk technical in a way that is understandable

[cmontella]

@zubairq

Sorry for your frustration! I think it's just because in this particular setting, we're getting two groups of people who use different language to talk about the same thing. But I disagree that this issue of what to call "objects" is bikeshedding, because bikeshedding implies a degree of triviality. What we name things really matter, and although the choice may not sink Eve, we don't want to make things any harder on people.

Bertrand was trying to really define an object as they are represented in the system, because once we really define them, then we should have a better idea of what to call them.

Ignoring the words he used, I hope actually his picture helps. Internally, we use the term EAV (stands for Entity-Attribute-Value) to refer to "facts" as we've been calling them externally. EAVs/facts are just any data you put into Eve. A name is a fact. A tag is a fact. A birthday, or a salary, or revenue are all facts. But facts have to be connected somehow, and that's where "Entities" (as we call them internally in the system, not what we are discussing as calling "Objects") come in. For example, I might want to represent myself in the system, so I would enter my name and age and height. Those are three facts, relating to a common "Entity", me.

So this is all Bertrand was showing. In his drawing, he shows an "Entity" with an ID f82b, and it has three facts: a name and two tags. He shows a second Entity with ID 0ac7, and it has a single fact connected to it.

Let me attempt an analogy, which I hope can make this clearer:

Pretend I'm a teacher and I have a classroom of students. We're learning about genetics, so I ask all the students with brown eyes to raise their hands. If I were to model this scenario in Eve, then the students would each be an "entity" in Eve system terms. Their attributes would be their hair color, age, weight, eye color, gender, GPA, or any other thing relating to them. When I ask for all the students with brown eyes, in Eve terms I'm doing this [#students eye-color: "brown"].

I hope this clears some things up for you.

[yazz]

@cmontella Actually that is a fairly good explanation, thanks! :) It sounds like the Eve data model is the same as the Neo4j data model. Does it make sense to use their terminology of Neo4j then???? they already use MATCH and other similar stuff to Eve, and have nodes, properties and tags

[bertrandrustle]

Right, so if facts are EAVs, then "fact" is ruled out as a possible replacement for "object". That leaves me with just two proposed candidates, "record" and "entity".

[cmontella]

It sounds like "record" has pretty broad appeal. So far Ruben, Bertrand, Rainhead, and Zubair have all supported it. Did I miss anyone? That's actually almost everyone who participated in the discussion, so it seems like a consensus to me. We'll start shopping the term out to more people, and see what reactions we get.

[bertrandrustle]

@cmontella Don't forget to pitch "pattern" and "binding form" to fill the other use case for ostensible "objects". ;)

[cmontella]

Actually, can we revisit "pattern" a little more? I'd like to hear input from more people about "pattern" because it fits with our "match" word, and actually Chris and Josh used the word "pattern" several times in their posts.

Another possibility I'd raise is: a couple people have noted that the "objects" are really different things in the match and action phases of a block. Do we want to call them by different names? Does that add more confusion or provide clarity?

[bertrandrustle]

Binding form has the advantage of explicitly highlighting the fact that in addition to pattern matching, matches/sub-matches can be bound inline to variables. However, the strongest connotation in my mind for the concept of "pattern" in the programming context is Perl-style regular expression patterns, and those also enable inline binding, so perhaps it's superfluous to mention binding after all.

[shamrin]

As an outside observer I no longer understand what is the topic of this thread. Would it make sense create another issue/RFC called "Rename object"? Its description could clarify the problem and list possible alternatives.

In addition to "pattern", "entity" and "record" I would suggest "template", "structure", "p-object" (in match) and "r-object" (in bind + commit), or even "pattern object" and "record object". Further: "match object" and "action object".

[cmontella]

@shamrin

It seems the topic of this thread has changed slightly over time. The first main discussion was regarding the collect / freeze / maintain nomenclature, which was resolved by renaming to match / commit / bind. Since you last commented, the discussion has shifted to "what do we call objects?"

You're right that this is confusing, and we'll have to figure out a process to handle that. Nested comments would be nice here, but I don't think GitHub supports that. I'm reluctant to start a new thread right now, because a lot of people are tuned into this thread already.

[bertrandrustle]

@shamrin I'm pretty sure renaming objects is being discussed here because the syntax RFC says:

Communication with Eve happens through "objects", which are key-value pairs attached to a unique ID (object is a pretty generic and overloaded term, so let us know if you have ideas for what to call these guys).

And we haven't even begun to discuss renaming "bag" and "block". ;)

[wtaysom]

So to summarize the object naming conversation...

Bike-shedding is where discussion of the trivial, such as the color of a bike shed at a nuclear power plant, takes precedence over the essential, the main reactor. Naming, like bike shed color, is a topic that many have an opinion about and an esthetic one at that. Unlike the shed, names determine how we talk about the reactor, its parts, how they relate, how we conceptualize what our system is. We can see that we have had a fruitful naming discussion because we've recognized semantic distinctions that we may not have noticed otherwise, two in particular:

(1) The distinction between stuff in the database and expressions, patterns, binding forms used for picking out some of the stuff. (2) The distinction between facts asserted and the things to which those facts refer.

Ultimately, good nomenclature reflects important distinctions so that things which are distinct have different names allowing us to concisely refer to things, precisely say how they relate. For those of us with a certain background @bertrandrustle, @cmontella, @joshuafcole, myself, EAV terminology fit well. However, the "Entity" is off-putting to some @zubairq, @RubenSandwich, and even those accustomed to it @joshuafcole, @cmontella feel it's "not really in vernacular". I buy that. I recommend we choose record. Let me give you three reasons. I do so with the caveat that EAV be mentioned when defining "record" so that those coming from that tradition will be immediately enlightened.

Reasons why "record" is a good term:

(1) Suppose you run a hospital. When you ask for a patient's record, what do you expect to get? A report of all the things that have been saved or written down about the patient or at least the things associated with the person's ID as some things may have not been saved in a structured way.

(2) Suppose you are a programmer. What is a record in a programming language? It's like a struct with predefined fields and values but without the memory layout legacy of C. Great, Eve records are like that, and you don't have to fix the fields in advance.

(3) Suppose you are an data Accessy, Excelish person. What is a record? It's a row in a table. What's in the row? Well, for each column you have a cell with some data in it. Great, Eve records are like that, and you can add a new column whenever you have a new kind of data.

[yazz]

@wtaysom I guess we can all agree on one thing at least, "record" is a good term :)

[cmontella]

Okay, it's been a week since we talked about renaming object, and I think we're settling on record. It's not perfect, but it's the best we have and people seem to be in agreement, as @zubairq said. Great.

I think the next question is what to call bags. Bags are a partitioning of facts. When you commit a fact to Eve, it goes into a particular bag. Right now we have two default bags: the global bag and the session bag. When you commit a fact to Eve, it goes into the session bag by default, so the fact is only visible to your session. When you commit a fact to the global bag, it is visible to every session on the server.

We expect you might want any arbitrary bag. For instance, if you have a multiplayer networked game you might want a game state bag for every player that is coordinated with a global game state bag. In the future, the browser might only look for HTML elements in a browser bag.

Thoughts?

[wtaysom]

Context. I find the common usage of "context" matches an Eve bag reasonably well. Consider...

Sometimes a word means one thing, sometimes it means another. What makes the difference? Context. When you ask a question, the answer depends on the context. When you say something, assert a fact, be aware of the implicit context surrounding it. If you take a comment out of context, it may be embarrassing.

Aside from the use of bags, contexts, scopes or whatever we call them, there a separate, though related, semantic question of distinguishing states. In "Breaking Down: Tic-Tac-Toe" @joshuafcole uses side conditions on rules to differentiate the normal game playing state from the end of the game, where the board has a winner. For example, there are two #click matching rules. When there's a winner, restart the game. When there isn't and the square you clicked in is still empty, fill it. A lot of interaction design is about identifying side conditions, understanding what happens in all the possible states. I have yet to see a great solution for dealing with this inherent complexity.

Some systems use context, bag, scope things to help with states. For example, in Kodu Game Lab (if I recall correctly) you assign a sheet of condition/action rules to an agent. One possible action is to switch the sheet that the agent uses, putting it in a new state, and altering its responses in the future.

[yazz]

@cmontella In large companies we often buy third party products, which have different storage mechanisms, sometimes databases, sometimes NoSQL, sometimes XMlL, sometimes flat files, and others too such as network storage. However, I have seen that during the discussions between the vendors and the companies the ONLY term that people inside the companies understand is database.

So my suggestion would be to call it a local database and a shared database, or global database. Even though technically it may not be a database it will be the only terminology people inside large companies will understand, especially the more senior level decision makers.

[bertrandrustle]

I'm surprised there hasn't been much discussion of bags yet. They seem to have the potential to be a major Eve selling point. I envision bags as a kind of hybrid scoping mechanism that serves part of the purpose that variable scoping in other languages serves, and much of the purpose that scoping of larger constructs serves in other languages via module systems. Bags could allow the programmer to declare practically arbitrary scopes, from the level of the source file (or even individual blocks?), on up to the network level, and could contain code (in the form of functions) and/or data. Is that too fanciful?

Drawing upon that conception, a couple of weeks ago I brainstormed on candidates to replace the term "bag" should it be renamed. Coincidentally one of the choices I hit upon was also independently proposed above by @wtaysom: context.

Here's the rest of the candidates:

• zone
• space
• scope
• range
• domain
• constraint
• perspective
• projection

[cmontella]

I think context really stands out. I particularly like it because the common usage and understanding of the word "context" really fits with the concept. You are matching facts that only exist in some context. I think we'll run with that for now and see how people react.

@zubairq I see your point about database being familiar. We were considering "dataset" as well for that reason. My hope is that if we call out that Eve itself has a database, then that can provide the right framing for decision makers. But I'd like to avoid talking about databases in databases, as that would be the case here. What are your thoughts on "context"?

[yazz]

@cmontella Actually you got it spot on. At work we talk about "databases" and "datasets" so that terminology is great!

[yazz]

@cmontella context is good as well. The biggest issue with context however though is that it is a very overloaded term and it is almost always used as a non-technical term by people in meetings. Non-technical people can have a technical vocabulary but it is always a "tip of the iceberg" vocubulary which is why words like database and dataset can be used and specifically relate to an IT tool.

[yazz]

@cmontella I guess I am trying to say that non techies who will use Eve have a techie vocabulary and a non techie vocabulary, and it is important to make sure that the words used are part of their existing techie vocabulary already, as new terms, or terms from from non-techie vocabulary will only confuse them, especially if they have to convince their manager why they should buy a product. I can imagine someone in a meeting trying to convince their manager to buy Eve: "Well Eve lets us organize and collobarate by putting our data into different bags" will not help sell it to them as they will think of shopping bags, but "Well Eve lets us organize and collobarate by putting our data into different datasets" will work because dataset is IT vocabulary for them

[yazz]

So I recommend datasets in databases :)

[bertrandrustle]

The problem with "dataset" and "database" is that they are words primarily connoting a "what", not a "where". For a bag in Eve the quality of where it is is a principal aspect of its identity. Terms like "context" and "scope" have a strongly signified "where" quality; when you conceptualize them you think of a boundary enclosing a very specific area, just as much as you think of their contents. When developers/programmers conceptualize a dataset or database they're using, they typically aren't concerned about where it is physically or logically; that concern tends to be more the purview of database administrators.

[yazz]

ok, makes sense. But "bag" doesn't make me think of a data... ... in that case I would think "zone" or "space" is better, as context seems like an abstract thing

[bertrandrustle]

Yeah, "bag" is another one of those inscrutable terms employed in computer science that was borrowed from mathematics -- in this instance from set theory, where a bag is more formally called a multiset and refers to a generalized form of sets. Notably, multisets/bags are sets that admit duplicate elements, while ordinary sets contain no duplicates. I'm pretty sure that's the meaning of bag the Eve developers had in mind anyhow, please correct me if I'm wrong!

You're right about "zone", it's definitely more concrete than "context" and I think users in general, not just programmers, would be more comfortable with it.

[yazz]

@bertrandrustle Its quite funny, as I was always so bad at mathematics only just getting by with calculus and intergation and all that, so I sometimes feel really stupid when I talk to you guys as I don't know the correct terms. I guess I always want the simpler terms as I see that most users in large companies are totally ignorant about the tech and don't even care... so they need simpler terms they can anchor in their heads to understand the concepts. Which is why I keep pushing for simpler terms!