APL for Web Development

[neeraj]

Hi All:

Will the forum share with me their experiences in using APL for browser based applications? As far as I know APL can be used with ASP.NET. It is also probably possible to use APL as a web and application server although I do not know how APL will perform as a Web Server with several hundred simultaneous users.

Are there other paradigms for browser based development using APL as the only or main language?

Thanks
Neeraj Gupta

[StefanoLanzavecchia]

Back in the days when I was Vector's editor and I could write in English, I wrote an editorial in support of using APL to write Web Servers for internal use.

I wrote 3 web servers from the ground up in APL. The only one that actually went into production is the second one, the worst, the less complete, the less inspired.

I've never had to deal with hundreds of users: my limit is probably less than half a dozen concurrently. And since it takes the APL code often more than half a minute in a critical section to produce the data to be displayed, the concern is not so much on the capability of the HTTP server to handle hundred of users...

Anyway, I am now embedding my 4th web server. But this time I couldn't be bothered to print the HTTP specs again and implement them from the ground up. I surfed the web and found a simple embeddable and extensible Web Server written in C#. The latest version of this server is not even complete and has a couple of unexpected bugs. But I know C#, I know web servers, and I know my way 'round other people's code. So it was quite simple to adapt it to my needs. If the author ever publishes new patches then I am going to be in trouble because I'll have to evaluate what to include and how. But so far I am rather satisfied. By using this "external" web server coupled with a module that can call back into APL, I can leave the duty of serving static resources to somebody who understands HTTP 1.1 and concentrate only on the dynamic part of the application. I do need fancy controls, but that's all client-side code either downloaded from the immense World Wide Web or hand-crafted in JavaScript (well... yes... it's a fun project!).
Mostly the data transfered from APL to the HTML/JS front-end is JSON (gzipped to reduce the communication overhead: 2 megs of quotes and curly braces shrink down to 200K and that's all part of HTTP and easily supported by the .NET BCL, so I had to do very little work to implement it).

[kai]

Ruby on Rails is a BIG success. (In fact this web framework was the reason why people started to look into Ruby as a language that might offer something). There are quite a number of websites running on this framework now, not the smallest one by the inventors of Ruby on Rails, 37signals. They have quite a large number of customers, and any customer is by definition a web user.

Yet Ruby is an interpreted language, and it does not even have threads, at least not when I looked into Ruby 2 years ago.

The success of Ruby on Rails should teach us something.

[neeraj]

Thanks for the replies. I am curious to know what lessons can be drawn from Ruby on Rails for the Dyalog APL community. Thanks.

[neeraj]

Most of the web hosting services use Linux and Ruby on rails is available on linux and has a tight integration with a number of web servers such as apache. Only a very few web hosting companies make Windows Server based web hosting available and if they do it is almost always at a price premium to linux based hosting. I do not believe that Dyalog on Linux has such integration with Apache etc. Also, I do not know how Windows/ASP.NET/Dyalog performs compare to something like Linux/APache/Ruby on Rails in terms of performance.

At 2009 conference Dave Thomas exhorted for APLers to get in/on the cloud. I am not sure what is the paradigm in the Dyalog world to develop cloud based applications. For, e.g., how would one implement a Salesforce.com type of web/browser based app in Dyalog. Does the question even make sense because we "only" do desktop applications?

Is APL# going to provide a solution here?

I think we as an APL community need to address these issues. A lot of computing is happening on handheld devices. The world is changing and we need to be cognizant of this and react accordingly.

[woody]

I have been playing around with the new MildServer DyalogAPL 12.1.x workspace (MSERVER) as a Web Server and find it easy to use and very well engineered.

I know of at least 3 other APL'ers who are also active with the new MildServer workspace. And I hear rumors that a newer and more "robust" version of MSERVER will be coming out soon.

Could we have a new FORUM section dedicated to the topic of Web Servers and Web Services using DyalogAPL ? and/or a FORUM specific to the new MildServer web server "product" ?

Thanks!

//W

[rpullman]

Two years ago I wrote a couple of (computational) APL components for an ASP.Net application. There is nothing to it. Just need to declare data types. APL code can be unit tested in immediate execution. Integration is a matter of exporting the APL as an assembly. Communication and presentation can be handled outside of APL. APL components are the same as any other component as far as ASP.Net is concerned.

For example consider an APL regression object 'Regress', instantiated with a data set 'b':
a←⎕NEW Regress b

In immediate execution all the features of Regress can be tested directly:
c←a.RSquared t
d←a.ANOVA e f g

ASP.Net's instantiation and usage is analogous. The key to the interface is the :Signature line of each public method. The Signature discloses the data types, e.g.

∇ r←Calc(threshhold methodology group sample band);index;s;b;data;bv;idx;p;i;n;mu;sig;j
:Access Public
:Signature Int32←Calc Double threshhold,Int32 methodology,Int32[] group,Int32 sample,Double band
.....

The Signature is visible to the ASP.Net developer so the descriptive names are helpful, as opposed to
:Signature Int32←Calc Int32 a, Int32 b, Int32 c, Int32 d, Int32 d1...

Generally if it works in unit testing it will work under ASP.Net, but ASP.Net does have stricter rules so some adjustment of code will likely be needed.

[woody]

Greetings.

It has been a few years ... and we have made some excellent progress with hosting APL on the Internet at http://www.APLcloud.com.

We decided to partner with Amazon (AWS) and Dyalog with a focus on helping APLers move up to a web based hosting environment.

Our dedicated servers run both Linux and Windows (2012-R2) Operating Systems. These are robust full featured dedicated servers that include a licensed version of Dyalog APL 14.1. (Prices start at $40 USD per month at a computer center near you)

In addition, we have excelled in the use of the Dyalog APL Web Server "MildServer" (aka MiServer or MServer). We're happy to share our work with other Dyalog APLers.

Is there any interest in running APL on the Internet as a Web Site or Web Service?

Got any ideas for Web Sites and Services that might leverage Dyalog APL?
(Multi-user Games? System Integration? Application as a Service?)

How about "porting" legacy APL systems to become Web Based applications?

Or, client/server solutions with Dyalog APL (client apps) connected through a central Dyalog APL Web Service "HUB"?

Thoughts?

Cheers,

//W