On Wednesday, 14 February 2018 at 22:43:21 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 14 February 2018 at 18:43:34 UTC, Mark wrote:
Luna [1], a new programming language that was recently
mentioned on Reddit, also appears to take this "flow-oriented
design" approach. It's purely functional, n
On Wednesday, 14 February 2018 at 18:43:34 UTC, Mark wrote:
Luna [1], a new programming language that was recently
mentioned on Reddit, also appears to take this "flow-oriented
design" approach. It's purely functional, not OO, and I'm
curious to see how it evolves.
[1] http://www.luna-lang.or
On Wednesday, 14 February 2018 at 19:53:31 UTC, H. S. Teoh wrote:
On Wed, Feb 14, 2018 at 06:43:34PM +, Mark via
Digitalmars-d wrote:
On Wednesday, 14 February 2018 at 09:39:20 UTC, Luís Marques
wrote:
> It seems that someone once again rediscovered the benefits
> of component progr
On Wed, Feb 14, 2018 at 06:43:34PM +, Mark via Digitalmars-d wrote:
> On Wednesday, 14 February 2018 at 09:39:20 UTC, Luís Marques wrote:
> > It seems that someone once again rediscovered the benefits of
> > component programming, in the context of OOP, but (as usual) witho
On Wednesday, 14 February 2018 at 09:39:20 UTC, Luís Marques
wrote:
It seems that someone once again rediscovered the benefits of
component programming, in the context of OOP, but (as usual)
without the more mathematical and principled approach of
something like ranges and algorithms
On Wednesday, 14 February 2018 at 09:39:20 UTC, Luís Marques
wrote:
It seems that someone once again rediscovered the benefits of
component programming, in the context of OOP, but (as usual)
without the more mathematical and principled approach of
something like ranges and algorithms:
<h
It seems that someone once again rediscovered the benefits of
component programming, in the context of OOP, but (as usual)
without the more mathematical and principled approach of
something like ranges and algorithms:
<http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/f
I recently reread Walter's 2012 article, as it's _the_ piece I
recommend to others who want to know about D from a technical
perspective:
http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321
Given the great success of H.S Teoh's subsequent artic
Sorry for the very late reply; my internet connection was down for 2
weeks and only came back yesterday.
On Thu, Sep 04, 2014 at 08:03:51AM +, David Ledez via Digitalmars-d wrote:
> Dear T,
>
> I've read with a great attention your reply regarding ECS and OOP. You
> mention that you work on
It was a learning process to understand what should become an
object, and
what should stay as usual procedural (functions/records/units)
code.
Regarding component programming in general, this used to be a
good book on the subject. Only read the first edition (based in
Component Pascal), the s
http://t-machine.org/index.php/2014/03/08/data-structures-for-entity-systems-contiguous-memory/
has some very nice insights in the memory issue.
I've written a coffeescript Entity Component System
once(https://github.com/NikkiKoole/ces), I am planning on using
https://github.com/elvisxzhou/artemisd for my D needs and I am
hoping it's good (and hoping it does the components in some cache
friendly manner).
how does your nitro compare?
On Wednesday, 12 February 2014 at 17:38:30 UTC, H. S. Teoh wrote:
I would say that while it's insightful to apply different
paradigms to
solve the same problem, one shouldn't make the mistake of
shoehorning
*everything* into the same approach. This is what Java does
with OO, for
example, to
busy with other
matters.
On Tue, Feb 04, 2014 at 04:12:48AM +,
digitalmars-d-boun...@puremagic.com wrote:
I loved reading Walter's component programming article in Dr.
Dobb's
[0] in late 2012. I had missed H. S. Teoh's mid 2013 article on
calendar textual formatting using the c
Sorry for this belated reply, I have been rather busy with other
matters.
On Tue, Feb 04, 2014 at 04:12:48AM +, digitalmars-d-boun...@puremagic.com
wrote:
> I loved reading Walter's component programming article in Dr. Dobb's
> [0] in late 2012. I had missed H. S. Teoh'
Am Fri, 07 Feb 2014 09:58:52 +
schrieb "Francesco Cattoglio" :
> On Friday, 7 February 2014 at 09:47:43 UTC, Zoadian wrote:
> > On Friday, 7 February 2014 at 08:09:10 UTC, Mike Parker wrote:
> > Nitro will store Translation like this, so it is even possible
> > to iterate over parts of compon
On Friday, 7 February 2014 at 09:47:43 UTC, Zoadian wrote:
On Friday, 7 February 2014 at 08:09:10 UTC, Mike Parker wrote:
Nitro will store Translation like this, so it is even possible
to iterate over parts of components:
Entity[]
int[] for a
int[] for b.x
int[] for b.y
int[] for b.
On Friday, 7 February 2014 at 08:09:10 UTC, Mike Parker wrote:
On 2/7/2014 12:14 AM, Paul Freund wrote:
You're example almost works. With the EntityComponentManager
API it
works like this:
auto shipEntities = ecm.query!SpaceShip();
foreach (i, spaceship; taskPool.parallel(sh
On 2/7/2014 12:14 AM, Paul Freund wrote:
You're example almost works. With the EntityComponentManager API it
works like this:
auto shipEntities = ecm.query!SpaceShip();
foreach (i, spaceship; taskPool.parallel(shipEntities))
{
auto shipData = spaceship.g
On Thursday, 6 February 2014 at 13:47:22 UTC, Meta wrote:
On Thursday, 6 February 2014 at 05:27:22 UTC, Mike Parker wrote:
A cursory look at Nitro suggests they are using an ECS with
DOP. Given that they're providing ranges for iterating the
data, it will fit into D's range-based component pipe
On Thursday, 6 February 2014 at 05:27:22 UTC, Mike Parker wrote:
A cursory look at Nitro suggests they are using an ECS with
DOP. Given that they're providing ranges for iterating the
data, it will fit into D's range-based component pipelines
(std.algorithm and such).
That seems cool. I can o
On Wednesday, 5 February 2014 at 15:29:14 UTC, Luís Marques wrote:
Still, I wonder how related to the (pipelined) component
approach described by Walter and Teoh this ECS approach really
is. Perhaps more specifically, I wonder if the ECS approach
also allows using a lot of the std.algorithms
On Tuesday, 4 February 2014 at 09:49:39 UTC, Zoadian wrote:
We're currently working on an Entity Component System for D (
https://github.com/Zoadian/nitro)
Here some good explanations:
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
http://w
On Tuesday, 4 February 2014 at 10:24:57 UTC, Paul Freund wrote:
We are currently working on the first "stable" version (and
API). The master branch is the last working state but our
current development is in the finalize_basics
(https://github.com/Zoadian/nitro/tree/finalize_basics) branch,
in
On Tuesday, 4 February 2014 at 10:06:18 UTC, Francesco Cattoglio
wrote:
On Tuesday, 4 February 2014 at 09:49:39 UTC, Zoadian wrote:
We're currently working on an Entity Component System for D (
https://github.com/Zoadian/nitro)
Here some good explanations:
I've seen it too. I like it so far,
On Tuesday, 4 February 2014 at 09:49:39 UTC, Zoadian wrote:
We're currently working on an Entity Component System for D (
https://github.com/Zoadian/nitro)
Here some good explanations:
I've seen it too. I like it so far, because of the nice usage of
templates, but right now I didn't gave it
On Tuesday, 4 February 2014 at 04:12:49 UTC, Luís Marques wrote:
I loved reading Walter's component programming article in Dr.
Dobb's [0] in late 2012. I had missed H. S. Teoh's mid 2013
article on calendar textual formatting using the component
approach [1], but fortunately
I loved reading Walter's component programming article in Dr.
Dobb's [0] in late 2012. I had missed H. S. Teoh's mid 2013
article on calendar textual formatting using the component
approach [1], but fortunately Ali brought it to my attention
recently, and I also find it absolut
On Mon, Aug 19, 2013 at 01:26:42PM +0200, Chris wrote:
> On Monday, 12 August 2013 at 12:28:36 UTC, Jason den Dulk wrote:
[...]
> Btw, I got an error message compiling dcal.d with ldmd2
>
> dcal.d(34): Error: no property 'recurrence' for type 'Date'
>
> It compiles with dmd and works.
What versi
On Monday, 12 August 2013 at 12:28:36 UTC, Jason den Dulk wrote:
On Wednesday, 31 July 2013 at 10:20:57 UTC, Chris wrote:
This is only losely related to D, but I don't fully understand
the separation of component programming and OOP
What the wikipedia entry is saying, in a roundabout w
On Wednesday, 31 July 2013 at 10:20:57 UTC, Chris wrote:
This is only losely related to D, but I don't fully understand
the separation of component programming and OOP
What the wikipedia entry is saying, in a roundabout way is:
All objects are components, but not all components are ob
On 2013-08-04 06:53, Jonathan M Davis wrote:
std.datetime has something like that internally for some of what it does (in
particular, toSimpleString, which I wouldn't even put in there now if I could
go back), but we explicitly didn't make anything like that public, because
it's English-specific
On Tue, Aug 06, 2013 at 06:20:23PM +0200, bearophile wrote:
> H. S. Teoh:
>
> >It looks like I may have to sort out some issues with compiler bugs
> >before officially posting this article, though, since the code
> >apparently fails to compile with many versions of DMD. :-(
>
> If not already pre
H. S. Teoh:
It looks like I may have to sort out some issues with compiler
bugs
before officially posting this article, though, since the code
apparently fails to compile with many versions of DMD. :-(
If not already present, I suggest you to put a reduced version of
the problems you have fo
On Mon, Aug 05, 2013 at 02:11:32PM +0200, Dejan Lekic wrote:
[...]
> Good work! I've read the article yesterday. Very educational!
Thanks!
I did actually make a major revision to the article last night based on
some feedback I got; I rewrote much of the first part of it, so if
you're interested y
.
Yes, please!
Alright, so I decided to prove my point about component
programming by
actually writing a fully-functional version of the calendar
layout
program, so that I have a solid piece of evidence that component
programming lives up to its promise. :) In addition, I decided
that for
m
On Sun, Aug 04, 2013 at 05:02:05AM +0200, bearophile wrote:
[...]
> A bit improved chunkBy could go in Phobos.
Yeah I'll look into that sometime. It'll definitely be a useful thing to
have, I think.
> ---
>
> >For our purposes, though, we can't just do this in a loop, because
> >it
On Sunday, August 04, 2013 06:20:57 Andre Artus wrote:
> > Bearophile:
> > If not already present this array should go in std.datetime or
> >
> > core.time:
> > static immutable string[] monthNames = [
> >
> > "January", "February", "March", "April", "May", "June",
> > "Ju
Bearophile:
If not already present this array should go in std.datetime or
core.time:
static immutable string[] monthNames = [
"January", "February", "March", "April", "May", "June",
"July", "August", "September", "October", "November",
"December"
];
It should probab
H. S. Teoh:
OK, here's a draft of the article:
http://wiki.dlang.org/User:Quickfur/Component_programming_with_ranges
Most of the code below is not tested. So my suggestions may
contain bugs or mistakes.
A bit improved chunkBy could go in Phobos.
---
For our purposes
On Fri, Aug 02, 2013 at 03:02:24PM -0700, H. S. Teoh wrote:
> On Thu, Aug 01, 2013 at 10:49:00PM -0700, Walter Bright wrote:
[...]
> > I think this is awesome, and this + your previous post are
> > sufficient to create a great article!
>
> OK, here's a draft of the article:
>
> http://wiki.
On Saturday, August 03, 2013 01:27:20 Timon Gehr wrote:
> Also, you may want to replace some of the manually implemented ranges
> where this makes sense.
>
> Eg, datesInYear can be expressed more to the point as:
>
>
> auto datesInYear(int year){
> return Date(year,1,1).recurrence!((a,n)=>a
On Sat, Aug 03, 2013 at 04:12:58AM +0200, Timon Gehr wrote:
> On 08/03/2013 01:05 AM, H. S. Teoh wrote:
> >
> >Actually, I just pulled git HEAD again, and it's still working fine.
> >Maybe you just need to update your repo?
> >...
>
> I think it pulled in the wrong version of druntime.
OK, I've w
On 8/3/2013 6:46 AM, David Nadlinger wrote:
In this example, no, as all involved ranges are evaluated lazily. (I see your
general point, though.)
The rules for ranges do not specify if they are done eagerly, lazily, or in
parallel. Meaning, of course, that a library writer could provide all th
On Fri, Aug 02, 2013 at 06:07:02PM -0700, Andrei Alexandrescu wrote:
> On 2013-08-02 23:27:20 +, Timon Gehr said:
> >Also, you may want to replace some of the manually implemented
> >ranges where this makes sense.
> >
> >Eg, datesInYear can be expressed more to the point as:
> >
> >
> >auto dat
On Saturday, 3 August 2013 at 13:46:38 UTC, David Nadlinger wrote:
On Saturday, 3 August 2013 at 13:35:56 UTC, Andre Artus wrote:
import std.stdio;
import std.algorithm;
void main()
{
auto values = [ 1, 2, 3, 4, 5 ];
writeln(values
.map!(a => a * 10)
.map!(a => a / 3)
.filter!(a => !(
On Saturday, 3 August 2013 at 13:35:56 UTC, Andre Artus wrote:
import std.stdio;
import std.algorithm;
void main()
{
auto values = [ 1, 2, 3, 4, 5 ];
writeln(values
.map!(a => a * 10)
.map!(a => a / 3)
.filter!(a => !(a % 2)));
}
As stated this implies 3 separate traversals of th
On Thursday, 1 August 2013 at 22:45:10 UTC, bearophile wrote:
Walter Bright:
But consider that optimizers are built to optimize typical
code patterns. Component programming is fairly non-existent in
C and C++, and is new in D. Hence, optimizers are not set up
to deal with those patterns (yet
On 08/03/2013 01:05 AM, H. S. Teoh wrote:
Actually, I just pulled git HEAD again, and it's still working fine.
Maybe you just need to update your repo?
...
I think it pulled in the wrong version of druntime.
On 2013-08-02 23:27:20 +, Timon Gehr said:
Also, you may want to replace some of the manually implemented ranges
where this makes sense.
Eg, datesInYear can be expressed more to the point as:
auto datesInYear(int year){
return Date(year,1,1).recurrence!((a,n)=>a[n-1]+1.dur!"days")
On 08/03/2013 12:02 AM, H. S. Teoh wrote:
On Thu, Aug 01, 2013 at 10:49:00PM -0700, Walter Bright wrote:
On 8/1/2013 10:24 PM, H. S. Teoh wrote:
Once this last bit worked, though, everything fell into place quickly.
After all unittests were passing, no more bugs were found!! The program
can pri
On 8/2/2013 3:02 PM, H. S. Teoh wrote:
OK, here's a draft of the article:
http://wiki.dlang.org/User:Quickfur/Component_programming_with_ranges
It looks like I may have to sort out some issues with compiler bugs
before officially posting this article, though, since the code
apparently f
On Fri, Aug 02, 2013 at 03:00:01PM -0700, H. S. Teoh wrote:
> On Fri, Aug 02, 2013 at 08:49:30PM +0200, Timon Gehr wrote:
[...]
> > I get the dreaded forward reference errors with at least DMD 2.060,
> > DMD 2.063 and DMD 2.063.2 and the 2.x build on dpaste.
>
> Can you send me the error messages?
On Thu, Aug 01, 2013 at 10:49:00PM -0700, Walter Bright wrote:
> On 8/1/2013 10:24 PM, H. S. Teoh wrote:
> >Once this last bit worked, though, everything fell into place quickly.
> >After all unittests were passing, no more bugs were found!! The program
> >can print beautifully laid out calendars w
On Fri, Aug 02, 2013 at 08:49:30PM +0200, Timon Gehr wrote:
> On 08/02/2013 07:24 AM, H. S. Teoh wrote:
> >...
> >Anyway. Enough hand-waving in the air. Let the actual code speak for
> >itself:
> >
> > https://github.com/quickfur/dcal/blob/master/dcal.d
> >...
>
> Which version of the compiler
On 08/02/2013 07:24 AM, H. S. Teoh wrote:
...
Anyway. Enough hand-waving in the air. Let the actual code speak for
itself:
https://github.com/quickfur/dcal/blob/master/dcal.d
...
Which version of the compiler are you using?
I get the dreaded forward reference errors with at least DMD
H. S. Teoh:
It would be nice to collect these custom ranges and see if
there's some common functionality that can be added to Phobos.
chunkBy seems OK for Phobos.
Bye,
bearophile
On Fri, Aug 02, 2013 at 04:06:46PM +, Justin Whear wrote:
> On Thu, 01 Aug 2013 22:24:32 -0700, H. S. Teoh wrote:
> > Now, w.r.t. the roadblocks I alluded to.
> >
> > When I first started working on the code, my goal was to maximize
> > usage of existing Phobos facilities in order to show how
On Thu, 01 Aug 2013 22:24:32 -0700, H. S. Teoh wrote:
> Now, w.r.t. the roadblocks I alluded to.
>
> When I first started working on the code, my goal was to maximize usage
> of existing Phobos facilities in order to show how many batteries D
> already comes with. As it turned out, I could only us
On Wednesday, 31 July 2013 at 10:20:57 UTC, Chris wrote:
This is only losely related to D, but I don't fully understand
the separation of component programming and OOP (cf.
https://en.wikipedia.org/wiki/Component-based_software_engineering#Differences_from_object-oriented_programming).
On 8/1/2013 10:24 PM, H. S. Teoh wrote:
Once this last bit worked, though, everything fell into place quickly.
After all unittests were passing, no more bugs were found!! The program
can print beautifully laid out calendars with no problems whatsoever.
I'm so in love with D right now... If I'd do
ded to prove my point about component programming by
actually writing a fully-functional version of the calendar layout
program, so that I have a solid piece of evidence that component
programming lives up to its promise. :) In addition, I decided that for
maximum reusability, I want the output lines
Walter Bright:
But consider that optimizers are built to optimize typical code
patterns. Component programming is fairly non-existent in C and
C++, and is new in D. Hence, optimizers are not set up to deal
with those patterns (yet).
I agree.
GHC also works with a LLVM back-end, so those
g about the *other*
>component programming, a method commonly used by game
>developers
>to avoid deep class hierarchies.
>
>http://gameprogrammingpatterns.com/component.html
"Component programing" is kind of a crowded term in programming
which means a lot of different t
n I read Walter's
>article was that I thought he was talking about the *other*
>component programming, a method commonly used by game
>developers
>to avoid deep class hierarchies.
>
>http://gameprogrammingpatterns.com/component.html
"Component programing" is kind of
On Thu, Aug 01, 2013 at 11:40:21PM +0200, Brad Anderson wrote:
> On Thursday, 1 August 2013 at 07:23:42 UTC, Meta wrote:
> >The one thing that confused me at first when I read Walter's
> >article was that I thought he was talking about the *other*
> >component programmi
mizing compiler. Is this a frontend issue or a backend issue?
I don't know.
But consider that optimizers are built to optimize typical code patterns.
Component programming is fairly non-existent in C and C++, and is new in D.
Hence, optimizers are not set up to deal with those patterns (yet).
On Thursday, 1 August 2013 at 07:23:42 UTC, Meta wrote:
The one thing that confused me at first when I read Walter's
article was that I thought he was talking about the *other*
component programming, a method commonly used by game
developers to avoid deep class hierarchies.
On Wednesday, 31 July 2013 at 22:23:54 UTC, bearophile wrote:
Currently this code inlines nothing (the allocations, the
difference and the product):
If you write it in component-style (using doubles here):
Resident compiler guys,
How difficult would it be to make sure stuff like this g
anonymous observer:
ERROR 404 - PAGE NOT FOUND
Andrei
This one, perhaps?
http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf
Yes, it's the same, thank you.
Another comparison (I have not yet read this):
http://www.leafpetersen.com/leaf/publications/hs2013/hrc-paper.pdf
On 8/1/2013 2:23 AM, John Colvin wrote:
On Thursday, 1 August 2013 at 00:47:43 UTC, H. S. Teoh wrote:
Add in some code examples and that could make a nice article.
Yes, please!
On Thursday, 1 August 2013 at 16:13:55 UTC, Andrei Alexandrescu
wrote:
On 7/31/13 6:40 PM, bearophile wrote:
According to this article it seems better, but I have no direct
experience of it:
http://www.leafpetersen.com/leaf/publications/hs2013/haskell-gap.pdf
ERROR 404 - PAGE NOT FOUND
Andre
On Thursday, 1 August 2013 at 00:47:43 UTC, H. S. Teoh wrote:
On Wed, Jul 31, 2013 at 11:52:35PM +, Justin Whear wrote:
On Thu, 01 Aug 2013 00:23:52 +0200, bearophile wrote:
>
> The situation should be improved for D/dmd/Phobos, otherwise
> such D
> component program
On 7/31/13 6:40 PM, bearophile wrote:
According to this article it seems better, but I have no direct
experience of it:
http://www.leafpetersen.com/leaf/publications/hs2013/haskell-gap.pdf
ERROR 404 - PAGE NOT FOUND
Andrei
On 08/01/2013 03:40 AM, bearophile wrote:
> Take a look at this thread in D.learn:
>
> http://forum.dlang.org/thread/mailman.304.1375190212.22075.digitalmars-d-le...@puremagic.com
Yea, this was a frustration. :-( It was really nice to be able to write simple,
clean, elegant code using D -- it wa
On Thursday, 1 August 2013 at 00:47:43 UTC, H. S. Teoh wrote:
On Wed, Jul 31, 2013 at 11:52:35PM +, Justin Whear wrote:
On Thu, 01 Aug 2013 00:23:52 +0200, bearophile wrote:
>
> The situation should be improved for D/dmd/Phobos, otherwise
> such D
> component program
ecause it is still a bit "loopy". And I
guess this is what component programming is all about,
disentangling code.
The only difficulty I have is the opposition to OOP. I don't
really see how the two concepts are mutually exclusive. OOP can
benefit from component programming and
On Wednesday, 31 July 2013 at 22:23:54 UTC, bearophile wrote:
Justin Whear:
If anything, component programming is just functional
programming + templates and some nice syntactic sugar.
And a healthy dose of pure awesome.
What D calls "component programming" is very nice and good,
The one thing that confused me at first when I read Walter's
article was that I thought he was talking about the *other*
component programming, a method commonly used by game developers
to avoid deep class hierarchies.
http://gameprogrammingpatterns.com/component.html
;good
enough" efficiency.
Justin Whear:
I hadn't realized how bug-prone non-trivial loops tend to be
until I started writing this way and avoided them entirely.
I agree.
Thus far, I don't think I've rewritten anything out of the
component pr
On 7/31/2013 5:46 PM, H. S. Teoh wrote:
> [...]
Thank you for an excellent and concise summary of what component programming is
all about!
On Wed, Jul 31, 2013 at 11:52:35PM +, Justin Whear wrote:
> On Thu, 01 Aug 2013 00:23:52 +0200, bearophile wrote:
> >
> > The situation should be improved for D/dmd/Phobos, otherwise such D
> > component programming remains partially a dream, or a toy.
> >
>
On 7/31/13 4:17 PM, bearophile wrote:
Walter Bright:
Ironically, the component program from the article I wrote:
...
is 2x faster than the Haskell version:
Benchmarking code written in two different languages is tricky, there
are so many sources of mistakes, even if you know well both languag
On Thu, 01 Aug 2013 00:23:52 +0200, bearophile wrote:
>
> The situation should be improved for D/dmd/Phobos, otherwise such D
> component programming remains partially a dream, or a toy.
>
> Bye,
> bearophile
I disagree with your "toy" assessment. I've bee
27;ll also agree with you that the component programming style is new in D, and
probably could benefit a great deal from 20 years of concerted effort :-)
I disagree with you that it is a toy, however. Speed is only one measure of
utility.
Walter Bright:
Ironically, the component program from the article I wrote:
...
is 2x faster than the Haskell version:
Benchmarking code written in two different languages is tricky,
there are so many sources of mistakes, even if you know well both
languages. But I accept your timing. And I s
On 07/31/2013 03:46 PM, Walter Bright wrote:
> is 2x faster
What do you mean exactly? :p
Ali
On 7/31/2013 3:23 PM, bearophile wrote:
The situation should be improved for D/dmd/Phobos, otherwise such D component
programming remains partially a dream, or a toy.
Ironically, the component program from the article I wrote:
void main() {
stdin.byLine(KeepTerminator.yes)// 1
On Wed, Jul 31, 2013 at 09:16:20PM +, Justin Whear wrote:
> On Wed, 31 Jul 2013 12:20:56 +0200, Chris wrote:
>
> > This is only losely related to D, but I don't fully understand the
> > separation of component programming and OOP
[...]
> A few things:
> 1) T
Justin Whear:
If anything, component programming is just functional
programming + templates and some nice syntactic sugar.
And a healthy dose of pure awesome.
What D calls "component programming" is very nice and good, but
in D it's almost a joke.
Currently this code inlin
On Wed, 31 Jul 2013 12:20:56 +0200, Chris wrote:
> This is only losely related to D, but I don't fully understand the
> separation of component programming and OOP (cf.
> https://en.wikipedia.org/wiki/Component-
based_software_engineering#Differences_from_object-oriented_programmin
On Wed, Jul 31, 2013 at 12:20:56PM +0200, Chris wrote:
> This is only losely related to D, but I don't fully understand the
> separation of component programming and OOP (cf.
> https://en.wikipedia.org/wiki/Component-based_software_engineering#Differences_from_object-oriented_prog
This is only losely related to D, but I don't fully understand
the separation of component programming and OOP (cf.
https://en.wikipedia.org/wiki/Component-based_software_engineering#Differences_from_object-oriented_programming).
In an OO framwork, the objects are basically components. See
Then maybe you have missed the last two times I have discussed
such topics in D.learn.
Sorry, I meant the main D newsgroup.
Bye,
bearophile
On Tuesday, 28 May 2013 at 17:24:13 UTC, H. S. Teoh wrote:
On Tue, May 28, 2013 at 11:37:06AM +0200, bearophile wrote:
Timothee Cour:
>python uses itertools.product which is lexicographic_depth.
>Like you
>say, no-one can agrees what the order should be, so let's
>leave it up
>to user throug
On 5/28/2013 2:54 AM, bearophile wrote:
The "rewrite rules" is a feature of the GHC compiler. It allows the library
writers to define rules that in most (or many) cases are advantageous and lead
to better optimization. As example one of such rules swap map and filter,
putting the filter before th
On Tuesday, May 28, 2013 19:55:43 Peter Alexander wrote:
> Phobos does this a little bit in simple cases. For example,
> retro(retro(r)) returns r if I remember correctly.
Yes. Phobos tries to optimize useless templates like that, and definitely does
it in this particular case, though I don't kno
On Tuesday, 28 May 2013 at 09:54:35 UTC, bearophile wrote:
The "rewrite rules" is a feature of the GHC compiler. It allows
the library writers to define rules that in most (or many)
cases are advantageous and lead to better optimization. As
example one of such rules swap map and filter, putting
On Tue, May 28, 2013 at 11:37:06AM +0200, bearophile wrote:
> Timothee Cour:
>
> >python uses itertools.product which is lexicographic_depth. Like you
> >say, no-one can agrees what the order should be, so let's leave it up
> >to user through a template. Sounds like a no-brainer to me. There
> >
Jacob Carlborg:
Why not use proper lambdas instead of strings?
Mostly for personal reasons: quoted strings are sometimes a
little shorter, and they require you to use arguments with
default names (as "a" and "b"), this increased standardization
makes me read them a little faster than lambda
1 - 100 of 130 matches
Mail list logo
