I did like that. I do not remember reading it before, but I might have. There's a lot of good reasoning behind that kind of presentation.
But I am also reminded of Google's struggles. In essence, they seem to be caught in a sort of early stages of "AI-war". Recently, using google, I have noticed a lot of garbage results. Garbage, for me, being spam and/or foreign language content. These are related - both of them being content from communities which at that time did not interest me. Anyways, the spam and spam filtering issues are a natural consequence of increased capability of coding systems and their adoption by people who need ... well, I'll leave it up to them to define what they need. Meanwhile, the foreign language issues are a more historical variation on the theme of what drives human interest. For myself, what I most often miss from Google's search results are content from previous years. I often wish their advanced search would let me focus on older content. I have ideas about why they do not do this, but at the same time I wish that they at least were better using information gleaned in past years to help distinguish spam from ham. But I also wish that I could shift my interests into artificially generated text, just to see what's there, and then back out without having to have that interest be thought of as relevant to unrelated searches. Basically, I see Google's business model as finding immediate commercial applications for high end computational structures (aka "artificial intelligence") and that's really a tough business to be in. Between regulatory pressures designed to drive everyone's competition out of business and the boring nature of day-to-day business needs, they're actually doing amazingly well. But it's painful to watch them being eaten alive by the very things driving their success. Thanks, -- Raul On Sun, Mar 2, 2014 at 11:33 AM, Vijay Lulla <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
