Re: Do everything in Java?
On Friday, 5 December 2014 at 07:33:21 UTC, Shammah Chancellor wrote: On 2014-12-04 14:12:32 +, Ola Fosheim Grøstad said: I did not find that odd, they are not perceived as stable and proven. Go is still working on finding the right GC solution. There are quite a few companies using Go in production. Yes, but I will not consider Go ready for production until they are out of Beta on Google App Engine. Google has to demonstrate that they believe in the capability of their own language ;-). https://cloud.google.com/appengine/docs/go/
D Meetup in SF?
I didn't notice a D meetup group in SF. Is anyone else in here interested in doing something like this once a month? -S.
Re: Do everything in Java…
Well, his choice may make sense, but I see no connection between pet projects and proprietary paid work. They can't share code.
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Let me know if you are interested in taking part in this or any future Berlin based events. I would be interested too.
Re: Do everything in Java…
On Fri, 05 Dec 2014 08:22:03 + Kagamin via Digitalmars-d digitalmars-d@puremagic.com wrote: Well, his choice may make sense, but I see no connection between pet projects and proprietary paid work. They can't share code. hm. but they can. my proprietary paid projects sharing alot of code with my hobby projects. it's like i'm writing some libraries for my own use and then including parts of that in my paid work, 'cause it's much easier to simply use tested and familiar library than to write brand new one. signature.asc Description: PGP signature
Re: Do everything in Java…
On Friday, 5 December 2014 at 08:34:18 UTC, ketmar via Digitalmars-d wrote: 'cause it's much easier to simply use tested and familiar library than to write brand new one. Why not? There are always things to improve.
Re: Do everything in Java…
On Fri, 05 Dec 2014 08:41:57 + Kagamin via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 5 December 2014 at 08:34:18 UTC, ketmar via Digitalmars-d wrote: 'cause it's much easier to simply use tested and familiar library than to write brand new one. Why not? There are always things to improve. my customers paying me for making the work done, not for experimenting and researching. that's why i'm doing researches in my hobby projects, and then just using the resulting code in my paid projects. well-tested (heh, i don't want my projects go mad from bugs, so fixing 'em is a must here ;-) and mature code. this way everyone is happy, and i'm not blocked in trying another approach or breaking some API. if i wrote code especially for payed project, i can't use that code anywhere else: my customers payed for it, so they own it. i don't want to go into legal things with them, it's too boring. but it's generally ok for customers if we'll saying that we will use some of our internal libraries to deliver a product faster. they don't claiming ownership on those libraries and everyone is happy. signature.asc Description: PGP signature
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Let me know if you are interested in taking part in this or any future Berlin based events. Thanks, Ben. Another Sociomantic developer checking in. Great that this is happening. I'll be there...
Re: D Meetup in SF?
On 12/05/2014 12:15 AM, Shammah Chancellor wrote: I didn't notice a D meetup group in SF. Is anyone else in here interested in doing something like this once a month? -S. I am interested but Tuesdays are not good for me. Do you mean San Francisco proper, or more South? Andrei wanted to start Friday D breakfasts at Facebook but that attempt dwindled after a couple of sessions. Ali
Re: Do everything in Java…
On Friday, 5 December 2014 at 02:47:51 UTC, ketmar via Digitalmars-d wrote: yes, i know about doxygen, unittesting frameworks and so on. somehow they never works for me. ah, those tools are second class citizens, i'll do 'em favor later. of course, that later means never most of the time. ;-) In this case I just return task to the developer with a requirement to write a test. D builtin unittests are not suited for complex integration tests, because they are all or nothing and tests easily become brittle, we never have all green builds.
Re: D Meetup in Berlin
Another Sociomantic developer here, and I'm in! Mozilla is also starting organizing weekly hacking sessions for Rust in Berlin, so keep in mind that it doesn't need to be organized as a Dconf, just people hanging, discussing and coding is enough for me to be there! On Friday, 5 December 2014 at 08:25:07 UTC, Mathias LANG wrote: On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Let me know if you are interested in taking part in this or any future Berlin based events. I would be interested too.
Re: Do everything in Java…
On Fri, 05 Dec 2014 08:56:42 + Kagamin via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 5 December 2014 at 02:47:51 UTC, ketmar via Digitalmars-d wrote: yes, i know about doxygen, unittesting frameworks and so on. somehow they never works for me. ah, those tools are second class citizens, i'll do 'em favor later. of course, that later means never most of the time. ;-) In this case I just return task to the developer with a requirement to write a test. D builtin unittests are not suited for complex integration tests, because they are all or nothing and tests easily become brittle, we never have all green builds. that may work for big team projects. but i'm speaking of hobby/tiny team projects here. sure i can return task to myself, but this will not help. ;-) signature.asc Description: PGP signature
Re: Do everything in Java…
On Friday, 5 December 2014 at 08:56:03 UTC, ketmar via Digitalmars-d wrote: my customers paying me for making the work done, not for experimenting and researching. They pay you to make the work from scratch and they don't care how you do it. must here ;-) and mature code. this way everyone is happy, and i'm not blocked in trying another approach or breaking some API. If you do it from scratch, there's no breakage. What's the reason to not do it? It looks as if you hate writing better code in your language of choice. You hate that language?
Re: D Meetup in Berlin
I would like to join. The problem is, that I'm working in Munich (at Funkwerk). But almost every Friday I will be in Berlin. So, it would be great if such a Meetup could be on a Friday.
Re: Review needed for the wiki - Pascal to D page
Baz: I was already thinking to add one because the foreach(i; 0 .. 8) Better to write: foreach(immutable i; 0 .. 8) Bye, bearophile
Re: Do everything in Java…
On Fri, 05 Dec 2014 09:07:23 + Kagamin via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 5 December 2014 at 08:56:03 UTC, ketmar via Digitalmars-d wrote: my customers paying me for making the work done, not for experimenting and researching. They pay you to make the work from scratch and they don't care how you do it. in no way. thay paying me to build the software that solving their problems. if they can pay less and get the software faster, they are happy. and then they going to me when they need another software, 'cause they know that i'm not interested in only taking their money and deliver something that barely works, and beyond the deadline. must here ;-) and mature code. this way everyone is happy, and i'm not blocked in trying another approach or breaking some API. If you do it from scratch, there's no breakage. What's the reason to not do it? It looks as if you hate writing better code in your language of choice. You hate that language? i hate rewriting the code which is already written and working. that's why i'm not starting new project with writing new compiler for it, for example. and that's why i like to reuse what i did in another projects -- to deliver a good solution in reasonable time and budget. it may be fun for me to rewrite everything again and again, but my customers aren't interested in giving me fun, they want their problems solved. signature.asc Description: PGP signature
Re: Do everything in Java?
On Friday, 5 December 2014 at 07:33:21 UTC, Shammah Chancellor wrote: On 2014-12-04 14:12:32 +, Ola Fosheim Grøstad said: I did not find that odd, they are not perceived as stable and proven. Go is still working on finding the right GC solution. There are quite a few companies using Go in production. -S. Yes there are, but for me using Go in production means it is listed as the required language in a Request For Proposal document. -- Paulo
Re: Do everything in Java…
On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote: On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote: http://www.teamten.com/lawrence/writings/java-for-everything.html i didn't read the article, but i bet that this is just another article about his language of preference and how any other language he tried doesn't have X or Y or Z. and those X, Y and Z are something like not being on market for long enough, vendor ACME didn't ported ACMElib to it, out staff is trained in G but not in M and so on. boring. From the article: Most importantly, the kinds of bugs that people introduce most often aren’t the kind of bugs that unit tests catch. With few exceptions (such as parsers), unit tests are a waste of time. Not my experience with unittests, repeated over decades and with different languages. Unit tests are a huge win, even with statically typed languages. Yes, but they cannot test everything. GUI code is specially ugly as it requires UI automation tooling. They do exist, but only enterprise customers are willing to pay for it. This is why WPF has UI automation built-in. The biggest problem with unit tests are managers that want to see shiny reports, like those produced by tools like Sonar. Teams than spend ridiculous amount of time writing superfluous unit tests just to match milestone targets. Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. -- Paulo
Re: D Meetup in Berlin
I will attend if it happens between 24.01 and 29.01
Re: Need help deciphering posix.mak
On Thursday, 4 December 2014 at 23:19:21 UTC, Daniel Murphy wrote: Dmitry Olshansky wrote in message news:m5qe1c$218a$1...@digitalmars.com... 04-Dec-2014 18:32, Dicebot пишет: Please no additional 3d-party dependencies for D core tool stack. What are current 3rd-party deps? Dependency on DMC make and compiler is already there, GNU make is not installed by default on FreeBSD. What would you suggest we do? Write a build script in D? That or just clean up the existing makefiles (getting rid of DMC make and using GNU make on all platforms would be ideal). Or just doing nothing - while existing build system is quite a mess, the problem is not critical enough to extend the infrastructure.
Re: On heap segregation, GC optimization and @nogc relaxing
On Thursday, 4 December 2014 at 23:22:04 UTC, deadalnix wrote: I don't think this is solving the same problem as Marc's proposal so I'm not sure how comparing them make sense. Marc's proposal is about manipulating data without having ownership. This defines ownership. Indeed. But both combined add too much complexity to be feasible and thus we need to decide what problems are more important to solve. I think one from Marc has wider application while elements of yours can be more suitable as hidden implementation detail. Though now there is also DIP69 and I need to seriously shake them all through my head before having any true opinion :P This proposal add some complexity, but I do think this is a winner. Right now we have various type qualifier (mutable, const, immutable, shared, const shared, inout, inout shared). This come at a cost, and, ultimately, as the proposal interact with this, you want to compare the total complexity with the total benefit. I respectfully can't agree that shared qualifier truly exists in current language implementation. Thus perspective is a bit different. Also const/inout don't actually tell anything about how underlying data is managed and serve as secondary utility qualifiers.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 14:32:27 UTC, Daniel Murphy wrote: FWIW I don't really like this - it feels like a hack. I'd rather just declare a private logger alias (or something like that) and use that in the library. Decision can be made at compile time, doesn't require reverse module imports, doesn't depend on global versions. eg alias libraryLogger = std.logger.FilteredLogger!(LogLevel.info); I agree with Daniel here. It feels like seeking for too much magic just because it is cool - while more simple and straightforward approach can do the job as well.
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Hi All, I am a Berlin based D developer who has been working with D for about 2 and a half years. Like other more well known names in these forums I work for a company called Sociomantic. I am interested in organizing some meetups for D programmers in the nearby area. The first of these will be very informal and involve a social meeting at a cafe or bar to chat and gauge any interest in future events and in what direction people think these should head. I was thinking of arranging this for mid January next year but am very flexible on the dates. Let me know if you are interested in taking part in this or any future Berlin based events. Thanks, Ben. Sounds great! I will attend as well :)
Re: Need help deciphering posix.mak
Dicebot wrote in message news:kgogertqxpmczhoqr...@forum.dlang.org... That or just clean up the existing makefiles (getting rid of DMC make and using GNU make on all platforms would be ideal). Or just doing nothing - while existing build system is quite a mess, the problem is not critical enough to extend the infrastructure. As much as I dislike digital mars make, requiring GNU make on windows would be worse. One of these days I'm going to rewrite the dmd test suite to not require make at all, but I'm going to have to figure out how it works first.
Re: Need help deciphering posix.mak
On Friday, 5 December 2014 at 10:48:15 UTC, Daniel Murphy wrote: As much as I dislike digital mars make, requiring GNU make on windows would be worse. One of these days I'm going to rewrite the dmd test suite to not require make at all, but I'm going to have to figure out how it works first. How is it really different? Both require external tool, both are available via prebuilt windows binary. At least you can build GNU one yourself.
Re: D Meetup in Berlin
Awesome to see so much interest in the meetup! Looking at when people can make it lets set the date for the first meetup as Friday 23rd of January. I will announce the venue and time closer to the date. Already looking forward to it.
Re: Need help deciphering posix.mak
On Friday, 5 December 2014 at 10:48:15 UTC, Daniel Murphy wrote: Dicebot wrote in message news:kgogertqxpmczhoqr...@forum.dlang.org... That or just clean up the existing makefiles (getting rid of DMC make and using GNU make on all platforms would be ideal). Or just doing nothing - while existing build system is quite a mess, the problem is not critical enough to extend the infrastructure. As much as I dislike digital mars make, requiring GNU make on windows would be worse. One of these days I'm going to rewrite the dmd test suite to not require make at all, but I'm going to have to figure out how it works first. I think I'd much rather GNU make. No offence, but there's no chance your little tool will ever get the same test coverage or real-world use testing of GNU make on Windows. This is why I prefer CMake like tools over dub. Plus make -jX is *much* faster than dub build (and SCons for that matter). /uri
Re: Do everything in Java…
On Friday, 5 December 2014 at 09:27:16 UTC, Paulo Pinto wrote: On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote: On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote: http://www.teamten.com/lawrence/writings/java-for-everything.html i didn't read the article, but i bet that this is just another article about his language of preference and how any other language he tried doesn't have X or Y or Z. and those X, Y and Z are something like not being on market for long enough, vendor ACME didn't ported ACMElib to it, out staff is trained in G but not in M and so on. boring. From the article: Most importantly, the kinds of bugs that people introduce most often aren’t the kind of bugs that unit tests catch. With few exceptions (such as parsers), unit tests are a waste of time. Not my experience with unittests, repeated over decades and with different languages. Unit tests are a huge win, even with statically typed languages. Yes, but they cannot test everything. GUI code is specially ugly as it requires UI automation tooling. They do exist, but only enterprise customers are willing to pay for it. This is why WPF has UI automation built-in. The biggest problem with unit tests are managers that want to see shiny reports, like those produced by tools like Sonar. Teams than spend ridiculous amount of time writing superfluous unit tests just to match milestone targets. Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. -- Paulo Now is the right time to confess. I hardly ever use unit tests although it's included (and encouraged) in D. Why? When I write new code I unit test as I go along, with debug writefln(result %s, result); and stuff like this. Stupid? Unprofessional? I don't know. It works. I once started to write unit tests only to find out that indeed they don't catch bugs, because you only put into unit tests what you know (or expect) at a given moment (just like the old writefln()). The bugs I, or other people, discover later would usually not be caught by unit tests simply because you write for your own expectations at a given moment and don't realize that there are millions of other ways to go astray. So the bugs are usually due to a lack of imagination or a tunnel vision at the moment of writing code. This will be reflected in the unit tests as well. So why bother? You merely enshrine your own restricted and circular logic in tests. Which reminds me of maths when teachers would tell us And see, it makes perfect sense!, yeah, because they laid down the rules themselves in the first place. The same goes for comparing your output to some gold standard. The program claims to have an accuracy of 98%. Sure, because you wrote for the gold standard and not for the real world where it drastically drops to 70%. The good thing about unit tests is that they tell you when you break existing code. But you'll realize that soon enough anyway.
Re: Do everything in Java…
On Fri, 05 Dec 2014 11:53:10 + Chris via Digitalmars-d digitalmars-d@puremagic.com wrote: Now is the right time to confess. I hardly ever use unit tests although it's included (and encouraged) in D. Why? When I write new code I unit test as I go along, with debug writefln(result %s, result); ah, that debug code is so annoying. besides, it requires importing std.stdio, which is not always desirable. and... and... and... you can move it to unittest section and then just run it with rdmd! hee-hoo, now you got best from the both worlds: you can check that your code is working and you have unittests! just don't tell anyone that your carefully crafted unittests are simple debug statements moved to another place. i'm doing that all the time and never been caught. signature.asc Description: PGP signature
Re: Do everything in Java…
The good thing about unit tests is that they tell you when you break existing code. That's the great thing about unittests, and the reason why I write unittests. I work on a fairly complex code base and every now and then there's a new feature requested. Implementing features involves several to dozen of modules to be changed, and there's no way that I could guarantee that feature implementation didn't change behaviour of the existing code. I both hate and love when I `make` compiles and unittest fails. But you'll realize that soon enough anyway. This is not good enough for me. Sometimes soon enough means week or two before somebody actually notice the bug in the implementation (again, very complex project that's simply not hand-testable), and that's definitively not soon enough keeping in mind amount of $$$ that you wasted into air. On Friday, 5 December 2014 at 11:53:11 UTC, Chris wrote: On Friday, 5 December 2014 at 09:27:16 UTC, Paulo Pinto wrote: On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote: On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote: http://www.teamten.com/lawrence/writings/java-for-everything.html i didn't read the article, but i bet that this is just another article about his language of preference and how any other language he tried doesn't have X or Y or Z. and those X, Y and Z are something like not being on market for long enough, vendor ACME didn't ported ACMElib to it, out staff is trained in G but not in M and so on. boring. From the article: Most importantly, the kinds of bugs that people introduce most often aren’t the kind of bugs that unit tests catch. With few exceptions (such as parsers), unit tests are a waste of time. Not my experience with unittests, repeated over decades and with different languages. Unit tests are a huge win, even with statically typed languages. Yes, but they cannot test everything. GUI code is specially ugly as it requires UI automation tooling. They do exist, but only enterprise customers are willing to pay for it. This is why WPF has UI automation built-in. The biggest problem with unit tests are managers that want to see shiny reports, like those produced by tools like Sonar. Teams than spend ridiculous amount of time writing superfluous unit tests just to match milestone targets. Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. -- Paulo Now is the right time to confess. I hardly ever use unit tests although it's included (and encouraged) in D. Why? When I write new code I unit test as I go along, with debug writefln(result %s, result); and stuff like this. Stupid? Unprofessional? I don't know. It works. I once started to write unit tests only to find out that indeed they don't catch bugs, because you only put into unit tests what you know (or expect) at a given moment (just like the old writefln()). The bugs I, or other people, discover later would usually not be caught by unit tests simply because you write for your own expectations at a given moment and don't realize that there are millions of other ways to go astray. So the bugs are usually due to a lack of imagination or a tunnel vision at the moment of writing code. This will be reflected in the unit tests as well. So why bother? You merely enshrine your own restricted and circular logic in tests. Which reminds me of maths when teachers would tell us And see, it makes perfect sense!, yeah, because they laid down the rules themselves in the first place. The same goes for comparing your output to some gold standard. The program claims to have an accuracy of 98%. Sure, because you wrote for the gold standard and not for the real world where it drastically drops to 70%. The good thing about unit tests is that they tell you when you break existing code. But you'll realize that soon enough anyway.
Re: D Meetup in Berlin
On Friday, 5 December 2014 at 11:35:29 UTC, Ben wrote: Awesome to see so much interest in the meetup! Looking at when people can make it lets set the date for the first meetup as Friday 23rd of January. I will announce the venue and time closer to the date. Already looking forward to it. I'm from Poland and interested also :)
Re: Symbol lookup rules and imports
On 02/12/2014 22:00, H. S. Teoh via Digitalmars-d wrote:
Recently, in a bid to reduce the messy tangle that is the web of
interdependencies among Phobos modules, many module-scope imports have
been replaced with scoped imports. In addition to reducing gratuitous
dependencies (the scoped import is not processed in a template body
until the template is actually needed, so if user code doesn't need that
template, then it won't pull in a whole bunch of unnecessary Phobos
modules), scoped imports also make the code easier to refactor -- you
can move things around more easily without breaking it.
However, there are major issues with scoped imports currently,
that make this otherwise ideal solution less-than-ideal, which stem from
the way 'import' is implemented in D. When the compiler encounters an
'import' statement, what it essentially does is to parse the symbols in
the target module, and add them to the symbol table for the current
scope. While this is a simple, straightforward implementation method, it
leads to the following problems:
1) Consider this code:
// Quiz for the reader: what does this code do?
void myFunc(string text, string number) {
import std.conv;
import std.stdio;
auto x = to!int(number);
writeln(text, x);
}
void main() {
myFunc(The count is: , 123);
}
Here's the output:
123
The reason is that `import std.conv;` pulls in *all* the symbols from
std.conv into the local scope, including the function called text.
This causes text (i.e., std.conv.text) to shadow the parameter text,
so `writeln(text, x);` is interpreted as:
std.stdio.writeln(std.conv.text(), x);
so the parameter text is never used. This is just a simple example;
the problem becomes much harder to trace when the shadowed symbol is not
this close to the import scope:
struct S {
string text;
...
void method() {
import std.conv;
...
writeln(text); // uses std.conv.text, not this.text
}
}
Worse yet, suppose we have this code, that today works correctly:
struct S {
string buf;
void format() {
buf = ... /* format S's data into string form */
}
void method() {
import std.file;
... // do some processing based on files
format(); // calls this.format()
}
}
Now, suppose at some point in the future, we introduce a function also
called format() in std.file, that formats your hard drive. The user code
is unchanged. What happens when you recompile the program and run it? It
will compile successfully... and then format your hard drive without any
warning.
This is the crux of the issue behind:
https://issues.dlang.org/show_bug.cgi?id=10378
2) OK, so the conclusion is that unqualified scoped imports are
dangerous, right? Alright, let's see what happens when we use qualified
imports:
// mod.d
module mod;
struct S {
// Use a fully-qualified import.
// We place it in the body of S because S's methods
// repeatedly needs it -- after all, DRY is good, right?
import std.format : format;
void method1(string fmt) {
writeln(format(fmt, ... ));
}
void method2() {
auto s = format(abc %s def, ...);
...
}
}
// main.d
module main;
import mod; // we need the definition of S
void format(S s) {
... /* do something with s */
}
void main() {
S s;
s.format(); // UFCS -- should call main.format(s), right?
}
Wrong. That last line in main() actually calls std.format.format. Why?
Because in mod.d, the `import std.format : format` declaration actually
pulls in std.format.format into the symbol table of S, therefore,
S.format now refers to std.format.format. This, therefore, hijacks the
intended call to main.format.
This is: https://issues.dlang.org/show_bug.cgi?id=13808
3) OK, so putting scoped, qualified imports in struct bodies is a bad
idea, they should always go into the method bodies, then we'll be OK,
right? Sure... until you need to do this:
// A
struct S {
// B
void method(R)(R range)
if (isInputRange!R)
{
// C
}
}
This will not compile unless you import std.range : isInputRange
somewhere. Putting it in the line marked //A introduces a module-global
dependency on std.range,
Re: LogLevel [was std.experimental.logger formal review round 3]
On Friday, 5 December 2014 at 10:30:08 UTC, Dicebot wrote: On Thursday, 4 December 2014 at 14:32:27 UTC, Daniel Murphy wrote: FWIW I don't really like this - it feels like a hack. I'd rather just declare a private logger alias (or something like that) and use that in the library. Decision can be made at compile time, doesn't require reverse module imports, doesn't depend on global versions. eg alias libraryLogger = std.logger.FilteredLogger!(LogLevel.info); I agree with Daniel here. It feels like seeking for too much magic just because it is cool - while more simple and straightforward approach can do the job as well. Yes simpler is better, if it works. As discussed twice already, an approach like: alias libraryLogger = std.logger.FilteredLogger!(LogLevel.info); will not work. Currently I think the best solution is Martin's idea with my mod. The complexity of the task to accomplish does not simple go away. Unless you cut features which we can't do to keep the generality of the library. And that is the main goal after all.
Re: Do everything in Java…
On Friday, 5 December 2014 at 12:06:55 UTC, Nemanja Boric wrote: The good thing about unit tests is that they tell you when you break existing code. That's the great thing about unittests, and the reason why I write unittests. I work on a fairly complex code base and every now and then there's a new feature requested. Implementing features involves several to dozen of modules to be changed, and there's no way that I could guarantee that feature implementation didn't change behaviour of the existing code. I both hate and love when I `make` compiles and unittest fails. But you'll realize that soon enough anyway. This is not good enough for me. Sometimes soon enough means week or two before somebody actually notice the bug in the implementation (again, very complex project that's simply not hand-testable), and that's definitively not soon enough keeping in mind amount of $$$ that you wasted into air. On Friday, 5 December 2014 at 11:53:11 UTC, Chris wrote: On Friday, 5 December 2014 at 09:27:16 UTC, Paulo Pinto wrote: On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote: On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote: http://www.teamten.com/lawrence/writings/java-for-everything.html i didn't read the article, but i bet that this is just another article about his language of preference and how any other language he tried doesn't have X or Y or Z. and those X, Y and Z are something like not being on market for long enough, vendor ACME didn't ported ACMElib to it, out staff is trained in G but not in M and so on. boring. From the article: Most importantly, the kinds of bugs that people introduce most often aren’t the kind of bugs that unit tests catch. With few exceptions (such as parsers), unit tests are a waste of time. Not my experience with unittests, repeated over decades and with different languages. Unit tests are a huge win, even with statically typed languages. Yes, but they cannot test everything. GUI code is specially ugly as it requires UI automation tooling. They do exist, but only enterprise customers are willing to pay for it. This is why WPF has UI automation built-in. The biggest problem with unit tests are managers that want to see shiny reports, like those produced by tools like Sonar. Teams than spend ridiculous amount of time writing superfluous unit tests just to match milestone targets. Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. -- Paulo Now is the right time to confess. I hardly ever use unit tests although it's included (and encouraged) in D. Why? When I write new code I unit test as I go along, with debug writefln(result %s, result); and stuff like this. Stupid? Unprofessional? I don't know. It works. I once started to write unit tests only to find out that indeed they don't catch bugs, because you only put into unit tests what you know (or expect) at a given moment (just like the old writefln()). The bugs I, or other people, discover later would usually not be caught by unit tests simply because you write for your own expectations at a given moment and don't realize that there are millions of other ways to go astray. So the bugs are usually due to a lack of imagination or a tunnel vision at the moment of writing code. This will be reflected in the unit tests as well. So why bother? You merely enshrine your own restricted and circular logic in tests. Which reminds me of maths when teachers would tell us And see, it makes perfect sense!, yeah, because they laid down the rules themselves in the first place. The same goes for comparing your output to some gold standard. The program claims to have an accuracy of 98%. Sure, because you wrote for the gold standard and not for the real world where it drastically drops to 70%. The good thing about unit tests is that they tell you when you break existing code. But you'll realize that soon enough anyway. Yes, yes, yes. Unit tests can be useful in cases like this. But I don't think that they are _the_ way to cope with bugs. It's more like stating the obvious, and bugs are hardly ever obvious, else they wouldn't be bugs. I read some comments in D code on github saying extend unit test to include XYZ. So it's already been tested, it works and it will never be added, just like the debug writeln() disappears after the code has been thoroughly tested. If there's a bug, it's not the XYZ that has been tested but the ZYX nobody thought of (or couldn't think of, because it works as unexpected on Windows) :-). Usually you run standard tests anyway to see if the old stuff still works as expected. Designing unit tests for each module is a bit tedious. And what if you change a function/method? The unit tests will break and you have to write new ones or comment them out. Blah blah blah. Maybe people expect too much from
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 02:39:07AM +, deadalnix via Digitalmars-d wrote:
On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote:
[...]
From the article:
Most importantly, the kinds of bugs that people introduce most often
aren’t the kind of bugs that unit tests catch. With few exceptions
(such as parsers), unit tests are a waste of time.
Not my experience with unittests, repeated over decades and with
different languages. Unit tests are a huge win, even with statically
typed languages.
Well truth to be said, if you don't test, you don't know there is a
bug. Therefore there is no bug.
Yeah, back in my C/C++ days, I also thought unittests were a waste of
time. But after having been shamed into writing unittests in D ('cos
they are just sooo easy to write I ran out of excuses not to), I started
realizing to my horror at how many bugs are actually in my code -- all
kinds of corner cases that I missed, typos that slipped past compiler
checks, etc.. More times than I'm willing to admit, I've revised and
revised my code to perfection and proven (in my head) that it's
correct, only to run it and have it fail the unittests because my brain
has unconsciously tuned out a big glaring typo staring me right in the
face. Had this been in C/C++, the bug wouldn't have been discovered
until much later.
That said, though, for unittests to be actually useful, you sometimes
need to change your coding style. Certain kinds of coding style doesn't
lend itself well to unittesting -- for example, deeply-nested loops that
are very hard to reach into from a unittest, because it may not be
immediately obvious how a unittest might test a rare, tricky
if-condition buried 3 levels inside nested loops. Usually, such code is
actually *never* tested because it's too hard to test -- it's a rare
error-condition that doesn't happen with good input (and how many times
we succumbed to the temptation of thinking the program is only ever
given well-formed input, with disastrous results), too rare to justify
the effort of crafting a unittest that would actually trigger it.
This is where range-based component programming becomes an extremely
powerful idiom -- separating out the logical parts of a complex piece of
code so that there are no longer deeply-nested loops with hard-to-reach
conditions, but everything is brought to the forefront where they can be
easily verified with simple unittests.
But, some people may not be willing to change the way they think about
their coding problem in order to code in a testable way like this. So
they may well resort to trying to rationalize away the usefulness of
unittests. Well, the loss is their own, as the lack of unittesting will
only result in poorer quality of their code, whereas those who are less
arrogant will benefit by developing a much better track record of code
correctness. :-)
T
--
LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 04:49:02AM +0200, ketmar via Digitalmars-d wrote: On Fri, 05 Dec 2014 02:39:49 + deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote: [...] Also relevant: http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application i didn't make it past the contents. too hard for silly me. Whoa. Thanks for the link -- I was actually at some point considering maybe to get into the Java field instead of being stuck with C/C++ at work, but after reading that page, I was completely dispelled of the notion. I think I would lose my sanity after 5 minutes of clicking through those endless submenus, typing out XML by hand (argh), and writing 50 pages of Java legalese and setting up 17 pieces of scaffolding just to get a Hello World program to run. Whoa! I think I need therapy just skimming over that page. This is sooo over-engineered it's not even funny. For all their flaws, C/C++ at least doesn't require that level of inanity... But of course, if I could only write D at my job, that'd be a whole lot different... :-P T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Re: Do everything in Java…
On Fri, 2014-12-05 at 11:53 +, Chris via Digitalmars-d wrote: […] indeed they don't catch bugs, because you only put into unit tests what you know (or expect) at a given moment (just like the old writefln()). The bugs I, or other people, discover later would usually not be caught by unit tests simply because you write for your own expectations at a given moment and don't realize that there are millions of other ways to go astray. So the bugs are usually due to a lack of imagination or a tunnel vision at the moment of writing code. This will be reflected in the unit tests as well. So why bother? You merely enshrine your own restricted and circular logic in tests. Which reminds me of maths when teachers would tell us And see, it makes perfect sense!, yeah, because they laid down the rules themselves in the first place. […] Developers need to stop thinking how is this code supposed to work when it comes to tests and start thinking how can I break this code. It is how testers and QA work, sadly developers all too often fail to. This is particularly relevant for APIs where there is less likely to be a QA team involved, and developers not looking for error cases is why so many APIs are so broken. One of the failings of TDD is the emphasis on correct cases, insufficient emphasis on how can I make this code fail. But that doesn't mean co-development of tests and system is a bad thing. Exactly the opposite, it is a good thing. So on the one hand I agree with much of your analysis, but I totally disagree with your conclusion. Unit, integration and system tests are essential. They document the usage of code and outline the test coverage and how well the system is likely to work. Even if a system appears to work and yet has no tests, it is totally untrustworthy. Best response to such code is rm -rf *. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Do everything in Java…
On Thu, Dec 04, 2014 at 09:03:59PM -0800, Walter Bright via Digitalmars-d wrote: On 12/4/2014 6:47 PM, ketmar via Digitalmars-d wrote: and what i also can't grok is test-driven developement. ah, we spent alot of time writing that tests that we can't even run 'cause we didn't start working on the actual code yet. it's splendid! we didn't start the real work yet and we are already bored. i don't believe that this is a good way to develop a good project. What I find most effective is writing the unit tests and the code they drive at the same time. Yeah, in D, I find that whenever I'm writing a tricky bit of code, I always do an :sp in vim and start adding unittests past the end of the function to record the tricky cases that come to mind. It's proving to be extremely useful in keeping bugs out, because sometimes there are just too many special cases to remember to test afterwards, so if you don't write out the unittests right then and there, you'll probably forget some subtle corner case which will inevitably come back to bite you at the most inconvenient time afterwards. As for TDD... or OOD, or whatever other acronym / bandwagon methodology that get invented every 5 years, I've always been a skeptic. I'm pretty sure the underlying ideas are beneficial -- unittests, thinking of your data in terms of objects, etc.. They are useful tools for getting your job done, and done well. But when you start pushing that as the be-all and end-all of programming, it ceases being a tool and becomes an idealogy shoved down your throat -- everything Must Be A Class Even When It Only Has Static Methods, You Must Write Tests All Day Before Writing A Single Line Of Code, ad nauseaum -- that inevitably results in needlessly convoluted code that isn't actually *better* than more straightforward code to begin with, as well as coders who hold the strange belief that by following the proposed magic formula their code will magically become correct even if they never even bothered to *think* about their programming problem. As Walter once said: I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright T -- Music critic: That's an imitation fugue!
Re: Do everything in Java…
On Friday, 5 December 2014 at 12:42:16 UTC, Chris wrote: I read some comments in D code on github saying extend unit test to include XYZ. So it's already been tested, it works and it will never be added, just like the We require adding test cases to match Phobos changes not because it is necessary to ensure obvious. It is there for regression control so that new behavior won't be broken 2 years later by some random change in compiler / other part of Phobos.
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 09:27:15AM +, Paulo Pinto via Digitalmars-d wrote:
On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote:
[...]
From the article:
Most importantly, the kinds of bugs that people introduce most often
aren’t the kind of bugs that unit tests catch. With few exceptions
(such as parsers), unit tests are a waste of time.
Not my experience with unittests, repeated over decades and with
different languages. Unit tests are a huge win, even with statically
typed languages.
Yes, but they cannot test everything. GUI code is specially ugly as it
requires UI automation tooling.
I don't think it was ever claimed that unittests tested *everything*. If
they did, they'd be *tests*, not merely *unit*tests. :-)
As for GUI code, I've always been of the opinion that it should be coded
in such a way as to be fully scriptable. GUI's that can only operate
when given real user input has failed from the start IMO, because not
being scriptable also means it's non-automatable (crippled, in my book),
but more importantly, it's not auto-testable; you have to hire humans to
sit all day repeating the same sequence of mouse clicks just to make
sure the latest dev build is still working properly. That's grossly
inefficient and a waste of money spent hiring the employee.
They do exist, but only enterprise customers are willing to pay for
it.
IMO, GUI toolkits that don't have built-in UI automation are
fundamentally flawed.
This is why WPF has UI automation built-in.
Yay! :-D
The biggest problem with unit tests are managers that want to see
shiny reports, like those produced by tools like Sonar.
Teams than spend ridiculous amount of time writing superfluous unit
tests just to match milestone targets.
Just because code has tests, doesn't mean the tests are testing what
they should. But if they reach the magical percentage number then
everyone is happy.
[...]
Hmm...
void func1(...) { ... }
unittest {
// Stating the obvious
func1();
assert(1 == 1);
}
unittest {
// If you gotta state it once, better do it twice for
// double the coverage
func1();
assert(2 == 2);
}
unittest {
// And better state it multiple ways just to be sure
func1();
assert(2 == 1 + 1);
// (even though this has nothing to do with func1() at
// all)
}
int func2() { ... }
unittest {
// Just in case the == operator stops working
assert(func2() == func2());
assert(is(typeof(1)));
}
unittest {
// Just in case commutativity stops working -- hey, they
// don't work for floats, better make sure they do for
// ints!
assert(func2() + 1 == 1 + func2());
assert(int.max == int.max);
}
unittest {
// Just in case zero stops behaving like zero, y'know.
assert(func2() * 0 == 0 * func2());
assert(1*0 == 0);
}
Welp, I got 3 unittests per function, I guess I must be doing pretty
well, eh? Sounds like an awesome idea, I should start writing unittests
like this from now on. It's much easier this way, and I'd feel better
about my code just from the sheer number of unittests! Hey, at least I'd
know it if a compiler bug causes built-in operators and types to stop
working!
:-P
T
--
You are only young once, but you can stay immature indefinitely. -- azephrahel
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 11:53:10AM +, Chris via Digitalmars-d wrote: [...] The good thing about unit tests is that they tell you when you break existing code. That's one of the *major* benefits of unittest IMO: prevent regressions. But you'll realize that soon enough anyway. Hahahahahahahahahaha... How I wish that were true! At my day job, you'd be shocked to know how many times things flat-out break in the nastiest, most obvious ways, yet people DO NOT EVEN NOTICE QA has developed this bad habit of only testing the feature they were asked to test, and the developers have become complacent over time and blindly trusting that QA has done their job, when in reality test coverage is extremely poor, and changes get merged into the main code repo that cause all sorts of regressions. I've had to fix the SAME bugs over and over again in various varying forms, simply because we have no unittesting framework to sound the alarms when somebody inadvertently broke the code AGAIN, the 100th time, 'cos they didn't understand what the correct behaviour should be. Fixing regressions is easily 30-40% of my workload, and almost all of those cases could be prevented had there been unittests to catch regressions. How I wish that with every bugfix I submit, I could also submit a unittest to make sure it complains loudly and clearly the next time somebody breaks it yet again! There are so many corner cases that we fixed over time, that there's no way for QA to practically re-test all of them (plus, without automated tests, how realistically can you do full regression testing anyway?), and I can almost guarantee that many of these bugs will come back as soon as that piece of code gets touched again. We always have to add new features, many of which involve extensive code changes, but without unittests, we could be introducing hundreds of subtle bugs every time, and, given the rate of new feature merges, we could be covering over most of these subtle bugs because code paths have changed significantly. As a result, most of these bugs become dormant in the code, and only show up again years later when a new code change uncovers that code path once more. By then, so many changes would've already accumulated that we may have forgotten what the old bug really was and what the bugfix should be. It may take multiple tries before that bug gets re-fixed. All of this needless churn could be eliminated just by having unittests catch regressions up-front. T -- Debian GNU/Linux: Cray on your desktop.
Re: DIP69 - Implement scope for escape proof references
void foo(int[2]) {}
void bar(int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
That is a rather unfriendly syntax, it is the kind that
degenerates into noise with other structures.
Re: DIP69 - Implement scope for escape proof references
On Friday, 5 December 2014 at 02:38:48 UTC, Daniel Murphy wrote: H. S. Teoh via Digitalmars-d wrote in message news:mailman.2709.1417745546.9932.digitalmar...@puremagic.com... I've often pondered about the possibility of a language where the compiler will analyze each module and infer any number of attributes and optimization opportunities for each symbol exported by that module, and this information will be saved in the object file (or some other kind of interfacing file). This includes any half-compiled template bodies and whatever else that can't be fully codegen'd until actual use. The attributes will include all sorts of stuff that programmers normally wouldn't want to deal with -- there could be 10+ or 50+ attributes representing various optimization / static checking opportunities. Then every time a module is imported by another module, the compiler never goes to the source code of the imported module anymore, but it will read the object (interface) file, which is fully attributed, and the saved attributes will be used internally for static checking, optimization, and inferring attributes for the current module. This can't be used to infer attributes that can produce errors - those attributes have to be user-visible or the errors don't make any sense. If it's purely for optimization, then that's basically what LTO does. We could inter attributes if not specified instead of assuming a default, for example @nogc and a possible @gc. --- int[] foo1(int[] bar) @nogc // function is @nogc, error if gc is used int[] foo2(int[] bar) @gc // function is @gc, functions that call foo2 cannot be @nogc int[] foo3(int[] bar) // neither @nogc nor @gc, compiler infers attribute ---
Re: DIP69 - Implement scope for escape proof references
ixid:
void foo(int[2]) {}
void bar(int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
That is a rather unfriendly syntax, it is the kind that
degenerates into noise with other structures.
Can you show an example of the noisy code it causes?
And are you able to invent something succint that is better?
Bye,
bearophile
Re: Do everything in Java…
On Friday, 5 December 2014 at 11:53:11 UTC, Chris wrote: and stuff like this. Stupid? Unprofessional? I don't know. It works. I once started to write unit tests only to find out that indeed they don't catch bugs, because you only put into unit tests what you know (or expect) at a given moment (just like the old writefln()). The bugs I, or other people, discover later would usually not be caught by unit tests simply because you write for your own expectations at a given moment and don't realize that there are millions of other ways to go astray. The code can still break even if those expectations are met. Of course tests catch only regressions, not all possible sorts of bugs. And when they do, it's really fascinating.
Re: Do everything in Java…
On Friday, 5 December 2014 at 13:43:51 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Dec 05, 2014 at 09:27:15AM +, Paulo Pinto via Digitalmars-d wrote: On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote: [...] you have to hire humans to sit all day repeating the same sequence of mouse clicks just to make sure the latest dev build is still working properly. That's grossly inefficient and a waste of money spent hiring the employee. Since this is a public forum, the best I allowed to say is search for sweet shop coding. Over a beer I would say something else. -- Paulo
Re: Do everything in Java…
On Friday, 5 December 2014 at 13:14:52 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Dec 05, 2014 at 04:49:02AM +0200, ketmar via Digitalmars-d wrote: On Fri, 05 Dec 2014 02:39:49 + deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote: [...] Also relevant: http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application i didn't make it past the contents. too hard for silly me. Whoa. Thanks for the link -- I was actually at some point considering maybe to get into the Java field instead of being stuck with C/C++ at work, but after reading that page, I was completely dispelled of the notion. I think I would lose my sanity after 5 minutes of clicking through those endless submenus, typing out XML by hand (argh), and writing 50 pages of Java legalese and setting up 17 pieces of scaffolding just to get a Hello World program to run. Whoa! I think I need therapy just skimming over that page. This is sooo over-engineered it's not even funny. For all their flaws, C/C++ at least doesn't require that level of inanity... But of course, if I could only write D at my job, that'd be a whole lot different... :-P T Modern JEE is quite different from that tutorial. Besides you don't use JEE for HelloWorld, rather for distributed applications. C/C++ don't provide half the tools that allow JEE to scale across the cluster and the respective monitoring infrastructure. JEE is the evolution of distributed CORBA applications in the enterprise, with .NET enterprise applications being the evolution of DCOM. Both games that C++ lost its place at. -- Paulo
Re: DIP69 - Implement scope for escape proof references
On Friday, 5 December 2014 at 14:10:44 UTC, bearophile wrote:
ixid:
void foo(int[2]) {}
void bar(int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
That is a rather unfriendly syntax, it is the kind that
degenerates into noise with other structures.
Can you show an example of the noisy code it causes?
And are you able to invent something succint that is better?
Bye,
bearophile
[1,2].stack
stack [1,2]
@stack [1,2]
[1,2]stack
Re: Do everything in Java…
On 12/5/14, 8:53 AM, Chris wrote: On Friday, 5 December 2014 at 09:27:16 UTC, Paulo Pinto wrote: On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote: On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote: Now is the right time to confess. I hardly ever use unit tests although it's included (and encouraged) in D. Why? When I write new code I unit test as I go along, with debug writefln(result %s, result); and stuff like this. Stupid? Unprofessional? I don't know. It works. You should trying writing a compiler without unit tests.
Re: Do everything in Java…
On 12/5/14, 9:42 AM, Chris wrote: On Friday, 5 December 2014 at 12:06:55 UTC, Nemanja Boric wrote: The good thing about unit tests is that they tell you when you break existing code. That's the great thing about unittests, and the reason why I write unittests. I work on a fairly complex code base and every now and then there's a new feature requested. Implementing features involves several to dozen of modules to be changed, and there's no way that I could guarantee that feature implementation didn't change behaviour of the existing code. I both hate and love when I `make` compiles and unittest fails. But you'll realize that soon enough anyway. This is not good enough for me. Sometimes soon enough means week or two before somebody actually notice the bug in the implementation (again, very complex project that's simply not hand-testable), and that's definitively not soon enough keeping in mind amount of $$$ that you wasted into air. On Friday, 5 December 2014 at 11:53:11 UTC, Chris wrote: On Friday, 5 December 2014 at 09:27:16 UTC, Paulo Pinto wrote: On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote: On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote: http://www.teamten.com/lawrence/writings/java-for-everything.html i didn't read the article, but i bet that this is just another article about his language of preference and how any other language he tried doesn't have X or Y or Z. and those X, Y and Z are something like not being on market for long enough, vendor ACME didn't ported ACMElib to it, out staff is trained in G but not in M and so on. boring. From the article: Most importantly, the kinds of bugs that people introduce most often aren’t the kind of bugs that unit tests catch. With few exceptions (such as parsers), unit tests are a waste of time. Not my experience with unittests, repeated over decades and with different languages. Unit tests are a huge win, even with statically typed languages. Yes, but they cannot test everything. GUI code is specially ugly as it requires UI automation tooling. They do exist, but only enterprise customers are willing to pay for it. This is why WPF has UI automation built-in. The biggest problem with unit tests are managers that want to see shiny reports, like those produced by tools like Sonar. Teams than spend ridiculous amount of time writing superfluous unit tests just to match milestone targets. Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. -- Paulo Now is the right time to confess. I hardly ever use unit tests although it's included (and encouraged) in D. Why? When I write new code I unit test as I go along, with debug writefln(result %s, result); and stuff like this. Stupid? Unprofessional? I don't know. It works. I once started to write unit tests only to find out that indeed they don't catch bugs, because you only put into unit tests what you know (or expect) at a given moment (just like the old writefln()). The bugs I, or other people, discover later would usually not be caught by unit tests simply because you write for your own expectations at a given moment and don't realize that there are millions of other ways to go astray. So the bugs are usually due to a lack of imagination or a tunnel vision at the moment of writing code. This will be reflected in the unit tests as well. So why bother? You merely enshrine your own restricted and circular logic in tests. Which reminds me of maths when teachers would tell us And see, it makes perfect sense!, yeah, because they laid down the rules themselves in the first place. The same goes for comparing your output to some gold standard. The program claims to have an accuracy of 98%. Sure, because you wrote for the gold standard and not for the real world where it drastically drops to 70%. The good thing about unit tests is that they tell you when you break existing code. But you'll realize that soon enough anyway. Yes, yes, yes. Unit tests can be useful in cases like this. But I don't think that they are _the_ way to cope with bugs. It's more like stating the obvious, and bugs are hardly ever obvious, else they wouldn't be bugs. Unit tests are not for detecting bugs. They are only useful for: 1. Making sure things work (a bit). 2. Making sure things continue to work when you refactor or introduce new code. 3. When a new bug is found you can write a test for it that will make that bug impossible to ever resurrect. 4. Show how code is supposed to be used. Again, their purpose is not to detect bugs, but to build more robust software.
Re: Do everything in Java…
On Friday, 5 December 2014 at 15:03:39 UTC, Ary Borenszweig wrote: On 12/5/14, 9:42 AM, Chris wrote: On Friday, 5 December 2014 at 12:06:55 UTC, Nemanja Boric wrote: The good thing about unit tests is that they tell you when you break existing code. That's the great thing about unittests, and the reason why I write unittests. I work on a fairly complex code base and every now and then there's a new feature requested. Implementing features involves several to dozen of modules to be changed, and there's no way that I could guarantee that feature implementation didn't change behaviour of the existing code. I both hate and love when I `make` compiles and unittest fails. But you'll realize that soon enough anyway. This is not good enough for me. Sometimes soon enough means week or two before somebody actually notice the bug in the implementation (again, very complex project that's simply not hand-testable), and that's definitively not soon enough keeping in mind amount of $$$ that you wasted into air. On Friday, 5 December 2014 at 11:53:11 UTC, Chris wrote: On Friday, 5 December 2014 at 09:27:16 UTC, Paulo Pinto wrote: On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote: On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote: http://www.teamten.com/lawrence/writings/java-for-everything.html i didn't read the article, but i bet that this is just another article about his language of preference and how any other language he tried doesn't have X or Y or Z. and those X, Y and Z are something like not being on market for long enough, vendor ACME didn't ported ACMElib to it, out staff is trained in G but not in M and so on. boring. From the article: Most importantly, the kinds of bugs that people introduce most often aren’t the kind of bugs that unit tests catch. With few exceptions (such as parsers), unit tests are a waste of time. Not my experience with unittests, repeated over decades and with different languages. Unit tests are a huge win, even with statically typed languages. Yes, but they cannot test everything. GUI code is specially ugly as it requires UI automation tooling. They do exist, but only enterprise customers are willing to pay for it. This is why WPF has UI automation built-in. The biggest problem with unit tests are managers that want to see shiny reports, like those produced by tools like Sonar. Teams than spend ridiculous amount of time writing superfluous unit tests just to match milestone targets. Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. -- Paulo Now is the right time to confess. I hardly ever use unit tests although it's included (and encouraged) in D. Why? When I write new code I unit test as I go along, with debug writefln(result %s, result); and stuff like this. Stupid? Unprofessional? I don't know. It works. I once started to write unit tests only to find out that indeed they don't catch bugs, because you only put into unit tests what you know (or expect) at a given moment (just like the old writefln()). The bugs I, or other people, discover later would usually not be caught by unit tests simply because you write for your own expectations at a given moment and don't realize that there are millions of other ways to go astray. So the bugs are usually due to a lack of imagination or a tunnel vision at the moment of writing code. This will be reflected in the unit tests as well. So why bother? You merely enshrine your own restricted and circular logic in tests. Which reminds me of maths when teachers would tell us And see, it makes perfect sense!, yeah, because they laid down the rules themselves in the first place. The same goes for comparing your output to some gold standard. The program claims to have an accuracy of 98%. Sure, because you wrote for the gold standard and not for the real world where it drastically drops to 70%. The good thing about unit tests is that they tell you when you break existing code. But you'll realize that soon enough anyway. Yes, yes, yes. Unit tests can be useful in cases like this. But I don't think that they are _the_ way to cope with bugs. It's more like stating the obvious, and bugs are hardly ever obvious, else they wouldn't be bugs. Unit tests are not for detecting bugs. They are only useful for: 1. Making sure things work (a bit). 2. Making sure things continue to work when you refactor or introduce new code. 3. When a new bug is found you can write a test for it that will make that bug impossible to ever resurrect. 4. Show how code is supposed to be used. Again, their purpose is not to detect bugs, but to build more robust software. I completely agree with all your points. Point 4 I forgot to mention, I often look at the unit tests in D source code to see how it is supposed to be used. All I'm saying is that sometimes
Re: Do everything in Java…
On Friday, 5 December 2014 at 13:06:14 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Dec 05, 2014 at 02:39:07AM +, deadalnix via
Digitalmars-d wrote:
On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright
wrote:
[...]
From the article:
Most importantly, the kinds of bugs that people introduce
most often
aren’t the kind of bugs that unit tests catch. With few
exceptions
(such as parsers), unit tests are a waste of time.
Not my experience with unittests, repeated over decades and
with
different languages. Unit tests are a huge win, even with
statically
typed languages.
Well truth to be said, if you don't test, you don't know there
is a
bug. Therefore there is no bug.
Yeah, back in my C/C++ days, I also thought unittests were a
waste of
time. But after having been shamed into writing unittests in D
('cos
they are just sooo easy to write I ran out of excuses not to),
I started
realizing to my horror at how many bugs are actually in my code
-- all
kinds of corner cases that I missed, typos that slipped past
compiler
checks, etc.. More times than I'm willing to admit, I've
revised and
revised my code to perfection and proven (in my head) that
it's
correct, only to run it and have it fail the unittests because
my brain
has unconsciously tuned out a big glaring typo staring me right
in the
face. Had this been in C/C++, the bug wouldn't have been
discovered
until much later.
That said, though, for unittests to be actually useful, you
sometimes
need to change your coding style. Certain kinds of coding style
doesn't
lend itself well to unittesting -- for example, deeply-nested
loops that
are very hard to reach into from a unittest, because it may not
be
immediately obvious how a unittest might test a rare, tricky
if-condition buried 3 levels inside nested loops. Usually, such
code is
actually *never* tested because it's too hard to test -- it's a
rare
error-condition that doesn't happen with good input (and how
many times
we succumbed to the temptation of thinking the program is only
ever
given well-formed input, with disastrous results), too rare to
justify
the effort of crafting a unittest that would actually trigger
it.
This is where range-based component programming becomes an
extremely
powerful idiom -- separating out the logical parts of a complex
piece of
code so that there are no longer deeply-nested loops with
hard-to-reach
conditions, but everything is brought to the forefront where
they can be
easily verified with simple unittests.
But, some people may not be willing to change the way they
think about
their coding problem in order to code in a testable way like
this. So
they may well resort to trying to rationalize away the
usefulness of
unittests. Well, the loss is their own, as the lack of
unittesting will
only result in poorer quality of their code, whereas those who
are less
arrogant will benefit by developing a much better track record
of code
correctness. :-)
T
I wish it was arrogance or unwillingness to change, because you
can work on that. If I were arrogant or unwilling to learn, I
wouldn't have gone for D which keeps kicking me in the backend
relentlessly.
I introduced uint tests a while ago (because it's sooo easy in D)
but I've failed to maintain them. I found out that most of the
bugs weren't caught in the unit tests but where somewhere else
further down in the logic (more on that later). I repeat my point
that we put into the unit tests what think will or won't work,
just as you said:
I've revised and
revised my code to perfection and proven (in my head) that
it's
correct, only to run it and have it fail the unittests because
my brain
has unconsciously tuned out a big glaring typo staring me right
in the
face.
Unit tests are just another way of proving in your head. In D
I work a lot with components and ranges, and I f**king love it.
While it is true that this approach to programming makes each
unit easily testable, I've found out that they are no guard
against major f**k ups further down in a program's logic. At the
end of the day, you have to design a general test suit for the
whole program and see if it works. So why bother to test every
unit, which may work perfectly fine on its own, when you have to
test the whole shebang anyway.
As I said, I'm not against unit tests and I use them where they
make sense (difficult output, not breaking existing tested code).
But I often don't bother with them when they tell me what I
already know.
assert(addNumbers(1,1) == 2);
I've found myself in the position when unit tests give me a false
sense of security.
What Russel said, that we should think about breaking the code.
It's true, but extremely hard to do when you _create_ something.
You create something to make it work and not to destroy it. It
also kills your imagination. It's like writing a thesis when you
spend most of the time preparing for possible attacks from the
examiners rather
Re: DIP69 - Implement scope for escape proof references
On 12/4/14 5:48 PM, deadalnix wrote: On Thursday, 4 December 2014 at 14:58:47 UTC, Steven Schveighoffer wrote: There can be at most one owner for any piece of data. This doesn't seem right. For GC data, the GC owns the data, that is true. But for Ref-counted data, there is more than one owner, and only when all the owners disown the data can it be destroyed. The RC mechanism is the owner. Ownership is loosly defined in this DIp so that it do not close any door for future language evolution. Well, actually the DIP is pretty rigid, it speaks only of ownership in terms of variables -- which variable owns a piece of data. It doesn't allow this kind of ownership via a concept or condition. I would change the DIP to reflect this clarification, if that is what is intended. -Steve
Re: Do everything in Java…
On 12/5/14, 12:11 PM, Chris wrote: On Friday, 5 December 2014 at 15:03:39 UTC, Ary Borenszweig wrote: On 12/5/14, 9:42 AM, Chris wrote: On Friday, 5 December 2014 at 12:06:55 UTC, Nemanja Boric wrote: The good thing about unit tests is that they tell you when you break existing code. That's the great thing about unittests, and the reason why I write unittests. I work on a fairly complex code base and every now and then there's a new feature requested. Implementing features involves several to dozen of modules to be changed, and there's no way that I could guarantee that feature implementation didn't change behaviour of the existing code. I both hate and love when I `make` compiles and unittest fails. But you'll realize that soon enough anyway. This is not good enough for me. Sometimes soon enough means week or two before somebody actually notice the bug in the implementation (again, very complex project that's simply not hand-testable), and that's definitively not soon enough keeping in mind amount of $$$ that you wasted into air. On Friday, 5 December 2014 at 11:53:11 UTC, Chris wrote: On Friday, 5 December 2014 at 09:27:16 UTC, Paulo Pinto wrote: On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote: On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote: http://www.teamten.com/lawrence/writings/java-for-everything.html i didn't read the article, but i bet that this is just another article about his language of preference and how any other language he tried doesn't have X or Y or Z. and those X, Y and Z are something like not being on market for long enough, vendor ACME didn't ported ACMElib to it, out staff is trained in G but not in M and so on. boring. From the article: Most importantly, the kinds of bugs that people introduce most often aren’t the kind of bugs that unit tests catch. With few exceptions (such as parsers), unit tests are a waste of time. Not my experience with unittests, repeated over decades and with different languages. Unit tests are a huge win, even with statically typed languages. Yes, but they cannot test everything. GUI code is specially ugly as it requires UI automation tooling. They do exist, but only enterprise customers are willing to pay for it. This is why WPF has UI automation built-in. The biggest problem with unit tests are managers that want to see shiny reports, like those produced by tools like Sonar. Teams than spend ridiculous amount of time writing superfluous unit tests just to match milestone targets. Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. -- Paulo Now is the right time to confess. I hardly ever use unit tests although it's included (and encouraged) in D. Why? When I write new code I unit test as I go along, with debug writefln(result %s, result); and stuff like this. Stupid? Unprofessional? I don't know. It works. I once started to write unit tests only to find out that indeed they don't catch bugs, because you only put into unit tests what you know (or expect) at a given moment (just like the old writefln()). The bugs I, or other people, discover later would usually not be caught by unit tests simply because you write for your own expectations at a given moment and don't realize that there are millions of other ways to go astray. So the bugs are usually due to a lack of imagination or a tunnel vision at the moment of writing code. This will be reflected in the unit tests as well. So why bother? You merely enshrine your own restricted and circular logic in tests. Which reminds me of maths when teachers would tell us And see, it makes perfect sense!, yeah, because they laid down the rules themselves in the first place. The same goes for comparing your output to some gold standard. The program claims to have an accuracy of 98%. Sure, because you wrote for the gold standard and not for the real world where it drastically drops to 70%. The good thing about unit tests is that they tell you when you break existing code. But you'll realize that soon enough anyway. Yes, yes, yes. Unit tests can be useful in cases like this. But I don't think that they are _the_ way to cope with bugs. It's more like stating the obvious, and bugs are hardly ever obvious, else they wouldn't be bugs. Unit tests are not for detecting bugs. They are only useful for: 1. Making sure things work (a bit). 2. Making sure things continue to work when you refactor or introduce new code. 3. When a new bug is found you can write a test for it that will make that bug impossible to ever resurrect. 4. Show how code is supposed to be used. Again, their purpose is not to detect bugs, but to build more robust software. I completely agree with all your points. Point 4 I forgot to mention, I often look at the unit tests in D source code to see how it is supposed to be used. All I'm saying is that sometimes unit tests are sold as the be all
Re: DIP69 - Implement scope for escape proof references
On 12/4/14 4:24 AM, Walter Bright wrote: http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. This, among other things, makes a ref counting type practical. It also makes it more practical to use other storage allocation schemes than garbage collection. It does not make scope into a type constructor, nor a general type-annotation system. It does not provide an ownership system, though it would complement one. Can we take a step back here? I read many people's comments and I understand only about half of them. Can someone who knows what this new feature is supposed to do give some Ali Çehreli-like description on the feature? Basically, let's strip out the *proof* in the DIP (the how it works and why we have it), and focus on how it is to be used. I still am having a hard time wrapping my head around the benefits and when to use scope, scope ref, why I would use it. I'm worried that we are adding all this complication and it will confuse the shit out of users, to the point where they won't use it. -Steve
Re: Do everything in Java…
On Friday, 5 December 2014 at 15:25:19 UTC, Ary Borenszweig wrote: On 12/5/14, 12:11 PM, Chris wrote: On Friday, 5 December 2014 at 15:03:39 UTC, Ary Borenszweig wrote: On 12/5/14, 9:42 AM, Chris wrote: On Friday, 5 December 2014 at 12:06:55 UTC, Nemanja Boric wrote: The good thing about unit tests is that they tell you when you break existing code. That's the great thing about unittests, and the reason why I write unittests. I work on a fairly complex code base and every now and then there's a new feature requested. Implementing features involves several to dozen of modules to be changed, and there's no way that I could guarantee that feature implementation didn't change behaviour of the existing code. I both hate and love when I `make` compiles and unittest fails. But you'll realize that soon enough anyway. This is not good enough for me. Sometimes soon enough means week or two before somebody actually notice the bug in the implementation (again, very complex project that's simply not hand-testable), and that's definitively not soon enough keeping in mind amount of $$$ that you wasted into air. On Friday, 5 December 2014 at 11:53:11 UTC, Chris wrote: On Friday, 5 December 2014 at 09:27:16 UTC, Paulo Pinto wrote: On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote: On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote: http://www.teamten.com/lawrence/writings/java-for-everything.html i didn't read the article, but i bet that this is just another article about his language of preference and how any other language he tried doesn't have X or Y or Z. and those X, Y and Z are something like not being on market for long enough, vendor ACME didn't ported ACMElib to it, out staff is trained in G but not in M and so on. boring. From the article: Most importantly, the kinds of bugs that people introduce most often aren’t the kind of bugs that unit tests catch. With few exceptions (such as parsers), unit tests are a waste of time. Not my experience with unittests, repeated over decades and with different languages. Unit tests are a huge win, even with statically typed languages. Yes, but they cannot test everything. GUI code is specially ugly as it requires UI automation tooling. They do exist, but only enterprise customers are willing to pay for it. This is why WPF has UI automation built-in. The biggest problem with unit tests are managers that want to see shiny reports, like those produced by tools like Sonar. Teams than spend ridiculous amount of time writing superfluous unit tests just to match milestone targets. Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. -- Paulo Now is the right time to confess. I hardly ever use unit tests although it's included (and encouraged) in D. Why? When I write new code I unit test as I go along, with debug writefln(result %s, result); and stuff like this. Stupid? Unprofessional? I don't know. It works. I once started to write unit tests only to find out that indeed they don't catch bugs, because you only put into unit tests what you know (or expect) at a given moment (just like the old writefln()). The bugs I, or other people, discover later would usually not be caught by unit tests simply because you write for your own expectations at a given moment and don't realize that there are millions of other ways to go astray. So the bugs are usually due to a lack of imagination or a tunnel vision at the moment of writing code. This will be reflected in the unit tests as well. So why bother? You merely enshrine your own restricted and circular logic in tests. Which reminds me of maths when teachers would tell us And see, it makes perfect sense!, yeah, because they laid down the rules themselves in the first place. The same goes for comparing your output to some gold standard. The program claims to have an accuracy of 98%. Sure, because you wrote for the gold standard and not for the real world where it drastically drops to 70%. The good thing about unit tests is that they tell you when you break existing code. But you'll realize that soon enough anyway. Yes, yes, yes. Unit tests can be useful in cases like this. But I don't think that they are _the_ way to cope with bugs. It's more like stating the obvious, and bugs are hardly ever obvious, else they wouldn't be bugs. Unit tests are not for detecting bugs. They are only useful for: 1. Making sure things work (a bit). 2. Making sure things continue to work when you refactor or introduce new code. 3. When a new bug is found you can write a test for it that will make that bug impossible to ever resurrect. 4. Show how code is supposed to be used. Again, their purpose is not to detect bugs, but to build more robust software. I completely agree with all your points. Point 4 I forgot to mention, I often
Re: Do everything in Java…
On Friday, 5 December 2014 at 14:53:43 UTC, Chris wrote: As I said, I'm not against unit tests and I use them where they make sense (difficult output, not breaking existing tested code). But I often don't bother with them when they tell me what I already know. assert(addNumbers(1,1) == 2); I've found myself in the position when unit tests give me a false sense of security. Sure, you need to test the obvious things, but I find the real gains come from being able to verify the behaviour of edge cases and pathological input; and, critically, ensuring that that behaviour doesn't change as you refactor. (My day job involves writing and maintaining legacy network libraries and parsers in pure C. D's clean and easy unit tests would be a godsend for me.) -Wyatt
Re: Do everything in Java…
On Friday, 5 December 2014 at 13:56:27 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Dec 05, 2014 at 11:53:10AM +, Chris via Digitalmars-d wrote: At my day job, you'd be shocked to know how many times things flat-out break in the nastiest, most obvious ways, yet people DO NOT EVEN NOTICE QA has developed this bad habit of only testing the feature they were asked to test, and the developers have become complacent over time and blindly trusting that QA has done their job, That's not trust or complaceny. That's a worldwide conspiracy to ensure good paid jobs for poor programmers testers like us...
Re: Do everything in Java…
On Friday, 5 December 2014 at 15:44:35 UTC, Wyatt wrote: On Friday, 5 December 2014 at 14:53:43 UTC, Chris wrote: As I said, I'm not against unit tests and I use them where they make sense (difficult output, not breaking existing tested code). But I often don't bother with them when they tell me what I already know. assert(addNumbers(1,1) == 2); I've found myself in the position when unit tests give me a false sense of security. Sure, you need to test the obvious things, Everywhere? For each function? It may be desirable but hard to maintain. Also, unit tests break when you change the behavior of a function, then you have to redesign the unit test for this particular function. I prefer unit tests for bigger chunks. but I find the real gains come from being able to verify the behaviour of edge cases and pathological input; and, critically, ensuring that that behaviour doesn't change as you refactor. (My day job involves writing and maintaining legacy network libraries and parsers in pure C. D's clean and easy unit tests would be a godsend for me.) -Wyatt True, true. Unfortunately, the edge cases are usually spotted when using the software, not in unit tests. They can be included later, but new pathological input keeps coming up (especially if you write for third party software). Now don't get me wrong, I wouldn't want to miss unit tests in D, but I use them more carefully now, not everywhere.
Re: Do everything in Java…
On Friday, 5 December 2014 at 15:49:13 UTC, eles wrote: On Friday, 5 December 2014 at 13:56:27 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Dec 05, 2014 at 11:53:10AM +, Chris via Digitalmars-d wrote: At my day job, you'd be shocked to know how many times things flat-out break in the nastiest, most obvious ways, yet people DO NOT EVEN NOTICE QA has developed this bad habit of only testing the feature they were asked to test, and the developers have become complacent over time and blindly trusting that QA has done their job, That's not trust or complaceny. That's a worldwide conspiracy to ensure good paid jobs for poor programmers testers like us... Programmers get paid for fixing bugs they have introduced themselves. :-)
Re: Would you trade 0.1% in performance for a better debugging experience?
On Thursday, 4 December 2014 at 22:11:36 UTC, Martin Nowak wrote: If it were only 0.1% at maximum for any code, it wouldn't be a problem. But enabling stack traces would make a std.simd module which would only consists of tiny leaf functions basically unusable. Traditionally it doesn't prevent inlining. Inlined functions will disappear from the stack trace, but most of it will stay.
Re: D Meetup in SF?
On Friday, 5 December 2014 at 08:15:03 UTC, Shammah Chancellor wrote: I didn't notice a D meetup group in SF. Is anyone else in here interested in doing something like this once a month? -S. I am interested, preferable Sunday evening or so, because I am fairly limited on the weekend due to commute. Something in the south (Palo Alto, etc) would work for me as well.
Re: Would you trade 0.1% in performance for a better debugging experience?
On Thursday, 4 December 2014 at 22:08:20 UTC, Martin Nowak wrote: -fasynchronous-unwind-tables Whoa! Are they big?
Re: DIP69 - Implement scope for escape proof references
There are limitations this proposal has in comparison to my
original one. These limitations might of course be harmless and
play no role in practice, but on the other hand, they may, so I
think it's good to list them here.
Additionally I have to agree with Steven Schveighoffer: This DIP
is very complicated to understand. It's not obvious how the
various parts play together, and why/to which degree it works,
and which are the limitations. I don't think that's only because
my brain is already locked on my proposal...
1) Escape detection is limited to `ref`.
T* evil;
ref T func(scope ref T t, ref T u) @safe {
return t; // Error: escaping scope ref t
return u; // ok
evil = u; // Error: escaping reference
}
vs.
T[] evil;
T[] func(scope T[] t, T[] u) @safe {
return t; // Error: cannot return scope
return u; // ok
evil = u; // !!! not good
}
As can be seen, `ref T u` is protected from escaping (apart from
returning it), while `T[] u` in the second example is not.
There's no general way to express that `u` can only be returned
from the function, but will not be retained otherwise by storing
it in a global variable. Adding `pure` can express this in many
cases, but is, of course, not always possible.
Another workaround is passing the parameters as `ref`, but this
would introduce an additional indirection and has different
semantics (e.g. when the lengths of the slices are modified).
2) `scope ref` return values cannot be stored.
scope ref int foo();
void bar(scope ref int a);
foo().bar();// allowed
scope tmp = foo(); // not allowed
tmp.bar();
Another example:
struct Container(T) {
scope ref T opIndex(size_t index);
}
void bar(scope ref int a);
Container c;
bar(c[42]);// ok
scope ref tmp = c[42]; // nope
Both cases should be fine theoretically; the real owner lives
longer than `tmp`. Unfortunately the compiler doesn't know about
this.
Both restrictions 1) and 2) are because there are no explicit
lifetime/owner designations (the scope!identifier thingy in my
proposal).
3) `scope` cannot be used for value types.
I can think of a few use cases for scoped value types (RC and
file descriptors), but they might only be marginal.
4) No overloading on `scope`.
This is at least partially a consequence of `scope` inference. I
think overloading can be made to work in the presence of
inference, but I haven't thought it through.
5) `scope` is a storage class.
Manu complained about `ref` being a storage class. If I
understand him right, one reason is that we have a large toolkit
for dealing with type modifiers, but almost nothing for storage
classes. I have to agree with him there. But I haven't understood
his point fully, maybe he himself can post more about his
problems with this?
6) There seem to be problems with chaining.
scope ref int foo();
scope ref int bar1(ref int a) {
return a;
}
scope ref int bar2(scope ref int a) {
return a;
}
ref int bar3(ref int a) {
return a;
}
ref int bar4(scope ref int a) {
return a;
}
void baz(scope ref int a);
Which of the following calls would work?
foo().bar1().baz();
foo().bar2().baz();
foo().bar3().baz();
foo().bar4().baz();
I'm not sure I understand this fully yet, but it could be that
none of them work...
Re: Do everything in Java…
On Friday, 5 December 2014 at 15:25:19 UTC, Ary Borenszweig wrote: This is very true. Specially when mocks come into play, sometimes test become duplicated code and every time you make changes in your codebase you have to go and change the expected behaviour of mocks, which is just tedious and useless. In my opinion OOP is very unfriendly for testing as a paradigm in general. The very necessity to create mocks is usually an alarm.
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 03:55:22PM +, Chris via Digitalmars-d wrote: On Friday, 5 December 2014 at 15:44:35 UTC, Wyatt wrote: On Friday, 5 December 2014 at 14:53:43 UTC, Chris wrote: As I said, I'm not against unit tests and I use them where they make sense (difficult output, not breaking existing tested code). But I often don't bother with them when they tell me what I already know. assert(addNumbers(1,1) == 2); I've found myself in the position when unit tests give me a false sense of security. This is an example of a poor unittest. Well, maybe *one* such case isn't a bad idea to stick in a unittest block somewhere (to make sure things haven't broken *outright*, but you'd notice that via other channels pretty quickly!). But this is akin to writing a unittest that computes the square root of a number in order to test a function that computes the square root of a number. Either it's already blindingly obvious and you're just wasting time, or the unittest is so complex that it proves nothing (you could be repeating exactly the same bugs as the code itself!). No, a better way to writing a unittest is to approach it from the user's (i.e., caller's) POV. Given this function (as a black box), what kind of behaviour do I expect from it? What if I give it unusual arguments, will it still give the correct result? It's well-known that most bugs happen on boundary conditions, not in the general output (which is usually easy to get right the first time). So, unittests should mainly focus on boundary and exceptional cases. For example, in testing a sqrt function, I wouldn't waste time testing sqrt(16) or sqrt(65536) -- at the most, I'd do just one such case and move on. But most of the testing should be on the exceptional cases, e.g., what happens with sqrt(17) if the function returns an int? That's one case. What about sqrt(1)? sqrt(0)? what happens if you hand it a negative number? Sure, you need to test the obvious things, Everywhere? For each function? It may be desirable but hard to maintain. Also, unit tests break when you change the behavior of a function, then you have to redesign the unit test for this particular function. I prefer unit tests for bigger chunks. Usually, I don't even bother unittesting a function that isn't generic enough that I know it won't drastically change over time. Usually, it's when I start factoring out code in generic form that I really start working on the unittests. When I'm still in the experimental / exploratory stage, I'd throw in some tests to catch boundary conditions, but I wouldn't spend too much time on that. Most of the unittests should be aimed at preserving certain guarantees -- e.g., math functions should obey certain identities even around boundary values, API functions should always behave according to what external users would expect, etc.. But internal functions that are subject to a lot of changes -- I wouldn't do too much more than just stick in a few things that I know might be problematic (usually while writing the code itself). Any cases not caught by this will be caught at the API boundary when something starts failing API guarantees. Besides these, I'd add a unittest for each bug I fix -- for regression control. I'm not afraid of outright deleting unittests if the associated function has been basically gutted and rewritten from scratch, if said unittests are more concerned with implementation details. The ones concerned with overall behaviour would be kept. This is another reason it's better to put the unittest effort on the API level than on overly white-box dependent parts, since those are subject to frequent revisions. but I find the real gains come from being able to verify the behaviour of edge cases and pathological input; and, critically, ensuring that that behaviour doesn't change as you refactor. (My day job involves writing and maintaining legacy network libraries and parsers in pure C. D's clean and easy unit tests would be a godsend for me.) -Wyatt True, true. Unfortunately, the edge cases are usually spotted when using the software, not in unit tests. They can be included later, but new pathological input keeps coming up (especially if you write for third party software). I guess it depends on the kind of application you write, but when writing unittests I tend to focus on what ways the code could break, rather than how it might work. Sure, you won't be able to come up with *all* the cases, and unittests sure don't guarantee 100% bug-free code, but generally you do catch the most frequent ones, which saves time dealing with the whole cycle of customer reports, generating bug fix change orders, QA testing, etc.. The ones that weren't caught early will eventually be found in the field, and they would be added to the growing body of unittests to control future regressions. Now don't get me wrong, I wouldn't want to miss unit tests in D, but I use them more carefully now, not everywhere. As
Re: Would you trade 0.1% in performance for a better debugging experience?
On Thursday, 4 December 2014 at 16:44:51 UTC, Temtaime wrote: Why when an DMD developer said « no » to you in ticket you go to the forum and troll there ? If one wants debug information he will use debug version of phobos. In fine-tune application there's no need for -gs flag. With stack info in place, core dumps become a much more useful tool for diagnosing production problems. It should definitely be an option that can be disabled, but I'm in favor of having it on by default.
Re: Need help deciphering posix.mak
Dicebot wrote in message news:jrymzqkdctmfsgrqz...@forum.dlang.org... How is it really different? Both require external tool, both are available via prebuilt windows binary. At least you can build GNU one yourself. Because I already have to install dmc and dm make comes with that.
Re: Need help deciphering posix.mak
uri wrote in message news:glxybpnqadqnfnixk...@forum.dlang.org... I think I'd much rather GNU make. No offence, but there's no chance your little tool will ever get the same test coverage or real-world use testing of GNU make on Windows. This is why I prefer CMake like tools over dub. Plus make -jX is *much* faster than dub build (and SCons for that matter). That doesn't make a lot of sense to me. It's a script that runs tests, I don't care how well real-world tested it is.
Re: Need help deciphering posix.mak
On Friday, 5 December 2014 at 17:47:10 UTC, Daniel Murphy wrote: Dicebot wrote in message news:jrymzqkdctmfsgrqz...@forum.dlang.org... How is it really different? Both require external tool, both are available via prebuilt windows binary. At least you can build GNU one yourself. Because I already have to install dmc and dm make comes with that. Not really. I personally used msvcc when investigating dmd failures on Windows and was forced to download dmc only for dmake. I don't think it is uncommon.
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 03:11:29PM +, Chris via Digitalmars-d wrote: [...] be used. All I'm saying is that sometimes unit tests are sold as the be all end all anti-bug design. I'm not sure where you heard that from, but even the name itself should already have given it away -- it's *unit* testing, not global testing. Even in the best, most ideal case, you can only prove things about that *unit* of code, it says nothing about what happens when you put them together to form the entire system. There are many ways to put perfectly-functioning components together that results in a malfunctioning system. Also, while unittests do help to catch many bugs, it's certainly not an anti-bug design. There is no such thing! As we all (should) know, there is no such thing as a bug-free system. The best you can do is to reduce the total number of bugs; by their very nature, complex systems are far too complex for us to fully weed out every possible failure. Anyone selling this or that methodology as the be-all and end-all of solving your bug woes is merely pandering snake oil. :-D I think they should be used sensibly not everywhere. Certainly. T -- I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 03:57:14PM +, Chris via Digitalmars-d wrote: On Friday, 5 December 2014 at 15:49:13 UTC, eles wrote: On Friday, 5 December 2014 at 13:56:27 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Dec 05, 2014 at 11:53:10AM +, Chris via Digitalmars-d wrote: At my day job, you'd be shocked to know how many times things flat-out break in the nastiest, most obvious ways, yet people DO NOT EVEN NOTICE QA has developed this bad habit of only testing the feature they were asked to test, and the developers have become complacent over time and blindly trusting that QA has done their job, That's not trust or complaceny. That's a worldwide conspiracy to ensure good paid jobs for poor programmers testers like us... Programmers get paid for fixing bugs they have introduced themselves. :-) Ah yes, the good ole Make Work Project, subcontracted under Job Securities Inc.. Reminds me of my first job, where there were severe performance problems with the system, and then we go in and find blatantly obvious ways of improving it, like replacing O(n^2) algorithms with a trivial O(n) ones, etc.. At one point we joked that sleep()'s were deliberately added to the code so that later when the customer complains about performance we just comment them out one at a time. :-P Hey, it ensures customers keep coming back to us, right? T -- It's amazing how careful choice of punctuation can leave you hanging:
Re: D Meetup in SF?
I'm also down for a SF meetup. TBH, I haven't written much D lately (game developer), but I'd love to participate.
Re: Do everything in Java…
JEE is the evolution of distributed CORBA applications in the enterprise, with .NET enterprise applications being the evolution of DCOM. Both games that C++ lost its place at. What about zeromq with C++ or even resorting to simple internal REST protocols. I've yet to see a valid argument that DCOM (not sure about COBRA) offer a tangible benefit over simpler approaches. Thoughts?
Re: Do everything in Java...
On Thu, Dec 4, 2014 at 6:12 AM, via Digitalmars-d digitalmars-d@puremagic.com wrote: For speed... I dunno. In the cloud you can run Python on 10 instances with little effort, But if a single instance suffices, why would you? Probably not a popular opinion, but we should think more about resources and power usage, even if they're cheap. Convenience is not everything. As engineers, we have duties and responsibilities toward the community and the environment. I am not a fan at the throw-servers-at-it-until-it-works approach.
Re: Do everything in Java…
On Fri, 2014-12-05 at 05:12 -0800, H. S. Teoh via Digitalmars-d wrote:
On Fri, Dec 05, 2014 at 04:49:02AM +0200, ketmar via Digitalmars-d wrote:
On Fri, 05 Dec 2014 02:39:49 +
deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote:
[...]
Also relevant:
http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application
i didn't make it past the contents. too hard for silly me.
Whoa. Thanks for the link -- I was actually at some point considering
maybe to get into the Java field instead of being stuck with C/C++ at
work, but after reading that page, I was completely dispelled of the
notion. I think I would lose my sanity after 5 minutes of clicking
through those endless submenus, typing out XML by hand (argh), and
writing 50 pages of Java legalese and setting up 17 pieces of
scaffolding just to get a Hello World program to run. Whoa! I think I
need therapy just skimming over that page. This is sooo over-engineered
it's not even funny. For all their flaws, C/C++ at least doesn't require
that level of inanity...
But of course, if I could only write D at my job, that'd be a whole lot
different... :-P
Hopefully this all being stated in jest since anyone considering using
JavaEE for a Hello World micro-service is either trying to introduce
people to the JavaEE workflow for big applications or has a deep agenda,
possibly involving Spring Boot or general hatred of Java.
As a counter example let us consider Ratpack where the complete Hello
World micro-service (*) is coded as.
get(/) {
Hello, World!
}
(*) This term is now mandatory for fashion reasons.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: D Meetup in SF?
http://www.meetup.com/D-Lang-Sillicon-Valley in Sunnyvale. First meeting in Jan., and then every 6 weeks Room holds 2 - 500, sponsored by Apakau Looking for co-organizers to meet w/ ahead of first meeting. I can go over a step by step of setting up Eclipse, DUB, vibe-D at fist meeting and take it from there.
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 07:52:24PM +, Russel Winder via Digitalmars-d wrote:
On Fri, 2014-12-05 at 05:12 -0800, H. S. Teoh via Digitalmars-d wrote:
On Fri, Dec 05, 2014 at 04:49:02AM +0200, ketmar via Digitalmars-d wrote:
On Fri, 05 Dec 2014 02:39:49 +
deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote:
[...]
Also relevant:
http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application
i didn't make it past the contents. too hard for silly me.
Whoa. Thanks for the link -- I was actually at some point
considering maybe to get into the Java field instead of being stuck
with C/C++ at work, but after reading that page, I was completely
dispelled of the notion. I think I would lose my sanity after 5
minutes of clicking through those endless submenus, typing out XML
by hand (argh), and writing 50 pages of Java legalese and setting up
17 pieces of scaffolding just to get a Hello World program to run.
Whoa! I think I need therapy just skimming over that page. This is
sooo over-engineered it's not even funny. For all their flaws, C/C++
at least doesn't require that level of inanity...
But of course, if I could only write D at my job, that'd be a whole
lot different... :-P
Hopefully this all being stated in jest since anyone considering using
JavaEE for a Hello World micro-service is either trying to introduce
people to the JavaEE workflow for big applications or has a deep
agenda, possibly involving Spring Boot or general hatred of Java.
It's not so much jest as hyperbole. :-) While I'm sure J2EE (or
whatever the correct acronym is these days) has its uses, otherwise it
would quickly cease to exist, it violates the principle of easy things
being easy and hard things being possible. No doubt it makes hard things
possible, but easy things require an incommensurate amount of effort.
That, and the general tendency of Java platforms to require a whole
infrastructure of external configuration files and assorted
paraphrenelia makes me think twice about stepping in that direction.
Surely there are less tedious ways of accomplishing the same thing!
As a counter example let us consider Ratpack where the complete Hello
World micro-service (*) is coded as.
get(/) {
Hello, World!
}
Yes, and *that* would be what I'd call easy things are easy, and hard
things are possible. Well, I don't have direct evidence of the latter
half of the statement, but I'm giving the benefit of the doubt here. :-)
On a more serious note, the fact that these alternatives to heavy-weight
Java web application platforms are springing up suggests that perhaps my
evaluation of J2EE (or whatever it's properly called) may not be
completely off-base. No matter how much you try to alleviate the tedium
by having fancy IDEs auto-generate everything for you, there's something
about simplicity that attracts people. K.I.S.S., and all that. :-)
(*) This term is now mandatory for fashion reasons.
[...]
This statement makes one suspect that perhaps there is some truth to
Nick Sabalausky's hyperbole about fashion designers posing as software
engineers. ;-)
T
--
Once the bikeshed is up for painting, the rainbow won't suffice. -- Andrei
Alexandrescu
Re: Do everything in Java…
On 12/5/2014 1:27 AM, Paulo Pinto wrote: Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. I write unit tests with the goal of exercising every line of code. While one can argue that that doesn't really test what the code is supposed to be doing, my experience is that high coverage percentages strongly correlate with few problems down the road.
Re: Do everything in Java...
On Fri, Dec 05, 2014 at 11:41:28AM -0800, Ziad Hatahet via Digitalmars-d wrote: On Thu, Dec 4, 2014 at 6:12 AM, via Digitalmars-d digitalmars-d@puremagic.com wrote: For speed... I dunno. In the cloud you can run Python on 10 instances with little effort, But if a single instance suffices, why would you? Probably not a popular opinion, but we should think more about resources and power usage, even if they're cheap. Convenience is not everything. As engineers, we have duties and responsibilities toward the community and the environment. I am not a fan at the throw-servers-at-it-until-it-works approach. I agree. It's not just about conservation of resources and power, though. It's also about maximizing the utility of our assets and extending our reach. If I were a business and I invested $10,000 in servers, wouldn't I want to maximize the amount of computation I can get from these servers before I need to shell out money for more servers? There are also certain large computational problems that basically need every last drop of juice you can get in order to have any fighting chance to solve them. In such cases you'd want to get as far as possible in refining approximate (or partial) solutions before giving up. If it were up to me, I'd want to squeeze every last drop out of every last server I can ever afford to buy, since otherwise I might not be able to go as far as I could have due to too many resources being wasted on unnecessary or inefficient processes. But apparently, in these days of economic downturn, we are still wallowing in enough cash that throwing more servers at the problem is still a viable business strategy, and not maximizing what we can get given what we have is an acceptable compromise. *shrug* T -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth
Re: Do everything in Java…
On 12/5/2014 8:36 AM, H. S. Teoh via Digitalmars-d wrote: As with all things, I'm skeptical of blindly applying some methodology even when it's not applicable or of questionable benefit. In general I agree with you, but for unittests a methodology of using it with a coverage analyzer to ensure all code paths are executed is extremely effective. I just found two bugs in dmd's lexer.c merely by writing tests to cover unexercised code. https://github.com/D-Programming-Language/dmd/pull/4191
Re: Do everything in Java…
On 12/5/2014 5:41 AM, H. S. Teoh via Digitalmars-d wrote: As for GUI code, I've always been of the opinion that it should be coded in such a way as to be fully scriptable. GUI's that can only operate when given real user input has failed from the start IMO, because not being scriptable also means it's non-automatable (crippled, in my book), but more importantly, it's not auto-testable; you have to hire humans to sit all day repeating the same sequence of mouse clicks just to make sure the latest dev build is still working properly. That's grossly inefficient and a waste of money spent hiring the employee. A complementary approach is to have the UI code call semantic routines that are in non-UI code, and those semantic routines do all the semantic work. That minimizes the UI code, and hence the testing problem. Most GUI apps I've seen mixed up all that code together.
Re: Do everything in Java…
On Friday, 5 December 2014 at 20:25:49 UTC, Walter Bright wrote: On 12/5/2014 1:27 AM, Paulo Pinto wrote: Just because code has tests, doesn't mean the tests are testing what they should. But if they reach the magical percentage number then everyone is happy. I write unit tests with the goal of exercising every line of code. While one can argue that that doesn't really test what the code is supposed to be doing, my experience is that high coverage percentages strongly correlate with few problems down the road. I imagine you haven't seen unit tests written by off-shore contractors For example, you can have coverage without asserts.
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 12:35:50PM -0800, Walter Bright via Digitalmars-d wrote: On 12/5/2014 8:36 AM, H. S. Teoh via Digitalmars-d wrote: As with all things, I'm skeptical of blindly applying some methodology even when it's not applicable or of questionable benefit. In general I agree with you, but for unittests a methodology of using it with a coverage analyzer to ensure all code paths are executed is extremely effective. I just found two bugs in dmd's lexer.c merely by writing tests to cover unexercised code. https://github.com/D-Programming-Language/dmd/pull/4191 Yes, and earlier this week I found a bug in version.c just by trying to increase code coverage with test cases. :-) The kind of blind application of methodology I had in mind was more along the lines of OK so I'm required to write unittests for everything, so let's just pad the tests with inane stuff like 1+1==2, or testing that the function's return value equals itself, 'cos it's Friday afternoon and I wanna go home. T -- Hi. 'Lo.
Re: Do everything in Java…
On Friday, 5 December 2014 at 18:46:12 UTC, Jonathan wrote: JEE is the evolution of distributed CORBA applications in the enterprise, with .NET enterprise applications being the evolution of DCOM. Both games that C++ lost its place at. What about zeromq with C++ or even resorting to simple internal REST protocols. I've yet to see a valid argument that DCOM (not sure about COBRA) offer a tangible benefit over simpler approaches. Thoughts? I am yet to enconter any project using zeromq. The whole issue is the infrastructure you can get from such eco-systems for large scale deployments. For example, you a standard way across multiple operating systems to: - message queues, including mainframe systems - monitoring - scheduling - user security, including integration with existing systems and multiple authentication levels - database drivers - package aplications and deliver them across the cluster - load balancing schemes - web development frameworks - batch processing - orms - meta-programming - cluster based cache systems - web apis In C++ you would need to cherry pick different sets of libraries, without guarantees of compatibilities across them, with different semantics. And they still wouldn't cover the whole functionality. Then you will be fighting with compilation times, memory errors and so on. -- Paulo
Re: DIP69 - Implement scope for escape proof references
On 12/5/2014 7:27 AM, Steven Schveighoffer wrote: Can someone who knows what this new feature is supposed to do give some Ali Çehreli-like description on the feature? Basically, let's strip out the *proof* in the DIP (the how it works and why we have it), and focus on how it is to be used. I still am having a hard time wrapping my head around the benefits and when to use scope, scope ref, why I would use it. I'm worried that we are adding all this complication and it will confuse the shit out of users, to the point where they won't use it. The tl;dr version is when a declaration is tagged with 'scope', the contents of that variable will not escape the lifetime of that declaration. It means that this code will be safe: void foo(scope int* p); p = malloc(n); foo(p); free(p); The rest is all the nuts and bolts of making that work.
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 12:44:17PM -0800, Walter Bright via Digitalmars-d wrote: On 12/5/2014 5:41 AM, H. S. Teoh via Digitalmars-d wrote: As for GUI code, I've always been of the opinion that it should be coded in such a way as to be fully scriptable. GUI's that can only operate when given real user input has failed from the start IMO, because not being scriptable also means it's non-automatable (crippled, in my book), but more importantly, it's not auto-testable; you have to hire humans to sit all day repeating the same sequence of mouse clicks just to make sure the latest dev build is still working properly. That's grossly inefficient and a waste of money spent hiring the employee. A complementary approach is to have the UI code call semantic routines that are in non-UI code, and those semantic routines do all the semantic work. That minimizes the UI code, and hence the testing problem. Most GUI apps I've seen mixed up all that code together. Agreed, but that doesn't address the problem of how to test the GUI code itself. Modern GUIs are complicated beasts, even in non-semantic code, and, judging by my admittedly limited experience with GUIs, they sorely need to be more thoroughly tested. I had to implement a drag-n-drop function in Javascript once, and the thing was one big convoluted mess, even after excluding the semantic part (which in this case is trivial). It left me really longing to have some kind of unittest framework to verify that later code changes won't break that fragile tower of cards, but alas, we didn't have any such framework available. T -- Try to keep an open mind, but not so open your brain falls out. -- theboz
Re: Do everything in Java…
On Fri, Dec 05, 2014 at 08:43:02PM +, paulo pinto via Digitalmars-d wrote:
On Friday, 5 December 2014 at 20:25:49 UTC, Walter Bright wrote:
On 12/5/2014 1:27 AM, Paulo Pinto wrote:
Just because code has tests, doesn't mean the tests are testing what
they should. But if they reach the magical percentage number then
everyone is happy.
I write unit tests with the goal of exercising every line of code.
While one can argue that that doesn't really test what the code is
supposed to be doing, my experience is that high coverage percentages
strongly correlate with few problems down the road.
I imagine you haven't seen unit tests written by off-shore
contractors
For example, you can have coverage without asserts.
Exactly!!
auto func(...) { ... }
unittest {
auto x = func(...); // woohoo, I got me some test coverage!
} // haha, nobody would even notice when it fails!
T
--
Questions are the beginning of intelligence, but the fear of God is the
beginning of wisdom.
Re: Do everything in Java...
On Friday, 5 December 2014 at 20:32:54 UTC, H. S. Teoh via Digitalmars-d wrote: I agree. It's not just about conservation of resources and power, though. It's also about maximizing the utility of our assets and extending our reach. If I were a business and I invested $10,000 in servers, wouldn't I want to maximize the amount of computation I can get from these servers before I need to shell out money for more servers? Those $10,000 in servers is a small investment compared to the cost of the inhouse IT department to run them… Which is why the cloud make sense. Why have all that unused capacity inhouse (say 90% idle over 24/7) and pay someone to make it work, when you can put it in the cloud where you get load balancing, have a 99,999% stable environment and can cut down on the IT staff? There are also certain large computational problems that basically need every last drop of juice you can get in order to have any fighting chance to solve them. Sure, but then you should run it on SIMD processors (GPUs) anyway. And if you only run a couple of times a month, it still makes sense to run it on more servers using map-reduce in the cloud where you only pay for CPU time. The only situation where you truly need dedicated servers is where you have real time requirements, a constant high load or where you need a lot of RAM because you cannot partition the dataset.
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 6:56 PM, deadalnix wrote:
On Friday, 5 December 2014 at 00:32:32 UTC, Walter Bright wrote:
On 12/4/2014 3:04 PM, deadalnix wrote:
So as mentioned, there are various problem with this DIP :
- rvalue are defined as having a scope that goes to the end of the statement.
That mean they can never be assigned to anything as per spec.
I don't believe this is correct. Rvalues can be assigned, just like:
__gshared int x;
{ int i; x = i; }
i's scope ends at the } but it can still be assigned to x.
It work even better when i has indirections.
I understand what you're driving at, but only a scoped rvalue would not be
copyable.
- It add more special casing with (as if it wasn't enough of a mess with
@property, optional () and the fact the function aren't first class). For
instance *e has infinite lifetime when (*e) is lifetime(e).
That's right. I know you're worried about that, but I still don't see it as an
actual problem. (The optimizer makes use of this special case all the time.)
Yes, this is the job of the optimizer to do this kind of stunt.
Not the semantic analysis.
I don't see any other way, nor do I see the practical problem.
I originally had scope only apply to ref, but that made having scoped classes
impossible.
Promoting scoped class on stack is an ownership problem, and out
of scope (!). It make sense to allow it as an optimization.
Problem is, lifetime goes to infinite after indirection, so I'm
not sure what the guarantee is.
The guarantee is there will be no references to the class instance after the
scoped class goes out of scope.
During discussion, I proposed to differentiate lifetime calculation between
lvalues and rvalues (which are inherently different beasts with different
lifetime) and carry (or not) the scope flag with each expression.
I'm not sure how that would be different from the DIP as it stands now.
I cause everything reached through the view to be scope and
obliviate the need for things like (*e) having special meaning.
Are you suggesting transitive scope?
r/rust and DIP69
Thought this might be interesting: http://www.reddit.com/r/rust/comments/2od8a8/ds_proposal_for_escapeproof_references_with_some/
std::string responsible for half the allocations in chrome
http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] .
Re: std::string responsible for half the allocations in chrome
On Fri, Dec 05, 2014 at 10:03:38PM +, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Yeah!!! String processing totally sucks in C/C++, even with clever tricks like ropes for std::string. Having said that, though, D's immutable(char)[] isn't panacea either. I've seen (well, written... *hangs head in shame*) D code that deals with const(char)[] and needs to produce string, and as a result is a bit too trigger-happy with .idup's. Causes lots of GC slowdown. It used to be that you could just grep for idup to find the problem spots, but nowadays with the to!string idiom, many of these idups could be masked behind a nice to!string (which is harmless if the source is already string, but it's not always immediately obvious at a glance). T -- Music critic: That's an imitation fugue!
Re: Do everything in Java...
On Friday, 5 December 2014 at 21:21:49 UTC, Ola Fosheim Grøstad wrote: The only situation where you truly need dedicated servers is where you have real time requirements, a constant high load or where you need a lot of RAM because you cannot partition the dataset. Btw, in most cases the last point does not apply. Compute Engine has a 16core/104GB option and I would be surprised if Azure and Amazon doesn't have a similar offer. You pay for at least 10 minutes and after that per minute at 0.8-1.2 USD/hour. So if the computation has to run for 30 minutes on 30 instances (Approx. the cpu power of 480 sandy bridge cores and 3 TB RAM) it will cost you ~18USD.
Re: Do everything in Java…
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via Digitalmars-d wrote: It's an argument for Java over Python specifically but a bit more general in reality. This stood out for me: !…other languages like D and Go are too new to bet my work on. http://www.teamten.com/lawrence/writings/java-for-everything.html My problems with java: no unsigned ints primitive are passed by value; arrays and user defined types are passed by reference only (killing memory usage) no operator overloading(looks at java.util.ArrayList) no templates no property syntax(getters and setters are used instead even if you know the field is never going to be dynamic) only and exactly one class per file(ALL THE IMPORTS) every thing must be inside a class(globals and free functions are static fields in a class) This is all i can remember.
Re: Need help deciphering posix.mak
05-Dec-2014 03:02, Trent Forkert пишет: On Thursday, 4 December 2014 at 19:52:12 UTC, Dmitry Olshansky wrote: 04-Dec-2014 18:32, Dicebot пишет: Please no additional 3d-party dependencies for D core tool stack. What are current 3rd-party deps? Dependency on DMC make and compiler is already there, GNU make is not installed by default on FreeBSD. What would you suggest we do? Do what many large open source projects do: support multiple build systems. There is no reason that the addition of SCons/CMake build files to DMD would require the removal of the existing makefiles. It just means somebody has to do a little maintenance when source files are added/removed/renamed. There is no point in having to maintain both. The whole idea to use other (sane) build system instead of make and so far (to me) CMake seems like the best option because it generates next to anything else. D is unique in its schizophrenic tendency to try hard and no have dependencies only to introduce some subtle and stupid ones. For instance, out-dated zlib is hard-wired, curl is bundled separately on Windows and needs special library version of it on Linux (AFAIK), and lastly we need C++ compiler and specifically GLIBC on Linux. Thousands of projects use CMake, likewise SCons. It's an arbitrary choice to support DM make and GNU make: apt-get install build-esential is nowhere harder then apt-get install scons or apt-get cmake for that matter. Downloading DMC++ is nowhere harder then downloading SCons or CMake. In both cases one needs to adjust PATH. Building OpenSource software on Windows was (and still is) a PITA for most Windows developers because they don't even know about console, PATH and how compiler actually is invoked. NOTHING is going to change that, MS made sure developers don't look into console at all costs. -- Dmitry Olshansky
Re: Need help deciphering posix.mak
05-Dec-2014 04:47, Daniel Murphy пишет: H. S. Teoh via Digitalmars-d wrote in message news:mailman.2688.1417735514.9932.digitalmar...@puremagic.com... What would you suggest we do? Write a build script in D? +1. I mean, a D compiler is an additional dependency, but it's one we're already planning to add for dmd. Well I might do just that once I complete my SCons proof of concept. Do I take it right that nobody would be opposed to a D build tool (somewhat dumb but no worse then makefiles) ? -- Dmitry Olshansky
Re: Need help deciphering posix.mak
On Sat, Dec 06, 2014 at 01:34:20AM +0300, Dmitry Olshansky via Digitalmars-d wrote: 05-Dec-2014 04:47, Daniel Murphy пишет: H. S. Teoh via Digitalmars-d wrote in message news:mailman.2688.1417735514.9932.digitalmar...@puremagic.com... What would you suggest we do? Write a build script in D? +1. I mean, a D compiler is an additional dependency, but it's one we're already planning to add for dmd. Well I might do just that once I complete my SCons proof of concept. Do I take it right that nobody would be opposed to a D build tool (somewhat dumb but no worse then makefiles) ? [...] Not only I'm not opposed to it, I'd welcome it. Especially if it can be made generic and work with other projects. (In the future, of course, that's a bit too ambitious to shoot for that in an initial stab at it.) T -- If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Re: Do everything in Java?
On Friday, 5 December 2014 at 08:08:13 UTC, Ola Fosheim Grøstad wrote: On Friday, 5 December 2014 at 07:33:21 UTC, Shammah Chancellor wrote: On 2014-12-04 14:12:32 +, Ola Fosheim Grøstad said: I did not find that odd, they are not perceived as stable and proven. Go is still working on finding the right GC solution. There are quite a few companies using Go in production. Yes, but I will not consider Go ready for production until they are out of Beta on Google App Engine. Google has to demonstrate that they believe in the capability of their own language ;-). https://cloud.google.com/appengine/docs/go/ Go is more mature than D. They have at least 2 implementation and well fleshed out specs. Granted, it is easier in Go as the language is smaller.
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 1:32 PM, Steven Schveighoffer wrote:
On 12/4/14 3:58 PM, Walter Bright wrote:
On 12/4/2014 7:25 AM, Steven Schveighoffer wrote:
int* bar(scope int*);
scope int* foo();
bar(foo()); // Ok, lifetime(foo()) lifetime(bar())
I'm trying to understand how foo can be implemented in any case. It
has no scope
ints to return, so where does it get the int from?
Could be from a global variable. Or a new'd value.
Well, OK, but why do that?
Why would a programmer do that? I often ask that question! But the language
allows it, therefore we must support it.
I don't see where the proposal defines what exactly can be returned
via scope.
The scope return value does not affect what can be returned. It affects
how that return value can be used. I.e. the return value cannot be used
in such a way that it escapes the lifetime of the expression.
I assumed the scope return was so you could do things like:
scope int *foo(scope int *x)
{
return x;
}
which would be fine, I assume, right?
No. A scope parameter means the value does not escape the function. That means
you can't return it.
My question was about how this kind of allows declaring a ref variable in the
middle of a function, which was never allowed before.
There's no technical reason it is disallowed - it's just that I didn't see a
point to it.
