Re: Anyone working on updated Qt bindings?
On Friday, 13 November 2015 at 21:30:34 UTC, karabuta wrote: On Friday, 13 November 2015 at 20:03:38 UTC, Ramon wrote: Just for note, you can make desktop D applications in HTML/CSS3/scripting using https://github.com/midiway/sciter-dport May be Github's Electron or D's webview bindings(which also abstracts too much, with too much weird naming conventions) IMO. No, there is a lot of difference between engines. Chromium is tailored for web-browsers, while Sciter goal is for making desktop apps, so it is more lighweight and flexible. Electron is a binary distribution so its pretty hard to mix any new native code. You don't need to know nothing about Sciter API to start off, you can just download a project from http://misoftware.rs/Bootstrap and just write the HTML, the code will teach you by itself, you learn as you go, and it is flexible because you have access to all native source-code involved, unlike Electron.
Re: Anyone working on updated Qt bindings?
Just for note, you can make desktop D applications in HTML/CSS3/scripting using https://github.com/midiway/sciter-dport
Re: wiki 'send confirmation e-mail is broken'
On Friday, 13 November 2015 at 00:26:04 UTC, Vladimir Panteleev wrote: On Thursday, 12 November 2015 at 23:04:11 UTC, Ramon wrote: I registered in the wiki http://wiki.dlang.org/The_D_Programming_Language, but I never receive the confirmation e-mail, so I can't contribute.. maybe someone can manually activate my account: midiway The email server handling your email address domain seems to be actively rejecting connections from the wiki.dlang.org server. To resolve the issue, you will probably need to contact your email hosting service. Unfortunately, it doesn't seem like I can activate your account manually without editing the database, nor would it be a great idea because I would receive bounces for future failed emails. Please try another email address not associated with your hosting provider, such as Gmail or Mailinator. Using my @gmail.com address worked. Thks.
wiki 'send confirmation e-mail is broken'
I registered in the wiki http://wiki.dlang.org/The_D_Programming_Language, but I never receive the confirmation e-mail, so I can't contribute.. maybe someone can manually activate my account: midiway
Re: OctoDeskdex: D language program for your pleasure
On Saturday, 4 July 2015 at 15:00:08 UTC, Guy Gervais wrote: On Tuesday, 16 June 2015 at 00:47:59 UTC, Ramon wrote: If anyone is interested in this kind of GUI library, I can write more about how to use it It looks very interesting, but looking at the sources, it seems D is just being used as a container for an HTML/javascript application. Is there a way to use D for the internal logic too? For example, if I wanted to write a multi-platform game, but not do it in javascript how would I setup my screen (canvas?) and control what's shown from D? Yes, you can use D or C++ for the backend (internal logic), and there is an entire API for the backend->frontend conversastion. You can access and manipulate the DOM from the backend, as you can do it also through scripting (the language that Sciter technology supports is called TIScript, very similar to javascript). I recommend do to all the UI logic through scripting. You will need to use the native D/C++ side for the system stuff, like feeding the HTML/CSS/img resources, loading the HTML page, creating the HWND, ...
OctoDeskdex: D language program for your pleasure
Hi folks Just want to share some insights about what you can achieve with the D programming language and the Sciter library, which I use for making the GUI interface. I've written the OctoDeskdex app, which is basically the Github's Octodex page in a desktop version. Source is available at: https://github.com/midiway/OctoDeskdex It uses my https://github.com/midiway/sciter-dport library which let you Sciter technology http://www.terrainformatica.com/sciter/main.whtm in D language. If anyone is interested in this kind of GUI library, I can write more about how to use it regards
linking a .lib compiled with Digital Mars C compiler with DMD linker
Given a C source code that gives me a .lib static library compiled with the Digital Mars C compiler, can I link this .lib to my final .exe using DMD linker? that is, is Digital Mars C .lib compatible with DMD linker?
D embeddable on-line compiler
In the http://dlang.org/ start page, there is a textarea with D code and options to compile/edit/rude the code. I want to have one of this in my website. So is there an online service with an API to embbed a D syntax editor/compiler in my site? (aka iframe)
Re: Move VisualD to github/d-programming-language ?
Compliments to Russel Winder for simply discussing the matter and staying professional at all times rather than to play group and social games. Special thanks to Walter Bright for at least indirectly admitting that he didn't care for what I said simply because he judged me to be a troll right away. As it is senseless anyway for me to discuss here, no matter how polite or well intended, I will accept the unwritten local rules and stay away from this forum and limit myself to the D.learn forum and some others for those cases where I have to contribute some bits. Thanks in that context also to dicebot who hinted me early on that one needs to stay low here for quite some time until one has earned by merits, usually in the form of code, to have an opinion without being considered a troll. And generally thanks to all here; I have learned more about D here than I had expected. Thanks -R
Re: Move VisualD to github/d-programming-language ?
Wow. So many people turning so many circles around so little as "ze" instead of "ws". What's your objective in all this? To make me nicely say "Windows" as desired by you? A storm in the tea pot for 2 letters? If that is "grown up" I'd prefer to be an "immature brat". Is it enough, now? Can we finally return to technical issues? Or are some more "grown up" circles needed? (Note: This is not in response to dicebot specifially) @dicebot I'm generous enough to not feel insulted by your repeated "troll" accusations. Sure enough this is just another symbol of being grown up ;)
Re: Move VisualD to github/d-programming-language ?
Sorry, Joseph Rushton Wakeling but this is getting silly. You see, I try to be polite and to value anyones work. I will gladly value your (or Nicks, or ...) views on programming, no matter whether I agree with them, I respect your work and will gladly take your advise on D related matters. But not you nor anyone else here will educate me on manners or alike. You will not force your private feelings on how one should speak upon me. Period. You or Nick or Carl or whoever finds it insulting when I say Windoze because I write it in a way you don't like? Sorry, that's ridiculous. Similarly I write Visual$ - the $ meaning "fill in as appropriate" - rather than VisualStudio, VisualExpress, VisualBasic, VisualNet, VisualWhoKnowsWhat? Ridiculous! Should I now make some noise, too and complain about imaginary insults because you evidently assume that eveyone must know the correct product name of some Visual$ even when he doesn't use Windoze? This is getting silly. Let us stop that construed out of thin air "problem" ping pong and *really* behave like grown ups that is, return to technical issues. A+ -R
Re: Move VisualD to github/d-programming-language ?
On Monday, 9 September 2013 at 09:13:16 UTC, Joseph Rushton Wakeling wrote: On 09/09/13 09:31, Ramon wrote: (Note to myself: In order to get grown-up I should learn to insult those whose linguistic habits differ from mine) No, but it may help to learn to distinguish between someone saying "You're making yourself look like an immature brat," and someone saying you _are_ one. Well, to me someone who talks in a negative way about another user (or "smartly" works out subtle differences in such remarks) rather than about D related issues looks like an idiot. Isn't it beautiful to experience variety of perception? I sincerely hope it's not too immature brat looking to suggest that we focus on D related issues again. Thank you so much -R
Re: Move VisualD to github/d-programming-language ?
On Monday, 9 September 2013 at 08:29:44 UTC, Russel Winder wrote: ... If Windows and (C or C++ or C# or F# or Python) then VisualStudio. If Windows and Java then (Eclipse of IntelliJ IDEA) I understand the point about Visual$. While I myself hardly know it, very many (quite possibly the majority) of programmers on Windoze use it and seem to be quite happy with it. That's reason enough for me to accept it. This, however, is (to me) the really interesting point So if D is to compete with C++ on Windows, a D plugin for Visual Studio has to be in place and enjoyably usable. Is it? Why compete? The only way to attracts large numbers of C++ developers is to become more and more like C++ (incl. of course, massive amounts of libraries and tools) and to end up as some kind of C+++. Python is similar to - nothing (commonly used) - and yet it grew wildly. There are so many to complain about Python's weird indentation syntax. And yet they come and use it. Because it promises something tangible and it delivers. Because there is "the Python way". Because there excellent docs. And because there is no real competitor. Had van Rossum tried to please the perl crowd, he might have attracted some more and quicker but today Python would be a small niche thingy nobody'd care much about. I feel we should largely ignore C++. I feel that D is grossly inconsequent in a) - very smartly - aiming to be what C++ wanted to be and b) - not at all smartly - trying to please the C++ crowd and to mimick C++ up to the point of at least seriously considering mimicking leper and plague of C++, too. D already *is* what C++ wanted to be, namely a more modern C with OO. D shouldn't measure itself against C++ but rather against what C++ wanted to be. And there is another immensely important factor: reliability and safety. This world gets ever more dependent on software - and software is ever more recognized as unreliable and insecure; hell, there is even an industry living from that (anti virus, anti-malware, etc, etc). THAT's the sweet spot. To be what C++ wanted to be - plus - a strong focus on reliability and safety. The Ada people are not stupid. There is a good reason for them to ponder a year or longer over a new keyword. Bertrand Meyer may have it implemented in a way that looks strange to many but that man isn't stupid at all. The lesson to learn from those two languages known for reliability? Have a tight definition and think long and hard before you make the slightest changes. And *always* keep your "guiding principles" in mind. A+ -R
Re: Move VisualD to github/d-programming-language ?
On Monday, 9 September 2013 at 07:21:17 UTC, Jacob Carlborg wrote: On 2013-09-08 23:47, Nick Sabalausky wrote: Let's stick to grown-up words here. I'm not a fan of MS or Win either, but every time you write "Windoze" or spell something with $ it does nothing to hurt MS/Win and only makes you and other Posix users look like immature brats. Why do you put him together with the rest of us Posix users, seems a bit unfair. Don't worry, I'm pretty certain he meant only immature-brats like myself and not cultivated grown up persons like you. (Note to myself: In order to get grown-up I should learn to insult those whose linguistic habits differ from mine) Have a beautiful day, everyone :-)
Re: new DIP47: Outlining member functions of aggregates
Correction (3rd paragraph) My personal view is that we should *not* make D a mixed pickles with lots of "but C++ has that" and then some more gadgets thrown in for good measure. Sorry -R
Re: new DIP47: Outlining member functions of aggregates
Manu has pointed to some issue behind the obvious issue that will come up again and again unless it's settled once and for all. Let's call it "To please everyone somewhat (and never really enough) - vs - to stick to a clear and well founded concept". My personal view is that we should make D a mixed pickles with lots of "but C++ has that" and then some more gadgets thrown in for good measure. The point that triggered me was "quick and dirty throw away code". Frankly, I don't care batshit about that. Don't get me wrong, Manus desire is doubtlessly valid and I wish him the best of luck to achieve maximum happyness. But I also see that comfort for "throw away code" has a strong tendency to run counter reliability. There's a gazillion C++ compilers, pretty printers, analysers and other tools out there. And C++ has proven to be useful as a throw away code language - just look at mountains of throw away code out there (they won't call it that, of course). And there is C#, $Basic, Perl (a perfect language to create trobletickets - or to not even care to), etc, etc. The issue is not to please crowd A or crowd B. The issue is to make up ones mind and to establish a clear definition of what D is meant to be - and than to bloody stick to it. D had "reliability" and "safety" written in quite big letters in it's PR. It's a *major* reason for (sure enough not only) me to be here. Comfort and some luxury is important, too, when you make your living using a tool, sure. But that's no contradiction. One can have both. If I wanted to play a mixture of hide and seek and lottery I'd use C++ in the first place (and would have tools thrown at me). In case I missed it, could someone kindly point me to a more or less binding priorities list of what D is meant to be and in what order of priorities. Maybe it's my fault and I just didn't see that list. But in case #1 on the list was "to please everyone and then glue some more gadgets to it" I wouldn't be here. Thanks -R
Re: Move VisualD to github/d-programming-language ?
On Sunday, 8 September 2013 at 21:47:59 UTC, Andrej Mitrovic wrote: On 9/8/13, Ramon wrote: Fox and fltk are nice little thingies but not up to (todays) par lacking even functionality like printing. Printing seems like something that should be in a separate library, and maybe the GUI library would provide a nice interface over its functionality. I've no idea, but are there no such cross-platform libraries around? For some reason, probably to follow the situation on Windoze, printing is considered to belong to or at least to be very tightly coupled with the GUI. Technically speaking MS has solved printing by drawing to a "special canvas", which is somewhat unfortunate but actually not that bad conceptionally. In part the problem is also to do with linux going another way that is smart, too, by somewhat decoupling printing and going for postcript. Unfortunately this approach is quite different from Windoze (which still happens to own around 95% of the desktops) and also shows troublesome in a world of GDI printers (for many of which drivers exist nowadays in linux, too). From developers point of view the Windows approach probably looks more natural and desirable; after all printing, at least often, *is* just drawing on another target (paper rather than screen) and, more importantly, postscript is more at the driver side than on the creation side. tl;dr printing should be part of or at least reachable through the gui system. On Sunday, 8 September 2013 at 21:47:59 UTC, Nick Sabalausky wrote: On Sun, 08 Sep 2013 23:00:17 +0200 "Ramon" wrote: Visual$$ on Windoze Let's stick to grown-up words here. I'm not a fan of MS or Win either, but every time you write "Windoze" or spell something with $ it does nothing to hurt MS/Win and only makes you and other Posix users look like immature brats. Let's stick to the freedom of expressing oneself any (polite) way one sees fit as long as it's easily understandable. For the uninitiated: '$' often indicates a placeholder in nixnux world. With a friendly smile - the brat. A+ -R
Re: Move VisualD to github/d-programming-language ?
On Sunday, 8 September 2013 at 21:08:59 UTC, Iain Buclaw wrote: ... Against because we need a solution for *all* major platforms (Lx32, Lx64, *BSD, apple, w32,w64) and I'm worried that this resolution here might lead to a "So, we *do* have an IDE. Case closed" attitude. Why not cross-platform instead of *just* the major platforms? :o) Because I have saved at least some crumbs of being realistic *g I'm btw. *not* against Visual$$ and I *do* know and respect that it has a lot of happy and productive followers. MS has definitely done something quite right there. My point isn't "Ignore Visual$$! Hehe" but rather "Please, make sure to have happy linux and BSD users, too!". On Sunday, 8 September 2013 at 21:21:37 UTC, Iain Buclaw wrote: On 8 September 2013 22:00, Ramon wrote: Just for the sake of completeness: mono is *detested* and considered even more inacceptable than java by many linux and (even more) *BSD users. Swings in roundabouts. Also depends what you mean by detest and inacceptable... I'm, afraid it has shown to be quite senseless to resolve such issues by analysing and discussing adjectives. From an ethical viewpoint, I think most of it is FUD that still lingers from back when there was confusion over what Microsoft was going to do C# (there was for a long time fear that it would drive all free C# implementations underground). But all that mist has been cleared for a while, and I don't believe this represents the overall view of users/developers - except for those who are still stuck in 2008 mindset. Then let me inform you from a practical viewpoint that I'm not stupid and ignorant enough to automatically refuse anything from MS just because it's from MS. I don't like them and I don't trust them a nanometer but I recognize (even publicly) and respect when they do something well - like Visual$$. I'm btw. also advising clients in ca. 85% of cases to forget about Linux on the desktop and to use Windoze. My reasons to "paranoically" avoid Windoze for *myself* are not political or religious but purely pragmatic. tl;dr One is grossly mistaken when seeing myself as linux-taliban like anti-MS. I've talked to Miguel in person and I have solid reasons to not consider or touch Mono. Kindly note that I'm not fudding or preaching against it - I simply state that I and many others will not, no matter matter what, touch it. Mono/C# as a language may be detested for technically sound reasons however... Indeed. And those reasons might sometimes even be related to Mono. A+ -R
Re: D Lang Socket Programming Example
On Sunday, 8 September 2013 at 10:42:22 UTC, Savsak wrote: ... In the example you give, but I receive this error during compilation. savsak:~ savsak$ dmd /Users/savsak/Desktop/test.d ld: library not found for -lphobos2 collect2: ld returned 1 exit status --- errorlevel 1 To help dicebot and others to help you it would be useful to copy the output of the following two commands: cat /etc/dmd.conf find /usr -name 'libphobos2*' (Please note the *single* ticks (rather than ") to not have your shell resolve it. Also note that probably /usr/lib would be more efficient as search path but using /usr can also catch exotic cases like /usr/share). If your installation is OK you will find the paths told by the find command to match those in /etc/dmd.conf. Here is an example of a working installation: $ find /usr -name 'libphobos2*' /usr/lib/x86_64-linux-gnu/libphobos2.so /usr/lib/x86_64-linux-gnu/libphobos2.a /usr/lib/i386-linux-gnu/libphobos2.so /usr/lib/i386-linux-gnu/libphobos2.a /usr/lib/i386-linux-gnu/libphobos2.so.0.2 --- $ cat /etc/dmd.conf // ... some comment lines .. [Environment] DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu -L-L/usr/lib/x86_64-linux-gnu -L--no-warn-search-mismatch -L--export-dynamic HtH -R
Re: Move VisualD to github/d-programming-language ?
Just for the sake of completeness: mono is *detested* and considered even more inacceptable than java by many linux and (even more) *BSD users. Actually I *did* try the eclipse D IDE thing ... and found it to match my (utterly negative) perception of java (which has pretty nothing to do with the D ide and pretty everything with eclipse). Concerning Mono-D I heard about it and respect the efforts of the creator(s) ... but never even looked at it (and never will until hell freezes). I vaguely remember seeing colleagues work with Visual$$ on Windoze and they looked happy and productive to me. For a reason: Visual$$ seems to serve quite nicely the needs and expectations of those developing on Windoze. For fairness sake: It's next to impossible to do the same (as Visual$$) on linux/BSD due to complexity and a fractured eco system. Gnome and QT/kde basically are religious issues and no matter which one one chooses one will have a large audience refusing it. Besides both are monstrous (and more often than not meet resistance or at the very minimum reluctance on the Windoze side). Fox and fltk are nice little thingies but not up to (todays) par lacking even functionality like printing. And so on. That's quite regrettable, considering that we have a quite nice editor engine (Scintilla), quite good a debugger, and quite good compilers for pretty every language around. That said, maybe my first reaction was too harsh. After all, it's not D's job to solve the linux gui troubles. Having GDC with GDB working and some editors and even IDEs more or less working with D, I see that I should walk back a little and agree with the proposal (of this thread). A+ -R
Re: new DIP47: Outlining member functions of aggregates
On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright
wrote:
Outlining of member functions is the practice of placing the
declaration of a member function in the struct/class/union, and
placing the definition of it at global scope in the module or
even in another module.
http://wiki.dlang.org/DIP47
I'm against that.
Reasons:
- Do not change a language without very solid or even urgent need.
- A concise spec (we are going there that, right?) and
reliability is way more important than gadgets or "X has that. We
need that, too!".
- What for? This approach is anyway not the right one. If this is
about readability then ...
... what's the big issue? "I don't like 'class ...{' at the
beginning of my source code and a '}' at the end"?
Because that's what it comes down to.
If this is about readability as in "I want to have a quick and
comfortable look
at my module or class interface" (which is a reasonable desire
and a useful thing) then ...
... the solution is not to change the language but to have a
compiler switch to have the compiler generate a client/interface
view file. (One might discuss what exactly should should go there)
A+ -R
Re: Move VisualD to github/d-programming-language ?
On Saturday, 7 September 2013 at 20:02:37 UTC, Paulo Pinto wrote: Am 07.09.2013 21:55, schrieb Peter Alexander: On Saturday, 7 September 2013 at 19:39:21 UTC, Russel Winder wrote: Sadly, Visual Studio is a huge player in the game. Make the connection :-) Why sadly? It's a fantastic product. The only thing I don't like is the reliance on Visual Assist and ReSharper for refactoring features that other IDEs offer out of the box. -- Paulo I'm both pro and against it. Pro because VisualD seems to be (Pardon me, I don't work on Windoze and didn't work with it but trust Windoze D users opinion on that) an excellent solution and supporting nicely what seems to be *the* IDE in Windoze world. Against because we need a solution for *all* major platforms (Lx32, Lx64, *BSD, apple, w32,w64) and I'm worried that this resolution here might lead to a "So, we *do* have an IDE. Case closed" attitude. Kudos anyway to Rainer though for his important work. A+ -R
Re: Add support implicit conversion between types
I understand and support Kenjis request (linked in this thread) in the "no casting, though" version. And I find "C++ or C# or Foo2k has this!" a very troublesome approach and measure. Whatever feature is introducing inconsistencies is almost never worth it. We do have explicit conversion. If anyone feels that to look ugly he should ask what's worse, language inconsistencies or looks. A+ -R
Re: D Lang Socket Programming Example
On Friday, 6 September 2013 at 21:50:11 UTC, Brian Schott wrote: server.bind(new InternetAddress(8080)); Not quite the same - the original used a Unix domain socket. I *think* if you replace that line with a UnixAddress: http://dlang.org/phobos/std_socket.html#UnixAddress http://d.puremagic.com/issues/show_bug.cgi?id=9384 It won't work. (This is why my project uses IP sockets for local communication, even on Linux) Meaning that domain/Unix sockets aren't available at all in D (or need to be done through C calls directly)?
Re: Had another 48hr game jam this weekend...
On Wednesday, 4 September 2013 at 20:51:03 UTC, Joseph Rushton Wakeling wrote: On Tuesday, 3 September 2013 at 21:26:46 UTC, Ramon wrote: Now, if you will excuse me, I'll hurry to debian unstable *g Latest GDC release is also in the soon-to-be released Ubuntu 13.10, if that's useful to you. And check D.Announce for the latest info on D packages in Arch Linux. I can't remember if you've tried to build from source, but for what it's worth that's now a fairly straightforward, albeit time-consuming, process. So don't be afraid to do that in order to have the latest release. I can help guide you through it if you like. Thank you, J R, for the info and your friendly offer to help. But I'm already fine and settled thanks to some hints in the GDC forum and in particular thanks to hints and help from Iain Buclaw (whose help and work can't be praised enough). In case someone else runs into similar problems: debian unstable (or unstable based derivates) offer GDC-4.8 apt-getable .deb (and phobos) which works well right out of the box. Thanks and A+ -R
Re: Had another 48hr game jam this weekend...
On Tuesday, 3 September 2013 at 21:21:51 UTC, Iain Buclaw wrote: On 3 September 2013 21:30, Ramon wrote: Someone wrote sth along the line of "How egotistical! Some want this and want that. D doesn't get better or more popular by wanting ever more things". I'll very soon begin to work on a project. Originally it was planned to it in Ada. Relevant feature sets are roughly equal with D offering a little more (like comfortable unittests) and Ada being well proven. I *want* to go D. And I would, of course, gladly tell everyone who doesn't run away fast enough that our application is developed in D.(The application will quite probably have a good, even international visibility but by no means be major or widely known. The major (and very well useable, not "crippled") part of it will be free, btw.) In other words: One can contribute also by using (and talking about) D - not only by defending it teeth and claws or by writing code for or around D itself. Here is my current resumee: - dmd not debuggable -> not an acceptable solution, no matter how fast it compiles. - gdc possibly still buggy (Disclaimer: Probably it was just bad luck that I fell over a bug (not even an important one) and am a little wary now - No offense intended. I'm immensely grateful that with gdc there is an alternative and, even better, GDB *works* with gdc - hurray!!) The current development of gdc passes 100% unittests and testsuite, so that gives me confidence to say that codegen bugs are very unlikely to be found in gdc. - gdc (2): I have to either use an old version (4.63) or build it myself along with gcc, which is a major hurdle That is an old version. As I dropped gcc-4.6 support in mainline development back in April 2012. - Can I trust the GDC guys, are they professionals? My impression so far: Yes. That's important to me because GDC clearly is the compiler I'd go with. You can trust me. :o) - Will they provide at least GDC 4-7 binaries (they did for GDC 4-6 (debian)) - dunno. Would be a very big Plus. gdc-4.7 was skipped because of lack of time I could dedicate. This time around have collaborated with doko (gcc maintainer for debian/ubuntu) and gdc 4.8 is available in debian unstable. It is recent enough using 2.062 front-end. In summary, my resumee is quite positive (if with quite some bumps) but *THE* go or break issue is debugging with dmd and GDC being reliable. For the former I don't hold my breath, for the latter I'm quite positively looking ahead. Find a bug in gdc -> report it. Otherwise saying it is unreliable with no basis is pretty useless to me (I use it day in day out without problems). Iain, you made my day. Thanks so much! I'm really, seriously. honestly grateful for what you did/are doing. In my case you are the one who put the D issue from "rather not *sigh" to "go ahead" ;) Now, if you will excuse me, I'll hurry to debian unstable *g A+ -R
Re: [OT]: Memory & Performance
On Tuesday, 3 September 2013 at 21:10:17 UTC, Chris wrote: As regards the SSD, it's still a lot of money. Are those hybrids any good? Performance wise? E.g.: Theoretically yes. Practically probably not that much for most typical workloads. Looking at your scenario: The best performance/price ratio for you is quite doubtlessly RAM. 8 GB should do fine. With some VMs and lots of browsing and possibly movie transcoding you might want to even consider 16GB.
Re: [OT]: Memory & Performance
On Tuesday, 3 September 2013 at 16:15:51 UTC, Chris wrote: If you had the choice between: - 4 GB DDR3 SDRAM at 1600MHz - 1 X 4 GB - 8 GB Dual Channel DDR3 SDRAM at 1600MHz - 2 X 4GB ( + $49.00 ) Is it worth the extra money or is the increase in performance not worth mentioning? Any experience with that. The processor 4th Generation Intel® Core™ i7-4700MQ Processor ( 2.4 GHz 6MB L3 Cache - 4 Cores plus Hyperthreading ) Thanks. That very much depends on your usage scenario. My rather old (T500, 2*2,8 GHz, 4GB, normal hard disk) notebook still feels perfectly fine even for the occasional movie. For Windoze I don't know but for linux and FreeBSD a 4GB dual core system is absolutely OK and that includes software development even with IDE unless you use Eclipse. Unless you want to compile linux or gcc or the like frequently a Core7 is actually overkill/luxury. Generally speaking though, you might want to always have 2 (equal size) RAMs rather than 1. As for SSDs, I have one on my main system and it's nice but frankly, with linux buffering and enough RAM the difference usually isn't that noticeable. A+ -R
Re: Had another 48hr game jam this weekend...
Someone wrote sth along the line of "How egotistical! Some want this and want that. D doesn't get better or more popular by wanting ever more things". I'll very soon begin to work on a project. Originally it was planned to it in Ada. Relevant feature sets are roughly equal with D offering a little more (like comfortable unittests) and Ada being well proven. I *want* to go D. And I would, of course, gladly tell everyone who doesn't run away fast enough that our application is developed in D.(The application will quite probably have a good, even international visibility but by no means be major or widely known. The major (and very well useable, not "crippled") part of it will be free, btw.) In other words: One can contribute also by using (and talking about) D - not only by defending it teeth and claws or by writing code for or around D itself. Here is my current resumee: - dmd not debuggable -> not an acceptable solution, no matter how fast it compiles. - gdc possibly still buggy (Disclaimer: Probably it was just bad luck that I fell over a bug (not even an important one) and am a little wary now - No offense intended. I'm immensely grateful that with gdc there is an alternative and, even better, GDB *works* with gdc - hurray!!) - gdc (2): I have to either use an old version (4.63) or build it myself along with gcc, which is a major hurdle -ldc not yet tried. Dunno. - Windoze stuff not yet tried. But the mere thought that D might force me to use Windoze puts dark shadows over D, sorry. - IDEs: Some existing. Using geany with good support for D is perfectably acceptable (Me not liking fat IDEs anyway). It comes down to a very acceptable editor with some gadgets (like class viewer) with a small engine driving builds and a debugger interface (or do I mix that up with Code:Blocks?)) Summary: Good starting grounds. Perfection and dreamland can be reached later. - libraries: Looks between regrettable (lots of old/broken/pre alpha stuff) and uncomfortable (equals increased development cost/time). Major problem: No readily available mechanism (I know of and would trust/use) to 2/4 automate C lib binding. The situation being that I must, and pretty soon, make a decision, it - for me - comes down to: - dmd would be used for coverage and doc and possibly profiling but not for compilation. - Can I trust the GDC guys, are they professionals? My impression so far: Yes. That's important to me because GDC clearly is the compiler I'd go with. - Will they provide at least GDC 4-7 binaries (they did for GDC 4-6 (debian)) - dunno. Would be a very big Plus. - IDE *is* a major issue for general language uptake. For myself though I'd have a quite acceptable base. Worst case: Fumble and finetune in Scite engine for D. No sweat. As for libs and stuff D looks lousy and unorganized. For me that's not a problem, I'll bite and find my way through. For general language uptake and acceptance though that's about as attractive as the more remote corner of a used car shop. Red line: When in a project I have to "fight" the project - not the tools; those must simply work reliably. The community seems quite OK. Very little flames and hate, quite professional with a tendency to be friendly; they strongly seem to prefer to discuss and elaborate minute details, work-arounds and hacks, and seems to react rather pissed to any critical remark on D, but I feel that there would basically always an answer if one had a question. Andrei (sorry, the core people *are* important because they shape language and community) is a matter for itself and W. Bright would rather discuss the availability of TV programs than to answer, even when addressed directly, if he doesn't like someone or consider him unworthy because being newb or whatever. The layer around them though seems more open and accessible. Good enough, no, actually even quite good. In summary, my resumee is quite positive (if with quite some bumps) but *THE* go or break issue is debugging with dmd and GDC being reliable. For the former I don't hold my breath, for the latter I'm quite positively looking ahead. Now destroy me. A+ -R
Re: Had another 48hr game jam this weekend...
On Monday, 2 September 2013 at 21:04:24 UTC, Walter Bright wrote: On 9/2/2013 1:36 PM, H. S. Teoh wrote: It's things like this "keyhole interface", that caused me to be convinced that the GUI emperor has no clothes, and to turn to CLI-only development. One of the giant failures of the GUI interface, and that VS suffers from, too, is when you need to do repetitive operations. On the CLI, I constantly use the history list, and I constantly write throwaway scripts to automate what I'm doing at the moment. It makes everything I do, no matter how obscure, only 2 or 3 keypresses. With VS, or any GUI, if there's not a button to do it, I'm reduced to: move mouse click move mouse click move mouse type move mouse click type to get something done. And if I want to do it again, I have to repeat that process. After the 10th time, it's gahhh I hate it and go back to the CLI. I scan a lot of photos. I have a GUI photo editor. A common thing I do is straighten the photos, because they never go through the scanner straight. So it's: right shift click on the picture select open with select photoeditor select edit select rotate select autorotate select apply select save select exit Sounds easy, right? It is easy. Now do it to 1000 photos. With a command line tool: write a script that does it to one picture, name it cc.bat do: dir/b *.jpg >doit.bat open the file and use the macro feature to prepend "cc " to each file name, maybe 10 keystrokes execute the script Done! And CLI Clint goes and surfs the n.g. while GUI Gus has just gotten to picture 4, only 996 more to go! I'm not that big fan of "full" Guis either and try to stick to slick ones. But for fairness sake: Better Gui Programms (read: way too few) have Macro facilities. (My major reason to go GUI for programming is the auto* /configure/m4/makefile mess. Having that handled by some build in magic is cool. Which, if I'm not mistaken is less of an issue with D (dub, etc?)) A+ -R
Re: Had another 48hr game jam this weekend...
I think dicebot has hit a point there. It's true, much if not most of OS software is a (hopefully) somewhat niced up version of what was written to scratch a personal itch. But I'm quite confident that this is not true for a project like D. I mean, just to come up with a solid and well thought description of the itch (like "C++ is a mess and a PITA") that can serve as guiding line when conceiving a language is a major undertaking. One possibly may come up with some script thingy just to scratch an itch; to conceive, design and implement something like D, however, was and is a very major undertaking, 1000s and 1000s of hours, aso. Wouldn't one like then that others see, too, what one has understood 10 years ago and tried to make better? Wouldn't one then want to make it really easy to test drive the language, see it's power (on cpus rather than web sites)? My driver for complaining about D is *that it's so great* - but quite low on the useability side. If D weren't that great I'd simply have turned away. I get Walter Brights point that he can't (and doesn't want to) be in charge of everything and the kitchen sink. The debugger issue though *does* concern dmd itself and not having a realiably working debugger with full (usual) functionality *is* a major show-stopper. I mean, come on, how reasonable and consistent is it to leave the C/C++ mess and to then spread debug writelns all over the place?! For the rest, I agree, it might be hard to see for emacs/vim crowd and the like. Yes, they are right, there is life without nice colors and mousing around development. Let us not forget: To be somehow useable for insiders is only a first step. To really gain traction a second step must be taken: To be reasonably well useable according to what is common today. Which, I think, translates at least to: vim or emacs modes plus some decent cross platform editor like Scite and a"thin IDE" like geany. From there on it's a matter of taste and religion and - that's an important point! - having a comfortable base useability through the chain we can afford to say "You want X? Go and code it. The tools needed are there.". A+ -R
Re: Had another 48hr game jam this weekend...
On Monday, 2 September 2013 at 13:46:33 UTC, Manu wrote: On 2 September 2013 21:37, Jos van Uden wrote: On 1-9-2013 20:00, bearophile wrote: Manu: Seriously, how do you quickly read and understand the API through the noise? The noise increases if you have to repeat the class name for each method :-) +1 Really? You both think seeing the function signature a second time at the definition is 'noisy' when compared to massive blocks of arbitrarily indented function body code consuming the entire class definition, and completely breaking up your code window? A few function bodies and you can't see anything anymore. You have to scroll miles to get an overview of the class, and try and remember each function header along the way as you scroll by; you can never digest it cleanly in one place. My memory's not that good... So you end up scrolling up and down and up and down and up and down, and then inevitably, get off your arse, walk over, and interrupt the guy that wrote it. That's a waste of my time, it's a waste of their time, and in an office environment, it's a waste of money. So, I find it extremely useful being able to see the members and functions available listed in a row all together. I can quickly gather a fairly complete mental picture. Everyone on the weekend agreed with me, none of us could immediately understand the classes we were working with. Productivity being the key element in our exercise, and it demonstrably impacted our productivity. But whatever. I just threw it in there because it was a recurring topic, and I thought it was worth mentioning. I think there is a way to please both sides. I Eiffel there is a (standard) way to show only the definition and/or the interface of a class. It shouldn't be much of a work to have the D compiler (or some utility, but that'd be considerably more work) spit out those, too. While I don't agree with Manu's wish to handle D classes C++ style I do quite well see the value of a clean definition skeletton/API/interface overview. A+ -R
Re: obsolete D libraries/modules
I see strong points on both sides. Maybe it would be a good thing
to really have two versions with the second one ("getOpts")
getting the options in arrays (as introduced above). Like that
the "simple" version we have now could, besides some minor
corrections, stay like it is and not disturb existing programs
using it. The second version would be the "bigger" one with help,
valid ranges, eval funcs, and other goodies as identified by a
crowd discussed wish list (and "auto help print" controlled e.g.
by a flag).
A+ -R
Re: End user experience with D
On Monday, 2 September 2013 at 04:00:37 UTC, Peter Williams wrote: IMHO, the IDE should only be a wrapper around the core functionality and never be so closely integrated that the core is unusable without the IDE. Personally, I just like using a configurable editor (e.g. Geany, emacs and so on) which knows (or can be taught) how to do various useful things that an IDE might offer. If you want an IDE then create one but make it an "add on" and don't expect everyone to use it. Cheers Peter PS I especially hate IDEs that try to force me to create "projects". PPS I especially like IDEs that have built in terminal editors so that you can do command line stuff without the need for a separate window. I perfectly agree. An IDE should be optional - but it should exist. And btw: With IDE I don't necessarily mean a fully blown Eclipse like thing. A smart developer oriented editor (like Geany) with a reasonable interface to a *working* debugger is good enough.
Re: Had another 48hr game jam this weekend...
Sorry, if I sound somewhat p*ssed but that's what I just am after wasting half a day with weird catch-me with D. Following a friendly advice given to me today I compiled (DMD on linux) with the -gc switch (rather than simply -g) and ... debugging is still useless. GDB doesn't grok it. Being somewhat desperate but still good-willing (or stubborn?) I want to try GDC. After all the gnu backend is supposed to properly feed the gnu debugger, right. This must be A JOKE! I have to clone from github (which I don't like but OK ...) then I have to f*cking compile gcc After that I will be allowed to compile GDC. Great. How about compiling a whole bloody OS before finally having a D compiler that kind of works? And, of course (if the GDC wiki doesn't lie) it'll be version 2.062 which probably opens another can of problems ... But again, I'm good-willing and so I do what I really, really HATE. But for D I do it: I install a windoze VM and install the Windoze version. Following the instructions I learn, I'll have to download 2 Visual Blah related thingies. Of course I'll have to register first with Microsoft. Excuse me, but when some Gambas or FreePascal hobby guys can do *considerably better* (and accordingly have quite many loyal and happily coding followers), shouldn't it strike us boldly that something is going terribly wrong on the practical and useability side of D?!
Re: Had another 48hr game jam this weekend...
=== INTERRUPT Can we, please, just for a moment leave details aside? Dear Walter Bright There are currently 3 threads addressing more or less the same issue: user experience. You have, no doubt, created a wonderful, great and promising language. That's why we're here. Yet we have heard from users who left. Not because D isn't good enough - actually it's so good that some at stay loosely connected and read and write here - but because in order to be useful and to grow and spread all over the universe, the power, the beauty and the elegance of a language must be found in practically interaction, too. In other words: user experience. It seems in that context there are mainly 3 points coming up: - IDE - Docs - Debugging And I'd like to add a 4th: C library bindings. Obviously neither you nor any 3 or 5 of us can possibly make *every*one happy. Equally obviously, making too many not happy leads to potential D users leaving the language. Shouldn't we find some reasonable common grounds? Shouldn't we at least discuss and create a rough ToDo route with some priorities? There are, for instance, tools out there that allow to create various common formats for documentation, incl. HTML and .chm. Shouldn't we make an effort to identify and agree (or, if necessary, a dictum by you and/or Andrei) on some cross platform tool for documentation so as to be able to create all needed formats from one set of docs? Thanks for D and - please - let us do the next step now. Let us not debate over Eclipse vs. Vim but agree that at least 1 cross platform IDE must be supported along with at least 1 cross platform Editor. Let us not only address language issues and problems with a narrow view but let us at the same time keep our mind open for the larger picture. And let us agree that a not yet perfect language along with well useable and realiably working tools is worth at least as much as an ever more refined language with lousy, alpha, broken old, or simply not reasonably useable tools. The same goes for the tools. Let us have 1 set of cross platform tools, even primitive ones but realiable and reliably working ones rather than striving to have a variety tools for each and every OS and whim addressing every minute detail coming up. Let's build a base - and then conquer the world.
Re: End user experience with D
On Sunday, 1 September 2013 at 23:22:30 UTC, Adam D. Ruppe wrote: On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote: Finally and possibly most importantly, basically not having fully working debugger support is a very serious lack. Maybe it is because I write 100% bug free code the first time every time ( :-) ) but I've found the gdb support, at least on Linux, to be really pretty good. I compile with -gc -debug - the "pretend to be C" option is something I started doing years ago and might not be necessary anymore, but I've found it to be plenty good enough anyway. D's bias toward Windows doesn't help either. If anything, I don't think D goes far enough in its Windows support. It works well there, sure, even the optlink things others complain about don't bother me, but there's a lot of stuff it could easily do and doesn't, at least not without grabbing additional downloads. On Linux, dmd works quite excellently, as do gdc and ldc. -gc? Hmmm ... I'll try that. Thanks for the tip ;) For the rest: Frankly, I'm not even sure, I should follow that kind of discussion (like in Manu's thread) anymore. I don't mean to offend someone but it strikes me as ... uhm ... brains not used at their full power ... when "there is no really properly and fully working IDE" (which is pretty close to a killer for many) gt thrown in - and seriously - discussed with stuff like "nenene, in Windows Visual Blah 2010 it worked and now Intellisense works only with handish settings, nenene". Even worse, while I'm still hoping for a promising statement by a heavy-weight like e.g. W. Bright along the line "Yep, we really, seriously need some working cross platform IDE, preferably an easy to install one" ... one seems quite happy to seriously adress nitty-bitties for Windows Whatever 2012 (c) (tm) $$$. Maybe perfection must be three, the catholic way, a triplet. Maybe we need another incarnation of Andrei A. (who brought great stuff to D) but this third guy bringing good useabilty to D.
Re: End user experience with D
On Sunday, 1 September 2013 at 22:27:43 UTC, Brian Schott wrote: On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote: D's bias toward Windows doesn't help either. Did you mean against? I've found D to be much nicer on Linux. Well, I can't comment on Windoze as I avoid it like the plague. But I'm under the impression (basically from reading here in the forum and looking at D related tools, IDEs, etc) that there is a certain bias toward Windows. Which would be OK as most users (?) seem to work on Windoze *if* D marketed itself as a language for Windows. As for linux, yes, you are right. I didn't experience any problems with DMD itself. Installed like a charm, worked like a charm. But: I remember my first days and the conditio sine qua non that there are tools for linux, too. Well, there seems to ... yet, I'm still unable to reasonably debug. which, from what I saw/read seems to be a problem on the D side. A+ -R
Re: Had another 48hr game jam this weekend...
Manu
(answering the OP)
Stupid me, I just adressed similar issues in
http://forum.dlang.org/thread/jlssvljpdgxlubdaj...@forum.dlang.org
("End user experience with D") because first I thought this here
was about game development (which I don't care about).
Short version: I agree with Manu. Completely. Strongly.
One warning tough: We should differentiate between "essential"
and "nice but not urgent". For a simple reason: Feasibility.
Sure, .chm help would be nice for Windows users but frankly, good
doc at all are more important; if it's, say, HTML that's good
enough for a start.
As for an IDE we should definitely favour something cross
platform (and non-java!!!) rather than caring about peculiarities
of Windows, OSX, lx/kde, etc. Those can be done later. Really
important is to have a base asap.
The killer: Debugging.
GDB is bare minimum and seeing adresses of structures rather than
the members and their values is basically worthless.
When trying a new language I usually do a small project:
"osnsort", i.e. a utility that takes (usually via a pipe from 'du
-h') lines with OS style numbers (like "4,3M" for 4,4MB filesize)
and then sorts those lie properly (unlike sort which lousily
fails).
While D nicely showed some of its strengths and the coding was
really enjoyable and the docs good enough for someone with a C
background) I soon found myself inserting lots of "debug"
statements as a "more elegant" version of the old "#ifdef DEBUG
printf(...) #endif". *** YUCK!!! ***
Putting it bluntly: D is so great, so powerful, so nice language
that it's worth a lot of efforts. With any other language I would
have turned away and taken it to be a hobby thingy.
So, we must not please everyone and take care of their OS issues
right now, but we definitely need some kind of, if somewhat
crude, working base in terms of debugger support, IDE and docs.
A+ -R
Re: End user experience with D
Ludovit Lucenic For the IDE and GDB issues I fully agree. And I'add less than comfortable (~"semi automatic"; from what I know) C library bindings. While one may discuss about IDE or cli, I feel that an IDE is at least an immensely helpful starting point. I agree that one should be able to do programming with no more than a simple editor, a compiler/linker, and a debugger (!). Newcomers, however, (and even many seasoned programmers) handily profit from an IDE (and I don't mean Eclipse which I count as a moloch that, to make things worse, is based on java). I also feel that any modern language just *must* have a comfortable way to use C libraries. Finally and possibly most importantly, basically not having fully working debugger support is a very serious lack. I may be wrong (actually I hope to be wrong) but from what I know, this issue doesn't seem to be seen as having very high priority. I'm more and more getting the impression that D could be a programmers dreams come true if only it were practically and productively useable. Sure, it's not D's fault. But in the end we need a fully working debugger, some good editor support (say, on a Scintilla/Scite level), preferably at least one cross platform non-java IDE (like Code:Blocks) and easy access to C libraries in order to actually and productively work with a language. D's bias toward Windows doesn't help either. Looking at it from a marketing perspective, i.e. looking for what potential users (read: "the large crowd out there") would look for, I see that the creators of D have done an excellent job that, however reminds of a Porsche engine on a makeshift chassis. Frankly, if we want D to attract developers and to get the position it undoubtedly deserves that will not be achieved so much by finetuning D or even phobos but by being able to offer a well-rounded and well useable package (and soon after good docs for what we have so far). A+ -R
Re: d from the outside
john james I'm afraid you hit a point there. Documentation is existing and being worked on but still leaves a lot to desire. But then, to be fair, one came come along quite well with D and what can't be found right away, can be asked here, particularly in the D.learn Forum. While I'm absolutely not sure that Go is a good language to learn for a programming newbie, I'm pretty sure that D isn't. Don't get me wrong, D is a great language (why else would I be here?), but in my minds eye (some will strongly oppose that view) it's not for newbies and possibly not even for seasoned programmers unless one has a certain combination of mindset, needs and capabilities. It might be helpful for you to ask some questions beyond the language itself. After all it's not about the language itself only but also about the environment, the available tools, etc. One example is comfort (as in "find one click installation sets for Win/Apple/Linux/*BSD/Solaris in the Download section"). Another (somewhat sad for D) example is your needs for a development environment. There seems to be a rule of thumb that says that major and well established languages offer complete, even luxurious, IDE support for all major OSs while less well established and mature languages might offer not much more than "Emacs is supported and there is some half cooked Eclipse and Code:Blocks support" which might be a prohibitively large hurdle for a beginner. Yet another issue is libraries. A newbie might be better served with, say, FreePascal or Python which both have a nice set of batteries included. If I were to put D into one single sentence (beware! I'm a D newbie myself) it would be "C/C++ done right and with a major focus on systems programming". For some people (like ourselves here) D's capabilities and potential are well worth to be patient, to contribute to it (and it's environment!) and D is or comes damn close to what we always wanted. One point that might make D somewhat less attractive for CS students is the fact (well, according to my impression) that one doesn't care that much about concepts around here but rather about performance and somehow hacking it to work. In any case it will be hard for you to decide - and for us to helpfully advise - without you considering/telling us somewhat more about your needs. On a somewhat private sidenote: I value Pike highly and I had a closer look at Go but don't consider it highly in any regard. Frankly, my impression was "lots of exitement and hype and some nice gadgets but rather insignificant (no matter how many fans it attracts). In case you decide to stay with D or to at least test it somewhat more extensively, you should definitely get the book "The D Programming Language" by Andrei Alexandrescu, one of the major D figures and a major contributor to D. Have a look at the wiki and at the D.learn forum!
Re: obsolete D libraries/modules
On Sunday, 1 September 2013 at 17:20:56 UTC, Jacob Carlborg wrote:
On 2013-09-01 16:28, Andrei Alexandrescu wrote:
string outputFile;
getopt(args, "output",
&outputFile).min(2).max(4).restrict("a", "b",
"c", "d");
What would this line do?
The "output" argument expects at least two values and at most
four. The values can be "a", "b", "c" or "d".
Conceptionally questionable. The job of an argument parser is to
parse arguments, to possibly do some comfort magic (like
generating arg help) and to return info about the arguments in a
sensible manner.
It is *not* to do things that are not general but rather the
programms job.
And it is based on well established standards like having args in
either short form '-' (or '/' on windoze) plus one letter or in
long form '--' plus optionname and letting options have optional
arguments as in '-o outfile'.
Unless we want to arbitrarily (and therefore often uselessly)
pick out one of the many multi option argument notations like "-x
a:b=3:c=8859-15" it is - and should be - the task of the programm.
phobos job shouldn't be to provide comfort and magic for any and
every no matter how abstruse situation but to offer concise,
clear, well defined and real world mechanisms.
Considering that a standard lib is rather close to (and by many
considered part of) the language, there are, as in language
design, many trade offs to be decided upon, generality and
reliability weighing in much higher than "it can do everything
including the kitchen sink and a colour picker".
Re: obsolete D libraries/modules
On Saturday, 31 August 2013 at 18:44:52 UTC, Brad Anderson wrote: On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote: On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote: Right now, having no way to actually update that site to add a notice to this effect On this point, when's the last time someone tried pinging him via email? Is the whois for the domain not current? -Wyatt His email is supposedly brad at dsource.org. I know people have had difficulty contacting him in the past but I've never tried myself. And just to clarify, I'm not the same Brad Anderson that runs DSource (which has caused some confusion in the past). I'm pretty sure neither of us talk in the third person. He, the dsource guy, is Brad AndersEn from Atlanta, GA, according to what little info is available. His whois email is at some company that seems to have gone away or changed name or ... dsource seems to be on a VPS at slicehost and, so it seems, just one in some more sites on that virtual host. It seems we shouldn't hold our breath to hear from Mr. Andersen, unless someone here knows him personally and is in contact with him. But then, most people looking for D arrive here at dlang anyway. I think, we should simply put some kind of marker here concering dsource being comatose. A+ -R
Re: obsolete D libraries/modules
On Friday, 30 August 2013 at 11:42:00 UTC, Jacob Carlborg wrote: - why tango? What's better there than in phobos? In my opinion: * Argument parsing * XML package * Net package (not any external dependencies) * Zip package * I think it has more collections * Logging - what's the offering? (Is it a complete replacement for phobos?) Yes, but you can use just what you want. As I said, I'm only using the argument parsing from Tango. Thanks for the information and your thoughts. I'd like to ask one more question on that, as I happened to work a little with phobos' getopt and looked at your code and happened to notice (your use of) tangos arg parsing/handling: Why do you consider tangos arg parsing being better? Could you kindly elaborate that somewhat? (Because I, possibly due to my newbness, failed to see striking advantages in tangos arg parsing when looking at Dstep). On Friday, 30 August 2013 at 11:43:15 UTC, Jacob Carlborg wrote: Oh, and BTW, if you want to code on DStep you need to learn libclang even more than you need to learn Tango. libclang is a very interesting matter, anyway, and indeed one of the more reasonable ways to attack the C->D problem. On a sidenote, I also keep a very interested eye on the D frontend for llvm. Please, be assured that I have no interest whatsoever to dig in old wounds or to talk against tango which sure enough is a major piece of work. Thanks & A+ -R
Re: obsolete D libraries/modules
On Friday, 30 August 2013 at 06:48:55 UTC, Jacob Carlborg wrote: On 2013-08-29 21:36, Ramon wrote: Being as was, hase come to be and is, some cleaning might be desirable. Frankly, the only reason I didn't just click away Dstep is because it's *so* bloody important. Otherwise seeing "tango" somewhere makes me click away. OTOH binding C libraries being so bloody vital for D I feel we should a) "port" Dstep to phobos and b) advertise prominently, happily and loudly. It's a shame that people here think of Tango like that. I'm sincerely asking: "What's so bad about it?". Especially when most people just see "Tango" and turns a way without knowing that it is. It's just another third party library. I understand your point and I understand that some reasonably (from their perspective) perceive a lack of fairness. My point of view, however, was that of a newbie. As such I won't make my learning curve steeper by learning two "standard libraries", which one to use when, etc. And, you see, it's not just the lib, it's also about documentation, compatibility, the eco system. It might be helpful if you (or some tango guy) would explain - why tango? What's better there than in phobos? - what's the offering? (Is it a complete replacement for phobos?) etc. A+ -R
Re: obsolete D libraries/modules
On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote: I wonder if we should post a notice on dlang.org to the effect that dsource.org is dead, and that people shouldn't rely on it. Right now, having no way to actually update that site to add a notice to this effect, the first thing people are going to do when they discover D is to hit the search engines and dsource.org is inevitably going to turn up. Then it's anyone's guess whether the net effect will be positive or negative -- I'm guessing negative, a bad first impression of D that it has lots of promising but dead projects. Yes. I, being a D newbie myself, can report that's exactly what happened. And it's particularly bad because, while a newb-newbie might happily hack along and learn D, a professional newbie has actual work to do. *of course* looking for what's available is one of the first things to do. This whole thing get's even more weight as D happend to be advertised like "use any C library to your liking". [...] But there is a (possibly very small) but, too: Tango. Maybe I'm simply mistaken but my impression so far is: There once were 2 rt libraries, phobos and tango and (for whatever reason, no judgement implied) phobos won and today with D2 it's D + phobos, period. [...] This is a dark part of D's history that people don't really like to talk ... Oh, I did b no means intend to dig in wounds. My point rather is: 2 "batteries included" libs is not a good thing but a bad thing because it confuses newbies. I go with phobos because it's the official thingy and because I don't see any major obstacles or bad issues. Being as was, hase come to be and is, some cleaning might be desirable. Frankly, the only reason I didn't just click away Dstep is because it's *so* bloody important. Otherwise seeing "tango" somewhere makes me click away. OTOH binding C libraries being so bloody vital for D I feel we should a) "port" Dstep to phobos and b) advertise prominently, happily and loudly. Being able to import C libs to D quite simply is vital, it's a go or break issue for many. And if Dstep is the reasonable and working way to get that done, we should put it on the front page. --- As for the modules, dsource etc., I very strongly feel that we should go the way of Python, span and others, i.e. we should build an official repository. A+ -R
Re: assert() vs. enforce(), invariant() vs. ... ?
Let me share some thoughts and inner warnings, here.
I notice a certain (constructive and pragmatic) tendency here to
say "Ha, that can be done" using templates, mixins, whatever.
I personally feel that to be somewhat dangerous and short term.
It's about concepts. Concepts and a smart and consistent
implementation is almost always preferable over a "can be done"
hack.
DbC is a concept and a powerful one - and the D creators have
wisely decided to implement it in D. Unfortunately they seem to
not have done it consistently (as some question and threads
indicate).
There *should* be a clear answer/rule/statement to "which one to
use? enforce? invariants? asserts?". And there *should* be a way
to let the programmer decide about his use of DbC (as opposed to
"release cuts all DbC").
I propose to end the "release cuts out DbC" approach and to
instead introduce sth. like "@DbC-on" and '@DbC-off'. This, hand
in hand with D's smart version mechanism offers much more without
losing anything.
The current way would be
version(release)
@DbC-off;
and being the default D would work as it did before. But we could
decide ourselves and we could have DbC available at runtime if we
please so. Using @DbC-on and @DbC-off we could even have good
granularity.
assert shouldn't be mixed up with DbC (as it often is right now).
In fact, I think, assert could/should have two major roles.
Ignoring DbC assert has a well established purpose and that's
what it has and does in D, too.
In relation/context to DbC there is no competition. DbC cares
about three scenarios, namely, method entry, method exit and
class level ("as long as you are not in a method X is guaranteed
to be ..."). assert is no competion but a complement as I see it,
in that it offers checks/guarantees for certain single situations
that are just not DbC jobs (example: make sure inside a method
something doesn't go amok).
Thanks for considering
A+ -R
Re: obsolete D libraries/modules
I'm still a newbie, which is not a pleasant but *can* be useful because, after all, D does not intend to be or stay a rarter closed insider group and a newbie might be better able to come up with certain, possibly stupid, issues. So kindly allow me to share some thoughts with you. I hear a lot about performance and sure enough that's important. Also very important, however, is the question of available libraries and of binding C libs. If there is (and possibly DStep is) an up-to-date (workig with D2, phobos) a solution LET US ADVERTISE THAT and make it easy to find, too! This is not some luxury like D being 7% faster than, say, Pascal. This is a go-or-break issue for many who have a first look at D. I took dsource to be of relevance and learned it's not. One reason for that was that I was, of course, looking for existing modules/libraries and it seems there is not yet an "official" list of repositories and modules. Let's change that. While I personally have not much of a problem with a funny assortment of cvs, svn, bzr, git and whatnot repositories spread all over the internet, some might consider that unattractive enough to stay away from D. Maybe we should create/have sth. like "the official D modules repository" where modules are sorted (gui, db, algo, etc. - and - D2, phobos, tango based, etc), where activity or last update or similar is shown, where some maturity indicator (like 1=concept ... 5=mature/production qual.) is shown. Thanks for considering and discussing A+ -R
Re: obsolete D libraries/modules
On Thursday, 29 August 2013 at 07:02:40 UTC, Jacob Carlborg wrote: Well, dsource.org is dead. The projects are basically there for reference only. Most project these days are at Github. I guess there isn't an obvious way to find all of them though. Thanks for that information an for - even better - pointing me to something alive. I'll come back on that later in a more general way. DStep is a a tool for automatically converting C headers to D modules: https://github.com/jacob-carlborg/dstep That's really great news, thank you! But there is a (possibly very small) but, too: Tango. Maybe I'm simply mistaken but my impression so far is: There once were 2 rt libraries, phobos and tango and (for whatever reason, no judgement implied) phobos won and today with D2 it's D + phobos, period. There's also a Github organization dedicated to C bindings, created by the D community and language authors: https://github.com/D-Programming-Deimos/ http://jkm.github.io/d-programming-language.org/deimos.html Thanks for that info.
Re: Why I chose D over Ada and Eiffel
On Thursday, 29 August 2013 at 14:50:18 UTC, Gour wrote: On Thu, 29 Aug 2013 16:13:06 +0200 "John Colvin" wrote: just something I whipped up in a few mins: [...] Thanks. So, it's possible, but (maybe) it's not as elegant. Now, let's be fair. While the point you brought up is one that I, too, do very much like with Ada, it's not magic what Ada does. Agreed, Ada has it wrapped in nice syntactic sugar, but in the end such a subtype is just the basic type with range checking done bhind the curtain, while D does it publicly visible and in the open (and, yes, less nicely sugared). In the end it's about the concept, so the relevant question is not "Does D offer the same sugar and wardrobe?" but "does D offer a way to implement that (important) concept other than (C-like) hand inserting range checking code everywhere". The answer is "yes, it does". A by far bigger concern in my minds eye is D's somewhat unlucky DbC mechanism or, more precisely, the somewhat step-son treating by disabling DbC in realease code. I strongly feel that something like "@DbC" (and @noDbC) would be far more satisfying. A+ - R
obsolete D libraries/modules
Apologies if this is the wrong forum or even the wrong place but it seems to me there is a kind of tight connection between dlang and dsource.org (to which the following relates). I can perfectly well understand that any group around a not yet globally known language with a not yet richly endowed assortment of libraries isn't eager to push the kill button on 3rd party/user created modules. And yes, it sure gives a new user a warm nice feeling to discover lots of available modules (which after all translates to a quick start and efficiency for many taskS). Let me, however, also share my experience and feelings as a (exited and pleased) newbie to D when one finds out that what seems to be easily 2/3rd of seemingly available modules are "dead, exitus, this bird is passed away, gone, dead, and only sitting there because someone drove a nail through the poor animal" or, at best optimistically pre-early-alpha (speaking with a friendly grin). Feels like a 16 ton weight coming down (if I may borrow again from Python, here). And there is another unpleasant side effect: It doesn't feel profoundly attractive to write something and put it in between all those dead parrots. I'd like to suggest therefore that we begin to mildly weed out dead or stuck-in-dream stage modules or at least discreetly mark them as RIP. In case someone is interested in what disappointed me most, it's hto2 and bcd-gen, bot of which address an important need and both of which don't look healthy and useful. This is particularly troublesome as "make C libs work in D" type tools are essential in any effort to bring D forward in the world out there. In case someone feels like hitting me: Hold it. This thread was written with good intention and the honest worry that a lack of libs and a lack of some support for bringing in C stuff might turn out to be regrettable bumps in the road. A+ -R
Re: Why I chose D over Ada and Eiffel
On Monday, 26 August 2013 at 08:01:51 UTC, deadalnix wrote: On Monday, 26 August 2013 at 07:32:53 UTC, Zach the Mystic wrote: On Sunday, 25 August 2013 at 23:26:19 UTC, Ramon wrote: But then, maybe D's beauty in part lies in the fact that it offers a lot regarding safety/reliabilty - and - very nice performance, too ;) One of the theories as to why there are no bears to be found on the African continent is that they are omnivores - i.e. generalists - which in a hugely competitive environment such as Africa, there is no niche in which they will not be beat out by a more specifically adapted animal. My understanding of D is that is like a bear, trying to be good at everything. (Maybe that's why bearophile likes it so much!) Human come from Africa. You'll a significant amount of monkey as well. D *does* offer roughly the speed of C++ *and* does compile significantly faster *and* offers reasonable strings and dyn arrays *and* offers DbC *and* offers considerable levels of safety. I don't see where this "bear" gets beaten up by lions or other kings of an environment. Yes, it's not yet fully there and still has some quirks. But then, D is not yet a fully grown up bear with decades of a predatory experience. And I for one couldn't care less for 2% less in speed - which I'll more than make up in development time, anyway.
Re: std.getopt error
On Monday, 26 August 2013 at 07:06:07 UTC, growler wrote: Given: int colOrder = 1; ... Could it be that "-c 1" is ignored because it is in invalid and the default colOrder value is used? Sorry for expressing myself clumsily. if the commandline arg is "-c 1" (which according to getopt doc is illegal) it actually *does* work properly. if the commandline arg is "-c1" (which according to getopt doc is legal) then the result of getopt is false/wrong. "-c 1" then sets the variable to -1. Same with 2. So the problem is not 1 or 1 being the var default. Thanks - R
std.getopt error
There seems to be a bug in std.getopt. D doc says: "To set timeout to 5, use either of the following: --timeout=5, --timeout 5, --t=5, --t 5, or ** -t5 **. Forms such as -t 5 and -timeout=5 will be not accepted." However bool reverseOrder = false, helpFlag = false; int colOrder = 1; getopt(args, std.getopt.config.bundling, "reverse|r", &reverseOrder, "column|c", &colOrder,"help|?", &helpFlag); sets colOrder to -1 rather than to +1 when the commandline has "-c1" as arg. Funnily, when the arg is *illegally* "-c 1", the variable is set correctly to +1. This is not an urgent issue because there is a very simple workaround: colorder = - colorder; But I thought it should be mentioned anyway and, if not noticed it can create troublesome situations. Being at that, the official rule "-t 5" is not acceptable is problematic because that form is pretty commonly used on unix and even sometimes used in docs. - R
Re: Why I chose D over Ada and Eiffel
On Sunday, 25 August 2013 at 23:00:21 UTC, bearophile wrote: Ramon: As for language comparisons or shoot outs, I don't care that much. In your first post of this thread you have listed some things you like, some things you don't like, listed points (Arrays, Strings, DBC, modern concurrency, GUI, "defer mechanism", Genericity) you have even assigned points. So while you have not written a direct language comparison, you have analysed specific points. In my answer I've given example that shows why Ada has still something good to offer that's lacking in D. Language comparisons can be sterile, or they can be a chance to learn. I think we have a misunderstanding here. I'm *not* against Ada and I think that, of course, comparing languages to a degree is a good thing and sometimes a necessity. I just don't think that slocs or "language A does it in x ms while language B needs y ms" does tell me a lot about a language. Referring to Walter Bright in part, I see that the major problem with server software usually is *not* performance but reliability and safety. Furthermore usually the game is influenced by quite different factors such as the concurreny model chosen. You might well end up having some Lua (interpreted!) server beating the sh*t out of apache (C/C++) simply because the former uses, say, libevent based AIO while the latter uses processes. *That* actually was a major criterion for me (I happen to work a lot in the server world): I wanted a language that offers a sound and elegant "multitask" implementation (à la Ada) as well as *easy* and comfortable access to AIO (which e.g. in Eiffel carries a considerable performance penalty by using the agent model). When I discovered vibe.d I smiled and thought "Of course! It comes almost naturally for a D guy to implement that". What a nice proof of D's capabilities.
Re: Why I chose D over Ada and Eiffel
On Sunday, 25 August 2013 at 22:27:30 UTC, Walter Bright wrote: It's also clear to me that unless D achieves performance parity with C++, D is not going to be considered for a lot of applications. The good news is that I believe that D is technically capable of beating C++ on performance. That is probably true for a large part of the existing and potential clientele. But while performance *is* important to me, my concern happens to not be performance to the max but rather the reliability aspects. Gladly, D delivers - and delivers quite well - in that regard, too. As for performance, maybe I'm plain old-school, i.e. falling back to asm (or C as a cross platform "asm") for those few really critical sections. From what I see around here, it seems that D still has quite some minor quirks. With all respect due (and well deserved) I consider it more important to get D really stable and well rounded. Actually, I think, D can afford some time to beat C++ in performance because thanks to it's asm capabilities, it's build in coverage stats and some other goodies, there always *is* some solution for performance. But then, maybe D's beauty in part lies in the fact that it offers a lot regarding safety/reliabilty - and - very nice performance, too ;)
Re: Why I chose D over Ada and Eiffel
On Sunday, 25 August 2013 at 22:00:23 UTC, Walter Bright wrote: On 8/21/2013 9:50 AM, Ramon wrote: I am *not* against keeping an eye on performance, by no means. Looking at Moore's law, however, and at the kind of computing power available nowadays even in smartphones, not to talk about 8 and 12 core PCs, I feel that the importance of performance is way overestimated (possibly following a formertimes justified tradition). While a 5% performance boost is not relevant for consumer apps, it can make an enormous difference for server side apps. For example, if you've got a $100m server farm, 5% means you save $5m, and server farms can be much, much bigger than that. You are, of course, perfectly right and my professional background would testify you to be correct. But I didn't argue "performance is evil" - my point is "performance vs. realiability" and that it may quite well be a problem to favour performance too much. performance is desirable, no doubt. But reliability is a conditio sine qua non in some environments. To rephrase it: Thank you, Walter Bright, for giving us not only a performant language but one that also offers some very welcome mechanism to support reliability/safety.
Re: Observation on packages
On Sunday, 25 August 2013 at 20:36:22 UTC, H. S. Teoh wrote: I don't think GDC is officially a part of GCC yet. From whereever it came and for whatever it's worth: (On mint 14) $ apt-cache search gdc | grep ^gdc gdc - D compiler (language version 2), based on the GCC backend gdc-4.4 - D compiler (version 1), based on the GCC backend gdc-4.6 - GNU D compiler (version 2), based on the GCC backend gdc-v1 - D compiler (language version 1), based on the GCC backend
Re: Why I chose D over Ada and Eiffel
Well, I had good reason not to mention Ariane5. Looking at that particular problem, D would have helped, too and roughly in the same way as Eiffel that is, by doing some debug runs with the current (Ariane5) values; then dbc could have helped spot the problem. I did, btw, not at all intend to bash Ada. From what I can see, Ada is well alive and has considerably more users than Eiffel and, at least for the time being, D. Looking at the type of user, usually not newbies but experienced software engineers, tells me that Ada is alive and well for a reason. As for language comparisons or shoot outs, I don't care that much. I tend to look whether a language has a sound implementation of some of the major concepts and paradigms, whether it's consistent(ly implemented) and whether it has dropped out of academia or rather had an evolutionary birth, preferably with lots of experience behind it. And yes, one point I keep in mind is what (in my minds eye) is the point to be learned from Ariane5: Humans aren't good at micro bookkeeping large numbers of details - computers are.
Re: DIP44: scope(class) and scope(struct)
Maybe I'm just plain too unexperienced or dumb but I see problems. - What's a dtor's job in D? This is not C++ (where cleaning up often means freeing/not leaking), in D the GC saves us lots of problems. Actually, we do not even really free anything (except malloc'ed stuff) but rather hinting the runtime expressis verbis that sth. isn't needed anymore. - scope(this) adds something new to the scope mechanism wich is per se bad and imo not justified for luxury. - I see H.S. Teoh's point to in a way have stuff aquired or allocated in ctor kind of "registered" in dtor for proper cleanup, but that *can* be done with what we have right now. - From what I understand the proposal implies some kind of a transactional "all or nothing" mechanism. Is a ctor and class level the right place to implement that? @H.S. Teoh Maybe it would helpful to explain why you think this is an *important* problem (rather than a nuisance) and more clearly define it (and why it can't be solved using what we have)? Thanks
Re: codeblocks - simple newbie tip/correction
Thanks a lot, Deadalnix What/How you told me to do worked fine. The new Howto (section) for D on Debian/Ubuntu/Mint with Code:Blocks can now be found here -> http://wiki.dlang.org/CodeBlocks Maybe someone with more experience might want to have a look and make sure I did't rape the wiki too badly. Thank you - R
Re: codeblocks - simple newbie tip/correction
On Saturday, 24 August 2013 at 18:01:55 UTC, deadalnix wrote: As you just did it, I think the best option is that you put what you just did somewhere in the wiki. Then we can work on form, link that where appropriate. That'd be great. Thank you. I do, however, not have permission to edit anything in the wiki (nor any experience in editing wikis). How to proceed? Thanks - R
codeblocks - simple newbie tip/correction
While rdmd is extremey handy, newcomers might often want to start simple and easy for the beginning. Looking in the D wiki, there is quite a lot listed under IDE and Editors and Code:Blocks might actually be one of the more attractive beginners solutions. Unfortunately the documentation (mainly on the code:blocks side) isn't reliable and/or correct and I feel that we should make it as easy and painfree as possible for newcomers to like and getting to try/work with D. I'm now sitting in front of a working installation on a current Debian/Ubuntu/Mint (which might be pretty often encountered) and could provide/share a short howto for that scenario leading to a properly working codeblocks for D. A) is that welcome/wanted? B) if so, what's the right place for such a howto? C) (for the future) is the forum the right place to introduce/ask about such stuff? If not, apologies for my misuse and: what's the right place and procedure? Thanks - R
Re: DIP44: scope(class) and scope(struct)
I'd seriously *hate* to abuse invariants for that. The job of invariants is to give guarantees about state - not to manage e.g. allocations, creations, cleanups, etc. "Has something properly succeeded and if not is there cleanup needed?" is the job of scope and possibly (but ugly and non-elegantly) exceptions.
Re: Parallel Rogue-like benchmark
I think that there is a lot speaking against sloc. First it's often (ab?)used for "Ha! My language x is better than yours. I can write a web server in 3 lines, you need 30". And then slocs say a lot of things about a lot of things. Like: Experience (being new or not used to X I'll need more lines in X than in "my" lang, say, D), built in vs. library, coding style, and others. In the end "100 sloc in X vs. 180 sloc in Y" quite often means close to nothing. Putting it bluntly: If I know enough about all the relevant details of the languages+environment to arrive at having sloc mean anything useful, I won't need that comparison in the first place.
Re: DIP44: scope(class) and scope(struct)
On Saturday, 24 August 2013 at 08:34:10 UTC, Simen Kjaeraas wrote: On Sat, 24 Aug 2013 03:34:32 +0200, Ramon wrote: What, for instance, if I aquire 10 resources in ctor and during normal programm execution cleanup 7 of them, so only some are left for dtor? Then they don't have the same lifetime as the object, and scope(this) would be the wrong tool for the job. Understood. But there *are* objects with different lifetimes. If, for instance, I aquire some "nice" objects (GC'd, properly through D) - and - some "dirty" malloced stuff (not talking about externals). Thinking about it I also dislike a special thing that also feels and shows a special thing (namely "this" rather than e.g. "failure"). "Holy rule": No special cases if any possible but everything in a consistent way. If there are special cases, somehow make them not look like it; try to make them look consistent. The scope mechanism deals with success, with failure and with exit. That's great, that's sufficient. That's how it should at least *look* like in ctors, too. Another inconsistency: If this mechanism is to "guard" on class level, it should be there, at class level and not in a function like entity (albeit the rather special "function" this). Maybe I'm overly shy but I feel that logical consistency is a major issue to be a good language and for safety, too.
Re: DIP44: scope(class) and scope(struct)
I don't want to be picky but I feel one shouldn't pack too much into one thing and in a way break the logic flow and possibly introduce limitations. The basic rule is to clean up in the destructor what has been allocated/aquired in the constructor - and this shouldn't be interrupted but stay that way. What you want to address, if I got it right (If not, I apologize for my interruption) is the problem of incoherent state, i.e. (relating to your example) to have res1 and res2 aquired but not res3. In my (possibly strongly limited) understanding scope(failure) is the right approach. Having a mechanism (as suggested) that also takes care of the dtor's job breaks the normal logic and might create new problems or limitations by implicitly putting a dtor job into a ctor mechanism. What, for instance, if I aquire 10 resources in ctor and during normal programm execution cleanup 7 of them, so only some are left for dtor? If scope(failure) does already work in ctor, just keep it that way. If not,HS Teoh's idea to make it work is great. But that about it. Don't add more functionality in it. Normal ctor/dtor working should be kept and so should scope(). Whatever user wants beyond that can be coded by him. Don't break major flow for some luxury (having scope in ctor isn't luxury, having it reach into dtor, too up to the point of making dtor superflous is). scope is a brilliant feature. But I feel we shouldn't have it do "miracles", even less behind curtains. In case what I said is just plain stupid and I should have shut up as newbie, I apologize and won't disturb any more.
Re: Parallel Rogue-like benchmark
I like it and see an interesting mix of concepts in Nimrod.
That said, I didn't and still don't see the major breakthrough or
value of {} vs. begin/end vs. Python style. While I agree that
Python enforces some visual style I also see that this question
always comes down to personal philosophy and discipline. You can
write clean looking code in D as well as in Python. If someone
really really feels, say, begin/end to be earthshakingly,
strategically better than {}, he is free to edit the language
spec and to create his private D (or whatever) with begin/end
rather than {}.
More importantly, I feel that whole sloc thingy misses the major
point. Code is written for 2 situations, once for the compiler
(which doesn't care too much about human readability) and, imo
way more important, maintenance. *That*, maintenance, is what
readability is or should be mostly all about.
I'll keep an occasional eye on Nimrod but I fail to spot anything
major or strategic enough to warrant even considering leaving D
for Nimrod.
R
Re: Why I chose D over Ada and Eiffel
On Friday, 23 August 2013 at 14:30:06 UTC, Chris wrote: On Friday, 23 August 2013 at 14:14:47 UTC, Ramon wrote: Listen: Your reference is quality, realiability, even elegance (an excellent indicator), maybe performance and yourself knowing you did it well. Don't give Joe and Mary any power they wouldn't know how to use anyway. And btw: Probably Joe and Mary won't know about or even understand your work. But they *will* notice that your stuff works reliably and well. Yes, of course. But shiney little buttons impress people and often the GUI logic is neglected due to a "Click, it works! Let's move on to something else" mentality. A lot of apps out there don't have a proper MVC architecture (look wxPython or Tkinter apps). It's just so easy to be neglegent. Absolutely, Chris, I get your point and I do not disagree. But, to be fair: We *all* are in some way or another guilty of that sin. Do we, for instance, all really see, value and appreciate the math behind behind many good things? Or do we, let's be honest, usually just say "Wow, D has cool dynamic arrays, that makes my life easier or Yowza, TLS 1.2 offers considerable security"? Frankly, most and that includes programmers, do not even make the effort to properly learn and understand the basics so as to, e.g. user the proper chain mode. I have an image that helps me. I see my "other" grandpa (actually a neighbour) having worked with wood, looking at his workpiece, refining it again a little until finally he looks at it and is content and everythings just fits nicely.
Re: Why I chose D over Ada and Eiffel
On Friday, 23 August 2013 at 10:34:08 UTC, Chris wrote:
On Thursday, 22 August 2013 at 20:10:37 UTC, Ramon wrote:
[...]
Probably making myself new enemies I dare to say that gui,
colourful and generally graphics is the area of lowest quality
code. Simplyfying it somewhat and being blunt I'd state:
Chances are that your server will hum along years without
problems. If anything with a gui runs some hours without
crashing and/or filling up stderr, you can consider yourself
lucky.
...
Well, I'm a friend of GUIs simply because with a GUI everyone
can use computers not just tech-savvies, and that's what
computers are there for, aren't they? The problem are not the
GUIs, I think, but the mentality. MVC hardly ever works in real
life due to constraints in framework design or deadlines. Cocoa
if used sensibly is great. But most of the time you don't have
proper MVC because GUI frameworks "seduce" people to do sh*it
like
Oh, I'm not at all anti-GUI "politically". I don't like anything
graphical (incl. X, Photoshop and pretty everything with pixels
and colours) for *pragmatic* reasons.
Actually I *do* see the advantages of a GUI and value them. And I
detest them for being sloppily designed along a set of criteria
DTP guys or artist might consider great but missing simple,
everyday needs. I detest them for usually being implemented in an
unsound way and generously wasting Megabytes and resources and
... (*pushing brake*)
Just look at a modern browser. It happily eats up around 200 -
300 MB Ram and a good part of the CPU's cycles. And that for 1
person.
Now look at a server. It walks and works and dances with 1% to
10% of memory, a fraction of CPU cycles and serves hundreds of
users.
Look at a smartphone ...
It's the "bolt-on" mentality that ruins things, which is partly
due to deadlines. As one guy once said to me (after I had
complained about a quick and dirty implementation) "We have the
choice between doing it right and doing it right NOW!" Ain't no
more to say.
Right you are. But then, this is also true for anyone else.
Pretty every software (in a company) is created with tight
deadlines and "design", priorities, and features dictated by
Marketing and product management (read: marketing/sales).
It's a sad state of affairs but quite probably the most efficient
way to very considerably increase product and code quality within
a very shiort time is to shot some marketing people.(No, Obelix,
you may not kill some graphic artists "while we are at it")
Also, sadly enough, technologies that were never meant to be
for GUIs are being used for GUI design. PHP and JS
(shudder) Much as I try to keep up a proper MVC pattern,
it's useless. Things will always be dirty, disgusting,
work-arond-y, unsafe, buggy, you name it. And you just stop
giving a sh*t. Ain't no use.
Hey, didn't they tell you? PHP and JS are freedom technologies,
enabling everyone to - well, now they actually *do* it and
we know what the Bible was about speaking of hell and unbearable
pain.
Where is Obelix? His attitude ("may I kill some?") might come in
handy ...
And last but not least, a programmer can work for hours on end
implementing a clever algorithm, using unit tests, component
programming etc etc. Nobody will ever notice. If users see a
button that when they press it the screen says "Hello User!",
they are forever happy. What goes on under the hood is "boys
and their toys".
Nope. Unless, of course, Joe and Mary "I'll gladly click on
anything and btw. Mr. Bob is cool" are your reference.
Listen: Your reference is quality, realiability, even elegance
(an excellent indicator), maybe performance and yourself knowing
you did it well. Don't give Joe and Mary any power they wouldn't
know how to use anyway.
And btw: Probably Joe and Mary won't know about or even
understand your work. But they *will* notice that your stuff
works reliably and well.
Re: Why I chose D over Ada and Eiffel
On Friday, 23 August 2013 at 07:15:49 UTC, Gour wrote: On Mon, 19 Aug 2013 22:18:04 +0200 "Ramon" wrote: Sorry, this is a long and big post. But then, so too is my way that led me here; long, big, troublesome. And I thought that my (probably not everyday) set of needs and experiences might be interesting or useful for some others, too. Thank you very much for this post. I was considering to use D for quite some time for multi-platform gui project, but was not satisfied with the state of its GUI bindings (only gtkd although someone was working on wx bindings, but, afaik, nothing happened) as well as non-stability of the language itself. That led me to research and try some other languages, starting with OCaml, then explored .NET/Mono platform and languages like F# (even Cobra). On the other end of the spectrum I've tried some obscure ones like Nimrod and finally considered Ada as the most robust/safe option with decent options for GUI (GTK & Qt). Your post and another thread 'DQuick a GUI Library (prototype)' makes me optimistic that it would be possible to use D as the 'general programming language' sutiable for writing GUI apps as well. Now, careful, Gour What I wrote was written with close to zero D experience and largely based on spec, gut feeling (W. Bright implements languages since 2+ decades and says straightout that he approached from a pragmatic view; which in my book counts as a bik +) and some logical verification. And it was said from someone who wants at least a large part of Eiffels goodness in a more C/C++ way and look and feel and practical useability. So, this might be pretty far away from what you consider reasonable, important, etc. Yes, I think that D lends itself very well to GUI programming and, more importantly (to me) it's one of the *very* few languages in which a useful, professional and soundly designed GUI lib could be implemented with adequate and reasonable efforts. A warning though (and one I tried to get written in red permanent marker like letters in my own head) when studying D somewhat more (along the D book): Don't underestimate D! One might be led to look at it as some kind of "easier C++ and better done"; it is not. Or, more correctly, It is way more than that and offers a lot of freedom paradigmwise. If GUI is very important to you it might also be useful to look at a small GUI (like lus'a IUP) and tinker along the lines of how this would, could, and should be done in D and at how it was actually done e.g. with the gtk binding. I hope you'll enjoy D as much as I'm beginning to do ;)
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote: Or rather, I *will* be happy as can be once I find a suitable replacement for a browser. Browsers are by far the most ridiculously resource-consuming beasts ever, given that all they do is to display some text and graphics and let you click on stuff. T Pretty much describes my feelings too, although I've made my peace with them beasts and like to use xombrero. Although webkit based (translate: bloat) it's relatively(!) modest and is keyboard controllable. I assume you know links2 and w3m, both textmode browsers which support tables, frames, and even images. links2 (or was it elinks?) even supported javascript for some time. You also might like that links by default is non-graphic and needs a commandline switch to go graphical. R
Re: Possible solution to template bloat problem?
On Friday, 23 August 2013 at 01:17:55 UTC, bsd wrote: Well, that's a bit harsh. Can we close this thread? Aren't you a bit harsh here? After all, as a quick forum search suggests, "Wise Words", or more correctly the person who usually writes under another screen name here made the effort to bravely use another screen name in order to ... uhm ... troll. I guess "Wise Words" didn't mean me but rather told us about an experience where someone told him "Grow a pair and move on". Evidently he didn't follow at least the first part of the advice given to him. Amusing.
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 19:28:42 UTC, Nick Sabalausky wrote: On Wed, 21 Aug 2013 18:50:35 +0200 "Ramon" wrote: I am *not* against keeping an eye on performance, by no means. Looking at Moore's law, however, and at the kind of computing power available nowadays even in smartphones, not to talk about 8 and 12 core PCs, I feel that the importance of performance is way overestimated (possibly following a formertimes justified tradition). Even if we assume Moore's law is as alive and well as ever, a related note is that software tends to expand to fill the available computational power. When I can get slowdown in a text-entry box on a 64-bit multi-core, I know that hardware and Moore's law, practically speaking, have very little effect on real performance. At this point, it's code that affects performance far more than anything else. When we hail the great performance of modern web-as-a-platform by the fact that it allows an i7 or some such to run Quake as well as a Pentium 1 or 2 did, then we know Moore's law effectively counts for squat - performance is no longer about hardware, it's about not writing inefficient software. Now I'm certainly not saying that we should try to wring every last drop of performance out of every place where it doesn't even matter (like C++ tends to do). But software developers' belief in Moore's law has caused many of them to inadvertently cancel out, or even reverse, the hardware speedups with code inefficiencies (which are *easily* compoundable, and can and *do* exceed the 3x slowdown you claimed in another post was unrealistic) - and, as JS-heavy web apps prove, they haven't even gotten considerably more reliable as a result (Not that JS is a good example of a reliability-oriented language - but a lot of people certainly seem to think it is). I agree. However I feel we should differentiate: On one hand we have "Do not waste 3 bytes or 2 cycles!". I don't think that this a the, or at least not an adequate answer to doubts of Moore's laws eternal validity. On the other hand we have what is commonly referred to as "code bloat". *That's" the point where a diet seems promising and reasonable. And btw., there we are talking megabytes instead of 2 or 5 bytes. Now, while many look in the hobby-programmers corner for the culprits, I'm convinced the real culprits are graphics/gui and the merciless diktat of marketing. The latter because they *want* feature hungry customers and they don't give developers the time needed to *properly* implement, maintain, and repair those features. Often connected to the this is the graphical guys (connected because graphical is what sells; customers rarely pay for optimized algorithm implementations deep down in the code). Probably making myself new enemies I dare to say that gui, colourful and generally graphics is the area of lowest quality code. Simplyfying it somewhat and being blunt I'd state: Chances are that your server will hum along years without problems. If anything with a gui runs some hours without crashing and/or filling up stderr, you can consider yourself lucky. Not meaning to point fingers. But just these days I happened to fall over a new gui project. Guess what? They had a colourful presentation with lots of vanity, pipe dreams and, of course, colours. That matches quite well what I have experienced. Gui/graphical/colour stuff is probably the only area where people seriously do design with powerpoint. I guess that's how they tick. You can as well look at different developers. Guys developing for an embedded system are often hesitating to even use a RTOS. Your average non-gui, say server developer will use some libraries but he will ponder their advantages, size, dependencies and quality. Now enter the graphic world. John, creating some app, say, to collect, show, and sort photos will happily and very generously user whatever library sounds remotely usefull and doesn't run away fast enough. Results? An app on a microcontroller that, say, takes care of building management in some 10K. A server in some 100K. And the funny photo app with 12MB plus another 70MB libraries/dependencies. The embedded sytem will run forever and be forgotten, the server will be rebooted ever other year and the photo app will crash twice a day.
Re: Possible solution to template bloat problem?
Regan Heath You try to wrap it nicely but in the end you just prove my hypothesis right. The newcomer not only has to know all local habits and quirks of the group but he also has to know the history behind it. As a helpful hint you pick up dicebots hint that a newcomer probably should be read only for a while. Great. And what exactly kept you away from formalizing that, such making it known to newcomers? You try different funny tricks on me, for instance, by mixing up responsabilities. If this group has rules - which it is perfectly entitled to have - then it's the groups responsability to make those rules known in advance. It is *not* the newcomers responsability to somehow find out about them, possibly by getting accused of destruction. Another little trick of yours is, I'm putting it bluntly, to play the card "We are many, you are just 1; we are here since years, you are new - so bend over and obey". Frankly, the original matter doesn't even matter that much anymore to me. I've since quite a while put it aside as "he's a cheap asshole with micro-alpha syndrome but he has done very useful and partly brilliant work. That's all I want from him. So what?". What drives me now is the desperate, abstruse and stubborn group dynamics at play. And no, I'm not doing that just for the fun of it; it can actually be a useful service (and it does have a certain relation to the original problem). In two words: Context counts. (Which btw. is something you should like as you try playing it a lot). In this context here group seniority might be a big thing. Or particular technical skills. As soon as we leave the area of code, however, the cards get mixed again and who was big then might be surprisingly small. In this discussion here, for instance, the capability to analyze and recognize e.g. social and rhetorical mechanisms is way more important than D skills (No suprise. After all it *is* a group, social and human thing). To put it bluntly: Chances are that I can take apart whatever smart tricks you come up with. But why, what for? Why don't you yourself just stick to your own advice and assume - and correctly assume - that I have no bad intentions? You even have proof! If I had bad intentions or just were out for a fight or revenge, I would certainly not have recognized A's work as brilliant and lauded his book. Nor would I quite politely and patiently discuss and respond to statements that I, no offense intended, perceive as, uh, less than intellectually exciting. Take what I offer. Because it's good and because you will definitely not succeed in getting any femtogram more from me. a) Mr. A. did act in an unfair und unjustified way, no matter how you try to bend it. Maybe what he did was well known and usual here. But not toward myself. b) It's long forgiven and I'm in a peaceful and constructive state of mind. But don't you dare to convince me that Mr. A. was right and I should bend over and adapt to absurd group rules that demand inter alia precognition and possibly telepathy. Can we now finally return to discussing D, algorithms, code and the like or do you insist to educate me and to continue your route toward nada, nothing, zilch? Just consider me a miserable creature and really ugly on top of it if that helps.
Re: Possible solution to template bloat problem?
On Thursday, 22 August 2013 at 16:28:58 UTC, Regan Heath wrote:
No, I did not take the advice. Partly because it doesn't mean
and/or concern me, partly because I tend to carefully select
from whom I take advice.
I believe it should concern you. I believe it contributed to
what happened here. I believe you would have a much more
pleasant time on internet forums (in general) if you took it on
board (not that I have any evidence that you don't, however can
you honestly say this is the first time this has happened to
you?)
I doesn't concern me because I do not entertain the assumption of
an evil (to me) world, because I do *not* assume anyone here
having bad intentions towards myself (from the beginning. That
might be different now)
For the rest of your post: Yeah, right, *I* have got it wrong.
Of course. You bunch of assholes.
("asshole", of course, meaning "esteemed colleagues" but I
won't tell you that until later).
I understand, you're blowing off steam. You're directing it in
the wrong direction here however.
Thanks for walking into my trap (put there for innocent
illustrative purposes only).
... To the point being made; 1 person cannot define the
"norm", you cannot redefine "asshole" all by yourself in any
meaningful way - that was the point I was making, and the
distinction which is important here.
Uhum. Well, it was only 1 person abusing the word "destroy". So
it *is* just 1 person that did take that liberty - and you
evidently think that's OK.
Furthermore: If you are right, how many persons are needed? I
don't think it's a quantitative issue.
What you really say is: You, the newcomer, entered our group and
by doing that you have to submit to our rules up to the point of
redefining the well established meaning of common words. EAT IT!
This not only is untenable by being quite close to rude
dictatorship but it's also nonsensical because a newcomer can
naturally not know the local quirks and habits, no matter his
good will to adapt.
Turn and bend it as you please, all the funny groups tactics to
make Mr. A's rude habit look nice (an myself guilty) fail. And,
surprise, some of you actually *expected* it to become
problematic and said so.
I do not even have a major problem with it. After all, it's
common and wide spread group dynamics that can be (and have been)
experienced all over the world. You have your holy little "D
crowd" living room and want to impose your own little rules and
want to celebrate and show loyalty to the great masters of that
"D crowd" living romm? Great, just go ahead, no problem with me.
But then stand with it and don't try to paint it nicely with
pseudo logical, pseudo psychological or pseudo social
explanations.
Funny, I have been lectured, fought and even attacked (e.g. as a
troll and a miserable creature) and it seems it just didn't
strike you that the solution might be as simple as Mr. A. saying
(what others already indicated) "Sorry, Ramon, it wasn't meant
negative, quite the contrary, but I understand that it could be
taken as negative and injust due to the usual meaning of
'destroy'. Feel welcome here".
And I'm still quite reasonable, polite, and friendly and I'm
still fair and open and praising not only D but even "evil" Mr.
A. and calling his work great and even brilliant.
To avoid misunderstandings: This is my opinion concerning the
matter at hand. I did and do not want to judge or attack you as a
person. While I have a clear and by no means positive impression
of what you said, I did and do not think your intentions were in
any way evil or negative. Actually I assume that your intention
was peaceful and constructive.
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 15:50:50 UTC, John Colvin wrote:
On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
One (OK, not very creative) example that comes to mind is to
have less experienced programmers to work in "safe mode" only,
which anyway is good enough for pretty everything the average
app needs, and to limit "system mode" to seasoned programmers.
If I was managing a D based team, I would definitely make use
of safe/system for code reviews. Any commit that touches
@system code* would have to go through an extra stage or
something to that effect.
Yep. Considering that pretty every non-trivial/small utility
software is layered anyway it comes even quite natural.
But I (often involved in systems stuff) will also use it as a
private warning system. Trying to get done whatever can get done
using @safe. Quite probably ("probably" because I lack experience
with D) it will even reflect back on the design along the line of
tinkering "does this *really* need to be here?".
Re: Possible solution to template bloat problem?
Dicebot "Have a nice day and be sure that I'll gladly listen to you as soon as it's about D ;)"
Re: Why I chose D over Ada and Eiffel
http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt I have quickly looked over that paper and find it quite worthless for a couple of reasons (I will not elaborate on, except one: All these scientific elaborations are nice and all but we have real problems here in the real world. Frankly, someone having worked on "Cyclone" may be bright and all, but he definitely hasn't got som major points). While Eiffel and D look (and in quite some respects are) quite different, both have actually realized some important real world problems and have them addressed in not so different conceptual ways. One of the reasons D is considerably more safe than C is strikingly simple and one doesn't need any scientific research to spot it: D offers (a quite sane implementation of) strings and "resizeable arrays". Why is this related to safety? Because zillions of bugs have been created by programmers desperately using, bending and abusing what was available in C (and to a degree in C++). Give them reasonable strings and some reasonable way to handle dynamic arrays and you have prevented gazillions of bugs. Simple as that. Another pragmatic look at reality underlines my point: In todays world even major software projects are being worked on by people with an almost brutally large degree of variation in their skills. Even worse, each of them (at least sometimes) has to work with code written by others with a (sometimes very) sifferent level of skills. D has made a very major contribution to safety alone for the fact that it allows less skilled people to create less errors. And it has something else that might not seem that big a thing, that however, started a (imo) very important path: safe, trusted and system. In C/C++ pretty everybody can - and does - play with potentially dangerous mechanism (like pointers) pretty much everywhere. Those simple 3 "code classes" safe, trusted and system can help a great deal there. One (OK, not very creative) example that comes to mind is to have less experienced programmers to work in "safe mode" only, which anyway is good enough for pretty everything the average app needs, and to limit "system mode" to seasoned programmers. Furthermore this D mechanism offers something else of high value by introducing a simple and important question "How much power do I need?". I might sound streetwise rather than properly educated, I know, but I have experienced again and again that what really counts is results. And I'm sure that D, if understood and used properly, contributes quite much to a very important result: Less bugs and more reliable code.
Re: Possible solution to template bloat problem?
Agreeing with eles
On Thursday, 22 August 2013 at 14:08:47 UTC, eles wrote:
Let's end this trouble. There is a lot of work that awaits to
be done.
I limit myself to
On Thursday, 22 August 2013 at 14:21:45 UTC, Regan Heath wrote:
.. and have you taken that advice as it was intended? With
good intent? Or are you still assuming the worst in people?
Yes and no.
No, I did not take the advice. Partly because it doesn't mean
and/or concern me, partly because I tend to carefully select from
whom I take advice.
And Yes, I have understood you having good intentions.
For the rest of your post: Yeah, right, *I* have got it wrong. Of
course. You bunch of assholes.
("asshole", of course, meaning "esteemed colleagues" but I won't
tell you that until later).
On Thursday, 22 August 2013 at 14:22:44 UTC, Dicebot wrote:
Human language rarely has any clear and well-defined meanings.
Without cultural context it is almost nothing. Actually, in
fact people almost never understand each other, they always
operate within some amount of false assumptions.
And, of course, the "D-crowd" is perfectly right assuming a
newcomer to know their internal communication codes - while - the
newcomer, of course, is plain wrong when assuming that words
carry the meaning they carry for the rest of the world. Sure.
Strikes me as brilliantly logical. I should bow before so much
wisdom. How does one bow around here? By farting?
In that regard, Andrei, who has been using well-established
communication protocol understood by most part of this
community was most honest and reasonable in expressing his
intentions. Failure to understand that is always your failure
as "proper" communication is always defined by community and
never by beliefs of some people.
Short version: Mr. A is alpha and we are "the D crowd" not only
making whateverrules we please but we also expect anyone entering
our virtual group to immediately know all our arbitrary wanton
rules and kinks.
Try that with your dog. Using that on intelligent life forms is
bound to fail.
Scorning from my side is not because of opinions you express or
technical goals you find important. It is because of sermon
flavor that overwhelms all your comments. No reasonable man can
think his beliefs and/or habits are any exceptional. Denying
this and refusing to properly study domain you oppose is quite
reliable indicator of ignorance or trolling. Probably both and
I shouldn't really care about the difference.
I must admit I am quite fast to lose my temper and tend to
overreact sometimes. However, it makes me sad to see that D
community falls into completely opposite extreme - wasting time
and efforts in useless attempts to satisfy people who are
simply mocking it, whenever form it may take.
So I'm supposed to thank you for your lack of consistency and
"wasting time"?
You seem to know quite a lot about D. It might be wise to play
that strength rather than doing what you did here (and which I
mercifully will not take on further).
Have a nice day and be sure that I'll gladly listen to you as
soon as it's about D ;)
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote: Just read this this : ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come back informed. Well, I can give you a link to some paper that says that the world will break down and stop next tuesday. Interested? A vast amount of software is written in javascript, java, C#, PHP and many "safe" languages, and still are crippled with bugs. Do I get you right considering js, java, C# and PHP being "safe" languages? They are dramatically superior to C in term of safety. I know "bridges" in Siberia that are vastly superior to bridges in the Andes. Frankly, I'd prefer to use a european bridge. And one *can* be in the C/C++ family and have a vastly safer system. Look at D. Some codebase are trully scary. Look at gdb's source code or gtk's. Written in C/C++ ... Well look at phpBB's source code then. Horrible codebase isn't language specific. So? Is this a "who knows most programs with lousy coding?" contest? All I see there is that programmers, in particular hobby hackers will spot - and use - any chance to wildly shoot around unless they are mildly (or less mildly) guided by a sound and safe system. And I see (and confess for myself) that even seasoned programmers can very much profit from a system that makes it easier to do the right thing and harder to do the wrong thing. You want no bugs ? Go for Haskell. But you'll get no convenience or performance. The good thing if that if it does compile, you are pretty sure that it does the right thing. Why should I? Isn't that what D promises, too (and probably is right)? D promise a pragmatic balance between safety, performance, ease of use, productivity, etc . . . Well, being a systems programming language D is condemned to keep quite some doors open. It seems (as far as I can that now) however to have done an excellent job in terms of safety (give or take some minor sins like '=' as assignment). One might put Java against D. But frankly, I do not consider Javas approach "Subdue them with pervert bureaucracy, hehe" approach as acceptable (and it creates a whole set of problems, too). Frankly, if I had to work on a highly safety critical and reliable project (say in the medical area) I would have a hard time to spot just 5 languages that I would consider. Ada comes to mind (but I don't like it) and Eiffel, which is great but that great pragmatically. I'm afraid I'd end up where I ended up in the first place: Eiffel vs. D. I'm probably not counted as a happy D protagonist around here but I'd happily state that D is way ahead of 99% of the known languages. And that expressly includes safety. On another perspective: Consider this question "Would you be willing to have all your software (incl. OS) running 10% or even 20% slower but without bugs, leaks, (unintended) backdoors and the like?" My guess: Upwards of 80% would happily chime "YES!". Would you accept it if it means a 3x slowdown and no real time capabilities (no video games for instance) ? I refuse to answer that because it's way out of reality.
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language
design from the beginning. In D ways and mechanisms are
provided to achieve what quite usually is the goal of
generics, namely generic algorithms in way, i.e. by having to
write code for an algorithm just once. That might seem to be a
minor difference, in particular when looking from a "Huh? I
can get it done, so what's the fuss all about, eh?"
perspective.
Of course, there the C and successors worlds proponents are
right, this incurs a price (which templates do, too ...) and,
yes, in the end, somewhere someone or something must sort the
types out anyway (because of the way CPUs work).
There are basically two ways to implement generics. Type
erasure (Java,Haskell) or template instantiation (C++,D).
Instantiation provides better performance, but sacrifices error
messages (fixable?), binary code size, and compilation
modularity (template implementation must be available for
instantiation). Type safety is not a problem in either approach.
Longer form: http://beza1e1.tuxen.de/articles/generics.html
An interesting twist would be to use type erasure for reference
types and instantiation for value types. Another idea could be
to use instantiation selectively as an optimization and erasure
in general.
Another example is data types, concretely integers. Ada offers
a nice way do precisely nail down precision/storage. If I want
to store days_of_month I can have an integer type holding ints
between 1 and 31 (which, due to the way they implemented it
can be a PITA). Eiffel gives me something quite similar (in a
more elegant way) and additionally a "dumb" INTEGER (32 or 64
bit) and than a gazillion subtypes like "INTEGER_16". That's
great because in a quick and dirty script a plain integer (max
size of CPU) is good enough and keeps life simple. If I need
days_of_month I can very easily have that as int type.
In D you can use structs:
struct days_of_month {
int day;
/* fill in operator overloading etc */
}
Thank you.
Well in an OO language the actual type(s) is/are known. So real
genericity boils done to whether an object has the required
functions or not.
D has, obviously piously following the C++ way (which can be a
good thing), chosen to go the template way, that is, to handle it
compile time. Other languages have chosen to do it runtime which
is no worse or better per se but happens to be more consistent
with OO.
Some here argued that, well, in the end, say, a simple int and a
bank account, need different data types and operations because it
matters to CPUs whether it does sth. with a DWORD or a char[].
And, so they argued, therefore you have to pay a runtime penalty
for real generics. I don't think so.
Sure, one evidently pays a penalty for OO in general (as opposed
to simple scalars). But it's not the genericity that costs.
Last but not least, there simply isn't a either/or issue. Once
can perfectly well have both. And no, that doesn't necessarily
bring a performance penalty with it.
Another point of view that doesn't match precisely but may help
to understand it is this:
True OOP is basically about "It's the *data*!" while systems
programming understandably is closer to "it's the *code*!"
Where the former has data "carrying the operations with them" the
latter has data as something that is fed in and processed and
spit out by the machinery. And it's that what brings up the
question "Well, but how would the CPU know what kind of data it's
working on? That requires expensive extra steps".
Again, for systems programming that's just fine. But the whole
penalty assumption largely stems from looking at true OOP through
the C/C++ model.
Re: Possible solution to template bloat problem?
On Thursday, 22 August 2013 at 09:10:33 UTC, Regan Heath wrote: On Wed, 21 Aug 2013 02:46:33 +0100, Ramon wrote: On Tuesday, 20 August 2013 at 22:58:24 UTC, John Colvin wrote: On Tuesday, 20 August 2013 at 22:49:40 UTC, Ramon wrote: Happily I'm stupid and completely missed the condescending tone of an evident genius. Instead I'll just be grateful that it pleased one of the D masters to drop some statement down at me at all. Awesome, thank you and keep destroying. "destroying"??? Which part of "not to bash it" and of "D means a lot to me" and of "D is, no doubts, an excellent and modern incarnation of C/C++. As far as I'm concerned D is *the* best C/C++ incarnation ever, hands down." was too complicated to understand for your genius brain? I knew this would happen at some point: Andrei uses "destroy" as a positive term to denote a well-reasoned powerful argument/response. Chill :) Uhum. Well, where I live "to destroy" has a pretty clear and very negative meaning. I took that post (of Mr. Alexandrescu) as very rude and condescending and I do not intend to change my communication habits so as to understand "to destroy" as a positive statement or even a compliment. Have you heard the phrase "when in Rome..". Seriously, you would rather assume a negative meaning/intent even after someone has taken the time to explain the intent/usage of the word/phrase in this grand forum? I sense that you may be beyond reasonable advice at this point? But, if not.. Always start by assuming good intent, if you're right (and you will be 90% of the time) no problem. If you're wrong, well at least you've not gotten worked up about it (so they have failed in their goal) and chances are it will annoy the abuser even more that you haven't (so ultimately, you win). Communication in written form is fraught with pitfalls, and this thread demonstrates how comments can be taken in completely the wrong way. Dicebot's "I am dangerously close to hating you." was meant in a friendly way, /you/ decided not to read it that way. Likewise Andrei's style is abrupt but there are good reasons for this, none of which include the goal of offending but /you/ have chosen to read them that way. Sure, more effort could be taken to make it clearer with excess smileys etc. But, that stuff isn't necessary for communicating the content, and isn't necessary between established forum members, and isn't necessary if everyone just assumes good intent from the outset. All the best, Regan Wow. Now I even get general advice for my life like "Always start by assuming good intent". How about some honesty? It happens to everybody of us. We hadn't any bad intentions but, alas, someone feels offended, improperly treated, etc. There is exactly 1 proper reaction for a responsible adult: To honestly look "Did I contribute to that?" and if so, to explain oneself. It would have cost pretty nothing to Mr. A. to simply say "OOps. Didn't mean any bad. When I say 'destroy' it's actually in between an invitation to continue hitting with constructive criticism and a compliment. Weird habit of mine". Not even a "sorry" would be needed. Well, he didn't. Instead he relied on his alpha-dog factor and the fact that there had already been some group members explaining and excusing him (and, in fact and very funnily, when he finally decided to comment he addressed not me but someone else). Meanwhile I'd be better placed to start trouble - if that ever were my intention. I've read a good part of Mr. A's book, watched quite some youtube, both with Mr. Bright and Mr. A. - and I have, to put it in prosecutor like wording, generously enough material in my hands (where Bright/AA basically say something I said too and got bad reactions. But then, it's not really new that it matters in social groups _who_ says sth.). One simple example: Is Mr. A perfectly well capable to talk/write within usual social limits? Yes, he is. His (btw. very well done, if somewhat jumpy) book proves it. He just happens to feel free to behave like an *** in this group, where he is an alpha and where "tough lingo" and weird personal rites are part of the "culture" - and glue - of this "D crowd". I don't feel hurt, I am not after Mr. A., I'm not looking for trouble and I'm not in fight mode or anti-D or anything like that. But would you (all) kindly refrain from playing your group games with me and telling me bullsh*t? I'm not interested. Mr. A. has written the book on D and he did that quite well. He has largely contributed to D and he did that well and some of his work is even brilliant (for "scope" alone I'd be willing to praise him gleeful
Re: Possible solution to template bloat problem?
On Wednesday, 21 August 2013 at 02:01:48 UTC, Dicebot wrote: This comment set put together with recent avalanche of JS posts makes a lovely collection of internet abuse techniques :) I can't even rage. It is brilliant. Thanks so much for your repeated status updates for your emotions. This is immensely important and doubtlessly of high significance for D. Just out of curiosity: Do you also sometimes refer to D or D related matters here? (Don't call. We will contact you ...) @Tyler Jameson Little Thank you. As you are not the first one to excuse/explain Mr. Alexandrescu's, uhm, (sometimes?) strongly individual communication style, I take that to (positively) imply that, except for some quite unlucky situations, Mr. Alexandrescu is well liked by many around here. ACK. Concerning this as well as the "D crowd" and the culture here, kindly give me some time to find my way around here and in D, will you. If this community is just half as attractive as D, and there are indications it is, I'll soon be a happy member ;)
Re: Possible solution to template bloat problem?
If I'm not completely mistaken, Mr. Alexandrescu could notice the obvious fact that I'm new here. Whatever, the interesting issue is not myself, or some, so it seems, hate and rage obsessed member whose screen name I don't remember, no matter how often he informs me about his negative feelings, or Mr. Alexandrescu (insofar as being a major figure in the "D crowd" and a co-developer of D automatically gives him a certain importance in matters of D), *the interesting issue is D*. Thanks to some of your constructive and socially competent posts to me my worries are greatly reduced and if I'm somewhat unhappy the reason isn't D but my somewhat unrealistic wishes and my possibly premature excitation. From what I see so far, D wins hands down against other languages that I've looked into in a quest over quite some years now. It's not perfect for me but then nothing is perfect for everyone. What matters is a simple question in the end: Does the overall mix support me in my work and in my striving to efficiently produce code that meets my standards in terms of reusability, reliability and others? While I still feel that Eiffel comes somewhat closer to my "dream language" I have to - and do - also see that in the end some pragmatic criteria make D the best choice for me. It should also be seen that at *no point in time* did I say (or feel) that D is bad or mediocre. It was clear from the beginning that D is in the top 3 anyway. Looking at it like this, this whole thing is basically a luxury discussion. And again, I did question (and question critically) D *because* it's so great and deserves attention incl. critically questioning. As for Mr. Alexandrescu, the main importance (IMO) is in him being an important D figure. Whether D should offer a friendly, forgiving and welcoming interface to newcomers or whether expecting newcomers are to know about Mr. Alexandrescu's personal habits and acting in a way that at least makes it easy to be misunderstood in an unpleasant and possibly apalling way is not for me to decide. For me it's more important whether Mr. Alexandrescu is capable to write a good book about D that helps me during my first steps (and possibly even beyond that). From what I know so far, this seems highly probable and I'm looking forward to start reading it tomorrow and to learn. Nevertheless, thanks for your constructive and positive way to approach things once more ;) R.
Re: Experiments with emscripten and D
On Wednesday, 21 August 2013 at 00:41:58 UTC, Piotr Szturmaj wrote: W dniu 21.08.2013 01:49, Ramon pisze: Ha! Expanding on myself: Have simple web server written in D on the client and then a "D-script" interpreter in that server. Possibly some minimalist "friendly" interpreter thingy like Lua too (or optionally). Only problem I see: Does D compile to/for Arm w/ Android and iphone "OS"? Don't worry. My solution just needs HTML + JS so it will work _everywhere_. Might be important as increasingly many users browse from their gadgets (rather than from their PCs) I still disagree. But I understand your point of view and wish you the best of luck. May the keyboard be with you ;)
Re: Possible solution to template bloat problem?
On Tuesday, 20 August 2013 at 22:58:24 UTC, John Colvin wrote: On Tuesday, 20 August 2013 at 22:49:40 UTC, Ramon wrote: Happily I'm stupid and completely missed the condescending tone of an evident genius. Instead I'll just be grateful that it pleased one of the D masters to drop some statement down at me at all. Awesome, thank you and keep destroying. "destroying"??? Which part of "not to bash it" and of "D means a lot to me" and of "D is, no doubts, an excellent and modern incarnation of C/C++. As far as I'm concerned D is *the* best C/C++ incarnation ever, hands down." was too complicated to understand for your genius brain? I knew this would happen at some point: Andrei uses "destroy" as a positive term to denote a well-reasoned powerful argument/response. Chill :) Uhum. Well, where I live "to destroy" has a pretty clear and very negative meaning. I took that post (of Mr. Alexandrescu) as very rude and condescending and I do not intend to change my communication habits so as to understand "to destroy" as a positive statement or even a compliment. While I'm certainly not in a position to look down on J. Ichbiah, N. Wirth, and B. Meyer, I have certainly not spent the last 25+ years without understanding a thing or two about my profession, no matter what Mr. Alexandrescu seems to think. No matter what Mr. Alexandrescu thinks or likes/dislikes or how he behaves I recognize (and praise) D as a very major improvement on C/C++ and as a very attractive language (by no means only for system programming). Furthermore I recognize and respect Mr. Alexandrescu's profound knowledge of D and the (assumed and highly probable) value of his book and thank him for his work. Maybe I'm simply profitting from my being a lowly retarded creature who, as some kind of a generous compensation by nature, is capable to recognize the knowledge and work of others irrespective of their being friendly or rightout rude and condescending. As for Mr. Alexandrescu's book, I'm glad to report that I will no longer need to molest him with my lowly requests. I have found a way to buy an epub version (through InformIt/Pearson). "D The programming language" has been bought and already downloaded and I'm looking forward to learn quite a lot about D from it. Regards - R.
Re: Why I chose D over Ada and Eiffel
On Tuesday, 20 August 2013 at 23:44:37 UTC, H. S. Teoh wrote: On Wed, Aug 21, 2013 at 01:33:34AM +0200, John Colvin wrote: I think you might enjoy https://github.com/conformal/xombrero/ snapshots here: https://opensource.conformal.com/snapshots/xombrero/ although they're a month or so old and I had to edit the URL to get there... They clearly don't want any noobs haha I just built from source and it works very nicely, very minimalist. Interesting, I'll have to take a look at this sometime when I have some free time. Thanks! In any case, I hope the keyboard interface isn't just something tacked on, as it's not as simple as it may look to design a keyboard interface that's efficient on a webpage, where you need to balance between navigating logical structure to find links, and providing visual navigation keys (ala Opera <=12). This is one aspect where I find Elinks lacking -- in a multicolumn layout the keys for navigating links leave a lot to be desired. Nope. Don't worry. xombrero (formerly named "xxxterm") is seriously keyboard driven. I happen to use it because I dont want the whole web bloat. It also offers quite interesting control through a simple keyboard interface. From what I have read so far from you you gonna love it.
Re: Experiments with emscripten and D
Ha! Expanding on myself: Have simple web server written in D on the client and then a "D-script" interpreter in that server. Possibly some minimalist "friendly" interpreter thingy like Lua too (or optionally). Only problem I see: Does D compile to/for Arm w/ Android and iphone "OS"? Might be important as increasingly many users browse from their gadgets (rather than from their PCs)
Re: Experiments with emscripten and D
I agree with those who are against it. For a variety of reasons, one of them being that, yes, anything that produces javasc*t does a) recognize js and b) embold and support it. Web pages are/should be about *content* not about eye candy and gadgets. Furthermore, increasingly many (like myself) have js filters, often in "brutal" mode (cutting out *all* js and enabling it expressly if needed/wished). The real solution isn't to add one more way to the existing 3 gazillion ways for js but to create a real alternative. Seen from D's perspective a D interpreter would be a start. Although, frankly, most web hackers won't like it; it's too unfriendly and hard, they want some kind of web basic (which js happens to be). And why and what for? HTML5 is rich enough. If I want to put serious computing work on the client I'd rather put it in a web server (written in D). And if I just want to put fancy blabla into a browser I can chose from 2,5 gazillion toys.
Re: Possible solution to template bloat problem?
Happily I'm stupid and completely missed the condescending tone
of an evident genius. Instead I'll just be grateful that it
pleased one of the D masters to drop some statement down at me at
all.
On Tuesday, 20 August 2013 at 21:52:29 UTC, Andrei Alexandrescu
wrote:
On 8/20/13 2:22 PM, Ramon wrote:
= vs :=
void main() {
int a, b;
if (a = b) {}
}
./test.d(4): Error: assignment cannot be used as a condition,
perhaps == was meant?
This is a solved problem. (However see also
http://d.puremagic.com/issues/show_bug.cgi?id=10862 which I
just submitted). I haven't heard a peep about it in D and C++
circles (most C++ compilers define a similar warning, although
they aren't required).
I did as advised and found:
Now consider:
void main() {
int a, b;
if ((a = b) = 0) {}
}
This compiles diagnostic-free. The shape if (expr1 = expr2)
should be
disallowed at a grammatical level, i.e. during parsing
Oops.
So, after all, making it invitingly easy to mix up assignment and
comparison can actually be troublesome? Wow.
I've seen hints from the authors of D themselves that '++' and
'--'
might not be the wisest way of action. So I stand here asking
"Why the
hell did they implement them?"
That would be news to me. I find "++" and "--" very useful for
daily use. D also implements their overloading arguably in a
more elegant way than C++ does.
I don't remember the precise spot but somewhere (here on this
site) someone from the D team says something to the effect of
maybe pre *and* post inc/dec might be not so desirable.
Whatever, it was *my* error to express myself not precisely. Yes,
++ and -- *are* useful. What I meant (and didn't make clear) was
that there are 2 versions, post and pre. One of them is fine, two
versions, pre and post, can create trouble.
It would be very simple to implement that logic in an editor
for those
who feel that life without '++' is impossible to automagically
expand
"x++" to "X := x + 1".
This argument is unlikely to do very well with this crowd.
So do other arguments in a C++ crowd. Happily enough you did
think what you thought and what made you aork on D anyway.
Having seen corporations in serious trouble
because their system broke (or happily continued to run albeit
producing
erroneous data ...) for this "small detail" I have a hard time
to defend
'++'. ("Save 5 sec typing/day and risk your company!").
Very interesting! What pernicious effects does "++" have?
Same thing as above. Pre-inc'ing e.g. a pointer that should be
post-inc'ed can lead to pretty ugly situations.
Another issue (from an Ada background): Why "byte" ... (the
complete
series up to) ... "cent"? Bytes happen to be important for
CPUs - not
for the world out there. I wouldn't like to count the
gazillion cases
where code went belly up because something didn't fit in 16
bits. Why
not the other way around, why not the whole she-bang, i.e., 4
(or) 8
bytes as default for a single fixed point type ("int") and a
mechanism
to specify what actually is needed?
So for days in a month we'd have "int'b5 dpm;" (2 pow x
notation) or
"int'32dpm;"?
As a rule of thumb primitive types model primitive machine
types. For everything else there are libraries. Or should be
:o).
This happens to be a nice example for perspective. C's
perspective (by
necessity) was resource oriented along the line "offer an 8bit
int so as
to not waste 16bits were 8bits suffice".
Yet we still do that in the 21st century rather than acting
more *human
oriented* by putting the decision for the size to the human.
Don't
underestimate that! The mere action of reflecting how much
storage is
needed is valuable and helps to avoid errors.
There's very much wrong in this. Byte-level access is necessary
in a systems language for a variety of reasons, of which
storing individual integers is probably the least interesting.
There is a reason or explanation for everything, no matter what.
But my point was another one. It was about another perspective.
C's and, so it seems, D's perspective is "What's natural with a
CPU" - mine is "What's natural and useful for humans trying to
solve problems".
With all respect, Andrei, your argument doesn't mean too much to
me anyway because if the job at hand is pure system low level
programming, I'll do it in C anyway. Furthermore it is well
understood nowadays that it might be smart to split even OS
design into a HAL (C/Asm) and higher level stuff (higher level
language).
Does it hurt performance to do everything in 32 bits rather than
in, say, 16 bits (on a 32 or 64 bit CPU)? Last time I looked at
CPU specs, no.
Finally,
Re: Possible solution to template bloat problem?
Thanks again, H. S. Teoh,
for yet another informative and well informed post.
Allow me one remark though.
"Easy to read" can mean a lot of things and coming from soneone
with a strong C/C++ background, it usually doesn't mean that
much. No offense intended, I do very well remember my own
attitude over the years.
Let me put it in the form of a confession. I confess that 25
years ago I considered Pascal programmers to be lousy hobby boys,
Ada programmers bureaucratic perverts and Eiffel guys simply
insane perverts.
It probably doesn't shine a nice light on myself but I have to
follow up with another and potentially more painful confession:
It took me over a decade to even think about my position and
C/C++ and another half decade to consider it possible that
Pascal, Ada, and Eiffel guys actually might have gotten something
right, if only minor details ...
Today, some hundred (or thousand?) hours of painful search for
bugs or problems later due to things like '=' in an if clause,
I'm ready to admit that any language using '=' for assignment
rather than, for instance, ':=' is effectively creating a trap
for the people using it.
Today I look at Ada and Eiffel with great respect.
I've seen hints from the authors of D themselves that '++' and
'--' might not be the wisest way of action. So I stand here
asking "Why the hell did they implement them?"
It would be very simple to implement that logic in an editor for
those who feel that life without '++' is impossible to
automagically expand "x++" to "X := x + 1". Having seen
corporations in serious trouble because their system broke (or
happily continued to run albeit producing erroneous data ...) for
this "small detail" I have a hard time to defend '++'. ("Save 5
sec typing/day and risk your company!").
Another issue (from an Ada background): Why "byte" ... (the
complete series up to) ... "cent"? Bytes happen to be important
for CPUs - not for the world out there. I wouldn't like to count
the gazillion cases where code went belly up because something
didn't fit in 16 bits. Why not the other way around, why not the
whole she-bang, i.e., 4 (or) 8 bytes as default for a single
fixed point type ("int") and a mechanism to specify what actually
is needed?
So for days in a month we'd have "int'b5 dpm;" (2 pow x notation)
or "int'32dpm;"? Even funnier, even D's authors seems to have had
thoughts in that direction (but not following them) when
designing the dyn array mechanism where a dyn array effectively
has 2 pow x based de facto storage (size 6 (elements officially
used) de facto is an 8 element array).
This happens to be a nice example for perspective. C's
perspective (by necessity) was resource oriented along the line
"offer an 8bit int so as to not waste 16bits were 8bits suffice".
Yet we still do that in the 21st century rather than acting more
*human oriented* by putting the decision for the size to the
human. Don't underestimate that! The mere action of reflecting
how much storage is needed is valuable and helps to avoid errors.
D is, no doubts, an excellent and modern incarnation of C/C++. As
far as I'm concerned D is *the* best C/C++ incarnation ever,
hands down.
But is '=' really a holy issue? Would all D programmers have run
away if D had ':=' as assignment op?
I wish, D had done all the miraculos things it did - and then on
top, had allowed itself the luxury to be more human centric
rather than sticking to a paradigm that was necessary 50 years
ago (and even then not good but necessary)
BTW: I write this because D means a lot to me not to bash it. For
Java, to bname an ugly excample, I never wasted a single line of
criticism; t'sjust not worth it. So, please, read what I say as
being written in a warm tone and not negatively minded.
Re: Why I chose D over Ada and Eiffel
First, thanks all for returning (or keeping up) a constructive discussion. @monarch_dodra My error, sorry. I was talking in the context of a western view, ignoring China, Japan, Koreas (and probably some more Asian countries/languages, too). Not meaning to propagate that as generally sound practice, I personally happen to work in a very western-centric world where, say, Russian (kyrillic alphabet) is already considered *very* exotic. In that context, however, 16bits are plenty enough. @H. S. Teoh I remember myself to stubbornly refuse Windows and staying with Dos or Unix (cli). Well, work forced me to make compromises and since FreeBSD came up (and Solaris worked on X86) I made one step and another ... and are (by your standards) pretty rotten nowadays *g I got your point and I agree. Yes, it's a major plus for D to be cli useable and not requiring a (probably bloated) IDE. OTOH, I'm quite liberal in that and never had qualms about using an IDE (or, in old days, E, brief and the like); after all, a computers raison d'etre is to make our lifes easier and to take on a gazillion of boring little tasks, no? But it's, of course, strongly desirable to have "direct access" on the commandline, which IMO is valid for other areas, too. Actually it always was oe of my reasons to outright hate Windows for keeping me away from its guts. @Timon Gehr Here I'd tend to disagree. Code duplication is the compiler's job. I get your point but I disagree. Sure, looking at it from D's point of view (with very powerful and elaborate "duplication" facilities) you are right. I see that, however, as a (valuable) add-on. It doesn't change the fact that the technical part of code production is an editors job; just think code completion, intellisense and the like. Maybe it's just a perspective thing. I tend to feel that the editor is the interface between the system and myself. What is produced with it will then be the input to a compiler. Anyway, that's not important because thanks to D's facilities we can actually have it both ways ;) As for generics: Maybe I'm not the brightest guy around but I have suceeded in noticing that there seems to be tendency in D's community to not react warmly to critical remarks regarding generics ... Actually, I'm far away from hitting on D. Even if, suppose, its generics were lousy, there would still be lots of solid good reasons to like D and to consider it one of the best approaches wide and far. It might as well be my fault to be stubbornly fixed on "generics done right".
Re: Possible solution to template bloat problem?
Thank you very much, H. S. Teoh That was an excellent post, very helpful and constructive. Thank you! I'm, btw. not opposed to templates and I see perfectly well that a compiler is in a better position to handle them than an editor. I also agree that sometimes I will gladly use templates rather than real generics. My main point wasn't anti-D (although I still don't like to advertise generics when actually delivering templates and mechanisms to implement generics oneself) but a completely different one: Sometimes I just want (or feel needing) to go fully OO and, at the same time, have the compiler take care of the nitty gritties. This, in fact, is a rather humble position; I have learned in many years that, no matter how smart we are, we introduce bugs and problems into our code because we are humans. I've learned the hard way that there are things computers simply do better and more diligently than we humans. And there is another point. Nowadays, we happily use gigantesque GUI systems, we gladly put 3 config parameters into an XML file and we happily consider 600k lines sorce code adequate for, say, an audio player based on some insane gobject system ... On the other hand we do have serious qualms to increase program size by, say, 5% in an application that typically runs on a 4 core processor with 8GB RAM. This strikes me as ... uh ... strange. And we *do get* something, possibly something vital, for those 5% code size increase, namely code that is easier to understand and to maintain, easier to extend and less buggy. I'm not sure that Prof. Meyers no compromises attitude is always good. After all, life is a series of trade offs and compromises. I am, however, pretty sure that template systems tend to be messy and complicated - and therefore bound to be error prone. 25 years ago I would have defended any weirdness; the harder and stranger the better. Meanwhile I have learned that readability often is considerably more important than ease of writing and that some compromises seem cheap but turn out to be very expensive later on. Last but not least, there are hundred (thousands?) of more or less compromise type languages out there. That wasn't what I was looking for. Thanks to your friendly, patient and constructive answer I'm feeling that while D isn't perfect it's quite close to it and, more importantly, it at least offers guys like me what I consider important, if at a price. So what. So, again: Thank you very much - Ramon
Re: Why I chose D over Ada and Eiffel
On Tuesday, 20 August 2013 at 16:49:35 UTC, QAston wrote:
Interfaces offer runtime resolution:
interface Comparable
{
}
void doStuff(Comparable c)
{
}
will work with anything that meets the specs for comparable.
For compile time resolution you can do this
Thanks QAston for your constructive and helpful suggestion.
Actually this is more or less the approach that I'm following
(researching for the time being).
Actually I assume that Prof. Meyer was at that point at some
time, too. He just happened, so it seems, to have figured out a
way to do polymorphism right and painfree. Pragmatically this
(your suggestion) pretty closely matches how one approaches it in
Eiffel (but don't tell Prof. Meyer! He'll probably vehemently
elaborate on theory *g).
Whatever, that's basically what I wanted. Although I have to
lament somewhat that D's doc (as far as I know) doesn't point
that out clearly.
Thanks.
Re: Possible solution to template bloat problem?
On Tuesday, 20 August 2013 at 17:05:21 UTC, Dicebot wrote: On Tuesday, 20 August 2013 at 16:59:00 UTC, Ramon wrote: I'm afraid the issue is bigger. Your insight about variety of modern programming language applications is extremely limited. If you are willing to introduce random runtime costs for nothing, there are lot of other awesome languages that can satisfy your needs. As someone who does not want to write embedded'ish code in C anymore (and hopes to drag D there eventually) I am dangerously close to hating you. And that shows. Well, if that fits your definition of "professional", so be it. To avoid misunderstandings: I still like D and think that it's a great language/solution. I still see very attractive points. I still think that even templates can be attractive and are way better done in D than in C++. I just don't agree that writing "generics" in the brochure and actually delivering templates is a good thing. And I happen to think that real generics are a very good thing. Nevertheless, feel free to hate me and to get closer to ad hominems. I even promise to *not* consider your attitude to in any way reflect D's (or their creators) ;-)
Re: Possible solution to template bloat problem?
I'm afraid the issue is bigger.
One major criterion, for instance, is the basic question how we
attribute weights to the involved entities.
C had a clear background. There was a new system (PDP11) and a
need to use it. Memory was little and strongly limited, the
typical use was quite modest (considerably less than what we
today have on our mobile phones), processor power and capability
was very low and very expensive, etc.
This, ladies and gentleman, is quite simple not anymore and
adequate approach.
Don't get me wrong, I'm not on the side of the other extreme
("Who cares about processor time and memory"). But the world has
very considerably changed and so has computing. Features that
would have seemd miraculous in 1970 are low standard today and -
very importantly - the whole world had very considerably gained
in complexity.
If I need to programm a MPC430 or even an STM32F4, I'll use C,
period. There *is* a solution for jobs with very tight
constraints, we just don't need a new language for that.
If, however, I have to design and build a solution that works on
different OSes incl. mobile phones and spans over a large network
then I won't use C.
Furthermore, we have seen again and again how unreliable humans
are at certain jobs. Just think "virus","buffer overflow" and a
gazillion of other problems stemming from two reasons, a) lack of
professionality and b) lack of perfection, where perfection is
very much dependant on working tediously diligently and
stubbornly (in other words, somethings that computers are *way*
better at than humans).
Templates just don't cut it, period. Templates are
ultra-yesteryear and proven to be troublesome, no matter how
smartly you implement them. It's just not acceptable that a
language in 2013 (in that regard) doesn't offer dimensionally
more and better than what I could do with Brief or the like in
1985.
So: Are D templates ugly loat? Yes, sure. Do I care? No, not at
all. Why should I complain about D being unsatisfying as an
editor?
Re: Why I chose D over Ada and Eiffel
Yes and no.
While UTF-8 almost always is the most memory efficient
representation of anything beyond ASCII it does have a property
that can be troublesome a times, the difference between length
and size of a string, i.e. the number of "characters" vs. the
number of bytes used.
---
As for another issue I'm getting more and more disappointed:
generics.
To put (my mind) bluntly, D does *not* support generics but
rather went into the same ugly trap C++ went into, albeit D
handles the situation way more elegantly.
Forgive me seeming harsh here but I just wrote it in the D gui
thread: Any really great solution needs a solid philosophy and
very profound thinking and consistency - and here D failed
bluntly (in my minds eye).
With all due respect: Templates are an editors job, not a
compilers.
Yes, templates offer some gadgets beyond simple replacement but
basically they are just a comfort thingy, relieving the
programmer from typing.
That, however, was *not* the point about generics. They are about
implementing algorithms independent of data types (as far as
possible).
Now, I'm looking around at mixins and interfaces in order to
somehow makeshift some kind of a halfway reasonable generics
mechanism. Yuck!
Well, maybe it's my fault. Maybe I was foolish to hope for
something like Eiffel but more pragmatically useful and useable,
more C style and way better documented. What I seem to have found
with D is a *very nice* and *way better* and considerably more
useful kind of C++.
Why aren't real generics there? I mean it's not that high tech or
hard to implement (leaving aside macho bla bla like "It'd break
the ranges system").
why not something like
generic min(T:comparable) { // works only with comparable
types/classes
// min magic
}
This could then at *run time* work with anything that met the
spec for "comparable" which basically came down to anything that
offers "equ" and "gt" (and "not").
On a sidenote: It seems we are somehow trapped in between two
worlds, the theoreticians and the pragmatics. Walter and his
colleagues have created an astonishingly beautiful beast coming
from pure pragmatic engineering, while e.g. Prof. Meyer has
created a brilliant system that just happens to be factually
unuseable for the majority of developers (and be it only because
hardly anyone will spend some 1.000$ to get started with Eiffel).
It's as if one side a purely as engineers while the other side
just didn't care sh*t about their stuff being useable and useful.
My sincere apologies if I happened to offend anyone; that was
definitely not my intention.
Re: Ideas for a brand new widget toolkit
Front up: As it seems nobody heftily disagrees with my groupings. While I myself am (as probably many others) in the 1 & 3 camp (looking for some kind of GUI-kit that is less massive than gtk, qt, etc. and runs pretty everywhere. - and - Add a GUI toolkit to D) I took note that there is also a not insignicant need from the 2 group (Looking for sophisticated GUI, possibly mainly for games, video etc.). If I'm not badly mistaken, the 2 groups needs will basically need/could be addressed by OpenGL. *Please, correct me, if I'm fundamentally wrong!* On Tuesday, 20 August 2013 at 01:28:10 UTC, Gambler wrote: IMO, a useful start would be choosing a moderately real-life use case and stepping through imaginary code or markup that would be required for it to work using each proposed approach (including data binding, event handling and so on). Well, yes and no. Actually I think that pretty everyone here (i.e. people who have a gui need of whatever detail sort) does have a pretty clear picture of "reasonable basics". Let me name it: - Windows (surprise! *g) - Menus - the "standard" controls (text boxes, lists, combos, ...) - font handling - supporting well established mechanisms like DragnDrop - and - importantly - a design that allows for creation of more complex widgets (like spreedsheats) using the basic ones. On Tuesday, 20 August 2013 at 07:15:38 UTC, Jacob Carlborg wrote: On 2013-08-19 23:01, Ramon wrote: - Whatever we come up with should use native controls where existing and otherwise simulate them using other more basic native controls. This sounds ugly, can, however, actually be a major chance and interesting approach. If native controls are used then the first step is make sure we have proper and easy to use bindings to these. For example, it's a PITA to access Objective-C frameworks (needed for Mac OS X) form D. So we need this: Thanks a lot! Important point. While there has not yet been defined a list of targets I assume,pretty everybody can agree on "Win/X11/Mac" and possibly Android (?) with the letter as well as other more exotic targets being more of a "we had it in mind and ried har to not block the road, did however not build it for the time being" kind, right? Which brings up another important point: Of course, it's seductive to "just get something working". At the same time though I suspect this attitude to be a major factor for GUI kits not having been finished or having been condemned to insignificance. I'd strongly suggest to not too quickly go to the "let's hack it" phase but rather to properly develop a design that is sound, allows for future changes and improvements (wayland, iphone, ...). That's true for languages, DBs and other stuff, too. The good and widely accepted ones have a clear "philosophy" and design behind them, the insigificant or bad ones don't. Sure, a programmers, we prefer coding but frankly, as *mature* developers we know about the importance of thinking, discussing and pondering before approaching the keyboard, don't we? @Adam D. Ruppe Thank you. I think those "etudes" can be very helpful. I suggest, however, no matter how attractive it might be, to *not* just grab something and hack on it but (sorry for repeating myself) to think well and profoundly about important criteria and a "philosophy" and only then begin to develop a sound design (before we start to hack the beast). One seemingly paradoxical reasoning behind my point of view is that we (well, most of us anyway) are not in the gui and graphics business but merely developers who need a major itching scratched, preferably once and for all. Thinking properly about it we will, if, say, a major new OS target or windowing system comes up, be able to quite quickly port our gui and be done with it. Another issue that we might underestimate are colleagues using completely different languages, say, Python. Shouldn't they - and wouldn't they love to - have a chance to grok/bind our D gui into their language, too? And wouldn't that be a major and quite convincing advertisement for D? Thanks everyone for your patience with my long posts - Ramon
Re: Possible solution to template bloat problem?
Well, I'm afraid that's what templates are. One (or the compiler)
fills them in and that's it.
In other words: Templates are compile time while (real) generics
are run time. This basically comes down to have some way of
designating classes as, for instance, comparable and then either
running along the object chain comparing all built in objects
(with built in compare functionality) or having a compare
implemented (Of course, there is also arithmetic functions, etc.).
While this sounds great it actually carries some code weight
("bloat") with it, too because all that functionality must be
somewhere. It gets (relatively) cheaper though when being heavily
used.
