subject:"Uphill"

On Mon, 01 Jun 2015 11:10:09 +, Ola Fosheim GrÃ¸stad wrote:

 But I think web browsers are slowly moving towards a situation where you
 soon can make sensible games in webgl + asm.js using home-made engines
 using native javascript (basically javascript targetting LLVM IR) or
 pnacl (LLVM IR).  So the distinction between native and non-native is
 getting blurred.

this whole thing is complete disaster. instead of designing a simple 
virtual machine with well-defined commands, they keep uglifying already 
ugly js. this is so bad that i believe that we will live with that for 
many years (really, i see that the worst technology with as many ugliness 
one can stuff into it usually wins; that web shit is ugly enough).

signature.asc
Description: PGP signature

Re: Uphill

2015-06-02 Thread Paulo Pinto via Digitalmars-d


On Tuesday, 2 June 2015 at 09:18:27 UTC, ketmar wrote:

On Mon, 01 Jun 2015 11:10:09 +, Ola Fosheim GrÃ¸stad wrote:

But I think web browsers are slowly moving towards a situation 
where you
soon can make sensible games in webgl + asm.js using home-made 
engines
using native javascript (basically javascript targetting 
LLVM IR) or
pnacl (LLVM IR).  So the distinction between native and 
non-native is

getting blurred.


this whole thing is complete disaster. instead of designing a 
simple
virtual machine with well-defined commands, they keep uglifying 
already
ugly js. this is so bad that i believe that we will live with 
that for
many years (really, i see that the worst technology with as 
many ugliness
one can stuff into it usually wins; that web shit is ugly 
enough).


Thankfully mobile OSes and desktop app stores seem to be on the 
right track to kill this.


http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html

Re: Uphill

2015-06-02 Thread Jacob Carlborg via Digitalmars-d


On 2015-06-02 08:32, Jonathan M Davis wrote:


D's semantics for __FILE__ and __LINE__ are so much better than C++'s. I
sorely miss D's semantics for them whenever I'm in C++. Having them get
the values from the call site rather than the declaration site is so
much more useful that it's not even funny.


Yeah, it's pretty cool. Swift also evaluates them in the same way as D, 
they even credited D in their blog post :)


--
/Jacob Carlborg

Re: Uphill

On Tue, 02 Jun 2015 23:51:13 +, weaselcat wrote:

 I, for one, am in favor of scrapping javascript and replacing it with
 lua. At least it has a decent JIT implementation.

it doesn't really matter. be it js, Lua, basic -- it's all equally bad. 
websites are not applications, and they doesn't need any scripting at all.

signature.asc
Description: PGP signature

Re: Uphill


On Tuesday, 2 June 2015 at 23:04:30 UTC, Nick Sabalausky wrote:

On 06/02/2015 05:44 AM, Paulo Pinto wrote:


Thankfully mobile OSes and desktop app stores seem to be on 
the right

track to kill this.

http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html


+1billion

My god it's nice to see that finally acknowledged.

Still, we web developers have spent the last six years in 
denial. Our working assumption has been that all web sites 
should be app-like, and therefore tooled up to the hilt.


Love it.

Thing is, one of the biggest reasons (likely even THE biggest 
reason) for the giant web for apps push was the whole 
no-install aspect. But then instead of actually, y'know, 
creating a no-install for applications, which could have been 
made and well-entrenched by now, the whole tech sector went and 
blew (probably) billions in $ and time retrofitting rich, 
dynamic experience into a document platform. And for all those 
blown resources, it's STILL at least as much of a broken mess 
as it was back when we still thought the IE/Netscape divergence 
was the greatest damage we could ever inflict our unfortunate 
web-based users.


And then on top of all that, 
Java/Flash/JS/basic-freaking-displaying-a-stupid-little-image 
demonstrated that even the whole purported sandboxing benefit 
of web apps (and VMs for that matter) was a near total bust.


I have to disable javascript on amazon.com to be able to use the 
site or else it brings my browser to a crawl.


I, for one, am in favor of scrapping javascript and replacing it 
with lua. At least it has a decent JIT implementation.


fun tidbit, back when the benchmark's game had luajit on it, 
luajit's _interpreter_ would beat V8 in every single benchmark.

Re: Uphill

On Tue, 02 Jun 2015 17:04:58 +, Ola Fosheim GrÃ¸stad wrote:

 On Tuesday, 2 June 2015 at 14:01:48 UTC, ketmar wrote:
 On Tue, 02 Jun 2015 13:43:29 +, Ola Fosheim GrÃÂ¸stad wrote:

 The situation that is emerging now is that you can integrate different
 browser technologies, and that browser vendors cooperate, and that
 makes all the difference.

 except you can't really integrate browser techs in your program, but
 you are required to integrate your program into browser. ;-)
 
 https://github.com/domokit/mojo

exactly! integrate your app into our stinkin' browser!

signature.asc
Description: PGP signature

Re: Uphill

On Tue, 02 Jun 2015 18:41:20 -0400, Nick Sabalausky wrote:

 On 06/02/2015 09:43 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
 ola.fosheim.grostad+dl...@gmail.com wrote:
 On Tuesday, 2 June 2015 at 13:37:47 UTC, ketmar wrote:
 and there was a thing that allows to use real applications without
 installing them... java web start! way too ahead of it's time,
 though...
 
 And 0install. (Though I admit I haven't checked in on that in a few
 years. But I always wanted to see that, or something like it, succeed.)

that's a different story. 0install is a self-containing bundle with all 
libs and so on. you got it, you run it, you use it.

and javaws is a something completely different. it doesn't even download 
the whole app at the start -- it can download only the classes it 
requires to run right now, downloading the rest on background or when 
user activates a feature for the first time.

besides, application is not a bundle, it's more like a browser cache. 
javaws can check for updates transparently and update only parts of 
application (think about fixing some bug in some classes -- whoa, only 
that classes need to be downloaded). and if user didn't use a feature 
that requres updated class yet, he doesn't even need to restart the app.

that said, javaws was a great idea -- killed by java and by being too 
advanced for it's time.

signature.asc
Description: PGP signature

Re: Uphill

2015-06-02 Thread Nick Sabalausky via Digitalmars-d


On 06/01/2015 01:08 AM, Paulo Pinto wrote:

On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:

On 1 June 2015 at 10:56, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On Sun, 31 May 2015 09:08:27 +, Joakim wrote:


Most mobile games are written in C/C++/OpenGL


that will fade away soon. it's safe to ignore that in long-time plan.


How so? Game dev's aren't moving away from native code any time soon...


  Objective-C, Swift, Java (as of Android 5) and .NET on mobile OSes
aren't no less native than D.

All of them compile to pure native code. There isn't any VM running on
the device.



That may be technically true, but the elimination of the VM still 
doesn't eliminate all the VM baggage.


The need for the languages to support their old VMs does still impose 
restrictions on the language designers, and thus language itself, that 
wouldn't need to exist had there been no VM at all.


Ex: No matter how aggressively AOT is used, manual memory management and 
controlling memory layout are still gonna be a royal pain in 
Java/Android5 and .NET. That's unlikely to go away without deprecating 
support for the VMs. But it IS likely to become more and more of a 
problem for those languages with performance being increasingly 
sensitive to data layout. Good news for D though ;)

Re: Uphill

2015-06-02 Thread Nick Sabalausky via Digitalmars-d


On 06/02/2015 07:26 AM, Paulo Pinto wrote:

On Tuesday, 2 June 2015 at 10:18:59 UTC, ketmar wrote:

On Tue, 02 Jun 2015 09:44:24 +, Paulo  Pinto wrote:


Thankfully mobile OSes and desktop app stores seem to be on the right
track to kill this.


yet they pushing cromeos and firefoxos...


FirefoxOS is going nowhere.

http://www.cnet.com/uk/news/mozilla-overhauls-firefox-smartphone-plan-to-focus-on-quality-not-cost/


As for Chromebooks, at least in Germany they are gathering dust on the
few stores that bother to try to sell them.

They might be on the Amazon US top charts, but I bet most of its users
are GNU/Linux users, wiping ChromeOS and using GNU/Linux instead.


Yes. That's also part of why I don't have much expectation for Taizen, 
either. It would already have enough of an uphill battle even if the 
technical aspect was total 100%. But by promoting HTML5-for-apps, they 
might very well be riding the wrong end of a last-decade fad.

Re: Uphill

2015-06-02 Thread Nick Sabalausky via Digitalmars-d


On 06/02/2015 05:44 AM, Paulo Pinto wrote:


Thankfully mobile OSes and desktop app stores seem to be on the right
track to kill this.

http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html


+1billion

My god it's nice to see that finally acknowledged.

Still, we web developers have spent the last six years in denial. Our 
working assumption has been that all web sites should be app-like, and 
therefore tooled up to the hilt.


Love it.

Thing is, one of the biggest reasons (likely even THE biggest reason) 
for the giant web for apps push was the whole no-install aspect. But 
then instead of actually, y'know, creating a no-install for 
applications, which could have been made and well-entrenched by now, the 
whole tech sector went and blew (probably) billions in $ and time 
retrofitting rich, dynamic experience into a document platform. And 
for all those blown resources, it's STILL at least as much of a broken 
mess as it was back when we still thought the IE/Netscape divergence was 
the greatest damage we could ever inflict our unfortunate web-based users.


And then on top of all that, 
Java/Flash/JS/basic-freaking-displaying-a-stupid-little-image 
demonstrated that even the whole purported sandboxing benefit of web 
apps (and VMs for that matter) was a near total bust.

Re: Uphill


On Tuesday, 2 June 2015 at 11:26:06 UTC, Paulo  Pinto wrote:

On Tuesday, 2 June 2015 at 10:18:59 UTC, ketmar wrote:

On Tue, 02 Jun 2015 09:44:24 +, Paulo  Pinto wrote:

Thankfully mobile OSes and desktop app stores seem to be on 
the right

track to kill this.


yet they pushing cromeos and firefoxos...


FirefoxOS is going nowhere.

http://www.cnet.com/uk/news/mozilla-overhauls-firefox-smartphone-plan-to-focus-on-quality-not-cost/

As for Chromebooks, at least in Germany they are gathering dust 
on the few stores that bother to try to sell them.


They might be on the Amazon US top charts, but I bet most of 
its users are GNU/Linux users, wiping ChromeOS and using 
GNU/Linux instead.


They're insanely popular, especially in educational environments. 
They do everything 98% of modern computer users do, which is 
generally check email, browse facebook, and use twitter.


my local public highschool ordered 800-some of them instead of 
upgrading their ipads(???), which would have cost far, far more. 
AFAIK they got the cool thinkpad versions.

