619 karma · joined August 12, 2014
That being said, there are a variety of other character traits that play a role in how different people reach success, thus part of the issue is simply the interpretation of "success" itself, because quite often we look to very specific examples of successful people (e.g. Steve Jobs) or paths, that don't suit our personality taits nor strengths at all, and set us up with unrealistic expectations for ourselves.
Success comes in all forms, shapes, and sizes, so there should be no reason to let certain traits limit us on the hunt for success, when the game is largely about filtering out the noise and focusing on paths and pursuits that actually play to our strengths, instead of ones that make us perpetually anxious and stressed out.
That's actually quite a controversial statement that many professional mathematicians might beg to differ with.
Viewing mathematical results and axioms as being totally invented, opens the possibility of being able to just will contradictory proofs into existence, and that is simply not the case in practice. Mathematics might be more for description than definition, but what it's describing isn't usually the physical world, it's the logical limitations of certain principles. And if these principles are found to be reflected in some aspect of the "real world", then the corresponding mathematics becomes applicable. But you can't just pick any arbitrary axioms/principles and have them automatically be mathematically coherent either, so again we're limited in the maths that we can "invent".
I chuckled at that, because while it makes for a good joke, I've learned from experience that writing stuff in less mainstream languages like Haskell is probably the best way to avoid getting distracted by trendy new frameworks all the time, since they tend to have smaller, more niche focused communities that don't produce new frameworks every week that would even be relevant to you.
Why do these reasons have to be mutually exclusive?
Furthermore, your second point relies on every single cumbersome/complex java library also being a perpetrator of trying to do too much. Surely a lot of people here can probably think of smaller libraries that explicitly don't try to do everything, and are still "complex" and cumbersome to use. The best examples I can think of were of internal libraries at previous jobs, and that happened across many languages not just java. These sorts of annoyances pop up repeatedly in a wide variety of languages, despite not necessarily having the same culture as java.
Not to play evangelist here, but I just haven't had as many of these kinds of issues with libraries since switching to more modular typed functional languages (i.e. ML/Haskell), and it has really played a role in helping me see the forest instead of the trees. Noticing how language complexity and inexpressiveness leads to those kinds of problems isn't supposed to be obvious or intuitive, because it's effectively a Butterfly Effect that causes most of its severe repercussions much further down the line. We can play whack-a-mole with smaller sources of complexity (such as java having kitchen-sink libraries) as long as we like, but shouldn't the goal be to hunt down where all those "complexity moles" are even coming from in the first place? Because if that is the goal, and even smaller more focused libraries still produce annoying amounts of incidental complexity, then there's not much room to blame anything other than the constraints of the language at that point.
Saying the experience is "not transferable" is looking at it the wrong way. Learning the discipline behind haskell isn't even remotely the same kind of beast as learning how to use a niche legacy framework in COBOL for example.
It's a lot more akin to learning to read human language for the first time, because all it's doing is familiarizing you with patterns that exist in code and computation, independent of Haskell. The actual language part of the haskell equation is literally the least relevant/significant, because what it teaches you is to recognize mathematical/computational patterns that you can find in any language, despite the difficulty of expressing some of those concepts succinctly in some languages (e.g. java).
The biggest thing that's 'not transferable' is the ability to communicate the high level patterns to others who haven't gained literacy with that particular branch of mathematics/CS yet. But that's true of all sciences and mathematics. You can call it a "weird side language", but that's kinda doing it a disservice as a language that's intended to express complex relationships and computational patterns in the most general way possible.
I just want to emphasize this part because it's really quite true, as someone who came to it from F#/OCaml.
The thing with learning "haskell", is that there's faar more to it than learning the basic language constructs. You can learn haskell the language in about a day, but you can't really learn haskell the paradigm/philosophy/mathematical discipline in a day, much less actually program haskell that quickly.
That being said, it's not as difficult as it's made out to be, the mountain you need to climb is much shorter than people realize. The issue is largely one of jargon, and getting used to using and thinking in all the new terms and concepts that really have few equivalents in other languages.
The word "pure" gets thrown around with regards to haskell, but most of its draw and apparent purity, isn't the same as the technical definition of it being a "pure" functional functional language.
This "pure" functional aspect is more of a quirk that you get used to working with, rather than a noticeable feature.
I would argue that the seeming 'purity' most haskellers love about the language, has to do with it's ability to cleanly and flexibly model domains without fear of refactoring, or worrying about fitting them to strict opinionated frameworks. This is because the language is flexible enough to let you really model your thoughts however you want, regardless of what they'll be plugging into. Meaning that you can focus 'purely' on the business logic.
So no, the 'purity' shouldn't be affected very much in large projects.
> The fact that everything is a linked list (bad for caching & performance) and everything gets copied around really turns me off.
It sounds more like you're inadvertently looking to shoehorn your existing mental model of how "performant code should work" into Haskell, rather than looking into how "performance with haskell" is achieved. Haskell works on a fairly different paradigm, so you can't just make assumptions about it like that. For example, hashmaps are largely unnecessary in Haskell, and you find out why the more you use it. The linked lists in haskell are also not much of a concern, because they're already highly optimized, due to the fact that they have to handle being infinitely large, not to mention that there are other data structure readily available if needed. Overall, haskell is already quite performant,and you can turn it's laziness features off wherever you want if you really have a hard time reasoning about is lazy evaluation performance anyway.
You can still always open complicated org files in emacs if you really need to, but that shouldn't stop people from attempting to develop a lighter client alternative that's more convenient for the browser or mobile, for example.
Even just using a subset of orgs features, it can still be significantly more powerful than just plain old markdown. Most of my org notes would be ok to edit with nothing more complicated than the labels+tags+checkboxes+tables features. Would be mildly annoying to manually update a few things here and there, but it'd still be far better than nothing.
I have to question just how much you've read from Uncle Bob to begin with, because he's by no means the NULL fan you're making him out to be. He's a proponent of immutable/functional languages like clojure for crying out loud.
Stop propping up strawmen and spreading fud about authors if you don't actually take the time to understand their perspectives.
For the dosing, you're probably right, since I didn't have a milligram scale at the time, but I tried to eyeball a portion similar to half of an adderall tablet, since the entire reason I tried it in the first place was to make that comparison.
As for the ingestion method, I tried to keep it the same as I would take any other medication and quickly washed it down with water, however it being a powder makes it harder to guarantee none of it was absorbed sublingually, though I've also tried adderall that way, and the effects were still not that intense.
Anyways, I am aware how similar the two compounds, I just tried to highlight the effect differences, since that's usually what gets people up in arms about drugs.
Methamphetamine is so strong, I honestly couldn't even tolerate small amounts of the stuff. The few times I've tried it just resulted in dehydration, headaches, and muscle aches, easily outweighing any cognitive effects it had (which weren't even really more noticeable than regular amphetamine's effects for me). Cocaine isn't as bad, but still a bit too much for me as well.
Regular amphetamine on the other hand, the compound this article is about, has given me quite a noticeable improvement in my quality of life. Results do vary even among us adhd people, but for me, I've never experienced anything worse than staying up a bit later than I would like from taking it. Otherwise it just feels like drinking a really strong cup of tea for me, cause even coffee makes me more jittery. So the research in this article doesn't surprise me too much, but it's always nice to have some extra reassurance against all the anti-adhd-medication propaganda that originally made me paranoid about even trying it back when I was first diagnosed.
https://www.commitstrip.com/en/2016/07/11/a-bad-workman-blam...
Jokes aside, the history of mathematics is a pretty worthwhile subject to study to truly appreciate the importance and implications of tools (or mathematical discoveries in this case). There's a reason why it took humans 2000 years after Euclid first wrote his 'Elements' to discover non-euclidean geometry...
Proper abstractions are supposed to compress large bundles of information into a smaller set of [broad] concepts, which then imply all the large sets of details they're abstracting away. High level languages are pretty good abstractions on top of raw assembly code for example, because you don't have to think about what the assembly for your java code is going to look like, it's already implied that it's going to work.
As for react, I'm also not a huge fan, but that's because it's still a relatively leaky abstraction that comes with a lot of the same baggage as plain js+html+css. Especially when compared to a fuller abstraction like Elm[0]. But even that's still lacking a complete abstraction of html/css stuff. And that's not even taking the leaky abstractions on the backend side of the equation into account:
http://haskell-web.blogspot.com/2014/04/towards-deeper-integ...
I'm not going to deny the presence of some built-in preferences for formalized thinking among some subset of the general population, however the cognitive resources and preferences that would lead one to enjoy or excel at math, are about the same as those correlated with programming. e.g. a noticeable interest in understanding mechanical systems.
So given that set of preferences that would produce an interest in math/cs, if a person was raised by a mathematician parent, they'd likely be "good at math", but possibly still struggle with programming when they reach their CS classes in college. Meanwhile another person with the same set of preferences but raised by a hacker, might be good at programming by the time they reach college, but still have a hard time with math.
The issue is less about "can this CS person be good at math?" or vice versa, and more about "will this person be motivated to learn these complementary skill-sets?". Because it's not just a one-way street, mathematicians can also learn from thinking programatically, as shown by the growing popularity of automated theorem provers like Coq. And mathematics being helpful for programming is nowhere better epitomized than by the huge trend of nearly every popular language slowly adopting functional features (and even "optional" typing), because everyone is slowly discovering that mathematically sound programming principles actually are practical (just a bit more abstract and difficult to grasp at times).
Both of those examples should be pretty good evidence of these two fields being pretty helpful towards each other. The large show-stopping issue here making this relationship non-obvious, is education. If complex subjects that are already difficult get taught poorly, it's only natural that we don't expect people to make connections and think "oh hey, this [math/cs] concept I learned about might be helpful in this [totally unrelated] situation".
P.S.: as an anecdote, I just recently used my (minimal) category theory knowledge to change the way I take notes, so that I can smoothly use outlining tools (like org-mode) more like mindmaps when taking notes on complex topics.
Oh I agree completely, didn't mean to give the impression I advocate the "special snowflake" view of the world either. My apologies! My entire field of research is practically based around our predictability ;)
What I meant to say rather, was that while there are definite behavioural patterns, they tend to cluster into discrete groupings, rather than being broad and generally applicable traits that can be used on everyone across the board in aggregate (i.e. a singular "average person"). There are certainly many 'trivial' human traits we all share in common of course, but I've found those to be less helpful in personal decision making situations than more specific correlated traits. But then again, I might be a bit bias given that's my area of expertise :)
One ceo may may look at a worker exhibiting stereotypical output of a "lazy" person and decide this person must not care about their work and thus should be fired. Meanwhile another may see this as a symptom of burnout from caring about their work too much and decide the worker should get some time off to relax. Regardless of who's interpretation is correct, it is a decision than can have a big impact on a person.
The behavioural economics approach is definitely worth keeping in mind regardless of people-reading ability, but we should be weary of interpreting such things as being too 'directly applicable' in anything other than very generalized circumstances. Unfortunately, I've seen my fair share of cases like the example I stated above, so it is worth remembering that there is no such thing as "the average person". Not to say there aren't definite patterns of behavior of course, but that's a whole other conversation.
There actually seems to be somewhat of a Dunning-Kruger like effect when it comes to people evaluation skills. Generally, those who appear the most confident about their people judgements, also seem to be those who are wildly speculative and inaccurate about what other people are thinking.
The key to 'seeing it coming' of course, is to first willingly accept the possibility that something might happen, and then actually look into it. The issue was that many people were just not entertaining the possibility at all, and therefore not bothering to look into it. The information was all there for anybody to see, but this was a case of people missing the gorilla in the room because they were too busy paying attention to the game[0].
[0] http://www.livescience.com/6727-invisible-gorilla-test-shows...
Like how math was a good idea that was applied everywhere from physics to modern medicine and architecture?
Don't get me wrong, it's a decent rule of thumb for a lot of ideas, but for formal languages with rigid structures and rigorous definitions such as mathematical logic, it doesn't quite work. In fact, applying a good idea to an area where doing so would objectively be detrimental, would inherently be not logical by definition.
And That's the power of logic. If followed rigorously, it can actually protect us from going down a lot of inaccurate roads, because doing so means it's also highly probable that you're doing something inconsistent with formal logic. This is the same reason why strongly typed programming languages like Haskell and ML have such a cult following, it's because they prevent a lot of silliness from even starting to happen. It's just a specialized niche case of the same idea, letting people discuss complex ideas in a structured way so that they're easier to communicate and verify. Now imagine if he had that kind of clarity in communication with social issues...
> The idea that facts and logic are everything suggests that we could feed facts into some ubercomputer and the Truth would come out.
That's not necessarily true, and drastically undermines what logic actually is. We already know there are several problems that have been proven to be uncomputable, but that doesn't mean we can't use logic to understand them; logic is separate from computability, and vastly more powerful. Logic is what gave birth to the entire notion of computation in the first place, and there are many math proofs that are logically sound but not computable either. To paint logic simply as something that computers do is a mass disservice to what it represents and is capable of.
The issue is usually not with how logic itself works, but with how people misuse, and more importantly, how people misunderstand it. It is just absolutely tragic how undervalued and widely misunderstood logic is in modern society, despite it having given us so much already.
Discussing things like mathematicians trying to solve a hard math problem would probably help our communications more if anything, compared to say, carrying out discourse like we're all Deepak Chopras...
[0] This idea is described pretty well by the whole "Unreasonable Effectiveness of Mathematics" discussion:
https://plus.maths.org/content/unreasonable-effectiveness
http://www.dartmouth.edu/~matc/MathDrama/reading/Wigner.html
It's a strange world when a startup that was just founded 2 years ago and is steadily growing [0][1][2], is considered a failure because they haven't already wiped out a 22-year-old goliath that has had a long history of struggling to break even, and operates in several other markets (AWS, Streaming Video, Devices, etc) that aren't this startup's main focus.
[0] https://www.snapagency.com/blog/jet-com-vs-amazon-mean-ecomm...
[1] https://www.internetretailer.com/2016/04/15/jetcom-predicts-...
[2] http://time.com/money/4337044/jet-com-lowest-prices-amazon-w...
Also, I would argue that what op was talking about did fall more in line with platforms than algorithms, despite what the libs actually did, because Ethereum and Bitcoin are themselves platforms that spark those kinds of libs. Not to mention that you're always liable to run into situations where some obscure algorithm isn't available in your language of choice, regardless of how popular it is (unless you're using c++, which marketed/encouraged the kitchen-sink approach to development, and has had a lot of time to build quite a few kitchens).
As for interfaces, I'm not sure exactly you mean that hasn't been covered already, like in the case of F# being able to smoothly interface with external data (which also includes the ability to interface with libraries from entirely different languages like R and Python). And interfacing with hardware is also a lot like a platform issue similar to the browser situation, except with C instead of js. And then there's stuff like arduino, which is also very clearly a platform.
All in all, branding and marketing shouldn't be underestimated as the driving forces behind a lot of tech decisions, because software development does have a very strong social component that shouldn't be ignored. I mean, just look at the type of site we're on...
F#'s Type Providers basically make ORMs, query builders, scrapers, web request libs, parsers, etc, largely unnecessary, because they enable the language to have built-in support for fully typed foreign data sources.
Dart meanwhile, makes a large chunk of typical boilerplate js libs like jquery, underscore, promises, requirejs, etc, all obsolete while still being relatively similar to js.
However, js is still the language of the largest platform out there (the browser), and the F# community still doesn't push it's branding and marketing towards trendy startup engineers very much, compared to a community like ruby's.
Let's not forget Purescript[0], which is looking to be the spiritual successor to Haskell, and runs on node.
They shouldn't. Our work is deplorable. Any non-trivial internal codebase would probably give any mathematically savvy engineer nightmares for days. If our office buildings were designed as needlessly hastily the software designed inside them, having our tech hub in an earthquake hotspot would be a serious issue.
Yes, there is something to be said about the convenience of our "agile"/rapid-development cycle, but it's not like we use that power responsibly. We have enough decades-old codebases that have been in a perpetual state of 'fragile legacy-code' since they were first written, that prove that we don't take our designs seriously enough to improve them despite all our conveniences. If building engineers suddenly had access to some magical 'easy-bake oven' for building skyscraper MVP's and making 'agile' changes, I know I'd be concerned, looking back at our track record with software.