www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OSCON 2012 notes

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I'm back from OSCON 2012, where my talk has enjoyed a somewhat 
unexpected good reception (OSCON is not the most down-D's-alley audience).

The talk abstract is at 
http://www.oscon.com/oscon2012/public/schedule/detail/23888 and the 
slides are at 
http://www.slideshare.net/andreialexandrescu1/generic-program
ing-galore-using-d. 
There will be a video up some time in the future for the entire talk.

It would be really cool if we could enhance D's offering in the Web 
arena. People were really attracted by the notion of a language not 
requiring many type annotations, yet with the exploratory feel of a 
dynamic language. A small framework or simply a couple of standard 
library components that would make e.g. Vladimir's work (on 
forum.lang.org) or Adam Ruppe's work easy to assemble from preexisting 
parts would be just awesome.

Go has enjoyed a stronger presence in numbers: 
http://www.oscon.com/oscon2012/public/schedule/detail/23910, 
http://www.oscon.com/oscon2012/public/schedule/detail/23906, but my 
perception (confirmed by ratings) is that the reception has been a tad 
colder.


Cheers,

Andrei
Jul 20 2012
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 21.07.2012 07:14, schrieb Andrei Alexandrescu:
 I'm back from OSCON 2012, where my talk has enjoyed a somewhat
 unexpected good reception (OSCON is not the most down-D's-alley audience).

 The talk abstract is at
 http://www.oscon.com/oscon2012/public/schedule/detail/23888 and the
 slides are at
 http://www.slideshare.net/andreialexandrescu1/generic-programming-galore-using-d.
 There will be a video up some time in the future for the entire talk.

Thanks for putting them up. Eagerly waiting for the video.
 It would be really cool if we could enhance D's offering in the Web
 arena. People were really attracted by the notion of a language not
 requiring many type annotations, yet with the exploratory feel of a
 dynamic language. A small framework or simply a couple of standard
 library components that would make e.g. Vladimir's work (on
 forum.lang.org) or Adam Ruppe's work easy to assemble from preexisting
 parts would be just awesome.

We need something like std.database for web development, which as far as I know is currently on hold. WinRT support would also be a nice feature. Need to spend some time checking how to work with type libraries.
 Go has enjoyed a stronger presence in numbers:
 http://www.oscon.com/oscon2012/public/schedule/detail/23910,
 http://www.oscon.com/oscon2012/public/schedule/detail/23906, but my
 perception (confirmed by ratings) is that the reception has been a tad
 colder.

Go earns a lot of brownie points from geeks due to Google factor and having Plan 9 authors in the team. I've watched most of their presentations, to be honest their typical web application PR demo with goroutines, can be easily reproduced in many languages. Even the features that are sold as why one should pick Go, are no novelty for the developers that have good CS backgrounds in compiler design and implementation. I already had many discussions on gonuts regarding lack of abstractions in the language like enumerations and generics, or the distinction between make and new. The Go community seems to think it is ok to make use of code generation tools, like the C++ compiler vendors used to do until around 1993, when preprocessor tricks and external tools were used as a kind of generics. With Go 2, years away this situation is hardly going to change. After becoming disapointed with Go leaving in the past, I've come to the conclusion that between the two, D is a much better choice. -- Paulo
Jul 20 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, July 21, 2012 08:48:57 Paulo Pinto wrote:
 After becoming disapointed with Go leaving in the past, I've come to the
 conclusion that between the two, D is a much better choice.

I still need to study up on Go one of these days (along with a variety of other languages which are on my to-learn list), but the more I learn about it, the less I understand why Go and D are treated as competitors. I guess it's because of the systems language moniker (though Go doesn't mean it in the same was as C++ and D, so that skews things already), but Go and D are just so radically different in their basic approaches and philosophies, that I would expect that the folks who like one would dislike the other in most cases. They're just so completely different that I wouldn't expect them to really compete with one another save for the fact that developers only have so much time to check out new languages, so if one's getting a lot more attention, that could reduce how many people check out the other one, even if most people who check out the first one don't end up liking it. - Jonathan M Davis
Jul 21 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 21.07.2012 10:20, schrieb Jonathan M Davis:
 On Saturday, July 21, 2012 08:48:57 Paulo Pinto wrote:
 After becoming disapointed with Go leaving in the past, I've come to the
 conclusion that between the two, D is a much better choice.

I still need to study up on Go one of these days (along with a variety of other languages which are on my to-learn list), but the more I learn about it, the less I understand why Go and D are treated as competitors. I guess it's because of the systems language moniker (though Go doesn't mean it in the same was as C++ and D, so that skews things already), but Go and D are just so radically different in their basic approaches and philosophies, that I would expect that the folks who like one would dislike the other in most cases. They're just so completely different that I wouldn't expect them to really compete with one another save for the fact that developers only have so much time to check out new languages, so if one's getting a lot more attention, that could reduce how many people check out the other one, even if most people who check out the first one don't end up liking it. - Jonathan M Davis

Go is an evolution of Limbo (http://www.vitanuova.com/inferno/limbo.html), where ADTs got replaced by interfaces coupled with method declarations syntax from Component Pascal (http://www.oberon.ch/pdf/CP-Lang.pdf), an extension to Oberon. If you spend some time reading Inferno and Limbo documentation after learning Go, you'll see how they share so many concepts. http://doc.cat-v.org/inferno/books/inferno_programming_with_limbo/ Regarding systems programming, Go could actually play in the same league as D, since Oberon was used to write the Native Oberon and A2 operating systems. Besides the assembly for the GC and boot, everything else is written in Oberon. As a personal workstation the system was used a lot by the ETHZ researchers during the 90's. A quite cool environment where you get a Smalltalk like environment, with a strong typed language. Nowadays it is mainly used to teach OS principles at ETHZ, and embedded systems development. You can read more it here, http://www.ethoberon.ethz.ch/native/WebScreen.html (screenshots) http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf (how it was implemented) http://www.astrobe.com/Oberon.htm (embedded systems support) The trick with Oberon, which Go also uses, is to have a special module reckognised by the compiler with primitives to do the low tricks C offers. Additionaly any function/method without body can be implemented in Assembly. This is nothing new, Modula-2 already worked like this. What I miss from Go, and is what makes me like more of D is, - enumerations - exceptions - metaprogramming - generics - dynamic loading - constness - operator overloading - method overloading - support for FP Basically everything that has become part of the enterprise world since the late 90's. Wirth has a nice paper where we describes the evolution of the languages he designed, stating on the chapter 7, that Oberon failed in the industry because companies preferred the code bloat of other languages instead of Oberon's simplicity. http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf This is exactly the same school of thought that Go designers follow. If language design would be considered art, they would probably be part of the Minimalism mouvement. -- Paulo
Jul 21 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, July 21, 2012 19:13:20 Nick Sabalausky wrote:
 On Sat, 21 Jul 2012 14:41:05 +0200
 
 Paulo Pinto <pjmlp progtools.org> wrote:
 Regarding systems programming, Go could actually play in the same
 league as D

[...]
 The trick with Oberon, which Go also uses, is to have a special module
 reckognised by the compiler with primitives to do the low tricks C
 offers. Additionaly any function/method without body can be
 implemented in Assembly. This is nothing new, Modula-2 already worked
 like this.

If a language has to resort to such "outside-of-the-language" tricks like that to do system software, then it's just simply not a systems language.

I tend to agree. However, it's my understanding that when the Go folks talk about Go being a "systems language," they mean that it's meant for building large systems, not that it's meant for writing low-level stuff like kernels, which is what C++ and D mean when they call themselves systems languages. So, I believe that the core problem here is that the term is being used differently by different languages rather than Go claiming that they're a systems language in the C++/D sense when they have to rosert to outside of the language tricks. But I could be wrong about what they mean. - Jonathan M Davis
Jul 21 2012
prev sibling next sibling parent reply Brad Anderson <eco gnuk.net> writes:
--e0cb4e43d29388716a04c561b704
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jul 21, 2012 at 5:38 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 On Saturday, July 21, 2012 19:13:20 Nick Sabalausky wrote:
 On Sat, 21 Jul 2012 14:41:05 +0200

 Paulo Pinto <pjmlp progtools.org> wrote:
 Regarding systems programming, Go could actually play in the same
 league as D

[...]
 The trick with Oberon, which Go also uses, is to have a special module
 reckognised by the compiler with primitives to do the low tricks C
 offers. Additionaly any function/method without body can be
 implemented in Assembly. This is nothing new, Modula-2 already worked
 like this.

If a language has to resort to such "outside-of-the-language" tricks like that to do system software, then it's just simply not a systems language.

I tend to agree. However, it's my understanding that when the Go folks talk about Go being a "systems language," they mean that it's meant for building large systems, not that it's meant for writing low-level stuff like kernels, which is what C++ and D mean when they call themselves systems languages. So, I believe that the core problem here is that the term is being used differently by different languages rather than Go claiming that they're a systems language in the C++/D sense when they have to rosert to outside of the language tricks. But I could be wrong about what they mean. - Jonathan M Davis

The Go people no longer refer to Go as a systems language. I believe they did intend for it to be a systems language in the same manner D is but over time they decided to focus less on that. Here's what Russ Cox said on that matter: "We removed the word 'systems' because it was too limiting. Go is more general than that. It is still a great language for writing systems." Regards, Brad Anderson --e0cb4e43d29388716a04c561b704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jul 21, 2012 at 5:38 PM, Jonathan M Davis <span dir=3D"ltr">&lt;<a = href=3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jmdavisProg gmx.com</= a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"> <div class=3D"im">On Saturday, July 21, 2012 19:13:20 Nick Sabalausky wrote= :<br> &gt; On Sat, 21 Jul 2012 14:41:05 +0200<br> &gt;<br> &gt; Paulo Pinto &lt;<a href=3D"mailto:pjmlp progtools.org">pjmlp progtools= .org</a>&gt; wrote:<br> &gt; &gt; Regarding systems programming, Go could actually play in the same= <br> &gt; &gt; league as D<br> &gt;<br> &gt; [...]<br> &gt;<br> &gt; &gt; The trick with Oberon, which Go also uses, is to have a special m= odule<br> &gt; &gt; reckognised by the compiler with primitives to do the low tricks = C<br> &gt; &gt; offers. Additionaly any function/method without body can be<br> &gt; &gt; implemented in Assembly. This is nothing new, Modula-2 already wo= rked<br> &gt; &gt; like this.<br> &gt;<br> &gt; If a language has to resort to such &quot;outside-of-the-language&quot= ; tricks<br> &gt; like that to do system software, then it&#39;s just simply not a syste= ms<br> &gt; language.<br> <br> </div>I tend to agree. However, it&#39;s my understanding that when the Go = folks talk<br> about Go being a &quot;systems language,&quot; they mean that it&#39;s mean= t for building<br> large systems, not that it&#39;s meant for writing low-level stuff like ker= nels,<br> which is what C++ and D mean when they call themselves systems languages. S= o,<br> I believe that the core problem here is that the term is being used differe= ntly<br> by different languages rather than Go claiming that they&#39;re a systems l= anguage<br> in the C++/D sense when they have to rosert to outside of the language tric= ks.<br> But I could be wrong about what they mean.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> - Jonathan M Davis<br> </font></span></blockquote></div><br><div>The Go people no longer refer to = Go as a systems language. =A0I believe they did intend for it to be a syste= ms language in the same manner D is but over time they decided to focus les= s on that.</div> <div><br></div><div>Here&#39;s what Russ Cox said on that matter:</div><div=
<br></div><div>&quot;We removed the word &#39;systems&#39; because it was =

t language for</div> <div>writing systems.&quot;</div><div><br></div><div>Regards,</div><div>Bra= d Anderson</div> --e0cb4e43d29388716a04c561b704--
Jul 21 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/12 10:16 PM, Brad Anderson wrote:
 The Go people no longer refer to Go as a systems language.  I believe
 they did intend for it to be a systems language in the same manner D is
 but over time they decided to focus less on that.

 Here's what Russ Cox said on that matter:

 "We removed the word 'systems' because it was too limiting.
 Go is more general than that.  It is still a great language for
 writing systems."

Yah, it's one of those things that stuck just like "Scala is FP on the JVM", characterization that Martin Odersky himself was surprised of (and refuted). Andrei
Jul 21 2012
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 22.07.2012 01:13, schrieb Nick Sabalausky:
 On Sat, 21 Jul 2012 14:41:05 +0200
 Paulo Pinto<pjmlp progtools.org>  wrote:
 Regarding systems programming, Go could actually play in the same
 league as D

 The trick with Oberon, which Go also uses, is to have a special module
 reckognised by the compiler with primitives to do the low tricks C
 offers. Additionaly any function/method without body can be
 implemented in Assembly. This is nothing new, Modula-2 already worked
 like this.

If a language has to resort to such "outside-of-the-language" tricks like that to do system software, then it's just simply not a systems language.

How is this different from ANSI/ISO C, which is considered a systems programming language? -- Paulo
Jul 22 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 22.07.2012 10:42, schrieb Nick Sabalausky:
 On Sun, 22 Jul 2012 01:24 -0700
 Jonathan M Davis<jmdavisProg gmx.com>  wrote:

 On Sunday, July 22, 2012 10:10:43 Paulo Pinto wrote:
 Am 22.07.2012 01:13, schrieb Nick Sabalausky:
 On Sat, 21 Jul 2012 14:41:05 +0200

 Paulo Pinto<pjmlp progtools.org>   wrote:
 Regarding systems programming, Go could actually play in the same
 league as D

[...]
 The trick with Oberon, which Go also uses, is to have a special
 module reckognised by the compiler with primitives to do the low
 tricks C offers. Additionaly any function/method without body
 can be implemented in Assembly. This is nothing new, Modula-2
 already worked like this.

If a language has to resort to such "outside-of-the-language" tricks like that to do system software, then it's just simply not a systems language.

How is this different from ANSI/ISO C, which is considered a systems programming language?

It can actually use raw pointers and the like? It's my understanding that pretty much all of the low level "system" stuff like that is hidden from you in Go. So, the result would be a bit like calling Java a systems language because you can use JNI to get at low level stuff.

Right. IIRC, I think I heard that Go does have pointers, but they're very limited compared to C/D and there's no ptr arithmetic.

Simple pointers are available. package main import "fmt" func main() { x := 25 y := &x fmt.Println("x is ", x) *y = 30 fmt.Println("x is now ", x) } Pointer arithmetic is possible using the unsafe package, but should only be used if really needed, like interfacing with system code. package main import "fmt" import "unsafe" func main() { x := []byte{1, 2, 3, 4} fmt.Println("x is ", x) for i := 0; i < len(x); i++ { e := x[i] fmt.Printf("%d index is %d, at %x\n", i, e, &x[i]) } y := &x[0] fmt.Println("Base adress ", y) size := unsafe.Sizeof(x[0]) fmt.Println("Size per element ", size) for i := 0; i < len(x); i++ { cell := uint64(uintptr(unsafe.Pointer(y))) + (uint64(i) * uint64(size)) value := (*byte)(unsafe.Pointer(uintptr(cell))) fmt.Printf("%d index is %d, at %p\n", i, *value, value) } }
 Another thing would be reinterpret cast: Take a value and map a
 different type onto the same memory without any runtime overhead. That
 can be very useful for both speed and memory optimizations. I admit I
 don't actually know whether Go supports that, but from what I understand
 about the language it would surprise me. Actually, if it could, then
 that would effectively give it ptr arithmetic (and in a really ugly
 non-typesafe way), so I really doubt it.

Not really, you can fake it though, by using the enconding.binary package, http://golang.org/pkg/encoding/binary/ -- Paulo
Jul 22 2012
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 22.07.2012 20:46, schrieb Nick Sabalausky:
 On Sun, 22 Jul 2012 18:14:23 +0200
 Paulo Pinto<pjmlp progtools.org>  wrote:
 	y :=&x[0]
 	fmt.Println("Base adress ", y)
 	size := unsafe.Sizeof(x[0])
 	fmt.Println("Size per element ", size)
 	for i := 0; i<  len(x); i++ {
 		cell := uint64(uintptr(unsafe.Pointer(y))) +
 (uint64(i) * uint64(size)) value :=
 (*byte)(unsafe.Pointer(uintptr(cell))) fmt.Printf("%d index is %d, at
 %p\n", i, *value, value) }
 }

Eeew!! That's awful.

Pointer arithmetic as endless source for security exploits is to be used *only* when no other solution exists. But yes, the way to do it could be simpler.
Jul 22 2012
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2012-07-21 06:48:57 +0000, Paulo Pinto <pjmlp progtools.org> said:

 We need something like std.database for web development, which as far as
 I know is currently on hold.
 
 WinRT support would also be a nice feature. Need to spend some time 
 checking how to work with type libraries.

The web is a low-hanging fruit for D. The language is already very suitable for it: being able to talk to C APIs, socket IO, and starting external processes plenty enough. All it needs really is some library code. Supporting WinRT, or Cocoa, in any pleasant way is a much bigger project. Both these APIs use OO extensively and, while they are accessible from C, dealing with such code using C functions is a pain. I'm convinced that what D needs is direct support for new object models in the language. The good news is that semantically both the WinRT model and the Cocoa model of an object are close enough to the D model -- single inheritance, one root object -- and I've shown with my experimental DMD/Objective-C branch[1] that such a model integrates quite well to D despite the differences. In fact, WinRT, being based on COM, would probably map better than Cocoa. [1]: http://michelf.ca/projects/d-objc/ So in short, to be successful in GUI development, D need to support the native object model of the GUI platform it runs on without having to jump through hoops and without having a complicated layer of bindings. Using D code within a GUI app should be as easy as using C++ code within it would be. Otherwise, you cannot really compete. And also, more and more it'd require ARM support to be competitive in the GUI area. Compare those requirements to those of web development, were almost all servers are x86, where C, socket IO, and execution of external processes is all that's needed interface with other components, and you'll see that web dev is truly the low-hanging fruit in terms of market for D. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jul 21 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/12 10:08 AM, Adam D. Ruppe wrote:
 On Saturday, 21 July 2012 at 13:47:06 UTC, Michel Fortin wrote:
 The web is a low-hanging fruit for D.

Yea, I've been eating that fruit for years. While my libs are out there, I haven't gotten around to doing the rest of the documentation or anything. My libraries are just a means to an end to me. They get the job done, so I focus on the job, and then I have other stuff the rest of my time. But there's people who have used my libs regardless so if you are interested, here it is: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

Would you agree if someone took your code, modified it for the purposes of passing it through the forks of the review process, and pushed it into Phobos? You'd still receive credit, of course, but it would be shared with that person or group because that's significant work. Let us know - thanks! Andrei
Jul 21 2012
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 21-07-2012 21:51, Nick Sabalausky wrote:
 On Sat, 21 Jul 2012 09:47:06 -0400
 Michel Fortin <michel.fortin michelf.ca> wrote:
 And also, more and more it'd require ARM support to be competitive in
 the GUI area.

Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D.

... and C# ;)
 I know I keep harping on that, but it's a big issue for me since I'm
 deep into that stuff now and goddamn do I wish I could be doing
 it in D, but D's support on those devices (or just outputting C/C++)
 unfortunately just isn't mature enough ATM.

GDC is pretty far along as far as ARM support goes; I intend to have another run through it one of these days to look at any remaining issues. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Jul 21 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 21-07-2012 22:26, Nick Sabalausky wrote:
 On Sat, 21 Jul 2012 21:59:12 +0200
 Alex Rønne Petersen <alex lycus.org> wrote:

 On 21-07-2012 21:51, Nick Sabalausky wrote:
 On Sat, 21 Jul 2012 09:47:06 -0400
 Michel Fortin <michel.fortin michelf.ca> wrote:
 And also, more and more it'd require ARM support to be competitive
 in the GUI area.

Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D.

... and C# ;)

Oh, yea. I assume you're referring to Unity, right?

Nah, more of a shameless plug: http://xamarin.com/ (I work for Xamarin ;))
 I know I keep harping on that, but it's a big issue for me since I'm
 deep into that stuff now and goddamn do I wish I could be doing
 it in D, but D's support on those devices (or just outputting C/C++)
 unfortunately just isn't mature enough ATM.

GDC is pretty far along as far as ARM support goes; I intend to have another run through it one of these days to look at any remaining issues.

That is encouraging to hear :) What about druntime and phobos, though? And what about D feature set, is it up to 2.059?

GDC is up to DMD FE 2.059, so as far as the language goes, D on ARM should be up to date. Phobos should already build on ARM as-is (I sent some ARM patches upstream recently, too). druntime might need tweaking for some recent changes in in the threading/GC infrastructure, but I'll have to investigate further to see what the state is. I'll probably get around to that on Monday.
 I wonder if maybe I could somehow tell Marmalade's annoying proprietary
 build system to pass in some extra object files to the linker? I'll have
 to ask on their forums. Because maybe then I could compile some stuff
 with GDC and link it in.

-- Alex Rønne Petersen alex lycus.org http://lycus.org
Jul 21 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/12 3:59 PM, Alex Rønne Petersen wrote:
 GDC is pretty far along as far as ARM support goes; I intend to have
 another run through it one of these days to look at any remaining issues.

That's awesome. I got a feel at OSCON that a combination of big iron + ARM-based small devices is the most popular combo going forward. Andrei
Jul 21 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-07-21 21:59, Alex Rønne Petersen wrote:
 On 21-07-2012 21:51, Nick Sabalausky wrote:

 Yes. But there's an even bigger reason for ARM: Mobile devices, like
 iOS and Android. I'm not personally a fan of them, but nonetheless those
 things are HUGE (no pun intended). And yet the ONLY real language
 choices there are C++, Java and Objective-C (and Lua if you count
 "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are
 out of the question if you want cross platform, which any sane developer
 should. So PERFECT fertile ground for D.

... and C# ;)

... and Ruby :) -- /Jacob Carlborg
Jul 23 2012
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2012-07-21 19:51:37 +0000, Nick Sabalausky 
<SeeWebsiteToContactMe semitwist.com> said:

 On Sat, 21 Jul 2012 09:47:06 -0400
 Michel Fortin <michel.fortin michelf.ca> wrote:
 
 And also, more and more it'd require ARM support to be competitive in
 the GUI area.

Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D. I know I keep harping on that, but it's a big issue for me since I'm deep into that stuff now and goddamn do I wish I could be doing it in D, but D's support on those devices (or just outputting C/C++) unfortunately just isn't mature enough ATM.

For my part, in the last year I've been building a big codebase that had to be C++ just because of this, with countless hours spent figuring out things that would have been a lot easier to do in D. Here's the problem as I came to realize it: no single project is going to be enough to justify the investment required to make it happen. Nobody's project is by itself big enough to make D/Objective-C worthwhile to produce and maintain, because making it and then keeping it in sync with both D and Apple's Objective-C is a huge effort that'll in itself derail the project you were using to justify the investment. So D/Objective-C has to stand as a project of its own somehow. Also, making it a cross-platform thing would require a similar investment for WinRT and Android (through JNI?). While it surely is technically possible and would sure help a lot of developers move away from C++, I'm not so sure such a thing will happen at all. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jul 22 2012
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 22.07.2012 14:19, schrieb Michel Fortin:
 On 2012-07-21 19:51:37 +0000, Nick Sabalausky
 <SeeWebsiteToContactMe semitwist.com> said:

 On Sat, 21 Jul 2012 09:47:06 -0400
 Michel Fortin <michel.fortin michelf.ca> wrote:
 And also, more and more it'd require ARM support to be competitive in
 the GUI area.

Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D. I know I keep harping on that, but it's a big issue for me since I'm deep into that stuff now and goddamn do I wish I could be doing it in D, but D's support on those devices (or just outputting C/C++) unfortunately just isn't mature enough ATM.

For my part, in the last year I've been building a big codebase that had to be C++ just because of this, with countless hours spent figuring out things that would have been a lot easier to do in D. Here's the problem as I came to realize it: no single project is going to be enough to justify the investment required to make it happen. Nobody's project is by itself big enough to make D/Objective-C worthwhile to produce and maintain, because making it and then keeping it in sync with both D and Apple's Objective-C is a huge effort that'll in itself derail the project you were using to justify the investment. So D/Objective-C has to stand as a project of its own somehow. Also, making it a cross-platform thing would require a similar investment for WinRT and Android (through JNI?). While it surely is technically possible and would sure help a lot of developers move away from C++, I'm not so sure such a thing will happen at all.

Those are the reasons why, even though I follow a few new programming languages with interest, in the end I keep on coding in JVM/.NET/C++. Unfortunely my time is limited and I have to use what works out of the box. -- Paulo
Jul 22 2012
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2012-07-22 19:05:45 +0000, Nick Sabalausky 
<SeeWebsiteToContactMe semitwist.com> said:

 On Sun, 22 Jul 2012 08:19:12 -0400
 Michel Fortin <michel.fortin michelf.ca> wrote:
 
 On 2012-07-21 19:51:37 +0000, Nick Sabalausky
 <SeeWebsiteToContactMe semitwist.com> said:
 
 On Sat, 21 Jul 2012 09:47:06 -0400
 Michel Fortin <michel.fortin michelf.ca> wrote:
 
 And also, more and more it'd require ARM support to be competitive
 in the GUI area.

Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D. I know I keep harping on that, but it's a big issue for me since I'm deep into that stuff now and goddamn do I wish I could be doing it in D, but D's support on those devices (or just outputting C/C++) unfortunately just isn't mature enough ATM.

For my part, in the last year I've been building a big codebase that had to be C++ just because of this, with countless hours spent figuring out things that would have been a lot easier to do in D. Here's the problem as I came to realize it: no single project is going to be enough to justify the investment required to make it happen. Nobody's project is by itself big enough to make D/Objective-C worthwhile to produce and maintain, because making it and then keeping it in sync with both D and Apple's Objective-C is a huge effort that'll in itself derail the project you were using to justify the investment. So D/Objective-C has to stand as a project of its own somehow. Also, making it a cross-platform thing would require a similar investment for WinRT and Android (through JNI?). While it surely is technically possible and would sure help a lot of developers move away from C++, I'm not so sure such a thing will happen at all.

FWIW, Marmalade ( www.madewithmarmalade.com ) has already done the legwork to allow crossplatform natively-compiled C++ code that works on iOS, Android and a bunch of other less "hip" stuff like Bada, WebOS, Symbian, and some version of mobile windows (6, IIRC). I'm sure they'll be doing WinRT at some point if not already working on it. They do abstract away the underlying OS calls (including usage of Objective-C), although they also provide a (somewhat roundabout) way to access them directly if you need. Unfortunately, it's not open-source and it's somewhat pricey, but point is, C++ across all those platforms does at least exist.

Marmalade, from what I see, is some sort of meta-platform you can use to write something that works everywhere. It adds a new layer of abstraction that can work on top of each platform. Good for them and their developers, but I generally try to avoid unnecessary layers like this. It often makes things harder to debug and fix, and will always lag behind the functionalities each of platform has to offer. No, the idea is to make the D *language* work with each platform's object model. Just like D can call and define C functions with zero overhead, it should be capable of defining classes from other languages too and overriding their functions with zero overhead. That way you can talk directly with each platform's API with no middle man playing a complicated translation/abstraction process in the middle.
 Also, on the Android, you don't need to deal with the JVM (or whatever
 Google's version of it is called). Apparently that used to
 be the case, but now you can just use straight C++, even without third
 party tools like Marmalade.

But all the interface widgets are still in Java, no? If you're working on an OpenGL/ES game maybe you won,t need them, but if you're building any other kind of app, you'll have to play with JNI a lot. Or add Marmalade as an abstraction layer. Either way it's suboptimal compared to using directly the APIs you need.
 There's a lot of about Google and Android I
 don't like, but as usual: At least it's not *quite* as shitty as dealing
 with Apple's inevitably putrid offering.

With Apple's platform, integrating a C++ backend with an Objective-C frontend is quite a breeze: both object models mix very well together. It's pretty much the same thing as Microsoft did with WinRT: regular C++ classes mix with WinRT classes in the same source file pretty much in the same way. Try do that with Android's UI classes written in Java. But maybe I misunderstood what you're referring to. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jul 22 2012
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2012-07-23 05:04:39 +0000, Nick Sabalausky 
<SeeWebsiteToContactMe semitwist.com> said:

 Personally I like abstraction layers for GUI: it means you don't have to
 deal with twenty different system-specific (and idiosyncratic) APIs.
 For example, I hope I never have to touch Win32 directly again.

Win32 is a special case. It's old and low-level, no one wants to touch it. Even those who build directly on it abstract it with a layer of their own. Abstraction layers for GUI are not inherently bad, but they also tend to blur platform specificities. This often results in apps that feel a little alien on every platform. So whether you should use them or not depends on your priorities. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Jul 23 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-07-23 13:21, Michel Fortin wrote:

 Abstraction layers for GUI are not inherently bad, but they also tend to
 blur platform specificities. This often results in apps that feel a
 little alien on every platform. So whether you should use them or not
 depends on your priorities.

I think a system where the common widgets, i.e. windows, buttons and similar, are abstracted but still lets you easily access the native API would be a good thing. This mean you would still need to be able to access the Objective-C and WinRT object model to be really useful. -- /Jacob Carlborg
Jul 23 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 21 July 2012 at 13:47:06 UTC, Michel Fortin wrote:
 The web is a low-hanging fruit for D.

Yea, I've been eating that fruit for years. While my libs are out there, I haven't gotten around to doing the rest of the documentation or anything. My libraries are just a means to an end to me. They get the job done, so I focus on the job, and then I have other stuff the rest of my time. But there's people who have used my libs regardless so if you are interested, here it is: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
Jul 21 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 21 July 2012 at 16:45:20 UTC, Andrei Alexandrescu 
wrote:
 Would you agree if someone took your code, modified it for the 
 purposes of passing it through the forks of the review process, 
 and pushed it into Phobos?

Yes, no problem at all.
 You'd still receive credit, of course, but it would be shared 
 with that person or group because that's significant work.

That's why I haven't done it myself yet! It is in a state where it works for me and the phobos cost is just too high in my current situation.
Jul 21 2012
prev sibling parent "nazriel" <spam dzfl.pl> writes:
On Saturday, 21 July 2012 at 14:08:48 UTC, Adam D. Ruppe wrote:
 On Saturday, 21 July 2012 at 13:47:06 UTC, Michel Fortin wrote:
 The web is a low-hanging fruit for D.

Yea, I've been eating that fruit for years.

Web development with D is quite easy and very enjoyable. With Adam's work it even more easier. I've done couple projects already with some of personal and Adam's stuff. Also I've try out a bit with Vibe.d, Adam's stuff, Serenity and they give the feel of php-like capabilities but I think it would be better to get something like Ruby on Rails, Django or Whatever-php-framework-you-may-use that allows Rapid Web Development. While making basic stuff like databases support, CGI/FCGI support etc to Phobos seems fine to me, I think that creating specialized D framework for web development would be better idea (and for sure it shouldn't be placed in standard library).
Jul 21 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 21 Jul 2012 09:47:06 -0400
Michel Fortin <michel.fortin michelf.ca> wrote:
 
 And also, more and more it'd require ARM support to be competitive in 
 the GUI area.
 

Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D. I know I keep harping on that, but it's a big issue for me since I'm deep into that stuff now and goddamn do I wish I could be doing it in D, but D's support on those devices (or just outputting C/C++) unfortunately just isn't mature enough ATM.
Jul 21 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/12 1:14 AM, Andrei Alexandrescu wrote:
 I'm back from OSCON 2012, where my talk has enjoyed a somewhat
 unexpected good reception (OSCON is not the most down-D's-alley audience).

 The talk abstract is at
 http://www.oscon.com/oscon2012/public/schedule/detail/23888 and the
 slides are at
 http://www.slideshare.net/andreialexandrescu1/generic-programming-galore-using-d.
 There will be a video up some time in the future for the entire talk.

Slides are being discussed on reddit: http://www.reddit.com/r/programming/comments/wxjv0/generic_programming_galore_using_d/ Andrei
Jul 21 2012
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 21 Jul 2012 01:14:57 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 I'm back from OSCON 2012, where my talk has enjoyed a somewhat 
 unexpected good reception (OSCON is not the most down-D's-alley
 audience).
 
 The talk abstract is at 
 http://www.oscon.com/oscon2012/public/schedule/detail/23888 and the 
 slides are at 
 http://www.slideshare.net/andreialexandrescu1/generic-program
ing-galore-using-d. 
 There will be a video up some time in the future for the entire talk.
 

Great stuff! It's a perfect way of explaining why D kicks so much ass. Side note though: Seriously, no download with registration?!? WTF
 A small framework or simply a couple of standard 
 library components that would make e.g. Vladimir's work (on 
 forum.lang.org) or Adam Ruppe's work easy to assemble from
 preexisting parts would be just awesome.
 

