Re: [Jchat] Interesting talk "How did we end up Here?"
On Mon, Sep 28, 2015 at 6:10 AM, Jo van Schalkwyk wrote: > It's a little while since I played with Erlang, but the approach used > struck me as pretty generic (if unusual), rather than being 'niche'. I'm going to quote someone else's opinion: "Basically Erlang is really good at receiving, parsing, and sending data, and bad at anything remotely processor-intensive (or graphical)." But of course, a lot of coding nowadays is all about the stuff Erlang is good at... -- Raul -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jchat] Interesting talk "How did we end up Here?"
It's a little while since I played with Erlang, but the approach used struck me as pretty generic (if unusual), rather than being 'niche'. I think it's early on in Cesarini's Erlang book that he describes how while still a young programmer he had a task which seemed to require a "shared mutable state" that was straightforward in Erlang. He then tried the same thing in C++ and found it cripplingly difficult. I also found the Erlang microthreading approach (and the associated benchmarks) quite impressive, with Java falling over with ten thousand concurrent processes, while Erlang managed 100,000 with ease. This was some years ago. I agree with Raul that you need to pick your language carefully. My 2c is that I've seen any number of distributed projects founder, and in such circumstances Erlang may be worth a second glance (even before you go belly-up :) Another thing to look at is Stackless Python. Jo. On 28 September 2015 at 16:20, Devon McCormick wrote: > But does that mean you have to adapt your algo to fit particular > requirements? > > > On Sun, Sep 27, 2015 at 3:59 PM, Jo van Schalkwyk > > wrote: > > > Re the horrors of "shared mutable state", one consideration is to look at > > Erlang. Joe Armstrong seems to have it about right. What Erlang does is > to > > use 'variables' that can only be written once, and then build from there > > up. It's elegant and seems to prevents the nightmare that Devon > describes. > > > > Regards Jo. > > > > On 28 September 2015 at 07:59, Don Guinn wrote: > > > > > Why would array programming require a large team? The problem with > large > > > teams is coordination of many people. I would think that if anything > > array > > > programming groups would be smaller. > > > On Sep 27, 2015 11:41 AM, "Devon McCormick" > wrote: > > > > > > > At a Kdb talk I attended recently, Fintan Quill mentioned that K does > > > > multi-processing but not multi-threading. He didn't go into details > on > > > > this but, based on what they say in this talk and what I've heard > > > > elsewhere, the reason seems obvious: multi-threading is nearly > > impossible > > > > to get to work properly. > > > > > > > > As they say in this talk about how "Shared Mutable State" in > > > multi-threaded > > > > programming should be some of the most feared words in computing, > > Martin > > > > Thompson elaborates "It's a complete nightmare even with really, > really > > > > good people." He then goes on to add "I haven't come across any > > > > multi-threaded application where people are mutating the same space, > > that > > > > isn't bug-ridden." > > > > > > > > So, in short, don't do this. Don't even try to do this: > fine-grained, > > > > multi-threaded parallelism is probably a waste of time with the > current > > > > level of tools we have for it. > > > > > > > > Multi-processing, on the other hand, is dead-easy to do in J for > > anything > > > > that can be parallelized at a coarse-grained level, which is many if > > not > > > > most things. I've written about this extensively over the past few > > years > > > > (all at jcode.jsoftware.com/wiki/): > > > > User:Devon_McCormick/ParallelizedJCodeExamples, > > > > Community/Conference2012/Talks/ParallelSimulationInJ, > > > > NYCJUG/2011-04-12/RedOrBlackGameSimulation > > > > . These latter two give detailed examples on how to achieve > > > > multi-processor parallelization. > > > > > > > > On another note, there's been some mention of processes like Agile > for > > > > speeding up the development process. Keep in mind that the context > for > > > > these kinds of "methodologies" is an idea that a small team might be > > five > > > > people. In the array-programming world, this would be a large team. > > > > > > > > > > > > On Sat, Sep 26, 2015 at 7:19 PM, Don Guinn > wrote: > > > > > > > > > Given a fork (f g h) f and h can be processed in parallel. But if f > > > and h > > > > > have side effects (shared global names that are modified) then they > > > > should > > > > > not run in parallel. A programming practice that should be avoided > > > > > anyway. This is not a pipeline, but multiple processors could be > > used. > > > > But > > > > > even not running them in parallel I see nothing stating which, f or > > h, > > > is > > > > > run first. So one should avoid code that depended on the order of f > > > and h > > > > > execution anyway. > > > > > > > > > > On Sat, Sep 26, 2015 at 4:42 PM, Raul Miller < > rauldmil...@gmail.com> > > > > > wrote: > > > > > > > > > > > On Sat, Sep 26, 2015 at 3:04 PM, Vijay Lulla < > vijaylu...@gmail.com > > > > > > > > wrote: > > > > > > > quite easy. But what I'm very unclear about is how does one do > > > > > > > pipelining in J? Say we have functions f, g, and h (all used > > > > > > > monadically) and it is applied like f@g@h y and function g was > > > > > > > particularly costly how can we parallelize (maybe the user has > to > > > > > > > program it himself or the interpreter can do some cost analys
Re: [Jchat] Interesting talk "How did we end up Here?"
But does that mean you have to adapt your algo to fit particular requirements? On Sun, Sep 27, 2015 at 3:59 PM, Jo van Schalkwyk wrote: > Re the horrors of "shared mutable state", one consideration is to look at > Erlang. Joe Armstrong seems to have it about right. What Erlang does is to > use 'variables' that can only be written once, and then build from there > up. It's elegant and seems to prevents the nightmare that Devon describes. > > Regards Jo. > > On 28 September 2015 at 07:59, Don Guinn wrote: > > > Why would array programming require a large team? The problem with large > > teams is coordination of many people. I would think that if anything > array > > programming groups would be smaller. > > On Sep 27, 2015 11:41 AM, "Devon McCormick" wrote: > > > > > At a Kdb talk I attended recently, Fintan Quill mentioned that K does > > > multi-processing but not multi-threading. He didn't go into details on > > > this but, based on what they say in this talk and what I've heard > > > elsewhere, the reason seems obvious: multi-threading is nearly > impossible > > > to get to work properly. > > > > > > As they say in this talk about how "Shared Mutable State" in > > multi-threaded > > > programming should be some of the most feared words in computing, > Martin > > > Thompson elaborates "It's a complete nightmare even with really, really > > > good people." He then goes on to add "I haven't come across any > > > multi-threaded application where people are mutating the same space, > that > > > isn't bug-ridden." > > > > > > So, in short, don't do this. Don't even try to do this: fine-grained, > > > multi-threaded parallelism is probably a waste of time with the current > > > level of tools we have for it. > > > > > > Multi-processing, on the other hand, is dead-easy to do in J for > anything > > > that can be parallelized at a coarse-grained level, which is many if > not > > > most things. I've written about this extensively over the past few > years > > > (all at jcode.jsoftware.com/wiki/): > > > User:Devon_McCormick/ParallelizedJCodeExamples, > > > Community/Conference2012/Talks/ParallelSimulationInJ, > > > NYCJUG/2011-04-12/RedOrBlackGameSimulation > > > . These latter two give detailed examples on how to achieve > > > multi-processor parallelization. > > > > > > On another note, there's been some mention of processes like Agile for > > > speeding up the development process. Keep in mind that the context for > > > these kinds of "methodologies" is an idea that a small team might be > five > > > people. In the array-programming world, this would be a large team. > > > > > > > > > On Sat, Sep 26, 2015 at 7:19 PM, Don Guinn wrote: > > > > > > > Given a fork (f g h) f and h can be processed in parallel. But if f > > and h > > > > have side effects (shared global names that are modified) then they > > > should > > > > not run in parallel. A programming practice that should be avoided > > > > anyway. This is not a pipeline, but multiple processors could be > used. > > > But > > > > even not running them in parallel I see nothing stating which, f or > h, > > is > > > > run first. So one should avoid code that depended on the order of f > > and h > > > > execution anyway. > > > > > > > > On Sat, Sep 26, 2015 at 4:42 PM, Raul Miller > > > > wrote: > > > > > > > > > On Sat, Sep 26, 2015 at 3:04 PM, Vijay Lulla > > > > > wrote: > > > > > > quite easy. But what I'm very unclear about is how does one do > > > > > > pipelining in J? Say we have functions f, g, and h (all used > > > > > > monadically) and it is applied like f@g@h y and function g was > > > > > > particularly costly how can we parallelize (maybe the user has to > > > > > > program it himself or the interpreter can do some cost analysis > > [like > > > > > > query planning in SQL databases]) it to make it faster? Isn't > this > > > > > > what the presenters were mentioning when they were using the > > example > > > > > > of airbus pipeline system? > > > > > > > > > > "Pipelining" seems to describe a variety of topics. > > > > > > > > > > https://en.wikipedia.org/wiki/Pipeline_(computing) > > > > > > > > > > So, I would have to say that there is no general technique. If f, g > > > > > and h are black boxes, you cannot pipeline them. If you want to > > > > > reschedule g or make it more efficient, you'll need to know details > > > > > about g. The more you know, the greater the odds are that you can > do > > > > > it (or the important parts of it) differently, in a more efficient > > > > > manner. > > > > > > > > > > That said, I should also point out that a lot of the automated > query > > > > > planning systems are workarounds for bogus constraints underlying > the > > > > > sql standard. That effort could have gone in much more useful > > > > > directions if people hadn't bought into those ideas. (But at this > > > > > point, it has turned into a multi-billion dollar industry, so it's > > not > > > > > going away. And there are some app
Re: [Jchat] Interesting talk "How did we end up Here?"
Erlang is a lovely design, for certain kinds of problems (which is to say: building communicating systems). It's not so good though, for other kinds of problems. You can find examples of people venturing into these areas if you do a little searching. (Nothing against Erlang here - all programming languages have some areas where they do less well.) -- Raul On Sun, Sep 27, 2015 at 3:59 PM, Jo van Schalkwyk wrote: > Re the horrors of "shared mutable state", one consideration is to look at > Erlang. Joe Armstrong seems to have it about right. What Erlang does is to > use 'variables' that can only be written once, and then build from there > up. It's elegant and seems to prevents the nightmare that Devon describes. > > Regards Jo. > > On 28 September 2015 at 07:59, Don Guinn wrote: > >> Why would array programming require a large team? The problem with large >> teams is coordination of many people. I would think that if anything array >> programming groups would be smaller. >> On Sep 27, 2015 11:41 AM, "Devon McCormick" wrote: >> >> > At a Kdb talk I attended recently, Fintan Quill mentioned that K does >> > multi-processing but not multi-threading. He didn't go into details on >> > this but, based on what they say in this talk and what I've heard >> > elsewhere, the reason seems obvious: multi-threading is nearly impossible >> > to get to work properly. >> > >> > As they say in this talk about how "Shared Mutable State" in >> multi-threaded >> > programming should be some of the most feared words in computing, Martin >> > Thompson elaborates "It's a complete nightmare even with really, really >> > good people." He then goes on to add "I haven't come across any >> > multi-threaded application where people are mutating the same space, that >> > isn't bug-ridden." >> > >> > So, in short, don't do this. Don't even try to do this: fine-grained, >> > multi-threaded parallelism is probably a waste of time with the current >> > level of tools we have for it. >> > >> > Multi-processing, on the other hand, is dead-easy to do in J for anything >> > that can be parallelized at a coarse-grained level, which is many if not >> > most things. I've written about this extensively over the past few years >> > (all at jcode.jsoftware.com/wiki/): >> > User:Devon_McCormick/ParallelizedJCodeExamples, >> > Community/Conference2012/Talks/ParallelSimulationInJ, >> > NYCJUG/2011-04-12/RedOrBlackGameSimulation >> > . These latter two give detailed examples on how to achieve >> > multi-processor parallelization. >> > >> > On another note, there's been some mention of processes like Agile for >> > speeding up the development process. Keep in mind that the context for >> > these kinds of "methodologies" is an idea that a small team might be five >> > people. In the array-programming world, this would be a large team. >> > >> > >> > On Sat, Sep 26, 2015 at 7:19 PM, Don Guinn wrote: >> > >> > > Given a fork (f g h) f and h can be processed in parallel. But if f >> and h >> > > have side effects (shared global names that are modified) then they >> > should >> > > not run in parallel. A programming practice that should be avoided >> > > anyway. This is not a pipeline, but multiple processors could be used. >> > But >> > > even not running them in parallel I see nothing stating which, f or h, >> is >> > > run first. So one should avoid code that depended on the order of f >> and h >> > > execution anyway. >> > > >> > > On Sat, Sep 26, 2015 at 4:42 PM, Raul Miller >> > > wrote: >> > > >> > > > On Sat, Sep 26, 2015 at 3:04 PM, Vijay Lulla >> > > wrote: >> > > > > quite easy. But what I'm very unclear about is how does one do >> > > > > pipelining in J? Say we have functions f, g, and h (all used >> > > > > monadically) and it is applied like f@g@h y and function g was >> > > > > particularly costly how can we parallelize (maybe the user has to >> > > > > program it himself or the interpreter can do some cost analysis >> [like >> > > > > query planning in SQL databases]) it to make it faster? Isn't this >> > > > > what the presenters were mentioning when they were using the >> example >> > > > > of airbus pipeline system? >> > > > >> > > > "Pipelining" seems to describe a variety of topics. >> > > > >> > > > https://en.wikipedia.org/wiki/Pipeline_(computing) >> > > > >> > > > So, I would have to say that there is no general technique. If f, g >> > > > and h are black boxes, you cannot pipeline them. If you want to >> > > > reschedule g or make it more efficient, you'll need to know details >> > > > about g. The more you know, the greater the odds are that you can do >> > > > it (or the important parts of it) differently, in a more efficient >> > > > manner. >> > > > >> > > > That said, I should also point out that a lot of the automated query >> > > > planning systems are workarounds for bogus constraints underlying the >> > > > sql standard. That effort could have gone in much more useful >> > > > directions if people hadn't
Re: [Jchat] Interesting talk "How did we end up Here?"
Re the horrors of "shared mutable state", one consideration is to look at Erlang. Joe Armstrong seems to have it about right. What Erlang does is to use 'variables' that can only be written once, and then build from there up. It's elegant and seems to prevents the nightmare that Devon describes. Regards Jo. On 28 September 2015 at 07:59, Don Guinn wrote: > Why would array programming require a large team? The problem with large > teams is coordination of many people. I would think that if anything array > programming groups would be smaller. > On Sep 27, 2015 11:41 AM, "Devon McCormick" wrote: > > > At a Kdb talk I attended recently, Fintan Quill mentioned that K does > > multi-processing but not multi-threading. He didn't go into details on > > this but, based on what they say in this talk and what I've heard > > elsewhere, the reason seems obvious: multi-threading is nearly impossible > > to get to work properly. > > > > As they say in this talk about how "Shared Mutable State" in > multi-threaded > > programming should be some of the most feared words in computing, Martin > > Thompson elaborates "It's a complete nightmare even with really, really > > good people." He then goes on to add "I haven't come across any > > multi-threaded application where people are mutating the same space, that > > isn't bug-ridden." > > > > So, in short, don't do this. Don't even try to do this: fine-grained, > > multi-threaded parallelism is probably a waste of time with the current > > level of tools we have for it. > > > > Multi-processing, on the other hand, is dead-easy to do in J for anything > > that can be parallelized at a coarse-grained level, which is many if not > > most things. I've written about this extensively over the past few years > > (all at jcode.jsoftware.com/wiki/): > > User:Devon_McCormick/ParallelizedJCodeExamples, > > Community/Conference2012/Talks/ParallelSimulationInJ, > > NYCJUG/2011-04-12/RedOrBlackGameSimulation > > . These latter two give detailed examples on how to achieve > > multi-processor parallelization. > > > > On another note, there's been some mention of processes like Agile for > > speeding up the development process. Keep in mind that the context for > > these kinds of "methodologies" is an idea that a small team might be five > > people. In the array-programming world, this would be a large team. > > > > > > On Sat, Sep 26, 2015 at 7:19 PM, Don Guinn wrote: > > > > > Given a fork (f g h) f and h can be processed in parallel. But if f > and h > > > have side effects (shared global names that are modified) then they > > should > > > not run in parallel. A programming practice that should be avoided > > > anyway. This is not a pipeline, but multiple processors could be used. > > But > > > even not running them in parallel I see nothing stating which, f or h, > is > > > run first. So one should avoid code that depended on the order of f > and h > > > execution anyway. > > > > > > On Sat, Sep 26, 2015 at 4:42 PM, Raul Miller > > > wrote: > > > > > > > On Sat, Sep 26, 2015 at 3:04 PM, Vijay Lulla > > > wrote: > > > > > quite easy. But what I'm very unclear about is how does one do > > > > > pipelining in J? Say we have functions f, g, and h (all used > > > > > monadically) and it is applied like f@g@h y and function g was > > > > > particularly costly how can we parallelize (maybe the user has to > > > > > program it himself or the interpreter can do some cost analysis > [like > > > > > query planning in SQL databases]) it to make it faster? Isn't this > > > > > what the presenters were mentioning when they were using the > example > > > > > of airbus pipeline system? > > > > > > > > "Pipelining" seems to describe a variety of topics. > > > > > > > > https://en.wikipedia.org/wiki/Pipeline_(computing) > > > > > > > > So, I would have to say that there is no general technique. If f, g > > > > and h are black boxes, you cannot pipeline them. If you want to > > > > reschedule g or make it more efficient, you'll need to know details > > > > about g. The more you know, the greater the odds are that you can do > > > > it (or the important parts of it) differently, in a more efficient > > > > manner. > > > > > > > > That said, I should also point out that a lot of the automated query > > > > planning systems are workarounds for bogus constraints underlying the > > > > sql standard. That effort could have gone in much more useful > > > > directions if people hadn't bought into those ideas. (But at this > > > > point, it has turned into a multi-billion dollar industry, so it's > not > > > > going away. And there are some applications where the flaws are not > > > > all that important.) > > > > > > > > Thanks, > > > > > > > > -- > > > > Raul > > > > > -- > > > > For information about J forums see > http://www.jsoftware.com/forums.htm > > > > > > > --
Re: [Jchat] Interesting talk "How did we end up Here?"
My point was perhaps the opposite of how you appear to be taking it. To re-state it: a large team for an array-programming project might be "more than one". On Sun, Sep 27, 2015 at 2:59 PM, Don Guinn wrote: > Why would array programming require a large team? The problem with large > teams is coordination of many people. I would think that if anything array > programming groups would be smaller. > On Sep 27, 2015 11:41 AM, "Devon McCormick" wrote: > > > At a Kdb talk I attended recently, Fintan Quill mentioned that K does > > multi-processing but not multi-threading. He didn't go into details on > > this but, based on what they say in this talk and what I've heard > > elsewhere, the reason seems obvious: multi-threading is nearly impossible > > to get to work properly. > > > > As they say in this talk about how "Shared Mutable State" in > multi-threaded > > programming should be some of the most feared words in computing, Martin > > Thompson elaborates "It's a complete nightmare even with really, really > > good people." He then goes on to add "I haven't come across any > > multi-threaded application where people are mutating the same space, that > > isn't bug-ridden." > > > > So, in short, don't do this. Don't even try to do this: fine-grained, > > multi-threaded parallelism is probably a waste of time with the current > > level of tools we have for it. > > > > Multi-processing, on the other hand, is dead-easy to do in J for anything > > that can be parallelized at a coarse-grained level, which is many if not > > most things. I've written about this extensively over the past few years > > (all at jcode.jsoftware.com/wiki/): > > User:Devon_McCormick/ParallelizedJCodeExamples, > > Community/Conference2012/Talks/ParallelSimulationInJ, > > NYCJUG/2011-04-12/RedOrBlackGameSimulation > > . These latter two give detailed examples on how to achieve > > multi-processor parallelization. > > > > On another note, there's been some mention of processes like Agile for > > speeding up the development process. Keep in mind that the context for > > these kinds of "methodologies" is an idea that a small team might be five > > people. In the array-programming world, this would be a large team. > > > > > > On Sat, Sep 26, 2015 at 7:19 PM, Don Guinn wrote: > > > > > Given a fork (f g h) f and h can be processed in parallel. But if f > and h > > > have side effects (shared global names that are modified) then they > > should > > > not run in parallel. A programming practice that should be avoided > > > anyway. This is not a pipeline, but multiple processors could be used. > > But > > > even not running them in parallel I see nothing stating which, f or h, > is > > > run first. So one should avoid code that depended on the order of f > and h > > > execution anyway. > > > > > > On Sat, Sep 26, 2015 at 4:42 PM, Raul Miller > > > wrote: > > > > > > > On Sat, Sep 26, 2015 at 3:04 PM, Vijay Lulla > > > wrote: > > > > > quite easy. But what I'm very unclear about is how does one do > > > > > pipelining in J? Say we have functions f, g, and h (all used > > > > > monadically) and it is applied like f@g@h y and function g was > > > > > particularly costly how can we parallelize (maybe the user has to > > > > > program it himself or the interpreter can do some cost analysis > [like > > > > > query planning in SQL databases]) it to make it faster? Isn't this > > > > > what the presenters were mentioning when they were using the > example > > > > > of airbus pipeline system? > > > > > > > > "Pipelining" seems to describe a variety of topics. > > > > > > > > https://en.wikipedia.org/wiki/Pipeline_(computing) > > > > > > > > So, I would have to say that there is no general technique. If f, g > > > > and h are black boxes, you cannot pipeline them. If you want to > > > > reschedule g or make it more efficient, you'll need to know details > > > > about g. The more you know, the greater the odds are that you can do > > > > it (or the important parts of it) differently, in a more efficient > > > > manner. > > > > > > > > That said, I should also point out that a lot of the automated query > > > > planning systems are workarounds for bogus constraints underlying the > > > > sql standard. That effort could have gone in much more useful > > > > directions if people hadn't bought into those ideas. (But at this > > > > point, it has turned into a multi-billion dollar industry, so it's > not > > > > going away. And there are some applications where the flaws are not > > > > all that important.) > > > > > > > > Thanks, > > > > > > > > -- > > > > Raul > > > > > -- > > > > For information about J forums see > http://www.jsoftware.com/forums.htm > > > > > > > -- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > > > > > > -- > > Devon McCormick, CFA > > --
Re: [Jchat] Interesting talk "How did we end up Here?"
Why would array programming require a large team? The problem with large teams is coordination of many people. I would think that if anything array programming groups would be smaller. On Sep 27, 2015 11:41 AM, "Devon McCormick" wrote: > At a Kdb talk I attended recently, Fintan Quill mentioned that K does > multi-processing but not multi-threading. He didn't go into details on > this but, based on what they say in this talk and what I've heard > elsewhere, the reason seems obvious: multi-threading is nearly impossible > to get to work properly. > > As they say in this talk about how "Shared Mutable State" in multi-threaded > programming should be some of the most feared words in computing, Martin > Thompson elaborates "It's a complete nightmare even with really, really > good people." He then goes on to add "I haven't come across any > multi-threaded application where people are mutating the same space, that > isn't bug-ridden." > > So, in short, don't do this. Don't even try to do this: fine-grained, > multi-threaded parallelism is probably a waste of time with the current > level of tools we have for it. > > Multi-processing, on the other hand, is dead-easy to do in J for anything > that can be parallelized at a coarse-grained level, which is many if not > most things. I've written about this extensively over the past few years > (all at jcode.jsoftware.com/wiki/): > User:Devon_McCormick/ParallelizedJCodeExamples, > Community/Conference2012/Talks/ParallelSimulationInJ, > NYCJUG/2011-04-12/RedOrBlackGameSimulation > . These latter two give detailed examples on how to achieve > multi-processor parallelization. > > On another note, there's been some mention of processes like Agile for > speeding up the development process. Keep in mind that the context for > these kinds of "methodologies" is an idea that a small team might be five > people. In the array-programming world, this would be a large team. > > > On Sat, Sep 26, 2015 at 7:19 PM, Don Guinn wrote: > > > Given a fork (f g h) f and h can be processed in parallel. But if f and h > > have side effects (shared global names that are modified) then they > should > > not run in parallel. A programming practice that should be avoided > > anyway. This is not a pipeline, but multiple processors could be used. > But > > even not running them in parallel I see nothing stating which, f or h, is > > run first. So one should avoid code that depended on the order of f and h > > execution anyway. > > > > On Sat, Sep 26, 2015 at 4:42 PM, Raul Miller > > wrote: > > > > > On Sat, Sep 26, 2015 at 3:04 PM, Vijay Lulla > > wrote: > > > > quite easy. But what I'm very unclear about is how does one do > > > > pipelining in J? Say we have functions f, g, and h (all used > > > > monadically) and it is applied like f@g@h y and function g was > > > > particularly costly how can we parallelize (maybe the user has to > > > > program it himself or the interpreter can do some cost analysis [like > > > > query planning in SQL databases]) it to make it faster? Isn't this > > > > what the presenters were mentioning when they were using the example > > > > of airbus pipeline system? > > > > > > "Pipelining" seems to describe a variety of topics. > > > > > > https://en.wikipedia.org/wiki/Pipeline_(computing) > > > > > > So, I would have to say that there is no general technique. If f, g > > > and h are black boxes, you cannot pipeline them. If you want to > > > reschedule g or make it more efficient, you'll need to know details > > > about g. The more you know, the greater the odds are that you can do > > > it (or the important parts of it) differently, in a more efficient > > > manner. > > > > > > That said, I should also point out that a lot of the automated query > > > planning systems are workarounds for bogus constraints underlying the > > > sql standard. That effort could have gone in much more useful > > > directions if people hadn't bought into those ideas. (But at this > > > point, it has turned into a multi-billion dollar industry, so it's not > > > going away. And there are some applications where the flaws are not > > > all that important.) > > > > > > Thanks, > > > > > > -- > > > Raul > > > -- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > -- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > -- > Devon McCormick, CFA > -- > For information about J forums see http://www.jsoftware.com/forums.htm > -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jchat] Interesting talk "How did we end up Here?"
At a Kdb talk I attended recently, Fintan Quill mentioned that K does multi-processing but not multi-threading. He didn't go into details on this but, based on what they say in this talk and what I've heard elsewhere, the reason seems obvious: multi-threading is nearly impossible to get to work properly. As they say in this talk about how "Shared Mutable State" in multi-threaded programming should be some of the most feared words in computing, Martin Thompson elaborates "It's a complete nightmare even with really, really good people." He then goes on to add "I haven't come across any multi-threaded application where people are mutating the same space, that isn't bug-ridden." So, in short, don't do this. Don't even try to do this: fine-grained, multi-threaded parallelism is probably a waste of time with the current level of tools we have for it. Multi-processing, on the other hand, is dead-easy to do in J for anything that can be parallelized at a coarse-grained level, which is many if not most things. I've written about this extensively over the past few years (all at jcode.jsoftware.com/wiki/): User:Devon_McCormick/ParallelizedJCodeExamples, Community/Conference2012/Talks/ParallelSimulationInJ, NYCJUG/2011-04-12/RedOrBlackGameSimulation . These latter two give detailed examples on how to achieve multi-processor parallelization. On another note, there's been some mention of processes like Agile for speeding up the development process. Keep in mind that the context for these kinds of "methodologies" is an idea that a small team might be five people. In the array-programming world, this would be a large team. On Sat, Sep 26, 2015 at 7:19 PM, Don Guinn wrote: > Given a fork (f g h) f and h can be processed in parallel. But if f and h > have side effects (shared global names that are modified) then they should > not run in parallel. A programming practice that should be avoided > anyway. This is not a pipeline, but multiple processors could be used. But > even not running them in parallel I see nothing stating which, f or h, is > run first. So one should avoid code that depended on the order of f and h > execution anyway. > > On Sat, Sep 26, 2015 at 4:42 PM, Raul Miller > wrote: > > > On Sat, Sep 26, 2015 at 3:04 PM, Vijay Lulla > wrote: > > > quite easy. But what I'm very unclear about is how does one do > > > pipelining in J? Say we have functions f, g, and h (all used > > > monadically) and it is applied like f@g@h y and function g was > > > particularly costly how can we parallelize (maybe the user has to > > > program it himself or the interpreter can do some cost analysis [like > > > query planning in SQL databases]) it to make it faster? Isn't this > > > what the presenters were mentioning when they were using the example > > > of airbus pipeline system? > > > > "Pipelining" seems to describe a variety of topics. > > > > https://en.wikipedia.org/wiki/Pipeline_(computing) > > > > So, I would have to say that there is no general technique. If f, g > > and h are black boxes, you cannot pipeline them. If you want to > > reschedule g or make it more efficient, you'll need to know details > > about g. The more you know, the greater the odds are that you can do > > it (or the important parts of it) differently, in a more efficient > > manner. > > > > That said, I should also point out that a lot of the automated query > > planning systems are workarounds for bogus constraints underlying the > > sql standard. That effort could have gone in much more useful > > directions if people hadn't bought into those ideas. (But at this > > point, it has turned into a multi-billion dollar industry, so it's not > > going away. And there are some applications where the flaws are not > > all that important.) > > > > Thanks, > > > > -- > > Raul > > -- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > -- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jchat] Interesting talk "How did we end up Here?"
Given a fork (f g h) f and h can be processed in parallel. But if f and h have side effects (shared global names that are modified) then they should not run in parallel. A programming practice that should be avoided anyway. This is not a pipeline, but multiple processors could be used. But even not running them in parallel I see nothing stating which, f or h, is run first. So one should avoid code that depended on the order of f and h execution anyway. On Sat, Sep 26, 2015 at 4:42 PM, Raul Miller wrote: > On Sat, Sep 26, 2015 at 3:04 PM, Vijay Lulla wrote: > > quite easy. But what I'm very unclear about is how does one do > > pipelining in J? Say we have functions f, g, and h (all used > > monadically) and it is applied like f@g@h y and function g was > > particularly costly how can we parallelize (maybe the user has to > > program it himself or the interpreter can do some cost analysis [like > > query planning in SQL databases]) it to make it faster? Isn't this > > what the presenters were mentioning when they were using the example > > of airbus pipeline system? > > "Pipelining" seems to describe a variety of topics. > > https://en.wikipedia.org/wiki/Pipeline_(computing) > > So, I would have to say that there is no general technique. If f, g > and h are black boxes, you cannot pipeline them. If you want to > reschedule g or make it more efficient, you'll need to know details > about g. The more you know, the greater the odds are that you can do > it (or the important parts of it) differently, in a more efficient > manner. > > That said, I should also point out that a lot of the automated query > planning systems are workarounds for bogus constraints underlying the > sql standard. That effort could have gone in much more useful > directions if people hadn't bought into those ideas. (But at this > point, it has turned into a multi-billion dollar industry, so it's not > going away. And there are some applications where the flaws are not > all that important.) > > Thanks, > > -- > Raul > -- > For information about J forums see http://www.jsoftware.com/forums.htm > -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jchat] Interesting talk "How did we end up Here?"
On Sat, Sep 26, 2015 at 3:04 PM, Vijay Lulla wrote: > quite easy. But what I'm very unclear about is how does one do > pipelining in J? Say we have functions f, g, and h (all used > monadically) and it is applied like f@g@h y and function g was > particularly costly how can we parallelize (maybe the user has to > program it himself or the interpreter can do some cost analysis [like > query planning in SQL databases]) it to make it faster? Isn't this > what the presenters were mentioning when they were using the example > of airbus pipeline system? "Pipelining" seems to describe a variety of topics. https://en.wikipedia.org/wiki/Pipeline_(computing) So, I would have to say that there is no general technique. If f, g and h are black boxes, you cannot pipeline them. If you want to reschedule g or make it more efficient, you'll need to know details about g. The more you know, the greater the odds are that you can do it (or the important parts of it) differently, in a more efficient manner. That said, I should also point out that a lot of the automated query planning systems are workarounds for bogus constraints underlying the sql standard. That effort could have gone in much more useful directions if people hadn't bought into those ideas. (But at this point, it has turned into a multi-billion dollar industry, so it's not going away. And there are some applications where the flaws are not all that important.) Thanks, -- Raul -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jchat] Interesting talk "How did we end up Here?"
I agree with you Don. In my opinion J's "always right to left evaluation" and monadic/dyadic verbs with hook/train forming rules are very flexible which make data transformations and function composition quite easy. But what I'm very unclear about is how does one do pipelining in J? Say we have functions f, g, and h (all used monadically) and it is applied like f@g@h y and function g was particularly costly how can we parallelize (maybe the user has to program it himself or the interpreter can do some cost analysis [like query planning in SQL databases]) it to make it faster? Isn't this what the presenters were mentioning when they were using the example of airbus pipeline system? Regardless, thanks for taking the time to share your thoughts. On Sat, Sep 26, 2015 at 2:30 PM, Don Guinn wrote: > One major problem with programming today is that it is too easy to develop > and publish something. We don't take time to really understand what we want > and need. In my first job the computer was behind a locked wall which I > couldn't see behind. I got one test run a day, sometimes two if I was > really fast with keypunch and lucky. So, what did I do while waiting for > the results of my next test run? I studied what I had written looking for > better ways to do it. I got really good at simulating the computer with > pencil and paper. Now testing is so fast and easy one never has to > thoroughly understand the problem. Raul's comment about rewriting once one > understands the problem is most important. But companies don't allow people > to do that. > > > I found their comments about parallel processing most interesting and a > little confusing. They claimed that parallel processing is extremely > difficult. Then they talk about the advantages of asynchronous processing. > Kind of similar, different in geography. I think that parallel processing > is easy, particularly with tools like J has. One trap with parallel > processing is that if one is to do parallel processing is that one has to > run processes in parallel. Instead, identify processes that can run in > parallel, but not to force them to run in parallel. > > > J's constructs for arrays and rank, along with Under, Atop and adverbs like > Insert etc. identify things that can be done in parallel, but don't force > them to be done in parallel. If I write a verb to handle one item and I > pass it many items via rank specification and the underlying hardware can > split the items over many processors, great. If not run them serially. The > important thing is to identify and tell the interpreter, compiler or > whatever if a thing can be done in parallel if it is capable of doing so. > > > That is one reason I prefer to use Atop (@) instead of At (@:) as it tells > the J interpreter that verbs can be pipelined given verb ranks if it > chooses to. OK, in today's implementation of J @. is faster, but maybe that > will change in the future. Vijay, is this what you are looking for? > >> >> > -- > For information about J forums see http://www.jsoftware.com/forums.htm -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jchat] Interesting talk "How did we end up Here?"
One major problem with programming today is that it is too easy to develop and publish something. We don't take time to really understand what we want and need. In my first job the computer was behind a locked wall which I couldn't see behind. I got one test run a day, sometimes two if I was really fast with keypunch and lucky. So, what did I do while waiting for the results of my next test run? I studied what I had written looking for better ways to do it. I got really good at simulating the computer with pencil and paper. Now testing is so fast and easy one never has to thoroughly understand the problem. Raul's comment about rewriting once one understands the problem is most important. But companies don't allow people to do that. I found their comments about parallel processing most interesting and a little confusing. They claimed that parallel processing is extremely difficult. Then they talk about the advantages of asynchronous processing. Kind of similar, different in geography. I think that parallel processing is easy, particularly with tools like J has. One trap with parallel processing is that if one is to do parallel processing is that one has to run processes in parallel. Instead, identify processes that can run in parallel, but not to force them to run in parallel. J's constructs for arrays and rank, along with Under, Atop and adverbs like Insert etc. identify things that can be done in parallel, but don't force them to be done in parallel. If I write a verb to handle one item and I pass it many items via rank specification and the underlying hardware can split the items over many processors, great. If not run them serially. The important thing is to identify and tell the interpreter, compiler or whatever if a thing can be done in parallel if it is capable of doing so. That is one reason I prefer to use Atop (@) instead of At (@:) as it tells the J interpreter that verbs can be pipelined given verb ranks if it chooses to. OK, in today's implementation of J @. is faster, but maybe that will change in the future. Vijay, is this what you are looking for? > > -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jchat] Interesting talk "How did we end up Here?"
J (array programming?) makes transformations super easy. But what does pipelining look like in J? Just use ] and [ ? On Sat, Sep 26, 2015 at 11:19 AM, Björn Helgason wrote: > I like using oop in J. > It is good to be able to inspect objects etc live. > Gives much better visual feeling what oop is all about. > Most utilities are hidden away in locales. > Before locales the naming caos made big projects with lots of names > difficult. > On 26 Sep 2015 14:12, "chris burke" wrote: > >> > ...OOP itself, seems to be used little >> >> I prefer to say that OOP can be used where appropriate. Some packages like >> Jd make heavy use of OOP. >> >> What J doesn't do is force you to use OOP where it is unnecessary. >> >> >> On 25 September 2015 at 21:41, Jon Hough wrote: >> >> > Well, one point they make is the awfulness of shared mutable state >> between >> > threads. I suppose J solved that by being single threaded. >> > Others... >> > >> > Bad architectural designs and abstractions... well, I don't know what >> > kind of abstractions are generally used in J. OOP patterns seem to be >> used >> > little (OOP itself, seems to be used little). J seems to abstract >> > everything in another direction, by abstracting algorithms and then >> letting >> > them be composed in different ways and on different datatypes. >> > Difficult to understand solutions (over engineering)...From what I >> see >> > (bearing in mind I only use J as a hobby), there is little overall >> > structure to J programs, in a Design Pattern sense. That is actually one >> > reason I like using J, I can just get straight to the solution, with no >> > ceremony, cruft, taking care of incidental issues... but then again, it >> is >> > difficult to argue that a super long tacit verb is easy to understand or >> > extend or modify. >> > Bad use of agile and buzzword methodologies...I don't know if >> > "enterprise J" users even use these kinds of methodologies. I can't see >> it >> > being too different from other languages in this regard though. A standup >> > meeting is a standup meeting after all. Incremental changes and feedback >> > cycles don't change much with language, I suppose. >> > >> > >> > > Date: Sat, 26 Sep 2015 00:08:44 -0400 >> > > From: devon...@gmail.com >> > > To: c...@jsoftware.com >> > > Subject: Re: [Jchat] Interesting talk "How did we end up Here?" >> > > >> > > I'm only 17 minutes into it but they seem to be asking a lot of >> questions >> > > and posing problems to which the array-language community has answers. >> > > >> > > On Fri, Sep 25, 2015 at 11:39 PM, Jon Hough >> wrote: >> > > >> > > > I thought this youtube talk from the Goto conference might interest >> > some >> > > > people here >> > > > >> > > > https://www.youtube.com/watch?v=oxjT7veKi9c >> > > > >> > > > >> > > > Essentially, the two speakers are musing on why everything in >> software >> > > > development is so terrible, convoluted, messy etc. >> > > > >> > > > It's quite long, but might be of interest to some people. >> > > > >> > > > I enjoyed the quip "The internet is basically in debug mode" as we >> are >> > all >> > > > passing around text data (JSON or XML etc), since I've been looking >> > into >> > > > protobufs (not with J!) binary serialization of data. >> > > > >> -- >> > > > For information about J forums see >> http://www.jsoftware.com/forums.htm >> > > > >> > > >> > > >> > > >> > > -- >> > > Devon McCormick, CFA >> > > -- >> > > 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
Re: [Jchat] Interesting talk "How did we end up Here?"
I like using oop in J. It is good to be able to inspect objects etc live. Gives much better visual feeling what oop is all about. Most utilities are hidden away in locales. Before locales the naming caos made big projects with lots of names difficult. On 26 Sep 2015 14:12, "chris burke" wrote: > > ...OOP itself, seems to be used little > > I prefer to say that OOP can be used where appropriate. Some packages like > Jd make heavy use of OOP. > > What J doesn't do is force you to use OOP where it is unnecessary. > > > On 25 September 2015 at 21:41, Jon Hough wrote: > > > Well, one point they make is the awfulness of shared mutable state > between > > threads. I suppose J solved that by being single threaded. > > Others... > > > > Bad architectural designs and abstractions... well, I don't know what > > kind of abstractions are generally used in J. OOP patterns seem to be > used > > little (OOP itself, seems to be used little). J seems to abstract > > everything in another direction, by abstracting algorithms and then > letting > > them be composed in different ways and on different datatypes. > > Difficult to understand solutions (over engineering)...From what I > see > > (bearing in mind I only use J as a hobby), there is little overall > > structure to J programs, in a Design Pattern sense. That is actually one > > reason I like using J, I can just get straight to the solution, with no > > ceremony, cruft, taking care of incidental issues... but then again, it > is > > difficult to argue that a super long tacit verb is easy to understand or > > extend or modify. > > Bad use of agile and buzzword methodologies...I don't know if > > "enterprise J" users even use these kinds of methodologies. I can't see > it > > being too different from other languages in this regard though. A standup > > meeting is a standup meeting after all. Incremental changes and feedback > > cycles don't change much with language, I suppose. > > > > > > > Date: Sat, 26 Sep 2015 00:08:44 -0400 > > > From: devon...@gmail.com > > > To: c...@jsoftware.com > > > Subject: Re: [Jchat] Interesting talk "How did we end up Here?" > > > > > > I'm only 17 minutes into it but they seem to be asking a lot of > questions > > > and posing problems to which the array-language community has answers. > > > > > > On Fri, Sep 25, 2015 at 11:39 PM, Jon Hough > wrote: > > > > > > > I thought this youtube talk from the Goto conference might interest > > some > > > > people here > > > > > > > > https://www.youtube.com/watch?v=oxjT7veKi9c > > > > > > > > > > > > Essentially, the two speakers are musing on why everything in > software > > > > development is so terrible, convoluted, messy etc. > > > > > > > > It's quite long, but might be of interest to some people. > > > > > > > > I enjoyed the quip "The internet is basically in debug mode" as we > are > > all > > > > passing around text data (JSON or XML etc), since I've been looking > > into > > > > protobufs (not with J!) binary serialization of data. > > > > > -- > > > > For information about J forums see > http://www.jsoftware.com/forums.htm > > > > > > > > > > > > > > > > -- > > > Devon McCormick, CFA > > > -- > > > 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
Re: [Jchat] Interesting talk "How did we end up Here?"
> ...OOP itself, seems to be used little I prefer to say that OOP can be used where appropriate. Some packages like Jd make heavy use of OOP. What J doesn't do is force you to use OOP where it is unnecessary. On 25 September 2015 at 21:41, Jon Hough wrote: > Well, one point they make is the awfulness of shared mutable state between > threads. I suppose J solved that by being single threaded. > Others... > > Bad architectural designs and abstractions... well, I don't know what > kind of abstractions are generally used in J. OOP patterns seem to be used > little (OOP itself, seems to be used little). J seems to abstract > everything in another direction, by abstracting algorithms and then letting > them be composed in different ways and on different datatypes. > Difficult to understand solutions (over engineering)...From what I see > (bearing in mind I only use J as a hobby), there is little overall > structure to J programs, in a Design Pattern sense. That is actually one > reason I like using J, I can just get straight to the solution, with no > ceremony, cruft, taking care of incidental issues... but then again, it is > difficult to argue that a super long tacit verb is easy to understand or > extend or modify. > Bad use of agile and buzzword methodologies...I don't know if > "enterprise J" users even use these kinds of methodologies. I can't see it > being too different from other languages in this regard though. A standup > meeting is a standup meeting after all. Incremental changes and feedback > cycles don't change much with language, I suppose. > > > > Date: Sat, 26 Sep 2015 00:08:44 -0400 > > From: devon...@gmail.com > > To: c...@jsoftware.com > > Subject: Re: [Jchat] Interesting talk "How did we end up Here?" > > > > I'm only 17 minutes into it but they seem to be asking a lot of questions > > and posing problems to which the array-language community has answers. > > > > On Fri, Sep 25, 2015 at 11:39 PM, Jon Hough wrote: > > > > > I thought this youtube talk from the Goto conference might interest > some > > > people here > > > > > > https://www.youtube.com/watch?v=oxjT7veKi9c > > > > > > > > > Essentially, the two speakers are musing on why everything in software > > > development is so terrible, convoluted, messy etc. > > > > > > It's quite long, but might be of interest to some people. > > > > > > I enjoyed the quip "The internet is basically in debug mode" as we are > all > > > passing around text data (JSON or XML etc), since I've been looking > into > > > protobufs (not with J!) binary serialization of data. > > > -- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > > > > > > -- > > Devon McCormick, CFA > > -- > > 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
Re: [Jchat] Interesting talk "How did we end up Here?"
As a general rule, when I program in J (or really in any language), I tend to program in terms of what I want to happen to the data. I expect the data transforms to be understandable, and I expect that any good programmer could rewrite the code once they understood the data and how it gets changed. In general, I'm a fan of that style of programming. Thanks, -- Raul On Sat, Sep 26, 2015 at 12:41 AM, Jon Hough wrote: > Well, one point they make is the awfulness of shared mutable state between > threads. I suppose J solved that by being single threaded. > Others... > > Bad architectural designs and abstractions... well, I don't know what kind > of abstractions are generally used in J. OOP patterns seem to be used little > (OOP itself, seems to be used little). J seems to abstract everything in > another direction, by abstracting algorithms and then letting them be > composed in different ways and on different datatypes. > Difficult to understand solutions (over engineering)...From what I see > (bearing in mind I only use J as a hobby), there is little overall structure > to J programs, in a Design Pattern sense. That is actually one reason I like > using J, I can just get straight to the solution, with no ceremony, cruft, > taking care of incidental issues... but then again, it is difficult to argue > that a super long tacit verb is easy to understand or extend or modify. > Bad use of agile and buzzword methodologies...I don't know if "enterprise > J" users even use these kinds of methodologies. I can't see it being too > different from other languages in this regard though. A standup meeting is a > standup meeting after all. Incremental changes and feedback cycles don't > change much with language, I suppose. > > >> Date: Sat, 26 Sep 2015 00:08:44 -0400 >> From: devon...@gmail.com >> To: c...@jsoftware.com >> Subject: Re: [Jchat] Interesting talk "How did we end up Here?" >> >> I'm only 17 minutes into it but they seem to be asking a lot of questions >> and posing problems to which the array-language community has answers. >> >> On Fri, Sep 25, 2015 at 11:39 PM, Jon Hough wrote: >> >> > I thought this youtube talk from the Goto conference might interest some >> > people here >> > >> > https://www.youtube.com/watch?v=oxjT7veKi9c >> > >> > >> > Essentially, the two speakers are musing on why everything in software >> > development is so terrible, convoluted, messy etc. >> > >> > It's quite long, but might be of interest to some people. >> > >> > I enjoyed the quip "The internet is basically in debug mode" as we are all >> > passing around text data (JSON or XML etc), since I've been looking into >> > protobufs (not with J!) binary serialization of data. >> > -- >> > For information about J forums see http://www.jsoftware.com/forums.htm >> > >> >> >> >> -- >> Devon McCormick, CFA >> -- >> 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
Re: [Jchat] Interesting talk "How did we end up Here?"
Well, one point they make is the awfulness of shared mutable state between threads. I suppose J solved that by being single threaded. Others... Bad architectural designs and abstractions... well, I don't know what kind of abstractions are generally used in J. OOP patterns seem to be used little (OOP itself, seems to be used little). J seems to abstract everything in another direction, by abstracting algorithms and then letting them be composed in different ways and on different datatypes. Difficult to understand solutions (over engineering)...From what I see (bearing in mind I only use J as a hobby), there is little overall structure to J programs, in a Design Pattern sense. That is actually one reason I like using J, I can just get straight to the solution, with no ceremony, cruft, taking care of incidental issues... but then again, it is difficult to argue that a super long tacit verb is easy to understand or extend or modify. Bad use of agile and buzzword methodologies...I don't know if "enterprise J" users even use these kinds of methodologies. I can't see it being too different from other languages in this regard though. A standup meeting is a standup meeting after all. Incremental changes and feedback cycles don't change much with language, I suppose. > Date: Sat, 26 Sep 2015 00:08:44 -0400 > From: devon...@gmail.com > To: c...@jsoftware.com > Subject: Re: [Jchat] Interesting talk "How did we end up Here?" > > I'm only 17 minutes into it but they seem to be asking a lot of questions > and posing problems to which the array-language community has answers. > > On Fri, Sep 25, 2015 at 11:39 PM, Jon Hough wrote: > > > I thought this youtube talk from the Goto conference might interest some > > people here > > > > https://www.youtube.com/watch?v=oxjT7veKi9c > > > > > > Essentially, the two speakers are musing on why everything in software > > development is so terrible, convoluted, messy etc. > > > > It's quite long, but might be of interest to some people. > > > > I enjoyed the quip "The internet is basically in debug mode" as we are all > > passing around text data (JSON or XML etc), since I've been looking into > > protobufs (not with J!) binary serialization of data. > > -- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > -- > Devon McCormick, CFA > -- > For information about J forums see http://www.jsoftware.com/forums.htm -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jchat] Interesting talk "How did we end up Here?"
I'm only 17 minutes into it but they seem to be asking a lot of questions and posing problems to which the array-language community has answers. On Fri, Sep 25, 2015 at 11:39 PM, Jon Hough wrote: > I thought this youtube talk from the Goto conference might interest some > people here > > https://www.youtube.com/watch?v=oxjT7veKi9c > > > Essentially, the two speakers are musing on why everything in software > development is so terrible, convoluted, messy etc. > > It's quite long, but might be of interest to some people. > > I enjoyed the quip "The internet is basically in debug mode" as we are all > passing around text data (JSON or XML etc), since I've been looking into > protobufs (not with J!) binary serialization of data. > -- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA -- For information about J forums see http://www.jsoftware.com/forums.htm
[Jchat] Interesting talk "How did we end up Here?"
I thought this youtube talk from the Goto conference might interest some people here https://www.youtube.com/watch?v=oxjT7veKi9c Essentially, the two speakers are musing on why everything in software development is so terrible, convoluted, messy etc. It's quite long, but might be of interest to some people. I enjoyed the quip "The internet is basically in debug mode" as we are all passing around text data (JSON or XML etc), since I've been looking into protobufs (not with J!) binary serialization of data. -- For information about J forums see http://www.jsoftware.com/forums.htm
