Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Erg: a statically typed language that is Python compatible

github.com

Post reply on HN
Print view View original

131–140 of 194 posts

Re: Erg: a statically typed language that is Python compatible

#131

Post by still_grokking »

echelon wrote: post #122
chaxor wrote: post #98

Earlier quoted context omitted.

What i don't like about python: The goddamn versioning and packaging problems. About 5 years ago python was incredible. You could pop out a project quickly because there were very few packages that made breaking changes over their development, so you could often use your standard workflow with the set of packages you we're comfortable with, even if there were new versions available that day. Now, Nvidia and Google ru…

I feel this comment in my bones. I went from loving Python to hating it with a seething rage. Python package managers are all so bad that the only reasonable solution is Docker containers or vendoring everything (not easy). And even so, I've had untouched Docker builds still die because dependencies mysteriously get yanked or changed. God, I hate Python so much now.

If you like the look & feel of Python, but not the ecosystem:

https://docs.scala-lang.org/scala3/book/scala-for-python-dev...

Sorry for that quite random comment, but SCNR.

Re: Erg: a statically typed language that is Python compatible

#132

Post by pratk »

peaky_blinder wrote: post #84
codedokode wrote: post #18

Earlier quoted context omitted.

Because you can do a lot with little typing and there are lots of great libraries. Python is probably the best choice when you need to get something done quick or calculate something when performance is not important. It is also not an exotic functional language without loops and filled with linked lists. Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. If you name a language, wi…

> Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. There is no such thing as a buggy language. Software can be buggy (or language implementation), but not the language. And the reason you do not have integer overflow is because integers are implemented as integer objects of arbitrary size, which is great if you're doing something quick and dirty, but could be disastrous for a ser…

Well, we have defect reports in language specs too: https://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm

Re: Erg: a statically typed language that is Python compatible

#133

Post by still_grokking »

gilch wrote: post #67
hsbauauvhabzb wrote: post #58

Earlier quoted context omitted.

So why not static with the ability to ignore hinting or similar? C# does this. I think function definitions should be statically defined, but the actual body of a function could easily stay largely dynamic.

I do think that's helpful compared to the strict alternative, but much of the up-front cost is still there. You still write most things twice, and the static type checker still slows you down when prototyping. You'd still be tempted to write bad code to work around the insufficiently-expressive type language, rather than write it in the most natural way, and only give up when it's too hard. You can also approach this…

> You'd still be tempted to write bad code to work around the insufficiently-expressive type language, rather than write it in the most natural way. […]

Could you provide any evidence for the claims that one needs "workarounds" and can't write code "in the most natural" way in a statically typed language?

> You can also approach this from the other direction: why not start with a dynamic language for the rapid prototyping and gradually introduce typing as the code stabilizes? Python and Typescript do this.

Which obviously does not work, which is the whole point of this submission and discussion thread…

Re: Erg: a statically typed language that is Python compatible

#134

Post by pratk »

still_grokking wrote: post #114
tomp wrote: post #109

Earlier quoted context omitted.

It's technically not a "bug" in Rust or C++, it's undefined behaviour , which is much worse than a bug! (and it's never correct behaviour)

Little nitpick: In C/C++ it's "only" UB for signed ints. For unsigned ints it's arithmetic modulo 2^n (where n is the number of bits in the value representation of that particular size of integer). Such divergent definitions make the whole mess of course even bigger, that's not the point.

Also, the UB can be mitigated with -fwrapv (if desired) to handle overflowing integers with 2's complement

Re: Erg: a statically typed language that is Python compatible

#135

Post by barefeg »

Arbortheus wrote: post #9

It would be nice if someone created a typescript for python. Something that allows us to wrangle control and sanity over reams of legacy untyped python madness.

As others have mentioned, one can get some types in python through its own typing module and use a combination of tools for type enforcing and editor intellisense (mypy, pylance, etc.).

However what I’m missing is having more advanced type constructs. For example mapped types, lookup types, etc [1].

That said, it seems like python devs keep adding features over time. For example a couple of years ago it wasn’t possible to specify which fields of a dictionary are required and not required (it required putting required fields in one TypedDict and then subclassing it into another one that had the non required ones with total=False), nor it was possible to “spread” a TypedDict to declare the kwarg types in a function.

[1]: https://www.typescriptlang.org/docs/handbook/release-notes/t...

Re: Erg: a statically typed language that is Python compatible

#136

Post by elcritch »

bb88 wrote: post #106
elcritch wrote: post #91

Earlier quoted context omitted.

Erg looks fun for small programs. Though Erg's syntax choices seem less Pythonic than I'd expected. Interesting though, some of the idioms seem handy. Though Nim definitely can be described as a statically typed Python-compatible language! I haven't used them but https://github.com/Pebaz/nimporter https://github.com/yglukhov/nimpy both seem great. Nimporter in particular looks fantastic for writing fast python librar…

> I really want to try making a native KiCad autorouter. But I don't want to figure out the C++ plugin setup and since KiCad 6 the Python APIs seem better documented and supported anyways. So I find this to be super interesting, particularly when it comes to parts with lots of pads that one has to route. Python would let you iterate the algorithm quickly. It's far easier to optimize the big O notation of your autorou…

Thanks! Good to hear others would be interested in something like that. It's one of those borderline "oh man that would be nice".

> Python would let you iterate the algorithm quickly. It's far easier to optimize the big O notation of your autorouter than in C++, say.

The hard part wouldn't be the routing algorithm itself. It's getting the algorithm and code to handle all of the corner cases. That's really what has kept me from it.. Getting all the correct data in and out of KiCad seems like a pain.

> mostly because it would be easier to go back and forth in python rather than switching mental contexts between Nim and C and Python.

If I were to tackle it, I'd do it in Nim since my overall productivity is as fast or faster than with Python. The Python layer would just be necessary to act as the glue layer to KiCad and `nimpy` looks great. It looks like `nimporter` builds binary wheel's too! That's awesome.

Cython seems handy but involves more mental switching between Python-to-C types than Nim would (IMHO). Taking an example from the Cython docs and writing it in Nim with nimpy would be:

    proc randomNoise(number: int = 1): seq[float] {.exportpy.} =
      result = newSeq[float](number)
      for i in 0 .. number:
        result[i] = rand(1.0)
Versus the original Cython:

    def random_noise(int number=1):
        cdef int i
        # allocate number * sizeof(double) bytes of memory
        cdef double *my_array =  malloc(
        number * sizeof(double))
        if not my_array:
            raise MemoryError()
        try:
            ran = random.normalvariate
            for i in range(number):
                my_array[i] = ran(0, 1)
            return [x for x in my_array[:number]]
        finally:
            free(my_array)

Re: Erg: a statically typed language that is Python compatible

#137

Post by danuker »

gleenn wrote: post #83
vonwoodson wrote: post #25

Earlier quoted context omitted.

Oh, man, have I got a treat for you: go checkout hylang.org - Hy is a lisp that (ab)uses the python AST to give you access to the entirety of python, but gives you a pretty lisp syntax.

I've always been super interested in Hy but couldn't ever get it working. Any suggestions for forums or good installation instructions or tutorials? I live Clojure and also have to deal with a lot of Python at work so would be awesome to use lispy syntax to write my Python stuff

Does this not work?

`pip3 install --user hy`

as mentioned in the first page of the docs:

https://docs.hylang.org/en/stable/

Re: Erg: a statically typed language that is Python compatible

#138

Post by still_grokking »

pratk wrote: post #134
still_grokking wrote: post #114

Earlier quoted context omitted.

Little nitpick: In C/C++ it's "only" UB for signed ints. For unsigned ints it's arithmetic modulo 2^n (where n is the number of bits in the value representation of that particular size of integer). Such divergent definitions make the whole mess of course even bigger, that's not the point.

Also, the UB can be mitigated with -fwrapv (if desired) to handle overflowing integers with 2's complement

Stupid question, but how can a compiler flag "mitigate" some UB that is (to my knowledge) defined by the standard as UB?

This would be possible only if the standard would define the behavior in question as implementation defined. But that's not the case afaik.

Signed overflow is undefined behavior as it's afaik defined to be that. But maybe I'm just wrong here?

But at least SO is confining my knowledge:

https://stackoverflow.com/questions/16188263/is-signed-integ...

Re: Erg: a statically typed language that is Python compatible

#139

Post by hnfong »

still_grokking wrote: post #120
peaky_blinder wrote: post #84

Earlier quoted context omitted.

> Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. There is no such thing as a buggy language. Software can be buggy (or language implementation), but not the language. And the reason you do not have integer overflow is because integers are implemented as integer objects of arbitrary size, which is great if you're doing something quick and dirty, but could be disastrous for a ser…

> There is no such thing as a buggy language. How can you know if you don't have a verified formal description of your language's semantics? It's very much possible (and imho even quite likely) that a lot of language definitions are self contradicting. Of course one could argue that such self contradictions aren't "bugs" at all. But such an argumentation would seem very odd, imho, no matter one can actually "define"…

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

> Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN.

Probably not what the GP meant, but I think this qualifies as a "buggy language (spec)"

Re: Erg: a statically typed language that is Python compatible

#140

Post by zx14 »

gilch wrote: post #72
DreamFlasher wrote: post #68

Amazing, but... Why not done with Python syntax? And no, mypy is not a solution. Even with strictest mypy it is still possible to have errors that would have been caught with static typing.

Even with strict static typing, it's possible to have errors. Mypy is static typing.

What a ridiculous argument.
Post reply on HN