What do you mean by "make it easy to assemble Vladimir's and Adam's web libraries from preexisting parts"? A couple months ago I had a little bit of free time and used it to work on a custom...uhh...*cough* "not-a-blog" system I've been putting together for myself. I used the combination of: - Vibe.d's CGI library and HTTP server - simendsjo's fork of Steve Teale's native MySQL library: https://github.com/simendsjo/mysqln/tree/misc-cleanups (Actually, I think this is included in Vibe.d now?) - Adam's HTML DOM (And I cached partial and full results in memory, of course, so I wasn't DOMming it up on every request) It was working out BEAUTIFULLY for me, at least until I ran out of free time and had to leave it unfinished :(
Jul 21 2012
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 21 July 2012 at 20:17:11 UTC, Nick Sabalausky wrote:
 - Adam's HTML DOM (And I cached partial and full results in 
 memory, of course, so I wasn't DOMming it up on every request)

DOMing it up every request rox. That's what I do and so far the impact of those have been negligible in the profiling.
Jul 21 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/12 4:17 PM, Nick Sabalausky wrote:
 Side note though: Seriously, no download with registration?!? WTF

Crap. Didn't know, otherwise I might've chosen differently. Andrei
Jul 21 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/12 4:17 PM, Nick Sabalausky wrote:
 What do you mean by "make it easy to assemble Vladimir's and Adam's web
 libraries from preexisting parts"?

I mean putting much of their work in std, such that people can write their own Web/NNTP/CGI/etc stuff with much less code than they had to write.
 A couple months ago I had a little bit of free time and used it to work
 on a custom...uhh...*cough* "not-a-blog" system I've been putting
 together for myself. I used the combination of:

 - Vibe.d's CGI library and HTTP server

 - simendsjo's fork of Steve Teale's native MySQL library:
    https://github.com/simendsjo/mysqln/tree/misc-cleanups  (Actually, I
    think this is included in Vibe.d now?)

 - Adam's HTML DOM (And I cached partial and full results in memory, of
    course, so I wasn't DOMming it up on every request)

 It was working out BEAUTIFULLY for me, at least until I ran out of
 free time and had to leave it unfinished :(

A feeling experienced by me all too often. My point is instead of having people buy these batteries, charging them by hand, and connecting them via diodes, to integrate the batteries with std. Andrei
Jul 21 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 21 Jul 2012 21:59:12 +0200
Alex R=F8nne Petersen <alex lycus.org> wrote:

 On 21-07-2012 21:51, Nick Sabalausky wrote:
 On Sat, 21 Jul 2012 09:47:06 -0400
 Michel Fortin <michel.fortin michelf.ca> wrote:
 And also, more and more it'd require ARM support to be competitive
 in the GUI area.

Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D.

... and C# ;) =20

Oh, yea. I assume you're referring to Unity, right?
 I know I keep harping on that, but it's a big issue for me since I'm
 deep into that stuff now and goddamn do I wish I could be doing
 it in D, but D's support on those devices (or just outputting C/C++)
 unfortunately just isn't mature enough ATM.

GDC is pretty far along as far as ARM support goes; I intend to have=20 another run through it one of these days to look at any remaining issues. =20

That is encouraging to hear :) What about druntime and phobos, though? And what about D feature set, is it up to 2.059? I wonder if maybe I could somehow tell Marmalade's annoying proprietary build system to pass in some extra object files to the linker? I'll have to ask on their forums. Because maybe then I could compile some stuff with GDC and link it in.
Jul 21 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 21 Jul 2012 16:17:00 -0400
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 On Sat, 21 Jul 2012 01:14:57 -0400
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 
 I'm back from OSCON 2012, where my talk has enjoyed a somewhat 
 unexpected good reception (OSCON is not the most down-D's-alley
 audience).
 
 The talk abstract is at 
 http://www.oscon.com/oscon2012/public/schedule/detail/23888 and the 
 slides are at 
 http://www.slideshare.net/andreialexandrescu1/generic-program
ing-galore-using-d. 
 There will be a video up some time in the future for the entire
 talk.
 

Great stuff! It's a perfect way of explaining why D kicks so much ass. Side note though: Seriously, no download with registration?!? WTF

s/with/without/
Jul 21 2012
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 21 Jul 2012 14:41:05 +0200
Paulo Pinto <pjmlp progtools.org> wrote:
 
 Regarding systems programming, Go could actually play in the same
 league as D

 The trick with Oberon, which Go also uses, is to have a special module
 reckognised by the compiler with primitives to do the low tricks C 
 offers. Additionaly any function/method without body can be
 implemented in Assembly. This is nothing new, Modula-2 already worked
 like this.
 

If a language has to resort to such "outside-of-the-language" tricks like that to do system software, then it's just simply not a systems language. If that meant Go^H^HIssue 9 could play in the same systems league as D, then scripting languages like Lua or JavaScript or even VBScript would qualify, too.
Jul 21 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 22, 2012 10:10:43 Paulo Pinto wrote:
 Am 22.07.2012 01:13, schrieb Nick Sabalausky:
 On Sat, 21 Jul 2012 14:41:05 +0200
 
 Paulo Pinto<pjmlp progtools.org>  wrote:
 Regarding systems programming, Go could actually play in the same
 league as D

