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
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
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:
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
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 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
parent reply 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
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 reply 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
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 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 reply "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
next sibling parent reply 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
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.


+1

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 parent reply 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
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.





 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 reply 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.


=20

=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.


=20
 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
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.





 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 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 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
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 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
next sibling 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
next sibling 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 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.


=20
 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 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 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 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 "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
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
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 "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 parent Caligo <iteronvexor gmail.com> writes:
Just curious, do you know if Alexander Stepanov uses D or not?
Jul 22 2012