July 28, 2012
On 7/27/12 6:38 PM, Dmitry Olshansky wrote:
> Then it's not in anyway better then ranges. You again maintain stack (or
> queue, whatever). The only difference is that for is replaced with a
> function front/popFront that do one iteration of the same state machine.

I'd say this argument on which is "better", yield or ranges, is a problem ill posed.

"yield" adds real, nontrivial value, and is not entirely implementable as a library. Walter and I saw some uses of it in C# at Lang.NEXT that were quite impressive.

On the other hand yield's charter is limited when compared to that of ranges. Yield goes with the very simple "go through everything once" functionality, which is essentially input ranges - only a tiny part of ranges can do.


Andrei
July 28, 2012
On 28-07-2012 14:41, Stuart wrote:
> On Saturday, 28 July 2012 at 11:43:14 UTC, Jacob Carlborg wrote:
>> On 2012-07-28 09:52, Stuart wrote:
>>
>>> Ah. So, in essence, C has a purpose because [a] it supports incredibly
>>> obsolete hardware that nobody in their right mind would be using; and
>>> [b] nobody's ported D to MacOS (or whatever) yet.
>>
>> If you refer to Mac OS X, I use D on it every day. If you're actually
>> referring to MacOS then who cares, it's a dead operating system and
>> has been for at least ten years.
>
> Which only reinforces my point that C is redundant.

See Paulo's post.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
July 28, 2012
On 7/28/12 4:26 AM, Nick Sabalausky wrote:
> God I hope that's not true. Using a VM on a low-power system is just so
> rediculously *wrong* it should be a crime.

Isn't Android standardizing on Java?

Andrei


July 28, 2012
On 28-07-2012 15:42, Andrei Alexandrescu wrote:
> On 7/28/12 4:26 AM, Nick Sabalausky wrote:
>> God I hope that's not true. Using a VM on a low-power system is just so
>> rediculously *wrong* it should be a crime.
>
> Isn't Android standardizing on Java?
>
> Andrei
>
>

Yes (see second paragraph of Nick's post).

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
July 28, 2012
On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
> On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:
>>
>> I tend to favour F# instead of OCaml due to three things
>
> I've never really seen the point of F#. Aside from maths, what is F# good for that a standard imperative language is not? Especially when you consider that all flavours of .NET have native support for LINQ.

Let me see:

- Symbolic code manipulation;
- Metaprogramming;
- Easy parallelization of code thanks to immutable data structures and workflows
- Type providers (comming in F# 3.0) to manipulate remote data as language data types
- The right way of doing type inference (shared by all ML languages)
- Asynchronous programming builtin without having to wait for .NET 4.5
- Algebraic data types

Microsoft wouldn't have brought F# into Visual Studio if it wasn't worth it, Microsoft is a business, not a language charity company.



July 28, 2012
"bearophile" <bearophileHUGS@lycos.com>
> Gotos are not so evil. Just use them when they are useful and they can't
be replaced by structured programming. In D I create finite state machines at compile-time that use gotos, they are quick.

Do you happen to still have the code, by any chance? I think Phobos could use a std.fsm, to automatically generate FSM at compile-time  (using lots of gotos :) ).


July 28, 2012
On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
> On Friday, 27 July 2012 at 19:14:29 UTC, Stuart wrote:
>> On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
>>> On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
>>>>
>>>> Recursion isn't just a security risk - it's a performance hit as well.
>>>
>>> Only in languages without tail call optimizations.
>>
>> Which is pretty much all of them.
>>
>> Scheme does it, and probably HOPE too; but bugger-all you could write a real program in, like .NET or C++. I mean, we're in bloody FORTRAN territory here. What use is that for writing Windows applications?
>>
>> Does D have tail call optimisation?
>
>
> Well, at least all of these:
>
> - Scheme
> - Haskell
> - OCaml
> - F#
> - Erlang
> - Clojure
> - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
> - Most commercial Lisp compilers
>
> Yes D compilers also do tail call optimizations in certain cases, even if not specified in the language spec, picking up an old thread
>
> http://www.digitalmars.com/d/archives/digitalmars/D/learn/Tail_call_optimization_33772.html
>
> --
> Paulo

All implementations of Lua also perform TOC and as far as I know some of Python implementations as well.
July 28, 2012
> All implementations of Lua also perform TOC and as far as I know some of Python implementations as well.

err TCO :)
July 28, 2012
On Saturday, 28 July 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
> On Sat, 28 Jul 2012 09:53:27 +0200
> "Stuart" <stugol@gmx.com> wrote:
>
>> On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis wrote:
>> > On Saturday, July 28, 2012 04:31:40 Alex Rønne Petersen wrote:
>> >> But note, even then, that D only targets 32-bit architectures
>> >> and up, while C can handle 16-bit architectures.
>> >
>> > True, but I'm kind of shocked that anything 16-bit even still exists. _32-bit_
>> > is on its way out. I thought that 16-bit was dead _years_ ago. I guess that
>> > some embedded stuff must use it. But really, I wouldn't expect the lack of 16-
>> > bit support to be much of an impediment - if any at all - and in the long run,
>> > it'll mean absolutely nothing.
>> 
>> Embedded systems mostly use Java now in any case, as I understand
>> it.
>
> God I hope that's not true. Using a VM on a low-power system is just so
> rediculously *wrong* it should be a crime.

Java != VM

There are quite a few companies selling Java native code compilers
for embedded systems.

For example, the Perc systems from Aonix,
http://www.atego.com/products/aonix-perc/

What I can say it that in telecommunications, many SIM cards are
actually running Java Card inside.

http://java.sun.com/javacard/overview.jsp

I know at least of one mobile operator that uses this in all its
SIM cards, and it is a pretty big operator available across Europe.
Due to NDA issues I cannot state the name, but should not be hard to guess.

Not really commercial product, but you can also get a Java Spot, with the VM almost fully implemented in Java, except for the low level hardware access done via native methods.

http://www.sunspotworld.com/

The embedded space is very broad, from the tiny processors which you still have to code in pure Assembly while counting valuable byte space, to some which are big enough to run Java in all flavours, high speed interpreter, JIT or natively.

It all a matter of cost vs type of product you want to sell.

--
Paulo

July 28, 2012
On 7/28/12 10:04 AM, Paulo Pinto wrote:
> On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
>> On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:
>>>
>>> I tend to favour F# instead of OCaml due to three things
>>
>> I've never really seen the point of F#. Aside from maths, what is F#
>> good for that a standard imperative language is not? Especially when
>> you consider that all flavours of .NET have native support for LINQ.
>
> Let me see:
>
> - Symbolic code manipulation;
> - Metaprogramming;
> - Easy parallelization of code thanks to immutable data structures and
> workflows
> - Type providers (comming in F# 3.0) to manipulate remote data as
> language data types
> - The right way of doing type inference (shared by all ML languages)
> - Asynchronous programming builtin without having to wait for ..NET 4.5
> - Algebraic data types
>
> Microsoft wouldn't have brought F# into Visual Studio if it wasn't worth
> it, Microsoft is a business, not a language charity company.

It was for Basic :o). Anyhow, indeed, the tools around it make F# pretty cool (just not all that original as a language).

Andrei