ubiquity   1836

« earlier    

How I Choose What To Read — David Perell
unaffiliated  advice  reflection  checklists  metabuch  learning  studying  info-foraging  skeleton  books  heuristic  contrarianism  ubiquity  time  track-record  thinking  blowhards  bret-victor  worrydream  list  top-n  recommendations  arbitrage  trust  aphorism 
14 hours ago by nhaliday
Linus's Law - Wikipedia
Linus's Law is a claim about software development, named in honor of Linus Torvalds and formulated by Eric S. Raymond in his essay and book The Cathedral and the Bazaar (1999).[1][2] The law states that "given enough eyeballs, all bugs are shallow";


In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate.[4] While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".[5][6]

Although detection of even deliberately inserted flaws[7][8] can be attributed to Raymond's claim, the persistence of the Heartbleed security bug in a critical piece of code for two years has been considered as a refutation of Raymond's dictum.[9][10][11][12] Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain.[12] In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking".[11] Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.

Given enough eyeballs, all bugs are shallow? Revisiting Eric Raymond with bug bounty programs: https://academic.oup.com/cybersecurity/article/3/2/81/4524054

wiki  reference  aphorism  ideas  stylized-facts  programming  engineering  linux  worse-is-better/the-right-thing  correctness  debugging  checking  best-practices  security  error  scale  ubiquity  collaboration  oss  realness  empirical  evidence-based  multi  study  info-econ  economics  intricacy  plots  manifolds  techtariat  cracker-prog  os  systems  magnitude  quantitative-qualitative  number  threat-modeling 
4 weeks ago by nhaliday
data structures - Why are Red-Black trees so popular? - Computer Science Stack Exchange
- AVL trees have smaller average depth than red-black trees, and thus searching for a value in AVL tree is consistently faster.
- Red-black trees make less structural changes to balance themselves than AVL trees, which could make them potentially faster for insert/delete. I'm saying potentially, because this would depend on the cost of the structural change to the tree, as this will depend a lot on the runtime and implemntation (might also be completely different in a functional language when the tree is immutable?)

There are many benchmarks online that compare AVL and Red-black trees, but what struck me is that my professor basically said, that usually you'd do one of two things:
- Either you don't really care that much about performance, in which case the 10-20% difference of AVL vs Red-black in most cases won't matter at all.
- Or you really care about performance, in which you case you'd ditch both AVL and Red-black trees, and go with B-trees, which can be tweaked to work much better (or (a,b)-trees, I'm gonna put all of those in one basket.)


> For some kinds of binary search trees, including red-black trees but not AVL trees, the "fixes" to the tree can fairly easily be predicted on the way down and performed during a single top-down pass, making the second pass unnecessary. Such insertion algorithms are typically implemented with a loop rather than recursion, and often run slightly faster in practice than their two-pass counterparts.

So a RedBlack tree insert can be implemented without recursion, on some CPUs recursion is very expensive if you overrun the function call cache (e.g SPARC due to is use of Register window)


There are some cases where you can't use B-trees at all.

One prominent case is std::map from C++ STL. The standard requires that insert does not invalidate existing iterators


I also believe that "single pass tail recursive" implementation is not the reason for red black tree popularity as a mutable data structure.

First of all, stack depth is irrelevant here, because (given log𝑛 height) you would run out of the main memory before you run out of stack space. Jemalloc is happy with preallocating worst case depth on the stack.
nibble  q-n-a  overflow  cs  algorithms  tcs  data-structures  functional  orders  trees  cost-benefit  tradeoffs  roots  explanans  impetus  performance  applicability-prereqs  programming  pls  c(pp)  ubiquity 
june 2019 by nhaliday
The End of the Editor Wars » Linux Magazine
Moreover, even if you assume a broad margin of error, the pollings aren't even close. With all the various text editors available today, Vi and Vim continue to be the choice of over a third of users, while Emacs well back in the pack, no longer a competitor for the most popular text editor.

I believe Vim is actually more popular, but it's hard to find any real data on it. The best source I've seen is the annual StackOverflow developer survey where 15.2% of developers used Vim compared to a mere 3.2% for Emacs.

Oddly enough, the report noted that "Data scientists and machine learning developers are about 3 times more likely to use Emacs than any other type of developer," which is not necessarily what I would have expected.

[ed. NB: Vim still dominates overall.]


Time To End The vi/Emacs Debate: https://cacm.acm.org/blogs/blog-cacm/226034-time-to-end-the-vi-emacs-debate/fulltext

Vim, Emacs and their forever war. Does it even matter any more?: https://blog.sourcerer.io/vim-emacs-and-their-forever-war-does-it-even-matter-any-more-697b1322d510
Like an episode of “Silicon Valley”, a discussion of Emacs vs. Vim used to have a polarizing effect that would guarantee a stimulating conversation, regardless of an engineer’s actual alignment. But nowadays, diehard Emacs and Vim users are getting much harder to find. Maybe I’m in the wrong orbit, but looking around today, I see that engineers are equally or even more likely to choose any one of a number of great (for any given definition of ‘great’) modern editors or IDEs such as Sublime Text, Visual Studio Code, Atom, IntelliJ (… or one of its siblings), Brackets, Visual Studio or Xcode, to name a few. It’s not surprising really — many top engineers weren’t even born when these editors were at version 1.0, and GUIs (for better or worse) hadn’t been invented.


… both forums have high traffic and up-to-the-minute comment and discussion threads. Some of the available statistics paint a reasonably healthy picture — Stackoverflow’s 2016 developer survey ranks Vim 4th out of 24 with 26.1% of respondents in the development environments category claiming to use it. Emacs came 15th with 5.2%. In combination, over 30% is, actually, quite impressive considering they’ve been around for several decades.

What’s odd, however, is that if you ask someone — say a random developer — to express a preference, the likelihood is that they will favor for one or the other even if they have used neither in anger. Maybe the meme has spread so widely that all responses are now predominantly ritualistic, and represent something more fundamental than peoples’ mere preference for an editor? There’s a rather obvious political hypothesis waiting to be made — that Emacs is the leftist, socialist, centralized state, while Vim represents the right and the free market, specialization and capitalism red in tooth and claw.

How is Emacs/Vim used in companies like Google, Facebook, or Quora? Are there any libraries or tools they share in public?: https://www.quora.com/How-is-Emacs-Vim-used-in-companies-like-Google-Facebook-or-Quora-Are-there-any-libraries-or-tools-they-share-in-public
In Google there's a fair amount of vim and emacs. I would say at least every other engineer uses one or another.

Among Software Engineers, emacs seems to be more popular, about 2:1. Among Site Reliability Engineers, vim is more popular, about 9:1.
People use both at Facebook, with (in my opinion) slightly better tooling for Emacs than Vim. We share a master.emacs and master.vimrc file, which contains the bare essentials (like syntactic highlighting for the Hack language). We also share a Ctags file that's updated nightly with a cron script.

Beyond the essentials, there's a group for Emacs users at Facebook that provides tips, tricks, and major-modes created by people at Facebook. That's where Adam Hupp first developed his excellent mural-mode (ahupp/mural), which does for Ctags what iDo did for file finding and buffer switching.
For emacs, it was very informal at Google. There wasn't a huge community of Emacs users at Google, so there wasn't much more than a wiki and a couple language styles matching Google's style guides.


And it is still that. It’s just that emacs is no longer unique, and neither is Lisp.

Dynamically typed scripting languages with garbage collection are a dime a dozen now. Anybody in their right mind developing an extensible text editor today would just use python, ruby, lua, or JavaScript as the extension language and get all the power of Lisp combined with vibrant user communities and millions of lines of ready-made libraries that Stallman and Steele could only dream of in the 70s.

In fact, in many ways emacs and elisp have fallen behind: 40 years after Lambda, the Ultimate Imperative, elisp is still dynamically scoped, and it still doesn’t support multithreading — when I try to use dired to list the files on a slow NFS mount, the entire editor hangs just as thoroughly as it might have in the 1980s. And when I say “doesn’t support multithreading,” I don’t mean there is some other clever trick for continuing to do work while waiting on a system call, like asynchronous callbacks or something. There’s start-process which forks a whole new process, and that’s about it. It’s a concurrency model straight out of 1980s UNIX land.

But being essentially just a decent text editor has robbed emacs of much of its competitive advantage. In a world where every developer tool is scriptable with languages and libraries an order of magnitude more powerful than cranky old elisp, the reason to use emacs is not that it lets a programmer hit a button and evaluate the current expression interactively (which must have been absolutely amazing at one point in the past).


more general comparison, not just popularity:
Differences between Emacs and Vim: https://stackoverflow.com/questions/1430164/differences-between-Emacs-and-vim



