Of which, most are failures themselves (for many various reasons) according to the TIOBE ranking trend, as compared to Swift's climb.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS Starting to dig into Swift... it sucks.
- Thread starter 1458279
- Start date
- Sort by reaction score
Of which, most are failures themselves (for many various reasons) according to the TIOBE ranking trend, as compared to Swift's climb.
"Code has to be written in a way that it *can* be modified in the future.
Something that I'd expect any professional developer to know."
The code can still be modified, but it shouldn't be modified by someone that doesn't understand byRef vs byVal.
I don't need my light switches to say "On" and "Off" because I understand that flipping the switch up turns the light on and flipping it down turns it off. I understand turning a key clockwise opens the lock.
I remember have a discussion with a professor that was trying to teach the class byRef vs byVal and so many were having trouble with it that it started drawing pictures. Many were confused that you could modify the value of one inside a function and not the other. They didn't get that one was a copy and they other was a pointer to the original. We spent so much time on that, the whole class had to wait for those that didn't get it. Those were the some of same people that ended up failing the class.
The world of apps has changed programming. Anyone with a computer can make an app. We get people asking questions like "do I have to learn to code to make an app" I guess they need to see inout.
Looks like they are focused more on quantity than quality. We have some 1.5 million apps on the appstore and the average device has some 60 apps on them with only about a dozen getting much actual use. Do we really need every man, woman, and child to have their own app on the appstore? How many clones of a popular game to we really need? How many "flappy" knock offs did we have?
Just like the internet itself, a whole lot of answers to questions nobody asked. The vast majority of web pages will never matter. Probably < 1% actually matter. How many people go thru all the apps in a category in order to eval each one in order to find the best. When you have 10,000 flappy apps or flashlight apps, you've probably flooded the market.
Some 60% of the users download zero apps in a month. Not everyone in the world can be a gold miner and get rich.
Something that I'd expect any professional developer to know."
The code can still be modified, but it shouldn't be modified by someone that doesn't understand byRef vs byVal.
I don't need my light switches to say "On" and "Off" because I understand that flipping the switch up turns the light on and flipping it down turns it off. I understand turning a key clockwise opens the lock.
I remember have a discussion with a professor that was trying to teach the class byRef vs byVal and so many were having trouble with it that it started drawing pictures. Many were confused that you could modify the value of one inside a function and not the other. They didn't get that one was a copy and they other was a pointer to the original. We spent so much time on that, the whole class had to wait for those that didn't get it. Those were the some of same people that ended up failing the class.
The world of apps has changed programming. Anyone with a computer can make an app. We get people asking questions like "do I have to learn to code to make an app" I guess they need to see inout.
Looks like they are focused more on quantity than quality. We have some 1.5 million apps on the appstore and the average device has some 60 apps on them with only about a dozen getting much actual use. Do we really need every man, woman, and child to have their own app on the appstore? How many clones of a popular game to we really need? How many "flappy" knock offs did we have?
Just like the internet itself, a whole lot of answers to questions nobody asked. The vast majority of web pages will never matter. Probably < 1% actually matter. How many people go thru all the apps in a category in order to eval each one in order to find the best. When you have 10,000 flappy apps or flashlight apps, you've probably flooded the market.
Some 60% of the users download zero apps in a month. Not everyone in the world can be a gold miner and get rich.
So named parameters will make software more reliable? I wonder if most operating systems or the web is written with named parameters. At this point, I thing most software in the world is still written in some version of C or some old language and still works. Suggesting that labeling parameters makes more reliable software says more about the programmers than it does the programming language.
What a professional developer thinks they know, and what they know when actually coding are not the same thing.
Even Knuth has sent out some checks for $1.
Most operating systems are not reliable. Just look at the change notes for almost any Linux, iOS and OS X version. Expect more of the same in the future.
But some even older (but still quite useful) languages are not gone from the TIOBE list.
Would those be more reliable if they used named parameters or the "inout" identifier?
We can't know the true cause of the problem without knowing the skills of the people and/or the skills of the people that wrote the code before or the robustness of that code as the needs of the OS changes.
Would we have more bike riders if all bike were required to have training wheels? Should we require training wheels on all bikes independent of skills because it would make bikes more popular and easier to ride?
Consider: I had a conversation with someone about me riding a motorcycle. I studied motorcycle riding for quite a while a practiced until my skill was such that I could handle it at a usable level. I never had training wheels on the motorcycle. The person I was talking with asked about "those 3 wheeled" ones with motorcycle engines. They are not the same thing. We shouldn't force every motorcycle rider to switch over to a trike just because it is easier to ride. We have some people that are very skilled at riding and don't want a trike.
I don't mind that some use whatever tools they use to do whatever they want. I do mind when people are forced to use something because others don't like or want what's currently or could be offered. Example, I don't like languages that are not compiled. I want speed because that allows me to create a program that does more without being slow. I don't like Android because it uses a non-native compiled system (or at least I think it did before, that might have changed).
Modern programming practices are more like helmets and gloves than training wheels. Some states do require helmets, even for riders who don't fall (yet?).
Apple does not force the use of either Swift or Objective C for iOS or OS X apps. Code in arm64/x86-64 asm if you want... but I would not try to interview for most iOS app dev positions if that's your only skill.
The training wheels would actually stop the bike from tipping over and would be a hinder to some moves, whereas the gloves/helmet simply protect the rider without consideration of skill. Most accidents involve error on the part of riders and/or drivers.
At this time, Apple doesn't force Swift over ObjC. One of the things I noticed was the lean towards new things being for Swift. Module opt for faster apps, app slicing, playground, OS version checking thing(forgot the name) and others I can't remember off the top of the head. In fact, that's the reason I started watching the Swift training videos.
TBH, I'm not exactly a fan of ObjC either. I still don't understand why all these languages can agree on a common verb for looping or structure for a selection block, heck they can't even agree on fall thru after something is selected.
It's as if every city had it's own traffic rules where some say stop on green and other say stop on red.
It is. Different countries use very different sounding words with different numbers of letters and/or syllables for "stop", "red" and "green". In some countries any traffic signs and lights seem to just for decoration, as the drivers just ignore them.
Think how much easier things would be if all the cars had steering wheels on the same side and all the signs/laws/etc... were universal.
Look back at the cars made before standardization. Most people will never understand the economic value of standardization, from the Edison light bulb socket to shipping containers. The end value to the consumer is huge.
Every new programming language is an evolution process, each new language tries to solve problems of existing languages, or introduce new languages features for easier development ( not for 'training wheels' as you so suggest ) . So no - in short - languages will not be 100% consistent across the board.
Java, Python, Pascal et al are based upon the *syntax* from Algol.. hence they are named AlgolFamily. There are similarities as you suggest otherwise. I.e., For loops will look familiar across all these languages.
Other languages such as Hascal do not belong to this group so look very different. Programming languages serve different purposes.
Cobol was designed in the 50s, Pascal in the 1960s. Java 90s.. Swift in the past several years - I picked these because in a previous post you've mentioned that you've used each of them.
Would be dumb to be repeating same mistakes of a 1950s language in 2010, wouldn't it? Or repeat the same deficits as Java in Swift? No?
So - there will never be 'agreements' as you would like....
Last edited:
I can see that, we used to complain about Cobol all the time. Maybe part of the problem is that I don't yet see what problems Swift has solved. I'm clearly not an expert in Swift, so maybe it's about not giving it enough time or maybe expecting more as I didn't like the parameter names mixed with the parameters on ObjC either and thought that would change.
I remember people used to say Pascal was a self-documenting language, while others didn't like it because they thought it was simply a teaching language and not a 'professional' language.
Truth is that most advanced languages can do almost anything. I don't know if there is any app someone can write with Swift and not write with C++, ObjC, or Java. If you look at apps for Android vs iPhone, it would be hard to make the case that Android can't do what Apple can as far as limits within the language.
So it's an issue of the amount of work the programmer does vs the output of that work, and the power of the end product (native vs runtime VM). The rest comes down to APIs/3rd pary being able to do things.
I'll continue to give it a run, maybe it's an acquired taste.
Funny. My Latin teacher said something very similar about every modern language. Let's all just learn Latin. (But the Chinese, among others, would disagree I suppose...).
I've heard that pilots all speak English, I've always wondered, don't all people that use a given programming write the same code?
We don't have an ObjC in French do we? So the source code for a programming language is all the same. AFAIK, there aren't any popular programming language that don't use English keywords. I guess that says something about the value of standardization.
If we agree on the argument that English is used as a standard in programming languages, why wouldn't that same argument hold for standard verbs within the different languages?
I have no doubt that there is more to Swift than named parameters. I also pointed out "inout" and return value at the end of the function. I haven't mastered the language yet but I've seen the use of ? and ! and unrolling and don't know what those are yet.
Someone pointed out in another thread some Swift code that was doing something more complex, and it was dam hard to read. It looks more like Apple wants their developers to stay their developers.
One problem I see is that the end user doesn't see the code. They just use the app. Having to re-code for different platforms and learn a language that doesn't follow standards of any other language doesn't seem to help.
Java and the web was supposed to move towards make code work with different devices, now this seems to break away from the ability to use knowledge and routines already proven to work.
Looks like Apple really wants to set themselves apart and create their own ecosystem in every way they can.
I guess it doesn't impact game developers that use something like Unity, but those that write business software don't have that advantage with this route.
Maybe because you don't fully understand swift yet?
What standards would those be? Sure there are commonalities between languages, but standards? Examples would be nice.
That is for server side software, things aren't so easy on the desktop side. Generally, Java desktop GUIs aren't as nice as native GUIs.. it can be done.. but takes more effort for the polish.
Same for Microsoft ( C# et al ) and Google etc. Apple are being consistent.
Like I mentioned above : much easier to write server side software in one language, and have it run on multiple O/Ses ( i.e, Linux, Winows, OSX, Solaris ) than desktop. Such languages, but not limited to, would be Java, Scala, Python, Ruby...
I actually hope you're right about me not knowing Swift yet. I hope it's just me going thru some "adjustment" to something new.
The standards seem to have been tossed out the window a while back. IIRC, C/c++ was setting standards and then MS and others seemed to toss things out the windows years ago with things like C#.
I was never much of a fan of server side GUIs, and native is usually better. Users also prefer native and it can also give an edge to developers that take advantage of unique offerings of each device. That's one of the reasons I stay away from scripting, runtime universal solutions.
I'm going to continue to learn Swift, maybe I'll like it. I didn't like VB back when I learned it, but I still used it.
Maybe I have an attitude problem that I can't see
Give some examples of these "standards" you are referring to?
What - Server side GUIs?!!?
Runtime universal solutions - Such as Java ? But you were lamenting in a previous post about having to write software in a different language for each target operating system.
BTW - when I referred to Native GUI - I'm referring to say differences between GUI frameworks that target multiple O/S, such as Swing or QT. The GUI doesn't 'feel' or some cases 'look like' a native GUI - when built in , for example, XCode for OSX. They tend to be a little 'quirky'.
Last edited by a moderator:
Here's the list of standards. AFAIK, ANSI and maybe others agree on standards for both C and C++. This allows someone to use a compiler on different systems and use the standard code base.
https://en.wikipedia.org/wiki/ANSI_C
Isn't the web a server side GUI? The browser works like a dump terminal in that the code telling it what to do is on a server.
As far as runtime universal solutions, I'm against runtime solutions like Java vs compiled native code which is faster and more secure, although it can still have a robust runtime that can be called on and resolved at runtime like the ObjC runtime.
It's perfectly reasonable to have a compiled language that allows someone to exploit the specific elements of a specific device. This would probably be done thru API calls. Just like in the days of the PC where C/C++ would be able to compile on different systems and control different devices on those systems without having to learn a different language.
https://en.wikipedia.org/wiki/ANSI_C
Isn't the web a server side GUI? The browser works like a dump terminal in that the code telling it what to do is on a server.
As far as runtime universal solutions, I'm against runtime solutions like Java vs compiled native code which is faster and more secure, although it can still have a robust runtime that can be called on and resolved at runtime like the ObjC runtime.
It's perfectly reasonable to have a compiled language that allows someone to exploit the specific elements of a specific device. This would probably be done thru API calls. Just like in the days of the PC where C/C++ would be able to compile on different systems and control different devices on those systems without having to learn a different language.
Those standards that apply to C/C++ may not be relevant to other language such as compiler capability - only one vendor may produce the compiler / JVM Apples and Oranges. Where are for C/C++ there are numerous implementations.
There's a reason why pure C++ is no longer popular for building applications ( such as web applications, or desktop apps ) - other languages are more suitable and capable - with better 3rd party frameworks. Sure you could write a web app in C++, but would you want to?
The web content still runs on the client side - the web server just serves the content to the web browser -still - very basic web pages are nothing more than dumb as you point out.
-- however --
The Web GUI doesn't have to be completely dumb - using Javascript or whatever - having the web browser handle the GUI logic making for a more richer client.
( As you well aware, the webapp ( running on the WebServer / Application Server ) doesn't have to just target web browser - and may not care what is running on the client side - just receiving requests and sending responses, handing the business logic.)
Interpreted languages don't have to be slower than compiled languages - how well or badly an application is developed also makes a difference. Nor do they have to be less secure - how well is the interpreter / Virtual Machine written. There are vulnerabilities in iOS and OSX... The JVM is just particularly bad, but they aren't all like this.
The ObjectiveC extension to C is dynamic is resolved at runtime, yes. Also as a consequence of OO - dynamic / late binding. C++, Delphi ( which you've listed as using ) therefore can also resolve at runtime due to those supportingh Object Orientation.
Last edited:
Swift is being open sourced and will come with a standard library. Sure only Linux is being added initially to the supported platforms, but you can expect others to follow including that other very popular one. Of course there is so much more required to support multiple GUI environments. The next few years of Swift development and integration will be very interesting to watch.
The value of standardization is not dependent on the popularity of an older language. Look at the shipping industry. Containers became standard not that long ago. Now ports are being built that are much more robot driven. Being able to use the same container in the trucking industry is a huge advantage.
Think about a company that had a very complex routine written in C vs Swift if they wanted to port that to something else, Swift would require a rewrite whereas the C might not because of a standard in the language.
In fact, a huge part of my game plan is to write as many core routines as I can. I did this many years ago and was able to develop custom business software faster than anyone else I've ever known. The system I developed for American Express was done from ground zero to complete working system in 1 day and worked without flaw.
Some may only look at themselves and how easy/hard it is for them to read code, but I look at the business of software development and what the customer wants. The customer doesn't care how easy or hard it is for you to do something, they don't see that. I don't know how hard it is for Ford to build a pickup truck and I don't care... that's their businesses and they should get a handle on it. I care about the product presented and the value it adds to me or my business.
It's hard to see Swift being a good target to make a core foundation of business routines that I can use across whatever platform the customer has. It's hard to see me saying "drop all your devices and buy new ones" to make my product work.
Think about a company that had a very complex routine written in C vs Swift if they wanted to port that to something else, Swift would require a rewrite whereas the C might not because of a standard in the language.
In fact, a huge part of my game plan is to write as many core routines as I can. I did this many years ago and was able to develop custom business software faster than anyone else I've ever known. The system I developed for American Express was done from ground zero to complete working system in 1 day and worked without flaw.
Some may only look at themselves and how easy/hard it is for them to read code, but I look at the business of software development and what the customer wants. The customer doesn't care how easy or hard it is for you to do something, they don't see that. I don't know how hard it is for Ford to build a pickup truck and I don't care... that's their businesses and they should get a handle on it. I care about the product presented and the value it adds to me or my business.
It's hard to see Swift being a good target to make a core foundation of business routines that I can use across whatever platform the customer has. It's hard to see me saying "drop all your devices and buy new ones" to make my product work.