Check out cobra, python inspired -- it already helped developers "realize how great optional typing can be in everyday code": http://cobra-language.com/docs/why/
Great language too if you're down with .NET.
Why we're supporting Typed Clojure
31–40 of 77 posts
Re: Why we're supporting Typed Clojure
#32There is already typing in Clojure (and Python and Ruby). It`s called "100% unit test coverage". If you want it, you can have it now.
Unit test coverage (as much as I enjoy it, since that's how CircleCI makes all its money) is good, but it can't provide the guarantees static type checking can. Each has its place, and neither replaces the other.
Re: Why we're supporting Typed Clojure
#33Earlier quoted context omitted.
Indeed. I'm hoping the IDE support will include emacs - it can already do loads of cool things connected to nrepl, but completion on a hash would be amazing.
Does emacs support language aware intelliense (auto complete) for any language? I thought the common case was support through CTAGs.
It does for several languages (Dylan, Common Lisp, Java, etc). If you've got a compiler with an API, like say Clang, you can talk to it from Emacs Lisp.
Re: Why we're supporting Typed Clojure
#34Earlier quoted context omitted.
Indeed. I'm hoping the IDE support will include emacs - it can already do loads of cool things connected to nrepl, but completion on a hash would be amazing.
Does emacs support language aware intelliense (auto complete) for any language? I thought the common case was support through CTAGs.
Yes, at least in clojure and CL. In Clojure, you use nrepl. Emacs (and several other IDEs) have clients which open a socket connection to your running clojure process. While editing a function, emacs will say "tell me about `my.namespace/foo`". It then shows arity and argument name info for the fn.
It's basically the same UX as you're used to in Java, except the info comes from asking the running process, rather than parsing statically.
Re: Why we're supporting Typed Clojure
#35There is already typing in Clojure (and Python and Ruby). It`s called "100% unit test coverage". If you want it, you can have it now.
I write lots of Ruby, and I downvoted you because this isn't very constructive.
Re: Why we're supporting Typed Clojure
#36Earlier quoted context omitted.
Does emacs support language aware intelliense (auto complete) for any language? I thought the common case was support through CTAGs.
It does for several languages (Dylan, Common Lisp, Java, etc). If you've got a compiler with an API, like say Clang, you can talk to it from Emacs Lisp.
How does Emacs plug into a statically typed language like Java? Does a compiler like Clang have an interactive/heuristic based mode suitable for use in a language-aware editor? Or do they just assume the code is in a good state and run the compiler when feedback is desired?
Re: Why we're supporting Typed Clojure
#37Earlier quoted context omitted.
What do you mean?
I'd like to see your defintion of structural typing in PHP. (Hint: Not casts, not lots of manual gettype)
I don't have a definition, I just use the thing. That's why I'm asking, I'm not a computer scientist. Eg:
$f = function helloAction(Http\Request $request) {
$response = new Http\Response("Hello " . $request->query->get('name'), 200);
$response->setMa // at this point the IDE will show a list of methods like 'setMaxAge($time)', because it knows its type
};
$someObject->someMethod($f);
protected method someMethod($f) {} // no checks!
protected method someMethod(\Closure $f) {} // only an argument of type Closure will be accepted.
Response $r = new Response(...);
Re: Why we're supporting Typed Clojure
#38Earlier quoted context omitted.
Autocompletion on the keys of a hash.
I know that in several communities, "hash" and "hash map" are synonymous. However, in Clojure hash maps are only one of several map implementations. We have implementations backed by linear array scans, prefix trees, and other data structures too. The word "hash" a shorthand for the noun-phrase "hash code" (aka "digest") and a verb for the process of creating hash codes.
Oops. Sorry about that; I was still thinking in Ruby (day job) mode!
Re: Why we're supporting Typed Clojure
#39Earlier quoted context omitted.
I'd like to see your defintion of structural typing in PHP. (Hint: Not casts, not lots of manual gettype)
I don't have a definition, I just use the thing. That's why I'm asking, I'm not a computer scientist. Eg: $f = function helloAction(Http\Request $request) { $response = new Http\Response("Hello " . $request->query->get('name'), 200); $response->setMa // at this point the IDE will show a list of methods like 'setMaxAge($time)', because it knows its type }; Now I can pass $f somewhere else, like this: $someObject->some…
Pretty sure those are runtime contracts, not static types. Also see https://en.wikipedia.org/wiki/Structural_type_system
Re: Why we're supporting Typed Clojure
#40I still don't think this is worth supporting if you don't use Clojure. As far as dynamic languages go, I already use Racket quite a bit and as mentioned I can just use Typed Racket if I want, or I can use Racket's excellent contract system for some things (sparingly if I need good performance). Also I doubt it will catch on in the Python community, which is hostile to this sort of thing. JavaScript is perhaps a good…
Typed Racket and Typed Clojure are major sources of inspiration/reference for typed versions of JavaScript like TypeScript and possibly future versions of EcmaScript.