This is only tangentially related, but one thing that I am still kind of hopeful about is analytic combinatorics will free us from the tyranny of asymptotic analysis.
I suppose this is kind of a hot take, and in some ways less relevant than it was (say) 10 years ago, but I believe the theoretical CS community has spent a lot of time analyzing the performance of various algorithms over the years and kind of pointedly not inventing algorithms which accomplish some result at all, even if it is only known to be computable in a pathologically inefficient way. This means a lot of breakthroughs that could have been TCS breakthroughs have been invented, usually worse, by other communities.
I am not the only one who thinks so, here[1] is an obscure talk where Michael Mitzenmacher (a well-known CS theory prof at Harvard) makes more or less this specific complaint.
One of the nice things about Flajolet/Sedgewick[2] (mentioned in this post) is that it gives a nice set of combinators for (at least it seems to me, in theory) precisely enumerating how many "steps" an algorithm would take given some input. I optimistically imagine a world where we replace the relatively non-specific asymptotic bounds of an algorithm with a very specific quantification of the work an algorithm will take. And that this in turn would free TCS to focus on things that are more germane to the field as a whole.
With that all said I'm open to the argument that TCS has fundamentally changed and this is no longer such a big issue. But perusing the various TCS conferences I sense it isn't.
> One of the nice things about Flajolet/Sedgewick[2] (mentioned in this post) is that it gives a nice set of combinators for (at least it seems to me, in theory) precisely enumerating how many "steps" an algorithm would take given some input. I optimistically imagine a world where we replace the relatively non-specific asymptotic bounds of an algorithm with a very specific quantification of the work an algorithm will take. And that this in turn would free TCS to focus on things that are more germane to the field as a whole.
Check out the Art of Computer Programming, by Knuth. He writes all of the algorithms in a hypothetical machine code called MIX (MMIX in later editions). He does go through algorithmic analysis to the degree you describe, showing exactly how many cycles a particular routine may take to complete, based on different variables. This is actually fairly complex even for simple programs. Consider the simple case of computing the maximum in a list:
let current_max := 0
for x in array_of_numbers {
if x > current_max {
current_max = x;
}
}
return current_max;
Anyone can tell you this runs in O(N) time. But exactly how many cycles would this take? Ignoring the architectural details, you would need to know how often the condition "x > current_max" is true. If the list of numbers is in ascending order, this will be true every time, if it is in descending order it will only be true once. The difference in the number of cycles between those two cases is significant. I believe Knuth works through this example, and shows that, for a randomly-ordered array, this would be true around log_2(n) times.
I actually have read a chunk of the relevant TAOCP, but didn't mention it because the comment was already kind of long. I remarked to a friend the other day that it's kind of funny that we've a little bit come full circle on asymptotic analysis in that we are now counting FLOPs, and it is not a little bit like what Knuth does here. :)
I think this needs the use of a CAS (Computer Algebra System, like Mathematica) to calculate the runtime of some code relative to different choices of computer architecture. Then it looks practical. Could even be added to IDEs. But without the help of a CAS, few people would attempt this, because it would be too tedious to do by hand.
Natural log of n, actually. That's because the expected number of times a new max is found is H_n, the nth harmonic number, where n is the size of the array. And H_n = ln n + gamma + o(1).
I don't think it's controversial to say that asymptotic analysis has flaws: the conclusions you draw from it only hold in the limit of larger inputs, and sometims "larger" means "larger than anything you'd be able to run it on." Perhaps as Moore's law dies we'll be increasingly able to talk more about specific problem sizes in a way that won't become obsolete immediately.
I suppose my question is why you think TCS people would do this analysis and development better than non-TCS people. Once you leave the warm cocoon of big-O, the actual practical value of an algorithm depends hugely on specific hardware details. Similarly, once you stop dealing with worst-case or naive average-case complexity, you have to try and define a data distribution relevant for specific real-world problems. My (relatively uninformed) sense is that the skill set required to, say, implement transformer attention customizing to the specific hierarchical memory layout of NVIDIA datacenter GPUs, or evaluate evolutionary optimization algorithms on a specific real-world problem domain, isn't necessarily something you gain in TCS itself.
When you can connect theory to the real world, it's fantastic, but my sense is that such connections are often desired and rarely found. At the very least, I'd expect that to often be a response to applied CS and not coming first from TCS: it's observed empirically that the simplex algorithm works well in practice, and then that encourages people to revisit the asymptotic analysis and refine it. I'd worry that TCS work trying to project onto applications from the blackboard would lead to less rigorous presentations and a lot of work that's only good on paper.
Average-case complexity can be a fickle beast. As you say, the simplex algorithm for LP is great in practice, so it's rarely problematic to use. But meanwhile, people also say, "Modern SAT/SMT solvers are great, they can solve huge problems!" Yet when I try using one, I usually run into exponential runtimes very quickly, especially for unsatisfiable instances.
Overall, it's annoying to tell whether an NP-hard problem is always really hard, or if ~all practical instances can be solved with a clever heuristic. It doesn't help that most problems receive little attention (e.g., to find solvable special cases) after being labeled NP-hard.
> most problems receive little attention (e.g., to find solvable special cases) after being labeled NP-hard.
Since I know quite some people who exactly work on this kind of problem of finding special classes that can be solved in polynomial time, my impression is of course different.
But I think it can be said that if some NP-hard problem is very important in practice and there is no easy way to to get around this problem (i.e. it will also be practically relevant in, say, 15 years), the problem will for sure get a lot more attention.
This is also the reason why some NP-hard problems are much more researched than others.
Yeah, perhaps I was a bit unfair, it's just that the problems that have gotten good results never seem to be the ones I need! C'est la vie, I suppose. (In particular, I've been working with recognizing small formal languages from samples, which has usually NP-hard, but has a surprising number of solvable cases. But my impression is that most modern work has gone into various forms of probabilistic grammars, which aren't really what I'm looking for.)
Sometimes it's also helpful to look into approximation algorithms, e.g., a good LLL implementation can work wonders for certain problems. But heaven forbid someone obtains an inapproximability result for your problem, then you're really in trouble.
> But heaven forbid someone obtains an inapproximability result for your problem, then you're really in trouble.
This is not (necessarily) true:
For example, there exists a great approximation algorithm (Goemans-Williamson algorithm) for MAXCUT in graphs with non-negative edge weights.
On the other hand, when negative weights do occur, one can show (unless P=NP) that there exists no polynomial-time approximation algorithm for which the approximation guarantee is a constant factor times the optimal solution.
But since the Goemans-Williamson algorithm is a great algorithm (if the Unique Games Conjecture holds, and P != NP, it has the best approximation guarantee that any approximation algorithm for MAXCUT with non-negative weights can get in polynomial time) nobody "forbids" you to use it in situations where also negative edge weights can occur. You will loose the approximation goodness guarentee, but in practice, this algorithm nevertheless gives good results in this situation, just not certified good results.
I just meant that there are lots of problems where I think TCS could have contributed but didn't, because the relevant analysis was not acceptable at FOCS or SODA (or whatever). A good example is the original transformers paper, which is vastly over-complicated relative to (say) a later treatment[1] by Ruslan Salakhutdinov's lab, which shows that attention is "just" plain-old Nadaraya-Watson kernel smoothing—which if you don't know is a weighted average of points covered in elementary grad stats.
I'm not saying it was TCS people would be "better" at discovering this or anything like that, I'm just saying that the opportunity for contribution from TCS people is very high, and because the fields are not well-integrated you often have to wait years to uncover what ML concepts "really" are. I think working together would benefit both ML and TCS!
> I optimistically imagine a world where we replace the relatively non-specific asymptotic bounds of an algorithm with a very specific quantification of the work an algorithm will take.
I think you're getting this backwards. The (good) point you and Mitzenmacher are making is that our analysis standards are _too strict_, and hence we avoid good algorithms that are just too hard to analyze.
If we instead require exact combinatorics, e.g., using Flajolet/Sedgewick, that will be _even harder_ than if we _just_ try to do asymptotic analysis. Remember that asymptotics are a way to _approximate_ the exact number of steps. It's supposed to make it _easier_ for you.
Oh I think there is no real doubt that this is true, it's why analytic combinatorics did not succeed in replacing asymptotic analysis. I just wish it had. If it was tractable in a similar set of areas I think a lot of things would be quite a bit better.
His point is exactly that, often researchers care only about worst-case analysis and asymptotics, which is not necessarily a useful scientific analysis of how long an algorithm is expected to take on a machine as a function of the input size (which was the original motivation for Knuth etc to develop the field).
The same authors (but ordered as Sedgewick and Flajolet!) also have a book called An Introduction to the Analysis of Algorithms; there's a course website at https://aofa.cs.princeton.edu/home/ and videos on Coursera (https://www.coursera.org/learn/analysis-of-algorithms) — it is advanced mathematics but less advanced than the Analytic Combinatorics book.
Coincidentally I just did an asymptotic complexity analysis yesterday (something I rarely do). It seemed right since it's by the book but I wasn't sure. After running the extensive benchmarks on the algorithm, I was so happy to find the results matched the asymptotic prediction. The lesson is verify, verify, and always verify.
I'm not a researcher, so start with the default assumption that I don't know what I'm talking about, but I had the same impression when studying those topics, asymptotic analysis is kind of broken.
For example, we assume that arbitrary arithmetic takes constant time. Good. Except that if you take that seriously, then P=PSPACE. So we might say that bit operations on fixed registers are constant time. But nobody does that because then arithmetic is O(lg n) and it's too much trouble to keep track of everything (and if you do, then hashtables aren't O(1) any longer!) If we are more sophisticated we might take a transidchotomous model, but that's really weird and we have results like sorting in less than n lg n time.
Not to mention that the mathematical foundations get a bit shaky with more than one variable.
I think the hard problem underneath is that it's hard to define a computational model that (a) can be reasoned about and isn't extremely weird, (b) has solid mathematical foundations, (c) is reasonably predictive of real world performance, and (d) is not linked to a specific architecture. Asymptotic analysis is kind of a compromise. It can be formulated in very elementary terms, it makes mathematical sense and if you plot the performance of a sorting algorithm on a chart it kind of looks like the graph of n log n if you squint a bit.
Knuth does something similar to what you're suggesting IIRC, albeit without the analytic combinatorics machinery. For some programs he derives a precise expression as a function of the size of input that describes how many operations of each kind the underlying machine will perform. In numerical analysis there is a similar concept, e.g. evaluating a polynomial with Horner has the same asymptotic complexity as the naive method, but we say it's better because it takes exactly the optimal amount of floating point operations (and, in practice, because it uses fused multiply-adds, but that's another story...)
A research program along those lines would be certainly fascinating, but the combination of "needs to be reasonably predictive" and "needs to be portable" is a tough nut to crack.
Yep, I mentioned this elsewhere in the threads—Knuth does do this quite a bit in TAOCP. I think in a lot of ways we've ended up completely full circle, in that we are now counting FLOPs. This time though I think we have very little hope for something as nice and pretty as asymptotics. At least ones that are useful.
> For example, we assume that arbitrary arithmetic takes constant time.
Arithmetic on fixed-width number types is constant. It's very much not constant on arbitrary precision integers, something that underpins much of cryptography. Indeed, if you try to e.g. use Gaussian elimination (which uses O(n^3) arithmetic operations) to compute the determinant of a large integer matrix, you'll run into trouble, which is why there is another algorithm for this use case: https://en.m.wikipedia.org/wiki/Bareiss_algorithm
My sentence there is a bit unclear -- I meant it as an implication.
Arithmetic on fixed-width registers in O(1) is equivalent to saying that bit operations are O(1), which intuitively makes the most sense, after all adding two uint64 is not the same as adding two arbitrary precision integers. But that's not always the model we pick, often we just assume that arithmetic is O(1) and sweep length considerations under the rug.
Also, what does fixed mean? Is it like the word size in an actual computer architecture, where registers are 64 bits and that's all you'll ever get, or it depends on the size of input? Because the latter is the transdichotomous model, yet another option. Unsurprisingly you can get different results with different computational models.
This is not to say that asymptotic analysis is wrong, obviously, but it's a bit of a mess and it's important to remember what computational model the analysis was performed under.
> But that's not always the model we pick, often we just assume that arithmetic is O(1) and sweep length considerations under the rug.
So, I only have rudimentary undergraduate knowledge about complexity theory, but my materials (e.g. in theoretical CS, cryptography and computational algebra) were always incredibly clear about the fact that arbitrary integer arithmetic isn't constant - this is why complexity classes such as weakly vs. strongly NP-complete exist. Do you have any examples of where people would treat arbitrary length integer arithmetic as constant? (I think most people just never have to use arbitrary precision arithmetic, so that's why they'd not talk about it explicitly.)
You're right that computational complexity depends on the model and that this makes it nontrivial to use in practice. The theoreticians would sweep this under the rug with "these models are all polynomially equivalent to Turing machines" (which lets us formulate a conjecture such as P=NP precisely), but of course that doesn't in practice help you distinguish between a constant, linear or quadratic algorithm.
> I optimistically imagine a world where we replace the relatively non-specific asymptotic bounds of an algorithm with a very specific quantification of the work an algorithm will take.
My understanding is that it's pretty much how it started, but proved to be impractical. Meaning, we absolutely can quantify the work any algorithm will take, but for that we need to define the architecture first, i.e., to specify what is the unit of work, what are operations available to us. And, sure, we can do that for any given task (and we always could), but it's usually too messy to include that in general discussions about algorithms, not specifically concerned with the architecture.
In cryptography it is common to get exact estimates for the number of bit operations required to break a cipher. Asymptomatic analysis is great in some circumstances. It for example explains why quicksort is faster than bubble sort for large inputs. Beyond that you want some empirical results.
I am one of these people! I am one of a handful of people who speak my ancestral language, Kiksht. I am lucky to be uniquely well-suited to this work, as I am (as far as I know) the lone person from my tribe whose academic research background is in linguistics, NLP, and ML. (We have, e.g., linguists, but very few computational linguists.)
So far I have not had that much luck getting the models to learn the Kiksht grammar and morphology via in-context learning, I think the model will have to be trained on the corpus to actually work for it. I think this mostly makes sense, since they have functionally nothing in common with western languages.
To illustrate the point a bit: the bulk of training data is still English, and in English, the semantics of a sentence are mainly derived from the specific order in which the words appear, mostly because it lost its cases some centuries ago. Its morphology is mainly "derivational" and mainly suffixal, meaning that words can be arbitrarily complicated by adding suffixes to them. So baked into English is word order that sometimes we insert words into sentences simply to make the word order sensible. e.g., when we say "it's raining outside", the "it's" refers to nothing at all—it is there entirely because the word order of English demands that it exists.
Kiksht in contrast is completely different. Its semantics are nearly entirely derived from triple-prefixal structure of (in particular) verbs. Word ordering almost does not matter. There are, like, 12 tenses, and some of them require both a prefix and a reflective suffix. Verbs are often 1 or 2 characters, and with the prefix structure, a single verb can often be a complete sentence. And so on.
I will continue working on this because I think it will eventually be of help. But right now the deep learning that has been most helpful to me has been to do things like computational typology. For example, discovering the "vowel inventory" of a language is shockingly hard. Languages have somewhat consistent consonants, but discovering all the varieties of `a` that one can say in a language is very hard, and deep learning is strangely good at it.
I am also working on low-resource languages (in Central America, but not my heritage). I see on Wikipedia [0] it seems it's a case of revival. Are you collecting resources/data or using existing? (I see some links on Wikipedia).
We are fortunate to have a (comparatively) large amount of written and recorded language artifacts. Kiksht (and Chinookan languages generally) were heavily studied in the early 1900s by linguists like Sapir.
re: revival, the Wikipedia article is a little misleading, Gladys was the last person whose first language was Kiksht, not the last speaker. And, in any event, languages are constantly changing. If we had been left alone in 1804 it would be different now than it was then. We will mold the language to our current context just like any other people.
Super interesting, thank you very much for sharing your thoughts!
HN is still one of the few places on the internet to get such esoteric, expert and intellectually stimulating content. It's like an Island where the spirit of 'the old internet' still lives on.
I am applying for graduate school (after 20 years in the software industry) with the intent of studying computational linguistics; specifically, for the documentation and support of dying/dead languages.
While I am not indigenous, I hope to help alleviate this problem. I'd love to hear about your research!
I did research on entirely unrelated NLP, actually. I worked on search for awhile (I am corecipient of SIGIR best paper ‘17) ad a bit in space- and memory- efficient nlp tasks.
Wow kiksht sounds like a pretty cool language! Are there any resources you'd recommend for the language itself? I'm mostly curious about the whole "a verb with prefix structure can be a whole sentence" thing, that sounds like a pretty cool language feature!
So, bad news. Culturally, the Wasq'u consider Kiksht something that is for the community rather than outsiders. So unfortunately I think it will be extremely challenging to find someone to teach you, or resources to teach yourself.
How do you combine that feeling/observation together with what you're working on now, which I'm guessing you'll eventually want to publish/make available somehow? Or maybe I misunderstand what the "it will eventually be of help" part of your first comment.
I’m not sure that the AI itself has many ethical complications. Many terms of service grant AI companies ownership of the data you supply to them though and that very problematic for many tribes which consider the language sacred and not to be shared.
Good luck I wish you the best. I think you will almost certainly need to create a LoRA and fine tune an existing model. Is there enough written material available? I think this would be a valuable effort for humanity, as I think the more languages we can model, the more powerful our models will become because they embody different semantic structures with different strengths. (Beyond the obvious benefits of language preservation)
There is more material than you'd normally find, but it is very hard to even fine-tune at that volume, unfortunately. I think we might be able to bootstrap something like that with a shared corpus of related languages, though.
You can always fine tune with the corpus you have and then try in context on top the fine tuning even if it’s insufficient. Then with that - and perhaps augmenting with RAG against the corpus - you might be able to build a context that’s stable enough in the language that you can generate human mediated synthetic corpuses and other reinforcement to enrich the LORA.
> I will continue working on this because I think it will eventually be of help.
They say language shapes thought. Having an LLM speak such a different language natively seems like it would uncover so much about how these models work, as a side effect of helping preserve Kiksht. What a cool place to be!
I learned it from my grandmother and from Gladys's grandkid. Gladys was the last person whose first language was Kiksht, not the last person who speaks it.
Maybe there are some sources talking about fully fluent people still being alive? As currently the article gives the impression they were the last person to "fully" speak it.
I’m aware and I think people do not care much to correct it. The tribe has had consistently bad experiences with outsiders attempting to document this kind of thing and I sense that people are mostly wanting to be left alone at this point. There is some possibility that I would make a different decision, but it’s not for me to decide, it’s for the elders.
I really love this article. I made the transition in the opposite direction: I am a distributed systems engineer who found himself working on a collaborative text editor, and initially it was very unintuitive to me that text editors were not a completely solved problem.
One of the most confusing things about the space is that you only learn after using every high-level editing library (Lexical, etc.) that ProseMirror really is the right abstraction, a masterpiece of engineering and architecture. The reason this is unintuitive is because ProseMirror is essentially the same level of abstraction as a compiler middle-end, and it's surprising that there are no higher-level abstractions that seem to work better in practice. If you are doing something remotely non-trivial, you will need the customization that only ProseMirror provides, and you will learn that the hard way. You will need the decade of bug-fixes for various touch devices and old browsers, you'll need the careful work that has gone into performance, and so on.
For a long time the missing piece was that (1) PM defaults are not what the vast, vast majority of users want, and (2) it is nearly impossible to get it to work cleanly with React. react-prosemirror, in my view, is the solution. Every day I am happy that I get to work with it, and I am not sure what we'd do without it.
>If you are doing something remotely non-trivial, you will need the customization that only ProseMirror provides, and you will learn that the hard way.
As far as I know Meta's Lexical [1] (used by Facebook, Whatsapp, and Instagram) is goes also a similar direction: customizable, but it takes time to get used to it.
Does ProseMirror handle large files well? One thing that impresses me hugely about browsers is that they all seem to render pages of seemingly unlimited size robustly and with speed (for example, whole novels on Gutenberg.org).
In my experience no similar editor, including Google Docs, can deal with documents more than 10-12 pages but I haven’t tried ProseMirror AFAIK.
I’d love to hear what people are reading to actually understand this. At this point I will openly admit that I do not know if what’s happening in Argentina is good or even on purpose. I sense that everything I read is at best motivated reasoning and at worst propaganda, and I’m not skilled enough to determine what is correct and what is not.
One of the things I like about this paper is the pristine, crystal-clear English it uses to describe things I thought I knew extremely well:
> Processes are the software analog of processors. They are the units of software modularity, service, failure and repair. The operating system kernel running in each processor provides multiple processes, each with a one gigabyte virtual address space. Processes in a processor may share memory, but for fault containment, and to allow processes to migrate to other processors for load balancing, sharing of data among processes is frowned upon. Rather, processes communicate via messages. They only share code segments.
"Processes are the software analog of processors." Yes of course. How easy it is to never ponder such a thing.
> "Processes are the software analog of processors." Yes of course.
Maybe this analogy worked in 1986 when hardware was a lot less reliable, but I don't think it goes very far these days: processes die all the time (normal termination, crash, get killed). When was the last time a processor or core died on you? In fact, according to this analogy most of us are running MS-DOS equivalent of systems since if your processor or core dies, your machine dies. And I don't see this changing any time soon.
I think the point they're making is that a process is a software abstraction that provides programmers the illusion of having a processor all to themselves. So in that sense the process is a software "analog" to the processor.
>When was the last time a processor or core died on you?
Almost every day. You may never experience if you only manage tens or hundreds of cores, but when you manage hundreds of thousands of cores, it happens.
I am being serious. There is a lot of value in making complicated things trivially understandable. I think it's not an accident, for example, that many of the highest-cited academic papers in CS are survey papers.
There is one other way in which you are not a failure, and I am sure that I am not alone in thinking about it: I have been reading your words for 15 years, from the time I was a baby CS major. That's really true, e.g., here[1] is a comment from 11 years ago where I mentioned that a lisp you wrote for the Apple //e informed a lisp for the Apple //e that I wrote.
Especially in my college years (2009-2013, ish), the world seemed smaller, and to me, a lot of what you wrote was like looking through a keyhole into the real world. Grown-ups can apparently write lisp at JPL[2]! Google was chaotic[3][4][5][6] to work in 2000, especially if you commuted from Burbank. A name change[7]. And, variously, surveillance, more lisp stuff, etc. Now I'm an adult and I still haven't professionally written lisp, but I'm glad to have read about it anyway.
Anyway, it might surprise you to learn that when I think of your writing, though, I think of your HN comments first. There is a kind of influence that you can only get with a steady, unthanked build-up of seemingly-small contributions over a long period of time. In the right place they compound. I probably cite you to other engineers once a month or so.
I think of GitHub as a sad story. There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues). There are dozens of upstarts "unbundling" features of GitHub that are genuinely useful, but which are under-loved and under-invested in, and surely some of those will become successful too. It feels like GitHub continuously invents the future, and then waits for someone else to make it truly great.
It is so painful to watch because I love GitHub so much. I graduated college in 2013, which means I started programming right when they got started. I read their dev blog every single day, eagerly waiting for new features (which were released every couple days). I watched their team page grow, I looked carefully at what they did to deserve a spot at such a cool company. I scoured the projects they contributed back to for hints about what good code looked like (my favorite was Vicent Martí's contributions to libgit2). I eagerly taught my friends how to use git because university taught subversion. I wrote my own Rails tutorials as a way to learn the magic.
But it's been years now, and it's not an easy love. It's work! It's so painful to watch it get continuously lapped by upstarts. I always just thought the core offerings (Pull Requests and Issues) would get better eventually. And now, 14 years later, they finally are. But very slowly. I really want to believe, but after 16 years, it is starting to sink in that GitHub might just be a place to store files.
The magic is still in there. I think there are lots of people like me, who want to believe. But it will take real agency to do it, and that's really hard to muster at this stage in a company's life.
I like GitHub precisely because it didn't try to capture the entire market of issue trackers and code search too aggressively.
If GitHub sub-issues had existed even in an inferior form back in 2019, developer-targeted trackers like Linear and Shortcut would have had a hard time existing, and all of their ideas (some of which have advised the UX of today's GitHub sub-issues release!) would have been lost to time.
Now, perhaps this was not value-maximizing to Microsoft, or value-maximizing to companies who now need an extra license for Linear - but I would argue that for actual developer experience, GitHub fostering a spirit of innovation through its own stagnation has created a vibrant ecosystem better than anything any company could do themselves.
Yes this is one of the reasons this discussion is so tricky. I just believe that if I maintain a popular project on GitHub I should not be automatically consigned to worst-in-class experiences for Issues and code review. I understand this is mildly controversial but I have had maintainer status on a few top 0.01% GitHub repositories and I have seen tools that do not suck, and so my opinion is that a better world is possible.
Again, I say all of this entirely with love. I love GitHub. I have used GitHub since I started programming. I want them to win.
> automatically consigned to worst-in-class experiences
You said it perfectly. This is why there are a lot of people willing to create better experiences on top of GitHub’s API.
I created CodeApprove (https://codeapprove.com) to improve GitHub’s code review and there’s also Graphite, CodePeer, Reviewable, and others doing a great job.
Any of them support dependencies between issues? Without it, it's still all worst-in-class experience for the purpose of managing work. Yes, this is distinct from issue tracking, which is an input, and usually external, but people seem to have this weird habit of trying to manage software projects using GitHub or GitLab issues.
> There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues).
I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at all.
Any developer's workflow consists of a) ticketing, b) revision control, c) auditing code and change history, d) CICD. Obviously a) b) and c) are tightly coupled and you cannot have one without the other, whereas d) invariably leads to a) b) and c) in any incident response scenario. There is no argument that justifies any alternative to a unified developer experience.
Sorry if this was not clear, but I am not making a normative statement that each feature should be broken out into its own tool. I'm saying that the revenue ramp on each these products is, empirically, good enough to be on track to IPO. So GitHub is apparently doing a bad enough job in each of those areas that three separate companies were able to break a feature out into a dedicated product, sell it on its own, and ramp revenue fast enough to support a venture class business. Absolutely wild stuff.
I feel like ticketing is something that has been pasted on for corporate reasons.
Keeping track of the work to be done doesn't require a ticketing system,
anyone remember using Story Cards? A whiteboard?
Well, if they wanted to implement keeping track of work to be done, they'd have long ago implemented subissues, sub-subissues, and sub^n-issues, because obviously work does not break down into a list, or a one-level-deep tree - the natural data structure for breaking down work is a directed graph (and if you really must do an 80/20 on it, then a tree).
Sadly, to this day, out of popular software packages used in software companies, only Microsoft Project and maybe Jira get this right. Unfortunately, they have plethora of unrelated issues that are big enough that they drive the industry towards silliness of managing work in tools like Trello or Github/Gitlab issues.
EDIT: I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks, you can't really plan ahead much further than a sprint. So is the Agile cadence really about avoiding the Folly of the Waterfall, or is it just shitty tooling that makes it exponentially hard to think ahead for more than two weeks? Did we invent "epics" because we can't link together multiple tasks on a Kanban board?
And then, how many companies SCRUM the living hell out of their developers, while PMs secretly plan the whole thing ahead in MS Project to keep the project on track towards some goal, and then pray no one on the dev team spots a Gantt chart open on their screen?
(Personally, I worked under one once; they begrudgingly admitted to managing everything in MS Project once I started asking if I can get a license, because even Emacs Org Mode sucks at the job if the job is to break down month's worth of work on entire deliverable.)
EDIT2:
> Keeping track of the work to be done doesn't require a ticketing system, anyone remember using Story Cards? A whiteboard?
Anyone remembers a project plan? Work breakdown structure? I know PERT looks to people like a Borg Cube, but then the status quo in software dev looks like Pakled technology. "We are devs. We scrum. Trello make us go!"
I find its subtasks a little half baked and I feel like portions of Jira weren’t designed with sub-tasks in mind. We actually avoid them completely at my current work.
It’s understandable why a lot of systems don’t support sub-tasks. Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.
> I feel like portions of Jira weren’t designed with sub-tasks in mind
That's true, and I can see why you avoid them. Last time I touched Jira, I quickly learned that subtasks are annoying.
Dependency releationships between tasks are more general and better overall. Unfortunately,
> Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.
Don't know of any software that fully figured it out. Even MS Project, which does the relationship and scheduling parts a-ok, is a PITA to use in general, and has some pretty annoying bugs that made me stop using it. Being able to irrecoverably brick the auto-scheduler and have it suddenly crash on opening the project file is a kind of show-stopper.
Another tricky challenge here is scope. Planning, scheduling and doing are three different mindsets, and it's tough to balance them all in a single tool. Someone who figures out how to do it well stands to make a lot of money.
> I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks
In the agile world it's accepted that a task that today looks like it depends on another task may not have that dependency next week.
Planning involves scheduling what the stakeholders prioritize now that can be done,
and whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled.
> Planning involves scheduling what the stakeholders prioritize now that can be done, and whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled.
Planning and scheduling/prioritizing are two distinct processes people often confuse. Planning is about identifying what needs to be done, and breaking it down into a network of tasks joined by dependencies. Scheduling is figuring out who's going to do what and when they're going to do it.
Planning is figuring out your service needs e-mail verification, password reset, and some transactional messages, to stuff like "design e-mail templates" "write templates for {verification, reset, account confirmation} e-mails", "set up infra for sending e-mails", "add {verification, reset} URL flows", "make it send {verification, reset, confirmation} e-mail on {{relevant action}}", etc. Scheduling is me assigning "design e-mail templates" to Joe in graphics dept. and giving him 3 days for it, assigning you the "set up infra" task and giving you a week, and knowing the "make it send ..." tasks won't start until next sprint, at which point we'll find someone to do them, etc.
In naive Agile reality, while <<whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled>>, it gets recorded somewhere (e.g. product backlog), but it won't have its dependency relationship encoded. So every sprint, someone goes over a heap of such tasks, and has to manually reconstruct those relationships, to the degree it lets them plan out the next sprint or two. This both adds work and limits the ability to plan forward (you ain't going to be even thinking about stuff that's obviously beyond the horizon).
While it's true that stakeholder priorities change (as they should), and this affects scheduling, it affects planning much less, as the dependencies aren't about order in time, they're about order in execution. Dependencies aren't volatile - no matter what the stakeholders think this week, you won't be able to work on "make it send emails" until you can send e-mails (infra task) and have e-mails to send (design/write) and have them be useful (endpoints/routes for links). This is useful information to have encoded, particularly with more interdependent features - not only the system will help you do the scheduling correctly, it'll also let you quickly tell that unscheduling work on X now will delay work on Y down the line, etc.
Planning and scheduling/prioritizing are split into separate things by people who think less about shipping working code and more about counting beans.
Shipping working code is a means to an end, not end unto itself. Planning and scheduling/prioritizing are split into separate things by people who think about and then tell the people shipping working code what they should be writing and shipping.
I hate bureaucracy and will actively question the necessity of any imposition of bureaucracy, and resist its imposition if it doesn't seem justified.
Nonetheless, there is use to more than just sticky notes. It tends to come with scale, and trying to coordinate and align teams of teams of teams of teams, etc.
Additionally, sticky notes are impractical for remote teams (would there be some always-on webcam pointed at them?)
Don’t forget code review. I created CodeApprove, but there are so many other good alternatives that could have been GitHub features (Graphite, CodePeer, Reviewable, etc).
FWIW, this specific feature - what they are now calling sub-issues - is actually better described as a framework for modeling proper parent-child relationships in their system, which is something quite hard to get right, mainly because it has to work somehow with the existing issues feature set. People building this feature from scratch (e.g. Linear) have it trivial to solve, because they didn't have any backwards compatibility issue to worry about. This is, of course, absolutely Github's fault for not designing it to accomodate such a thing easily in the first place, but the people who built this feature are probably not the same people who made that original decision.
They've been working on some version of this feature for several years now in various iterations. I believe this is either their third or fourth attempt to get it right - I was trialing a beta of some previous iteration of it a few years ago and it was incomplete/not fully well thought out which must be why they dropped it. I'd trust the feature here at least to be decent now, because of how many attempts they've had at it.
But yeah if I was a company like Zenhub I would be probably a bit worried at this announcement since it is almost inevitable that this specific feature is going to be enough for people to no longer need third party management of issues. I know in a previous company I worked for that specific feature (proper parent-child relationships) was the reason they used Zenhub, and same for my current company using Linear.
> FWIW, this specific feature - what they are now calling sub-issues - is actually better described as a framework for modeling proper parent-child relationships in their system, which is something quite hard to get right
That's a wrong framework to use. Parent/child relationship is a special case of dependencies between tasks, which can be more generally modeled as start/finish relationships, i.e. one of: Start-to-Start, Start-to-Finish, Finish-to-Start and Finish-to-Finish; parent-child relationship is Finish-to-Finish here. This distinction starts to matter if you want to plan out more work items than you can quickly eyeball on a Kanban board, and it's all well-trodden ground with nearly century worth of prior art, to which our entire industry is entirely oblivious.
Popular software occasionally spotted in use in our industry (usually by PMs, in secret) that supports it: MS Project, maybe Jira, ... is there anything else?
Once you have sizing, the ability to make an issue dependent, estimated start / end, don’t you have everything needed to generate a PERT / Gantt chart?
You also need the proper dependency types[0] I mentioned, though I'd say you can get away with FS for dependencies and FF for subtasks.
Beyond merely generating a Gantt chart, when you have dependencies and estimated duration you can start estimating how long things will take and which ones can take longer or be delayed without impacting overall project time; add the ability to provide constraints on start and end time, and you can automatically schedule work (and re-schedule at it happens).
Most of these things are in every system in some form or other, but dependencies seem to be missing almost everywhere - and dependencies are the one key component that enable major benefits and turn the system into a proper project planning tool.
Sorry, the goal here is not to trivialize GitHub, or suggest they suck at engineering, or even to say this is easy. I am just saying my own perspective, which is that I wish the core properties (pull requests, issues) had improved a long time ago. I have been a maintainer of a top 0.01% project, and I have seen it get in the way where other tools would have been tolerable. It hasn't always been easy to be a fan.
Ok, let's try from another angle. Close your eyes and picture the ideal, best, most successful product in this space, for whatever definitions those words mean to you.
Everyone is different, but I think most people would not picture a source control product where search, issues, and on-prem are each so terrible, the default solution for that feature is to use a completely different product from a totally different company, which solves that specific issue (Sourcegraph, Linear, GitLab, respectively).
> I started programming right when they got started.
Then let me tell you about SourceForge. SourceForge, around the time that GitHub started, had a lot of these features (or at least, the ones that were standard practice at the time). It was the de facto home of open source software development at the time, but it was also a megalith that tried to do everything.
GitHub was a breath of fresh air precisely because it had just the right balance of minimalism and features. There were plenty of truly minimalist hosts out there, so we didn't need any more of those. But we also had lots of bloated and slow code hosts. And it deserves to be stressed that the bloated ones were just as unusable as the minimalist ones, even while being (again, for the time) as feature-complete as they come.
Bloated products can't pivot. New features often don't integrate well with existing ones, and they take a long time to develop. We're seeing this with GitHub too, as feature velocity has dropped. But the difference is that GitHub's feature set, particularly their core initial feature set, was exceptionally well designed. They've lost a bit of this edge over time, but overall I think they've done a well enough job of balancing the thoughtfulness of their build-out with doing things at a reasonable speed.
I just want to emphasize this point because I think it gets lost, especially if you're not familiar with what the competition of the time looked like. GitHub absolutely would not have made it to where it is today if they had rushed to add features. For a comparison of what it looks like to build features first and put design on the back burner, see GitLab. There's a reason why I still find their product difficult to navigate despite it being one of the main tools I use in my day-to-day work. And I fear that if anything, GitHub is succumbing to the lure of feature count and becoming its own bloated monolith over time, even with their slow pace.
One of my formative experiences as a freshman in CS (I learned to program in college) was accidentally opening a PDF with Emacs and watching as it displayed not weird binary data but a real, rendered PDF. I wondered what else it was doing behind my back that I didn't know about.
Sadly, I was not able to run Doom in a PDF, in Emacs. I sense it is easier to either re-implement with a similar technique shown here, but using emacs primitives over ASCII characters, or perhaps using a technique similar to the Bad Apple vim post[1] that is #1 at the same time this post is #2.
I accidentally opened a pdf with less a few weeks ago and learned about pdftotext and all the other software that pagers can use to display arbitrary documents if set up correctly.
Reminded me of how modern linux distros decide how to execute a file. When I learned about that years ago, I spent far too long getting .exe files to run in either wine or mono when run on my machine. Fun exercise, not worth it.
The qualitative description here is pretty interesting, but so is the quantitative one here[1]. 1,600 ft tall, 220 mph top speed, inflicting 10 Gs for roughly 60 seconds, which induces cerebral hypoxia in the brain, causing death.
Seems like the drop is entirely unnecessary and mainly gamifies it, since the user has to press the button. You could easily just have an Incredicoaster-style magnetic propulsion system that takes you to 220 mph, producing the same effect without the distress. Other than the drop, losing consciousness in this way is relatively pleasant as a way to go (I know because it has happened to me).
I am Wasq'u (a tribe in the PNW), I am connected to my tribe, and I am one of a handful of remaining speakers of the language. I am really tired of being caught in the maw of people fighting about my identity, what I am owed, and to some extent what place my identity has in society.
To the pro-DEI crowd: I have some hard truths for you. Actual change requires commitment and focus over an extremely long period of time. That means you have to choose probably 1 cause among the many worthy causes, and then invest in it instead of the others. You can't do everything. The problems that afflict my community are running water, drug addiction, lack of educational resources, and secular trends have have made our traditional industries obsolete. I am not saying that land acknowledgements and sports teams changing their names from racial slurs are negative developments, but these things are not even in my list of top 100 things to get done.
We all want to help, but to have an impact you must have courage to say no to the vast majority of social issues you could care about, and then commit deeply to the ones you decide to work on. Do not be a tourist. I don't expect everyone to get involved in Indian affairs, but I do expect you to be honest with me about whether you really care. Don't play house or go through motions to make yourself feel better.
When you do commit to some issue, understand that the biggest contributions you can make are virtually always not be marketable or popular—if they are, you take that as a sign that you need to evaluate whether they really are impactful. Have the courage to make an assessment about what will actually have an impact on the things you care about, and then follow through with them.
To the anti-DEI crowd: focus on what you can build together instead of fighting on ideological lines. The way out for many minority communities in America is substantial economic development. In my own communities, I have seen economic development that has given people the ability to own their own destiny. It has changed the conversation from a zero sum game to one where shared interests makes compromise possible. If you want to succeed you need to understand that your fate is shared with those around you. In-fighting between us is going to make us less competitive on the world stage, which hurts all of us.
> To the anti-DEI crowd: focus on what you can build together
The problem with DEI-as-implemented is that it often not only contains overt discrimination against a group (based on a protected class), but also prohibits any criticism of this. When someone is being discriminated against, not subtly or silently but explicitly, intentionally and overtly, and then punished for daring to complain about it, that leads to a lot of resentment (both by the people directly affected and by other members of the same class that observe both the discrimination and the silencing).
I'd say that resentment is justified; unfortunately, I suspect the backlash will primarily hit the people that the DEI policies were supposed to help, rather than the perpetrators of the discrimination.
I totally get it. A lot of our wounds are still open, too. I'm not here to tell people how to feel, I'm just advocating for deciding what is actually important to you and focusing all your attention on it until it is resolved. I happen to think that citizens of the US are worth more to each other as sometimes-conflicting allies than as complete adversaries, but that is for everyone to decide on their own.
> that leads to a lot of resentment (both by the people directly affected and by other members of the same class that observe both the discrimination and the silencing).
Agreed. This is the fundamental flaw of a lot of social theories borne out of academia when they land in the real world. They thrive in an academic world where hierarchy is bought into by students eagerly and are transplanted into a world where people must accept hierarchy to survive.
> I'd say that resentment is justified
Resentment never makes anything better, no matter how justified. Unfortunately.
Ah yes I remember all the polls saying “Meta’s hiring policies” were in the top 1,303,886 issues voters cared about
That might’ve drove a few people to donate huge sums of money to information campaigns that fomented hatred, division, and distrust among voters, but no: American voters were not voting on big tech DEI policies.
White voters point to conversations about justice – for racial minorities, for the children of immigrants, for women worried about losing their reproductive rights, for transgender teenagers – and question why nobody ever talks about justice for them.
Few expect Trump to fix everything or believe him when he says he will. What they do believe is that the system is broken and corrupt, just as Trump says it is, and that a candidate who promises to tear it down and start again might just be on to something.
I think this goes in this direction. People don't care about "Meta's hiring policies" but they care about "wokeness", and news articles about the former lead to a perception that society has way too much of the latter and that it's a bad thing.
Isn't the point of affirmate action and some DEI measures to correct for centuries of systemic injustice? If so I don't see why groups that have benefited and reinforced their advantages for generations are now so easily offended by efforts to rebalance the scales.
I'm a white male who was raised comfortably middle class. The more folks I've met and the more history I've studied, it's pretty clear I was born with a huge number of advantages many of my peers didn't enjoy. I don't mind them getting preferential treatment, even if I'm more qualified once in a while.
So you are born in the middle class, then it is a class issue? Will Smiths son Jaden had it way better than you. The axis for where to look is just bizarre.
To really help, make sure the schools in poor areas are top notch, even better than upper class schools, and you will automatically fix the imbalance, without having to use equipment for darkness, dna samples to check the heritage and other clearly bizarre future paths.
> “Always remember that the people are not fighting for ideas, nor for what is in men’s minds. The people fight and accept the sacrifices demanded by the struggle in order to gain material advantages, to live better and in peace, to benefit from progress, and for the better future of their children. National liberation, the struggle against colonialism, the construction of peace, progress and independence are hollow words devoid of any significance unless they can be translated into a real improvement of living conditions.” - Amílcar Cabral
>to have an impact you must have courage to say no to the vast majority of social issues you could care about, and then commit deeply to the ones you decide to work on.
I strongly agree, but sadly I think what you're saying here is probably almost incomprehensible to a broad swathe of middle-class white Americans, to whom being seen to be outwardly supportive of every DEI-ish cause has essentially become something like personal hygiene -- a thing you do perfunctorily and without thinking. It's just "what you do", "what a civilised person does", etc.
I'd be interested to hear more about what you have seen work and not work for economic development in these communities.
In our area, it is mostly resorts and casinos. Economic development gives everyone in the area jobs and opportunities. This has changed the picture from "Indians begging the Bureau of Indian Affairs (BIA) and local government for resources" to "we have a robust economic engine which is a critical part of the greater surrounding community, and which we'd mostly all like to succeed, but need to work through details on." It's not perfect and there's still conflict but it's much easier to work together in the latter situation.
Could you please explain this part? I am not sure how you meant it. Is the main problem that the resources are not in the language of your tribe? Or is that a lack of educational resources regardless of language (e.g. simply not enough textbooks to give to each child)? What kind of educational resources do you wish you had?
Great questions. The kids mostly speak English as first language, and the schools are in English. With the exception of one huge twist, the schools have many educational difficulties you'll find in rural America generally—it's hard to get money for materials and curriculum, hard to recruit good teachers, hard to get students connected to people with practical advice/guidance, hard to get connected to opportunities, hard to reach escape velocity, and so on.
So, what's the twist? Tribal schools tend to be administrated by the federal government which makes problems extremely slow and hard to address. With some asterisks, the local elementary school was basically provisioned as a consequence of a federal treaty with the US Senate, and is/was mostly administered by a the Bureau of Indian Affairs (BIA), which rolls up into a federal department that until 2020ish, had never been run by a native person. All of these things make it very tricky to work with.
In spite of that, believe it or not, this is a massive improvement: until relatively recently, the school was a mandatory boarding trade school meant to teach kids to be (basically) English-only maids. This lead to a substantial percentage of the population being either illiterate or semi-literate, with no meaningful work experience, and with very very few opportunities that were not menial work. That inertia is extremely challenging to overcome, and the most natural place to try is the education system, which generally is simply not up to it.
I am stating these as a neutral facts on purpose. Regardless of how we got here, the hand is ours to play. Some of us got out and whether we succeed in the next generation depends on whether we can mobilize the community to productively take advantage of the resources we do have. This is why it's painful to me to hear about, e.g., land acknowledgements. If you have seen this pain firsthand I just do not see how that can be the #1 policy objective.
Land acknowledgements are easy. They're not a policy objective. Most DEI stuff, it's the result of being in a room where you're trying to get some real change accomplished and you just give up with the decisionmakers and say "OK, whatever, do nothing about this problem, but could you at least admit that the boarding schools were bad?" And they agree because it gets them out of the conversation. And no, it's not going to solve everything, it might not even solve anything, but it's nice to at least have some agreement on things that we definitely shouldn't do again, even if we have no idea how to fix the damage.
> I am stating these as a neutral facts on purpose. Regardless of how we got here, the hand is ours to play.
Yeah.
English as a first language is a huge advantage (you have most of the internet at your disposal, with tons of educational resources), but illiteracy is a huge problem.
> hard to recruit good teachers
Good teachers are rare. I wonder if you could find some people to teach who are not teachers in the usual sense. People having a different job, or university students, who would just come and teach kids one lesson a week. It's not perfect, but it could be the most popular lesson, just because it is unusual.
But the important part would be to grow your own teachers; help the best kids become the teachers of the next generation. Maybe you could encourage kids to do this from the start; for example, take the best kids at each grade, and tell them to teach some younger kids one lesson a week.
I wish I could help, but I'm on the opposite side of the planet.
Not sure where you see assumptions. There are many possible problems, and I don't know OP's situation, which is why I was asking what is the main problem there. Sometimes it's teachers. Sometimes it's textbooks. Sometimes it's not having a roof above your head. Sometimes the kids are starving and can't focus on the lessons. Sometimes it's different language.
> would great teachers largely choose to settle in PNW?
One possible reason is that some of them could be born there. Again, this differs between communities. Some of them respect their smartest members. Some kick them out.
Unfortunately, our reservation is in central Oregon, which is less desirable. Even if we were not forced out of the ancestral homeland (what is now called the Columbia River Gorge), I'm not sure that would have been better. Although pretty, it is very out of the way, and people do not know that it is in the same class as the Yangtze (say).
in the US, schools in poor counties have less resources and less high quality teachers, and the children have much less of an education-focused environment in which they can flourish because of the parent's lack of resources
raise the economic level of the community, and education rises with it
Abbott districts in New Jersey are an obvious counterpoint to this. They are funded at levels equal to if not greater than the wealthiest districts in the state, despite being in some of the poorest parts of the state. I spite of this, over the four decades that Abbott districts have been in place, educational attainment gaps between them and the rest of the state have actually widened.
it's not just about the funding to the schools; it's about the economic situation of the parents and their ability to provide conditions where their children can thrive academically
that's why I said the best way to improve the education is to improve the economic conditions of the community
You make this to be a financial problem, but I think actually it is a cultural problem. Maybe lack of row models or not valuing education sufficiently. Having too much money can be a hinderance to educational motivation too.
Thank you for this wonderful message. As a fellow American, I can see you have our common interests at heart, as well as those of your tribe. That is a model for all of us.
Thank you for the response, I am very glad to hear that came through. I think these discussions tend to be fundamentally pessimistic towards the future and I really don't think they need to be. We control our destiny, and we can make it whatever we wish.
> "The problems that afflict my community are running water, drug addiction, lack of educational resources, and secular trends have have made our traditional industries obsolete"
So in my rural, predominantly white "Non DEI target" part of the country, this is the problem too except when these people apply to hundreds of jobs in software engineering they get crickets.
Well, just one data point for you (YMMV), but in "DEI" contexts I've been a part of, class diversity did actually come up somewhat regularly. I would not say corp diversity efforts I saw were all that successful in staffing that demographic—but they also weren't that successful in staffing minorities either. Mostly I think this reflects a consistent disconnect between what people wanted corp diversity efforts to be, and what they really were.
With all that said I do have a story of my own like this. In 2013 or so I wrote some stuff about spam detection and a Twitter engineer reached out about a job. I was an outgoing new grad from the University of Utah. When I got through with the loop the recruiter said, "How did you get here, we don't get many candidates from Utah." I still wonder what they wanted me to think when I heard that. What I actually felt was deeply out of place and uncomfortable. And it has affected every hiring process I've been apart of since.
I always bring this up to extremely woke people. I grew up at the poverty line in rural Minnesota with a blue collar truck driver father, divorced parents, in a trailer park. I don’t say this to get sympathy, I am proud I overcame it. But DEI and other race based (vs economically/financially based) affirmative action is just racism in a different outfit. Are the white people living below the poverty line all across America “privileged”? Certainly not, and as you said, on top of that they are immediately disqualified from so many types of aid. Imagine applying for college and seeing every other minority under the sun have scholarships specifically for them: women, black people, Asians, etc. White male from poverty? lol not you, you’re privileged. It’s ridiculous and it’s been going on since I was in college over 10 years ago.
Well, in the non-DEI world, we'll soon find out if the reason this happens was solely because of policies or if low educational attainment seeps into one's college, ones preparedness for a job, one's ability to get a job, etc.
but you do see the problem here. Its not the "DEI targets" that are at fault, its the systematic roll back of any protection for any poor community.
The same people that are saying "a new way forward" or "make america great again" failed to put any money to help. Your community doesn't produce anything that those funding congress care about, means that you get nothing.
I don't have to be invested in a cause to know that diversity in problem solving can be a key component to success hence global technology companies, or that promoting the ideas of equity and inclusion are things most humans can benefit from. DEI is not about change or solving a particular problem, it's about awareness of perspective and seeking to understand others.
To be clear I am not arguing for or against working with a bunch of people from totally different backgrounds, demographics, etc. I am arguing that, because we can't do everything we should decide what really matters to us, commit to it in the long term, and invest in it to the exclusion of the many other completely worthy causes. I know it sounds obvious, but at least for the communities I belong to, the industry committed shallowly and as a result accomplished very little.
It sounds like you're confusing affirmative action with DEI. A broader perspective benefits everyone. Different lived experiences contribute to a broader perspective. It's not about checking boxes or filling quotas and it's not specific to any particular group.
I’m happy to continue this conversation, but I think we’re not on the same page about what I am saying, which makes it hard to say how to proceed. To your specific point here, I’m not sure what this has to do with the discussion.
lol I have been saying similar things here in Minnesota for years. A lot of extremely liberal, wealthy progressives like to try to change landmarks around here to the native language version. I have no issue with this at face value. What I do have an issue with, is these people acting like this is doing anything to help the local Native American tribes. Why would they care if a lake they probably never visit and a flag they barely look at are changed? Especially when they weren’t even asking for it? What does that do at all to actually help our local Native communities struggling with the things you listed above? Absolutely nothing. It’s all a parade to make these people feel like they’re doing something while having to sacrifice absolutely nothing from their own lives. It’s honestly pathetic.
Oh I think we have very good empirical reasons to believe that’s not true. If this was indeed common knowledge, DEI as a movement would not be mired with the issues it has, specifically relating to performative activism and focus. If that’s not good enough for you, we can evaluate your claim further by surveying people and seeing if this advice is actually well-known. I encourage you to try this yourself, I think what you’ll find is that the vast majority of people who participate in these systems find what I’ve written surprising and unintuitive. And that’s one reason why this comment has 250 upvotes, which is more than almost all HN stories on a given day. YMMV, happy to hear about how this turns out for you.
I suppose this is kind of a hot take, and in some ways less relevant than it was (say) 10 years ago, but I believe the theoretical CS community has spent a lot of time analyzing the performance of various algorithms over the years and kind of pointedly not inventing algorithms which accomplish some result at all, even if it is only known to be computable in a pathologically inefficient way. This means a lot of breakthroughs that could have been TCS breakthroughs have been invented, usually worse, by other communities.
I am not the only one who thinks so, here[1] is an obscure talk where Michael Mitzenmacher (a well-known CS theory prof at Harvard) makes more or less this specific complaint.
One of the nice things about Flajolet/Sedgewick[2] (mentioned in this post) is that it gives a nice set of combinators for (at least it seems to me, in theory) precisely enumerating how many "steps" an algorithm would take given some input. I optimistically imagine a world where we replace the relatively non-specific asymptotic bounds of an algorithm with a very specific quantification of the work an algorithm will take. And that this in turn would free TCS to focus on things that are more germane to the field as a whole.
With that all said I'm open to the argument that TCS has fundamentally changed and this is no longer such a big issue. But perusing the various TCS conferences I sense it isn't.
[1]: https://www.youtube.com/watch?v=p3anjSAnKBo
[2]: https://algo.inria.fr/flajolet/Publications/book.pdf
reply