Well now, I have got to find time to implement Joy (lang by Manfred von Thun) in this and see if it works. (I can't tell just by thinking about it, at least not so far. It will either work and be great, or not-work and be really really interesting why not.)
Graal and Truffle could accelerate programming language design
131–140 of 204 posts
Re: Graal and Truffle could accelerate programming language design
#132Earlier quoted context omitted.
Startup times are mostly important for scripting or running things in the browser. If you start applications once on the server or desktop and keep them running then steady-state performance is more important. There also are projects underway to bring AOT compilation / caching of compiled code to the JVM. Right now they're only available to commercial customers due to their experimental nature and the needed support…
True about AOT coming to the JVM, however, dynamic languages can't be AOT'd well in general, so that won't help Graal+Truffle languages much. Instead, dynamic languages tend to do tiering, which in principle is something Graal+Truffle could do, but it might be a lot of work.
Well at least it would help you avoid warm-up for the interpreter/compiler itself, so it might help a bit.
Re: Graal and Truffle could accelerate programming language design
#133Okay, very cute, but what if you want your language to have significant semantic differences from C and the like? What if you want to write a Scheme interpreter, for instance? Can I have Continuations? Can I have Tail Call Optimization? I very much doubt it. If you want to write a language that is semantically like C for the most part, than go ahead and use Truffle, but that's not where interesting language design is…
Don't know why you get downvoted. That's exactly what I thought. Java is my main lang and currently I'm working on my hobby project - implementing Scheme r5rs in Java. That is hard! And I doubt I'll be able to implement full r5rs even close. I have no idea (yet) how to implement Continuations: In theory yes, you can implement Continuations in any lang which has Exceptions (the only way in Java to unwind a stack). Lik…
You're not compiling to Java though. You're writing an AST walking interpreter, so you should be able to implement continuations and TCO just fine.
Re: Graal and Truffle could accelerate programming language design
#134There's actually a fairly long history of cross-language VMs, with various degrees of success. What usually happens is that they work fine for languages that look, semantically, basically like the native language on the VM. So LLVM works well as long as your language is mostly like C (C, C++, Objective-C, Rust, Swift). Parrot works if you language is mostly like Perl 6 (Perl, Python, PHP, Ruby). .NET works if your la…
F# isn't much like C#, and in fact it does suffer a bit for it, as some of the back end causes compromises in the F# language. Mutable fields in records have secret baggage, functions with arithmetic operators can't be automatically genericized unless you mark them inline, etc
My biggest let down with F# is that NullReferenceException is still a thing. Also a C# function is called as if they're typed to take tuples but then you can't create a tuple & pass it along
Re: Graal and Truffle could accelerate programming language design
#135Earlier quoted context omitted.
>Even Windows Phone has better support for it, and they do have WinRT and .NET on them. No they don't. Point me to one windows phone audio app that has low latency audio.
Well there are these sources from Microsoft: https://blogs.windows.com/buildingapps/2014/05/15/real-time-... https://rtaudiowsapps.codeplex.com/ https://channel9.msdn.com/Events/Build/2014/3-548 And I just found this, but not sure how good it fares. https://www.microsoft.com/en-us/store/apps/audio-meter/9wzdn...
You linked to an app that measures audio db levels. There are no low latency audio / music apps because windows phone isn't very good at it.
Re: Graal and Truffle could accelerate programming language design
#136Earlier quoted context omitted.
> BASIC is a good demonstration of why the platonic ideal language is wrong That's often my point when people bring up arguments against a language that seems a bit more complex (Perl), or for language simplicity (Python). Some complexity falls into a sliding scale where there is more cognitive load while learning, but it pays of in the every day usage. The siple example of an extreme end of this is APL. If you can i…
> If you can internalize and understand the extremely concise and powerful syntax and semantics of the language (I haven't), you can do amazing things very quickly Not to mention figuring out how to type APL -- that's where I got stuck.
Keyboards are available, but they're expensive:
Re: Graal and Truffle could accelerate programming language design
#137Earlier quoted context omitted.
Android does a bunch of things to keep you off the UI thread(IO throws an exception, handlers, Async Tasks, etc). You still have to GC at some point and when that happens chances are you're going to drop frames. Unless you're very aware of the garbage you're creating you'll take more than ~5ms which is usually enough to push you over 16ms with the other work that goes on during a frame.
Measure Java performance by how Android works is not a good measure. Dalvik is well known on Java world for having a JIT and GC implementations that worse than what most commercial embedded JVM are capable of. Things have improved with ART, but even there there are quite a few performance improvements that Google could eventually do. Soft real time Java GCs for embedded devices are being used in ground station contro…
>As a side note, just check how many Android releases are they going through and yet real-audio support isn't quite there
Actually, there is. As of Android 6.0 Google's CCD includes a section for Professional Audio devices
If a device implementation meets all of the following requirements, it is STRONGLY RECOMMENDED to report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager class.
The device implementation MUST report support for feature android.hardware.audio.low_latency.
The continuous round-trip audio latency, as defined in section 5.6 Audio Latency, MUST be 20 milliseconds or less and SHOULD be 10 milliseconds or less over at least one supported path.
If the device includes a 4 conductor 3.5mm audio jack, the continuous round-trip audio latency MUST be 20 milliseconds or less over the audio jack path, and SHOULD be 10 milliseconds or less over at the audio jack path.
The device implementation MUST include a USB port(s) supporting USB host mode and USB peripheral mode.
The USB host mode MUST implement the USB audio class. If the device includes an HDMI port, the device implementation MUST support output in stereo and eight channels at 20-bit or 24-bit depth and 192 kHz without bit-depth loss or resampling.
The device implementation MUST report support for feature android.software.midi.
If the device includes a 4 conductor 3.5mm audio jack, the device implementation is STRONGLY RECOMMENDED to comply with section Mobile device (jack) specifications of the Wired Audio Headset Specification (v1.1).
Re: Graal and Truffle could accelerate programming language design
#138Earlier quoted context omitted.
> BASIC is a good demonstration of why the platonic ideal language is wrong That's often my point when people bring up arguments against a language that seems a bit more complex (Perl), or for language simplicity (Python). Some complexity falls into a sliding scale where there is more cognitive load while learning, but it pays of in the every day usage. The siple example of an extreme end of this is APL. If you can i…
> If you can internalize and understand the extremely concise and powerful syntax and semantics of the language (I haven't), you can do amazing things very quickly Not to mention figuring out how to type APL -- that's where I got stuck.
Don't worry too much about typing it. The syntax of APL isn't all that powerful and actually limits how you can leverage the aggregate operation semantics.
Re: Graal and Truffle could accelerate programming language design
#139There's actually a fairly long history of cross-language VMs, with various degrees of success. What usually happens is that they work fine for languages that look, semantically, basically like the native language on the VM. So LLVM works well as long as your language is mostly like C (C, C++, Objective-C, Rust, Swift). Parrot works if you language is mostly like Perl 6 (Perl, Python, PHP, Ruby). .NET works if your la…
We should be clear here by what we mean by language. It's perfectly possible and manageable to create cross-language VMs and to translate pretty accurately between languages. However, what breaks down, as you alluded to, is that people expect the standard libraries, and the libraries of others, to work interchangeably, and that is orders of magnitudes more complex (mostly because you are, by definition, working close…
> Do we have a grasp on what it would take to treat the stdlib as a "first class" citizen?
One of the solutions to this problem could be having package management in your language be a first-class citizen, then treating each part of the stdlib as a separate package. If using stdlib code is just as simple as using 3rd-party libraries, then why need a stdlib at all?
Re: Graal and Truffle could accelerate programming language design
#140There's actually a fairly long history of cross-language VMs, with various degrees of success. What usually happens is that they work fine for languages that look, semantically, basically like the native language on the VM. So LLVM works well as long as your language is mostly like C (C, C++, Objective-C, Rust, Swift). Parrot works if you language is mostly like Perl 6 (Perl, Python, PHP, Ruby). .NET works if your la…
Well you have the mainframes model that used kernel JITs for all their official languages, like the OS/400 nowadays IBM i. On IBM i the language surface is RPG, Cobol, C, C++ and Java. On other ones you could eventually consider the micro-coded CPUs as a kind of cross language VMs.
The ctoss-language compatibility was a feature of OpenVMS systems. The AS/400 family had AOT and/or JIT for all object code in system. They also had PL/S that subsetted PL/I by removing runtime. These tech seem to combine all those capabilities in one stack.