Any project already written in dg? #44
Comments
|
IMO, there can't be any project written in dg while those other 12 issues continue to stay mostly unanswered and unlabeled. |
|
I mean you technically still can, I used to have a documentation generator that I lost when my hard drive was wiped by accident. |
|
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.
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. |
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.
That is understandable. However, maybe you should consider putting a proper disclaimer to the top of Again, I would always love to see dg as a counterpart of LiveScript. |
|
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... |
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
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
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). |
In both dg and Python. It doesn't matter, code in either results in a
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.
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. |
In Hy we just lift out statements from expressions and assign to a temporary variable FWIW. |
|
yes, typing syntax will be an issue. but haskell has...lol |
Besides dg itself, I cannot search any in github, maybe a dglang tag should be created?
The text was updated successfully, but these errors were encountered: