That’s enough for INDENT, but for DEDENT you also need a stack of previous indentation levels. That’s how, when the amount of indentation decreases, you know how many DEDENTs to emit.
The requirement for a stack means that Python’s lexical grammar is not regular.
AFAICT Python basically is a [statically-]typed language nowadays. Most people are using MyPy or an alternative typechecker, and the community frowns on those who aren’t.
> Most people are using MyPy or an alternative typechecker, and the community frowns on those who aren’t.
That's not like a widespread/by-default/de-facto standard across the ecosystem, by a wide margin. Browse popular/trending Python repositories and GitHub sometime and I guess you can see.
Most of the AI stuff released is still basically using conda or pip for dependencies, more times than not, they don't even share/say what Python version they used. It's basically still the wild west out there.
Never had anyone "frown" towards me for not using MyPy or any typechecker either, although I get plenty of that from TS fans when I refuse to adopt TS.
I think in the case of TS, it's more that JavaScript itself is notoriously trash (I'm not being subjective; see https://www.destroyallsoftware.com/talks/wat), and TypeScript helps paper over like 90% of the holes in JavaScript.
Python typed or untyped feels like a taste / flexibility / prototyping tradeoff; TypeScript vs. JavaScript feels like "Do you want to get work done or do you want to wrap barbed wire around your ankle and pull?" And I say this as someone who will happily grab JS sometimes (for <1,000 LOC projects that I don't plan to maintain indefinitely or share with other people).
Plus, TypeScript isn't a strict superset of JavaScript, so choice at the beginning matters; if you start in JS and decide to use TS later, you're going to have to port your code.
Typed Python vs untyped Python is literally the same as TS vs JS, don't let others fool you into thinking somehow it's different.
> TypeScript helps paper over like 90% of the holes in JavaScript
Always kind of baffles me when people say this, how are you actually programming where 90% of the errors/bugs you have are related to types and other things TS addresses? I must be doing something very different when writing JS because while those things happen sometime (once or twice a year maybe?), 90% of the issues I have while programming are domain/logic bugs, and wouldn't be solved by TS in any way.
I mean, I'm one of the fools who would fool you into thinking it's different, since I use all four languages. ;)
I can just skip the mypy run if I want to do untyped Python. I can't skip adding types if I'm writing TypeScript in most contexts; it's not valid TypeScript syntax. Conversely, I can't add types to JavaScript; it's not valid JavaScript syntax (jsdoc tags and running a static checker over that being a different subject, and more akin to the Python situation).
> how are you actually programming where 90% of the errors/bugs you have are related to types and other things TS addresses
It's the things in the "wat" video. JavaScript, in general, errs on the side of giving you some answer when you try and do something very unusual with types (like add a boolean to a number or a string to an array) over taking a runtime error. TypeScript will fail to typecheck in most of the places where those operations are techincally correct but surprising as hell in the wrong way unless you explicitly coerce the types to match up.
It's a funny video, still after 15 years of seeing it, I'll give you that. But the number of times I'm bothered by accidentally triggering those scenarios in real-life? Could probably count that on one hand.
I also give you that TypeScript helps beginner JavaScript developers a ton, and that's no easy feat by itself, just because of those things you mention. Once you build up intuition about how things work in JavaScript though, those sort of bugs should stop happening though, otherwise I'd say you aren't really learning the language.
> Never had anyone "frown" towards me for not using MyPy or any typechecker either
I’ve seen it many times. Here’s one of the more extreme examples, a highly-upvoted comment that describes not using type hints as “catastrophically unprofessional”:
But yeah, that's reddit, people/bots rejoice over anything being cargoculted there, and you really can't take any upvote/downvote numbers on reddit seriously, it's all manipulated today.
Don't read stuff on reddit and use whatever you've "learned" there elsewhere, because it's basically run by moderators who try to profit of their communities these days, hardly any humans left on the subreddits.
Edit: I really can't stress this enough, don't use upvotes/likes/stars/whatever as an indicator that a person on the internet is right and has a good point, especially not on reddit but I would advice people to not do so on HN either, or any other place. But again, especially on reddit, the upvotes literally count for nothing. Don't pick up advice based on upvoted comments on reddit!
Generally you only get frowned at if you're not using type hints while contributing to a project whose coding standards say "we use type hints here."
If you're working on a project that doesn't use type hints, there's also plenty of frowning, but that's just because coding without a type checker is kind of painful.
> Generally you only get frowned at if you're not using type hints while contributing to a project whose coding standards say "we use type hints here."
Yeah, that obviously makes sense, not following the code guidelines of a project should be frowned upon.
It's a pretty nice best-of-both-worlds arrangement. The type information is there, but the program still runs without it (unless one is doing something really fancy, since it does actually make a runtime construct that can be introspected; some ORMs use the static type data to figure out database-to-object bindings). So you can go without types for prototyping, and then when you're happy with your prototype you can let mypy beat you up until the types are sound. There is a small nonzero cost to using the types at runtime (since they do create metadata that doesn't get dropped like in most languages with a static compilation step, like C++ or TypeScript).
I can name an absolute handful of languages I've used that have that flexibility. Common LISP comes to mind. But in general you get one or the other option.
> It's a pretty nice best-of-both-worlds arrangement
It’s also a worst-of-both-worlds arrangement, in that you have to do the extra work to satisfy the type checker but don’t get the benefits of a compiled language in terms of performance and ease-of-deployment, and only partial benefits in terms of correctness (because the type system is unsound).
AFAIK the Dart team felt this way about optional typing in Dart 1.x, which is why they changed to sound static typing for Dart 2.
Without dependent typing, it's the worst of all worlds anyway. You have to express types, but they aren't expressive enough to not have to also express the same in tests, leaving this weird place where you have to repeat yourself over and over.
That was an okay tradeoff for humans writing code as it enables things like the squiggly line as you type for basic mistakes, automatic refactoring, etc. But that stuff makes no difference to LLMs.
> you need to [use Git] to work with everyone else
Programmers use different operating systems, editors, languages - is there any reason we all have to use the same source control tool? We weren’t doing so before Git came along.
You could make that argument about HTTP, SMTP, Slack, or the English language. It turns out that yes, the actual concrete points of collaborative interaction do need to be standardised to a degree, unless you're thinking of everyone shouting into their particularly flavoured void, with no means of communicating. You can have different clients speaking the same protocol, but you can't have different protocols.
Even before git, you generally had to use what your team was using, or the FOSS project you were trying to contribute to. So it's kind of a moot point.
> OLEDs make great TVs and gaming monitors [...] But on desktop monitors for still things — text and fine lines — OLEDs currently just aren’t great
It seems that LCD has long been the best technology for desktop monitors - but interestingly, despite its popularity, may never have been the best technology for TVs. CRT, plasma and now OLED have all had better image quality than contemporary LCDs.
3 is also the product of the sets {3, 1}, {3, 1, 1}, etc.
We’re excluding the unit when defining these factor sets (ie, multiplicative identity) because it removes unique factorization.
That 1 is the unit is also why it’s the value for the product of the empty set because we want the product of a union of sets to match the product of a product of sets. But we don’t exclude it from the primes for that reason.
Mruby isn’t aimed at embedded systems, it’s “lightweight Ruby” intended to be embedded within a lower-level application. The language it’s most similar to is Lua.
My gut feeling comparing the two is that mRuby is a better (or at least less “quirky”) language, but Lua has a better (more robust) implementation. I don’t know how the two compare in terms of performance or “lightweight-ness”.
Lua definitely seems to be more widely-used, at least outside Japan.
I've used Ruby and Lua for about 15 years now, and looked at mruby (and possibly used it, I don't remember) about 10 years ago. Having little else to contribute to society anymore, perhaps my insight on these two languages might be of some use to some.
IIrc, Matz designed Ruby as a pet passion project, and its design was reactionary against excessiveness found in other languages, hence its minimalism in arguably excessive syntax and notation. Otoh, Tegcraf designed Lua out of pure necessity, adding only the features needed to satisfy its clients' needs.
In my opinion, necessity always leads to the better product than desire, hence C is still unbeat, having been formed under similar circumstances. Lua's C API is copied by nearly every other embeddable scripting language, including (I think) mruby. Yet they were the first to come up with it, a testament to their creativity under pressure.
Ruby (and mruby) takes the Smalltalk approach, and asks, what if everything was an object and every function call is a method call? Lua takes a less extreme approach, and merely asks, what if every data structure was built on a hashmap?
Other than that, Lua takes a very minimal approach, having break/goto but not continue, if/elseif but not switch, metamethods but not inheritance. It gets to 90% of the functionality of JavaScript with 10% of the spec and 1% of the code. You can read the entire Lua manual in one Saturday. You can read its grammar in under five minutes.
For all its cleverness, and as a price for its concise implementation and design, Lua is inconvenient to use. Hence the plethora of languages that compile to Lua and try to make it more convenient to use. One comes to mind but I can't remember or google the name successfully.
The MRuby embedding API isn't a whole lot like Lua's. Lua is a fantastic experience to embed. You might have to futz with the registry to store Lua objects in a C struct, but the abstraction allows you to almost never have to actually worry about the VM internals or the GC directly. Mruby is a lot more like MRI Ruby's API. Raw objects are exposed to you, you have to turn off strict aliasing because inheritance is implemented by the old "common meta struct as first member" idiom, you have to manually trigger VM collecting in long-running C code ( https://github.com/mruby/mruby/blob/master/doc/guides/gc-are... ), getting args in a C function involves a variadic scanf-style function. The most striking difference is documentation. The documentation of the mruby C API is actually "read the headers". There are many seemingly redundant functions that look like they do the same thing, completely without explanatory comments, or minimal inscrutable comments:
/* mrb_gc_protect() leaves the object in the arena */
MRB_API void mrb_gc_protect(mrb_state *mrb, mrb_value obj);
/* mrb_gc_register() keeps the object from GC. */
MRB_API void mrb_gc_register(mrb_state *mrb, mrb_value obj);
/* mrb_gc_unregister() removes the object from GC root. */
MRB_API void mrb_gc_unregister(mrb_state *mrb, mrb_value obj);
I'd rather work with Ruby as a language than Lua, but I'd much rather work with Lua than Mruby for the documentation and API alone. If mruby had anything close to the Lua reference documentation, I'd be all over it. As-is, embedding mruby kind of sucks, which is a real shame.
> you have to turn off strict aliasing because inheritance is implemented by the old "common meta struct as first member" idiom
You shouldn't have to turn off strict aliasing for that, struct pointers are allowed to alias pointers to their first member. Unless I'm missing some awkward compatibility rule that mruby breaks.
You do need to turn off strict aliasing for that, because mruby uses `struct RObject { RB_OBJECT_HEADER; ... }` and `struct RHash { MRB_OBJECT_HEADER; ... }` (where MRB_OBJECT_HEADER begins with `RClass `). You can alias objects of both types as an `RClass `, but you can't alias them as one-another, converting RHash to RObject. According to my reading of the strict aliasing rules[0], the aliasing would be legal if one of the types literally contained the other, or if they were being accessed through a union. The "compatible types"[0] section requires the types to be exactly the same in layout, not just starting as the same. It's not safe to cast incompatible structs to one another just because they have the same initial members, unless you are accessing them through a union (C11 6.5.2.3p6). Optimization can cause UB when working with mruby if strict aliasing is enabled.
Oof, I get it now. I was expecting RHash to start with an actual RObject, not just the same members. I too read the "compatible first member" rule as not applying here, so I agree it breaks strict aliasing.
Syntactically: From `~=` instead of `!=`, and no support for `+=` or `continue`, to free-form syntax with no statement separators - except in that one place where they're necessary.
Semantically: Conflation of arrays and maps, conflation of `nil` and empty (both in tables and in function arguments), and the perennially-unpopular 1-based indexing.
Agreed. Lua is older though. It was created in 1993.
mruby was created in 2012.
I have only two gripes with regard to mruby.
1) The primary users are C hackers. That's ok, but it means it also leaves out many other people. (Lua has the same problem of course.)
2) Documentation. This is something that really plagues about 90% of ruby projects. And it's not getting any better. It is as if in ruby, only 10% care about documentation - at best. Look at rack, opal, wasm for ruby - the documentation is TOTAL TRASH. Non-existing; look at rack. What a joke.
Now that ruby is following perl in its extinction path (sorry, the numbers are hard and real, there is no way to deny it), the ruby community should instead try to reverse that trend. Instead you see mega-corporations such as shopify pwning the remaining ecosystem and cannibalizing on it or people such as DHH rant about how Europe is collapsing (what the actual ... https://world.hey.com/dhh/europe-is-weak-and-delusional-but-... - we need an alternative to rails, how can anyone still work with DHH? Lo and behold, another shopify guy. The message is so clear for everyone to see now). None of this will of course revitalize ruby. Without an active AND actively growing community, ruby is set to die. I say this as someone who still uses ruby daily; I am tired of the "rumours of ruby dying are exaggerated". Yes, the rumours are exaggerated - but they are not rumours. The numbers are solid. TIOBE alone, with its 10000 faults, shows this trend clearly.
Hanami remains a bright spark as an alternative growing Ruby app framework to Rails. The project is under active development, I’ve met the core dev and they are lovely and much more humble than DHH and the project aims to stick much closer to the Ruby ways of doing things as opposed to the rails way.
Sure the project just can’t be as mature as Rails but it deserves a look and we need to get behind projects like this if we do indeed want to see Rails alternatives flourish and grow.
> 2) Documentation. This is something that really plagues about 90% of ruby projects. And it's not getting any better. It is as if in ruby, only 10% care about documentation - at best. Look at rack, opal, wasm for ruby - the documentation is TOTAL TRASH. Non-existing; look at rack. What a joke.
Are you familiar with the Ruby ecosystem?
You can easily view documentation for all installed gems using yard like so:
yard server --gems
or from the command line you can look up a class like so:
Yeah, I think the Ruby world burned out of the whole "make everything nice" aesthetic when they alienated the everloving fuck out of _why. Now it's a post-apocalyptic wasteland where if you want nice things, you better be prepared to become a right expert because you will have no one to turn to when it breaks. I don't mind, I don't make money coding anymore and the challenge makes me feel alive again.
If I ever get to the point to where I gotta learn the C API, I'll do it through mruby. But it'll be a much easier path to systems work to interop with Rust instead.
As others have mentioned, Crystal is close to Ruby in many ways, such that some simpler code will port straight over. I've managed to port a large Ruby application (the sup email client) to Crystal, and a lot of the code just worked, but I still had tweak just about everything else to get it to compile. The hardest bits were the places that used Ruby's dynamic nature, e.g., constructing method names at runtime and then calling them with send, or creating methods on the fly, or data structures that mixed up types freely.
Crystal's intent, as I see it, is very different from Ruby's. Because it compiles down to machine code in a single executable, it's good for making things that are fast and easy to deploy. I've used it to make small web services as well as the bigger thing I mentioned above.
Yes, Crystal is not a superset of Ruby with all of its behaviors and semantics. And thus, it is great if you are starting fresh and don't mind foregoing the Ruby gem ecosystem and the popular frameworks like Rails proper.
But it's not a migration path for Ruby codebases to add types, like the new initiatives for type annotations are. It's just that the syntax used by the available options has been somewhere between bad and downright terrifying until now.
It's different, but close enough to not matter a lot of the time. As in, some constructs are not allowed but they're extremely rare in practice and have simple workarounds, even if you don't preserve the exact same usage syntax.
So, you extremely rarely can run Ruby code in Crystal. But simple scripts are trivial to annotate. Larger apps won't require huge changes, but you're likely to run into dependencies you also need to port.
Semantics are quite different, but the stdlib APIs are similar enough that it really feels rubylike, unless you want to use some of that dynamism in ruby. The code ends up looking a lot more similar than c++ compared to JavaScript.
https://news.ycombinator.com/item?id=26998308
reply