Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 01:47:57 UTC, Walter Bright wrote: The one difference was Go's support for green threads. There's no technical reason why D can't have green threads, it's just that nobody has written the library code to do it. Go can move stacks and extend them. Go is closer to having a low latency GC. These are not small language issues for D.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 04:05:30 UTC, Laeeth Isharc wrote: Programming is - for now - still a human activity, and what is important in human activities may not always be measured, and what may be easily measured is not always important. That doesn't mean one should throw away the profiler and go back to guessing, but it does suggest caution about adopting the prestigious techniques of the natural sciences and applying them to a domain where they don't necessarily fully belong. What is almost always important is: 1. to be able to ship the product in a predictable fashion 2. not go 300-400% over budget 3. being able to train new people to maintain it in reasonable time 4. being able to add new unexpected features to the code base on request Perl is a very expressive and productive language. And you can write maintainable software in it if you have discipline. In the real world Perl tends to lead to an unmaintainable mess with the average programmer.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/26/2015 11:40 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Go can move stacks and extend them. That has no value on 64 bit systems, and is not a language issue (it's an implementation issue). Go is closer to having a low latency GC. I.e. it doesn't have one. These are not small language issues for D. GC issues are library issues, not language issues.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote: I think the way go handles interfaces and their composition would require a few tricks in D and C++, but I am sure it can be done. Interfaces can be done with D templates. It'll be compile time polymorphism rather than run time, but the same effect will result (and of course it'll be faster). It's pretty much how Ranges work in D. Aren't green threads now given the label fibres? My understanding of fibers is they are all in one thread. Go's green threads can be in multiple threads, the same thread, and even moved from one thread to another. And I think Vibe.d has an implementation for these – but I do not know for certain. I don't know, either. D needs to corral all the bits, which I think are there, to create a good offering. Yes. However, I cannot see this happening purely on volunteer, hobbyist resource. We need to find an organization or three willing to resource this activity. I don't think it's that hard of a problem.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 09:44:27 UTC, Walter Bright wrote: On 3/27/2015 1:41 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote: The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages. http://wiki.osdev.org/Page_Tables So what? The point is there is PLENTY of virtual address space. You can allocate absurd amounts of address space for each goroutine, and still have plenty without physically moving anything. If you don't care about performance, bloated page tables and laying waste to memory: 1. Page tables are hierarchical, to save space nodes can point back to themselves. IFF the node is similar. Throwing shit all over the memory space makes this impossible. So you get BLOATed page tables. 2. All dirty pages maps to physical memory. So one recursion chain on a fiber will create a big physical mem allocation. To get rid of it you would have make a slow syscall. 3. You have no way to go below the page size for a stack. 4. Operating system calls like mmap are slow. 5. Trapped pages are slow and so are modifying page tables. 6. You cannot expect to get more than 47-53 bits of address space from the OS. It's not like 64 bits CPUs provide 64 bits address space. There is a big hole in the middle. Have you actually thought about these issues or done performance tests?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Fri, 2015-03-27 at 03:11 -0700, Walter Bright via Digitalmars-d-announce wrote: On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote: […] However, I cannot see this happening purely on volunteer, hobbyist resource. We need to find an organization or three willing to resource this activity. I don't think it's that hard of a problem. If no-one is resourced to write the code, it will not get written. -- 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: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Fri, 2015-03-27 at 10:14 +, via Digitalmars-d-announce wrote: […] Have you actually thought about these issues or done performance tests? The Go team certainly have, and have changed their goroutine model twice because of it. No matter what they do in Go 0.0 →1.4, 1.5 onwards will be different since the who system is being revised: Go implemented Go toolchain, new GC, new runtime. I suspect Go 1.6 will be the watershed for this, but that will likely be 2016. The question is though what should happen in D. If Vibe.d fibres are a single threaded system, then they are not suitable for the actor, dataflow, CSP implementation needed in D since that must sit on a kernel thread pool where each lightweight thread is animated by whichever work stealing kernel thread comes along. Erlang, Go, GPars, Quasar, etc. all have different solutions to the problem of thread pools and task switching since the context is all important. -- 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: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 10:37:01 UTC, Russel Winder wrote: The question is though what should happen in D. If Vibe.d fibres are a single threaded system, then they are not suitable for the actor, dataflow, CSP implementation needed in D since that must sit on a kernel thread pool where each lightweight thread is animated by whichever work stealing kernel thread comes along. Erlang, Go, GPars, Quasar, etc. all have different solutions to the problem of thread pools and task switching since the context is all important. Yes, I agree that the question is what should happen in D. But the claim was that D provides everything Go does and there is only a tiny scheduler that is missing. I don't think D benefits from these claims. Benchmark D thoroughly against Go before making claims or just give Go credit for being better in some areas. If it was up to me then co-routines would be ripped out of the language. They are a cross cutting feature that makes significant optimizations and improvements difficult or impossible.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 12:37 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 27 March 2015 at 06:53:01 UTC, Walter Bright wrote: On 3/26/2015 11:40 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Go can move stacks and extend them. That has no value on 64 bit systems, It has. The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. The MMU can map and remap that to physical memory on demand through the address translation tables. Moving stacks is a great solution for 1995 computers.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thu, 2015-03-26 at 18:47 -0700, Walter Bright via Digitalmars-d-announce wrote: On 3/26/2015 12:40 PM, Russel Winder via Digitalmars-d-announce wrote: (Almost) All publicity is good publicity. I attended a presentation at NWCPP on Go last week. I have never written a Go program, so filter my opinion on that. It seems to me that every significant but one feature of Go has a pretty much direct analog in D, i.e. you can write Go code in D much like you can write C code in D. That is almost certainly true. I suspect you can write Go in C++ as well. D and C++ are definitely supersets of Go. The one difference was Go's support for green threads. There's no technical reason why D can't have green threads, it's just that nobody has written the library code to do it. I think the way go handles interfaces and their composition would require a few tricks in D and C++, but I am sure it can be done. Aren't green threads now given the label fibres? And I think Vibe.d has an implementation for these – but I do not know for certain. The dataflow way of working and the special case CSP, also actors are clearly the right abstraction for most parallel computation, using as we all agree, a kernel thread pool animating tasks. std.parallelism has something along these lines but focussed on data parallelism. Given the existence of C++CSP2 (http://www.cs.kent.ac.uk/projects/ofa/c ++csp/) D can get a CSP implementation for free, especially if the recent innovation on C++ working come to fruition. As work on GPars and Quasar in the JVM arena, and Erlang and Go since they were created, show, lightweight processes with communication channels is the next step in providing good abstractions for CPU and IO bound processing. Anthony Williams (Just Software, https://www.justsoftwaresolutions.co.uk/)) has been at work trying to put actors and dataflow on top of C++11 threads, with some success. D needs to corral all the bits, which I think are there, to create a good offering. However, I cannot see this happening purely on volunteer, hobbyist resource. We need to find an organization or three willing to resource this activity. -- 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: DlangUI
On Thursday, 26 March 2015 at 13:48:20 UTC, Chris wrote: On Thursday, 26 March 2015 at 11:47:59 UTC, Vadim Lopatin wrote: Try `dub upgrade --force-remove` followed by `dub build --force` For the love of God, please put this on the github page under troubleshooting. It happens quite a lot. Ok. Added following notice to README (you can see it on project main page on GitHub) Important notice If build of your app is failed due to dlangui or its dependencies, probably you have not upgraded dependencies. Try following: dub upgrade --force-remove dub build --force As well, sometimes removing of dub.json.selections can help.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote: The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages. http://wiki.osdev.org/Page_Tables
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 1:41 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote: The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages. http://wiki.osdev.org/Page_Tables So what? The point is there is PLENTY of virtual address space. You can allocate absurd amounts of address space for each goroutine, and still have plenty without physically moving anything.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 06:53:01 UTC, Walter Bright wrote: On 3/26/2015 11:40 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Go can move stacks and extend them. That has no value on 64 bit systems, It has. and is not a language issue (it's an implementation issue). It is if you cannot control references to the stack. Go is closer to having a low latency GC. I.e. it doesn't have one. Comes in Go 1.5. https://docs.google.com/document/d/1wmjrocXIWTr1JxU-3EQBI6BK6KgtiFArkG47XK73xIQ/preview?sle=true These are not small language issues for D. GC issues are library issues, not language issues. It is a language issue if you want it to perform well.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 08:41:40 UTC, Ola Fosheim Grøstad wrote: tables? If you want to address more than 512GB you need to move to 1MiB pages. Actually, it is 2MiB. Also keep in mind that there is an advantage to having very small stacks (e.g. 1-2K) when you do simulations.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu wrote: https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/ Andrei Downplaying other languages makes the D crowd look desperate... Go has stability, is production ready and has an ecosystem with commercial value. D lacks all of these atm... Not to mention that Go is in GCC for a very long time already... :) I never liked the language much (I think Erlang or Scala are definitely better choices than Go), but it is in a much better shape than D (unless you want to use stable D1).
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 27.03.2015 um 11:11 schrieb Walter Bright: On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote: Aren't green threads now given the label fibres? My understanding of fibers is they are all in one thread. Go's green threads can be in multiple threads, the same thread, and even moved from one thread to another. And I think Vibe.d has an implementation for these – but I do not know for certain. I don't know, either. It has, that is more or less the original selling point. It also keeps an internal thread pool where each thread has a dynamic set of reusable fibers to execute tasks. Each fiber is bound to a certain thread, though, and they have to, because otherwise things like thread local storage or other thread specific code (e.g. the classic OpenGL model, certain COM modes etc.) would break. Apart from these concerns, It's also not clear to me that moving tasks between threads is necessarily an improvement. There are certainly cases where that leads to a better distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses).
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu wrote: https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/ Andrei If Go community is what they believe they are - intelligent. They would not blame D community for this article, but the person who wrote it. - It is not tagged Opinion for no reason !! My personal opinion about the article - people may hate D equally for being too pragmatic. That `source.byLine.join.to!(string);` line for example, takes much longer time to understand than 20 lines of Go code. Any D newbie with knowledge of some modern language will struggle understanding (and being 100% sure that he/she understands!) that line of D code. I could give a big list of things where Go has advantage over D. What I found pathetic is that Go community used list of established open-source projects done in Go. :) But OK, we expected that, did we?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote: Am 27.03.2015 um 11:11 schrieb Walter Bright: On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote: Aren't green threads now given the label fibres? My understanding of fibers is they are all in one thread. Go's green threads can be in multiple threads, the same thread, and even moved from one thread to another. And I think Vibe.d has an implementation for these – but I do not know for certain. I don't know, either. It has, that is more or less the original selling point. It also keeps an internal thread pool where each thread has a dynamic set of reusable fibers to execute tasks. Each fiber is bound to a certain thread, though, and they have to, because otherwise things like thread local storage or other thread specific code (e.g. the classic OpenGL model, certain COM modes etc.) would break. Apart from these concerns, It's also not clear to me that moving tasks between threads is necessarily an improvement. There are certainly cases where that leads to a better distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses). I've always wondered whether thread-local fibers with a stop-the-world (or at least part of the world) load balancer that can move them would be a good model. You could get away without a lot of synchronisation e.g. tls could be fixed-up from the scheduler thread while all the others are stopped. Perhaps there are good reasons why not, I don't know enough to say...
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 03:53:36 UTC, Laeeth Isharc wrote: That kind of articles are bad for the image of the D community Nick S: No. Just...no. I'm honestly *really* tired of general society's (seemingly?) increasing intolerance FOR intolerance. Some things ARE bad. Some ideas are dumb ideas (ie without merit). Some features are bad features. Some products really are crappy products. Calling it out when you see it, using a frank explanation of your reasoning, isn't bad, it's productive. Excellence is incompatible with tolerating mediocrity or what is appalling, and what I have seen is that there are aesthetic aspects to creative endeavours not conventionally thought of as having an aesthetic element, and it is in the nature of such things that one cannot and should not tolerate what one perceives to be ugly in a creative endeavour. If one is driven mostly by ROI rather than high feelings, one doesn't get to excellence. So it is my belief that dealing with creative people means dealing with a certain ... intensity. That (on the aesthetic aspects of technical fields) is not just my opinion, but also (I think) that of a certain Mr W Bright, judging by his comments on how good code should look and on good aircraft design, although he presented this in his usual low-key manner. I was looking for a language that was beautiful, as well as powerful, and for whatever it is worth, this was a factor of high appeal with D. It's also the view of Feynman, not to mention many great minds of the past. Ie it is limiting to insist on data before forming a strong opinion about something (which is not to say that one may not change one's mind in the face of contrary data). You can recognize truth by its beauty and simplicity. When you get it right, it is obvious that it is right—at least if you have any experience—because usually what happens is that more comes out than goes in. ...The inexperienced, the crackpots, and people like that, make guesses that are simple, but you can immediately see that they are wrong, so that does not count. Others, the inexperienced students, make guesses that are very complicated, and it sort of looks as if it is all right, but I know it is not true because the truth always turns out to be simpler than you thought. - Feynman via Wikiquote (but the same idea comes across in his books). To discourage dissent, objections, or complaints is to rob ourselves of potential improvement. *That's* what critique and complaints and objections ARE: Recognition of the potential for improvement. There *cannot* be progress and improvement without first identifying existing faults. If nobody ever identified and voiced criticism of punchcards, for example, we'd all still be stuck in the world of 1950's computing. Excellently put. (And, I would add, a constructive draw towards what is generative - not just fault-finding). It's not as if the D crowd doesn't critique itself and it's own language just plenty, so it's not like there's any hypocrisy here. And I'm certainly not willing to accept that programmers should be viewed as being part of distinct mutually-exclusive factions based on some single-language allegiance. I'm a D guy. I also happen to be a fan of Nemerle. And both languages have things I hate. So scratch the it's the D crowd idea. Interesting - what should I read about Nemerle, and what is it best at ? And seriously, the article in question barely mentions D at all. So no, this is NOT some sort of D community piece attacking another language as some comments seem to imply. It is merely an isolated critique of one language by someone who happens to be *using* the given language. There are some very interesting psychological dynamics in the reaction to this kind of piece. For me it was key that although it was clearly written in a humorous tone, and hurriedly, he seemed to speak from the heart - it is refreshing to see such work even when one doesn't agree with it. BTW since when has linking to something been an endorsement of it? Interesting. Have you read Oscar Wilde? Your comments remind me of him somehow. I was just thinking yesterday how working with D makes me happy whereas working with other (lower) languages makes me grumpy. Going down to the punchcard level (PHP, JS etc.) is boring and doesn't do justice to the human mind. Whenever I use D, I am confident that I can map a complicated reality onto a machine, it inspires me and it challenges me. Primitive languages discourage me. So there's more to productivity than meets the eye when looking at numbers. Numbers are insignificant, they can prove anything you want, and you can tweak them any way you want. Eat shit, a million flies can't be wrong!, as they say. It's one thing to be productive in terms of maintaining and selling apps and another in terms of being innovative. You can sell a million records by sticking to well-trodden
Re: DDT 0.11.0 released (please read!)
On 06/03/2015 17:37, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) Note that there is a tool recently released, Eclipse Optimizer, that can help optimize Eclipse startup time: Also, to improve Eclipse performance and startup time, it is recommended you tweak the JVM parameters. There is a tool called Eclipse Optimizer that can do that automatically, it is recommended you use it. Read more about it http://www.infoq.com/news/2015/03/eclipse-optimizer . (Installing/enabling the JRebel optimization is not necessary as that only applies to Java developers) I've added the above info to the User Guide. Also, because Google Code is shutting down, I've moved the DDT project homepage to: http://ddt-ide.github.io/ -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote: distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses). It is a complete disaster to not move fibers between threads if you want good latency.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 14:18:33 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote: distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses). It is a complete disaster to not move fibers between threads if you want good latency. Only if execution time between fibers is very unevenly distributed and/or their amount is low.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 27.03.2015 um 17:06 schrieb Dicebot: On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad wrote: No... E.g.: On the same thread: 1. fiber A receives request and queries DB (async) 2. fiber B computes for 1 second 3. fiber A sends response. Latency: 1 second even if all the other threads are free. This is a problem of having blocking 1 second computation in same fiber pool as request handlers - broken application design. Hiding that issue by moving fibers between threads is just making things worse. Exactly, the problem will remain there, even with moving fibers around, because you might as well have the same situation in all of the threads at the same time like that. It always makes sense to have dedicated threads for lengthy computations. Apart from that, long computations can call yield() every now and then to avoid this kind of issue in the first place.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:27:48 UTC, Dicebot wrote: I have no interest in arguing with you, just calling out especially harmful lies that may mislead random readers. Nice one. I am sure your attitude is very helpful for D.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:20:28 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 16:09:08 UTC, Chris wrote: It need not be new, it needs to be good. That's all. I don't understand this obsession people have with new things, as if they were automatically good only because they are new. Why not try square wheels? Uh, it's new, you know. New things can be cool for a toy language, but not for a production language. The latter needs polish and support (IDE etc). Just pointed out the social dynamics where Go/D communities are not all that different. There's probably a difference between programmers that juggle 5-7 languages and programmers that stick to 1 language: «it is just A tool among many» vs «it is THE tool». I think you see this expressed in both Go and D communities. I'd say Go fans are worse in this respect (yes, I know, probably not all of them). People in the D community are here, because they have tried at least 5-7 other languages. Go programmers, if Pike's remarks are anything to go by, are probably less experienced (just left school or college) and are more susceptible to Google's propaganda. I'd say they know not better.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 27.03.2015 um 17:31 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com: On Friday, 27 March 2015 at 16:18:33 UTC, Sönke Ludwig wrote: So what happens if 10 requests come in at the same time? Does moving things around still help you? No. Load balancing is probabilistic in nature. Caching also makes it unlikely that you get 10 successive high computation requests. You could say the same for the non-moving case. If you have a fully loaded node and mix request handling and lengthy computations like this, you'll run into this no matter what. The simple solution is to just either separate lengthy computations (easy) or to split them up into shorter parts using yield() (usually easy, too). Caching *may* make it unlikely, but that completely depends on the application. If you have some kind of server-side image processing web service with many concurrent users, you'd have a lot of computation heavy requests with no opportunities for caching. BTW, why would an event driven design be any better? You'd have exactly the same issue. 1. No stack. That reduces the memory footprint, but doesn't reduce latency. 2. Batching. Can you elaborate? But it is more tedious.
Re: GtkD 3.1.0 released, GTK+ with D.
On Thursday, 26 March 2015 at 22:41:01 UTC, Mike Wey wrote: Shortly after the last release, GtkD has been updated for GTK+ 3.16. Thank you, that's awesome :) Can't wait for my distro to get updated to start playing with this.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:40:14 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 16:27:48 UTC, Dicebot wrote: I have no interest in arguing with you, just calling out especially harmful lies that may mislead random readers. Nice one. I am sure your attitude is very helpful for D. Actually, it really is. He does a lot of useful work that has helped improve many parts of D and it's ecosystem. Mostly I see you sniping from the sidelines with in-actionable comments; not because you're necessarily wrong, but because despite what appears to be a significant body of knowledge, your arguments lack detail and are often supported by a bunch of academic knowledge that - at best - you refer to in overly general terms. Sorry if that sounds harsh, but it's frustrating seeing you throw knowledge at topics without making any of it stick.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:18:33 UTC, Sönke Ludwig wrote: So what happens if 10 requests come in at the same time? Does moving things around still help you? No. Load balancing is probabilistic in nature. Caching also makes it unlikely that you get 10 successive high computation requests. BTW, why would an event driven design be any better? You'd have exactly the same issue. 1. No stack. 2. Batching. But it is more tedious.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad wrote: No... E.g.: On the same thread: 1. fiber A receives request and queries DB (async) 2. fiber B computes for 1 second 3. fiber A sends response. Latency: 1 second even if all the other threads are free. This is a problem of having blocking 1 second computation in same fiber pool as request handlers - broken application design. Hiding that issue by moving fibers between threads is just making things worse.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 15:54:31 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 12:48:04 UTC, Dejan Lekic wrote: My personal opinion about the article - people may hate D equally for being too pragmatic. That Yeah, well, both the D/Go communities use the term pragmatic to gloss over underwhelming design issues in D/Go, and makes a point of how D/Go is deliberately not being a research language, yet still claim that D/Go bring novel features... although neither D or Go bring anything new to the table. I.e.just about all the major concepts in D/Go are 30-50 years old... It need not be new, it needs to be good. That's all. I don't understand this obsession people have with new things, as if they were automatically good only because they are new. Why not try square wheels? Uh, it's new, you know. It is mostly a case of inexperienced programmers not knowing PL history becoming fanbois of new languages. Kind of like the OS wars of the 1990s.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:06:55 UTC, Dicebot wrote: On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad wrote: No... E.g.: On the same thread: 1. fiber A receives request and queries DB (async) 2. fiber B computes for 1 second 3. fiber A sends response. Latency: 1 second even if all the other threads are free. This is a problem of having blocking 1 second computation in same fiber pool as request handlers - broken application design. Hiding that issue by moving fibers between threads is just making things worse. Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform? You can create more complicated setups where multiple 200ms computations cause the same latency when the CPU is 90% idle. This is simply not good enough, if fibers carry this cost then it is better to just use an event driven design.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:09:08 UTC, Chris wrote: It need not be new, it needs to be good. That's all. I don't understand this obsession people have with new things, as if they were automatically good only because they are new. Why not try square wheels? Uh, it's new, you know. New things can be cool for a toy language, but not for a production language. The latter needs polish and support (IDE etc). Just pointed out the social dynamics where Go/D communities are not all that different. There's probably a difference between programmers that juggle 5-7 languages and programmers that stick to 1 language: «it is just A tool among many» vs «it is THE tool». I think you see this expressed in both Go and D communities.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 14:47:08 UTC, Dicebot wrote: On Friday, 27 March 2015 at 14:18:33 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote: distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses). It is a complete disaster to not move fibers between threads if you want good latency. Only if execution time between fibers is very unevenly distributed and/or their amount is low. No... E.g.: On the same thread: 1. fiber A receives request and queries DB (async) 2. fiber B computes for 1 second 3. fiber A sends response. Latency: 1 second even if all the other threads are free.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 12:48:04 UTC, Dejan Lekic wrote: My personal opinion about the article - people may hate D equally for being too pragmatic. That Yeah, well, both the D/Go communities use the term pragmatic to gloss over underwhelming design issues in D/Go, and makes a point of how D/Go is deliberately not being a research language, yet still claim that D/Go bring novel features... although neither D or Go bring anything new to the table. I.e.just about all the major concepts in D/Go are 30-50 years old... It is mostly a case of inexperienced programmers not knowing PL history becoming fanbois of new languages. Kind of like the OS wars of the 1990s.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:11:42 UTC, Ola Fosheim Grøstad wrote: Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform? You can create more complicated setups where multiple 200ms computations cause the same latency when the CPU is 90% idle. This is simply not good enough, if fibers carry this cost then it is better to just use an event driven design. I have no interest in arguing with you, just calling out especially harmful lies that may mislead random readers.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 27.03.2015 um 17:11 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com: On Friday, 27 March 2015 at 16:06:55 UTC, Dicebot wrote: On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad wrote: No... E.g.: On the same thread: 1. fiber A receives request and queries DB (async) 2. fiber B computes for 1 second 3. fiber A sends response. Latency: 1 second even if all the other threads are free. This is a problem of having blocking 1 second computation in same fiber pool as request handlers - broken application design. Hiding that issue by moving fibers between threads is just making things worse. Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform? You can create more complicated setups where multiple 200ms computations cause the same latency when the CPU is 90% idle. This is simply not good enough, if fibers carry this cost then it is better to just use an event driven design. So what happens if 10 requests come in at the same time? Does moving things around still help you? No. BTW, why would an event driven design be any better? You'd have exactly the same issue.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 03/26/2015 09:47 PM, Walter Bright wrote: It seems to me that every significant but one feature of Go has a pretty much direct analog in D I'm no Go expert, but AIUI, Go seems to be one of those languages that considers *lacking* certain features to *be* a feature. Ie the whole minimalism approach to language design. For people who value that (not for me personally though), it's a feature D doesn't offer and deliberately doesn't try to.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 27.03.2015 um 19:56 schrieb Walter Bright: On 3/27/2015 5:15 AM, Sönke Ludwig wrote: It has, that is more or less the original selling point. It also keeps an internal thread pool where each thread has a dynamic set of reusable fibers to execute tasks. Each fiber is bound to a certain thread, though, and they have to, because otherwise things like thread local storage or other thread specific code (e.g. the classic OpenGL model, certain COM modes etc.) would break. It's awesome that vibe has that! How about replacing the fiber support in druntime with that? It's actually based on the fiber support in Druntime. It would definitely be great to get the event loop and the scheduler into Druntime/Phobos, too. But it needs to be integrated in many places at the same time (core.sync.*, std.concurrency, std.stdio, std.socket etc.) to avoid bad surprises for users. We'd need to decide how to cut that work into manageable pieces. Fortunately there is now already an event loop abstraction written in pure D [1], which should be integrated first, because the fiber scheduler itself isn't worth much without an event loop. [1]: https://github.com/etcimon/libasync
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 19:11:58 UTC, Walter Bright wrote: On 3/27/2015 5:48 AM, Dejan Lekic wrote: That `source.byLine.join.to!(string);` line for example, takes much longer time to understand than 20 lines of Go code. Any D newbie with knowledge of some modern language will struggle understanding (and being 100% sure that he/she understands!) that line of D code. This style of programming does take some getting used to for one that is used to traditional loop programming (like me). But it is like learning a new language - once you learn what byLine, join, etc., do, it is pretty simple to see what is happening. Sean Parent's advice for no raw loops comes to mind. https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning With that rule, basically a one-line body for foreach becomes acceptable. Your own description of component programming was also very good. Also Andrei's description of generic algorithms as being something like the final destination of programming, etc. You start with the same old code you might be used to from other languages, and then slowly learn to write generic code and propose new algorithms.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 5:15 AM, Sönke Ludwig wrote: It has, that is more or less the original selling point. It also keeps an internal thread pool where each thread has a dynamic set of reusable fibers to execute tasks. Each fiber is bound to a certain thread, though, and they have to, because otherwise things like thread local storage or other thread specific code (e.g. the classic OpenGL model, certain COM modes etc.) would break. It's awesome that vibe has that! How about replacing the fiber support in druntime with that? Apart from these concerns, It's also not clear to me that moving tasks between threads is necessarily an improvement. There are certainly cases where that leads to a better distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses). I agree that moving between threads can wait.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 5:48 AM, Dejan Lekic wrote: That `source.byLine.join.to!(string);` line for example, takes much longer time to understand than 20 lines of Go code. Any D newbie with knowledge of some modern language will struggle understanding (and being 100% sure that he/she understands!) that line of D code. This style of programming does take some getting used to for one that is used to traditional loop programming (like me). But it is like learning a new language - once you learn what byLine, join, etc., do, it is pretty simple to see what is happening.
Re: DTanks Alpha
On Wednesday, 25 March 2015 at 15:16:06 UTC, Russel Winder wrote: On Tue, 2015-03-24 at 23:37 +, Kingsley via Digitalmars-d-announce wrote: On Saturday, 21 March 2015 at 15:57:54 UTC, Dan Olson wrote: Kingsley kingsley.hendric...@gmail.com writes: In preparation for the London D meetup I have got the DTanks robot battle framework into the first alpha release state - good enough to use at the meetup anyway. https://github.com/masterthought/dtanks And an excellent framework it is too. I hope to be able to put some programming effort towards this to help make it even better. Actually I am wondering if we can put the framework skeleton to a constructive rather than destructive purpose. --K DTanks looks cool! I am going to have to try it. Brings back memories. I got hooked on the Apple ][ version (http://corewar.co.uk/robotwar/) back in the 80's and started a version for the Amiga called Tonks but it never got off the drawing board. I've always loved this game concept. Even did a version to run each tank on a node of an Intel Hypercube as a school project. Cool - feel free to give me any feedback. At the London D programmers meetup we had a tank tournament which was great fun. Some of the guys who came had not done D before - they were Scala / Java guys - but really enjoyed playing with D by way of the tanks game. Great fun was had by all there. Thanks to Kingsley for organizing this, and perhaps more importantly, getting the framework together. An interesting point was made by some there: this looks very like Java coding. Laeeth and I both agreed, saying that we felt Kingsley background in Java was being reflected a little in the look and feel of the D code, that if a C++ programmer had written it most likely the code would have had a C++ feel to it. Much of this is about spacing, identifier structure and things like that – relatively trivial stuff in the main. The question us then is this fine ( that D code can have a Java or C++ feel) or should there always be a D feel to all D code? There should be a video of the tournament emerging at some point from SkillsMatter who sponsor the meetup as they filmed it. The video may not reflect quite as much of the fun that was had! Here is the video: https://skillsmatter.com/skillscasts/6287-d-robot-tank-battle-tournament the fun starts at 16:48
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 20:20:07 UTC, Nick Sabalausky wrote: On 03/26/2015 09:47 PM, Walter Bright wrote: It seems to me that every significant but one feature of Go has a pretty much direct analog in D I'm no Go expert, but AIUI, Go seems to be one of those languages that considers *lacking* certain features to *be* a feature. Ie the whole minimalism approach to language design. For people who value that (not for me personally though), it's a feature D doesn't offer and deliberately doesn't try to. there's a difference between minimalism and blatantly not adopting core advances in language design over the past 40 years.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 1:20 PM, Nick Sabalausky wrote: I'm no Go expert, but AIUI, Go seems to be one of those languages that considers *lacking* certain features to *be* a feature. Ie the whole minimalism approach to language design. For people who value that (not for me personally though), it's a feature D doesn't offer and deliberately doesn't try to. That's right. What a minimal language does is transfer the work from the compiler to the programmer. Obviously, I prefer to transfer the work to the compiler. After all, if you're going to be spending 8 hours a day programming, investing a few more hours to learn the language is nothing compared with the time savings from using a more powerful one.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 1:35 PM, weaselcat wrote: there's a difference between minimalism and blatantly not adopting core advances in language design over the past 40 years. Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity. It's a tricky thing finding the sweet spot.
Re: GtkD 3.1.0 released, GTK+ with D.
On 2015-03-26 17:41, Mike Wey wrote: GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. Shortly after the last release, GtkD has been updated for GTK+ 3.16. GtkD 3.1.0 is now available on gtkd.org: http://gtkd.org/download.html great news - thanks for your efforts! there is a name conflict though. folder \srcgstreamer\gstreamer\ contains GStreamer.d and gstreamer.d this is not supported on windows machines i don't think DMD supports differentiating between them either. /det
Re: 2nd London D Programmers Meetup - Robot Tank Battle Tournament
On Wednesday, 25 March 2015 at 13:21:21 UTC, Iain Buclaw wrote: On 25 Mar 2015 12:15, Russel Winder via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Wed, 2015-03-25 at 11:25 +, wobbles via Digitalmars-d-announce wrote: On Tuesday, 24 March 2015 at 23:32:38 UTC, Kingsley wrote: Here are the details - spread the word: http://www.meetup.com/London-D-Programmers/events/220610394/ thanks --Kingsley Thanks for all who came to the D meetup. The champion tank of the evening goes to runaway.d by Justin Priya which defeated all challengers swiftly and in style :) Looking forward to the next meetup. Any videos of the fights? (Or were they all robot fights?) The activity was captured by the good folk of Skills Matter. It is worth noting the name of the winning tank exemplified it's strategy. It can be characterized by a quote from Monty Python and the Holy Grail: run away, run away. Whilst there, I didn't get around to writing a tank strategy, I spent too long looking at, and analysing, Kingsley's little framework – oh and chatting with Laeeth about D, Go, computational finance, etc. Kingsley's code is (mostly) great; hopefully I and others can help evolve this via pull requests, to be something we can put before CAS and others for inclusion in Key Stage 3 and 4 educational materials. Long explanation of new UK computing education system elided. This would be a great way of getting young people interested in native code after Scratch and Python. D and Java would be a good combination. Great stuff. I would have tried to come up, but with moving home and all... Vacated the flat this morning. :-o Iain Here is the video: https://skillsmatter.com/skillscasts/6287-d-robot-tank-battle-tournament the fun starts at 16:48
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 20:58:44 UTC, Walter Bright wrote: On 3/27/2015 1:35 PM, weaselcat wrote: there's a difference between minimalism and blatantly not adopting core advances in language design over the past 40 years. Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity. It's a tricky thing finding the sweet spot. I don't disagree, but Go is definitely not in that sweet spot - it's crippled by its benevolent dictators for the sake of being crippled.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Fri, 27 Mar 2015 22:37:21 +, weaselcat wrote: On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote: On Fri, 27 Mar 2015 16:11:41 +, Ola Fosheim Grøstad wrote: Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform? but it is broken! the whole point of async i/o servers is that such servers spend most of their time waiting for i/o. and if you need to do some lengthy calculations, you either spawns a real thread and commands it to wake you up when it is finished, or asking external server to do the job (and wake you when it is finished). what moving fibers from thread to thread does is bringing in state copying (we want our threads fairly isolated, aren't we? so either copying, or ownership management). the whole thing of cooperative multitasking is to be... cooperative. in several years some Shiny New Async Framework will use no transferring fibers between worker threads as Spectacular Invention. as an outsider to the web-scale world, this entire thing seems like a half-baked fork reimplementation the whole userspace threads concept is a reimplementation of kernel threads and sheduling. ;-) the main question is the amount of work required to switch between threads. if we have a little amount of threads that does heavy work, it's ok to use kernel mechanics: the time of context switching is neglible. but it we have alot of threads that mostly waits for i/o, then does very little amount of work and waits for i/o again, context switching time starts to show itself. so we moving the whole treading thing to user application, thus minimising thread context switching time. all in all this is a half-baked kernel thread reimplementation, yes. but it has it's own pros. and cons, of course: such as unresponsive user thread can block the whole app, like in good old windows 3 times. signature.asc Description: PGP signature
Re: GtkD 3.1.0 released, GTK+ with D.
On 03/27/2015 10:27 PM, captaindet wrote: On 2015-03-26 17:41, Mike Wey wrote: GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. Shortly after the last release, GtkD has been updated for GTK+ 3.16. GtkD 3.1.0 is now available on gtkd.org: http://gtkd.org/download.html great news - thanks for your efforts! there is a name conflict though. folder \srcgstreamer\gstreamer\ contains GStreamer.d and gstreamer.d this is not supported on windows machines i don't think DMD supports differentiating between them either. /det Fixed in 3.1.1. -- Mike Wey
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Fri, 27 Mar 2015 16:11:41 +, Ola Fosheim Grøstad wrote: Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform? but it is broken! the whole point of async i/o servers is that such servers spend most of their time waiting for i/o. and if you need to do some lengthy calculations, you either spawns a real thread and commands it to wake you up when it is finished, or asking external server to do the job (and wake you when it is finished). what moving fibers from thread to thread does is bringing in state copying (we want our threads fairly isolated, aren't we? so either copying, or ownership management). the whole thing of cooperative multitasking is to be... cooperative. in several years some Shiny New Async Framework will use no transferring fibers between worker threads as Spectacular Invention. signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote: On Fri, 27 Mar 2015 16:11:41 +, Ola Fosheim Grøstad wrote: Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform? but it is broken! the whole point of async i/o servers is that such servers spend most of their time waiting for i/o. and if you need to do some lengthy calculations, you either spawns a real thread and commands it to wake you up when it is finished, or asking external server to do the job (and wake you when it is finished). what moving fibers from thread to thread does is bringing in state copying (we want our threads fairly isolated, aren't we? so either copying, or ownership management). the whole thing of cooperative multitasking is to be... cooperative. in several years some Shiny New Async Framework will use no transferring fibers between worker threads as Spectacular Invention. as an outsider to the web-scale world, this entire thing seems like a half-baked fork reimplementation
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Fri, 27 Mar 2015 12:48:03 +, Dejan Lekic wrote: That `source.byLine.join.to!(string);` line for example, takes... ...almost no time to understand. it's a simple composition, the thing they should learn on their CS courses, along with lambda calculus (or functional programming, if you want). signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 2:47 PM, weaselcat wrote: On Friday, 27 March 2015 at 20:58:44 UTC, Walter Bright wrote: On 3/27/2015 1:35 PM, weaselcat wrote: there's a difference between minimalism and blatantly not adopting core advances in language design over the past 40 years. Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity. It's a tricky thing finding the sweet spot. I don't disagree, but Go is definitely not in that sweet spot - it's crippled by its benevolent dictators for the sake of being crippled. I tried to program in Java, and found it went too far in the simplicity department. I haven't programmed in Go, but it has also gone too far for my taste. I just don't want to program that way anymore. I am not going to claim that D has hit the sweet spot, either, but I'd rather err on the side of having the power I want.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 08:39:14 UTC, Russel Winder wrote: On Wed, 2015-03-25 at 14:00 -0700, Andrei Alexandrescu via Digitalmars-d-announce wrote: https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/ Andrei The reaction in the Go community to this article has been exactly as one would have anticipated. I paraphrase the common theme thus: Go is successful in the market, D isn't, therefore Go is a better language than D. Go does indeed have much greater market penetration, but I leave it as an exercise for the reader to deduce the sophistry, and indeed casuistry, in most of the argumentation. By this standard, Go is much worse than C++, Java, or even C, which they pretend to be a better version of.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
There are some very interesting psychological dynamics in the reaction to this kind of piece. For me it was key that although it was clearly written in a humorous tone, and hurriedly, he seemed to speak from the heart - it is refreshing to see such work even when one doesn't agree with it. BTW since when has linking to something been an endorsement of it? Interesting. Have you read Oscar Wilde? Your comments remind me of him somehow. Only a few things, and not his writings on aesthetics - but I do think truth, beauty and virtue need to balance each other. Concentrating on prettiness alone leads to a shallow kind of thing becomes it becomes disconnected from the underlying generative spirit and eventually the life goes out of it. So I suspect his perspective was rather different. I was just thinking yesterday how working with D makes me happy whereas working with other (lower) languages makes me grumpy. Yes - and this matters so much more than as technical people we give ourselves permission to realize because willpower is a limited resource and modern life often appears as if it is a conspiracy to exhaust it. When one actually look forward to writing a boring script because I can do it in D, I take notice. Moving towards what is generative and away from the wrong kind of pain is a strategy that seems to pay off in life. Going down to the punchcard level (PHP, JS etc.) is boring and doesn't do justice to the human mind. Whenever I use D, I am confident that I can map a complicated reality onto a machine, it inspires me and it challenges me. Primitive languages discourage me. Yes, although I must say I still prefer programming in C to VBA. Provided the aim is not actually to accomplish something quickly ! So there's more to productivity than meets the eye when looking at numbers. Numbers are insignificant, they can prove anything you want, and you can tweak them any way you want. Eat shit, a million flies can't be wrong!, as they say. Yes. And worst of all is the self deception from believing analytical objectivity to be something real rather than something that results from unexamined implicit assumptions. Dr Iain Mcgilchrist at Oxford is excellent on this topic. That doesn't mean one should throw away the profiler, of course... It's one thing to be productive in terms of maintaining and selling apps and another in terms of being innovative. You can sell a million records by sticking to well-trodden paths (dum-dum-dum-di-dum) or you can be a Mozart, a Beethoven, a Miles Davis or a Hendrix and just say I'm gonna do my own thing!. Sure, it involves what is commonly perceived as arrogance, but it's not. Fully agree, although humbler initial aspirations and self conceptions are also compatible with a creative path. Viz. I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 06:49:05 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 04:05:30 UTC, Laeeth Isharc wrote: Programming is - for now - still a human activity, and what is important in human activities may not always be measured, and what may be easily measured is not always important. That doesn't mean one should throw away the profiler and go back to guessing, but it does suggest caution about adopting the prestigious techniques of the natural sciences and applying them to a domain where they don't necessarily fully belong. What is almost always important is: 1. to be able to ship the product in a predictable fashion 2. not go 300-400% over budget 3. being able to train new people to maintain it in reasonable time 4. being able to add new unexpected features to the code base on request Perl is a very expressive and productive language. And you can write maintainable software in it if you have discipline. In the real world Perl tends to lead to an unmaintainable mess with the average programmer. Fair points that I wouldn't argue with (although I think predicting when one will finish something entirely new is a mugs game - another reason to favour prototyping and rapid iteration when possible). But those strike me as practical questions of commercial experience, judgement, and tradecraft, and I don't see what it has to do with D or with a scientific approach, except that D may have some advantages in some cases in these areas. I don't see any essential resemblance whatsoever between D and Perl - on the contrary. The data points we have suggest that the scarcity of D programmers is an imaginary problem, because enterprises just hire good people and they pick it up (ask Don at Sociomantic or Dicebot for example). Modern business has a misplaced emphasis on credentials. And if you have a large code base it is not like a new guy can just dive in, anyway. There is a signalling effect at work also, at least for the time being. I am curious about something, if I might ask. You seem like you feel let down by something about D. Ie you give various reasons but I am not sure that's the motivating factor. What's behind that ? No need to answer if you prefer not to, of course. Laeeth.
Re: Release D 2.067.0
On 3/26/2015 3:53 PM, ketmar wrote: filling bugs like this huge project not compiling! is not working, as nobody wants to run dustmite on such projects, people just waiting for issue author to provide more information. Realistically, people who want to work on bug fixing are going to work on ones that have already been isolated and filed. If you've got a huge project that's not compiling and don't know where to start, that implies it isn't well modularized and encapsulated.
Re: Release D 2.067.0
On Fri, 27 Mar 2015 21:36:15 -0700, Walter Bright wrote: On 3/26/2015 3:53 PM, ketmar wrote: filling bugs like this huge project not compiling! is not working, as nobody wants to run dustmite on such projects, people just waiting for issue author to provide more information. Realistically, people who want to work on bug fixing are going to work on ones that have already been isolated and filed. If you've got a huge project that's not compiling and don't know where to start, that implies it isn't well modularized and encapsulated. thank you for supporting my POV on not reporting bugs. that is what i wanted to told to John, yes. i must admit, though, that it wasn't even project of mine. but nevermind. signature.asc Description: PGP signature
Re: Release D 2.067.0
On Saturday, 28 March 2015 at 04:36:18 UTC, Walter Bright wrote: On 3/26/2015 3:53 PM, ketmar wrote: filling bugs like this huge project not compiling! is not working, as nobody wants to run dustmite on such projects, people just waiting for issue author to provide more information. Realistically, people who want to work on bug fixing are going to work on ones that have already been isolated and filed. There are also people who don't mind helping to reduce bugs so the compiler hackers can fix them quickly. But honestly, there already exists so much information on how to use DustMite, I don't know what else can be said. ANYONE should be able to use DustMite or Digger to reduce a test case down to reasonable size.
Re: Release D 2.067.0
On Sat, 28 Mar 2015 04:55:47 +, Vladimir Panteleev wrote: But honestly, there already exists so much information on how to use DustMite... ...that people in bugzilla keep asking what it is. ANYONE should be able to use DustMite or Digger to reduce a test case down to reasonable size. having a big codebase that you didn't wrote and never read took 12 hours to dustmite. not that i can just leave it unattended though, as compiler itself segfaults sometimes, and that effectively leaves dustmite frozen. so it not only eats resources of my box (and i have a work to do, and that work involves compiling big codebases too), but it requires my attention. but yes, it's entirely my fault that i cannot afford such resources and asking for help, i know. signature.asc Description: PGP signature
