July 27, 2012
Nick Sabalausky:

> Chemistry is really weird...

Yep, and that's one of the things it makes is fascinating:
http://en.wikipedia.org/wiki/Ionic_bond

And of course chemistry runs animal bodies like ours :-)

Bye,
bearophile
July 27, 2012
On Friday, 27 July 2012 at 20:42:40 UTC, Nick Sabalausky wrote:
> On Fri, 27 Jul 2012 17:52:27 +0200
> "Jesse Phillips" <Jessekphillips+D@gmail.com> wrote:
>
>> so I guess you can take my opinion of GUI designers with an atom of salt.
>
> <annoyingly pedantic>It would have to be a molecule. Try to take an
> atom of salt and you'll either get a poisonous gas, or
> something that goes boom in contact with water.</annoyingly
> pedantic>

You know, I do believe he's right.
July 27, 2012
On Friday, 27 July 2012 at 20:42:40 UTC, Nick Sabalausky wrote:
> On Fri, 27 Jul 2012 17:52:27 +0200
> "Jesse Phillips" <Jessekphillips+D@gmail.com> wrote:
>
>> so I guess you can take my opinion of GUI designers with an atom of salt.
>
> <annoyingly pedantic>It would have to be a molecule. Try to take an
> atom of salt and you'll either get a poisonous gas, or
> something that goes boom in contact with water.</annoyingly
> pedantic>
>
> Chemistry is really weird...

I realized the whole molecule thing but through laziness it was on purpose. Besides, as you have described here it fits nicely, my opinion could potentially explode with contact to water.
July 27, 2012
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

July 27, 2012
On 27-Jul-12 23:09, Paulo Pinto wrote:
> On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
>> On Friday, 27 July 2012 at 16:28:50 UTC, Dmitry Olshansky wrote:
>>>
>>> But this advantage is unimportant since arbitrary deep recursion is a
>>> security risk (especially for servers that typically use threads with
>>> tiny stacks).
>>
>> I would like to point out here that the example VB.NET code I just
>> gave for lazy-populating a list of all files on a drive uses NO
>> recursion whatsoever.
>>

It sure thing would. Just list your code to do so. Recursively scan all files on drive does involve stack or recursion.

If you mean list all files shallowly then of course no recursion takes place (but then ranges will do the same no problem).

>> Recursion isn't just a security risk - it's a performance hit as well.
>
> Only in languages without tail call optimizations.

Tail call won't do. Precisely because call in this function saves state. In effect you maintain the same stack of directories but implicitly so though hardware call stack with locals.



-- 
Dmitry Olshansky
July 27, 2012
On 27-Jul-12 22:58, Stuart wrote:
> On Friday, 27 July 2012 at 16:15:46 UTC, Jesse Phillips wrote:
>>
>> Taking a look at DirIteratorImpl[1] in std.file suggest there is a lot
>> of setup to navigate the filesystem on Windows. How does Yield help
>> with that logic?
>
> Well, off the top of my head, you could use something like:
>
>     Public Iterator Function AllFiles(RootDirectory As String) As
> IEnumerable(Of String)
>        Dim Roots As New Queue(Of String) From {RootDirectory}
>        While Roots.Any
>           Dim Root = Roots.Pop
>           Roots.AddRange(IO.Directory.GetDirectories(Root))
>           For Each Filename in IO.Directory.GetFiles(Root)
>              Yield Filename
>           Next
>        End While
>     End Function
>

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.

-- 
Dmitry Olshansky
July 27, 2012
On 28-Jul-12 00:42, Nick Sabalausky wrote:
> On Fri, 27 Jul 2012 17:52:27 +0200
> "Jesse Phillips" <Jessekphillips+D@gmail.com> wrote:
>
>> so I guess you can take my opinion of GUI designers with
>> an atom of salt.
>
> <annoyingly pedantic>It would have to be a molecule. Try to take an
> atom of salt and you'll either get a poisonous gas, or
> something that goes boom in contact with water.</annoyingly
> pedantic>
>

Well Na isn't much of boom. K will do much better :)

> Chemistry is really weird...
>

...though Physics is no less so once you are past the Newton mechanics.

-- 
Dmitry Olshansky
July 28, 2012
On 27-07-2012 20:50, Stuart wrote:
> On Friday, 27 July 2012 at 15:27:58 UTC, Alex Rønne Petersen wrote:
>> On 27-07-2012 14:56, Stuart wrote:
>
>>> In any case, isn't it the job of the compiler to unroll loops? Why
>>> should the coder have to do this himself? Unless of course he's using a
>>> thin shitty wrapper over assembly language that claims falsely to be a
>>> high-level language - i.e. C.
>>
>> It was a high-level language at the time it was created.
>
> Quite possibly. But the definition of "high level" has since changed,
> and C no longer qualifies. Yet proponents of C/C++ continue to froth at
> the mouth and claim it's a decent language.
>
> Why is D so awesome? Because it's not C.

In all fairness, I think C still has its place. The advantage of writing software in C is that when you want to port it to a new platform/architecture, there will almost always be a C compiler available. This isn't the case for D yet - but hopefully will be in the future. But note, even then, that D only targets 32-bit architectures and up, while C can handle 16-bit architectures.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
July 28, 2012
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.

- Jonathan M Davis
July 28, 2012
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.

 The largest majority of computers and programs aren't what you and me use on a computer, it's things that are everywhere and they remain hidden. Your watch, your calculator, smart cards, CD players, devices (Like CD-ROM drives). There are still 8bit chips you can buy, program and use. For the main common computers, yes 32bit is going out of style.

http://www.mouser.com/Semiconductors/MCU-MPU-DSP-DSC-SoC-Processors/Microprocessors-MPU/_/N-6hpeh?Keyword=microprocessors&FS=True

 It's been a while since I looked over this list or catalog.