HN Explorer

56 comments

[ 2.8 ms ] story [ 106 ms ] thread
nicoburns
Question for the OP seeing as this is a Show HN: how does this compare to Nim (https://nim-lang.org/)?
eerimoq
It's a wide question, and I don't have a good answer. One obvious difference is the syntax. I prefer Python's syntax over Nim's, but at the same time I find Python slow sometimes and hard to use in embedded systems. I'm aiming to create something similar to Nim's toolchain to address that.
elcritch
P.S. Since you’re using C++ shared pointers, you might want a cycle detection. But like Nim’s new ARC you can let the programmer beware and ensure their programs don’t produce cycles. It seems handy to allow pure RC’ing for embedded devices.
nepeckman
Not OP, but a big Nim fan. I think Nim has made a mistake by marketing itself as Python inspired. I know why it does so; Python is a very successful language and as a niche language, Nim wants to associate itself with an established one. But in my experience, Nim has a very small overlap with Python. It is whitespace significant, prefers short words to symbols for operators, and has a robust stdlib. But if you look at the actual language semantics, or even the keywords, Nim is not really related to Python. I'd go as far as saying Nim is more similar to a Lisp than it is Pythonic (which works fine for me, as I prefer Lisp to Python).

All of this to say, the OPs language seems much more Pythonic. The key words, the built in functions, the class system, all seems designed to match Python as closely as possible.

elcritch
It took me a couple of weeks to realize Nim’s semantics are really different. Despite that Nim feels like an alternate reality of Python 2 -> 3 that went more lispy and a bit Pascal-ish. It gives me the old Python 2.7 vibe. Though I’d still prefer ‘def’ to ‘proc’ but that’s pretty minor to me.

It’s interesting to see how well the typed Python syntax maps to a static implementation of Python. The speed should probably be a lot faster than CPythin too for many cases.

sullyj3
The really nice thing about proc is that emphasizes that they are in fact procedures, rather than mathematical functions - a distinction that becomes more relevant as FP gains mindshare.
dukoid
I am working on something similar, although with a different focus (mobile coding): https://github.com/stefanhaustein/tantilla

P.S.: Might make sense to try to get to a common type-safe language spec?

eerimoq
Nice job.

I don't understand the question. Can you rephrase it? =)

dukoid
It might make sense to try to support the same subset of Python in both projects. On the other hand, this might make experimentation harder... And there seem to be many differences, for instance I am trying to move towards async/await... But there might also be areas that could be easy to get consistent, e.g. how local variables are declared...

p.s. And I wasn't aware of Cocopy either. Having a list of similarities and differences of all three might be useful...

eerimoq
I like the idea. If our languages are similar it could even make sense to stop developing one of them and focus on the other, but that's probably far fetched. I'll have a look at yours to get a better understanding of what it looks like and where it shines. Maybe we meet again =)
dukoid
Do you have any objections against using google drive for an initial list of similarities / differences? I think the comment function could be useful....
eerimoq
Please do, but I won't promise I will contribute a lot, so don't be disappointed. =)
dec0dedab0de
This looks cool. Is there anything specific you're trying to do with Mys that another language didn't do? Nim comes to mind as being in a similar space.

Small nitpick about the title: Python is strongly typed.

aidenn0
I would call Python untyped
striking
You would be wrong. Try adding a string and number together. That's a type error. Unlike in JS or C, where a lot of these conversions are implicit and only warn if anything.

Python determines the types at runtime, but it is very clear about what few operations you're allowed to do on any given set of types.

lgeorget
I wouldn't call C untyped because implicit conversions happen all the times. It's just that it assumes that since you declare your variables with a type, when you assign them, you know what is going to happen.
striking
I'm not calling C untyped either. It's weakly (statically) typed.
didibus
Barely anything is truly untyped nowadays, I can think only of assembly.
aidenn0
I can import this with no errors, so Python is untyped:

    def foo():
      return 1 + "2"
Another example showing Python is untyped:

    x = 1
    x = "2"
x clearly has no type. No variables in python have types.
dec0dedab0de
I'm not sure if you're being serious, but Im going to assume you are.

Your first example demonstrates that python does not have compile time type checking

Your second example demonstrates that python variables can dynamically change types.

striking 

  >>> 1 + "2"
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for +: 'int' and 'str'
https://dev.to/jiangh/type-systems-dynamic-versus-static-str...
aidenn0
What that article calls "dynamically typed" is commonly referred to as "untyped" in PL research.

The program '1 + "2"' is a perfectly valid python program with well defined behavior (it signals a TypeError). This demonstrates that you can in fact add integers to strings in python. Of course whether or not you can add integers to strings is completely orthogonal to whether or not a language is typed. Both typed and untyped languages may overload the addition operator.

