Re: Java Interop on steroids?

[atdixon]

> Do the framework you're talking about do static analysis of the types? 
Because generic types are erased at runtime, so there wouldn't ever be a 
way for proxy to set them in.

They aren't entirely erased. They're erased from the code, but Java 
compilers are obligated to emit generic type signatures (as metadata) in 
the compiled class file.

The frameworks I mentioned reflect on these generic type parameters *at 
runtime* to drive their dynamic behavior. 

More information here:

https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getGenericSuperclass--
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.9.1

Searching back through this group, I found that in 2012 someone proposed a 
patch to Clojure supporting this in `proxy` (link: 
https://groups.google.com/d/msg/clojure/Xv1pKATfP0c/od_uwpHlNhMJ) but it 
looks like it never made it in.


On Saturday, June 22, 2019 at 11:32:36 PM UTC-5, Didier wrote:
>
> > They did cite a significant performance boost as a side effect.
>
> I think it isn't very clear from the wording. They didn't just rewrite it 
> in Java, they also changed the architecture:
>
> > Storm 2.0.0 introduces a new core featuring a leaner threading model, a 
> blazing fast messaging subsystem and a lightweight back pressure model
>
> So it is hard I think to do an apples to apples comparison. In my opinion, 
> a system like Storm will fundamentally be more limited by its architecture 
> in performance than the language it uses.
>
> That said, even if I think the performance improvements are probably 
> mostly due to architectural changes they also made. It shouldn't come as a 
> surprise that Java would be faster than Clojure in most cases. I don't want 
> to make false pretenses. Clojure and Java are not equal in semantics, and 
> Java's mutable, eager and object grouped methods semantics are almost 
> always going to be more performant. Clojure makes a trade offs of 
> performance and memory for simplicity.
>
> When people say Clojure can match Java in performance, it almost always 
> implies using escape hatches and changing the semantics back to imperative 
> code. The good news though, when you use Clojure's semantics, you benefit 
> in simplicity and the performance impact is marginal, so it is still fast 
> enough for almost all use cases.
>
> Now, back to type annotations. I really don't think Storm 2.0 performance 
> improvements were due to usage of reflection that hadn't been addressed 
> from Clojure. But who knows.
>
> Do the framework you're talking about do static analysis of the types? 
> Because generic types are erased at runtime, so there wouldn't ever be a 
> way for proxy to set them in.
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/1cf5ad80-0504-4634-b186-b624206c0145%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Java Interop on steroids?

[Didier]

> They did cite a significant performance boost as a side effect.

I think it isn't very clear from the wording. They didn't just rewrite it in 
Java, they also changed the architecture:

> Storm 2.0.0 introduces a new core featuring a leaner threading model, a 
> blazing fast messaging subsystem and a lightweight back pressure model

So it is hard I think to do an apples to apples comparison. In my opinion, a 
system like Storm will fundamentally be more limited by its architecture in 
performance than the language it uses.

That said, even if I think the performance improvements are probably mostly due 
to architectural changes they also made. It shouldn't come as a surprise that 
Java would be faster than Clojure in most cases. I don't want to make false 
pretenses. Clojure and Java are not equal in semantics, and Java's mutable, 
eager and object grouped methods semantics are almost always going to be more 
performant. Clojure makes a trade offs of performance and memory for simplicity.

When people say Clojure can match Java in performance, it almost always implies 
using escape hatches and changing the semantics back to imperative code. The 
good news though, when you use Clojure's semantics, you benefit in simplicity 
and the performance impact is marginal, so it is still fast enough for almost 
all use cases.

Now, back to type annotations. I really don't think Storm 2.0 performance 
improvements were due to usage of reflection that hadn't been addressed from 
Clojure. But who knows.

Do the framework you're talking about do static analysis of the types? Because 
generic types are erased at runtime, so there wouldn't ever be a way for proxy 
to set them in.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/5a4ad6dc-922a-42ff-b058-faaa94219553%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Java Interop on steroids?

[Chris Nuernberger]

Nathan,

For the subset of problems for which clojure has insufficient power to 
optimize well, I think a good percentage of those would be best off solved 
by numeric languages like numpy  
or a numeric compiler like TVM  as 
this gives you a pathway to much more scalability and performance in the 
end.  In short, they aren't best solved by Java either but best solved via 
translation to, execution in, and then translation back from a numeric 
form.  Aided by 4 years of understanding the problem this sort of 
transformation should definitely be possible.
​
As for being able to contribute without knowing clojure I think this will 
probably overall lead to an ossification of design over time but the larger 
set of involved people is definitely a great thing in and of itself.  
Potentially the audience for Storm is mainly other jvm languages.

The best person I found who learned clojure fast was already very good at 
python and used Koans . I think it should be 
reasonable to stay within some of the extent of the language described in 
things like the Koans for the majority of the codebase and still provide a 
pathway for new people.

That's a lot of thinking for a weekend :-).  Thanks for the post it was 
interesting!

Chris
​

On Friday, June 21, 2019 at 5:18:06 PM UTC-6, Nathan Fisher wrote:
>
> Storm recently moved away from Clojure in its core.
>
> https://storm.apache.org/2019/05/30/storm200-released.html
>
> I wonder how much of the legacy Clojure core could be optimised or if they 
> reached an upper limit imposed by the runtime/architecture. That being said 
> I suspect for 90% of orgs they'll never hit that boundary.
>
> On Fri, Jun 21, 2019 at 16:40, Chris Nuernberger  > wrote:
>
>> Sean, 
>>
>> That is an interesting blog post.  Sorry if I am not following everything 
>> but why not use the annotation support in gen-class for those types of 
>> things?
>>
>>
>> https://github.com/clojure/clojure/blob/8af7e9a92570eb28c58b15481ae9c271d891c028/test/clojure/test_clojure/genclass/examples.clj#L34
>>
>> On Friday, June 21, 2019 at 1:29:56 PM UTC-6, Sean Corfield wrote:
>>>
>>> You might be interested in how we provide type-based annotations on 
>>> Clojure functions so that tooling (in our case New Relic) sees those 
>>> annotations:
>>>
>>>  
>>>
>>>
>>> https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/
>>>
>>>  
>>>
>>> I agree that this could be a lot easier.
>>>
>>>  
>>>
>>> Sean Corfield -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "If you're not annoying somebody, you're not really alive."
>>> -- Margaret Atwood
>>>
>>>  
>>> --
>>> *From:* clo...@googlegroups.com  on behalf of 
>>> eglue 
>>> *Sent:* Thursday, June 20, 2019 9:03:45 PM
>>> *To:* Clojure
>>> *Subject:* Java Interop on steroids? 
>>>  
>>> Don't get me wrong, I'm as much against types as the next R̶i̶c̶h̶ 
>>> ̶H̶i̶c̶k̶e̶y̶  guy. 
>>>
>>> However -- there are many popular Java frameworks that love to reflect 
>>> on their annotations and their generic type signatures.
>>>
>>> To name a heavyweight: Spring. But also, of late: big data frameworks, 
>>> many written in Java, love reflecting on generic type signatures. My org is 
>>> looking at Beam and Flink, for example.
>>>
>>> These frameworks use types not for the static checking really but as 
>>> parameters governing their own dynamic behavior. For example, Spring will 
>>> use types at runtime to simply match objects to where they should be 
>>> dynamically injected. Beam will look at your type signatures and do runtime 
>>> validations to ensure it can process things appropriately. Of course this 
>>> is unfortunate, using types this way, when it is all really just data. 
>>> Clojure does -- or would do -- it better, simpler, directer, and all of 
>>> that.
>>>
>>> Yet we would like to leverage these frameworks. Or rather, we must for 
>>> various pragmatic and business reasons.
>>>
>>> And any time we need to "communicate" to these frameworks "through" 
>>> their desired fashion of generic types and annotations, we can, of course, 
>>> create the appropriate .java files to represent what is needed (and then do 
>>> the invocation back to Clojure via IFn.invoke or Compiler.eval, etc). Yes, 
>>> this works.
>>>
>>> However this is quite tedious because in these frameworks I mentioned 
>>> you end up having to create these Java files quite a bit. For example, when 
>>> expressing a streaming data pipeline to Beam, you may specify multiple 
>>> transforms, each a function with its own type signature.
>>>
>>> A little searching and it seems Clojure has shied away from generating 
>>> generic type information in places where it could offer this capability. 
>>>
>>> For example, in `proxy` ... or I suppose also in `gen-class`, `reify`, 
>>> and other dynamic bytecode generation fea

Re: Java Interop on steroids?

[Aaron Dixon]

That is likely more to do with doing a full rewrite with 5+ years of
learned experience under their belt than any insurmountable performance
issue by Clojure.

(Storm was mostly Clojure from day one but always had Java code in the mix,
as well; in other words, they've always had Java if they had needed it...
so crediting their perf gains to the PL switch is suspect imo.)

On Sat, Jun 22, 2019 at 2:48 PM Nathan Fisher 
wrote:

> They did cite a significant performance boost as a side effect.
>
> On Fri, Jun 21, 2019 at 21:04, Sean Corfield  wrote:
>
>> I got the impression this was the primary reason for Storm’s rewrite:
>>
>>
>>
>> While Storm's Clojure implementation served it well for many years, it
>> was often cited as a barrier for entry to new contributors. Storm's
>> codebase is now more accessible to developers who don't want to learn
>> Clojure in order to contribute.
>>
>>
>>
>> Sean Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>
>> --
>> *From:* clojure@googlegroups.com  on behalf of
>> Nathan Fisher 
>> *Sent:* Friday, June 21, 2019 4:17:43 PM
>> *To:* clojure@googlegroups.com
>> *Subject:* Re: Java Interop on steroids?
>>
>> Storm recently moved away from Clojure in its core.
>>
>> https://storm.apache.org/2019/05/30/storm200-released.html
>>
>> I wonder how much of the legacy Clojure core could be optimised or if
>> they reached an upper limit imposed by the runtime/architecture. That being
>> said I suspect for 90% of orgs they'll never hit that boundary.
>>
>> On Fri, Jun 21, 2019 at 16:40, Chris Nuernberger 
>> wrote:
>>
>>> Sean,
>>>
>>> That is an interesting blog post.  Sorry if I am not following
>>> everything but why not use the annotation support in gen-class for those
>>> types of things?
>>>
>>>
>>> https://github.com/clojure/clojure/blob/8af7e9a92570eb28c58b15481ae9c271d891c028/test/clojure/test_clojure/genclass/examples.clj#L34
>>>
>>> On Friday, June 21, 2019 at 1:29:56 PM UTC-6, Sean Corfield wrote:

 You might be interested in how we provide type-based annotations on
 Clojure functions so that tooling (in our case New Relic) sees those
 annotations:




 https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/



 I agree that this could be a lot easier.



 Sean Corfield -- (904) 302-SEAN
 An Architect's View -- http://corfield.org/

 "If you're not annoying somebody, you're not really alive."
 -- Margaret Atwood


 --
 *From:* clo...@googlegroups.com  on behalf of
 eglue 
 *Sent:* Thursday, June 20, 2019 9:03:45 PM
 *To:* Clojure
 *Subject:* Java Interop on steroids?

 Don't get me wrong, I'm as much against types as the next R̶i̶c̶h̶
 ̶H̶i̶c̶k̶e̶y̶  guy.

 However -- there are many popular Java frameworks that love to reflect
 on their annotations and their generic type signatures.

 To name a heavyweight: Spring. But also, of late: big data frameworks,
 many written in Java, love reflecting on generic type signatures. My org is
 looking at Beam and Flink, for example.

 These frameworks use types not for the static checking really but as
 parameters governing their own dynamic behavior. For example, Spring will
 use types at runtime to simply match objects to where they should be
 dynamically injected. Beam will look at your type signatures and do runtime
 validations to ensure it can process things appropriately. Of course this
 is unfortunate, using types this way, when it is all really just data.
 Clojure does -- or would do -- it better, simpler, directer, and all of
 that.

 Yet we would like to leverage these frameworks. Or rather, we must for
 various pragmatic and business reasons.

 And any time we need to "communicate" to these frameworks "through"
 their desired fashion of generic types and annotations, we can, of course,
 create the appropriate .java files to represent what is needed (and then do
 the invocation back to Clojure via IFn.invoke or Compiler.eval, etc). Yes,
 this works.

 However this is quite tedious because in these frameworks I mentioned
 you end up having to create these Java files quite a bit. For example, when
 expressing a streaming data pipeline to Beam, you may specify multiple
 transforms, each a function with its own type signature.

 A little searching and it seems Clojure has shied away from generating
 generic type information in places where it could offer this capability.

 For example, in `proxy` ... or I suppose also in `gen-class`, `reify`,
 and other dynamic bytecode generation features of Clojure.

 However it seems to me that `proxy` (and these othe

Re: Java Interop on steroids?

[Nathan Fisher]

They did cite a significant performance boost as a side effect.

On Fri, Jun 21, 2019 at 21:04, Sean Corfield  wrote:

> I got the impression this was the primary reason for Storm’s rewrite:
>
>
>
> While Storm's Clojure implementation served it well for many years, it was
> often cited as a barrier for entry to new contributors. Storm's codebase is
> now more accessible to developers who don't want to learn Clojure in order
> to contribute.
>
>
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
> --
> *From:* clojure@googlegroups.com  on behalf of
> Nathan Fisher 
> *Sent:* Friday, June 21, 2019 4:17:43 PM
> *To:* clojure@googlegroups.com
> *Subject:* Re: Java Interop on steroids?
>
> Storm recently moved away from Clojure in its core.
>
> https://storm.apache.org/2019/05/30/storm200-released.html
>
> I wonder how much of the legacy Clojure core could be optimised or if they
> reached an upper limit imposed by the runtime/architecture. That being said
> I suspect for 90% of orgs they'll never hit that boundary.
>
> On Fri, Jun 21, 2019 at 16:40, Chris Nuernberger 
> wrote:
>
>> Sean,
>>
>> That is an interesting blog post.  Sorry if I am not following everything
>> but why not use the annotation support in gen-class for those types of
>> things?
>>
>>
>> https://github.com/clojure/clojure/blob/8af7e9a92570eb28c58b15481ae9c271d891c028/test/clojure/test_clojure/genclass/examples.clj#L34
>>
>> On Friday, June 21, 2019 at 1:29:56 PM UTC-6, Sean Corfield wrote:
>>>
>>> You might be interested in how we provide type-based annotations on
>>> Clojure functions so that tooling (in our case New Relic) sees those
>>> annotations:
>>>
>>>
>>>
>>>
>>> https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/
>>>
>>>
>>>
>>> I agree that this could be a lot easier.
>>>
>>>
>>>
>>> Sean Corfield -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "If you're not annoying somebody, you're not really alive."
>>> -- Margaret Atwood
>>>
>>>
>>> --
>>> *From:* clo...@googlegroups.com  on behalf of
>>> eglue 
>>> *Sent:* Thursday, June 20, 2019 9:03:45 PM
>>> *To:* Clojure
>>> *Subject:* Java Interop on steroids?
>>>
>>> Don't get me wrong, I'm as much against types as the next R̶i̶c̶h̶
>>> ̶H̶i̶c̶k̶e̶y̶  guy.
>>>
>>> However -- there are many popular Java frameworks that love to reflect
>>> on their annotations and their generic type signatures.
>>>
>>> To name a heavyweight: Spring. But also, of late: big data frameworks,
>>> many written in Java, love reflecting on generic type signatures. My org is
>>> looking at Beam and Flink, for example.
>>>
>>> These frameworks use types not for the static checking really but as
>>> parameters governing their own dynamic behavior. For example, Spring will
>>> use types at runtime to simply match objects to where they should be
>>> dynamically injected. Beam will look at your type signatures and do runtime
>>> validations to ensure it can process things appropriately. Of course this
>>> is unfortunate, using types this way, when it is all really just data.
>>> Clojure does -- or would do -- it better, simpler, directer, and all of
>>> that.
>>>
>>> Yet we would like to leverage these frameworks. Or rather, we must for
>>> various pragmatic and business reasons.
>>>
>>> And any time we need to "communicate" to these frameworks "through"
>>> their desired fashion of generic types and annotations, we can, of course,
>>> create the appropriate .java files to represent what is needed (and then do
>>> the invocation back to Clojure via IFn.invoke or Compiler.eval, etc). Yes,
>>> this works.
>>>
>>> However this is quite tedious because in these frameworks I mentioned
>>> you end up having to create these Java files quite a bit. For example, when
>>> expressing a streaming data pipeline to Beam, you may specify multiple
>>> transforms, each a function with its own type signature.
>>>
>>> A little searching and it seems Clojure has shied away from generating
>>> generic type information in places where it could offer this capability.
>>>
>>> For example, in `proxy` ... or I suppose also in `gen-class`, `reify`,
>>> and other dynamic bytecode generation features of Clojure.
>>>
>>> However it seems to me that `proxy` (and these others) could allow one
>>> to pass in a representation of desired type arguments, annotations, etc.
>>> and then we could remain in Clojure to interop with these popular
>>> frameworks.
>>>
>>> I respect Clojure's efforts to keep its core small and wait for worthy
>>> features to prove themselves.
>>>
>>> So my question is not when is Clojure going to do this, but rather:
>>>
>>> Are there any precedents in the community for someone building out the
>>> kind of richer Java interop that I'm nodding toward here?
>>>
>>> For example, does anyone know o

Re: Shorter form to check if some words are contained in a sentence?

[Andy Fingerhut]

No tip or payment needed for me.  If at some point you desperately want to
toss some money to someone for Clojure, one possibility is to make periodic
small payments to Cognitect Labs, which also gives you access to a tool
called REBL that you may find useful at some point if you continue using
Clojure for development: https://www.patreon.com/cognitect/posts

The syntax #(.contains value %) creates an anonymous function that takes
one argument, and the % represents where the argument is used in the
function body.

If it makes more sense, you can replace it with (fn [x] (.contains value
x)), which will do the same thing.

Yes, every? and some are similar to each other, with every? doing the AND
of all individual function calls on the elements in the sequence, and some
doing the OR, and not only doing the OR, but also returning the value of
the first call that returns a logical true value (anything except nil or
false).

There are Clojurians Slack and ZulipChat chat channels called #beginners
that are also useful for getting started problems.

Andy


On Sat, Jun 22, 2019 at 11:41 AM Thad Guidry  wrote:

> Beautiful Andy!  Can you confirm that last syntax for me?
> I see it as treating the anonymous function of #(.contains value %) as the
> predicate to check on every member of the vector?
> But anonymous function expansion is what throws me off... I need layman's
> terms (grandma speak) to break down the logic there.  Specifically, there
> must be some wiring of the vector members to the % placeholder?
> Ahhh! I guess that what does that actual wiring is the every? function ...
> "for every x in coll"
> So this is just a simple every? invocation I guess.
> And I assume that some would
> be like an or/coalesce, kinda in my usecase ?
> (some #(.contains value %) ["CBS" "Bar" "cat"])
>
> It worked by the way. See screenshot attached.
>
> Still learning a few ropes on Clojure  (and I still can't get the stupid
> nrepl to initialize in my Visual Studio Code with leiningen
>   so
> that doesn't help my learning when I don't have a real dev environment that
> I can learn Clojure against.  Would love someone to help me with that)
>
> Finally, how can I send you a tip or payment for this help?
> Thad
> https://www.linkedin.com/in/thadguidry/
>
>
> On Sat, Jun 22, 2019 at 12:38 PM Andy Fingerhut 
> wrote:
>
>> And, of course you can continue to use .contains:
>>
>> (every? #(.contains value %) ["CBS" "Bar" "cat"])
>>
>>
>>
>> On Sat, Jun 22, 2019 at 10:37 AM Andy Fingerhut 
>> wrote:
>>
>>> I haven't counted characters, but this would certainly become relatively
>>> shorter the more substrings you check for.  It is shown in the context of a
>>> Clojure REPL.  I do not know whether OpenRefine might already do the
>>> require for you, or perhaps even (use 'clojure.string).
>>>
>>> user=> (def value "Bar the cat from CBS")
>>> #'user/value
>>> user=> (require '[clojure.string :as str])
>>> nil
>>> user=> (every? #(str/includes? value %) ["CBS" "Bar" "cat"])
>>> true
>>>
>>> Andy
>>>
>>>
>>> On Sat, Jun 22, 2019 at 10:32 AM Thad Guidry 
>>> wrote:
>>>
 Clojure is supported as an expression language in OpenRefine.  Where
 any cells value in OpenRefine's datagrid is just accessed by the name
 value.
 Here's one of my cells value in OpenRefine...

 "001","878","245","$c","CBS Barmarick Publications,","$c","Emerald"

 and I am trying to see if that cells value contains all of these
 words...

 (and (.contains value "CBS") (.contains value "Bar") (.contains value
 "cat"))

 It works, but I am looking to Clojure experts to find out how to
 shorten this expression?

 -Thad

 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/clojure/c37eb1b0-1557-486b-b95a-a5bc53b67b24%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, se

Re: Shorter form to check if some words are contained in a sentence?

[Thad Guidry]

Beautiful Andy!  Can you confirm that last syntax for me?
I see it as treating the anonymous function of #(.contains value %) as the
predicate to check on every member of the vector?
But anonymous function expansion is what throws me off... I need layman's
terms (grandma speak) to break down the logic there.  Specifically, there
must be some wiring of the vector members to the % placeholder?
Ahhh! I guess that what does that actual wiring is the every? function ... "for
every x in coll"
So this is just a simple every? invocation I guess.
And I assume that some would be
like an or/coalesce, kinda in my usecase ?
(some #(.contains value %) ["CBS" "Bar" "cat"])

It worked by the way. See screenshot attached.

Still learning a few ropes on Clojure  (and I still can't get the stupid
nrepl to initialize in my Visual Studio Code with leiningen
  so that
doesn't help my learning when I don't have a real dev environment that I
can learn Clojure against.  Would love someone to help me with that)

Finally, how can I send you a tip or payment for this help?
Thad
https://www.linkedin.com/in/thadguidry/


On Sat, Jun 22, 2019 at 12:38 PM Andy Fingerhut 
wrote:

> And, of course you can continue to use .contains:
>
> (every? #(.contains value %) ["CBS" "Bar" "cat"])
>
>
>
> On Sat, Jun 22, 2019 at 10:37 AM Andy Fingerhut 
> wrote:
>
>> I haven't counted characters, but this would certainly become relatively
>> shorter the more substrings you check for.  It is shown in the context of a
>> Clojure REPL.  I do not know whether OpenRefine might already do the
>> require for you, or perhaps even (use 'clojure.string).
>>
>> user=> (def value "Bar the cat from CBS")
>> #'user/value
>> user=> (require '[clojure.string :as str])
>> nil
>> user=> (every? #(str/includes? value %) ["CBS" "Bar" "cat"])
>> true
>>
>> Andy
>>
>>
>> On Sat, Jun 22, 2019 at 10:32 AM Thad Guidry 
>> wrote:
>>
>>> Clojure is supported as an expression language in OpenRefine.  Where any
>>> cells value in OpenRefine's datagrid is just accessed by the name value.
>>> Here's one of my cells value in OpenRefine...
>>>
>>> "001","878","245","$c","CBS Barmarick Publications,","$c","Emerald"
>>>
>>> and I am trying to see if that cells value contains all of these words...
>>>
>>> (and (.contains value "CBS") (.contains value "Bar") (.contains value
>>> "cat"))
>>>
>>> It works, but I am looking to Clojure experts to find out how to
>>> shorten this expression?
>>>
>>> -Thad
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/clojure/c37eb1b0-1557-486b-b95a-a5bc53b67b24%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAKvLtDZxWM49qu-CCt-Lzn%3DCiQq%3DQy9MeY0kWV0tP4eHJknVbA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For mo

Re: Shorter form to check if some words are contained in a sentence?

[Andy Fingerhut]

And, of course you can continue to use .contains:

(every? #(.contains value %) ["CBS" "Bar" "cat"])



On Sat, Jun 22, 2019 at 10:37 AM Andy Fingerhut 
wrote:

> I haven't counted characters, but this would certainly become relatively
> shorter the more substrings you check for.  It is shown in the context of a
> Clojure REPL.  I do not know whether OpenRefine might already do the
> require for you, or perhaps even (use 'clojure.string).
>
> user=> (def value "Bar the cat from CBS")
> #'user/value
> user=> (require '[clojure.string :as str])
> nil
> user=> (every? #(str/includes? value %) ["CBS" "Bar" "cat"])
> true
>
> Andy
>
>
> On Sat, Jun 22, 2019 at 10:32 AM Thad Guidry  wrote:
>
>> Clojure is supported as an expression language in OpenRefine.  Where any
>> cells value in OpenRefine's datagrid is just accessed by the name value.
>> Here's one of my cells value in OpenRefine...
>>
>> "001","878","245","$c","CBS Barmarick Publications,","$c","Emerald"
>>
>> and I am trying to see if that cells value contains all of these words...
>>
>> (and (.contains value "CBS") (.contains value "Bar") (.contains value
>> "cat"))
>>
>> It works, but I am looking to Clojure experts to find out how to shorten
>> this expression?
>>
>> -Thad
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/clojure/c37eb1b0-1557-486b-b95a-a5bc53b67b24%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAKvLtDZxWM49qu-CCt-Lzn%3DCiQq%3DQy9MeY0kWV0tP4eHJknVbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shorter form to check if some words are contained in a sentence?

[Andy Fingerhut]

I haven't counted characters, but this would certainly become relatively
shorter the more substrings you check for.  It is shown in the context of a
Clojure REPL.  I do not know whether OpenRefine might already do the
require for you, or perhaps even (use 'clojure.string).

user=> (def value "Bar the cat from CBS")
#'user/value
user=> (require '[clojure.string :as str])
nil
user=> (every? #(str/includes? value %) ["CBS" "Bar" "cat"])
true

Andy


On Sat, Jun 22, 2019 at 10:32 AM Thad Guidry  wrote:

> Clojure is supported as an expression language in OpenRefine.  Where any
> cells value in OpenRefine's datagrid is just accessed by the name value.
> Here's one of my cells value in OpenRefine...
>
> "001","878","245","$c","CBS Barmarick Publications,","$c","Emerald"
>
> and I am trying to see if that cells value contains all of these words...
>
> (and (.contains value "CBS") (.contains value "Bar") (.contains value
> "cat"))
>
> It works, but I am looking to Clojure experts to find out how to shorten
> this expression?
>
> -Thad
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/c37eb1b0-1557-486b-b95a-a5bc53b67b24%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAKvLtDa49XSNFjsA53ou7hcMmMnLeyKe94p_fHR%2BdbGxVA6kzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Shorter form to check if some words are contained in a sentence?

[Thad Guidry]

Clojure is supported as an expression language in OpenRefine.  Where any 
cells value in OpenRefine's datagrid is just accessed by the name value.
Here's one of my cells value in OpenRefine...

"001","878","245","$c","CBS Barmarick Publications,","$c","Emerald"

and I am trying to see if that cells value contains all of these words...

(and (.contains value "CBS") (.contains value "Bar") (.contains value 
"cat"))

It works, but I am looking to Clojure experts to find out how to shorten 
this expression?

-Thad

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/c37eb1b0-1557-486b-b95a-a5bc53b67b24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Java Interop on steroids?

[atdixon]

Here is my problem, distilled. This code should tell the full story:

static class Apple {}

Apple a = new Apple() {};

Type[] x = ((ParameterizedType)a.getClass().getGenericSuperclass())
.getActualTypeArguments();

// x is a Type array containing String, Integer

HOWEVER, via Clojure `proxy`, I don't have a way to tell it which type 
arguments to use--

(proxy [Apple [String Integer]] []) ;; something like this is not supported

Certain frameworks, however, consult these type arguments to govern their 
own dynamic behavior.

Having Clojure's proxy support specifying type arguments would allow for 
this not uncommon Java interop need.

On Saturday, June 22, 2019 at 5:38:36 AM UTC-5, Matching Socks wrote:
>
> By "generic type information", you mean the X in List ?
>
>
> On Friday, June 21, 2019 at 12:03:46 AM UTC-4, atdixon wrote:
>>
>> However -- there are many popular Java frameworks that love to reflect on 
>> their annotations and their generic type signatures.
>>
>> To name a heavyweight: Spring. But also, of late: big data frameworks, 
>> many written in Java, love reflecting on generic type signatures. My org is 
>> looking at Beam and Flink, for example.
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/8c5ae6a3-2626-47ed-9439-adbab9dec469%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Java Interop on steroids?

[atdixon]

Here is my problem, distilled. This code should tell the full story:

static class Apple {}

Apple a = new Apple() {};

Type[] x = ((ParameterizedType)a.getClass().getGenericSuperclass())
.getActualTypeArguments();

// x is a Type array containing String, String

HOWEVER, via Clojure `proxy`, I don't have a way to tell it which type 
arguments to use--

(proxy [Apple [String Integer]] []) ;; something like this is not supported

Certain frameworks, however, consult these type arguments to govern their 
own dynamic behavior.

Having Clojure's proxy support specifying type arguments would allow for 
this not uncommon Java interop need.



On Saturday, June 22, 2019 at 5:38:36 AM UTC-5, Matching Socks wrote:
>
> By "generic type information", you mean the X in List ?
>
>
> On Friday, June 21, 2019 at 12:03:46 AM UTC-4, atdixon wrote:
>>
>> However -- there are many popular Java frameworks that love to reflect on 
>> their annotations and their generic type signatures.
>>
>> To name a heavyweight: Spring. But also, of late: big data frameworks, 
>> many written in Java, love reflecting on generic type signatures. My org is 
>> looking at Beam and Flink, for example.
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/b4fb12fe-6dc6-47a5-a271-f453941fcb2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Java Interop on steroids?

[Matching Socks]

By "generic type information", you mean the X in List ?


On Friday, June 21, 2019 at 12:03:46 AM UTC-4, atdixon wrote:
>
> However -- there are many popular Java frameworks that love to reflect on 
> their annotations and their generic type signatures.
>
> To name a heavyweight: Spring. But also, of late: big data frameworks, 
> many written in Java, love reflecting on generic type signatures. My org is 
> looking at Beam and Flink, for example.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/8fd67aff-8229-4588-9b2b-c07df8f5f055%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.