Hacker News Reader

Comment by weberc2 | Hacker News Reader

This seems like a neat project but I can’t say I ever wanted Python to be an even bigger language... Ideally we would have a Python-like that eschews unnecessary features like inheritance and much of the magic that makes Python hard to optimize (and often hard to understand), and with a type system (even an optional type system) that is better than Mypy.

I’m not 100% sure what that would look like, but I would ditch classes (and thus inheritance) for named tuples, make most things immutable by default, include enums and pattern matching (that the type system would check; I hardly see the point in dynamic pattern matching). If possible, typed code would compile to C extensions or similar. Oh, and exceptions would go away in favor of a Rust-like Result type.

View on HN

You should check nim out, it's a python-like language that compiles to C.

I also recommend looking at Nim. It has Python-like syntax but it feels very different than Python for me when using it. Stellar language though that has been getting a lot of attention!

Thanks for the recommendations, folks. I'll take a look!

Whoa - Nim seems really cool! Thanks for mentioning it. I like that it also compiles to JS, and seems to be pretty active (latest release was just on Dec 31).

Isn't Nim, like Python, a large, complex language? Looking at the documentation, it seems to include a huge number of features.

It is a little large, yes. The creator's goal was always to create a language with a small core but a rich set of features for extending the language (metaprogramming). Nim has bloated a little and we're now trying to remove as many features as we can without annoying too many people :)

Glad to hear it. I've been skimming the documentation and definitely got the impression that it is a feature-rich language to put it politely :). In the words of Bjarne Stroustrup, it seems like there is a small core language that wants to get out. I imagine you could create a linter that catches uses of extraneous features and foster a culture of "Good nim code passes this linter"--you could create badges for repositories that show the percent of the code that adheres to the linter or something. Over time, you could deprecate and then remove these extraneous features.

This is part of what turned me away from Nim, so it's good to hear that. Can you give some examples of some features you've removed recently? I notice you're not at 1.0, so are you comfortable ignoring the 'annoying too many people' part if you think there's enough of a reason to remove something?

One thing I can think of is the likely little known {.this.} feature, that's been removed. We definitely need to do more, and yeah, it's hard :)

Ever tried out Cython?

https://en.wikipedia.org/wiki/Cython

There's also RPython which is restrictive and what PyPy is done in.

https://en.wikipedia.org/wiki/PyPy#RPython

Edit: on an unrelated note, sounds like you'd love Go.

I'm aware of Cython and RPython. RPython is super cool but it isn't really a general purpose programming language. Cython is superficially similar to what I want, but it's always put me off; not sure why off the top of my head. I do love Go, however. :)

Cython is basically C in Python syntax with some convenience features.

Unless you know C it's not always worth using. Without doing any "C stuff" (i.e. just writing Python and compiling with Cython) you get about a 50% speedup in tight loops; sometimes that's good enough, other times it's not.

To go any faster than that, you basically need to start writing C code, using the CPython API, using Cython's badly under-documented features for doing so.

For me Cython truly shines when interfacing to C++.

Learning C to the point where you get Cython is pretty easy. C is much easier to pick up rather than the HUGE C++. Here is a video you can watch in an afternoon that would give you the general gist and covers the basics quickly. https://www.youtube.com/watch?v=KJgsSFOSQv0

I hear you on Go. I am a Python dev at work and love Python, have dug into PEP8 and understood the tradeoffs for the sake of simplicity. Now after years of not touching Go I go back to it and it feels soooo familiar. It truly feels like a compliment to any serious Python developer to find Go. Now I got two goto languages for prototyping.

Julia is very much like this.

superficially. Under the hood, though, Julia has an type-system that interacts with the compiler in a very specific way that makes it possible to write highly optimized dynamic code without the overhead of a VM (is that the right term) like python's.

What's wrong with Mypy? And have you looked at Pyre/Pytype?

Lots of small issues, some of which may have changed since I last checked. I haven't looked at Pyre/Pytype yet. These are just a handful of issues with mypy that spring to mind:

* Poor syntax support in the language. E.g., you have to define TypeVars as variables in a scope outside of the unit you want to use them in, potentially conflicting with other generic functions. No clear guidance from the documentation about how the type system interprets these, either.

* No recursive types; e.g., can't define a JSON type

* Some callables can't be typed. I'm thinking they're those with kwargs and/or args, but I forget the particulars.

