Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (116)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Swift  (Read 1484 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2014-06-06 09:15:59 »

So... I've had a fairly long look at Swift to see where "the minds" are going with the next decade or so of programming in a reasonably large ecosystem (Apple). Quite apart from all the suspicious fishy smells of lock-in and half-assed justifications about how it fits Apple's ancient creaky legacy APIs so-that's-why-they-did-it-this-way, I've a few observations about it all.

Firstly, the language appears to have been designed by egos and personal preferences rather than some modicum of analysis as to what sort of problems occur in the wild. So we've got the genius of the ".." and "..." operators that with a single hard-to-spot character immediately introduce a whole class of tricky little off-by-one bugs. Similarly we've got the == and === operators, bane of Javascript but behaving in almost completely different ways to any other C-like language. Which is fine if you're going to be a Swift programmer your entire life, but most of us won't be, and we'll be coming from other C-like languages and apart from the subtle redefinition of == the difference between == and === is, again, a single character with a radically different meaning and no other indication that something might be amiss, leading to another whole class of subtle runtime errors. There are various strangely thought out decisions as well such as making rather a lot of twiddly syntax bits that we're otherwise all used to such as brackets after an if() and the requirement to terminate statements with a semicolon optional. Which is great if it's annoyed you all these years having to type them, but is going to make for some fairly ugly differences in code style between programmers and lead to pointless arguments. Think about the squabbling we already endure about where {} brackets go and indentation. You get my drift. So a whole raft of small lexical nuances that lead to stress and bugs. Great.

Secondly, there are no exceptions. Just when somebody has finally figured out a great way to handle unexpected things happening in a clean way and provide some actual useful information to developers, the designers of Swift have thrown the entire lot out in favour of... well, it's every man for himself. This decision baffles me rather a lot. There are, it turns out, programmers who think that exceptions are a bad idea and that they're "slow" or "cause undefined runtime behaviour". These programmers are of luddites who like being paid to fix their own mistakes all day long. Hats off to them if they can hold down a job and keep the wool pulled over management's eyes. It ain't fooling me.

Thirdly, it uses "automatic reference counting" plus "some secret sorcery to detect strong circular references" in place of actual garbage collection. Again the reasoning appears to be unresearched - not even a cursory look at the state-of-the art found in Java for example. The reasoning goes that GC is too heavyweight for ARM-class devices such as phones. Which of course, is something of a complete joke, as we know; GC is incredibly fast now they know how to do it, and indeed, very lightweight, using very little CPU and relatively little overhead. Instead there's a half-assed ref counting scheme going on which is acknowledged to break under the circular reference scenario, and so they've had to add a bunch of other stuff to detect that occurring. Which sounds like GC, but more prone to trouble. More reasoning behind exactly why this is the way it is is because Apple's ancient creaky APIs are built upon reference counting and switching to proper GC appears to have freaked them out a bit, so they're not going to bite the bullet. Anyways... the concept does not appear to be built-in to the actual language spec itself but another hideously grafted afterthought.

Fourthly, there appears to be some fairly shitty inconsistency between what objects are, what references are, how arrays are treated, strings, pass-by-value, pass-by-reference, etc. There is essentially no consistency at all in the language or the data model or the object model. It looks like the designers of PHP have tried to invent a new language. It's a complete mess.

Fifthly, it's got some half-assed concept of collection types baked in to the language. All well and good if you're a newbie programmer but a quick look at the Java collections APIs and you'll soon come to the conclusion that it's a massive mistake to attempt to build collections into the language when there are in fact so many different use cases for different sorts of collections that they require a ton of different interfaces and implementations to achieve the correct semantics and behaviours. And this is all built on top of the creaky, inconsistent treatment of objects and references. It has some form of genericism or templating here but again, it's a half-assed, half-baked, ill-conceived, incomplete feature. The whole thing is a bit of a facepalm.

On the positive front:

It's got "optional" and not-null baked right into the language, which IMHO is a good thing, and removes one of the most common runtime errors. Yay!

It's got tuples, though they are immutable for some inexplicable reason.

You can name parameters to method calls and optionally use them.

All in all, the whole thing leaves me perplexed. I cannot honestly think of one good reason that anyone would use Swift... unless they were forced to.

Cas Smiley

Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2014-06-06 09:18:23 »

Reading that back to myself it really hits home just how utterly spoiled by sheer genius we've been with the Java foundation APIs, Java language specification, Java virtual machine spec, and memory model. It's absolutely complete, consistent... it's a masterpiece.

Cas Smiley

Offline Roquen
« Reply #2 - Posted 2014-06-06 12:22:44 »

I've yet to see the language reference so I'm holding my opinions.  The docs I looked at on the site are too much of a "overview" to form a reasonable impression.  Yeah I was thinking the same thing about reference counting, but the description is vague enough that it could be replaced by a GC at some point.  You just can't do reference counting right...unless there's some supra-secret research behind this.  Plus it bloats all instances with the count.  Already java headers are too big for my liking.

The language itself looks pretty run-of-the-mill otherwise...but again hard to say with the spec.  The one kinda cool thing I noticed was custom operators (from a limited character set) with definable precedence...which I'm sure everyone will hate.

The upside of all of this new stuff from Apple is that it's all going to be backed by LLVM (swift, new shader language) which means they'll be pouring even more cash into it.  I'm all for that.

EDIT: I can't see a reason to define a memory model unless there's something I'm forgetting between ARM and intel-a-likes.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #3 - Posted 2014-06-12 09:06:17 »

I got curious and it looks like there has been some advancement in state-of-the-art for reference counting in the last couple of years.

http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rcix-oopsla-2013.pdf
http://ssrg.nicta.com.au/summer/13/Shahriyar
Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2014-06-12 10:28:18 »

Jolly good. So long as it's completely transparent to the programmer I couldn't care less about which collector I'm using Smiley Well, so long as it's fast and pauseless. I'd quite like some of this RC-Immix GC stuff for a Hotspot VM to see how it compares for games programming. I've already determined that the G1GC is hopelessly slow Sad

Cas Smiley

Offline Roquen
« Reply #5 - Posted 2014-06-12 11:55:22 »

Take a look at this instead:
http://rkennke.files.wordpress.com/2014/02/shenandoahtake4.pdf
http://rkennke.wordpress.com/

All of these research things ya gotta take with a grain of salt.   
Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2014-06-12 12:51:04 »

Hm, they seem to be going for a reduction in potential pause times there to a general increase in slowness throughout... the pointer indirection stuff certainly seems like it might be slow but of course the proof of the pudding is always in the tasting.

Cas Smiley

Offline BurntPizza
« Reply #7 - Posted 2014-06-12 13:04:39 »

Right now the optimizer also seems practically broke: http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays 
Offline Roquen
« Reply #8 - Posted 2014-06-12 13:17:39 »

I only quickly skimmed.  It looked to me that the pointer indirection only occurs when an object has been moved and once time per reference.
Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2014-06-12 13:23:04 »

"per reference"... would that include this.x ++?

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #10 - Posted 2014-06-12 13:52:46 »

I re-skimmed and am not seeing what you're talking about.  Can you point me to it?  Doesn't seem likely..that would be a performance killer. 
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 800
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #11 - Posted 2014-06-12 13:56:15 »

I only quickly skimmed.  It looked to me that the pointer indirection only occurs when an object has been moved and once time per reference.
It has to *check* for this indirection upon any read/write on the object.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Roquen
« Reply #12 - Posted 2014-06-12 16:52:56 »

Mark the page to generate an exception on access.  The exception handler can perform the fix-up.  This is a thought out of my head...I'll have to look at the paper to see their strategy.
Offline Roquen
« Reply #13 - Posted 2014-06-13 08:17:08 »

Quote
In terms of machine code instructions, this means one additional read instruction for each write operation into the heap (and some read operations by the runtime).
Uggh.  If this is still the plan...pretend like I didn't mention this collector (unless I'm misreading this).  Sad

I wonder why there's just not marking the page to throw an exception on writes.  Ok it's hairy because you have to keep both versions up to date and needs specialized code for each major CPU family (humm..maybe it can't be done on ARM...humm..)

Solution:  just don't call new.
Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2014-06-13 08:42:52 »

Seems full o' fail to me. Still, it's optional and we'll be able to test it soon on real-world stuff.

Cas Smiley

Offline Roquen
« Reply #15 - Posted 2014-06-16 07:50:13 »

Oh.  While we're talking about GCs.  iCMS is going the way of the dodo in JRE 9.

http://openjdk.java.net/jeps/173

Pages: [1]
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

radar3301 (12 views)
2014-09-21 23:33:17

BurntPizza (30 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (28 views)
2014-09-20 20:14:06

BurntPizza (32 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!