10 ms·

> These “you should switch language” remarks are strangely enough from the backseat drivers of the Internet. Those who can tell us with confidence how to run ou

• WalterBright 10y ago
  D is compatible enough with C/C++ that I have been able to take largish multifile projects and convert them one file at a time to D. The full regression suite was run after each file was converted. This helped ensure both an accurate conversion and did not leave the project in a broken state for an extended period.
  • WalterBright 10y ago
    I've successfully converted many projects from one language to another using this method. One was a huge assembler program I converted to C back in the 1980s (ironically, so it could be ported to other platforms!).
• reitanqild 10y ago
  Were do I send proposals for "comment of the month"? More seriously speaking: IMO this is solid advice. It - is actionable - goes out of its way to be polite and respectful - has a chance to actually improve online discussions one comment (and hopefully commit) at a time
  • arethuza 10y ago
    And you're own comment is delightfully self referential (or not) - so both of you have up-votes for being so reasonable! :-)
  • d0mine 10y ago
    "For every complex problem there is an answer that is clear, simple, and wrong."
• tempodox 10y ago
  Yup, I wanted to comment on the very same thing, but you did it better. Thumbs up.
• satysin 10y ago
  Bang on point. All the people who complain "oh but C is so dangerous you should rewrite in $HotNewLanguage" do nothing to actually help with their "expert" recommendation.
  • pjmlp 10y ago
    I used to program in $BoringOldTurboPascal, before C became the $HotNewLanguage in systems programming, so excuse me if I feel like I know one thing or two about C security exploits.
    • mikulas_florek 10y ago
      Isn't C 11 years older than Turbo Pascal?
      • pjmlp 10y ago
        C was a UNIX only language, it had no relevance outside UNIX in the 80's. Those of us using CP/M and other systems had access to K&R C dialects like Small C, not fully compatible with C. In those days C was just another systems programming language, looking for a spotlight. That spotlight came thanks to universities adoption of UNIX, which given AT&T prohibition to profit from it, it was sold at symbolic prices and a few AT&T researchers did provide tapes to universities. Which then started to adopt UNIX instead of paying commercial licenses for other OSes. So when workstation startups like Sun and SGI started to look for OSes, they based their software stack on UNIX. Before the widespread of UNIX out of university labs into the workstation market, C wasn't that relevant. You see the same happening nowadays with Browser == UNIX and JavaScript == C. Also C is actually 10 years younger than Algol or PL/I, both used to implement several mainframe OSes.
        • phicoh 10y ago
          I disagree that C was looking for spotlight. C was the system programming language of Unix. Many people wanted Unix, so they started programming in C, because that was the best supported language. In the late 70s, byte code interpreted Pascal was also popular on Unix because it allowed for bigger programs on the then current 16-bit systems. It's pity that Modula-3 never got much traction. I guess that's part do to Modula's overly verbose syntax. C works as long as the platform is sufficiently like Unix. For example, in the MS-DOS world with near and far pointers, programming in C becomes utterly confusing. These days, linker scripts and ELF hide a lot of stuff C cannot express.
• generic_user 10y ago
  I would also like to see these arm chair developers bootstrap a new set of compilers, operating system and tool chain with a native system interface written entirely in there super cool new languages that are going to replace C and C++. For all the talk of 'a better system programming language' and replacing C/C++ there is curiously little interest or code written to prove that any of these new languages can be used to write systems from scratch and that the language and runtime can scale across architectures. Thats before you even get to a comparison of efficacy and speed vs C/C++.
  • pjmlp 10y ago
    The problem is catching up with 40 years of history. The quality of code generated by C compilers used to be pretty lame in the 80's, any junior Assembly programmer could do better. As for ubiquity, C was a UNIX only language, with K&R C incomplete dialects available in other systems, where C was just "yet another language". It was the adoption of UNIX, an almost free ($$) with source code available, by the 80's startups for creating the workstation market (like Sun and SGI) that lead to UNIX and C's adoption in the market. Had UNIX been as expensive to get as the other OS of the time, and we wouldn't be talking about C's ubiquity and execution speed of generated code.
    • jacquesm 10y ago
      How much history can you try to rewrite in one comment? A vast amount of software in C was written for other platforms than UNIX, both SGI and SUN were companies that were focused on selling hardware rather than software. If anything the workstation market was created by companies like Xerox and commercialized by companies like Apollo. UNIX was for a long time a very expensive operating system on X86, it only became affordable with SCO/Xenix and it became free with 386BSD by Bill and Lynne Jolitz and later Linux by Linus Torvalds. C definitely wasn't a UNIX only language, it was available for an enormous range of computers from 8 bitters to top of the line machines. In fact that (and not UNIX) was a major factor in C's long time dominance.
      • pjmlp 10y ago
• oskarth 10y ago
  Hear hear! At Recurse Center this is an explicit (lightweight) social rule: NO BACK-SEAT DRIVING. If you overhear people working through a problem, you shouldn't intermittently lob advice across the room. This can lead to the "too many cooks" problem, but more important, it can be rude and disruptive to half-participate in a conversation. This isn't to say you shouldn't help, offer advice, or join conversations. On the contrary, we encourage all those things. Rather, it just means that when you want to help out or work with others, you should fully engage and not just butt in sporadically. From https://www.recurse.com/manual#sub-sec-social-rules https://www.recurse.com/manual#sub-sec-social-rules
  • generic_user 10y ago
    Its even more obtuse whey back seat drivers exclaim, we should try and stop you from doing that! Its unsafe!
  • mannykannot 10y ago
    It is unfortunate that these things have to be pointed out, but they do.
    • colechristensen 10y ago
      Why? This is a particularly hard lesson to learn and everybody has to learn it, why not write it down in places?
      • bluGill 10y ago
        Because everyone has had their own experience that they have learned from. Most people who do this are not trying to be a troll. They really have learned A lesson and want to help you by sharing. The problem is few people have the context to know all the important issues, they just know they were burned badly one time and want to save you not realizing that the solution they found has downsides that will burn the other guy.
    • MaxfordAndSons 10y ago
• Rusky 10y ago
  > Just try and re-write some parts of curl in Rust I don't doubt that some suggestions have come from backseat drivers... but I also don't believe that's relevant. First, people are implementing curl's functionality in Rust (e.g. hyper, reqwest) and it's working out well. Second, you don't have to be the one implementing something to push for improvements- in the general case, that's absurd.
  • ifdefdebug 10y ago
    > ... people are implementing curl's functionality in Rust (e.g. hyper, reqwest) and it's working out well That is good, and it's the reasonable thing to do. New tools provide the same functionality, get used where curl would have been used otherwise, and when the time is right, curl can enjoy a well-earned retirement in the hall of fame of famous ancient projects.
• muraiki 10y ago
  I think that you express a fallacy. You're saying that nobody can provide thoughtful criticism unless they take up the task themselves. So the next time you criticize politics, are you going to run for office? The next time you criticize a meal, are you going to become a chef? The next time you criticize a car, are you going to become an engineer? Yes, it's one thing to make thoughtless and uninformed criticism. But providing thoughtful and useful criticism does not necessarily require actively creating something from scratch. Otherwise, we would all only be starting new projects and never collaborating!
  • jacquesm 10y ago
    No, he's spot on. The one thing that keeps happening over-and-over again is that people who have never put together a system of any complexity will yell from the sidelines how others should build their stuff. This goes for operating systems, application software and advanced rocketry alike. The reason we have so much C code powering the world is that (1) there wasn't anything better when that code was written, (2) time has weeded out most of the bad bugs to the point that the old codebase will be substantially more stable than anything new no matter what language you would write it in. If someone is willing to throw a few hundred million or so at re-building an operating system from the ground up that is 100% safe and reliable and that does not have more bugs than what is available right now then they are free to do so. They're also free to donate their own time and to try to enlist their buddies. But they're not free to yell at others how those others should do their jobs. Show don't tell.
    • adwn 10y ago
      > (2) time has weeded out most of the bad bugs to the point that the old codebase will be substantially more stable than anything new no matter what language you would write it in. This seems to assume that the codebase is stable and in maintainance mode. However, the reality for the vast majority of open-source projects is that they're either being actively developed, adding new code and new bugs, or they're abandoned.
    • fauigerzigerk 10y ago
      >The reason we have so much C code powering the world is that (1) there wasn't anything better when that code was written... Right, but the criticism he received for his first post was not primarily about choosing the wrong language or about refusing to rewrite in a different language now. It was primarily about downplaying the role of C in the security issues that were found. The rest of the debate, at least as I read it, was not so much criticism as it was a generic debate about the pros and cons of various programming languages like we're having one every other day on here and on reddit. Choosing C back then was clearly justified for a project like curl given all the constraints and considerations. And for a rewrite to be a net positive in terms of security probably takes years, not to mention the huge effort that someone would have to put into it.
• z3t4 10y ago
  You only get these kind of advices, not when you need them, but when your project is successful ... Everyone want to help a successful project. But while struggling, you get very little help.
• mannykannot 10y ago
  There is a certain type of person (I once fit the mold) who thinks new languages could significantly improve software development. The evidence is to the contrary, and many improvements turn out to be double-edged swords, capable of doing damage in the wrong hands. I am still interested in new languages, but I am no longer looking for the holy grail.
  • drvdevd 10y ago
    I've actually grown extremely bored of programming language debates and yet continue to be fascinated with the act of programming. Each language has something new to offer and also some limitation(s). Why not try them all? I believe opening our minds will be the only way to achieve meaningful improvement in software development. I also believe this is easier said than done.
• JoachimS 10y ago
  I suggested cRUST as name
• kbenson 10y ago
  For any sizable project in the public, I think switching languages is never the right choice. That is at best confusing for people, and at worst kills the project. The right way to replace a library or application is to build something better. If it matters, possibly with the same, or a close enough API. This is the only thing I've seen work in the past.