11 ms·

At the risk of being featured in a future episode of "Hacker News reacts to (Dropbox|iPhone)"... ...a Makefile and vim (or emacs, or even nano, I'm not going t

• hot_gril 3y ago
  My last project in C had a CMake file that generated a Makefile, idk if you consider that too much.
• Aurornis 3y ago
  > If they are not fine, then C is probably not the right language for the project. This is called gatekeeping and it’s not helpful. It’s fine to write C in vim/emacs/nano if you want. It’s fine to write C in Visual Studio Code if you want. It’s fine to write C in CLion if you want. There is nothing wrong with any approach and no need to gatekeeper an entire programming language based on editor preference.
  • the-printer 3y ago
    Is it really gatekeeping? Does this opinion (that was valid and useful to me) carry any preventive force that the term suggests?
    • bryancoxwell 3y ago
      It dissuades people who aren’t comfortable with Makefiles and Vim from using C, so I’d agree it’s gatekeep-y.
      • kragen 3y ago
        i think that's the opposite of the intent they're saying that you don't need to be comfortable with ides and fancy debuggers and cmake and language servers and game development engines and ci pipelines and all kinds of complicated stuff to write c successfully a bare-bones text editor and the most minimal build system are plenty and if they aren't plenty, they're not saying that's a problem with you, but with c i don't agree (ctags, valgrind, git, and gdb go a long way towards making c usable, and evidently c is the best language for a lot of things even ctags and gdb struggle with, like linux kernel drivers, and cmake evidently helps a lot if you care about ms-windows) but that's what they said, and you totally misunderstood them because you somehow got the idea that vim and make are some kind of super advanced tools rather than relics from the 01980s they're maybe a bit unprepossessing at first glance but mostly what they are is simple and primitive think of using a hammer rather than a cam-driven turret lathe you can go lower tech than make too now that cpus and c compilers are so fast while sleep 1; do # ci pipeline gcc -Wall -funny -mtune=i69 *.c -lm -liberty -letmypeoplego -o proggie && # build system ./proggie --run-tests # test runner done c compiles fast enough that this scales to several thousand lines of code, c++ very much does not of course you need a testing framework if (!strcmp(argv[1], "--run-tests")) return run_tests(); ... three seconds latair ... int run_tests() { return test_ui() || test_network() || test_parsing(); } int test_parsing() { assert(trees_equal(parse("3+4"), parse("3 + 4"))); assert(!trees_equal(parse("3+4"), parse("3 + 5"))); ... } now i'm not saying you shouldn't write a test runner in unity and distribute your ci pipeline with zmq and mqtt and whatever the fuck. better ux is worth my weight in gold, and i have programmer gut. also zmq is metal as fuck what i am saying is that the difference between no test runner and an infinite loop in bash is much bigger than the difference between the bash loop and circleci or gitlab pipelines. so don't be intimidated by articles like this which make it sound like you need a team of phds to set up a test runner. writing tests and running them is what helps, not so much stylishness except for version control. a build script in shell is a serviceable alternative to make, but cp -a proggie/src snapshot.$(date +%Y-%m-%d) is not a serviceable alternative to git also if 3d test runners with inotify and particle systems with custom shaders mean that people write more tests and see the tests fail sooner after they break shit, that could make a real difference
        • ryan-c 3y ago
          I'm not a he (some other folks used "they" which is fine), but this is otherwise a pretty good interpretation - it absolutely was a dig at C, not elitism. If you're going to learn a bunch of modern tooling and start a green field project that justifies that complexity, C is generally a poor choice. Learn a modern language. I use C somewhat regularly, including for kernel stuff, embedded, and legacy code. Mostly, though, when I use C, it's because I'm doing a small thing that I need to be very fast, and I haven't yet bothered to get comfortable with Rust.
          • kragen 3y ago
            oops, i'm sorry i misgendered you. i think i have fixed it now, but now the editing window has closed on your other points i mostly agree, except that if i write a library in any popular 'modern' language, it can only be called from that language, which seems like a missed opportunity and when i went back and compared development time logs, the development speed advantages of modern languages seem to be only a factor of 2 or 3 over c, once i get beyond a few hundred lines which i guess is why linux, firefox, cpython, gcc, apache, poppler, libvte, and so on are written in c or occasionally c++. it's not because the authors didn't know about common lisp, scheme, ml, smalltalk, and so on, or couldn't figure out how to write a garbage collector rust and some other unpopular modern languages look like they might change that situation (nim, zig, koka, a couple of others i can't think of right now)
            • ryan-c 3y ago
              I'm sorry, I'm having trouble hearing over the sound of that poor load bearing "generally" creaking under the stress of the thread. ;-) Yeah, the "C is the universal ABI" problem is... annoying. Hopefully something safer eventually replaces it in that niche. Also, I think the main reason I use a lot of the tools I do is just "suck cost fallacy".
              • kragen 3y ago
                heh what the fuck is it with these people that they flagged your comment upthread
      • seabird 3y ago
        If vim and make are spooking somebody, they need to turn tail and run the fuck away from C. I love it to death, but it's a frustrating experience from another era. vim and make are the least of your worries when dealing with it.
        • flohofwoe 3y ago
          > but it's a frustrating experience from another era Are you using C99 features? I find the "new" features extremely enjoyable, it feels like a different language compared to C89 or the common C/C++ subset.
          • seabird 3y ago
            I am, but C99 doesn't fix the various sharp corners and gotchas that are littered throughout language. I don't say any of this as a dig at C, but at ~50 years old, it definitely shows its age.
        • vidarh 3y ago
          I've used C since the 1980's, and vim most certainly "spooks" me. C and make does not
        • pjmlp 3y ago
          Started coding in 1986, used my first UNIX (Xenix) in 1993, the only thing I care about vi, is knowing enough to rescue me when there isn't anything else installed to edit files.
          • stjohnswarts 3y ago
            Yep, plenty of really good windows/macos programmers have never touched vi or emacs. I'm not sure why users of those are so elitist. I tend to prefer vim editor keystrokes in my editors but that's just because I got used to it from college and terminal editing.
    • Aurornis 3y ago
      The colloquial definition of "gatekeeping" doesn't require literal preventative force. See https://www.urbandictionary.com/define.php?term=Gatekeeping https://www.urbandictionary.com/define.php?term=Gatekeeping
      • the-printer 3y ago
        I get that, but even figuratively, it's a relatively harmless opinion that can only achieve as much by way of influence or control as readers are willing to allow the anonymous commenter to hold over them. There's more to learn if we confront the opinion by its premises (as shown by other responses to the comment) than by subjective moral grounds.
    • sophacles 3y ago
      The term has become common on the web to refer to enthusiasts trying to control how people enjoy/use a term or participate in an activity - for instance "real fans only like the stuff from before $album" or "only filthy casuals play the game that way" (or "you shouldn't use C if you want modern, good tooling"). This might be worth reading through: https://www.urbandictionary.com/define.php?term=Gatekeeping https://www.urbandictionary.com/define.php?term=Gatekeeping
      • gdy 3y ago
        [dead]
  • rfrey 3y ago
    I did not read this as gatekeeping, rather I read it as an opinion on the suitability of C for kinds of project. If vim + make isn't enough, then C is probably not the appropriate language. Not that you shouldn't use C if you don't use vim + make. We always talk about how good engineers "choose the right tool for the job". I don't think expressing an opinion on what the right kind of job is for a particular tool should be out of bounds. (Setting aside whether the opinion is correct or not.)
    • shortrounddev2 3y ago
      C is much easier to develop with using gdb
    • marmakoide 3y ago
      For niche embedded devices, you often end-up with a half-baked C compiler and assembler, nothing else.
      • xigoi 3y ago
        You can still use a high-level language that compiles to C.
  • deleted 3y ago
    [deleted]
  • hot_gril 3y ago
    You can write C how ever you want, doesn't mean it's the right language for the project. My team uses C++ a lot like Java, and turns out Java was the better tool for our use case.
    • stjohnswarts 3y ago
      I bet your customers enjoy the extra memory and performance though...
      • hot_gril 3y ago
        They don't, cause the speed at which we have to implement new features means cutting corners. We write backends, none of which are performance-critical. A lot of faster algos that would take too long to implement in C++ get skipped, so in the end it's slower than partner teams' Java code that does similar things, but again it doesn't matter as long as nobody notices the latency.
  • jonahx 3y ago
    > This is called gatekeeping and it’s not helpful. What a bad faith interpretation. It's advice based on the poster's experience, stated with both qualification and good humor. You are free to ignore it. I appreciated it.
    • 95014_refugee 3y ago
      It is gatekeeping. The poster was not offering advice, they were being actively discouraging. You can argue shades of grey, but at the end of the day this is an unsolicited discouragement, and an arbitrary out-grouping. The fact that you don't see this as problematic, is problematic.
      • kragen 3y ago
        the fact that they don't see it as problematic means that they didn't misinterpret the comment the way you did, which is because they know things you don't thus hegemonic institutions reinscribe the kyriarchy generation after generation by perpetuating a hierarchical opposition between "knowledge" and so-called "ignorance", which is socially constructed to be inferior, less than, but which serves the purpose of distinguishing the graduates of elite institutions (to which access is mediated by the financial privilege of the bourgeoisie) from the subaltern underclass; thus "knowledge" serves the interests of capitalism by reproducing oppressive class divisions, enabling the continued exploitation of the working class what could be more problematic than that? but if you're interested in learning something and not just playing word games to gain status by putting others down, i problematically mansplained what you're missing in https://news.ycombinator.com/item?id=37083233 https://news.ycombinator.com/item?id=37083233
      • lcnPylGDnU4H9OF 3y ago
        > a Makefile and vim (or emacs, or even nano, I'm not going to judge your kink) The advice is common enough that it has a wikipedia page: https://en.wikipedia.org/wiki/KISS_principle https://en.wikipedia.org/wiki/KISS_principle. There is no gatekeeping. There is a suggestion that C is best used for projects that have builds no more complex than a Makefile configuration. There is explicitly no ~judgement~ limit on what ~kink~ text editor one may use to edit the files.
  • ryan-c 3y ago
    Editor preference was not intended to be the focus of my comment, it was more me being incredulous that someone would build something in C which necessitated Docker. If someone wants to do that anyway, I am going to be perplexed that C was the language choice rather than golang or rust, and perhaps worried about C being a footgun WRT security, but whatever.
    • metabagel 3y ago
      I think the point of Docker is a reproducible build environment.
      • hot_gril 3y ago
        Yeah, the Docker part makes sense. You don't need it, but it can be nice. Don't want mundane differences between devs' setups to get in the way, especially when they're not all the same OS.
    • aulin 3y ago
      How many times in your professional career you had the liberty to choose the language a project was developed on?
      • ryan-c 3y ago
        A supermajority of them, actually.
        • aulin 3y ago
          That's usually not the case. You work on existing code base and you want your editor to be able to explore it efficiently. Changing language is rarely an option unless you happen to enter a project at the very start.
  • thr_gt 3y ago
    If you're using vsc then C is absolutely not the right language. If your code can't fit in your head when you're writing it then you have no hope of debugging it. Vsc very much encourages your code to grow as large as the machine you're wiring it in can handle.
  • crabbone 3y ago
    This is not a matter of taste. VSCode is an alien in the C world. It's clumsy, demanding and offers plenty of useless features, whereas the simple stuff is hard / impossible to get to work. If you work on a C project, you need to be ready to have to edit source code, at least minimally, from an environment that doesn't have GUI. You will have to interact with pagers, man readers, readline a lot -- it's a lot more convenient if your editor works in the same way as those tool. You are just creating unnecessary problems when you use VSCode or a similar editor. And I cannot think about a single benefit that would come from using it. Beside other things, it's just a crappy text editor... the only thing that's going on for it is that it's a Web browser application... which is kinda worthless when it comes to a typical C project.
    • pjmlp 3y ago
      As someone that has lived throught the glory days of UNIX development servers, I see VSCode as a modern version of using XEmacs via X Windows. Seemed perfectly modern for the mid-90's using DG/UX. Apparently plenty of people don't have a clue of many of those environments used to be.
• rewmie 3y ago
  > ...a Makefile and vim (or emacs, or even nano, I'm not going to judge your kink) are fine. If they are not fine, then C is probably not the right language for the project. Sorry buddy, you might believe Makefiles are fine only if you are not aware of the most basic requirements of a build system. CMake does stuff like running sanity checks on libraries, configure them for you with minimal effort, and even add platform-specific configuration easily. Did you know that cmake started as a Makefile generator? Why do you think people need that? Makefiles alone were never enough, as the development of tools such as the autotools family demonstrated decades ago. Claiming otherwise just seems naive flexing from someone who has no real world experience whatsoever.
  • znpy 3y ago
    > Did you know that cmake started as a Makefile generator? Why do you think people need that? I like make myself, but I’m honest enough to acknowledge that the whole autotools suite (autoconf/automake) was born to, essentially, generate makefiles. Which is not 100% make’s complexity’s fault though… the toolchains have their own complexity (even more so when a project must build across platforms)…
• sfpotter 3y ago
  Strongly recommend using meson or CMake instead of Make unless you have a very specific reason you can’t use one of these tools.
  • jjgreen 3y ago
    I once had to compile cmake from source (the cmake version of something I needed to build was lower that the OS version of cmake). Not a fun afternoon.
• heisenzombie 3y ago
  I don't quite understand the sentiment. So, let's say we have a project. For whatever technical (or social, historical, religious...) reason, C is chosen as the right language. Why does that imply that the programmers on that project should therefore write that C code in a terminal, with no linter, code formatter, static analysis, test runner, etc.?
  • isaacremuant 3y ago
    Weird strawman. Those tools all run on terminals. IDEs use tools that run on terminals. Teams can use a combination of different IDEs and run the tools at different levels or their pipelines, which necessitate that they be automatable (and not GUI only).
    • circuit10 3y ago
      You're missing the point, they aren't saying "your development process should never involve a terminal" but rather "you don't necessarily have to use this bare-bones setup which happens to be terminal based"
  • icedchai 3y ago
    20 years ago, I worked on a C and C++ project that supported a billion dollar business. Almost everyone used vi. They used none of those other tools, and there were maybe a half dozen unit tests in the whole project. I sure hope times have changed.
    • haggy102 3y ago
      Why not advocate for better testing? What was preventing you from spending more time unit testing code running a billion dollar business?
      • post-it 3y ago
        A project manager, probably. "Advocating for XYZ" costs emotional capital that I'm not necessarily willing to devote to a particular project, or to my employer at all.
• maccard 3y ago
  A dockerfile gives a clean, repeatable build environment. If there is ever a toolchain that needed that, it's native toolchains like gcc and clang.
  • hot_gril 3y ago
    Exactly. The one dev environment I can name where a Dockerfile really isn't useful is also the highest-level, NodeJS.
    • maccard 3y ago
      I write a decent amount of go, and it's not wildly useful there either but I still use them as the rest of the tooling is good enough that it works for me.
  • seabass-labrax 3y ago
    That reads almost like a disparagement of GCC/Clang; the reality is you can just build on pretty much any host system directly and it will work. Having clean and repeatable builds is extremely useful, and Docker is a reasonable way to do that, but that shouldn't mask the importance of understanding the native runtime dependencies of the program once used outside of that one container. A concrete example of that: don't compile a C program in an Alpine Linux Docker image with dynamic linking, or it you won't be able to run the resultant binary on a RHEL machine. This is contrast to languages which run atop a virtual machine or interpreter, where the details of the build environment rarely matter on the runtime machine.
    • maccard 3y ago
      Its a disparagement at the fact they're dated, rather than the software itself. GCC searches by default in /usr/include and friends, (and a similar set of paths for library paths), meaning that one random library you downloaded 11 years ago is now perpetually on your search path.
    • Dwedit 3y ago
      If your code is using a version of GCC that's many years old, then the compiler will have changed sufficiently that code can break.
• deleted 3y ago
  [deleted]
• xaduha 3y ago
  > If they are not fine, then C is probably not the right language for the project. It's for C/C++ as author says, not just for C. And even if you're using Qt and write mostly QML you still need some C++ and it's much easier with code completion. I'd rather use VSCode than Qt Creator for that and I'm certainly not going back to vim.
• badsectoracula 3y ago
  I write a bunch of C for various projects of mine and i do it in an editor with some C understanding (it varies by which, but the latest combo is Kate with a Clang-based LSP, however i've also used "plain" text editors with barely if at all any understanding like Notepad++ and Geany, both of which give you at best word completion with words they picked up from the buffer without actually knowing what they mean). I also write Free Pascal using Lazarus, an IDE which actually understands the language at a deep level. The experience writing the latter is way *WAY* better than the former and my opinion to that isn't "just write more in Free Pascal" but "i want an IDE for C that is at least as good as Lazarus is for Free Pascal". I want a C IDE that, among others: 1. Can understand the code so that when i, e.g., want to rename the identifier "foo" it doesn't try to rename it as a keyword but knows if it refers to a local variable, global variable or struct member and only update references to that. 2. Can understand the code so that if i use a symbol defined in a header file that the current module doesn't include by itself it can put it in the includes section automatically (or at least ask me to) instead of waiting for the compiler to fail. If there is some conflict (e.g. because the symbol definition depends on macros or whatever) it should be able to understand that. 3. Can understand the code so that it can move structs, functions, etc around in modules and update header files and their uses in other modules automatically. 4. Can understand the code so that it can convert a struct defined in a header file to an opaque struct and vice versa, for the former being able to tell me which existing code would break and offer fixes (e.g. automatically creating accessor functions for the members). 5. Can understand the code so that it can expand macros in place visually, allow me to edit the macros expanded in-place while actually modifying the header file (or wherever the macro is defined) and also quickly tell me where the macro is used in other places. 6. Can understand the code so that it can convert code to functions, expand functions inline (with any local variables being placed at a decent position and any conflicts handled - it can ask for example if it sees the inline code to use "for (i=1; i<10;" and the existing code also has a "int i" if it should reuse the "int i" or replace it with heuristics that provide decent defaults), add/remove arguments (with automatic updates wherever they are used), etc. 7. Can understand the code so that one can create queries like "replace all string literals to non-static functions whose name matches the '^foo_.*$' regex with calls to macro 'TXT' and the same string literal as the parameter to macro". 8. Has a debugger that works with all the basics (breakpoints, step in/through/out, watches, etc) and... 9. The debugger can modify a variable while the program is running. 10. The debugger can make function calls while the program is running. 11. The debugger can modify a function while the program is running (any new calls are done to that function). 12. The debugger can watch data over time and be able to display values in various means like various graph types. 13. The debugger can tell you where (in code) some use-after-free was originally allocated and then where it was freed and where it was used, all with nicely shown arrows, hyperlinks and graphics directly inside the editor instead of you having to manually parse (in your head) some callstack. Similar for other types of errors like accessing invalid pointers, array data out of range (should tell you both the range and the accessed index where that can be statically inferred), etc. 14. The debugger can put conditional breakpoints which: 14a. Can call functions defined in the program. 14b. Can check if the breakpoint comes from a specific callstack (e.g. break if function "foo" is called from "bar" but not from "baz"). 14c. Can access local variables and arguments up the callstack (obviously the breakpoint will only break where that is possible). 15. There is a profiler that works and... 16. The profiler can create call-based profiles (think gprof) and statistics-based profiles (think perf). 17. The profiler can record the full callstack instead of just the function name. 18. The profiler can create full call diagrams (see Luke Stackwalker[0] as an example) as well as flamegraphs (see some perl script for perf i don't remember). 19. The profiler can keep track not only where* but also when* a sample was taken so it can create profile timelines. Actually just have it do everything i had a profiler i wrote some time ago for Free Pascal[1], including be able to be instrumented by the running program, filter via thread, call stack depth, etc. 20. The profiler can call functions in the profiled program to create additional profile (e.g. if you want to count how many files are opened or how many rays your raytracer is casting or whatever so you can use the full profiler functionality instead of hacking up your own) 21. There is a static analysis tool that works and... 22. ...works like whatever Xcode's integration with Clang's analyzer is, i do not have much experience with those but i remember using it a couple of times years ago and thinking it was neat. I haven't seen any other graphical integration of a code analysis tool, pretty much every other analyzer feels like compiler warnings++. More of the graphical approach and less of the warnings++ approach please. 23. There is some form of project management / build tool / whatever that the IDE uses and... 24. The IDE can let you setup various "configurations" for build options (including preprocessor defines, which files/objects/libraries are to be included, etc) that can be mixed and matched at will (e.g. a "lightweight" and "full" configuration set could be mixed with a "win32" and "linux" configuration set with the latter relying on the "unix" configuration and none of those would need you to duplicate any information). 25. The IDE can know about libraries, be able to locate them as well as place them in appropriate locations when you are building a library. Libraries should be able to be built as both statically and dynamically linked if that is needed. If a library A relies on another library B and a program uses library A it should not need to also specify library B too - in the exceptional case where that is needed (e.g. there are alternative versions of library B) it should allow that but it should not be necessary. 26. Setting up the above should not need to be done via arcane text files but via a nice GUI that doesn't hate the user - e.g. using a library should not need you to type it's name but allow you to check next to its name in a listbox with checkboxes (with name filtering and categories). It should also know about different system libraries for the same thing (e.g. OpenGL in Windows, Linux and Mac is accessed via different ways). This should be configurable, not hardcoded - a custom library should also be able to use that functionality. Note that all of this can be stored in text files (e.g. for easier VCS support) but not needed. 27. More of a #26b but i think it deserves its own point: in addition the IDE should have deep knowledge of what a library offers and like #2 if it knows a symbol being offered by a library it should automatically add it to your project's requirements. 28. Again more of a #27b but also a #2b: it should be able to clean up any unused stuff (either automatic or explicitly). In total i should, e.g, be able to use OpenGL by typing "gl", pressing the auto-complete key (ctrl+space or whatever) and have the IDE suggest all the "gl" prefixed functions like "glClear", then once i select "glClear" (or whatever), the IDE adds the #include <GL/gl.h> header and the libgl library in the dependencies. If i press Ctrl-Z to undo that, the header files and library dependencies (if added) will be removed. If i press Ctrl+S to save or some other key to cleanup the project (depending on the configuration), any unused headers and libraries should be removed. I could write for more but basically i'd like an IDE (i haven't touched topics like VCS support and how i'd like to be able to see and use different version of the code from inside the IDE - like e.g. go back in time to a different function while the debugger is running - or anything that has to do with GUIs) that is smart and helps me get rid of all the manual drudge, (also FWIW little of the above is provided by Lazarus and i'd also like Lazarus to do all that where it makes sense but it still does more than pretty much any C IDE i've used) [0] https://lukestackwalker.sourceforge.net/ https://lukestackwalker.sourceforge.net/ [1] http://runtimeterror.com/tools/fpwprof/ http://runtimeterror.com/tools/fpwprof/
• Scarbutt 3y ago
  Docker provides an extra layer of "safety" for rogue third party packages. Better than installing those rogue packages directly to the host.
• shortrounddev2 3y ago
  I used to do that for years, and then I discovered gdb and IDE integrations with it (code blocks, codelite) and later visual studio. I have no idea why anyone would subject themselves to developing without breakpoints in 2023 other than to larp as an 80s MIT hacker
  • hot_gril 3y ago
    I started writing in C with an IDE then realized much later on that I don't really need breakpoints, I just log stuff. Whatever I'm testing often won't easily work in the debugger (or won't reproduce the bug there due to timing), and even when it does, it's not significantly easier than logging. Also, every new job I've had, I've watched my coworkers spend like a week trying to figure out how to make the IDE work with whatever environment, which then changes later... I just skip that.
    • shortrounddev2 3y ago
      Personally with visual studio and vcpkg, I never have an issues with setting up the environment. Vcpkg in particular makes it easy to note have to do manual linking, and it handles x86 vs x64 automatically as well.
    • uxp8u61q 3y ago
      Debuggers have logpoints as well as breakpoints. Learning to use a debugger grants you access to this kind of basic "log-debugging" with the option to use more advanced techniques (traditional breakpoints, break on value change, etc) at your fingertips. > Also, every new job I've had, I've watched my coworkers spend like a week trying to figure out how to make the IDE work with whatever environment, which then changes later... I just skip that. A single week to achieve better productivity? That's a sweet deal. It's about as much time as you need to figure out how the work email works, learn how to get to the cafeteria from your desk quickly, and so on. It's absurd to think that you'll be 100% productive that first week anyway, so why not use the opportunity to familiarize yourself with the tooling as well?
      • 3y ago
• tesseract 3y ago
  A big usecase for C is embedded systems projects where wrangling cross-compilers, debug dongles, etc. can become a big headache especially when trying to keep multiple developers' local toolchains in sync or when managing multiple projects with different requirements for the development environment.
  • thenickdude 3y ago
    PlatformIO is a dream for this, running build on a project automatically downloads the required toolchains for the target and orchestrates the build process for you.
  • 5ADBEEF 3y ago
    For me, it's Zephyr
    • sitzkrieg 3y ago
      im a bit of a rtos baby but (mostly in ti's really nice rtos), i'd throw my hat in for Zephyr + nordics stuff (i think?) for all the build automagic but i also think 'plain' ol (now amazon) freertos is pretty cool still
• deleted 3y ago
  [deleted]
• userbinator 3y ago
  ...or even Notepad. I write a lot of pure Win32 C, and I don't even need a Makefile for the majority of my projects because they're just compiled as a single file and quickly enough that I don't bother with anything more than necessary. IMHO the "tool fetish" that a lot of (mostly newer) programmers seem to have is an artifact of a mentality that favours complexity and novelty over simplicity and efficiency. They will waste tons of time and resources configuring and debugging (often with little understanding) huge complex monstrosities of "development environments", and end up feeling more productive, but in reality aren't. This article just further confirms what I'd already expected with the word "modern".
  • monsieurbanana 3y ago
    I'll take the notepad bit as satire. I think simplicity is underrated too, but I hope you'll agree that your single c file use case is rather niche.
    • hot_gril 3y ago
      and pure-Win32 is also niche
    • bitwize 3y ago
      I wrote my first Java code in Notepad and compiled it from command.com (as Windows 9x still called it). It was... fine, I guess? For the era? Not what I would want to do but far from unmanageable.
    • userbinator 3y ago
      For a lot of small and even medium-size C projects, one file is enough. IMHO having dozens of tiny files with only a few dozen lines each is an antipattern.
      • seabrookmx 3y ago
        How many LOC is "medium" in your view? Most devs I work with would only put a thousand lines of code in a single file (obviously subjective, depends on density, comments etc). I'd still consider that a toy app, as opposed to my medium mark at about 100k LOC. At that stage you certainly benefit from all the tooling you seem to eschew. "Large" projects (the likes of Linux and Chromium) have so much mass they tend to have fully customized build systems.
• marmakoide 3y ago
  There are small projects, hobby projects, and large industrial projects. For hobby projects in C, I am myself very happy with a shell, make, a text editor, git and valgrind. Imagine developing an embedded device for medical or aerospace hardware : you are going to provide lost of effort into testing. You are going to work with teams of people with varied abilities and experience : it's going to get a little bureaucratic, there are going to have rules and guidelines. Enforcing those with tools remove part of the friction, if done well.
  • nvy 3y ago
    Avionics code isn't written by hand any more. We (society) can't write sufficiently reliable C such that pilots and passengers can rely on it. Writing C by hand these days is hubris, in my opinion. Most avionics these days are done in Simulink, and then you hit the Autocode button.
• cushychicken 3y ago
  Docker is a godsend when you're a solo embedded consultant and a former customer comes to you five years later with an urgent firmware feature request and cash in hand. If you don't have the exact machine any more, then it's "Good luck getting the toolchain and build environment from the vendor!" Docker has saved my bacon at least twice in this manner.
  • publicmail 3y ago
    Yep. I use VMs though. I still have to build for some embedded platforms that are based on the 2.4 Linux kernel…
  • fbdab103 3y ago
    Would a five year old Docker image still work? I mean, probably, but for long term maintenance of a build environment, I would feel significantly better with a VM.
    • vidarh 3y ago
      I have Docker images older than that I use regularly. For things where kernel changes matter, sure a VM may provide better isolation, but should you ever run into problems running your older Docker images, you can easily solve that by spinning up a VM to run Docker in as a worst case fallback. Docker strikes a nice balance of ease of integration and sufficient isolation for most situations.
  • raverbashing 3y ago
    Yeah (and I agree) but it doesn't have to be docker It can be a vm, even a chroot. Also the compatibility questions and docker "opacity" come to mind. A QEMU VM sounds like a better propositions
    • cushychicken 3y ago
      I'd consider a VM, and I've used them before, but I've found Docker gives the advantage of forcing me to be thorough in my toolchain docs, and portable to CI pipelines. chroot sounds like nothing but a headache. QEMU VM, I don't even understand the potential advantage of lol
• pjmlp 3y ago
  A the macho man attitude, why are they writing C in first place. Real developers only code in Assembly with ed.
  • teddyh 3y ago
    <https://xkcd.com/378/ https://xkcd.com/378/>
• flohofwoe 3y ago
  IMHO any proposed solution (for any programming language) should also include a step-debugger that's directly integrated into the edit-compile-test workflow, otherwise people don't know what they are missing out on.