SloopJon
For those downvoting aidenn0's comments, I was surprised to find that "untyped" is indeed a common term that includes what many people (myself included) call dynamically typed. See the three top-voted answers to this Stack Overflow question, one of which includes a citation from TaPL, a standard text (emphasis added):

"A type system is a tractable syntactic method ... Terms like 'dynamically typed' are arguably misnomers."

https://stackoverflow.com/questions/9154388/does-untyped-als...

I still prefer the term dynamically typed, because there are useful distinctions about value types to be made among such languages, such as those described in striking's link.

alanbernstein
I think this discussion is frustrating because your explanation seems to be based on well-defined terms of art, as opposed to the colloquial terms like "weak" and "dynamic".

It's like the discussion is untyped, and the downvotes are runtime errors that would have been caught if terms were agreed upon ahead of time.

eerimoq
Well, probably not. Nim is similar, but I prefer Mys' Python-like syntax. Mys' toolchain will probably be similar to Nim. That is, generating C/C++ code.

Sorry about the confusion. Mys is statically typed. I changed the HN post from strongly to statically to make it clear.

sitkack
Given that the OP is the github project owner, are you aware of https://chocopy.org/ ?

You might want to also look at Shedskin, https://github.com/shedskin/shedskin which converts implicitly typed Python programs to C++

eerimoq
No, I am not aware of ChocoPy. Thanks for letting me know.

Shedskin uses the Python interpreter if I remember correctly. I aim not to.

sitkack
It can make both standalone executables as well as extension modules that can be loaded into cpython2.7
nerdponx
For the sake of completeness, might as well mention Nuitka [1] (another Python -> C compiler), Cython (Python-like language that compiles to C), and Numba (LLVM-based JIT compiler for a limited subset of Python).

[1]: http://nuitka.net/

[2]: https://cython.org/

[3]: https://numba.pydata.org/

pmoriarty
Strongly typed? You mean statically typed?

See "What to know before debating type systems":

http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...

eerimoq
Updated the GitHub repo and the HN post. Thanks.
azhenley
> Type inference is generally a big win.

I see this claimed a lot, but haven’t seen any evidence.

aw1621107
Might depend on what "win" is supposed to mean in this context. If it's intended to mean "languages with type inference are more productive", then sure, evidence would be nice. If it's intended to mean "type inference helps cut down on the need for explicit type annotations", I don't think evidence is really necessary.
ajkjk
I think the claims might be the evidence you're looking for.
lioeters
Not sure if this qualifies as evidence, but a quick search shows there are papers exploring the topic of whether type inference is a "big win" or not.

Benefits of Type Inference for an Object-Oriented Real-Time Language

https://www.researchgate.net/publication/220391749_Benefits_...

EDIT: Granted, this particular paper may be more claims without solid evidence.

dpc_pw
> Data races will occur when multiple threads uses a variable at the same time, which will likely make the program crash.

... or let the attacker execute arbitrary code.

BerislavLopac
I was once toying with the idea to create a statically-typed Python-like language, and I had the perfect name for it: Typhoon... ;)
HhE3334R7hf1lLF
Alternate idea: a language called Typon in which the compiler paves over typos of keywords and symbol names.
tabtab
Before making Yet Another Language, I'd like to see a good analysis of the options and trade-offs they offer: what does each design choice make easier and harder. There is probably no free lunch, but maybe we can find a better lunch by balancing things carefully.
eerimoq
For me it's pretty simple. I love Python. I like speed. I like embedded. This is an attempt to take advantage of Python's type hints to create fast and hopefully small binaries that can be executed on embedded devices limited amount of resources (both CPU and RAM).

There are probably other languages that would serve the same purpose, but oh well, I can't resist creating another. =)

h8hawk
Have you look at mypyc?

https://github.com/python/mypy

Its a compiler that support subset of python and mypy's team including Guido work on it. It would be great if this kind of efforts have been done on more realistic project.

eerimoq
It compiles statically typed Python modules to CPython C extension modules. I do not know the details, but it sounds like that's a major difference to Mys.
mlthoughts2018
Cython is a great tool for this. It’s a superset of Python with full static compilation support for native CPython or for pure C or C++ extension modules.

https://cython.org/

scottrogowski
I love this.

I have nothing else to say except that I want this to happen. Python is an amazing language which is missing two things - static types and speed. I starred your repo and am looking forward to seeing it progress.

toxik
> We don’t need a GC because RC

    L = []
    L.append(L)
trumpeta
Isn't Dotty basically statically typed Python? They added whitespace syntax recently and thanks to Scala native it should be possible to have a LLVM backend somewhere down the line.