Re: [Jchat] the language of the future for the programming of the past

[Björn Helgason]

In general it is a good practice to let a filter sort the post to different
boxes

On 10 Jan 2018 21:24, "Antony McCardell"  wrote:

> Hi Chris
>
> I need urgently to unsubscribe to J chat. Currently I am unable to
> participate and my mailbox is becoming overloaded with J chat messages. I
> cannot see an "unsubscribe" button anyway. Can you please point me in the
> right direction?
>
> Thanks
>
> Tony
>
>
> On 11/01/2018 12:21 AM, chris burke wrote:
>
>> After the fom editor was dropped we have been struggling.
>>>
>> The old form editor was needed because in the old days, there was no
>> layout
>> manager in the UI so controls had to be given an exact position on a form.
>> Fine-tuning this manually would have been tedious. However, there were
>> still problems, for example the layout that worked fine on one resolution
>> or OS may not have worked on another. I remember spending a great deal of
>> time on manually fixing up form editor output so forms worked properly
>> everywhere.
>>
>> However, Qt has a nice layout manager. Control positioning is easy and
>> just
>> works in all platforms.
>>
>>
>> On Tue, Jan 9, 2018 at 11:29 PM, Ric Sherlock  wrote:
>>
>> I can understand the appeal of the WYSIWYG aspect of the old form editor,
>>> but I much prefer the current system for designing and building forms. I
>>> spend much less time aligning controls perfectly and the form resizing
>>> behaviour is much better.
>>>
>>> As for the cross-platform experience, there is no contest - the current
>>> WD
>>> implementation is far superior in terms of functionality, reliability and
>>> appearance.
>>>
>>> I'm sure that the state of flux of GUI development from J6.02 to J8
>>> didn't
>>> help foster a plethora of GUI apps, but I think the paucity of GUI apps
>>> is
>>> primarily due to the focus of the majority of users than the facilities
>>> of
>>> the language.
>>>
>>> The GUI's I've developed are far from complex, but I've found them
>>> relatively easy and satisfying to build, and compare favourably with
>>> those
>>> of most other languages for GUI-based tasks on Rosetta code.
>>>
>>> On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason 
>>> wrote:
>>>
>>> J used to be great at making guis and had the best form editor on the
 market.
 After the fom editor was dropped we have been struggling.
 I would love to have easier ways to create guis.

 On 9 Jan 2018 18:57, "Dabrowski, Andrew John" 
 wrote:

 So it seems that J is not a self-contained language for making GUIs: you
 also need to know either html and js or qt.  Clojure has the significant
 advantage that the GUI code is in idiomatic Clojure.

 All I said was that J isn't a _good_ language for creating GUIs when
 compared with Clojure, Python, or Java for example.  I would have
 thought
 that would be uncontroversial: in fact there are very few examples of

>>> GUIs
>>>
 in the repo, and none are elaborate.  Evidently no one in the J
 community
 places a very high value on GUIs.

 Which is fine, not every language needs to be great at facilitating the
 construction of GUIs, there's a place for scripting languages.  I'm
 happy
 to grant J the distinction of being a superb calculation and scripting
 language, but for GUIs it happens to be mediocre.

 On 01/09/2018 03:02 AM, Björn Helgason wrote:

 JHS is using HTML as a front end.
 There are numerous ways of interacting with HTML tools.
 You can see examples and demos doing gui/graphics etc and mixing with
 javascripts.
 It may be difficult to distinguish between what is J/Javascript.

 On 8 Jan 2018 22:13, "Dabrowski, Andrew John" >>>
> 
 dabro...@indiana.edu> wrote:



 After reading "Algebra as Language" and "Computers and Mathematical
 Notation", I'm starting to see J the perfect language for numerical
 computation.  But for general purpose programming I can see Dijkstra's
 point.

 When APL was designed computers were seen largely as calculating
 machines.  But by the 1970s GUIs were starting to be developed, and
 computers were being applied in areas where tensors were no longer

>>> adequate
>>>
 as the sole data structure.  One thing general purpose programming
 languages must have is extensibility, and that J lacks.

 I'm trying to work out what the appropriate use cases are for J, and I
 think it's calculating with tensors.  If you need more than tensors, or

>>> if
>>>
 you need more than calculation (e.g. GUIs), J is not a good choice.
 --
 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] the language of the future for the programming of the past

[Antony McCardell]

Chris

I accept your offer to unsubscribe me. That would be most appreciated.

Tony


On 11/01/2018 9:42 AM, chris burke wrote:

Tony

To unsubscribe or change your forum options, see
http://code.jsoftware.com/wiki/System/Forums#Options.2FUnsubscribe .

If you like, I can unsubscribe you. However, you might also consider
getting forum messages as a digest.

Chris


On Wed, Jan 10, 2018 at 1:24 PM, Antony McCardell 
wrote:


Hi Chris

I need urgently to unsubscribe to J chat. Currently I am unable to
participate and my mailbox is becoming overloaded with J chat messages. I
cannot see an "unsubscribe" button anyway. Can you please point me in the
right direction?

Thanks

Tony



On 11/01/2018 12:21 AM, chris burke wrote:


After the fom editor was dropped we have been struggling.
The old form editor was needed because in the old days, there was no
layout
manager in the UI so controls had to be given an exact position on a form.
Fine-tuning this manually would have been tedious. However, there were
still problems, for example the layout that worked fine on one resolution
or OS may not have worked on another. I remember spending a great deal of
time on manually fixing up form editor output so forms worked properly
everywhere.

However, Qt has a nice layout manager. Control positioning is easy and
just
works in all platforms.


On Tue, Jan 9, 2018 at 11:29 PM, Ric Sherlock  wrote:

I can understand the appeal of the WYSIWYG aspect of the old form editor,

but I much prefer the current system for designing and building forms. I
spend much less time aligning controls perfectly and the form resizing
behaviour is much better.

As for the cross-platform experience, there is no contest - the current
WD
implementation is far superior in terms of functionality, reliability and
appearance.

I'm sure that the state of flux of GUI development from J6.02 to J8
didn't
help foster a plethora of GUI apps, but I think the paucity of GUI apps
is
primarily due to the focus of the majority of users than the facilities
of
the language.

The GUI's I've developed are far from complex, but I've found them
relatively easy and satisfying to build, and compare favourably with
those
of most other languages for GUI-based tasks on Rosetta code.

On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason 
wrote:

J used to be great at making guis and had the best form editor on the

market.
After the fom editor was dropped we have been struggling.
I would love to have easier ways to create guis.

On 9 Jan 2018 18:57, "Dabrowski, Andrew John" 
wrote:

So it seems that J is not a self-contained language for making GUIs: you
also need to know either html and js or qt.  Clojure has the significant
advantage that the GUI code is in idiomatic Clojure.

All I said was that J isn't a _good_ language for creating GUIs when
compared with Clojure, Python, or Java for example.  I would have
thought
that would be uncontroversial: in fact there are very few examples of


GUIs


in the repo, and none are elaborate.  Evidently no one in the J
community
places a very high value on GUIs.

Which is fine, not every language needs to be great at facilitating the
construction of GUIs, there's a place for scripting languages.  I'm
happy
to grant J the distinction of being a superb calculation and scripting
language, but for GUIs it happens to be mediocre.

On 01/09/2018 03:02 AM, Björn Helgason wrote:

JHS is using HTML as a front end.
There are numerous ways of interacting with HTML tools.
You can see examples and demos doing gui/graphics etc and mixing with
javascripts.
It may be difficult to distinguish between what is J/Javascript.

On 8 Jan 2018 22:13, "Dabrowski, Andrew John" 

dabro...@indiana.edu> wrote:



After reading "Algebra as Language" and "Computers and Mathematical
Notation", I'm starting to see J the perfect language for numerical
computation.  But for general purpose programming I can see Dijkstra's
point.

When APL was designed computers were seen largely as calculating
machines.  But by the 1970s GUIs were starting to be developed, and
computers were being applied in areas where tensors were no longer


adequate


as the sole data structure.  One thing general purpose programming
languages must have is extensibility, and that J lacks.

I'm trying to work out what the appropriate use cases are for J, and I
think it's calculating with tensors.  If you need more than tensors, or


if


you need more than calculation (e.g. GUIs), J is not a good choice.
--
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 informa

Re: [Jchat] the language of the future for the programming of the past

