Hacker Newsnew | past | comments | ask | show | jobs | submit | peatfreak's commentslogin

There's an undercurrent of victim blaming here.

A lot of companies hire data scientists simply because it's "the thing to do" and they want to appear modern in the marketplace. But then these data scientists are typically left to work alone and put under pressure to "produce results" with no tangible understanding of their mission.

Sure, you could say that it's up to them to advance their own case, but if you have no support system (which is something that most people need) then it's very demoralizing. Unless part of your job is to figure out how and whether a data driven approach is even applicable, then this is can be a very depressing situation to be in.


> Unless part of your job is to figure out how and whether a data driven approach is even applicable, then this is can be a very depressing situation to be in.

You make a good point... what is your job? I suppose I've been coming at it from the perspective that it very much is a data scientist's job to figure that out. Sometimes the answer is, no, using ML for X use case is a waste of time. Or "no, there's a qualitative heuristic we can use that's better than some lengthy statistical process". At most serious orgs it's expected that "no, this is a waste of time" is a reasonable answer.

The issue of not having a support system is an orthogonal problem no? The reality is some companies and even teams within good companies don't offer that. So you have to learn how to navigate politics, etc. to get execs to buy into your vision/results/suggestions.


Author is NOT the victim. They have a lack of people skills that could be remedied by taking some proper coursework, or seeking professional help. The companies author is working for are the victims.


Did you actually listen to the presentation? They explicitly addressed each of these points (except the bit about the confounding variables, admittedly).


The good examples are _always_ cherry picked.


I'd be interested in seeing other "setting up an electronics workshop" articles by other engineers.

Luke Gorrie, for example, has an article here: https://github.com/lukego/soldering


It's a video, not an article, but here's Dave "EEVblog" Jones on "How to set up an electronics lab".

https://www.youtube.com/watch?v=R_PbjbRaO2E


I haven't watched that particular video, but I would exercise caution with his videos. He can often exercise some rather strong opinions due to: (1) he's right, (2) he misunderstands the product or a feature but claims it's an issue, or (3) some arbitrary reason based upon the name printed on the product. And (2) is often coupled with (3). This caution is probably advised on many electronics videos, especially from old heads because their American made or Japanese made gear from 30 years ago is better, which is often unhelpful because that gear isn't available anymore and is subjective anyway. Or entry level gear is compared to their $1,000+ soldering iron or $5,000+ oscilloscope.

I have been doing a lot of research lately for some entry level gear that will last and suit my needs without breaking the bank, and it's very difficult to sort through inaccuracies and biases against certain gear.


He can often exercise some rather strong opinions due to: (1) he's right, (2) he misunderstands the product or a feature but claims it's an issue, or (3) some arbitrary reason based upon the name printed on the product.

That's fair, although I would say the same is true for most (if not all) people commenting on this topic! Myself included as far as that goes. I am, for example, a fan of Hakko kit (I use a Hakko soldering station as well as the aforementioned FR-301 desoldering gun) and am an unabashed Rigol fanboi when it comes to test equipment. Rigol made my oscilloscope, bench multimeter, lab power supply, programmable load, signal generator, and spectrum analyzer. Outside of Rigol I'm also a fanboi for old HPAK (HP/Agilent/Keysight) kit. I have an HPAK logic analyzer, modulation domain analyzer, frequency counter, and dynamic signal analyzer. And I'm still lusting after an HP 3458a one of these days.

That said, I try to avoid falling into complete fanboy'ism when recommending stuff to others. There are lots of good brands out there for most things!

I have been doing a lot of research lately for some entry level gear that will last and suit my needs without breaking the bank, and it's very difficult to sort through inaccuracies and biases against certain gear.

No doubt. For me, the pattern I fell into is reflected in what I wrote above: I buy mostly Rigol kit for anything I buy new. And that's because Rigol strikes me as a good compromise between cost, quality / functionality, and "hackability."

And then for more specialized / niche stuff, if I can find a used HPAK instrument for a good price on Ebay or whatever, I'll go with that. So far I feel like that strategy has allowed me to get my lab kitted out fairly nicely, without breaking the bank. But I'm sure even my lab would seem extravagant to somebody, especially the prototypical "starving college student".


I'm really curious as to how these were done, or might plausibly have been done. Is this indicated anywhere? After working on audio signal processing for quite a few years, I'm investigating image and video rendering, and applications like this are the kind of thing I'm interested in.


Any good 3D modeling and rendering system could do those images. Blender, Maya, etc.

The house-sized ones you could build for the better virtual worlds, such as Second Life.


The article has the following near the end:

"To see more real-world examples of makefiles, see my [World Atlas](https://github.com/mbostock/world-atlas) and [U.S. Atlas](https://github.com/topojson/us-atlas) projects, which contain makefiles for generating TopoJSON from Natural Earth, the National Atlas, the Census Bureau, and other sources."

I checked those repositories because the descriptions of the makefiles sound interesting, but I couldn't find the makefiles. Am I looking wrong?


It looks like the author gave up on using Make with this commit: https://github.com/topojson/world-atlas/commit/8f92f6eb692d1...


More like they moved from the need of using Make to create the topoJSON to use prebuild ones with Node.

In the package.json of that commit:

> - "description": "Roll your own TopoJSON from Natural Earth.",

> + "description": "Pre-built TopoJSON from Natural Earth.",


It kind of makes the whole article irrelevant. Like a house of cards that is build on a foundation of Make, but when you get to the bottom there are no actual Makefiles there.


It just means when the article was published, the need was real and make was useful. Context matters.

Based on that commit they don't need to download the data to generate the .json file, so they don't, Make became irrelevant. If anything this shows that a tool can be really useful but you don't need to marry it. Don't use if you don't have to.


The whole point of the article is to discuss Make.


Which isn't invalidated by a project having no need for it anymore.


This makes no sense!


> It makes me sad that many people will use this as an opportunity to write off Buddhist practices.

This would be a huge misunderstanding of the article. I read the whole article, and I found it to be positively re-affirming of Buddhism. Unfortunately the submission title is potentially misleading and possibly even clickbaity.

It's a very good article. I've read many critiques of Western Buddhism and they can mostly get a bit samey after a while. However -- after the first few paragraphs, which are admittedly pretty run-of-the-mill -- this article elevates itself to a much more interesting level. It also raises solutions, anecdotes, and references that go way beyond what you normally hear.


I disagree that it's a very good article or even a good article. Its conclusions stand in stark contrast to the fundamentals of Buddhist practice. It's message is confusion from an author who is not accomplished in practice but writes eloquently.

I think it's unfortunate its gone to the front-page because it makes a mess of the dharma and communicates Buddhism as a mass of contradictions.

People will latch on to anything that confirms their biases without practicing and seeing for themselves what it really is. I encourage more people to go out and practice the way we have the teachings preserved not in Zen, not in Tibetan but early Buddhism, where we're closest to the teacher. Start there, practice ethics first, then move on to stability of mind, then real insight practice always with an eye to, "is this thing improving my relationships to myself and others?" If it doesn't, if you become more egoic, more like Sasha, abandon it, seek help. Do not declare enlightenment, do not foster a following of people who will then spread your confusion to the four corners of the earth.


I've never seen so much disagreement about "what is Buddhism" as I have in online Buddhist communities. Everywhere I turn there is conflict, misunderstanding, and people proclaiming "this is not real Dharma, but I know what the real Dharma is".

I do however agree that a lot of folk seem to get into esoteric stuff like Tantra and Dzogchen very early before understanding basic things.

> Its conclusions stand in stark contrast to the fundamentals of Buddhist practice. It's message is confusion from an author who is not accomplished in practice but writes eloquently.

Some famous Buddhist teachers are a bit like this to me. Chogyam Trungpa, for example... I can't make head or tail of the man. Sometimes I think Crazy Wisdom is great, other times I think he's been a disaster for the spread of Buddhism to the West. I raise the spectre of CTR because the article we're discussing has a Crazy Wisdom feeling for me, and that's why I like it.

> I think it's unfortunate its gone to the front-page because it makes a mess of the dharma and communicates Buddhism as a mass of contradictions.

The whole Internet is a mess of contradictions regarding Buddhism. It is literally the worst place you can go to learn about what Buddhism really is, because the only way you learn properly is to trust a teacher by knowing them on some kind of personal level or teacher-student level.

For a tradition with such emphasis on sangha, practice, and lineage of teaching, it's ridiculous to submit to the thoughts of online Buddhists who you don't even know. I think this is a reason for all the disagreement; arguments are conjured up out of thin air with no reference to the actual practice of the person who says it.

I'm not saying the article is correct in all aspects, but rather that it goes beyond the trite and predictable criticisms of Western Buddhism, and for that alone it's more interesting than most articles. It raises anecdotes that I haven't much of before, it's slightly abrasive, and I like that.

> I encourage more people to go out and practice the way we have the teachings preserved not in Zen, not in Tibetan but early Buddhism, where we're closest to the teacher.

This is a very Western Buddhist attitude. In the Western tradition we love to get as close as possible to the primary canonical source when learning something, possibly because Western Buddhism tends to be quite dry and academic and admits very Protestant attitudes. I think a lot of Western Buddhists have this mistaken notion that Theravadans have some monopoly on what Real Buddhism actually is.

My most recent teacher said it doesn't matter whether you start out in Zen, Pure Land, Tibetan, or Theravada, just pick one and stick with it for a while otherwise you'll get your wires crossed and end up getting a jumbled message that is inconsistent with any sect. He acknowledged the desire for people to study early Buddhism as the "purest" form of Buddhism, but he said that IF you want to study early Buddhism or Theravada, then you need to stick with it. So, much like you're saying, yes the Theravada teachings are more direct and simpler, but maybe it's not necessary to start out with this form. Maybe it is, I don't know. I'll figure it out as I go along. But I don't disagree in principle.

Personally I like the simpler, warmer approaches to Buddhism, and I do often appreciate irrational, supernatural aspects when I encounter them. I do appreciate Theravada, not because it's the purest form, but because the practitioners I've met so far seem to be a bit warmer. Plus, Theravada is a bit more like, "do this, do that, keep it simple".

I've been very curious about Zen but I notice that a lot of Zen practitioners tend to deflect real-life problems into clever Buddhist aphorisms, which is just evasive and doesn't really engage with the world. Plus I don't really love meditation that much so maybe it's not for me. I'd prefer to do active physical exercise in my limited time (and when I'm not writing on HN) because I know this benefits my mind and body more than extended sitting. On the other hand, I like Alan Watts a lot, I think he had had a much more positive influence on Western Buddhism than CTR had. So AW a good, positive advertisement for Zen.

Pure Land sounds cool because I like chanting, but I like Nichiren chanting more (plus I met a lot of cool people in Nichiren circles). Tibetan Buddhist sanghas around where I live seem to be a bit, oh I don't know, I just can't really get into it.


Yes, I hope that most readers take away this sentiment as well.

I will say that some of Sasha's criticisms don't vibe well with my understanding, though. For example, we don't renounce pleasure because Buddha tells us we should, but because we directly observe that clinging to desire inherently feels bad. Our subconscious mind, when confronted with this info, naturally drops the object like a hot coal.

Telling newbies that traditional Buddhism is about giving up everything that makes you happy is a mischaracterization imo.

I also think his understanding of clinging is more narrow than what's described in the Abhidhamma. The interludes of TMI[1] give a pretty approachable introduction to this model of conscious experience.

[1]: https://a.co/d/04tc3dJ


Homebrew is an awful system, it's the exact opposite of what should be held up as an example of a well engineered "packaging system". It's not even a proper package management system anyway, and there are far, far better systems for Mac OS X. The whole "dump everything into /usr/local" is absolutely insane, and it's depressing that the development community on OS X has fallen for it.


And yet it’s by far the most popular, easiest to use, and solves the most number of problems for the most number of people. Millions of hours of saved dev time over the years. That’s well engineered to me - engineered for users, not purity.


While many people would agree that value to users is more important than "pure" engineering/code quality, moving the goalposts doesn't nullify the GP's point. If Google was hiring to acquire Homebrew (assuming it was possible) then value to users would be a factor to consider. But if they were just hiring the person to work on non-homebrew projects, why wouldn't "pure" engineering quality be relevant?


Do the projects at Google not also have to provide value to people? Given the number of products they kill, you’d think that would be a higher priority.


In the decade or so that I’ve used it, it’s pretty much always done exactly what I’ve needed it to with no negative side effects. What else am I supposed to want out of it?


Homebrew on Apple Silicon is finally at /opt/homebrew instead.

One not very sane decision tho is choosing to not require sudo for package installations but have /usr/local or /opt/homebrew writable for more than just root.


It's OK-good. 95% of the time it just works. One thing I would love is a feature like AppCleaner to know where was dependencies were installed before they are removed. Maybe it's already capable of but I didn't know how.


Ray of sunshine aren’t ya :’)


Does it solve the problem?


I never knew about MiroTalk before, so I'm happy to see this post. How does it compare with Jitsi, for example?


Hello peatfreak, It's my pleasure to share it! Just try and you can see the diffs ;)

Thank you.


> wasting time looking up the manuals

God forbid!


I think we should let this C era meme die, the manuals are often terrible. I'm currently working with the AWS SDK Python documentation and it's a hot pile of garbage from all points of view (UX, info architecture, technical detail, etc.).

Python lang docs are "kind-of-OK" but when someone raves about them I'm left scratching my head. Information is not always well-organized, examples are hit-and-miss, parameter and return types not always clear, etc.

Referencing docs as a programmer is generally a nightmare and a time sink, and it's the one use case where ChatGPT is slowly becoming indispensable crutch for me. I can ask for very specific examples that are not included in the docs, or that cannot be included in the docs, for example combinatorial in nature: "how can I mock this AWS SDK library by patching it with a context manager"? Occasionally it will hallucinate, but even if it gets it 8/10 times right - and it's higher than that in practice - it will prove revolutionary at least for this use case.


> I'm currently working with the AWS SDK Python documentation and it's a hot pile of garbage from all points of view (UX, info architecture, technical detail, etc.).

I agree that pretty much all AWS documentation is woeful, and it's a travesty that the service is so expensive yet its documentation is so poor. I would gladly dump AWS and never use it again, as I hate paying top-dollar to decipher the AWS doc team's mistakes (not to mention that they are unresponsive to bug reports and feedback).

My point was made more in jest, and supposed to point out the irony of the communities' changing expectations of what documentation should be like. I predict that in a few years we'll be circling back to prioritizing writing software documentation well. (Kind of like how everybody was hating on XML for the past 20 years and it's now having a renaissance because it actually does what it's supposed to well very well.)


I'm amazed by how divisive it is. I've also been using it to significantly increase my productivity, be that documenting things or having it mutate code via natural language or various other tasks. I feel that if you keep in mind that hallucination is something that can happen, then you can somewhat mitigate that by prompting it in certain ways. E.g. asking for unit tests to verify generated functions, among other things.

I find this tool so useful, that I scratch my head when I read about how dismissive some people are of it.


I think one of the reasons why Python got such a reputation for good docs is because its primary competitors back in the day were Perl and Ruby. Ruby has horrible documentation to this day, and Perl has extensive docs that are difficult to navigate; in comparison with either, Python was definitely superior.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: