kevingoslar

If the thinking was truly "slower", i.e. have less throughput, it would result in fewer insights overall, i.e. lower intelligence. This doesn't seem to be the case since the author describes equal success of these "slow thinkers" to neurotypical ways of thinking.

The problem therefore seems to be more accurately described as having the same insights as others, but they arrive later, i.e. "delayed" insights.

Delayed processing could be an effect of delayed context switching, i.e. monotropism [0]. Monotropism can be an indicator of mild autism.

[0] https://en.wikipedia.org/wiki/Monotropism

I use https://www.git-town.com/nested-feature-branches.html.

No.

Since my original post is now flagged and hidden, what I said is no longer visible and I cannot let these misinterpretations stand unaddressed. I said that not everything that appears like racism or sexism might actually have a racist or sexist background, and might actually be more a random abuse by a dark personality type which hasn't learned to use their powers in more constructive ways yet. For example, abuse as narcissistic supply.

That's not an attempt to downplay or excuse anything but an attempt to understand the underlying causes of problems better since that is a prerequisite for addressing them effectively.

It's beyond me how the statement "most men are actually nice people" could be interpreted as sexist in any way.

I'd maintain that awareness, training, and tooling are essential for achieving constructive outcomes here. Without knowing that one has dark personality traits, and thereby a particular way of experiencing the world and pleasure/reward that is different from how most people experience it, it's hard to not unintentionally develop abusive behavioral patterns. Goals develop from a world view. Improve somebody's perspective and their goals adjust.

Knowing that one deals with a dark personality makes it easier to adjust one's interactions and expectations to them and not fall for possible abuse.

Every problem can be solved with enough understanding.

That's not how dark personalities are defined. With enough training one can recognize them. Relevant video: https://youtu.be/GaeJCA4nRPI

Please note that the article merely encourages the application of some of the best practices introduced by functional programming - strong typing and more mindfulness around mutability and side effects - into all forms of programming.

Functional programming as it exists today takes these ideas to a somewhat extreme form. That has its place and value, but as experience in the real world shows, as long as it feels so mathematical, it isn't everybody's cup of tea. Hopefully, over time we find more intuitively accessible abstractions for the really useful principles that functional programming is based on.

Agreed, sorry for the paywall. Is there a better place to post such stories than Medium?

I also don't expect that a lot of the existing Java code will be rewritten in Go. But there exists a whole array of startups/unicorns today who use Go extensively. Many of them will grow into enterprises. I predict that Go will generally hold up well for them as they scale. They will feel a lot less of an urge to switch to something more mature and scalable like Java, as many companies who started out with Ruby, Scala, or PHP did.

I often see enterprises using a mix of languages and technologies (depending on how independent the different org units within it are) and some amount of Java fatigue in developers who are not retiring in less than a decade. Go is often amongst the top choices they are exploring.

In addition to the right culture, great platforms enable great ecosystems. I have found that putting everything as Markdown on a collaboration platform like Github/GitLab works really well and enables collaboration in a number of ways:

- people don't feel awkward to modify other people's content because there is a collaboration and review process in the form of pull requests

- you can assign different people to oversee different parts of the knowledge base. They make sure the organization of the knowledge base doesn't get messed up by reviewing changes of other people to it.

- you can keep others in the loop about important updates (big and small) by tagging them in pull requests

- verification can be automated via bots and CI, for example using https://github.com/originate/text-runner

Git Town started out as Git aliases written in Bash. Version 3 was many hundred lines of Bash, pushing it beyond what Bash was designed for. At some point it got ridiculous, and we got requests for Windows support, as well as better integration with the Github API. Hence the rewrite in Go.

It shows the Git commands it runs, as well as their output. So, you know exactly what Git is doing.

Hub is awesome, and orthogonal to what Git Town does. You can use both together, though.

Git Town covers a ton of edge cases. Just look at their "features" folder. If something goes wrong, Git Town allows to cleanly abort and undo what it did so far and go back to where it started.

That's a lot safer than the unholy mess that ensues when most people try to run "git reset --hard" or "git push --force" manually.

Good suggestion, will add them! Git Town uses Cucumber as living documentation: https://github.com/Originate/git-town/blob/master/features/g...

Git Town contributor here. Thanks! I love your aliases. That's exactly how Git Town started. Then people kept adding logic to cover edge cases, abort and undo operations, as well as Github and Bitbucket integration. Soon enough we ended with many hundreds of lines of Bash. Hence the recent rewrite in Go.

Git Town is a strict superset of your tools. Your "topic start" == "git hack". Your "topic pull" and "topic-push" = "git sync" (you always want to run both anyways). Your "topic-finish" = "git ship".

Want to join forces?

Git Town doesn't replace Git, nor does it try to shield you from learning how Git works. It shows the Git commands it runs for you, as well as their output. When using it, one should make sure to understand what it is doing.

The thing is, Git is awesome, but intentionally designed as a low-level and generic tool. Using it correctly for particular workflows (like Git Flow or Github Flow) requires running many Git commands for each operation, and is highly repetitive.

Good developers engineer repetition away. Great developers share what they build. Hence Git Town.

Git Town contributor here.

This tool was built to help stay sane in large high-velocity development teams. In such environments, one can easily spend an hour (or so) each day resolving merge conflicts. Feature branches go out of sync with the main development branch multiple times a day. One has to keep pulling, merging, or rebasing all open branches regularly to avoid more merge conflicts later. Those things require running many Git commands.

