Fork me on GitHub

I don’t do much graph work, but I have a graph problem. I have an undirected graph with a set of nodes that I want to consider to be roots, and would like to find all nodes that are not connected to those roots. I’m playing with loom and it’s easy enough to build the graph but none of the fns seem obviously correct to do what I’d like. Any tips?


Pretty much like a mark and sweep gc


Mark roots, push connected nodes into a stack, mark everything in the stack, mark connected nodes, etc. Don’t push any nodes onto the stack that are already marked. When the stack is empty unmarked nodes are unconnected.


Something like that ^^


@tbaldridge: do you know of a good resource for "programming in datascript exercises" ? I'm looking for a resource that would have 100 exercises of common problems in CS, and solutions of how they would be solved in datascript. Most datascript resources seems to cover the basics, but never quite reach the level of "datascript idioms" or "datascript mastery"


No it’s not a Turing complete language


So most examples are going to be quite limited


@donaldball - Fiddled with JGraphT during Advent of Code, they've got a solver for that kind of problem; ConnectivityInspector. This snippet builds the same kind of undirected graph. You can make short work of the problem by adding artifical edges between each root, making all the roots and their connected nodes join in a single set; all remaining nodes not in that set are by definition not connected to the roots.


For a lighter-weight dependency, you can implement it by hand with a disjoint set lib


Thanks y’all, with loom the fn wound up being pretty simple:

👍 4

I'm building a webapp, which offers new users a free trial. I don't want users to be able to get more free trails via creating more fake email addrs. Thus, I want to force "one phone # -- one free trail." Now, I could send SMS verification and paty those fees -- but is there some way to leverage an external api (whatsapp? telegram? signal?) where they do the auth and guarantees me unique phohne numbers ?


firebase has a phone api


IMO it’s not worth the effort @qqq . Just make a good app, tie it to the email, and trust your users. Most people have no problem paying for quality products. And you’ll never stop the pirates


@tbaldridge: I think you're right. Per unit time, it's better spent making the software better so the user base will grow by X%, rather than trying to fight the X% of jerks who would never pay anyway.


Hey everyone, I am currently trying to figure out problems which developers face ? any one want to help me out . i have few question


My biggest problem is the lack of a paid StackOverflow. I want a resource where I can post request for sample code to do FOOBAR, attach a bounty, and get working code.


@qqq so something like provided a test, the first code to pass the test would get the bounty, and the code only is visible for the one who put the bounty on?


I’ve read “out of the tarpit” and really enjoyed it. Any suggestions for other papers of that nature?


And this also goes a bit into the same subjects shown in the paper


Thanks @tbaldridge — any other suggestions for things a bit closer to the daily practices? I’m joining a new team and I’d like to woo them into paper reading a bit. Out of the tarpit was quite approachable even for someone who hasn’t ready any papers since uni days 15 years ago…


I know what you mean, the tarpit article is pretty unique in that regard.


Lol yeah, that's an awesome resource


Also there's Joe Armstrong's thesis... let me hunt that up


digs into Erlang a bit, but it's a good overview of how they deal with fault tolerant systems.


Yes, that’s been on my radar for some time…


wow. in the paper describing the correctness of the tools in erlang > At the time of writing the largest of these projects is a major Ericsson product, having over a million lines of Erlang code. This product (the AXD301) is thought to be one of the most reliable products ever made by Ericsson.


that's "all in" on a new language.


The paper was written in 2003? Erlang was first written in 1986 by engineers at Ericsson, so it wasn't exactly a "all-in"


2003 summarizing work from 1981 it says


But yeah, for what it was designed to do, Erlang is really good at it. My only complaints with the language is that I don't often need to do those things.


Erlang works best with message rates and small message sizes a few hundred bytes or so. So it baffles me when people want to write web servers with it where the headers alone are 1KB.


> The language started as an experiment to add concurrent processes to Prolog sounds right up your alley


lol yeah, that's where the nasty syntax comes from


who thought that this was a good idea?



that's a pain to edit, lol ^^


looks both smalltalky and prology to me


Apparently they got the compiler written fairly quickly. According to Joe Armstrong: "the hardest part was the pattern matcher. That was 10k lines of code, and there was only one code comment about half way through that said 'now for the hard part'"


reminds me of this comment that was in emacs' display code below an ascii skull and cross bones > BEWARE!! All ye who enter here: Most of the code in this module is twisted beyond belief! Tread carefully. If you think you understand it, You Don't, So Look Again.

☠️ 4

well some erlang http servers can nearly match nginx in terms of performance atm (depending on the scenario of course)


there's a lot of dirty tricks internally to avoid message passing everywhere, but it works



Once the design of the JAM was complete I started a C implementation
of the virtual machine—which was soon abandoned ader Mike
Williams read some of my C code—ader which I worked on the compiler.
Mike Williams wrote the virtual machine emulator and Robert
Virding worked on the Erlang libraries.


Yeah, in Erlang most of the IO can be done using lists (and malformed ones to boot) to boost performance — this maps almost directly to the system IO calls rather than having to build a big string in user land and copy that over to the OS.


a bit like Java zero copy code I assume


iolist, exactly.


you can nest them etc etc and it gets flattened/mapped nicely, it's kind of cool


Downloaded and printed “no silver bullet” and “equal rights for functional objects”


Ah, can’t delete the annoying preview from mobile. Sorry about that...

qqq19:03:36 <-- is this accurate? most people I've talked to tend to stick with a company for 4+ years, but anecdote != global data


@qqq It seems unlikely that someone here has already done a similar data analysis on such a large data sample as the authors, and can refute the article's claims based upon their own knowledge.


Anecdotally, I recall hearing that around 1999-2000 time frame, the average time for engineers to stay at one company was around 14 months, and the only reason it was that long, instead of shorter, is because typical contracts include a clause that you vest 0 stock options until working at the same place for 12 months.


So at the time of that Internet bubble, people on average were sticking around long enough to get 1 year's worth of vested stock options, then moving on.


There are a lot of contract positions in the tech industry, too, which I would guess tend to have shorter average durations at one company. The article you linked does not mention whether they tried to separate out contract positions from full time positions.


They say that their sample only includes people who say they worked at, then stopped working at, one of the companies they listed. It does not include people who started working at, and continue to work at, those companies.


That would pull the average way down, yes?


Yes, that would bias the data.


You know who should write this article? LinkedIn, it'd be like a single sql query.


They would still have the same issues of "position changes while remaining at the same company" to handle. Not sure it would be significantly easier for LinkedIn vs. other people.


probably also depends on what stage of careers they tend to hire at. You kinda need to bounce around a lot at the beginning to get decent pay raises in tech. I guess once that starts to plateau you can stick to one company longer…also you probably know what you like more


I'm at my fourth company in 6 years. And the first one was a large one, and we had a peer group of about 15 people, and they are all gone by now. It seems how bigger the company, how faster people leave, maybe because they feel less commented to the company.


I stayed 9 years at my previous company. Staff of 4 people :)