Re: [ANN and RFC] Bifurcan: impure functional data strucures

[Mikera]

Looks cool! I'm going to mine this for ideas and potentially use it. FWIW 
I've also been implementing some Java functional data structures for my 
language design experiments. 

If anyone is interested happy to share code, my own motivations were:
- I wanted decent persistent Lists, Sets, Maps for language experiments 
without pulling in the whole of Clojure as a dependency
- I care about some operations that are not very efficient in Clojure 
(sublists and concatenation especially)
- It's actually quite a fun challenge writing functional data structures

I have the same annoyance that it isn't easy to play nicely with Clojure 
code unless you implement the Clojure interfaces (IPersistentVector etc.). 
It would be nice if Clojure used protocols so you could extend 
interoperability to arbitrary types, but I can't see any way that is going 
to happen and it probably isn't a good idea overall for performance 
reasons. 

So I agree the practical way forward would be to write Clojure "wrappers" 
that extend IPersistentVector etc. if you want to use bifurcan in Clojure.



On Tuesday, 28 March 2017 00:51:46 UTC+8, Zach Tellman wrote:
>
> This is a slightly irregular announcement, because it's not for a Clojure 
> library.  Rather, it's for a library written purely in Java: 
> https://github.com/lacuna/bifurcan.
>
> This is a collection of mutable and immutable data structures, designed to 
> address some of my personal frustrations with what's available in the 
> Clojure and Java ecosystems.  Notably, they have pluggable equality 
> semantics, so while they *can* use Clojure's expensive hash and equality 
> checks, they don't *have* to.  They also provide high-performance mutable 
> variants of the data structure which share an API with their immutable 
> cousins.  
>
> I'm posting it here to ask for people's thoughts on how, if at all, this 
> should be exposed as a Clojure library.  It would be simple to simply wrap 
> them in the Clojure interfaces and make them behave identically to 
> Clojure's own data structures, but that kind of obviates the point. 
>  However, creating an entirely new set of accessors means that we can't 
> leverage Clojure's standard library.
>
> It's possible that I'm alone in my frustrations, and no Clojure wrapper is 
> necessary.  But if this does solve a problem you have, I'd like to hear 
> more about what it is, and how you think Bifurcan might help.  Please feel 
> free to reply here, or to grab me at Clojure/West and talk about it there.
>
> Thanks in advance,
> Zach
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Gregg Reynolds]

On Apr 18, 2017 2:16 PM, "Jason Basanese"  wrote:

Thanks, I have been told this before. After hearing it a couple more times
I am taking it much closer to heart.


also check-out #jobs-discuss on the clojurians slack thing.  this kind of
question would be welcome there, i think.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Jason Basanese]

Thanks, I have been told this before. After hearing it a couple more times 
I am taking it much closer to heart.

On Sunday, March 26, 2017 at 7:28:08 PM UTC-4, Gregg Reynolds wrote:
>
>
>
> On Mar 23, 2017 12:10 PM, "Jason Basanese"  > wrote:
>
> Attached is a fairly bad resume that I am using. Any tips on how I might 
> change it to appeal to more places that are looking for functional 
> developers?
>
>
> nobody ever gets hired on the strength of their resume. at best they get 
> an interview. almost every hire for an interesting job comes from personal 
> connection. forget your resume and start networking, contributing to os 
> projects, wtc.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Jason Basanese]

Hmm. I never really considered anyone would try to use them outside of just 
looking at the source code. You have made me second guess that. I 
definitely will consider adding ReadMes. Also thanks for the link.

On Friday, March 24, 2017 at 12:36:36 AM UTC-4, James Gatannah wrote:
>
> To get back on-target, I think you should highlight 1 or maybe 2 of your 
> github repos and go flesh them out.
>
> I had high hopes for both click-time-fun and cljs-game, but wasn't sure 
> what to try or where to start. Working demos are pretty magical, and, 
> honestly, incredibly rare.
>
> https://github.com/noffle/art-of-readme 
> 
>  
> has some advice that I've been planning to take to heart for a while now 
> about how to help other people understand what your projects are about.
>
> That probably won't help your resume get through the original HR screen, 
> but it can definitely make interviewers stand up and take notice.
>
> Good luck,
> James
>
>
> On Thursday, March 23, 2017 at 12:10:30 PM UTC-5, Jason Basanese wrote:
>>
>> Attached is a fairly bad resume that I am using. Any tips on how I might 
>> change it to appeal to more places that are looking for functional 
>> developers?
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Jason Basanese]

*He sent us a bill for an hour of consulting. *Wow, noted. Maybe I would be 
more hesitant to give questions directly related to the job if I ever found 
myself interviewing.

On Friday, March 24, 2017 at 12:17:14 AM UTC-4, James Gatannah wrote:
>
>
>
> On Thursday, March 23, 2017 at 2:00:28 PM UTC-5, puzzler wrote:
>>
>> On Thu, Mar 23, 2017 at 11:24 AM, Luke Burton  wrote:
>>
>  
>
>> Insightful post about a lot of things related to hiring, but I have to 
>> take exception with this very last point.  Recently, a friend of mine 
>> sought out a data science position in the Seattle area.  Each prospective 
>> employer gave him a take-home assignment that required 30-40 work hours to 
>> complete.  Some of the assignments were real problems the company was 
>> facing, so he was effectively being asked to do free consulting work for 
>> each company.  This is a horrible, burdensome interview practice and it 
>> would be dreadful if it became the norm in the software industry. 
>> Suggesting that someone offer to do a take-home project may make sense in 
>> specific cases for an inexperienced candidate, but I fear it starts our 
>> industry down the slippery slope.
>>
>
> It's not quite on-topic, since this is a post-resume story.
>
> But once upon a time I worked at a company where a fairly senior candidate 
> was asked about whatever real-world problem the interviewer was working on 
> at the time. I think it was a relaxed "So, how would you approach this 
> particular scenario?" big-picture kind of question.
>
> We didn't hire him.
>
> He sent us a bill for an hour of consulting.
>
> The legal department told us to pay it and never, ever, under any 
> circumstances, ask any question that could be remotely construed as 
> relevant to our actual business needs.
>
> Personally, I enjoy the little "Spend a couple of hours knocking this out" 
> challenges, as long as I don't get graded on criteria that wasn't mentioned 
> up front ("Our internal style guide, which you've never seen, dictates that 
> you must do X"). But I'm at the point where I'd rather point people to 
> github so we can talk about real projects that actually have serious 
> time/thought investments.
>
> And, on the flip side, I'd rather look at what a candidate's done there, 
> even if it does take more time/effort on the hiring side than seeing how 
> they approach a cookie-cutter project.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Jason Basanese]

I might think that 30-40 hours for a sample is excessive. Honestly many 
candidates worry and or prepare for at least two hours for an interview. 
Then have around an hour round trip. They also might spend a full hour in 
an interview. With about four hours to replace or supplement an interview 
you are getting much better results for the same time cost. Maybe even less 
stress for the applicant.

On Thursday, March 23, 2017 at 3:00:28 PM UTC-4, puzzler wrote:
>
> On Thu, Mar 23, 2017 at 11:24 AM, Luke Burton  > wrote:
>
>>
>> * So … if I was in your position, knowing what I know now, if I couldn't 
>> find companies that had very progressive hiring practices, I would make my 
>> resume stand out by leading in with an offer to spend a few hours writing a 
>> small implementation of anything the hiring manager would like me to write. 
>> Many hiring mangers are scared by take home projects because they're afraid 
>> of what the best candidate will think. "It's an insult to experienced 
>> candidates!" or "how would a rockstar candidate possibly spare the time?" 
>> But secretly I think all hiring mangers *really* want to know what it will 
>> be like to have you write code on their behalf. It's just not the industry 
>> norm to ask.
>>
>
> Insightful post about a lot of things related to hiring, but I have to 
> take exception with this very last point.  Recently, a friend of mine 
> sought out a data science position in the Seattle area.  Each prospective 
> employer gave him a take-home assignment that required 30-40 work hours to 
> complete.  Some of the assignments were real problems the company was 
> facing, so he was effectively being asked to do free consulting work for 
> each company.  This is a horrible, burdensome interview practice and it 
> would be dreadful if it became the norm in the software industry. 
> Suggesting that someone offer to do a take-home project may make sense in 
> specific cases for an inexperienced candidate, but I fear it starts our 
> industry down the slippery slope.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Jason Basanese]

*Getting involved in collaborative open source development (i.e. 
contributing to established projects) is likely to increase your 
confidence, as well as that of a prospective employer.* This is a good 
point I see echoed in a few other posts. Thanks for the tip. 

In my case and I imagine in the case of many curious younger developers we 
do not have strong enough opinions nor preferences for this yet; 
*I would consider including only the technologies I had interest in working 
with professionally.*
On Thursday, March 23, 2017 at 1:54:25 PM UTC-4, Moe Aboulkheir wrote:
>
> Jason,
>
> If it were my resumé, I would consider including only the technologies I 
> had interest in working with professionally.  Getting involved in 
> collaborative open source development (i.e. contributing to established 
> projects) is likely to increase your confidence, as well as that of a 
> prospective employer - you could consider shunting off the coursework 
> details (or listing those as "Interests", if they're interests) if you had 
> some voluntary development to put in its place.  Other ways to fill out 
> space while improving content would be to include a generic (i.e. not 
> job-specific) introduction beneath the heading, or using complete sentences 
> for the job description at the bottom.  If you go with bullet points, using 
> a list indicator might make this clearer.
>
> As far as visual feedback: it might scan better if the section headings in 
> the left column were kept to single words (i.e. no line breaks), and were 
> vertically justified with the top of corresponding piece of text in the 
> adjacent column (using a table with invisible borders).  The alignment of 
> the info icons (which are a good call) is off in a similar way, and that 
> block does not appear horizontally centred to me.  Some colour variation 
> may help also - examples would be converting the urls into links (with the 
> url as the link text, for printing), or using a dark shade of grey for 
> heading or title text.
>
> Take care,
> Moe
>
> On Thu, Mar 23, 2017 at 5:10 PM, Jason Basanese  > wrote:
>
>> Attached is a fairly bad resume that I am using. Any tips on how I might 
>> change it to appeal to more places that are looking for functional 
>> developers?
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Jason Basanese]

I had never thought of a resume this way "The function of the resume is to 
motivate someone to look deeper" thanks.

On Thursday, March 23, 2017 at 1:16:41 PM UTC-4, Gary Trakhman wrote:
>
> I'd put examples of interesting (hard, nontrivial) projects you worked on 
> during your time, not just keywords.  The function of the resume is to 
> motivate someone to look deeper instead of throwing it out.  The function 
> of the top of the resume is to hook someone to read the rest of it.  What's 
> special about you?  You can pack a lot into a single page, I think yours 
> has a lot of whitespace.  Does your school have a resume workshop or 
> something like that?
>
> On Thu, Mar 23, 2017 at 1:10 PM Jason Basanese  > wrote:
>
>> Attached is a fairly bad resume that I am using. Any tips on how I might 
>> change it to appeal to more places that are looking for functional 
>> developers?
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Jason Basanese]

Thanks for the response Luke. You make a lot of good points. Thomas 
Ptacek's article was eye opening. The suggestion to ask the hiring manager 
if they would like a sample of me doing company related work for them is a 
good one. The networking tip is one I hear time and time again, but the 
more I hear it the more I believe it. Also thanks for being somewhat 
specific on what you mean when you say networking. Overall this post has 
helped me get a picture of what a good job search or rather network 
building looks like. Again thanks for taking the time to write this post.



