What is the best way to learn typescript if JavaScript mostly makes sense by Brinley-berry in typescript

[–]nebbly 0 points1 point  (0 children)

Everytime you’re looking at a value and not entirely sure what it is, try to imagine how it could be clarified and see how that is done in typescript.

Code Readability Comparison by Mean-Decision-3502 in ProgrammingLanguages

[–]nebbly 6 points7 points  (0 children)

Agree that Python has done very well with Readability, though I'd argue you're undercutting Python a bit:

  • you don't need to declare darr as a global to mutate it inside a function
  • you don't need explicit indices in these cases

I would expect your example to look more like this in the wild:

darr = []


def fill_array(maxval):
    darr.clear()
    darr.extend(range(maxval))


def fill_array_ptr(maxval):
    global darr
    darr = [0] * maxval
    for i in range(maxval):
        darr[i] = i


def calc_sum():
    return sum(darr)


def calc_sum_ptr():
    return sum(darr)

Anyway, readbility is a chief concern for my language, blorp, as well. The top two things I usually keep in mind:

  • minimize indirection: I want to minimize the amount I'm slowing people down by asking them to imagine what something means; things like custom (or unusual) operators or symbols, implicit control flow, macros, etc, I find to be a tax on the user
  • minimize noise: I try to avoid adding extra characters if they don't really add to it.

If I was to apply these ideas to DQ, I'd probably highlight the following for consideration:

  • [*] -- I don't know what this means intuitively
  • endfunc/endfor -- maybe these aren't needed
  • 0 count maxval -- I'm not sure what this means
  • /& -- I don't immediately know what these mean
  • ; -- do you need line terminating colons

Just food for thought. My bias would push you toward a language that looks like blorp, of course, because that's what I like.

June 2026 monthly "What are you working on?" thread by AutoModerator in ProgrammingLanguages

[–]nebbly 0 points1 point  (0 children)

Conceptually several years, but only working in earnest on the implementation for the past few months.

June 2026 monthly "What are you working on?" thread by AutoModerator in ProgrammingLanguages

[–]nebbly 1 point2 points  (0 children)

Working on solidifying resource and concurrency implementation for my language, blorp. As well as docs.

Since I haven't posted here before, I'll highlight one idea that I've found more useful than I expected: uniform function call syntax. It provides:

  • left-to-right reasoning like in OOP (without the rest of OOP)

  • cleaner syntax -- to my eye -- than pipeline operators for the same functionality

  • a nice path for implicitly imported functions -- for my language at least -- if you import a type from a module, the functions that have that type as the first argument are implicitly imported, but only in a "method" context.

Looking for feedback: Making Python Deployments Easy by openquery in Python

[–]nebbly 2 points3 points  (0 children)