Git Town makes all of this quick,easy, and bulletproof. A lot of people have been using it for years and love it for that.

Apparently our documentation doesn't get this across well enough. We'll add more details.

There is a way to support both styles at the same time, and most libraries (that I'm aware of) use it. If a callback is given, call it with the result. If not, return a promise for the result. This doesn't require a rewrite of existing libraries, but merely a new minor version.

I don't see how compile-time type checking would help here. When checking out a new library, I read the documentation, or maybe it's test suite, and then use it accordingly. My tests ensure that I use it correctly, i.e. give it types it understands, give it the right data (the id of the correct user account for example), and handle the outcome correctly (i.e. display it in the right format).

JavaScript has run-time type checking, which could be used for automatic promisification, but I agree that's a slippery road, for many reasons.

Great to see that Rails still has so much momentum!

The secret to getting up early and it not feeling like torture is going to bed early. I'm getting sleepy around 9pm, and am in bed between 9 and 9.30pm. Depending on my need for sleep I naturally wake up between 5 and 5.30am. Melatonin has initially helped me get to bed early, now it happens naturally.

That's an excellent suggestion, thanks! Coming soon!

This reminds me of AppleScript. Super easy to read, very hard to write.

Git Town committer here. Our commands output the detailed Git commands when they run. In addition, we provide a summary of what each command does in its man page (see https://github.com/Originate/git-town/blob/master/documentat... for an example).

You have a good point about it being valuable to document the steps run by each command in more detail though. We'll add this, thanks for the suggestion! :)

Btw "git help ship" displays the man page for "git-ship".

It's probably not going to be a rewrite of existing systems, but a switch to new systems written in safer languages while phasing out the old C based systems.

On the server: unikernels. On the client: new mobile platforms, like OSes based mostly on web technologies (which while not quite being there yet are getting more and more powerful).

C/C++ is not only a poor choice in regards to security, but also to develop for hardware with hundreds or thousands of cores, and all hardware platforms are moving in that direction. Yes there are of course ways to deal with that in C/C++, but other languages are much better at this.

Within just a decade or two I can see a fundamental shift away from the old computing paradigm, at least for the majority of systems in mainstream use.

In my experience the by far best state to do any sort of work is being sober, clear minded, and in the zone. What psychedelics help with is expanding perspectives, looking at things from a different angle, getting the big picture, semantically over-exaggerating problematic details like a microscope, breaking away barriers, and shuffling things up.

When done responsibly, with enough processing and digestion after a psychedelic experience, this can lead to trying new approaches, which, combined with hard work over long periods of time, can indeed lead to extraordinary results.

This article misses the fundamental difference between vision and hallucination.

Hallucinations are psychiatric states, characterized by confusion, loss of identity and control, and have a destructive nature.

Visions on the other hand are spiritual experiences, they come with clarity, finding of identity and control about the inner and outer world, and are very constructive and uplifting experiences.

Pantheism. God is a word to describe the wholeness of reality, seen as a single living being (the One). "Living" here means complex, intelligent, interactive, responsive, loving, joyful, prospering, creative, amplifying, mysterious. To me (PhD, philosopher, entrepreneur, developer) these are the best attributes to describe the world I live in. Science describes this world in excruciating detail and beauty for my mind, religion makes the same available for my intuition.

If I would say "I don't believe in God", I wouldn't be talking about God, because then I no longer talk about the One, but about two things: myself and God. Then I merely criticize my own limited image of God. Which is fine.

Besides that, my religion is a school for love. Loving is tricky: strong emotions, complex beings with individual edges and blind spots, very close to each other, causing friction. Much more tricky than for example driving cars. Yet, we all agree that attempting to learn to drive cars all on our own is not a good idea. Sure, like love, in the end driving cars is about developing intuition and following our instincts, and we can make it work somehow after lots of bruises, but its better to have some guidance and mentoring along the way. We need to learn about the basic rules that make traffic safe, or we'll end up hurting ourselves or others. The same is true for love. Wisdom traditions that provide guidance on how to love (aka religions) are useful tools that add value here.

God is the "primary" source of everything. If God were created by something else, then we aren't talking about "God" anymore, but a part of God.

In my humble opinion most of the success of the open source movement comes from the economics of open source software, and not the licensing. Because unlike physical goods, software can be copied, and thereby given away and kept available to myself at the same time. That creates a situation where sharing software is almost always the better opion than not sharing it (cheaper, easier, faster, stronger etc).

If somebody creates a complex non business-critical piece of infrastructure, they have incentive to open source it. Because By doing so they can still use it as before, but get bug fixes and additional features for free from the community.

If I create an improvement for that open source code base, I also have an economical incentive to share that improvement back to the maintainers. Because I too can give it away while keeping it. If it gets merged, others maintain it for me, and all future updates to the software already contain my improvement. If I keep that improvement to myself, I have to patch all future versions of the software myself, which becomes harder over time as the software changes. Giving my patches back makes my life easier than not doing it.

I'm not against the idea of GPL, and the good intentions it has. It was necessary and good at the time. Some might still seem it necessary for philosophical or spiritual reasons, and that's okay. But most open source software that I'm aware of today, the majority of the open source revolution that the industry is experiencing right now (except for the honorable Linux) seems to be driven more by the economy of software sharing than the contractual requirement to do so.