81–90 of 121 posts
Earlier quoted context omitted.
Yup, specs can be used at runtime as well. Very helpful to validate data, or perhaps a set of business rules. Insures the spec you use to test is the same logic you use at runtime.
>specs can be used at runtime as well. What do you mean "as well"? I thought it was only a runtime check at all.
Earlier quoted context omitted.
Well that was condescending.
More disillusionment than condescending. I jumped on learning Clojure waiting for big, nice surprises, new stuff, or an enlightening moment, but there wasn't any. I do, however, find it easy to learn and that's a good thing. On the other hand i am not really knocking down Clojure. If somebody wants me to do a project that requires interacting with lots of Java classes, I'm really glad Clojure exists, since it liberat…
Earlier quoted context omitted.
If you need to force yourself, or if you need extra special motivation to use Clojure .. most likely you will never use it You might spend sometime learning it out of curiosity, but you will never use it The languages I used, are ones I had to use, either because they were the only option, or clearly the best option for my solution (C#, VB.Net, Powershell, SQL) Clojure will never be your only option, and .. it being…
I'm quite surprised by your conclusion that Clojure "is not the best option" for Business Intelligence. What general purpose language is better for that in your opinion? There's a difference between "best tool for the job" and "most widely used tool for the job" at this moment in time. People's habits sometimes take years or decades to break (if they ever do).
Is clojure.spec a replacement for static typing? I ask because I've taken a look at clojure in the past and generally like what I see, but after moving from JavaScript to TypeScript at work I don't think I can ever return to a dynamically typed language again. Types are just priceless when refactoring, integrating someone else's code with your own or just exploring new libraries or APIs.
One of the things it can be used for is to check variable types at dev time, just as static type systems check a type compile time. It can also be used for runtime validation, randomized generative testing, more advanced checks/rules than current type systems can specify(eg checking outputs are correctly related to inputs).
Also an important philosophical difference with type systems is an open approach to data structure, where types are generally closed. The concept is that it allows more flexible systems that are easier to adapt to new needs.
Here's the best intro to spec I've seen, it's long and sound is terrible, but it's a great talk. https://vimeo.com/195711510
Earlier quoted context omitted.
I'm looking forward to hearing a long-form rational of the :args :ret :fn function instrumenting decisions, and seeing if the devs see it as an easy choice or up for debate. It feels really uncomfortable declaring a full spec for a function & instrumenting it, then getting feedback if the args don't conform to spec but Clojure being A-OK if the return value doesn't. I understand well that in theory the functioning of…
I'm not familiar with Spec, but what you're describing sounds like enforcing preconditions but not postconditions by default, which is what most DbC frameworks (or languages with intrinsic support) normally do. The idea being that most of the time, you're running library code, and you want to validate what you're passing in, but you trust it to do the right thing for any input that is valid.
I believe this is a missed opportunity to find bugs.
Can anyone sell me on why I should use clojure over say, any of the other nice Lisp-1s, given that I don't care about java.
I am planning on learning Clojure for essentially two reasons: the community / ecosystem seems very active (which is really my primary reason for picking a programming language; I have no interest in writing something if a library exists), and I've heard good things about a couple of things that distinguish it from other Lisps, like maps and spec. I'm somewhere between indifferent to unhappy that it runs on the JVM,…
Earlier quoted context omitted.
If you're indifferent to Java then you can use a Lisp that just so happens to let you interop with Java libraries which is very very handy. It's also a nice Lisp, tho not as pure or quite as powerful as others. But I'm not very much up-to-date on anything new in the past few years, and I was never a guru anyways, so maybe there are better pitches.
Do you have a favorite accessible guide to comparisons of lisps with respect to purity and power?
* it doesn't do tail call optimisation unless you explicitly mark the self-call using by using recur (the lack of implicit TCO is a JVM limitation) * it doesn't use macros as much, although they are they're there and still used pretty often * it has language literals for the built-in data structures that look odd to other LISP'ers, e.g. {...} #{...} [...] * it's error messages are ecosystem dependent, e.g. Java stack traces for Clojure or and JS ones for ClojureScript
Earlier quoted context omitted.
Yup, specs can be used at runtime as well. Very helpful to validate data, or perhaps a set of business rules. Insures the spec you use to test is the same logic you use at runtime.
>specs can be used at runtime as well. What do you mean "as well"? I thought it was only a runtime check at all.
Can anyone sell me on why I should use clojure over say, any of the other nice Lisp-1s, given that I don't care about java.
> Can anyone sell me on why I should use clojure over say, any of the other nice Lisp-1s, given that I don't care about java. It's the same question I make myself, since after learning Clojure here I am, still using Common Lisp happily ever after. Well, if you think that data should be immutable by default, if you really need readymade syntax sugar for hash table and the likes, if you don't have any need for object o…
Earlier quoted context omitted.
At the moment, most of the things that are spec'ed in the box are the gnarly macro "languages" like destructuring, defn, ns, etc. These spec'ed macros do catch a far more complete set of error messages than the macro did with custom error handling. However, those error messages are in many case more challenging to read than before. This is an area of ongoing research - the reasons for the complexity are varied. In ge…
Do you have an idea of how far along clojure.spec is for a stable, non-alpha/beta release? clojure.spec is by far the most interesting and compelling reason for me to check out Clojure. I would also love for it to apply to ClojureScript as well, although I understand that's a separate project.