[Ric Sherlock]

There are J entries for a number of the GUI
I see a couple need updating for J8 still.

http://rosettacode.org/wiki/Category:GUI

Also see:
http://rosettacode.org/wiki/Animate_a_pendulum#J

The minesweeper and 2048 tasks on RosettaCode also have GUI interfaces that
have been made available as addons: games/minesweeper and games/2048
If you have those addons installed you can view the code
eg: open '~addons/games/2048/ui_wd.ijs'

HTH



On Thu, Jan 11, 2018 at 5:55 AM, Dabrowski, Andrew John <
dabro...@indiana.edu> wrote:

> Have you put yours on RosettaCode?  If not, where can I find them?
>
> On 01/10/2018 02:29 AM, Ric Sherlock wrote:
>
> I can understand the appeal of the WYSIWYG aspect of the old form editor,
> but I much prefer the current system for designing and building forms. I
> spend much less time aligning controls perfectly and the form resizing
> behaviour is much better.
>
> As for the cross-platform experience, there is no contest - the current WD
> implementation is far superior in terms of functionality, reliability and
> appearance.
>
> I'm sure that the state of flux of GUI development from J6.02 to J8 didn't
> help foster a plethora of GUI apps, but I think the paucity of GUI apps is
> primarily due to the focus of the majority of users than the facilities of
> the language.
>
> The GUI's I've developed are far from complex, but I've found them
> relatively easy and satisfying to build, and compare favourably with those
> of most other languages for GUI-based tasks on Rosetta code.
>
> On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason  gos...@gmail.com> wrote:
>
>
>
> J used to be great at making guis and had the best form editor on the
> market.
> After the fom editor was dropped we have been struggling.
> I would love to have easier ways to create guis.
>
> On 9 Jan 2018 18:57, "Dabrowski, Andrew John"  >
> wrote:
>
> So it seems that J is not a self-contained language for making GUIs: you
> also need to know either html and js or qt.  Clojure has the significant
> advantage that the GUI code is in idiomatic Clojure.
>
> All I said was that J isn't a _good_ language for creating GUIs when
> compared with Clojure, Python, or Java for example.  I would have thought
> that would be uncontroversial: in fact there are very few examples of GUIs
> in the repo, and none are elaborate.  Evidently no one in the J community
> places a very high value on GUIs.
>
> Which is fine, not every language needs to be great at facilitating the
> construction of GUIs, there's a place for scripting languages.  I'm happy
> to grant J the distinction of being a superb calculation and scripting
> language, but for GUIs it happens to be mediocre.
>
> On 01/09/2018 03:02 AM, Björn Helgason wrote:
>
> JHS is using HTML as a front end.
> There are numerous ways of interacting with HTML tools.
> You can see examples and demos doing gui/graphics etc and mixing with
> javascripts.
> It may be difficult to distinguish between what is J/Javascript.
>
> On 8 Jan 2018 22:13, "Dabrowski, Andrew John"  
>
>
> 
>
> dabro...@indiana.edu> wrote:
>
>
>
> After reading "Algebra as Language" and "Computers and Mathematical
> Notation", I'm starting to see J the perfect language for numerical
> computation.  But for general purpose programming I can see Dijkstra's
> point.
>
> When APL was designed computers were seen largely as calculating
> machines.  But by the 1970s GUIs were starting to be developed, and
> computers were being applied in areas where tensors were no longer adequate
> as the sole data structure.  One thing general purpose programming
> languages must have is extensibility, and that J lacks.
>
> I'm trying to work out what the appropriate use cases are for J, and I
> think it's calculating with tensors.  If you need more than tensors, or if
> you need more than calculation (e.g. GUIs), J is not a good choice.
> --
> 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

Re: [Jchat] the language of the future for the programming of the past

[Raul Miller]

Hmm... the "Names Created When Any Event Is Signaled:" bits strike me
as perhaps not completely accurate, since every name in the first
column of the wd'q' result gets set by wdhandler.

So, in the example I am currently looking at (a focuslost event), this means:

syshandler
sysevent
sysdefault
sysparent
syschild
systype
syslocalec
syslocalep
syshwndp
syshwndc
syslastfocus
sysmodifiers
sysdata

I should probably dig out my wiki credentials and update that page...

Thanks,

-- 
Raul


On Thu, Jan 11, 2018 at 12:08 AM, Ric Sherlock  wrote:
> The format of sysdata depends on the class involved. Described here
> http://code.jsoftware.com/wiki/Guides/Window_Driver/ChildClasses a number
> of ChildClasses
>
>
> On Thu, Jan 11, 2018 at 5:02 PM, Dabrowski, Andrew John <
> dabro...@indiana.edu> wrote:
>
>> Got it.
>>
>> EigenPicture is cool.  Does it get the xy-coordinates of the mouse from
>> sysdata?  Where is sysdata documented?
>>
>>
>> epd_g_mmove=: 3 : 0
>>
>> 'x y w h'=. 4 {. 0 ". sysdata
>>
>> y=. h - y
>>
>> rim=. unitvec (x,y) - -: w,h
>>
>> end=. rim + MATRIX mp rim
>>
>> j=. (MX,MY) + rim * X1,Y1
>>
>> pts=. flipypos 2 4$(MX,MY), j, j, (MX,MY) + end * X1,Y1
>>
>> glsel 'g'
>>
>> glclear''
>>
>> drawframe ''
>>
>> glpen 2 1
>>
>> drawpin LASTPTS
>>
>> setcolor EIGENCOLOR
>>
>> glpen 2 1
>>
>> drawpin pts
>>
>> drawpic''
>>
>> glpaint ''
>>
>> LASTPTS=: pts
>>
>> )
>>
>>
>>
>> On 01/10/2018 02:23 PM, Raul Miller wrote:
>> > I have installed all addons, and I am going to presume you have also.
>> >
>> > When I go to the jqt Help menu, I can select Studio > Showcase... and
>> > this offers the demos:
>> >
>> > cities
>> > coins
>> > deoptim
>> > eigenpictures
>> > events
>> > isigraph
>> > isigrid
>> > life
>> > minesweeper
>> > plot
>> > solitaire
>> > unicode simple
>> >
>> > And, then, each of these demos has its own menu with further depth.
>> >
>> > Some quick searching shows that the underlying implementation for this
>> > demos node in the jqt ui is addons/demos/wd/demos.ijs
>> >
>> > If you do not see that, where does what you see differ?
>> >
>> > Thanks,
>> >
>> --
>> 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] the language of the future for the programming of the past

[Ric Sherlock]

The format of sysdata depends on the class involved. Described here
http://code.jsoftware.com/wiki/Guides/Window_Driver/ChildClasses a number
of ChildClasses


On Thu, Jan 11, 2018 at 5:02 PM, Dabrowski, Andrew John <
dabro...@indiana.edu> wrote:

> Got it.
>
> EigenPicture is cool.  Does it get the xy-coordinates of the mouse from
> sysdata?  Where is sysdata documented?
>
>
> epd_g_mmove=: 3 : 0
>
> 'x y w h'=. 4 {. 0 ". sysdata
>
> y=. h - y
>
> rim=. unitvec (x,y) - -: w,h
>
> end=. rim + MATRIX mp rim
>
> j=. (MX,MY) + rim * X1,Y1
>
> pts=. flipypos 2 4$(MX,MY), j, j, (MX,MY) + end * X1,Y1
>
> glsel 'g'
>
> glclear''
>
> drawframe ''
>
> glpen 2 1
>
> drawpin LASTPTS
>
> setcolor EIGENCOLOR
>
> glpen 2 1
>
> drawpin pts
>
> drawpic''
>
> glpaint ''
>
> LASTPTS=: pts
>
> )
>
>
>
> On 01/10/2018 02:23 PM, Raul Miller wrote:
> > I have installed all addons, and I am going to presume you have also.
> >
> > When I go to the jqt Help menu, I can select Studio > Showcase... and
> > this offers the demos:
> >
> > cities
> > coins
> > deoptim
> > eigenpictures
> > events
> > isigraph
> > isigrid
> > life
> > minesweeper
> > plot
> > solitaire
> > unicode simple
> >
> > And, then, each of these demos has its own menu with further depth.
> >
> > Some quick searching shows that the underlying implementation for this
> > demos node in the jqt ui is addons/demos/wd/demos.ijs
> >
> > If you do not see that, where does what you see differ?
> >
> > Thanks,
> >
> --
> 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] the language of the future for the programming of the past

[Raul Miller]

One place sysdata is documented at is
http://www.jsoftware.com/docs/help701/user/isigraph_events.htm another
is http://www.jsoftware.com/help/jforc/graphics.htm - I'm not sure if
there's any new j version 8 details on it, yet.

Event handling more generally is documented at
http://code.jsoftware.com/wiki/Guides/Window_Driver/Window_Driver_Overview#Event_Handlers

More specifically, wdhandler sets the value of sysdata on its third line:

3 : 0
wdq=: wd 'q'
wd_val=. {:"1 wdq
({."1 wdq)=: wd_val
...

If you override wdhandler (and don't delegate to it) I think you'll
have to take care of this yourself.

Thanks,

-- 
Raul

On Wed, Jan 10, 2018 at 11:02 PM, Dabrowski, Andrew John
 wrote:
> Got it.
>
> EigenPicture is cool.  Does it get the xy-coordinates of the mouse from
> sysdata?  Where is sysdata documented?
>
>
> epd_g_mmove=: 3 : 0
>
> 'x y w h'=. 4 {. 0 ". sysdata
>
> y=. h - y
>
> rim=. unitvec (x,y) - -: w,h
>
> end=. rim + MATRIX mp rim
>
> j=. (MX,MY) + rim * X1,Y1
>
> pts=. flipypos 2 4$(MX,MY), j, j, (MX,MY) + end * X1,Y1
>
> glsel 'g'
>
> glclear''
>
> drawframe ''
>
> glpen 2 1
>
> drawpin LASTPTS
>
> setcolor EIGENCOLOR
>
> glpen 2 1
>
> drawpin pts
>
> drawpic''
>
> glpaint ''
>
> LASTPTS=: pts
>
> )
>
>
>
> On 01/10/2018 02:23 PM, Raul Miller wrote:
>> I have installed all addons, and I am going to presume you have also.
>>
>> When I go to the jqt Help menu, I can select Studio > Showcase... and
>> this offers the demos:
>>
>> cities
>> coins
>> deoptim
>> eigenpictures
>> events
>> isigraph
>> isigrid
>> life
>> minesweeper
>> plot
>> solitaire
>> unicode simple
>>
>> And, then, each of these demos has its own menu with further depth.
>>
>> Some quick searching shows that the underlying implementation for this
>> demos node in the jqt ui is addons/demos/wd/demos.ijs
>>
>> If you do not see that, where does what you see differ?
>>
>> Thanks,
>>
> --
> 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] the language of the future for the programming of the past

[Dabrowski, Andrew John]

Got it.

EigenPicture is cool.  Does it get the xy-coordinates of the mouse from 
sysdata?  Where is sysdata documented?


epd_g_mmove=: 3 : 0

'x y w h'=. 4 {. 0 ". sysdata

y=. h - y

rim=. unitvec (x,y) - -: w,h

end=. rim + MATRIX mp rim

j=. (MX,MY) + rim * X1,Y1

pts=. flipypos 2 4$(MX,MY), j, j, (MX,MY) + end * X1,Y1

glsel 'g'

glclear''

drawframe ''

glpen 2 1

drawpin LASTPTS

setcolor EIGENCOLOR

glpen 2 1

drawpin pts

drawpic''

glpaint ''

LASTPTS=: pts

)



On 01/10/2018 02:23 PM, Raul Miller wrote:
> I have installed all addons, and I am going to presume you have also.
>
> When I go to the jqt Help menu, I can select Studio > Showcase... and
> this offers the demos:
>
> cities
> coins
> deoptim
> eigenpictures
> events
> isigraph
> isigrid
> life
> minesweeper
> plot
> solitaire
> unicode simple
>
> And, then, each of these demos has its own menu with further depth.
>
> Some quick searching shows that the underlying implementation for this
> demos node in the jqt ui is addons/demos/wd/demos.ijs
>
> If you do not see that, where does what you see differ?
>
> Thanks,
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jchat] [Jprogramming] A normal exit from a deeply embedded function to a terminal prompt, how?

[Raul Miller]

As quicksort is not tail recursive, I do not see how tail recursion
should be relevant to quicksort.

As for evolve - my memory is unclear and the only working examples I
see for it are equivalent to the identity function, so I do not know
how I could test my work for correctness. (Though I doubt you would be
happy with FB=: ] and FT=:0:)

Perhaps you could shed a bit more light on whatever it is that you are
trying to talk about?

Thanks,

-- 
Raul



On Wed, Jan 10, 2018 at 7:39 PM, Jose Mario Quintana
 wrote:
>> I do not believe that there is anything meaningful about FB@:FT
>> relevant to tail recursion.
>
> You are right, of course, FB@:FT, as stated in my petty claim, has little,
> if anything, to do with tail recursion.  Indeed, the claim does not say
> much because no restrictions on the nature of FB and FT are imposed.
> Consequently, even recursive verbs which are not in tail recursive form can
> be trivially written as FB@:FT.  Remember the quicksort troublemaker verb
> [0]?
>
>quicksort=. (($:@(< # [) , (= # [) , $:@(> # [)) ({~ ?@#))^:(1 < #)
>
> one can readily rewrite it as quicksort=. FB@:FT,
>
>quicksort=. ]@:((($:@(< # [) , (= # [) , $:@(> # [)) ({~ ?@#))^:(1 < #))
>
> However, that is precisely my point, your claim, as originally stated, is
> not very different (it does not say much either) because no restrictions on
> the nature of FB and FT were imposed.  One can define quicksort as
> FB^:FT^:_ by choosing FT as 1:.  Do you see how FB can be defined to
> fulfill your claim?  A version of FT (named tricky) for this case is shown
> later in this post to avoid a spoiler for those who might like to write
> their own versions.  Indeed,
>
>qs=. tricky^:1:^: _
>
>(qs -: quicksort) 6 5 9 8 5 2 7 5 4 0 1 2 7 4 9
> 1
>
> You wrote: "I would be interested in seeing a counter-example that destroys
> my belief, if counter examples exist."  However, how can one try to think
> about a possible counterexample if even recursive verbs, which are not in
> tail recursion form, can be written in such fashion?
>
> Perhaps entertaining another example might bring some clarity.  Remember
> the verb evolve [1] which is in tail recursive form?  Not surprisingly,
> changing what needs to be changed in tricky results in,
>
>tricky^:1:^:_ 'METHINKS IT IS LIKE A WEASEL'
> METHINKS IT IS LIKE A WEASEL
>
> Surely the definitions for FB and FT that you might have in mind for this
> case are quite different.  Are they not?  Can you tell us what those
> definitions are?
>
> References
>
> [0] [Jprogramming] Tacit Expressions with Explicit J Syntax
> http://www.jsoftware.com/pipermail/programming/2017-October/049085.html
>
> [1] [Jprogramming] Recursive tail calls (WAS: Tacit exercise)
> http://www.jsoftware.com/pipermail/programming/2009-December/017529.html
>
> The verb tricky can be defined (wickedly) as follows,
>
>o=. @:
>c=. "_
>
>rank=. (;:'"')(0:`)(,^:) NB. Verbing " (dyadic verb)
>lrw=. (_2 }. ":) o (rank&_)  NB. Linear representation (monadic
> verb)
>k=. ] [ (". o ([ , '=. ' , lrw @:])) NB. Keep (monadic verb)
>
>tricky=. R_tricky_ c :: ('R_tricky'&k) o (quicksort f.)
>
>
> On Tue, Jan 9, 2018 at 8:11 PM, Raul Miller  wrote:
>
>> I do not believe that there is anything meaningful about FB@:FT
>> relevant to tail recursion.
>>
>> A tail recursive function has the characteristic that no matter how
>> deep you nest the stack, the result returned from the final result
>> will be the result of all routines which called it.
>>
>> This matches how inductive verbs work. The difference, of course, is
>> that there is no stack (which is all that tail recursion was about in
>> the first place).
>>
>> The requirement imposed by induction is that you refactor the original
>> recursive function so that the test (for whether you enter recursion)
>> be separable in some way from the rest of the code.
>>
>> How does FB@:FT have anything to do with any of this?
>>
>> Thanks,
>>
>> --
>> Raul
>>
>>
>> On Tue, Jan 9, 2018 at 6:51 PM, Jose Mario Quintana
>>  wrote:
>> > I am not entirely sure what you are trying to convey either.  Apparently,
>> > you are implying that "F=: FB^:FT^:_" would be, in some sense, simpler
>> than
>> > the original F but that might not be necessarily the case (depending on
>> the
>> > nature of FB and FT; which you did not specify).
>> >
>> > Your claim, to me (so far), is not much different than, for example,
>> >
>> >   If I have a recursive verb (F y) implemented in J, which satisfies the
>> >   constraints for tail recursion, I believe that there is always a pair
>> >   of companion functions (FB y) (FT y) such that an F workalike can be
>> >   written:
>> >
>> > F=: FB@:FT y
>> >
>> > (So what?)
>> >
>> >
>> > On Mon, Jan 8, 2018 at 7:45 PM, Raul Miller 
>> wrote:
>> >
>> >> I'm not entirely sure what issue you are trying to raise here, so I will
>> >> guess:
>> >>
>> >> In languages which support tail recursive optimizatio

Re: [Jchat] [Jprogramming] A normal exit from a deeply embedded function to a terminal prompt, how?

[Jose Mario Quintana]

> I do not believe that there is anything meaningful about FB@:FT
> relevant to tail recursion.

You are right, of course, FB@:FT, as stated in my petty claim, has little,
if anything, to do with tail recursion.  Indeed, the claim does not say
much because no restrictions on the nature of FB and FT are imposed.
Consequently, even recursive verbs which are not in tail recursive form can
be trivially written as FB@:FT.  Remember the quicksort troublemaker verb
[0]?

   quicksort=. (($:@(< # [) , (= # [) , $:@(> # [)) ({~ ?@#))^:(1 < #)

one can readily rewrite it as quicksort=. FB@:FT,

   quicksort=. ]@:((($:@(< # [) , (= # [) , $:@(> # [)) ({~ ?@#))^:(1 < #))

However, that is precisely my point, your claim, as originally stated, is
not very different (it does not say much either) because no restrictions on
the nature of FB and FT were imposed.  One can define quicksort as
FB^:FT^:_ by choosing FT as 1:.  Do you see how FB can be defined to
fulfill your claim?  A version of FT (named tricky) for this case is shown
later in this post to avoid a spoiler for those who might like to write
their own versions.  Indeed,

   qs=. tricky^:1:^: _

   (qs -: quicksort) 6 5 9 8 5 2 7 5 4 0 1 2 7 4 9
1

You wrote: "I would be interested in seeing a counter-example that destroys
my belief, if counter examples exist."  However, how can one try to think
about a possible counterexample if even recursive verbs, which are not in
tail recursion form, can be written in such fashion?

Perhaps entertaining another example might bring some clarity.  Remember
the verb evolve [1] which is in tail recursive form?  Not surprisingly,
changing what needs to be changed in tricky results in,

   tricky^:1:^:_ 'METHINKS IT IS LIKE A WEASEL'
METHINKS IT IS LIKE A WEASEL

Surely the definitions for FB and FT that you might have in mind for this
case are quite different.  Are they not?  Can you tell us what those
definitions are?

References

[0] [Jprogramming] Tacit Expressions with Explicit J Syntax
http://www.jsoftware.com/pipermail/programming/2017-October/049085.html

[1] [Jprogramming] Recursive tail calls (WAS: Tacit exercise)
http://www.jsoftware.com/pipermail/programming/2009-December/017529.html

The verb tricky can be defined (wickedly) as follows,

   o=. @:
   c=. "_

   rank=. (;:'"')(0:`)(,^:) NB. Verbing " (dyadic verb)
   lrw=. (_2 }. ":) o (rank&_)  NB. Linear representation (monadic
verb)
   k=. ] [ (". o ([ , '=. ' , lrw @:])) NB. Keep (monadic verb)

   tricky=. R_tricky_ c :: ('R_tricky'&k) o (quicksort f.)


On Tue, Jan 9, 2018 at 8:11 PM, Raul Miller  wrote:

> I do not believe that there is anything meaningful about FB@:FT
> relevant to tail recursion.
>
> A tail recursive function has the characteristic that no matter how
> deep you nest the stack, the result returned from the final result
> will be the result of all routines which called it.
>
> This matches how inductive verbs work. The difference, of course, is
> that there is no stack (which is all that tail recursion was about in
> the first place).
>
> The requirement imposed by induction is that you refactor the original
> recursive function so that the test (for whether you enter recursion)
> be separable in some way from the rest of the code.
>
> How does FB@:FT have anything to do with any of this?
>
> Thanks,
>
> --
> Raul
>
>
> On Tue, Jan 9, 2018 at 6:51 PM, Jose Mario Quintana
>  wrote:
> > I am not entirely sure what you are trying to convey either.  Apparently,
> > you are implying that "F=: FB^:FT^:_" would be, in some sense, simpler
> than
> > the original F but that might not be necessarily the case (depending on
> the
> > nature of FB and FT; which you did not specify).
> >
> > Your claim, to me (so far), is not much different than, for example,
> >
> >   If I have a recursive verb (F y) implemented in J, which satisfies the
> >   constraints for tail recursion, I believe that there is always a pair
> >   of companion functions (FB y) (FT y) such that an F workalike can be
> >   written:
> >
> > F=: FB@:FT y
> >
> > (So what?)
> >
> >
> > On Mon, Jan 8, 2018 at 7:45 PM, Raul Miller 
> wrote:
> >
> >> I'm not entirely sure what issue you are trying to raise here, so I will
> >> guess:
> >>
> >> In languages which support tail recursive optimizations for recursive
> >> functions, those optimizations can still be deployed if the function
> >> in question contains an expression which uses some different recursive
> >> function. Why should J's induction be any different?
> >>
> >> Thanks,
> >>
> >> --
> >> Raul
> >>
> >>
> >>
> >> On Mon, Jan 8, 2018 at 7:08 PM, Jose Mario Quintana
> >>  wrote:
> >> > The claim [2], as written, does not impose any restrictions on FN or
> FT
> >> > apart from being monadic; thus, F itself could be embedded in FB and
> >> could
> >> > provide an opportunity to cheat and defeat its purpose.
> >> >
> >> > Surely you mean something more substantial.  Can you elaborate your
> >> claim?
> >> >

Re: [Jchat] the language of the future for the programming of the past

[chris burke]

Tony

To unsubscribe or change your forum options, see
http://code.jsoftware.com/wiki/System/Forums#Options.2FUnsubscribe .

If you like, I can unsubscribe you. However, you might also consider
getting forum messages as a digest.

Chris


On Wed, Jan 10, 2018 at 1:24 PM, Antony McCardell 
wrote:

> Hi Chris
>
> I need urgently to unsubscribe to J chat. Currently I am unable to
> participate and my mailbox is becoming overloaded with J chat messages. I
> cannot see an "unsubscribe" button anyway. Can you please point me in the
> right direction?
>
> Thanks
>
> Tony
>
>
>
> On 11/01/2018 12:21 AM, chris burke wrote:
>
>> After the fom editor was dropped we have been struggling.
>>>
>> The old form editor was needed because in the old days, there was no
>> layout
>> manager in the UI so controls had to be given an exact position on a form.
>> Fine-tuning this manually would have been tedious. However, there were
>> still problems, for example the layout that worked fine on one resolution
>> or OS may not have worked on another. I remember spending a great deal of
>> time on manually fixing up form editor output so forms worked properly
>> everywhere.
>>
>> However, Qt has a nice layout manager. Control positioning is easy and
>> just
>> works in all platforms.
>>
>>
>> On Tue, Jan 9, 2018 at 11:29 PM, Ric Sherlock  wrote:
>>
>> I can understand the appeal of the WYSIWYG aspect of the old form editor,
>>> but I much prefer the current system for designing and building forms. I
>>> spend much less time aligning controls perfectly and the form resizing
>>> behaviour is much better.
>>>
>>> As for the cross-platform experience, there is no contest - the current
>>> WD
>>> implementation is far superior in terms of functionality, reliability and
>>> appearance.
>>>
>>> I'm sure that the state of flux of GUI development from J6.02 to J8
>>> didn't
>>> help foster a plethora of GUI apps, but I think the paucity of GUI apps
>>> is
>>> primarily due to the focus of the majority of users than the facilities
>>> of
>>> the language.
>>>
>>> The GUI's I've developed are far from complex, but I've found them
>>> relatively easy and satisfying to build, and compare favourably with
>>> those
>>> of most other languages for GUI-based tasks on Rosetta code.
>>>
>>> On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason 
>>> wrote:
>>>
>>> J used to be great at making guis and had the best form editor on the
 market.
 After the fom editor was dropped we have been struggling.
 I would love to have easier ways to create guis.

 On 9 Jan 2018 18:57, "Dabrowski, Andrew John" 
 wrote:

 So it seems that J is not a self-contained language for making GUIs: you
 also need to know either html and js or qt.  Clojure has the significant
 advantage that the GUI code is in idiomatic Clojure.

 All I said was that J isn't a _good_ language for creating GUIs when
 compared with Clojure, Python, or Java for example.  I would have
 thought
 that would be uncontroversial: in fact there are very few examples of

>>> GUIs
>>>
 in the repo, and none are elaborate.  Evidently no one in the J
 community
 places a very high value on GUIs.

 Which is fine, not every language needs to be great at facilitating the
 construction of GUIs, there's a place for scripting languages.  I'm
 happy
 to grant J the distinction of being a superb calculation and scripting
 language, but for GUIs it happens to be mediocre.

 On 01/09/2018 03:02 AM, Björn Helgason wrote:

 JHS is using HTML as a front end.
 There are numerous ways of interacting with HTML tools.
 You can see examples and demos doing gui/graphics etc and mixing with
 javascripts.
 It may be difficult to distinguish between what is J/Javascript.

 On 8 Jan 2018 22:13, "Dabrowski, Andrew John" >>>
> 
 dabro...@indiana.edu> wrote:



 After reading "Algebra as Language" and "Computers and Mathematical
 Notation", I'm starting to see J the perfect language for numerical
 computation.  But for general purpose programming I can see Dijkstra's
 point.

 When APL was designed computers were seen largely as calculating
 machines.  But by the 1970s GUIs were starting to be developed, and
 computers were being applied in areas where tensors were no longer

>>> adequate
>>>
 as the sole data structure.  One thing general purpose programming
 languages must have is extensibility, and that J lacks.

 I'm trying to work out what the appropriate use cases are for J, and I
 think it's calculating with tensors.  If you need more than tensors, or

>>> if
>>>
 you need more than calculation (e.g. GUIs), J is not a good choice.
 --
 For information about J forums see http://www.jsoftware.com/forums.htm


 --

Re: [Jchat] the language of the future for the programming of the past

[Raul Miller]

At the bottom of every chat message is the line:

For information about J forums see http://www.jsoftware.com/forums.htm

and that page contains the line:

To subscribe or unsubscribe, follow the above links to the
corresponding admin pages.

as well as a link for the chat forum.

When you follow that link, look down near the bottom for a place to
enter your email address with a button beside it that says
"Unsubscribe or edit options".

I did not try using that button, but I have no reason to expect it to not work.

I hope this helps,

-- 
Raul


On Wed, Jan 10, 2018 at 4:24 PM, Antony McCardell
 wrote:
> Hi Chris
>
> I need urgently to unsubscribe to J chat. Currently I am unable to
> participate and my mailbox is becoming overloaded with J chat messages. I
> cannot see an "unsubscribe" button anyway. Can you please point me in the
> right direction?
>
> Thanks
>
> Tony
>
>
>
> On 11/01/2018 12:21 AM, chris burke wrote:
>>>
>>> After the fom editor was dropped we have been struggling.
>>
>> The old form editor was needed because in the old days, there was no
>> layout
>> manager in the UI so controls had to be given an exact position on a form.
>> Fine-tuning this manually would have been tedious. However, there were
>> still problems, for example the layout that worked fine on one resolution
>> or OS may not have worked on another. I remember spending a great deal of
>> time on manually fixing up form editor output so forms worked properly
>> everywhere.
>>
>> However, Qt has a nice layout manager. Control positioning is easy and
>> just
>> works in all platforms.
>>
>>
>> On Tue, Jan 9, 2018 at 11:29 PM, Ric Sherlock  wrote:
>>
>>> I can understand the appeal of the WYSIWYG aspect of the old form editor,
>>> but I much prefer the current system for designing and building forms. I
>>> spend much less time aligning controls perfectly and the form resizing
>>> behaviour is much better.
>>>
>>> As for the cross-platform experience, there is no contest - the current
>>> WD
>>> implementation is far superior in terms of functionality, reliability and
>>> appearance.
>>>
>>> I'm sure that the state of flux of GUI development from J6.02 to J8
>>> didn't
>>> help foster a plethora of GUI apps, but I think the paucity of GUI apps
>>> is
>>> primarily due to the focus of the majority of users than the facilities
>>> of
>>> the language.
>>>
>>> The GUI's I've developed are far from complex, but I've found them
>>> relatively easy and satisfying to build, and compare favourably with
>>> those
>>> of most other languages for GUI-based tasks on Rosetta code.
>>>
>>> On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason  wrote:
>>>
 J used to be great at making guis and had the best form editor on the
 market.
 After the fom editor was dropped we have been struggling.
 I would love to have easier ways to create guis.

 On 9 Jan 2018 18:57, "Dabrowski, Andrew John" 
 wrote:

 So it seems that J is not a self-contained language for making GUIs: you
 also need to know either html and js or qt.  Clojure has the significant
 advantage that the GUI code is in idiomatic Clojure.

 All I said was that J isn't a _good_ language for creating GUIs when
 compared with Clojure, Python, or Java for example.  I would have
 thought
 that would be uncontroversial: in fact there are very few examples of
>>>
>>> GUIs

 in the repo, and none are elaborate.  Evidently no one in the J
 community
 places a very high value on GUIs.

 Which is fine, not every language needs to be great at facilitating the
 construction of GUIs, there's a place for scripting languages.  I'm
 happy
 to grant J the distinction of being a superb calculation and scripting
 language, but for GUIs it happens to be mediocre.

 On 01/09/2018 03:02 AM, Björn Helgason wrote:

 JHS is using HTML as a front end.
 There are numerous ways of interacting with HTML tools.
 You can see examples and demos doing gui/graphics etc and mixing with
 javascripts.
 It may be difficult to distinguish between what is J/Javascript.

 On 8 Jan 2018 22:13, "Dabrowski, Andrew John" 
> >>>
 dabro...@indiana.edu> wrote:



 After reading "Algebra as Language" and "Computers and Mathematical
 Notation", I'm starting to see J the perfect language for numerical
 computation.  But for general purpose programming I can see Dijkstra's
 point.

 When APL was designed computers were seen largely as calculating
 machines.  But by the 1970s GUIs were starting to be developed, and
 computers were being applied in areas where tensors were no longer
>>>
>>> adequate

 as the sole data structure.  One thing general purpose programming
 languages must have is extensibility, and that J lacks.

 I'm trying to work out what the appropriate use cases are for J, and I
 think it's calculating with t

Re: [Jchat] the language of the future for the programming of the past

[Antony McCardell]

Hi Chris

I need urgently to unsubscribe to J chat. Currently I am unable to 
participate and my mailbox is becoming overloaded with J chat messages. 
I cannot see an "unsubscribe" button anyway. Can you please point me in 
the right direction?


Thanks

Tony


On 11/01/2018 12:21 AM, chris burke wrote:

After the fom editor was dropped we have been struggling.

The old form editor was needed because in the old days, there was no layout
manager in the UI so controls had to be given an exact position on a form.
Fine-tuning this manually would have been tedious. However, there were
still problems, for example the layout that worked fine on one resolution
or OS may not have worked on another. I remember spending a great deal of
time on manually fixing up form editor output so forms worked properly
everywhere.

However, Qt has a nice layout manager. Control positioning is easy and just
works in all platforms.


On Tue, Jan 9, 2018 at 11:29 PM, Ric Sherlock  wrote:


I can understand the appeal of the WYSIWYG aspect of the old form editor,
but I much prefer the current system for designing and building forms. I
spend much less time aligning controls perfectly and the form resizing
behaviour is much better.

As for the cross-platform experience, there is no contest - the current WD
implementation is far superior in terms of functionality, reliability and
appearance.

I'm sure that the state of flux of GUI development from J6.02 to J8 didn't
help foster a plethora of GUI apps, but I think the paucity of GUI apps is
primarily due to the focus of the majority of users than the facilities of
the language.

The GUI's I've developed are far from complex, but I've found them
relatively easy and satisfying to build, and compare favourably with those
of most other languages for GUI-based tasks on Rosetta code.

On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason  wrote:


J used to be great at making guis and had the best form editor on the
market.
After the fom editor was dropped we have been struggling.
I would love to have easier ways to create guis.

On 9 Jan 2018 18:57, "Dabrowski, Andrew John" 
wrote:

So it seems that J is not a self-contained language for making GUIs: you
also need to know either html and js or qt.  Clojure has the significant
advantage that the GUI code is in idiomatic Clojure.

All I said was that J isn't a _good_ language for creating GUIs when
compared with Clojure, Python, or Java for example.  I would have thought
that would be uncontroversial: in fact there are very few examples of

GUIs

in the repo, and none are elaborate.  Evidently no one in the J community
places a very high value on GUIs.

Which is fine, not every language needs to be great at facilitating the
construction of GUIs, there's a place for scripting languages.  I'm happy
to grant J the distinction of being a superb calculation and scripting
language, but for GUIs it happens to be mediocre.

On 01/09/2018 03:02 AM, Björn Helgason wrote:

JHS is using HTML as a front end.
There are numerous ways of interacting with HTML tools.
You can see examples and demos doing gui/graphics etc and mixing with
javascripts.
It may be difficult to distinguish between what is J/Javascript.

On 8 Jan 2018 22:13, "Dabrowski, Andrew John" 

dabro...@indiana.edu> wrote:



After reading "Algebra as Language" and "Computers and Mathematical
Notation", I'm starting to see J the perfect language for numerical
computation.  But for general purpose programming I can see Dijkstra's
point.

When APL was designed computers were seen largely as calculating
machines.  But by the 1970s GUIs were starting to be developed, and
computers were being applied in areas where tensors were no longer

adequate

as the sole data structure.  One thing general purpose programming
languages must have is extensibility, and that J lacks.

I'm trying to work out what the appropriate use cases are for J, and I
think it's calculating with tensors.  If you need more than tensors, or

if

you need more than calculation (e.g. GUIs), J is not a good choice.
--
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 inform

Re: [Jchat] the language of the future for the programming of the past

[Raul Miller]

I have installed all addons, and I am going to presume you have also.

When I go to the jqt Help menu, I can select Studio > Showcase... and
this offers the demos:

cities
coins
deoptim
eigenpictures
events
isigraph
isigrid
life
minesweeper
plot
solitaire
unicode simple

And, then, each of these demos has its own menu with further depth.

Some quick searching shows that the underlying implementation for this
demos node in the jqt ui is addons/demos/wd/demos.ijs

If you do not see that, where does what you see differ?

Thanks,

-- 
Raul


On Wed, Jan 10, 2018 at 2:18 PM, Dabrowski, Andrew John
 wrote:
> I can't find them in the Showcase, either in Gallery or Studio, could you 
> give me another hint?
> 
> From: Chat  on behalf of chris burke 
> 
> Sent: Wednesday, January 10, 2018 2:03 PM
> To: c...@jsoftware.com
> Subject: Re: [Jchat] the language of the future for the programming of the
>   past
>
> Actually quite a few of the Showcase demos use mouse events, e.g. coins,
> eigenpictures, events, isigrid, solitaire etc.
>
> On Wed, Jan 10, 2018 at 10:58 AM, chris burke  wrote:
>
>> > There should be demos that illustrate mouse events.
>>
>> The old paint demo is at Help|Studio|Showcase|isigraph|Extras|Paint .
>>
>> To see the events in the Term window, first enter:
>>
>> showevents_jqtide_ 2
>>
>>
> --
> 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] the language of the future for the programming of the past

[chris burke]

> I can't find them in the Showcase, either in Gallery or Studio, could you
give me another hint?

These are the demos that can be accessed from within Jqt, not the wiki
pages.


On Wed, Jan 10, 2018 at 11:18 AM, Dabrowski, Andrew John <
dabro...@indiana.edu> wrote:

> I can't find them in the Showcase, either in Gallery or Studio, could you
> give me another hint?
> 
> From: Chat  on behalf of chris burke <
> cbu...@jsoftware.com>
> Sent: Wednesday, January 10, 2018 2:03 PM
> To: c...@jsoftware.com
> Subject: Re: [Jchat] the language of the future for the programming of
> the  past
>
> Actually quite a few of the Showcase demos use mouse events, e.g. coins,
> eigenpictures, events, isigrid, solitaire etc.
>
> On Wed, Jan 10, 2018 at 10:58 AM, chris burke 
> wrote:
>
> > > There should be demos that illustrate mouse events.
> >
> > The old paint demo is at Help|Studio|Showcase|isigraph|Extras|Paint .
> >
> > To see the events in the Term window, first enter:
> >
> > showevents_jqtide_ 2
> >
> >
> --
> 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] the language of the future for the programming of the past

[Dabrowski, Andrew John]

I can't find them in the Showcase, either in Gallery or Studio, could you give 
me another hint?

From: Chat  on behalf of chris burke 

Sent: Wednesday, January 10, 2018 2:03 PM
To: c...@jsoftware.com
Subject: Re: [Jchat] the language of the future for the programming of the  
past

Actually quite a few of the Showcase demos use mouse events, e.g. coins,
eigenpictures, events, isigrid, solitaire etc.

On Wed, Jan 10, 2018 at 10:58 AM, chris burke  wrote:

> > There should be demos that illustrate mouse events.
>
> The old paint demo is at Help|Studio|Showcase|isigraph|Extras|Paint .
>
> To see the events in the Term window, first enter:
>
> showevents_jqtide_ 2
>
>
--
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] the language of the future for the programming of the past

[Raul Miller]

Thanks - I somehow completely missed that Extras menu.

-- 
Raul


On Wed, Jan 10, 2018 at 1:58 PM, chris burke  wrote:
>> There should be demos that illustrate mouse events.
>
> The old paint demo is at Help|Studio|Showcase|isigraph|Extras|Paint .
>
> To see the events in the Term window, first enter:
>
> showevents_jqtide_ 2
> --
> 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] the language of the future for the programming of the past

[Dabrowski, Andrew John]

My purpose in starting this thread was just to clarify for myself what niche J 
fills.  For me that is calculation and scripting, but not exploratory 
programming or GUI making.

That is not a criticism of J.  No programming language can be all things to all 
programmers.  It's pretty clear that the J community is not concerned about 
GUIs in general, and there's no reason they should  be - the console and the 
plot package serve their needs adequately.

My advice (which I'm sure is unsought) would be to stick with what J is 
demonstrably good at, and let slide those things that other languages do 
better.   

I do fear that J is moribund.  I don't see it exciting the interest of young 
programmers.  The effort to make it a platform for developing web apps seems to 
have gone nowhere. 
 And even for business apps, once you guys retire who is going to maintain your 
code?

In order to allow J to survive another generation you'll have to make it 
best-in-class as a calculation tool; trying to convince people it's a great 
platform for making mobile apps is sure to fail.  The idea of making an 
interface to TensorFlow seems like a good one: J is a natural there.  J could 
also be great at shell scripting; or as an embedded language for calculation 
within a larger application, e.g. as  scripting language for Gnumeric.   

I like J, it's fun to work with, the code looks nice on the screen (unlike 
Mathematical, whose brackets are unredeemably ugly), you can get things running 
quickly.  But if you try to sell it as a one-size-fits-all solution to every 
programming problem, it's going to die, and that would be a shame.


From: Chat  on behalf of Raul Miller 

Sent: Wednesday, January 10, 2018 12:20 PM
To: Chat forum
Subject: Re: [Jchat] the language of the future for the programming of the  
past

http://code.jsoftware.com/wiki/Guides/Window_Driver/Window_Driver_Overview#Event_Handlers

(Short form: yes, mouse events are supported)

There should be demos that illustrate mouse events. Currently, I don't
see any examples that stand out. Feel free to write one? (Or, when I
get through my current job crunch, maybe I'll write one. Or maybe
there are some good examples in there already, and I just do not see
them.)

Thanks,

--
Raul


On Wed, Jan 10, 2018 at 11:58 AM, Dabrowski, Andrew John
 wrote:
> I looked through the WD docs and they're not great for newbies: more like 
> quick ref sheets than instruction manuals.
>
> But one thing notable by its absence was any mention of the mouse.  Does WD 
> support mouse events?  For example, can one attach an callback to the 
> mousedown event, or get the current xy-coordinates of the mouse?
>
> On 01/10/2018 02:29 AM, Ric Sherlock wrote:
>
> I can understand the appeal of the WYSIWYG aspect of the old form editor,
> but I much prefer the current system for designing and building forms. I
> spend much less time aligning controls perfectly and the form resizing
> behaviour is much better.
>
> As for the cross-platform experience, there is no contest - the current WD
> implementation is far superior in terms of functionality, reliability and
> appearance.
>
> I'm sure that the state of flux of GUI development from J6.02 to J8 didn't
> help foster a plethora of GUI apps, but I think the paucity of GUI apps is
> primarily due to the focus of the majority of users than the facilities of
> the language.
>
> The GUI's I've developed are far from complex, but I've found them
> relatively easy and satisfying to build, and compare favourably with those
> of most other languages for GUI-based tasks on Rosetta code.
>
> On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason 
>  wrote:
>
>
>
> J used to be great at making guis and had the best form editor on the
> market.
> After the fom editor was dropped we have been struggling.
> I would love to have easier ways to create guis.
>
> On 9 Jan 2018 18:57, "Dabrowski, Andrew John" 
> 
> wrote:
>
> So it seems that J is not a self-contained language for making GUIs: you
> also need to know either html and js or qt.  Clojure has the significant
> advantage that the GUI code is in idiomatic Clojure.
>
> All I said was that J isn't a _good_ language for creating GUIs when
> compared with Clojure, Python, or Java for example.  I would have thought
> that would be uncontroversial: in fact there are very few examples of GUIs
> in the repo, and none are elaborate.  Evidently no one in the J community
> places a very high value on GUIs.
>
> Which is fine, not every language needs to be great at facilitating the
> construction of GUIs, there's a place for scripting languages.  I'm happy
> to grant J the distinction of being a superb calculation and scripting
> language, but for GUIs it happens to be mediocre.
>
> On 01/09/2018 03:02 AM, Björn Helgason wrote:
>
> JHS is using HTML as a front end.
> There are numerous ways of interacting with HTML tools.
> Yo

Re: [Jchat] the language of the future for the programming of the past

[chris burke]

Actually quite a few of the Showcase demos use mouse events, e.g. coins,
eigenpictures, events, isigrid, solitaire etc.

On Wed, Jan 10, 2018 at 10:58 AM, chris burke  wrote:

> > There should be demos that illustrate mouse events.
>
> The old paint demo is at Help|Studio|Showcase|isigraph|Extras|Paint .
>
> To see the events in the Term window, first enter:
>
> showevents_jqtide_ 2
>
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jchat] the language of the future for the programming of the past

[chris burke]

> There should be demos that illustrate mouse events.

The old paint demo is at Help|Studio|Showcase|isigraph|Extras|Paint .

To see the events in the Term window, first enter:

showevents_jqtide_ 2
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jchat] the language of the future for the programming of the past

[Raul Miller]

http://code.jsoftware.com/wiki/Guides/Window_Driver/Window_Driver_Overview#Event_Handlers

(Short form: yes, mouse events are supported)

There should be demos that illustrate mouse events. Currently, I don't
see any examples that stand out. Feel free to write one? (Or, when I
get through my current job crunch, maybe I'll write one. Or maybe
there are some good examples in there already, and I just do not see
them.)

Thanks,

-- 
Raul


On Wed, Jan 10, 2018 at 11:58 AM, Dabrowski, Andrew John
 wrote:
> I looked through the WD docs and they're not great for newbies: more like 
> quick ref sheets than instruction manuals.
>
> But one thing notable by its absence was any mention of the mouse.  Does WD 
> support mouse events?  For example, can one attach an callback to the 
> mousedown event, or get the current xy-coordinates of the mouse?
>
> On 01/10/2018 02:29 AM, Ric Sherlock wrote:
>
> I can understand the appeal of the WYSIWYG aspect of the old form editor,
> but I much prefer the current system for designing and building forms. I
> spend much less time aligning controls perfectly and the form resizing
> behaviour is much better.
>
> As for the cross-platform experience, there is no contest - the current WD
> implementation is far superior in terms of functionality, reliability and
> appearance.
>
> I'm sure that the state of flux of GUI development from J6.02 to J8 didn't
> help foster a plethora of GUI apps, but I think the paucity of GUI apps is
> primarily due to the focus of the majority of users than the facilities of
> the language.
>
> The GUI's I've developed are far from complex, but I've found them
> relatively easy and satisfying to build, and compare favourably with those
> of most other languages for GUI-based tasks on Rosetta code.
>
> On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason 
>  wrote:
>
>
>
> J used to be great at making guis and had the best form editor on the
> market.
> After the fom editor was dropped we have been struggling.
> I would love to have easier ways to create guis.
>
> On 9 Jan 2018 18:57, "Dabrowski, Andrew John" 
> 
> wrote:
>
> So it seems that J is not a self-contained language for making GUIs: you
> also need to know either html and js or qt.  Clojure has the significant
> advantage that the GUI code is in idiomatic Clojure.
>
> All I said was that J isn't a _good_ language for creating GUIs when
> compared with Clojure, Python, or Java for example.  I would have thought
> that would be uncontroversial: in fact there are very few examples of GUIs
> in the repo, and none are elaborate.  Evidently no one in the J community
> places a very high value on GUIs.
>
> Which is fine, not every language needs to be great at facilitating the
> construction of GUIs, there's a place for scripting languages.  I'm happy
> to grant J the distinction of being a superb calculation and scripting
> language, but for GUIs it happens to be mediocre.
>
> On 01/09/2018 03:02 AM, Björn Helgason wrote:
>
> JHS is using HTML as a front end.
> There are numerous ways of interacting with HTML tools.
> You can see examples and demos doing gui/graphics etc and mixing with
> javascripts.
> It may be difficult to distinguish between what is J/Javascript.
>
> On 8 Jan 2018 22:13, "Dabrowski, Andrew John" 
> mailto:dabro...@indiana.edu>
>
>
> 
>
> dabro...@indiana.edu> wrote:
>
>
>
> After reading "Algebra as Language" and "Computers and Mathematical
> Notation", I'm starting to see J the perfect language for numerical
> computation.  But for general purpose programming I can see Dijkstra's
> point.
>
> When APL was designed computers were seen largely as calculating
> machines.  But by the 1970s GUIs were starting to be developed, and
> computers were being applied in areas where tensors were no longer adequate
> as the sole data structure.  One thing general purpose programming
> languages must have is extensibility, and that J lacks.
>
> I'm trying to work out what the appropriate use cases are for J, and I
> think it's calculating with tensors.  If you need more than tensors, or if
> you need more than calculation (e.g. GUIs), J is not a good choice.
> --
> 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] the language of the future for the programming of the past

[Dabrowski, Andrew John]

I looked through the WD docs and they're not great for newbies: more like quick 
ref sheets than instruction manuals.

But one thing notable by its absence was any mention of the mouse.  Does WD 
support mouse events?  For example, can one attach an callback to the mousedown 
event, or get the current xy-coordinates of the mouse?

On 01/10/2018 02:29 AM, Ric Sherlock wrote:

I can understand the appeal of the WYSIWYG aspect of the old form editor,
but I much prefer the current system for designing and building forms. I
spend much less time aligning controls perfectly and the form resizing
behaviour is much better.

As for the cross-platform experience, there is no contest - the current WD
implementation is far superior in terms of functionality, reliability and
appearance.

I'm sure that the state of flux of GUI development from J6.02 to J8 didn't
help foster a plethora of GUI apps, but I think the paucity of GUI apps is
primarily due to the focus of the majority of users than the facilities of
the language.

The GUI's I've developed are far from complex, but I've found them
relatively easy and satisfying to build, and compare favourably with those
of most other languages for GUI-based tasks on Rosetta code.

On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason 
 wrote:



J used to be great at making guis and had the best form editor on the
market.
After the fom editor was dropped we have been struggling.
I would love to have easier ways to create guis.

On 9 Jan 2018 18:57, "Dabrowski, Andrew John" 

wrote:

So it seems that J is not a self-contained language for making GUIs: you
also need to know either html and js or qt.  Clojure has the significant
advantage that the GUI code is in idiomatic Clojure.

All I said was that J isn't a _good_ language for creating GUIs when
compared with Clojure, Python, or Java for example.  I would have thought
that would be uncontroversial: in fact there are very few examples of GUIs
in the repo, and none are elaborate.  Evidently no one in the J community
places a very high value on GUIs.

Which is fine, not every language needs to be great at facilitating the
construction of GUIs, there's a place for scripting languages.  I'm happy
to grant J the distinction of being a superb calculation and scripting
language, but for GUIs it happens to be mediocre.

On 01/09/2018 03:02 AM, Björn Helgason wrote:

JHS is using HTML as a front end.
There are numerous ways of interacting with HTML tools.
You can see examples and demos doing gui/graphics etc and mixing with
javascripts.
It may be difficult to distinguish between what is J/Javascript.

On 8 Jan 2018 22:13, "Dabrowski, Andrew John" 
mailto:dabro...@indiana.edu>


mailto:dabro...@indiana.edu>> wrote:



After reading "Algebra as Language" and "Computers and Mathematical
Notation", I'm starting to see J the perfect language for numerical
computation.  But for general purpose programming I can see Dijkstra's
point.

When APL was designed computers were seen largely as calculating
machines.  But by the 1970s GUIs were starting to be developed, and
computers were being applied in areas where tensors were no longer adequate
as the sole data structure.  One thing general purpose programming
languages must have is extensibility, and that J lacks.

I'm trying to work out what the appropriate use cases are for J, and I
think it's calculating with tensors.  If you need more than tensors, or if
you need more than calculation (e.g. GUIs), J is not a good choice.
--
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

Re: [Jchat] the language of the future for the programming of the past

[Dabrowski, Andrew John]

Have you put yours on RosettaCode?  If not, where can I find them?

On 01/10/2018 02:29 AM, Ric Sherlock wrote:

I can understand the appeal of the WYSIWYG aspect of the old form editor,
but I much prefer the current system for designing and building forms. I
spend much less time aligning controls perfectly and the form resizing
behaviour is much better.

As for the cross-platform experience, there is no contest - the current WD
implementation is far superior in terms of functionality, reliability and
appearance.

I'm sure that the state of flux of GUI development from J6.02 to J8 didn't
help foster a plethora of GUI apps, but I think the paucity of GUI apps is
primarily due to the focus of the majority of users than the facilities of
the language.

The GUI's I've developed are far from complex, but I've found them
relatively easy and satisfying to build, and compare favourably with those
of most other languages for GUI-based tasks on Rosetta code.

On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason 
 wrote:



J used to be great at making guis and had the best form editor on the
market.
After the fom editor was dropped we have been struggling.
I would love to have easier ways to create guis.

On 9 Jan 2018 18:57, "Dabrowski, Andrew John" 

wrote:

So it seems that J is not a self-contained language for making GUIs: you
also need to know either html and js or qt.  Clojure has the significant
advantage that the GUI code is in idiomatic Clojure.

All I said was that J isn't a _good_ language for creating GUIs when
compared with Clojure, Python, or Java for example.  I would have thought
that would be uncontroversial: in fact there are very few examples of GUIs
in the repo, and none are elaborate.  Evidently no one in the J community
places a very high value on GUIs.

Which is fine, not every language needs to be great at facilitating the
construction of GUIs, there's a place for scripting languages.  I'm happy
to grant J the distinction of being a superb calculation and scripting
language, but for GUIs it happens to be mediocre.

On 01/09/2018 03:02 AM, Björn Helgason wrote:

JHS is using HTML as a front end.
There are numerous ways of interacting with HTML tools.
You can see examples and demos doing gui/graphics etc and mixing with
javascripts.
It may be difficult to distinguish between what is J/Javascript.

On 8 Jan 2018 22:13, "Dabrowski, Andrew John" 
mailto:dabro...@indiana.edu>


mailto:dabro...@indiana.edu>> wrote:



After reading "Algebra as Language" and "Computers and Mathematical
Notation", I'm starting to see J the perfect language for numerical
computation.  But for general purpose programming I can see Dijkstra's
point.

When APL was designed computers were seen largely as calculating
machines.  But by the 1970s GUIs were starting to be developed, and
computers were being applied in areas where tensors were no longer adequate
as the sole data structure.  One thing general purpose programming
languages must have is extensibility, and that J lacks.

I'm trying to work out what the appropriate use cases are for J, and I
think it's calculating with tensors.  If you need more than tensors, or if
you need more than calculation (e.g. GUIs), J is not a good choice.
--
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

Re: [Jchat] the language of the future for the programming of the past

[chris burke]

> After the fom editor was dropped we have been struggling.

The old form editor was needed because in the old days, there was no layout
manager in the UI so controls had to be given an exact position on a form.
Fine-tuning this manually would have been tedious. However, there were
still problems, for example the layout that worked fine on one resolution
or OS may not have worked on another. I remember spending a great deal of
time on manually fixing up form editor output so forms worked properly
everywhere.

However, Qt has a nice layout manager. Control positioning is easy and just
works in all platforms.


On Tue, Jan 9, 2018 at 11:29 PM, Ric Sherlock  wrote:

> I can understand the appeal of the WYSIWYG aspect of the old form editor,
> but I much prefer the current system for designing and building forms. I
> spend much less time aligning controls perfectly and the form resizing
> behaviour is much better.
>
> As for the cross-platform experience, there is no contest - the current WD
> implementation is far superior in terms of functionality, reliability and
> appearance.
>
> I'm sure that the state of flux of GUI development from J6.02 to J8 didn't
> help foster a plethora of GUI apps, but I think the paucity of GUI apps is
> primarily due to the focus of the majority of users than the facilities of
> the language.
>
> The GUI's I've developed are far from complex, but I've found them
> relatively easy and satisfying to build, and compare favourably with those
> of most other languages for GUI-based tasks on Rosetta code.
>
> On Wed, Jan 10, 2018 at 6:17 PM, Björn Helgason  wrote:
>
> > J used to be great at making guis and had the best form editor on the
> > market.
> > After the fom editor was dropped we have been struggling.
> > I would love to have easier ways to create guis.
> >
> > On 9 Jan 2018 18:57, "Dabrowski, Andrew John" 
> > wrote:
> >
> > So it seems that J is not a self-contained language for making GUIs: you
> > also need to know either html and js or qt.  Clojure has the significant
> > advantage that the GUI code is in idiomatic Clojure.
> >
> > All I said was that J isn't a _good_ language for creating GUIs when
> > compared with Clojure, Python, or Java for example.  I would have thought
> > that would be uncontroversial: in fact there are very few examples of
> GUIs
> > in the repo, and none are elaborate.  Evidently no one in the J community
> > places a very high value on GUIs.
> >
> > Which is fine, not every language needs to be great at facilitating the
> > construction of GUIs, there's a place for scripting languages.  I'm happy
> > to grant J the distinction of being a superb calculation and scripting
> > language, but for GUIs it happens to be mediocre.
> >
> > On 01/09/2018 03:02 AM, Björn Helgason wrote:
> >
> > JHS is using HTML as a front end.
> > There are numerous ways of interacting with HTML tools.
> > You can see examples and demos doing gui/graphics etc and mixing with
> > javascripts.
> > It may be difficult to distinguish between what is J/Javascript.
> >
> > On 8 Jan 2018 22:13, "Dabrowski, Andrew John"  > > > dabro...@indiana.edu> wrote:
> >
> >
> >
> > After reading "Algebra as Language" and "Computers and Mathematical
> > Notation", I'm starting to see J the perfect language for numerical
> > computation.  But for general purpose programming I can see Dijkstra's
> > point.
> >
> > When APL was designed computers were seen largely as calculating
> > machines.  But by the 1970s GUIs were starting to be developed, and
> > computers were being applied in areas where tensors were no longer
> adequate
> > as the sole data structure.  One thing general purpose programming
> > languages must have is extensibility, and that J lacks.
> >
> > I'm trying to work out what the appropriate use cases are for J, and I
> > think it's calculating with tensors.  If you need more than tensors, or
> if
> > you need more than calculation (e.g. GUIs), J is not a good choice.
> > --
> > 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