cracker-prog   35

history - Why are UNIX/POSIX system call namings so illegible? - Unix & Linux Stack Exchange
It's due to the technical constraints of the time. The POSIX standard was created in the 1980s and referred to UNIX, which was born in the 1970. Several C compilers at that time were limited to identifiers that were 6 or 8 characters long, so that settled the standard for the length of variable and function names.
We carried out a family of controlled experiments to investigate whether the use of abbreviated identifier names, with respect to full-word identifier names, affects fault fixing in C and Java source code. This family consists of an original (or baseline) controlled experiment and three replications. We involved 100 participants with different backgrounds and experiences in total. Overall results suggested that there is no difference in terms of effort, effectiveness, and efficiency to fix faults, when source code contains either only abbreviated or only full-word identifier names. We also conducted a qualitative study to understand the values, beliefs, and assumptions that inform and shape fault fixing when identifier names are either abbreviated or full-word. We involved in this qualitative study six professional developers with 1--3 years of work experience. A number of insights emerged from this qualitative study and can be considered a useful complement to the quantitative results from our family of experiments. One of the most interesting insights is that developers, when working on source code with abbreviated identifier names, adopt a more methodical approach to identify and fix faults by extending their focus point and only in a few cases do they expand abbreviated identifiers.
q-n-a  stackex  trivia  programming  os  systems  legacy  legibility  ux  libraries  unix  linux  hacker  cracker-prog  multi  evidence-based  empirical  expert-experience  engineering  study  best-practices  comparison  quality  debugging  efficiency  time  code-organizing  grokkability 
5 weeks ago by nhaliday
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  static-dynamic 
5 weeks 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 
6 weeks ago by nhaliday
When to use C over C++, and C++ over C? - Software Engineering Stack Exchange
You pick C when
- you need portable assembler (which is what C is, really) for whatever reason,
- your platform doesn't provide C++ (a C compiler is much easier to implement),
- you need to interact with other languages that can only interact with C (usually the lowest common denominator on any platform) and your code consists of little more than the interface, not making it worth to lay a C interface over C++ code,
- you hack in an Open Source project (many of which, for various reasons, stick to C),
- you don't know C++.
In all other cases you should pick C++.


At the same time, I have to say that @Toll's answers (for one obvious example) have things just about backwards in most respects. Reasonably written C++ will generally be at least as fast as C, and often at least a little faster. Readability is generally much better, if only because you don't get buried in an avalanche of all the code for even the most trivial algorithms and data structures, all the error handling, etc.


As it happens, C and C++ are fairly frequently used together on the same projects, maintained by the same people. This allows something that's otherwise quite rare: a study that directly, objectively compares the maintainability of code written in the two languages by people who are equally competent overall (i.e., the exact same people). At least in the linked study, one conclusion was clear and unambiguous: "We found that using C++ instead of C results in improved software quality and reduced maintenance effort..."


(Side-note: Check out Linus Torvads' rant on why he prefers C to C++. I don't necessarily agree with his points, but it gives you insight into why people might choose C over C++. Rather, people that agree with him might choose C for these reasons.)

Why would anybody use C over C++? [closed]:
Joel's answer is good for reasons you might have to use C, though there are a few others:
- You must meet industry guidelines, which are easier to prove and test for in C.
- You have tools to work with C, but not C++ (think not just about the compiler, but all the support tools, coverage, analysis, etc)
- Your target developers are C gurus
- You're writing drivers, kernels, or other low level code
- You know the C++ compiler isn't good at optimizing the kind of code you need to write
- Your app not only doesn't lend itself to be object oriented, but would be harder to write in that form

In some cases, though, you might want to use C rather than C++:
- You want the performance of assembler without the trouble of coding in assembler (C++ is, in theory, capable of 'perfect' performance, but the compilers aren't as good at seeing optimizations a good C programmer will see)
- The software you're writing is trivial, or nearly so - whip out the tiny C compiler, write a few lines of code, compile and you're all set - no need to open a huge editor with helpers, no need to write practically empty and useless classes, deal with namespaces, etc. You can do nearly the same thing with a C++ compiler and simply use the C subset, but the C++ compiler is slower, even for tiny programs.
- You need extreme performance or small code size, and know the C++ compiler will actually make it harder to accomplish due to the size and performance of the libraries
- You contend that you could just use the C subset and compile with a C++ compiler, but you'll find that if you do that you'll get slightly different results depending on the compiler.

Regardless, if you're doing that, you're using C. Is your question really "Why don't C programmers use C++ compilers?" If it is, then you either don't understand the language differences, or you don't understand compiler theory.


- Because they already know C
- Because they're building an embedded app for a platform that only has a C compiler
- Because they're maintaining legacy software written in C
- You're writing something on the level of an operating system, a relational database engine, or a retail 3D video game engine.
q-n-a  stackex  programming  engineering  pls  best-practices  impetus  checklists  c(pp)  systems  assembly  compilers  hardware  embedded  oss  links  study  evidence-based  devtools  performance  rant  expert-experience  types  blowhards  linux  git  vcs  debate  rhetoric  worse-is-better/the-right-thing  cracker-prog  multi  metal-to-virtual 
may 2019 by nhaliday
Colin Percivel's homepage
interesting links to Hacker News highlights
people  security  engineering  programming  links  blog  stream  hn  hacker  🖥  techtariat  cracker-prog 
october 2016 by nhaliday
command center: Prints
rob pike on the ephemerality of the digital and the reliability of the physical
planning  futurism  photography  lifestyle  reflection  rsc  techtariat  blowhards  cracker-prog  flux-stasis  spreading  nihil  bits 
july 2016 by nhaliday

related tags

abstraction  academia  advanced  algorithms  amazon  aphorism  api  apple  assembly  automata-languages  backup  benchmarks  best-practices  bits  blog  blowhards  books  build-packaging  c(pp)  carmack  certificates-recognition  cheatsheet  checking  checklists  cloud  code-dive  code-organizing  commentary  community  comparison  compilers  computer-memory  concurrency  contrarianism  correctness  cost-benefit  critique  cs  d-lang  dataviz  dbs  debate  debugging  degrees-of-freedom  design  devops  devtools  diogenes  direct-indirect  direction  distributed  documentation  dotnet  duplication  editors  education  efficiency  elegance  email  embedded  empirical  ends-means  engineering  error-handling  error  essay  evidence-based  expert-experience  explanation  facebook  flexibility  flux-stasis  formal-methods  forum  futurism  games  git  golang  google  gotchas  graphics  graphs  grokkability  guide  hacker  hardware  hci  history  hn  homepage  howto  impetus  infrastructure  init  integration-extension  intricacy  jvm  keyboard  keyboards  learning  legacy  legibility  let-me-see  libraries  lifestyle  links  linux  list  measurement  media  memes(ew)  metal-to-virtual  metrics  microsoft  mobile  multi  nihil  nitty-gritty  nostalgia  notation  objektbuch  oop  org:com  org:med  os  oss  osx  parsimony  pdf  people  performance  philosophy  photography  plan9  planning  pls  plt  pragmatic  prediction  presentation  priors-posteriors  profile  programming  properties  protocol  python  q-n-a  quality  rant  reference  reflection  research-program  research  retrofit  review  rhetoric  rigidity  rsc  rust  saas  scaling-tech  search  security  shipping  slides  social  software  spreading  stackex  state  static-dynamic  stories  stream  strings  structure  study  sub-super  summary  summer-2014  sv  syntax  system-design  systems  tech  technical-writing  techtariat  telos-atelos  terminal  theory-practice  thinking  time-complexity  time  tip-of-tongue  tools  top-n  traces  track-record  tradeoffs  trees  tricks  trivia  tutorial  twitter  types  uniqueness  unit  unix  ux  vcs  video  visualization  wire-guided  workflow  working-stiff  worrydream  worse-is-better/the-right-thing  yak-shaving  🖥 

Copy this bookmark: