
Tamgu, a functional, imperative, logical programming language - clauderoux
https://github.com/naver/tamgu
======
dkersten
Automatic type conversion I think is a mistake. It’s a huge cause for bugs.
But even if not, automatic string to number parsing is definitely not
something I want in my production code. Not only is it something that causes
hard to debug errors, if in a tight loop, it can have big performance impact.
There’s a reason modern languages have become stricter on type conversation,
instead of less strict. This language looks cool, but I will never use it for
this reason.

~~~
noobermin
I might cause a flame here, but I feel like academics and people who give
conference talks have adopted stricter typed languages. Actual developers
instead embraced from the get-go rather dynamic languages
(Python,Javascript,etc.) and continue to use such languages without the type
hints because it's easy and they have things to build.

~~~
colatkinson
IME dynamic typing is super easy and fast until it suddenly isn't. Then you're
going through ten layers of functions to check if None is a valid value for
some parameter because some intern three years ago figured that would be the
easiest way to do it.

I'd say that while there's certainly a ton of purely dynamically-typed code
out there, there's also a current reversal of the trend, with static and
gradual typing coming back in vogue. Python has fully-supported type
annotations, and Typescript is the trendy new way of writing JS. Facebook has
ReasonML and Hack/PHP 7. Go and Rust, the current "cool kid" languages, are
fully statically typed.

I think that the bad taste left in people's mouths by "enterprise" Java and
its 30-character type names is fading, and that we'll see a few years of
static types. Then of course the cycle will repeat itself, as is tradition.

~~~
dkersten
My favourite language is Clojure, but this exact thing leaves a bad taste
sometimes. Clojure has the attitude that you should validate on the edges,
using spec or similar, and then have dynamic types in between. This is really
super convenient! However, as the codebase grows, subtle type errors do slip
through and it gets rather hard to catch, since its now a runtime error that
may not happen until a long time later (and then Clojure's notoriously bad
error messages certainly don't help). So you hope your test suite catches it.
Luckily, with generative property-based testing, which Clojure has reasonable
support for, this can often get caught early, but during tests is still not as
early as with a type checker and generative tests could still take a very long
time to catch subtle issues (but it catches a lot more than just type
errors!). Of course, Clojure also encourages developing in the REPL, so most
of the time, you can be pretty confident that it will work before you even run
the tests. Still, I feel like some kind of static typed Clojure (not a
separate thing like Typed Clojure, which is slow and clunky, but something
with first-class static type checking as part of the language) would be
awesome. Maybe in reality it would conflict with many of Clojure's other
niceties though.

------
clauderoux
TAMGU (탐구) is a programming language that combines functional, imperative and
logical paradigms into a single formalism. The language has also been
specially designed to simplify automatic annotation and data augmentation for
Data Programming. Pre-compiled versions for Windows, Mac OS and Linux are
available at:
[https://github.com/naver/tamgu/releases](https://github.com/naver/tamgu/releases)

------
dvh
"20" \+ 10 = "2010"

10 + "20" = 30

~~~
noobermin
`+=` a different operator than `+`. `+` is symmetric while `+=` isn't.

~~~
tempguy9999
Doubtless. But it's one more special case to remember, is it worth it?

~~~
clauderoux
Hello,

I guess I should have been more explicit. I'm sorry for the confusion.

First, Tamgu is a language in which the recipient variable defines the context
in which the instruction is evaluated.

If your recipient variable is an integer then everything on the right side of
your assignment will be treated as an integer. If it is a string, well
everything will be treated as a string.

We use this approach in many other instances:

int pos;

vector v;

string s="This is a testing case";

pos = "i" in s; //we are looking for "i" in the string

In this case, pos==2.

v = "i" in s; //we are looking for all positions of "i" in the string

v == [2,5,14]

~~~
tempguy9999
oof. I see what you say about the LHS defining how the RHS is evaluated but
that attaches expression evaluation to assignment. You can't do one without
the other. Also the target type may be obscure to the programmer. What's the
behaviour with

    
    
      string s="This is a testing case";
      println("i" in s);
    

But separately your example now looks even worse. It's quite reasonable to
expect 'in' to behave the same way for both cases; that they both return
[2,5,14] - now you've added another complication.

No offence but without some overriding principle, and a justification for that
principle (that "things are demonstrably easier if you do it this way"),
you've just dumped and extra load on the programmer _which I do not need!_.

~~~
clauderoux
None taken... :-)

Well, I did my fair share of programming over the years in so many different
languages (Pascal, Cobol, C, C++, Java, Python, APL, Lisp, Prolog, Basic,
Small Talk, various assemblers) that I honestly cannot remember all of them.

Tamgu is the result of this experience and my choice was always towards
compactness and readability, with Perl being my personal nemesis.

The advantage of this approach is that you don't need to remember a long list
of operators, they are simply re-interpreted in context and the re-
interpretation is pretty consistent over most of the code.

But, well as the adage goes: Of tastes and colors...

------
_bxg1
Quick point of feedback: the first two imperative (+=) statements presumably
are being treated as independent, not part of the same sequence. I.e.:

    
    
      "20" + 10 = "2010"
    
      10 + "20" = 30
    

This was confusing, given that they are sequential statements listed without
any clear separation.

------
6thaccount2
I like the idea of having something like PROLOG/minikanren builtin to the
language.

Prolog is neat, but I wouldn't use it for text processing and database access,
so the logic programming piece to me makes better sense as embedded
functionality in a more general purpose language, which is what I'm guessing
you did here?

~~~
dkersten
I have the exact same opinion and like minikanren libraries in Scheme and
Clojure for that reason. I always liked Prolog, it always felt like an awesome
way to write certain aspects of a program, but always felt super awkward for
the rest of the program. With this approach, you can write the bits that make
sense in the style that most suits. That's a pretty nice thing to be able to
do!

~~~
clauderoux
Actually, there is a simple program: hanoi.tmg in
[https://github.com/naver/tamgu/tree/master/examples/Predicat...](https://github.com/naver/tamgu/tree/master/examples/Predicates),
which shows how to mix Prolog and imperative programming for a benefit of
both.

------
nudpiedo
Nice set of features and paradigm mix. To which platforms does it deliver it a
binaries? Does it deliver binaries or it is compiled, and where does it run
the compiled program?

Can you show some realistic usage or application and how do all these feature
hold together? An mvp todo list could make it, for web or for the command
line.

~~~
clauderoux
Hello,

I provide binaries for Windows, Mac OS, Fedora, Centos and Ubuntu:
[https://github.com/naver/tamgu/releases](https://github.com/naver/tamgu/releases)

You also have some examples in:
[https://github.com/naver/tamgu/tree/master/examples](https://github.com/naver/tamgu/tree/master/examples)

I provide makefiles for all platforms:

Windows: Visual 2013

Mac OS: both command line Makefile and Xcode Makefiles (including the native
Mac OS GUI)

Linux: (also for Mac OS), I provide a python script: install.py that
determines what is available on your machine and create a Makefile.in.

------
chunsj
Looks like another rewriting of S-expression based logical programming system
into non S-expression one.

------
jaehong
tamgu(탐구). intersting. clauderoux, are you from korea?

~~~
clauderoux
Not exactly, but I work for Naver, which is a Korean company. The lab I work
for is in France near Grenoble in the French alps

