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
