Re: OSCON 2012 notes
On Sat, 21 Jul 2012 23:11:02 +0200 Adam D. Ruppe destructiona...@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?
Re: OSCON 2012 notes
Nick Sabalausky wrote in message news:20120723010439.6efc@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
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
On Mon, 23 Jul 2012 08:59:32 +0200 Paulo Pinto pj...@progtools.org wrote: Nick Sabalausky wrote in message news:20120723010439.6efc@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 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).
Re: OSCON 2012 notes
On 2012-07-23 05:04:39 +, Nick Sabalausky seewebsitetocontac...@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.for...@michelf.ca http://michelf.ca/
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
Am 22.07.2012 01:13, schrieb Nick Sabalausky: On Sat, 21 Jul 2012 14:41:05 +0200 Paulo Pintopj...@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
Re: OSCON 2012 notes
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 Pintopj...@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
Re: OSCON 2012 notes
On 2012-07-21 19:51:37 +, Nick Sabalausky seewebsitetocontac...@semitwist.com said: On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin michel.for...@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.for...@michelf.ca http://michelf.ca/
Re: OSCON 2012 notes
Am 22.07.2012 10:42, schrieb Nick Sabalausky:
On Sun, 22 Jul 2012 01:24 -0700
Jonathan M Davisjmdavisp...@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 Pintopj...@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
Re: OSCON 2012 notes
Am 22.07.2012 14:19, schrieb Michel Fortin: On 2012-07-21 19:51:37 +, Nick Sabalausky seewebsitetocontac...@semitwist.com said: On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin michel.for...@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
Re: OSCON 2012 notes
On Sun, 22 Jul 2012 18:14:23 +0200
Paulo Pinto pj...@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.
Re: OSCON 2012 notes
On Sun, 22 Jul 2012 08:19:12 -0400 Michel Fortin michel.for...@michelf.ca wrote: On 2012-07-21 19:51:37 +, Nick Sabalausky seewebsitetocontac...@semitwist.com said: On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin michel.for...@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.
Re: OSCON 2012 notes
Am 22.07.2012 20:46, schrieb Nick Sabalausky:
On Sun, 22 Jul 2012 18:14:23 +0200
Paulo Pintopj...@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.
Re: OSCON 2012 notes
On 2012-07-22 19:05:45 +, Nick Sabalausky seewebsitetocontac...@semitwist.com said: On Sun, 22 Jul 2012 08:19:12 -0400 Michel Fortin michel.for...@michelf.ca wrote: On 2012-07-21 19:51:37 +, Nick Sabalausky seewebsitetocontac...@semitwist.com said: On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin michel.for...@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.for...@michelf.ca http://michelf.ca/
Re: OSCON 2012 notes
On Sun, 22 Jul 2012 17:58:20 -0400 Michel Fortin michel.for...@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.
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
On 2012-07-21 06:48:57 +, Paulo Pinto pj...@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.for...@michelf.ca http://michelf.ca/
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin michel.for...@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.
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
On 21-07-2012 21:51, Nick Sabalausky wrote: On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin michel.for...@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 a...@lycus.org http://lycus.org
Re: OSCON 2012 notes
On Sat, 21 Jul 2012 01:14:57 -0400 Andrei Alexandrescu seewebsiteforem...@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-programming-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 :(
Re: OSCON 2012 notes
On Sat, 21 Jul 2012 16:17:00 -0400 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Sat, 21 Jul 2012 01:14:57 -0400 Andrei Alexandrescu seewebsiteforem...@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-programming-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/
Re: OSCON 2012 notes
On Sat, 21 Jul 2012 21:59:12 +0200 Alex Rønne Petersen a...@lycus.org wrote: On 21-07-2012 21:51, Nick Sabalausky wrote: On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin michel.for...@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? 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? 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.
Re: OSCON 2012 notes
On 21-07-2012 22:26, Nick Sabalausky wrote: On Sat, 21 Jul 2012 21:59:12 +0200 Alex Rønne Petersen a...@lycus.org wrote: On 21-07-2012 21:51, Nick Sabalausky wrote: On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin michel.for...@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 a...@lycus.org http://lycus.org
Re: OSCON 2012 notes
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.
Re: OSCON 2012 notes
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.
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
On Sat, 21 Jul 2012 14:41:05 +0200 Paulo Pinto pj...@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.
Re: OSCON 2012 notes
On Saturday, July 21, 2012 19:13:20 Nick Sabalausky wrote: On Sat, 21 Jul 2012 14:41:05 +0200 Paulo Pinto pj...@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
Re: OSCON 2012 notes
On Sat, Jul 21, 2012 at 5:38 PM, Jonathan M Davis jmdavisp...@gmx.comwrote: On Saturday, July 21, 2012 19:13:20 Nick Sabalausky wrote: On Sat, 21 Jul 2012 14:41:05 +0200 Paulo Pinto pj...@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
Re: OSCON 2012 notes
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
Re: OSCON 2012 notes
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).
Re: OSCON 2012 notes
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-programming-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
OSCON 2012 notes
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. 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
