> (a) an argument helping my thesis by showing that you can program functional languages quite well by using mutable recourses
Let me preface this by revealing that I'm neither a functional programmer, nor am I convinced that functional programming or immutability is any sort of silver bullet.
Your original thesis was that "a data structure cannot be functional," which you later defended by saying "git is only immutable on the meta level, its implementation uses mutable files", which, while being 100% true, is also true of the category of programming languages we call "functional" as they rely on mutable RAM. That is what the GP has been trying to explain to you, but your obvious hate for anything labelled "functional" makes you blind to all this.
Sorry mate, you just have to concede the point here. This is not a discussion about whether functional programming is any good, which is what you seem to be treating it as.
While what you say is technically accurate, I think you're missing the bigger picture here. The author's point still stands: git's commit history (arguably the most important part of a version-control system) can be viewed as a purely-functional data structure, and that view has practical benefits too. I tried to explain more here: https://news.ycombinator.com/item?id=15892013
> "Look! It can be mutated! Therefore it cannot be functional!" And the response to that is, "Don't be so technical about how you define functional. Or immutable. You know it when you see it."
I think I can offer something to the discussion here, as I'm straddling the 2 camps - having a fairly intricate understanding of git (I've held training seminars at my company about it), and basic familiarity with functional (technically "persistent") data structures thanks to a long-standing interest in Clojure.
What the functional camp is talking about, when they refer to git as a "purely functional data structure", is the core of git's implementation - commits are immutable snapshots of the repository arranged in a directed acyclic graph (or a tree, if there are no merge commits), and branches are "just" movable pointers to some commit. In this view, everything other than this core model of history as a graph is extra details layered on top.
The other camp (let's call them the "git camp") looks at git in its entirety, including branches, tags, the index, the working tree, stashes, and so on, and they can't help but come to the conclusion you mentioned - "Branches are mutable references! The index is mutable! The working tree is mutable! How can git possibly be called a functional data structure?"
While this 2nd perspective is understandable and technically correct, I think it misses the point the other camp is trying to make: that the immutable commit is the "fundamental unit of git" so to speak, that we interact with everyday, and that most of git's history-manipulating commands (git commit, git commit --amend, git rebase, git merge, git cherry-pick) can be described in terms of purely-functional operations on the commit graph. Once you understand this, many complex git scenarios become easier to understand (rebase, and filter-branch, for example), so this view does have practical value. Then branches, tags, the index, stashes, etc can indeed be understood separately.
In fact, this perspective of git as a data structure is so useful, that I rarely use "git log" as it is, preferring these additional flags to view the entire graph instead:
The commit is immutable because when you "amend" a commit, git actually creates a new commit object, assigning it a new SHA1 hash. This means that the original contents from before the amend (i.e., the "old" commit) are still accessible via the old SHA1 hash - proving that an "amended" commit is actually a copy of the old one, not an in-place mutation.
Think of it like this - if I copy a text file and edit the copy, would you say that I've "mutated" the original file? No, right? That's what git does - it never actually mutates a commit :)
EDIT: to clarify further, git identifies each commit with a unique SHA1 hash which is assigned when the commit is created, and that hash depends on the contents of the files + the current timestamp + the SHA1 of its parent commit + some other things. Which means, if you try to edit the contents of the commit in any way at all (or even if you create another commit with the same exact files at a different time, or as a child of a different commit), its SHA1 hash will be different, i.e., it is a new commit by definition.
I see your point. But I'll take the liberty to use part of your comment as my own response: "You can certainly find snippets that are simpler in Ruby than in Python, and vice-versa". Now that is something I 100% agree with (I added the part after the comma btw).
Basically what I'm saying is that the differences are very minor compared to differences vs, for example, other languages (Java, Scala, C++, etc). So from that perspective there's not much to complain about. I just have a slight bias towards Ruby, I find it a little more readable (in a small way).
Care to elaborate with an example? I use Python day-to-day and did quite a bit of Ruby a few years ago, but I fail to see significant differences in verbosity.
What I do see is that Python is somewhat less consistent and readable (list comprehensions beyond the simplest ones are unreadable, Ruby's blocks allow cleaner DSLs, len(a) vs a.size, little things like "3.times", allowing "?" and "!" in identifiers). But Python has a bigger and more diverse ecosystem. So although I would prefer Ruby over Python, the ecosystem aspect makes the point moot.
I cant , and could never understand why this is, and if it is a problem.
Github, Basecamp, Twitch, Stripe, Square, AirBnB, Shopifly, Cookpad, and many more. All these are very successful site that are using Ruby ( Not necessarily Rails ) and most of them profitable.
If each or them could fund a 20-33% Salary of an additional Core Dev you instantly have 3 - 4 people working on it Full time.
So I have been thinking on this for sometime, It is because the Ruby community and the world as a whole does not want to donate? Or are we lacking someone to push this and ask for some help when needed?
Especially interesting when you compare to Python, which is used extensively by Google, Dropbox, Instagram, Pinterest, Reddit, Youtube.
Of those I know both Dropbox and Google have employed Gudio Von Rossum, and various other Python core devs are also employed full time.
Overall it seems that Python is much more community driven than Ruby. Python is interesting in that it has several big camps, including web dev, systems programming/automation, scientific usage, machine learning, etc, and all of these communities are fairly self sufficient but also contribute back to the main language.
Well that's exactly what is happening these companies employ people who work more or less full time on Ruby core issues. A lot of Ruby features are funded by big corps. The 3 people are just the 'core' core team. Like Linus did for Linux for years
Agree with Sujan, I found it very confusing too. At first glance it seems like the switch's 2 states are "Now UI Kit" and "White", which of course makes no sense. Only when I clicked it did I discover the other state.
I think you could add some space on the left side of the toggle and maybe show the "Orange" label there, or at least just add the space so it looks separated from the "Now UI kit" brand label.
In a different context, I would totally upvote your comment, but in Now UI's case the contrast is extremely low and gondo's argument is quite valid. See my comment elsewhere [1] for hard numbers on the contrast.
For the record, I have such a screen: a Samsung SyncMaster B2030, about 6 years old. Several of Now UI's widgets (form placeholders, disabled input labels, tab labels on white background) are nearly unreadable on this screen.
I actually checked (using [1]) the contrast ratio of some of these widgets, and they work out to very low numbers:
- Form placeholders - #ddd on #fff - contrast ratio 1.4:1
- Labels of disabled checkboxes - #9a9a9a on #fff - ratio 2.8:1
- Tab labels - #b8b8b8 on #fff - 2.0:1
This is far lower than the W3C's recommended minimum ratio of 4.5:1 [2] for text smaller than 24px. And since the font weight is often lower than normal, the perceived contrast ratio is even lower than the figures above suggest. I think the contrast needs major improvements for decent UX.
I agree with many of your points, but that casual dig at semver is unwarranted and reveals a misunderstanding of the motivation behind it [1]. Semver defines a contract between library authors and their clients, and is not meant for deployed applications of the kind being discussed here. Indeed, the semver spec [2] begins by stating:
> 1. Software using Semantic Versioning MUST declare a public API.
It has become fashionable to criticize semver at every turn. We as a community should be more mindful about off-the-cuff criticism in general, as this is exactly what perpetuates misconceptions over time.
Let me preface this by revealing that I'm neither a functional programmer, nor am I convinced that functional programming or immutability is any sort of silver bullet.
Your original thesis was that "a data structure cannot be functional," which you later defended by saying "git is only immutable on the meta level, its implementation uses mutable files", which, while being 100% true, is also true of the category of programming languages we call "functional" as they rely on mutable RAM. That is what the GP has been trying to explain to you, but your obvious hate for anything labelled "functional" makes you blind to all this.
Sorry mate, you just have to concede the point here. This is not a discussion about whether functional programming is any good, which is what you seem to be treating it as.