Re: OT: 'conduct unbecoming of a hacker'
On Friday, 12 February 2016 at 03:19:52 UTC, Nick Sabalausky wrote: On 02/11/2016 04:54 PM, w0rp wrote: His article is way too long. It seems like an article about whining about how people whine too much. It's metawhine! :) These meta whines get on my nerves, everything was much better in Usenet days.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 10:52:31 UTC, Ola Fosheim Grøstad wrote: On Thursday, 11 February 2016 at 09:51:16 UTC, Joakim wrote: All of which are decades-old projects from the heyday of the GPL, when many mistakenly attributed linux's success to the GPL and copied its license blindly. Yes, it does take decades to create complicated productivity apps. That almost nobody uses? I can do that in a day. ;) The only open source productivity app I use that isn't GPL is Open Office (IIRC), but it uses LGPL components, and is more corporate than community... I never use any productivity apps, including an IDE, never saw the point to them. And almost nobody uses the OSS ones you list either. It did nothing of the sort, as GNU/linux basically went nowhere and MS didn't care. It is only once permissively-licensed software like Android and parts of iOS hit billions of devices that MS started doing so, under permissive licenses like those projects, not the GPL. Android is based on Linux... but this is not how I remember it. Bill Gates went public with statements against FOSS way before Android appeared. He was clearly frustrated by how Linux made inroads in the server market. They may have made statements before, but didn't change their behavior till permissively-licensed projects actually started doing really well in the market, as they're nothing if not observers of market success. As for Android using linux, I addressed that below: Android has much more permissively-licensed and closed software on top of its linux kernel. Anything you want to add to a standard library can easily be maintained in a private fork or put up on dub, as you've suggested doing to all of phobos. So even if you don't get a change into the standard library, there's nothing stopping you from using it or distributing it, so this comment seems pointless. I've repeatedly stated that libraries, phobos inclusive, are inconsequential. What matters is the language, compiler and runtime. Libraries are luxury items. I was responding to your statement that people could code something up and use it themselves, "unless you are designing a standard library." If libraries don't matter, I don't see why you'd bring that up as an exception. I agree with everything till you start espousing consensus. If anything, consensus often leads to the most incoherent designs, ie design by committee. No. A standards committee is a collection of representatives that are trying to balance out different conflicting agendas. Which is precisely what leads to incoherence. It is theoretically possible that one can come up with a balanced design by committee that is also the best, but the problem is that many of the representatives are either wrong or don't matter, so by balancing in their concerns, you almost always end up with a product unbalanced for the real world. If you build at team you are better off establishing consensus. So step one is to attract people with the same agenda. So if you want to fork you should try to build consensus within a faction and then branch off. If only 1 or 2 people create a fork it will most likely go nowhere. That's why I differentiated between getting a team on the same page and high-quality coherent designs. The former may get more done, but usually not at high quality. Read up more at the Linus links I gave to get the alternate perspective, of how to do it _without_ consensus. For example, if you think there might be commercial users for that feature, you could sell them a slightly forked version of dmd with your feature. Yes, I've given that some thought. But for it to pay off you need a refactor high quality code documented code base. If a 1-2 person team is to serve customers you cannot waste hours on poor infrastructure. On the other hand, that means only those who really know or are willing to spend the time learning the codebase can compete with you, ie new competition can't get going as fast. There are both pros and cons to being early. And how far have they gotten? Entire forks don't get very far, but a tracking branch with a few additional features can do just fine. One project got pretty far, but then it went dead because their life situation changed as far as I can tell. Another one is alive, but is too close to C++, but not close enough: http://loci-lang.org/ I think Loci looks quite ok, but it might be too influenced by personal taste. I think the same applies to many languages, even Rust, Go and D. Too opinionated, by not entirely well founded priorities. How is Loci in any way a fork of D? It may be similar in its features and goals, but it doesn't appear to fork any dmd or D code. If you believe those languages' priorities are "not entirely well founded," that's an opportunity for you to get it right. :) Then perhaps you didn't really need that code, if you wouldn't have gotten much use out
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 12:47:20 UTC, Ola Fosheim Grøstad wrote: On Thursday, 11 February 2016 at 11:46:44 UTC, Joakim wrote: That's why I differentiated between getting a team on the same page and high-quality coherent designs. The former may get more done, but usually not at high quality. Read up more at the Linus links I gave to get the alternate perspective, of how to do it _without_ consensus. Linux is not a good example. Linux is too high profile and can afford massive churn. That is highly inefficient use of programmer resources. It was not always high-profile, it started off with one guy and grew big through the same decentralized process. On the other hand, that means only those who really know or are willing to spend the time learning the codebase can compete with you, ie new competition can't get going as fast. There are both pros and cons to being early. Mostly cons. There are very few potential customers. And most likely no local customers, which are the most attractive ones. The chicken has to start somewhere, or there will be no eggs. ;) How is Loci in any way a fork of D? It may be similar in its features and goals, but it doesn't appear to fork any dmd or D code. I didn't say fork. I was talking about people who have given up on the D development process and created their own language in the same catagory as C++ and D. You mentioned it in response to forks and how far they've gotten. That guy gave up on D? If you believe those languages' priorities are "not entirely well founded," that's an opportunity for you to get it right. :) Sure, I'm thinking about it. But I currently think WebAssembly/JavaScript + Linux server are the most important targets, so maybe going from scratch is less work, actually. But sure, building a new language over Rust, D or Go is an option. The loci guy, just a couple years out of university did it, surely you could too, if nobody else is getting it right. As the original post noted, both need and want are irrelevant, if you're unwilling to code. Nobody are unwilling to code. Most people are unwilling to manage a project or invest in a project that isn't properly managed. What you need is a well managed project with a clear vision, clear goals and good leadership. And please don't point at Linus, he is not a particularly effective leader, but probably does well as a manager. But Posix was already given... The broad strokes for a monolithic kernel is kinda given. He just happend to whip up something at the right time, that many people had been looking for (free unix). In the emails I linked to, he notes that he didn't have a clear vision or goals and that it is _likely impossible to do so for software_. So he agrees with you that he isn't some great leader, and notes that what's important is the decentralized process, where there is _no clear vision_. Now, you're right that copying UNIX is easier than coming up with an entirely new technical design, but he claims that the UNIX guys themselves didn't "design" it, that that was an evolutionary, decentralized process also. A lot of solo devs using D to go in the same general direction will work too, probably a lot better than consensus. Well, not sure what we are talking about here. Clearly, you need consensus among said devs if you are going to change the language so that it can either support better manual memory managment or faster garbage collection? Not necessarily, Sociomantic didn't wait for permission to go do their own concurrent GC for D1. One can experiment with various approaches to memory management and come back with actual data. It doesn't take much time to prototype something and test out ideas, before you make a push for it to be included in the language. My point is that we're not going to come to a consensus on the best approach to memory management. Somebody, likely several, will have to try out different approaches locally and then compare results. Perhaps that will lead to several different GCs shipping with D, tuned for different loads. According to Linus, linux never had such a consensus, why did it succeed? Because there was no free Unix on x86 and the CPUs at that point in time had MMUs. Many people who used Unix at work or on campus wanted Unix at home too. Many students used Minix in their OS course, and disliked the non-free license. So you basically had a fairly large group of people willing to throw in weeks and months, if not years in the early stages of the project. That's all well and good, but it doesn't answer the question: how did they succeed without prior consensus, which Linus claims was never there? Refactoring and documentation isn't a restart. It is common hygiene! Right, it's a question of whether we stop everything and take a thorough bath, or clean a little here and there on the go. There is refactoring constantly going on, and
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 10:21:19 UTC, Joakim wrote: You heard them above. Sun is basically inbreeding. That tends to be good to bring out specific characteristics of a breed, and tends to be good for _specialization_. Linus is not a very good analyst. All the big iron corporations had transition problems: Cray, SGI, IBM, Sun and many more. It would be very difficult to take the expertise SUN had and rapidly turn SUN into a competitive force in a different field. Of course, none of this is relevant to programming languages. Perl died because Python was better. Not because the niches changed. C++11 is replacing C/C++98 for newer projects that need performance. Better hardware means the niche has shrunk, but it will remain a significant niche.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 09:51:16 UTC, Joakim wrote: Consensus is for getting everybody doing the same thing, which is not the road to technical quality. Linus has talked about the "wasteful" OSS approach, which he compares to evolution: http://bobweigel.net/projects/index.php?title=Weigel/Notes Btw, in looking for a link with that old Linus quote, I also found this other one, that I'd never read before and is relevant for those who think D should specialize more: Linus: Quite frankly, Sun is doomed. And it has nothing to do with their engineering practices or their coding style. Tim: I'd love to hear your thoughts on why. Linus: You heard them above. Sun is basically inbreeding. That tends to be good to bring out specific characteristics of a breed, and tends to be good for _specialization_. But it's horrible for actual survival, and generates a very one-sided system that does not adapt well to change. Microsoft, for all the arguments against them, is better off simply because of the size of its population - they have a much wider consumer base, which in turn has caused them largely to avoid specialization. As a result, Microsoft has a much wider appeal - and suddenly most of the niches that Sun used to have are all gone, and its fighting for its life in many of its remaining ones. Why do you think Linux ends up being the most widely deployed Unix? It's avoided niches, it's avoided inbreeding, and not being too directed means that it doesn't get the problems you see with unbalanced systems. Face it, being one-sided is a BAD THING. Unix was dying because it was becoming much too one-sided. http://yarchive.net/comp/evolution.html
Re: OT: 'conduct unbecoming of a hacker'
I am sure nobody will disagree with this post. Thing is, whenever there are people, there will be disagreements. I remember "final by default" vs "virtual by default" thread. I remember people whining and leaving the D community for X various reasons. What made me personally stick to D is that I humbly believe people who drive the project have clear ideas where do we go. I know some will disagree with me, but I will say it anyway: IT community, especially developers, are known for poor social skills... People tend to forget that...
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 11:46:44 UTC, Joakim wrote: That's why I differentiated between getting a team on the same page and high-quality coherent designs. The former may get more done, but usually not at high quality. Read up more at the Linus links I gave to get the alternate perspective, of how to do it _without_ consensus. Linux is not a good example. Linux is too high profile and can afford massive churn. That is highly inefficient use of programmer resources. On the other hand, that means only those who really know or are willing to spend the time learning the codebase can compete with you, ie new competition can't get going as fast. There are both pros and cons to being early. Mostly cons. There are very few potential customers. And most likely no local customers, which are the most attractive ones. How is Loci in any way a fork of D? It may be similar in its features and goals, but it doesn't appear to fork any dmd or D code. I didn't say fork. I was talking about people who have given up on the D development process and created their own language in the same catagory as C++ and D. If you believe those languages' priorities are "not entirely well founded," that's an opportunity for you to get it right. :) Sure, I'm thinking about it. But I currently think WebAssembly/JavaScript + Linux server are the most important targets, so maybe going from scratch is less work, actually. But sure, building a new language over Rust, D or Go is an option. As the original post noted, both need and want are irrelevant, if you're unwilling to code. Nobody are unwilling to code. Most people are unwilling to manage a project or invest in a project that isn't properly managed. What you need is a well managed project with a clear vision, clear goals and good leadership. And please don't point at Linus, he is not a particularly effective leader, but probably does well as a manager. But Posix was already given... The broad strokes for a monolithic kernel is kinda given. He just happend to whip up something at the right time, that many people had been looking for (free unix). I don't use or follow C++, but stuff like CTFE has been mentioned in this forum before. Well, constexpr functions can replace convoluted template programming. Not sure if that is related to D. A lot of solo devs using D to go in the same general direction will work too, probably a lot better than consensus. Well, not sure what we are talking about here. Clearly, you need consensus among said devs if you are going to change the language so that it can either support better manual memory managment or faster garbage collection? According to Linus, linux never had such a consensus, why did it succeed? Because there was no free Unix on x86 and the CPUs at that point in time had MMUs. Many people who used Unix at work or on campus wanted Unix at home too. Many students used Minix in their OS course, and disliked the non-free license. So you basically had a fairly large group of people willing to throw in weeks and months, if not years in the early stages of the project. Yes. But it could be simple. Like. 1. full feature freeze 2. heavy refactoring 3. full documentation of module x, y and z. + some details on goals and planning Such restarts rarely work out in the best of circumstances, ie a company with lots of money, even more so in a volunteer community. Not saying it can't or shouldn't be done, just that incremental improvement is more likely. Refactoring and documentation isn't a restart. It is common hygiene! But python has not emerged from that scripting language niche either, and I think you greatly overestimate how well C++11 is doing. Python was inspired by a language used for teaching programming, but was geared to more advanced programmers. Not sure what you mean by Python not having emerged? Those who want D to specialize more should heed Linus's words. Can you paraphase those words in a condensed manner that is relevant to programming languages? I don't get the argument.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 14:53:37 UTC, Joakim wrote: It was not always high-profile, it started off with one guy and grew big through the same decentralized process. It was fairly popular among students even back when it was not so great. This is not so atypical. Someone fills a void, then it grows. The real enabler was getting access to machines that had MMUs. The loci guy, just a couple years out of university did it, surely you could too, if nobody else is getting it right. I could, in theory. But that would make it my only hobby... software_. So he agrees with you that he isn't some great leader, and notes that what's important is the decentralized process, where there is _no clear vision_. Now, you're right that copying UNIX is easier than coming up with an entirely new technical design, but he claims that the UNIX guys themselves didn't "design" it, that that was an evolutionary, decentralized process also. I find that difficult to follow. A Unix kernel is a pretty clear vision... But Solaris was a much more advanced OS than Linux was, geared towards more complicated setups. I don't think the design of Linux is a major factor, as long as it worked reasonably well. Linux proliferate because it is the path of least resistance and high installed base. Distributions like Slackware and Debian were probably very important. It's not like end user cared about the kernel all that much. They wanted convenient distributions. I think people put too much weight on the kernel. It is not all that special. compare results. Perhaps that will lead to several different GCs shipping with D, tuned for different loads. Well, the problem is that the language itself does not lend itself to effective GC. If you have a modular compiler, well structured and documented, then it would make sense to change the semantics to see what the effect is. That's all well and good, but it doesn't answer the question: how did they succeed without prior consensus, which Linus claims was never there? I have no idea what he means. The basic conceptual design of a monolithic Unix kernel is rather well established. Right, it's a question of whether we stop everything and take a thorough bath, or clean a little here and there on the go. There is refactoring constantly going on, and documentation is always tough for OSS projects. Yes, but I see people repeatedly state in the forums that they they want to try do some work on the compiler, but that they find the code badly structured, undocumented and the process difficult to grasp... So it probably will pay off, if they actually mean it. For everyone that voice an opinion we probably can add another 5 that choose to be silent? I mean it's still a scripting language used for teaching, scripting, and webapps. Almost nobody is using it for application programming, ie anything outside that scripting niche, say for mobile apps. Yes, that's true. Although many people use Python in their workflow as a supporting language or even for meta-programming, like generating source for other languages. He noted that the UNIX vendors failed because they were highly specialized for certain corporate niches, unlike linux or Windows, and couldn't survive a collapse of that niche, because they weren't general enough to survive in new niches. Similarly, I'm saying D shouldn't specialize for the same reasons. I don't think it is comparable, Sun sold hardware and consulting. When the hardware market is undermined by commodity they were left with consulting. It is better for a business to stay focused, and then sell that aspect of their business when the market is shrinking. Sun was also not dissolved, it was picked up and integrated with Oracle, who benefits from Sun's assets. Microsoft is not a very good counter example either. Nor HP or Motorola. Reorganizing fractured businesses is even more difficult, I would think. It basically means you are trying to make sense of many businesses at once, instead of managing one... People are not looking for a general purpose language. They are looking for a solution to their particular problem area... Go Rust Swift All fairly specialized and gaining ground.
Re: OT: 'conduct unbecoming of a hacker'
On 02/11/2016 06:53 AM, Dejan Lekic wrote: I know some will disagree with me, but I will say it anyway: IT community, especially developers, are known for poor social skills... People tend to forget that... There may be a certain *small* level of truth to that, but most of it is nothing more than decades of Hollywood's pejorative stereotyping. And people being naive enough to believe what they see in the fiction that was produced by people who have spent decades proving themselves to have zero comprehension of basic reality, let alone even a basic high-school level research ability. It's the standard old Hollywood complete and total disconnect with reality - hell, look how they portray Tourette's a having a relationship to swearing (which is just plain bizarre to anyone actually capable of spending a mere one minute on a basic web search), or how cracking security always involves playing a 3D puzzle game. And then there's the oddity that any time a writer or director uses a computer in real life, the machine is clearly built to detect it's being used by Hollywood personnel, so all login systems automatically switch from the normal "Username and Password don't match \ Incorrect login \ Password was incorrect" to a flashing red "ACCESS DENIED". Because presumably they actually see this flashing red "ACCESS DENIED" when they actually do use a computer in real life, because they couldn't really be THAT dumb when producing a film, right? At least that's the only explanation I can come up with for its appearance in otherwise "realistic" movies, at least aside from LSD...which really could explain all the rest of their delusions too...hmm... Hollywood mental flakes spend decades inventing and reinforcing their own myopic stereotypes, such as "technical ability == dorks with no social skills", most likely because they feel threatened by people with at least half a function brain (which most of them clearly lack), and then the masses believe it, and it becomes *cough* "fact". That's all there is to it.
Re: OT: 'conduct unbecoming of a hacker'
His article is way too long. It seems like an article about whining about how people whine too much.
Re: OT: 'conduct unbecoming of a hacker'
On 02/11/2016 04:54 PM, w0rp wrote: His article is way too long. It seems like an article about whining about how people whine too much. It's metawhine! :)
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 16:39:14 UTC, Joakim wrote: I wouldn't call Swift specialized, maybe only because it only runs on OS X, iOS and linux right now. So Linus would predict that Go and Rust may do well now because they're specialized, but will be hit hard if their niche collapses and they don't become more general-purpose before then (which I don't think they can do). You seem to think that's not a real concern, that the growth from specialization is worth it. Let's see who's right. :) I don't think there is any such thing as general purpose programming languages. They all get sucked into a niche.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 15:31:02 UTC, Ola Fosheim Grøstad wrote: People are not looking for a general purpose language. They are looking for a solution to their particular problem area... Go Rust Swift All fairly specialized and gaining ground. I wouldn't call Swift specialized, maybe only because it only runs on OS X, iOS and linux right now. So Linus would predict that Go and Rust may do well now because they're specialized, but will be hit hard if their niche collapses and they don't become more general-purpose before then (which I don't think they can do). You seem to think that's not a real concern, that the growth from specialization is worth it. Let's see who's right. :) On Thursday, 11 February 2016 at 15:34:47 UTC, Nick Sabalausky wrote: On 02/11/2016 06:53 AM, Dejan Lekic wrote: I know some will disagree with me, but I will say it anyway: IT community, especially developers, are known for poor social skills... People tend to forget that... There may be a certain *small* level of truth to that, but most of it is nothing more than decades of Hollywood's pejorative stereotyping. And people being naive enough to believe what they see in the fiction that was produced by people who have spent decades proving themselves to have zero comprehension of basic reality, let alone even a basic high-school level research ability. That's how Hollywood works: they take a well-known trait or stereotype and build a caricature out of it, ie jocks are good-looking and dumb, the President is wise and composed, and so on. It's the standard old Hollywood complete and total disconnect with reality - hell, look how they portray Tourette's a having a relationship to swearing (which is just plain bizarre to anyone actually capable of spending a mere one minute on a basic web search), or how cracking security always involves playing a 3D puzzle game. And then there's the oddity that any time a writer or director uses a computer in real life, the machine is clearly built to detect it's being used by Hollywood personnel, so all login systems automatically switch from the normal "Username and Password don't match \ Incorrect login \ Password was incorrect" to a flashing red "ACCESS DENIED". Because presumably they actually see this flashing red "ACCESS DENIED" when they actually do use a computer in real life, because they couldn't really be THAT dumb when producing a film, right? At least that's the only explanation I can come up with for its appearance in otherwise "realistic" movies, at least aside from LSD...which really could explain all the rest of their delusions too...hmm... A lot of that is about showing simply and visually, or with greater effect, what would be boring if shown realistically. Many watching will not be able to read "Incorrect login," but they can figure out that flashing red is bad. If that person with Tourette's were just twitching uncontrollably, it's not very entertaining, whereas it's funny if they unexpectedly swear like a sailor in front of some prude. :) Watching somebody cracking security or defusing a bomb realistically would be boring and confusing, if not for the 3D puzzles or flashing LED bomb clocks to watch and understand what's going on. They're not that stupid, you know. They're just trying to make as much money as they can, which means dumbing the material down for the lowest common denominator. In fact, I find it astonishing how often they raise issues that later become big in real life. Hollywood mental flakes spend decades inventing and reinforcing their own myopic stereotypes, such as "technical ability == dorks with no social skills", most likely because they feel threatened by people with at least half a function brain (which most of them clearly lack), and then the masses believe it, and it becomes *cough* "fact". That's all there is to it. There may be some truth to that, but more likely they're just pandering to the stereotypes of their audience, ie the salesman who snickers at the IT guy who can't get a date but is jealous that he makes more money. I did think the recent movies The Social Network and Jobs, both written by the writer of The West Wing and The Newsroom, showed a concerted effort to cast those tech CEOs in a negative light. Hollywood is likely mad that tech is encroaching on their domain, with youtube, iTunes, Netflix, etc. There were supposedly characters in The Newsroom who railed against bloggers (never watched the show, heard it was bad), and the writer has done the same in real life. What you say may be true in the last couple years, whereas before they likely didn't see tech as a threat.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 07:32:00 UTC, Ola Fosheim Grøstad wrote: On Thursday, 11 February 2016 at 06:20:33 UTC, Joakim wrote: Eh, there were always the BSDs and essentially nobody runs GNU code today. Uhm... Many do. And beyond GNU, the GPL/LGPL are the most common licenses in community driven open source productivity applications: Gimp, Inkscape, Blender, Audacity... All of which are decades-old projects from the heyday of the GPL, when many mistakenly attributed linux's success to the GPL and copied its license blindly. Almost nobody starts new projects with the GPL today, and it seems they've also given up on such OSS productivity apps. My point is that people see the success of open source and his early role as a vocal proponent and assume he was "critical," when the truth is more complicated, as his extreme formulation of completely "free software" has not done that well. It has not done well with corporations, but it has done very well with open source end-user software! Even projects that are not GPL tend to use LGPL code. Define "very well." :) Because I've listed multiple permissively-licensed projects that are a couple orders of magnitude more widely used, and I see almost no GPL software even close. It's basically just the linux kernel and that's it, and that only because it was piled high with permissively-licensed and even closed software on top, with Android. Yet, Linux did manage to scare the juggernauts, so now even Microsoft is starting to publish under liberal licenses (first very restrictive, now very liberal). It did nothing of the sort, as GNU/linux basically went nowhere and MS didn't care. It is only once permissively-licensed software like Android and parts of iOS hit billions of devices that MS started doing so, under permissive licenses like those projects, not the GPL. This is why you should generally only work on something you actually need, which is a great discipline. Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs. Well, yes. Unless you are designing a standard library. Anything you want to add to a standard library can easily be maintained in a private fork or put up on dub, as you've suggested doing to all of phobos. So even if you don't get a change into the standard library, there's nothing stopping you from using it or distributing it, so this comment seems pointless. The original open source projects were mostly about recreating existing designs, but with a open source license. So the missing features were obvious. In the case of GNU (Unix), it is a cluster of individual small programs. So if people was unhappy they wrote a new version from scratch. And the most popular ones survived. Creative designs that went open source tended to be research projects... so you had a clear vision (and people who were experts in their field leading the design). So, the linked rant is pretty clueless IMO. You need to form consensus in order to gain focus. If you don't have focus you'll never end up with something coherent. If the author believed in what he wrote, then why did he write it? He obviously wrote it because he believe that communication can lead to change. And thereby he undermines his own argument... I agree with everything till you start espousing consensus. If anything, consensus often leads to the most incoherent designs, ie design by committee. What brought original FOSS projects focus was the fact that they were not implementing original designs. And there has been LOTS of advocacy and arguments on usenet about every creek and cranny in software... since way before the Internet existed. So, it was an entertaining rant... and nothing more. It had some good points, but was inconsistent. Perhaps one reason OSS projects have become less willing to take his patches is that they've become much more widely used, where if your project ships on Android, it will be used by a billion and a half people. Given that these projects are still way understaffed- look at OpenSSL and its Heartbleed bug- it's understandable that some would be conservative. Of course, it's possible that the projects he talked to had almost no users, so it all depends on the scale of the project, as I said before. For example, I asked about ARM and mobile support for D in 2011, noting that mobile was starting to take off and that people had been asking for ARM support periodically for years even prior to that. I was told it was one of many priorities, but nobody knew when it'd be worked on. Yes, and this is all good, but it is not a language issue. It fits well with what makes contributing to GNU/Unix easy. You can write an isolated piece. Even with language issues, there is potential for deviation. For example, if you think there might be commercial users for that feature, you could sell them a
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 09:51:16 UTC, Joakim wrote: All of which are decades-old projects from the heyday of the GPL, when many mistakenly attributed linux's success to the GPL and copied its license blindly. Yes, it does take decades to create complicated productivity apps. The only open source productivity app I use that isn't GPL is Open Office (IIRC), but it uses LGPL components, and is more corporate than community... It did nothing of the sort, as GNU/linux basically went nowhere and MS didn't care. It is only once permissively-licensed software like Android and parts of iOS hit billions of devices that MS started doing so, under permissive licenses like those projects, not the GPL. Android is based on Linux... but this is not how I remember it. Bill Gates went public with statements against FOSS way before Android appeared. He was clearly frustrated by how Linux made inroads in the server market. Anything you want to add to a standard library can easily be maintained in a private fork or put up on dub, as you've suggested doing to all of phobos. So even if you don't get a change into the standard library, there's nothing stopping you from using it or distributing it, so this comment seems pointless. I've repeatedly stated that libraries, phobos inclusive, are inconsequential. What matters is the language, compiler and runtime. Libraries are luxury items. I agree with everything till you start espousing consensus. If anything, consensus often leads to the most incoherent designs, ie design by committee. No. A standards committee is a collection of representatives that are trying to balance out different conflicting agendas. If you build at team you are better off establishing consensus. So step one is to attract people with the same agenda. So if you want to fork you should try to build consensus within a faction and then branch off. If only 1 or 2 people create a fork it will most likely go nowhere. For example, if you think there might be commercial users for that feature, you could sell them a slightly forked version of dmd with your feature. Yes, I've given that some thought. But for it to pay off you need a refactor high quality code documented code base. If a 1-2 person team is to serve customers you cannot waste hours on poor infrastructure. And how far have they gotten? Entire forks don't get very far, but a tracking branch with a few additional features can do just fine. One project got pretty far, but then it went dead because their life situation changed as far as I can tell. Another one is alive, but is too close to C++, but not close enough: http://loci-lang.org/ I think Loci looks quite ok, but it might be too influenced by personal taste. I think the same applies to many languages, even Rust, Go and D. Too opinionated, by not entirely well founded priorities. Then perhaps you didn't really need that code, if you wouldn't have gotten much use out of it on your own. Yes, I've admitted that maintaining some language features is too painful or different to maintain in a private branch, but many can. Yep, that's true. I don't need any other languages than C++, TypeScript and Python. But what I need is not the same as what I want! Now, maybe it's impossible to maintain a high technical standard with a community-driven OSS project and you need a business model to be able to afford such exploration and possible waste of time. That may be a fundamental tension between technical quality and the OSS development model that cannot be resolved. But I see no way around such rejection if you want to maintain a high level of quality. Well, I think it matters that people can sit around a table and talk. And one can probably find solutions for doing cooperative work in a better way with the high bandwidths we have on the Internet today. But building a team with a shared vision and the right knowledge/attitude is not so easy either. Doing innovative things as a collective is very challenging. I think it takes much higher communication/people skills than is commonly found in these kind of projects. One of the reasons it's close is that new versions of C++ are copying D. :) I don't blame them for doing so or think there's anything wrong with it, but there are still enough problems with C++ that I don't think it'll be enough. Which features are you thinking of? I think D has rushed to implement proposed C++ features... (It can take a decade for things to make it into C++) Yes, politics, look at how much the politicians get done! ;) I think we all know and Walter and Andrei have said that they're not managers. So, what is the process? Where is the quality assurance? They have to do managment if they want to lead. Architects do manage the process. They don't lay down bricks. That's how great buildings become... great. And no, a programming language cannot be a "bazaar" (that's
Re: OT: 'conduct unbecoming of a hacker'
On 02/09/2016 09:11 PM, Laeeth Isharc wrote: My email is inevitably met not with acceptance, nor with constructive discussion, but with some attempt to derail the entire enterprise. Here are some real examples, paraphrased by yours truly: I think it should be done some other way, even though the other way obviously doesn’t work for you and so far nobody has ever been found who is willing to implement it that way I don’t want to solve this problem without also solving [unrelated problem X], your proposal doesn’t address [unrelated problem X], therefore I am inclined to reject it I don’t know you and there might be a bug in your patch. This patch is too important to leave to somebody new. At the same time it is not important enough for any of the core committers to get to it. Defend this proposal. You’re telling me you “need” encryption in an internet communications library, or you “need” unicode support in an object storage library. I don’t believe you. We’ve gotten along just fine for N months without it, and we’ll get along for another 2N months just fine thanks. Look, we’ve already implemented [sort-of related feature] even though it’s buggy and doesn’t cover your usecase. That decision was complicated and people were arguing about it for years and I really don’t want to go through that jungle again. If you wanted to do it this way you should have spoken up two years ago. Unfortunately, that sounds very similar to experiences I've had here in D-land :( Gets very frustrating.
Re: OT: 'conduct unbecoming of a hacker'
On Wed, Feb 10, 2016 at 12:17:40PM -0500, Nick Sabalausky via Digitalmars-d wrote: > On 02/09/2016 09:11 PM, Laeeth Isharc wrote: > > > >My email is inevitably met not with acceptance, nor with constructive > >discussion, but with some attempt to derail the entire enterprise. > >Here are some real examples, paraphrased by yours truly: > > > > I think it should be done some other way, even though the other > >way obviously doesn’t work for you and so far nobody has ever been > >found who is willing to implement it that way > > I don’t want to solve this problem without also solving > >[unrelated problem X], your proposal doesn’t address [unrelated > >problem X], therefore I am inclined to reject it > > I don’t know you and there might be a bug in your patch. This > >patch is too important to leave to somebody new. At the same time it > >is not important enough for any of the core committers to get to it. > > Defend this proposal. You’re telling me you “need” encryption in > >an internet communications library, or you “need” unicode support in > >an object storage library. I don’t believe you. We’ve gotten along > >just fine for N months without it, and we’ll get along for another 2N > >months just fine thanks. > > Look, we’ve already implemented [sort-of related feature] even > >though it’s buggy and doesn’t cover your usecase. That decision was > >complicated and people were arguing about it for years and I really > >don’t want to go through that jungle again. If you wanted to do it > >this way you should have spoken up two years ago. > > > > Unfortunately, that sounds very similar to experiences I've had here > in D-land :( Gets very frustrating. Have to agree with you there. :-( While, on the whole, my experience of D has been very pleasant, and I will probably stick to it for the long term, there *are* some rough edges that, arguably, should have been ironed out by now. But every time the topic comes up people get defensive and then the interminable forum threads ensue, and at the end nothing gets done because everyone is spent from all the arguments. More and more, I've found that participating in forum threads is, in general (there *are* exceptions), inversely proportional to actually getting stuff done. So nowadays I rather just submit a PR instead of getting entangled in the latest Great Debate. OTOH, even PR's can also get discouraging sometimes when it touches certain controversial issues, when it can get stonewalled for months on end, a great deterrent for new contributors to join in. T -- Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 18:09:57 UTC, Joakim wrote: Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. Well, 386BSD was there in 1992-1994, and several other OSes, so I don't think Linux is that special. Linux did have the right timing. Amiga and other specialized hardware was becoming less attractive at that point in time, and students were getting x86 PCs with MMUs and wanted an OS that was more like Unix, but less crude than Minix. But I don't think Hurd is much of a Stallman coding-project. His core project is the GPL and he did created Emacs and GCC which were very important for the spread of the GPL. Before GPL most academic software had very limiting "free for non-commercial educational use" clauses in their licenses. The GPL itself is much more important than any individual piece of software. As for the main point about useless bickering replacing hacking, that's probably because it was a much smaller community back then, so it consisted of only the really hard-core who wanted to _do_ something, whereas now it's expanded outside that group to the more half-hearted. Either that or he has on the usual rose-colored glasses for the past, the usual veteran complaint, "Everything was better when I was young!" :D Well, both Emacs and GCC have had their forks... so. Yes.
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 18:31:22 UTC, Nick Sabalausky wrote: On 02/10/2016 01:09 PM, Joakim wrote: Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. [Unimportant theorizing ahead...] I wouldn't say that's necessarily true: It could be argued the existence and proliferation of the Linux kernel reduced the priority of his Hurd work, even if only to a subconscious extent. If it hadn't been for the Linux kernel, maybe there would have been more drive (and more contributors) to Hurd. I've read that the bigger issue was that they couldn't quite get Hurd working on '90s hardware, and the simpler linux kernel outpaced it, ie I doubt linux displaced Hurd contribution as they're different approaches. On Wednesday, 10 February 2016 at 19:07:27 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 10 February 2016 at 18:09:57 UTC, Joakim wrote: Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. Well, 386BSD was there in 1992-1994, and several other OSes, so I don't think Linux is that special. Linux did have the right timing. Amiga and other specialized hardware was becoming less attractive at that point in time, and students were getting x86 PCs with MMUs and wanted an OS that was more like Unix, but less crude than Minix. Still means he'd have had to rely on others to provide his OS, plus BSD was under a legal cloud at the time, which is one of the reasons people say linux lapped it, and he'd probably resent it not being GPL, so it wouldn't work for him anyway. But I don't think Hurd is much of a Stallman coding-project. His core project is the GPL and he did created Emacs and GCC which were very important for the spread of the GPL. I thought he was intimately involved with Hurd, but I don't follow it. Before GPL most academic software had very limiting "free for non-commercial educational use" clauses in their licenses. The GPL itself is much more important than any individual piece of software. Perhaps historically as a guinea pig, but its use is waning for more permissive licenses, which have been around for decades too. As for the main point about useless bickering replacing hacking, that's probably because it was a much smaller community back then, so it consisted of only the really hard-core who wanted to _do_ something, whereas now it's expanded outside that group to the more half-hearted. Either that or he has on the usual rose-colored glasses for the past, the usual veteran complaint, "Everything was better when I was young!" :D Well, both Emacs and GCC have had their forks... so. Yes. Forks are a different issue, as he'd probably say that's real technical disagreement. He's talking more about silly reasons, though I guess forks are sometimes started because of the same dismissiveness he lays out.
Re: OT: 'conduct unbecoming of a hacker'
On 02/09/2016 09:11 PM, Laeeth Isharc wrote: http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/ (His particular suggestion about accept patches by default is not why I post this). Just read the rest of the article. That's a REALLY good article. Especially these bits: === "Consider the following outcomes, which happen with some regularity: * [...] * Objections that the problem should be solved another way, but that are accompanied without any volunteers to do it that way. A patch in the hand is better than two in the bush. If somebody does end up doing it the “right” way someday, git revert is only 10 keystrokes. The fact that someday a better patch might appear is not an argument against merging an adequate patch right now. * Bare assertions that there is no need for the feature, when the fact that somebody wrote a patch should be primae facie evidence that the feature was needed" --- "Really, what I’m asking is this: Which is more convincing? Concrete computer code authored by someone with first-hand knowledge of the defect? Or the bare assertion that something is wrong with it? I mean, either one might be correct. But the first is better supported." == Really like: "A patch in the hand is better than two in the bush."
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote: http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/ (His particular suggestion about accept patches by default is not why I post this). ' We’re all talk [...] Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. As for the main point about useless bickering replacing hacking, that's probably because it was a much smaller community back then, so it consisted of only the really hard-core who wanted to _do_ something, whereas now it's expanded outside that group to the more half-hearted. Either that or he has on the usual rose-colored glasses for the past, the usual veteran complaint, "Everything was better when I was young!" :D I don't think the D community actually has these problems that much, as most of the talk is about technical issues, not whether Apple is doing this or that with their business. The fact is that software was not as big a business back then, whereas the largest companies on the planet are built to write software nowadays, so of course people talk a lot more about how the giant software company du jour's actions affect them.
Re: OT: 'conduct unbecoming of a hacker'
On 02/10/2016 01:09 PM, Joakim wrote: Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. [Unimportant theorizing ahead...] I wouldn't say that's necessarily true: It could be argued the existence and proliferation of the Linux kernel reduced the priority of his Hurd work, even if only to a subconscious extent. If it hadn't been for the Linux kernel, maybe there would have been more drive (and more contributors) to Hurd.
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 19:44:50 UTC, Joakim wrote: Perhaps historically as a guinea pig, but its use is waning for more permissive licenses, which have been around for decades too. Well, they had been around for things like X11, which had a commercial consortium driving the development. X11 was just a reference implementation, and members got early access to it so that they could implement it in their proprietary X11 terminals before the general public got access to it... But as (even public) universities were pressured to earn money from their research the heads higher up insisted on anti-commercial licensing. Only when GPL gained traction could the comp. sci. people start to push for something more liberal. IIRC the most standard licensing was educational-use, non-commercial-use or public domain back then. People had to pay for their compilers and IDEs too... quite a lot... And phone bills from using BBSes. Shareware was a much more accepted concept at that point in time too... GPL changed the world quite significantly.
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 17:17:40 UTC, Nick Sabalausky wrote: Unfortunately, that sounds very similar to experiences I've had here in D-land :( Gets very frustrating. Yes - one trigger for posting it was the tone of some messages in some recent forum discussions (although it's really a tiny part of things on the whole). 'D is broken and needs a complete redesign', 'D has no chance against C# and Swift' etc. Maybe, but grumbling isn't going to make it better, once the ground has been covered once. I should they that although I have read his blog in the past, the trigger for reading that note was his commentary on the nanomsg hoohah (please - let's discuss that on another thread if necessary, not on this one). And that's the project he was referring to in this note. I don't know all the details there, but I think his broader point about the decline of hacker culture is a much stronger one than the specific application he makes with nanomsg (my take would be a bit different). [I'm not really able to judge situation as regards pull requests for D, although I wonder sometimes about type 1 vs type 2 errors and the balance between maintaining high standards and letting the best be the enemy of the good, given that something imperfect but useful can be the seeds of something that ends up becoming truly excellent - depending on the intrinsic sunk costs from doing things not perfectly the first time which might depend on the particular problem but also might not be obvious beforehand]. Eg for all the time spent arguing about what's holding D back, some of the real progress in terms of making the language attractive to real end-users who are going to hire people and maybe contribute resources came from people just doing stuff. ndslice, PyD Magic (integration with python notebook), bachmeier's integration with R (which means access to all the R libraries, which is huge). I notice Kenji rarely argues about things in the forum. Would we be better off if he were to spend much more time here instead of fixing bugs ? :) would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP? Joakim: "Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus." No - I think he used Stallman as an example of someone who although he whined a lot actually did a hell of a lot of work even so and became the change in the world he wanted. In my view productivity isn't about how many projects you don't manage to finish, but how many you do get done, and I am not sure I am in a position to criticize Stallman from that perspective, and even if his ideological approach isn't entirely my cup of tea, I do recognize he played a critical role there that was necessary. Nick: "That's a REALLY good article - quoting 'a patch in the hand is better than two in the bush'." Yes, I think so. Though it's delicate. Problem is for some things making the wrong decision can be a disaster. But, for example, with dirEntries right now - it's broken for serious use (last I checked and if it's fixed now, the point stands as it was broken for a long time). Almost decent solutions have been proposed but fell short of perfection and then they were kind of dropped. So the consequence is it's (possibly and if not then was for a long time) still broken. That's not the first time this kind of thing has happened. Was that the right trade-off between Type 1 and Type 2 errors? If you're not making some of each kind of mistake then it may be the case that the balance is wrong. (Depending on the situation of course - depends on what the consequences are of making a mistake. Conservatism isn't always the lower risk option, even though it feels that way). "* Bare assertions that there is no need for the feature, when the fact that somebody wrote a patch should be prima facie evidence that the feature was needed" Yes. Though with language features it's delicate, and I respect the taste of Andrei/Walter and other key people. "Really, what I’m asking is this: Which is more convincing? Concrete computer code authored by someone with first-hand knowledge of the defect? Or the bare assertion that something is wrong with it? I mean, either one might be correct. But the first is better supported." Yes - quite. Lobo - thanks for video link. Will watch. His montage of the shift in the front cover of hacker magazines was rather revealing of broader societal shifts. (From Byte and Dr Dobbs in the 80s to their successors becoming more like lifestyle magazines today). I've seen the same thing happen in my lifetime in certain parts of finance. In the beginning you have a bunch of highly unusual people who ended
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 23:55:17 UTC, deadalnix wrote: Also because context switching got from a handful of cycle at the time to about 1000 cycles on modern CPU, making the idea of microkernel somewhat less attractive. But saying Stallman released nothing is unfair. If we can consider hurd a failure, he was also behind emacs, early gcc and other things. Nobody said "nothing," I specifically noted his "GNU tools" and that a microkernel was ambitious. Just remarking that his kernel didn't get done, for a variety of reasons.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:50:04 UTC, Laeeth Isharc wrote: For the most difficult/contentious issues, writing a DIP is just another form of arguing. Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive. True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 06:20:33 UTC, Joakim wrote: On Thursday, 11 February 2016 at 05:31:54 UTC, tsbockman wrote: As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.) I'll note that not knowing a better solution doesn't mean one must simply accept the solution at hand, especially if that temporary solution will be difficult to unwind later. Sometimes you simply need more time to come up with something better. It all depends on the scale of the project and the suitability of the solution presented; you cannot simply say that "some" solution is better than nothing, as the original quoted post does. But yeah, maybe the reasons for rejection can be communicated better. Although I realize it might sound like I am, I'm not really criticizing either side in this. I don't really know whether either DIP69 or DIP77 actually represents a reasonable solution to the problem; as I said, I am unqualified to make that determination. I was simply giving my impression of where the discussion stands at the moment. I am certainly not advocating that DIP77 be implemented over the objections of so many of the people in the community who *are* qualified. In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons. This is why you should generally only work on something you actually need, which is a great discipline. Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs. Definitely. For example, I asked about ARM and mobile support for D [...] Your efforts are appreciated! I don't know if anyone else is using your work *yet*, but give it time and I'm confident that they will. ARM and Android are very important platforms.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:50:04 UTC, Laeeth Isharc wrote: On Thursday, 11 February 2016 at 04:35:27 UTC, tsbockman wrote: On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote: would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP? For the most difficult/contentious issues, writing a DIP is just another form of arguing. Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive. And not only is it more constructive but the structured format forces you to think things through and to make explicit what isn't in a forum post (which may reduce contention since its much clearer what you mean). And even if this were not the case then there are plenty of things that people like to grumble about but that wouldn't be all that contentious once expressed in a thought through DIP even if people didn't agree with you. Because then its all set out clearly and it becomes more of an objective technical debate.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:54:15 UTC, tsbockman wrote: On Thursday, 11 February 2016 at 04:50:04 UTC, Laeeth Isharc wrote: For the most difficult/contentious issues, writing a DIP is just another form of arguing. Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive. True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered. Which ones, out if interest ? And in your opinion were they thought through ?
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:59:16 UTC, Laeeth Isharc wrote: On Thursday, 11 February 2016 at 04:54:15 UTC, tsbockman wrote: True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered. Which ones, out if interest ? And in your opinion were they thought through ? Specifically, DIP69 and its predecessors, which propose a Rust-inspired lifetime and escape analysis system as a solution to many of D's memory model woes. It seemed (and still seems) like a good solution to me, but I recognize that I am insufficiently experienced and knowledgeable in the relevant areas to deserve a vote in the matter. So, I'm not necessarily saying that it should have been accepted - but I can definitely understand how frustrating it is for those who worked on it over the course of several months to have it rejected (as far as I can tell) simply because it is "too complicated". This is non-constructive in the sense that it is a subjective judgment which does not point the way to a better solution. As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.) In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote: Joakim: "Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus." No - I think he used Stallman as an example of someone who although he whined a lot actually did a hell of a lot of work even so and became the change in the world he wanted. In my view productivity isn't about how many projects you don't manage to finish, but how many you do get done, and I am not sure I am in a position to criticize Stallman from that perspective He got some stuff done, which I alluded to, but his big project to build an OS on which to run his tools didn't. even if his ideological approach isn't entirely my cup of tea, I do recognize he played a critical role there that was necessary. Eh, there were always the BSDs and essentially nobody runs GNU code today. Android, that big open-source success, comes with almost no GNU code, just the linux kernel from Linus and company and a bunch of Apache-licensed code. A lot of the BSD guys went to work at Apple, where they have now spread the permissively-licensed Darwin base of OS X and iOS to more than a billion devices, along with llvm and other permissively-licensed projects. Stallman's GNU/GPL effort has largely failed, so he was clearly neither critical nor necessary. Was he important, as a vocal proponent of FOSS early on? Perhaps, but things would likely have progressed this way regardless, as his extremist, quasi-religious preaching of "free software" is largely dying out. That religious fervor may even have hurt as much as it helped early on, as that collaborative model only really took off after the more business-friendly rebranding as "open source," which has also led to a move to more permissive licenses, ie not the GPL. My point is that people see the success of open source and his early role as a vocal proponent and assume he was "critical," when the truth is more complicated, as his extreme formulation of completely "free software" has not done that well. On Thursday, 11 February 2016 at 05:31:54 UTC, tsbockman wrote: So, I'm not necessarily saying that it should have been accepted - but I can definitely understand how frustrating it is for those who worked on it over the course of several months to have it rejected (as far as I can tell) simply because it is "too complicated". This is non-constructive in the sense that it is a subjective judgment which does not point the way to a better solution. As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.) I'll note that not knowing a better solution doesn't mean one must simply accept the solution at hand, especially if that temporary solution will be difficult to unwind later. Sometimes you simply need more time to come up with something better. It all depends on the scale of the project and the suitability of the solution presented; you cannot simply say that "some" solution is better than nothing, as the original quoted post does. But yeah, maybe the reasons for rejection can be communicated better. In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons. This is why you should generally only work on something you actually need, which is a great discipline. Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs. For example, I asked about ARM and mobile support for D in 2011, noting that mobile was starting to take off and that people had been asking for ARM support periodically for years even prior to that. I was told it was one of many priorities, but nobody knew when it'd be worked on. Two years later, seeing mobile still hadn't been done (though others had gotten ldc/gdc working on linux/ARM to some extent), I took it up and, along with Dan, alpha releases for iOS and Android are now listed on the main download page. It doesn't matter to me if nobody here uses D on mobile- though I certainly think that would be a huge missed opportunity- as _I_ want to use D on Android and now I can. While this is not generalizable for all D PRs, ie nobody wants to maintain a fork of certain language
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 06:01:29 UTC, Laeeth Isharc wrote: Beyond my pay grade, but looks to me like study group is devoted to just this kind of question It's not just devoted to this *kind* of question - it's devoted to this *exact* question. It was formed explicitly for the purpose of trying to work out an acceptable solution to the reference-counting safety problem. and in response to observation that this is something very important to get right and very difficult the discussion is beginning "Starting over" or maybe even "sidetracking" would be more accurate - quite a lot of other stuff got posted in the study group before the RCString thing came up. No consensus was emerging, hence the reset. with a simpler but important (there were some stats on chrome that were quite shocking) problem of how to do RC strings. If there's one area where you shouldn't just accept patches this surely must be it ! True. It's a hard problem, especially since they're shooting for making safe RC a non-breaking change. And I don't see the people that are grumbling participating in the study group... ? But some of them are. The grumbling over RC is a reflection of how hard the problem is to solve, not a collective unwillingness to contribute code on the part of either side.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 05:31:54 UTC, tsbockman wrote: On Thursday, 11 February 2016 at 04:59:16 UTC, Laeeth Isharc wrote: On Thursday, 11 February 2016 at 04:54:15 UTC, tsbockman wrote: True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered. Which ones, out if interest ? And in your opinion were they thought through ? Specifically, DIP69 and its predecessors, which propose a Rust-inspired lifetime and escape analysis system as a solution to many of D's memory model woes. It seemed (and still seems) like a good solution to me, but I recognize that I am insufficiently experienced and knowledgeable in the relevant areas to deserve a vote in the matter. So, I'm not necessarily saying that it should have been accepted - but I can definitely understand how frustrating it is for those who worked on it over the course of several months to have it rejected (as far as I can tell) simply because it is "too complicated". This is non-constructive in the sense that it is a subjective judgment which does not point the way to a better solution. As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.) In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons. Beyond my pay grade, but looks to me like study group is devoted to just this kind of question and in response to observation that this is something very important to get right and very difficult the discussion is beginning with a simpler but important (there were some stats on chrome that were quite shocking) problem of how to do RC strings. If there's one area where you shouldn't just accept patches this surely must be it ! And I don't see the people that are grumbling participating in the study group...
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 06:20:33 UTC, Joakim wrote: Eh, there were always the BSDs and essentially nobody runs GNU code today. Uhm... Many do. And beyond GNU, the GPL/LGPL are the most common licenses in community driven open source productivity applications: Gimp, Inkscape, Blender, Audacity... My point is that people see the success of open source and his early role as a vocal proponent and assume he was "critical," when the truth is more complicated, as his extreme formulation of completely "free software" has not done that well. It has not done well with corporations, but it has done very well with open source end-user software! Even projects that are not GPL tend to use LGPL code. Yet, Linux did manage to scare the juggernauts, so now even Microsoft is starting to publish under liberal licenses (first very restrictive, now very liberal). This is why you should generally only work on something you actually need, which is a great discipline. Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs. Well, yes. Unless you are designing a standard library. The original open source projects were mostly about recreating existing designs, but with a open source license. So the missing features were obvious. In the case of GNU (Unix), it is a cluster of individual small programs. So if people was unhappy they wrote a new version from scratch. And the most popular ones survived. Creative designs that went open source tended to be research projects... so you had a clear vision (and people who were experts in their field leading the design). So, the linked rant is pretty clueless IMO. You need to form consensus in order to gain focus. If you don't have focus you'll never end up with something coherent. If the author believed in what he wrote, then why did he write it? He obviously wrote it because he believe that communication can lead to change. And thereby he undermines his own argument... What brought original FOSS projects focus was the fact that they were not implementing original designs. And there has been LOTS of advocacy and arguments on usenet about every creek and cranny in software... since way before the Internet existed. So, it was an entertaining rant... and nothing more. For example, I asked about ARM and mobile support for D in 2011, noting that mobile was starting to take off and that people had been asking for ARM support periodically for years even prior to that. I was told it was one of many priorities, but nobody knew when it'd be worked on. Yes, and this is all good, but it is not a language issue. It fits well with what makes contributing to GNU/Unix easy. You can write an isolated piece. While this is not generalizable for all D PRs, ie nobody wants to maintain a fork of certain language features, it is for Several people have created their own languages because they have given up on the D development process... for dmd. Caring enough about a change to code it yourself is a good test for whether it is worth doing, which is one point the original post alludes to. Writing code without a fork, when you know it will be rejected, is pointless. Spending days or weeks on a DIP, in order to have it dismissed by a "nice technical DIP, but does not fit with our vision", is very wasteful. So people create their own languages instead, but without building consensus, meaning they end up in an incomplete state or being to close to D, having a different set of issues. Which is a key aspect of D's problem too, it is too close to C++ to not be compared to it. So fixing some issues and introducing others isn't good enough for adoption. Building consensus is very important. Just take a look at politics. Communicating a clear vision and a believable path to implementation is essential. And listening. Good leaders are always very good at listening, IMO.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote: would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP? For the most difficult/contentious issues, writing a DIP is just another form of arguing.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:35:27 UTC, tsbockman wrote: On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote: would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP? For the most difficult/contentious issues, writing a DIP is just another form of arguing. Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive.
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote: http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/ (His particular suggestion about accept patches by default is not why I post this). ' ... Hacking should be about making things. And yet a great many of our institutions are set up to discourage, distract, destroy, and derail the making of anything. It’s time we called it what it is: conduct unbecoming of a hacker. ' Great post, and very funny. Nick
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote: http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/ (His particular suggestion about accept patches by default is not why I post this). ' We’re all talk [...] On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote: [] Interesting timing! At my workplace we have a geekfest video session once a month and last week it was this: https://youtu.be/-F-3E8pyjFo It's worth a watch and it covers very similar ground. The presenters discuss their experiences developing subversion and other FOSS projects. bye, lobo
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 18:31:22 UTC, Nick Sabalausky wrote: On 02/10/2016 01:09 PM, Joakim wrote: Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. [Unimportant theorizing ahead...] I wouldn't say that's necessarily true: It could be argued the existence and proliferation of the Linux kernel reduced the priority of his Hurd work, even if only to a subconscious extent. If it hadn't been for the Linux kernel, maybe there would have been more drive (and more contributors) to Hurd. Also because context switching got from a handful of cycle at the time to about 1000 cycles on modern CPU, making the idea of microkernel somewhat less attractive. But saying Stallman released nothing is unfair. If we can consider hurd a failure, he was also behind emacs, early gcc and other things.
