|
|
Quote: IMHO it's requiring coders do what's basically IDE's job.
Ding ding, we have a winner. Did not expect this from Apple.
|
|
|
|
|
Why Apple? Idea is Jet Brains'.
|
|
|
|
|
|
My point was that language designers spent time to add a future which enforces some stupid rule on developers, instead spending that time implementing an IDE plugin which does the job (likely faster and better than developers anyway). Because everybody uses IDE nowadays, right? Uhm... wait.
And for the recored, no-single-liners and no-assigment-in-comparison policies suddenly started to make sense... idiots.
|
|
|
|
|
Wow, I hadn't seen that Apple bug you linked before.
I mean seriously, most C compilers will produce a warning for that, let alone Lint-style tools. For a company in there position not to be using at least those on crucial code like SSL shows that they really have no respect for their users.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Smalltalk had similar readability, achieved differently.
In this case, an object kennel may define a method changeNameOf:To: would be invoked as follows:
kennel changeNameOf: d To: 'Fido'.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: Smalltalk had similar readability, achieved differently
Interesting.
So what you're saying is that Swift is trying to copy syntax that is used by a 46 year old language.
Just kidding.
|
|
|
|
|
I suppose it helps Swift code read more like Objective-C code.
That's important in this context, because Objective-C basically grafted Smalltalk's object system onto C. And so ObjC's object syntax ended up being very Smalltalk-like.
I really enjoyed it in Smalltalk. I felt that it made for very readable, understandable code. It didn't work as well and ObjC because there was a huge clash between the C syntax and the Smalltalk syntax.
At first, I disliked this syntax in Swift. But in the end, I decided it was just one of those things that I disliked because it was different than what I was used to. After a while, I didn't mind it so much.
I find it a lot uglier in Swift than in Smalltalk, however, since in Smalltalk you don't use brackets when sending a message to an object. The Smalltalk debugging environment is also way more fun. Test driven development is fun in Smalltalk, because if you write a test that calls a method that doesn't exist yet, it's no problem. The Smalltalk debugger will yell at you, pause execution, and then give you an opportunity to implement the method before resuming execution.
Like many things in life, though, it's definitely a matter of taste and opinion. Some people will never like this aspect of Swift, and I think it's completely fine for them to feel that way. 
|
|
|
|
|
That's a nice summary of what Swift is trying to do and I wouldn't have known any of that about it coming from smalltalk etc. I do like readable code, but I find this type of syntax almost gets in the way since things get named very oddly just to make them begin to make natural language sentences.
I like things like a player object that has a bool property of hasSpecialAbility so I can do things like:
if (payer.hasSpecialAbility){
}
Maybe the Swift stuff will grow on me as I use it more. Only time will tell.
Thanks for the great discussion.
|
|
|
|
|
I'll have to learn and use Swift. This year ... 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Good luck. I started writing some of it up here at CP : iOS 12 Programming Fundamentals With Swift: Intro & Chpt1[^]
I find that learning Xcode (IDE) is a barrier too. I'm definitely accustomed to VStudio and Android Studio. The odd way that you add code when a button is clicked (see article) just doesn't feel natural to me.
|
|
|
|
|
Nice. I have found a minor formatting issue. Search for "garbage" and you will see it.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Thanks for checking out my article and letting me know about that.
It's something with the CP editor and the fact that they added a new Swift code setting.
It seems to be a bug and I had reported it but they never got around to it. I'll check with them again.
|
|
|
|
|
Thanks for the link to the Swift book. Do you already know iOS?
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: Do you already know iOS?
Well, not really. I've developed a few apps but not much more.
Are you learning now?
|
|
|
|
|
raddevus wrote: Are you learning now?
No, I'm currently in a passionate relationship with Android and expect this to continue for several years. There's a small chance I'll embrace iOS development if I get a Mac.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: I'm currently in a passionate relationship with Android and expect this to continue for several years.
Very smart. I like Android development a lot. Probably my favorite platform right now because it reminds me of Windows dev in the earlier years. Just seems like a lot more fun.
iOS has a lot of crappy stuff and Xcode (IDE) is annoying and I realy don't like the UI layout designer because it is so confusing. In Android you can get right down into the XML and the XML makes sense and is easy to deal with (which I think is rare). iOS Ui and interactions are a pain to deal with. I feel like I"m going to move something and mess up the whole layout.
|
|
|
|
|
I think with Swift and future tooling, iOS development will evolve to be like how Android is today. I think the reason why iOS development is a bit fragmented today is because it has deep roots in the legacy NextStep OS, much like early Win32 development was because it had its roots in MS-DOS (on which Windows was layered). Today, I rely on the .NET framework and Windows Forms to insulate me from Win32 APIs.
Another reason I chose to start mobile development with Android is because I get to use my favorite language (C#) and IDE (VS) to build native Android apps using Xamarin. I have a lot of well-tested, production code in C# that I would have to rewrite (and retest) in Java. Using the native Android API from C# is a joyous experience. The downside is VS doesn't gibe you the free Firebase tooling that Android Studio. But I'm still crawling, and have a way to go before I use Firebase.
/ravi
|
|
|
|
|
If you want to see some very readble, but nasty code, you should try Cobol or better yet, SNOBOL.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Have just been asked to take over support for a live website. It's a mix of Classic ASP and ASP.Net. It runs on Windows Server 2003, .Net Framework 1.1, on a box running in the client's office. The business depends on the application.
Because there's a mix of classic and .Net, and the login authentication is done in Classic with a login token stored in the Classic Session object, login status is inaccessible to the .Net pages. So you can just enter the URL of a .net page and you get full access to everything. Neat!
The .ASPX pages are written exactly as Classic ASP; no code-behind, absolutely no separation of UI and business logic. HTML interspersed with VB.Net. Variables are defined without any type in most cases. There is no concept of objects and absolutely no code re-use (e.g. most pages can send emails, and there's all the code needed to setup an SMTP client on every page). Some pages connect to the database using ODBC and OLEDB concurrently, and the connection strings for each are hard-coded in the pages themselves.
Came across this little snippet just now...
The page has about 20 bound controls, dropdown lists, all setup the same way:
mySelect = "select product_id, name from mytable"
If Request.QueryString("cust_id") <> "0" Then
mySelect = mySelect + " WHERE cust_id=" & Request.QueryString("cust_id")
End If
mySelect = mySelect + " order by name"
myDBCommand = New OleDbCommand(mySelect, myConnection)
myDBReader = myDBCommand.ExecuteReader()
lstBox1.DataSource = myDBReader
lstBox1.DataTextField = "name"
lstBox1.DataValueField = "product_id"
lstBox1.DataBind()
myDBReader.Close()
myDBReader = myDBCommand.ExecuteReader()
iLoop = 0
Do While myDBReader.Read And iLoop < 10000
If product_id = myDBReader("product_id") Then
lstBox1.SelectedIndex = iLoop
iLoop = 10000
End If
iLoop = iLoop + 1
Loop
myDBReader.Close()
I don't know what I like least about this. The lack of validation of the querystring parameter; the concatenation of the query string into the SQL statement (ripe for SQL injection); the re-opening (i.e. re-execution) of the data reader; the looping through all the rows to match the existing value; the arbitrary limit of 10000 on the loop; the setting of the loop counter to 10000 rather than 9998 to exit the loop ... almost every line makes my head hurt.
There's hundreds of pages written like this. Of which about 10% are actually used; the remainder are "old" versions of pages, but not named consistently and some referenced from live pages so I can't just go through and delete irrelevant stuff.
I'm advising the client that a total rewrite is very urgently needed, but in the meantime there are functional changes required and this stuff has to be edited!
|
|
|
|
|
Sometimes code is the equivalent of a train wreck.
What you have there is more like a jumbo jet crashing into the titanic which is sent hurtling into a train. 
Well, thank goodness there are probably lots of global variables in there that will help you code this up right.
Good luck!
|
|
|
|
|
|
smoke and a few pops? Suggest Office Space - Printer Scene (UNCENSORED) - YouTube[^]
Now that scene was in California, so we could go to other extremes....
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
What a waste of good deodorant!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
