Re: The Computer Language Benchmarks Game
On Tuesday, 9 August 2016 at 03:21:37 UTC, Chris Wright wrote: My impression of Go is that it has good production quality. go is... not a very good language. it doesn't matter how good the compiler is if language is... mediocre.
Re: The Computer Language Benchmarks Game
On 8/8/2016 8:02 PM, Emre Temelkuran wrote: If you don't do it, you will suffer the consequences. Don't threaten people here, even in jest.
Re: The Computer Language Benchmarks Game
On Mon, 08 Aug 2016 19:26:25 +, Meta wrote: > On Monday, 8 August 2016 at 17:16:52 UTC, H. S. Teoh wrote: >> I have never understood how popularity has anything to do with quality. > > It isn't; see: Javascript, Go. The only thing we have to understand is > that how popular people perceive a language to be affects whether or not > they will use it. My impression of Go is that it has good production quality. It's got pretty good tooling for its age, and you're unlikely to encounter an internal compiler error. Popularity *tends* to bring that sort of quality with it -- a language or framework that's widely used will likely be used by a company that can afford to put significant resources behind it. Popularity draws more eyes to expose problems and volunteers to fix bugs. In D land, a lot of us did without for a fair few years. But these days, things are getting a lot better.
Re: The Computer Language Benchmarks Game
On Monday, 8 August 2016 at 22:53:48 UTC, Isaac Gouy wrote: On Monday, 8 August 2016 at 17:11:54 UTC, Meta wrote: Despite the fact that comparing benchmarks across languages tells you very little about how "fast" that language is … Doing so would at-least offer something for people to consider. Mr. Isaac it's the last warning to you from the community of Ionian Kingdom, i want to see D lang listed in https://benchmarksgame.alioth.debian.org/ . If you don't do it, you will suffer the consequences.
Re: move std.{ascii, base64, utf} to a new encoding package
On Monday, August 08, 2016 19:42:50 Seb via Digitalmars-d wrote: > Hi all, > > today Johannes and I had a short discussion on Github about > > std.base64. I think his post is a good summary of the status quo: > > base64 shouldn't be a top level module though, moving it to a > > new package std.encoding may be a good idea. std.base64 is just > > quite old and when it was written we didn't use subpackages in > > phobos yet. std.utf and std.ascii are also encodings and could > > be moved to std.encoding as well, AFAICS. And we also have a > > std.encoding module which should be part of the same package. > > That being said I know that such housekeeping isn't liked a lot, > but with `public import` we can very easily mitigate breakage and > allow a long deprecation period. > What's your opinion on this? Any major objections? > > Cheers, > > Seb > > [1] > https://github.com/dlang/phobos/pull/4720#issuecomment-238348553 std.encoding needs a complete overhaul. Unfortunately, while I think that that's generally agreed upon, no one has stepped up to do it. So, who knows when it'll be fixed. However, given that std.encoding needs an overhaul, I don't seem much point in moving stuff into it. While it may not be ideal, base64 works where it is, and we can worry about moving it when std.encoding is revamped. If we changed it now and then changed it again when std.encoding got overhauled, then we'd end up breaking code twice just to move a function around. - Jonathan M Davis
Re: The Computer Language Benchmarks Game
On Monday, 8 August 2016 at 17:11:54 UTC, Meta wrote: Despite the fact that comparing benchmarks across languages tells you very little about how "fast" that language is … Doing so would at-least offer something for people to consider.
Re: move std.{ascii, base64, utf} to a new encoding package
On Monday, 8 August 2016 at 19:42:50 UTC, Seb wrote: ... Also see https://github.com/dlang/phobos/pull/4599 for more discussion on why std.encoding's current design is problematic, and why it should probably be redesigned.
Re: move std.{ascii, base64, utf} to a new encoding package
On Monday, 8 August 2016 at 19:42:50 UTC, Seb wrote: Hi all, today Johannes and I had a short discussion on Github about std.base64. I think his post is a good summary of the status quo: base64 shouldn't be a top level module though, moving it to a new package std.encoding may be a good idea. std.base64 is just quite old and when it was written we didn't use subpackages in phobos yet. std.utf and std.ascii are also encodings and could be moved to std.encoding as well, AFAICS. And we also have a std.encoding module which should be part of the same package. That being said I know that such housekeeping isn't liked a lot, but with `public import` we can very easily mitigate breakage and allow a long deprecation period. What's your opinion on this? Any major objections? Cheers, Seb [1] https://github.com/dlang/phobos/pull/4720#issuecomment-238348553 They're all related to encoding but they don't have a proper common interface like std.digest or std.experimental.allocators I think it would be justified for something like std.encoding.variable_length_quantity std.encoding.z85 std.encoding.base64 std.encoding.base32 std.encoding.base16 etc... with an uniform API (decode, encode, + specialized helpers) I you do it as the modules are now it's gonna look like the content of a girl bag because of no uniform API. In short I'm against unless a serious work is done on the API, otherwise it's just a crappy useless refactoring.
move std.{ascii, base64, utf} to a new encoding package
Hi all, today Johannes and I had a short discussion on Github about std.base64. I think his post is a good summary of the status quo: base64 shouldn't be a top level module though, moving it to a new package std.encoding may be a good idea. std.base64 is just quite old and when it was written we didn't use subpackages in phobos yet. std.utf and std.ascii are also encodings and could be moved to std.encoding as well, AFAICS. And we also have a std.encoding module which should be part of the same package. That being said I know that such housekeeping isn't liked a lot, but with `public import` we can very easily mitigate breakage and allow a long deprecation period. What's your opinion on this? Any major objections? Cheers, Seb [1] https://github.com/dlang/phobos/pull/4720#issuecomment-238348553
Re: The Computer Language Benchmarks Game
On Monday, 8 August 2016 at 17:16:52 UTC, H. S. Teoh wrote: On Mon, Aug 08, 2016 at 05:11:54PM +, Meta via Digitalmars-d wrote: [...] Despite the fact that comparing benchmarks across languages tells you very little about how "fast" that language is, people still routinely ask why D isn't represented and then conclude that it can't be that popular of a language or worth their time. I have never understood how popularity has anything to do with quality. T It isn't; see: Javascript, Go. The only thing we have to understand is that how popular people perceive a language to be affects whether or not they will use it.
Re: The Computer Language Benchmarks Game
On Mon, Aug 08, 2016 at 05:11:54PM +, Meta via Digitalmars-d wrote: [...] > Despite the fact that comparing benchmarks across languages tells you > very little about how "fast" that language is, people still routinely > ask why D isn't represented and then conclude that it can't be that > popular of a language or worth their time. I have never understood how popularity has anything to do with quality. T -- Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright
Re: The Computer Language Benchmarks Game
On Monday, 8 August 2016 at 16:37:27 UTC, Isaac Gouy wrote: On Monday, 8 August 2016 at 00:44:46 UTC, Walter Bright wrote: On 8/7/2016 10:53 AM, Isaac Gouy wrote: Rather than only being dismissive, How did you get from Yeah, I wouldn't bother with it, either. to If you've changed your mind about putting D back on the site, we'd be happy to help. ? Despite the fact that comparing benchmarks across languages tells you very little about how "fast" that language is, people still routinely ask why D isn't represented and then conclude that it can't be that popular of a language or worth their time.
Re: The Computer Language Benchmarks Game
On Monday, 8 August 2016 at 00:44:46 UTC, Walter Bright wrote: On 8/7/2016 10:53 AM, Isaac Gouy wrote: Rather than only being dismissive, How did you get from Yeah, I wouldn't bother with it, either. to If you've changed your mind about putting D back on the site, we'd be happy to help. ?
Re: The Computer Language Benchmarks Game
On Monday, 8 August 2016 at 00:15:09 UTC, jmh530 wrote: I think he's referring to a HPC cluster running chapel vs. C++ versions of programs. Let's not speculate about Russel Winder's comment. The advantage to Chapel is its simplicity and expressiveness. That does seem to be the selling point -- even with tiny tiny benchmarks game programs.
Re: [DIP] In-place struct initialization
On Monday, 8 August 2016 at 09:57:38 UTC, Cauterite wrote: On Friday, 5 August 2016 at 07:04:55 UTC, deadalnix wrote: Also, there are nice library solution for named argument already. Which ones do you have in mind? https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d
Re: [DIP] In-place struct initialization
On Friday, 5 August 2016 at 07:04:55 UTC, deadalnix wrote: Also, there are nice library solution for named argument already. Which ones do you have in mind?
Re: I'll be back soon
On Sunday, 7 August 2016 at 18:25:45 UTC, Andrei Alexandrescu wrote: Hello, I've been busy with a paper submission that has a deadline on Wednesday. There have also been some computer troubles along the way. After Wed I should be able to tend to the many open PRs (dog days of the summer these aren't! thanks for the many contributions!), look at GSoC progress, and tend to my own PRs. -- Andrei Jesus, do you never go on holiday?
Re: Is dmd fast?
On Friday, 24 June 2016 at 09:09:49 UTC, Nordlöw wrote: What about adding a flag to DMD that overrides the default name for the linker from `ld` to `ld.gold`? Ping!
