Yep, I actually think C is quite a clean, simple language. C++ is a beast. Swift is actually a little over-complicated too in my opinion.
Some things you write in C are not clean because modern language features are missing. Every C programmer has had to resort to ugly preprocessor hacks to make up for missing features. Swift is a very nice language. It catches *many* classes of bugs that are hard to catch any other way. I was starting to write some backend code for a Cocoa app in Rust to avoid C/C++. Now it is all in Swift. I can see a lot of directions they may take the language (golang style lightweight threads/stacks, c++ interoperability, meta-programming, etc.). Not to mention that Swift could serve as a Power Shell/Applescript type language in OS X since Swift has a CLI. The future will be interesting.
The article graph weighs up discussion interest on the vertical vs actual code repositories on the horizontal. The following animated site gives a nice view of just the code side:
"it should get to the point where there are thousands of projects on github all written in parallel code”
but if you check the animated stats, you can click through the time period and see Swift moving up from almost nothing to over 11,000 code repositories just since it was introduced, which probably shouldn't be that surprising considering there are over 600k active iOS developers and 9 million registered. Assembly has just over 2,000 repos but it could be including repos that contain assembly code while being mainly written in another language. Projects like VLC will use some assembly code for codec optimization but it's not all written in assembly. It would probably be more useful to see the numbers of files or SLOC in each language rather than projects that contain each.
The lines of code written in the other languages will vastly outnumber Swift just now but the number of projects being started in Swift is high. This is also just projects that are willing to have their code visible to others. Closed source projects will be unknown.
Given that Swift is intended to be Objective-C's successor, I can see there being a downtrend in Objective-C and some previous projects written in Objective-C can be migrated over. The downside with Swift is that some large games will be mostly written in a cross-platform C++ codebase, which can be mixed with Objective-C but harder with Swift. Someone made a project here showing how it can be done:
They made an Objective-C (Objective-C++ perhaps) wrapper for the function call to C++ and then make the call to Objective-C from Swift. Not too bad as it lets you do most of the controls in Swift and the wrapper class is quite minimal. It might be helpful if Xcode could create these Obj-C wrapper classes automatically or rather not create the files but just let Swift call the C++ code using a special suffix or prefix and the compiler figures it out behind the scenes e.g in Swift write @CPP_cplusplusclass and then during compile time, Xcode creates an Obj-C wrapper class for cplusplusclass and nobody has to write any Obj-C code for it to work. They could also have a built-in translator that converts C++ to Swift as closely as it can with just a click and it can try to maintain changes to both C++ and Swift code using manually activated code conversions for selected portions of code.
I'm surprised Assembly is as high as it is on that chart.
There is a lot of embedded stuff out there. For some of the common micro controllers Assemly is pretty easy to deal with, with either an entire project written in it or a a few files/routines. I kinda doubt there is a massive amount of i86 assembly being written.
In any event its is surprising how far Swift has come. The problem as I see it is that Swift only corrects part of Apple development tools problems. I've never really liked the way the SDK and interface builder works, it just rubs me the wrong way.
What problems with the SDK? Much of it is being (or has been) rewritten under the the direction of Chris Lattner (creator of Swift).
I agree with you on IB -- but that's [mostly] old code too! Storyboards are a modern addition to [replacement for] IB that illustrates a more modern approach to UI design and prototyping. IMO, Apple needs to update things like Bindings. Undo, etc. to make them less fiddly with more capability and better defaults.
Then meld Storyboards and Playgrounds so they work interactively with each other. Then Lattner can give a live interactive demo of developing a non-game app with nary an NS... IB... XIB... to be seen, anywhere.
Fortran has been relegated to HPC markets mostly and even there C++ and Haskell have been making inroads slowly for years.
Do you know that a good portion of the code that the climate scientists use in their climate models is Fortran based? That right there is enough to make me question their theories about the causes of global warming.
Ha! (my second Ha of the day).
My first experience with ForTran was on an IBM 1920 ...
The 1620 was an inexpensive scientific computer that was code-named CADET while under development. The 1620 performed arithmetic operations by table lookup ... CADET stood for Can't Add, Doesn't Even Try!
Hmm ... Don't See FARGO (Forteen-oh-one Automatic Report Generating Operation) on that chart
Yep, I actually think C is quite a clean, simple language. C++ is a beast. Swift is actually a little over-complicated too in my opinion.
Some things you write in C are not clean because modern language features are missing. Every C programmer has had to resort to ugly preprocessor hacks to make up for missing features. Swift is a very nice language. It catches *many* classes of bugs that are hard to catch any other way. I was starting to write some backend code for a Cocoa app in Rust to avoid C/C++. Now it is all in Swift. I can see a lot of directions they may take the language (golang style lightweight threads/stacks, c++ interoperability, meta-programming, etc.). Not to mention that Swift could serve as a Power Shell/Applescript type language in OS X since Swift has a CLI. The future will be interesting.
Yea, lotsa' potential!
I see two big targets at the top right of that chart: Java and JavaScript.
I think that Java programs could be handled by a SIFT program -- possibly re-integrate Java into Xcode so it can co-exist with Swift within an app (ala Swift/Obj-C) ... IBM could be quite interested in this,
As for JavaScript -- Swift source:
can look a lot like JavaScript source
is safer
is faster
can be programmed interactively
could be integrated with an interactive WebView UI in Storyboards
can be compiled to byte code or machine code
should be more productive
would require less bandwidth and fewer handshakes to download to a browser
Do you know that a good portion of the code that the climate scientists use in their climate models is Fortran based? That right there is enough to make me question their theories about the causes of global warming.
Well, I can't exactly blame them TBH.
Fortran is still more accurate than both and much faster a language, though time will tell as to how long that remains so.
What problems with the SDK? Much of it is being (or has been) rewritten under the the direction of Chris Lattner (creator of Swift).
I agree with you on IB -- but that's [mostly] old code too! Storyboards are a modern addition to [replacement for] IB that illustrates a more modern approach to UI design and prototyping. IMO, Apple needs to update things like Bindings. Undo, etc. to make them less fiddly with more capability and better defaults.
Then meld Storyboards and Playgrounds so they work interactively with each other. Then Lattner can give a live interactive demo of developing a non-game app with nary an NS... IB... XIB... to be seen, anywhere.
Not sure what SDK, but UIKit/Cocoa are not under Chris Lattner... just the standard library. I personally like UIKit/Cocoa, but it will be interesting to see if they evolve to take advantage of Swift. Interface builder has never quite got it right, but I really like the new features IBInspectable and IBDesignable that allow you to extend Interface Builder and storyboards. Now they just need to add IBInspectable support for non-views (controllers, etc.) and IBDesignable support for view controllers and it may be a great tool. Hopefully SpriteKit also adds the equivalent of IBInspectable/IBDesignable.
This might not be a fair evaluation. Lots of community questions does not necessarily equate to lots of users, but rather lots of problems.
Its not exactly an exact way or measuring popularity. You only post on stack overflow if have an issue you cant find an answer to. The more experienced people get in a language the less they post.
Number of git repos is also going to side with people doing open source stuff or example projects as I imagine they cant count private repos. Also why only github? The problem with these thongs tend to be devs in different languages use different sites.
I have to admit that having spent all my working day sat at a computer writing code it can then be pretty difficult finding the motivation to spend time on my evenings and weekends sat at a computer trying to learn how to write different code...
My destress / unwind technique tends to be getting out into the hills on my mountain bike for a few hours although the weather in the UK isn't really ideal for that at the moment.
The UK needs to be towed a few thousand miles to the south and the sooner the better.
With a bit of luck, global warming will warm us up by 5 degrees Centigrade or so.
Comments
Yep, I actually think C is quite a clean, simple language. C++ is a beast. Swift is actually a little over-complicated too in my opinion.
Some things you write in C are not clean because modern language features are missing. Every C programmer has had to resort to ugly preprocessor hacks to make up for missing features. Swift is a very nice language. It catches *many* classes of bugs that are hard to catch any other way. I was starting to write some backend code for a Cocoa app in Rust to avoid C/C++. Now it is all in Swift. I can see a lot of directions they may take the language (golang style lightweight threads/stacks, c++ interoperability, meta-programming, etc.). Not to mention that Swift could serve as a Power Shell/Applescript type language in OS X since Swift has a CLI. The future will be interesting.
Ha!
Gotta love RPN.
I first saw an APL demo in White Plains in the spring of 1968 -- and started using it to do PERT scheduling and some coding, later that year.
I can write that APL program in 1 [very, very long] line of code
Problem is, when I come back next month (or this afternoon) I can't read/understand what the progam is doing -- or how :???:
... Now where did I put Iverson's phone number???
Dick Applebaum is so old that he had to wait for early man to discover the '0' before he learn binary.
(Still working on my material for your roast)
http://githut.info
I thought there was a possibility that Swift was being inflated by the other language called Swift:
http://swift-lang.org/main/
http://www.linux.com/news/featured-blogs/200-libby-clark/725638-swift-the-easy-scripting-language-for-parallel-computing/
"it should get to the point where there are thousands of projects on github all written in parallel code”
but if you check the animated stats, you can click through the time period and see Swift moving up from almost nothing to over 11,000 code repositories just since it was introduced, which probably shouldn't be that surprising considering there are over 600k active iOS developers and 9 million registered. Assembly has just over 2,000 repos but it could be including repos that contain assembly code while being mainly written in another language. Projects like VLC will use some assembly code for codec optimization but it's not all written in assembly. It would probably be more useful to see the numbers of files or SLOC in each language rather than projects that contain each.
The lines of code written in the other languages will vastly outnumber Swift just now but the number of projects being started in Swift is high. This is also just projects that are willing to have their code visible to others. Closed source projects will be unknown.
Given that Swift is intended to be Objective-C's successor, I can see there being a downtrend in Objective-C and some previous projects written in Objective-C can be migrated over. The downside with Swift is that some large games will be mostly written in a cross-platform C++ codebase, which can be mixed with Objective-C but harder with Swift. Someone made a project here showing how it can be done:
https://github.com/romitagl/shared/tree/master/C-ObjC-Swift/Performance_Console/Performance_Console
They made an Objective-C (Objective-C++ perhaps) wrapper for the function call to C++ and then make the call to Objective-C from Swift. Not too bad as it lets you do most of the controls in Swift and the wrapper class is quite minimal. It might be helpful if Xcode could create these Obj-C wrapper classes automatically or rather not create the files but just let Swift call the C++ code using a special suffix or prefix and the compiler figures it out behind the scenes e.g in Swift write @CPP_cplusplusclass and then during compile time, Xcode creates an Obj-C wrapper class for cplusplusclass and nobody has to write any Obj-C code for it to work. They could also have a built-in translator that converts C++ to Swift as closely as it can with just a click and it can try to maintain changes to both C++ and Swift code using manually activated code conversions for selected portions of code.
What problems with the SDK? Much of it is being (or has been) rewritten under the the direction of Chris Lattner (creator of Swift).
I agree with you on IB -- but that's [mostly] old code too! Storyboards are a modern addition to [replacement for] IB that illustrates a more modern approach to UI design and prototyping. IMO, Apple needs to update things like Bindings. Undo, etc. to make them less fiddly with more capability and better defaults.
Then meld Storyboards and Playgrounds so they work interactively with each other. Then Lattner can give a live interactive demo of developing a non-game app with nary an NS... IB... XIB... to be seen, anywhere.
Ha! (my second Ha of the day).
My first experience with ForTran was on an IBM 1920 ...
The 1620 was an inexpensive scientific computer that was code-named CADET while under development. The 1620 performed arithmetic operations by table lookup ... CADET stood for Can't Add, Doesn't Even Try!
Hmm ... Don't See FARGO (Forteen-oh-one Automatic Report Generating Operation) on that chart
Yea, lotsa' potential!
I see two big targets at the top right of that chart: Java and JavaScript.
I think that Java programs could be handled by a SIFT program -- possibly re-integrate Java into Xcode so it can co-exist with Swift within an app (ala Swift/Obj-C) ... IBM could be quite interested in this,
As for JavaScript -- Swift source:
Do you know that a good portion of the code that the climate scientists use in their climate models is Fortran based? That right there is enough to make me question their theories about the causes of global warming.
Well, I can't exactly blame them TBH.
Fortran is still more accurate than both and much faster a language, though time will tell as to how long that remains so.
What problems with the SDK? Much of it is being (or has been) rewritten under the the direction of Chris Lattner (creator of Swift).
I agree with you on IB -- but that's [mostly] old code too! Storyboards are a modern addition to [replacement for] IB that illustrates a more modern approach to UI design and prototyping. IMO, Apple needs to update things like Bindings. Undo, etc. to make them less fiddly with more capability and better defaults.
Then meld Storyboards and Playgrounds so they work interactively with each other. Then Lattner can give a live interactive demo of developing a non-game app with nary an NS... IB... XIB... to be seen, anywhere.
Not sure what SDK, but UIKit/Cocoa are not under Chris Lattner... just the standard library. I personally like UIKit/Cocoa, but it will be interesting to see if they evolve to take advantage of Swift. Interface builder has never quite got it right, but I really like the new features IBInspectable and IBDesignable that allow you to extend Interface Builder and storyboards. Now they just need to add IBInspectable support for non-views (controllers, etc.) and IBDesignable support for view controllers and it may be a great tool. Hopefully SpriteKit also adds the equivalent of IBInspectable/IBDesignable.
Swift is one of Apple's breakthrough innovations of 2014.
There's also a plentitude of good Swift courses on Lynda.com and One Month, which helps as well.
But Apple can't innovate now that Steve Jobs is dead¡
Number of git repos is also going to side with people doing open source stuff or example projects as I imagine they cant count private repos. Also why only github? The problem with these thongs tend to be devs in different languages use different sites.
And BBC BASIC!
With a bit of luck, global warming will warm us up by 5 degrees Centigrade or so.
Looking forward to buying a car.