Re: Uphill

2015-06-02 Thread Nick Sabalausky via Digitalmars-d

On 06/02/2015 09:43 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
ola.fosheim.grostad+dl...@gmail.com wrote:

On Tuesday, 2 June 2015 at 13:37:47 UTC, ketmar wrote:

and there was a thing that allows to use real applications without
installing them... java web start! way too ahead of it's time, though...


And 0install. (Though I admit I haven't checked in on that in a few 
years. But I always wanted to see that, or something like it, succeed.)



Java got itself a bad reputation in the 90s by providing a really poor
implementation.



Over the years, I've noticed that one of the best ways to kill an idea 
is to get everyone onboard a really, really bad implementation of it. 
(Ex, see: email vs exchange server and webmail clients, or static 
type system vs C++ and Java. Or IMHO: desktop/laptop computers vs 
every major desktop OS in existence ;))

Re: Uphill

2015-06-02 Thread Nick Sabalausky via Digitalmars-d


On 06/02/2015 07:51 PM, weaselcat wrote:


I have to disable javascript on amazon.com to be able to use the site or
else it brings my browser to a crawl.



When I finally figured out how to hack (by that I mean load it down 
with an endless list of add-ons and THEN waste an evening configuring) 
a modern Firefox to be tolerable, I thought I was finally in pretty 
decent good shape. (Well, at least until I was subjected to Mozilla's 
next couple rounds of UI blunders anyway...)


But now that I've finally accepted defeat on screw cellphones and been 
in the android habit for over a year, I've found myself in a new web 
hell: Now, no matter what mobile browser I use (Chrome, Firefox, 
Dolphin, or the amazingly-incorrectly named Internet), I have a choice:


A. Use the goofy, straightjacketed, sluggish mobile versions of 
websites (Wikipedia's is particularly bad, what with the auto-collapsing 
of every section on the entire page *while* you're scrolling and reading 
and then again every time you navigate back to a section you'd already 
re-expanded manually. Gee, thanks for closing my book, Wikipedia, never 
mind that I was reading it.)


Or B. Switch on request desktop site mode and get *improved* mobile UX 
but can easily take 30 seconds to a full minute (per page) before 
becoming responsive enough to accept clicking on a link. And that's for 
pages that aren't even dynamic beyond the initial flurry of JS onLoad() 
nonsense.


(Seriously, nearly anything that can be run during onLoad(), BELONGS on 
the server. Why would ANYONE in their right mind EVER make every single 
client do several Ajax/REST/whatever requests, THEN render the EXACT 
SAME page every time, for every single incoming request? Instead of, oh, 
I dunno, rendering the EXACT SAME page ONCE when content ACTUALLY 
changes and having the server spit THAT out to every request? Not 
enterprisey enough, I guess. Really, how often does a blog or news site 
actually post or modify an article? That exact same pages REALLY need to 
get completely regenerated on every hit even though NOTHING has changed 
since the last 500 hits?)


What I find very interesting is that it's consistently big businesses 
that have the most impossible-to-use sites. Ex: Just look at any site by 
SCE. You'd almost think they *don't* want any viewers and customers.

Re: Uphill

2015-06-02 Thread Joakim via Digitalmars-d


On Tuesday, 2 June 2015 at 22:38:47 UTC, weaselcat wrote:
They're insanely popular, especially in educational 
environments. They do everything 98% of modern computer users 
do, which is generally check email, browse facebook, and use 
twitter.


Not really.  While they do sell some in education, they were 1.8% 
of the PC market last year, much less than even Macs despite 
being much cheaper:


https://www.petri.com/chromebook-continues-to-be-a-tiny-slice-of-the-pc-market

Compare that 5.7 million in sales to a billion Android devices 
sold last year, native is definitely winning.

Re: Uphill


On Wednesday, 3 June 2015 at 03:41:39 UTC, Joakim wrote:

On Tuesday, 2 June 2015 at 22:38:47 UTC, weaselcat wrote:
They're insanely popular, especially in educational 
environments. They do everything 98% of modern computer users 
do, which is generally check email, browse facebook, and use 
twitter.


Not really.  While they do sell some in education, they were 
1.8% of the PC market last year, much less than even Macs 
despite being much cheaper:


https://www.petri.com/chromebook-continues-to-be-a-tiny-slice-of-the-pc-market

Compare that 5.7 million in sales to a billion Android devices 
sold last year, native is definitely winning.


chromebooks weren't even really usable until the latter half of 
2013/start of 2014 when Acer/HP/Dell/Toshiba/etc all got on board 
and it stopped being just Samsung making them. 2% is huge for 
less than 2 years. That was the chromebook revision that featured 
the ultra low power Haswell CPUs(2955U,) before that they were 
incredibly slow and suffered from general netbook issues.


And they're not even comparable to an android /phone/. Compare 
them to tablet sales.

Re: Uphill


On Wednesday, 3 June 2015 at 04:36:31 UTC, weaselcat wrote:

On Wednesday, 3 June 2015 at 03:41:39 UTC, Joakim wrote:

On Tuesday, 2 June 2015 at 22:38:47 UTC, weaselcat wrote:
They're insanely popular, especially in educational 
environments. They do everything 98% of modern computer users 
do, which is generally check email, browse facebook, and use 
twitter.


Not really.  While they do sell some in education, they were 
1.8% of the PC market last year, much less than even Macs 
despite being much cheaper:


https://www.petri.com/chromebook-continues-to-be-a-tiny-slice-of-the-pc-market

Compare that 5.7 million in sales to a billion Android devices 
sold last year, native is definitely winning.


chromebooks weren't even really usable until the latter half of 
2013/start of 2014 when Acer/HP/Dell/Toshiba/etc all got on 
board and it stopped being just Samsung making them. 2% is huge 
for less than 2 years. That was the chromebook revision that 
featured the ultra low power Haswell CPUs(2955U,) before that 
they were incredibly slow and suffered from general netbook 
issues.


And they're not even comparable to an android /phone/. Compare 
them to tablet sales.


Oh, I forgot the most important part.
The acer c720 was $200 on release, it was the cheapest chromebook 
to date. C700 launched at $349, and the samsung series 5 launched 
at $399 for reference.



Before the haswell iteration they just weren't ready to be a 
thing.

Re: Uphill

2015-06-02 Thread Paulo Pinto via Digitalmars-d


On Tuesday, 2 June 2015 at 10:18:59 UTC, ketmar wrote:

On Tue, 02 Jun 2015 09:44:24 +, Paulo  Pinto wrote:

Thankfully mobile OSes and desktop app stores seem to be on 
the right

track to kill this.


yet they pushing cromeos and firefoxos...


FirefoxOS is going nowhere.

http://www.cnet.com/uk/news/mozilla-overhauls-firefox-smartphone-plan-to-focus-on-quality-not-cost/

As for Chromebooks, at least in Germany they are gathering dust 
on the few stores that bother to try to sell them.


They might be on the Amazon US top charts, but I bet most of its 
users are GNU/Linux users, wiping ChromeOS and using GNU/Linux 
instead.

Re: Uphill


On Tuesday, 2 June 2015 at 09:18:27 UTC, ketmar wrote:
ugly js. this is so bad that i believe that we will live with 
that for many years


Possibly, but whatever is available on dominant browsers will be 
used. I many situations avoiding user-initiated installs are 
desirable. In most, actually...

Re: Uphill


On Tuesday, 2 June 2015 at 08:06:16 UTC, deadalnix wrote:
That would be even greater if they would be chained ! What a 
debug tool we could get out of this ! I know ! We should call 
them stack traces ! Catchy !


A stack trace is a dump of activation records, yes. But compile 
time introspection isn't actually a stack trace.

Re: Uphill

On Tue, 02 Jun 2015 13:43:29 +, Ola Fosheim GrÃ¸stad wrote:

 The situation that is emerging now is that you can integrate different
 browser technologies, and that browser vendors cooperate, and that makes
 all the difference.

except you can't really integrate browser techs in your program, but you 
are required to integrate your program into browser. ;-)

signature.asc
Description: PGP signature

Re: Uphill

On Tue, 02 Jun 2015 09:44:24 +, Paulo  Pinto wrote:

 Thankfully mobile OSes and desktop app stores seem to be on the right
 track to kill this.

yet they pushing cromeos and firefoxos...

signature.asc
Description: PGP signature

Re: Uphill

On Tue, 02 Jun 2015 10:37:40 +, Ola Fosheim GrÃ¸stad wrote:

 On Tuesday, 2 June 2015 at 09:18:27 UTC, ketmar wrote:
 ugly js. this is so bad that i believe that we will live with that for
 many years
 
 Possibly, but whatever is available on dominant browsers will be used. I
 many situations avoiding user-initiated installs are desirable. In most,
 actually...

and there was a thing that allows to use real applications without 
installing them... java web start! way too ahead of it's time, though...

signature.asc
Description: PGP signature

Re: Uphill


On Tuesday, 2 June 2015 at 13:37:47 UTC, ketmar wrote:
and there was a thing that allows to use real applications 
without
installing them... java web start! way too ahead of it's time, 
though...


Java got itself a bad reputation in the 90s by providing a really 
poor implementation.


The situation that is emerging now is that you can integrate 
different browser technologies, and that browser vendors 
cooperate, and that makes all the difference.

Re: Uphill


On Tuesday, 2 June 2015 at 14:01:48 UTC, ketmar wrote:

On Tue, 02 Jun 2015 13:43:29 +, Ola Fosheim GrÃ¸stad wrote:

The situation that is emerging now is that you can integrate 
different
browser technologies, and that browser vendors cooperate, and 
that makes

all the difference.


except you can't really integrate browser techs in your 
program, but you

are required to integrate your program into browser. ;-)


https://github.com/domokit/mojo

Re: Uphill


On Tuesday, 2 June 2015 at 06:32:43 UTC, Jonathan M Davis wrote:
D's semantics for __FILE__ and __LINE__ are so much better than 
C++'s. I sorely miss D's semantics for them whenever I'm in 
C++. Having them get the values from the call site rather than 
the declaration site is so much more useful that it's not even 
funny.


But you are referring to evaluation of default parameters. 
Evaluating default parameters at the call site can be 
problematic, so I don't think this is obvious at all.


All functions have a conceptual object which is the activation 
record, often represented by the stack frame (but in some 
languages a heap object). It would be reasonable to be able to 
query this activation record object, just like you have this 
that refers to the object of a method you could have a 
thisfunction.caller.lineno etc.

Re: Uphill

