Intro to ATS - How to code productively

[Lance Galletti]

Hi ats users!

I recently had the opportunity to give a talk at a hackathon about ATS and coding productivity / quality. I thought I would share my slides here:

https://docs.google.com/presentation/d/157VR0oQNTfUiiChYdbv77PYZkYKo_zkZfwRiqGv6sEY/edit?usp=sharing

And the informal write up I am currently developing:

https://github.com/galletti94/magnificATS/tree/master/INTRO

If, like me, you are passionate about coding quality, methodology, productivity, or functional programming and, of course ATS, please reach out!

I would be happy to collaborate on the write up and hear your thoughts about what drew YOU to ATS.

Looking forward to connecting!

Lance Galletti

gall...@bu.edu

[gmhwxi]

Thanks for sharing!

[Artyom Shalkhakov]

Hi Lance,

On Tuesday, March 27, 2018 at 9:40:55 PM UTC+6, Lance Galletti wrote:

Hi ats users!

I recently had the opportunity to give a talk at a hackathon about ATS and coding productivity / quality. I thought I would share my slides here:

https://docs.google.com/presentation/d/157VR0oQNTfUiiChYdbv77PYZkYKo_zkZfwRiqGv6sEY/edit?usp=sharing

And the informal write up I am currently developing:

https://github.com/galletti94/magnificATS/tree/master/INTRO

If, like me, you are passionate about coding quality, methodology, productivity, or functional programming and, of course ATS, please reach out!

First off, I chuckled when I saw the name of the repo. :-)

I want to write something about the C-style programming for ATS, but not quite have the time (or the guts or whatever it is I lack). It would be great to help fellow programmers learn more about ATS!
 

I would be happy to collaborate on the write up and hear your thoughts about what drew YOU to ATS.

I still view ATS as C-with-proper-type-system. :) This is what drew  me to ATS: you can write safe, efficient systems-level programs but this will require some theorem proving, bringing this academic discipline close to actual programming practice (or you can cast your way through the types, but then you're the one to blame if things go wrong). ATS helped me to improve my knowledge of C.

Regarding your write-up, have you seen HtDP (How to Design Programs)? Their "design recipes" are somewhat similar IIRC (proceed top-down, refine, state pre- and post-conditions, provide examples of evaluation aka tests).

[Lance Galletti]

Hi Artyom!

Thank you for your feedback! It is great to hear an advanced programmer's perspective on the appeal of ATS. If you have the time it would be great to incorporate into the write-up a section about this! :)

So far I have been just putting together what I have learned from Hongwei's classes and books but I will definitely be checking out HtDP - thank you for the suggestion!

[Artyom Shalkhakov]

On Wednesday, March 28, 2018 at 9:34:37 PM UTC+6, Lance Galletti wrote:

Hi Artyom!

Thank you for your feedback! It is great to hear an advanced programmer's perspective on the appeal of ATS. If you have the time it would be great to incorporate into the write-up a section about this! :)

I wouldn't call myself an advanced programmer, but I've been interested in ATS programming for a lot of time, that's true.

I'll write a sales-pitch. It's really exciting stuff (to me, at least!).
 

[Lance Galletti]

Awesome thank you! Looking forward to it! :)

[Artyom Shalkhakov]

Hi Lance,

I've put this together.

What do you think? And the rest of the group? This is mostly aimed at C programmers.

[Lance Galletti]

This is so amazing! Thank you for taking the time!

[Steinway Wu]

Hi Artyom, 

This is awesome :)

I have a question about "gradual improvement" of performance. I personally feels it is more about gradual improvement of specification, e.g. change a simple data type into a more refined type, to catch more bugs. So the sales pitch is more like "write dirty code that works first, and then sit down and formally specify what the code should do", at least to me. What do you think? 

Also I would like to point out abstract types. It's a great way to work out a system in a top-down fashion. We craft some abstract types, then provide a set of functions that works on values of these types (like a DSL), and program using these functions. We can quickly prototype the idea using the type checker, and defer the implementation details to a later point. C can probably do this via pointers or structs, but then you need to think about the details of a struct. 

[Artyom Shalkhakov]

Hi Steinway,

On Sunday, April 1, 2018 at 11:39:34 PM UTC+6, Steinway Wu wrote:

Hi Artyom, 

This is awesome :)

Thanks!
 

I have a question about "gradual improvement" of performance. I personally feels it is more about gradual improvement of specification, e.g. change a simple data type into a more refined type, to catch more bugs. So the sales pitch is more like "write dirty code that works first, and then sit down and formally specify what the code should do", at least to me. What do you think? 

Well, I guess the two views are complementary! I was actually thinking about non-linear data type to linear data type to be a refinement -- is this not  considered the usual meaning? I wasn't actually thinking of "refinement" in a technical sense.

I changed the phrasing somewhat:

• gradual improvement: no need to put a lot of effort upfront, write dirty code that works, and then sit down and improve efficiency and correctness (either or both, you have the tools!)

Is this any better?

Also I would like to point out abstract types. It's a great way to work out a system in a top-down fashion. We craft some abstract types, then provide a set of functions that works on values of these types (like a DSL), and program using these functions. We can quickly prototype the idea using the type checker, and defer the implementation details to a later point. C can probably do this via pointers or structs, but then you need to think about the details of a struct. 

Indeed! This is certainly the way to go.
 

[Steinway Wu]

Hi Artyom, 

Yes, I think it's good :)

(Sorry for the delay. I was offline for the past week. )