This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-15
Channels
- # beginners (15)
- # boot (4)
- # cider (1)
- # cljsrn (16)
- # clojars (1)
- # clojure (92)
- # clojure-india (3)
- # clojure-russia (27)
- # clojure-spec (9)
- # clojure-uk (5)
- # clojurescript (73)
- # cursive (28)
- # datascript (10)
- # emacs (1)
- # events (5)
- # hoplon (1)
- # instaparse (7)
- # juxt (2)
- # klipse (13)
- # lumo (17)
- # off-topic (166)
- # onyx (4)
- # protorepl (5)
- # re-frame (5)
- # reagent (13)
- # rum (26)
- # untangled (17)
- # yada (3)
@qqq there isn't really a standard list, constraints are just validation functions with a context. A unique constraint takes the rest of the table as a context. The FK constraint takes another table, etc. So you could model it as "a arbitrary function with context". For that matter some DBs have programmable triggers and the like. And awhile back MS SQL server allows you to use custom C# dlls from inside the SQL server. So you can write constraints how ever you want.
@qqq that being said, I think you'll find that Clojure maps really closely to the tarpit paper as is. About the only thing Clojure doesn't implement is logic rules. But most of the rest of the semantics described in that paper are already in Clojure.
@tbaldridge : unique key constraints / foreign key constraints can be efficeintly checked in terms of the transaction -- without having to check over the entire db; I suspect there is a nice set of functions that can be easily checked over 'diff of databse', without having to be rerun over entire db
@tbaldridge : (on tarpit paper) -- I'd have to disagree; I don't think Clojure maps is a good replacement of a "relational store"; there's already core.logic -- but even using core.logic, I feel like something is missing -- i.e. this in memory relational store
@qqq maybe? But I haven't seen that in reality. Most constraints I use in Datomic (which is transactional level checks) have to look up something in the DB).
@qqq for relational store, that's where Datomic comes in š But seriously, I remember what Rich said once about my comments on the paper: "the Tarpit paper includes a lot of nice ideas...implementing them is really hard". And I think he's right. Even the paper itself admits that some things like relational logic may have to be removed from an implementation to get acceptable performance. And that's what Clojure did. Fun fact: Clojure almost had a variant of Prolog back before Clojure 1.0. I don't think the code still exists, but it was never "fast enough" to be production ready.
Although IMO some of the pattern matching/unification stuff is rising again in the form of spec.
@tbaldridge : (re constraints): yeah, for foreignkey/uniqueness, we definitely have to look at the db; but we only have to look at the db on the eav triplets we touch, and not have to recheck everything else
@tbaldridge: yeah, I'm not implementing logic programming ; I just want to pass around "typed relational datastores" š
When I started out with clojure was the time I also read the tarpit paper and a few related and time and time again I could see which of these papers Rich Hickey had read and implented (partially) in clojure. Really a nice experience all at all.
Yeah, my only complaint with the tarpit paper is it's almost completely vaporware, not even giving clues as to how any of it would map to modern machines.
I never have these expectations for papers. If a paper provides a working implementation / solution I am all up for it, but if it does not, I am fine with that too. One takeaway I remember is that deriving values is one part of the problem of todays software. But we are just not able to survive without caches, replication, etc. For me the only solution I see are quantum computers or at least a completey new generation of computing power and storage.
@tbaldridge I just saw your video about pixie, and the video from @nasser about mage/magic Why not/Is possible/Is a good idea implement pixie in clojure?
@sveri I agree about the expectations part. Sometimes it's worth cursing the darkness even if you don't have a candle at the ready. It's very easy to get so accustomed to fumbling around in the dark that you forget you're doing so.
I will say that I am a bit more hopeful than you about things getting better. A lot of small incremental improvements over time can eventually lead to an order of magnitude improvement.
And I think we've kind of seen that already. Even Brooks, who pointed out that there was no silver bullet on the horizon, has since acknowledged that we have gotten quite a lot better at software since he pointed that out, enough so that it would like a silver bullet to programmers of the time. Just in the time I've been seriously writing software (about 20 years now) it has gotten a lot easier.
Still hard though, and of course as we get better at it we take on harder problems, so...
Of all the improvements in that time, I think that having Internet access, and so much information easily searchable might be the biggest improvement. I wrote a fair amount of code before I had internet access, and trying to learn how to do it from a few manuals was... well, you'd get stuck on something simple and spend hours working it out. A lot of that kind of thing can now be solved in a few minutes with a Google search.
Hmm- I kind of like "a merge of programmers." "a merge-conflict of programmers" does not roll off the tongue quit as easily, even if it is more accurate.
Names are hard though, even outside of software. Have spent a lot of the morning talking to some associates about what to name a corporation we're forming. The availability of domain names is a concern.
Not that we were considering this, but I was quite surprised to learn that "http://stenchblossom.com" is available.
"http://perfectlycromulent.com" is, unfortunately and not surprisingly, taken.
"abend" has the advantage of obscurity. if you never did mainframe, you've prolly never heard of it.
Hmm- I never did mainframe, but... I suppose I'm old enough to have worked with some people who did.
kinda like the HCF instruction ("Halt and Catch Fire"). hmm, maybe "an HCF of programmers"?
I don't think I'd like a "pear-shaped" of programmers as a general term, but I might be convinced to like "a pear of programmers" when referring to just two, especially when they pair program.
weeell, a little on the cute side, no? howsabout "pod"? most programmers are aliens, after all.
i rather like "a recursion of functional programmers". not to be confused with "a co-recursion of oo programmers". :)
I do sort of like the names that suggest that programmers create a bit of havoc, and ones that nod at our history, thus the "pear-shaped"...
so other programmers would be called a "complex?" I think that's a bit too opinionated š
no, "a complectitude of programmers". clojurists are a "decomplectitude". since they so awesomely decomplectitudinous. somebody stop me, please.
Hmm- I think not. I mean what do we do? Two thing, really. We solve problems. And in the process we create more problems that need solving. We're like lawyers in that respect.
I'm inclined to think that measure words should be one word. "A hazard of programmers" seems reasonable, but again a bit too accurate for my tastes.
could be wrong. see https://en.m.wikipedia.org/wiki/List_of_English_terms_of_venery,_by_animal
Dunno though- I'm going to stick with liking "A problem of programmers" both on alliterative grounds, and on the grounds that is a grammatically versatile phrase.
me, i'm lookin for sth a little nuttier. thing is "a problem of programmers" sounds like a description of a problem that programmers face. the beauty of "exaltation of larks" is that there is no apparent connection between the two terms.
Hmm- I'm inclined to think that there is a connection there, though it is a bit of a stretch.
Note that 'on a lark' is also an English phrase, and one not entirely unlike 'exaltation'
following "a boil of hawks": howsabout "a carbuncle of orogrammers"? i like that one!
It seems that people have associated the lark with a sort of exalted freedom for a very long time.
yeah, same for "charm of finches", i suppose. but the venery terms are very old, and the conbection is lost on most of us. a "business of ferrets?"
I mean- weasels, in general, are take-charge sorts. Not the nicest mammals you know, but the sort you want at least one of on your board š.
yeah if you squint hard you can make sense of a lot of them. i'm also not convinced they're all genuine. has anybody ever said "gee, i think we have a wisdom of wombats to deal with"?
I'm pretty sure wombats was added well after these sort of measure words fell out of common parlance.
"i'm also not convinced they're all genuine" - every convention starts somewhere, most of the collective nouns date to the late 19th century
they are old, but not ancient
and they started as a jokular, whimsical thing, but stuck around enough to be "official"
We still use a few measure word for animals indispensably in English- hard to do without the word 'flock,' for instance.
right, but all the whimsical ones were a late victorian fad
venery terms are very old, but i'm guessing you're right, many were invented more recently.
Measure words in general are... well a thing that comes and goes in various languages in various ways.
venery: "archaic: sexual indulgence"
it's a fascinating linguistic topic, similar to grammatical complexity. small, isolated communities tend to have much more complex grammar than big cosmopolitan societies.
Japanese and hinese, despite being very dfferent languages, both have lots of them that are grammatically required in many cases.
@noisesmith that's a different word. http://www.etymonline.com/index.php?allowed_in_frame=0&search=venery
not at all. there's no counting in "gaggle of geese". count words are a whole different animal.
For instance in Japanese, you can say 'yi-pikki' where yi means one, and pikki is a measure word that refers to small animals.
p.s. they are not "measure" terms. they're about categorization rather than measurement. number is not involved, except for "few, many, many many", etc.
I think it is very similar, taking into account basi grammatical differences in the languages involved.
i don't know how they say "hutch of rabbits", but i'll bet it has little to do with "-hiki"
I'd say that while we use these sorts of words mainly for animals, and we only retain a few of our archaic terms (like flock and herd)
actually i think we still use lots of them, like "litter of kittens". but count words are entirely orthogonal. we're talking about 2 different ways of categorizing. japanese ippon, nihon, etc. categorizes by shape, not by e.g. membership in "pencil".
e.g. you can say "5 head of cattle" and you can say "herd of cattle". there is no linguistic connection between "head" and "herd".
similarly you can say ippiki referring to a sparrow, that's completely separate from saying "flock of sparrows" in japanese (sorry cannot remember the word).
yes, but my point is that is completely separate from mass noun terms like venery terms.
Hm- I'm not sure I see your point... the vernary words are, as a matter of grammar, just measure/counting words, right?
NO. heh. they have nothing to do with measurement or counting! they just categorize.
yeah, or mass, dunno what the linguists would call it. but it does not involve measurement or counting.
except of course in the extreme case when you want to ask the philosophical question: how many grains of sand does it take to make a pile?
And I think you're right when you say that we don;t use terms like this for counting, but wrong hen you say we don't use them for measurement.
We almost never say "I'd like to sell you three murders of crows" but we often say "I'd like to sell you three pounds of sand."
btw it's a balmy 80 degrees in chicago and i'm enjoying this little chat, dork that i am.
ah, but sand is already a mass noun. you don't say "i hate that damn sand" meaning one sand.
iow "pound of sand" is not analogous to "murder of crows". the give-away is in the plural "crows"
Ah, but, as a matter of grammar, it is in many languages, which is what I am getting at.
ah, well far be it from me to argue in favor of language universals. but i'm only talking about English: venery terms are not measure/count terms, as far as i can see
john: 1st Rule of Naming: do not use common, generic terms. Calling a component library "Component" is like naming your dog "Dog".
Naming is hard. Have you read Zach Tellmanās āElements of Clojureā?
(itās a work in progress book right now)
john: 1st Rule of Naming: do not use common, generic terms. Calling a component library "Component" is like naming your dog "Dog".