2015-06-02 Thread Jonathan M Davis via Digitalmars-d

On Tuesday, 2 June 2015 at 05:58:43 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 1 June 2015 at 18:54:18 UTC, Jonathan M Davis wrote:
It sounds to me like you're too against macros for your own 
good. Sure, they suck, but that's just life with C++ unless 
you want to make life harder for yourself. Simply wishing that 
the


But it doesn't make my C++ life harder, it makes my C++ life 
better. I don't need them, where I would use macros in C, I can 
usually make do with a constexpr or a template and get type 
safety and more readable code.


But I hope you see my point that __FILE__ and __LINE__ would be 
better done with introspection, also in D? Such magic cookies 
are signs of a lack of orthogonality.


(And it can be done as hidden registers/parameters in the 
language implementation so that you can have separate 
compilation and compile time evaluation of introspection where 
possible.)


D's semantics for __FILE__ and __LINE__ are so much better than 
C++'s. I sorely miss D's semantics for them whenever I'm in C++. 
Having them get the values from the call site rather than the 
declaration site is so much more useful that it's not even funny.


- Jonathan M Davis

Re: Uphill


On Monday, 1 June 2015 at 18:54:18 UTC, Jonathan M Davis wrote:
It sounds to me like you're too against macros for your own 
good. Sure, they suck, but that's just life with C++ unless you 
want to make life harder for yourself. Simply wishing that the


But it doesn't make my C++ life harder, it makes my C++ life 
better. I don't need them, where I would use macros in C, I can 
usually make do with a constexpr or a template and get type 
safety and more readable code.


But I hope you see my point that __FILE__ and __LINE__ would be 
better done with introspection, also in D? Such magic cookies 
are signs of a lack of orthogonality.


(And it can be done as hidden registers/parameters in the 
language implementation so that you can have separate compilation 
and compile time evaluation of introspection where possible.)

Re: Uphill

2015-06-01 Thread weaselcat via Digitalmars-d


On Monday, 1 June 2015 at 05:45:56 UTC, Paulo Pinto wrote:

On Monday, 1 June 2015 at 05:37:39 UTC, weaselcat wrote:

On Monday, 1 June 2015 at 05:20:27 UTC, Paulo Pinto wrote:

On Monday, 1 June 2015 at 05:14:59 UTC, Manu wrote:

On 1 June 2015 at 14:05, weaselcat via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:


On 1 June 2015 at 10:56, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:


On Sun, 31 May 2015 09:08:27 +, Joakim wrote:


Most mobile games are written in C/C++/OpenGL



that will fade away soon. it's safe to ignore that in 
long-time plan.



How so? Game dev's aren't moving away from native code any 
time soon...



a large portion of ios, android, and steam games use unity, 
which outside of

the core engine uses mono for programming.


Ah, yeah, but Unity itself is all C code. Every modern game 
has a

scripting solution, just that Unity has made that interface
front-and-center. Lots of meaty Unity plugins are native too.


Since last Unity version, C# is also compiled to native code 
via IL2CPP.


Only because of mono's license update, it's why they've been 
using a nearly decade old mono for so long.


No, only because they are too cheap to pay for the work of 
Xamarin.


I doubt that the amount of money wasted in Danish salaries for 
writing a .NET native compiler is cheaper than paying for the 
licenses.
AFAIK It's heavily based off of mono 2.0 code, it actually 
directly links against a lot of mono libraries to supply the 
CLR(or did, anyways.)


However riding the fame wave is easy to forget how unknown they 
were before they firstly added Mono to their JavaScript and Boo 
offerings, followed by porting the engine to Windows.

Boo requires mono ;)


So I don't really get why Xamarin gets the blame and Unity is 
portraid as the good guys.


For me they are just a company that got lucky using open source 
and now doesn't want to pay back.


Xamarin is doing great without their money.


I wasn't blaming Xamarin, unity owes a lot of their success to 
them - mono helped them greatly reduce the barriers of indie 
gamedev.

Re: Uphill


On Monday, 1 June 2015 at 10:37:31 UTC, ketmar wrote:
even PC games tend to migrate to Unity. mobile games will stop 
using home-
made engines very soon, as porting it to each platform is 
simply wasting
of time. so there will be old codebases which nobody will 
convert anyway,

and new codebases that using Unity, Cocos or something like it.


I don't know, it is hard to stand out if you build on Unity or 
Cocos unmodified.


But I think web browsers are slowly moving towards a situation 
where you soon can make sensible games in webgl + asm.js using 
home-made engines using native javascript (basically javascript 
targetting LLVM IR) or pnacl (LLVM IR).  So the distinction 
between native and non-native is getting blurred.


Just take a look at shadertoy and see what people can do in GL 
shaders that work on the web. And shaders are written to the 
current hardware if they are to perform well (so native).


Realtime javascript programming + WebGL quality is going to 
become more important than native binaries for games if the 
payment model issues find a solution.


I'd say the payment model that the app-stores provide are more 
important than distributing native code.


A web-based game has a distinct significant marketing advantage. 
Click on a web ad and instantly find yourself in a game world 
(free trial). Anything that takes installation is at a 
disadvantage. Unfortunately, anything that requires entering 
credit card info is at a disadvantage too...


so generating native code for mobile platforms target can be 
ignored,
it's investement that will take alot of time and efforts with 
very little

benefit.


I think the focus will shift from generating native code for 
specific hardware to generating code that effectively 
translates to native code for specific hardware. Which roughly 
is the same deal.


(Most games are scripty, yes, paper doll, cartoony 2D etc…)

Re: Uphill

2015-06-01 Thread ketmar via Digitalmars-d

On Mon, 01 Jun 2015 13:38:28 +1000, Manu via Digitalmars-d wrote:

 On 1 June 2015 at 10:56, ketmar via Digitalmars-d
 digitalmars-d@puremagic.com wrote:
 On Sun, 31 May 2015 09:08:27 +, Joakim wrote:

 Most mobile games are written in C/C++/OpenGL

 that will fade away soon. it's safe to ignore that in long-time plan.
 
 How so? Game dev's aren't moving away from native code any time soon...

even PC games tend to migrate to Unity. mobile games will stop using home-
made engines very soon, as porting it to each platform is simply wasting 
of time. so there will be old codebases which nobody will convert anyway, 
and new codebases that using Unity, Cocos or something like it.

so generating native code for mobile platforms target can be ignored, 
it's investement that will take alot of time and efforts with very little 
benefit.


signature.asc
Description: PGP signature

Re: Uphill

2015-06-01 Thread Atila Neves via Digitalmars-d


On Sunday, 31 May 2015 at 09:13:33 UTC, Ola Fosheim Grøstad wrote:

On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote:
While C++ programmers should try and avoid the preprocessor as 
much as possible, sometimes it just isn't possible to do so. 
There's just no other way to generate code sometimes. I know, 
I've tried.


In what case is this true? If it is only to avoid some boiler 
plate then it is not a good excuse, IMO. You can usually avoid 
macros by restructuring composition (using multiple layers of 
templates).


I'll take a macro over boilerplate any day of the week and twice 
on Sundays.


Atila

Re: Uphill

2015-06-01 Thread Jonathan M Davis via Digitalmars-d


On Monday, 1 June 2015 at 16:09:34 UTC, Dan Olson wrote:

Atila Neves atila.ne...@gmail.com writes:

On Sunday, 31 May 2015 at 09:13:33 UTC, Ola Fosheim Grøstad 
wrote:

On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote:
While C++ programmers should try and avoid the preprocessor 
as much
as possible, sometimes it just isn't possible to do so. 
There's
just no other way to generate code sometimes. I know, I've 
tried.


In what case is this true? If it is only to avoid some boiler 
plate
then it is not a good excuse, IMO. You can usually avoid 
macros by
restructuring composition (using multiple layers of 
templates).


I'll take a macro over boilerplate any day of the week and 
twice on

Sundays.


Timely!  I and stack overflow struggled for a couple hours to 
find an
equivalent C++ template for something that was straightforward 
with a

couple macros.


I use macros for stuff like exceptions all the time - e.g.

THROW(MyException, (This value is wrong: %d, foo));

The macro handles logging the exception, getting and setting the 
stacktrace on the exception, setting the file and line number of 
the exception, as well as constructing the string for the 
exception's message given the arguments - and of course finally 
throwing it. You _are_ still forced to call format in D (whereas 
that macro does it for you), but aside from that, the built-in 
exception stuff does all of that for you by simply throwing a new 
exception with a message, whereas C++ doesn't even come close. 
Without a macro, getting all of the information in C++ - and 
doing it consistently and correctly - would be a big problem.


Yes, macros should be avoided in general, but there are areas 
where you really don't have much choice, and saying that all 
macros are unequivocably bad is quite short-sighted. It's when 
macros are used when they aren't needed that it's a problem.


Coming out of college, I actually believed the dogma that all 
macros are bad, but experience has shown me that that's just not 
true. Sure, it would be nice if we had a better solution in C++, 
but sometimes we just don't.


- Jonathan M Davis

Re: Uphill


On Monday, 1 June 2015 at 16:09:34 UTC, Dan Olson wrote:
Timely!  I and stack overflow struggled for a couple hours to 
find an
equivalent C++ template for something that was straightforward 
with a

couple macros.


…but without an example it is hard to figure out what macros are 
needed for.

Re: Uphill

2015-06-01 Thread Dan Olson via Digitalmars-d

Atila Neves atila.ne...@gmail.com writes:

 On Sunday, 31 May 2015 at 09:13:33 UTC, Ola Fosheim Grøstad wrote:
 On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote:
 While C++ programmers should try and avoid the preprocessor as much
 as possible, sometimes it just isn't possible to do so. There's
 just no other way to generate code sometimes. I know, I've tried.

 In what case is this true? If it is only to avoid some boiler plate
 then it is not a good excuse, IMO. You can usually avoid macros by
 restructuring composition (using multiple layers of templates).

 I'll take a macro over boilerplate any day of the week and twice on
 Sundays.

Timely!  I and stack overflow struggled for a couple hours to find an
equivalent C++ template for something that was straightforward with a
couple macros.

Re: Uphill


On Monday, 1 June 2015 at 17:17:18 UTC, Ola Fosheim Grøstad wrote:

On Monday, 1 June 2015 at 16:57:00 UTC, Jonathan M Davis wrote:

I use macros for stuff like exceptions all the time - e.g.

THROW(MyException, (This value is wrong: %d, foo));


ick! Yes,  if you want stack-trace like information in 
release-builds you need to use the macro system, but that's 
because __FILE__ and __LINE__ are macros! That's a C deficiency.


