iOS For those that were interested in function programming for Swift:

[1458279]

Some have expressed an interest in functional programming in Swift.

I found that link:
https://www.objc.io/books/functional-swift/

There's a bit of talk about this and might be interesting to keep up on.

 

[PhoneyDeveloper]

The book preview on that site is interesting

https://www.objc.io/books/functional-swift/preview/

I think that the way that 'normal' developers (i.e., never used Haskel and maybe never heard of it) will ease into functional programming is with map, filter, reduce. I see the use of those methods in some open source swift code. Look at the tutorial here

http://www.raywenderlich.com/82599/swift-functional-programming-tutorial

I may be wrong but whole-hog functional programming, like in the book you link to is not in the cards for most iOS developers. It will probably depend on Apple. When block's were added to Objective-C Apple adopted them widely in the system APIs. If you are an iOS developer you have to understand Blocks. We're certainly not at the stage where Apple is adopting the functional paradigm for system APIs. So any app that uses functional code will be Object-Oriented where it interfaces with the system classes and functional in its own independent code. For those that love functional programming they will probably go that way. The rest of us will only use functional programming in a limited way.

 

[1458279]

The book preview on that site is interesting

https://www.objc.io/books/functional-swift/preview/

I think that the way that 'normal' developers (i.e., never used Haskel and maybe never heard of it) will ease into functional programming is with map, filter, reduce. I see the use of those methods in some open source swift code. Look at the tutorial here

http://www.raywenderlich.com/82599/swift-functional-programming-tutorial

I may be wrong but whole-hog functional programming, like in the book you link to is not in the cards for most iOS developers. It will probably depend on Apple. When block's were added to Objective-C Apple adopted them widely in the system APIs. If you are an iOS developer you have to understand Blocks. We're certainly not at the stage where Apple is adopting the functional paradigm for system APIs. So any app that uses functional code will be Object-Oriented where it interfaces with the system classes and functional in its own independent code. For those that love functional programming they will probably go that way. The rest of us will only use functional programming in a limited way.

I haven't dug deep into it, but I was under the impression that you could have a mix. Although the benefit of a mix might not be great, it could offer some advantages. I can't think of any worthwhile examples off the top, but something along the lines of a set of global function that could be used anywhere by any object at any time.

I used a mixed system before (OO/Function) and I remember writing a bunch of base functions and used them wherever I wanted. That's not to say methods and OO couldn't do the job, but I remember it worked well and wasn't hard to understand.

 

[PhoneyDeveloper]

Your app's interaction with UIViewController and UIView and all the rest of UIKit is object-oriented, by design. All of your delegate callbacks and view controllers need an object-oriented design. In your data model you can do what you like. So if what you like is Swift functional then you can do that there. Certainly it can be a mix in that sense.

 

[1458279]

Your app's interaction with UIViewController and UIView and all the rest of UIKit is object-oriented, by design. All of your delegate callbacks and view controllers need an object-oriented design. In your data model you can do what you like. So if what you like is Swift functional then you can do that there. Certainly it can be a mix in that sense.

What I remember from "back in the day" was a bunch of string functions, date function, user settings, etc. Example was an encrypted user security system where they would have access to some areas of the program.

My understand is that function can be made global and that can address several app wide needs.

I'm thinking of things that people would otherwise use a singleton for.

 

[eventailapp]

Let's not forget the fact that Swift now runs on Linux. Functional programming is a great paradigm for backends. Especially if you are aiming for completely stateless crash-only server.

 

[1458279]

Let's not forget the fact that Swift now runs on Linux. Functional programming is a great paradigm for backends. Especially if you are aiming for completely stateless crash-only server.

Didn't know this, this could be a game changer.

Looks like someone already started making one:

http://www.sitepoint.com/server-side-swift-with-perfect/

That could change the issue with full-stack employment because I notice not as many jobs were asking for full-stack and with a new language that goes cross platform, it could change that. It's really an issue of getting backend programmers to adopt Swift.

I don't know how hard it is to setup a backend server, I imagine it'll end up like web pages where you have templates and less programming as they become more standard.

On the other side, I heard a podcast about Swift and they said it wasn't usable because of something at a lower level. I don't remember what, but that is probably what needs to be changed in the open source version.