* Unions aren't true ADTs; the only way to define single-value variants (e.g., "null" in a JSON type) is to do something verbose and hokey, like creating a type that can only have one value.

* Lots of common libraries can't be spec'ed and therefore can't be typechecked. Things like SQLAlchemy which generate their types/classes at runtime, for example.

* Generally, the implementation is buggy even for mundane cases

This sounds like Rust to me...

Rust is great for lots of reasons, but it's not remotely what I think of as Pythonic. Rust has a steep learning curve and requires a much deeper understanding of memory management than Python, and it's also not much smaller.

I feel like you mostly just described Haskell, no?

Haskell is functionally pure with a syntax that I just can't bring myself to call readable. It's also very complex--which string type do I use? Which prelude? Which compiler extensions? Which build tools? Which testing library? I think if someone went and made a Haskell-lite and really focused on polishing the experience (including a familiar syntax, simple/straightforward tooling, relaxing the functional purity requirement, etc) it would be a great advancement.

I agree and the closest thing I've found to a Haskell lite is F#.

Ocaml is, imo, a pretty and not utterly impractical language as well.

I knew the thread would head in this direction. :) Unfortunately, those languages' syntaxes are only marginally better and they have more complexity than I care for (especially objects and inheritance).

Given your "especially" comment -- you might be mis-remembering something about OCaml? It's true that it has these features, but in practice they are almost never used. The object system is useful if your program's design really needs open recursion / inheritance. But it's far more common to build an OCaml program using other constructs (modules and simple data types).

That's not to say that there isn't any complexity in OCaml. The type system and module/functor system have a daunting number of features. But most applications stick to a much simpler subset of the language, which is quite straightforward and easy to reason about.

Granted objects are rare and this isn't one of the things I consider to be significant grievance about OCaml. :)

Fair enough. :)

Does it still do the thing where it doesn't have operator overloading?

Made math code oh so ugly.

Ocaml has no ability to do ad-hoc polymorphism at all (but it does have parametric polymorphism), which affects more things than operators, so that's why not only have the weird math operators, but things like string_of_int.

This will change at some point though. Modular implicits are coming to Ocaml. These are similar but much simpler than Scala's implicits, and allow the same kinds of patterns. If Ocaml gets that and eventually gains a bigger community with better library coverage, it's something I would consider using heavily.

That would indeed be good yeah - it sounds like a small thing but it really would help code readability quite a bit, especially when dealing with stuff like bignums.

Also has a syntax reskin in the form of ReasonML

Please don't relax the functional purity requirement. Instead, just use an algebraic effects library in place of monads as the "sin bin", guaranteeing that anything fitting the requirements to be an effect commutes with other effects, but still requiring them to be marked in the type.

That's not meaningful to me (I'm a Haskell novice), but the thing I care about is that the compiler doesn't reject correct code (and no, "correctness" is not defined by the compiler, it's defined by the desired behavior). Whether that property comes from relaxing functional purity or some library, I don't much care.

There's a language community investigating those ideas here: https://www.eff-lang.org/ . As they brag:

>Effects are thus first-class citizens of Eff and can be seamlessly combined. There is no need for the do notation, no need for monad transformers, and no need to reshuffle your whole program just to read a global flag.

On that topic Haskell is soooooooooo much more readable than clojure to me

Could you elaborate on this? Personally, I like the idea of Haskell about as much as I like the idea of Clojure, but Haskell has never quite clicked for me.

I don't think it's necessarily readability holding me back from Haskell, but I do find Clojure to be highly readable which really helped me get up to speed with it quickly. I'm curious what you find more readable about Haskell.

Haskell has a higher learning curve. It takes effort to pick it up. There is no learn Haskell in 5 minutes. But it's syntax is incredibly consistent and beautiful once learned.

Clojure has an incredibly simple syntax, but that isn't so much because it removed the complexity but rather that it just moved it away from the syntax imho.

> There is no learn Haskell in 5 minutes.

True, but there is a learn Haskell in 10 minutes...

https://wiki.haskell.org/Learn_Haskell_in_10_minutes

If you spend enough time in Clojure, it becomes quite readable. With threading macros and the like, there's no real reason you need many more parens that a language like Python.

It is kind of funny when I make my programmer friends count parenthesis in their code vs my Clojure.

I guess no one of your friends uses F#

Not really, but I like OcaML.

I can confirm, I have been writing Clojure for seven years. Its pretty nice to look at now.

I guess it is just a matter of taste. Clojure is the reason I have been writing software and it helped me to achieve things that would be very difficult without. It just has the right set of tools for a guy like me with systems engineering background. I find it much more understandable to use map + reduce than for loops, async instead of fork + threading code. The out of the box performance of JVM is also one reason I keep using Clojure.

> which string type do I use?

I think this issue is way overblown. The reasons for choosing a particular string representation in Haskell are analogous to the reasons to choose among e.g. byte arrays, streams, string builders, etc. in mainstream programming languages.

> Which prelude?

There is a standard prelude. Unless you actively choose another one, that's the one you'll get.

> Which compiler extensions?

If you want to use certain advanced language features, enable the appropriate extensions.

> Which testing library?

Many mainstream programming platforms (e.g. .NET) have multiple popular testing libraries to choose from. Is this a bad thing?

These were examples of the choices one has to make when using Haskell; it is far from exhaustive. The point is that IMO Haskell undervalues consistency and standardization.

I can only directly address the examples you've given. If you disagree with how I've characterized those examples, I'd be interested to know why. If you have other examples, I'd be interested to hear them.

Haskell has its weaknesses, e.g. the lack of quality tooling available as compared to mainstream programming languages.

But I disagree that Haskell is complex, at least as a criticism. When expressing concepts of a similar complexity, I find Haskell to be particularly concise and expressive as compared to most other programming languages I am familiar with.

And if Haskell undervalues consistency and standardization, I would like to know as compared to what? The only programming languages that I know of where there are not many reasonable choices for e.g. a testing framework are those that either (a) haven't been around that long, or (b) haven't seen wide adoption.

I have never seen non-trivial Haskell that didn't enable at least 1 compiler extension. Laziness is difficult to reason about. Purity makes easy things hard in exchange for making hard things easy. You can't even make it through the standard library documentation without bumping into category theory.

Haskell is many things. Simple is not one of them.

> I have never seen non-trivial Haskell that didn't enable at least 1 compiler extension.

Language extensions are idiomatic Haskell. There is only one mainstream compiler used everywhere. Widely used extensions are a natural result when the compiler, as a testbed, can outpace the language standard.

Enabling extensions is as trivial as including a standard library package. (In fact, the extensions are often better documented than the standard library, as you hint to.)

Honestly, I’m content to agree to disagree. I’ve had this conversation too often to repeat it here. The criticisms aren’t novel; I’m sure they’re easily found elsewhere on the Internet.

> Which compiler extensions?

If you want to use certain advanced language features, enable the appropriate extensions.

Your answers typify a level of comprehension of Haskell which appears to occupy the same brain space empathy would do. The whole POINT is that there are complex language features which have to be enabled if you want them: how does anyone know a priori in a new situation what to enable and what to disable? What side effects? What consequences?

I loved learning Haskell but to pretend it's syntactic simplicity translates to simple in all things is to misunderstand.

Gcc has a million compiler -W options do you think every C programmer knows them all? Do you think that every cat user knows why we joke about cat -v?

You have mastered Haskell and forgotten what lack of complete understanding means to anyone else. Mastering FORTRAN or pascal or lisp was trivial by comparison.

Mastering the underlying concepts of recursion, and tail recursion, and typing systems, and then integrating optional language features is not trivial.

There's a lot here I would like to respond to, but I'll limit myself to a couple points:

> The whole POINT is that there are complex language features which have to be enabled if you want them

Yes, "if you want them". If you value having a simpler language, don't use them. And Haskell is hardly unique in this regard. You've mentioned GCC, but I think the Babel transpiler is another good example.

> You have mastered Haskell and forgotten what lack of complete understanding means to anyone else.

I've managed to teach my daughter some Haskell, who had no prior exposure to programming languages whatsoever, so I doubt your assertion is entirely true.

The hardest programming language I ever learned was the first one. Each one after that was easier than the one before...until I got to Haskell. It was so different that I was forced to go back to a more fundamental understanding of the nature of code and computation and start from there. It felt pretty challenging, especially at first, but I think that had more to do with my perspective and experience coming into it than the language itself (and the fact that I had a family and career at that point didn't help).

mypy is great

Reply on news.ycombinator.com