The SAD thing here is that C++ actually do expensive stack 
introspection to unwind the stack based on return address, so the 
C++ runtime _could_ have been designed to look up call site 
information down the stack at runtime for low additional cost 
even with separate compilation, just like a high level language 
with stack introspection (in Python: 
inspect.stack()[1][0].f_lineno).


Not saying it is a good idea for a  system level language, but 
there is no technical reason to have macro warts like __LINE__ 
since the full C++ runtime already is bloated. And they could 
have gotten around it with by adding compile time introspection 
to the language too.


I'd say C has embraced macros for good reasons, as a minimalistic 
language design strategy  (newest C version using it for 
generics), but C++ has no longer an excuse for providing it.

Re: Uphill


On Monday, 1 June 2015 at 16:57:00 UTC, Jonathan M Davis wrote:

I use macros for stuff like exceptions all the time - e.g.

THROW(MyException, (This value is wrong: %d, foo));


ick! Yes,  if you want stack-trace like information in 
release-builds you need to use the macro system, but that's 
because __FILE__ and __LINE__ are macros! That's a C deficiency.  
 Usually your debugger gets you what you are looking for without 
this in debug builds, right?


And your THROW macro does not help when you receive exceptions 
from libraries.


(I don't use exceptions in C++)

even come close. Without a macro, getting all of the 
information in C++ - and doing it consistently and correctly - 
would be a big problem.


You would need a core dump ;^), but consistently… well, if you 
don't use libraries.


Yes, macros should be avoided in general, but there are areas 
where you really don't have much choice, and saying that all 
macros are unequivocably bad is quite short-sighted. It's when 
macros are used when they aren't needed that it's a problem.


It's a problem if you need it. It is almost always used to 
address language design flaws or other structural flaws.


Coming out of college, I actually believed the dogma that all 
macros are bad, but experience has shown me that that's just 
not true. Sure, it would be nice if we had a better solution in 
C++, but sometimes we just don't.


Yet, some of programmers don't actually use it anymore. In C you 
need it, it is an integral part of the language design. In C++ 
you can avoid it for the most part or replace it with external 
code-gen ( + makefile ).


(I sometimes use macros for constants like π out of habit, but I 
consider it a bad habit :-P.)

Re: Uphill


On Monday, 1 June 2015 at 18:44:02 UTC, Atila Neves wrote:

1. Backwards compatibility with existing C++ code
2. Being able to call C code that depends on macro definitons 
to actually work

3. The aforementioned cases in which templates can't do the job

With regards to #3: see when you use `mixin` in D code? You 
need a macro to achieve the equivalent task in C++. It's either 
that or boilerplate. Yay when I get to write D, boo when I just 
have to use C++. I feel dirty every time I type `#define`, but 
I'd feel dirtier if I repeated code all over the place. As 
always, it's a trade-off.


Yes, it is a trade-off. 20 years ago I tried to write terser code 
and do code gen with macros if possible, now I don't mind some 
repeated code as it is often easier to understand later on than 
indirections and I often find that building tables etc with an 
external tool is cleaner than macros anyway.


Some boiler plate, like SFINAE templates for testing type 
properties (does the class have a .length() function) look 
really ugly in C++ compared to newer languages, but I keep those 
tucked away in a header file, so it is not so bad. The good thing 
about this is that I don't get tempted to add SFINAE constructs I 
don't understand, which is an advantage when debugging...


I agree macros are needed for reasonable C interop, but 
_unfortunately_ the presence of macros is like a sleeping pillow 
for the C++ language-designers that allows them to add new pieces 
without getting down to a clean core language.


As for mixins, I don't like those either. You can often get 
around that with analysis that leads to a well thought out 
design, but I agree that  sometimes it is too late for that and 
boilerplate or macros ensue as a result of evolution… The 
question then is, would a lack of textual-substitution-first-aid 
have made the architect/programmers spend more time on design 
before coding?


So yes, providing and using macros is a trade-off, but I usually 
of the wrong kind. (E.g. a convenient excuse for not cleaning up 
the language or the application design)

Re: Uphill

2015-06-01 Thread Jonathan M Davis via Digitalmars-d


On Monday, 1 June 2015 at 17:17:18 UTC, Ola Fosheim Grøstad wrote:

On Monday, 1 June 2015 at 16:57:00 UTC, Jonathan M Davis wrote:

I use macros for stuff like exceptions all the time - e.g.

THROW(MyException, (This value is wrong: %d, foo));


ick! Yes,  if you want stack-trace like information in 
release-builds you need to use the macro system, but that's 
because __FILE__ and __LINE__ are macros! That's a C deficiency.
 Usually your debugger gets you what you are looking for 
without this in debug builds, right?


Goodness no. The exception needs to have that information in it, 
and I want exceptions logged so that I can track what happened 
without running in a debugger - and in release mode as well as 
debug mode. And it's not like I can necessarily reproduce the 
problem by rerunning the program anyway, so relying on the 
debugger for this sort of thing just doesn't fly in general, much 
as it might in simple cases.



(I don't use exceptions in C++)


My condolences.

It's a problem if you need it. It is almost always used to 
address language design flaws or other structural flaws.


Even if that's true, you're still stuck unless they fix the 
language. If/until C++ provides alternate solutions to the kinds 
of things that require macros right now, you need macros. I can 
always wish that C++ were better, but if I'm programming in C++, 
I have to deal with what it provides. The only way around that is 
to use another language (like D), and it that were an option, I 
probably wouldn't be using C++ in the first place.


It sounds to me like you're too against macros for your own good. 
Sure, they suck, but that's just life with C++ unless you want to 
make life harder for yourself. Simply wishing that the situation 
were better doesn't make it so.


- Jonathan M Davis

Re: Uphill

2015-06-01 Thread Atila Neves via Digitalmars-d

I'd say C has embraced macros for good reasons, as a 
minimalistic language design strategy  (newest C version using 
it for generics), but C++ has no longer an excuse for providing 
it.


Excuses for C++ :

1. Backwards compatibility with existing C++ code
2. Being able to call C code that depends on macro definitons to 
actually work

3. The aforementioned cases in which templates can't do the job

With regards to #3: see when you use `mixin` in D code? You need 
a macro to achieve the equivalent task in C++. It's either that 
or boilerplate. Yay when I get to write D, boo when I just have 
to use C++. I feel dirty every time I type `#define`, but I'd 
feel dirtier if I repeated code all over the place. As always, 
it's a trade-off.


Atila

Re: Uphill


On Sunday, 31 May 2015 at 09:08:28 UTC, Joakim wrote:

On Sunday, 31 May 2015 at 07:54:29 UTC, Paulo Pinto wrote:
However, C++ seems to be really into the route of library only 
language if we look at how it is available on mobile OS, only 
as complement to the main languages, not as the language under 
the spotlight.


Even on WinRT, C++/CX doesn't seem to get many followers 
outside the game developers world. To the point that Windows 
10 will also expose DirectX as WinRT components (on 8.x it is 
only directly available to C++).


You seem to dismiss game development as some niche, when it is 
one of the main killer apps driving the mobile boom.  Around 
80% of the top paid apps on iOS and Android are games:


https://www.appannie.com/apps/google-play/top/united-states/



I don't know how you got to understand that. My point was that 
C++/CX was pushed
to be at the same level as C# and VB.NET for WinRT applications, 
specially for

the MFC users.

However, apparently only game developers cared to pick it up and 
it has been ignored by traditional business developers, this was 
my point.


And a big complaint was having to manually make use of COM 
interop to access DirectX from .NET languages or being forced to 
write WinRT wrappers in C++/CX.


So as of Windows 10, DirectX is also exposed as WinRT compoments.



Most mobile games are written in C/C++/OpenGL, to the point 
where google even makes their Play Games Services APIs 
available as C++ headers, which they don't do for most of the 
rest of their Java-only APIs:


https://developers.google.com/games/services/cpp/gettingStartedAndroid



If you knew Android development, you would know that Google Games 
API was Java only.


Here are the videos from Google explaining to NDK users how to 
write themselves the respective JNI wrappers to the API.



https://www.youtube.com/watch?v=zst3R1OP6Y0

Only after a huge backslash from game developers did they port 
the API to C++.



In many cases those games are being written in Java (LibGDX), 
Unity, Cocos-2D, with C++ for the graphics and sound layer only.



As for WinRT, almost nobody uses Windows Phone and Windows 8 
was a huge bust, especially Modern apps, so that's neither here 
nor there.


Nobody in US, yes.


In South America, Eastern Europe and some southern Europe 
countries it is a bit different.


In Portugal for example, you will see more people with Android 
and Windows Phone than iOS.





You're right that google keeps pushing Java into the spotlight, 
but it is native development that is actually doing well, 
pushing Java back into library mode for google's Java-only 
APIs.  Perhaps that's why they compile Java Ahead-Of-Time since 
the recent Lollipop release. :)


They are late to the game there. As Android was the only platform 
still using a JIT.


iOS never used one and Windows Phone 8 always had .NET compiled 
to native code.


Dalvik was just a lame good enough VM implementation, so I 
guess they really needed to do something there.


--
Paulo

Re: Uphill

2015-05-31 Thread Manu via Digitalmars-d

On 1 June 2015 at 10:56, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On Sun, 31 May 2015 09:08:27 +, Joakim wrote:

 Most mobile games are written in C/C++/OpenGL

 that will fade away soon. it's safe to ignore that in long-time plan.

How so? Game dev's aren't moving away from native code any time soon...

Re: Uphill

2015-05-31 Thread weaselcat via Digitalmars-d


On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:

On 1 June 2015 at 10:56, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On Sun, 31 May 2015 09:08:27 +, Joakim wrote:


Most mobile games are written in C/C++/OpenGL


that will fade away soon. it's safe to ignore that in 
long-time plan.


How so? Game dev's aren't moving away from native code any time 
soon...


a large portion of ios, android, and steam games use unity, which 
outside of the core engine uses mono for programming.

Re: Uphill

2015-05-31 Thread ketmar via Digitalmars-d

On Sun, 31 May 2015 07:54:26 +, Paulo Pinto wrote:

 Using macros in C++ is considered bad style and a sign of someone
 sticking to Cisms.
 
 With meta-programming, templates, strong enums, const, constexpr and
 inline there are very few valid reasons to use macros other than C
 copy-paste compatibility.

and the fact that it's way easier to write a C-like macro than C++ 
template. ;-)

signature.asc
Description: PGP signature

Re: Uphill

2015-05-31 Thread ketmar via Digitalmars-d

