I got laid off from a job and did some consulting on the side for a few months. The break helped my creativity tremendously
Readit Newsergest commented on After Callous Layoffs, Workers Are Done with the Full-Time Work a.team//mission/the-great... · Posted by u/raunometsa
There have been other periods of massive layoffs. (I’ve personally witnessed 2001 and 2008) Weren’t workers disillusioned with full time work back then or has it become easier and more acceptable to freelance in the last decade? Was it perhaps the callousness of the layoffs that ignited these emotions?
ergest commented on PRQL – A proposal for a better SQL github.com/max-sixty/prql... · Posted by u/maximilianroos
I like it, it's readable, unlike some SQL alternatives I've seen it doesn't make me feel like I'm dumb and don't understand what a query even is.
I can't decide if it would be better or worse if it stuck more closely to SQL keywords. You use "from" and "select", but not "where", "order by", "group by". There's some danger of it being in an uncanny valley of SQLish, but I'm pretty sure I'd prefer just using those terms verbatim (including the space in "order by"... that style is less common in modern languages but it's not really that much harder to parse).
I'd like to see more examples of joins and composing SQL. Does this language make it easier to make more general SQL queries? Can I take two queries and squash them together in a reliable way? I feel like I end up with a lot of theme and variation in my queries, often involving optional filters.
I might even like a notion of encapsulation that could help this query language when it's embedded in other languages. Like if I could say, in the language itself, that a query has certain unbound variables (and not just ? or other placeholders). This language seems like it would be better for generating than SQL, and sometimes generation is just necessary (like in any application that supports data exploration), but for most common cases I'd hope to avoid that. Defining inputs and then making whole filter sections or other statements conditional on those inputs would help here.
> I can't decide if it would be better or worse if it stuck more closely to SQL keywords. You use "from" and "select", but not "where", "order by", "group by". There's some danger of it being in an uncanny valley of SQLish, but I'm pretty sure I'd prefer just using those terms verbatim (including the space in "order by"... that style is less common in modern languages but it's not really that much harder to parse)
I agree 100% here. As a SQL veteran, it would make the transition a lot easier if you used common SQL keywords like group by, order by, limit, etc. e.g.
from employees
where country = "USA"
derive [
gross_salary: salary + payroll_tax,
gross_cost: gross_salary + benefits_cost
]
where gross_cost > 0
group by:[title, country] [
average salary,
sum salary,
average gross_salary,
sum gross_salary,
average gross_cost,
sum_gross_cost: sum gross_cost,
count,
]
order by:sum_gross_cost
where count > 200
limit 20ergest commented on Metrics-driven product development is hard blog.doubleloop.app/metri... · Posted by u/kiyanwang
That’s because metrics are great for optimization and fine tuning features but terrible for innovation
ergest commented on Your Lifestyle Has Already Been Designed (2010) raptitude.com/2010/07/you... · Posted by u/tacon
I agree that the 40h workweek is not technically “designed” per se but rather it’s the best confluence of factors such as keeping competition at bay, keeping society productive, making people feel useful, making life purposeful for many, etc. It’s the current local minima. If we could work 60 or 80 hours and still get the same benefits, we’d do so. However, nobody has experimented with working less while others work more because competition will eat you up.
ergest commented on Why have there been so many own goals at the Euros? inews.co.uk/sport/footbal... · Posted by u/sbmthakur
The comment of Tyler Heaps gives a clue:
“If you look at each one and how they’ve occurred, many have come from “dangerous areas” on the pitch. At AS Monaco over the last season, we looked at where and how goals were most often scored and key areas to shoot/cross from to apply in our game model.”
With teams applying more analytics to soccer there are more cases of high goal probability crosses and defenders’ attempts to clear these are often futile. A great example was England’s equalizer yesterday that technically was an OG but realistically the defender had no chance to clear it and Sterling was right there to tap it in.
ergest commented on How to Learn Complex Things Quickly: A Guide product.hubspot.com/blog/... · Posted by u/fmccaffrey
The guide is ok, but I will say that nothing works better than having a problem you’re trying to solve. The rest comes naturally. I taught myself data mining (now called machine learning or data science) in a matter of months because I was trying to build a lead scoring model.
ergest commented on Ultrasound has potential to damage coronaviruses news.mit.edu/2021/ultraso... · Posted by u/tracyhenry
Might work wonders in being applied to air filters or disinfecting large spaces. Not sure if you could run this continuously especially when humans are around.
Why is it a killer feature? First of all, LLMs complete text from left to right. That alone is a killer feature.
But for us meatboxes with less compute power, pipe syntax allow (much better) code completion.
Pipe syntax is delightful to work with and makes going back to SQL a real bummer moment (please insert meme of Kate Perry kissing the earth here).