On Thursday, March 23, 2017 at 2:24:34 PM UTC-4, Luke Burton wrote:
>
>
> On Mar 23, 2017, at 10:10 AM, Jason Basanese  > wrote:
>
> Attached is a fairly bad resume that I am using. Any tips on how I might 
> change it to appeal to more places that are looking for functional 
> developers?
>
>
> Couple of general tips … based on a few decades of looking at these things 
> :) Sorry about the length but I care a lot about hiring!
>
> * Redact your home address and phone number when you circulate it on the 
> open internet. I wouldn't even include that in a resume I sent to an 
> organization, personally.
>
> * Resumes are the worst. There's almost no correlation between "things the 
> candidate had on his/her resume" and "that candidate is performing really 
> well for us 2 years later", but we persist in using them because everything 
> else is a lot more work. Just keep that in mind before you think there's 
> something "wrong" with your resume.
>
> * Resumes should be considered a marketing document. A classic new grad 
> mistake is to think that what hiring mangers and recruiters are looking for 
> is a complete transcript and accurate information. What they're actually 
> looking for is purely subjective. I could tell you stories - resumes 
> skipped over for the dumbest of reasons. After looking through hundreds, 
> people start cutting corners or just plain discriminating. So, think of it 
> as serving roughly the same purpose as a blurb on the back of a paperback 
> novel.
>
> * To play along with the resume game, I recommend customizing your resume 
> to the greatest extent possible based on what you know about the job. 
> That's "the job" singular, as in you need to do this for each application. 
> It's easy to carpet bomb the same resume across many companies, but you 
> simply won't stand out. You are on the right track here already - what 
> would make it appealing to places looking for functional developers? Take 
> it a step further and find those places, then write something that 
> specifically targets them. Remember it's not just about keywords, you also 
> have to come across as someone who might fit the culture.
>
> * To avoid (or supplement) playing the resume game, build relationships. 
> Keep all your projects up on GitHub, find and cultivate 
>  things you want to stick at and 
> improve, and start getting to know people. Meetups, fixing issues on other 
> people's projects, it doesn't have to be super involved, it just has to be 
> an involvement. The absolute best jobs you will ever land will come from 
> people who know the quality of your work and recommend you from the inside. 
>
> * I am a huge fan of Thomas Ptacek's perspective on hiring 
> . Very much 
> worth your time to read. If you can find a company that asks candidates to 
> write some code - actual code like you'll be writing on the job, not a 
> graph traversal puzzle - then jump on that chance. I started applying these 
> techniques and we immediately experienced an inversion between who we 
> thought looked strong on paper and who ended up being a great engineering 
> fit for our team. This candidate we hired would have flunked the keyword 
> filter had we used one, they had not used a single technology in common use 
> for our team. Eye opening. 
>
> * So … if I was in your position, knowing what I know now, if I couldn't 
> find companies that had very progressive hiring practices, I would make my 
> resume stand out by leading in with an offer to spend a few hours writing a 
> small implementation of anything the hiring manager would like me to write. 
> Many hiring mangers are scared by take home projects because they're afraid 
> of what the best candidate will think. "It's an insult to experienced 
> candidates!" or "how would a rockstar candidate possibly spare the time?" 
> But secretly I think all hiring mangers *really* want to know what it will 
> be like to have you write code on their behalf. It's just not the industry 
> norm to ask.
>
> Hope this helps! Good luck …
>
> Luke.
>

-- 
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 

Re: [ANN and RFC] Bifurcan: impure functional data strucures

[Zach Tellman]

To be clear, my intention was always to wrap the implementations in the
appropriate Clojure interfaces, and I don't believe that will cause much,
if any, of a performance hit (inlining is magic).  However, there are some
real questions regarding how to expose non-standard equality semantics, and
whether transients should be represented using the immutable or mutable
collection variants.

For what it's worth, I have about 1/3 of an implementation of
Clojure-compatible versions of these data structures, I just wanted to mull
on the above questions a bit before going further.  I'm happy to discuss
them here in more depth if you have any questions or opinions.

Zach

On Tue, Apr 18, 2017 at 6:53 AM Dave Dixon  wrote:

> Stared at this a bit yesterday. Seems like if you want to leverage spec
> while using bifurcan, then the bifurcan types need to have the Clojure
> wrapper. The alternative appears to be re-implementing at least a large
> subset of collection-related spec code, which is a lot to bite off. Also
> tried updating some existing code to use bifurcan. Similar to spec, there
> are going to be cases which are less perf sensitive, where it would be nice
> to use code that is polymorphic for collections, and drop down to the fast
> interface in perf-sensitive parts.
>
>
> On Monday, April 17, 2017 at 1:52:39 PM UTC-7, Dave Dixon wrote:
>>
>> What is the issue with wrapping in Clojure interfaces? Added overhead of
>> function calls?
>>
>> I'm finding myself in the process of doing some of this, at least for
>> constructors. Also thinking of generating predicates/generators for use
>> with spec.
>>
>> On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote:
>>
>>> This is a slightly irregular announcement, because it's not for a
>>> Clojure library.  Rather, it's for a library written purely in Java:
>>> https://github.com/lacuna/bifurcan.
>>>
>>> This is a collection of mutable and immutable data structures, designed
>>> to address some of my personal frustrations with what's available in the
>>> Clojure and Java ecosystems.  Notably, they have pluggable equality
>>> semantics, so while they *can* use Clojure's expensive hash and equality
>>> checks, they don't *have* to.  They also provide high-performance mutable
>>> variants of the data structure which share an API with their immutable
>>> cousins.
>>>
>>> I'm posting it here to ask for people's thoughts on how, if at all, this
>>> should be exposed as a Clojure library.  It would be simple to simply wrap
>>> them in the Clojure interfaces and make them behave identically to
>>> Clojure's own data structures, but that kind of obviates the point.
>>> However, creating an entirely new set of accessors means that we can't
>>> leverage Clojure's standard library.
>>>
>>> It's possible that I'm alone in my frustrations, and no Clojure wrapper
>>> is necessary.  But if this does solve a problem you have, I'd like to hear
>>> more about what it is, and how you think Bifurcan might help.  Please feel
>>> free to reply here, or to grab me at Clojure/West and talk about it there.
>>>
>>> Thanks in advance,
>>> Zach
>>>
>> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/1m_I7IrDGb0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN and RFC] Bifurcan: impure functional data strucures

[Dave Dixon]

Stared at this a bit yesterday. Seems like if you want to leverage spec 
while using bifurcan, then the bifurcan types need to have the Clojure 
wrapper. The alternative appears to be re-implementing at least a large 
subset of collection-related spec code, which is a lot to bite off. Also 
tried updating some existing code to use bifurcan. Similar to spec, there 
are going to be cases which are less perf sensitive, where it would be nice 
to use code that is polymorphic for collections, and drop down to the fast 
interface in perf-sensitive parts.

On Monday, April 17, 2017 at 1:52:39 PM UTC-7, Dave Dixon wrote:
>
> What is the issue with wrapping in Clojure interfaces? Added overhead of 
> function calls?
>
> I'm finding myself in the process of doing some of this, at least for 
> constructors. Also thinking of generating predicates/generators for use 
> with spec.
>
> On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote:
>
>> This is a slightly irregular announcement, because it's not for a Clojure 
>> library.  Rather, it's for a library written purely in Java: 
>> https://github.com/lacuna/bifurcan.
>>
>> This is a collection of mutable and immutable data structures, designed 
>> to address some of my personal frustrations with what's available in the 
>> Clojure and Java ecosystems.  Notably, they have pluggable equality 
>> semantics, so while they *can* use Clojure's expensive hash and equality 
>> checks, they don't *have* to.  They also provide high-performance mutable 
>> variants of the data structure which share an API with their immutable 
>> cousins.  
>>
>> I'm posting it here to ask for people's thoughts on how, if at all, this 
>> should be exposed as a Clojure library.  It would be simple to simply wrap 
>> them in the Clojure interfaces and make them behave identically to 
>> Clojure's own data structures, but that kind of obviates the point. 
>>  However, creating an entirely new set of accessors means that we can't 
>> leverage Clojure's standard library.
>>
>> It's possible that I'm alone in my frustrations, and no Clojure wrapper 
>> is necessary.  But if this does solve a problem you have, I'd like to hear 
>> more about what it is, and how you think Bifurcan might help.  Please feel 
>> free to reply here, or to grab me at Clojure/West and talk about it there.
>>
>> Thanks in advance,
>> Zach
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.