[...]
 The trick with Oberon, which Go also uses, is to have a special module
 reckognised by the compiler with primitives to do the low tricks C
 offers. Additionaly any function/method without body can be
 implemented in Assembly. This is nothing new, Modula-2 already worked
 like this.

If a language has to resort to such "outside-of-the-language" tricks like that to do system software, then it's just simply not a systems language.

How is this different from ANSI/ISO C, which is considered a systems programming language?

It can actually use raw pointers and the like? It's my understanding that pretty much all of the low level "system" stuff like that is hidden from you in Go. So, the result would be a bit like calling Java a systems language because you can use JNI to get at low level stuff. - Jonathan M Davis
Jul 22 2012
prev sibling next sibling parent "nazriel" <spam dzfl.pl> writes:
On Saturday, 21 July 2012 at 05:14:57 UTC, Andrei Alexandrescu 
wrote:
 I'm back from OSCON 2012, where my talk has enjoyed a somewhat 
 unexpected good reception (OSCON is not the most down-D's-alley 
 audience).

 The talk abstract is at 
 http://www.oscon.com/oscon2012/public/schedule/detail/23888 and 
 the slides are at 
 http://www.slideshare.net/andreialexandrescu1/generic-program
ing-galore-using-d. 
 There will be a video up some time in the future for the entire 
 talk.

[...]

 Cheers,

 Andrei

Looking forward to see it
Jul 21 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 22 Jul 2012 01:24 -0700
Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Sunday, July 22, 2012 10:10:43 Paulo Pinto wrote:
 Am 22.07.2012 01:13, schrieb Nick Sabalausky:
 On Sat, 21 Jul 2012 14:41:05 +0200
 
 Paulo Pinto<pjmlp progtools.org>  wrote:
 Regarding systems programming, Go could actually play in the same
 league as D

[...]
 The trick with Oberon, which Go also uses, is to have a special
 module reckognised by the compiler with primitives to do the low
 tricks C offers. Additionaly any function/method without body
 can be implemented in Assembly. This is nothing new, Modula-2
 already worked like this.

If a language has to resort to such "outside-of-the-language" tricks like that to do system software, then it's just simply not a systems language.

How is this different from ANSI/ISO C, which is considered a systems programming language?

It can actually use raw pointers and the like? It's my understanding that pretty much all of the low level "system" stuff like that is hidden from you in Go. So, the result would be a bit like calling Java a systems language because you can use JNI to get at low level stuff.

Right. IIRC, I think I heard that Go does have pointers, but they're very limited compared to C/D and there's no ptr arithmetic. Another thing would be reinterpret cast: Take a value and map a different type onto the same memory without any runtime overhead. That can be very useful for both speed and memory optimizations. I admit I don't actually know whether Go supports that, but from what I understand about the language it would surprise me. Actually, if it could, then that would effectively give it ptr arithmetic (and in a really ugly non-typesafe way), so I really doubt it.
Jul 22 2012
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
Just curious, do you know if Alexander Stepanov uses D or not?
Jul 22 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 22 Jul 2012 18:14:23 +0200
Paulo Pinto <pjmlp progtools.org> wrote:
 	y := &x[0]
 	fmt.Println("Base adress ", y)
 	size := unsafe.Sizeof(x[0])
 	fmt.Println("Size per element ", size)
 	for i := 0; i < len(x); i++ {
 		cell := uint64(uintptr(unsafe.Pointer(y))) +
 (uint64(i) * uint64(size)) value :=
 (*byte)(unsafe.Pointer(uintptr(cell))) fmt.Printf("%d index is %d, at
 %p\n", i, *value, value) }
 }
 

Eeew!! That's awful.
Jul 22 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 22 Jul 2012 08:19:12 -0400
Michel Fortin <michel.fortin michelf.ca> wrote:

 On 2012-07-21 19:51:37 +0000, Nick Sabalausky 
 <SeeWebsiteToContactMe semitwist.com> said:
 
 On Sat, 21 Jul 2012 09:47:06 -0400
 Michel Fortin <michel.fortin michelf.ca> wrote:
 
 And also, more and more it'd require ARM support to be competitive
 in the GUI area.

Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D. I know I keep harping on that, but it's a big issue for me since I'm deep into that stuff now and goddamn do I wish I could be doing it in D, but D's support on those devices (or just outputting C/C++) unfortunately just isn't mature enough ATM.

For my part, in the last year I've been building a big codebase that had to be C++ just because of this, with countless hours spent figuring out things that would have been a lot easier to do in D. Here's the problem as I came to realize it: no single project is going to be enough to justify the investment required to make it happen. Nobody's project is by itself big enough to make D/Objective-C worthwhile to produce and maintain, because making it and then keeping it in sync with both D and Apple's Objective-C is a huge effort that'll in itself derail the project you were using to justify the investment. So D/Objective-C has to stand as a project of its own somehow. Also, making it a cross-platform thing would require a similar investment for WinRT and Android (through JNI?). While it surely is technically possible and would sure help a lot of developers move away from C++, I'm not so sure such a thing will happen at all.

FWIW, Marmalade ( www.madewithmarmalade.com ) has already done the legwork to allow crossplatform natively-compiled C++ code that works on iOS, Android and a bunch of other less "hip" stuff like Bada, WebOS, Symbian, and some version of mobile windows (6, IIRC). I'm sure they'll be doing WinRT at some point if not already working on it. They do abstract away the underlying OS calls (including usage of Objective-C), although they also provide a (somewhat roundabout) way to access them directly if you need. Unfortunately, it's not open-source and it's somewhat pricey, but point is, C++ across all those platforms does at least exist. Also, on the Android, you don't need to deal with the JVM (or whatever Google's version of it is called). Apparently that used to be the case, but now you can just use straight C++, even without third party tools like Marmalade. There's a lot of about Google and Android I don't like, but as usual: At least it's not *quite* as shitty as dealing with Apple's inevitably putrid offering.
Jul 22 2012
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 22 Jul 2012 17:58:20 -0400
Michel Fortin <michel.fortin michelf.ca> wrote:
 
 Marmalade, from what I see, is some sort of meta-platform you can use 
 to write something that works everywhere. It adds a new layer of 
 abstraction that can work on top of each platform. Good for them and 
 their developers, but I generally try to avoid unnecessary layers
 like this. It often makes things harder to debug and fix, and will
 always lag behind the functionalities each of platform has to offer.
 
 No, the idea is to make the D *language* work with each platform's 
 object model. Just like D can call and define C functions with zero 
 overhead, it should be capable of defining classes from other
 languages too and overriding their functions with zero overhead. That
 way you can talk directly with each platform's API with no middle man
 playing a complicated translation/abstraction process in the middle.
 

Yea, I agree that's worth having. Just thought it was worth mentioning.
 
 Also, on the Android, you don't need to deal with the JVM (or
 whatever Google's version of it is called). Apparently that used to
 be the case, but now you can just use straight C++, even without
 third party tools like Marmalade.