On Sun, 31 May 2015 09:08:27 +, Joakim wrote:

 Most mobile games are written in C/C++/OpenGL

that will fade away soon. it's safe to ignore that in long-time plan.

signature.asc
Description: PGP signature

Re: Uphill


On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:

On 1 June 2015 at 10:56, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On Sun, 31 May 2015 09:08:27 +, Joakim wrote:


Most mobile games are written in C/C++/OpenGL


that will fade away soon. it's safe to ignore that in 
long-time plan.


How so? Game dev's aren't moving away from native code any time 
soon...


 Objective-C, Swift, Java (as of Android 5) and .NET on mobile 
OSes aren't no less native than D.


All of them compile to pure native code. There isn't any VM 
running on the device.


_
Paulo

Re: Uphill


On Monday, 1 June 2015 at 05:37:39 UTC, weaselcat wrote:

On Monday, 1 June 2015 at 05:20:27 UTC, Paulo Pinto wrote:

On Monday, 1 June 2015 at 05:14:59 UTC, Manu wrote:

On 1 June 2015 at 14:05, weaselcat via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:


On 1 June 2015 at 10:56, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:


On Sun, 31 May 2015 09:08:27 +, Joakim wrote:


Most mobile games are written in C/C++/OpenGL



that will fade away soon. it's safe to ignore that in 
long-time plan.



How so? Game dev's aren't moving away from native code any 
time soon...



a large portion of ios, android, and steam games use unity, 
which outside of

the core engine uses mono for programming.


Ah, yeah, but Unity itself is all C code. Every modern game 
has a

scripting solution, just that Unity has made that interface
front-and-center. Lots of meaty Unity plugins are native too.


Since last Unity version, C# is also compiled to native code 
via IL2CPP.


Only because of mono's license update, it's why they've been 
using a nearly decade old mono for so long.


No, only because they are too cheap to pay for the work of 
Xamarin.


I doubt that the amount of money wasted in Danish salaries for 
writing a .NET native compiler is cheaper than paying for the 
licenses.


However riding the fame wave is easy to forget how unknown they 
were before they firstly added Mono to their JavaScript and Boo 
offerings, followed by porting the engine to Windows.


So I don't really get why Xamarin gets the blame and Unity is 
portraid as the good guys.


For me they are just a company that got lucky using open source 
and now doesn't want to pay back.


Xamarin is doing great without their money.

Re: Uphill

2015-05-31 Thread Manu via Digitalmars-d

On 1 June 2015 at 14:05, weaselcat via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:

 On 1 June 2015 at 10:56, ketmar via Digitalmars-d
 digitalmars-d@puremagic.com wrote:

 On Sun, 31 May 2015 09:08:27 +, Joakim wrote:

 Most mobile games are written in C/C++/OpenGL


 that will fade away soon. it's safe to ignore that in long-time plan.


 How so? Game dev's aren't moving away from native code any time soon...


 a large portion of ios, android, and steam games use unity, which outside of
 the core engine uses mono for programming.

Ah, yeah, but Unity itself is all C code. Every modern game has a
scripting solution, just that Unity has made that interface
front-and-center. Lots of meaty Unity plugins are native too.

Re: Uphill


On Monday, 1 June 2015 at 05:14:59 UTC, Manu wrote:

On 1 June 2015 at 14:05, weaselcat via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:


On 1 June 2015 at 10:56, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:


On Sun, 31 May 2015 09:08:27 +, Joakim wrote:


Most mobile games are written in C/C++/OpenGL



that will fade away soon. it's safe to ignore that in 
long-time plan.



How so? Game dev's aren't moving away from native code any 
time soon...



a large portion of ios, android, and steam games use unity, 
which outside of

the core engine uses mono for programming.


Ah, yeah, but Unity itself is all C code. Every modern game has 
a

scripting solution, just that Unity has made that interface
front-and-center. Lots of meaty Unity plugins are native too.


Since last Unity version, C# is also compiled to native code via 
IL2CPP.

Re: Uphill

2015-05-31 Thread weaselcat via Digitalmars-d


On Monday, 1 June 2015 at 05:20:27 UTC, Paulo Pinto wrote:

On Monday, 1 June 2015 at 05:14:59 UTC, Manu wrote:

On 1 June 2015 at 14:05, weaselcat via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote:


On 1 June 2015 at 10:56, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:


On Sun, 31 May 2015 09:08:27 +, Joakim wrote:


Most mobile games are written in C/C++/OpenGL



that will fade away soon. it's safe to ignore that in 
long-time plan.



How so? Game dev's aren't moving away from native code any 
time soon...



a large portion of ios, android, and steam games use unity, 
which outside of

the core engine uses mono for programming.


Ah, yeah, but Unity itself is all C code. Every modern game 
has a

scripting solution, just that Unity has made that interface
front-and-center. Lots of meaty Unity plugins are native too.


Since last Unity version, C# is also compiled to native code 
via IL2CPP.


Only because of mono's license update, it's why they've been 
using a nearly decade old mono for so long.

Re: Uphill

2015-05-31 Thread via Digitalmars-d


On Sunday, 31 May 2015 at 06:03:36 UTC, Brian Schott wrote:
I find it hilarious that they can say that in a language that 
needs a preprocessor. Macros (and mixins) destroy AST-based 
tools, not things like static if that are right there in the 
AST.


That's not right. static if is just as bad as macros and 
affects partial evaluation. Besides I think C++ is moving away 
from macros, and I believe it is a stated goal for BS to do so. I 
don't use macros in C++ anymore.

Re: Uphill

2015-05-31 Thread Brian Schott via Digitalmars-d


On Sunday, 31 May 2015 at 04:18:32 UTC, Walter Bright wrote:

Furthermore, the adoption of this
feature would seriously compromise our ability to produce AST- 
based tools
for C++, and therefore put C++ at a further disadvantage 
compared to other

modern languages vis a vis tool support.


I find it hilarious that they can say that in a language that 
needs a preprocessor. Macros (and mixins) destroy AST-based 
tools, not things like static if that are right there in the 
AST.

Re: Uphill


On Sunday, 31 May 2015 at 06:03:36 UTC, Brian Schott wrote:

On Sunday, 31 May 2015 at 04:18:32 UTC, Walter Bright wrote:

Furthermore, the adoption of this
feature would seriously compromise our ability to produce 
AST- based tools
for C++, and therefore put C++ at a further disadvantage 
compared to other

modern languages vis a vis tool support.


I find it hilarious that they can say that in a language that 
needs a preprocessor. Macros (and mixins) destroy AST-based 
tools, not things like static if that are right there in the 
AST.


Using macros in C++ is considered bad style and a sign of someone 
sticking to Cisms.


With meta-programming, templates, strong enums, const, constexpr 
and inline there are very few valid reasons to use macros other 
than C copy-paste compatibility.


However, C++ seems to be really into the route of library only 
language if we look at how it is available on mobile OS, only as 
complement to the main languages, not as the language under the 
spotlight.


Even on WinRT, C++/CX doesn't seem to get many followers outside 
the game developers world. To the point that Windows 10 will also 
expose DirectX as WinRT components (on 8.x it is only directly 
available to C++).



--
Paulo

Re: Uphill

2015-05-31 Thread Atila Neves via Digitalmars-d

While C++ programmers should try and avoid the preprocessor as 
much as possible, sometimes it just isn't possible to do so. 
There's just no other way to generate code sometimes. I know, 
I've tried.


Atila

On Sunday, 31 May 2015 at 07:54:29 UTC, Paulo Pinto wrote:

On Sunday, 31 May 2015 at 06:03:36 UTC, Brian Schott wrote:

On Sunday, 31 May 2015 at 04:18:32 UTC, Walter Bright wrote:

Furthermore, the adoption of this
feature would seriously compromise our ability to produce 
AST- based tools
for C++, and therefore put C++ at a further disadvantage 
compared to other

modern languages vis a vis tool support.


I find it hilarious that they can say that in a language that 
needs a preprocessor. Macros (and mixins) destroy AST-based 
tools, not things like static if that are right there in the 
AST.


Using macros in C++ is considered bad style and a sign of 
someone sticking to Cisms.


With meta-programming, templates, strong enums, const, 
constexpr and inline there are very few valid reasons to use 
macros other than C copy-paste compatibility.


However, C++ seems to be really into the route of library only 
language if we look at how it is available on mobile OS, only 
as complement to the main languages, not as the language under 
the spotlight.


Even on WinRT, C++/CX doesn't seem to get many followers 
outside the game developers world. To the point that Windows 10 
will also expose DirectX as WinRT components (on 8.x it is only 
directly available to C++).



--
Paulo

Re: Uphill

2015-05-31 Thread Joakim via Digitalmars-d


On Sunday, 31 May 2015 at 07:54:29 UTC, Paulo Pinto wrote:
However, C++ seems to be really into the route of library only 
language if we look at how it is available on mobile OS, only 
as complement to the main languages, not as the language under 
the spotlight.


Even on WinRT, C++/CX doesn't seem to get many followers 
outside the game developers world. To the point that Windows 10 
will also expose DirectX as WinRT components (on 8.x it is only 
directly available to C++).


You seem to dismiss game development as some niche, when it is 
one of the main killer apps driving the mobile boom.  Around 80% 
of the top paid apps on iOS and Android are games:


https://www.appannie.com/apps/google-play/top/united-states/

Most mobile games are written in C/C++/OpenGL, to the point where 
google even makes their Play Games Services APIs available as C++ 
headers, which they don't do for most of the rest of their 
Java-only APIs:


https://developers.google.com/games/services/cpp/gettingStartedAndroid

As for WinRT, almost nobody uses Windows Phone and Windows 8 was 
a huge bust, especially Modern apps, so that's neither here nor 
there.


You're right that google keeps pushing Java into the spotlight, 
but it is native development that is actually doing well, pushing 
Java back into library mode for google's Java-only APIs.  Perhaps 
that's why they compile Java Ahead-Of-Time since the recent 
Lollipop release. :)

Re: Uphill


On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote:
While C++ programmers should try and avoid the preprocessor as 
much as possible, sometimes it just isn't possible to do so. 
There's just no other way to generate code sometimes. I know, 
I've tried.


Atila



Yes, there is. By using an external tool like in other languages. 
:)


However I do agree that for small things, it doesn't make sense 
to add an external dependency to the build.


--
Paulo

Re: Uphill

2015-05-31 Thread via Digitalmars-d


On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote:
While C++ programmers should try and avoid the preprocessor as 
much as possible, sometimes it just isn't possible to do so. 
There's just no other way to generate code sometimes. I know, 
I've tried.