Here's the podcast if anyone want's to hear it. It's about the year ahead with ios dev.
https://devchat.tv/iphreaks/141-ips-2015-roundup-and-2016-predictions


Another discussion about this:
https://www.reddit.com/r/swift/comments/3tert8/swift_as_a_backend_language/

 

[eventailapp]

Indeed Swift can have a bright future but if you need something reliable on a backend now or in a year then it is most definitely not the right choice. For backends it is a good practice to use tested technology and If you go the Swift route you will probably need to develop a lot of bricks yourself.

 

[1458279]

Indeed Swift can have a bright future but if you need something reliable on a backend now or in a year then it is most definitely not the right choice. For backends it is a good practice to use tested technology and If you go the Swift route you will probably need to develop a lot of bricks yourself.

Isn't a lot of the back end server stuff "ready made" as compared to an app?

What I mean is that an app can be many things, where as a back end server manages data and responds to requests, logs users, etc. I would guess there would be a lot of "out of the box" code already written and customization for specific needs.

If that's the case, then Swift would have a bit of an up hill climb until someone makes (and tests) the "out of the box" code base in Swift.

 

[eventailapp]

Languages usually do not come with out of the box stuff made for backends, that is what frameworks are for (example Express for Node.js or Ruby on Rails for Ruby)

Swift needs a solid database connection library (for various databases), a web-server, a file server. Swift on Linux currently lacks multi-threading (libdispatch is not yet ported). String manipulation is not complete (as anything tied to Objective-C does not work in Swift on Linux and Swift String relies on NSString for some of its functionality).

So yes indeed, Swift on a server will be an uphill battle. I am confident it will get there, eventually. Hopefully Apple will provide some first party libraries. I can imagine that they do plan on replacing Web Objects at some point, and most probably by something written in Swift.

 

[1458279]

Languages usually do not come with out of the box stuff made for backends, that is what frameworks are for (example Express for Node.js or Ruby on Rails for Ruby)

Swift needs a solid database connection library (for various databases), a web-server, a file server. Swift on Linux currently lacks multi-threading (libdispatch is not yet ported). String manipulation is not complete (as anything tied to Objective-C does not work in Swift on Linux and Swift String relies on NSString for some of its functionality).

So yes indeed, Swift on a server will be an uphill battle. I am confident it will get there, eventually. Hopefully Apple will provide some first party libraries. I can imagine that they do plan on replacing Web Objects at some point, and most probably by something written in Swift.

Isn't that what this guy did? :

We've been developing an open-source back-end application server for Swift.https://github.com/PerfectlySoft/Perfect

It has Postges, MySQL and SQLite connectors and I'm almost done with the MongoDB work.

It's currently the backend for a few apps which are in beta. We are waiting on the Linux version to drop so we can do the final bits of work to get it running there and deploy to the real servers (i.e. not Mac minis).

Here's the Reddit discussion, sounds like he's got something going on. There's a GitHub link in there, maybe check it out.
https://www.reddit.com/r/swift/comments/3tert8/swift_as_a_backend_language/

 

[eventailapp]

Yes, it is a promising start. However if you do not wish to get burned it is better to use server software that has years of bug fixes under the belt. Using beta software is a very bad idea, especially if you hope having thousands or millions customers relying on it. I believe in server side Swift and will certainly try this for some side projects, but I'd wait a year or two before using this on something big.

 

[1458279]

Yes, it is a promising start. However if you do not wish to get burned it is better to use server software that has years of bug fixes under the belt. Using beta software is a very bad idea, especially if you hope having thousands or millions customers relying on it. I believe in server side Swift and will certainly try this for some side projects, but I'd wait a year or two before using this on something big.

What you say is true, but there is a theory, that humans have the ability to learn from their mistakes in the past. Understand this is just a theory, but if humans have the ability to learn from their mistakes, they could produce a less buggy system by looking at what caused the bugs in the past.

I think the real problem with this theory is that humans are involved. Humans can (and usually do) screw up anything

 

[Stella]

Promising, but Perfect is just a start, and not production ready by any means. It's going to be a long while for this project to become stable and mature enough to be considered as viable in a production environment. Hopefully the Devs will stick it out.