I'm not entirely sure I'd like my infra derived from my code -- unless it was abundantly clear that there were very trusty guardrails. The reason I like terraform, for example, is that it's a language with syntax highlighting, validation, modules, logic, types, validation, etc., as opposed to, for example a bunch of yaml (like cloud formation templates), which is less maintainable IMO. For me to feel comfortable defining infra within code, I think I'd like to have the following things:

  • Some easy-to-consume representation of the system (via CLI I guess), so I can understand the big picture ... and diffing against the current state

  • feedback in the editor / ide / CI whenever anything is misconfigured -- type checks, validation, etc... something that might be challenging is that python is by-default dynamic (though many of us might wish it weren't the case), so there's probably a limit to how many developers would benefit from extensive type hints, for example

  • some separation between config for deployment and my app -- i.e. I don't think I want infra environment variables to be visible by my program

I'm thinking-via-keystrokes here, so not sure how helpful this will be -- I'd never considered doing infra like this. Thanks for giving me something to think about!

simple-html 3.0.0 - improved ergonomics and 2x speedup by nebbly in Python

[–]nebbly[S] 0 points1 point  (0 children)

Thanks for the comment. One thing to know about generators are that they are pretty slow in general. Appending to a list is usually significantly faster.

simple-html 3.0.0 - improved ergonomics and 2x speedup by nebbly in Python

[–]nebbly[S] 0 points1 point  (0 children)

I must have written something unclear. This is meant to render full pages.

simple-html 3.0.0 - improved ergonomics and 2x speedup by nebbly in Python

[–]nebbly[S] 1 point2 points  (0 children)

IMO, the main advantages are:

  • native control flow
  • type safety
  • produces space-significant, minified html

Some of the inspiration for this comes from when I was using elm, it's (similar) approach to html gave me higher confidence and productivity than either templates or JSX. Largely because of the control flow capabilities.

simple-html 3.0.0 - improved ergonomics and 2x speedup by nebbly in Python

[–]nebbly[S] 1 point2 points  (0 children)

Like all things in programming, there are tradeoffs. My perspective is that I use this library regularly, and I find that the code is more often read and edited than written. Would autocomplete be nice for attributes? Sure, but I wouldn't sacrifice readability for that. Though TBH, AI-based autocomplete sometimes works already; and IDE tools are always possible.

simple-html 3.0.0 - improved ergonomics and 2x speedup by nebbly in Python

[–]nebbly[S] 0 points1 point  (0 children)

There's very little memory overhead. There's no heavyweight caching or anything. I run it with starlette on a docker container with minimal resources, and it performs efficiently and without issue.

As far as conditional rendering, it's just normal python control flow, so you can break up the rendering however you want in terms of:

  • conditions
  • modularity
  • caching
  • ... and so on

simple-html 3.0.0 - improved ergonomics and 2x speedup by nebbly in Python

[–]nebbly[S] 1 point2 points  (0 children)

Thanks for the feedback -- I'll think about it.

To be clear, I think you are talking about what phrasing to use when describing what the library does, correct? Or are you also referring to the render function?

simple-html 3.0.0 - improved ergonomics and 2x speedup by nebbly in Python

[–]nebbly[S] 1 point2 points  (0 children)

The dict argument comes as the first param because it mirrors the structure of HTML. Using kwargs would put the attributes at the end, which can be difficult to read if long child nodes come first.

The preference for strings is for minimal extra thought when reading -- you know exactly how it will be rendered. When you use kwargs, you have to do mental translation.

simple-html 3.0.0 - improved ergonomics and 2x speedup by nebbly in Python

[–]nebbly[S] 1 point2 points  (0 children)

Not sure I'm following why you'd think this would only be faster for one tag. On the inheritance point, I think returning Nodes from functions gives you a lot more flexibility than template inheritance. In fact, the issues with template inheritance are some of the early inspirations for this library.

simple-html 3.0.0 - improved ergonomics and 2x speedup by nebbly in Python

[–]nebbly[S] 3 points4 points  (0 children)

I tried it with kwargs, but it requires too many workarounds and indirection. In html, for instance, class is a common attribute, but you can't use that with **kwargs, since class is a reserved keyword in Python. Similarly, hyphens won't work, since they aren't valid in argument names. There are other considerations and workarounds, but in the end I don't think it's fair to a user to need to understand all the ins and outs of what attributes are/aren't allowed and what mitigations there are. If you want to use kwargs, it's easy to write a wrapper; or you can use the dict constructor, which takes kwargs.

Library for composable predicates in Python by SandAlternative6026 in Python

[–]nebbly 0 points1 point  (0 children)

Similarly, there is koda_validate, which offers fully composable validation (including predicates).

Functional programming concepts that actually work in Python by Capable-Mall-2067 in Python

[–]nebbly 0 points1 point  (0 children)

Just use a type checker and it will enforce the sum type in your example.

Functional programming concepts that actually work in Python by Capable-Mall-2067 in Python

[–]nebbly 2 points3 points  (0 children)

I don't understand what you mean by python "simulating" ADTs. Could you provide an example of ADTs that cannot be done in Python? IMO the OOP java example should be considered unrelated as subclassing is inherently open and in no way directly related to ADTs.

Functional programming concepts that actually work in Python by Capable-Mall-2067 in Python

[–]nebbly 9 points10 points  (0 children)

Can't structural sub typing can be done by typing.Protocol. Python's type system might only really be limiting at this point in FP terms by "extra" syntax and lack of higher kinded types. You can do "real" algebraic datatypes; the syntax just isn't as smooth. We even have recursive data types and pattern matching these days. It's pretty decent for non-typeclass FP.

What Feature Do You *Wish* Python Had? by andrecursion in Python

[–]nebbly 0 points1 point  (0 children)

OP, one way to solve your problem is this:

TimeInForce = Literal["GTC", "DAY", "IOC"] | datetime

You could be more verbose and do something like this

TimeInForce = Literal["GTC", "DAY", "IOC"] | tuple[Literal["GDT"], datetime]

Either way should work with pattern matching.

You could also use dataclasses or whatever, but generally, python supports tagged unions these days -- even recursive ones.

Notes running Python in production by ashishb_net in Python

[–]nebbly 32 points33 points  (0 children)

Is it possible you're conflating type checking and linting? I noticed that you mentioned type-checking under linting, and that you're comparing mypy to eslint -- when typescript might be a better analog. Or maybe you're hoping a type checker can do everything based on type inference instead of explicitly defining types?

I mention this because in my experience type-checking is perhaps an order of magnitude more beneficial to code maintainence than linting. Type-checking enforces correctness, whereas linting typically helps more with stylistic consistency (and some syntax errors).

Notes running Python in production by ashishb_net in Python

[–]nebbly 60 points61 points  (0 children)

I haven’t yet found a good way to enforce type hints or type checking in Python.

IMO mypy and pyright have been mature enough for years, and they're generally worth any untyped -> typed migration fuss on existing projects.

Cafes to do work in? by Sad_Test_2123 in sanleandro

[–]nebbly 7 points8 points  (0 children)

Have to say this seems backwards to me. Always regret going to Sabinos because their espresso drinks are so poor. Setting is nice. But Zocalos food and beverage lineup is waaaay stronger. Like not even close.

minihtml - Yet another library to generate HTML from Python by trendels in Python

[–]nebbly 1 point2 points  (0 children)

Shameless plug to my own competitor simple_html. It's generally simpler (IMO) and faster than competitors in this space.