In what case is this true? If it is only to avoid some boiler 
plate then it is not a good excuse, IMO. You can usually avoid 
macros by restructuring composition (using multiple layers of 
templates).


Anyway, cpp is a separate language from c++ so it only affects 
AST related tooling that modify source files where macros are 
present. It is overall more separate than builtin textual 
substitution (which is generally a bad idea) since it is a 
discrete independent step that a tool easily can apply before 
analysis.

Re: Uphill

2015-05-30 Thread Nick Sabalausky via Digitalmars-d


On 05/28/2015 04:55 AM, Chris wrote:

If it's for free, it
must be sh*t, I often hear people say. Maybe we should have a D
Enterprise Edition (DEE) and sell it for $1,000. Believe me, people
would take to it like ducks take to water.


Indeed. There's an MBA born every minute ;)

Re: Uphill

2015-05-30 Thread Rikki Cattermole via Digitalmars-d


On 31/05/2015 3:52 p.m., Manu via Digitalmars-d wrote:

On 28 May 2015 at 19:23, Rikki Cattermole via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On 28/05/2015 8:55 p.m., Chris wrote:


On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote:


On Wed, 27 May 2015 13:23:16 +, Paulo  Pinto wrote:


Only when I can sell D to customers that put money into this kind of
stuff



if customers are deciding which technologies to use... ok then, they can
do their work without my help, 'cause they are so knowledgeable.



It's funny that people spend millions on technologies that makes
mediocre or crap languages better, but they would never invest in
something like D, because they dread the investment. I think it's
because D doesn't have a price tag attached to it. If it's for free, it
must be sh*t, I often hear people say. Maybe we should have a D
Enterprise Edition (DEE) and sell it for $1,000. Believe me, people
would take to it like ducks take to water.



Or we put together a D consultancy firm, perhaps as part of D's future
foundation?

Starting at e.g. bug fixes ext. with price tag ranges on them.
Perhaps even a price tag on working on DIP's.


I would put my money on the table.


Now we just need either Walter or Andrei to weigh in on this idea.
And perhaps somebody willing to step up and lead this.

Laeeth Isharc perhaps? As I know he is interested in this area already 
and has the skills to back it up.

Re: Uphill

2015-05-30 Thread Manu via Digitalmars-d

On 28 May 2015 at 19:23, Rikki Cattermole via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On 28/05/2015 8:55 p.m., Chris wrote:

 On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote:

 On Wed, 27 May 2015 13:23:16 +, Paulo  Pinto wrote:

 Only when I can sell D to customers that put money into this kind of
 stuff


 if customers are deciding which technologies to use... ok then, they can
 do their work without my help, 'cause they are so knowledgeable.


 It's funny that people spend millions on technologies that makes
 mediocre or crap languages better, but they would never invest in
 something like D, because they dread the investment. I think it's
 because D doesn't have a price tag attached to it. If it's for free, it
 must be sh*t, I often hear people say. Maybe we should have a D
 Enterprise Edition (DEE) and sell it for $1,000. Believe me, people
 would take to it like ducks take to water.


 Or we put together a D consultancy firm, perhaps as part of D's future
 foundation?

 Starting at e.g. bug fixes ext. with price tag ranges on them.
 Perhaps even a price tag on working on DIP's.

I would put my money on the table.

Re: Uphill

2015-05-30 Thread Walter Bright via Digitalmars-d


On 5/24/2015 9:03 AM, Andrei Alexandrescu wrote:

On 5/24/15 1:20 AM, weaselcat wrote:

IMO I think the worst thing C++ has done is blatantly ignore features
that have been 'killer' in D(see: the reaction to the static_if proposal)


http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4461.html -- Andrei


The proposal:

Proposal: static if declaration
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf

The rebuttal:

Static If Considered
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf

Quoted from the rebuttal:


The static if feature recently proposed for C++ [1, 2] is fundamentally flawed,
and its adoption would be a disaster for the language. The feature provides a
single syntax with three distinct semantics, depending on the context of use.
The primary mechanism of these semantics is to avoid parsing in branches not
taken. This will make programs harder to read, understand, maintain, and
debug. It would also impede and possibly prevent the future development of
other language features, such as concepts. Furthermore, the adoption of this
feature would seriously compromise our ability to produce AST- based tools
for C++, and therefore put C++ at a further disadvantage compared to other
modern languages vis a vis tool support. It would make C++ a lower-level
language.

Re: Uphill

2015-05-30 Thread Andrei Alexandrescu via Digitalmars-d


On 5/30/15 8:55 PM, Rikki Cattermole wrote:

On 31/05/2015 3:52 p.m., Manu via Digitalmars-d wrote:

On 28 May 2015 at 19:23, Rikki Cattermole via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On 28/05/2015 8:55 p.m., Chris wrote:


On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote:


On Wed, 27 May 2015 13:23:16 +, Paulo  Pinto wrote:


Only when I can sell D to customers that put money into this kind of
stuff



if customers are deciding which technologies to use... ok then,
they can
do their work without my help, 'cause they are so knowledgeable.



It's funny that people spend millions on technologies that makes
mediocre or crap languages better, but they would never invest in
something like D, because they dread the investment. I think it's
because D doesn't have a price tag attached to it. If it's for
free, it
must be sh*t, I often hear people say. Maybe we should have a D
Enterprise Edition (DEE) and sell it for $1,000. Believe me, people
would take to it like ducks take to water.



Or we put together a D consultancy firm, perhaps as part of D's future
foundation?

Starting at e.g. bug fixes ext. with price tag ranges on them.
Perhaps even a price tag on working on DIP's.


I would put my money on the table.


Now we just need either Walter or Andrei to weigh in on this idea.
And perhaps somebody willing to step up and lead this.


Speaking only for myself, I'll look into how the foundation can 
facilitate such paid consultancy. (Probably poorly if it's non-profit.) 
The practical issue I see is with the geographical distribution of 
participants. Probably a strong entrepreneur could overcome these 
issues. -- Andrei

Re: Uphill

2015-05-28 Thread ketmar via Digitalmars-d

On Thu, 28 May 2015 08:55:57 +, Chris wrote:

 On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote:
 On Wed, 27 May 2015 13:23:16 +, Paulo  Pinto wrote:

 Only when I can sell D to customers that put money into this kind of
 stuff

 if customers are deciding which technologies to use... ok then, they
 can do their work without my help, 'cause they are so knowledgeable.
 
 It's funny that people spend millions on technologies that makes
 mediocre or crap languages better, but they would never invest in
 something like D, because they dread the investment. I think it's
 because D doesn't have a price tag attached to it. If it's for free, it
 must be sh*t, I often hear people say. Maybe we should have a D
 Enterprise Edition (DEE) and sell it for $1,000. Believe me, people
 would take to it like ducks take to water.

a nice idea. you don't want it for free? ok, we'll take your money if 
you want that. ;-)

signature.asc
Description: PGP signature

Re: Uphill

2015-05-28 Thread Chris via Digitalmars-d


On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote:

On Wed, 27 May 2015 13:23:16 +, Paulo  Pinto wrote:

Only when I can sell D to customers that put money into this 
kind of

stuff


if customers are deciding which technologies to use... ok then, 
they can

do their work without my help, 'cause they are so knowledgeable.


It's funny that people spend millions on technologies that makes 
mediocre or crap languages better, but they would never invest in 
something like D, because they dread the investment. I think it's 
because D doesn't have a price tag attached to it. If it's for 
free, it must be sh*t, I often hear people say. Maybe we should 
have a D Enterprise Edition (DEE) and sell it for $1,000. Believe 
me, people would take to it like ducks take to water.

Re: Uphill

2015-05-28 Thread Rikki Cattermole via Digitalmars-d


On 28/05/2015 8:55 p.m., Chris wrote:

On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote:

On Wed, 27 May 2015 13:23:16 +, Paulo  Pinto wrote:


Only when I can sell D to customers that put money into this kind of
stuff


if customers are deciding which technologies to use... ok then, they can
do their work without my help, 'cause they are so knowledgeable.


It's funny that people spend millions on technologies that makes
mediocre or crap languages better, but they would never invest in
something like D, because they dread the investment. I think it's
because D doesn't have a price tag attached to it. If it's for free, it
must be sh*t, I often hear people say. Maybe we should have a D
Enterprise Edition (DEE) and sell it for $1,000. Believe me, people
would take to it like ducks take to water.


Or we put together a D consultancy firm, perhaps as part of D's future 
foundation?


Starting at e.g. bug fixes ext. with price tag ranges on them.
Perhaps even a price tag on working on DIP's.

Re: Uphill

2015-05-28 Thread Chris via Digitalmars-d


On Thursday, 28 May 2015 at 09:23:07 UTC, Rikki Cattermole wrote:

On 28/05/2015 8:55 p.m., Chris wrote:

On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote:

On Wed, 27 May 2015 13:23:16 +, Paulo  Pinto wrote:

Only when I can sell D to customers that put money into this 
kind of

stuff


if customers are deciding which technologies to use... ok 
then, they can
do their work without my help, 'cause they are so 
knowledgeable.


It's funny that people spend millions on technologies that 
makes
mediocre or crap languages better, but they would never invest 
in
something like D, because they dread the investment. I think 
it's
because D doesn't have a price tag attached to it. If it's 
for free, it
must be sh*t, I often hear people say. Maybe we should have a 
D
Enterprise Edition (DEE) and sell it for $1,000. Believe me, 
people

would take to it like ducks take to water.


Or we put together a D consultancy firm, perhaps as part of D's 
future foundation?


Starting at e.g. bug fixes ext. with price tag ranges on them.
Perhaps even a price tag on working on DIP's.


Charge them and they will come! :-)

Re: Uphill

2015-05-27 Thread Chris via Digitalmars-d


On Tuesday, 26 May 2015 at 17:13:18 UTC, ketmar wrote:

On Tue, 26 May 2015 10:07:08 +, Chris wrote:

With Go I have the sinking feeling that it won't be able to 
contend with
C++ - or D for that matter. It took off due to Google and a 
fool-proof,
easy-to-use infrastructure. But it is way too limited and 
limiting to be
useful for more sophisticated tasks. Go's core devs even say 
that they
wanted it to be an easy-to-use, middle-of-the-road language 
for those
who work in their code mines, focusing on a high output, and 
it doesn't
matter, if you have to write the same function or for-loop 
with slight

modifications over and over and over again.


and it really doesn't matter... for Rob Pike. he also don't 
like shared
libraries and other bells and whistles. sometimes he is right, 
but

sometimes he is too radical.