More Database connectors would be nice, such as Oracle, DB2 etc...

Swift absolutely requires a healthy developer community for it to be used outside of the Apple world, otherwise there won't be any compelling reason to switch from existing languages.

Projects like this are encouraging...

 

[1458279]

Promising, but Perfect is just a start, and not production ready by any means. It's going to be a long while for this project to become stable and mature enough to be considered as viable in a production environment. Hopefully the Devs will stick it out.

More Database connectors would be nice, such as Oracle, DB2 etc...

Swift absolutely requires a healthy developer community for it to be used outside of the Apple world, otherwise there won't be any compelling reason to switch from existing languages.

Projects like this are encouraging...

That's yet another interesting point. With Swift changing some of the language and having syntax that's different from other common languages, it faces an up hill climb. A big part of the motivation to learn Swift is apps, in the world of back end servers, that motivation isn't there. They already have working solutions and probably don't care about "this can make apps too" part, and it's only a small part of making apps anyways.

It's looking more and more against this becoming something.

 

[eventailapp]

A big part of the motivation to learn Swift is apps, in the world of back end servers, that motivation isn't there.

Well for me there is actually motivation to learn Swift for backends as well. The thing is that I do not like most of the languages that are currently used for back ends. Python and Go use significant whitespace, I got tired of PHP bugs and quirks, I like Perl but it lacks nice frameworks, I have chills when I approach anything that uses a JVM. Also I really want to use functional programming for server side so any strong OOP languages are out (Ruby).

Finally I am leaning towards JavaScript but that is quite ugly without ES6 and needs absurdly excessive tooling to get something to run.

Swift comes to the rescue. Luckily I won't be needing any server backends for some years so there is time for at least one framework to rise.

 

[1458279]

Well for me there is actually motivation to learn Swift for backends as well. The thing is that I do not like most of the languages that are currently used for back ends. Python and Go use significant whitespace, I got tired of PHP bugs and quirks, I like Perl but it lacks nice frameworks, I have chills when I approach anything that uses a JVM. Also I really want to use functional programming for server side so any strong OOP languages are out (Ruby).

Finally I am leaning towards JavaScript but that is quite ugly without ES6 and needs absurdly excessive tooling to get something to run.

Swift comes to the rescue. Luckily I won't be needing any server backends for some years so there is time for at least one framework to rise.

If what you say is a common view, then there should be enough interest to make it happen.

I'm actually kind of surprised that the back end world would have such problems. Seems like all the computer areas have issues like this. Maybe that's why some people hate STEM jobs

 

[Stella]

That's yet another interesting point. With Swift changing some of the language and having syntax that's different from other common languages, it faces an up hill climb.

There are more significant issues, language syntax is minor. Since the Swift is based upon Algol, there is no significant difference in learning Swift and any other Algol Family language ( Java, Ruby, Pascal, Python, Scala, C, et al ).
[doublepost=1455884304][/doublepost]

Python and Go use significant whitespace,
Finally I am leaning towards JavaScript but that is quite ugly without ES6 and needs absurdly excessive tooling to get something to run.

The indentation of Python is a strength of the language IMO!

Have you looked at Coffee Script? There's quite a few commonality between ES6. Although it just translates into JavaScript pre ES6, it will work in most browsers, unlike ES6.

 

[1458279]

There are more significant issues, language syntax is minor. Since the Swift is based upon Algol, there is no significant difference in learning Swift and any other Algol Family language ( Java, Ruby, Pascal, Python, Scala, C, et al ).

I've always been of the opinion that any language that has a preprocessor and was well supported would have a bunch of routines ready made that people could share.

We used to do that all the time in Pascal/C etc... Everything from a sort routine to file managers etc... I would be surprised if at this point someone just didn't pic a stable language and write a bunch of routines to handle all these things.

Pretty much the same idea as a game engine. Don't we have a pretty fair selection of open source game engines? Isn't Cocoa2d/3d open source? Isn't there the same kinda thing with the back end servers?

 

[Stella]

I've always been of the opinion that any language that has a preprocessor and was well supported would have a bunch of routines ready made that people could share.

