On Thursday, 7 January 2016 at 09:12:05 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 7 January 2016 at 04:43:28 UTC, Joakim wrote:
Most programmers have a C-style parser wired into their
heads: you cannot replace it.
You get used to a different syntax rather fast if it is
reasonably close to something familiar. I was sceptical to
Python, but picked it up quickly.
I haven't found Python to be that different, certainly not as
much as the two I mentioned. But the required spacing is one of
the aspects that killed it for me.
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.
No, they are not going after C, but making it less necessary to
drop down to C from Swift. If they have a fixed ABI then you
can FFI Swift functions?
OK, not a full C competitor, but taking some of the higher-level
work. I think D could take all of C's domain, Walter certainly
knows how.
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:
I don't know much about it, but I've heard that Facebook have
serious internal software development process problems
resulting in bloat across the board. Just a rumour. I thought
that implied to their mobile apps too? (I don't use it.)
Regardless, the point is the greater efficiency of native worked
better for them.
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:
Ok, well, Facebook and other juggernauts can afford to develop
their apps on all kinds of platforms (from scratch even).
Yes, which is why many apps that are debuting now are native
mobile-only, their devs can't be bothered with arcane and
inefficient legacy platforms like the web. :)
In any case, your point is still unclear: why would WebAsm not
have the same browser support?
We'll see, but less motivation (demand) is my guess. Webasm is
unreadable, runs as machine language and you don't have type
info?
You could always splice in the debug info if you're debugging,
right? I saw some talk on their github about using DWARF or some
other debug format: they're considering those tooling issues now.
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 really think the DOM is baroque. It is like a scene
graph. The only really bad thing about it is that you set css
values as strings. It could use a redesign, but it is more
flexible than regular GUI libraries (which are rather ugly and
tedious).
A scene graph jammed into an antiquated document layout, then
stylesheet and scripting languages mashed on top: what could go
wrong? :D
Complexity kills. Try searching the Chromium issue tracker for
"painting" and see how many issues pop up:
https://code.google.com/p/chromium/issues/list?can=1&q=painting&colspec=ID+Pri+M+Stars+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles
Pick some of the obvious UI-related issues from that list and see
what kind of bugs crop up. I haven't been involved in Chromium
development in years, but it was amazing how many painting issues
would pop up, though perhaps not so amazing once you consider the
complexity involved.
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:
There are 3 approaches for "re-architecting" gui-style
components in the web DOM:
1. The approach taken by React which is to have a virtual DOM
(a pure javascript DOM).
2. The approach taken by Angular which is to have special
HTML-style attributes for templating functionality (like
for-loops) and use observers (track change events).
3. The approach taken by Web Components using shadow DOM
(invisible sub-DOM under custom elements/nodes).
I suggested something completely different in my post, chucking
the web stack altogether and starting from scratch. The
incremental approaches you suggest cannot really change much.
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
Smartphones support p2p? That's new to me. I thought they were
deliberately limited to servers.
Sounds like you're joking, but I was surprised to find that the
torrent client I ran on my Android tablet ran really fast, better
than the one I tried on my laptop. There's a p2p wave coming,
that will kill off most of this stupid cloud stuff, and take down
the web stack with it.
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.
No, it will not kill the web. Nothing can kill the web... you
want it, but it ain't happenin'.
Let's see, I present arguments why it will happen, while you
simply state that it cannot. Who is it that's thinking wishfully
here? :)
That approach is what modern javascript frameworks is supposed
to support! The web is further down that path than GUI libs.
Angular2 is basically a client side templating system, and so
is web components...
I'm not sure what you mean by the web going down that path, but
I'm talking about not sending GUI info whatsoever, ie going back
to something like plaintext email, where users simply send
messages back and forth and the client figures out how to render
it. Of course, it will be much more advanced than email, as the
messages will say what kind of data they contain, and the client
will construct UIs tailored for the various kinds of message data
it receives.
On Thursday, 7 January 2016 at 13:32:40 UTC, Russel Winder wrote:
On Wed, 2016-01-06 at 16:52 +0000, Joakim via Digitalmars-d
wrote:
[…]
We're talking cross-platform here, Swift isn't even in the
game till they get on other platforms than OSX/iOS.
There is an Ubuntu version that also works on Debian.
Yes, I've mentioned the in-progress linux port in this forum
several times: it's not finished yet.
[…]
Sure, COBOL is still around on some mainframe somewhere too,
but
almost nobody knows it exists! :D
But those that do get £150k+ and almost all are over 60.
Those are both signs that it's so obscure and limited that nobody
bothers to learn it. Great paying work for those who grew up
with it, but it's basically gone.