Go is a java from google, aimed to raise a bunch of easily 
replaceable

programmers.


Exactly. As such it cannot be a serious contender as regards 
quality and versatility. There will be loads of Go code around, 
millions of for-loops on hundreds of thousands of servers, but I 
don't think it will go any further. Languages like D that are 
flexible and take useful concepts on board are much better suited 
for the programming challenges of the future (e.g. sophisticated 
high speed data processing algorithms).


The thing is that Java and Python (and soon Go?) hit a brick wall 
sooner or later. Huge efforts are made to improve speed, 
flexibility and whatnot (JIT, Cython etc). But the real problem 
lies in rigid and narrow minded design decisions taken more than 
a decade ago. This is why it's still back to C and C++ for 
serious stuff.[1]


[1] For more than a decade I've been hearing that with Java 
8.x/9.x/10.x this or that issue will be fixed, or that Python 
will soon have native performance. It never happens and it never 
will. It's time to move on. Take the D train. :-)



so, like java, Go can't be complicated. both Gosling and
Pike are highly talented people, and that talent helps them to 
design

dumb languages (which is not as easy as it seems ;-).

Re: Uphill

2015-05-27 Thread Paulo Pinto via Digitalmars-d

On Wednesday, 27 May 2015 at 10:01:35 UTC, Chris wrote:

On Tuesday, 26 May 2015 at 17:13:18 UTC, ketmar wrote:

On Tue, 26 May 2015 10:07:08 +, Chris wrote:

With Go I have the sinking feeling that it won't be able to
contend with
C++ - or D for that matter. It took off due to Google and a
fool-proof,
easy-to-use infrastructure. But it is way too limited and
limiting to be
useful for more sophisticated tasks. Go's core devs even say
that they
wanted it to be an easy-to-use, middle-of-the-road language
for those
who work in their code mines, focusing on a high output, and
it doesn't
matter, if you have to write the same function or for-loop
with slight

modifications over and over and over again.

and it really doesn't matter... for Rob Pike. he also don't
like shared
libraries and other bells and whistles. sometimes he is right,
but

sometimes he is too radical.

Go is a java from google, aimed to raise a bunch of easily
replaceable

programmers.

Exactly. As such it cannot be a serious contender as regards
quality and versatility. There will be loads of Go code around,
millions of for-loops on hundreds of thousands of servers, but
I don't think it will go any further. Languages like D that are
flexible and take useful concepts on board are much better
suited for the programming challenges of the future (e.g.
sophisticated high speed data processing algorithms).

The thing is that Java and Python (and soon Go?) hit a brick
wall sooner or later. Huge efforts are made to improve speed,
flexibility and whatnot (JIT, Cython etc). But the real problem
lies in rigid and narrow minded design decisions taken more
than a decade ago. This is why it's still back to C and C++ for
serious stuff.[1]

[1] For more than a decade I've been hearing that with Java
8.x/9.x/10.x this or that issue will be fixed, or that Python
will soon have native performance. It never happens and it
never will. It's time to move on. Take the D train. :-)

Only when I can sell D to customers that put money into this kind
of stuff

http://www.azulsystems.com/press-2014/azul-systems-and-orc-partner-to-enable-smarter-high-performance-trading

http://chronicle.software/products/koloboke-collections/

http://devblogs.nvidia.com/parallelforall/next-wave-enterprise-performance-java-power-systems-nvidia-gpus/

Ecosystems count more than language features.

--
Paulo

Re: Uphill

2015-05-27 Thread ketmar via Digitalmars-d

On Wed, 27 May 2015 13:23:16 +, Paulo  Pinto wrote:

 Only when I can sell D to customers that put money into this kind of
 stuff

if customers are deciding which technologies to use... ok then, they can 
do their work without my help, 'cause they are so knowledgeable.

signature.asc
Description: PGP signature

Re: Uphill

2015-05-26 Thread weaselcat via Digitalmars-d


On Tuesday, 26 May 2015 at 08:35:46 UTC, ketmar wrote:
On Tue, 26 May 2015 07:43:59 +0200, Iain Buclaw via 
Digitalmars-d wrote:


p.s.

I suspect the most common beginner bugs occurs when using 
right accessor
on the wrong tree causes an ICE at runtime in 'some obscure 
location'.


Incase you intend to dabble again in the future as more parts 
move over
to C++, so far, RTL, GIMPLE, callgraphs, and almost all 
synthetic value
types have been switched over. When trees finally get shunted 
across,

you'll finally benefit from compile-time verified AST.


that's why i have mixed feelings about C++ code in GCC. 
although i really

like it being C only, compile-time checking is very valuable.


just convince the gcc dev team to port it to D ;)

Re: Uphill

2015-05-26 Thread Laeeth Isharc via Digitalmars-d


On Sunday, 24 May 2015 at 22:24:40 UTC, Iain Buclaw wrote:

The compiler
situation feels odd, LDC and GDC have very few contributors 
despite being
better than dmd at optimizing and providing a lot of extra 
perks


I find the situation being like at university looking for 
grants or funding, and constantly being told. 'Oh yes, it is 
important what you are doing, and you must keep doing it as it 
is pivotal for future success.  But no, we won't help you.'


I wish I could do something to help, but unfortunately I can't 
think of much for now.  (C++ coding and learning compiler 
internals exceeds what's possible as things stand).  If things 
should take off on the business front, I'll try to help where I 
can, but that's a matter of a few years in the best case.


Anyway, I very much appreciate the work of you and your 
colleagues on GDC.

Re: Uphill

On Tue, 26 May 2015 04:07:40 +, weaselcat wrote:

 while I agree with your ideological standpoint on GPL, gcc is virtually
 inaccessible to anyone who isn't already familiar with the codebase in
 comparison to llvm. At least it seems gcc is interested in changing
 this.

funny, that movement in GCC is in major part stimulated by LLVM. and 
that's why i'm not saying LLVM must die! ;-)

signature.asc
Description: PGP signature

Re: Uphill

On Tue, 26 May 2015 07:43:59 +0200, Iain Buclaw via Digitalmars-d wrote:

p.s.

 I suspect the most common beginner bugs occurs when using right accessor
 on the wrong tree causes an ICE at runtime in 'some obscure location'.
 
 Incase you intend to dabble again in the future as more parts move over
 to C++, so far, RTL, GIMPLE, callgraphs, and almost all synthetic value
 types have been switched over. When trees finally get shunted across,
 you'll finally benefit from compile-time verified AST.

that's why i have mixed feelings about C++ code in GCC. although i really 
like it being C only, compile-time checking is very valuable.

signature.asc
Description: PGP signature

Re: Uphill

On Tue, 26 May 2015 07:43:59 +0200, Iain Buclaw via Digitalmars-d wrote:

 On 26 May 2015 00:30, ketmar via Digitalmars-d 
 digitalmars-d@puremagic.com wrote:

thank you for the info. ah, if only i have a time freezing device to 
make my days longer... ;-)

signature.asc
Description: PGP signature

Re: Uphill

2015-05-26 Thread Chris via Digitalmars-d


On Sunday, 24 May 2015 at 21:35:13 UTC, bachmeier wrote:

On Sunday, 24 May 2015 at 20:36:47 UTC, Laeeth Isharc wrote:
Without wishing to dwell on the negatives of alternatives, 
might I ask what made you decide to settle on D?  Do you have 
collaborators who write code and, if so, how did the 
discussions with them go about this?  For your use case, what 
have been the main gains you have seen and how long did it 
take before these started to come through?


I'm not weaselcat, but I'm an academic and I also tried out 
Rust before using D. I came to the conclusion that there was no 
way I could ever expect any collaborator to use Rust. The 
syntax was crazy. The requirement to study memory management 
issues (something completely irrelevant) before even reading 
the code was a non-starter. It's just a complicated language 
that is not suited for the average programmer.


D is different. As long as I avoid templates, it's easy to read 
the code I've written, without any experience with the 
language. I tried C++ (Dirk Eddelbuettel devoted a section of 
his Rcpp book to an example I contributed), Rust, and Go. The 
other realistic alternative was Go, but I chose D as a matter 
of personal preference.


This is an often underestimated aspect. Code that looks clean and 
pretty makes programming much more enjoyable and thus boosts 
productivity. If a language is not nice to look at, it puts 
people off. Not only because it makes code less readable, it is 
also aesthetically off-putting, which is purely psychological, 
but real nonetheless. D is quite clean for the most part and you 
can easily discern the shape of a program (even people who've 
never used D, can make sense of it by looking at it). If a 
language like Rust introduces convoluted syntax for even the 
simplest tasks, then it will put people off, both in an aesthetic 
sense and as far as understanding the code is concerned (not to 
mention all the typing!). I think this is one of the reasons 
Python took off. It's nice to look at.


With Go I have the sinking feeling that it won't be able to 
contend with C++ - or D for that matter. It took off due to 
Google and a fool-proof, easy-to-use infrastructure. But it is 
way too limited and limiting to be useful for more sophisticated 
tasks. Go's core devs even say that they wanted it to be an 
easy-to-use, middle-of-the-road language for those who work in 
their code mines, focusing on a high output, and it doesn't 
matter, if you have to write the same function or for-loop with 
slight modifications over and over and over again.


Nim looks interesting, though. It combines nice features with 
Python's cleanliness. It is just this type of language people at 
universities and coders-by-accident love. Ha ha ha.

Re: Uphill

2015-05-26 Thread Ziad Hatahet via Digitalmars-d

On Sun, May 24, 2015 at 12:06 PM, weaselcat via Digitalmars-d 
digitalmars-d@puremagic.com wrote:


 Furthermore, I strongly dislike that Rust has made it completely
 impossible to opt out of bounds checking without annotating your code with
 unsafe.


Using iterators should cause bounds checking to be eliminated; otherwise,
it should be a bug.

--
Ziad

Re: Uphill

On Tue, 26 May 2015 10:07:08 +, Chris wrote:

 With Go I have the sinking feeling that it won't be able to contend with
 C++ - or D for that matter. It took off due to Google and a fool-proof,
 easy-to-use infrastructure. But it is way too limited and limiting to be
 useful for more sophisticated tasks. Go's core devs even say that they
 wanted it to be an easy-to-use, middle-of-the-road language for those
 who work in their code mines, focusing on a high output, and it doesn't
 matter, if you have to write the same function or for-loop with slight
 modifications over and over and over again.

and it really doesn't matter... for Rob Pike. he also don't like shared 
libraries and other bells and whistles. sometimes he is right, but 
sometimes he is too radical.

