Any project already written in dg?

[shizhaojingszj]

Besides dg itself, I cannot search any in github, maybe a dglang tag should be created?

[ceremcem]

IMO, there can't be any project written in dg while those other 12 issues continue to stay mostly unanswered and unlabeled.

[refi64]

I mean you technically still can, I used to have a documentation generator that I lost when my hard drive was wiped by accident.

[pyos]

Please note that dg is just a small project I made for fun, not something intended for use in anything serious. I didn't even bother telling anyone about it myself, what little attention it got is due to someone stumbling onto it by accident and posting links on reddit, etc. To be honest, I don't consider the design of the language to be particularly good.

IMO, there can't be any project written in dg while those other 12 issues continue to stay mostly unanswered and unlabeled.

Sorry about that, I was mostly occupied with work the last couple years and didn't have any energy left to maintain the side projects.

[ceremcem]

Please note that dg is just a small project I made for fun, not something intended for use in anything serious.

Well, I took it seriously :) I'm using LiveScript for lots of my commercial products, which is much like to dg for Javascript. dg has a great potential IMO, so it's sad to hear that it's not beyond an experiment.

Sorry about that, I was mostly occupied with work

That is understandable. However, maybe you should consider putting a proper disclaimer to the top of README so anyone can shape his/her expectations.

Again, I would always love to see dg as a counterpart of LiveScript.

[pyos]

I don't know, personally I don't really believe that a fancy syntax is all that important, and the benefits of using a widely known language are unquestionable. Even in Java it's not that hard to write beautiful code. (You do have to have a lot of boilerplate, sure, but it's not all that bad if it fits into established patterns, and I've heard people complain about having trouble reading my C++ code because it's "information-dense", so maybe sometimes verbosity is a good thing?) Sure, Python could use a few improvements on the functional programming front, but the most important ones - typing and performance (function calls are really, really slow) - aren't that easy. I don't even have any idea how to fit type annotations into dg's syntax...

[ceremcem]

benefits of using a widely known language are unquestionable

I love LiveScript and I use it a lot. Last year I came across with a library that just fits into my needs (at last) and I just picked the library up. However, library had a tiny bug, so I thought it's worth to fix it. I opened the code and voila! It was written in LiveScript! But... I didn't see such a garbage since college. I fixed the bug and then I started a massive refactoring (then created a PR, the PR is merged while WIP, etc.). My point is that the coding style matters more than language benefits.

I think, in Python, it's impossible to write a beautiful code if you're using Twisted, because you have to define the function first and then assign the callbacks and errbacks. That's why you have to write code upwards in the file (That's why Gevent is invented, AFAIK). Also, it's very annoying even reading your own code when there is a long chain of function calls because you have to read it backwards. Think of Bash pipes and how it gets our lives comfortable.

With No-parentheses function calls, with single character null checking, comparison operators like is, isnt; and most importantly with pipe operator; the language becomes self documenting (if the code is properly written). There is a fine line between a well designed language and a cryptic one though.

(function calls are really, really slow)

You mean in dg, right? While remembered, I want to ask you: Did you consider compiling to Python instead of bytecodes in the first place? For example, LiveScript has such a feature, thus

1. It doesn't have a performance penalty (it claims to run even faster with optimized code generation)
2. An application doesn't have to be re-written when one day we gave up using LS. Just compile to Javascript and continue the project with a well known language. That option relaxes everyone.

A language is like a vehicle. You have to choose the right one according to your destination. Think ADA/SPARK, think Elixir, think Julia. Popularity means nothing if you want to go to space, you can't use a car or bike, you have to invent something new. If the vehicle is already chosen for a project, learning how to drive is not that hard (takes a week or two).

[pyos]

You mean in dg, right?

In both dg and Python. It doesn't matter, code in either results in a CALL_FUNCTION opcode or similar. (Inlining would break reflection, etc.)

Did you consider compiling to Python instead of bytecodes in the first place?

That's what the first version did, and also what hy pretty much does (except it constructs a Python AST directly instead of outputting parseable code). That's limiting in what kind of constructs you can implement and does not help with performance if the virtual machine itself is slow. (In fact, something like a value-returning try-except would be even slower if implemented that way, since it would have to be extracted into a function because the AST does not allow you to use try-except as an expression.) Sure, you could say that maybe there's a fast Python interpreter out there and producing Python code would allow dg to run on it, but as far as I know, all but CPython and PyPy are dead.

it claims to run even faster with optimized code generation

Yeah, and that's JIT compilation, a feature of the virtual machine. CPython does not have that; the only optimization it can do is basically a constant folding and dead code elimination pass over the bytecode. dg also runs on PyPy, which might be able to produce good jitted code, but I haven't checked that.

[refi64]

something like a value-returning try-except would be even slower if implemented that way, since it would have to be extracted into a function because the AST does not allow you to use try-except as an expression

In Hy we just lift out statements from expressions and assign to a temporary variable FWIW.

[shizhaojingszj]

yes, typing syntax will be an issue. but haskell has...lol