Re: Slicing static arrays should be @system
On Sunday, 4 November 2012 at 05:58:20 UTC, Jonathan M Davis wrote: I think that anything that the compiler can't absolutely gurantee is @safe must be @system. If that's annoying in some places, then that's life, because we can't compromise on SafeD just because a few things that we use a lot can't be @safe. Now, if we can make further improvements that make it so that the compiler _can_ determine that something is actually @safe when before it couldn't, then that's great. So, in at least some cases, compiler improvements could be used to reduce the annoyance factor, but I don't think that we can compromise on this. - Jonathan M Davis I completely agree, but I don't think we should decide what should be guaranteed and what cannot by the current state of the compiler. We need a properly specified goal that programmers can rely on, and implementers work towards.
Re: Slicing static arrays should be @system
On Sunday, November 04, 2012 06:48:15 Jakob Ovrum wrote: > So what do we do about all these related issues? I think that anything that the compiler can't absolutely gurantee is @safe must be @system. If that's annoying in some places, then that's life, because we can't compromise on SafeD just because a few things that we use a lot can't be @safe. Now, if we can make further improvements that make it so that the compiler _can_ determine that something is actually @safe when before it couldn't, then that's great. So, in at least some cases, compiler improvements could be used to reduce the annoyance factor, but I don't think that we can compromise on this. - Jonathan M Davis
Re: Slicing static arrays should be @system
On Sunday, 4 November 2012 at 05:31:41 UTC, Jonathan M Davis
wrote:
I just thought that I should bring greater attention to
http://d.puremagic.com/issues/show_bug.cgi?id=8838
As it stands, I think that the slicing static arrays being
considered @safe is
a major hole in SafeD's safety, and I think that it's one that
many of us
aren't aware of. But there seems to be some resistance to
outright making the
slicing of static arrays @system within that bug report, and I
recall similar
resistance in the thread that prompted that bug report
(unfortunately, I don't
remember what thread it was - somewhere in D.Learn I think).
So, I was wondering what the general consensus on this was.
Should slicing
static arrays be considered @system? I honestly don't see how
we could do
otherwise without the compiler being way, way smarter at
detecting escaping
references than is ever going to happen.
Also, I really think that if we're agreed that this change
needs to be made
that it should then be made sooner rather than later, because
it's going to
break code which actually tries to use @safe.
- Jonathan M Davis
Just as a note, if slicing static arrays cannot be @safe, then
type-safe variadic functions can't be @safe either, as it
essentially does the same thing, just implicitly:
void foo(int[] a...)
{
// 'a' is a slice of stack memory when foo *isn't* called
with an explicit array.
}
The compiler does perform its simple escape analysis on such
parameters, but as we know, it's not very smart.
I guess another solution to this particular case is to make it
generate a dynamic array when foo is @safe, but I don't think
anyone is excited about this option...
Then there's the scope parameter storage class. The compiler
isn't very smart about scope parameters either.
So what do we do about all these related issues?
Re: Slicing static arrays should be @system
On Sunday, November 04, 2012 06:37:57 bearophile wrote: > One question is how much work does it take to precisely keep > track of such memory zones inside the static type system of D? :-) I don't think that the type system has any concept of that whatsoever. - Jonathan M Davis
Re: Slicing static arrays should be @system
Jonathan M Davis: I honestly don't see how we could do otherwise without the compiler being way, way smarter at detecting escaping references than is ever going to happen. One question is how much work does it take to precisely keep track of such memory zones inside the static type system of D? :-) Bye, bearophile
Slicing static arrays should be @system
I just thought that I should bring greater attention to http://d.puremagic.com/issues/show_bug.cgi?id=8838 As it stands, I think that the slicing static arrays being considered @safe is a major hole in SafeD's safety, and I think that it's one that many of us aren't aware of. But there seems to be some resistance to outright making the slicing of static arrays @system within that bug report, and I recall similar resistance in the thread that prompted that bug report (unfortunately, I don't remember what thread it was - somewhere in D.Learn I think). So, I was wondering what the general consensus on this was. Should slicing static arrays be considered @system? I honestly don't see how we could do otherwise without the compiler being way, way smarter at detecting escaping references than is ever going to happen. Also, I really think that if we're agreed that this change needs to be made that it should then be made sooner rather than later, because it's going to break code which actually tries to use @safe. - Jonathan M Davis
Re: D vs C++11
On Fri, 2 Nov 2012 18:47:22 -0400 Nick Sabalausky wrote: > On Fri, 02 Nov 2012 14:53:05 -0700 > Walter Bright wrote: > > > On 11/2/2012 2:33 PM, Jacob Carlborg wrote: > > > I said the gap is getting thinner, not that is gone. It got > > > foreach, some form of CTFE, static assert, lambda to mention a few > > > new features. > > > > > > No ranges. No purity. No immutability. No modules. No dynamic > > closures. No mixins. Little CTFE. No slicing. No delegates. No > > shared. No template symbolic arguments. No template string > > arguments. No alias this. > > No proper modules. No properties. Slow compilation. No reference > semantics for classes. No scope guards. Little default initialization. > Goofy ptr and func-ptr declaration syntax. Goofy rules about what > is/isn't virtual. Lots of undefined behavior. Forward declarations. > > Things I'm not entirely certain about: > > No IFTI? No polysemous literals? No finally? > And no underscores in numeric literals. It's a minor little thing, but it's so very nice to have: No more carefully counting digits to make sure you got it right. :)
Re: Transience of .front in input vs. forward ranges
On Sunday, November 04, 2012 02:30:49 Era Scarecrow wrote:
> From watching and gleaming from what I have so far, I can only
> think that transient should NOT be the default way that ranges
> work (as it causes too many problems); However transient should
> be allowed (and available) when possible.
>
> I can only think that perhaps using a template to determine if
> it's transient should be present, that way it's a simple flag to
> enable/disable and should propagate anywhere that that range was
> used.
>
> struct Range(bool isTransient=false) {
>static if (isTransient) {
> //front and transient
>} else {
> //front and non-transient
>}
> }
>
> Unless someone thinks this is a bad approach?
That's just trying to be able to tell a range whether it should be transient
or not and doesn't really solve the problem. The problem is that algorithms in
general assume that front is _not_ transient, and we need to either decide
that algorithms are free to continue to assume that front is non-transient
(meaning that you make front transient on your range at your own risk and no
guarantees that any range-based functions will work with it), or we need to
provide a way for range-based functions to know whether a particular range has
a transient front or not. As such, I think that it comes down primarily to
either
1. Just decide that all input ranges can have transient fronts and that no
ranges greater than input ranges can have transient fronts. Then algorithms
can infer transience from the type of range. This is how Andrei thinks that
it's supposed to work but pretty much no one else does (if nothing else,
because that idea was never made clear anywhere, and no one else inferred that
from the definitions of input ranges).
2. Make it so that any range can have a transient front but provide a template
for checking for it like we do with stuff like hasSlicing or length. Presumably
that template would check that for something like like the existence of
R.isTransient, and ranges with transient fronts would just declare an enum
with that name. Then every range-based function which relied on front not
being transient would have to check whether the range that it was given was
transient or not or fail to compile if it is, and every wrapper range would
have to propogate the isTransient member. Failure to do so in either case
(which _would_ happen at least some of the time, at least outside of Phobos),
would result in transient ranges silently doing bizarre things.
3. Make it so that ranges which can be transient are non-transient by default
but provide a function to get at a transient version for speed (which was the
fastRange proposal in this thread). The main problem here is that when the
fast range gets wrapped, it's transient, and so anything using the wrapped
range will be forced to use the transient version rather than using the non-
transient version and only using the transient version when it's asked for.
So, I don't think that this is particularly viable.
4. Just decide that range-based algorithms can assume that front isn't ever
transient. Any range types which make it transient do so at their own risk.
Honestly, I'd really like to go with #4 and make ByLine and ByChunk use
opApply. I think that transience complicates things too much. Even just having
input ranges have transient fronts really screws with things. Something as
simple as
auto app = appender!E();
foreach(e; range)
app.put(e);
is totally screwed by transience, and it's only operating on input ranges. I
seriously question that a function like std.array.array can be implemented
with a transient front. Without a way to explicitly copy front, you can't have
front be transient and keep it like std.array.array does. And even if there
_were_ a way to explictly copy the result of front, that would be horribly
inefficient in the cases where front isn't transient, because it would force
you
to copy when it was completely unnecessary.
I honestly don't think that transience really works outside of some very
specific use cases, and the cost of trying to support it will not be small. And
given the issues that std.array.array has with it and the fact that
std.array.array really shouldn't have to operate on forward ranges, I don't
think that the idea of input ranges having transient fronts is really going to
work, which would mean using something like isTransient, which has the same
sort of problems as save tends to and is likely to be forgotten even more than
save is. So, I really question that transience and ranges is really going to
work at all. If we _do_ support it though, I think that we need to go the
isTransient route.
- Jonathan M Davis
Re: Transience of .front in input vs. forward ranges
On Saturday, 3 November 2012 at 23:19:11 UTC, H. S. Teoh wrote:
I wish Andrei would give some input as to how we should proceed
with this. I do consider this a major issue with ranges,
because for efficiency reasons I often write ranges that have
transient .front values, and they can lead to subtle bugs with
the current implementation of std.algorithm. It would be good
to settle on this issue one way or another. I'd be happy even
if the decision is to say that transient ranges are invalid and
shouldn't be considered "real" ranges. Anything is better than
the current nebulous state of things which only leads to subtle
bugs for the unwary.
From watching and gleaming from what I have so far, I can only
think that transient should NOT be the default way that ranges
work (as it causes too many problems); However transient should
be allowed (and available) when possible.
I can only think that perhaps using a template to determine if
it's transient should be present, that way it's a simple flag to
enable/disable and should propagate anywhere that that range was
used.
struct Range(bool isTransient=false) {
static if (isTransient) {
//front and transient
} else {
//front and non-transient
}
}
Unless someone thinks this is a bad approach?
Re: Transience of .front in input vs. forward ranges
On Saturday, November 03, 2012 16:21:19 H. S. Teoh wrote: > I wish Andrei would give some input as to how we should proceed with > this. I do consider this a major issue with ranges, because for > efficiency reasons I often write ranges that have transient .front > values, and they can lead to subtle bugs with the current implementation > of std.algorithm. It would be good to settle on this issue one way or > another. I'd be happy even if the decision is to say that transient > ranges are invalid and shouldn't be considered "real" ranges. Anything > is better than the current nebulous state of things which only leads to > subtle bugs for the unwary. I think that you're the only person that I've ever heard of who created a front that was transient outside of std.stdio. But who knows what people outside of this newsgroup are doing. Andrei seems to think that algorithms should consider input ranges' fronts to be transient, and that forward ranges and greater shouldn't have transient fronts. And I don't think that he's said much about it after that (probably mostly because he was out of town and unable to communicate on the newsgroup much for a while). However, I think that he's the only one in this thread who had come to that conclusion. Most of the rest of us agree that transience isn't necessarily related to the type of range at all. And I think that most everyone has considered ranges like ByLine and ByChunk to be bizarre and abnormal and not something that normal algorithms need to worry about (and if anything that ByLine and ByChunk should be changed to be non-transient or to not be ranges at all). If we're going to support transient fronts, then we need a solid plan for doing so. Even if it's the case that we're ultimately going to go with input ranges' fronts being considered transient, and all other ranges' fronts being considered non-transient, we need that to be clear and be made explicitly clear in the docs. It's definitely not how things are treated right now. - Jonathan M Davis
Re: D vs C++11
On Saturday, November 03, 2012 13:46:17 Erèbe wrote: > Nearly no support in vim (my editor of choice) What does vim do for D that it doesn't do for C/C++? Some plugins that you can use for C/C++ probably won't work for D, but vim itself should support D just as well as C/C++. vim is a power user level editor, not an IDE, so most of the types of features that really require understanding the language wouldn't be in vim anyway. > Support should not be a top priority for the D-core now that the > language is well featured ? Something coherent with what already > exist (dmd) ? The folks who work on the compiler and libraries are unlikely to be the same folks working on tools for D. Stuff that requires compiler support does get done by the compiler folks (e.g. providing debug symbols that gdb can use), but IDE stuff? That's not going to be done by the people working on the core language. It's generally a completely different set of people who end up working on that sort of stuff, and even without adding lots of new features to the language, there's still a lot for the core developers to be working on in terms of bug fixing or fleshing out the standard library. And D isn't adding features left and right. In fact, it's mostly feature frozen. So, that long list of features says nothing about the focus of the D community at this point as far as work goes. That just means that lots of work was done in the past. The main focuses of the compiler folks at this point are compiler features which will help make D more fully usable (e.g. adding 64-bit support to Windows) and bug fixes. We're not adding much in the way of features to the language at all at this point. So, their focus is likely where it should be, aside perhaps from which bug in particular gets fixed first. If you want better tools beyond the compiler, then other people need to write them. And other people _do_ write them. We have VisualD, Mono-D, etc. Maybe there aren't enough people working on that sort of thing, but work is definitely being done there. But if you're looking for something like a fully-fledged IDE for D written completely in D, then you're going to have a very long time to wait, because that's the sort of thing that takes years and lots of people to write. And given that all there is that needs to be done for D, that's arguably a very poor use of time anyway, because solid plugins for IDEs like Ecilpse and Monodevelop will do the job just fine for the most part and require far less effort. Maybe we'll get it someday, but no time soon. And other people are putting time and effort into other types of tools to improve D from the standpoint of tools (e.g. some work has been done on getting a package management tool for D similar to what some other languages have). So, work _is_ being done. It just takes time, and we arguably don't have enough people much of anywhere in the various areas of D development. So, pretty much everything is slower than we might like it to be. But it _is_ improving, and work is still getting done. - Jonathan M Davis
Re: D vs C++11
On 11/03/2012 11:01 PM, Malte Skarupke wrote: ... I've learned C++ in the last two years and learned D in the last couple months, and I slightly prefer C++ over D. When I started using C++11, I took for granted that all the features just work. I have run into bugs in both g++ and clang, and I do not actually use C++ for anything beyond experimenting. Using D, I realize that that is actually unusual. There are many bugs in the implementation, but stuff often works. In D you still encounter compiler bugs or inconsistent behavior way too often, and I have workarounds all over my code. Do you not have 'workarounds' all over your C++ code? There are conferences about how to work around C++'s limitations. It is fun, but unproductive.
Re: D vs C++11
On Saturday, November 03, 2012 09:08:16 H. S. Teoh wrote: > Yeah I use vim too, and I don't see any problem. But then again, maybe > he's looking for syntax highlighting or that kind of stuff which I don't > use. D does syntax highlighting just fine. It's distributed with vim, and if you want the latest version, you can grab it from here ( https://github.com/JesseKPhillips/d.vim ), though for some reason, more recent versions are missing from the page at vim.org ( http://www.vim.org/scripts/script.php?script_id=379 ). Jesse Phillips maintains vim's D syntax file, and he's still an active member of the community. I don't know of anything that vim doesn't support with D that it supports with C or C++. It may be that there are further plugins that you can get which work with C/C++ but not D (e.g. I have no idea whether cscope would work or not; I expect that plugins like that would choke on templated stuff though). It doesn't have IDE-level features in general, but vim doesn't have those normally. It's a power user level text editor, not an IDE. - Jonathan M Davis
Re: D vs C++11
On Saturday, 3 November 2012 at 22:45:59 UTC, Tommi wrote:
On Saturday, 3 November 2012 at 22:01:21 UTC, Malte Skarupke
wrote:
D also makes the const keyword more annoying than it should be.
What kind of annoyances regarding const have you encountered in
D?
To start off it's simple things like this:
void main()
{
struct A
{
this(int x) { this.x = x; }
int x;
}
const(A) a = A(5);
A b = a;
}
This doesn't compile. And it will probably never compile. The
issue is that struct A has a context pointer and because of
transitive const, you are not allowed to copy that pointer. And
you can not specify your own copy constructor because all copy
constructors happens post-blit, at which point you'd already have
a non-const pointer. So that will probably never change.
But that's not a big problem.
It's more been stuff like me implementing an equivalent of
std::function from C++. (as I said I like to be more explicit
about things than delegates) I uploaded the code for it here:
http://dpaste.dzfl.pl/60a46049 As you can see there isn't a
single mention of const in there. All I wanted was a const and an
immutable version of opCall and better const correctness for
opAssign, but I just couldn't get it to compile. It'd be great if
you could have a look at it. If you succeed in getting that code
to be const correct, please tell me how you did it. (Also worth
mentioning: I ran into at least two more issues in just this one
file: 1. I couldn't specify the templated opAssign that C++'s
std::function has because of a compiler bug (which will be fixed
in DMD 2.061) and I had to define opAssign twice because there is
no way to specify a function which accepts both an rvalue and an
lvalue) That being said the code still is much cleaner than it
would be in C++.
Another issue I've had was trying to implement my own hashtable
which has more deterministic memory behavior. In that I found it
very difficult to get the ranges for byKey and byValue to be
const correct. I think I had issues with the "inout" keyword when
I was passing pointers marked as inout to the range object. I
think I'll revisit that one tomorrow and maybe I'll then post
code here.
Re: D vs C++11
On Sat, Nov 03, 2012 at 07:14:18PM -0400, Nick Sabalausky wrote: > On Sat, 3 Nov 2012 16:12:44 -0700 > "H. S. Teoh" wrote: > > > I don't even use syntax highlighting > > Now that's hard-core! I've *tried* using it before, mind you. I just found the colors more distracting than helpful. But then, I'm just a crazy command-line-only relic from the 70's. My window manager is something that turns X11 into a glorified text console. I don't do desktops at all. (Sometimes I chmod -w $HOME in order to prevent Firefox from creating a Desktop subdir in my home.) So I don't expect many to share my views on these things. :-P T -- Let's call it an accidental feature. -- Larry Wall
Re: CTFE, std.move & immutable
On Saturday, 3 November 2012 at 21:24:29 UTC, Dmitry Olshansky wrote: it explicitly reinterprets data as chunk of bytes Sounds like a bad idea
Re: Transience of .front in input vs. forward ranges
On Fri, Nov 02, 2012 at 04:17:10PM -0400, Jonathan M Davis wrote: > On Friday, November 02, 2012 10:01:55 H. S. Teoh wrote: > > Ah, I see. That makes sense. So basically it's not the source (or > > any intermediate step) that decides whether to use the optimization, > > but the final consumer. > > > > Though now we have the issue that all intermediate ranges must > > propagate .fast, which is troublesome if every range has to do it > > manually. Can this be handled automatically by UFCS? > > It's no different form propogating slicing or random access or > whatnot. Wrapper ranges have to look at the capabilities of the ranges > that they're wrapping and create wrappers for each of the range > functions where appropriate. If we added isTransient or fastRange or > whatever, wrapper ranges would then have to take it into account, or > the wrapper wouldn't have it. [...] I wish Andrei would give some input as to how we should proceed with this. I do consider this a major issue with ranges, because for efficiency reasons I often write ranges that have transient .front values, and they can lead to subtle bugs with the current implementation of std.algorithm. It would be good to settle on this issue one way or another. I'd be happy even if the decision is to say that transient ranges are invalid and shouldn't be considered "real" ranges. Anything is better than the current nebulous state of things which only leads to subtle bugs for the unwary. T -- Real Programmers use "cat > a.out".
Re: D vs C++11
On Sat, 3 Nov 2012 16:12:44 -0700 "H. S. Teoh" wrote: > I don't even use syntax highlighting Now that's hard-core!
Re: D vs C++11
On Sat, Nov 03, 2012 at 11:37:15PM +0100, "Erèbe" wrote: [...] > On Saturday, 3 November 2012 at 16:06:11 UTC, H. S. Teoh wrote: > >Yeah I use vim too, and I don't see any problem. But then again, > >maybe he's looking for syntax highlighting or that kind of stuff > >which I don't > >use. > > I only use IDE at the beginning (for a new language or librairy) > because I found autocompletion helpful, after that I switch back to > vim. So what's missing about D support in vim? > >But still. Oleg has a point -- IDE support and other such things need > >to be done by other people than the core developers, who need to > >focus on honing the language. > > > >I find it strange that every so often people clamor for IDE support, > >syntax highlighting, debugger support, etc., yet nobody seems to be > >willing to contribute actual code. Don't like something about the > >current state of D development tools? Well then do something about > >it. The source code is there for a reason, and it's not just to make > >people feel all warm and fuzzy inside because now we can label > >ourselves "open source". [...] > I was expecting the argument of "Not happy ? Do it yourself !". I > shall be glad to do it by myself, but I don't have the knowledge (of > the language, of the codebase) yet, and in regards with my studies > and the time I can dedicate to my side-projects, I will not be > started before 6 months or more. What I said wasn't directed at you specifically. I was just saying that the state of IDE support, etc., are the way they are, because so far few have stepped up to do something about it. We've had a lot of people complain about lack of IDE support, debugger, etc., but we haven't had many volunteers to actually do the work, so there's really not much that can be done about it. For one thing, I only use vim with gdb and command-line tools, so I wouldn't even know where to begin in terms of adding/improving IDE support for D. I don't even use syntax highlighting or any of that stuff. > My point is, there may are a lot of people with that knowledge in > the community, and a little impulsion from the root should be > helpful, because modern support will make D shine even brighter. We *have* had repeated requests for this stuff, and I'm sure whoever has that knowledge in this community have taken heed, but apparently that hasn't been enough. So maybe what we really need is somebody to take the initiative to be the first to make it all happen, I guess? > I will work toward this direction but it will take me time. Best of luck to you, then! Maybe you can be the first one to make it happen. T -- A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White
Re: D vs C++11
On Sat, 03 Nov 2012 23:45:58 +0100
"Tommi" wrote:
> On Saturday, 3 November 2012 at 22:01:21 UTC, Malte Skarupke
> wrote:
> >
> > D also makes the const keyword more annoying than it should be.
>
> What kind of annoyances regarding const have you encountered in D?
My understanding is that Phobos, and even Object, aren't totally
const-correct yet, so that's given people some trouble. ('Course, my
info on that might be outdated, I don't know.)
Re: 'with' bug?
On Saturday, 3 November 2012 at 20:29:14 UTC, bearophile wrote: Faux Amis: Care to elaborate on that? They share most of the problems of global variables. While not evil, it's better to avoid module-level mutables. This makes the code more testable, simpler to understand, less bug prone, and makes functions more usable for other purposes. In D there the attribute "pure" is present also to enforce such better coding style. Let's not forget that since global variables are 'per thread' that the issues involving them lessen and are less evil than before.
Re: D vs C++11
On Sat, 03 Nov 2012 23:01:19 +0100 "Malte Skarupke" wrote: > On Friday, 2 November 2012 at 17:03:38 UTC, Erèbe wrote: > > Hello student here, > > > > I have started to learn D a few months ago with Andrei's book > > (I really liked arguments about design decisions), but as the > > same time I was learning new features of C++11, and now I'm > > really confused. (As learning projects, I've done an IRC Bot in > > D and an IPv6 stack in C++11) > > > > D is a great language and introduce a lot of features I really > > like (range, property, UFCS, great metaprogramming, ...) but > > C++11 and the new standard librairy are well supported now. > > > > I have some solid experience with C++, so I know how cumbersome > > C++ could be (C++11 and universal reference ?), but D has a lot > > of features too and (as C++) a slow learning curve. > > > > I would like to konw the point of view of the community about > > C++11 in regard of D ? Is the gap between D and C++11 is > > getting thinner ? Do you think D will keep attracting people > > while at the same time C++11 has more support (debugger, IDE, > > Librairies, Documentation) ? > > I've learned C++ in the last two years and learned D in the last > couple months, and I slightly prefer C++ over D. When I started > using C++11, I took for granted that all the features just work. > Using D, I realize that that is actually unusual. In D you still > encounter compiler bugs or inconsistent behavior way too often, > and I have workarounds all over my code. [...] > D also makes the const keyword more annoying than it should be. > In C++ you typically use it as an indicator for the intent of the > interface and to prevent you from making mistakes. There are some > programmers who find it very annoying and who never use const. In > D I am leaning towards being one of those programmers, even > though I belong to the group who uses const more strictly in C++. > Bringing things back to another branch of this thread: What you say here is a big part of the reason our core devs aren't focused on IDE sorts of things right now. Because this core stuff needs to come first. That said, my experience with the current state of D seems to be better than yours, unfortunately. But maybe that's because I was using D five or so years ago (and mostly gave up on C++ close to 10 years ago) and so the thing I see most is the improvement since then (plus, of course, I've become more accustomed to dealing with the issues when they do pop up). You do raise some fair points. *Personally* I find dealing with D's occasional hiccups to be much more than totally compensated for by D's benefits. But YMMV, of course.
Re: D vs C++11
On Saturday, 3 November 2012 at 22:01:21 UTC, Malte Skarupke wrote: D also makes the const keyword more annoying than it should be. What kind of annoyances regarding const have you encountered in D?
Re: D vs C++11
On Saturday, 3 November 2012 at 13:17:46 UTC, bearophile wrote: Erèbe: Is there a point in the D roadmap where we will see "Okay, D has enough features, let add some support to the language now" ? Because in my opinion D is for now just a language, a awesome one yes, but not yet a good environnement for developper. You are missing some essential points. First of all features are not just "done": they have corner cases to be fixed, details to be improved, they need to be fully implemented, they need to become efficient, bugs need to be removed, new needs ask for new parts, there are new CPUs to support, new OSes, new vector extensions added to CPUs, and so on. So in the end the work for the core language developers never ends. Putting such developers at work on tools is not a good idea, because then no one does the essential work on the core language and they will often be newbies regarding tools. So it becomes a lose-lose situation. You can't stop the development of the core language to develop tools, it causes a disaster. Usually you have to build a language good enough that it attracts other people, that are willing to work on tools and external modules :-) Bye, bearophile Duly noted On Saturday, 3 November 2012 at 15:25:07 UTC, Kiith-Sa wrote: http://forum.dlang.org/thread/khmerwhgumluolifx...@forum.dlang.org#post-khmerwhgumluolifxtix:40forum.dlang.org Thanks I will try ! On Saturday, 3 November 2012 at 16:06:11 UTC, H. S. Teoh wrote: Yeah I use vim too, and I don't see any problem. But then again, maybe he's looking for syntax highlighting or that kind of stuff which I don't use. I only use IDE at the beginning (for a new language or librairy) because I found autocompletion helpful, after that I switch back to vim. But still. Oleg has a point -- IDE support and other such things need to be done by other people than the core developers, who need to focus on honing the language. I find it strange that every so often people clamor for IDE support, syntax highlighting, debugger support, etc., yet nobody seems to be willing to contribute actual code. Don't like something about the current state of D development tools? Well then do something about it. The source code is there for a reason, and it's not just to make people feel all warm and fuzzy inside because now we can label ourselves "open source". T I was expecting the argument of "Not happy ? Do it yourself !". I shall be glad to do it by myself, but I don't have the knowledge (of the language, of the codebase) yet, and in regards with my studies and the time I can dedicate to my side-projects, I will not be started before 6 months or more. My point is, there may are a lot of people with that knowledge in the community, and a little impulsion from the root should be helpful, because modern support will make D shine even brighter. I will work toward this direction but it will take me time.
Re: D vs C++11
On Saturday, 3 November 2012 at 15:06:36 UTC, mist wrote: Ye, that is exactly what I meant when said C++ has no real context capture and thus no real delegates here. The std::function is just as "real" as any delegate. And the variable capture [&] is just as real as in any other language. The only difference is that you have to manage the lifetimes of variables instead of having a GC randomly pause your app. So if you want to _return_ an object, you have to make sure it's valid. That makes it no less "real" than any other type of delegate; it's just forcing you to think about the lifetime of the context. Welcome to C++ I guess?
Re: D vs C++11
On Sat, 03 Nov 2012 13:46:17 +0100 "Erèbe" wrote: > > All of you name a lot of missing features in C++11, while I > completely agree upon that makes D cool, don't you fear a turtle > effect if D only focus on features ? > I explain myself, C++ is a well supported language and come with > a lot of tools which could help/improve your developpement. In > the decision of taking D xor C++, developper could think "Hey I > already know C++ and how to work with it (aka tools), let just > stick with it and wait for the new C++11 features coming for > free". In that situation, C++11's no effort (or little to learn > new additions) seem more rewarding than learning D, so why try ? > That is a problem we face, but it's true of any up-and-coming language, and it's not really specific to "focus on features". I'd say the biggest selling points to C++ users would be much better productivity, and much better safety without sacrificing efficiency. In other words, C++'s two biggest known weak points. > Is there a point in the D roadmap where we will see "Okay, D has > enough features, let add some support to the language now" ? We've *already* been at that point there for some time. Language features are no longer added without strong justification. And the primary focuses are on toolchain and fleshing out the std lib. > C(++) had man (K in vim) and gdb, pascal his own ide, dynamic > languages have their interpreters, Java eclipse, what has D ? > Such things are typically cross-language these days (well, except for interpreters). What what D has is "All that cross-language stuff". As examples: a lot of people use gdb with D, D syntax highlighting is in damn near every editor on the planet (and definitely all scintilla-based ones), and there are D plugins for all the major IDEs: Eclipse, VisualD and Mono-Develop. That said, D does have DustMite which isn't an editor anything like that, but it is damn awesome: https://github.com/CyberShadow/DustMite/wiki > Nearly no support in vim (my editor of choice), a Plugin for > eclipse wich force you to stick with an older version, Hmm, I guess I wouldn't have known. I can't use vi, and I don't use Eclipse (too bloated). > a Visual studio plugin where you need to buy a liscence in order to > have the IDE. I don't know where you got that, but that's that remotely true. It works fine with the free VS shell, even says so on the VisualD homepage, and I've done it that way myself. > The only viable choice for me is the plugin for > monodevelop which is really great but no debugger (assert is > enough for now). > Lots of people here use vim and swear by it. And again, gdb for debugging. (But I'm a printf-debugging fan myself. Or writeln in D's case ;) ) > Support should not be a top priority for the D-core now that the > language is well featured ? Something coherent with what already > exist (dmd) ? Ideally, yes, but they have other big things to work on too, and there's only so much manpower to go around. Especially since very few of the people who really want or expect big IDE features have been willing to join up and lend a hand.
Re: D vs C++11
On Friday, 2 November 2012 at 17:03:38 UTC, Erèbe wrote: Hello student here, I have started to learn D a few months ago with Andrei's book (I really liked arguments about design decisions), but as the same time I was learning new features of C++11, and now I'm really confused. (As learning projects, I've done an IRC Bot in D and an IPv6 stack in C++11) D is a great language and introduce a lot of features I really like (range, property, UFCS, great metaprogramming, ...) but C++11 and the new standard librairy are well supported now. I have some solid experience with C++, so I know how cumbersome C++ could be (C++11 and universal reference ?), but D has a lot of features too and (as C++) a slow learning curve. I would like to konw the point of view of the community about C++11 in regard of D ? Is the gap between D and C++11 is getting thinner ? Do you think D will keep attracting people while at the same time C++11 has more support (debugger, IDE, Librairies, Documentation) ? I've learned C++ in the last two years and learned D in the last couple months, and I slightly prefer C++ over D. When I started using C++11, I took for granted that all the features just work. Using D, I realize that that is actually unusual. In D you still encounter compiler bugs or inconsistent behavior way too often, and I have workarounds all over my code. I also prefer C++ being much more explicit about everything it does. For example I prefer the lambdas with a capture list over D delegates. And in D you've got the core runtime allocating memory without me being aware of it all the time. Sure, it gets garbage collected at some point, but I'd rather that it didn't do it at all. D also makes the const keyword more annoying than it should be. In C++ you typically use it as an indicator for the intent of the interface and to prevent you from making mistakes. There are some programmers who find it very annoying and who never use const. In D I am leaning towards being one of those programmers, even though I belong to the group who uses const more strictly in C++. That being said I do think that I write better code in D, but I wouldn't use it for real projects any time soon. It just isn't ready, and I'm sure that my existing code will break several more times in future compiler versions. At the moment the issue is that C++11 is pretty good, and D is not ready. So people will start using C++11 and they'll see that it's good enough and they'll never migrate. The best features of D don't matter if the language is a bit annoying as soon as you leave the space of clean and nice examples.
CTFE, std.move & immutable
I was looking to find a way to make std.algorithm.move CTFE-able. AFAIK
it's not easy as it explicitly reinterprets data as chunk of bytes and
that's something CTFE doesn't support at all.
So I went on and tried to just make a copy and then put write T.init
into source, that's a copy and is somewhat fragile w.r.t. opAssign but
should work.
And then...
std\algorithm.d(1563): Error: cannot modify struct source Data with
immutable members
std\container.d(983): Error: template instance std.algorithm.move!(Data)
error instantiating
std\container.d(1490):instantiated from here: SList!(Data)
std\container.d(1490): Error: template instance
std.container.SList!(Data) error instantiating
Strangely it moves a struct with a const field. In essence it can move
immutable struct and will happily bit-blast it's previous location with
T.init. That could be quite problematic...
Just for fun I tried this, kind shocked (and hit another bug in the
compiler while writing it):
import std.algorithm;
struct C{ int dummy; }
struct S{
immutable C c;
int dummy;
this(int x){
c = C(x);
dummy = x;
}
//to get T.init memcpy-ed over us
this(this){}
//uncomment this to the impenetrable:
// Error: can only initialize const member c inside constructor
// And no line number ...
// ~this(){}
//curiously having ~this() without this(this) works but not together
}
immutable C a = C(36);
S s = S(47);
void main(){
//auto x = move(a); //doesn't compile, pointer to immutable vs void* in
memcpy
//assert(a.dummy == 0);
//
auto y = move(s);
assert(s.c.dummy == 0); //yay! we've fooled typesystem
assert(y.c.dummy == 47);
}
Soo... CTFE won't allow us to grossly break typesystem with an interpret
cast. I believe we should forbid moving immutable/const stuff and honor
the typesystem.
In any case for message passing (the prime use case) you still can move
pointer to (slice of) immutable anyway?
P.S. I'm not first to discover this odd behavior of move...
A related pull request mentioning this problem among others:
https://github.com/D-Programming-Language/phobos/pull/923
--
Dmitry Olshansky
Re: 'with' bug?
Faux Amis: Care to elaborate on that? They share most of the problems of global variables. While not evil, it's better to avoid module-level mutables. This makes the code more testable, simpler to understand, less bug prone, and makes functions more usable for other purposes. In D there the attribute "pure" is present also to enforce such better coding style. Bye, bearophile
Re: 'with' bug?
On 02/11/2012 20:19, bearophile wrote: Faux Amis: When talking about global variables are we talking about module scope variables? Right, in D with "global scope" I meant "module scope". As I see the module as the most primary data encapsulation in D, I often use module scope variables (in combo with static import). In my opinion that's a bad practice in D. Care to elaborate on that? I didn't know you could shadow globals and in my situation it sounds bug prone. It's not terrible, I am able to write code. But I think it doesn't help. Bye, bearophile
Re: D vs C++11
On Sat, Nov 03, 2012 at 08:19:15AM +0100, Paulo Pinto wrote: [...] > Languages get adopted because of business value, not due to the > coolness of their feature set, how boring it may sell. > > If we want to sell D to companies using C++ for years, slowly > migrating to JVM, .NET worlds, or just updating their codebases to > C++11, then we need to sell D's business value not feature lists. [...] I understand that business types ultimately don't care for feature lists, etc., but the thing about D isn't so much the features themselves, but rather how those features save development costs. For example, I've been working on this particular project in my day job for a while now, and I see almost every day how the lack of a certain feature in C++ or C (or the bad design/implementation of said feature) is costing lots and lots of duplicated or plain wasted development time. Lots of code is copy-n-pasted, or otherwise duplicated, because of the lack of reusable constructs. A certain database subsystem was designed with a particular use in mind, with structs that may contain some nested lists, etc.. Recently they wanted to introduce a JSON-based interface for it. It ended up requiring a lot of duplicated logic, simply because the lack of destructors in C required special-casing a lot of code just to clean things up properly. If this had been done in D, first of all, there wouldn't even need to be an elaborate subsystem for mapping structs to SQL: we'd just write a template-based wrapper that used compile-time introspection to automate most of the code. That, or used AA's and alias this or opDispatch to simulate the structs, which can be done in a day or two's work as opposed to 2 months. Then for the JSON-based interface, the GC would just take care of any garbage that gets generated, so no special casing would be needed. This alone would have saved hundreds of hours of development work, not to mention alleviated many subtle pointer bugs and other problems that we've had to fix over the years, which probably adds up to another hundreds of hours. So much time is wasted in working around C/C++ deficiencies and cleaning up the resulting mess, that I think that alone would have justified using D instead. I mean, we're talking about hundreds of development hours that could've been invested in actual *development* rather than mere maintenance and cleanup. Hundreds of employee hours, which come with the cost of employee benefits, associated costs, etc.. About the only good thing with the current situation is that we'll never be out of a job, because there is no end to the mess that comes from C/C++. T -- If it breaks, you get to keep both pieces. -- Software disclaimer notice
Re: mixin functions
On 11/02/2012 10:30 PM, Jacob Carlborg wrote: On 2012-11-02 21:03, Manu wrote: I bumped into this today actually. It's certainly a nice idea. I see a lot of noise about said AST macros... I understand the idea, but I have no idea how it might look in practice. Are there any working proposals? No, not for D. But there are several other languages that have AST macros: Scala: http://scalamacros.org/ Nimrod: (templates and macros) http://nimrod-code.org/tut2.html#templates Nemerle: http://nemerle.org/wiki/index.php?title=Macros Nemerle also supports creating new syntax for the language. - http://www.haskell.org/haskellwiki/Template_Haskell - http://opendylan.org/books/dpg/db_329.html - http://en.wikipedia.org/wiki/Common_Lisp#Macros (not a complete list at all.)
Re: [OT] D mentioned in Channel 9 TypeScript/Dart interview
On Saturday, 3 November 2012 at 18:18:50 UTC, Andrej Mitrovic wrote: I'm almost sure Charles interviewed Walter and Andrei once, it was on video somewhere. Yes, he did: http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-6-The-D-Episode-with-Walter-Bright-and-Andrei-Alexandrescu David
Re: D vs C++11
On 11/03/2012 08:19 AM, Paulo Pinto wrote: On Friday, 2 November 2012 at 23:08:00 UTC, Timon Gehr wrote: On 11/02/2012 10:53 PM, Walter Bright wrote: On 11/2/2012 2:33 PM, Jacob Carlborg wrote: I said the gap is getting thinner, not that is gone. It got foreach, some form of CTFE, static assert, lambda to mention a few new features. No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this. No static if. Limited forward references. No real function local aggregate types. No real nested classes. No local template instantiation. No nested functions. No value range propagation for implicit conversions. No built-in string support. No built-in unicode support. No template guards. No inout. No default-initialization. No return type deduction for non-lambdas. No generic lambdas. No type deduction for lambda parameter types. No super. Less powerful typeof that is called decltype. No is-expressions. No compile-time reflection. No thread-local by default. No UFCS. No tuple/sequence types. No sequence auto-expansion. No sane built-in array types. No tuple slicing. No .init/.min/.max/etc. No kind of static foreach. No new scopes introduced in case statements. No block statements in a for-loop initializer. No optional parentheses on function calls. No implicit reference types. No ^^ operator. No binary ! operator. No built-in complex number types. Less comparison operators. None of eg. bearophile's enhancement requests. ... in no particular order, afaik, and to name a few. :o) What I have learned in all my years of enterprise development is that all those features have zero value for business. Languages get adopted because of business value, not due to the coolness of their feature set, how boring it may sell. If we want to sell D to companies using C++ for years, slowly migrating to JVM, .NET worlds, or just updating their codebases to C++11, then we need to sell D's business value not feature lists. Maybe you misunderstood. I am not trying to make D look good. The point of the post was to show that C++11 and D are quite different languages. Walter's list was rather short.
Re: [OT] D mentioned in Channel 9 TypeScript/Dart interview
On 11/3/12, David Nadlinger wrote: > Apparently, spreading the word about D is on Charles Torre's > secret agenda. ;) > > In all seriousness, I just found it funny that he compares trying > to establish a »more productive JavaScript« to trying to bring > people from C++ to D at ~23:00 in the following conversation with > Anders Hejlsberg and Lars Bak: > > http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-and-Lars-Bak-TypeScript-JavaScript-and-Dart > > Maybe Walter's talk at GOTO was shortly before the interview took > place? > > David > I'm almost sure Charles interviewed Walter and Andrei once, it was on video somewhere.
Re: D vs C++11
I'm not convinced D has caught up to C++ yet from a usability standpoint, as the tools are still quite bad(VisualD -not- fun). But the other day I tried out MonoD and it shows promise, auto completion is solid, and it seems to have at least some of the features I've come to expect from using Visual C++ with Visual Assist. Its still behind though, perhaps in another year? Ideally VisualD would support the completion/reflection stuff MonoD has, and that would be a pretty awesome package that I think would attract many more developers.
Re: D vs C++11
On Sat, 03 Nov 2012 12:23:17 -0500, Rob T wrote: Geany on Linux has good D support. It seems more like an editor than a true IDE, but it does have some project management features and ability to execute builds. Codeblocks is a complete feature rich C++ cross platform IDE, it has some D support but it is incomplete last I checked. --rt I LOVE geany. Especially with the built in terminal. I bound ctr-alt to switch to the terminal and ctr-super to switch to the editor. When I need to easily look through multiple files, geany is my goto. I found that the Terminal was easier and far more hackable for builds than any built in execution.. But that's just me. I think Geany's D Syntax highlighting could use a little work(But it does highlight aliases as types, which is awesome), but It's never been enough of an issue for me to actually fix it. (And I might simply be running an older release) Also I think Geany's block insert and block highlighting is easier than Vim's. I never really liked CodeBlocks, It seems like it has soo many things that I wouldn't use simply because the manual method is easier. But it is important to mention, since I assume lots of people don't know about all of the IDE's that support D.
[OT] D mentioned in Channel 9 TypeScript/Dart interview
Apparently, spreading the word about D is on Charles Torre's secret agenda. ;) In all seriousness, I just found it funny that he compares trying to establish a »more productive JavaScript« to trying to bring people from C++ to D at ~23:00 in the following conversation with Anders Hejlsberg and Lars Bak: http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-and-Lars-Bak-TypeScript-JavaScript-and-Dart Maybe Walter's talk at GOTO was shortly before the interview took place? David
Re: D vs C++11
Geany on Linux has good D support. It seems more like an editor than a true IDE, but it does have some project management features and ability to execute builds. Codeblocks is a complete feature rich C++ cross platform IDE, it has some D support but it is incomplete last I checked. --rt
Re: Simple implementation of __FUNCTION
On Saturday, 3 November 2012 at 11:09:48 UTC, Jacob Carlborg wrote: I think it would be worth to but in Phobos anyway. I suppose it works as a temp solution until a real one is finally implemented, or maybe the mixin behaviour is considered a bug and can be fixed?
Re: D vs C++11
On Sat, 03 Nov 2012 11:08:16 -0500, H. S. Teoh wrote: On Sat, Nov 03, 2012 at 09:02:58AM -0500, 1100110 wrote: On Sat, 03 Nov 2012 07:46:17 -0500, Erèbe wrote: [...] >Nearly no support in vim (my editor of choice), a Plugin for >eclipse wich force you to stick with an older version, a Visual >studio plugin where you need to buy a liscence in order to have >the IDE. The only viable choice for me is the plugin for >monodevelop which is really great but no debugger (assert is >enough for now). [...] Nearly no support in Vim? Are you joking? What does Vim not support for D that you want it to? [...] Yeah I use vim too, and I don't see any problem. But then again, maybe he's looking for syntax highlighting or that kind of stuff which I don't use. But still. Oleg has a point -- IDE support and other such things need to be done by other people than the core developers, who need to focus on honing the language. I find it strange that every so often people clamor for IDE support, syntax highlighting, debugger support, etc., yet nobody seems to be willing to contribute actual code. Don't like something about the current state of D development tools? Well then do something about it. The source code is there for a reason, and it's not just to make people feel all warm and fuzzy inside because now we can label ourselves "open source". T Check out D.Announce. Even *more* support for D in vim. I'm happy enough with my current setup, but I also want to play with this.. -- Wait. Define 'within'.
Re: D vs C++11
On Sat, Nov 03, 2012 at 09:02:58AM -0500, 1100110 wrote: > On Sat, 03 Nov 2012 07:46:17 -0500, Erèbe wrote: [...] > >Nearly no support in vim (my editor of choice), a Plugin for > >eclipse wich force you to stick with an older version, a Visual > >studio plugin where you need to buy a liscence in order to have > >the IDE. The only viable choice for me is the plugin for > >monodevelop which is really great but no debugger (assert is > >enough for now). [...] > Nearly no support in Vim? Are you joking? What does Vim not > support for D that you want it to? [...] Yeah I use vim too, and I don't see any problem. But then again, maybe he's looking for syntax highlighting or that kind of stuff which I don't use. But still. Oleg has a point -- IDE support and other such things need to be done by other people than the core developers, who need to focus on honing the language. I find it strange that every so often people clamor for IDE support, syntax highlighting, debugger support, etc., yet nobody seems to be willing to contribute actual code. Don't like something about the current state of D development tools? Well then do something about it. The source code is there for a reason, and it's not just to make people feel all warm and fuzzy inside because now we can label ourselves "open source". T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney
Re: News and problems about foreach loops
Peter Alexander:
I'm not a fan of introducing new keywords or introducing
breaking changes in D code (even though I don't use Case3). I
think this might just be something we have to live with,
Using a custom property is maybe acceptable (this @copy doesn't
need to be a built-in, probably it's not too much hard to define
it with user-defined attributes):
void main() {
auto data = [0, 1, 2, 3];
foreach (@copy x; data)
x++;
}
But there are other solutions, like asking D tool (like D IDEs or
future D lints) to show a warning here.
Another solution is to require an already present keyword ("new"
means it's a copy, it's not related to heap allocations) for the
Case3:
void main() {
auto data = [0, 1, 2, 3];
foreach (new x; data)
x++;
}
Bye,
bearophile
Re: [OT] .NET is compiled to native code in Windows Phone 8
On Thu, Nov 01, 2012 at 06:11:17PM -0400, Nick Sabalausky wrote: > On Thu, 01 Nov 2012 08:43:10 +0100 > "Paulo Pinto" wrote: > > > On Wednesday, 31 October 2012 at 23:20:15 UTC, deadalnix wrote: [...] > > > This compiler in the cloud things seems really scary. All my > > > apps will not work anymore if microsoft decide so ? > > > > I really dislike this cloud trend. It seems that everyone wants > > to sell me software as a service somehow. > > > > From my lastest projects in the Fortune 500 world, I can tell > > everyone is jumping with both feets into cloud stuff. > > > > For the lovers of software freedom this is scary. In a world of > > software as service and patent trolls, having the source code > > available seems to no longer be enough. [...] Exactly, so what if you have the full source code if you have no control over the server and no control over your data? > I feel exactly the same way. (Hell, that's one of the reasons I never > liked web apps.) [...] > I think it's all happening because MBAs are in charge, and the one > thing they know and like best is buzzwords. And "cloud" is the > biggest buzzword right now. Yeah no kidding, talk about castles in the air. :-P > I really hate the word "cloud" anyway. All it is, is a stupid renaming > of the words "Internet", "hosted" and "distributed", and which one it > means is usually dependent on context. "Cloud" is my #1 least favorite > word right ahead of "tween" (except when used for animation) and using > "crazy" as an adverb. It's another one of those overhyped bandwagons of questionable lasting value, that people are jumping on left right and center just because it's a buzzword. Nevermind the privacy issues, scalability issues, software freedom issues, etc.. T -- The most powerful one-line C program: #include "/dev/tty" -- IOCCC
Re: D vs C++11
On Saturday, 3 November 2012 at 12:46:18 UTC, Erèbe wrote: To be fair though, asking "C++ vs D" on a D newsgroup is clearly going to be tilted more towards the D end ;) But yea, personally, I feel that C++11 is merely playing "catch up", and doing so on a broken leg. I didn't expect that much of response to my question, but it was my intent to see the point of view of the community even if I know it is biased. All of you name a lot of missing features in C++11, while I completely agree upon that makes D cool, don't you fear a turtle effect if D only focus on features ? I explain myself, C++ is a well supported language and come with a lot of tools which could help/improve your developpement. In the decision of taking D xor C++, developper could think "Hey I already know C++ and how to work with it (aka tools), let just stick with it and wait for the new C++11 features coming for free". In that situation, C++11's no effort (or little to learn new additions) seem more rewarding than learning D, so why try ? Is there a point in the D roadmap where we will see "Okay, D has enough features, let add some support to the language now" ? Because in my opinion D is for now just a language, a awesome one yes, but not yet a good environnement for developper. C(++) had man (K in vim) and gdb, pascal his own ide, dynamic languages have their interpreters, Java eclipse, what has D ? Nearly no support in vim (my editor of choice), a Plugin for eclipse wich force you to stick with an older version, a Visual studio plugin where you need to buy a liscence in order to have the IDE. The only viable choice for me is the plugin for monodevelop which is really great but no debugger (assert is enough for now). Support should not be a top priority for the D-core now that the language is well featured ? Something coherent with what already exist (dmd) ? http://forum.dlang.org/thread/khmerwhgumluolifx...@forum.dlang.org#post-khmerwhgumluolifxtix:40forum.dlang.org
Re: D vs C++11
Ye, that is exactly what I meant when said C++ has no real
context capture and thus no real delegates here.
On Saturday, 3 November 2012 at 15:04:25 UTC, Paulo Pinto wrote:
On Saturday, 3 November 2012 at 12:56:36 UTC, mist wrote:
http://codepad.org/s38L9tUr
Am I misunderstanding something regarding C++ here?
On Saturday, 3 November 2012 at 02:44:49 UTC, Mehrdad wrote:
On Saturday, 3 November 2012 at 02:27:21 UTC, mist wrote:
Regarding delegates - I think deal is that none of this C++
stuff can automatically capture local function context with
delegate, so there are no _real_ delegates.
I don't understand what you mean...
std::function make_adder(int a)
{
return [=](int b) { return a + b; };
}
You could use the following instead
auto f = [&](){ return x; };
but then you cannot return the lambda.
--
Paulo
Re: D vs C++11
On Saturday, 3 November 2012 at 12:56:36 UTC, mist wrote:
http://codepad.org/s38L9tUr
Am I misunderstanding something regarding C++ here?
On Saturday, 3 November 2012 at 02:44:49 UTC, Mehrdad wrote:
On Saturday, 3 November 2012 at 02:27:21 UTC, mist wrote:
Regarding delegates - I think deal is that none of this C++
stuff can automatically capture local function context with
delegate, so there are no _real_ delegates.
I don't understand what you mean...
std::function make_adder(int a)
{
return [=](int b) { return a + b; };
}
You could use the following instead
auto f = [&](){ return x; };
but then you cannot return the lambda.
--
Paulo
Re: News and problems about foreach loops
On 11/3/12, Andrej Mitrovic wrote:
> It should be something like "cannot modify const member x".
In fact the error is already read but the else statement is not taken
in Expression::checkModifiable:
if (var && var->storage_class & STCctorinit) // goes here
{
const char *p = var->isStatic() ? "static " : "";
error("can only initialize %sconst member %s inside %sconstructor",
p, var->toChars(), p);
}
else
{
OutBuffer buf;
MODtoBuffer(&buf, type->mod);
error("cannot modify %s expression %s", buf.toChars(), toChars());
}
Re: D vs C++11
On Saturday, 3 November 2012 at 12:46:18 UTC, Erèbe wrote: Nearly no support in vim (my editor of choice), a Plugin for eclipse wich force you to stick with an older version, a Visual studio plugin where you need to buy a liscence in order to have the IDE. The only viable choice for me is the plugin for monodevelop which is really great but no debugger (assert is enough for now). Hi Erèbe, you can use free Visual Studio Shell with VisualD.. http://www.microsoft.com/en-us/download/details.aspx?id=30670 Thanks, Oleg.
Re: News and problems about foreach loops
On 11/3/12, bearophile wrote:
> Now you can omit the type, this is very handy:
>
> struct Foo { int x; }
> void main() {
> auto data = [Foo(10), Foo(20), Foo(30)];
> foreach (const f; data) {}
> }
That's really cool that we have this now. But this error message needs
to improve:
foreach (const f; data)
{
f.x++;
}
test.d(9): Error: can only initialize const member x inside constructor
It should be something like "cannot modify const member x".
Re: News and problems about foreach loops
On Saturday, 3 November 2012 at 14:04:45 UTC, bearophile wrote: A third solution is use idioms, and do not change D. It means that on default the programmer puts always a "const" in foreach. This avoids most bugs caused by fake Case3, and you don't use it in the uncommon true Cases3. There are few more alternative ways to face this problem. Including doing nothing :-) I never use Case3, except accidentally. It's possibly the most common language-caused bug in my D code. That said, I'm not a fan of introducing new keywords or introducing breaking changes in D code (even though I don't use Case3). I think this might just be something we have to live with, although making use of "const" idiomatic may be a good step forward (unfortunately, it's more unnecessary typing, so it's unlikely to catch on).
Re: D vs C++11
On Sat, 03 Nov 2012 07:46:17 -0500, Erèbe wrote: To be fair though, asking "C++ vs D" on a D newsgroup is clearly going to be tilted more towards the D end ;) But yea, personally, I feel that C++11 is merely playing "catch up", and doing so on a broken leg. I didn't expect that much of response to my question, but it was my intent to see the point of view of the community even if I know it is biased. All of you name a lot of missing features in C++11, while I completely agree upon that makes D cool, don't you fear a turtle effect if D only focus on features ? I explain myself, C++ is a well supported language and come with a lot of tools which could help/improve your developpement. In the decision of taking D xor C++, developper could think "Hey I already know C++ and how to work with it (aka tools), let just stick with it and wait for the new C++11 features coming for free". In that situation, C++11's no effort (or little to learn new additions) seem more rewarding than learning D, so why try ? Is there a point in the D roadmap where we will see "Okay, D has enough features, let add some support to the language now" ? Because in my opinion D is for now just a language, a awesome one yes, but not yet a good environnement for developper. C(++) had man (K in vim) and gdb, pascal his own ide, dynamic languages have their interpreters, Java eclipse, what has D ? Nearly no support in vim (my editor of choice), a Plugin for eclipse wich force you to stick with an older version, a Visual studio plugin where you need to buy a liscence in order to have the IDE. The only viable choice for me is the plugin for monodevelop which is really great but no debugger (assert is enough for now). Support should not be a top priority for the D-core now that the language is well featured ? Something coherent with what already exist (dmd) ? Nearly no support in Vim? Are you joking? What does Vim not support for D that you want it to? -- Using Opera's revolutionary email client: http://www.opera.com/mail/
News and problems about foreach loops
(This post is not crystal clear because unfortunately now I don't
have a lot of time to make it better, but I think it's
acceptable.)
In DMD 2.061 there will be some interesting changes, one of them
regards the foreach loops. Foreach loops are everywhere in D
code, it's one of the most used D constructs, so this is an
important topic; and avoiding problems and corner cases, and
making it not bug-prone is quite important.
Hara, Walter and others have started to implement a change I have
suggested time ago (from Python loops):
import std.stdio;
void main() {
foreach (i; 0 .. 10)
i++; // line 4
auto array = [10, 20, 30, 40, 50];
foreach (i, item; array) {
writeln(item);
i++; // line 8
}
}
With warnings this now gives:
test.d(4): Warning: variable modified in foreach body requires
ref storage class
test.d(8): Warning: variable modified in foreach body requires
ref storage class
10
30
50
Anoter change is visible here, in past this code required:
struct Foo { int x; }
void main() {
auto data = [Foo(10), Foo(20), Foo(30)];
foreach (const Foo f; data) {}
}
Now you can omit the type, this is very handy:
struct Foo { int x; }
void main() {
auto data = [Foo(10), Foo(20), Foo(30)];
foreach (const f; data) {}
}
Unfortunately currently this compiles and runs, but there is
already a patch to forbid it:
https://github.com/D-Programming-Language/dmd/pull/1249
void main() {
foreach (const i; 0 .. 10)
i++;
}
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=6214
http://d.puremagic.com/issues/show_bug.cgi?id=4090
http://d.puremagic.com/issues/show_bug.cgi?id=6652
Given how foreach now works on integer ranges, there is one more
situation worth discussing. In D this is a recognized common
source of bugs:
struct F { int x; }
void main() {
auto fs = [F(10), F(20), F(30)];
foreach (f; fs)
f.x += 1;
assert(fs[0].x == 10);
}
I think there are 3 main use cases for foreach loops on
collections of structs:
Case1: The struct iterated on is constant or it's not modified in
the loop body:
import std.stdio;
struct F { int x; }
void main() {
auto data = [F(10), F(20), F(30)];
foreach (f; data)
writeln(f);
foreach (const f; data)
writeln(f);
foreach (const ref f; data)
writeln(f);
foreach (immutable f; data)
writeln(f);
immutable data2 = [F(10), F(20), F(30)];
foreach (immutable ref f; data2)
writeln(f);
}
Case2: you want to modify the structs of the array:
import std.stdio;
struct F { int x; }
void main() {
auto data = [F(10), F(20), F(30)];
foreach (ref f; data)
f.x++;
writeln(data);
}
Case3: you want to modify just the copy of the struct, but you
don't want to modify the structs inside the array:
import std.stdio, std.range;
void main() {
auto iotas = [iota(0,3), iota(3,7), iota(7,10)];
foreach (it; iotas) {
it.popFront();
it.popFront();
writeln(it);
}
writeln(iotas);
}
[Note: in foreach ranged loops you only have Case1 and Case2 (and
in practice Case2 is not common):
import std.stdio;
void main() {
foreach (const i; 0 .. 10)
writeln(i);
}
]
Currently in D Case1 requires nothing, but today it's also more
handy than before to mark the struct loop variable with const or
immutable or even "const ref", to make sure you will not change
it inside the loop.
Case2 requires ref. If you see "ref" (but not "const ref") you
know inside the loop the struct will probably be modified.
Currently Case3 is denoted as Case1, but in my code this is a
much less common case. It's easy to write by mistake the Case3
pattern when you want to write the Case2 pattern.
So if there is a warning that warns against code like (later the
warning will become an error, I think. It's a very small breaking
change):
import std.stdio;
void main() {
foreach (i; 0 .. 4)
i++;
}
then maybe the fake case3 too should become a warning and later
an error (this is another breaking change):
// Solution1:
void main() {
auto data = [0, 1, 2, 3];
foreach (x; data)
x++; // warning
}
So the compiler always require "const" or "ref" in the loops, so
you can't write true Case3 any more. You have to copy the struct
manually:
import std.stdio, std.range;
void main() {
auto iotas = [iota(0,3), iota(3,7), iota(7,10)];
foreach (it; iotas) {
auto it2 = it;
it2.popFront();
it2.popFront();
writeln(it2);
}
writeln(iotas);
}
What are the alternative solutions?
A second solution is to require some kind of tagging to tell the
D compiler that the programmer really wants the Case3:
// Solution2:
void main() {
auto data = [0, 1, 2, 3];
foreach (@mutable x; data)
x++;
foreach (/*mut*/ x; data)
x++;
}
A third solution is use idioms, and do not change D. It means
that o
Re: D vs C++11
Erèbe: Is there a point in the D roadmap where we will see "Okay, D has enough features, let add some support to the language now" ? Because in my opinion D is for now just a language, a awesome one yes, but not yet a good environnement for developper. You are missing some essential points. First of all features are not just "done": they have corner cases to be fixed, details to be improved, they need to be fully implemented, they need to become efficient, bugs need to be removed, new needs ask for new parts, there are new CPUs to support, new OSes, new vector extensions added to CPUs, and so on. So in the end the work for the core language developers never ends. Putting such developers at work on tools is not a good idea, because then no one does the essential work on the core language and they will often be newbies regarding tools. So it becomes a lose-lose situation. You can't stop the development of the core language to develop tools, it causes a disaster. Usually you have to build a language good enough that it attracts other people, that are willing to work on tools and external modules :-) Bye, bearophile
Re: D vs C++11
http://codepad.org/s38L9tUr
Am I misunderstanding something regarding C++ here?
On Saturday, 3 November 2012 at 02:44:49 UTC, Mehrdad wrote:
On Saturday, 3 November 2012 at 02:27:21 UTC, mist wrote:
Regarding delegates - I think deal is that none of this C++
stuff can automatically capture local function context with
delegate, so there are no _real_ delegates.
I don't understand what you mean...
std::function make_adder(int a)
{
return [=](int b) { return a + b; };
}
Re: D vs C++11
To be fair though, asking "C++ vs D" on a D newsgroup is clearly going to be tilted more towards the D end ;) But yea, personally, I feel that C++11 is merely playing "catch up", and doing so on a broken leg. I didn't expect that much of response to my question, but it was my intent to see the point of view of the community even if I know it is biased. All of you name a lot of missing features in C++11, while I completely agree upon that makes D cool, don't you fear a turtle effect if D only focus on features ? I explain myself, C++ is a well supported language and come with a lot of tools which could help/improve your developpement. In the decision of taking D xor C++, developper could think "Hey I already know C++ and how to work with it (aka tools), let just stick with it and wait for the new C++11 features coming for free". In that situation, C++11's no effort (or little to learn new additions) seem more rewarding than learning D, so why try ? Is there a point in the D roadmap where we will see "Okay, D has enough features, let add some support to the language now" ? Because in my opinion D is for now just a language, a awesome one yes, but not yet a good environnement for developper. C(++) had man (K in vim) and gdb, pascal his own ide, dynamic languages have their interpreters, Java eclipse, what has D ? Nearly no support in vim (my editor of choice), a Plugin for eclipse wich force you to stick with an older version, a Visual studio plugin where you need to buy a liscence in order to have the IDE. The only viable choice for me is the plugin for monodevelop which is really great but no debugger (assert is enough for now). Support should not be a top priority for the D-core now that the language is well featured ? Something coherent with what already exist (dmd) ?
Re: A little Py Vs C++
Simen Kjaeraas wrote: > On 2012-39-03 12:11, Jens Mueller wrote: > > > >> > >>I have a fork; some people are using it already. It still needs a lot of > >>work though; some compilers missing parts, platforms not supported. > >>That said, it's not an effort to address D's natural vector > >>syntax, the key > >>goal is to provide a hardware SIMD API that is as orthogonal as possible > >>and portable (with confidence it will run reasonably well). > >>I wonder if druntime could be enhanced to use the SIMD stuff > >>though in the > >>functions that perform the natural vector operations, might > >>offer some nice > >>little boosts. > > > >Cool. > >It'll be nice though if D's vector operations could be expressed on top > >of it. I mean a[] + b[] is so much easier to read. > > Perhaps I'm the confused one here, but as I understand it, that's the > whole point of the latter part of the paragraph - array operations are > implemented in druntime, and that implementation might benefit from using > SIMD instructions. Sorry. I'm the one being confused. You're right Simen. Jens
Re: D vs C++11
On Saturday, 3 November 2012 at 10:33:54 UTC, Nick Sabalausky wrote: On Sat, 03 Nov 2012 08:19:15 +0100 "Paulo Pinto" wrote: What I have learned in all my years of enterprise development is that all those features have zero value for business. Languages get adopted because of business value, not due to the coolness of their feature set, how boring it may sell. If we want to sell D to companies using C++ for years, slowly migrating to JVM, .NET worlds, or just updating their codebases to C++11, then we need to sell D's business value not feature lists. The problem with "business value" is that there's two types of it: First there's "reality" business value which *naturally* includes, among other things, how well it works for the people actually using it. But then there's also "MBA/PHB" business value which *doesn't* factor that in because...well I can't finish that sentence without delving into rather graphic profanity, anatomical references, and general offensiveness to an entire profession ;) Sadly I meant the MBA type of business value. :(
Re: A little Py Vs C++
On 2012-39-03 12:11, Jens Mueller wrote: I have a fork; some people are using it already. It still needs a lot of work though; some compilers missing parts, platforms not supported. That said, it's not an effort to address D's natural vector syntax, the key goal is to provide a hardware SIMD API that is as orthogonal as possible and portable (with confidence it will run reasonably well). I wonder if druntime could be enhanced to use the SIMD stuff though in the functions that perform the natural vector operations, might offer some nice little boosts. Cool. It'll be nice though if D's vector operations could be expressed on top of it. I mean a[] + b[] is so much easier to read. Perhaps I'm the confused one here, but as I understand it, that's the whole point of the latter part of the paragraph - array operations are implemented in druntime, and that implementation might benefit from using SIMD instructions. -- Simen
Re: D vs C++11
On 2012-11-02 23:47, Nick Sabalausky wrote: No proper modules. No properties. Slow compilation. No reference semantics for classes. No scope guards. Little default initialization. Goofy ptr and func-ptr declaration syntax. Goofy rules about what is/isn't virtual. Lots of undefined behavior. Forward declarations. I've read Scott Meyer's Effective C++. On one of the first few pages it says something: "C++ can be hard, but if you think of it as three separate languages it much easier. One for the imperative, C inherited part, one for the object oriented part and one for the template part". With that statement it's no turning back. It can never be a good language it can only become worse, no feature in the world can make up for that. -- /Jacob Carlborg
Re: A little Py Vs C++
Manu wrote: > On 3 November 2012 01:41, Walter Bright wrote: > > > On 11/2/2012 3:10 PM, Jens Mueller wrote: > > > >> I see. Thanks for clarifying. > >> If I want fast vector operations I have to use core.simd. The built-in > >> vector operations won't fit the bill. > >> > > > I think a better quote would be "If i want *HARDWARE* vector > operations..."; this is not automatically faster by nature, it requires > strict self-control in terms of application, and very careful attention if > you want your code to be portable. > > At the moment, yes. > > > > However, Manu is working on developing a higher order layer. > > > > I have a fork; some people are using it already. It still needs a lot of > work though; some compilers missing parts, platforms not supported. > That said, it's not an effort to address D's natural vector syntax, the key > goal is to provide a hardware SIMD API that is as orthogonal as possible > and portable (with confidence it will run reasonably well). > I wonder if druntime could be enhanced to use the SIMD stuff though in the > functions that perform the natural vector operations, might offer some nice > little boosts. Cool. It'll be nice though if D's vector operations could be expressed on top of it. I mean a[] + b[] is so much easier to read. Jens
Re: D vs C++11
On 2012-11-02 22:53, Walter Bright wrote: No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this. Why do you think I'm here, using D instead :) -- /Jacob Carlborg
Re: Simple implementation of __FUNCTION
On 2012-11-02 23:33, Rob T wrote:
That looks better. Not sure what the down side would be if any.
Unrelated to either form, I discovered it fails to compile when inside a
function with "auto" as the return type.
auto test()
{
throw new Exception( mixin(__FUNCTION) );
return 0;
}
Error: forward reference to test
but this works
int test()
{
throw new Exception( mixin(__FUNCTION) );
return 0;
}
So we're kinda sunk for inclusion in phobos unless this error can be
resolved.
I think it would be worth to but in Phobos anyway.
--
/Jacob Carlborg
Re: A little Py Vs C++
On 3 November 2012 01:41, Walter Bright wrote: > On 11/2/2012 3:10 PM, Jens Mueller wrote: > >> I see. Thanks for clarifying. >> If I want fast vector operations I have to use core.simd. The built-in >> vector operations won't fit the bill. >> > I think a better quote would be "If i want *HARDWARE* vector operations..."; this is not automatically faster by nature, it requires strict self-control in terms of application, and very careful attention if you want your code to be portable. At the moment, yes. > > However, Manu is working on developing a higher order layer. > I have a fork; some people are using it already. It still needs a lot of work though; some compilers missing parts, platforms not supported. That said, it's not an effort to address D's natural vector syntax, the key goal is to provide a hardware SIMD API that is as orthogonal as possible and portable (with confidence it will run reasonably well). I wonder if druntime could be enhanced to use the SIMD stuff though in the functions that perform the natural vector operations, might offer some nice little boosts.
Re: D vs C++11
On Sat, 03 Nov 2012 08:19:15 +0100 "Paulo Pinto" wrote: > > What I have learned in all my years of enterprise development is > that all those features have zero value for business. > > Languages get adopted because of business value, not due to the > coolness of their feature set, how boring it may sell. > > If we want to sell D to companies using C++ for years, slowly > migrating to JVM, .NET worlds, or just updating their codebases > to C++11, then we need to sell D's business value not feature > lists. > The problem with "business value" is that there's two types of it: First there's "reality" business value which *naturally* includes, among other things, how well it works for the people actually using it. But then there's also "MBA/PHB" business value which *doesn't* factor that in because...well I can't finish that sentence without delving into rather graphic profanity, anatomical references, and general offensiveness to an entire profession ;)
Re: D vs C++11
On Saturday, 3 November 2012 at 07:35:26 UTC, Brad Roberts wrote: On 11/3/2012 12:19 AM, Paulo Pinto wrote: On Friday, 2 November 2012 at 23:08:00 UTC, Timon Gehr wrote: What I have learned in all my years of enterprise development is that all those features have zero value for business. Languages get adopted because of business value, not due to the coolness of their feature set, how boring it may sell. If we want to sell D to companies using C++ for years, slowly migrating to JVM, .NET worlds, or just updating their codebases to C++11, then we need to sell D's business value not feature lists. -- Paulo In my experience (which admittedly is limited to several companies that are all technology companies, which introduces an specific bias) it's the engineers which ultimately define the languages used. Eventually after enough people want to use , it gets used. It has little to do with business value or rational logic and more to do with determination and momentum. Of course each of us works in very different eco-systems. In my case it is enterprise world of Fortune 500 companies, new technologies only get introduced in two forms: - customer requires technology X (e.g. Objective-C for iApps, EC2 for deployments, ...) - company can earn big money if it sells consulting support with technology X -- Paulo
Re: D vs C++11
On 11/3/2012 12:19 AM, Paulo Pinto wrote: > On Friday, 2 November 2012 at 23:08:00 UTC, Timon Gehr wrote: > > What I have learned in all my years of enterprise development is that all > those features have zero value for business. > > Languages get adopted because of business value, not due to the coolness of > their feature set, how boring it may sell. > > If we want to sell D to companies using C++ for years, slowly migrating to > JVM, .NET worlds, or just updating their > codebases to C++11, then we need to sell D's business value not feature lists. > > -- > Paulo In my experience (which admittedly is limited to several companies that are all technology companies, which introduces an specific bias) it's the engineers which ultimately define the languages used. Eventually after enough people want to use , it gets used. It has little to do with business value or rational logic and more to do with determination and momentum.
Re: D vs C++11
On Friday, 2 November 2012 at 23:08:00 UTC, Timon Gehr wrote: On 11/02/2012 10:53 PM, Walter Bright wrote: On 11/2/2012 2:33 PM, Jacob Carlborg wrote: I said the gap is getting thinner, not that is gone. It got foreach, some form of CTFE, static assert, lambda to mention a few new features. No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this. No static if. Limited forward references. No real function local aggregate types. No real nested classes. No local template instantiation. No nested functions. No value range propagation for implicit conversions. No built-in string support. No built-in unicode support. No template guards. No inout. No default-initialization. No return type deduction for non-lambdas. No generic lambdas. No type deduction for lambda parameter types. No super. Less powerful typeof that is called decltype. No is-expressions. No compile-time reflection. No thread-local by default. No UFCS. No tuple/sequence types. No sequence auto-expansion. No sane built-in array types. No tuple slicing. No .init/.min/.max/etc. No kind of static foreach. No new scopes introduced in case statements. No block statements in a for-loop initializer. No optional parentheses on function calls. No implicit reference types. No ^^ operator. No binary ! operator. No built-in complex number types. Less comparison operators. None of eg. bearophile's enhancement requests. ... in no particular order, afaik, and to name a few. :o) What I have learned in all my years of enterprise development is that all those features have zero value for business. Languages get adopted because of business value, not due to the coolness of their feature set, how boring it may sell. If we want to sell D to companies using C++ for years, slowly migrating to JVM, .NET worlds, or just updating their codebases to C++11, then we need to sell D's business value not feature lists. -- Paulo
Re: [OT] .NET is compiled to native code in Windows Phone 8
On Thursday, 1 November 2012 at 22:15:49 UTC, Nick Sabalausky wrote: On Thu, 1 Nov 2012 18:11:17 -0400 Nick Sabalausky wrote: On Thu, 01 Nov 2012 08:43:10 +0100 "Paulo Pinto" wrote: > On Wednesday, 31 October 2012 at 23:20:15 UTC, deadalnix > wrote: > > Le 30/10/2012 20:15, Paulo Pinto a écrit : > >> Now Build 2012 is happening and the new Windows Phone 8 > >> features have > >> been revealed. > >> > >> One of the most interesting is that .NET applications are > >> actually > >> compiled to native code as well, before being made > >> available for download. > >> > >> http://blogs.msdn.com/b/dotnet/archive/2012/10/30/announcing-the-release-of-the-net-framework-for-windows-phone-8.aspx > >> > >> > >> Assuming Microsoft eventually releases a native code > >> compiler for C# > >> (better than NGEN), this will make D use harder in the > >> enterprise. :\ > >> > >> -- > >> Paulo > > > > This compiler in the cloud things seems really scary. All > > my apps will not work anymore if microsoft decide so ? > > I really dislike this cloud trend. It seems that everyone > wants to sell me software as a service somehow. > > From my lastest projects in the Fortune 500 world, I can > tell everyone is jumping with both feets into cloud stuff. > > For the lovers of software freedom this is scary. In a world > of software as service and patent trolls, having the source > code available seems to no longer be enough. > I feel exactly the same way. (Hell, that's one of the reasons I never liked web apps.) A few months ago, I was looking into cross-platform 2D mobile game frameworks and it came down to Corona vs Marmalade. One of the big reasons we went with Marmalade was because Corona was 100% compiled on *their* servers, which lead to various uncomfortable consequences. I think it's all happening because MBAs are in charge, and the one thing they know and like best is buzzwords. And "cloud" is the biggest buzzword right now. I really hate the word "cloud" anyway. All it is, is a stupid renaming of the words "Internet", "hosted" and "distributed", and which one it means is usually dependent on context. "Cloud" is my #1 least favorite word right ahead of "tween" (except when used for animation) and using "crazy" as an adverb. Speaking of all this: http://dilbert.com/2012-10-21/ That summarizes it perfectly. Great! :)
