I just realized that I made a mistake, obverse should be: ^:_1 :: (a -> b) -> (b -> a), apologizes for any confusion.
On Sun, Apr 5, 2015 at 12:31 PM, Aistis Raulinaitis <[email protected]> wrote: > Raul, > > You are absolutely right, you can definitely think of all the data types > available currently as a sum. > > No, no, no. You are right, it is a big thing. You put it very well, and > I'm sure there is a trail of blood of others who have gone down that path. > My intention is not to say that I think J would need these things, there > are already so many good reasons to use J over Haskell. No more (map . map > . map), etc. Just to see what the opinion on these things are. It's given > me a lot to think about! > > I like your idea, I was thinking of keeping rank in, but starting even > smaller seems like a better idea. I don't forget how many types J does > have, sparse arrays, complex numbers, etc! But even on that line of > thinking, there are still lots of low hanging fruit. Like interfaces from > Haskell to J and back, among many other things. So maybe that's something > that would be more useful than me indulging in my pet hobby of language > design. Haskell and J complement each other very well for how I think about > computing, it's amazing how in some ways they are very close in the > language design space but in other ways they are as far as can be. > > What do you mean by plumbing, I'm not quite sure what you mean? > > You are absolutely right, he starts off the conversation without defining > terms. I think the context is in terms of defining new types, the point > being that you only have the types you are given by the compiler writer in > a dynamic language. Which can be a virtue, like in J, which this > restriction gives the ability for J's terseness and optimizations. But in > other languages it's simply a vice, since most people that use languages > like Python think that "dynamicness" == monkey patching, or something or > other. Which on second thought is another similarity between Haskell and J, > where you are consciously making a design choice to give up certain things > to gain others. > > Right, he is definitely going after a grammatical issue that happens in > the more mainstream communities. J transcends most of these definitions > because most of the terms mean wildly different things in context. Just > like monads in J or Haskell. > > Yup, he is definitely an academic, so most of his work doesn't really > worry about speed. But it's a bit unfair to place the goalposts on machine > code generation, even the theoretical stuff needs to happen since it is > useful. (An example would be that the heartbleed bug would have been > impossible if it was implemented in something like Haskell, using a high > level language so thing like buffer overflows aren't even expressible and a > strong static type system that would enforce things like constant timing > and other invariants.) I admire his work, it's very high quality, he's done > major contributions in verified software using the Twelf language ( > http://twelf.org/wiki/Main_Page), as well as his recent work with > Homotopy Type Theory (https://github.com/HoTT/book). > > Well, I don't know. I think that J and Haskell are great examples of > amalgamations of theory and practice. I'll just leave it at that. > > You are absolutely right, what you do with the language is infinitely > more important that the language itself. It's just that I have an interest > in languages for the sake of languages, and that's partially why I find > myself here. When it comes to languages, I can't say enough good things > about J, it really is top of class. I find myself steeped constantly in the > cultures of other languages, it's very nice to hear the opinions of other > in other communities. It's actually kind of funny, because Haskell is still > closer in some respects to all the other languages in the design space > because of it's lack of implicit operation over arrays. I think there would > be much to be gained if we brought both of the languages closer to each > other, since they both have complementary characteristics that benefit > computing immensely. > > > On Sat, Apr 4, 2015 at 12:41 PM, Joe Bogner <[email protected]> wrote: > >> I find static typing to be most effective when working with code that I >> didn't write or that has many dependencies. >> >> Once familiarized with the error syntax, it can be faster than consulting >> the documentation to understand what the expected inputs and outputs of a >> function are, especially with decent intellisense >> >> It can also be faster to refactor code by failing fast at compile time >> instead of run time. Of course, a comprehensive test suite can provide an >> even higher level of security when refactoring, but that is not always >> afforded >> >> Some common examples I encounter: >> >> 1. Refactor a method call from having a handful of parameters to accepting >> a type instead. One 'safe' approach may be to create a new overload for >> the >> function, but maybe it makes sense to clean up all the existing >> references. >> The compiler can find the references faster than I can >> >> 2. Remove a method / parameter that's no longer in use. Add a parameter >> (although many languages offer a default parameter syntax for unspecified >> parameters -- c# recently) >> >> I haven't felt the benefit as often when using a small code base written >> by >> me. Specifically in J, I find myself writing small verbs that accept 1 >> parameter or two at max. I don't consider a single parameter that is a >> list >> of parameters as a single parameter either ( 3 : ' ''a b c''=.y ') would >> count as 3 parameters to me. As a result, I don't find as much complexity >> that the type systems seem to be designed to deal with. >> >> When dealing with larger code bases, I appreciate type systems that stay >> out of your way and seem to figure out the right thing to do. C# does a >> nice job of this with type inference and even dynamic/duck types. My >> larger >> Javascript projects can start to become unwieldy which has me starting to >> look towards typescript with optional typing. >> >> A few common examples that drive me crazy: >> >> Dynamic typing (javascript) - math: >> >> 3+0.001+1 >> 4.0009999999999994 >> >> Static typing (c#) - requiring casting: >> >> //this is ok >> decimal x=3; >> >> //this throws a compile time error: Operator '*' cannot be applied to >> operands of type 'decimal' and 'double' >> decimal y=x* 1.5; >> >> //this is ok -- needed to add the m >> decimal y=x * 1.5m >> >> >> >> >> On Thu, Apr 2, 2015 at 10:05 PM, Devon McCormick <[email protected]> >> wrote: >> >> > I'm interested in examples demonstrating the value of static typing. Do >> > you have any you find particularly compelling? >> > >> > On Thu, Apr 2, 2015 at 8:01 PM, Aistis Raulinaitis < >> [email protected]> >> > wrote: >> > >> > > Definitely. Thanks. I felt a little sad for the author's distaste for >> > > static typing. As a Haskeller I actually see static typing as tool to >> > lean >> > > into when things get tough, instead of a thing you have to work >> against. >> > To >> > > me programs are just data and mappings of that data from input to >> > output. I >> > > may just be one of those weirdos, but for me (at least right now) the >> > > perfect language for me would be if J and Idris/Agda had a baby and >> made >> > a >> > > dependently typed array language. ...and regained back APL's symbolic >> > > syntax and left ASCII in the dust. >> > > On Apr 2, 2015 4:33 PM, "Joey K Tuttle" <[email protected]> wrote: >> > > >> > > > With this interesting article - >> > > > >> > > > >> http://www.technologyreview.com/review/536356/toolkits-for-the-mind/ >> > > > >> > > > >> > > > >> ---------------------------------------------------------------------- >> > > > 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 >> > > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
