On Monday, 24 March 2014 at 22:23:50 UTC, Nick Sabalausky wrote:
> Using the same language on client/server is indeed quite nice, partly because of less mental context-switching, and also because of increased code sharing (which also makes it easier to move things between client vs server if you need to).

Yes, especially for data models. It is always annoying to modify several different layers just to add some fields to a database entry. Not a big deal, but so… pointless.

> using Haxe pretty heavily for a good while. Haxe is a rather "ok" language, which is practically high praise coming from me - I'm typically very critical of languages.

I've looked at Haxe from time to time, and I like the approach, but it has never been sufficient to solve any issues in any real code I've worked on.

> FWIW though, lately I've been swinging back over to the side of "I'd rather use the best language I can whenever possible, code duplication and other concerns over multiple languages be damnned." Life's too short to tolerate subpar tools.

Yeah, that's where I am at now too. So currently I deal with Python, Dart (working hard to get rid of Javascript) and C++ (and dabble with XSLT, Java and Objective-C). But I'd rather use something more clean and strongly typed like Go and D, but with Pythonesque terseness and functional style list processing hight level cleaness. Unfortunately both D and Go lack production level support. And even with production level support they still lack production quality libraries for excel handling, pdf generation etc.

On Friday, 21 March 2014 at 23:33:51 UTC, Ziad Hatahet wrote:
> I don't know if significant whitespace is actually "improving" the syntax.
>
> "As a simple, self-contained example, consider the representation of
> program structure. Some observers objected to Go's C-like block structure
> with braces, preferring the use of spaces for indentation, in the style of
> Python or Haskell. However, we have had extensive experience tracking down
> build and test failures caused by cross-language builds where a Python
> snippet embedded in another language, for instance through a SWIG
> invocation, is subtly and invisibly broken by a change in the indentation
> of the surrounding code. Our position is therefore that, although spaces
> for indentation is nice for small programs, it doesn't scale well, and the
> bigger and more heterogeneous the code base, the more trouble it can cause.
> It is better to forgo convenience for safety and dependability, so Go has
> brace-bounded blocks. "
>
> Source:  http://talks.golang.org/2012/splash.article
>
> --
> Ziad

+1

This is exactly my experience. A lot of people use Python for quick prototyping which doesn't involve more than a few hundered lines of code. Fine. If, however, you have a medium-to-big project in Python it is just one big annoyance. Python's syntax is prescriptive in the sense that it prescribes how your code should look like on the page ("to help you write clean code"). Even trivial things like copy and paste cause problems in Python (not to mention the "tab against space war"). As usual, (over-)prescriptiveness causes more problems than it solves in the long run.

On 3/24/2014 6:49 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Monday, 24 March 2014 at 22:23:50 UTC, Nick Sabalausky wrote:
>> Using the same language on client/server is indeed quite nice, partly
>> because of less mental context-switching, and also because of
>> increased code sharing (which also makes it easier to move things
>> between client vs server if you need to).
>
> Yes, especially for data models. It is always annoying to modify several
> different layers just to add some fields to a database entry. Not a big
> deal, but so… pointless.
>

Yea, common data models was a very big use of shared server/client code for me, too.

>> using Haxe pretty heavily for a good while. Haxe is a rather "ok"
>> language, which is practically high praise coming from me - I'm
>> typically very critical of languages.
>
> I've looked at Haxe from time to time, and I like the approach, but it
> has never been sufficient to solve any issues in any real code I've
> worked on.
>

For me, the killer features were:

- As mentioned already, shared server/client code.

- Being able to run code on any commodity PHP servers I was required to support, without having to actually *write* any PHP.

- (Note this was several years ago:) Being able to generate Flash applets without having to actually use any of Adobe's horrible toolchain.

- The language itself *didn't* totally piss me off. ;)

So yea, the Haxe language itself wasn't really a key thing for me, just what it allowed me to *avoid* doing. But even those reasons are loosing their bite for me now, since Flash has pretty much become legacy, vibe.d has appeared, and I'd just as soon avoid the entire PHP runtime as a whole.

> Yeah, that's where I am at now too. So currently I deal with Python,
> Dart (working hard to get rid of Javascript) and C++ (and dabble with
> XSLT, Java and Objective-C). But I'd rather use something more clean and
> strongly typed like Go and D, but with Pythonesque terseness and
> functional style list processing hight level cleaness. Unfortunately
> both D and Go lack production level support. And even with production
> level support they still lack production quality libraries for excel
> handling, pdf generation etc.

Heh, I guess that's where we differ ;) I'm...not exactly a big Python fan, and I find D totally production-ready. I generally avoid client-side JS - when I do use it, it's just a sprinkling. If I need to do anything else Flash-like in the future, I'm looking more at Unity3D (esp. the v5 on the horizon with asm.js support) rather than doing HTML5 directly or via things like Dart or CoffeScript.

On Tuesday, 25 March 2014 at 10:28:51 UTC, Nick Sabalausky wrote:
> On 3/24/2014 6:49 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> On Monday, 24 March 2014 at 22:23:50 UTC, Nick Sabalausky wrote:
>>> Using the same language on client/server is indeed quite nice, partly
>>> because of less mental context-switching, and also because of
>>> increased code sharing (which also makes it easier to move things
>>> between client vs server if you need to).
>>
>> Yes, especially for data models. It is always annoying to modify several
>> different layers just to add some fields to a database entry. Not a big
>> deal, but so… pointless.
>>
>
> Yea, common data models was a very big use of shared server/client code for me, too.
>
>>> using Haxe pretty heavily for a good while. Haxe is a rather "ok"
>>> language, which is practically high praise coming from me - I'm
>>> typically very critical of languages.
>>
>> I've looked at Haxe from time to time, and I like the approach, but it
>> has never been sufficient to solve any issues in any real code I've
>> worked on.
>>
>
> For me, the killer features were:
>
> - As mentioned already, shared server/client code.
>
> - Being able to run code on any commodity PHP servers I was required to support, without having to actually *write* any PHP.
>
> - (Note this was several years ago:) Being able to generate Flash applets without having to actually use any of Adobe's horrible toolchain.
>
> - The language itself *didn't* totally piss me off. ;)
>
> So yea, the Haxe language itself wasn't really a key thing for me, just what it allowed me to *avoid* doing. But even those reasons are loosing their bite for me now, since Flash has pretty much become legacy, vibe.d has appeared, and I'd just as soon avoid the entire PHP runtime as a whole.
>
>> Yeah, that's where I am at now too. So currently I deal with Python,
>> Dart (working hard to get rid of Javascript) and C++ (and dabble with
>> XSLT, Java and Objective-C). But I'd rather use something more clean and
>> strongly typed like Go and D, but with Pythonesque terseness and
>> functional style list processing hight level cleaness. Unfortunately
>> both D and Go lack production level support. And even with production
>> level support they still lack production quality libraries for excel
>> handling, pdf generation etc.
>
> Heh, I guess that's where we differ ;) I'm...not exactly a big Python fan, and I find D totally production-ready. I generally avoid client-side JS - when I do use it, it's just a sprinkling. If I need to do anything else Flash-like in the future, I'm looking more at Unity3D (esp. the v5 on the horizon with asm.js support) rather than doing HTML5 directly or via things like Dart or CoffeScript.

In semi related news, have you guys seen Cmsed? Built into the data model registration is generation of javascript models which tie into the restful routing to give you (if I finished it) the same level of interaction with the database as you would in D. And yes you're in control of the security of each data model for each operation type.
I just think thats a neat little feature.

On Saturday, 22 March 2014 at 17:28:16 UTC, Andrei Alexandrescu wrote:
> As simple as it gets. The program would translate files with extension ".wsd" into files with extension ".d" and run dmd (or rdmd) transparently. Appropriate handling of file timestamps etc. would complete a nice utility. You'd use it like
>
> wsd myscript.wsd
>
> which under the hood would create (if necessary) myscript.d and then exec rdmd on it.
>
>
> Andrei

Turns out this already exists:
http://pplantinga.github.io/archives/delight-programming-language.html

On Tuesday, 25 March 2014 at 10:28:51 UTC, Nick Sabalausky wrote:
> So yea, the Haxe language itself wasn't really a key thing for me, just what it allowed me to *avoid* doing. But even those reasons are loosing their bite for me now, since Flash has pretty much become legacy, vibe.d has appeared, and I'd just as soon avoid the entire PHP runtime as a whole.

I like the basic idea of Haxe since it in theory would allow programming cross platform on mobile units, but Apple, Google and Microsoft have made moves to make cross platform programming more difficult by deliberately being different for the sake of being different...

> Heh, I guess that's where we differ ;) I'm...not exactly a big Python fan, and I find D totally production-ready.

Well, I wasn't a Python fan until I started using it, and still don't like the dynamic aspects of it, but the language/library support is better than the alternatives.

The syntax does not prevent Python from scaling with a decent IDE, the lack of compile time type safety does. However it is nice to replace perl, bash, php etc with one cross platform language. Python manage to cover a lot of ground.

That said I consider using D for a Windows tool (reading CVS files and uploading the result to a web server as a "cron" job). If I can do full static linking and just install a single binary then I can get simple "unbreakable" installs on client computers.

On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote:
> Hi
>
> As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python?
>
>
> Thanks.

As an alternative, python could be modified to make it more D like.

Steve