204 karma · joined July 26, 2009
take heart, not profits
My mother is an accountant for example, and she could easily pick up SQL or a programming language, but the issue with teaching her one is that it doesn't solve any of her immediate problems. Excel already automates most of that work away, so for her that's all she needs.
Your company's accountants can probably write excel statements that are equivalent to complex SQL statements, so I wouldn't underestimate them :)
Probably not only split on this one variate (externally or internally triggered), but it means that certain types of depression are usually triggered externally and certain types not externally.
It's like saying that "in some cases, a broken leg is not triggered by some external influence". Sure, you could develop some bone density issue and break a leg when walking normally, so we tend to distinguish treatment of these cases--we may recommend a more permanent solution for someone who is prone to breaking their leg.
How can we even falsify your statement? To do so would require self-reports or some sort of real-time 24/7 measurement of the brain, the first doesn't really falsify anything, and the second is not very viable at the present.
Self-reports can easily lie. They also may simply not remember, or be in denial.
I've developed and maintained projects that are more than a million lines of code (probably much more), and I've also written large haskell programs (5000 lines is large, since it encompasses what would have taken me maybe 30000 lines in C++). I can say that the maintenance time and error rate of my Haskell programs dwarfs that of any C++ program I've written or maintained.
We've also learned in software engineering that the defect rate is mainly correlated with the code size, ie. the complexity of the code and how much there is, or simply the entropy of the code. With functional abstraction, the abstractions aren't "leaky" and actually allow you to reduce complexity and forget about the lower level details entirely.
We want free speech, not a lawless society. I hope.
You sound pretty introverted, but it doesn't explain all behaviors, which is my intent. To do so, you have to also explain why sometimes I am introverted by your description, even for years at a time, and then at other times I am extroverted, with similar time scales.
> If the behavior is occasional, that's not introversion or "barely introverted".
I mean to say it's between occasional (extroversion), and constant (introversion). This means there's a certain probability of it happening, so you're right, it could be rarely, occasional, sometimes, most of the time, almost all of the time, and all of the time.
So I don't disagree with you, you can make a clear demarcation, but then the words are much more useless. And if you're close to either side then you might as well call yourself an introvert or an extrovert.
I'm definitely both--I've had periods of my life where I can't detach myself from groups of people, and I've had periods of my life where I spend multiple days inside without going out. There are definitely some environmental factors.
Introversion is tied in with neuroticism, which is definitely on a spectrum. The big five personality traits are also a spectrum.
If I had two colors on a spectrum, lets say blue and yellow, we wouldn't call the middle of the spectrum "color", we'd call it "green".
> Why would a new set of pronouns be needed to categorize such a non-homogeneous group when neutrality already captures everyone between the normal binary categorizations?
I think this is the issue, it doesn't necessarily capture them directly. I think there is merit in having a pronoun, but it shouldn't be forced by law (as it is where I live). It doesn't arise naturally probably because there are many different categorizations in the middle and most people are on the poles, which I think is fine.
If, during conversation, we wanted to specify through a pronoun what gender a person was, there is no way to do it purely with pronouns anymore, since non-cisgendered people will sometimes use "they" so to distinguish between cis and non-cis you need to explicitly state it. Or even to specify the plurality of a group of non-gendered people you have to explicitly state it. Which is not typical english.
So I find it difficult referring to a non-binary person in singular or in particular. I usually just say "non-binary" or trans when it's important, typically only using their name, or not mentioning them at all for fear of misgendering them.
https://en.wikipedia.org/wiki/United_States_free_speech_exce...
The US definitely has the most free speech, but you're still restricted in various ways.
At the very least even with the knowledge that it refers to Abel they will still leave it in noun case.
Maybe it's just a post-rationalization of the phenomenon you're describing.
edit: This is done consistently, and I think abelian is one of the few examples. I've never seen it capitalized before, which is why I made this post.
Our minds are literally categorical machines--in order to fight entropy we find stable states through classification of the world into categories. So literally any form of thought is a form of discrimination between many categories. Every word can be thought of as a category.
> Usually, I find that code that is thoughtfully written and extensively debugged in the debugger is the most robust part of the program, but YYMV.
Have you ever worked in a code base that is thoughtfully written but not extensively debugged? I'd wager they're pretty rare because of this extensive widespread use of debuggers, but perhaps these code bases are even more robust, since in my experience they're more thoughtfully written. Preconditions and postconditions everywhere!
It's also not for lack of use, I've developed software for more than fifteen years, and I've always had access to some sort of debugger, and I've always used them, just very rarely.
>You add log statements, rebuild, relink, reproduce; or, you could just set a hardware watchpoint to print the backtrace whenever it changes. In my experience people don't reach for the debugger way of doing it simply because it might not be needed all the time and the syntax is forgotten. Diving into `man` or docs is harder than printf(). Use those skills more regularly and/or make a cheatsheet, macros, etc. and it is less of a problem.
Hardware watch points work horribly for objects, I have to create and maintain views for all the practical objects I use, unless they're very popular libraries like OpenCV. Ultimately, these views could simply be printf or cout statements, maintained with a common function or method defined on all objects.
These log statements typically happen right near assert statements, so they can be maintained along with the code. I'll usually use something more sophisticated than simple printf, and I'll have many different types of logs for common debugging cases. They can be enabled or disabled at runtime, so no recompilation needed. They give me access to all the state I could possibly require, and they get committed to the code base.
I've had coworkers spend entire days in debuggers (often in groups), where a simple step back and a simple log easily solves the problem.
I would use hardware watchpoints if they were standardized across debuggers, but they don't have all the features I need even in the best debuggers, and then I'm still useless on other platforms. Also, I usually need the program to run at near real-time otherwise the bug may not reproduce itself.
edit: I should add I do use some of the more advanced debugger features in those rare cases. So debuggers are still necessary, just not in the day-to-day.
I should also say I've also worked in environments where the software has to be pretty much bug-free, where small bugs may not be immediately noticeable. So there's a lot of planning, design, even non-formal proofs of correctness happening. If it's allowable for your software to have some bugs, maybe you can take a shortcut with a debugger.
Finally, I'm not against all tooling, just debuggers. I use visual profilers all the time.
A debugger gives you the state of the entire program, and one point in time. A log allows you to focus, which gives you the state you actually care about, at all the points in time where you care about it.
The time-evolution of the state of the program is practically the only thing I'm interested in.
I find that code that has been written mainly with debuggers is often full of tons of errors, often simple negations which have been worked around an even number of times. Then you're stuck with the debugger, and there's no way to reason about the program. The result is low quality.
Even at large R&D companies which have the investment, people are still hesitant to invest in new ideas since they simply don't have the money. It works the same way with the government, just at a larger scale.
Many people don't care about any of this though. They just want to live their lives, find something to be passionate about, and die peacefully. You'll always have to fight these people, politically.
We also have to consider the legal ramifications of such things. It is difficult to do ethical R&D.
It shouldn't actually be too difficult to get the hand pose with gloves. I've been out of this space for four years though.
Algorithms can actually produce a real physical result, whereas mathematics exists beyond pen and paper.
Algorithms that we (programmers) construct usually aren't done in terms of Turing machines or the lambda calculus. Therefore they're not purely mathematical.
> Premise 3: Hahaha, lawyers don't know math but they do know billable hours.
A patent lawyer I worked with had a mechannical engineering degree. I'm fairly sure he knew some math that I didn't.
Just because innovation happened without software patents does not mean that higher quality innovations can not exist with patents. I know of algorithms which give certain companies an edge in their flagship international products. If these algorithms were able to be patented globally, it would be a large benefit to the entire industry. Since China is part of this market, the company does not patent this algorithm and instead keeps it as a trade secret.
I think in this case it would be better if the algorithm was patented.
We need to distinguish this case where the patent is truly non-trivial and would not be able to be re-created without great expense. It's very difficult to evaluate this, especially for those who aren't experienced.
Honestly, I don't think "end of all software patents" is the solution here. Imagine if NNs were developed completely as a trade secret.
These external problems ultimately are about explaining patterns in the world.
I'm just saying you'll never replace the relationship between the mathematician and the physicist by simply replacing the mathematician. Instead, you'd have to replace the whole academic process, making fully autonomous universities. In which case they're still not interested in exactly same problems unless they are constructed in the same way (which they are not, since they are not human).
I'm not saying that computers won't be able to aid us with these meta-theories which help push our main theories forward. So I do agree that they can come up with some theory, but not all of it, and not most of it.