Setting aside feelings one way or the other, posting this because the default behavior changing is bound to bite somebody in the next month or two. If anybody knows what minor version is going to start doing this, post here so we can know what to check git --version against. It appears this is landing prior to git 3.0.
Quoting from the mailing list discussion:
So we need to make sure existing users know that they can add:
[init]
defaultBranch = master
to their ~/.gitconfig if they want the legacy behavior
In case you need to support legacy scripts or muscle memory.
git config --global init.defaultBranch master may also work, but haven’t tried it on my machine.
Wait, I thought that init.defaultBranch was the compromise, to avoid renaming the default branch in Git, while still allowing those who feel uncompfortable by it to avoid it as much as possible?
Are there any statistics or scientific attempts to qualify how much of a problem this is? It’s probably my fault, but I find it hard to imagine that if someone is in the need for version control, will learn all the basics up until the point where they see the word “master”and give up, not because of direct racism, but racism by association.
Non-technical issues like these are never easy, but there should at least be some discission where one position is designated as the morally superior before a word is said.
Semi-serious question: How do we know that? I’m going to guess that the people who decieded to use “master” in version control systems didn’t do this out of mallace, but just because the phrase seemed appropriate. So how can we be sure that main won’t eventually fall our of favour? I remember that at the beginning of 2015 Elementary OS wanted to release a new version called “Isis”, afaik in reference to the egyptian god, but then the terror group in ISIS gaiend power and a more or less inncoent name became very controversial.
And does “shorter” and “simpler” even matter? Almost everyone uses autocompletion in some form or another, and it’s not something you use as often as “git commit”.
Ok, fair enough, but let’s twist the question again: How do we know that everyone has a seat at the table? What if there is a language or a culture where main has a different meaning (a simple but unoffensive example is in Germany, where Main is a river)? Apparently there were no black people, or people “decendents of slavery” to be exact (because not all back people were slaves) were present when the term “master” came into use, to correct this issue early on. But then on the other hand, if I remember correctly, make still uses tabs instead of general indentation, beacuse Stuart Feldman didn’t want to disrupt his userbase of at most a few dozen users.
I intend to show that the argument is internally inconsistent. We cannot simultaniously assume a kind of standpoint theory, by which there is always a posibility that a term is (objectivly) wrong, but at the same time be able to suggest an (objective) replacment for a (subjective) offense.
A simpler understanding, that does not run into these problems is that offense is determined by intent, not by the nature or the etomology of a word.
At the same time, I don’t think that people advocating for this change are arguing on this level. Any reference to this logic is handwaving, but the motivation appears to be something else, which I would either guess to be some kind of at best false pragmatism or at worse opportunism.
(I apologize if I misinterpret your comment, English is not my first language and I am trying to understand your comment)
a group X used a terminology to undermine/subjugate a group Y in the past, the group X is much smaller now but it still exists.
the change happening here is removing that specific terminology because group Y today is reminded of the past treatment.
and is your argument is that, since we don’t know that the new terminology wasn’t used to undermine any group in the past, the change is fruitless as we might need to change it again?
or that since the terminology was also used in other contexts by people not in group X, it should be okay to continue using it?
As I am neither a member of group X or group Y, my opinion is that if the change results in more people being comfortable using tool, we should definitely do it.
First of all, and I don’t know why this has to be said: Slavery didn’t exist because it was called slavery, it existed because the society reproduced the conditions under which people were slaves.
and is your argument is that, since we don’t know that the new terminology wasn’t used to undermine any group in the past, the change is fruitless as we might need to change it again?
or that since the terminology was also used in other contexts by people not in group X, it should be okay to continue using it?
I explained the further in a sibling comment, that on the terms of the argumentation, it is imposible to say that main is better than master, because perspectives cannot be compared or have any common point of reference. Since this discussion is not based on any hard evidence, we cannot derive any emperical conclusion like “this will make more people comfortable”, since we are talking about idealized, aggregated perspectives, produced by a worldview that has ever increasing problems to explain anything that is happening, hence the focus on such things like “master/main”.
I find it not to be only a “thought experiment”. The questions are on point. No data (if any, I would like to see it) to back up claims that people are offended by these words results in such major changes for everyone. At least that needs to be pointed out.
OP is leaning back in their armchair imagining the theoretical universe in which the broader German community is coping with the upsetting rivered associations with “main” as the new default git branch. I suggest they apply their philosophical leanings to the actual real world in which it turns out a sizeable community of real live humans prefer to dispose of master/slave language where possible in discussions with their terminal.
Please re-read my comment, the “main” example was just to give an example due to limited perspectives, we cannot know what our actions or decisions mean from other perspectives. I explicity said it was harmless, but if you want something better, consider @caleb’s example.
I suggest they apply their philosophical leanings to the actual real world in which it turns out a sizeable community of real live humans prefer to dispose of master/slave language where possible in discussions with their terminal.
How can you know that? Where are the statistics? Where are the polls? How did we figure this out? When did we figure this out? This is just postulated, and nobody goes into it. And I have a hunch that this is because if you were to actually find out what most people belive, that it would not be what you want to think they do. But that’s just by unprooven hypothesis.
I’m not going to debate you because you’re displaying a preference for thought experiment over an engagement in reality, which not only suggests a closed mind, but also that you simply don’t have sympathy for the real issue at hand. @caleb’s “example” is a much less veiled form of the same type of trolling you’re unwilling to let go of.
You wish to model reality, but no modeling is required to understand this issue. We’re here because we’re here. This is a real conversation which is taking place in the real world for several years now. You’re attempting to place the burden of proof of the existence and size of a community on that exact community itself, which is existentially large and significant enough to make the issue stick broadly across numerous open source projects, GitHub, and now the git project itself.
This is just completely illogical. If you want to go do your own research and develop some set of quantitative metrics in an attempt to quantize a complex social issue which is unfolding as we speak, then go ahead and do so. It’s not going to change what’s happening.
As already stated, I just want to explain why the position is incoherent, and as everyone knows, ex falso, quod libet. You have already dismissed everyone who is questioning it as a troll, declare the issue as obviously setteled and then proceed to moralize it by claiming those who don’t agree have no sympathy for the real issue at hand – but of course, we are have a closed mind. I am honestly disgusted by this kind of behaviour, this dishonesty and the smug superiority you emit. Please stop and consider what you are doing, and why you feel the need to behave the way you do.
You wish to model reality, but no modeling is required to understand this issue. We’re here because we’re here. This is a real conversation which is taking place in the real world for several years now. You’re attempting to place the burden of proof of the existence and size of a community on that exact community itself, which is existentially large and significant enough to make the issue stick broadly across numerous open source projects, GitHub, and now the git project itself.
This could be accomplished by a small group of PR professionals who don’t actually care about racism, but recognize a potential upside for their company while the cost of changing a default is distributed throughout the open source community.
The real story here is that GitHub made the change unilaterally, and git followed suit. One might consider the depth of anti-racist feeling that would drive a company to make this change while continuing to partner with ICE, DOD, and police departments around the country.
i was there when we named elementary OS Isis and i was also there when we named it Freya.
from what i remember, no one was concerned about optimizing the name, we were more concerned about not hurting people who themselves or their families had been impacted by Isis.
I am 110% proud of our decision.
(taking the elementary OS dev hat off)
I found main to be a better choice, i am used to using mainline at work now (because of perforce legacy repos) and don’t even notice a difference.
But considering that the same would apply again, ad infinitium, we cannot say we will ever find a good name. And at then, what is the point? Either we go on forever renaming every time someone complains, at technical expense, or we claim that this renaming is more important than others, because one offended group is more important than others, which I don’t think that the people arguing for this want to argue.
I don’t think anyone is claiming that main will be the perfect name forever. If at some point in the future main becomes offensive, then we could change it again. I haven’t found any evidence that would lead me to believe that git would be changing the branch name on a monthly or yearly basis, so I don’t think there is a high cost here.
forever renaming every time someone complains, at technical expense
Uh, we work in software. Everything changes all the time at technical expense. Updating your dependencies could break your app (even if the API doesn’t change), products get deprecated, new products get created. I don’t see this much backlash against Apple changing their CPU architecture and that’s gonna cause a lot more trouble than this change.
But that makes sense because the real issue here is ideology, wokes vs anti-wokes. We’re just pretending it’s technical. I think it’s fine to argue the ideological issue. I don’t think people are automatically racist for not liking the change. I just don’t think the technical argument holds much water.
I don’t know how Apple is going to handle the migration, but I suppose they have tooling to make it easier, the kind of tooling Git lacks.
Those conversations might also be more private.
As for tech expenses, you’re correct in that everything comes at an expense.
Is it therefore justified to impose more of it on others?
Maybe that’s an important ideological question as well?
This doesn’t have to be all about how git has a master branch to signify “the master copy”.
See also: how master hosts usually perform more work than slave hosts (to counter American slavery connotations) or how offensive “blanket exception handling” and “collaborators” should be (in cultures treated with “less thought” than American slavery).
Master is more precise, traditional, doesn’t break anything, and has no negative connotation in this context, or most other contexts.
Main does not make me feel welcome, it makes me feel like I’m being forced to bend the knee to a mob that can’t or willfully choose to not understand English. It makes me embarrassed to be in this field. Admitting that feeling means I deserve to feel bad anyway though, so whatever.
Tradition should not hold back progress. There are more descriptive names out there. For example allow/deny is better than black/whitelist, parent/child is better than master/slave. I understand people are resistant to change and humans are creatures of habit (energy conservation) but this is a simple name change where there’s more advantages than not and people will get over it after a few weeks.
Sorry about your child abuse, or are you simply virtue signaling? If you feel strongly about it then you can message the maintainers of the software you use to alter the names, otherwise why bring up a “whataboutism” argument.
That you consider it valid shows the futility of choosing names to please everybody.
The master slave relationship is not the same as the primary secondary relationship, nor the parent child relationship. Sometimes master slave actually describes the subject matter.
And sometimes the master copy of some source code should live on the master branch. Many people only commit to master when they are certain of their work, while they use another branch as their main branch. Kind of presumptuous, calling the default branch the main branch, isn’t it.
Hold on, it’s not possible to win an argument about inclusiveness by saying that the other person is broken. Or even pretend that there is only one way to view things. We have to learn to communicate better and see the other person’s point of view.
No, @yawpitch is quite on-point. This isn’t about “winning an argument”. Those with any decent capacity for nuance, critical thought, and self-reflection will note that “main” draws fewer negative associations than “master”. Those with unconfronted reactionary cultural/emotional anger stemming from the strawman “woke mob” fantasy will come up with a contorted bad-faith “arguments” a such as “the word ‘main’ makes me feel unwelcome”. You gotta call bullshit when you see it.
First off, this isn’t an argument about inclusiveness, it’s at best a debate about semantics, and since there’s no cognizable or remotely valid viewpoint that can distinguish “master” in the “traditional” sense being described above from its root association with human bondage, it’s not even a very sensible debate. No such valid viewpoint, with no pretense involved, exists: the word has several long-standing definitional meanings and the one involved here is fundamentally and absolutely inseparable from the notion of master / slave dynamics by which it derives any meaning whatsoever to the cause of version control. To try and empathize with any countering point of view is absurd … it’s a word, its meaning is simply a fact, and that fact is not open to meaningful and intellectually honest dispute, without descending into the interminable Hell of “alternative facts”.
The semantic dispute thus settled the only question, then, is is the community, right now, okay with that semantic baggage being carried further forward, or is the community prepared to make a break from that historical association? Personally I’d say that’s also a moot point … it’s been de facto settled by Github and the very reason the patch detailed above exists is because the network pressures of the downstream are driving an upstream change because YES the community is ready to not be exclusive any longer.
What remains is for individuals who are not comfortable with that linguistic and cultural evolution to, frankly, grow up and un-break themselves of their lack of empathy … the point of view of the “tradition” argument has been heard to death, it does not need more empathy heaped upon it.
I stand by my point: if you – and I’m using the most generally inclusive meaning of “you” here – feel that you’re somehow more included by “master” and less included by “main” then something is deeply and dangerously flawed with your emotional apparatus. The only colorable arguments against this minor default change are inertial, as in you either don’t want to invest the time required to update existing repos or you don’t want to engage in the effort needed to reprogram some muscle memory for future ones. Those are the available arguments. They’re just not very good ones.
Maybe OP doesn’t know everything you do. Git is being used all over the world, in different types of cultures, and this seems like an American problem at heart. If they feel like this change is being trusted upon them, and on top of that they get vilified when they want to talk about it, it’s not really helpful to generate a common understanding. It doesn’t mean that they are broken, they just have a different context from you.
I feel like a better line of discussion would be to give out concrete instances where this word has been a problem. Or actually, even ask why OP feels like they do.
OP made their context quite clear with their phrasing:
Master is more precise
… only when understood as an explicit reference to master/ slave dynamics …
traditional
… which is automatically a claim of being “inside” the dominant cultural context …
doesn’t break anything
… privileges the idea that the status quo isn’t already broken, which it is if you find the master / slave connotation at all problematic …
and has no negative connotation in this context
… no negative connotation to OP; the phraseology has an extremely negative connotation to me, and I am most certainly not alone: you keep suggesting I need to apply more empathy to someone who’s denying my very existence…
or most other contexts.
… can someone please enumerate the many and varied contexts in which master / slave has no negative connotation from the perspective of anyone who has been a slave, or whose family history was affected by slavery. I can affirm that I’ve personally got a great many friends in a great many contexts – including well outside of America – who see the problem with “master” as default.
I don’t need to understand why OP feels like they do … I need only identify that the feeling itself is unworthy of consideration in the political choice at hand… it is impossible for any rational being that both understands English and is armed with minimal historical context to see “main” as more exclusionary and historically problematic than “master”, hence we need not engage with any such view that happens to be espoused at all, except to point out its obvious and manifest flaws.
I guess I didn’t get notifications for this continuing discussion. I’m on mobile and also don’t really care to keep this going, but I do want to clarify that I mean more precise in the sense of “master recording” or “master copy”, as in the source of truth from which copies are derived.
I can’t tell if you already read it that way, and believe that usage to itself be derived from slavery, or just think I’m directly defending the master/slave dynamic.
Both of those usages — arguably they’re the same usage — rely in their entirety on the master / slave semantic for their meaning. Indeed no semantic value can be extracted from
either without knowing that relationship exists, at least implicitly. A replication master makes no sense without duplication slaves, and that’s exactly what we called them in the bygone days of glass / nickel masters in optical pressing and tape in replication farms. Even before tape and indeed wax cylinders the master mold of foundry and pottery days was there to be used to direct the toil of those making exact copies, as it were, slavishly, with no independent freedom allowed in the work. They’re utterly inextricable from the historical institution they took as their model.
As I’ve said before there’s is not now, nor ever can be, any legitimate argument to be made that separates usage in version control from the historical idea of the privileged master and the slave(s) that follow.
it is impossible for any rational being that both understands English and is armed with minimal historical context to see “main” as more exclusionary and historically problematic than “master”, hence we need not engage with any such view that happens to be espoused at all, except to point out its obvious and manifest flaws.
I’m totally with you, though based on the extent of some of the involved philosophical gymnastics into symbology, original intent, and sociology on the “other side” thrown in the face of the simple actual sizeable live human community looking to stop promoting “master” I’ve gotta conclude that these folks are ultimately motivated by a certain emotional bias…
In many uses of master/slave in computer related things, it is actually a poor analogy. Often a “master” does all the work with the “slave” sitting idle waiting to step in only if needed, Other terms like prime and replica can be a better fit anyway. parent/child has a connotation of the parent spawning the child which works for, e.g. processes but not in other cases. In the case of git, there isn’t even a corresponding “slave” concept, only “branches” - In my mind, I wouldn’t even connect that use of the term master to slavery, but I’m not American. In any case, the subversion term “trunk” was better to begin with.
Trunk is a good term. I can understand a change to Trunk.
In the book 1984, a major plot point is the reduction of language to reduce the complexities of expressable thought. Words meaning only one thing, like master only meaning “of a slave,” is an example of this language reduction.
The name trunk like in SVN is ok but I still think calling it main is better overall because of it’s shortness and detachment from it’s controversial origin.
Perhaps your expectations of congressman is so low that the ability and initiative to use a website to do research is the more surprising part, because it doesn’t take a lot of familiarity with Github to perform a search. He did sound familiar with programming on more than a surface level, however.
His mention of DoD practice leads me to think he picked this up as an intelligence officer. You don’t have to be an experienced developer to recognize high-level risks. Extrapolating from a single point of experience working for a former I.O. for several years, they have a keen skill for picking through details.
About half my computer science lecturers at university were older than that, and they were all familiar with git. My dad’s about that age, and he’s familiar with git.
57 isn’t actually particularly old. Many of the pioneers of computer science have died of old age at this point. We’re well past the point where programming or computer science is a ‘young man’s game’ in any reasonable sense.
The number of programmers doubled roughly every 5 years for a long period of time. Possibly from the beginning up until recently. This suggests that there are 64 times more 25 years old programmers than there are 55 years old programmers. Yes, all the pioneers are now old. But they were exactly that: few pioneers.
Programming has never been a young man’s game, but this exponential growth skews the numbers like crazy, and make it appear like a young man’s game. After all, if the only thing you know about someone is their age, the older they are, the less likely they are to have learned programming.
there was definitely a dip in the rate of CS enrollment after the dotcom bust in 2000, but then numbers of both major and nonmajor CS exposure has seen a massive surge since 2005
I wouldn’t expect that the average 57 year old has a better or worse idea of git than the average 21 year old. People often claim that young people are better with technology. In my experience, they tend to not be at all.
Good point! My bias is showing (growing up where I did, the only people I knew who knew about computers were my age). This makes me hopeful that I can still be programming well into retirement age :)
Lol I didn’t notice the tie. Purely a political yuck. He’s proud of bombing Afghanistan, pro-trump tax cuts, pro-deregulation, and anti-gun control. ¯_(ツ)_/¯ to whether his staffer gave him talking points on rust and javascript.
I think it’s odd to list “interviewer time” as an issue with the current system and then offload a day of work onto the interviewee as if the current process isn’t expensive enough from that angle.
TLDR: Author used several bad IDEs, which crashed to the point of rebooting so that restarting after a reboot alsotook a long while.
Well, now I really want to know on what kind of potato the author was running which IDEs. JetBrains IDEA is not lightweight but I’d used it for 4 years on an x230 (ok, i7 with 16GB and SSD) without any problems. Multiple projects, multiple languages, multiple VMs running at the same time. Now I use QtCreator and it’s a joy.
Not using IDEs is fine, but the concept of an IDE is absolutely not the problem here.
You never have not any problems ;) But I’ve definitely had less problems than when using non-IDEs. (Sure it crashed once in a while or was stuck at “indexing” - but it’s given me less problems than, say, my browser, IRC client, mail client or anything else. Maybe I was just lucky :P) But just opening many files and switching between them multiple times per minute, resplitting panes, etc. It’s doable in vim/tmux/etcc (for me) but there’s no “intuitive flow” and forget about plain editors.
JetBrains has some quality IDE’s. For me, PhpStorm has features that I haven’t found in other IDE’s let alone text editors. I’m guessing this is similar to other languages too. For example IDE’s that support and extend hot swapping for Java.
Typescript has become my favourite language for side projects and I’ve even snuck it into the Day Job. The dynamism of JS with a fairly rich type system at “compile” time is a fantastic combination.
I suspect that part of what’s great is that the type system has been built to be expressive enough to capture real JS usage and APIs. Instead of being a static type system imposed on a dynamic languages it’s a type system suited to the language and its users.
Au contraire your au contraire! Static languages have dynamic types, but they’re so weak you need to run a SECOND program just to make sure you don’t accidentally use them!
Not so, some languages are built from the ground up with static types. There’s no way to implement Haskell (typeclasses) or Scala (implicits) without implementing a de facto static type system.
Haskell is built from the ground up with types, sure. In a sense though it is still a series of extensions to the untyped LC. Type classes are type level computation and therefore a part of the type system so their absence doesn’t make a great counter example.
Granted this is all a lot more hair splitting than my original question.
I think the major difference is that some languages expose untyped constructs to language users, while in other cases untyped constructs are just hidden artifacts of a compiler implementation that are invisible to users.
the issue is these terms are vague with conflicting alternative definitions. None of this is relevant to clarifying the second paragraph I was asking about.
Haskell is built from the ground up with types, sure. In a sense though it is still a series of extensions to the untyped LC. Type classes are type level computation and therefore a part of the type system so their absence doesn’t make a great counter example.
What do you mean? There’s no sense in which a Haskell expression like (decode x) - can be understood from an untyped perspective. Both its semantics and its behaviour are fundamentally entangled with what type the expression has.
Granted this is all a lot more hair splitting than my original question.
It’s not “hair splitting”, your original claim is false and misleading.
Further at runtime the type information about a generic parameter is almost totally lost, you need to have an instance to base type information off of. There are real weaknesses with bolting strong typing onto dynamically typed runtimes.
From the perspective of someone who’s written multiple ORMs and other serialization frameworks … this is objectively wrong. You need to know what fields are on an object, and be able to call into generic functions with strongly typed parameters to make sure things like interfaces are still satisfied.
Typescript is a step forward for javascript devs but it is still very, very lacking compared to something like golang even.
Take a look at how ORMs and serialization frameworks are implemented in Scala or Haskell sometime. Implementing those things requires ad-hoc polymorphism, but that can be done at compile time rather than at runtime, via typeclasses or similar mechanisms. This is better for maintainability and understandability of code than doing runtime reflection on reified generics, because it makes the distinction between parametric and ad-hoc polymorphism visible to the programmer - one can immediately see which functions will always follow the same code path at runtime, and which maybehave differently for different types.
You get compile-time guarantees with reified generics too; and they end up being safer and more expressive (and faster in a lot of cases). I’m not sure what you’re arguing for other than less expressive systems are easier to understand.
A lot of guarantees the reader would expect from a parametric function can be violated if that function uses runtime type information. https://failex.blogspot.co.uk/2013/06/fake-theorems-for-free.html gives a few simple examples - const3 is only possible to implement because the types are present at runtime. The only thing that reified generics give you compared to erased generics is the ability to implement functions that use the mechanism that const3 uses, and such functions are a bad idea.
(There are problems that you might assume could only be solved by writing functions like const3 - you mentioned ORMs and serialization - but actually it’s perfectly possible to solve those problems without reified generics)
I’m an ORM. I see a type. I need to create a binder at runtime to take a database row result and map it to the fields on that type. I can either have the user create mapping functions to do this manually, or I can examine the type, dynamically emit that mapping function for them (in .net you can do this with IL/Lamda.Compile()), saving the developer a lot of steps per type.
One runtime approach creates a lot of manual work for the developer. One does not. The second order affects that reification creates for functional programming (specifically the corner cases you outlined) do not outweigh the other benefits of having full type information at runtime. Especially in a runtime that can dynamically emit and load types.
I’m an ORM. I see a type. I need to create a binder at runtime to take a database row result and map it to the fields on that type. I can either have the user create mapping functions to do this manually, or I can examine the type, dynamically emit that mapping function for them (in .net you can do this with IL/Lamda.Compile()), saving the developer a lot of steps per type.
Again, look at how this is done in Haskell or Scala. You put a typeclass constraint on your loader function, and the language uses typeclass derivation to generate the mapping codepath at compile time. You get the safety of compile-time type checking, but the developer doesn’t have to do any extra steps (depending on the language they might have to add a marker like deriving (DatabaseMappable), but they never have to manually implement the mapping functions).
First of all, I’m working on other problems. Whereas I used to do a lot of work that was very easy to map to numpy operations (which are fast as they use compiled code), now I write a lot of code which is not straight numerics. And, then, if I have to write it in standard Python, it is slow as molasses. I don’t mean slower in the sense of “wait a couple of seconds”, I mean “wait several hours instead of 2 minutes.”
So, basically, the author is solving problems Python isn’t good at. So, great - use another tool, Haskell or whatever. I do not see how this says anything useful or interesting about the language itself other than “Python is not optimized for solving numerical problems not addressed with numpy”
It’s OK. The mainline compiler doesn’t have vectorization by default yet. See https://ghc.haskell.org/trac/ghc/wiki/SIMD/Implementation/Status . For some classes of numerical algorithms, you can expect performance on par with (unvectorized) C. For algorithms that are inherently mutation heavy, I generally find that making Haskell exactly as efficient as C removes many of the benefits of using Haskell in the first place. That’s fine for library writers but not great for end users.
Haskell’s main strength wrt speed is that you can compose high-level things and the abstraction overhead will be unreasonably small. If you’re churning through gigabytes of data per second, you can write Haskell that’s almost as fast as really well optimized C for a small fraction of the effort. However, I wouldn’t really describe the problems this works well on as “numerical”. When I think of “numerical” I usually thing of lots of mutations on big matrices, for which I would rather use Numpy or something. Haskell’s good for many of the things numpy isn’t.
I may be wrong but my understanding was that haskell does have library support for generalized stream fusion which gets very good performance without having to write particularly clever code.
“Type theory is a theory of computation that classifies programs according to their behavior, rather than their structure. Types are themselves programs whose values stand for specifications of program equivalence.”
I had to stop right there. Most of us in imperative languages using types use them or structure. Especially in terms of structs or objects. This says types have nothing to do with structure. Makes me wonder if that’s inaccurate or type theory doesn’t cover what imperative/OOP programmers normally call types. Or do they have another definition of structure outside the mainstream definition. I have a feeling a certain amount of confusion that happens in type theory discussions might have started right there.
An example of something that structural interpretations of types have trouble with is equality of functions. Many programming languages have a very limited or outright broken notion of function equality, but it’s important if you want to prove a program conforms to a specification. It’s also important to have a language for what function equality means. Are a quicksort and a merge sort equal functions?
Bob Harper is both the author of this blog post and PFPL.
Type theory is a theory of computation that classifies programs according to their behavior, rather than their structure. Types are themselves programs whose values stand for specifications of program equivalence.
I took “behaviour” to mean the ‘externally visible’ aspects of a value/program. For example, that something with function type Foo -> Bar can be called with a Foo value to produce a Bar value; that something with product type Foo * Bar can be projected to give both a Foo value and a Bar value; that something with sum type Foo + Bar can be projected to give either a Foo value or a Bar value but not both; etc.
I took “structure” to mean the ‘internal’ aspects of a value/program. For example, the different parts it may be made out of, any functions/computations that it uses (delayed or already completed), the syntax it was written as, etc.
In this sense:
We can make these “behaviours” as complex and precise as we like, by making the types more complex and precise. For example, with dependent pairs and functions we can encode arbitrarily complicated mathematical relationships between values, inputs/outputs, etc.
We can’t use types to classify the “structure” of a value/program.
As a provocative example, we can think about a value of product type Foo * Bar. We might think that the type tells us some ‘structural’ properties about the value, like “it contains a Foo” and “it contains a Bar”, but that’s not quite right. All we know is the “behaviour”, that we can project the value to get a Foo and a Bar, but we don’t know what will happen during that process. For all we know, the value might be an integer plumbed into an ‘unpairing’ function, like with Cantor pairing or Goedel numbering. Should we say that such a value “contains” a Foo and a Bar? What if that same integer is also used elsewhere to generate a boolean, a list of bitmaps, etc.? We’d at least have to weaken what we think of as “containing” or “structure”.
One example which I’ve heard discussed about type theory as opposed to set theory, is that in set theory we can (and very often do) ask whether a value is contained in a set, e.g. foo ∈ {foo, bar} and foo ∈ {high, low} are propositions which may be true or false. In type theory we can’t ask whether a value has a particular type, e.g. foo : (Foo * Bar) and foo : (High * Low) aren’t true/false propositions; they’re logical statements, which may be well-typed (valid) or ill-typed (invalid).
This is important for the “behaviour” vs “structure” distinction, since in set theory we can distinguish between isomorphic sets, e.g. {foo, bar} and {high, low} are isomorphic (they “behave the same”), but the foo ∈ x predicate is true for one and false for the other (they’re structured differently). Since type theory doesn’t let us do this, isomorphic types are indistinguishable (within the theory), so we can only reason about “behaviour”. This has connotations for modularity, reusability, optimisations, etc.
You’re right that the types discussed in here are not being used in the same way that types in many c likes primarily use them. The goal is essentially different in scope. C types mostly capture the size of memory required for allocation of something. Types in the type theory sense can capture this idea, but can also contain much richer and complicated concepts in the types themselves.
also aside from PFPL Bob Harper is known for his work on SML and LF
Yeah I don’t think you can do type theoretic proofs in say C# without a lot of work with interfaces and tuples. After all you don’t even have “Product and Sum types”. Heck it’s even hard right now in F# due to the fact that you have to explicitly name everything.
So for example say you have a function which takes a tuple of an int and (bool or string) and returns either a tuple of an int and a bool or and int an a string.
int * (bool | string) -> (int * bool) | (int * string) //this would be the function signature. More amusingly
Old * (dumb | fat) -> (Old * dumb) | (Old | fat) // if I’m old and (dumb or fat) this implies I’m either old and dumb or old and fat
This is equivalent to
A ^ (B v C) = (A ^ B) v (A ^ C).
in logical propositions.
we can the write a function which takes an int and either a bool or a string, and return an int and bool, or an int and string and we know we have covered all possible return combinations.
In this way the function signature, the “Type” represents the lemma and then function itself exists as proof.
This as I understand it is merely the beginning of the whole thing. There’s a good computerphile video on the subject.
re: always be considerate (ABC): while providing a language that does not enforce static types may have been “considerate” for user adoption, it has left us with a world where a frightening portion of major fiscal and scientific operations are carried out in a tool where writing correct software requires a lot of skill.
Maybe it’s considerate and expedient, but is it right?
I haven’t run across it, though I could imagine some contexts where they might be. I might even consider doing it in the future, given the right circumstances. But I think they’re not that likely circumstances. Usually university courses are trying to teach at least two things with a programming language (or language construct): the language itself, and some broader principle, which students will hopefully retain long-term and be able to apply even when languages inevitably change over. So typically Java has been used either as “generic intro-level language” or “OO language”, which Java 8+ streams don’t fit that well into.
In universities where Java’s used as the standard intro-level language, there’s some advantage to continuing to scaffold atop it for further things, because you can assume everyone already knows the basics. But it’s falling out of favor for intro-level classes in favor of Python. So I think you will either see people introducing this “streams” style of programming in Python if the circumstances fit, or else they’ll stick with a more traditional introduction to sequence filtering/mapping/etc. in the context of an introducion to functional programming, in Haskell or ML or maybe some Lisp dialect.
So I think you will either see people introducing this “streams” style of programming in Python if the circumstances fit, or else they’ll stick with a more traditional introduction to sequence filtering/mapping/etc. in the context of an introducion to functional programming, in Haskell or ML or maybe some Lisp dialect.
I’m aware of some libraries that provide special syntax for that in Python, but I don’t think anything other than list comprehensions (and maybe higher-order functions) for this kind of stuff is considered “Pythonic”.
I did much the same but tried to introduce names in the same places as in the original; as relatively idiomatic Java that’s:
public class Triangles {
public static void main( String[] args ) {
System.out.println( triangle( 4 ) );
}
public static String triangle( int n ) {
return IntStream.rangeClosed( 1, n ).mapToObj( Triangles::line ).collect( Collectors.joining( "\n" ) );
}
public static String line( int n ) {
return alternating( n ).limit( n ).mapToObj( Integer::toString ).collect( Collectors.joining( " " ) );
}
public static IntStream alternating( int start ) {
return IntStream.iterate( start, i -> i + 1 ).map( i -> i % 2 );
}
}
You can also go totally crazy, but I wouldn’t recommend it:
public class Triangles {
public static void main( String[] args ) {
IntFunction<IntStream> alternating = i -> IntStream.iterate( i, n -> n + 1 ).map( n -> n % 2 );
IntFunction<String> lines = l -> alternating.apply( l ).limit( l ).mapToObj( Integer::toString ).collect( Collectors.joining( " " ) );
IntFunction<String> triangle = n -> IntStream.rangeClosed( 1, n ).mapToObj( Triangles::line ).collect( Collectors.joining( "\n" ) );
System.out.println( triangle.apply( 4 ) );
}
}
This was referenced in the post but if you’re looking for a packaged up implementation that does take advantage of some type family level stuff see Richard Eisenberg’s units library
I don’t really agree with this, in basically any meaningful way, mostly because the writer has their head up their ass.
Expectations for what a web site should be able to do have evolved enormously. […list of bullshit follows…]
And they want a pony and a snow cone and anything else devs are stupid enough to claim they support. And frankly, I’d argue that devs are projecting on users quite a bit: devs want to build fast apps with instant loading service workers and spiffy SPA stuff and all the rest, not users.
You know how I know this? Go look at “boring” but huge-traffic sites. Go look at 4chan, at Reddit, at Stack Overflow (notice that the tabs load a new page, every time), at Craigslist. And then come back and tell me that somehow users are clamoring for anything more complicated.
The functional and popular web only needs basic things.
The web as a platform, as ever, lags behind its developers. They want ES6 syntax, they want modular JavaScript, modular CSS and modular HTML. Browsers provide none of these things, so they are hacked together in frameworks.
The browsers provide none of those things because they aren’t necessary–no more required than say stabby lambdas in ES6. Hell, if you want “modular” things, consider just using different script tags and IIFE. We had those for ages and they worked fine.
Devs aren’t adopting all this new tech just because it’s new and fun (though it’s a bad idea to dismiss fun as a valuable quality in a development tool). They are doing it because they have to in order to survive.
Bullshit. Most new tech comes out because of one or more of:
Learning how to use existing tech/APIs is hard.
Making your own new APIs is fun work that isn’t as boring as delivering customer value. (see also yakshaving)
It’s harder to sell product than it is to sell consulting–and you get street cred for being the dev who made X/Y/Z (the new hotness)
It’s harder to build a reputation for building solid applications than to give conference talks.
Are there some people using a huge pile of JavaScript and a monstrous build chain to throw together a single-pager web site with one box that collects an email address? For sure. And that’s silly and unnecessary. But so what? The misuse of technology does not invalidate it.
How many billions (BILLIONS!) have been wasted by companies trying to have mudball jQuery applications cleaned up? How many man-centuries have been wasted waiting for an over-built “web app” to load to display a static document? How many gigawatts (and fuel and so on) are wasted on processors crunching spurious bullshit JS that never needed to be there?
This is a fucking plague. This is ludicrous spendthrift garbage. This culture of ignored externalities is killing us, folks.
Over the next 5 years I expect there will be a lot of consolidation in technologies and in tools.
No, because web assembly is going to let every chucklefuck use their pet language and framework(s). It’s going to be the goddamn tower of babel. Things are going to get so much worse.
jQuery was a performance problem at scale, and sometimes over- or mis-applied, or used superfluously by newbies who didn’t know there was a simpler way. Big deal.
Again, author clearly has no empathy for the poor schmucks who have had to actually deal with solving the messes left by other developers who shared the author’s philosophy–or the people signing their paychecks.
Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.
The author’s child is the little shit that runs around and sets fire to squirrels and breaks things and the author is a shitty parent for celebrating that behavior and telling other parents to let their kids do the same.
~
And then I saw that the author is an exec at npm, and it all makes sense.
Of course the author shills for the “evolving” web, because their business is predicated on that growing cancer and shitty development. Of course they’re going to insist “This is fine, this is the way things’re supposed to be”–their livelihood depends on it!
Author: You write shitty software. Your company writes shitty software. Your views on engineering are a net negative on the web. You are a bad person and you should feel bad.
Was I pointing out that the author knowingly supports bad software that directly impacts in a negative way thousands of developers? Yes.
Look, saying that “@gambogi you’re a goddamned carebear and your face is ugly and you stink” is a personal attack. Pointing out that somebody online in a position of power is making the world a worse place by their actions is not.
Now, perhaps “you are a bad person” should be person-first language “you are a person with bad thoughts and actions”–mea culpa.
EDIT:
Let me make vent a little more on this point.
A few years ago I had to deal with the stupidity of npm. I had to deal with npm’s decision to just use nested dependencies, with their derpy version management (shrinkwrap having been eventually introduced). Others had to deal with the entire left-pad debacle, but I personally along with my team wasted man-days on this.
That was time I didn’t get to spend with my family. That was time I didn’t get to spend exercising. That was time I didn’t get to spend posting online. That was time I didn’t get to spend eating, fucking, singing, playing, cycling, dancing, or anything else that makes me a human being.
That is time I’m never getting back.
And this bozo? This is the person responsible for the engineering that caused those problems.
We have to hold engineers accountable for their actions.
If people can’t interpret text at all, they shouldn’t be online.
Nothing is as frustrating to read as apologetic “I’m sure you are a nice person with your family, and even Hitler painted roses, but when it comes to your position in the public eye and the way you exert power, I find your actions disagreaable to say the least, and if political correctness had not won, I’d call them outright evil!”
It’s ok to say someone’s bad every once in a while and let the reader figure it out.
I agree with you. I just want to point out that mobile reddit is complete and utter JS-laden abomination. They probably know how bad it is, because they heavily advertise their mobile application. I even think it is intentionally bad, to push the app down their users throats.
Instead, you posted about it on Lobste.rs, and in an alternate timeline, The Zuck just stole it, ran all the way to a time masheen, and now look where we’re at.
From what I know about Thoughtworks, they meet a lot of these requirements, and also are a mainly consulting-based company. Sure it’s a lot of work to ensure you can enforce your requirements when working with clients, but it probably pays off in the long run.
Thoughtworks is often “we do the whole project from you”-consulting, because that sounds nicer then “team-selling”. We consult for specific technologies and are just 10 people, spread over 5 projects, most of the time.
Sure, it makes sense, and they can do that, but I enjoy solving hard database problems where people have direct issues, I’m not gonna enter their building and start by introducing new development methodologies first. (unless they may be a source of the problem)
This. I’m slowly thinking about career direction and while technicalities are interesting, the foremost thing is the business model and people - is it something I’m morally okay with? Do the people have a DNA where I feel like “the worst drummer in the band” (I.e. a feeling that I’m learning)? Will the work be spread such that I’m not just assigned things nobody else wants to do?
I’m not sure why this is share-worthy. What is the content here that people are upvoting? Not trying to be snarky - genuinely interested if there was something I missed.
It’s not really that much about her, though, unfortunately.
It reads like “docker kubermetes docker, a couple observations about open source, generic advice, plug for help for docker or kubermetes”. She seems like a perfectly nice person, but she doesn’t seem that much more noteworthy than any of a thousand other open-source developers paid to work on infrastructure projects. The interview doesn’t really cover anything personal about her, it doesn’t have her saying anything we haven’t heard a thousand times before or at least going in-depth on a story to explain her advice. The systemd->butts transform was amusing, to be sure, but otherwise why?
I hate to be this, well, mean, but shouldn’t we be using the person tag for people of, well, note?
~
And yes, this is kind of a core problem with the person tag. This person isn’t that interesting–given the information in the submission–to me, for example, but I could probably pick some alternate submissions that might be equally uninteresting (a person I know who is a greybeard at GOOG and has some coolprojects.
But where to draw the line without being petty? What makes articles under people good articles (instead of PR puff pieces)? Therein lies the rub.
I think the problem here is that the interview doesn’t really say enough to convince someone that she’s worth interviewing. If you know her, you get it. If you don’t, then… we’ll, this isn’t helping, unfortunately.
You’re right. Unfortunately, I don’t know that anyone who’s already “soaking in it” will take the time to write the “Hey, all you folks not in Devops, this is why Jesse is awesome!”.
Maybe a little bit of open mindedness on people’s parts would help?
Clearly not “without question”, right? Perhaps in the Docker/Kubermetes realm, but the article itself really doesn’t give much information about her, why she’s a big deal, or what she’s done. And that sucks, because people here are pointing out waaaay more interesting accomplishments she’s had.
But again, the problem with the person tag is that you and I can both draft up a list of at least a half-dozen devs that are “of note” and yet the other one of us will go “huh?”. And in a few decades time, probably none of the people on those lists will be remembered.
The person tag is for stories about people, not profiles. A link to one of her talks, an in-depth or technical interview, or any one of a number of her blog posts would not have been flagged as off-topic.
edit: I’ll also point out that in general the person tag is used alongside another tag. Cases of “person” alone are generally of some historical significance, an interview, or a death announcement; all of which are more substantive and/or better discussion topics than a simple profile.
I’m with you. The title alone means nothing to me. I thought it was going to be some sort of memorial when I first saw it. But there isn’t really much of any content there. There’s nothing technical in it. I don’t understand what we’re meant to get from it.
It fits HN more because that site is full of fluff like this, but I wouldn’t expect it here.
FWIW this was only posted in here because it’s in the front page of HN. @av consistently posts whatever is popular there here (most of the time it makes sense, though).
So it starts off saying “not meant to be insulting to anyone or anything” and then, a bit below, they decide to take “designed for stupid people” as an actual reason of why Go is not good? I can’t say I’m impressed.
To be fair, the author is just listing what other people have said about go and their major points. The author themselves did not say that Go is “designed for stupid people”, they included someone who did say it.
I refuse to accept that as valid; quoting someone is an action too. Author could have decided to leave that out, because let’s face it, it brings nothing to the table. Both of the articles cited for that point have a lot of other stuff that they are cited for, as well. To be fair, I’m probably nitpicking, but it still irritates the hell out of me when people pull together a list of reasonable concerns, and then plop in a “you’re stupid” trump card. I’ve worked with the “you’re stupid” trump card for a year and a half, now. I really dislike it. A lot.
[Edit: when I say “work with”, I mean “had a coworker who kept a trump card unreasonable argument nearby at all times”]
Personally, I would feel i’d either have to leave the article out entirely (which may have been what I did) or include the “point” in the list. It would have felt incomplete/wrong to me otherwise.
i got voted down as a troll for saying this in another subthread, but direct, deadpan quoting of someone who says something over-the-top is a definite form of humour. “psuedointellectual arrogance of Rob Pike and everything he stands for” was a big tell, but the overall “tone” of the page is subtly (and i’d bet intentionally) funny, regardless of whether it serves a useful purpose or not.
I doubt they’re falling Go users stupid; it’s probably a reference to Rob Pike’s (one of Go’s creators) comment “They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
It was definitely a poorly expressed point by Rob Pike but making a language easy to use is absolutely the whole point of language design. And really, Go is very easy to learn and provides a very low barrier to getting real work done. So that’s a great thing.
making a language easy to use is absolutely the whole point of language design
That is really not the case. “Ease of use” is only one dimension of a language, and one that’s commonly overoptimized for to the detriment of other properties like correctness, efficiency, readability, maintainability…
Okay, so a hit on pride, but how is that a shortcoming of the language? If it’s a driving point of design decisions, it would result in the language being weak-sauce, but in and of itself, it’s not a weakness of the language.
Personally I’ve never understood the comment as developer mistakes seem like the greatest motivator for strong type systems and uh, not including null.
Am a bit underwhelmed by this article, as a long time Python programmer I’ve been eyeing Haskell for years but never invested the time to try for real. I would love to see an article from someone who made the jump, like Brian O'Sullivan.
Stage 4: Composability is destroyed at program boundaries, therefore extend these boundaries outward, until all the computational resources of civilization are joined in a single planetary-scale computer… this is the idea of Unison and unison.cloud.
I feel like a couple reasoning steps were skipped between the assertion and the conclusion on this stage.
Too bad this happened.
Given the limited info you gave it could be different things:
1. a transient error connecting to github
2. a proxy in use that somehow breaks the connection
3. using a broken version of cargo (yes, we had that recently…)
From my own experience I find the Rust tooling far more reliable than what Go offers.
Do you think that’s because golang has concretely better tooling in some way or because you’ve grow accustomed to its quirks? I’ve experienced the promising new library without a working example a lot, regardless of language. I’d be curious to hear what approach go takes that can address it.
Quirks that hang up new golang devs:
* $GOPATH
* the import system
* (new) vendoring
Things that golang gets right:
* When things fail, they fail in very transparent ways. An example would be, if I had the above issue, I would 100% be able to reproduce it if I tried a git clone myself, vs. rust where it’s not shelling out and it’s some other configuration or library issue.
* golang has no configuration files, everything you need can be inferred by what’s on disk.
Basically it comes down to, an initial hurdle of slight magic with golang, and then extreme transparency and logic with everything after that initial acclimation period.
On other end of spectrum, I had to try to code something in a hurry on a new computer without knowing tooling or programming due to memory loss. FreeBASIC did a simple install, I/O worked as in tutorials, typed stuff into text editor, and ran compiler with terminal command.
Effortless just like QBasic I started with ages ago. Another good one from my early time was LISP box or something like that. Integrated everything from editor to compiler in one executable. Stuff like this is how I judge how easy tooling is to install and get running with.
Setting aside feelings one way or the other, posting this because the default behavior changing is bound to bite somebody in the next month or two. If anybody knows what minor version is going to start doing this, post here so we can know what to check
git --versionagainst. It appears this is landing prior to git 3.0.Quoting from the mailing list discussion:
In case you need to support legacy scripts or muscle memory.
git config --global init.defaultBranch mastermay also work, but haven’t tried it on my machine.Adding this to my gitconfig now to avoid future issues…
Wait, I thought that
init.defaultBranchwas the compromise, to avoid renaming the default branch in Git, while still allowing those who feel uncompfortable by it to avoid it as much as possible?Are there any statistics or scientific attempts to qualify how much of a problem this is? It’s probably my fault, but I find it hard to imagine that if someone is in the need for version control, will learn all the basics up until the point where they see the word “master”and give up, not because of direct racism, but racism by association.
Non-technical issues like these are never easy, but there should at least be some discission where one position is designated as the morally superior before a word is said.
main is shorter, simple, and has no negative connotations whatsoever. This is an easy thing to do and it makes people feel welcome
Semi-serious question: How do we know that? I’m going to guess that the people who decieded to use “master” in version control systems didn’t do this out of mallace, but just because the phrase seemed appropriate. So how can we be sure that main won’t eventually fall our of favour? I remember that at the beginning of 2015 Elementary OS wanted to release a new version called “Isis”, afaik in reference to the egyptian god, but then the terror group in ISIS gaiend power and a more or less inncoent name became very controversial.
And does “shorter” and “simpler” even matter? Almost everyone uses autocompletion in some form or another, and it’s not something you use as often as “git commit”.
If we knew the future the world would be a better place ;) In the absence of perfect prescience, we will have to be guided by the voices of today.
Ok, fair enough, but let’s twist the question again: How do we know that everyone has a seat at the table? What if there is a language or a culture where main has a different meaning (a simple but unoffensive example is in Germany, where Main is a river)? Apparently there were no black people, or people “decendents of slavery” to be exact (because not all back people were slaves) were present when the term “master” came into use, to correct this issue early on. But then on the other hand, if I remember correctly, make still uses tabs instead of general indentation, beacuse Stuart Feldman didn’t want to disrupt his userbase of at most a few dozen users.
Of course, given that “git” itself is an offensive term in the UK, I insist that the whole project must be immediately renamed.
false equivalence bad-faith troll
Ok, but it is a swear word and you would be chastised for saying it in a learning environment.
Much like “GIMP” doesn’t belong in polite conversation.
What are you hoping to achieve with this thought experiment?
I intend to show that the argument is internally inconsistent. We cannot simultaniously assume a kind of standpoint theory, by which there is always a posibility that a term is (objectivly) wrong, but at the same time be able to suggest an (objective) replacment for a (subjective) offense.
A simpler understanding, that does not run into these problems is that offense is determined by intent, not by the nature or the etomology of a word.
At the same time, I don’t think that people advocating for this change are arguing on this level. Any reference to this logic is handwaving, but the motivation appears to be something else, which I would either guess to be some kind of at best false pragmatism or at worse opportunism.
(I apologize if I misinterpret your comment, English is not my first language and I am trying to understand your comment)
a group X used a terminology to undermine/subjugate a group Y in the past, the group X is much smaller now but it still exists.
the change happening here is removing that specific terminology because group Y today is reminded of the past treatment.
and is your argument is that, since we don’t know that the new terminology wasn’t used to undermine any group in the past, the change is fruitless as we might need to change it again?
or that since the terminology was also used in other contexts by people not in group X, it should be okay to continue using it?
As I am neither a member of group X or group Y, my opinion is that if the change results in more people being comfortable using tool, we should definitely do it.
First of all, and I don’t know why this has to be said: Slavery didn’t exist because it was called slavery, it existed because the society reproduced the conditions under which people were slaves.
I explained the further in a sibling comment, that on the terms of the argumentation, it is imposible to say that main is better than master, because perspectives cannot be compared or have any common point of reference. Since this discussion is not based on any hard evidence, we cannot derive any emperical conclusion like “this will make more people comfortable”, since we are talking about idealized, aggregated perspectives, produced by a worldview that has ever increasing problems to explain anything that is happening, hence the focus on such things like “master/main”.
I find it not to be only a “thought experiment”. The questions are on point. No data (if any, I would like to see it) to back up claims that people are offended by these words results in such major changes for everyone. At least that needs to be pointed out.
OP is leaning back in their armchair imagining the theoretical universe in which the broader German community is coping with the upsetting rivered associations with “main” as the new default git branch. I suggest they apply their philosophical leanings to the actual real world in which it turns out a sizeable community of real live humans prefer to dispose of master/slave language where possible in discussions with their terminal.
Please re-read my comment, the “main” example was just to give an example due to limited perspectives, we cannot know what our actions or decisions mean from other perspectives. I explicity said it was harmless, but if you want something better, consider @caleb’s example.
How can you know that? Where are the statistics? Where are the polls? How did we figure this out? When did we figure this out? This is just postulated, and nobody goes into it. And I have a hunch that this is because if you were to actually find out what most people belive, that it would not be what you want to think they do. But that’s just by unprooven hypothesis.
I’m not going to debate you because you’re displaying a preference for thought experiment over an engagement in reality, which not only suggests a closed mind, but also that you simply don’t have sympathy for the real issue at hand. @caleb’s “example” is a much less veiled form of the same type of trolling you’re unwilling to let go of.
You wish to model reality, but no modeling is required to understand this issue. We’re here because we’re here. This is a real conversation which is taking place in the real world for several years now. You’re attempting to place the burden of proof of the existence and size of a community on that exact community itself, which is existentially large and significant enough to make the issue stick broadly across numerous open source projects, GitHub, and now the
gitproject itself.This is just completely illogical. If you want to go do your own research and develop some set of quantitative metrics in an attempt to quantize a complex social issue which is unfolding as we speak, then go ahead and do so. It’s not going to change what’s happening.
As already stated, I just want to explain why the position is incoherent, and as everyone knows, ex falso, quod libet. You have already dismissed everyone who is questioning it as a troll, declare the issue as obviously setteled and then proceed to moralize it by claiming those who don’t agree have no sympathy for the real issue at hand – but of course, we are have a closed mind. I am honestly disgusted by this kind of behaviour, this dishonesty and the smug superiority you emit. Please stop and consider what you are doing, and why you feel the need to behave the way you do.
This could be accomplished by a small group of PR professionals who don’t actually care about racism, but recognize a potential upside for their company while the cost of changing a default is distributed throughout the open source community.
The real story here is that GitHub made the change unilaterally, and git followed suit. One might consider the depth of anti-racist feeling that would drive a company to make this change while continuing to partner with ICE, DOD, and police departments around the country.
i was there when we named elementary OS Isis and i was also there when we named it Freya.
from what i remember, no one was concerned about optimizing the name, we were more concerned about not hurting people who themselves or their families had been impacted by Isis.
I am 110% proud of our decision.
(taking the elementary OS dev hat off)
I found main to be a better choice, i am used to using mainline at work now (because of perforce legacy repos) and don’t even notice a difference.
Then we just change it again?
But considering that the same would apply again, ad infinitium, we cannot say we will ever find a good name. And at then, what is the point? Either we go on forever renaming every time someone complains, at technical expense, or we claim that this renaming is more important than others, because one offended group is more important than others, which I don’t think that the people arguing for this want to argue.
I don’t think anyone is claiming that
mainwill be the perfect name forever. If at some point in the futuremainbecomes offensive, then we could change it again. I haven’t found any evidence that would lead me to believe that git would be changing the branch name on a monthly or yearly basis, so I don’t think there is a high cost here.Uh, we work in software. Everything changes all the time at technical expense. Updating your dependencies could break your app (even if the API doesn’t change), products get deprecated, new products get created. I don’t see this much backlash against Apple changing their CPU architecture and that’s gonna cause a lot more trouble than this change.
But that makes sense because the real issue here is ideology, wokes vs anti-wokes. We’re just pretending it’s technical. I think it’s fine to argue the ideological issue. I don’t think people are automatically racist for not liking the change. I just don’t think the technical argument holds much water.
I don’t know how Apple is going to handle the migration, but I suppose they have tooling to make it easier, the kind of tooling Git lacks.
Those conversations might also be more private.
As for tech expenses, you’re correct in that everything comes at an expense.
Is it therefore justified to impose more of it on others?
Maybe that’s an important ideological question as well?
This doesn’t have to be all about how git has a master branch to signify “the master copy”.
See also: how master hosts usually perform more work than slave hosts (to counter American slavery connotations) or how offensive “blanket exception handling” and “collaborators” should be (in cultures treated with “less thought” than American slavery).
Changing it alone is more welcoming than any harm from the word itself.
This I don’t get. Could you explain what you mean?
Master is more precise, traditional, doesn’t break anything, and has no negative connotation in this context, or most other contexts.
Main does not make me feel welcome, it makes me feel like I’m being forced to bend the knee to a mob that can’t or willfully choose to not understand English. It makes me embarrassed to be in this field. Admitting that feeling means I deserve to feel bad anyway though, so whatever.
Tradition should not hold back progress. There are more descriptive names out there. For example allow/deny is better than black/whitelist, parent/child is better than master/slave. I understand people are resistant to change and humans are creatures of habit (energy conservation) but this is a simple name change where there’s more advantages than not and people will get over it after a few weeks.
Not if it brings up memories of child abuse.
Sorry about your child abuse, or are you simply virtue signaling? If you feel strongly about it then you can message the maintainers of the software you use to alter the names, otherwise why bring up a “whataboutism” argument.
That you consider it valid shows the futility of choosing names to please everybody.
The master slave relationship is not the same as the primary secondary relationship, nor the parent child relationship. Sometimes master slave actually describes the subject matter.
And sometimes the master copy of some source code should live on the master branch. Many people only commit to master when they are certain of their work, while they use another branch as their main branch. Kind of presumptuous, calling the default branch the main branch, isn’t it.
Sure, but it should hold this back.
Not when there are demonstrably better names that are not, traditionally, associated with one-sided power dynamics, it shouldn’t.
If “main” makes you feel less welcome, then there’s something wrong with your capacity for feeling.
Hold on, it’s not possible to win an argument about inclusiveness by saying that the other person is broken. Or even pretend that there is only one way to view things. We have to learn to communicate better and see the other person’s point of view.
No, @yawpitch is quite on-point. This isn’t about “winning an argument”. Those with any decent capacity for nuance, critical thought, and self-reflection will note that “main” draws fewer negative associations than “master”. Those with unconfronted reactionary cultural/emotional anger stemming from the strawman “woke mob” fantasy will come up with a contorted bad-faith “arguments” a such as “the word ‘main’ makes me feel unwelcome”. You gotta call bullshit when you see it.
Maybe. Or it’s also an opportunity to learn. People can have different points of view, and still, be good people. <3
First off, this isn’t an argument about inclusiveness, it’s at best a debate about semantics, and since there’s no cognizable or remotely valid viewpoint that can distinguish “master” in the “traditional” sense being described above from its root association with human bondage, it’s not even a very sensible debate. No such valid viewpoint, with no pretense involved, exists: the word has several long-standing definitional meanings and the one involved here is fundamentally and absolutely inseparable from the notion of master / slave dynamics by which it derives any meaning whatsoever to the cause of version control. To try and empathize with any countering point of view is absurd … it’s a word, its meaning is simply a fact, and that fact is not open to meaningful and intellectually honest dispute, without descending into the interminable Hell of “alternative facts”.
The semantic dispute thus settled the only question, then, is is the community, right now, okay with that semantic baggage being carried further forward, or is the community prepared to make a break from that historical association? Personally I’d say that’s also a moot point … it’s been de facto settled by Github and the very reason the patch detailed above exists is because the network pressures of the downstream are driving an upstream change because YES the community is ready to not be exclusive any longer.
What remains is for individuals who are not comfortable with that linguistic and cultural evolution to, frankly, grow up and un-break themselves of their lack of empathy … the point of view of the “tradition” argument has been heard to death, it does not need more empathy heaped upon it.
I stand by my point: if you – and I’m using the most generally inclusive meaning of “you” here – feel that you’re somehow more included by “master” and less included by “main” then something is deeply and dangerously flawed with your emotional apparatus. The only colorable arguments against this minor default change are inertial, as in you either don’t want to invest the time required to update existing repos or you don’t want to engage in the effort needed to reprogram some muscle memory for future ones. Those are the available arguments. They’re just not very good ones.
Maybe OP doesn’t know everything you do. Git is being used all over the world, in different types of cultures, and this seems like an American problem at heart. If they feel like this change is being trusted upon them, and on top of that they get vilified when they want to talk about it, it’s not really helpful to generate a common understanding. It doesn’t mean that they are broken, they just have a different context from you.
I feel like a better line of discussion would be to give out concrete instances where this word has been a problem. Or actually, even ask why OP feels like they do.
OP made their context quite clear with their phrasing:
… only when understood as an explicit reference to master/ slave dynamics …
… which is automatically a claim of being “inside” the dominant cultural context …
… privileges the idea that the status quo isn’t already broken, which it is if you find the master / slave connotation at all problematic …
… no negative connotation to OP; the phraseology has an extremely negative connotation to me, and I am most certainly not alone: you keep suggesting I need to apply more empathy to someone who’s denying my very existence…
… can someone please enumerate the many and varied contexts in which master / slave has no negative connotation from the perspective of anyone who has been a slave, or whose family history was affected by slavery. I can affirm that I’ve personally got a great many friends in a great many contexts – including well outside of America – who see the problem with “master” as default.
I don’t need to understand why OP feels like they do … I need only identify that the feeling itself is unworthy of consideration in the political choice at hand… it is impossible for any rational being that both understands English and is armed with minimal historical context to see “main” as more exclusionary and historically problematic than “master”, hence we need not engage with any such view that happens to be espoused at all, except to point out its obvious and manifest flaws.
I guess I didn’t get notifications for this continuing discussion. I’m on mobile and also don’t really care to keep this going, but I do want to clarify that I mean more precise in the sense of “master recording” or “master copy”, as in the source of truth from which copies are derived.
I can’t tell if you already read it that way, and believe that usage to itself be derived from slavery, or just think I’m directly defending the master/slave dynamic.
Both of those usages — arguably they’re the same usage — rely in their entirety on the master / slave semantic for their meaning. Indeed no semantic value can be extracted from either without knowing that relationship exists, at least implicitly. A replication master makes no sense without duplication slaves, and that’s exactly what we called them in the bygone days of glass / nickel masters in optical pressing and tape in replication farms. Even before tape and indeed wax cylinders the master mold of foundry and pottery days was there to be used to direct the toil of those making exact copies, as it were, slavishly, with no independent freedom allowed in the work. They’re utterly inextricable from the historical institution they took as their model.
As I’ve said before there’s is not now, nor ever can be, any legitimate argument to be made that separates usage in version control from the historical idea of the privileged master and the slave(s) that follow.
I’m totally with you, though based on the extent of some of the involved philosophical gymnastics into symbology, original intent, and sociology on the “other side” thrown in the face of the simple actual sizeable live human community looking to stop promoting “master” I’ve gotta conclude that these folks are ultimately motivated by a certain emotional bias…
In many uses of master/slave in computer related things, it is actually a poor analogy. Often a “master” does all the work with the “slave” sitting idle waiting to step in only if needed, Other terms like prime and replica can be a better fit anyway. parent/child has a connotation of the parent spawning the child which works for, e.g. processes but not in other cases. In the case of git, there isn’t even a corresponding “slave” concept, only “branches” - In my mind, I wouldn’t even connect that use of the term master to slavery, but I’m not American. In any case, the subversion term “trunk” was better to begin with.
Trunk is a good term. I can understand a change to Trunk.
In the book 1984, a major plot point is the reduction of language to reduce the complexities of expressable thought. Words meaning only one thing, like master only meaning “of a slave,” is an example of this language reduction.
The master name in git was derived from master/slave terminology, see https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html
The name trunk like in SVN is ok but I still think calling it main is better overall because of it’s shortness and detachment from it’s controversial origin.
Saw, am very not convinced by his sources that it is master slave, even in bitkeeper.
Trunk is much better than main. One is descriptive.
Principal/agent makes a lot more sense than parent/child for workflows.
Not bad, certainly makes sense under certain delegation workflow contexts.
Master is not more precise.
As we’ve seen, you can never make people feel welcome–you can only make it more or less costly to join.
the spanish main was the site of centuries of brutal colonialism
“Congressman, I don’t have all the answers to your very technical questions…”
That’s not something you hear everyday. Who is this Riggleman guy?
This guy.
It’s interesting because he sounds decently familiar with GitHub. I wonder how many Congresspersons have GitHub accounts, if any?
Perhaps your expectations of congressman is so low that the ability and initiative to use a website to do research is the more surprising part, because it doesn’t take a lot of familiarity with Github to perform a search. He did sound familiar with programming on more than a surface level, however.
He was able to talk confidently about nightly toolchain builds though, which takes a fair amount of technical understanding.
His mention of DoD practice leads me to think he picked this up as an intelligence officer. You don’t have to be an experienced developer to recognize high-level risks. Extrapolating from a single point of experience working for a former I.O. for several years, they have a keen skill for picking through details.
He was also an NSA contractor.
I think he did indeed mention he had a background in intelligence.
What jgb said. He talked like a programmer or project manager, not someone vaguely familiar with it.
About half my computer science lecturers at university were older than that, and they were all familiar with git. My dad’s about that age, and he’s familiar with git.
57 isn’t actually particularly old. Many of the pioneers of computer science have died of old age at this point. We’re well past the point where programming or computer science is a ‘young man’s game’ in any reasonable sense.
The number of programmers doubled roughly every 5 years for a long period of time. Possibly from the beginning up until recently. This suggests that there are 64 times more 25 years old programmers than there are 55 years old programmers. Yes, all the pioneers are now old. But they were exactly that: few pioneers.
Programming has never been a young man’s game, but this exponential growth skews the numbers like crazy, and make it appear like a young man’s game. After all, if the only thing you know about someone is their age, the older they are, the less likely they are to have learned programming.
there was definitely a dip in the rate of CS enrollment after the dotcom bust in 2000, but then numbers of both major and nonmajor CS exposure has seen a massive surge since 2005
Very well explained, thank you!
Linus Torvalds himself turns 50 this year.
57 and working in computer science is different from the average 57 year old who may not have an in-depth exposure to computer science.
I wouldn’t expect that the average 57 year old has a better or worse idea of git than the average 21 year old. People often claim that young people are better with technology. In my experience, they tend to not be at all.
Young people work for cheap and are more easily taken advantage of.
Why do you think so much of advertising is aimed at people in their twenties? Some disposable income and not as much life experience.
Yeah, the average 21 year old also has no exposure to computer science either. I agree it’s a pointless comparison.
Good point! My bias is showing (growing up where I did, the only people I knew who knew about computers were my age). This makes me hopeful that I can still be programming well into retirement age :)
I agree that his tie isn’t the most flattering, but I wouldn’t necessarily say “Yuck”.
Care to elaborate?
Lol I didn’t notice the tie. Purely a political yuck. He’s proud of bombing Afghanistan, pro-trump tax cuts, pro-deregulation, and anti-gun control. ¯_(ツ)_/¯ to whether his staffer gave him talking points on rust and javascript.
I think it’s odd to list “interviewer time” as an issue with the current system and then offload a day of work onto the interviewee as if the current process isn’t expensive enough from that angle.
TLDR: Author used several bad IDEs, which crashed to the point of rebooting so that restarting after a reboot alsotook a long while.
Well, now I really want to know on what kind of potato the author was running which IDEs. JetBrains IDEA is not lightweight but I’d used it for 4 years on an x230 (ok, i7 with 16GB and SSD) without any problems. Multiple projects, multiple languages, multiple VMs running at the same time. Now I use QtCreator and it’s a joy.
Not using IDEs is fine, but the concept of an IDE is absolutely not the problem here.
Intellij crashes on me at times. Are you sure you haven’t had any problems?
Edit: Don’t take my question as an endorsement of this article, which it is not. 🙂
You never have not any problems ;) But I’ve definitely had less problems than when using non-IDEs. (Sure it crashed once in a while or was stuck at “indexing” - but it’s given me less problems than, say, my browser, IRC client, mail client or anything else. Maybe I was just lucky :P) But just opening many files and switching between them multiple times per minute, resplitting panes, etc. It’s doable in vim/tmux/etcc (for me) but there’s no “intuitive flow” and forget about plain editors.
wink wrote:
JetBrains has some quality IDE’s. For me, PhpStorm has features that I haven’t found in other IDE’s let alone text editors. I’m guessing this is similar to other languages too. For example IDE’s that support and extend hot swapping for Java.
Typescript has become my favourite language for side projects and I’ve even snuck it into the Day Job. The dynamism of JS with a fairly rich type system at “compile” time is a fantastic combination.
I suspect that part of what’s great is that the type system has been built to be expressive enough to capture real JS usage and APIs. Instead of being a static type system imposed on a dynamic languages it’s a type system suited to the language and its users.
Every static type system is a type system imposed on a dynamic language. Are you meaning to compare to flow here?
Au contraire! You have it backwards. Dynamic languages do have static types – just, not very expressive ones.
https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/
Au contraire your au contraire! Static languages have dynamic types, but they’re so weak you need to run a SECOND program just to make sure you don’t accidentally use them!
Not so, some languages are built from the ground up with static types. There’s no way to implement Haskell (typeclasses) or Scala (implicits) without implementing a de facto static type system.
Haskell is built from the ground up with types, sure. In a sense though it is still a series of extensions to the untyped LC. Type classes are type level computation and therefore a part of the type system so their absence doesn’t make a great counter example.
Granted this is all a lot more hair splitting than my original question.
I think the major difference is that some languages expose untyped constructs to language users, while in other cases untyped constructs are just hidden artifacts of a compiler implementation that are invisible to users.
the issue is these terms are vague with conflicting alternative definitions. None of this is relevant to clarifying the second paragraph I was asking about.
What do you mean? There’s no sense in which a Haskell expression like
(decode x)- can be understood from an untyped perspective. Both its semantics and its behaviour are fundamentally entangled with what type the expression has.It’s not “hair splitting”, your original claim is false and misleading.
Further at runtime the type information about a generic parameter is almost totally lost, you need to have an instance to base type information off of. There are real weaknesses with bolting strong typing onto dynamically typed runtimes.
Generics should be erased at runtime, having them there only makes it easier to violate parametricity.
From the perspective of someone who’s written multiple ORMs and other serialization frameworks … this is objectively wrong. You need to know what fields are on an object, and be able to call into generic functions with strongly typed parameters to make sure things like interfaces are still satisfied.
Typescript is a step forward for javascript devs but it is still very, very lacking compared to something like golang even.
Take a look at how ORMs and serialization frameworks are implemented in Scala or Haskell sometime. Implementing those things requires ad-hoc polymorphism, but that can be done at compile time rather than at runtime, via typeclasses or similar mechanisms. This is better for maintainability and understandability of code than doing runtime reflection on reified generics, because it makes the distinction between parametric and ad-hoc polymorphism visible to the programmer - one can immediately see which functions will always follow the same code path at runtime, and which maybehave differently for different types.
You get compile-time guarantees with reified generics too; and they end up being safer and more expressive (and faster in a lot of cases). I’m not sure what you’re arguing for other than less expressive systems are easier to understand.
A lot of guarantees the reader would expect from a parametric function can be violated if that function uses runtime type information. https://failex.blogspot.co.uk/2013/06/fake-theorems-for-free.html gives a few simple examples -
const3is only possible to implement because the types are present at runtime. The only thing that reified generics give you compared to erased generics is the ability to implement functions that use the mechanism thatconst3uses, and such functions are a bad idea.(There are problems that you might assume could only be solved by writing functions like
const3- you mentioned ORMs and serialization - but actually it’s perfectly possible to solve those problems without reified generics)You’re mixing paradigms here.
I’m an ORM. I see a type. I need to create a binder at runtime to take a database row result and map it to the fields on that type. I can either have the user create mapping functions to do this manually, or I can examine the type, dynamically emit that mapping function for them (in .net you can do this with IL/Lamda.Compile()), saving the developer a lot of steps per type.
One runtime approach creates a lot of manual work for the developer. One does not. The second order affects that reification creates for functional programming (specifically the corner cases you outlined) do not outweigh the other benefits of having full type information at runtime. Especially in a runtime that can dynamically emit and load types.
Again, look at how this is done in Haskell or Scala. You put a typeclass constraint on your loader function, and the language uses typeclass derivation to generate the mapping codepath at compile time. You get the safety of compile-time type checking, but the developer doesn’t have to do any extra steps (depending on the language they might have to add a marker like
deriving (DatabaseMappable), but they never have to manually implement the mapping functions).For what?
I agree. A huge donate bar seems very out of place for a site previously so focused on being able to apply filters and focus on content.
And I really don’t care about adopting… an emoji…
So, basically, the author is solving problems Python isn’t good at. So, great - use another tool, Haskell or whatever. I do not see how this says anything useful or interesting about the language itself other than “Python is not optimized for solving numerical problems not addressed with numpy”
Is Haskell well-optimized for numerical problems?
It’s OK. The mainline compiler doesn’t have vectorization by default yet. See https://ghc.haskell.org/trac/ghc/wiki/SIMD/Implementation/Status . For some classes of numerical algorithms, you can expect performance on par with (unvectorized) C. For algorithms that are inherently mutation heavy, I generally find that making Haskell exactly as efficient as C removes many of the benefits of using Haskell in the first place. That’s fine for library writers but not great for end users.
Haskell’s main strength wrt speed is that you can compose high-level things and the abstraction overhead will be unreasonably small. If you’re churning through gigabytes of data per second, you can write Haskell that’s almost as fast as really well optimized C for a small fraction of the effort. However, I wouldn’t really describe the problems this works well on as “numerical”. When I think of “numerical” I usually thing of lots of mutations on big matrices, for which I would rather use Numpy or something. Haskell’s good for many of the things numpy isn’t.
I may be wrong but my understanding was that haskell does have library support for generalized stream fusion which gets very good performance without having to write particularly clever code.
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/haskell-beats-C.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fndp%2Fhaskell-beats-c.pdf
That’s exactly what I meant by
Excellent question - I have zero idea. It’s compiled, right? So I’d think there’s more room for optimization there, but I dunno.
“Type theory is a theory of computation that classifies programs according to their behavior, rather than their structure. Types are themselves programs whose values stand for specifications of program equivalence.”
I had to stop right there. Most of us in imperative languages using types use them or structure. Especially in terms of structs or objects. This says types have nothing to do with structure. Makes me wonder if that’s inaccurate or type theory doesn’t cover what imperative/OOP programmers normally call types. Or do they have another definition of structure outside the mainstream definition. I have a feeling a certain amount of confusion that happens in type theory discussions might have started right there.
Regarding the RedPRL prover, one person on it is the person who wrote Practical Foundations for Programming Languages. People might find those interesting by themselves.
An example of something that structural interpretations of types have trouble with is equality of functions. Many programming languages have a very limited or outright broken notion of function equality, but it’s important if you want to prove a program conforms to a specification. It’s also important to have a language for what function equality means. Are a quicksort and a merge sort equal functions?
Bob Harper is both the author of this blog post and PFPL.
I took “behaviour” to mean the ‘externally visible’ aspects of a value/program. For example, that something with function type
Foo -> Barcan be called with aFoovalue to produce aBarvalue; that something with product typeFoo * Barcan be projected to give both aFoovalue and aBarvalue; that something with sum typeFoo + Barcan be projected to give either aFoovalue or aBarvalue but not both; etc.I took “structure” to mean the ‘internal’ aspects of a value/program. For example, the different parts it may be made out of, any functions/computations that it uses (delayed or already completed), the syntax it was written as, etc.
In this sense:
We can make these “behaviours” as complex and precise as we like, by making the types more complex and precise. For example, with dependent pairs and functions we can encode arbitrarily complicated mathematical relationships between values, inputs/outputs, etc.
We can’t use types to classify the “structure” of a value/program.
As a provocative example, we can think about a value of product type
Foo * Bar. We might think that the type tells us some ‘structural’ properties about the value, like “it contains aFoo” and “it contains aBar”, but that’s not quite right. All we know is the “behaviour”, that we can project the value to get aFooand aBar, but we don’t know what will happen during that process. For all we know, the value might be an integer plumbed into an ‘unpairing’ function, like with Cantor pairing or Goedel numbering. Should we say that such a value “contains” aFooand aBar? What if that same integer is also used elsewhere to generate a boolean, a list of bitmaps, etc.? We’d at least have to weaken what we think of as “containing” or “structure”.One example which I’ve heard discussed about type theory as opposed to set theory, is that in set theory we can (and very often do) ask whether a value is contained in a set, e.g.
foo ∈ {foo, bar}andfoo ∈ {high, low}are propositions which may be true or false. In type theory we can’t ask whether a value has a particular type, e.g.foo : (Foo * Bar)andfoo : (High * Low)aren’t true/false propositions; they’re logical statements, which may be well-typed (valid) or ill-typed (invalid).This is important for the “behaviour” vs “structure” distinction, since in set theory we can distinguish between isomorphic sets, e.g.
{foo, bar}and{high, low}are isomorphic (they “behave the same”), but thefoo ∈ xpredicate is true for one and false for the other (they’re structured differently). Since type theory doesn’t let us do this, isomorphic types are indistinguishable (within the theory), so we can only reason about “behaviour”. This has connotations for modularity, reusability, optimisations, etc.You’re right that the types discussed in here are not being used in the same way that types in many c likes primarily use them. The goal is essentially different in scope. C types mostly capture the size of memory required for allocation of something. Types in the type theory sense can capture this idea, but can also contain much richer and complicated concepts in the types themselves.
also aside from PFPL Bob Harper is known for his work on SML and LF
Yeah I don’t think you can do type theoretic proofs in say C# without a lot of work with interfaces and tuples. After all you don’t even have “Product and Sum types”. Heck it’s even hard right now in F# due to the fact that you have to explicitly name everything.
So for example say you have a function which takes a tuple of an int and (bool or string) and returns either a tuple of an int and a bool or and int an a string. int * (bool | string) -> (int * bool) | (int * string) //this would be the function signature. More amusingly
Old * (dumb | fat) -> (Old * dumb) | (Old | fat) // if I’m old and (dumb or fat) this implies I’m either old and dumb or old and fat
This is equivalent to A ^ (B v C) = (A ^ B) v (A ^ C). in logical propositions.
we can the write a function which takes an int and either a bool or a string, and return an int and bool, or an int and string and we know we have covered all possible return combinations.
In this way the function signature, the “Type” represents the lemma and then function itself exists as proof.
This as I understand it is merely the beginning of the whole thing. There’s a good computerphile video on the subject.
re: always be considerate (ABC): while providing a language that does not enforce static types may have been “considerate” for user adoption, it has left us with a world where a frightening portion of major fiscal and scientific operations are carried out in a tool where writing correct software requires a lot of skill.
Maybe it’s considerate and expedient, but is it right?
Yes, it looks much uglier than Haskell version, but constructs are almost the same.
(I’m not arguing that you can avoid imperativeness in Java, you almost can’t, and even
Streams are imperative but somewhat composable)to be fair, java 8 (and streams) had only been out in the wild for 5 months when this was written.
But are those features of Java actually taught at university? Because they sure don’t spend time on them where I’m at.
I haven’t run across it, though I could imagine some contexts where they might be. I might even consider doing it in the future, given the right circumstances. But I think they’re not that likely circumstances. Usually university courses are trying to teach at least two things with a programming language (or language construct): the language itself, and some broader principle, which students will hopefully retain long-term and be able to apply even when languages inevitably change over. So typically Java has been used either as “generic intro-level language” or “OO language”, which Java 8+ streams don’t fit that well into.
In universities where Java’s used as the standard intro-level language, there’s some advantage to continuing to scaffold atop it for further things, because you can assume everyone already knows the basics. But it’s falling out of favor for intro-level classes in favor of Python. So I think you will either see people introducing this “streams” style of programming in Python if the circumstances fit, or else they’ll stick with a more traditional introduction to sequence filtering/mapping/etc. in the context of an introducion to functional programming, in Haskell or ML or maybe some Lisp dialect.
I’m aware of some libraries that provide special syntax for that in Python, but I don’t think anything other than list comprehensions (and maybe higher-order functions) for this kind of stuff is considered “Pythonic”.
I did much the same but tried to introduce names in the same places as in the original; as relatively idiomatic Java that’s:
You can also go totally crazy, but I wouldn’t recommend it:
Great, now I want to my own version but I have to work…
I wrote mine too! ;)
Funny how similar Rust and Haskell are in those small examples.
This was referenced in the post but if you’re looking for a packaged up implementation that does take advantage of some type family level stuff see Richard Eisenberg’s units library
I don’t really agree with this, in basically any meaningful way, mostly because the writer has their head up their ass.
And they want a pony and a snow cone and anything else devs are stupid enough to claim they support. And frankly, I’d argue that devs are projecting on users quite a bit: devs want to build fast apps with instant loading service workers and spiffy SPA stuff and all the rest, not users.
You know how I know this? Go look at “boring” but huge-traffic sites. Go look at 4chan, at Reddit, at Stack Overflow (notice that the tabs load a new page, every time), at Craigslist. And then come back and tell me that somehow users are clamoring for anything more complicated.
The functional and popular web only needs basic things.
The browsers provide none of those things because they aren’t necessary–no more required than say stabby lambdas in ES6. Hell, if you want “modular” things, consider just using different script tags and IIFE. We had those for ages and they worked fine.
Bullshit. Most new tech comes out because of one or more of:
How many billions (BILLIONS!) have been wasted by companies trying to have mudball jQuery applications cleaned up? How many man-centuries have been wasted waiting for an over-built “web app” to load to display a static document? How many gigawatts (and fuel and so on) are wasted on processors crunching spurious bullshit JS that never needed to be there?
This is a fucking plague. This is ludicrous spendthrift garbage. This culture of ignored externalities is killing us, folks.
No, because web assembly is going to let every chucklefuck use their pet language and framework(s). It’s going to be the goddamn tower of babel. Things are going to get so much worse.
Again, author clearly has no empathy for the poor schmucks who have had to actually deal with solving the messes left by other developers who shared the author’s philosophy–or the people signing their paychecks.
The author’s child is the little shit that runs around and sets fire to squirrels and breaks things and the author is a shitty parent for celebrating that behavior and telling other parents to let their kids do the same.
~
And then I saw that the author is an exec at npm, and it all makes sense.
Of course the author shills for the “evolving” web, because their business is predicated on that growing cancer and shitty development. Of course they’re going to insist “This is fine, this is the way things’re supposed to be”–their livelihood depends on it!
Author: You write shitty software. Your company writes shitty software. Your views on engineering are a net negative on the web. You are a bad person and you should feel bad.
Personal attacks are not acceptable here.
Was I attacking another user of this site? No.
Was I pointing out that the author knowingly supports bad software that directly impacts in a negative way thousands of developers? Yes.
Look, saying that “@gambogi you’re a goddamned carebear and your face is ugly and you stink” is a personal attack. Pointing out that somebody online in a position of power is making the world a worse place by their actions is not.
Now, perhaps “you are a bad person” should be person-first language “you are a person with bad thoughts and actions”–mea culpa.
EDIT:
Let me make vent a little more on this point.
A few years ago I had to deal with the stupidity of npm. I had to deal with npm’s decision to just use nested dependencies, with their derpy version management (shrinkwrap having been eventually introduced). Others had to deal with the entire left-pad debacle, but I personally along with my team wasted man-days on this.
That was time I didn’t get to spend with my family. That was time I didn’t get to spend exercising. That was time I didn’t get to spend posting online. That was time I didn’t get to spend eating, fucking, singing, playing, cycling, dancing, or anything else that makes me a human being.
That is time I’m never getting back.
And this bozo? This is the person responsible for the engineering that caused those problems.
We have to hold engineers accountable for their actions.
That doesn’t make it morally correct, especially when the package is being shoved down people’s throats with VC marketing money.
If people can’t interpret text at all, they shouldn’t be online.
Nothing is as frustrating to read as apologetic “I’m sure you are a nice person with your family, and even Hitler painted roses, but when it comes to your position in the public eye and the way you exert power, I find your actions disagreaable to say the least, and if political correctness had not won, I’d call them outright evil!”
It’s ok to say someone’s bad every once in a while and let the reader figure it out.
I agree with you. I just want to point out that mobile reddit is complete and utter JS-laden abomination. They probably know how bad it is, because they heavily advertise their mobile application. I even think it is intentionally bad, to push the app down their users throats.
It used to be so simple too…
I’m a fan of their
.compactview: https://www.reddit.com/.compactWhen I saw this I thought I had accidentally submitted a partial draft with the exact same title
I thought about making something like facebook before facebook existed.
Instead, you posted about it on Lobste.rs, and in an alternate timeline, The Zuck just stole it, ran all the way to a time masheen, and now look where we’re at.
What’s described isn’t a company, it’s a software project.
Multiple projects with the same rules == company, isn’t it?
Nope. I’m part of consulting company, so the “rules” in our project widely diverge, as we often support external projects.
From what I know about Thoughtworks, they meet a lot of these requirements, and also are a mainly consulting-based company. Sure it’s a lot of work to ensure you can enforce your requirements when working with clients, but it probably pays off in the long run.
Thoughtworks is often “we do the whole project from you”-consulting, because that sounds nicer then “team-selling”. We consult for specific technologies and are just 10 people, spread over 5 projects, most of the time.
Sure, it makes sense, and they can do that, but I enjoy solving hard database problems where people have direct issues, I’m not gonna enter their building and start by introducing new development methodologies first. (unless they may be a source of the problem)
Everything I wrote was about internal software projects, so I scaled this to the company. Maybe I’m wrong with these assumptions.
This. I’m slowly thinking about career direction and while technicalities are interesting, the foremost thing is the business model and people - is it something I’m morally okay with? Do the people have a DNA where I feel like “the worst drummer in the band” (I.e. a feeling that I’m learning)? Will the work be spread such that I’m not just assigned things nobody else wants to do?
I’m not sure why this is share-worthy. What is the content here that people are upvoting? Not trying to be snarky - genuinely interested if there was something I missed.
Not sure why it isn’t. It’s an interview about a [good] dev and an open-source maintainer, and the post fits perfectly under the
persontag :)The title needs to be fixed to be more useful (is the link her personal site, a biography, some post about her?).
She has been one of the more consistently public, helpful, and relatable faces of Docker for years. Good presentations and demos.
It’s not really that much about her, though, unfortunately.
It reads like “docker kubermetes docker, a couple observations about open source, generic advice, plug for help for docker or kubermetes”. She seems like a perfectly nice person, but she doesn’t seem that much more noteworthy than any of a thousand other open-source developers paid to work on infrastructure projects. The interview doesn’t really cover anything personal about her, it doesn’t have her saying anything we haven’t heard a thousand times before or at least going in-depth on a story to explain her advice. The
systemd->buttstransform was amusing, to be sure, but otherwise why?I hate to be this, well, mean, but shouldn’t we be using the
persontag for people of, well, note?~
And yes, this is kind of a core problem with the
persontag. This person isn’t that interesting–given the information in the submission–to me, for example, but I could probably pick some alternate submissions that might be equally uninteresting (a person I know who is a greybeard at GOOG and has some cool projects.But where to draw the line without being petty? What makes articles under
peoplegood articles (instead of PR puff pieces)? Therein lies the rub.I get that anger is in your username and stuff but if you describe your own post as mean it’s probably not constructive.
She is without question “of note” in the open source community. Especially in the infrastructure / “devops” space.
If you don’t know her, maybe that’s not your thing?
I think the problem here is that the interview doesn’t really say enough to convince someone that she’s worth interviewing. If you know her, you get it. If you don’t, then… we’ll, this isn’t helping, unfortunately.
You’re right. Unfortunately, I don’t know that anyone who’s already “soaking in it” will take the time to write the “Hey, all you folks not in Devops, this is why Jesse is awesome!”.
Maybe a little bit of open mindedness on people’s parts would help?
Yes! This is the key. We should probably trust our community a bit more than suggest an post with a decent number of points is irrelevant.
Clearly not “without question”, right? Perhaps in the Docker/Kubermetes realm, but the article itself really doesn’t give much information about her, why she’s a big deal, or what she’s done. And that sucks, because people here are pointing out waaaay more interesting accomplishments she’s had.
But again, the problem with the
persontag is that you and I can both draft up a list of at least a half-dozen devs that are “of note” and yet the other one of us will go “huh?”. And in a few decades time, probably none of the people on those lists will be remembered.IMO it comes down to what people want this community to be about.
I can totally see the angle where “person” violates the spirit of the place - what makes Lobsters great is all hardcore tech - all the time.
I can also see the idea that showcasing awesome community contributors could be a good thing.
The person tag is for stories about people, not profiles. A link to one of her talks, an in-depth or technical interview, or any one of a number of her blog posts would not have been flagged as off-topic.
edit: I’ll also point out that in general the person tag is used alongside another tag. Cases of “person” alone are generally of some historical significance, an interview, or a death announcement; all of which are more substantive and/or better discussion topics than a simple profile.
I’m with you. The title alone means nothing to me. I thought it was going to be some sort of memorial when I first saw it. But there isn’t really much of any content there. There’s nothing technical in it. I don’t understand what we’re meant to get from it.
It fits HN more because that site is full of fluff like this, but I wouldn’t expect it here.
I completely agree, this is not the kind of content I want to see here.
FWIW this was only posted in here because it’s in the front page of HN. @av consistently posts whatever is popular there here (most of the time it makes sense, though).
I like this content, but I don’t think that something reaching the front page of HN is a good litmus test for if it should be cross-posted here
Lots of people don’t know where to start, and stories like this can be helpful. Lobste.rs has previously made similar pages for some of our users.
Well, the community has voted for it so I guess you’ll just have to avoid clicking the link and move on then.
By the same argument tabloids are the best because there’s lots of demand for them!
So it starts off saying “not meant to be insulting to anyone or anything” and then, a bit below, they decide to take “designed for stupid people” as an actual reason of why Go is not good? I can’t say I’m impressed.
To be fair, the author is just listing what other people have said about go and their major points. The author themselves did not say that Go is “designed for stupid people”, they included someone who did say it.
I refuse to accept that as valid; quoting someone is an action too. Author could have decided to leave that out, because let’s face it, it brings nothing to the table. Both of the articles cited for that point have a lot of other stuff that they are cited for, as well. To be fair, I’m probably nitpicking, but it still irritates the hell out of me when people pull together a list of reasonable concerns, and then plop in a “you’re stupid” trump card. I’ve worked with the “you’re stupid” trump card for a year and a half, now. I really dislike it. A lot.
[Edit: when I say “work with”, I mean “had a coworker who kept a trump card unreasonable argument nearby at all times”]
Personally, I would feel i’d either have to leave the article out entirely (which may have been what I did) or include the “point” in the list. It would have felt incomplete/wrong to me otherwise.
i got voted down as a troll for saying this in another subthread, but direct, deadpan quoting of someone who says something over-the-top is a definite form of humour. “psuedointellectual arrogance of Rob Pike and everything he stands for” was a big tell, but the overall “tone” of the page is subtly (and i’d bet intentionally) funny, regardless of whether it serves a useful purpose or not.
I doubt they’re falling Go users stupid; it’s probably a reference to Rob Pike’s (one of Go’s creators) comment “They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
It was definitely a poorly expressed point by Rob Pike but making a language easy to use is absolutely the whole point of language design. And really, Go is very easy to learn and provides a very low barrier to getting real work done. So that’s a great thing.
That is really not the case. “Ease of use” is only one dimension of a language, and one that’s commonly overoptimized for to the detriment of other properties like correctness, efficiency, readability, maintainability…
Google “rich hickey simple made easy”
Okay, so a hit on pride, but how is that a shortcoming of the language? If it’s a driving point of design decisions, it would result in the language being weak-sauce, but in and of itself, it’s not a weakness of the language.
Personally I’ve never understood the comment as developer mistakes seem like the greatest motivator for strong type systems and uh, not including null.
“I’m sorry if you feel offended”.
Am a bit underwhelmed by this article, as a long time Python programmer I’ve been eyeing Haskell for years but never invested the time to try for real. I would love to see an article from someone who made the jump, like Brian O'Sullivan.
Here you go: https://lobste.rs/s/lto5en/becoming_productive_haskell
Stephen Diehl has a pretty comprehensive list of useful things to know: http://dev.stephendiehl.com/hask/
not haskell, but you should enjoy the posts about 0install’s migration from python to ocaml
I feel like a couple reasoning steps were skipped between the assertion and the conclusion on this stage.
That’s because this could be construed as clever marketing/advertising. :)
I’m not a rust person, figured I’d give it a try.
Can’t get the
hello-worldexample to build because cargo can’t fetch the crates index because of some git issue talking to https://github.com/...Every time I try projects like this, and the tooling is wonky, it makes me appreciate golang that much more.
Fascinating that someone voted this down as (incorrect). I can show you my terminal if you want, this did actually happen, and is actually a defect.
Too bad this happened. Given the limited info you gave it could be different things: 1. a transient error connecting to github 2. a proxy in use that somehow breaks the connection 3. using a broken version of cargo (yes, we had that recently…)
From my own experience I find the Rust tooling far more reliable than what Go offers.
Do you think that’s because golang has concretely better tooling in some way or because you’ve grow accustomed to its quirks? I’ve experienced the promising new library without a working example a lot, regardless of language. I’d be curious to hear what approach go takes that can address it.
Quirks that hang up new golang devs:
* $GOPATH
* the import system
* (new) vendoring
Things that golang gets right:
* When things fail, they fail in very transparent ways. An example would be, if I had the above issue, I would 100% be able to reproduce it if I tried a
git clonemyself, vs. rust where it’s not shelling out and it’s some other configuration or library issue.* golang has no configuration files, everything you need can be inferred by what’s on disk.
Basically it comes down to, an initial hurdle of slight magic with golang, and then extreme transparency and logic with everything after that initial acclimation period.
On other end of spectrum, I had to try to code something in a hurry on a new computer without knowing tooling or programming due to memory loss. FreeBASIC did a simple install, I/O worked as in tutorials, typed stuff into text editor, and ran compiler with terminal command.
Effortless just like QBasic I started with ages ago. Another good one from my early time was LISP box or something like that. Integrated everything from editor to compiler in one executable. Stuff like this is how I judge how easy tooling is to install and get running with.