back to article Dropbox would rather write code twice than try to make C++ work on both iOS and Android

Dropbox has abandoned a longstanding technical strategy of sharing C++ code between its applications for iOS and Android, saying the overhead of writing code twice is less than the cost of making code-sharing work. The online storage outfit formed the previous strategy in 2013 to enable a small team to ship code quickly. It …

  1. karlkarl Silver badge

    To be fair, if Apple stopped wasting time with Swift on iOS and moved to C++ and Google / Android stopped wasting time flittering between Java and Kotlin and just made C++ first class *everyone* could stop messing about and keep to C++ for everything.

    Chuck Microsoft's Cee-Sharp crud into the mix; it seems like mobile OS vendors want to simply use anything *but* the correct language for the job.

    Possibly a mix of vendor lockin, a mix of making it easier for complete amateur developers and just bad choices all round.

    The article is right though. Senior developers do not want to waste their skills and life faffing with broken mobile platforms. They have the experience to say "no thanks!".

    1. Anonymous Coward
      Anonymous Coward

      Before Swift, Apple was (and still is somewhat) very heavily invested in ObjC. I don't see them moving from ObjC to C++ any time soon.

      1. karlkarl Silver badge

        "Before Swift, Apple was (and still is somewhat) very heavily invested in ObjC. I don't see them moving from ObjC to C++ any time soon."

        This is a slightly different topic but yes I agree to an extent. I predict that Apple will lose interest in Swift and move back to Objective-C. Then to integrate with the rest of the world they will put more focus into Objective-C++ and go from there.

        You heard it here first folks ;)

      2. OnlyMortal

        You can mix Objective C and C++. No C glue needed.

        1. teknopaul

          Trying to write C++ interfacing to Androids java api is clearly a pretty wierd mobile strategy. No wonder they dropped it. No help from the open source community? Perhaps no one else was doing that.

    2. bazza Silver badge


      One day we’ll all be coding Rust...

      1. DrXym

        Re: Rust

        Rust would face many of the same issues as C++. It would be fine while doing its own thing but the moment you want to put up a GUI, or call some service on the phone then you're in the same boat as every language unblessed by the platform holder.

    3. Kevin McMurtrie Silver badge

      C++ and Android don't mix well because there are so many chipsets. Each one has different features, different strengths and weaknesses, and different lists of bugs. You're essentially compiling once for every phone. Kotlin/Java are compiled on demand. (Not sure if Android has all the tricks of a desktop/server JIT.)

      The one thing that, for me, holds back Java performance is the lack of contiguous data structures. You end up with hacks like using one array per field or manually interleaving and typecasting fields in one array. This would probably very difficult to fix in a GC language, but it sure would make it easier for JVMs to perform complex calculations usually reserved for C/C++.

      1. lambdacalculus

        Yeah, that's easy problem to solve. You just get your C++ compiler to output directly to JVM or .net bytecode(s) and you can use all the standard Android APIs then.

    4. J27

      High level GC languages increase productivity, even fantastic C++ support isn't going to change that. The vast majority of apps are written on a tight budget and performance just has to be "good enough".

      You don't seem very clued-in to current mobile dev trends, if anything we're headed to even more levels of abstraction and build once run everywhere platforms like Google's Flutter (but maybe not actually Flutter).

      1. Bronek Kozicki

        The GC that these high level languages use is typically implemented in C++. It is just that, at this moment, the only common GC framework that is available in C++ is based on smart pointers, while some people just feel utterly unable to abandon raw pointers.

        1. Rich 2 Silver badge

          But there are very good reasons why most C++ peeps don't want/use GC.

          C++ has very good features for handling resources in a consistent and deterministic way; something no current GC (as far as I am aware) is capable of

      2. Anonymous Coward
        Anonymous Coward

        High level GC languages increase productivity

        That's a myth created by the language companies. Actually, managers think that's a way to sandbox developers so they can hire cheaper ones, while spending less on tools.

        In return all we got worse, slower and more bloated applications.

        It is true today people attempt to invent a new language every day, still all relevant stuff is written in 'older' languages, because often abstractions just get in the way as they are too often designed to solve a particular problem only and are far from being versatile.

        1. Ian Joyner Bronze badge

          Re: High level GC languages increase productivity

          "That's a myth created by the language companies."

          The premise is complete nonsense.

          "abstractions just get in the way"

          Not complete nonsense – some abstractions are just wrong. But abstraction as a whole is the basis for all computing.

          1. horse of a different color

            Re: High level GC languages increase productivity

            You sound like a shill for Big Language!

            1. Ian Joyner Bronze badge

              Re: High level GC languages increase productivity

              I object to being called shill. And 'big language' you completely misunderstand what I'm saying. I'm saying C++ is such a big language and we should replace it with small, powerful and to-the-point languages.

              Read this paper for John Backus' comments on fat and flabby but weak languages:


              1. CrazyOldCatMan Silver badge

                Re: High level GC languages increase productivity

                I object to being called shill

                That'll be a hurricane-force *whoosh* then..

              2. horse of a different color

                Re: High level GC languages increase productivity

                In fairness, I was being facetious and not serious. :)

      3. hoagy_ytfc

        I realise you may have been making a more general point, but FWIW neither Swift nor ObjectiveC have garbage collection.

        ObjC _did_ have it for a while, but I'm pretty sure it's long gone.

        1. Kristian Walsh Silver badge

          "... You alloc, then init, then add to a pool. Simple, yeah?"

          Ugh. I'd forgotten about autorelease pools until you posted. Another bad memory from my days writing ObjC code.

          To be honest, as all of my, few, Cocoa apps were actually written in C++, not C, I think one of the first things I did was to make a std::auto_ptr<> concrete type that handled all that nonsense for me.

    5. gnasher729 Silver badge

      Well, I don't know about Kotlin, but Swift is _way_ ahead of C++ as far as writing efficient, compact code that your average mid-level developer can understand is concerned. So Swift is absolutely _not_ wasting time.

      1. DrXym

        Swift is a terse language but it is conspicuously not cross platform. Same for Kotlin too.

        But I assume DropBox went into this choosing C++ because they hoped that they could code 80% of the app in a portable fashion using C++ and use abstractions to interact with the platform.

        1. Daniel Pfeiffer

          Kotlin/Native targets iPhone


          Kotlin/Native is primarily designed to allow compilation for platforms where virtual machines are not desirable or possible, for example, embedded devices or iOS.

          the compiler creates: an Apple framework for Swift and Objective-C projects

          It's currently in Beta stage.

        2. CrazyOldCatMan Silver badge

          but it is conspicuously not cross platform

          So - MacOS, Linux and (via openswift) Windows isn't cross-platform? You can also use Swift on Android but (needless to say) Google conspicuously won't help you and it's not full-featured yet.

      2. Rich 2 Silver badge

        "...Swift is _way_ ahead of C++ as far as writing efficient, compact code..."

        I hesitate to say this, but that's nonsense. C++ compiles down to very efficient and very compact code. If it doesn't then you're doing something wrong. There is nothing inherently more efficient about Swift that makes it better in either respect.

        In fact, in general, unless you have specific hardware support for some whizz-bang feature that boosts performance by a notable margin, C (and by extension C++) is pretty much as efficient as it gets. There are other languages that are as efficient, but significantly (if at all) MORE efficient? I think not.

        1. flibble

          The qualifiers in the original sentence are I believe important; it's not that Swift generates more efficient, compact code than C++, it's that it's far easier to do so in Swift and that Swift has far fewer ways for junior to mid-level devs to shoot themselves in the foot. Swift I believe also has a much richer set of standard libraries than C++, which removes lots of need for pulling in third party code - e.g. Swift has a built in for handling URLs, I'm pretty sure C++ still doesn't.

          If you're writing high frequency trading code, C++ is definitely where it's at. If you're writing run of the mill mobile apps, you'll get far more done with fewer bugs using Swift. Automatic reference counting is a massive improvement manual memory management - less code and less bugs, and wins over GC on performance, peaks, efficiency, etc.

          Even on mobile, there are cases where C++ makes sense. It's all about using the right tool for the right job. The original article from Dropbox makes a number of very good points.

          (Aside: I'm unsure if by 'compact' the OP meant 'small compiled binary' or 'without unnecessary boiler plate in the source code'.)

          1. Tom 7

            I think this is more about 'I know how to do it in Swift, I dont know how to do it in C++' rather than one language being better than the other. Automating reference counting pops up in Boost as does URL handling. I dread to think what the internals of a language look like when things that are better provided by libraries are actually dragged into the language, Or rather I do - I've seen many languages try this over the years and to no benefit.

            Having said that I've yet to find a use for Dropbox that doesnt set alarms ringing and would never ever use it in a business unless a gun was pointed at my pay-check.

    6. DrXym

      Yes but that would make too much sense. Each of these mobile platforms wants to be a silo and they want it to be very inconvenient for devs to be agnostic across platforms.

    7. JLV

      There we go again with Mr My Language Uber Alles

      It was tedious when it was the COBOL guys 30 years ago. Tedious when Java’s AbstractStrategyFactory roamed the land. And it certainly is tedious in 2019 where a number of languages are available, one of which C++, is rightly, quite appreciated for many purposes: system, device and game programming and indeed anywhere where performance is critical.

      Are you saying a Todo app in iOS ought to be written in C++? Why? Speed optimization? What about a website (not a web server)? C++ to marshal tons of character pointers into html? A database batch processing program? Non-perf critical business logic code? And, no don’t yap on about “just iOS and Android”, this is a general question because you’ve stated before all the rest of us are hobbyists for not using your particular type of hammer to put in our screws.

      Can elaborate your reasoning on this? How are you going to address the skill gap where a moderately skilled programmer, not a deity like yourself of course, can write program X in any number of high level GC languages but would struggle to do it securely in C++?

      Anyone _else_ who likes and codes well in C++, respect and no dissing intended. Having mastered a hard language most assuredly need not turn everyone into a twat.

      1. karlkarl Silver badge

        "Anyone _else_ who likes and codes well in C++, respect and no dissing intended. Having mastered a hard language most assuredly need not turn everyone into a twat."

        But that's just the thing, C++ isn't hard, you just need to not waste time faffing with other languages.

        The old fashioned view that C++ is "for advanced tasks only" is such a cliche. Rust is actually proof of that; Rust is extremely popular (even with amateurs) for Web, embedded, desktop and if you look at Rust's technology and memory management system; compare it with modern C++ (i.e smart pointers); you will realize not only does it compile down to mostly the exact same binary; it is almost written in exactly the same way.

        1. JLV

          Nice how you skipped my actual questions and yapped about the one part in my post that _really_ wasn’t addressed to you.

          Alright, let’s make it more clear. This site, El Reg, is, IIRC, written in PHP. Not my preferred language, no, but an eminently sensible choice for this type of site.

          I ain’t talking about the web server itself - I do prefer nginx over Apache, partly beause its C++, not Java. No I mean the CMS part.

          Should El Reg have been written in C++ instead? What benefits would that bring, besides performance? - which is perfectly adequate as is btw. How would a C++ core affect the average hourly pay rate of whoever was working on it and overall dev and maintenance costs? In your big bag of claims, what would be the concrete gains from C++ here?

          1. ratfox

            Alright, let’s make it more clear. This site, El Reg, is, IIRC, written in PHP

            You are mistaken! It is written in Perl. Not sure if that is better or worse than PHP. For sure, PHP is a terrible language, but... I mean... Perl?

            1. diodesign (Written by Reg staff) Silver badge

              "It is written in Perl"

              Indeed it is. And it's very nice Perl. Our tools are listed here:



              1. JLV

                Re: "It is written in Perl"

                Agh. One of your devs said something _pretty darn clever_ in the context of your framework a while back, say 4-8 months. Thought it was about PHP but El Reg’s been around the block, so PERL makes sense.

                1. CrazyOldCatMan Silver badge

                  Re: "It is written in Perl"

                  El Reg’s been around the block

                  Which is a polite way of saying "but you're *old*" :-)

                  (AKA - it's not the age, it's the mileage.).

              2. 404

                Re: "It is written in Perl"

                > and it's a very nice Perl'

                hehe... love that...

        2. Bronek Kozicki

          Nope, C++ *is* hard; to say otherwise is only an indication where you are on the Dunning-Kruger curve. It is also a great language, but not as general purpose as I wished it was. A good programmer should be able to code in few languages, and choose the tool for the job.

          1. CrazyOldCatMan Silver badge

            A good programmer should be able to code in few languages, and choose the tool for the job

            Same is true of deciding which OS to use..

        3. Ian Joyner Bronze badge

          Karlkarl: "But that's just the thing, C++ isn't hard, you just need to not waste time faffing with other languages."

          That is exactly why programmers should learn other languages. C++ makes things inordinately difficult. Every workplace will have different style guidelines of what to use or not use depending on their understanding.

          Even for languages that were perfect and simple I'd still say learn another language. But if the languages are simple that will be easy to do.

          Of course if they not simple like C++ there will be a lot of resistance to doing that – just as karlkarl does.

    8. DJV Silver badge

      Brainfuck FTW!

    9. Anonymous Coward
      Anonymous Coward

      It reminds me of a letter published once by Computer Weekly from an IT manager saying that if everybody just stopped messing around with all these other systems and used Windows and Office, life would be so much simpler.

      It might be worth reading Umberto Eco's book The search for the perfect language which describes the attempts over many years to invent or rediscover a perfect language which would replace all those messy ones that make communication so difficult. All, of course, ended in failure.

      1. John Sager

        Going a bit further OT into the field of human languages, the book "In the Land of Invented Languages" by Arika Okrent is a good read.

        1. This post has been deleted by its author

        2. Caltharian

          I have not read the book however i remember reading a lot of years ago that there were more speakers of Klingon in the world than Esperanto

    10. Anonymous Coward
      Anonymous Coward

      <strike>Spyware</strike>Cloud Code

      Yea, but the Dropbox app isn't that complicated, give the file, communication & encryption API's on both platforms. It's the spyware code that's hard to maintain...

    11. Ian Joyner Bronze badge

      C++ the right answer to the wrong question

      "To be fair, if Apple stopped wasting time with Swift on iOS and moved to C++" says karlkarl.

      You are right C++ is the right answer, but to the wrong question.

      C++ is heavily based on a bad system language C with all its flaws.

      It is C++ that has wasted nearly 40 years now trying to fix the problems with C and introduce a bad implementation of OO with its horrible versions of multiple inheritance and generics (templates).

      As the obvious C++ zealot that karlkarl obviously is, it is not C++ that is broken, it is the platforms.

      Actually, most platforms are only broken in the sense that they support C and C++. A good platform would reject these languages and most programs in them would cease to work (at least without a good deal of modification and bug fixing).

      This is because such devices as pointers and the ++ operator (after which C++ is named) are the right answers to the wrong question. The right answer in small off-the-network systems that don't require correctness and security.

      C and C++ are not the right answer in today's highly-connected and security sensitive environments and have cost the world trillions of dollars in data breaches and attacks.

      Good security is based on languages that respect memory boundaries (no out-of-bound indexing, buffer overflows, etc). C and C++ cheat the industry of good security. There are many other reasons to move away from these languages.

      It is time to move past languages like C and C++ and the weak CPU architectures they are based on.

      (I'm not enamoured of the fact that Swift, C#, and Kotlin try to look something like C either. The continued use of () to call a (misnamed) function breaks the uniform access principle Or that it uses the mathematically universally accepted equality symbol '=' to mean something as completely different as assignment ':=' and this then has to be explained to learners to be careful. Silly perpetuation of the mistakes of C.)

      1. swm

        Re: C++ the right answer to the wrong question

        Then there was a guy at Franz Lisp who got tired of all of the security patches to ftp. So in less than a day he rewrote the server in lisp and ended all of the problems.

    12. Ian Joyner Bronze badge

      Another point in addition to my long comment on karlkarl's nonsense is that when Apple changed MacApp from a nice language (that they developed in conjunction with a real language designer – Niklaus Wirth) Object Pascal to C++, MacApp descended into the C++ mess and mire.

      They are wise to develop their own language in Swift. In fact, vendor languages seem to be very useful – they program the platform directly without descending to hardware level.

    13. deftelf

      Ah, the old arrogant 'rockstar' programmer bullshit, complete with pushing the one true language for all situations, and decrying anyone who doesn't want to use their preferred tools as amateurs, and implying that nobody working on mobile is 'senior'. Well done sir you've laid out all your prejudices very efficiently!

      Very obvious that this programmer has never worked in mobile, but has lots of opinions about it.

      1. anonanonanon

        Being so dismissive of a platform in excess of a billion devices seems rather short sighted too, but nothing less than I expect from some devs. Of course some of that success comes from deliberately disallowing devs to have free reign to do whatever they want in favour of a consistent user experience, security and power management.

  2. werdsmith Silver badge

    I think there is a good case for Qt here. It's very strong now and uses C++.

    1. Anonymous Coward
      Anonymous Coward

      QT won't help with the low-level stuff.

    2. anonanonanon

      QT still has a long way to go on mobile, and trying to stop cpp developers designing their mobile apps like it's a desktop is a pain.

  3. BrownishMonstr

    Electron. Obvo. Written by gods. Like Slack desktop app is so reliable and never asks me to refresh ten times in a row, then immediately requiring a forced restart because even that doesn't work. That never happens to me. It's awesome.

    Being serious, Web apps are the way forward. Stuck in the nostalgic 90's and imitates desktop development with the plethora of frameworks. Super fun to debug too. I ❤️ stateless Web apps.

    1. Tim Almond

      App Store

      I looked into apps a few years ago and walked away from it. It wasn't the development side but the ecosystem, particularly the Apple app store. The costs of an annual license, having to own a Mac, and a recent Mac to upload to the store, how it has to be reviewed before a change goes up, have to use their ad service, they can reject it because of how it looks or behaves. They've even interfered to stop people making off-the-shelf templated apps or code generators.

      The Play store was much more reasonable, but if I'm going to be doing one, I'd really have to do both. It's not even just the cost of buying that stuff, it's that it's deliberate pain by Apple, and that gets my back up. Coming from the world of the web, where it's a whole load of open standards and you use what you want to use to do what you want to do, it feels like a backward step.

      It's why web apps and PWAs are the real future. Cross-platform, open standards. The devices are fast enough to do some pretty sophisticated stuff with a browser. Chrome is adding more and more stuff that can be accessed via Javascript, so you don't need an app to get NFC.

      1. anonanonanon

        Re: App Store

        I'm mostly in favour of the more rigourous process of the app store. It prevents shovelware, spyware, copycats (to some extent), poor security management, "clever" hacks that play havoc with people devices and generally promotes the ideal that apps should be useable and good.

        It's quite clear why Apple do it, although it may be an inconvenience, an app store flooded with terrible apps just puts users off the product as a whole. This policing provides trust for the user that downloading an app won't do anything unexpected.

        While you may feel inconvenienced by it, the software industry as a whole has proved time and time again it will do anything it can to shovel crap to users. Apple try to limit that.

  4. Richard 12 Silver badge

    Dropbox failed the "not invented here" test

    There are several commercial and open source cross-platform C++ frameworks that support iOS and Android.

    Yet they refused to use any of them, instead choosing to write their own. That is a lot of work, which is why everyone else buys it in.

    None of them are perfect, but they solve 99% of the problems, so only have to deal with your specific edge cases.

    Qt has a simply massive user base, so chances are someone has already solved your edges anyway.

    Yet, instead of buying in that cross-platform framework and slowly porting their existing C++ over to it, they've decided to effectively re-write from scratch not just once, but twice!

    It seem with a completely new team too. Oh boy.

    I guess those who remember Netscape are doomed to watch others repeat it.

    1. pavel.petrman

      Re: Dropbox failed the "not invented here" test

      Maybe they just fiugured that Qt commercial license, costing several thousand (Pounds/Euro/Dollar) per seat, isn't a justified expense when you can have the LGPL options which is basically the same except for some tiny OS-specific bits. Yeah, right. The folks at Qt know what they get paid for and we, mere mortals, don't get to hear all their success stories. What we do get to hear are stories like this, happening at every other dev workplace every other week, where the thousands scare the managers as they would need to go from the department budget and not the HR/personnel budget. I have fond understanding for those poor souls mocked for their decision, as I have had my numerous times at the cost optimal end of the budget whip as well.

    2. anonanonanon

      Re: Dropbox failed the "not invented here" test

      QT may have a massive user base, but not so much on mobile, which seems poorly supported

    3. Fibbles

      Re: Dropbox failed the "not invented here" test

      Qt aside, I'm at a loss as to why they wrote their own serialisation code and a JSON parser. There are umpteen open source libraries with permissive licences that can already do those tasks. Some of them are even small header-only affairs.

  5. MrBanana

    What the hell is C++, Java, C# and the other drivel?

    Looks like something that girls would use. Proper blokes use assembler. That would solve their problems.

    1. Anonymous Coward
      Anonymous Coward

      Re: What the hell is C++, Java, C# and the other drivel?

      I wouldn't want to be in the room if you called Rear Admiral Grace Hopper a "girl" to her face (you might end up stapled to a punch card like the original bug) but yes, a woman was responsible for the first practical high level language.

      1. MrBanana

        Re: What the hell is C++, Java, C# and the other drivel?

        "the first practical high level language."

        So FORTRAN (1957 for the first complier implementation) and ALGOL (1958) were not practical, or not high level? Compared to the horror* of COBOL (1960).

        * It is the only language that I have have failed to write the simplest "Hello World" demo program by looking only at the published grammar.

        1. Anonymous Coward
          Anonymous Coward

          Re: What the hell is C++, Java, C# and the other drivel?

          Bad phraseology on my part, I admit. For "practical" read "commercial".

          Early Algol and Fortran were/are basically scientific languages, COBOL was practical in the sense that it was widely adopted for business and financial use.

          You may not have got on with it, but an awful lot of COBOL has stood the test of time very well. And, given its typical uses, it was hardly the language you wanted someone trying to write from the grammar only. Many languages suck, but none of them suck like a program written by someone who thinks he (it's going to be he) is so 1337* that he can learn any program from the spec and be let loose on enterprise code**.

          *I know 1337 is obsolete.

          **If you don't know what "enterprise code" means, you have never had to write any.

          1. MrBanana

            Re: What the hell is C++, Java, C# and the other drivel?

            Congratulations on winning this month's Specsavers award. For me writing 'simplest "Hello World" demo program', and you reading 'enterprise code'. And yes, I do know the difference.

        2. swm

          Re: What the hell is C++, Java, C# and the other drivel?

          Algol 60 had no IO so no "hello world". FORTRAN I was a high-level assembler for the IBM 704 (DO loops modelled the loop instructions, size of integers modelled the size of the 3 index registers etc.). People wouldn't use it if the code it produced was slower than assembly. COBOL wasn't so bad considering when it was introduced.

          1. MrBanana

            Re: What the hell is C++, Java, C# and the other drivel?

            It is not true that ALGOL 60 had no IO - it just lacked a consistent mechanism across different implementations. So no single "Hello World" program could be compiled on all the different variants.

            I used later versions, so I am not that familiar with FORTRAN I. But even the Wikipedia entry indicates that, although FORTRAN I was close to the IBM 704 assembler, some things like the IF statement was not a direct equivalent of the CAS – Compare Accumulator with Storage instruction. Also the FREQUENCY statement could be used to give runtime weightings to the brach operator - that's way more high level in language terms than a simple assembler.

      2. Dagg Silver badge

        Re: What the hell is C++, Java, C# and the other drivel?

        Strictly speaking COBOL was more of a macro assembler


        LOAD A

        ADD B

        STORE C

    2. Boris the Cockroach Silver badge

      Re: What the hell is C++, Java, C# and the other drivel?

      Assembler? you wimp

      Real programmers know the machine codes ops and program in that

      So stick that in your stack and (Z80)201 it

      Then there are the crazies who do binary.. ...

      1. Neil Barnes Silver badge

        Re: What the hell is C++, Java, C# and the other drivel?

        Pah. *Real* programmers simply arrange the starting conditions of the universe such that when they need a program, it is already there.

        1. Charlie Clark Silver badge

          Re: What the hell is C++, Java, C# and the other drivel?

          Have a pint for such a great comment.

      2. Anonymous Coward
        Anonymous Coward

        Re: What the hell is C++, Java, C# and the other drivel?

        One of the best (i.e. worst) bugs I ever found was in an embedded application using EPROM. There was a debugger in it which had been borrowed direct from someone else's code for which there was no assembler source.

        The genius programmer decided to incorporate the code with just a few mods to fix entry and exit pooints. He was one of those people who boasted that he could work out opcodes. And he almost could.

        There was at one point a jump in the debugger (at the bottom of EPROM) back into the running program which was from the top downwards.

        Unfortunately it actually jumped into unprogrammed EPROM between the end of the debugger and the start of the program. Which was of course filled with FFFF. Which just happened to be a valid opcode that corrupted RAM based on the content of a register.

      3. Anonymous Coward
        Anonymous Coward

        Re: What the hell is C++, Java, C# and the other drivel?

        *Real* programmers have a workplace environment where “Software” is written in a French department and “Hardware” (ASICs and FPGAs) in the U.K. When the U.K. bods want to make a unit microcontroller, they hook up a PROM *without a CPU*, with some data output lines fed back to the address lines. It’s a massive state machine / Turing machine bastard child. They aren’t “writing software”, so they are allowed to do it in the U.K.

        Figuring out the binary contents of the PROM to get the desired output and state behaviour is obviously hard, so they’ve written themselves a spreadsheet in Excel to help them. This allows them to avoid installing any software development tools on their PCs, which would be against company policy. The spreadsheet has man-years of development effort embedded in it, used in half a dozen major projects.

        The declared justification is that this not-software is required for high reliability aerospace application! “Software” is allegedly too unreliable, too bug-prone, and too expensive to verify. And that being without RAM reduces vulnerability to radiation-induced bitflips

        The general conclusion I draw depends on my daily level of cynicism....

        a) For every crazy language, there really is some application where it is the best tool for the job, for some interpretation of “best”.

        b) The best tool for the job is the one that the team already understands and uses.

        c) The team leader selects tools based on which one improves their CV, and allows them to keep their job. There may well be an optimum technical choice, but it’s irrelevant.

        1. Anonymous Coward
          Anonymous Coward

          Re: What the hell is C++, Java, C# and the other drivel?

          I am delighted to read this because I was once faced with designing a very small safety critical system for a manufacturing process. Get it wrong and an operator could punch a hole in herself.

          The company had a "maintenance department" which reckoned it knew more about software than any of those engineers. Using a PLC would have meant that at some point one of them would have spotted what looked like a clever speed up but in reality would create a severe hazard. And would have done it, hoping for a bonus.

          Connecting the inputs and outputs to a suitable FPGA and creating a carefully designed state machine was the right answer. Anything goes wrong, use on of the spare FPGAs. Want to change the program? Even if you had the tools and could understand them, we've blown the fuses.

          1. swm

            Re: What the hell is C++, Java, C# and the other drivel?

            Some early PROMS would intermittently misread a bit. Required a logic analyser to catch the occasionally failing bit.

      4. swm

        Re: What the hell is C++, Java, C# and the other drivel?

        If you have never programmed from the switches you aren't a REAL programmer.

    3. Ian Joyner Bronze badge

      Re: What the hell is C++, Java, C# and the other drivel?

      "Proper blokes use assembler."

      I take this as a humorous comment – women program as well.

      Real programmers provide a layer above which higher layers don't need to be concerned about lower layers.

      That C and C++ people insist that these system languages (which provide leaky layers in themselves) is an admission by system programmers that they have failed in their job.

    4. Anonymous Coward
      Anonymous Coward

      Re: What the hell is C++, Java, C# and the other drivel?

      REAL girls code in 6502 machine code. So nerr! :-}

      1. jeffdyer

        Re: What the hell is C++, Java, C# and the other drivel?

        I went through a phase of programming my C64 by putting the code in BASIC DATA statements containing 6502 op codes read from the Programmers Reference Guide. Then calling SYS 1024 or whatever to run the program.

        Certainly made you press Rec/Play on the tape more regularly.

        1. werdsmith Silver badge

          Re: What the hell is C++, Java, C# and the other drivel?

          I once wrote code that changed itself on the fly, by storing new operand values in memory where the program lived.

          I thought I'd done the smartest thing ever until my college tutor saw it.

          1. JulieM Silver badge

            Re: What the hell is C++, Java, C# and the other drivel?

            That was how a lot of programming used to be done, in the days of magnetic core memory and before index registers.

            1. Anonymous Coward
              Anonymous Coward

              Re: What the hell is C++, Java, C# and the other drivel?

              PDP-8s required it because standard practice was to store subroutine return address in the location immediately before the subroutine. Also, the PDP-8 had instructions that saved time by leaving the memory location cleared, so it was not necessary to rewrite the read value back into core.

              I actually liked the PDP-8, it made you feel that you actually understood what was going on right down to the gate level.

      2. OnlyMortal

        Re: What the hell is C++, Java, C# and the other drivel?

        Rich BBC owner? 6510 ftw

      3. CrazyOldCatMan Silver badge

        Re: What the hell is C++, Java, C# and the other drivel?


        *Shudder*. SCMP[1] 4-bit is VASTLY SUPERIOR and SHOULD be used in EVERY situation!

        (Sorry - channelling BB seems to have got away with me.)

        [1] I think that's what it was called - a little Cambridge Scientific self-build board in the mid-1970's with a 6-digit output display and (I think) 256 bytes of RAM. When we replaced it with a Nascom-1 (Z80) we thought it a big upgrade since it had 1K of RAM - and then we bought a 4K expansion card that was the same size as the original motherboard. And it even had a (300-baud?) tape interface!

        1. Neil Barnes Silver badge

          Re: What the hell is C++, Java, C# and the other drivel?

          Might that board be a Sinclair MK14? There's a chap in Czechoslovakia will sell you a new board and bits - I'm currently negotiating some new proms. Enormous things; 512x4bits...

    5. CrazyOldCatMan Silver badge

      Re: What the hell is C++, Java, C# and the other drivel?

      Proper blokes use assembler

      Pah! Assembler is for the weak! *Proper* warriors directly flip the individual bits with their minds to produce code!

  6. Anonymous Coward
    Anonymous Coward


    Surely the likes of Xamarin, Mono, etc make porting C# pretty simple between platforms? Okay, the UI handling might need a bit of tweaking here and there but the backend code should be portable. Plus no Corporate Use license worries as with Java, and with a bit of messing with the interop features you can use existing C/C++ code.

    It's a file transfer system, not a game engine or huge distributed AI cluster. Surely there are a multitude of languages and libraries out there for them to use?!

    Between this and the other suggestions, it sounds a lot like someone's come in and wants to show off their Nerd credentials rather than looking at the right tool for the job...

    1. karlkarl Silver badge

      Re: C#

      "Surely the likes of Xamarin, Mono, etc make porting C# pretty simple between platforms?"

      Hopefully dropbox has a bit more foresight; porting the .NET VM to different architectures is an extremely difficult task. If you write your code in Cee-Sharp; you will need to wait for the bloat to get ported and then you have lost all the big bucks!

      Stay light; stay portable; C++ is often horrific but it is the best we got.

      1. StaudN

        Re: C#

        "porting the .NET VM".... yeah, you are clearly qualified to comment.

      2. Ian Joyner Bronze badge

        Re: C#

        "Stay light; stay portable; C++ is often horrific but it is the best we got."

        C++ is hardly light. If it's the best we've got heaven help us. Fortunately, Karl's assertion is not true.

    2. Sil

      Re: C#

      Xamarin looks like a much better idea than Swift+Kotlin.

      You can use all native calls, you can share code, develop on Windows or Mac, and you can automate testing on a very grand scale.

    3. AndrueC Silver badge

      Re: C#

      We're using Xamarin to target Windows (WPF) and iOS / Mobile. It was a bit rough when we started a couple of years ago but is pretty good now. Build times for iOS are irritating (might be our fault for using Mac minis) and the debugging experience isn't always as polished or feature-rich as Windows (you can forget edit and continue and sometimes evaluations aren't as detailed) but we're all managing to jump between the three target platforms without issues or mostly can just ignore that by working on common code.

      I'd estimate that 90% of our code base is shared with just a handful of platform specific stuff like audio handling and a few view model service classes where pages/views have a lightweight platform specific view model that calls down to the common service.

      There are a few differences in the XAML between WPF and Xamarin but nothing of any real significance. If you're already familiar with WPF the only things you need to learn are how a mobile app differs from a desktop application and that's always going to be a concern if your team is doing cross-platform development.

  7. Dan 55 Silver badge

    Agile project management failure

    Must develop a new framework because something like Qt is NIH, keep running into platform-specific problems with the home-brewed framework as new features are added on-the-fly to the app and the framework doesn't cover those cases, and finally deciding this means they are unable to share common code between two platforms. This looks like Agile to me.

    1. Charlie Clark Silver badge

      Re: Agile project management failure

      I don't know if that's really the case here. It's not really about the GUI side of things, where QT excels, but the low-level system stuff. Plus, the blog article makes it clear: they're having trouble finding people with the C++ skills to maintain what they already have. While we might bemoan this as yet more evidence of decadence in the IT industry, that won't change the associated risks. Switching to the platforms' preferred languages at least makes this someone else's probem.

  8. Will Godfrey Silver badge


    1. Anonymous Coward
      Anonymous Coward

      Re: Obligatory...

      Isn't this the opposite?

      They tried to create a new common framework but ended up going back to the platform-specific standard to enjoy all the features of each platform dropping standard n+1?

      My suspicion is that the key feature of the platform-specific frameworks is that they have less issues during (frequent) platform upgrades.

  9. Anonymous Coward
    Anonymous Coward

    Amateurs :)

    Our entire core technology stack (cross platform video player) is written in C++.

    We have a C-based API to expose functionality to the world and then platform specific wrappers that implement UI and provide a few minor services to the core layer (although most of those have finally been moved into C++ now, and a lot of our UI processing is in C++ too).

    We have a Swift wrapper on iOS/ipadOS, macOS, and tvOS, a Kotlin wrapper on Android, a C# wrapper for Unity, and a ReactNative wrapper for whatever the fuck that is for. :) We also have a few others in the works that will be made available as and when they're ready.

    For rendering, we use Metal on Apple platforms and OpenGL on Android. I'm slowly getting a DirectX renderer up and running on Windows (currently that's using OpenGL), and I'll work on a Vulkan port sometime after that.

    When I started working at the company they were using Uno by Fuse Tools as their cross platform solution. A platform which, at the time, lacked quite a few features that we knew we would need at some point. I basically rewrote our core technology in C++ as a side project, we switched over a few months later, and haven't looked back.

    If anyone's interested, our player is available at </shamelessplug> ;)

    1. Aitor 1

      Re: Amateurs :)

      So your player is crap on ATI/AMD cards?

      Anyway, congrats for running something so crossplatform

      1. Anonymous Coward
        Anonymous Coward

        Re: Amateurs :)

        Our primary focus is mobile. Our desktop players are mostly used for development purposes at the moment. :)

        That said, on mobile we out-perform the standard platform players (AVPlayer and ExoPlayer) on both processor usage and power consumption when playing at 1x. The user scrubbing video in realtime does come at a cost though, obviously. ;)

    2. JLV

      Re: Amateurs :)

      Hey, I upvoted you, because it makes sense, but... look at the likelyDropbox concerns:

      - network

      - file system

      - presentation GUI - you need OS widgets here btw, not a video canvas.

      - Dropbox biz/functional logic, a good of which probably resides server-side.

      Of those, only #4 isn’t “tainted” by close platform coupling. So, what works in your case - having thin wrappers around an agnostic core, may be less relevant to an app whose component are by nature mostly engaged in talking to the platform services.

      1. Anonymous Coward
        Anonymous Coward

        Re: Amateurs :)

        All valid concerns. :)

        For networking, we use libcurl on most platforms and emscripten in our (WIP) WebASM port. Our primary focus is streaming anyway. There's very little need for local file support from our customers who are interested in HLS and MPEG-Dash more than anything else. (We support both streaming specifications on all platforms as well as MP4 and MKV files either locally or remotely.)

        File system abstraction is fairly simple. We have a few simple classes that provide a consistent API internally for each platform. We do have other levels of abstraction in there for hardware/OS specifics too, of course - the most obvious being video/audio decoder/encoder access. We can't do everything in vanilla C++, but what is there is fairly well separated and a small percentage of the overall code base.

        UI is mostly happening in our platform specific layers with a small amount of common code in C++. We have standard video player controls as well as remix/sharing overlays and controls. That said, it's highly likely we will push more of this into C++ in the future. Maintaining the UIs on multiple platforms is our biggest work drain at the moment.

        Our main business focus is statistics and services to our customers. The users get a nice video experience, but our customers are interested in reducing their hosting fees (by not having to provide different stream formats for different client platforms, for example) and analytics. But we can also use that analytic data ourselves to drive the player in various ways, so there's a fair bit of communication going on behind the scenes, and our ability to create remixes of streamed video and share those remixes socially gets us closer to dropbox functionality in a way.

  10. joeW

    "He said the open-source culture in the C++ dev community is weak, especially when it comes to mobile, so they had to build frameworks to address cross-language type declarations and interface bindings"

    Presumably they then open-sourced these frameworks, to help strengthen the culture he thinks is weak?

    1. J27

      Hahaha, good one.

      1. JLV

        Well Dropbox most assuredly has contributed back to Open Source where their skills are strong. The whole mypy Python progressive type checker is from them, for example. Guido Van Rossum, Python’s daddy, works for Dropbox.

  11. Anonymous Coward
    Anonymous Coward

    If you’re writing a 3D game then C++ with platform-specific low-level wrappers is clearly the right way to go. C++ is portable, and OpenGL ES is portable, and you probably don’t need a huge amount of platform-specific code that has to be rewritten on each platform.

    I have a non-game app which I decided to write using C++ and OpenGL for (a) portability, and (b) because objective C was a hideous trainwreck of a language, and (c) because I was fed up with all the bugs in Apple’s APIs. That decision was almost 10 years ago; things have changed a bit - would I make the same decision now? OpenGL is deprecated on iOS, replaced by the proprietary “Metal”. Obj C is replaced by the less revolting but still proprietary “Swift”. I’m still maintaining a lot of user interface written in a style that I like but is very “NIH”.

    I sympathise with the Dropbox people. It’s unfortunate that we have such a disjointed environment for developing mobile apps. (At least the web is now more uniform than it used to be.). Is there a good solution?

    For me the irony is that having built all the “portable” code, I never built an Android version, for business reasons....

  12. Anonymous Coward
    Anonymous Coward



  13. Oh Homer
    Big Brother

    While you're down there...

    If they're rewriting that stuff anyway, now would be a good time to finally implement file encryption.

    Unless Dropbox's aversion to security is a matter of policy, of course.

  14. JLV

    One possible upside to writing it twice is that, if you play your cards just right, you might be able to use both implementations to cross-check each other. Basically if an input x1 results in output y1 then that should hold true across the board that Kotlin(x1) == Swift(x1). Anywhere where that’s not true can be scrutinized for specs compliance.

    Not optimal but making lemonade from lemons.

  15. martinusher Silver badge

    Pardon my Ignorance.....

    .....but isn't this more a platform problem than a language problem?

    I was brought up to regard languages and language library support were two very different animals. I know that over the years I've found that many programmers tend to think of the library functions as intrinsic to the language and that combined with the tendency to integrate system functionality into the language might give rise to the confusion about what language is 'best' for a particular task or platform. This might explain going back to languages like C++ for writing code; although C++ has accumulated many of the same problems these platform specific languages have over the years most of it is optional, its under the program designer's control (so - to a large extent if you've make a totally impenetrable piece of spaghetti then you only have yourself to blame for it!).

    1. Charlie Clark Silver badge

      Re: Pardon my Ignorance.....

      The platform problem becomes the language problem; the language problem becomes a maintenance problem which then becomes a project risk.

  16. jelabarre59

    Or maybe

    Perhaps they should just rewrite it in Python. I'm sure if they looked in their own ranks they could find an experienced Python developer...

    1. Anonymous Coward
      Anonymous Coward

      Re: Or maybe

      Mark Twain reports how he was watching a hunt in England when a man on a horse rode up and demanded "which way did the fox go?" To which Twain replied "Which fox? Because there are such a lot of foxes."

      And I ask, "Which Python? Because there are such a lot of pythons."

      (You missed the joke icon, without which you might be misinterpreted.)

    2. Tom 7

      Re: Or maybe

      Python is just a front end for C/C++ libraries.

  17. Anonymous Coward
    Anonymous Coward

    Deep system integration?

    On iOS? I call bullshit.

  18. dakliegg

    Just stupid. Use flutter

    I multitarget everyday using flutter. I'm a lone dev that doesn't even know iOS that well yet I can deploy to an old 5s from my hackintosh VM just fine.

    This is really a company fearing learning a new language (Dart) more than anything. Dart is so banal any dev can learn it.

  19. sum_of_squares

    Steps to repeat:

    1) Try to write a mildly complex feature in C++

    2) Debug it

    3) Debug it again

    4) C'mon, you can do better!

    5) Now do a complete rewrite in a modern language like Kotlin or Swift

    6) Realize it's way simpler, more robust while you used half the LOCs and dev time

    7) Think of all the good and bad times you've spend with C++, give it a great big hug and kiss it goodbye for the last time

    8) Take a deep breath, hold back the tears, turn around and never look back again

    "Sometimes the hardest thing and the right thing are the same.."

  20. jms222

    Why not go all the way and switch to a language invented last week

    I don't doubt Dropbox know what they're doing and that decision may be right for _them_.

    But Kotlin is eight years old. Swift is five.

    Does anybody _really_ want to invest their time in getting to grips with such young languages ? Are they really going to be around in another ten years ?

    Now imagine you're a bank and you'd like to have a bit of continuity. It's a bit wordy yes but what's really wrong with COBOL ?

  21. Anonymous Coward
    Anonymous Coward

    I remember dropbox

    It used to be useful back in the day

  22. lambdacalculus

    C++ is a beast of a language and I love it, and there's nothing like it for cross-platform development. The issue that the dropbox guys are alluding to here is that C++ standard library feature support has simply not kept pace with other languages. This is by far the biggest problem with C++, its can be a real pain to do things that are straightforward in other languages. Simply because the libraries in .net, Java, Kotlin etc are far richer.

    The C++ standards body at last are taking steps to address this - and not before time. C++17 introduced the standard filesystem library, and C++22 will support networking within the standard library. The C++ standards community needs to increase focus on standard library feature richness as a priority, rather than geeky and esoteric language feature masturbation or C++ will die.

  23. JoeCool Silver badge

    How are we equating C++ with Javascript

    From the article:

    "Dropbox may have made cross-platform coding particularly challenging by choosing C++ rather than C# or JavaScript."

    If someone is using C++ to kill a problem that is reasonably solvable with JavaScript, then I'll go out on a limb and say that's a bad technology choice. But I cannot think of any case where a C++ code base would be better rewritten in standalone JS. This statement deserves a little more explanation.

    1. Tom 7

      Re: How are we equating C++ with Javascript

      All I can say is in the early years of the millennium there was a thing that netscape released and they called it JavaScript2 and it had things like classes and inheritance without prototype bollox and it was easy to write good things. I hope for that day to come again.

  24. octaves

    Beard talk

    Surely everything is written with the Rubies these days? Whatever happened to the Rubies?

    1. Anonymous Coward
      Anonymous Coward

      Re: Beard talk

      Sadly they went off the rails.

      They were last seen drinking rubbing alcohol behind a dumpster.

      1. Tom 7

        Re: Beard talk

        It was curtain rails for them.

  25. Anonymous Coward
    Anonymous Coward

    I feel their pain

    I was given the task -- tasked in modernspeak -- of resurrecting some old C++ code. It would not compile on any of the compilers I tried. At painful investigation, I found it was written under g++ 2.95.

  26. Anonymous Coward
    Anonymous Coward

    Where's bombastic bob when you need her.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like