Re: Vision document for H1 2018
On Friday, 16 March 2018 at 07:58:33 UTC, Dmitry Olshansky wrote: Playing captain the obvious but this is COPY not slice. Shh. Don't tell my customers that. D had slices since 2000s, pointing to any kind of memory. Mmm..D showing off.. as always ;-)
Re: Vision document for H1 2018
On Thursday, 15 March 2018 at 18:39:08 UTC, rumbu wrote:
My quote is out of context. Somebody asked surprised why C#
developers are interested in D. For me (mainly a C# developer),
this is the main reason: native compilation (and this includes
memory management). I highlighted the fact that the C# team
keep implementing D specific ideas in each new version, so
don't be surprised if your list of D exclusive features becomes
smaller with each new C# iteration. My complaint was the fact
that D drops features or push them into library solutions.
That was me ;-)
Yeah..native compilation is so nice..it's hard to resist.
And so is a good GC implementation (does D have one of those ??)
btw. run your C# or Java program for long enough, and it's
essentially native compiled anyway. When I run some of my java
programs, I still don't know how 'native compilation' would make
it go any faster (noticably). Same goes for my C# Windows Forms
apps..they just fly...native compilation wouldn't add much.
btw C# has had slices since day 1. Just required an extra
forklift or two - as opposed to taking it off the nearby shelf.
-
using System;
using System.IO;
public class Program
{
public static int Main()
{
int[] arr = { 1, 2, 3, 4, 5 };
int[] sliceOfArr = arr.Slice(2, 3);
Console.WriteLine(string.Join(", ", arr));
Console.WriteLine(string.Join(", ", sliceOfArr));
return 0;
}
}
public static class Utils
{
public static T[] Slice(this T[] arr, int start, int len)
{
T[] slice = new T[len];
Array.Copy(arr, start, slice, 0, len);
return slice;
}
}
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 19:09:42 UTC, Dennis wrote: On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote: This post may not be all that helpful, but I feel the need to voice the frustrations with my experience. Sorry for the pointless/off-topic rant. Thank you for this post, I found this actually really insightful. I'm also (relatively) inexperienced, a Windows user, and I have time/motivation for contributing. Your post is very relatable to me. But while you actually tried to compile dmd, I kind of pushed it aside after seeing how much there is involved in setting it up, predicting a big hassle like you describe. I really wish it could be as simple as cloning the repository and running a command on Windows. hey... I have 25+ years experience as a systems administator. i.e I'm very, very used to doing very complex things. complex, is my day at the office. But even I couldn't get my head around how to compile D from source on Windows ;-) I do have it compling just fine on my freebsd system, and multiple different linux's I use. But Windows? Forget it. Someone will need to explain in detail how that is actually done - I no longer have the patience for working that one out.
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 06:13:35 UTC, rumbu wrote: I'm comparing two open source projects, both hosted on github. Both available in the same supermarket. It seems that one of them is easy to reach to, the other one is on the top shelf and you need a forklift to reach it. And when you bring the forklift, you find out that you need two additional excavators running on a special kind of fuel which is not available in your country. I'm comparing the contributing experience, because almost every time when someone complains about something, is invited to contribute himself. yeah, but if you know in advance, that you need a fork lift to reach it, and that you'll also need two additional excavators running on a special kind of fuel, which is not available in your country...then..and only then.. are your expectations in line with reality ;-) but people come to D, thinking they can just walk over to the shelf and take it. (because that's often what they are used to). Some of us are actually used to the very opposite - i.e you always have make that extra effort, even to do the most simple things. But that effort just seems normal to us. I agree, there needs to be more middle ground, which both types will benefit from in the end.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. Hey.. I feel your pain.. I like things to be easy too ;-) but I think comparing things in the C# world, to things in the D world, does not make a lot of sense, really. It's like comparing my local corner shop to some worldwide supermarket chain. What's the point in going into the local corner shop and complaing that they don't stock this or that, but the supermarket down the road does. Or complaining that they charge $4 for a loaf of bread, when down the road at the supermarket it only costs $2.50. You have to compare apples with apples, not apples with shiny red toffee apples ;-)
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote: I am sure that lots of D members will be quick to point out, that C# is run by a commercial company and D has only open source contributors. Now why did you not contribute! /sarcasm I'd like to point out, that C# is run by a commercial company and D has only open source contributors. For that matter, so is Rust (a 1/2 billion $ organisation, at least), run by sjw's who will 'attack' (as opposed to 'point out') anyone that speaks out against anything. As for cross platform, have you tried running Rust in Windows XP? Anyway.. I'm going back to the sandbox, to play with my own toys.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote: My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly. OT: Interestingly, my uni is still stuck in the OOP paradigm, and is now teaching intro to OOP using .NET Core, cause it's now cross platform, and people can also used VS code, which also cross platform. but running > dotnet myprogram (.dll) is just an awful experience ;-) although, that's how java works to.. and java is probably the most widely used language of all.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 05:41:02 UTC, Dylan Graham wrote: I regret some of things I said. I'm sorry for any offence caused, specifically towards members of the DLF. I don't think you need to regret saying anything. You've demonstrated a willingness to engage in a conversation that we can *all* learn from. I also doubt anyone actually got offended ;-) .. we're all pretty strong minded here. But I get back to my point about "programmer" portability. Other developers of newer languages just don't seem to get that. And it's hardly surprising that D would be focused in some way, on languages used by the vast majority of programmers (C/C++/Java/C#... and dare I say it..python) That is D's great strength. (and betterc is just a part of it - and not one that particulary interests me). Because D resources are rather contstrained, betterc gets more push back than it really should. But the main take away point I get from that vision statement, is a greater focus on increasing contributions - which is really what D needs more than anything (apart from a correct and complete language specification).
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:58:50 UTC, psychoticRabbit wrote: i.e. How can the D Foundation encourage new additional resoures to focus on things that also matter to the community. and btw. the mention about strengthing the use of DIPS, does just that. there are many improvement to 'process' that can be done to encourage more people to contribute to D. This is not about betterc at all, really.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:53:30 UTC, Dylan Graham wrote: That sentence was to counter psychoticRabbit. I didn't mean it literally. If you've read my earlier posts, it's not BetterC I have an issue with, it's the allocation of time. Well that should have been the basis of your original argument. i.e. How can the D Foundation encourage new additional resoures to focus on things that also matter to the community. Instead, you started by attacking the D Foundation for allocating resources to betterc.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:46:09 UTC, Dylan Graham wrote: Rust was more popular and who could use that? Rust is popular because of its ideas, not because it pandered. I don't see "programmer" portability as being pandering. It common sense. Rust is good, in that it seeks to do something different. I like that. But I live in the real world, and need to switch between languages often. Language theory is nice and all that, but "programmer" portability is paramount for me.. not popular ideas. And Rust is popular... with Rust programmers.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote: The D Language Foundation, being the leading body of D, should hold some responsibility to the interests of the majority. And also the minority. A lesson that humanity has to learn over and over again.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote: I'm not sure what you mean at that last sentence. I mean, cause D is so compatible with C/C++/Java/C# - that you can easily switch between them. Whereas as Go and Rust have their own thing going, making those languages really difficult in terms of "programmer" portability. C++ became popular cause C programmers could easily use it. Java became popular cause C/C++ programmers could easily use it. C# became popular cause C/C++/Java programmers could easily use it. D is gradually becoming popular cause C/C++/Java/C# programmers can easily use it.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote: And "scripting" language like PHP, that everybody criticizes just keeps growing and gained 11% market share in the last 7 years ( at now 83% ). Where as D its gain has been minimalist thanks to people leaving almost as fast as it gain. Well, according to the TIOBE Index, C was the language of 2017. Java is almost always on top, followed by C, followed closely by C++. And it's not just 'old timers' using those languages... surely. And scripting language can pretty much replace any other scripting language. It's the 'real' programming languages that matter ;-) And D's not doing to badly at all...despite betterc https://www.tiobe.com/tiobe-index/d/ (although I wonder what happended back in 2009 ??)
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote: Point to the wall on the left side. That is what your talking to. D its focus on C++ as a bad plan has been made pushed by many people ( lots who left ). Its like asking Go for Generics. And its very nice to see the "71% in the poll do not want BetterC", well, screw them comment. So what is the point again by asking people opinions? And sure, BetterC can be reused to improve the D core but that is not what people want NOW. And yet, its a priority when 71% say its not! D simply is not equipped for dealing with people who come from languages like C#, Ruby, PHP, Python, ... because too many people here are C++ old timers ( yes, there are exceptions ) and they only think in that direction. There is a lesson the be learned in this somewhere... Again, D is not run by some corporation. Nor is it a democracy - where majority rule. (read this sentence over and over till you get it) It's a language that develops because people are sufficiently motivated to put in the time to develop what interests them. Have your say and leave it at that. Stop attacking the work others are doing. And stop your discriminatory use of the phrase 'old timers'.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote: Every day D becomes more like C++ 2.0, why can't it just be D? Oddly enough, I think this is D's strength. Golang tried to draw the line, and look where that got it. Now it's a limited language for a specific domain (at least until Go 3.0). Rust decided (and Go to some extent), to introduce foreign syntax that was vastly different to what the majority of programmers are familiar with, and, it makes it difficult to transistion to because its syntax is so unlike the syntax most people will continue to have to work with. D's strength, is that most C/C++/Java/C# programmers can just jump right in and use it. And, they can continue to go back and forth without syntax related psychosis developing. betterc is just another way of supporting that crowd..and it's a very big crowd. Your problem is not betterc, but something else. So focus on that instead. And personally, depending on the problem, C# is better to program in than D. I still don't know why C# programmers are willing to give up C# and prefer to use D. C# is vastly surperior for what it does. D is also particulary useful for some problems. Better to use both, not one or the other. Thanks to not being Go or Rust, you can do that - cause concepts, syntax etc, are really compatible with both.
Re: Vision document for H1 2018
On Saturday, 10 March 2018 at 11:45:25 UTC, rumbu wrote: I'm talking about the D Foundation priority list, not about the open source community surrounding it. I have nothing against betterC, the community is free to work on it, but I don't understand why it's a *priority* for the D foundation. Is there any funding involved requesting explicitly betterC support? perhaps this question can be one of many, that the community ask the members of the D foundation, on stage, during the Q and A at the upcoming Dconf ;-) there will be a roasting.. won't there?
Re: Vision document for H1 2018
On Saturday, 10 March 2018 at 11:45:25 UTC, rumbu wrote: I'm talking about the D Foundation priority list, not about the open source community surrounding it. I have nothing against betterC, the community is free to work on it, but I don't understand why it's a *priority* for the D foundation. Is there any funding involved requesting explicitly betterC support? I think cause interoperating with C/C++, as well as encouraging migrating C/C++ code over D..has always been a key objective for Andrei and Walter (as least that's the impression I get - as a relative newcomer to D). So I doesn't surprise me that it would be (remain) a priority for the D foundation, which they (and others) represent. All power to em... Although... I'm just not convinced that C programmers will give up C, and C++ programmers will give up C++ ... well... certainly I don't see any mass migration on the horizon of my crystal ball. Everyone will end up programming in C++, Java, or .NET .. says the crystal ball.
Re: Vision document for H1 2018
On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote: According to the State of D Survey, 71% of the respondents don't care about betterC. Why is betterC on the priority list? who cares what 'the majority' want... I mean really. stuff em! (ohh... that was in jest.. don't take that seriously)
Re: Vision document for H1 2018
On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote: Yeah. Why should D worry about tying itself into C when it can't even interface with itself through DLLs? A reasonable point. But.. in any case.. people work on what they are motivated to work on. That's really all there is to it. That's how the open source community works. Top down, corporate direction, simply does not apply here. One day you (or some other D programmer) might need betterC - who knows - and it'll be there for you - cause someone else was motivated to do it.
Re: Vision document for H1 2018
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu wrote: Hello, the vision document of the Founation for the first six months of 2018 is here: nice. andd that 'langauge specification' is really important too.. or people will drift towards languages that 'are' properly specified. None of us like to be surprised by what the compiler does. The spec should tell it what to do. and...just don't implement a 'no hugs' policy, or I'm outta here ;-)
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote: Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us? That's the day I stop using D. I do not, and will not, use dub. Full stop. Same goes for Rust ;-)
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 07:11:24 UTC, Jonathan M Davis wrote: That example actually should be perfectly @safe, because the array is null, and it's using writeln. Dereferencing null is @safe, because it segfaults and thus can't corrupt memory or access invalid memory. You obviously don't want it to happen, but it's @safe. Also, passing a pointer to writeln is fine, because it's just going to print the value, so that's @safe too, even if the pointer value is garbage. my point had nothing to do with writeln. my point was, that a RangeError exception may help save the day, but not when you use .ptr thankfully Steven gave a much better example to make the point clearer ;-) (I assume that int is meant to be size_t)
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote: Can somebody explain how [0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore. int[] a; writeln([0]); // good - runtime produces a core.exception.RangeError //writeln(arr.ptr); // what do you think will happen here?
Re: Release D 2.079.0
On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote: I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila Fair enough. Doing better is always a good thing to aim for. But really, who use something 'just released' in production? As far as I'm concerned, every release is a beta... even if the beta tag is removed. The real problem is something you mentioned .. new comers downloading the latest release..which as I mentioned, is really a beta. But that's just the way software developement works these days - sadly - ship quickly, and ship often. As a result, we're all just testers for the latest release.
Re: Release D 2.079.0
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote: Glad to announce D 2.079.0. This release comes with experimental `@nogc` exception throwing (-dip1008), a lazily initialized GC, better support for minimal runtimes, and an experimental Windows toolchain based on the lld linker and MinGW import libraries. See the changelog for more details. Thanks to everyone involved in this https://dlang.org/changelog/2.079.0.html#contributors. http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html - -Martin Well done to all! (especially the work on the toolchain) I'm going to download it and test that import syntax thingo...just to make sure it really is gone ;-)
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 12:20:31 UTC, Paulo Pinto wrote: And if you like C so much, what are you doing in a safe systems programming language forum? How safe is D.. i mean really ;-) and why do people ask me that question.. I don't get it. I program (or try to) in as many languages as my brain can handle ;-) (which oddly enough, seems to be stuck at about 7)
Re: [OFF TOPIC] State of D 2018 Survey
On Friday, 2 March 2018 at 13:05:58 UTC, Russel Winder wrote: Science, in and of itself, cannot be dodgy. science must involve humans, and humans are often dodgy. Yes there are debates to be had, cf. Popper, Kuhn, etc. but the foundation of science is hypotheses, experimentation, and reproducibility. It can be done badly or well by people, but it is not a dodgy thing. there is no science without humans - they are two sides of the one coin. If humans can be dodgy, so can science. Perhaps you do not, but Rust, like Go, is getting traction in the world out there. Like COBOL, C will always be there, but its use will diminish rapidly. Only when hardware becomes significantly faster, will C begin to fade, as then the case for C diminishes. I do like the simplicity of Go - and then there are days when I just hate that simplicity. That R?s? thing...well...it is too odd for most people to embrace, I think It is worth keeping an eye on .NET - as Microsoft are very determined to make this a cross platform runtime, and programming in C# is just .. nice. And if I recall correctly, Java and .NET still dominate the employment opportunities, and as 'safety' is becoming even more and more important, I think that is likely to stay that way for a long time to come. So I think all these new languages will just be playgrounds for ideas, or become domain specific languages, while .NET and JAVA use will continue to increase.
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 12:02:43 UTC, Russel Winder wrote: On Fri, 2018-03-02 at 11:52 +, Russel Winder wrote: […] report science, does make science dodgy. But that stray off topic for […] s/does/does not/ Obviously. :-) mmm...freudian slip?? I study science...and what's being taught to us .. is dodgy. and anyway, since when do D forum discussion stay on topic? C ruleZ! ..and D does too ;-) ... and I don't want to hear about Rust. So lets agree to never, ever mention that word...ever again.
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 11:00:09 UTC, Jonathan M Davis wrote: In any case, I expect that anyone who wants D3 is going to have a very hard time convincing Walter and Andrei that such large breaking changes would be worth it at this point. - Jonathan M Davis I agree. I don't think there is enough to warrant a D3 at this point. But still, imagine if every time an architect built a house, it had to be built using the same specs as the previous house. You'd end up with garbage, piled upon garbage. In essence, you'd get C++. So exploring ideas around what a new design might look like, can be useful too, so let's not discourage that by talking about 'forking' concerns.
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 10:21:05 UTC, Russel Winder wrote: ...continue with C in the face of overwhelming evidence it is the wrong thing to do. yeah, the health fanatics who promote their crap to goverments and insurance agencies, use very similar arguments about sugar, salt, alchohol, this and that when really, it's all about moderation, not prohibition (or increased taxes on things people say are bad). and science is so dodgy these days, that even scientific evidence requires evidence. c rules!
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 03:57:25 UTC, barry.harris wrote: Sorry little rabbit, your are misguided in this belief. Back in day we all used C and this is the reason most "safer" languages exist today. You can write pretty safe code in C these days, without too much trouble. We have the tooling and the knowledge to make that happen.. developed over decades - and both keep getting better, because the language is not subjected to a constant and frequent release cycle. Ironically, the demands on programmers to adapt to constant change, is actually making applications less safe. - and least, that's my thesis ;-) The real problem with using C these days (in some areas), is more to do with its limited abstraction power, not its lack of safety. And also C is frowned upon (and C++ too for that matter), cause most programmers are so lazy these days, and don't want to write code - but prefer to just 'link algorithms' that someone else wrote. I include myself in this - hence my interest in D ;-) Keep those algorithms coming!
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 02:35:46 UTC, Meta wrote: D1 -> D2 nearly killed D (can't remember which, but it was either Walter or Andrei that have said this on multiple occasions). A D2 -> D3 transition might generate a lot of publicity if done very carefully, but more than likely it would just put the nails in the coffin for good and destroy all the momentum D has built up over the past 3 years (I feel like 2015 was a big turning point where D finally got back on peoples' radars). I've read a bit about that history, but really, sometimes you have to be agressive with change or just it won't come about. And I don't see how D2 could have come about without an agressive push for change. And it's unlikely that D would have died. Some people might have left (and probably did). But D is better because it's D2. Imagine promoting D1 to the world! D3 could be even better. (e.g. @safe by default..just for starters). And I personally think all this ongoing integration with C and C++ is not ideal. It's creating a really complex beast, that has to be maintained indefinitely... by someone. So I'd like to see D3 dump all the compatibility crap ;-)
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 02:02:42 UTC, psychoticRabbit wrote: btw. I never said 'stop changing', I said "I wish programming languages would just stop changing so often." I'd also argue, that languages that are relatively stable, are far 'safer' than languages that constantly change. So given that the world is so focused on developing a variety of so called 'safer' languages, with ever rapid, frequent, release cycles, the world would actually be alot 'safer' if everyone went back and programmed in C ;-)
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 01:19:53 UTC, H. S. Teoh wrote: Because it has not stopped changing. To wit: K C (1978) C89 / C90 / ANSI C (1989-1990) The 1995 amendment to ANSI C (1995) C99 (1999) (Embedded C (2008)) C11 (2011) T btw. I never said 'stop changing', I said "I wish programming languages would just stop changing so often." And that last update to C, in 2011, was 7 years ago.. relative stability is a sure sign that something is right. constant, regular, change is a sure sign that something is wrong. And if stability were not the preferred state towards which things evolve, then the universe would be a very different place indeed.
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 00:53:02 UTC, H. S. Teoh wrote: On Fri, Mar 02, 2018 at 12:39:08AM +, psychoticRabbit via Digitalmars-d-announce wrote: [...] On the otherhand, I wish programming languages would just stop changing so often. [...] Change is inevitable, except from a vending machine. :-P The day a language stops changing is the day it begins to die. T C will never die !!
Re: State of D 2018 Survey
On Thursday, 1 March 2018 at 21:49:31 UTC, Jonathan M Davis wrote: That being said, I think that it's a given that we need to make breaking changes at least occasionally. The question is more how big they can be and how we go about it. Some changes would clearly be far too large to be worth it, whereas others clearly pay for themselves. The harder question is the stuff in between. ... - Jonathan M Davis Personally. I think the D1..D2 transistion was great idea. I think D2..D3 should follow the same principle. i.e restrict breaking changes to major versions. People are always able to stay on the major branch that they need - there are no forced upgrades here - you choose which major branch works for you. The source code is all there for you, to do as you please. This is the only way to evolve - otherwise D will just become another convoluted piece of %3@f!, like C++. On the otherhand, I wish programming languages would just stop changing so often. The constant release cycles is just crazy! That's a sure sign that something is not right. And who wants to program in a langauge that is not right?? That's why I still like, still use, and typically still prefer .. C. Nobody dares change it ;-)
Re: Documentation for any* dub package, any version
On Tuesday, 27 February 2018 at 02:57:08 UTC, Adam D. Ruppe wrote: Saturday morning, a user complained that several leading dub packages had poor documentation, if they could find it at all. That's changing, right now. Before long, packages without docs are going to suffer. This will put pressure on authors to have *something* written, and I'm providing the lowest cost for greatest benefit to help your package succeed in the market. Uhh? I don't get...why coders need to write documentation? .. it doesn't make any sense. stop this nonsense... at once!
Re: Beta 2.079.0
On Saturday, 24 February 2018 at 07:09:05 UTC, zabruk70 wrote: i don't understand whole theread. why all import must be written on one line? curent syntax very handy and readable. you must have understood the thread, cause you summarised it pretty well ;-)
Re: Beta 2.079.0
On Friday, 23 February 2018 at 16:03:56 UTC, Aurélien Plazzotta
wrote:
Perhaps, we could use Backus-Naur notation, as it is already
widely known into formal documents all over the globe, like the
following:
import std.stdio, std.whatever{this, that}, std.somethingelse,
std.grr{wtf};
That is with curly brackets instead of square brackets like you
suggest :)
Yeah...again.. I'd prefer to not to have to think differently
about syntax, just for writing imports. That's why I'd prefer to
just think of them as arrays using D's array like syntax.
import std.stdio [writeln, write = cwrite, writefln],
std.whatever;
I'm not sufficiently motivated to do anything here anyway, as I
don't believe a case for change can really be justified - cause
how many imports can you realistically include on a single line
anyway?
The current way is just fine, and provides really good clarity
for what's going on.
But I would (and am) very, very motivated to oppose introduction
of an obscure, confusing, or foreign syntax.
The real motivator for the change, as i see it, seemed to be
related to thinking that the imports section was not really for
human consumption - which it not true at all. The second motivate
seemed to be related to saving a few keystrokes or line space.
Again, human consumption should take priority here in my view.
Anyway, the point is moot at this point - since the change is
being reversed and nobody seems motivated to push it again. Which
is just fine with me ;-)
Re: Beta 2.079.0
On Friday, 23 February 2018 at 23:46:02 UTC, Norm wrote: Well, D is already a compiled scripting language :) technically (and otherwise) that is not correct...thank god! lets keep it that way.
Re: Beta 2.079.0
On Friday, 23 February 2018 at 18:13:51 UTC, Patrick Schluter wrote: On Friday, 23 February 2018 at 13:42:45 UTC, psychoticRabbit wrote: On Friday, 23 February 2018 at 12:06:23 UTC, Patrick Schluter wrote: Absolutely. D scripting is the trojan horse that enables introduction of it in hostile environment. Runnable compiled source code is nice. scripting languages is reinventing computer science.. only really badly. No, scripting languages is about getting shit done... that's exactly the problem. we're all to focused on getting 'shit' done ;-)
Re: [Maybe OT] Hashcode with Google
On Friday, 23 February 2018 at 14:07:03 UTC, Andrea Fontana wrote: It could be interesting if a D-team would win this :) tl;dr: Google gives a coding problem, you have to solve it. Any programming language is accepted. You have to register your team. Details: https://hashcode.withgoogle.com/overview.html Previous problems: https://hashcode.withgoogle.com/past_editions.html Andrea Fontana seriously...hasn't google got a big enough foothold on the world? do we all need to keep encouraging it by particpating in its self-promoting, self-advertising ventures? google are masters of social engineering and the psychology of the gift economy. so I ask, what's the catch this time? oh.. you need to create a google account first it seems. Then they've got you, and all your data too.
Re: Beta 2.079.0
On Friday, 23 February 2018 at 12:06:23 UTC, Patrick Schluter wrote: Absolutely. D scripting is the trojan horse that enables introduction of it in hostile environment. Runnable compiled source code is nice. scripting languages is reinventing computer science.. only really badly.
Re: Beta 2.079.0
On Friday, 23 February 2018 at 09:48:33 UTC, Norm wrote: This import feature and surrounding discussion I couldn't care less about ... I actually spend far more time reading large chunks of code, than writing code, and I certainly do NOT want to spend extra time deciphering imports, due to an unpopular and confusing syntax change. If I were mainly writing 'scripts', then I too would probably not care less ;-) If D just wants to become a compiled scripting language...good luck to it. I'll go find a proper progamming langauge long before that happens.
Re: Beta 2.079.0
On Friday, 23 February 2018 at 03:26:11 UTC, Seb wrote: On Friday, 23 February 2018 at 03:20:22 UTC, psychoticRabbit wrote: compared to the current change in beta. FWIW the change is almost gone from the beta: https://github.com/dlang/dmd/pull/7939 I'm glad common sense seems to be winning ;-) This is a good case for 'review of process' I think. The original request for change was very flawed, in that it presupposed "importing as an expenditure that should be minimized.". I think that is highly debatable, and more people should have had the opportunity to comment on that. Second, none of the proposed syntax options was sufficiently clear, for the brain to chunk into its components. This is a serious issue and should be of greatest priority when introducing changes to syntax (no matter how small the change). Changes to syntax need to be tested widely, for precisely this reason. You can do whole Phd's on this topic. Third, making D more and more like a quick scripting/hacking language (by removing or hiding so called 'noise', is not a good idea in my opinion. That too seemed to be a motivator for at some aspect of the change.
Re: Beta 2.079.0
On Friday, 23 February 2018 at 02:31:34 UTC, Jonathan M Davis wrote: We deprecate stuff when we need to, but every time we deprecate something, it breaks code (even if it's not immediate breakage), so the benefits that come from a deprecation need to be worth the breakage that it causes. Every D program on the planet which isn't completely trivial uses imports, and many of them use selective imports. So, you're talking about breaking a large percentage of the existing programs for a syntax change. That's not likely to go over well. Large breakage like that can be acceptable when it clearly fixes bugs but not just for aesthetics. - Jonathan M Davis oh..and really, there should be no need to deprecate anything here anyway. surely D can handle the current way of doing imports (not including that rubbish in beta), and also a new way for those that want to use it, or those that want put stuff on a single line. import std.stdio, std.whatever[this, that], std.somethingelse, std.grr[wtf]; This new syntax that I'm proposing (after reviewing discussions here) seems like a sensible change. It's very easy for the brain to chunk into components (unlike that rubbish in beta), and it introduces thinking about 'selective imports' as just being an array of selections, using the same array like syntax used elsewhere in D. I would be interested to see what controversy would result from this new proposal, compared to the current change in beta.
Re: Beta 2.079.0
On Friday, 23 February 2018 at 02:31:34 UTC, Jonathan M Davis wrote: We deprecate stuff when we need to, but every time we deprecate something, it breaks code (even if it's not immediate breakage), so the benefits that come from a deprecation need to be worth the breakage that it causes. Every D program on the planet which isn't completely trivial uses imports, and many of them use selective imports. So, you're talking about breaking a large percentage of the existing programs for a syntax change. That's not likely to go over well. Large breakage like that can be acceptable when it clearly fixes bugs but not just for aesthetics. - Jonathan M Davis yeah I do agree. I'd prefer no change. I don't really see the need. On the otherhand, if change is coming, lets make it a sensible change ;-)
Re: Beta 2.079.0
On Friday, 23 February 2018 at 01:53:45 UTC, Martin Nowak wrote:
On Friday, 23 February 2018 at 01:16:24 UTC, Jonathan M Davis
wrote:
I can sympathize with wanting to avoid bikeshedding, but
almost no one who has posted thinks that this is a good idea.
This was meant for the discussion of a new syntax for selective
imports like `import mod : { sym1, sym2 }` which seems like too
much churn to be worthwhile.
import mod : { sym1, sym2 }
thats not nice syntax - for these reasons:
first, why is the : needed? {} is enough to enscapsulate the
intention.
second, why are using {} instead of []
[] would allow me to think of selective importing, as though I
were importing an array of selections.
e.g:
import std.stdio, std.whatever[this, that], std.somethingelse,
std.grr[wtf];
so using [] would be consistent with using array like syntax
elsewhere in D, and would require no additional effort to think
about.
Re: Beta 2.079.0
On Friday, 23 February 2018 at 01:17:26 UTC, psychoticRabbit wrote: On Friday, 23 February 2018 at 01:02:59 UTC, Martin Nowak wrote: Interesting, you have a good example? yeah..phobos. I learn most about the various phobos libraries, and their usefulness, from looking at the various imports that phobos modules use. If they just used import *; I'd have no idea what was going on. and worse, if phobos used this new so-called 'optional' syntax...then I'd probably have switched to another language by now. import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1; I don't have the patience to decipher stuff like that.
Re: Beta 2.079.0
On Friday, 23 February 2018 at 01:02:59 UTC, Martin Nowak wrote: Interesting, you have a good example? yeah..phobos. I learn most about the various phobos libraries, and their usefulness, from looking at the various imports that phobos modules use. If they just used import *; I'd have no idea what was going on.
Re: Beta 2.079.0
On Friday, 23 February 2018 at 00:47:10 UTC, psychoticRabbit wrote: On Friday, 23 February 2018 at 00:14:21 UTC, Walter Bright wrote: On 2/22/2018 1:56 PM, H. S. Teoh wrote: I'm a little disappointed that a change like this got in, whereas something that's actually helpful, like DIP 1009, is sitting in limbo. It's always true that trivia attracts far more attention and far more emotion than issues that require effort to understand. Umm...this requires effort to understand (much more than it should) : import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1; Can anyone see why this created attention? If can you don't know the answer, it's because it "requires effort to understand".
Re: Beta 2.079.0
On Friday, 23 February 2018 at 00:14:21 UTC, Walter Bright wrote: On 2/22/2018 1:56 PM, H. S. Teoh wrote: I'm a little disappointed that a change like this got in, whereas something that's actually helpful, like DIP 1009, is sitting in limbo. It's always true that trivia attracts far more attention and far more emotion than issues that require effort to understand. Umm...this requires effort to understand (much more than it should) : import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1; Can anyone see why this created attention?
Re: Beta 2.079.0
On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote: Unfortunately it's a bit hard to find arguments in the discussion below, would have been cool if there were a few well argumented comments instead dozens of +1s. Go back and read all of this thread, properly. - this grammar is ambiguous Isn't that an argument? It has always been in various ways and that's annoying to learn when you first deal with D. Personally I find it even more annoying that you can mix imports and selective imports, but only in a very specific exception. - why not X instead Aren't alternative ideas welcome? Go for it and try to find a consensus. I don't think the issue is big enough to warrant a huge design and bikeshedding discussion. Some don't agree with you. That's your opinion, my opinion is that importing 6 symbols from 6 different modules for a tiny cli tool sucks and bloats code example. That's your opinion. Indeed an alternative with a similar goal, reducing the amount of typing/noise for hacking. You seem overly eager to save some typing, and the expense of comprehension. I don't get it. That's what bring programming languages into disrepute. - why hasn't this been a DIP Because it looked primarily like a minor grammar rectification that doesn't break anything and is entirely optional. Go back are read the 'arguments' are but 'optional' aspect. Also DIPs are a crucial process for our language, and it seems problematic to clog it with trivialities. This doesn't seem that trivial based on the discussion. On the other side please note that: - you don't have to use it - it will unlikely land in phobos' style-guide - it's useful for talks, posts, code puzzles or on a repl where code is size constrained - there is no ambiguity or chance for bugs - practical examples of this usage are hardly confusing import std.stdio : writeln, std.algorithm : find; Seriously? You came up with the simplest example to demonstrate you're argument? - remember that some people use `import mod1, mod2, mod3, mod4;` at least sometimes while others prefer each import on it's own line - imports are mostly for tooling, less for humans That's your opinion. I happen to think that imports help people discover where stuff resides. I've learnt a lot from looking at imports used. - many java editors collapse the import manifest at the top - a lot of languages have an import std.* operator or auto-imports That's why nobody know where anything is in the their library. And last but not least, the simpler the topic the more opinions, so please refrain from "I don't like it, +1" and leave space for actual arguments. Again, go back and read this thread properly, and don't be so dismissive of the concerns people have expressed.
Re: Beta 2.079.0
On Thursday, 22 February 2018 at 13:35:00 UTC, aliak wrote: Given that comma is implemented already, and barring a revert, can we maybe somewhat unbreak it by allowing: import mod1: write, .mod2; So leading dot to say it's a module (if not fully qualified) leading dots?? grr!! I doubt change can be easier, clearer, or nicer to look at, than: import std.rabbit [food, water], std.house, std.family [carer]; I would support that syntax 100%. Nothing else I've seen would get that level of support from me.
Re: Beta 2.079.0
On Thursday, 22 February 2018 at 10:42:46 UTC, Daniel Kozak wrote: I still believe it should be something more readable: import std.stdio, std.conv : [ to, from ], std.algorithm : doSomething, std.whatever; yeah.. nice.. though we can make that even easier by dropping ":" i.e. import std.rabbit [food, water], std.house, std.family [carer];
Re: Beta 2.079.0
On Thursday, 22 February 2018 at 08:42:12 UTC, psychoticRabbit wrote: import std.stdio:write,writeln,writefln & std.array:join,split,replicate; vs import std.stdio:write,writeln,writefln,std.array:join,split,replicate; and the rule would be simple. you can import modules on a single line, seperating each with a comma. however, an & instead of a comma seperates selective imports from the subsequent import. import std.stdio, std.algoritm: goDoStuff, goDoMoreStuff & std.conv, std.whatever; actually, the more I do that, the less I like it. I would still prefer selective imports to be on their own line: import std.stdio, std.conv, std.whatever; import std.algoritm : goDoStuff, goDoMoreStuff; but in simple case I might use it all on one line: import std.stdio: write, writeln & std.algorithm: doStuff, doSomeOtherStuff; but once introduced, programmers will misuse it - guaranteed. then will just be spending more of our time deciphering import statements.
Re: Beta 2.079.0
On Wednesday, 21 February 2018 at 16:58:22 UTC, H. S. Teoh wrote:
On Wed, Feb 21, 2018 at 02:46:56PM +, psychoticRabbit via
Digitalmars-d-announce wrote: [...]
Syntax is EVERYTHING. It can make or break a language.
And semantics doesn't matter.
:-D
T
assert("easy on the eyes" == "easy on the brain");
wtf! I get an assertion failure??
programming languages are just dumb tools to write syntax ;-)
the semantics are in a different domain.
Re: Beta 2.079.0
On Wednesday, 21 February 2018 at 15:33:02 UTC, Joakim wrote: I thought about chiming in on that PR when it was open, but didn't because the vote was split at 5-5 and I thought it wouldn't get merged. Also, I'm not against the idea in principle, but I do wish you'd chosen better syntax, such as not reusing the comma to split modules too. I don't have a better separator suggestion though, `|`? How about the plain obvious? import std.stdio:write,writeln,writefln & std.array:join,split,replicate;
Re: Beta 2.079.0
On Wednesday, 21 February 2018 at 10:15:48 UTC, Jonathan M Davis wrote: On Wednesday, February 21, 2018 10:04:01 Kagamin via Digitalmars-d-announce wrote: On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote: > Yeah, personally I'd avoid writing it that way too. There's no other way to use this feature though. Some of us think that it's a bad feature and have no intention of ever using it, though once it's in the language, we all have to worry about dealing with code that does use it. - Jonathan M Davis +1000 how on earth can anyone approve, that syntax like that, can become part of the D Programming language? I'm really bewildered. Syntax is EVERYTHING. It can make or break a language.
Re: The Expressive C++17 Coding Challenge in D
On Wednesday, 14 February 2018 at 09:50:31 UTC, Ola Fosheim Grøstad wrote: If C++ isn't viewed as a competitor, why bother with repetitive complaining about C++? Because it doesn't get enough criticism ;-) I believe the programming langauges of the future, and the ones people should invest their time learning, are those that can be best understood in the least amount of time. This is because programs are getting larger and more complex, and to understand them at all, they have to be simple to understand. C++ is not simple. It never has been. The so called 'modernisation' of it is not helping me to change my mind about it ;-) And chances are, when you go to work in some C++ environment, you'll have to deal with lots of legacy style code - which you will be expected to understand as well. It's time to stop 'improving' C++ and redesign it from scratch - or move to D.
Re: The Expressive C++17 Coding Challenge in D
On Wednesday, 14 February 2018 at 08:53:31 UTC, drug wrote: 14.02.2018 11:45, Ola Fosheim Grøstad пишет: On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d It's mostly targeted at beginners as I explain many basic D features, but maybe it's helpful for beginners looking into D. Sadly, he just picked the solution that used most C++17 features and not one that was clean and compact... :-/ I guess the point was to create a C++17 tutorial, and not a coding contest as such. It's sadly that using most C++17 features fails to provide clean and compact solution... yeah.. even the more modern C++ code still makes me want to stay clear of it...(perhaps even more so). I just never get the same feeling when I look at D programs.
Re: The Expressive C++17 Coding Challenge in D
On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d It's mostly targeted at beginners as I explain many basic D features, but maybe it's helpful for beginners looking into D. What a great article! I love the depth of explanation too, that really makes it worthwhile reading.
Re: Vanquish Forever These Bugs That Blasted Your Kingdom
On Monday, 12 February 2018 at 06:28:15 UTC, Dmitry Olshansky wrote: Then pick assembly of sorts. C ABI is a stright-jacket that ensures e.g. that your callstack is laid out correctly so that a ‘ret’ will bring you back to the call site not somewhere else. Do I need to mention libc’s machinations done “for compatibility”. Who the fuck were these guys to steal the pleasure of misaligned stacks and wrong push/pop order? Or register save missed? The reality is we are programming on top of increasingly complex run-times that solve low-level problems to certain extents. That includes C (even w/o libc) and pretty much any other high-level language. -boundscheck=off D rocks! "D is in a conflicted position regarding the bounds checking conundrum. The language is trying to offer at the same time the safety and convenience of modern languages and the ultimate unmuffled performance sought by system-level programmers. The bounds checking issue implies a choice between the two, and D allows you to make that choice instead of making it for you." [ Andrei Alexandrescu - The D Programming Language, 2010] (again) -boundscheck=off D rocks!
Re: Vanquish Forever These Bugs That Blasted Your Kingdom
On Monday, 12 February 2018 at 07:10:42 UTC, Cym13 wrote: As someone who's job is to audit banking and governmental systems for security vulnerabilities, I can assure you it's a real issue. Not the most common one, okay, but that doesn't make it any less dangerous. humans auditing the work of humans - what could be more dangerous than that ;-)
Re: Vanquish Forever These Bugs That Blasted Your Kingdom
On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky wrote: Other languages like Rust or C# (or Java) have bounds check. Plus we probably lose it in release mode, which is the mode where lurking bugs are discovered usually days after development ;) Some of these languages would prevent it on the VM level/compiler level, leaving no way to shoot yourself in the foot. We all really need to get away from this idea that *we* should stop *others* from shooting themselves in the foot. People are free to do it, if they want. Who has the right to take that choice away from me? So let's NOT be like those other languages that just want to control what you do. -boundscheck=off D rocks!
