On Wednesday, 6 January 2016 at 18:52:05 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 6 January 2016 at 16:52:34 UTC, Joakim wrote:
Swift is dumbed down?
Yes, they are streamlining for apps. It is ARC through and
through. They are removing things like "++", currying and
C-style for-loops; in order to make the language simpler for
programmers. Cutting complexity where it isn't really adding
much to the language in _typical_ scenarios.
Eh, those removals are all well though-out and sensible, D has
similar opinions. I was impressed that most of the stuff they
say they _won't_ remove is related to C-style syntax:
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
They aren't making the mistake of many other languages- cough,
Haskell, rust, cough- of inventing new syntax for no real reason.
Most programmers have a C-style parser wired into their heads:
you cannot replace it.
btw, maybe Walter and Andrei should write up a similar list on
the wiki, would be easy for us to point noobs who want one of
those features to it.
I'm surprised you started off by saying that 80%/GC is the
big market, but now believe D should be "advanced."
It is the bigger crowded tooling-demanding market where you
have Java, C#, Go, Swift and a slew of others. Without tooling
you don't stand a chance in that market.
D aimed for the niche right below that, with higher efficiency,
that Swift is now also going after. It turns out that efficiency
matters, which is why Java and C# never made much headway in
application programming, certainly not outside their enterprise
niches, ie consumers don't use Java/C# apps, and are now both
AoT-compiled on mobile.
And really, if you want to compete with C, you can't really be
in that market. Do it well, or not at all.
C is so old and outdated that you could wrap up both. It may be
harder, but it can be done. C++ certainly took some share from C
over the years, D could do even better with a lighter runtime. D
hasn't really focused on that yet, but I think Walter wants to
one day.
Swift3 probably will try to get closer to C though. Apple
seems to be focused on making C less frequently needed.
So they too will try to straddle both horses!
No, they aim for ABI stability and portability. No concurrency
features.
https://github.com/apple/swift-evolution
Not sure how ABI stability/portability hurts that, but is Swift
going after C or not? You seem to say they are, then they
aren't. Going after lower-level code that would use C is the
other horse you mentioned, so if they are, they're trying to
straddle both.
Traditionally, it's been C and C++. I could see D providing a
lighter version that went after C, especially in embedded,
while the current version competes with C++.
With at different team?
Walter is the team. :) He's done embedded work before, he's aware
of the challenges.
We're talking cross-platform here, Swift isn't even in the
game till they get on other platforms than OSX/iOS.
But who are using D for cross platform development today? Isn't
Linux the primary platform in real world use (i.e. deployment)?
I don't know, and probably. But D runs well on all the major
desktop/server platforms and soon the two major mobile platforms,
not to mention upcoming platforms like wearables and smart TVs,
which D devs are currently testing. Get back to me when Swift
can say that.
more every year. Apple does it by continually staying at the
top of the performance heap, with their in-house designed
custom ARM cores blowing away the benchmarks year after year
I don't really think consumers know what they buy, but people
tend to want the same UI experience... so switching over takes
time.
The latest iPhone always blows away any Android phone on measures
of UI lag. Users don't know what makes a phone fast- the
components mentioned before, along with not using Java and its
GC-caused lag for your apps- but they can see when it is.
Maybe, but I don't see them willingly choosing javascript. :)
They'll be forced to. Managers will choose whatever readymades
carry name recognition... ;^) Java, .NET, node.js, Angular...
And with javascript losing its browser monopoly, it will slide
down that list. :)
I think most users are used to the web being different or
don't care about the "look and feel."
Most users probably don't care, but people who spec mobile apps
put it into the requirements.
Which is why I said it's dumb, because most users don't actually
care about that. One of the biggest herd behaviours I've seen in
recent years is the crazy drive to build mobile apps to replace
perfectly functional webapps, whose CSS UI could be simply redone
for mobile too. Unless you have a compelling reason to be
mobile-first, many are just wasting money.
So "dominant" that Facebook ditched their HTML5 mobile app for
native and Snapchat doesn't even have a webapp! HTML5 may now
be fairly ubiquitously _implemented_ in current browsers, but
you greatly overestimate how many devs are using it or want to.
Not sure what you mean, Facebook invest a lot of money into web
tech like React. If anything Facebook is heavily pushing
WebApps by funding the frameworks that enables it.
Perhaps you haven't heard, but the original Facebook mobile app
was simply their HTML5 site bundled on mobile, then they switched
to native years ago for efficiency:
https://facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920
They may still use and release legacy HTML5 frameworks, ;) as
that's where they started, but almost half of their users now
only use the native mobile apps, and that mobile-only user share
keeps growing:
http://venturebeat.com/2015/07/29/nearly-half-of-facebooks-users-only-access-the-service-on-mobile/
Others have followed them in ditching HTML5.
I don't get it: you have access to a debugger _in the
customer's browser_ with ES7?
All browsers have debuggers built in...
I wouldn't know as Chrome is all I use in recent years, and I
thought that was the only browser that always came with one. In
any case, your point is still unclear: why would WebAsm not have
the same browser support?
Every time this happens over the previous decades, something
simpler comes along and 80/20s the past bloated tech. The web
is _long_ overdue for this. They're finally trying to clean
it up a bit, with the recent HTTP/2 and WebAsm moves, but it
isn't enough.
I don't see HTTP/2 and WebAsm as a big thing. It is just
another step to make web a more solid cross platform deployment
platform.
They cannot fix the real problem, the baroque architectural pasta
of HTMl/CSS/DOM, but those moves make those two components much
more efficient, which certainly helps.
I don't spend much time on compatibility tweaks anymore. I
don't mind spending 1% on cross platform. That's actually
pretty impressive. Try to get there with native apps on 5
platforms: Linux, OS-X, Windows, Android, iOS... Impossible.
It can be done, but it's not actually what I'm suggesting. I
think there will be some new cross-platform approach that takes
over the web's spot. I've suggested a re-architecting of the web
approach before, to focus on efficiency and extreme simplicity of
graphical layout in the client:
http://forum.dlang.org/post/[email protected]
I used to want to work on that approach, but I now actually think
that entire client-server model is outdated. I suspect what's
coming is more of a p2p approach, where smartphones simply pass
data to each other, then construct UIs customized for the user
out of the data they want to see. That's my guess, but whatever
it is, it will kill the web.
