Re: D as a college language
On 06/05/2018 1:35 PM, Seb wrote: On Friday, 4 May 2018 at 11:35:22 UTC, Sjoerd Nijboer wrote: So i'm a college student in and what bothers me is that there seem to kind of assume programming languages don't evolve or don't get replaced by better ones. Right now if you go to college you'll most likely get tought c++, c# or java for any comp sci degree. While these languages are industrial standards, they all have their drawbacks. And one drawback that looks important for teaching is flexibility in expressiveness. [...] @ everyone in this discussion: you ask and answer the wrong question. The question needs to be: "What can we do or improve upon to allow D playing a bigger role in education?" The answer to that is simple: We need to create a couple of qualifications. 1) Hard CS theory meant for existing developers in industry 2) Introduction to programming covering most aspects that they would face Make the material, make the path ways, and make it simple for institutes and standard bodies to adopt. We cannot do this alone. We need help. We need professional institutes like ITP to assist us in our cause of teaching the next generation of programmers (D is just a tool in this goal).
D4M In D?
http://www.mit.edu/~kepner/D4M/ Anyone?
Re: D as a college language
On Saturday, 5 May 2018 at 15:13:34 UTC, Russel Winder wrote: In that C is a portable assembly language and Java is an object-based language supporting some forms of polymorphism they are very different, but they are far from extremes. Come on, the difference between C and Java is far more than that. The differences are so extreme actually, that undergrads deserve to be introduced to both. Introducing python to undegrads is an abomination! Introducing D to undergrads is problematic, since D is an unprincpled mix of pretty much everything - and more to come (which is good in some sense, and bad in another sense). D is the swiss army knife of programming langauges. What is great about D, is how it integrates it all into one tool, making it easier to use those tools. But IMO, D is not ideal for undergrads, as it's a little too unprincipled - and undergrads needs principled approaches when starting off. In addition, the syntax of C and Java is not too different, so undergrads can switch from one to other other without too much drama. Imagine switching between C and Go, or Java and Go, or Java and Python etc..etc. C and Java provide the greatest learning experience for undergrads, IMO, and at the least 'cognitive' cost. Python should be banned! Cut of it's head!! Hopefully this is a troll, and you don't mean that. No. I do mean it. Python has no place in an undergrad course. As someone intimately involved with a university for many, many years, I have to wonder whether teachers are the problem, rather than the solution ;-) I can't speak with direct evidence for the last decade but certainly till then far too many academics in the UK couldn't really program well at all. The whole university system militates against programming as something an academic is good at. Fortunately there seem to be just enough academics who can program well, at least in the top universities, that the programming courses do actually get taught well. Of course with programming moving from university to school (6 to 18) the problem shifts from academics to school teachers. The thing is, those teaching in uni are not really 'teachers'. They are usually just filling in time, to earn some extra money or whatever, while continuing their studies or research. Very few actually know how to 'teach', and even few are motivate to 'teach'. Undergrads can learn a great deal more from just buying some good books (or even a single good book). Perhaps this is why programming should be 'taught' before students reach uni, and then they can focus on doing more productive things when they get to uni, rather than learning how to write a for loop, or move circle around the screen!
Re: D as a college language
On Friday, 4 May 2018 at 11:35:22 UTC, Sjoerd Nijboer wrote: So i'm a college student in and what bothers me is that there seem to kind of assume programming languages don't evolve or don't get replaced by better ones. Right now if you go to college you'll most likely get tought c++, c# or java for any comp sci degree. While these languages are industrial standards, they all have their drawbacks. And one drawback that looks important for teaching is flexibility in expressiveness. [...] @ everyone in this discussion: you ask and answer the wrong question. The question needs to be: "What can we do or improve upon to allow D playing a bigger role in education?"
Re: D as a college language
On Friday, 4 May 2018 at 11:35:22 UTC, Sjoerd Nijboer wrote: So i'm a college student in and what bothers me is that there seem to kind of assume programming languages don't evolve or don't get replaced by better ones. Right now if you go to college you'll most likely get tought c++, c# or java for any comp sci degree. While these languages are industrial standards, they all have their drawbacks. And one drawback that looks important for teaching is flexibility in expressiveness. From my experience college students seem to have problems translating their often declarative thought process into actual semi compile-able code that runs in a given language. Since D seems to be a language that supports a lot of programming paradigms very well, wouldn't it be beneficial to learn people declarative programming using D for a little and from there expose them to other programming styles in thesame language to lower the barrier of entry? I think D could play a bigger role in education since its such a "clean" language that is flexible but doesn't have any real gotcha "features". Its also a language that could potentially be used over someones entire college career as the primary language. If this would be achieved there would be a higher income flow into the industry of young D programmers which will pollute other programmers with the D mind and featureset. I thought it might help if I mentioned that I successfully used D as one of three languages to teach the Programming Languages course at Vassar College last Fall. The main reason I ended up using three languages was this: 1. Most undergraduate CS courses that I sampled (at UW, for one taught by Dan Grossman, among others) use a core functional programming language such as (S)ML which really helps in solidifying some of the principles of programming languages—the concept of environment, scope, binding; functions as values; curry, filter, map, etc. Plus it has a version that comes with a REPL and really helps students explore it. That said, it is not a "industrial strength" language, and since I also wanted to empasize on the pragmatic aspects, it could not be the only one. 2. I briefly introduced the concept of logic programming using Prolog, but I couldn't really spend too much time on it and so cannot count it as another language 3. When I asked students what language they would like to choose—given the choice, most of the class leaned towards Python. That plus the likelihood of them actually using it at some point, I decided to cover some programming language aspects using it over two-three weeks. It also has some fascinating feature sets (dunder methods, some meta programming niceties, etc.) and being interpreted language, provides a nice complementary view. 4. The rest of the course used D. I used both Andrei Alexandrescu's book and Ali's book to generate the course content. I was fortunate to have a stack of slides from the Andrei himself. And even more fortunate, as it happened to spend a Boston D meetup dinner with the two and Steven Schv-guy. I have been in love with D ever since I firsr started reading Andrei's book in 2010, and it was really quite something that I could use it in an undergraduate CS curriculum seven years later. Originally, I was hoping to use D for the entire course, but then given various aspects of the course, and the styles in which it is being taught many places made me change things a bit. Oh, and I should mention that I did get a few slides from Chuck Allison who uses D to teach a small part of his course at UVU. If you haven't seen his talk at, I believe the first/second DConf at UVU, I would highly recommend it. The icing on the cake was that Andrei was able to visit Vassar in November and give a talk on his Fastware muse (if I may call it that). He was an instant success! I am scheduled to teach the course again next Spring, and I am trying to figure out how/if I can use more D than I did the last time without sacrificing some of the goodness that (S)ML brings to the table. That way I can cover more programming paradigms that D brings to life—built in unittests, contract programming, delegates, and many many more—with a flair. Any thoughts/pointers that this wonderful community can provide would be very much appreciated. -- Sameer
Re: D for microservices
On 10/23/2017 06:02 PM, Adam Wilson wrote: On 10/23/17 05:08, Jacob Carlborg wrote: * Database drivers for the common databases (PostgreSQL, MySQL, SQLite) compatible with vibe.d * Database driver abstraction on top of the above drivers, perhaps some lightweight ORM library I've been looking pretty extensively at these two items recently. If the database drivers are compatible with Vibe.d AND we wish to provide a common abstraction layer for them (presumably via Phobos) then order for the abstraction layer to aware of the whether the driver is making a blocking or non-blocking call we must include Vibe.D in the abstraction layer. Mysql-native is vibe.d-compatible, but also works when you have zero vibe.d dependencies (in which case it switches to Phobos's sockets instead of using Vibe's sockets.)
Re: D for microservices
On 05/05/2018 02:30 PM, Nick Sabalausky (Abscissa) wrote: On 10/23/2017 06:02 PM, Adam Wilson wrote: On 10/23/17 05:08, Jacob Carlborg wrote: * Database drivers for the common databases (PostgreSQL, MySQL, SQLite) compatible with vibe.d * Database driver abstraction on top of the above drivers, perhaps some lightweight ORM library I've been looking pretty extensively at these two items recently. If the database drivers are compatible with Vibe.d AND we wish to provide a common abstraction layer for them (presumably via Phobos) then order for the abstraction layer to aware of the whether the driver is making a blocking or non-blocking call we must include Vibe.D in the abstraction layer. Mysql-native is vibe.d-compatible, but also works when you have zero vibe.d dependencies (in which case it switches to Phobos's sockets instead of using Vibe's sockets.) Sorry, didn't notice this was a half-year-old thread.
Re: Should 'in' Imply 'ref' as Well for Value Types?
On Saturday, 5 May 2018 at 15:22:04 UTC, Bolpat wrote: I once proposed that `in` can mean `const scope ref` that also binds rvalues. https://github.com/dlang/DIPs/pull/111#issuecomment-381911140 We could make `in` be something similar to `inline`. The compiler can implement it as stated above (assign the expression to temporary, reference it), or use copy if copy is cheaper than referencing. I remember, and I still like that proposal a lot, as it'd allow the compiler to tune generic code to the targeted platform and its ABI and free the dev from having to worry about how to pass a read-only input argument in the most efficient way. So if `in` semantics are ever to be redefined, `const [scope ref]` (depending on type and target ABI) are the only ones I'd happily agree with. [And I'd be extremely happy if rvalues could finally bind to ref params, not just as prerequisite for this.]
Re: Should 'in' Imply 'ref' as Well for Value Types?
On Saturday, May 05, 2018 15:22:04 Bolpat via Digitalmars-d wrote: > On Friday, 4 May 2018 at 09:34:14 UTC, Jonathan M Davis wrote: > > [...] > > It's actually not infrequent now that in C++, you want to pass > > stuf by value rather than const& precisely because move > > semantics can be used to avoid copies. So, it's not at all > > necessarily the case that passing by ref is the efficient thing > > to do. It's heavily dependent on the code in question. > > I once proposed that `in` can mean `const scope ref` that also > binds rvalues. > https://github.com/dlang/DIPs/pull/111#issuecomment-381911140 > We could make `in` be something similar to `inline`. The compiler > can implement it as stated above (assign the expression to > temporary, reference it), or use copy if copy is cheaper than > referencing. Having ref of any kind accept rvalues is a highly controversial issue, and it may or may not ever be in the language. If it's added, then at that point, whether it makes sense to make in imply ref could be re-examined, and maybe at that point, doing so would make great sense. But as long as ref does not accept rvalues, it really doesn't make sense. It would break too much code and would be far too annoying to use in many, many cases where it is currently commonly used. - Jonathan M Davis
Re: Should 'in' Imply 'ref' as Well for Value Types?
On Friday, 4 May 2018 at 09:34:14 UTC, Jonathan M Davis wrote: [...] It's actually not infrequent now that in C++, you want to pass stuf by value rather than const& precisely because move semantics can be used to avoid copies. So, it's not at all necessarily the case that passing by ref is the efficient thing to do. It's heavily dependent on the code in question. I once proposed that `in` can mean `const scope ref` that also binds rvalues. https://github.com/dlang/DIPs/pull/111#issuecomment-381911140 We could make `in` be something similar to `inline`. The compiler can implement it as stated above (assign the expression to temporary, reference it), or use copy if copy is cheaper than referencing. So, even if we were designing in from scratch, making ref would be a questionable choice. However, even if we all agreed that it would be desirable, such a change would break a large percentage of code that currently uses in, because any code that passes an rvalue to a function taking its argument as in would then break. So, any attempt to change in to include ref would have to have some sort of deprecation path to avoid code breakage. But given how annoying it would be to have in be ref by default due to how that affects rvalues, I'm willing to bet that most programmers would not be at all happy with such a change, regardless of how well the transitition was handled. Yes. Therefore the idea above. It will break much less code if any.
Re: D as a college language
On Sat, 2018-05-05 at 11:57 +, KingJoffrey via Digitalmars-d wrote: > On Saturday, 5 May 2018 at 11:25:45 UTC, Russel Winder wrote: > > […] > > What is the pedegogy here, what are the justifications. > > That the languages being taught to undergrads, must be pervasive. Not needed. The language must be good and fit for purpose not necessarily pervasive. For example Clean is an excellent language for teaching functional programming. That most professional programmers have ever heard of it doesn't undermine it's suitability. Conversely, Spark Ada is pervasive but would you use it to teach programming? However, I think it is right that exiting undergraduates have experience of Python, Java, and other languages used in the world of work, but they do not necessarily have to be the teaching languages. > That the languages being taught to undergrads, must teach them > about low-level types, and higher-level types. Definitely. Abstraction is at the core of programming. But different programming language have different type systems. So Ceylon, Haskell, OCaml, and Lisp are language for learning this sort of stuff. > And a whole lot of other stuff..(e.g, open source, cross > platform, have multiple compilers, standardised, formalised, > etc..) ..I can't be bothered typing any more ... Clearly the technology of programming in a professional way is important. But this is not specific to the programming language. And if we add IDE support as an integral part of professional programming, D fails to meet the criteria. > > In UK we have Scratch then Python then ??? This is working > > tremendously well to get large numbers of young people > > programming far better than most professional programmers. > > > > Don't teach undergrads how to play with toys! > > They can play with toys in junior high school, sure. Do not underestimate the quality and quantity of code written by 14 year olds with a Scratch and Python background. They put a large swathe of professional programmers to shame. And this with school teachers who are not at all sure they know what they are doing. CAS, Code Club, and other organisations have helped massively. More importantly though in a situation where new undergraduates already know Python, universities have to have a whole new approach. This is a revolution to traditional university CS education and training. Most universities in the UK are having to completely rework the whole curriculum ad way of working. For the better. […] > > C and Java are not extremes. Lisp, assembly language, Haskell, > > Erlang, these are extremes. > > C and Java, in comparison to each other, are at the end of each > extreme. In that C is a portable assembly language and Java is an object-based language supporting some forms of polymorphism they are very different, but they are far from extremes. > Those other languages you mention are mostly irrelevant (at least > on a grand scale), and certainly non-pervasisve. They have no > place in undergrad course. Erlang still runs much of the international telephone system, and a lot of share trading systems. Haskell is used for a lot of quant work in finance houses. Common Lisp and Clojure between them run quite a lot of Web systems and a lot of front-end share trading systems. They are very relevant and any undergraduate who has used them at all is probably sub-standard. > > > > D could be a postgrad interest perhaps. > > > > No, this would be a bad idea.We can debate this elsewhere. > > That should depend on the interests of the postgrad. > > At some point, we really, really should let them choose to focus > on what interests them. That is what options and projects are for. It all works very well in the UK. […] > you forgot 'mobile'. I guess a lot of people are interested in mobile, which these days means Swift and Kotlin. […] > > Python should be banned! Cut of it's head!! Hopefully this is a troll, and you don't mean that. Python is used by a huge swathe of data science and especially the quants who more or less run the finance system of the world. […] > > As someone intimately involved with a university for many, many > years, I have to wonder whether teachers are the problem, rather > than the solution ;-) I can't speak with direct evidence for the last decade but certainly till then far too many academics in the UK couldn't really program well at all. The whole university system militates against programming as something an academic is good at. Fortunately there seem to be just enough academics who can program well, at least in the top universities, that the programming courses do actually get taught well. Of course with programming moving from university to school (6 to 18) the problem shifts from academics to school teachers. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc De
Re: auto: useful, annoying or bad practice?
On Monday, 30 April 2018 at 21:31:48 UTC, Giles Bathgate wrote: On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote: [...] It takes some getting used to. Type inference is useful because often you don't care/know, or want to type out the full name of the type for every variable. It does, however, assume that the developer can also do type inference (when/if you need to know the type). When it's not clear what the type is by looking at the right-hand side perhaps the codebase has bigger problems. functions that return auto are a bit odd IMHO, that is a feature unique to D. C++14 would beg to differ. As would any language with Hindley-Milner type inference. Atila
Re: D as a college language
On Saturday, 5 May 2018 at 11:25:45 UTC, Russel Winder wrote: On Sat, 2018-05-05 at 03:02 +, KingJoffrey via Digitalmars-d wrote: […] Students should learn C first, Java second. Not one or the other, both! What is the pedegogy here, what are the justifications. That the languages being taught to undergrads, must be pervasive. That the languages being taught to undergrads, must teach them about low-level types, and higher-level types. And a whole lot of other stuff..(e.g, open source, cross platform, have multiple compilers, standardised, formalised, etc..) ..I can't be bothered typing any more ... In UK we have Scratch then Python then ??? This is working tremendously well to get large numbers of young people programming far better than most professional programmers. Don't teach undergrads how to play with toys! They can play with toys in junior high school, sure. Then, perhaps, they will begin to understand the basics of computer programming - from both extremes. C and Java are not extremes. Lisp, assembly language, Haskell, Erlang, these are extremes. C and Java, in comparison to each other, are at the end of each extreme. Those other languages you mention are mostly irrelevant (at least on a grand scale), and certainly non-pervasisve. They have no place in undergrad course. D could be a postgrad interest perhaps. No, this would be a bad idea.We can debate this elsewhere. That should depend on the interests of the postgrad. At some point, we really, really should let them choose to focus on what interests them. And what's earning an income got to do with anything? It's a stupid concept that humans have imposed on themselves, and it's the primary cause of all things that are wrong with society. The sooner we move to universal incomes, the better grauate programmers we'll get, cause they'll be studying it because it actually interests them, as opposed to being motived by its' 'earning' capacity. There being jobs using a programming language may not be a primary driver, but it is a secondary driver. University courses not using Java, Go, and JavaScript somewhere in the curriculum theses days get shunned by students. OK so all programming is clearly Web programming and nothing else is needed. :-) you forgot 'mobile'. So let me provide something actually constructive: Given that the world will move inexorably to using Python for teaching young people programming the trick is to have a Python → D learning programme with lots of support. Teaching support is everything in this aspect of the game. Python should be banned! Cut of it's head!! Teach the teachers that D is the route from Python to native code programming and thence C, C++, Fortran, etc, and you have an angle. Having an angle that appeals to the teachers is the first step in getting students to be taught a programming language. Java proved this. As someone intimately involved with a university for many, many years, I have to wonder whether teachers are the problem, rather than the solution ;-)
OST to PST Converter
It becomes easy to recover the damaged OST files with the help of ATS OST to PST Converter which is highly recommended by its users. it is very honest and reliable tool because of its highly rich algorithm. It converts the OST files into many different and important formats like EML, EMLX, vCard, vCal, MSG, and MBOX, then the best thing is that you can convert and save your OST data into Office 365 & Live Exchange Server which is a very important cloud-based application. It support window server 2003, 2003 R2, 2008, 2008 R2 2016. Get more details: http://www.bulkecommerce.com/store/ats-ost-to-pst-converter-software-159.html
Re: D as a college language
On Sat, 2018-05-05 at 23:16 +1200, rikki cattermole via Digitalmars-d wrote: > […] > You're forgetting one crucial detail. The people making the decisions > now, are not the same ones back then. Not forgetting at all, but may be didn't make the point as well as I should. All universities are not the same. There are the leaders and there are the followers. Follower university departments emphasise job opportunities much more than leader university departments. The old university/polytechnic split in the UK used to highlight this very well. Leader departments value pedegogy and concepts much more than follower departments. Sadly in many cases this got labelled as "academic" vs "practical" which remains a very unfortunate way of categorising things. > I have repeated what I was told using all the same arguments presented > in this thread and I am only relaying it here their response. It isn't > my opinion. Understood. I will always say job opportunities is a secondary factor, just not a primary one. Except that in some follower departments they do not accept this, they are more about training and less about education. For them job opportunities are everything: training not education. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D as a college language
On Sat, 2018-05-05 at 03:02 +, KingJoffrey via Digitalmars-d wrote: […] > > Students should learn C first, Java second. Not one or the other, > both! What is the pedegogy here, what are the justifications. In UK we have Scratch then Python then ??? This is working tremendously well to get large numbers of young people programming far better than most professional programmers. > Then, perhaps, they will begin to understand the basics of > computer programming - from both extremes. C and Java are not extremes. Lisp, assembly language, Haskell, Erlang, these are extremes. > D could be a postgrad interest perhaps. No, this would be a bad idea.We can debate this elsewhere. > And what's earning an income got to do with anything? It's a > stupid concept that humans have imposed on themselves, and it's > the primary cause of all things that are wrong with society. The > sooner we move to universal incomes, the better grauate > programmers we'll get, cause they'll be studying it because it > actually interests them, as opposed to being motived by its' > 'earning' capacity. There being jobs using a programming language may not be a primary driver, but it is a secondary driver. University courses not using Java, Go, and JavaScript somewhere in the curriculum theses days get shunned by students. OK so all programming is clearly Web programming and nothing else is needed. :-) So let me provide something actually constructive: Given that the world will move inexorably to using Python for teaching young people programming the trick is to have a Python → D learning programme with lots of support. Teaching support is everything in this aspect of the game. Teach the teachers that D is the route from Python to native code programming and thence C, C++, Fortran, etc, and you have an angle. Having an angle that appeals to the teachers is the first step in getting students to be taught a programming language. Java proved this. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Need help with the dmd package on NixOS
On Saturday, 5 May 2018 at 00:07:01 UTC, Johannes Loher wrote: Am 04.05.2018 um 22:27 schrieb Thomas Mader: [...] Here is a demangled version of what you posted: Here comes the entire demangled output of the Hello World build. Maybe it has something to do with ModuleInfo? I also need to skip through changes which might have introduced this problem. hello.o: In function `@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])': hello.d:(.text.@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])[@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])]+0x46): undefined reference to `@safe std.stdio.File.LockingTextWriter std.stdio.File.lockingTextWriter()' hello.d:(.text.@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])[@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])]+0x57): undefined reference to `@safe void std.stdio.File.__dtor()' hello.d:(.text.@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])[@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])]+0xa4): undefined reference to `@trusted void std.stdio.File.LockingTextWriter.__aggrDtor()' hello.o:(.data.DW.ref.__dmd_personality_v0+0x0): undefined reference to `__dmd_personality_v0' hello.o: In function `@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])': hello.d:(.text.@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])[@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])]+0x20): undefined reference to `std.exception.ErrnoException.__Class' hello.d:(.text.@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])[@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])]+0x5b): undefined reference to `@trusted std.exception.ErrnoException std.exception.ErrnoException.__ctor(immutable(char)[], immutable(char)[], ulong)' hello.d:(.text.@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])[@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])]+0x63): undefined reference to `_d_throwdwarf' hello.o: In function `@safe void std.stdio.File.LockingTextWriter.put!(immutable(char)).put(immutable(char))': hello.d:(.text.@safe void std.stdio.File.LockingTextWriter.put!(immutable(char)).put(immutable(char))[@safe void std.stdio.File.LockingTextWriter.put!(immutable(char)).put(immutable(char))]+0x1b): undefined reference to `@property @trusted core.stdc.stdio._IO_FILE* std.stdio.File.LockingTextWriter.handle_()' hello.d:(.text.@safe void std.stdio.File.LockingTextWriter.put!(immutable(char)).put(immutable(char))[@safe void std.stdio.File.LockingTextWriter.put!(immutable(char)).put(immutable(char))]+0x37): undefined reference to `@property @trusted core.stdc.stdio._IO_FILE* std.stdio.File.LockingTextWriter.handle_()' hello.o: In function `@safe void std.stdio.File.LockingTextWriter.put!(char).put(char)': hello.d:(.text.@safe void std.stdio.File.LockingTextWriter.put!(char).put(char)[@safe void std.stdio.File.LockingTextWriter.put!(char).put(char)]+0x1b): undefined reference to `@property @trusted core.stdc.stdio._IO_FILE* std.stdio.File.LockingTextWriter.handle_()' hello.d:(.text.@safe void std.stdio.File.LockingTextWriter.put!(char).put(char)[@safe void std.stdio.File.LockingTextWriter.put!(char).put(char)]+0x37): undefined reference to `@property @trusted core.stdc.stdio._IO_FILE* std.stdio.File.LockingTextWriter.handle_()' hello.o: In function `main': hello.d:(.text.main[main]+0xc): undefined reference to `_d_run_main' /nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/lib/libphobos2.a(lifetime_68e_482.o):(.data+0x0): undefined reference to `rt.lifetime.__ModuleInfo' /nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/lib/libphobos2.a(lifetime_68e_482.o): In function `_d_newclass': (.text._d_newclass[_d_newclass]+0x35): undefined reference to `pure nothrow @nogc core.exception.OutOfMemoryError core.exception.staticError!(core.exception.OutOfMemoryError).staticError()' (.text._d_newclass[_d_newclass]+0x3d): undefined reference to `_d_throwdwarf' /nix/store/x9wfppgz07zgks9yfn7c96965wmrl
Re: D as a college language
On 05/05/2018 11:06 PM, Russel Winder wrote: On Sat, 2018-05-05 at 03:22 +1200, rikki cattermole via Digitalmars-d wrote: […] Teaching materials is easy to create. My response is the response I got from my institution. It is industry usage which is the problem. Nobody wants to take the risk without being able to point and say "they" are using it for some serious work. Let me take you back to 1994. Universities teaching Scheme, Miranda, C++, or if they were a bit backward Pascal or even Modula-2. Java comes along and all universities switched to it and created vast amounts of teaching material. Absolutely no industrial take up at all. You're forgetting one crucial detail. The people making the decisions now, are not the same ones back then. I have repeated what I was told using all the same arguments presented in this thread and I am only relaying it here their response. It isn't my opinion.
Re: D as a college language
On Fri, 2018-05-04 at 11:52 +, bauss via Digitalmars-d wrote: > […] > > The biggest issue is that there isn't much industrial work done > in D and that's why it's not taught. Perhaps this argument is used in some places, but it is not the primary driver for choice of programming languages in universities. It is a secondary factor though certainly. > When you're taught to program in specific languages, it's because > those languages are where the job market is at. In some training courses, yes, in universities no. > I completely agree with your post however, but I don't see D ever > taking off as an educational programming language in the majority > of schools, because it doesn't have a job market to support it. Not a primary argument. The single biggest reason why D is not taught in universities is that D is not taught in universities. There are many fashion and herd aspects to teaching programming. The leaders will choose a language for pedagogical reasons, mixed a bit with jobs market, and will create teaching materials. All the rest just follow what the leaders decide using the leaders materials if at all possible so as to avoid having to make their own. > Say if you apply for a Java job and it says you have 10 years of > experience programming in D and 3 years of experience programming > Java, then another applicant has 7 years of experience > programming in Java, but 0 experience with programming in D. > > To the one hiring the person with 7 years of experience seem like > a better choice, just because they generally have no idea what D > is and what it offers. They don't know that if you program in D > you can usually program very well, if not better than most > general Java developers __when__ using Java. All they know is > that they use Java and they're looking for the one with most > experience in that field. If this is the jobs market you have experienced you are applying to the wrong companies. Experience (as debated in other threads) is a problematic concept. Having worked for 10 years in C++ doesn't mean you have 10 years constructive experience; someone with 6 months might be a better programmer and thus chosen. Of course cost of person is a factor as well. Remember though someone with 1 year Haskell, 1 year Lisp, 1 year C++, and 1 year Java, may well be a better D programmer than someone with 10 years D experience. > Until D becomes an industrial requirement, then it will not be > taught. > > That's why D is a hobby language. N. D seems to be a hobby language because everyone says this in public forums. D is a programming language, some use it for hobby, some for hard core industrial and commercial. It is just that it's traction is not high. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D as a college language
On Sat, 2018-05-05 at 03:22 +1200, rikki cattermole via Digitalmars-d wrote: > […] > Teaching materials is easy to create. > My response is the response I got from my institution. > It is industry usage which is the problem. > > Nobody wants to take the risk without being able to point and say "they" > are using it for some serious work. Let me take you back to 1994. Universities teaching Scheme, Miranda, C++, or if they were a bit backward Pascal or even Modula-2. Java comes along and all universities switched to it and created vast amounts of teaching material. Absolutely no industrial take up at all. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: On emulating C++ Namespaces (don't ask why)
On Friday, 4 May 2018 at 19:19:19 UTC, Manu wrote:
On 4 May 2018 at 10:50, 0x via Digitalmars-d
wrote:
What am I violating here apart from the truth that our Mr.
Walter doesn't like namespaces:
interface tlvs
{
enum tlv { addr };
static:
void header();
}
Is this cool?
Thanks
But... modules?
I did intentionally sidelined modules, not an option
Re: D for microservices
On Sunday, 11 March 2018 at 11:10:09 UTC, Tamas wrote: On Thursday, 8 March 2018 at 22:53:11 UTC, aberba wrote: On Thursday, 8 March 2018 at 09:35:08 UTC, Andrew Benton wrote: On Thursday, 8 March 2018 at 07:54:29 UTC, Jacob Carlborg wrote: On Thursday, 8 March 2018 at 07:20:53 UTC, Radu wrote: This guys says that vide.d works https://forum.dlang.org/thread/gikoeutmdyvolfshp...@forum.dlang.org Yes, it's pretty straightforward: 1. Build on Ubuntu, or some other dist 2. Statically link the whole binary with LDC, then you don't need to use Musl 3. Run it on Alpine -- /Jacob Carlborg Looks like that works out much nicer than using alpine as the first stage right now. I'm not sure anyone will be too upset about the extra 7MB. Building directly in alpine will simplify automated builds too. Simple Vibe.d app talking to Redis, packed into docker containers: https://github.com/tam4s/hello-redis The takeaway is that I could not use Alpine as a host image, because I could not build the app statically on ubuntu. warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking I've put up a new binary release of ldc 1.9 for Alpine, which fixes the vibe.d issues by pulling in two upstream commits from druntime, adds druntime and Phobos as shared libraries, and includes dub and rdmd: https://github.com/ldc-developers/ldc/releases I tested by unpacking that release in an Alpine VPS, adding its bin/ to my path, and simply running the following: dub fetch vibe-d dub build vibe-d The list of Alpine packages needed to run ldc are listed in the release notes. You can also cross-compile using the regular linux build of ldc by using ldc-build-runtime, the included tool to rebuild the stdlib for other platforms, and these instructions from the wiki: https://wiki.dlang.org/Building_LDC_runtime_libraries#Usage_for_cross-compilation I'm looking at adding a flag to dmd to enable building for the Musl C runtime: https://github.com/dlang/dmd/pull/8020 While the Musl port is mostly there, it appears that yshui didn't bother porting all of druntime, so there may still be other dub packages that need other missing C declarations. However, I'm done working on this port, beyond finishing off the above pull and the druntime pull linked from the release notes, as I don't use Alpine, containers, or microservices. I simply chipped in because I have porting experience and thought I could push D for microservices a bit farther along. I'll keep putting out official builds of ldc for Alpine though, as long as there's demand for them. If you'd like to use D in Alpine containers, now's the time to contribute to whatever else is missing. A good idea of the current status can be found in the first post of the dmd pull linked above. This may be a good project for the hackathon, as it's mostly polishing up a bunch of small things.
Re: D as a college language
On 5/4/2018 4:35 AM, Sjoerd Nijboer wrote: Since D seems to be a language that supports a lot of programming paradigms very well, wouldn't it be beneficial to learn people declarative programming using D for a little and from there expose them to other programming styles in thesame language to lower the barrier of entry? I agree that D being a multi-paradigm language makes it ideal as a vehicle for teaching various paradigms. New paradigms can be taught without the diversion of having to start over learning a new language.
Re: auto: useful, annoying or bad practice?
On 05/04/2018 12:54 PM, H. S. Teoh wrote: This is a good point. However, I'm failing to see it as a big problem, because for it to be a problem in the first place, you have to have *deliberately* passed an object of said type into a function that expects that particular concept. First of all, just to be clear in case I wasn't, I didn't mean that it's equally dangerous as globals, just that it's analogous. Globals are, of course, more dangerous. Regarding the need to deliberately pass an object of said type to a function in order to cause a problem, that's not always true: It could be a matter of the compiler choosing the wrong overload. Or sticking it in the wrong parameter on certain templated functions. Also, generally speaking, even without structural typing, the danger of passing an object of the wrong type to the wrong parameter/function/overload IS considered to be significant enough to help justify the whole premise of static typing. (Well, at least according to a certain faction of programmers, anyway ;) ) And ultimately, from a design standpoint, I really see no compelling reason *not* to require a formal declaration of "This deliberately implements isXYZ", other than just...some people just dislike it. So like, yea, we *can* get by without it...but...why would we want to?