- Adrien Lucas Ecoffet,

Because it is hard to use. Really.

However, the second part of this sentence applies to just about every good editor out there: if you really learn Sublime Text, you will become super productive. If you really learn Emacs, you will become super productive. If you really learn Visual Studio… you get the idea.

Here’s the thing though, you never actually need to really learn your text editor… Unless you use vim.


For many people new to programming, this is the first time they have been a power user of… well, anything! And because they’ve been told how great Vim is, many of them will keep at it and actually become productive, not because Vim is particularly more productive than any other editor, but because it didn’t provide them with a way to not be productive.

They then go on to tell their friends how great Vim is, and their friends go on to become power users and tell their friends in turn, and so forth. All these people believe they became productive because they changed their text editor. Little do they realize that they became productive because their text editor changed them[1].

This is in no way a criticism of Vim. I myself was a beneficiary of such a phenomenon when I learned to type using the Dvorak layout: at that time, I believed that Dvorak would help you type faster. Now I realize the evidence is mixed and that Dvorak might not be much better than Qwerty. However, learning Dvorak forced me to develop good typing habits because I could no longer rely on looking at my keyboard (since I was still using a Qwerty physical keyboard), and this has made me a much more productive typist.

Technical Interview Performance by Editor/OS/Language: https://triplebyte.com/blog/technical-interview-performance-by-editor-os-language
[ed.: I'm guessing this is confounded to all hell.]

The #1 most common editor we see used in interviews is Sublime Text, with Vim close behind.

Emacs represents a fairly small market share today at just about a quarter the userbase of Vim in our interviews. This nicely matches the 4:1 ratio of Google Search Trends for the two editors.


Vim takes the prize here, but PyCharm and Emacs are close behind. We’ve found that users of these editors tend to pass our interview at an above-average rate.

On the other end of the spectrum is Eclipse: it appears that someone using either Vim or Emacs is more than twice as likely to pass our technical interview as an Eclipse user.


In this case, we find that the average Ruby, Swift, and C# users tend to be stronger, with Python and Javascript in the middle of the pack.


Here’s what happens after we select engineers to work with and send them to onsites:

[Python does best.]

There are no wild outliers here, but let’s look at the C++ segment. While C++ programmers have the most challenging time passing Triplebyte’s technical interview on average, the ones we choose to work with tend to have a relatively easier time getting offers at each onsite.

The Rise of Microsoft Visual Studio Code: https://triplebyte.com/blog/editor-report-the-rise-of-visual-studio-code
This chart shows the rates at which each editor's users pass our interview compared to the mean pass rate for all candidates. First, notice the preeminence of Emacs and Vim! Engineers who use these editors pass our interview at significantly higher rates than other engineers. And the effect size is not small. Emacs users pass our interview at a rate 50… [more]
news  linux  oss  tech  editors  devtools  tools  comparison  ranking  flux-stasis  trends  ubiquity  unix  increase-decrease  multi  q-n-a  qra  data  poll  stackex  sv  facebook  google  integration-extension  org:med  politics  stereotypes  coalitions  decentralized  left-wing  right-wing  chart  scale  time-series  distribution  top-n  list  discussion  ide  parsimony  intricacy  cost-benefit  tradeoffs  confounding  analysis  crosstab  pls  python  c(pp)  jvm  microsoft  golang  hmm  correlation  debate  critique  quora  contrarianism  ecosystem  DSL 
june 2019 by nhaliday

« earlier    

related tags

1840s  1887  1930s  1940s  1950  1950s  1953  1960s  1976  1980s  1985  1987  1990s  1993  1995  1997  2013  2015  2016  2017  2018  2019  ac2k  academia  accuracy  acquisition  action  activity  addiction  administration  advice  aesthetic  agency  aggregator  agi  ai-control  ai  air  airmax  airplane  aiweiwei  algorithms  alt-inst  alternatives  amazon  amazonecho  ambient  ambientcomputing  ambivalence  americanfinearts  analogy  analysis  anglo  animation  annual  ansible  anticommercial  antimonument  ants  aphorism  api  app  apple  applicability-prereqs  application  apps  arbitrage  architecture  archive  ars_technica  arselectronica  arstechnica  art  artforum  article  artificialintelligence  asia  atemporality  atoms  attendance  attention  audio  augmentedreality  automation  automaton  availability  awareness  backdoor  backdrop  backup  barrier  baskinrobbins  bbs  becoming  benjaminbratton  bernadettecorporation  best-practices  bigbox  bio  bitcoin  black  blackboard  blockchain  blowhards  body  book  books  border  born  bot  brand  branding  brands  brendalaurel  bret-victor  brexit  brianodoherty  brickandmortar  broadband  broadcast  browser  brunolatour  bug  build-packaging  business  c(pp)  calculator  calm  calmtechnology  camera  career  cars  casualdining  cctv  celebrity  cell  chain  chalk  chalkboar  chart  checking  checklists  checkout  china  city  civil-liberty  classroom  clock  cloud  coalitions  cocacola  cocoa  code-organizing  coffee  coherence  colindeland  collaboration  collection  colocation  color  commentary  commercial  communication  community  commute  comparison  compensation  competition  compilers  completeenvironment  computer-memory  computer  computers  concurrency  condition  conferences  confounding  connectivity  conscious  consciousexotica  consensus  consequence  constant  constellations  constraint  consumer  consumerism  consumption  container  content  context  contextaware  contrarianism  control  controller  cool  cooperunion  corian  corporate  correctness  correlation  cost-benefit  cracker-prog  critique  crosstab  cs  culture  cupholder  curation  current  customers  cybersecurity  cyberspace  dailylife  dariuskazemi  data-science  data-structures  data  database  datacenter  dataplan  dbs  dc:creator=burkemanoliver  dctagged  debate  debugging  decentralized  delicious  democracy  denayago  density  design  desires  desktop  destination  device  devonpowers  devtools  digital  digitalpainting  dirty-hands  discovery  discussion  disease  display  disruption  distance  distribution  division  dj  document  documentation  domain  donnaharaway  donuts  dotnet  drake's  drawing  drones  dryerase  dsl  dunkindonuts  duty  dynamic  early-modern  earworm's  ebooks  ecologies  ecology  economics  econotariat  ecosystem  edgeos  edgerouter  editors  education  edwardbellamy  eero  electricity  embodied  embodiment  empirical  emulator  energy  engineering  ensembles  entrepreneurial  erlang  error  essay  ethical-algorithms  europe  everydaylife  evidence-based  excess  exhibition  expanders  expert-experience  explanans  explanation  exploratory  facebook  facility  facts  failover  familiar  fashion  fashun  fastfashion  features  feminism  fence  fifthutility  fios  firewall  flaneur  flux-stasis  folder  forecasting  foreign-policy  form-design  format  forum  frame  frameworks  franchise  free  from:pinboard  frontend  frontwards  fruits  functional  future  futurism  garyzhexizhang  gas  gaze  gbooks  gender  generalelectric  geography  gif  gildedage  glass  global  globe  golang  google  gotchas  governance  green  grid  grokkability-clarity  grokkability  growth-econ  growth  guide  gypsum  hanshaacke  harajuku  hardware  haskell  hci  healthcare  heavy-industry  height  helenecixous  heuristic  highway  history  hmm  hn  home  homeimprovement  horology  household  howto  human-capital  hypertet  ibm  ide  ideas  identity  identitypolitics  ifttt  image  imaginaries  immersive  impact  impetus  in  inbetween  incentives  income  increase-decrease  industrial  industrialinternet  industry  info-dynamics  info-econ  info-foraging  information  informationtechnology  infrared  infrastructure  innovation  insurance  integration-extension  integration  intelligence  intelligentcity  interaction  interactivedesign  interconnected  interconnectedness  interconnectivity  interface-compatibility  interference  interior  internet  internetofthings  interpretability  interstate  interventions  intricacy  iot  iphones  irc  issue  jamesbridle  javascript  jeffreyscudder  jewelry  jilliansteinhauer  jobs  joshuaweibley  jpmorgan  junkspace  jvm  kellereastrling  key  khole  knowledge  kpp  landscape  language  latency  lateral  laurelschwulst  learning  lecture  led  left-wing  let-me-see  letters  level  lexical  libraries  lifelogging  lifestyle  light  limit  linguistics  links  linksys  linux  lisp  list  location  logistics  lookingbackward  los  low-hanging  luxury  maainframe  machine-learning  machine  magnetic  magnitude  mainstream  maker  management  manifolds  manual  map  mapping  marginal  market.analysis  market.saturation  market.share  market  marketing  marktribe  mashup  massachusetts  material  matter  mcdonalds  measurement  mechanical  media  medicine  meme  memory-management  memory  mesh  messaging  meta:medicine  metabuch  metaphor  metaphors  methodology  metrics  mezzanine  microprocessors  microsoft  mikepepi  military  mind  mindpalace  minimum-viable  mirroring  mix  mobile  mobilepay  mobiles  modernity  moire  money  monopolies  monumental  mostly-modern  motion  move-fast-(and-break-things)  movement  muds  multi  multitudes  museum  mycelium  nasa  nationalism-globalism  native  negative  neoliberalism  nesting  netadmin  netart  netartanthology  netgear  network-structure  network  networkedsociety  networking  networks  news  newyork  nibble  nonhuman  nonpermenent  nonstop  number  object  objektbuch  observation  ocaml-sml  olialialina  online  oop  open  opengovernment  opensource  openwrt  operatingsystem  optics  optimate  optimization  orders  org:com  org:lite  org:mag  org:med  ornament  os  oss  osx  overflow  paint  paradigm  parallax  parasites-microbiome  paris  parsimony  participation  pdf  pedestrian  people  pepsi  perception  performance  peripheral  perks  personal  personalcomputing  personification  perspective  pervasive  pervasivegames  pervasiveness  petracortright  pfsense  pharma  phone  photo  photography  photos  physical  pittsburgh  planning  platform  plots  pls  podcast  police  policy  politics  poll  popr  porcelain  portal  positive  postdigital  power  pragmatic  prediction  predix  preposition  present  preservation  primary  priors-posteriors  privacy  private  privatesector  privte  pro-rata  process  processed  processing  profiling  programming  properties  public  publishing  python  q-n-a  qos  qra  qrcode  quantitative-qualitative  quora  radio  railroad  railroads  railway  ranking  reading  realness  realtime  recommendations  reduction  redundancy  reference  reflection  reform  regularizer  remix  reneritchie  renovation  representation  reproduction  research  researchanddevelopment  resource  resources  responsibility  retail  retrofit  review  rhizome  right-wing  risk  role  roots  router  routers  routing  runaway  rust  saas  salon  samsung  satellite  sbc  scala  scale  scaling-tech  science  scitariat  sea  search  secondary  security-now  security  sense  sensor  sensors  sequential  server  service  sharing  shinoharatomoe  shipping  shoiciaoki  shopping  shortcut  shows  sides  siliconvalley  site  situationalawareness  skeleton  skyscraper  slate  sleep  sleuthin  slimemold  slogan  smart  smartgrid  smarthome  smartphone  smartphones  smell  soc  social-science  social  socialmedia  society  software  solar  space  spatial  speculation  speedtest  spirit  spooky  stackex  stagnation  standardization  standards  starbucks  state  static-dynamic  steel  stereotypes  stoarage  storage  street  streetlamp  streetlight  strings  study  studying  style  stylized-facts  subculture  suburbs  subway  summary  surf  surface  surveillance  sv  swarm  switch  sysadmin  system-design  systems  task  tcs  tech-infrastructure  tech  technology  techtariat  tedtalks  telecommunication  telephone  television  text  the-trenches  the-world-is-just-atoms  theater  themet  thinking  thinktank  thisamericanlife  thomasedison  thomasnagel  thread  threat-modeling  thucydides  time-series  time  timoreilly  tinysubversions  tool  tools  top-n  track-record  trade  tradeoffs  traffic  transit  transitionalintelligence  transmediale  transmitter  transportation  transversal  trap  trees  trends  trumpdonald  trust  truth  tutorial  twitter  types  ubiquiti  ubnt  ui  unaffiliated  unifi  unify  uniqlo  universalism-particularism  unix  upgrade  uptime  urban  usa  usability  user  usg  utility  ux  values  vanguard  video  viral  virtual  virtualreality  virus  vision  visual  visualization  voco  voicerecognition  volume  walking  wallpaper  walmart  walmartpay  waste  watch  water  wealth  weapon  wearable  wearables  web  web2.0  webservice  west-hunter  whistleblower  white  whiteboard  whitecube  whitneybiennial  wifi  wiki  windowless  windows  wireless  women  working-stiff  worrydream  worse-is-better/the-right-thing  writing  ww2  xerox  yale  youth  youtube  zeitgeist 

Copy this bookmark: