Well... there are other metrics besides code size in some sections, such as the total code size for all sections; the speed of compilation/linking; and ultimately, the user experience --- is it as fast or faster than C++ ?
When people make 'size' comparisons, I sometimes wonder if they'd best be done using lzip or something on the two code bases -- because the compressors are trying to remove redundancy in coding, and if one uses lots of whitespace in C++ to enhance readability, this should not punish C++ in the size department.
You generally want some 'system' ('language' seems too restrictive) to enable one to capture the algorithms rapidly and accurately in some notation (again, 'language' seems not quite the right word), and to as quickly as possible convert said notation into working binary (compiler, interpreter, JIT, etc all fair game) that satisfies the user need.
I claim (wrongly?) that these days, we generally only need a decent 'glue' notation that allows us to mash together existing libraries/classes/etc to produce the final product. Some of this glue would be sort-of templates, lispish macros, some would just be e.g. an FFT routine. But only by burying complexity in well-tested, lower-level chunks will we be able to build big systems that don't collapse.
Sorry, enough soapbox. I guess I'm suggesting that it's interesting to compare Swift to C++. It sort of begs the question: what is 'the best' way to get some functionality (e.g. this cool calc app) written?
C++ requires a lot more code because it is so clunky and inflexible. Swift is just a lot better language which is why you can get away with much shorter code for the same functionality.
I spent 15 years doing C++ and read so many books but always felt the language would get in the way. When switching to the Swift stuff just worked the way it should. No need to read tons of books to find clever tricks to get around inherent limitations of C++.
C++ was good for it’s time but it is strange that people think one cannot radically improve on what C++ is with newer languages. It is tied down with backwards compatibility with a 50 year old language.
That had lots of advantages, but downsides has caught up with advantages.
When people make 'size' comparisons, I sometimes wonder if they'd best be done using lzip or something on the two code bases -- because the compressors are trying to remove redundancy in coding, and if one uses lots of whitespace in C++ to enhance readability, this should not punish C++ in the size department.
You generally want some 'system' ('language' seems too restrictive) to enable one to capture the algorithms rapidly and accurately in some notation (again, 'language' seems not quite the right word), and to as quickly as possible convert said notation into working binary (compiler, interpreter, JIT, etc all fair game) that satisfies the user need.
I claim (wrongly?) that these days, we generally only need a decent 'glue' notation that allows us to mash together existing libraries/classes/etc to produce the final product. Some of this glue would be sort-of templates, lispish macros, some would just be e.g. an FFT routine. But only by burying complexity in well-tested, lower-level chunks will we be able to build big systems that don't collapse.
Sorry, enough soapbox. I guess I'm suggesting that it's interesting to compare Swift to C++. It sort of begs the question: what is 'the best' way to get some functionality (e.g. this cool calc app) written?