We used to do that all the time in Pascal/C etc... Everything from a sort routine to file managers etc... I would be surprised if at this point someone just didn't pic a stable language and write a bunch of routines to handle all these things.

Pretty much the same idea as a game engine. Don't we have a pretty fair selection of open source game engines? Isn't Cocoa2d/3d open source? Isn't there the same kinda thing with the back end servers?

Yes, there are plenty of Application Server Frameworks for different languages. Perfect is one for Swift. Perfect would then run on an Web Server, such as Apache.

"The bunch of routines" come from Libraries or other Frameworks. ObjectiveC and Swift do not have File Management support in the core language, nor should they. The File Management API comes from the Cocoa Framework. Being a bit more specific - majority languages have Sorting functionality in the core language.

 

[1458279]

Yes, there are plenty of Application Server Frameworks for different languages. Perfect is one for Swift. Perfect would then run on an Web Server, such as Apache.

"The bunch of routines" come from Libraries or other Frameworks. ObjectiveC and Swift do not have File Management support in the core language, nor should they. The File Management API comes from the Cocoa Framework. Being a bit more specific - majority languages have Sorting functionality in the core language.

Ok, so why would Swift be any better than those other languages that are already out there? If those languages already have routines made, it shouldn't be nearly as hard to set things up.

I could see if it were more like apps where every app can be very different, but I see this more like an OS, where you can customize it and most back ends would be doing much the say except for what data it's doing it to. Kinda like an SQL server, the commands, scripts might be common, but the data tables, reports etc would be different.

 

[Stella]

It is not Black and White. Ask many people the same question and you'll get multiple answers.

At the moment there is no compelling reason why you should be using Swift instead of other languages outside of iOS and OSX applications. Ask the same question in several years time after the language is more stable, with better developer support and you may get a different answers.

Ok, so why would Swift be any better than those other languages that are already out there? If those languages already have routines made, it shouldn't be nearly as hard to set things up.

I could see if it were more like apps where every app can be very different, but I see this more like an OS, where you can customize it and most back ends would be doing much the say except for what data it's doing it to. Kinda like an SQL server, the commands, scripts might be common, but the data tables, reports etc would be different.

 

[1458279]

It is not Black and White. Ask many people the same question and you'll get multiple answers.

At the moment there is no compelling reason why you should be using Swift instead of other languages outside of iOS and OSX applications. Ask the same question in 2 years time after the language is more stable, with better developer support and you may get a different answers.

I don't doubt that for a second Programmers tend to take sides on platforms and languages pretty strongly. IMO, part of it is because the time it takes to learn a language and platform, it's not so easy to know a bunch of different languages and keep up with things.
It's got to be one of the fastest changing jobs in the world.

 

[Stella]

Some say you should try to learn a different language every two years.

I don't doubt that for a second Programmers tend to take sides on platforms and languages pretty strongly. IMO, part of it is because the time it takes to learn a language and platform, it's not so easy to know a bunch of different languages and keep up with things.
It's got to be one of the fastest changing jobs in the world.

 

[eventailapp]

The indentation of Python is a strength of the language IMO!

Have you looked at Coffee Script? There's quite a few commonality between ES6. Although it just translates into JavaScript pre ES6, it will work in most browsers, unlike ES6.

Yes. This is a very personal preference of mine, I am attracted to Swift as I like its syntax. I do know about coffee script but for now I find that compiling (or transpiling, whichever term you prefer) to JS is too much of a burden for the benefit it brings, i.e.: compared to the C to ASM debate, the benefits of Coffee Script, TypeScript or AtScript are relatively minor, especially with the ES6 addressing most of the major issues. Also, I do not really believe that these languages have bright future with the advent of ES6 (and 7 and so on, I hope that JS will start evolving faster).

Ok, so why would Swift be any better than those other languages that are already out there? If those languages already have routines made, it shouldn't be nearly as hard to set things up.

One advantage of a backend in Swift is that you can potentially share some code with front end. This is also what made server-side JavaScript popular. Also it enables you to master one language very well.

Swift has the potential to have a very large reach, from scripts (build system) through the backend all the way to the frontend. But more tooling, more libraries and more tests are needed. For scripting a solid file system library and regexp support is a must. (something native to the language, regexes passed as strings are illegible and ugly)