First, to the immediate point: Ropes are not talked about much outside of whitepapers and undergrad data structure courses. This is a shame, even if ropes are only useful on very long strings. More discussion, more documentation, and more attempts to use ropes are not a bad thing, even if nothing "practical or necessary" comes of it. (And I would say that a text editor is quite practical!)
Second, it's completely reasonable to imagine data-structure-driven improvements to the task of writing source code. Imagine, for example, an AST editor. There are tools like org-mode and paredit which are halfway to true AST editing, and plenty of languages have tooling sufficient to support it, if there were demand. An AST editor would, of course, generalize the lessons here about ropes to pretty-printed ASTs, but there's no innate reason why it couldn't be done.
Third, a meta-comment, to address your comment elsewhere in the thread: "There are, of course, computer science concepts that are very smart. But we don't need these to save us from slow software, because today's slow software problem is just the result of people doing bad things in layer upon layer. We have to stop doing all the bad stuff and dig us out of the hole we're in, just to get back to neutral. Once we are back at neutral, then we can try thinking about some computer science smarty stuff to take us forward."
There are assumptions here about the nature of CS. CS is a science of abstractions. Complaining about layers in CS is complaining about the very nature of CS. Software is slow and insecure and hard to use because the tasks that we demand of software are extremely complex and our human processes for creating code are not sufficiently high-level, powerful, and expressive enough for us to design good systems on the first try.
Whenever somebody says, "I have removed a useless abstraction," they usually forget to also say, "By replacing it with a useful abstraction."
Only replying to one point in your post, but if you think org-mode and paredit take you halfway to AST editing, try abo-abo's lispy. It's closer to the ideal by half again, at least.
I've found the best removals of abstractions I've done have gone back to essentially bare code. That is, I put back the abstraction either I or a coworker originally avoided.
DDoS continues to look like an economic problem; we should not have grown used to the idea that small amounts of bandwidth are effectively a free good.
you are assuming that torrents only work when there are seeders, but that's not true at all. Seeders simply provide surplus bandwidth, allowing a torrent to operate on altruism. In the worst case where almost everyone is downloading it degrades into tit-for-tat behavior where everyone gets as much as others are willing to provide based on their current contribution, which still scales with the number of downloaders.
Maybe I should have mentioned one other condition. The network must be distributed and consist of nodes with symmetric bandwidth. If you have symmetric bandwidth you can upload as fast as you download and thus on average the network won't need altruistic nodes to saturate everyone's downlink.
We could go even further and demand ISP-local source-specific multicast, then you would have massive bandwidth multiplication for uploaders, making it trivial to replicate popular content. Alas, that seems to be a pipe dream.
> you are assuming that torrents only work when there are seeders, but that's not true at all.
No, I'm saying that if someone is trying to DDoS your torrent, the bandwidth doesn't scale with the number of downloaders because all the malicious nodes are using download bandwidth but (deliberately) not providing upload bandwidth. I was playing a bit fast and loose with the term "leecher" (I meant someone downloading but <i>not uploading at all</i>, as opposed to active participants in the swarm), but I thought that was understood. Even if you had a system where people were prioritized based on how much they were sharing, there are a lot of ways to get around that protocol with a big enough botnet.
Don't get me wrong, the built-in scaling features of things like torrents are great, I'm just saying I don't see an easy way for it to solve DDoS because it relies on cooperation from the participants.
Well, that depends on what kind of ddos we're talking about. The primitive ones simply pick a server and flood it with some kind of request. The distributed part makes it harder to block and provides more bandwidth than most single points can take
If you make your content distributed it can be mirrored by many more nodes than are needed to satisfy demand, removing some of the asymmetry while also making it more difficult for the attacker to pick his targets. Note that p2p networks can also respond to demand. E.g. in torrents clients don't seed all the content they have all the time, they first check statistics which swarms could use the bandwidth most. So if there were some content under attack by fake downloaders it would look like a swarm in need of extra bandwidth and thus more real nodes would join it to serve content, thus making the attack more costly.
> Even if you had a system where people were prioritized based on how much they were sharing, there are a lot of ways to get around that protocol with a big enough botnet.
With a big enough botnet you can also take out any ddos protection service.
Just set your peer limit to a small number. Your client shouldn't be connected to more than a couple peers at a time, and the tracker should be able to make sure you can find good peers.
Really what we need is some kind of trust net built onto our information pathways. It might leak privacy a bit, but realistically speaking privacy doesn't really exist right now anyway, and the truly paranoid will always have a way to get their basic stuff done.
As participation increases, quality declines, unless there are structural safeguards built into the system. I see nothing in Electron which suggests structural quality. I wonder whether rose-colored glasses are overly tinting the viewpoints of folks in the JS community.
> As participation increases, quality declines, unless there are structural safeguards built into the system.
Well, yeah, but that's a refutation of the entire web. Maybe we should go back to the days when only a chosen elite was able to distribute writing or software to a wide audience?
What a strawman. Noone wants to go back to days of "chosen elite", but JS/Electron really really REALLY isn't the only simple way of building cross-platform apps. Don't make false comparisons.
Cross platform desktop toolkits are usually SIMPLER to build apps in because they don't have the document-centric baggage of HTML/CSS/JS stack.
People have been building cross-platform software since forever - heck, in 1980s you had to port your game/software on several different architectures and bedroom programmers (far from "chosen elite") regularly supported Ataris, Amigas, Commodores, PCs and other platforms.
Let's be honest, Gopher was not that bad, and the Web is quite bad. That said, I'm not sure whether the Web can be replaced with something more desirable; a lot of folks like the Web's inability to protect folks from each other.
This is something so obvious that it doesn't need a citation, but I think it's misunderstood.
It doesn't mean that the quality of the product decreases, but that the average quality of whatever is made with the product decreases from a user's perspective.
Just take a look at WordPress; I'm going to assume that over time the product itself has gotten more secure and usable due to more eyes being on it and it's adoption rate increasing, but being secure in itself doesn't mean that it can't be used insecurely.
I find that it neatly fits the thesis; "King of the Hill" is a delightful satire of the inhabitants of a sleepy Texas town, and it's clearly influenced by Judge's time in Texas the same way that "Silicon Valley" was influenced by his time in the Bay, and Judge himself has confirmed this.
I think that it makes coastal city folk uncomfortable to talk about and celebrate KotH because satirizing urban Texan values, beliefs, and practices is self-seen as aggrandizing city-slicker behavior.
Kenneth from 30 Rock doesn't make them uncomfortable. They don't get KotH because they don't get the humor. Because they don't get lower middle class red state suburban culture. They see it as an absence of culture. They'd rather move to New Zealand (another HN thread that's going on right now) than learn about domestic cultures.
Oh puh-leeeeeeeeze, KotH has a broad appeal and heaps of "city slickers" watched and enjoyed it without irony or disdain for the characters. People haven't been completely retarded by living in cities, most of the stories in the KotH are fundamentally human and very relatable.
Apparently Willy Staley of the New York Times missed all the satire in KotH. Someone in the critical analysis business who understood towns like Garland, TX well wouldn't dismiss the satire in KotH offhand. Shows can be relatable and funny and still be misunderstood.
And I don't think cities necessarily corrupt people somehow. Obviously Garland itself is part of the DFW metroplex! It's probably more that people with a certain brand of cosmopolitan ethnocentrism end up in (or stay in) coastal cities.
There is a really great story on Fresh Air about how Mike Judge's neighbors fixed his fence for him. It provided inspiration for the Hank Hill character.
Fix your group's culture. Document things. If people refuse to document things, then do it for them and shove your docs in their face. Do it until they write the documentation themselves.
It's also the most important thing. If your culture is bad, changing what tool you use isn't going to fix everything. You're just going to have a new tool everyone uses poorly.
Here's the thing. You know what the alternative to all of the JS that's been written? If your answer is "Keep writing more JS," then you are on another planet. The answer is, "We have fucked ourselves as an ecosystem by permitting a monoculture to flourish, especially one which prides itself on worship of bad languages, bloated runtimes, convoluted abstractions, and general fuckery."
Nobody in the last ~20 years has cared about writing Web apps before JS came along. There's basically zero money in it, and it's massively expensive, both in terms of actual development time per feature (easily 10x the cost of working in sane languages with sane runtimes), and also in finding trendy hipsters who don't know algorithms or data structures but took four weeks of coding academy classes a couple years ago. And as for Electron, Electron has existed for over three decades (Project Athena launched in 1983) -- if its massive "Nixon throwing the peace signs before getting on the plane" moment hasn't happened by then, sorry, but it's not going to happen.
But now? People are making all kinds of great new languages, and more often than not, they don't repeat JS's mistakes. People are excited about programming again -- JS is so bad that it's single-handedly revitalizing interest in languages which two of the largest tech companies in the world are behind, yet couldn't make popular.
This is a Big Deal.
(You are being parodied mostly for being a Slack developer, not disclosing it up front, and then trying to convince folks that Electron is good, which makes you sound a lot like a pig farmer trying to sell pigs' feet.)
Desktop apps like Word, Excel, Powerpoint, Photoshop? I too can pick a few ridiculous outliers. Honestly I'm not sure if you're right or wrong but either way that argument isn't good.
You have it exactly backwards. JS succeeded because it's not a monoculture. Within JavaScript there are multiple frameworks, even multiple languages (CoffeeScript, TypeScript, ES6, etc).
Win32, Java, MacOS, et al lost because there were such strong standards for doing things the One True Way that competing standards couldn't flourish and the APIs stagnated.
In JavaScript, a new framework comes out every year and goes straight at the throat of the old one. The reason there is churn is because these new frameworks are actually solving problems better than the old ones, and because of the LACK of a monoculture developers will actually switch to them. Which in turn is why framework designers are drawn to it, which in turn leads to more new frameworks.
Is iOS solving problems better today than they were last year? Or in 2015? Because JavaScript is solving problems way better this year than last.
JavaScript frameworks are ultimately solving problems that the Web/DOM/JavaScript infrastructure created in the first place. The amount of technology required to create a single page application is staggering yet on the desktop that's just "an application". The technology has been around for 20 years and we're just getting to point in JavaScript where we were 20 years ago.
Yes, of course JavaScript has made tradeoffs to get where it is. Those seem like problems in isolation, but look what we got in exchange:
- apps from untrusted developers can be run safely
- app installs are measured in milliseconds and don't require switching windows
- app updates are invisible to the user
- beginners can modify apps without leaving the app itself (MySpace profiles, etc)
- references deep inside one app can be embedded in another
- apps run on nearly every device from one codebase
Native app programming can do many things well, but failing on these counts is a deal breaker for many purposes. You act like JavaScript's weaknesses are somehow due to ignorance on our part, but they are tradeoffs made deliberately.
And for the most part, the things JavaScript is bad at (high performance graphics, professional ergonomics, etc) are things that are improving. I don't see native apps getting millisecond installs any time soon. It's a classic disruptive technology.
So, I ask you - at what point fascism in Europe could have been stopped? At what point did fascist speech, rallies, and demonstrations turn into action?
Was it after they seized power? They were so appreciative of free speech, that they immediately repressed it.
Fascism in Europe could have been stopped in the 16-1800's when Britain and France gobbled up the world as colonies. They could have left a piece for Germany and Italy to occupy as these societies unified some years later. Or they could have not colonized at all.
Alternatively maybe it could have been stopped by preventing the industrial revolution. Or by preventing Germany and Italy from uniting as countries at the end of the 1800's/early 1900's. Or by preventing banking interests from lending to industrialists. Or by preventing the Viking invasions. Or preventing the collapse of international papal authority. Or by preventing the rise of papal authority in the first place. Or giving the Chinese first dibs on East Asia. Or giving native Africans gunpowder. Or by any number of other means.
Point being, you seem to think 1)Fascism in Europe during the second world war is the worst event to happen to mankind ever and attempting to prevent it re-occurring justifies any means, even those with potentially worse outcomes. And 2)Fascism arose strictly because some guys popped in out of nowhere and started talking.
What about Pol Pot? What about Stalin? What about the church during the Middle Ages? What about the conquests of Islam? What about the massacres in Medieval China? Events very simply don't happen in a vacuum, (in spite of the popular culture/ public school view of history).
The dangers of those who want to prevent free speech because it offends someone far outweigh the dangers of letting the marketplace of ideas decide which ideas are worth considering. I don't find the rise of the alt-right (which I don't support btw) nearly as alarming as I find the number of young people who think offensive speech should be legislated against or banned. Which is truly an authoritarian and disturbing trend.
Hi, Pacific Northwest native here. We learn about Japanese concentration camps, which were usually not deadly but still embodied all of the things that we don't like about them: Lack of due process, forced relocation, racism and prejudice, etc.
WP discusses the deadliness, or relative lack thereof, of Japanese concentration camps: "Despite a shortage of healthcare workers, limited access to equipment, and tension between white administrators and Japanese American staff, these hospitals provided much needed medical care in camp. The extreme climates of the remote incarceration sites were hard on infants and elderly inmates. The frequent dust storms of the high desert locations led to increased cases of asthma and coccidioidomycosis, while the swampy, mosquito-infested Arkansas camps exposed residents to malaria, all of which were treated in camp. Almost 6,000 live deliveries were performed in these hospitals, and all mothers received pre- and postnatal care. The WRA recorded 1,862 deaths across the ten camps, with cancer, heart disease, tuberculosis, and vascular disease accounting for the majority."
Second, it's completely reasonable to imagine data-structure-driven improvements to the task of writing source code. Imagine, for example, an AST editor. There are tools like org-mode and paredit which are halfway to true AST editing, and plenty of languages have tooling sufficient to support it, if there were demand. An AST editor would, of course, generalize the lessons here about ropes to pretty-printed ASTs, but there's no innate reason why it couldn't be done.
Third, a meta-comment, to address your comment elsewhere in the thread: "There are, of course, computer science concepts that are very smart. But we don't need these to save us from slow software, because today's slow software problem is just the result of people doing bad things in layer upon layer. We have to stop doing all the bad stuff and dig us out of the hole we're in, just to get back to neutral. Once we are back at neutral, then we can try thinking about some computer science smarty stuff to take us forward."
There are assumptions here about the nature of CS. CS is a science of abstractions. Complaining about layers in CS is complaining about the very nature of CS. Software is slow and insecure and hard to use because the tasks that we demand of software are extremely complex and our human processes for creating code are not sufficiently high-level, powerful, and expressive enough for us to design good systems on the first try.
Whenever somebody says, "I have removed a useless abstraction," they usually forget to also say, "By replacing it with a useful abstraction."