On Monday, 30 November 2015 at 18:07:20 UTC, Luis wrote:
> How do translate this example on SDLang ?

You can translate it by following these patterns:

http://www.yaml.org/spec/1.2/spec.html#Preview

As you see, you have some room for making it more dense if you want to. So you can tailor it a bit to your own taste.

On Monday, 30 November 2015 at 18:13:11 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 30 November 2015 at 18:02:34 UTC, Chris wrote:
>> YAML takes spaces into account, doesn't it? That's a source of unnecessary, Pythonesque bugs.
>
> Most editors support YAML so you should get no Pythonesque bugs since they enforce WYSIWYG.  I have more issues with my handwritten JSON than YAML.
>
> But there is nothing wrong in constraining the format as long as the resulting file is compatible.
>
> http://www.yaml.org/spec/1.2/spec.html#Basic

I once wrote a description in YAML. Spaces (or lack of them) lead to stupid errors. Not to mention the pain of copying and pasting with different indentation levels. If you have to use an editor to help you with indentation levels, there's something wrong, it means that it's not trivially easy.

When will people understand that indentation should not be part of a language's syntax?

On Monday, 30 November 2015 at 18:23:08 UTC, Chris wrote:
> When will people understand that indentation should not be part of a language's syntax?

Where is that norm coming from? :-) I my experience YAML is a very visually clean format for configuration. I use it for configuration files for websites.

As I mentioned, if you don't want tab issues, then just restrict the grammar so you have uniform indentation.

On Sun, 2015-11-29 at 22:52 +0000, Ola Fosheim Gr via Digitalmars-d wrote:
> 
[…]
> What is the advantage of having it in an imperative language, though? Isn't a concurrent deductive language better and faster?

Project definitions should be declarative, definitely. Proejcts should then have a default laying and naming scheme so that with convention over configuration you need say nothing else. THis was the hope of Maven and it chose XML. Then it became obvious that if you wanted even a little non-standard behaviour you had to write you own Java coded Maven plugin. So having a language which can offer a declarative DSL and the ability to do a bit of imperative stuff if it is needed, you get a good system. SCons and Gradle both do this: mostly declarative with bits as needed.

> Then again, what is the point of every language inventing their own eco system as an island...

Because, progress.

OK so there is the pissing contest of "my language makes a better build system than any other" so every language has to have its own build system. (Even Go switched from make to go.) However in doing this there is often forward progress in build. Maven beats Ant. SCons and CMake beat Make. etc., etc.

In the end though Lisp is the one true language, so we should all just write in Lisp.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sun, 2015-11-29 at 22:38 +0000, Paulo Pinto via Digitalmars-d wrote:
> 
[…]
> Only those that are required to use it for Android and suffer the pain of slow builds yet to be fixed as announced on Google IO 2015.
> 
> I have seen zero projects move to it, otherwise.

On the other hand I have seen none stay with Ant or Maven given the option of Gradle. Those that stayed were told they didn't have an option – for no good technical reason, just management "don't touch anything" attitude.

> All our customers are on Ant and Maven.

Maven I can sort of live with but only on double pay. Ant is beyond the pale in 2015. It was a late 1990s hack due to Make hatred.

> Personally I don't see any value on Gradle, besides having more time to fetch coffee.

I see huge value in Gradle as a replacement for Maven (and Ant of course). I have never seen the massive slow downs you intimate, for projects I have seen with both Maven and Gradle builds, the Gradle builds were a little slower, but the scripts were far, far easier to maintain since al the imperative things were in the build scripts not in additional Java plugins.

But this might be just a bikeshed issue. I have no intention of giving up on Gradle and SCons, I am intransigent. :-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 30 November 2015 at 18:56:58 UTC, Russel Winder wrote:
> On Sun, 2015-11-29 at 22:38 +0000, Paulo Pinto via Digitalmars-d wrote:
>> 
> 
>
> But this might be just a bikeshed issue. I have no intention of giving up on Gradle and SCons, I am intransigent. :-)

If it is a bikeshed issue then it will feel right at home in this thread.

On Sunday, 29 November 2015 at 18:54:04 UTC, Russel Winder wrote:
> On Sun, 2015-11-29 at 17:25 +0000, Poyeyo via Digitalmars-d wrote:
>> 
> […]
>> C/C++ make/cmake/nmake -> here be dragons
>
> Or SCons if you want to be cool. I guess Bazel (and maybe Tup) might
> become trendy.
>
>> perl CPANfile -> something perly
>> java maven -> xml
>
> Does anyone still use Maven – surely the world has moved to Gradle with it's Groovy scripts using the Gradle DSL.
>
>> ruby gemfile -> ruby
>> python pip -> python egg
>
> Python has moved to wheels, eggs were always crap.
>
>> php composer -> json
>> node.js npm -> json
>> go godep -> json
>
> I am not sure this as as mainstream as this comment implies. Also a lot of people are using gb.
>
>> rust cargo -> rust manifest
>
> Which is TOML.
>
>> d dub -> json and sdlang
>
> Personally I abhor JSON for this kind of specification, it a transfer notation between computers, cf. XML. On the other hand I couldn't get SDL specs working. I will undoubtedly try again as SDL is just so much nicer than JSON for this. On the third hand lots of people seem addicted to JSON. On the fourth hand I cannot get worked up about this, it is just a build specification script which really ought to be written in D. cf. SBT for Scala uses Scala. Leiningen for Clojure uses Clojure. These languages have the right idea.
>
> Oh, I just got worked up about this.

You can write build descriptions in D today:

http://code.dlang.org/packages/reggae

Package dependencies still comes from dub, so JSON or SDL are needed for that. Any project that needs an imperative language to describe its build can use reggae for the heavy lifting and dub to specify dependencies. You don't even have to use dub if you don't want to.

Atila

On Sunday, 29 November 2015 at 22:52:20 UTC, Ola Fosheim Gr wrote:
> On Sunday, 29 November 2015 at 18:54:04 UTC, Russel Winder wrote:
>> hand lots of people seem addicted to JSON. On the fourth hand I cannot get worked up about this, it is just a build specification script which really ought to be written in D. cf.
>
> What is the advantage of having it in an imperative language, though? Isn't a concurrent deductive language better and faster?

As much as possible, yes. But non-trivial builds require a DAG, ordering, and plain just telling the computer what to do.

I've written quite a bit of CMake script to handle complicated builds. When you need it, you want a full language. I've heard horror stories of people doing boolean logic and loops in XML for Ant. CMake script is bad enough, I can't imagine how much I'd bang my head against the wall trying to contort XML into a bad version of Lisp.

The truth is, for most projects a `dub build` will do, and that's fine. Declarative is the way to go then. But when you have binaries reading files to auto-generate code that then gets compiled in two different ways, one of which is copied... you get the idea.

Atila

On Monday, 30 November 2015 at 18:50:57 UTC, Russel Winder wrote:
> you had to write you own Java coded Maven plugin. So having a language which can offer a declarative DSL and the ability to do a bit of imperative stuff if it is needed, you get a good system. SCons and Gradle both do this: mostly declarative with bits as needed.

I don't know them, I am sure you have a point :).  But intuitively I think that modern build systems _ought_ to use a constraints-based language and be geared towards distributed builds... take that as an heartfelt opinion, not a fact.


> However in doing this there is often forward progress in build.

GNU make is good enough for my own stuff, but probably not so good for cross platform builds.

As for package managers, I'd much rather have a really good generic repository (like Debian) with precompiled vetted and patched quality libraries than all these language specific ones where 99% is useless/unfinished/unmaintained.

Take a look at node.js: 210820 packages. How do you find new gems in that mess? It is also becoming increasingly difficult to find quality stuff on github by searching IMO. Too much dead unfinished stuff. Maybe that's why Open Source repository sites die. They drown in dead code.

Besides, dealing with 10 different packaging systems, potential security risks and potential configuration conflicts is not entertaining.

> In the end though Lisp is the one true language, so we should all just write in Lisp.

Yes, keep it simple and do numbers in unary notation.

On Monday, 30 November 2015 at 19:36:18 UTC, Atila Neves wrote:
> As much as possible, yes. But non-trivial builds require a DAG, ordering, and plain just telling the computer what to do.

Representing a DAG in a logic language is not a problem. The biggest problem is probably that most programmers (myself included) have an imperative mindset.

> for Ant. CMake script is bad enough, I can't imagine how much I'd bang my head against the wall trying to contort XML into a bad version of Lisp.

I don't know much about CMake, only given it a glance as make+Python is good enough for me. But I see your point. I don't know how expressive CMake is, but it does take quite a bit of adjustment to express oneself in a deductive (logic) language.

> The truth is, for most projects a `dub build` will do, and that's fine. Declarative is the way to go then. But when you have binaries reading files to auto-generate code that then gets compiled in two different ways, one of which is copied... you get the idea.

Hmm, yes, but if we (in fantasy land) start from scratch and have a generic distributed build system with a shared nosql database for the intermediate results and some kind of linda-like tuple space to back it up with meta data. Then a deductive language to update the tuple space. Then you have regular executable workers pull stuff out of the linda-space, and put the results back in. Unlike a file system, it would be transactional.