On Tue, Dec 8, 2020 at 3:49 PM emacstheviking <[email protected]> wrote: > I am never going to get a job working with J unless I start my own start-up > I guess.
Employment is often a stressful subject, so I've been thinking about this one. So... first off, working with other people is an interesting subject, where how things play out over time and with large numbers of people winds up being an overriding concern. You don't get points for "going out in the weeds" (as golfers might say). You do get points for getting your part done quickly and with a minimum of fuss. So, how does J fit into those scenarios? Well, obviously, it depends, but it more or less breaks down like this: (+) Working with J tends to help you think about working with large sets of data, where a lot of computer training is focused on working with the smallest amounts of data. (There are some exceptions, but not enough.) (+) J can be used for prototype development, often resulting in quick implementations in other programming languages. (+) The phrase "programming language" is a deceitful phrase in most management contexts. Most people have a concept of "language" which includes languages like english. Consider, for example the xkcd "up goer five" which was "explained using only the ten hundred words people use the most often". In contrast, the vocabulary of J includes only a few dozen words. And, most coding libraries include far more "words" (library entries) than any single "programming language". So, instead of "programming language", I suspect "programming vocabulary" would be a better phrase in management discussions. (But "programming language" is still the right phrase in historical discussions of these issues.) But, also, a "caltech" (or "grace hopper") approach which tries to simplify coding by making it more english-like is going to result in deceptive complexity and nearly intractable problems (when you get to debugging). When working that way, you should expect frequent failures and eventual extreme caution. (Which, granted, might be the right approach in some problem domains). (+) In the long run, it's really interfaces which are important. Well documented interfaces let you swap out implementations when systems fail, and that's where you want to be for the most part. (Business types may immediately come up with the counter argument that they do not want competitor implementations replacing their own, but that's more a matter of where the interface boundaries are drawn, and what goes into the implementation than anything else. Mostly what you need to address there is adequate documentation. And a language is documentation but only at a rudimentary level.) Ironically, or perhaps not, there's a lot of contradictions which go into any employment effort, and at some level you have to go with your gut. ---------------------- In terms of actual employment: In many contexts, the "computer language" you use doesn't matter. In most job situations that need results, you use whatever tools you have at hand to produce the results you need. That said you will probably need to interoperate with tools from major companies (microsoft, apple, google, facebook), and in a few cases your working environment will be locked down (preventing you from using "foreign tools"), so it all depends. As a general rule, though, if you are in that situation for what looks like a long term, if you're not doing much of anything useful. It might be better to seek a job in a more productive environment? However, *programming* jobs are a bit different. In programming jobs, you're often working with other people who are also coding, and you do not get to mandate what language they use (unless you are a manager, at which point you also get to deal with the problem of finding people who are skilled enough to be worth paying). So, yes, starting your own company can be a good place to go if you want to use tools that you feel comfortable with. Though, at that point, there's more to be concerned with than just your tools... Anyways, "it all depends" but J as an employment opportunity is really about "J as a toolset which can interoperate with other toolsets". And, the going there is slow, because of issues like security concerns (which mostly winds up being a way of saying "guess work", on the larger levels of abstraction, where politicians drive economies. On the levels we address with coding, this mostly winds up being a context where spinning up a coding environment can take days, where standardization is intended to fix that by handing the job to a specialist, and where inevitably the specialist who spins up an environment for you gets things wrong which then takes a long time to deal with, but at least gives managers some hope that the people who work for them will be able to work with each other...). ---------------------- Long story short, it's typically going to be a mix of the incredibly boring and the occasional "far too difficult" issues, and it's best to use those boring stretches to anticipate and try to prepare for the oncoming problems. J can help you there, to the degree that you're able to understand those problems. And, especially, when its vocabulary helps you simplify those problems. ---------------------- This was probably an example of an "incredibly boring" treatment of a "far too difficult" set of issues, but... it's the best I can do today. Thanks, -- Raul Original: On Tue, Dec 8, 2020 at 3:49 PM emacstheviking <[email protected]> wrote: > > Yes Henry I know about those. > I have a reasonable understanding of it but I lack the flying time in > general solving real issues with J. > > I spent 45 minutes last night just absorbing the page on ranks, array, > k-cells and frames....it makes sense when you read it! > > I am never going to get a job working with J unless I start my own start-up > I guess. > Thanks. > Sean > > > On Tue, 8 Dec 2020 at 19:36, Henry Rich <[email protected]> wrote: > > > Do you know about NuVoc and the ancillary pages pointed to below the > > primitive table? There is a lot written about rank. > > > > Henry Rich > > > > On 12/8/2020 2:27 PM, emacstheviking wrote: > > > Hauke, > > > PERFECT! > > > > > > ,.psz &.> pqfname@(res&;)"0 i.ncols > > > ┌───────────────────┐ > > > │id │ > > > ├───────────────────┤ > > > │invoice_id │ > > > ├───────────────────┤ > > > │created │ > > > ├───────────────────┤ > > > │status │ > > > ├───────────────────┤ > > > │ce_survey_id │ > > > ├───────────────────┤ > > > │organisation_id │ > > > ├───────────────────┤ > > > │payment_provider_id│ > > > └───────────────────┘ > > > > > > I just have to go through it step at a time until I fully understand the > > > magic! I have a vague understanding of rank and shape and that you can > > use > > > "0 "1 etc which affects the frame/k-cell metrics but could you explain > > what > > > it is doing here please? > > > > > > Thanks > > > Sean > > > > > > > > > On Tue, 8 Dec 2020 at 17:15, Hauke Rehr <[email protected]> wrote: > > > > > >> Did I miss something or didn’t anyone answer the looping question yet? > > >> > > >> Without knowing much about what the names involved are doing, > > >> I think it ought to be > > >> pqfname@(res&;)"0 i. ncols > > >> which will have the shape > > >> (shape of i. ncols)×(shape of whatever pqfname res;0 returns) > > >> > > >> Am 08.12.20 um 14:34 schrieb emacstheviking: > > >>> Apologies for the length of this email but my brain has thrown one > > >> again... > > >>> I am currently working on a wrapper for Postgres using libpq-fe. It's > > >>> working but in need of some higher level functions to make result sets > > >>> easier to work with and feel more J-like. > > >>> > > >>> Once the query is executed, all results have been stored in RAM by the > > >>> library (not my first choice!) and then a value is obtained like so > > >>> > > >>> pqgetvalue result_set;row;col > > >>> > > >>> I've seen the source code for the library and the above translate > > >> directly > > >>> into an array read; > > >>> > > >>> char * PQgetvalue(const PGresult *res, int tup_num, int field_num) > > >>> { > > >>> if (!check_tuple_field_number(res, tup_num, field_num)) > > >>> return NULL; > > >>> return res->tuples[tup_num][field_num].value; > > >>> } > > >>> > > >>> > > >>> *# mema and management.* > > >>> > > >>> My plan was to write a 'pgquery' verb that takes the connection handle > > >> and > > >>> a SQL query (details to be settled) and then creates and executes the > > >> query > > >>> and returns back a table of boxed strings. My first question then is > > how > > >> is > > >>> the memory managed? I know from the documentation that memf is the > > >> natural > > >>> (obverse?) way to release memory but I wanted to know what happens if I > > >>> allocate a string with mema then return it and assign it into a boxed > > >>> structure. I have an ffi helper I wrote, I call it psz: > > >>> > > >>> psz=: 3 : 'memr (>y),0,_1' > > >>> > > >>> If I assign the return value to a variable: > > >>> > > >>> name =. psz a-mem-address-of-a-C-String > > >>> > > >>> is the pointer aliased or can I now memf the original address and still > > >>> have a viable copy of the string later. I ask this because, for the > > >>> lifetime of the result set object, the internally allocated memory is > > >>> always around until a pqclear is executed. In this particular case I am > > >>> hopefully correct in thinking that my returned box list of strings is > > >>> stable up until that time. > > >>> > > >>> (In --this case-- I don't need to release anything as the library does > > it > > >>> but I wanted a general asnwer about what memr actually does) > > >>> > > >>> I am more interested in the general case of using 'memr' though; does > > it > > >>> allocate a copy or, as I suspect, is it merely re-typing the memory > > >> address > > >>> as a string, in the same manner that 'ic' can be used to process > > integers > > >>> and floats. Some insights would be appreciated. > > >>> > > >>> > > >>> *# looping* > > >>> > > >>> This brings me to how best to extract the data from the internal result > > >>> set? My basic flow so far is this: > > >>> > > >>> conn=. pqconnectdb<'dbname=foo' > > >>> res=.pqexec conn;'select * from some_table' > > >>> nrows=. pqtuples res > > >>> ncols=. pqfields res > > >>> > > >>> So I might have 7 rows and 12 columns per row. Obtaining the name of > > the > > >>> columns is done using the pqfname call. I've been playing around and > > the > > >>> basic loop I have is awful! > > >>> > > >>> pgtest =: 3 : 0 > > >>> nrows=. pqntuples y > > >>> ncols=. pqnfields y > > >>> NB. get the column names as the first row > > >>> for_j. i. ncols do. > > >>> c =. pqfname y;j > > >>> smoutput psz c > > >>> end. > > >>> '' > > >>> ) > > >>> > > >>> I know I can do this 'looplessly' but have so far failed. It's going to > > >> be > > >>> a combination of bonding and maybe a hook or something but as I say, > > >> total > > >>> quagmire at the moment! The thing I require to be looped is this: > > >>> > > >>> pqfname res;col. NB. where col is i. ncols > > >>> > > >>> My thought process was along the lines of, produce an array of res;i > > >> pairs > > >>> but that feels ugly, then I thought about and played with trying to > > just > > >>> pass the i. ncols list into a bonded call to ; but somehow got stuck... > > >>> > > >>> So..I am after some nice solutions to how best to iterate ncols to > > obtain > > >>> the initial row of column names and then extract each row of data from > > >> the > > >>> result set...I know this can be done very succinctly, I continue to > > work > > >> on > > >>> it... > > >>> > > >>> Loving the challenge of thinking so differently! > > >>> > > >>> Thanks all, > > >>> Sean > > >>> ---------------------------------------------------------------------- > > >>> For information about J forums see http://www.jsoftware.com/forums.htm > > >>> > > >> -- > > >> ---------------------- > > >> mail written using NEO > > >> neo-layout.org > > >> > > >> ---------------------------------------------------------------------- > > >> For information about J forums see http://www.jsoftware.com/forums.htm > > >> > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > -- > > This email has been checked for viruses by AVG. > > https://www.avg.com > > > > ---------------------------------------------------------------------- > > 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