But all the interface widgets are still in Java, no? If you're working on an OpenGL/ES game maybe you won,t need them, but if you're building any other kind of app, you'll have to play with JNI a lot. Or add Marmalade as an abstraction layer. Either way it's suboptimal compared to using directly the APIs you need.

 Try do that with Android's UI
 classes written in Java. But maybe I misunderstood what you're
 referring to.
 

I wouldn't know. I haven't actually dealt with the android SDK directly, only Marm. When I saw google saying you use either Java or straight natively-compiled C++, I guess I assumed that meant an actual C++ API. Personally I like abstraction layers for GUI: it means you don't have to deal with twenty different system-specific (and idiosyncratic) APIs. For example, I hope I never have to touch Win32 directly again.
Jul 22 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
"Nick Sabalausky"  wrote in message news:20120723010439.00006efc unknown...
I wouldn't know. I haven't actually dealt with the android SDK
directly, only Marm. When I saw google saying you use either Java or
straight natively-compiled C++, I guess I assumed that meant an actual
C++ API.

No, actually you are still dealing with JNI. Google's position on native code, is that you should use it just for code hotspots, gamming or to port "legacy" code. [quote]In general, you should only use the NDK if it is essential to your app— never because you simply prefer to program in C/C++.[/quote] http://developer.android.com/tools/sdk/ndk/index.html The native activity is actually a Java Activity with a specific set of methods defined as native methods. http://developer.android.com/reference/android/app/NativeActivity.html You are only allowed to access these libraries: - libc (C library) headers - libm (math library) headers - JNI interface headers - libz (Zlib compression) headers - liblog (Android logging) header - OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers - libjnigraphics (Pixel buffer access) header (for Android 2.2 and above). - A Minimal set of headers for C++ support - OpenSL ES native audio libraries - Android native application APIS The Android native applications APIs are C wrappers around JNI calls, meaning you get a performance hit when calling them due to marshling. This is described in the STABLE-APIS.html document delivered as part of the NDK. [quote]Starting from API level 9, it is possible to entirely write an Android application with native code (i.e. without any Java). That does not mean that your code does not run inside a VM though, and most of the features of the platform will still need to be accessed through JNI.[/quote] Java is the main language to develop standard applications on Android, everything else are just workarounds, even if we don't like it. Another example are the new low level Codec APIs in Jelly Bean, which are only exposed directly via JNI to Java. http://developer.android.com/reference/android/media/MediaCodec.html -- Paulo
Jul 22 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-07-23 08:59, Paulo Pinto wrote:

 No, actually you are still dealing with JNI. Google's position on native
 code, is that
 you should use it just for code hotspots, gamming or to port "legacy" code.

 The Android native applications APIs are C wrappers around JNI calls,
 meaning you get a performance
 hit when calling them due to marshling. This is described in the
 STABLE-APIS.html document delivered
 as part of the NDK.

 [quote]Starting from API level 9, it is possible to entirely write an
 Android
 application with native code (i.e. without any Java). That does not mean
 that your code does not run inside a VM though, and most of the features
 of the platform will still need to be accessed through JNI.[/quote]

That is just so wrong. -- /Jacob Carlborg
Jul 23 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 23 Jul 2012 08:59:32 +0200
"Paulo Pinto" <pjmlp progtools.org> wrote:

"Nick Sabalausky"  wrote in message
news:20120723010439.00006efc unknown... I wouldn't know. I haven't
actually dealt with the android SDK directly, only Marm. When I saw
google saying you use either Java or straight natively-compiled C++,
I guess I assumed that meant an actual C++ API.

No, actually you are still dealing with JNI. Google's position on native code, is that you should use it just for code hotspots, gamming or to port "legacy" code. =20 [quote]In general, you should only use the NDK if it is essential to your app=E2=80=94 never because you simply prefer to program in C/C++.[/quote] =20 http://developer.android.com/tools/sdk/ndk/index.html =20 The native activity is actually a Java Activity with a specific set of methods defined as native methods. =20 http://developer.android.com/reference/android/app/NativeActivity.html =20 You are only allowed to access these libraries: =20 - libc (C library) headers - libm (math library) headers - JNI interface headers - libz (Zlib compression) headers - liblog (Android logging) header - OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers - libjnigraphics (Pixel buffer access) header (for Android 2.2 and above). - A Minimal set of headers for C++ support - OpenSL ES native audio libraries - Android native application APIS =20 The Android native applications APIs are C wrappers around JNI calls,=20 meaning you get a performance hit when calling them due to marshling. This is described in the=20 STABLE-APIS.html document delivered as part of the NDK. =20 [quote]Starting from API level 9, it is possible to entirely write an=20 Android application with native code (i.e. without any Java). That does not mean that your code does not run inside a VM though, and most of the features of the platform will still need to be accessed through JNI.[/quote] =20 Java is the main language to develop standard applications on Android, everything else are just workarounds, even if we don't like it. =20 Another example are the new low level Codec APIs in Jelly Bean, which are only exposed directly via JNI to Java. =20 http://developer.android.com/reference/android/media/MediaCodec.html =20

Gah! What the fuck is this, 1998?!? (Why can't we finally just let Java die as the wretched idea it always was?) I've always seen Android as a slightly-less-shitty clone of iOS. But every time I turn around, I discover another way Google seems hell-bent on proving me wrong. They ape most of Apple's bad ideas and then toss in some of their own. How the hell is it even *possible* for another company to compete this well with Apple on retarded design decisions? I suppose with the death of Jobs it was inevitable for another company to successfully surpass Apple's horridness, but I always figured it would be from Apple getting slightly less crappy or fading back into their 90's obscurity where they belong - not from others sinking down to sub-Jobsian idiocy. I'd never even considered that a possibility. Very depressing. I miss Woz's computers. Fuck, I even miss the days when Microsoft ruled the world with an iron fist. At least back then platforms were open and software/hardware designs were relatively sane from a user's standpoint (even if the code behind them wasn't).
Jul 23 2012
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 21 Jul 2012 23:11:02 +0200
"Adam D. Ruppe" <destructionator gmail.com> wrote:

 On Saturday, 21 July 2012 at 20:17:11 UTC, Nick Sabalausky wrote:
 - Adam's HTML DOM (And I cached partial and full results in 
 memory, of course, so I wasn't DOMming it up on every request)

DOMing it up every request rox. That's what I do and so far the impact of those have been negligible in the profiling.

I never actually benchmarked, so it's entirely possible I was just doing a premature optimization. Does it do anything special for the sake of speed?
Jul 27 2012