Go is a java from google, aimed to raise a bunch of easily replaceable 
programmers. so, like java, Go can't be complicated. both Gosling and 
Pike are highly talented people, and that talent helps them to design 
dumb languages (which is not as easy as it seems ;-).

signature.asc
Description: PGP signature

Re: Uphill

On Tue, 26 May 2015 08:45:01 +, weaselcat wrote:

 that's why i have mixed feelings about C++ code in GCC. although i
 really like it being C only, compile-time checking is very valuable.
 
 just convince the gcc dev team to port it to D ;)

ah, that would be *ideal*... but ok, let my Secret Plan work: first they 
will port GCC to simplified C++, and then... tadam! MagicPort Adjusted, D 
everywhere, C++-lovers are crying!

signature.asc
Description: PGP signature

Re: Uphill

On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d wrote:

 I find the situation being like at university looking for
 grants or funding, and constantly being told. #39;Oh yes, it is
 important what you are doing, and you must keep doing it as it is
 pivotal for future success.Â  But no, we won#39;t help you.#39;

that's 'cause GCC is untameable beast for average Joe like me, for 
example. ;-)

signature.asc
Description: PGP signature

Re: Uphill

2015-05-25 Thread via Digitalmars-d


On Sunday, 24 May 2015 at 16:03:30 UTC, Andrei Alexandrescu wrote:

On 5/24/15 1:20 AM, weaselcat wrote:
IMO I think the worst thing C++ has done is blatantly ignore 
features
that have been 'killer' in D(see: the reaction to the 
static_if proposal)


http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4461.html 
-- Andrei


Quote: always going to establish a new scope.

This alone will make it much less powerful that D's static if.

Re: Uphill

2015-05-25 Thread via Digitalmars-d


On Sunday, 24 May 2015 at 19:06:28 UTC, weaselcat wrote:
Furthermore, I strongly dislike that Rust has made it 
completely impossible to opt out of bounds checking without 
annotating your code with unsafe.


But this is exactly the situation in D, isn't it? As soon as you 
use `arr.ptr[i]`, you're no longer @safe. Or do you mean that 
there's no command-line switch equivalent to -noboundscheck?

Re: Uphill

2015-05-25 Thread Iain Buclaw via Digitalmars-d

On 25 May 2015 09:45, ketmar via Digitalmars-d 
digitalmars-d@puremagic.com wrote:

 On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d wrote:

  I find the situation being like at university looking for
  grants or funding, and constantly being told. #39;Oh yes, it is
  important what you are doing, and you must keep doing it as it is
  pivotal for future success.  But no, we won#39;t help you.#39;

 that's 'cause GCC is untameable beast for average Joe like me, for
 example. ;-)

Both have equal complexity, so that is no excuse.  DMD just operates at a
lower level, on a smaller scale, and forces you to think about the effect
on generated object code.

Re: Uphill

2015-05-25 Thread Andrei Alexandrescu via Digitalmars-d

On 5/25/15 3:51 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net 
wrote:

On Sunday, 24 May 2015 at 16:03:30 UTC, Andrei Alexandrescu wrote:

On 5/24/15 1:20 AM, weaselcat wrote:

IMO I think the worst thing C++ has done is blatantly ignore features
that have been 'killer' in D(see: the reaction to the static_if
proposal)


http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4461.html --
Andrei


Quote: always going to establish a new scope.

This alone will make it much less powerful that D's static if.


I know. Politics does have a cost. -- Andrei

Re: Uphill

On Mon, 25 May 2015 16:59:48 +0200, Iain Buclaw via Digitalmars-d wrote:

 On 25 May 2015 09:45, ketmar via Digitalmars-d 
 digitalmars-d@puremagic.com wrote:

 On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d
 wrote:

  I find the situation being like at university looking for grants or
  funding, and constantly being told. #39;Oh yes, it is important what
  you are doing, and you must keep doing it as it is pivotal for future
  success.  But no, we won#39;t help you.#39;

 that's 'cause GCC is untameable beast for average Joe like me, for
 example. ;-)
 
 Both have equal complexity, so that is no excuse.  DMD just operates at
 a lower level, on a smaller scale, and forces you to think about the
 effect on generated object code.

i'm afraid that they doesn't have equal complexity. i can read DMD code 
(ok, even backend, it's hard, but doable), but i cannot read GCC backend 
code in the same amount of time. and there are alot more things i have to 
know to understand GDC. i made some trivial fixes in DMD backend, yet i 
don't even know where to start to understand at least *something* in GCC.

signature.asc
Description: PGP signature

Re: Uphill

2015-05-25 Thread Iain Buclaw via Digitalmars-d

On 25 May 2015 at 18:14, ketmar via Digitalmars-d 
digitalmars-d@puremagic.com wrote:

 On Mon, 25 May 2015 16:59:48 +0200, Iain Buclaw via Digitalmars-d wrote:

  On 25 May 2015 09:45, ketmar via Digitalmars-d 
  digitalmars-d@puremagic.com wrote:
 
  On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d
  wrote:
 
   I find the situation being like at university looking for grants or
   funding, and constantly being told. #39;Oh yes, it is important what
   you are doing, and you must keep doing it as it is pivotal for future
   success.  But no, we won#39;t help you.#39;
 
  that's 'cause GCC is untameable beast for average Joe like me, for
  example. ;-)
 
  Both have equal complexity, so that is no excuse.  DMD just operates at
  a lower level, on a smaller scale, and forces you to think about the
  effect on generated object code.

 i'm afraid that they doesn't have equal complexity. i can read DMD code
 (ok, even backend, it's hard, but doable), but i cannot read GCC backend
 code in the same amount of time. and there are alot more things i have to
 know to understand GDC. i made some trivial fixes in DMD backend, yet i
 don't even know where to start to understand at least *something* in GCC.


Yes, they do.  The key difference is that GCC doesn't require you to delve
into it's backend, as a language implementer, you only need to think of how
the code should be represented in it's tree language (ie:
http://icps.u-strasbg.fr/~pop/gcc-ast.html) - Because of this, I never need
to look at assembly dumps to understand what is going on, only tree dumps,
which are handily outputted in a C-style format with
-fdump-tree-original=stdout.

Re: Uphill

On Mon, 25 May 2015 18:34:24 +0200, Iain Buclaw via Digitalmars-d wrote:

 Yes, they do.  The key difference is that GCC doesn't require you to
 delve into it's backend, as a language implementer, you only need to
 think of how the code should be represented in it's tree language (ie:
 http://icps.u-strasbg.fr/~pop/gcc-ast.html) - Because of this, I never
 need to look at assembly dumps to understand what is going on, only tree
 dumps,
 which are handily outputted in a C-style format with
 -fdump-tree-original=stdout.

yet there are no well-documented samples for GCC, like let's create a 
frontend for simple C-like language, step by step (at least not in the 
distribution). there are none for DMD too, but DMD code can be read and 
understood enough to work with it. and reading GCC code is out of 
question, it's way too huge.

i once thinking about using GCC as backend for my experimental language, 
and ended writing my own codegen. it does awful job, spitting almost non-
optimised code, but it was at least maintainable. with GCC i never got 
far enough, it's too complex and poorly documented.

sure, that is not your fault, i'm simply trying to explain why there are 
almost no people working on GDC. it's just too hard. or it seems to be 
hard, but without good GCC documentation it's almost the same.

signature.asc
Description: PGP signature

Re: Uphill


On Monday, 25 May 2015 at 22:27:10 UTC, ketmar wrote:
On Mon, 25 May 2015 18:34:24 +0200, Iain Buclaw via 
Digitalmars-d wrote:


Yes, they do.  The key difference is that GCC doesn't require 
you to
delve into it's backend, as a language implementer, you only 
need to
think of how the code should be represented in it's tree 
language (ie:
http://icps.u-strasbg.fr/~pop/gcc-ast.html) - Because of this, 
I never
need to look at assembly dumps to understand what is going on, 
only tree

dumps,
which are handily outputted in a C-style format with
-fdump-tree-original=stdout.


yet there are no well-documented samples for GCC, like let's 
create a
frontend for simple C-like language, step by step (at least 
not in the
distribution). there are none for DMD too, but DMD code can be 
read and
understood enough to work with it. and reading GCC code is out 
of

question, it's way too huge.

i once thinking about using GCC as backend for my experimental 
language,
and ended writing my own codegen. it does awful job, spitting 
almost non-
optimised code, but it was at least maintainable. with GCC i 
never got

far enough, it's too complex and poorly documented.

sure, that is not your fault, i'm simply trying to explain why 
there are
almost no people working on GDC. it's just too hard. or it 
seems to be

hard, but without good GCC documentation it's almost the same.


then contribute to LDC?

Re: Uphill

On Mon, 25 May 2015 22:46:51 +, weaselcat wrote:

 then contribute to LDC?

sorry, not interested in LLVM in any way. not that it should die, but 
i don't care if it exists or not.

signature.asc
Description: PGP signature

Re: Uphill


On Tuesday, 26 May 2015 at 00:24:20 UTC, ketmar wrote:

On Mon, 25 May 2015 23:19:26 +, weaselcat wrote:


On Monday, 25 May 2015 at 22:48:59 UTC, ketmar wrote:

On Mon, 25 May 2015 22:46:51 +, weaselcat wrote:


then contribute to LDC?


sorry, not interested in LLVM in any way. not that it should 
die, but

i don't care if it exists or not.


LLVM addresses every issue you complained about in GCC.


non-GPL. that means non-existent for me.


you're aware that the dmd backend is proprietary, right?

Re: Uphill

On Mon, 25 May 2015 23:19:26 +, weaselcat wrote:

 On Monday, 25 May 2015 at 22:48:59 UTC, ketmar wrote:
 On Mon, 25 May 2015 22:46:51 +, weaselcat wrote:

 then contribute to LDC?

 sorry, not interested in LLVM in any way. not that it should die, but
 i don't care if it exists or not.
 
 LLVM addresses every issue you complained about in GCC.

non-GPL. that means non-existent for me.

signature.asc
Description: PGP signature

Re: Uphill


On Monday, 25 May 2015 at 22:48:59 UTC, ketmar wrote:

On Mon, 25 May 2015 22:46:51 +, weaselcat wrote:


then contribute to LDC?


sorry, not interested in LLVM in any way. not that it should 
die, but

i don't care if it exists or not.


LLVM addresses every issue you complained about in GCC.

Re: Uphill

On Tue, 26 May 2015 00:53:35 +, weaselcat wrote:

 you're aware that the dmd backend is proprietary, right?

of course. that's why i never submitted any fixes to DMD backend, 
although i have some.

signature.asc
Description: PGP signature

Re: Uphill