Re: D's memory-hungry templates
On Thursday, 9 June 2016 at 22:03:36 UTC, Alex Bradbury wrote: On Thursday, 9 June 2016 at 14:46:12 UTC, tsbockman wrote: Ultimately, I believe it was a mistake for D to implement a separate, inferior programming language just for templates. However, it is too late to change that now (at least for D2), so I will offer some suggestions as to how memory consumption can be reduced within the current design: If you have a design in mind, I'd be interested in hearing your proposals for an alternative. I have an incomplete design for a new programming language, and the beginnings of a proof-of-concept implementation (written in D). It was inspired mainly by D and Lisp, with goal being to distill the power and performance that D strives for down into a language that is much closer to the simplicity and conceptual purity of Lisp. The project is still at a very early stage, and I haven't decided yet how serious I am about completing it, but I'll give you a brief sketch anyway: * Very simple syntax, with the goal that a person should be able to easily visualize the resulting AST. Inspired by Lisp, but with a little extra complexity to keep people from getting Lost In a Sea of Parentheses. * statically typed * functional, but not pure - mutability and global state are permitted * what D calls a template is really just a function * symbols, AST nodes, functions, templates, and data types are all regular values which can be manipulated via normal code * function call syntax explicitly (and concisely) indicates whether to evaluate the call at compile-time, run-time, or whenever * currying: evaluating a function with some, but not all, of its parameters returns another function that can later be fed the rest of its parameters * currying a function at compile-time and then calling the result at run-time is equivalent to instantiating and calling a template function in D * most complex features, such as polymorphic classes, lambdas, reified generics, inlining, tail recursion, and string mixins can be implemented in the standard library The above approach to meta-programming would be vastly simpler than what D has done, and offer much better compile-time performance if implemented sensibly. (I also have other ideas about managing memory, mutability, and multi-tasking, as well, but they're off-topic and less fully formed.) For D itself, though, we must work with what we have. I think the suggestions I gave at the beginning of this thread, combined with the CTFE system upgrade that Stefan Koch is working on, would bring huge improvements to D's compile-time performance.
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 05:37:37 UTC, Jonathan M Davis wrote:
I assume that you're not from the US?
Right, I am in Oslo (Norway).
In the US at least, professional programmers are almost always
referred to officially as software engineers (though they use
the term programmers informally all the time), whereas the
terms computer science and computer scientist are generally
reserved for academics
Well, I don't know what is "official". Some norwegian companies
seem to use convoluted "international business" terminology for
everything, which is just weird and "snobbish". I think "system
developer" ("systemutvikler") is the broad general term here.
So you can be an "informatiker" (broad term for your education)
with an education in the fields of "computer science" and
"software engineering", and work in the role of a "system
developer".
If you have a bachelor that fulfills the requirements for
starting on a comp.sci. master then you are a computer scientist,
but if you have a bachelor that doesn't and focus more on
practical computing then you are a software engineer?
You can have an education that is all about discrete math and
still be a computer scientist. You couldn't then say you have a
bachelor in software engineering, as it would be wrong. Likewise,
you can have a bachelor in software engineering and barely know
anything about complexity theory.
And while the term informatics (or very similar terms) are used
in several other languages/countries, I've never heard the term
used in the US except to mention that some other
languages/countries use the term informatics for computer
science, and I'm willing to bet that relatively few programmers
in the US have ever even heard the term informatics.
Yes, but it makes sense to distinguish between "computer science"
(the timeless math and concepts behind computing) and "software
engineering" (contemporary development methodology and practice).
Although I think an education should cover both. "Informatics"
just covers it all (as an educational field).
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 06:37:08 UTC, ketmar wrote: On Friday, 10 June 2016 at 06:25:55 UTC, ketmar wrote: On Thursday, 9 June 2016 at 16:44:23 UTC, Yura wrote: 4) The C language is well tested and rock solid stable. loool. ah, sorry, let me explain myself. i hit ALOT of gcc bugs in my life. and i never fixed any of them myself, 'cause gcc is very huge, and i don't feel that it worth it. even with bugs that blocked my work i used workarounds and hand-written asm. i hit some bugs in D too. curiously, it comparable with gcc in numbers (maybe this tells us something, and maybe it is just a coincidence). some of them i was able not only report, but fix. usually, official fix comes later, and was better than mine hacky patch, but hey... DMD compiler is less complex than gcc, *alot* less complex. now, why i loled: i thinked about what you wrote, and found that gcc bugs blocks my work/pet projects more often than dmd bugs. it may sounds strange, but dmd bug is usually either fixed fast enough (and building new dmd+druntime+phobos from sources takes less than two minutes on my PC), or i know a workaround. contrary to that, even if gcc bug was fixed fast (and usually they don't), rebuilding gcc takes 20‒30 minutes. and most of the time i can't even understand what fix does, due to huge and unknown codebase. so no, C languange is not "rock solid stable". it just has alot less features, and if you will use the same feature set in DMD, you will hardly hit a bug too. Thanks all of you for the constructive discussion, I am a chemist studying the programming by myself since I need it to explore chemistry at the molecular level and to check my chemical ideas. The professional software engineer(SE)/computer scientist(CS) would do the job much faster, and the resulting code would look much better - but, to do that you need to explain all the chemistry behind to SE/CS which would be tricky, and the most important (drastic) approximations come exactly from chemistry - not from the particular language. I hope you excuse me for the long introduction. In my area there are 3 languages dominating: Python, Fortran and C/C++. The first is easy (many libraries are available), but might be very slow. Fortran is used by the old professors, tons of libraries, but is not used outside of academia - and this stops young people from studying it because everyone at some point may quit an academia. C and C++ perhaps dominate the field, but especially the second one is very tough for people coming from non-IT background. I believe D has very high chances to be competitive in this field. Regarding the GC, I will try to check it when I have some time, but since most of the codes are written in non-GC languages (https://en.wikipedia.org/wiki/List_of_quantum_chemistry_and_solid-state_physics_software), something tells me that GC would slow you down because in this field people are fighting for every percent of the performance (many simulations are running for weeks). Another point is to link the libraries, with my poor background in IT, even to link the C library to the C code is a challenge, and something tells me that to link it to D would be even more challenging => to make linking the C libraries as easy as possible (Fortran or C++ libraries are not as important) and to have active support forum when you can as for help in linking the libraries to your D code would be helpful. As people have this support, then they are confident to start their new projects in D. Then, at the conferences/ in the scientific papers people can advertise and promote the language, which is more user friendly than C, Fortran and C++ and is modern enough. However, perhaps, only enthusiasm is not sufficient for all this, you need the sponsors... I agree the C subset for sure guarantees (almost) absence of bugs. Another things where I do almost all my mistakes is: array bounding/calling the memory which was free => the result is undefined behavior. If I remember correctly the D is better with that respect? Anyway, super easy way to use all C libraries + super active support would clearly help to increase D popularity/adoption. All other point I raised are perhaps not that important.
Re: Optimizations and performance
On Thursday, 9 June 2016 at 18:45:48 UTC, poliklosio wrote: On Thursday, 9 June 2016 at 10:00:17 UTC, Ola Fosheim Grøstad wrote: On Thursday, 9 June 2016 at 07:26:16 UTC, poliklosio wrote: First of all, there is not much point optimizing the language for people who are capable of optimizing everything to the extreme themselves. D already has as much power as C/C++ for them. No... not if you are talking about specific compilers. Get the logic right. The correct statement is: "Yes... not if you are talking about specific compilers." «D already has as much power as C/C++ for them.» No (D does not already has as much power as C/C++ for them.)... not if you are talking about specific (C/C++) compilers. Please don't twist my words. :-)
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 08:29:50 UTC, Yura wrote: something tells me that GC would slow you down because in this field people are fighting for every percent of the performance (many simulations are running for weeks). yes, GC will have an effect for such things. but then, people fighting for performance will resort to "dirty tricks" in any language, i believe, and in D it is not that hard to avoid GC (i'm doing something like that in my videogame and sound engines). but the great thing — at least for me — that you can easily prototype your solution with GC, debug it, and then gradually replace data structures with other data structures that does manual memory management. this way you can debug your data structures and algorithms independently. of course, it is possible in C and C++ too, but i found that with D it is somewhat easier. Another point is to link the libraries, with my poor background in IT, even to link the C library to the C code is a challenge, and something tells me that to link it to D would be even more challenging i found that D is better here too, it just require some... discipline. thanks to UFCS, one can write D code that *looks* like OOP, but actualy only using structs and free functions. this way you can use `export(C)` on your public API, and still use `myvar.myfunc()` syntax in D, but have C-ready `myfunc(&myvar)` syntax to export. also, with some CTFE magic one can even generate such wrappers in compile time. Another things where I do almost all my mistakes is: array bounding/calling the memory which was free => the result is undefined behavior. If I remember correctly the D is better with that respect? yes. with GC, you won't hit "use after free" error. and D does bound checking on array access (this can be turned off once you debugged your code), so you will get a stack trace on RangeError. Anyway, super easy way to use all C libraries + super active support would clearly help to increase D popularity/adoption. and as for C libraries... i'm actively using alot of C libs in my D projects, and most of the time i do wrappers for them with sed. ;-) i.e. i'm just taking C header file, run some regular expression replaces on it, and then do some manual cleanup. that is, even without specialized tools one is able to produce a wrapper with very small time and effort investement. tbh, i even translated some C libraries to D mostly with sed. for example, enet and libotr.
Re: Version identifier for PS4
On 2016-06-09 15:16, Steven Schveighoffer wrote: The precedent is to use whatever the OS defines for the host C compiler. This is the reason we have lower case "linux" for version, which is inconsistent with other version identifiers, but consistent with Linux's #define in C code. That's only true for the "linux" identifier. The other ones are using the more "official" name and casing of the operating system. Example: the C preprocessor identifier for OS X is __APPLE__, but in D it's "OSX". -- /Jacob Carlborg
Re: The Problem With DIPs
On 2016-06-09 23:34, Walter Bright wrote: That doesn't stop anyone from commenting on them, offering improvements, doing some promotion of them, organizing handling them, etc. If feel that's a bit pointless if no one with some form of authority will look at it. -- /Jacob Carlborg
Re: Andrei's list of barriers to D adoption
On Thursday, 9 June 2016 at 16:44:23 UTC, Yura wrote: Hello, I have to stress I am beginner in programming, mainly interested in number crunching in academia (at least so far). I started to write a small project in D, but had to switch to C for few reasons: 1) Importance for my CV. I know Python, if I add also C - it sounds, and could be useful since the C language is, apart from the other reasons, is popular and could help me wit the future job, both in academia and industry, since there are many C/C++ projects. I wouldn't worry too much about the CV. Maybe in a year or two companies will demand you know Ruby or Javascript :) Once you know who to program it's not so hard to pick up other languages. The basic concepts of handling / mapping data are always the same (hash tables, arrays ...) 2) The libraries - in the scientific world you can find practically everything which has already been coded in C, => many C libraries. To link it to be used within D code requires some work/efforts, and since I am not that confident in my IT skills, I decided that C code calling C libraries is much safer. It's a piece of cake most of the time, it's really easy.[1] When I first tried it, I couldn't believe that it was _that_ simple. I use some C code too in one of my projects and it's easy to either call individual C functions or, if needs be, you can turn a C header file into a D interface file with only a few changes (they will almost look identical). There is absolutely no reason not to use D because of existing C libraries. The seamless interfacing to C is one of D's major advantages. In this way you can write elegant D code and still take advantage of the plethora of C libraries that are available. Here are examples of porting C libraries that have D interfaces: https://github.com/D-Programming-Deimos?page=1 If you need help, you can always ask on the forum. Nobody will bite you :-) There are even D frameworks that enable you to interact with Python [2] and Lua. I'd say give it a shot. [1] http://dlang.org/spec/interfaceToC.html [2] https://github.com/ariovistus/pyd Other links: http://dlang.org/ctod.html http://dlang.org/articles.html 3) For C - a lot of tutorials, everything has been explained at stack overflow many times, huge community of people. E.g. you want to use OpenMP, Open MPI - everything is there, explained many times, etc. 4) The C language is well tested and rock solid stable. However, if you encounter a potential bug in D, I am not sure how long would it take to fix. 5) Garbage collector - it will slow my number crunching down. You should test it first, gut feeling is not a proof. If it really does slow down your code, write GC free code, as ketmar suggested. You can always ask on the .learn forum. Please, do not take it as criticism, I like D language, I tried it before C and I find it much much easier, and user friendly. I feel it is more similar to Python. On the other hand C++ is too complex for me, and D would be the perfect option for the scientific community, if the above points would be fixed somehow.. Best luck with your work!
Re: Optimizations and performance
On Thursday, 9 June 2016 at 16:47:28 UTC, Kagamin wrote:
On Thursday, 9 June 2016 at 15:16:34 UTC, Wyatt wrote:
The point is this sort of language benchmark should use normal
code. The sort of code that people who've never heard of
Haskell would write.
If it's a "fast" language, "ordinary-looking" code should be
fast. If being fast requires weird circumlocutions that
barely anyone knows, it doesn't matter if experts consider it
best practice.
A language optimized for performance of spontaneous code
written by newbies, who never learned the language and don't
use best practices?
Something like
`void main()
{
// Replace anything that looks like a real
// number with the rounded equivalent.
stdin
.byLine
.map!(l => l.replaceAll!(c => c.hit.round)
(reFloatingPoint))
.each!writeln;
}
`
should be as fast as possible. If we have to tell people that
yes, it is idiomatic D but, if you want speed you should use
for (size_t i = 0 ...) { /*some magic here*/ }
then we are doing something wrong.
Re: Andrei's list of barriers to D adoption
And also, always use ldc or gdc, once your project is ready to go. dmd generated code is slow as it is only a reference compiler. http://dlang.org/download.html
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 09:35:32 UTC, Chris wrote: And also, always use ldc or gdc, once your project is ready to go. dmd generated code is slow as it is only a reference compiler. but not *dog* *slow*. ;-) if one don't really need to squeeze every possible cycle out of CPU, DMD-generated code is more than acceptable. i, for example, managed to make my scripting language almost as efficient with DMD -O as Lua with gcc -O3. ;-)
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 09:46:11 UTC, ketmar wrote: On Friday, 10 June 2016 at 09:35:32 UTC, Chris wrote: And also, always use ldc or gdc, once your project is ready to go. dmd generated code is slow as it is only a reference compiler. but not *dog* *slow*. ;-) if one don't really need to squeeze every possible cycle out of CPU, DMD-generated code is more than acceptable. i, for example, managed to make my scripting language almost as efficient with DMD -O as Lua with gcc -O3. ;-) No not slow slow. Even in debugging mode it produces acceptable results for testing. A scripting language based on D? Is it open source? I've always dreamt of something like that.
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 10:03:29 UTC, Chris wrote: A scripting language based on D? Is it open source? I've always dreamt of something like that. i have several of them, actually. yet they are very specialized — i.e. designed to support my game engines, not to be "wide-area scripting languages". publicly accessible are: DACS[1] — statically typed, with modules and UFCS, and JIT compiler built with LibJIT[2], optionally supports internal stack-based VM. GML[3] — part of my WIP Game Maker 8 emulator, register-based 3-op VM, no JIT. [1] http://repo.or.cz/dacs.git [2] https://www.gnu.org/software/libjit/ [3] http://repo.or.cz/gaemu.git
Re: D's memory-hungry templates
On 6/9/16 7:56 PM, maik klein wrote: Also C++ beat D in every compile time meta programming benchmark that I have tested. Intriguing. Do you have a couple of representative benchmarks along with their C++ counterparts to post to bugzilla? Thanks! -- Andrei
Re: The Problem With DIPs
On 6/10/16 9:00 AM, Jacob Carlborg wrote: On 2016-06-09 23:34, Walter Bright wrote: That doesn't stop anyone from commenting on them, offering improvements, doing some promotion of them, organizing handling them, etc. If feel that's a bit pointless if no one with some form of authority will look at it. It's much better than making informal remarks on the forum, which then scroll out of memory. I encourage people who have good ideas and are willing and able to take them to completion to formulate them as DIPs. Good quality DIPs will eventually get discussed more often and end up being implemented. -- Andrei
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 10:21:07 UTC, ketmar wrote: i have several of them, actually. yet they are very specialized — i.e. designed to support my game engines, not to be "wide-area scripting languages". publicly accessible are: DACS[1] — statically typed, with modules and UFCS, and JIT compiler built with LibJIT[2], optionally supports internal stack-based VM. GML[3] — part of my WIP Game Maker 8 emulator, register-based 3-op VM, no JIT. [1] http://repo.or.cz/dacs.git [2] https://www.gnu.org/software/libjit/ [3] http://repo.or.cz/gaemu.git Cool. I'd love to see `DScript` one day - and replace JS once and for all ... well ... just day dreaming ...
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 10:55:42 UTC, Chris wrote: Cool. I'd love to see `DScript` one day - and replace JS once and for all ... well ... just day dreaming ... Adam has scripting engine in his arsd repo[1]. it's not a speed demon, but it is much more like JS, it even has exceptions, and it is very easy to integrate it with D code. you may take a look at it too. afair, you only need jsvar.d and script.d modules to use it. [1] https://github.com/adamdruppe/arsd
Re: D's memory-hungry templates
On Friday, 10 June 2016 at 10:27:09 UTC, Andrei Alexandrescu wrote: On 6/9/16 7:56 PM, maik klein wrote: Also C++ beat D in every compile time meta programming benchmark that I have tested. Intriguing. Do you have a couple of representative benchmarks along with their C++ counterparts to post to bugzilla? Thanks! -- Andrei Not in a presentable form, I still have a framework on my other machine. I basically generated new D files from within D and then compiled them using ldc/dmd. I could clean it up and upload it when I have some time.
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 11:05:27 UTC, ketmar wrote: Adam has scripting engine in his arsd repo[1]. it's not a speed demon, but it is much more like JS, it even has exceptions, and it is very easy to integrate it with D code. you may take a look at it too. afair, you only need jsvar.d and script.d modules to use it. [1] https://github.com/adamdruppe/arsd Nice. Anyone interested in turning this into "DScript"? Having a scripting language powered by D would also boost D's prestige. And it would be easy to write modules in pure D. DScript could then be used by scientists, game developers etc. à la Python and if speed is crucial, just write a module in pure D.
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 11:11:49 UTC, Chris wrote: Nice. Anyone interested in turning this into "DScript"? Having a scripting language powered by D would also boost D's prestige. And it would be easy to write modules in pure D. DScript could then be used by scientists, game developers etc. à la Python and if speed is crucial, just write a module in pure D. it looks like you just described a project you can start yourself! ;-)
Re: D's memory-hungry templates
On Friday, 10 June 2016 at 11:09:58 UTC, maik klein wrote: Not in a presentable form, I still have a framework on my other machine. I basically generated new D files from within D and then compiled them using ldc/dmd. I could clean it up and upload it when I have some time. Yes please. Compile-time perf is always good to test :)
Re: Killing the comma operator
On Thursday, 12 May 2016 at 10:29:36 UTC, Andrei Alexandrescu wrote: Before we get lost in the discussions, let's act on this by disallowing taking the result of the comma operator. Yes there is potential breakage (via typeof as Timon noted) but it's likely to be minimal. Once we have that in place we have more options. Thx! -- Andrei Just a quick update on that topic: using the return of a comma operator now yield a deprecation message (using DMD ~master). This will be part of 2.072.0. Thanks everyone for your feedback !
Re: Andrei's list of barriers to D adoption
On Tue, 2016-06-07 at 11:21 +, ketmar via Digitalmars-d wrote: > On Tuesday, 7 June 2016 at 11:11:31 UTC, Russel Winder wrote: > > On Tue, 2016-06-07 at 09:55 +, ketmar via Digitalmars-d > > wrote: > > > > > […] > > > considering that the whole package, including dlangUI, is one > > > man work... give it a chance! ;-) > > > > A project starting as a one person thing is quite natural, a > > project aiming to gain traction remaining a one person project > > is a dead end siding. > > not everybody is good at promoting their work. yes, this skill is > required to make your project wide-known (and then wide-used), > but... this is where other people can step in to help. i'm sux in > promoting things too, so i'm doing as much as i can: mentioning > the project occasionally here and there. My point was not so much a direct marketing one more an indirect one: if a project is claiming to be a production thing usable by all and sundry but is a one-person project, then it isn't actually production ready. It may actually be production ready, but it will not be perceived as that: person under a bus scenario and all that. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 11:20:35 UTC, ketmar wrote: On Friday, 10 June 2016 at 11:11:49 UTC, Chris wrote: Nice. Anyone interested in turning this into "DScript"? Having a scripting language powered by D would also boost D's prestige. And it would be easy to write modules in pure D. DScript could then be used by scientists, game developers etc. à la Python and if speed is crucial, just write a module in pure D. it looks like you just described a project you can start yourself! ;-) I have neither time nor the required expertise to write a scripting language from scratch ;) You on the other hand ... :-)
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 13:55:28 UTC, Chris wrote: I have neither time nor the required expertise to write a scripting language from scratch ;) You on the other hand ... :-) so just use Adam's code as the starting point then! ;-)
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 08:29:50 UTC, Yura wrote: Another things where I do almost all my mistakes is: array bounding/calling the memory which was free => the result is undefined behavior. If I remember correctly the D is better with that respect? I think slices and automatic bound checking is the most important improvement of D over C. An important concern in simulations (mentioned by one using D in bioinformatics) is correctness: if you have a bug, the program is not guaranteed to crash, it can just give an incorrect result. Anyway, super easy way to use all C libraries + super active support would clearly help to increase D popularity/adoption. All other point I raised are perhaps not that important. I'm not as optimistic about binding C libraries as others :) I think it requires skills.
Re: The Problem With DIPs
On Friday, 10 June 2016 at 10:38:49 UTC, Andrei Alexandrescu wrote: On 6/10/16 9:00 AM, Jacob Carlborg wrote: On 2016-06-09 23:34, Walter Bright wrote: That doesn't stop anyone from commenting on them, offering improvements, doing some promotion of them, organizing handling them, etc. If feel that's a bit pointless if no one with some form of authority will look at it. It's much better than making informal remarks on the forum, which then scroll out of memory. I encourage people who have good ideas and are willing and able to take them to completion to formulate them as DIPs. Good quality DIPs will eventually get discussed more often and end up being implemented. -- Andrei +1 It's all about working more collaboratively - I believe Dicebot will do an amazing job as review manager! If you read his proposed procedure at the WIP-repo (https://github.com/Dicebot/DIPs), it's about collecting high-quality DIPs in "Drafts" that are then "brought to the language authors for review".
Re: Optimizations and performance
On Friday, 10 June 2016 at 01:54:21 UTC, Ola Fosheim Grøstad wrote: By language you usually mean a portable language, not machine language. I believe there are more platforms that have an assembler, but not a C++ compiler and C++ libraries you want to use. Machine language benchmark the hardware, not the compiler. It only means assembler reaches the theoretical limit of performance by choosing right language abstractions, that you wanted to benchmark. But even then, domain experts are more likely to write higher performance code than non-domain experts, so machine language isn't sufficient. Some domain experts don't know (or don't want) any programming language and use matlab instead. Also what's about cost/benefit ratio? How do you benchmark cost/benefit? By eyeballing the source.
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 13:55:28 UTC, Chris wrote: I have neither time nor the required expertise to write a scripting language from scratch ;) You on the other hand ... :-) Oh, it isn't that hard, at least to do a quick basic thing. You might want to start with the various math parsers. A postfix one is relatively easy: 2 3 + break it up into tokens, read them in, build a syntax tree (well, for the postfix thing, it is probably a stack!). That approach will even work for a Lisp-like language! Then try an infix one. You'd use the same tokenizer, but the parser is different... and this kind of parser gets you started for a typical script language. 2 + 3 The way this works is you read the token, peek ahead, create an object and build a tree. You'd use different functions for different contexts. So it might start with readExpression which readFactor. Then readFactor might call readAddend... If you look at the D grammar: http://dlang.org/spec/grammar.html you'll find the various terms are defined as WhateverExpressions and often recursively... you can write the parser to follow that basically the same way! You end up with one of these: https://en.wikipedia.org/wiki/Recursive_descent_parser Once you get addition and multiplication working with correct order of operations, you just kinda start adding stuff! Make a function call and an if/loop statement and boom, you have a simple programming language. After that, it is basically just adding more token recognition and AST classes. To make an interpreter, you can just add a method to the AST objects that interprets and gives a result boom, it works! Compiling is basically the same idea, just spitting out something other than the result of the expression - spitting out code that gives you the result. That gets harder to get into all the fancy techniques, but it builds on the same foundation. It is a good thing to know how to do, at least the basic parts!
We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
Hi,everyone: The 'Programming In D' is a good book for new D coders,we want to start it in Chinese, do you have any good suggestions? Thank you.
Re: Optimizations and performance
On Friday, 10 June 2016 at 09:31:42 UTC, Chris wrote:
Something like
`void main()
{
// Replace anything that looks like a real
// number with the rounded equivalent.
stdin
.byLine
.map!(l => l.replaceAll!(c => c.hit.round)
(reFloatingPoint))
.each!writeln;
}
`
That's a best practice that requires some learning and discipline
to use. A newbie won't write such code.
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 11:11:49 UTC, Chris wrote:
Nice. Anyone interested in turning this into "DScript"? Having
a scripting language powered by D would also boost D's
prestige. And it would be easy to write modules in pure D.
So I use my toy thing from time to time and it is pretty cool. My
favorite part (and the reason I made it) is the easy interop with
D itself: you basically just assign your D functions and values
to a global object and get them out via the same var type - in D!
var globals = var.emptyObject;
globals.write = &(writeln!string);
var result = interpret(your_script_string, globals);
writeln(result);
where the script string looks like:
write("Hi!");
10 + 3 * 4;
and it will work:
$ dmd test.d arsd/script.d arsd/jsvar.d
$ ./test
Hi!
22
So really easy to use in all three ways: D interop is easy, the
script lang itself is easy, and compiling it is easy, it is just
the two modules.
I've even did a bit of GUI and DOM wrapping with it and my
simpledisplay.d and dom.d in toys... a surprisingly big chunk of
things just work.
The downside though is that it is something I basically slapped
together in a weekend to support var.eval on a lark... it has a
few weird bugs and the code is no longer beautiful as it has
grown organically, and it isn't very fast, it is a simple AST
interpreter that makes liberal use of new objects in D (even like
a null object is allocated on the D side), but it is REALLY easy
to use and coupled with native D functions for real work, it
might just be interesting enough to play with.
tho idk if I'd recommend it for serious work. Just use D for that!
Re: Optimizations and performance
On Friday, 10 June 2016 at 14:25:25 UTC, Kagamin wrote: On Friday, 10 June 2016 at 01:54:21 UTC, Ola Fosheim Grøstad wrote: By language you usually mean a portable language, not machine language. I believe there are more platforms that have an assembler, but not a C++ compiler and C++ libraries you want to use. Huh? All platforms have an assembler. You mean inline assembly? That's not really relevant. Machine language benchmark the hardware, not the compiler. It only means assembler reaches the theoretical limit of performance by choosing right language abstractions, that you wanted to benchmark. What language abstractions? There are no abstractions in machine language. Also what's about cost/benefit ratio? How do you benchmark cost/benefit? By eyeballing the source. Not objectively measurable in a meaningful way.
Re: Version identifier for PS4
On Friday, 10 June 2016 at 08:56:57 UTC, Jacob Carlborg wrote: On 2016-06-09 15:16, Steven Schveighoffer wrote: The precedent is to use whatever the OS defines for the host C compiler. This is the reason we have lower case "linux" for version, which is inconsistent with other version identifiers, but consistent with Linux's #define in C code. That's only true for the "linux" identifier. The other ones are using the more "official" name and casing of the operating system. Example: the C preprocessor identifier for OS X is __APPLE__, but in D it's "OSX". If this is the case we would want to use Orbis.
Re: The Problem With DIPs
On Friday, 10 June 2016 at 10:38:49 UTC, Andrei Alexandrescu wrote: On 6/10/16 9:00 AM, Jacob Carlborg wrote: On 2016-06-09 23:34, Walter Bright wrote: That doesn't stop anyone from commenting on them, offering improvements, doing some promotion of them, organizing handling them, etc. If feel that's a bit pointless if no one with some form of authority will look at it. It's much better than making informal remarks on the forum, which then scroll out of memory. I encourage people who have good ideas and are willing and able to take them to completion to formulate them as DIPs. Good quality DIPs will eventually get discussed more often and end up being implemented. -- Andrei What is the statistics for DIPs authored by outsiders vs being implemented?
Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On Friday, 10 June 2016 at 14:26:31 UTC, FrankLike wrote: Hi,everyone: The 'Programming In D' is a good book for new D coders,we want to start it in Chinese, do you have any good suggestions? Thank you. If you want you can also start to translate the DLang Tour (tour.dlang.org). It already has multi-lingual support, and we will start translating it soon - we just wait until the major wave of improvements is in. https://github.com/stonemaster/dlang-tour/issues/132 If you want to translate the 'Programming in D', you should ping Ali directly for help. You can find his contact details here: http://ddili.org/ders/d.en/
Re: The Problem With DIPs
On Friday, 10 June 2016 at 14:38:35 UTC, Ola Fosheim Grøstad wrote: On Friday, 10 June 2016 at 10:38:49 UTC, Andrei Alexandrescu wrote: On 6/10/16 9:00 AM, Jacob Carlborg wrote: On 2016-06-09 23:34, Walter Bright wrote: That doesn't stop anyone from commenting on them, offering improvements, doing some promotion of them, organizing handling them, etc. If feel that's a bit pointless if no one with some form of authority will look at it. It's much better than making informal remarks on the forum, which then scroll out of memory. I encourage people who have good ideas and are willing and able to take them to completion to formulate them as DIPs. Good quality DIPs will eventually get discussed more often and end up being implemented. -- Andrei What is the statistics for DIPs authored by outsiders vs being implemented? I don't think that any DIP was proposed by an outsider - the major problem is that the "Approval" process isn't formal at all, that's why so many DIPs are "Drafts". Have a look yourself at the DIP wiki: http://wiki.dlang.org/DIP
Re: The Problem With DIPs
On Friday, 10 June 2016 at 14:44:22 UTC, Seb wrote: I don't think that any DIP was proposed by an outsider - the major problem is that the "Approval" process isn't formal at all, that's why so many DIPs are "Drafts". Have a look yourself at the DIP wiki: http://wiki.dlang.org/DIP Hm, were these done by outsiders maybe: DIP 6 by Ary Borenszweig in 2009 DIP 20 by Alex Rønne Petersen in 2012 I can't find any later ones.
Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On 06/10/2016 07:41 AM, Seb wrote: > On Friday, 10 June 2016 at 14:26:31 UTC, FrankLike wrote: >> Hi,everyone: >> The 'Programming In D' is a good book for new D coders,we want to >> start it in Chinese, do you have any good suggestions? >> >> Thank you. > > If you want you can also start to translate the DLang Tour > (tour.dlang.org). > It already has multi-lingual support, and we will start translating it > soon - we just wait until the major wave of improvements is in. > > https://github.com/stonemaster/dlang-tour/issues/132 Agreed! I think that project has immediate impact and I think smaller in scope. > If you want to translate the 'Programming in D', you should ping Ali > directly for help. You can find his contact details here: > http://ddili.org/ders/d.en/ Right. For convenience, here are some information to the translators: The following is a modified version of what I had written for a German translation (which did not happened). The information assumes that the translation remains as a subdirectory of the ddili project. Otherwise, the translator can simply translate files one by one to a target location. Anyway, here is the information: First, I would have to create the directory structure for the Chinese translation. You would have to clone the repo after that: https://bitbucket.org/acehreli/ddili If you clone that repository and 'make' everything, there should be the following files generated: src/ders/d.cn/编程在D.print.pdf src/ders/d.cn/编程在D.pdf public_html_test/ders/d.cn/* (Or we can leave the file names in Latin characters as Programming_in_D.print.pdf, etc.) Chapter files end with .d and the solutions for a chapter are in the file that ends with .cozum.d (e.g. hello_world.d and hello_world.cozum.d). As described in the top-level README, you have to have Prince XML installed as well as a recent dmd compiler. (I think I've neglected to write there that Linux is a requirement as well.) Also, you need to add a new ChineseAlphabet class to alphabet.d and associate it with the "chinese" language in that file. Temporarily, it uses EnglishAlphabet. To make the editing process easier, you should only make the 'test' target and open the relevant chapter on your local browser. For example, open the following file: public_html_test/ders/d.cn/hello_world.html Of course, feel free to rename the chapter files to Chinese ones. This is what I constantly do when editing a chapter: 1) Open the file in my browser 2) Edit the chapter in most amazing editor 3) Alt-Tab to switch to the browser 4) F5 to update the page I recommend against building the pdf versions frequently because that takes a lot of time. Please contact me at acehr...@yahoo.com to start the process and to see how it goes. Would you be open to having one or more technical editors review the chapters as you post a pull request? That would improve the quality. Ali
[OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 14:25:37 UTC, Adam D. Ruppe wrote: To make an interpreter, you can just add a method to the AST objects that interprets and gives a result boom, it works! Given my limited knowledge of compilers/interpreters, this part kind of seems like magic. Let's say you have something simple like 1+2, you would build an AST that looks something like + / \ 1 2 What would be the next step?
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:03:30 UTC, jmh530 wrote: On Friday, 10 June 2016 at 14:25:37 UTC, Adam D. Ruppe wrote: To make an interpreter, you can just add a method to the AST objects that interprets and gives a result boom, it works! Given my limited knowledge of compilers/interpreters, this part kind of seems like magic. Let's say you have something simple like 1+2, you would build an AST that looks something like + / \ 1 2 What would be the next step? 1. this is heavily OT. ;-) 2. you may take a look at my gml engine. it has clearly separated language parser and AST builder (gaem.parser), and AST->VM compiler (gaem.runner/compiler.d).
Re: Fixed date to move to ddox for Phobos documentation
On 06/05/2016 11:21 AM, Jacob Carlborg wrote: > I found a minor issue recently. If there's more than one symbol in the > same module with the same name but with different casing, all these > symbols are shown on the same "single symbol page". Not sure if that's > solvable due to some operating systems not using case sensitive file > systems. We specifically fix it that way. [Issue 12526 – DDox possible issue with case sensitive file names](https://issues.dlang.org/show_bug.cgi?id=12526) If only the casing differs, the entities should always belong together. -Martin
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:03:30 UTC, jmh530 wrote: On Friday, 10 June 2016 at 14:25:37 UTC, Adam D. Ruppe wrote: To make an interpreter, you can just add a method to the AST objects that interprets and gives a result boom, it works! Given my limited knowledge of compilers/interpreters, this part kind of seems like magic. Let's say you have something simple like 1+2, you would build an AST that looks something like + / \ 1 2 What would be the next step? https://en.wikipedia.org/wiki/Tree_traversal#Post-order
Re: Andrei's list of barriers to D adoption
On Friday, June 10, 2016 07:45:03 Ola Fosheim Grøstad via Digitalmars-d wrote:
> On Friday, 10 June 2016 at 05:37:37 UTC, Jonathan M Davis wrote:
> > I assume that you're not from the US?
>
> Right, I am in Oslo (Norway).
>
> > In the US at least, professional programmers are almost always
> > referred to officially as software engineers (though they use
> > the term programmers informally all the time), whereas the
> > terms computer science and computer scientist are generally
> > reserved for academics
>
> Well, I don't know what is "official". Some norwegian companies
> seem to use convoluted "international business" terminology for
> everything, which is just weird and "snobbish". I think "system
> developer" ("systemutvikler") is the broad general term here.
Well, I meant official as in what someone's job title would be. Most
developers have titles like "Software Engineer" or "Senior Softweer
Engineer." They'e frequently called programmers and/or software developers
when not talking about titles.
> So you can be an "informatiker" (broad term for your education)
> with an education in the fields of "computer science" and
> "software engineering", and work in the role of a "system
> developer".
>
> If you have a bachelor that fulfills the requirements for
> starting on a comp.sci. master then you are a computer scientist,
> but if you have a bachelor that doesn't and focus more on
> practical computing then you are a software engineer?
>
> You can have an education that is all about discrete math and
> still be a computer scientist. You couldn't then say you have a
> bachelor in software engineering, as it would be wrong. Likewise,
> you can have a bachelor in software engineering and barely know
> anything about complexity theory.
Yeah. Most universities in the US have a Computer Science degree, but some
have Software Engineering as a separate degree. My college had Computer
Science, Software Engineer, and Computer Engineering, which is atypical. All
of them took practical courses, but the SE guys didn't have to take some of
the more theoretical stuff and instead took additional classes focused on
working on projects in teams and whatnot. And CPE was basically a hybrid
between Computer Science and Electrical Engineering with an aim towards
embedded systems. But all of them had more of a practical focus than is the
case at many schools, because the school's motto is "learn by doing," and
they focus a lot on the practical side of things, whereas many Computer
Science programs suffer from not enough practical skills being taught. The
college in the city where I lived for my last job is notoriously bad at
teaching their Computer Science students much in the way of practical
skills.
I think that it's by far the most typical though that someone gets a degree
in Computer Science (with varying degrees of practical skils involved) and
then takes a job as a Software Engineer. And if you got a good focus on
pratical skills in school in addition to the theory, then you went to a good
school, whereas some schools do a very poor job on the practical side of
things.
> > And while the term informatics (or very similar terms) are used
> > in several other languages/countries, I've never heard the term
> > used in the US except to mention that some other
> > languages/countries use the term informatics for computer
> > science, and I'm willing to bet that relatively few programmers
> > in the US have ever even heard the term informatics.
>
> Yes, but it makes sense to distinguish between "computer science"
> (the timeless math and concepts behind computing) and "software
> engineering" (contemporary development methodology and practice).
> Although I think an education should cover both. "Informatics"
> just covers it all (as an educational field).
Agreed. A good education covers both the theoritical stuff and the practical
stuff, and some schools do distinguish based on what the focus of their
program is, but in the US at least, it's very common to have a Computer
Science program and less common to have a Software Engineering program
(though I think that Software Engineering degrees are becoming more common).
- Jonathan M Davis
Re: Fixed date to move to ddox for Phobos documentation
On 06/04/2016 09:32 PM, Andrei Alexandrescu wrote: > Sounds good to me, thanks. Delegation/lieutenantship/empowering for the > win. I think we should also secure Martin's buy-in to make sure. -- Andrei I'm fine with switching to ddox, could have happened a while ago. Would be worth to switch for the auto-complete alone. I'd want to disable or replace discourse before we make it our official documentation. We could easily self-host some commenting functionality if deemed necessary, but adding an unmaintained communication channel isn't the best idea IMO. -Martin
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 14:25:37 UTC, Adam D. Ruppe wrote: On Friday, 10 June 2016 at 13:55:28 UTC, Chris wrote: I have neither time nor the required expertise to write a scripting language from scratch ;) You on the other hand ... :-) Oh, it isn't that hard, at least to do a quick basic thing. You might want to start with the various math parsers. A postfix one is relatively easy: 2 3 + break it up into tokens, read them in, build a syntax tree (well, for the postfix thing, it is probably a stack!). That approach will even work for a Lisp-like language! Then try an infix one. You'd use the same tokenizer, but the parser is different... and this kind of parser gets you started for a typical script language. 2 + 3 The way this works is you read the token, peek ahead, create an object and build a tree. You'd use different functions for different contexts. So it might start with readExpression which readFactor. Then readFactor might call readAddend... If you look at the D grammar: http://dlang.org/spec/grammar.html you'll find the various terms are defined as WhateverExpressions and often recursively... you can write the parser to follow that basically the same way! You end up with one of these: https://en.wikipedia.org/wiki/Recursive_descent_parser Once you get addition and multiplication working with correct order of operations, you just kinda start adding stuff! Make a function call and an if/loop statement and boom, you have a simple programming language. After that, it is basically just adding more token recognition and AST classes. To make an interpreter, you can just add a method to the AST objects that interprets and gives a result boom, it works! Compiling is basically the same idea, just spitting out something other than the result of the expression - spitting out code that gives you the result. That gets harder to get into all the fancy techniques, but it builds on the same foundation. It is a good thing to know how to do, at least the basic parts! I agree. It's good to know how to do it. But don't get me started, else I'll have a new obsession ... ;) But seriously, would you like to work on something like DScript. Your scripting language already fulfills things that were on my wishlist (easy D interop).
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 14:34:53 UTC, Adam D. Ruppe wrote: var globals = var.emptyObject; globals.write = &(writeln!string); Woah, I never thought of using it like that! The downside though is that it is something I basically slapped together in a weekend to support var.eval on a lark... it has a few weird bugs And yet it somehow seems to _work_ better than std.variant. :/ tho idk if I'd recommend it for serious work. Just use D for that! I use it in my toml parser and it's very pleasant. I figured it probably isn't very fast, but it works and that's important. -Wyatt
Re: Fixed date to move to ddox for Phobos documentation
On 06/04/2016 08:23 PM, Sönke Ludwig wrote: > I think they have. Vladimir has reported a bunch of them over time and > all of those have been fixed. Found a new one ;). [Issue 16152 – dpl-docs/ddox doesn't show documentation for eponymous template member](https://issues.dlang.org/show_bug.cgi?id=16152)
Re: The Problem With DIPs
On 6/10/16 10:52 AM, Ola Fosheim Grøstad wrote: On Friday, 10 June 2016 at 14:44:22 UTC, Seb wrote: I don't think that any DIP was proposed by an outsider - the major problem is that the "Approval" process isn't formal at all, that's why so many DIPs are "Drafts". Have a look yourself at the DIP wiki: http://wiki.dlang.org/DIP Hm, were these done by outsiders maybe: DIP 6 by Ary Borenszweig in 2009 No, Ary was a regular at that time. DIP 20 by Alex Rønne Petersen in 2012 Alex is a member of Phobos, druntime, dlang.org, and tools team. -Steve
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:14:02 UTC, ketmar wrote: 1. this is heavily OT. ;-) I didn't forget to mark it! :-) 2. you may take a look at my gml engine. it has clearly separated language parser and AST builder (gaem.parser), and AST->VM compiler (gaem.runner/compiler.d). I couldn't for the life of me find a link to this.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:35:32 UTC, jmh530 wrote: On Friday, 10 June 2016 at 15:14:02 UTC, ketmar wrote: 2. you may take a look at my gml engine. it has clearly separated language parser and AST builder (gaem.parser), and AST->VM compiler (gaem.runner/compiler.d). I couldn't for the life of me find a link to this. He linked it earlier: http://repo.or.cz/gaemu.git/tree/HEAD:/gaem/parser -Wyatt
Re: The Problem With DIPs
On Friday, 10 June 2016 at 15:37:31 UTC, Steven Schveighoffer wrote: DIP 20 by Alex Rønne Petersen in 2012 Alex is a member of Phobos, druntime, dlang.org, and tools team. Aww, apologies to Alex :-) Modifying the compiler might be more productive than writing a DIP, then.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:40:45 UTC, Wyatt wrote: He linked it earlier: http://repo.or.cz/gaemu.git/tree/HEAD:/gaem/parser -Wyatt Cheers.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:35:32 UTC, jmh530 wrote: On Friday, 10 June 2016 at 15:14:02 UTC, ketmar wrote: 1. this is heavily OT. ;-) I didn't forget to mark it! :-) Well, yeah, we should start a new thread, but compiler programming isn't really off topic at all on a forum where we talk about programming a compiler! Knowing the idea helps reading dmd source too.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:03:30 UTC, jmh530 wrote:
Let's say you have something simple like 1+2, you would build
an AST that looks something like
+
/ \
1 2
What would be the next step?
https://github.com/adamdruppe/arsd/blob/master/script.d#L879
The function is pretty simple: interpret the left hand side (here
it is 1, so it yields int(1)), interpret the right hand side
(yields int(2)), combine them with the operator ("+") and return
the result.
Notice that interpreting the left hand side is a recursive call
to the interpret function - it can be arbitrarily complex, and
the recursion will go all the way down, then all the way back up
to get the value.
Re: OT – the Javaverse [was Andrei's list of barriers to D adoption]
On Tue, 2016-06-07 at 15:15 +, Chris via Digitalmars-d wrote: > […] > Java has lambdas now (since version 8, I think) and I read > somewhere that it's not certain that Java programmers will adopt > (i.e. use) them at all. D has the advantage that its users are > […] Whatever you read, the writer didn't really know what they were talking about. At least not in general, and if they were talking of the Javaverse as a whole. Java 8 features such as lambda expressions, Streams, method references, etc. are no longer even controversial. There is a world-wide activity in transforming Java 6 and Java 7 code to Java 8. Yes some of this is pull rather than push, and I am sure there are islands of intransigence (*). However the bulk of Java programmers will eventually get and use the features. Of course many people have stopped using Java and use Kotlin, Ceylon, or Scala (**). The crucial point here is that the Javaverse is much, much more than just the Java language. (*) Usually people who think Java 5 was a bad move and stick with Java 1.4.2. (**) There are others but these are the main players. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Scripting in D (was Andrei's list of barriers to D adoption)
On Friday, 10 June 2016 at 15:29:01 UTC, Chris wrote: But seriously, would you like to work on something like DScript. Your scripting language already fulfills things that were on my wishlist (easy D interop). I'm best when working on something that I'm actively using, since then I find the bugs myself and have some personal thing to gain (a lot of times, I can take time out of the day job to do it then, since it contributes directly back to it)... and alas, right now, I'm not actively using it. I do have some plans for it, but no set schedule. That said though, it is already fairly useful... if you guys use it and report bugs/feature requests, I can probably respond to that.
Re: D's memory-hungry templates
On 6/10/16 11:09 AM, maik klein wrote: On Friday, 10 June 2016 at 10:27:09 UTC, Andrei Alexandrescu wrote: On 6/9/16 7:56 PM, maik klein wrote: Also C++ beat D in every compile time meta programming benchmark that I have tested. Intriguing. Do you have a couple of representative benchmarks along with their C++ counterparts to post to bugzilla? Thanks! -- Andrei Not in a presentable form, I still have a framework on my other machine. I basically generated new D files from within D and then compiled them using ldc/dmd. I could clean it up and upload it when I have some time. That would be very helpful. Thanks! -- Andrei
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:30:19 UTC, Wyatt wrote:
globals.write = &(writeln!string);
Woah, I never thought of using it like that!
Yeah, since writeln is a template, you need to instantiate it
with some arguments. This isn't the ideal way to do it in the
script btw, it'd be like:
globals.write = (var this_, var[] args) { writeln(args); };
or something like that - this signature gives a variadic function
to the scripting language, whereas writeln!string just has a
single argument.
But, of course, the script language cannot instantiate D
templates itself, so you gotta do that before assigning it to the
runtime var. But from there, the jsvar.d reflection code will
handle the rest of var<->string conversions.
I use it in my toml parser and it's very pleasant. I figured
it probably isn't very fast, but it works and that's important.
kewl! Did you use the script component for interpreting or just
the jsvar part for the data?
Re: Killing the comma operator
On 6/10/16 1:02 PM, Mathias Lang wrote: On Thursday, 12 May 2016 at 10:29:36 UTC, Andrei Alexandrescu wrote: Before we get lost in the discussions, let's act on this by disallowing taking the result of the comma operator. Yes there is potential breakage (via typeof as Timon noted) but it's likely to be minimal. Once we have that in place we have more options. Thx! -- Andrei Just a quick update on that topic: using the return of a comma operator now yield a deprecation message (using DMD ~master). This will be part of 2.072.0. Thanks everyone for your feedback ! That's terrific. Thank you!! -- Andrei
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:27:03 UTC, Jonathan M Davis wrote: Most developers have titles like "Software Engineer" or "Senior Softweer Engineer." They'e frequently called programmers and/or software developers when not talking about titles. Neither academia or businesses use Computer Scientist as a job title... tough? Yeah. Most universities in the US have a Computer Science degree, but some have Software Engineering as a separate degree. My college had Computer Science, Software Engineer, and Computer Engineering, which is atypical. All of them took practical courses, but the SE guys didn't have to take some of the more theoretical stuff and instead took additional classes focused on working on projects in teams and whatnot. Sounds like a good setup. At my uni we could pick freely what courses we wanted each semester, but needed a certain combination of fields and topics to get a specific degree. Like for entering computer science you would need the most feared topic, Program Verification taught by Ole-Johan Dahl (co-creator of Simula) who was very formal on the blackboard... I felt it was useless at the time, but there are some insights you have to be force-fed... only to be appreciated later in life. It is useless, but still insightful. Not sure if those more narrow programs are doing their students a favour, as often times the hardest part is getting a good intuition for the basics of a topic, while getting the "expert" knowledge for a specific task is comparatively easier. Especially now we have the web. So, being "forced" to learning the basics of a wider field is useful. I'm rather sceptical of choosing C++ as a language for instance. Seems like you would end up wasting a lot of time on trivia and end up students hating programming...
Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 17:10:39 UTC, Adam D. Ruppe wrote: On Friday, 10 June 2016 at 15:30:19 UTC, Wyatt wrote: I use it in my toml parser and it's very pleasant. I figured it probably isn't very fast, but it works and that's important. kewl! Did you use the script component for interpreting or just the jsvar part for the data? Just the jsvar; I've got a Ppegged grammar mixin doing most of the heavy lifting. IIRC, you actually wrote it around the time I was fighting a losing battle with nested Variant arrays and it saved me a lot of headache. -Wyatt
Re: Fixed date to move to ddox for Phobos documentation
On 6/10/16 3:17 PM, Martin Nowak wrote: On 06/04/2016 09:32 PM, Andrei Alexandrescu wrote: Sounds good to me, thanks. Delegation/lieutenantship/empowering for the win. I think we should also secure Martin's buy-in to make sure. -- Andrei I'm fine with switching to ddox, could have happened a while ago. Would be worth to switch for the auto-complete alone. Awesome! I should add that it would be valuable to keep the ddoc build as well. In my introductory material on D I discuss the basic elements of distribution: function, unittest, doc, deployment. It is compelling to mention that we build the stdlib documentation using the same means. An introduction to ddox at that point would be too much, and mentioning that "well ddoc isn't good enough for the official stdlib doc" does not sit well. I'd want to disable or replace discourse before we make it our official documentation. We could easily self-host some commenting functionality if deemed necessary, but adding an unmaintained communication channel isn't the best idea IMO. I'm a bit bummed about that. I like it. Is my understanding incorrect that disqus is fairly established by now? I see it on a bunch of legit sites, and it seems to add value to those as it could add to ours. Andrei
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 17:02:06 UTC, Adam D. Ruppe wrote:
https://github.com/adamdruppe/arsd/blob/master/script.d#L879
The function is pretty simple: interpret the left hand side
(here it is 1, so it yields int(1)), interpret the right hand
side (yields int(2)), combine them with the operator ("+") and
return the result.
Notice that interpreting the left hand side is a recursive call
to the interpret function - it can be arbitrarily complex, and
the recursion will go all the way down, then all the way back
up to get the value.
Ah, it produces mixin("1+2") and evaluates that.
What's the PrototypeObject sc I see everywhere doing?
Re: Fixed date to move to ddox for Phobos documentation
On 6/10/16 1:33 PM, Andrei Alexandrescu wrote: On 6/10/16 3:17 PM, Martin Nowak wrote: I'd want to disable or replace discourse before we make it our official documentation. We could easily self-host some commenting functionality if deemed necessary, but adding an unmaintained communication channel isn't the best idea IMO. I'm a bit bummed about that. I like it. Is my understanding incorrect that disqus is fairly established by now? I see it on a bunch of legit sites, and it seems to add value to those as it could add to ours. I can see a good reason to have a disqus forum for each page, as I have found tremendous value from the php.net forums on each symbol (with common tricks to use with the given function). But the problem is, people will ask questions on these forums, and likely will not get answers. I know I'm not going to peruse the docs looking for questions to answer. It's like adding 1000 black holes for newbies to get trapped in. So what would be the use cases? If we have legitimate reasons to have it, that aren't better solved by routing back to the D forums, or back to github itself (e.g. if you have a trick to post, instead of using disqus, create a PR with the example!). -Steve
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 17:36:02 UTC, jmh530 wrote:
Ah, it produces mixin("1+2") and evaluates that.
Sort of, 1 and 2 are both runtime variables there so it really
produces mixin("a+b") after setting a = 1 and b = 2 above.
But yeah, that's the idea - it just hoists that mixin to runtime
for scripting.
What's the PrototypeObject sc I see everywhere doing?
sc is short for "scope" - it refers to the chain of local
variables. So consider the following:
var a = 1;
function foo() {
var b = 4;
var c = a + b;
}
foo();
So as this is interpreted by my thing, it is like it runs the
following D code:
// this happens as part of the interpreter initialization
auto globalScope = new
PrototypeObject(globals_the_d_programmer_passed);
// now it starts running
auto currentScope = globalScope;
// var a = 1;
currentScope["a"] = 1; // it holds the local variables!
call_function("foo", []); // script foo();
// when we enter the new scope inside the function, it
// creates a new object, based on the old one
currentScope = new PrototypeObject(currentScope);
// var b = 4;
currentScope["b"] = 4; // remember the scope changed above, so
this is local to the function now
// var c = a + b;
currentScope["c"] = currentScope["a"] + currentScope["b"];
/*
OK, so at this point, we get two variables: a and b. That's
what the sc object in the script.d source represents - what
I called currentScope here.
The opIndex does two things: check the current scope for the
name. If it is there, return that value. If not, go up to
the parent scope and look there. Continue until you find it,
of if it isn't there, throw a "no such variable" exception.
It'd find b in the current scope and return the
function-local variable, and it'd find a in the parent scope.
*/
// and now that the function is over, we pop off the local
// variables from the function by setting the current back
// to the old parent
currentScope = currentScope.parent;
So yeah, the sc in the interpreter is just the currentScope from
the pseudocode, a chain of AAs holding the local variables.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 17:59:15 UTC, Adam D. Ruppe wrote: What's the PrototypeObject sc I see everywhere doing? sc is short for "scope" - it refers to the chain of local variables. So consider the following: [snip] Cool. Thanks.
[OT] Re: Andrei's list of barriers to D adoption
On Friday, June 10, 2016 17:20:29 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Friday, 10 June 2016 at 15:27:03 UTC, Jonathan M Davis wrote: > > Most developers have titles like "Software Engineer" or "Senior > > Softweer Engineer." They'e frequently called programmers and/or > > software developers when not talking about titles. > > Neither academia or businesses use Computer Scientist as a job > title... tough? In academia, you'd be a professor of Computer Science or a professor in the Computer Science department. You wouldn't normally be called a Computer Scientist - certainly not as a job title. And in businesses, the only companies that even _might_ have Computer Scientist as a title would be where it was a very research-heavy job, which would not be at all normal. Research-heavy jobs like that do exist in some large companies, but in the vast majority of cases, programmers are hired as Software Engineers to write code for actual products. > > Yeah. Most universities in the US have a Computer Science > > degree, but some have Software Engineering as a separate > > degree. My college had Computer Science, Software Engineer, and > > Computer Engineering, which is atypical. All of them took > > practical courses, but the SE guys didn't have to take some of > > the more theoretical stuff and instead took additional classes > > focused on working on projects in teams and whatnot. > > Sounds like a good setup. At my uni we could pick freely what > courses we wanted each semester, but needed a certain combination > of fields and topics to get a specific degree. Like for entering > computer science you would need the most feared topic, Program > Verification taught by Ole-Johan Dahl (co-creator of Simula) who > was very formal on the blackboard... I felt it was useless at the > time, but there are some insights you have to be force-fed... > only to be appreciated later in life. It is useless, but still > insightful. > > Not sure if those more narrow programs are doing their students a > favour, as often times the hardest part is getting a good > intuition for the basics of a topic, while getting the "expert" > knowledge for a specific task is comparatively easier. Especially > now we have the web. So, being "forced" to learning the basics of > a wider field is useful. I tend to be of the opinion that the best colloge program has all of the more theoretical stuff, because it provides a solid base for real life programming, but project-based, real world stuff is also very important to help prepare students for actual jobs. Too many college programs do very little with helping prepare students for actual programming jobs, but at the same time, I think that skipping a lot of the theoretical stuff will harm students in the long run. But striking a good balance isn't exactly easy, and it's definitely the case that a lot of the more theoretical stuff isn't as obviously useful then as it is later. In some ways, it would actually be very beneficial to actually go back to school to study that stuff after having programmed professionally for a while, but that's a pain to pull off time-wise, and the classes aren't really designed with that in mind anyway. > I'm rather sceptical of choosing C++ as a language for instance. > Seems like you would end up wasting a lot of time on trivia and > end up students hating programming... Choosing the right language for teaching is an endless debate with all kinds of pros and cons. Part of the problem is that good languages for professional work tend to be complicated with advantages aimed at getting work done rather than teaching, which causes problems for teaching, but picking a language that skips a lot of the compilications means that students aren't necessarily well-prepared to deal with the more complicated aspects of a language. When I started out in school, C++ was the main language, but it quickly changed to Java, which removes all kinds of certain problems, but it still has a lot of extra cruft (like forcing everything to be in a class and a ton of attributes forced to be on main), and it doesn't at all prepare students to properly deal with pointers and memory. So, students starting out with Java have some fun problems when they then have to deal with C or C++. Alternatively, there are folks in favor of starting with functional languages, which has certain advantages, but it's so different from how folks would program normally that I'm not sure that it's ultimately a good idea. All around, it's a difficult problem, and I don't know wha the right choice is. In general, there are serious problems with teaching with real world languages, and teaching with a language that was designed for teaching doesn't necessarily prepare students for the real world. I don't envy teachers having to figure out how to teach basic programming concepts. Regardless, I think that students should be at least exposed to both the imperative/OO languages and the functional languages over
Re: Killing the comma operator
On Fri, Jun 10, 2016 at 05:11:59PM +, Andrei Alexandrescu via Digitalmars-d wrote: > On 6/10/16 1:02 PM, Mathias Lang wrote: > > On Thursday, 12 May 2016 at 10:29:36 UTC, Andrei Alexandrescu wrote: > > > Before we get lost in the discussions, let's act on this by > > > disallowing taking the result of the comma operator. Yes there is > > > potential breakage (via typeof as Timon noted) but it's likely to > > > be minimal. Once we have that in place we have more options. Thx! > > > -- Andrei > > > > Just a quick update on that topic: using the return of a comma > > operator now yield a deprecation message (using DMD ~master). This > > will be part of 2.072.0. Thanks everyone for your feedback ! > > That's terrific. Thank you!! -- Andrei Hooray! One small step in the right direction of killing off the comma operator for good. T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On Friday, 10 June 2016 at 14:26:31 UTC, FrankLike wrote: Hi,everyone: The 'Programming In D' is a good book for new D coders,we want to start it in Chinese, do you have any good suggestions? Thank you. 太好了！很不幸，我的中文知识不足够的，所以不可能帮你们。加油，我很兴奋的！
Re: GSlice - Re: [OT] About GC: The Future of Rust : GC integration
On Wednesday, 8 June 2016 at 17:23:22 UTC, deadalnix wrote: I wonder if Andrei's allocator API supports freeing with a size argument. ... This extra bit of infos seems to be less useful in practice than you'd naively expect. Someone may come up with something interesting to do with it someday, but I haven't seen anything that groundbreaking so far. OK. What if the allocation size was passed as a compile time parameter on deallocation? Then CTFE could calculate e.g. the next power of 2.
Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On Friday, 10 June 2016 at 15:04:52 UTC, Ali Çehreli wrote: src/ders/d.cn/编程在D.print.pdf src/ders/d.cn/编程在D.pdf Is "programming" composed as "edit journey" in chinese? That's kinda philosphical. :-)
Allowing DConf presentations to be spoken in other languages
After this year's DConf I started to wonder if it could be beneficial to provide a slot during the conference where the speaker would do his presentation in a language other than English. I realize that many are like me and would not be able to consume such information, which is why the suggestion is to limit talks from other languages. My hope would be that it would help produce more language information content outside of English and strengthen those communities. Possibly uniting communities we don't see, but still center around D. This isn't for me, such an idea is not helpful for me. Is there anyone in a position who could speak to this being a reasonable thing to try?
Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On Friday, 10 June 2016 at 20:47:16 UTC, Ola Fosheim Grøstad wrote: On Friday, 10 June 2016 at 15:04:52 UTC, Ali Çehreli wrote: src/ders/d.cn/编程在D.print.pdf src/ders/d.cn/编程在D.pdf Is "programming" composed as "edit journey" in chinese? That's kinda philosphical. :-) Not quite. Many words in Chinese have roughly 10 different meanings in different contexts, which all gets very hard to keep track of. 编 can mean to edit in the sense of editing a newspaper, but it can also mean to weave, to organize, to write, or to fabricate. 程 is a noun that can mean rule, like "follow the rules", procedure, distance, or journey. The best way to translate it is of course "to program", but if you were to assign meaning to each character the best translation would probably be "to write a list of rules [for the computer to follow]".
I'd love to see DScript one day ...
On 6/10/2016 3:55 AM, Chris wrote: > Cool. I'd love to see `DScript` one day - and replace JS once and for all ... > well ... just day dreaming ... Dreams are reality: https://github.com/DigitalMars/DMDScript
Re: Andrei's list of barriers to D adoption
On 6/10/2016 3:55 AM, Chris wrote: Cool. I'd love to see `DScript` one day - and replace JS once and for all ... well ... just day dreaming ... Started a new thread for that.
Re: Allowing DConf presentations to be spoken in other languages
On Friday, 10 June 2016 at 21:31:36 UTC, Jesse Phillips wrote: After this year's DConf I started to wonder if it could be beneficial to provide a slot during the conference where the speaker would do his presentation in a language other than English. I realize that many are like me and would not be able to consume such information, which is why the suggestion is to limit talks from other languages. My hope would be that it would help produce more language information content outside of English and strengthen those communities. Possibly uniting communities we don't see, but still center around D. How about organizing local D conferences? It could be DConf Europe or even more specific like DConf Japan. This is very common & popular in the JS community: http://jsconf.com Let's make that happen!
Re: Allowing DConf presentations to be spoken in other languages
On Friday, 10 June 2016 at 21:31:36 UTC, Jesse Phillips wrote: After this year's DConf I started to wonder if it could be beneficial to provide a slot during the conference where the speaker would do his presentation in a language other than English. I realize that many are like me and would not be able to consume such information, which is why the suggestion is to limit talks from other languages. My hope would be that it would help produce more language information content outside of English and strengthen those communities. Possibly uniting communities we don't see, but still center around D. This isn't for me, such an idea is not helpful for me. Is there anyone in a position who could speak to this being a reasonable thing to try? That's what local or national conferences are for. Still, even in such ones people often prefer to use English (I've seen it in Portugal and Poland), as CS vocabulary for other languages is usually awkward, non-consistent or non-existent, and it feels even more awkward to use English verbs and nouns interspersed with your native prepositions.
Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On Friday, 10 June 2016 at 21:32:47 UTC, Meta wrote: On Friday, 10 June 2016 at 20:47:16 UTC, Ola Fosheim Grøstad wrote: On Friday, 10 June 2016 at 15:04:52 UTC, Ali Çehreli wrote: src/ders/d.cn/编程在D.print.pdf src/ders/d.cn/编程在D.pdf Is "programming" composed as "edit journey" in chinese? That's kinda philosphical. :-) Not quite. Many words in Chinese have roughly 10 different meanings in different contexts, which all gets very hard to keep track of. 编 can mean to edit in the sense of editing a newspaper, but it can also mean to weave, to organize, to write, or to fabricate. 程 is a noun that can mean rule, like "follow the rules", procedure, distance, or journey. The best way to translate it is of course "to program", but if you were to assign meaning to each character the best translation would probably be "to write a list of rules [for the computer to follow]". 编 可以是 编写 的缩写 编 could be short for 编写(write) 程 可以是 程序 的缩写 程 could be short for 程序(program) 编程 即 编写程序 So 编程 means writing programs aka programming.
Re: Allowing DConf presentations to be spoken in other languages
On Friday, 10 June 2016 at 21:31:36 UTC, Jesse Phillips wrote: After this year's DConf I started to wonder if it could be beneficial to provide a slot during the conference where the speaker would do his presentation in a language other than English. I realize that many are like me and would not be able to consume such information, which is why the suggestion is to limit talks from other languages. My hope would be that it would help produce more language information content outside of English and strengthen those communities. Possibly uniting communities we don't see, but still center around D. This isn't for me, such an idea is not helpful for me. Is there anyone in a position who could speak to this being a reasonable thing to try? against reading subtitles?
Re: Allowing DConf presentations to be spoken in other languages
On 6/10/2016 2:31 PM, Jesse Phillips wrote: After this year's DConf I started to wonder if it could be beneficial to provide a slot during the conference where the speaker would do his presentation in a language other than English. We hope to have them subtitled / close captioned in the future, which will help our deaf and ESL viewers. It will also mean that transcripts can be made, which will help people who don't have the time to watch them.
Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On Saturday, 11 June 2016 at 00:38:24 UTC, mogu wrote: 编 可以是 编写 的缩写 编 could be short for 编写(write) 程 可以是 程序 的缩写 程 could be short for 程序(program) 编程 即 编写程序 So 编程 means writing programs aka programming. 谢谢你纠正我，说中文不容易的。
Re: I'd love to see DScript one day ...
On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote: On 6/10/2016 3:55 AM, Chris wrote: Cool. I'd love to see `DScript` one day - and replace JS once and for all ... well ... just day dreaming ... Dreams are reality: https://github.com/DigitalMars/DMDScript I have a feeling this will end up like your compiled Java story. Just my pessimism speaking.
Re: Fixed date to move to ddox for Phobos documentation
On Friday, 10 June 2016 at 17:33:01 UTC, Andrei Alexandrescu wrote: I should add that it would be valuable to keep the ddoc build as well. We need DDoc anyway for the website itself, as well as formats other than the website (e.g. CHM and HTML files distributed with the compiler), so it's not going away.
Re: I'd love to see DScript one day ...
On Saturday, 11 June 2016 at 04:13:26 UTC, Jack Stouffer wrote: On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote: On 6/10/2016 3:55 AM, Chris wrote: Cool. I'd love to see `DScript` one day - and replace JS once and for all ... well ... just day dreaming ... Dreams are reality: https://github.com/DigitalMars/DMDScript I have a feeling this will end up like your compiled Java story. Just my pessimism speaking. Depends on whether it is conforming to edition 6. Modern frameworks use edition 6 or 5, and edition 6 may become ISO/IEC 16262:2016. For Go a similar project seems to be the most popular interpreter project: https://github.com/robertkrimen/otto Benchmarks, conformance comparisons?
