Raul, I think you might like http://norvig.com/ow.ps and I suspect you might've already read this.
On Sun, Mar 2, 2014 at 11:19 AM, Raul Miller <[email protected]> wrote: > Wait, wait, wait... > > First off, let's acknowledge that when we say "object" here, we do not > really mean an object in the normal human sense. Instead we are referring > to a computational abstraction which we hope in some sense represents > something else. > > But that computational abstraction is not a noun or a verb, it's an > arbitrarily complex thing. In essence, it's a somewhat crippled virtual > machine. > > And that crippling is deliberate. One of the most important concepts of > "object oriented theory" is "information hiding". Of course, information > cannot really be hidden, so it's a crippled form of information hiding. But > the theory is that if we do not understand what we are working with that > that somehow makes things better. > > Needless to say, that theory is itself somewhat lame. And my expression of > it here, even more so. > > But what it comes down to is: an object is not itself, but a thing which > represents itself. > > Needless to say, this can never be fully implemented. If it was, it would > no longer be an object. > > Anyways... > > In J, we use limited names as object references. Why? > > Well, let's take a step back - what is the use for objects? > > In terms of use, objects represent the interface between people. They give > us a way of getting things done in the face of incomplete information. They > are, in essence, a deliberate mix of partial understanding and partial > misunderstanding. They give us a way of freezing the interface between > something one person built and something another person built. > > Of course, nowadays, machines are getting cheap enough that "virtual" > machines can often be replaced by "real" machines. But they are also > getting fast enough that often "real" machines are overkill and "virtual" > machines are good enough. > > But this happens at all levels of abstraction - it's not just inside J but > at the OS level, and in other languages that we need to deal with these > kinds of things. > > Anyways... I think it's a bit much to expect the language to entirely solve > these kinds of abstraction issue. At some point the programmer is going to > have to admit some kind of understanding and just give in and do something > actually useful. Maybe not every day, but occasionally we do have to admit > to understanding something. > > Or at least, that's what I tell myself. > > In the case of object references, in J, we should probably have enough > skill to write a verb that behaves as we want. > > See also: > > > http://www.codeproject.com/Articles/35789/Understanding-Factory-Method-and-Abstract-Factory > > http://blogs.msdn.com/b/oldnewthing/archive/2004/05/07/127826.aspx > > > http://www.boost.org/doc/libs/1_55_0/libs/python/doc/tutorial/doc/html/python/exposing.html > > Thanks, > > -- > Raul > > > > On Sun, Mar 2, 2014 at 7:58 AM, Pascal Jasmin <[email protected] > >wrote: > > > > Back to J, I have never felt the need for nested names > > > > I think there is a simple feature (bug) missing from j > > > > if db_application_ is an object, you cannot do > > > > table1__db_base_ much less field1__table1__db_base_ > > > > you can do: > > field1__table1__d [ d. = db_base_ > > > > less convenient, but you can also do (if table1 is <'3' locale) > > > > field1_3_db_application_ > > > > The issue is not being able to mix __ and _y_ calling conventions. > > > > > > > > ----- Original Message ----- > > From: chris burke <[email protected]> > > To: Programming forum <[email protected]> > > Cc: > > Sent: Sunday, March 2, 2014 12:38:13 AM > > Subject: Re: [Jprogramming] Intro; Learning J Feedback > > > > Sorry, I got this wrong (which shows how much this comes up). > > > > You can indeed use nested names in current kdb+, as in: > > > > q).a.b.c:123 > > q).a.b.c > > 123 > > > > What you cannot do is change context to more than one level below root, > > e.g. > > > > this is OK: > > q)\d .a > > q.a) > > > > this fails: > > q)\d .a.b > > '.a.b > > > > So nested names is not fully supported. > > > > Back to J, I have never felt the need for nested names, though I > obviously > > use them in Java and similar languages. Perhaps this is because J gets by > > with much shallower locale paths compared to more traditional languages. > > > > > > > > > > On Sun, Mar 2, 2014 at 12:35 PM, chris burke <[email protected]> > wrote: > > > > > > Contrast this with the K tree which I think allows names like this: > > > > > > > > .node1.node2.node3.leaf > > > > > > No, this is not possible, at least in the current kdb+ system. > > > > > > > > > > > > On Sun, Mar 2, 2014 at 12:28 PM, Raul Miller <[email protected] > > >wrote: > > > > > >> What I mean by that is that locales cannot contain other locales. > > >> > > >> name_locale_ > > >> > > >> Contrast this with the K tree which I think allows names like this: > > >> > > >> .node1.node2.node3.leaf > > >> > > >> (using the . to separate names rather than _ and working from left to > > >> right > > >> rather than from right to left). > > >> > > >> Of course, K sacrifices "OOP" in its focus on speed. So it might not > be > > so > > >> good in an educational context. But I highly respect Arthur Whitney's > > >> taste > > >> in tradeoffs, and I think they are worth keeping in mind, especially > > when > > >> offering explanations. > > >> > > >> In J, you can have names like this_is_an_example (with embedded > > >> underlines) > > >> and you can reference that in a locale by including a locale suffix: > > >> > > >> this_is_an_example_base_=: 1 > > >> > > >> or > > >> foo=: <'base' > > >> this_is_an_example__foo=: 2 > > >> > > >> But this is an error: > > >> foo=: <'this_is_odd' > > >> this_is_an_example__foo=: 3 > > >> |ill-formed name: foo > > >> > > >> Only the last two underlines matter currently, in J, and locale names > > >> cannot contain the '_' character. The other optional '_' characters in > > >> names are just decoration. > > >> > > >> Does this make sense? > > >> > > >> Thanks, > > >> > > >> -- > > >> Raul > > >> > > >> > > >> On Sat, Mar 1, 2014 at 10:58 PM, chris burke <[email protected]> > > >> wrote: > > >> > > >> > > ... they all exist on the same level > > >> > > > >> > I am not sure what you mean by this, but J has had locale paths > since > > >> J4, > > >> > for example this enables OOP, e.g. create an object from a class. > See > > >> > http://www.jsoftware.com/papers/joop.htm > > >> > > > >> > > > >> > On Sat, Mar 1, 2014 at 2:22 PM, Raul Miller <[email protected]> > > >> wrote: > > >> > > > >> > > Directories are hierarchical - you can have a directory "inside" > > >> another > > >> > > directory. > > >> > > > > >> > > There's no way of doing that with locales - they all exist on the > > same > > >> > > level (though of course you can have a reference to any locale > > inside > > >> any > > >> > > locale). > > >> > > > > >> > > Thanks, > > >> > > > > >> > > -- > > >> > > Raul > > >> > > > > >> > > > > >> > > > > >> > > On Sat, Mar 1, 2014 at 12:25 AM, Don Guinn <[email protected]> > > >> wrote: > > >> > > > > >> > > > I don't understand what you mean when you say "locals are not > > >> > > > hierarchical". Locales are just name spaces. Locales are > > implicitly > > >> > > > referenced through path (18!:2). The path determines how locales > > are > > >> > > > searched to resolve a name not found in the current locale. This > > >> search > > >> > > is > > >> > > > hierarchical. The locales are searched in the order specified in > > >> 18!:2. > > >> > > But > > >> > > > each locale has its own path. In this way the hierarchy of > locales > > >> > > depends > > >> > > > on the current locale. In this way it is easy to implement > classes > > >> in > > >> > J. > > >> > > > But paths can be used outside of J classes in interesting ways. > > >> > > > > > >> > > > > > >> > > > On Fri, Feb 28, 2014 at 8:52 PM, Steven Taylor < > [email protected] > > > > > >> > > wrote: > > >> > > > > > >> > > > > the verbname__location / verbname_location_ format places more > > >> > emphasis > > >> > > > on > > >> > > > > the verb or noun inside that locale (assuming a left to right > > >> > cultural > > >> > > > > reading orientation). That appears illogical because nobody > > else > > >> > does > > >> > > > > that, however it can help with readability if you can get used > > to > > >> it. > > >> > > > > > > >> > > > > It also helps if you can flatten out the locale 'tree' > (although > > >> > > locales > > >> > > > > are not hierarchical). I mean just symantically. > > >> > > > > > > >> > > > > I found the process of re-evaluating how I initially thought > > >> > namespaces > > >> > > > > 'should' work refreshing and overall I think locales have > helped > > >> me > > >> > > make > > >> > > > > better namespace naming choices in other more verbose > languages. > > >> > > > > > > >> > > > > I'd also encourage considering locales outside of a strict oo > > >> > context. > > >> > > > > Try to stay away from state when possible. > > >> > > > > > > >> > > > > This is so obvious I am embarrassed that it took me so long to > > >> > consider > > >> > > > > this -- there are French and english 'locales' in Canada... > And > > I > > >> > > thought > > >> > > > > this sense of the word may have been behind J's use of it. > > >> Probably > > >> > > > that's > > >> > > > > obvious to everyone in north America ;-). > > >> > > > > > > >> > > > > If you find yourself writing > > >> > > > > A wrapper just around a structure like this > > >> > > > > Dictionary<string,Dictionary<string,obj>>, you'll know that > > >> locales > > >> > > have > > >> > > > > grown on you. I may have done that recently > > >> > > > > ;) > > >> > > > > > > >> > > > > -Steven T. > > >> > > > > > > >> > > > > > > >> > > ---------------------------------------------------------------------- > > >> > > > > For information about J forums see > > >> > http://www.jsoftware.com/forums.htm > > >> > > > > > > >> > > > > > >> ---------------------------------------------------------------------- > > >> > > > For information about J forums see > > >> http://www.jsoftware.com/forums.htm > > >> > > > > > >> > > > > ---------------------------------------------------------------------- > > >> > > For information about J forums see > > >> http://www.jsoftware.com/forums.htm > > >> > > > > >> > > ---------------------------------------------------------------------- > > >> > For information about J forums see > > http://www.jsoftware.com/forums.htm > > >> > > > >> ---------------------------------------------------------------------- > > >> For information about J forums see > http://www.jsoftware.com/forums.htm > > >> > > > > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
