pls   426

« earlier    

Panel: Systems Programming in 2014 and Beyond | Lang.NEXT 2014 | Channel 9
- Bjarne Stroustrup, Niko Matsakis, Andrei Alexandrescu, Rob Pike
- 2014 so pretty outdated but rare to find a discussion with people like this together
- pretty sure Jonathan Blow asked a couple questions
- Rob Pike compliments Rust at one point. Also kinda softly rags on dynamic typing at one point ("unit testing is what they have instead of static types").
video  presentation  debate  programming  pls  c(pp)  systems  os  rust  d-lang  golang  computer-memory  legacy  devtools  formal-methods  concurrency  compilers  syntax  parsimony  google  intricacy  thinking  cost-benefit  degrees-of-freedom  facebook  performance  people  rsc  cracker-prog  critique  types  checking  api  flux-stasis  engineering  time  wire-guided  worse-is-better/the-right-thing 
5 days ago by nhaliday
The Law of Leaky Abstractions – Joel on Software
[TCP/IP example]

All non-trivial abstractions, to some degree, are leaky.


- Something as simple as iterating over a large two-dimensional array can have radically different performance if you do it horizontally rather than vertically, depending on the “grain of the wood” — one direction may result in vastly more page faults than the other direction, and page faults are slow. Even assembly programmers are supposed to be allowed to pretend that they have a big flat address space, but virtual memory means it’s really just an abstraction, which leaks when there’s a page fault and certain memory fetches take way more nanoseconds than other memory fetches.

- The SQL language is meant to abstract away the procedural steps that are needed to query a database, instead allowing you to define merely what you want and let the database figure out the procedural steps to query it. But in some cases, certain SQL queries are thousands of times slower than other logically equivalent queries. A famous example of this is that some SQL servers are dramatically faster if you specify “where a=b and b=c and a=c” than if you only specify “where a=b and b=c” even though the result set is the same. You’re not supposed to have to care about the procedure, only the specification. But sometimes the abstraction leaks and causes horrible performance and you have to break out the query plan analyzer and study what it did wrong, and figure out how to make your query run faster.


- C++ string classes are supposed to let you pretend that strings are first-class data. They try to abstract away the fact that strings are hard and let you act as if they were as easy as integers. Almost all C++ string classes overload the + operator so you can write s + “bar” to concatenate. But you know what? No matter how hard they try, there is no C++ string class on Earth that will let you type “foo” + “bar”, because string literals in C++ are always char*’s, never strings. The abstraction has sprung a leak that the language doesn’t let you plug. (Amusingly, the history of the evolution of C++ over time can be described as a history of trying to plug the leaks in the string abstraction. Why they couldn’t just add a native string class to the language itself eludes me at the moment.)

- And you can’t drive as fast when it’s raining, even though your car has windshield wipers and headlights and a roof and a heater, all of which protect you from caring about the fact that it’s raining (they abstract away the weather), but lo, you have to worry about hydroplaning (or aquaplaning in England) and sometimes the rain is so strong you can’t see very far ahead so you go slower in the rain, because the weather can never be completely abstracted away, because of the law of leaky abstractions.

One reason the law of leaky abstractions is problematic is that it means that abstractions do not really simplify our lives as much as they were meant to. When I’m training someone to be a C++ programmer, it would be nice if I never had to teach them about char*’s and pointer arithmetic. It would be nice if I could go straight to STL strings. But one day they’ll write the code “foo” + “bar”, and truly bizarre things will happen, and then I’ll have to stop and teach them all about char*’s anyway.


The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.” Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.
techtariat  org:com  working-stiff  essay  programming  cs  software  abstraction  worrydream  thinking  intricacy  degrees-of-freedom  networking  protocol  examples  traces  no-go  volo-avolo  tradeoffs  c(pp)  pls  strings  dbs  transportation  driving  analogy  aphorism  learning  paradox  systems  elegance  nitty-gritty  concrete  cracker-prog 
11 days ago by nhaliday
Cleaner, more elegant, and harder to recognize | The Old New Thing
Really easy
Writing bad error-code-based code
Writing bad exception-based code

Writing good error-code-based code

Really hard
Writing good exception-based code


Really easy
Recognizing that error-code-based code is badly-written
Recognizing the difference between bad error-code-based code and
not-bad error-code-based code.

Recognizing that error-code-base code is not badly-written

Really hard
Recognizing that exception-based code is badly-written
Recognizing that exception-based code is not badly-written
Recognizing the difference between bad exception-based code
and not-bad exception-based code
techtariat  org:com  microsoft  working-stiff  pragmatic  carmack  error  error-handling  programming  rhetoric  debate  critique  pls  search  structure  cost-benefit  comparison  summary  intricacy  certificates-recognition  commentary  multi  contrarianism  correctness  quality  code-dive  cracker-prog 
11 days ago by nhaliday
python - Executing multi-line statements in the one-line command-line? - Stack Overflow
you could do
> echo -e "import sys\nfor r in range(10): print 'rob'" | python
or w/out pipes:
> python -c "exec(\"import sys\nfor r in range(10): print 'rob'\")"
> (echo "import sys" ; echo "for r in range(10): print 'rob'") | python

[ed.: In fish
> python -c "import sys"\n"for r in range(10): print 'rob'"]
q-n-a  stackex  programming  yak-shaving  pls  python  howto  terminal  parsimony  syntax  gotchas 
13 days ago by nhaliday
From Java 8 to Java 11 - Quick Guide - Codete blog
jshell, Optional methods, var (type inference), {List,Set,Map}.copyOf, `java $` execution
programming  cheatsheet  reference  comparison  jvm  pls  oly-programming  gotchas  summary  flux-stasis  marginal  org:com 
14 days ago by nhaliday
paradigms - What's your strongest opinion against functional programming? - Software Engineering Stack Exchange
The problem is that most common code inherently involves state -- business apps, games, UI, etc. There's no problem with some parts of an app being purely functional; in fact most apps could benefit in at least one area. But forcing the paradigm all over the place feels counter-intuitive.
q-n-a  stackex  programming  engineering  pls  functional  pragmatic  cost-benefit  rhetoric  debate  steel-man  business  regularizer  abstraction  state  realness 
18 days ago by nhaliday
Which of Haskell and OCaml is more practical? For example, in which aspect will each play a key role? - Quora
- Tikhon Jelvis,


This is a question I'm particularly well-placed to answer because I've spent quite a bit of time with both Haskell and OCaml, seeing both in the real world (including working at Jane Street for a bit). I've also seen the languages in academic settings and know many people at startups using both languages. This gives me a good perspective on both languages, with a fairly similar amount of experience in the two (admittedly biased towards Haskell).

And so, based on my own experience rather than the languages' reputations, I can confidently say it's Haskell.

Parallelism and Concurrency




Typeclasses vs Modules


In some sense, OCaml modules are better behaved and founded on a sounder theory than Haskell typeclasses, which have some serious drawbacks. However, the fact that typeclasses can be reliably inferred whereas modules have to be explicitly used all the time more than makes up for this. Moreover, extensions to the typeclass system enable much of the power provided by OCaml modules.


I've looked at F# a bit, but it feels like it makes too many tradeoffs to be on .NET. You lose the module system, which is probably OCaml's best feature, in return for an unfortunate, nominally typed OOP layer.

I'm also not invested in .NET at all: if anything, I'd prefer to avoid it in favor of simplicity. I exclusively use Linux and, from the outside, Mono doesn't look as good as it could be. I'm also far more likely to interoperate with a C library than a .NET library.

If I had some additional reason to use .NET, I'd definitely go for F#, but right now I don't.
q-n-a  qra  programming  pls  engineering  nitty-gritty  pragmatic  functional  haskell  ocaml-sml  dotnet  types  arrows  cost-benefit  tradeoffs  concurrency  libraries  performance  expert-experience  composition-decomposition 
18 days ago by nhaliday

« earlier    

related tags

:/  abstraction  accuracy  advanced  advice  aggregator  ai-control  ai  algorithms  alternative  amazon  analogy  analysis  analytical-holistic  aphorism  api  apple  applicability-prereqs  arrows  assembly  atoms  automata-languages  backup  benchmarks  best-practices  better-explained  big-picture  blowhards  books  branches  brands  browser  build-packaging  business  c(pp)  caching  calculation  career  carmack  cas  causation  certificates-recognition  characterization  cheatsheet  checking  checklists  civilization  classification  cloud  cocoa  code-dive  commentary  communication  community  comparison  compensation  compilers  complex-systems  composition-decomposition  computer-memory  computer-vision  concept  concrete  concurrency  config  confounding  conquest-empire  constraint-satisfaction  contrarianism  cool  correctness  correlation  cost-benefit  coupling-cohesion  course  cracker-prog  critique  crosstab  crypto  cs  culture  d-lang  dan-luu  data-science  data-structures  data  database  dataviz  dbs  debate  debugging  deep-learning  degrees-of-freedom  density  design  desktop  detail-architecture  devtools  differential  diogenes  direction  distribution  documentation  dotnet  driving  duplication  ecosystem  editors  education  elegance  email  embedded  empirical  ends-means  engineering  equation-modeling  ergo  erlang  error-handling  error  essay  estimate  ethical-algorithms  evidence-based  examples  experiment  expert-experience  explanans  explanation  exploratory  facebook  faq  finance  flux-stasis  formal-methods  forum  frameworks  frontier  functional  futurism  gamedev  games  generalization  gibbon  git  github  go  golang  google  gotchas  graphics  graphs  guide  hardware  haskell  hg  history  hmm  hn  homepage  homo-hetero  howto  huge-data-the-biggest  ide  ideas  ideology  idk  ieee  impact  impetus  incentives  increase-decrease  info-dynamics  info-foraging  infrastructure  init  input-output  integration-extension  interface  intricacy  ios  iron-age  jargon  javascript  jit  jobs  julia  jvm  keyboard  knowledge  language  learning  legacy  lens  let-me-see  lexical  libraries  linear-algebra  linear-models  links  linux  lisp  list  llvm  local-global  lol  machine-learning  marginal  math.nt  math  measure  measurement  media  mediterranean  memory-management  mental-math  metabuch  microsoft  minimalism  mit  mobile  model-class  models  module  money  mooc  mostly-modern  multi  multiplicative  network-structure  networking  nibble  nitty-gritty  no-go  nonlinearity  nostalgia  notation  novelty  numerics  objektbuch  ocaml-sml  oly-programming  oly  oop  open-closed  optimization  orders  org:com  org:edu  org:junk  org:med  os  oss  osx  overflow  paradox  pareto  parsimony  pdf  people  performance  pessimism  philosophy  pic  planning  plots  pls-pm  plt  poll  polynomials  pragmatic  prediction  prepping  presentation  prioritizing  priors-posteriors  pro-rata  productivity  prof  programming  properties  protocol  puzzles  python  q-n-a  qra  quality  quotes  r-lang  random  ranking  rant  realness  rec-math  recommendations  reddit  reference  reflection  regularizer  repo  resources-effects  review  rhetoric  risk  robust  roots  rsc  rust-lang  rust  saas  safety  scala  scale  scaling-tech  sci-comp  science  search  sem  sentiment  sequential  server  shipping  signum  slides  social  software  span-cover  speculation  stackex  stanford  state  stats  steel-man  stock-flow  stories  street-fighting  strings  structure  study  subculture  summary  survey  sv  syntax  system-design  systematic-ad-hoc  systems  tainter  talk  talks  tcs  teaching  tech  technical-writing  technology  techtariat  telos-atelos  terminal  the-classics  the-world-is-just-atoms  theory-practice  thick-thin  things  thinking  threat-modeling  time-complexity  time-series  time  tip-of-tongue  tools  top-n  traces  track-record  trade  tradeoffs  tradition  transportation  trees  trends  trivia  troll  tutorial  types  ubiquity  uncertainty  unit  universalism-particularism  unix  vcs  video  visual-understanding  visualization  volo-avolo  web  webapp  weird  whole-partial-many  wiki  wire-guided  workflow  working-stiff  worrydream  worse-is-better/the-right-thing  writing  yak-shaving  🖥 

Copy this bookmark: