7 ms·

>[libc4life] is aiming for simplicity and leverage; and it makes a real effort to get there by playing on C's strengths, rather than just inventing yet another

>[libc4life] is aiming for simplicity and leverage; and it makes a real effort to get there by playing on C's strengths, rather than just inventing yet another buggy Lisp. Ouch, right in the feels, I've been working on https://buildyourownlisp.com https://buildyourownlisp.com in my spare time. (EDIT: I was looking for a name for the repo, YABLisp it is.) > coding in C is a welcome therapy after seemingly wasting years exploring various ways of pretending the hidden complexity in my stack was someone else's problem I've noticed several older talented programmers express similar feelings. I was watching Casey Muratori's Handmade Hero stream, where he writes a game in C from scratch, and he said, I don't know who would watch this except aging C programmers. I'm less than 30 but I already feel like an aging C programmer. Most OOP seems like a morass; I've switched to writing my own projects in C and my prototypes in C-like Python. But I wonder what hope there is for people like us in the industry, which seems to be moving ever further away from this type of programming.

xenadu02 10y ago
I'm sure it inflates one's ego but the chances that they've avoided writing any exploitable security vulnerabilities is almost zero.
- codr4life 10y ago
  Show me a software stack without those kinds of bugs; they're all written in C somewhere down the line; enormous amounts of complicated C, written by coders of varying competence. At least in my stack I can keep it simple and fix anything that needs fixing.
  - nothrabannosir 10y ago
    He/she meant: two programmers of equal skill and security conscientiousness will create less exploitable security vulnerabilities per "unit of functionality", using C and <memory safe language> respectively, ceteris paribus. "Easier languages attract less skilled devs", "higher level languages allow you to create more complex programs", yada yada. Could all be true, but it's besides the point.
    - _pmf_ 10y ago
      > "Easier languages attract less skilled devs", "higher level languages allow you to create more complex programs", yada yada. Could all be true, but it's besides the point. For the armchair discourse it's beside the point, but for real-world development, it's what matters the most.
  - lmm 10y ago
    Not everything has to come down to C. OCaml is self-hosting I believe. And even if it did, rates matter.
- greenshackle2 10y ago
  I didn't mean to make the point so C-centric. I'm not just talking about C programmers. I don't think we should all write C all the time. I went back to C and Lisp in my spare time because I'm already invested in those languages, between C itself, and CPython. The common feeling I've seen repeated is doing OOP for a while then getting tired of it, and casting it off. > I'm sure it inflates one's ego I'm sure that's true for some, but it would be shortsighted to think all programmers who dislike OOP are just full of themselves and don't have any valid insights.
codr4life 10y ago
No worries :) I was mostly referring to the tendency to turn C into another language on the api-level. Building Lisps is one of my part time hobbies. Language abstractions are like training wheels. Once you know what you're doing they start getting in your way, and you start preferring languages with less baggage.
_RPM 10y ago
What the hell is C-Like Python?
- greenshackle2 10y ago
  Python that looks like C? It's not a thing, I just made it up. A subset of Python that is not too painful to rewrite in C. No classes, I use namedtuples as structs, etc. I'm not sure it's a sane thing to do, arguably I should just write the thing in C in the first place, but I have more experience with Python so it's still easier to me.
  - _RPM 10y ago
    Python does not look like C. The first thing I can think of is using traditional loop counters instead of the for..in construct.
    - greenshackle2 10y ago
      That's a minor detail. I'm talking about writing in a procedural style. Rewriting a for..in as a for with counters is relatively trivial, compared to re-implementing a complex class hierarchy in C. You can write procedural Python, and it will look kinda like C if you squint. Cython even lets you use C types directly, with a simple syntax. As I said, maybe not the sanest thing to do, everything is an object in Python so you can never really get away from it's object-oriented nature.
      - flamedoge 10y ago
        Nobody stops one from writing Python like C. CLikeMemoryModel = []
      - Beltiras 10y ago
        Python is not really object oriented. To get information hiding you have to wrap your class in a closure and that closure has to track the individual instances. It's not clean code and it's horribly inefficient. Python is also not a functional language. Python provides language structures that allow you to use both styles of programming OOP and functional as-if-it-was.
hvidgaard 10y ago
Long term maintanance is easier with safer languages.
- codr4life 10y ago
  Everything is easier in safer languages, far from everything is possible.
  - hvidgaard 10y ago
    What do you mean with everything? Because we have seen languages such as D (without GC) and Rust that offer the same possibilities and performance, yet much less opportunity to blow your hand off by accident.
userbinator 10y ago
But I wonder what hope there is for people like us in the industry, which seems to be moving ever further away from this type of programming. C is still very popular (along with Asm) in embedded systems. ARM cores and large memories are certainly getting very cheap, but still not at the level of many of the 8 and 16-bit microcontrollers. I find OOP often overused too, but it can be genuinely useful in certain situations where there is a very strong association between some data and the operations on it. For this reason, I tend to use a subset of C++ in a style that would probably enrage a lot of the "C++ is not C" advocates.
- conjectures 10y ago
  I've noticed this, and also that the typical salaries for embedded systems developers seems to be lower than for hotness.js developers :( Am I wrong? Hope so.
  - mauvehaus 10y ago
    My experience, coming as somebody who has experience on the large end of embedded (100's of MHz, 100's of MB RAM, MMU, running Linux), albeit a while ago, is that it's hard to break back into it if you've been out of the community for a while. The last time I was looking for a job, I had been doing non-embedded, including kernel and low-level for 8 years or so, and I had the darnedest time finding embedded positions to apply for, let alone get calls back from. Startups that do embedded seem to mostly get the embedded done in the MVP stage, and by the time they're looking to grow, they've got a (small) team already doing that work. In fairness, this is partially self-inflicted; iRobot has been on the monthly whoishiring threads for as long as I've been looking for jobs in the Boston area, but I decided long ago that I'd never work in defense (or finance). Recently, I've added to that list "companies whose business model is selling their users' information" (many of them these days), and "companies whose entire sales pitch plays on your fears" (a recruiter tried to put me in touch with a company that does baby monitors that measure some basic health parameters, and their promotional video was appalling to me). I kind of stuck a toe across the first line, and tried talking to somebody Fitbit-esque, but never got a call back. I also wound up with a connection into an electronic paper company, but that went cold after submitting a resume. Ditto a company that does automotive suspension stuff. I realize that being out of the community for a while makes it hard to get consideration if there are other candidates who have current experience, so I started a personal project building a clock out of VFD tubes, and added a github link to my resume before submitting several of those. That didn't seem to help. I got hired doing non-embedded before I finished the clock project. I'm at the point of needing to learn EAGLE, lay out boards and get them made. That was a year and a bit ago; right now I've got other projects that take up my weekend time. To respond directly to your point, I'm willing to bet that there are two factors at work: 1. Supply and demand. If demand exceeded supply, I would think that I'd at least be able to get a call back with my background. 2. Hardware is a hard row to hoe. There's a lot less capital invested in a hotness.js project that flops, and it's a lot easier to scale if it takes off. No, it's not necessarily easy, but there's a wide gap between "provision more instances on EC2 and fix the bottlenecks in the architectures" and "the factory is already at capacity and the supplier for the key part is backordered for 3 months". The money that doesn't need to go to covering those risks can go into your pockets.

xenadu02 10y ago

I'm sure it inflates one's ego but the chances that they've avoided writing any exploitable security vulnerabilities is almost zero.

codr4life 10y ago
Show me a software stack without those kinds of bugs; they're all written in C somewhere down the line; enormous amounts of complicated C, written by coders of varying competence. At least in my stack I can keep it simple and fix anything that needs fixing.
- nothrabannosir 10y ago
  He/she meant: two programmers of equal skill and security conscientiousness will create less exploitable security vulnerabilities per "unit of functionality", using C and <memory safe language> respectively, ceteris paribus. "Easier languages attract less skilled devs", "higher level languages allow you to create more complex programs", yada yada. Could all be true, but it's besides the point.
  - _pmf_ 10y ago
    > "Easier languages attract less skilled devs", "higher level languages allow you to create more complex programs", yada yada. Could all be true, but it's besides the point. For the armchair discourse it's beside the point, but for real-world development, it's what matters the most.
- lmm 10y ago
  Not everything has to come down to C. OCaml is self-hosting I believe. And even if it did, rates matter.
greenshackle2 10y ago
I didn't mean to make the point so C-centric. I'm not just talking about C programmers. I don't think we should all write C all the time. I went back to C and Lisp in my spare time because I'm already invested in those languages, between C itself, and CPython. The common feeling I've seen repeated is doing OOP for a while then getting tired of it, and casting it off. > I'm sure it inflates one's ego I'm sure that's true for some, but it would be shortsighted to think all programmers who dislike OOP are just full of themselves and don't have any valid insights.

codr4life 10y ago

No worries :) I was mostly referring to the tendency to turn C into another language on the api-level. Building Lisps is one of my part time hobbies. Language abstractions are like training wheels. Once you know what you're doing they start getting in your way, and you start preferring languages with less baggage.

_RPM 10y ago

What the hell is C-Like Python?

greenshackle2 10y ago
Python that looks like C? It's not a thing, I just made it up. A subset of Python that is not too painful to rewrite in C. No classes, I use namedtuples as structs, etc. I'm not sure it's a sane thing to do, arguably I should just write the thing in C in the first place, but I have more experience with Python so it's still easier to me.
- _RPM 10y ago
  Python does not look like C. The first thing I can think of is using traditional loop counters instead of the for..in construct.
  - greenshackle2 10y ago
    That's a minor detail. I'm talking about writing in a procedural style. Rewriting a for..in as a for with counters is relatively trivial, compared to re-implementing a complex class hierarchy in C. You can write procedural Python, and it will look kinda like C if you squint. Cython even lets you use C types directly, with a simple syntax. As I said, maybe not the sanest thing to do, everything is an object in Python so you can never really get away from it's object-oriented nature.
    - flamedoge 10y ago
      Nobody stops one from writing Python like C. CLikeMemoryModel = []
    - Beltiras 10y ago
      Python is not really object oriented. To get information hiding you have to wrap your class in a closure and that closure has to track the individual instances. It's not clean code and it's horribly inefficient. Python is also not a functional language. Python provides language structures that allow you to use both styles of programming OOP and functional as-if-it-was.

hvidgaard 10y ago

Long term maintanance is easier with safer languages.

codr4life 10y ago
Everything is easier in safer languages, far from everything is possible.
- hvidgaard 10y ago
  What do you mean with everything? Because we have seen languages such as D (without GC) and Rust that offer the same possibilities and performance, yet much less opportunity to blow your hand off by accident.

userbinator 10y ago

But I wonder what hope there is for people like us in the industry, which seems to be moving ever further away from this type of programming. C is still very popular (along with Asm) in embedded systems. ARM cores and large memories are certainly getting very cheap, but still not at the level of many of the 8 and 16-bit microcontrollers. I find OOP often overused too, but it can be genuinely useful in certain situations where there is a very strong association between some data and the operations on it. For this reason, I tend to use a subset of C++ in a style that would probably enrage a lot of the "C++ is not C" advocates.

conjectures 10y ago
I've noticed this, and also that the typical salaries for embedded systems developers seems to be lower than for hotness.js developers :( Am I wrong? Hope so.
- mauvehaus 10y ago
  My experience, coming as somebody who has experience on the large end of embedded (100's of MHz, 100's of MB RAM, MMU, running Linux), albeit a while ago, is that it's hard to break back into it if you've been out of the community for a while. The last time I was looking for a job, I had been doing non-embedded, including kernel and low-level for 8 years or so, and I had the darnedest time finding embedded positions to apply for, let alone get calls back from. Startups that do embedded seem to mostly get the embedded done in the MVP stage, and by the time they're looking to grow, they've got a (small) team already doing that work. In fairness, this is partially self-inflicted; iRobot has been on the monthly whoishiring threads for as long as I've been looking for jobs in the Boston area, but I decided long ago that I'd never work in defense (or finance). Recently, I've added to that list "companies whose business model is selling their users' information" (many of them these days), and "companies whose entire sales pitch plays on your fears" (a recruiter tried to put me in touch with a company that does baby monitors that measure some basic health parameters, and their promotional video was appalling to me). I kind of stuck a toe across the first line, and tried talking to somebody Fitbit-esque, but never got a call back. I also wound up with a connection into an electronic paper company, but that went cold after submitting a resume. Ditto a company that does automotive suspension stuff. I realize that being out of the community for a while makes it hard to get consideration if there are other candidates who have current experience, so I started a personal project building a clock out of VFD tubes, and added a github link to my resume before submitting several of those. That didn't seem to help. I got hired doing non-embedded before I finished the clock project. I'm at the point of needing to learn EAGLE, lay out boards and get them made. That was a year and a bit ago; right now I've got other projects that take up my weekend time. To respond directly to your point, I'm willing to bet that there are two factors at work: 1. Supply and demand. If demand exceeded supply, I would think that I'd at least be able to get a call back with my background. 2. Hardware is a hard row to hoe. There's a lot less capital invested in a hotness.js project that flops, and it's a lot easier to scale if it takes off. No, it's not necessarily easy, but there's a wide gap between "provision more instances on EC2 and fix the bottlenecks in the architectures" and "the factory is already at capacity and the supplier for the key part is backordered for 3 months". The money that doesn't need to go to covering those risks can go into your pockets.