For maintenance and testing better to export results to fill an existing 
spreadsheet. J can already be arrayed functions from my understanding.  

Donna

On 2013-05-11, at 7:01 AM, Greg Borota <[email protected]> wrote:

> Interesting idea. You could actually combine J and spreadsheets right now
> either via the COM (after registering J.dll) or by using VSTO and the
> PInvoke layer I wrote (and I hear others have had too but those are not
> publicly available):
> https://github.com/borota/NetJ/blob/master/J.SessionManager/JSession.cs
> .NET J console is an example of using j.dll inside C#:
> https://github.com/borota/NetJ/blob/master/J.Console/Program.cs
> 
> 
> On Sat, May 11, 2013 at 4:03 AM, Björn Helgason <[email protected]> wrote:
> 
>> What is quite obvious is that ordinary users have taken a fondness for all
>> kinds of spreadsheets.
>> 
>> Over the years spreadsheets have been very popular.
>> 
>> Spreadsheets may not be as advanced as many programming languages.
>> 
>> All kinds of things may be much better handled in J than a spreadsheet.
>> 
>> So why not mix J and spreadsheets?
>> 
>> J and grids have been interesting.
>> 
>> Some demos of sending data between a spreadsheet and J have been
>> interesting.
>> 
>> Having a spreadsheet with all the power of J would be very interesting.
>> 
>> 
>> 
>> 
>> 2013/5/11 <[email protected]>
>> 
>>>> I can imagine that if one were to look into how the documents are
>>>> generated, it would show interesting things like half the time going to
>>>> parsing XML or some other similarly relevant activity.
>>>> 
>>>> This kind of nonsense is rampant in commercial systems.
>>>> 
>>>> Anyone in this forum (maybe even working at MS) have a rationale for
>>>> naming an HTML file with a .xls extension?  (and distributing it to the
>>>> world....)
>>> 
>>> Imagine you want a quick-and-dirty export for medium-competent users.
>>> 
>>> You do not want to do all the configuration of sorting etc. because they
>>> want to be able to sort it in their spreadsheet anyway.
>>> 
>>> You know that a file of any widespread format and with .xls extension
>>> will be opened in the spreadsheet program the user uses — whether it is
>>> Excel or LibreOffice, Calligra or something else.
>>> 
>>> Now: generating valid XLS is a pain. CSV is good, but there are problems
>>> with default encoding. And HTML is opened easily by Excel _and_ contains
>>> encoding header. Also, valid HTML is not complex to parse and it is also
>>> easy to write a script that will reexport HTML file to CSV using any
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to