Hacker Newsnew | past | comments | ask | show | jobs | submit | setpatchaddress's commentslogin

The derogatory and inaccurate use of “monkey patch” to describe adding methods to an open class identifies you as a Python advocate, so grains of salt applied, but:

I can’t speak for this particular Rails usage, but one of the most powerful things you can do with Ruby is build domain-specific languages without modifying the language itself. *This is a core feature of Ruby.*

The criticism you’re making is one of the Rails DSL — there’s nothing in Ruby preventing you from instead writing account.desposit(Dollar.of(100)).

Put another way: This is like people criticizing RISC-V for not having multiplication in the core ISA — they don’t seem to grasp that RISC-V is an ISA construction set. Ruby is a language construction set.


"monkey patch" is frequently used by Rubyists without anny derogatory meaning.


True, but it was taken on by the ruby community as a badge of pride after being used as a slur by the aforementioned other community, IIRC.


I first heard the term in reference to how mootools messed with prototypes of JavaScript built-ins; at that time, I had no experience with either python or ruby.

Whatever context the term may have originated with, it far outgrew those origins. I definitely don't instinctively think of python programmers snubbing ruby when I hear the term.


I think it’s much simpler than that. Ruby didn’t have good documentation in English until the mid-2000’s. Python was in use by the English-speaking world before the turn of the century. Documentation + you can generally understand it at a glance == total Python dominance.

Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features.


> Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features.

My inkling is that this is because it is hard to have a general purpose language that lends itself to both novices and experts, and to small scale and large scale. Not impossible, but hard. Those categories desire/need different things, and will use the language in vastly different ways.

BASIC (for all its problems) was a better first language for many people than C or Fortran, but BASIC also didn't scale well to larger systems (structured variants scaling better). Then you start getting BASICs supporting OO and other features which complicate them and lose the appeal to novices, but more effectively meet the needs of intermediate-to-advanced users and maintainers of medium-to-large scale systems.

See also Pascal and its evolution. From a small language to a still small but not as small language in Delphi and others. For the novices, they can still use that small core. But it's now harder for them to onboard with a larger project or a project developed by more advanced users of the language. Especially as the standard library (for the language implementation, if not the language proper) grows.

Scheme, over the various revisions, has seen a similar conflict, culminating in the effective rejection of R6RS and the division into small and large for R7RS.

And those are languages that were largely meant to support novices and learners. Python started off similarly. Now it's older, and its users have aged, and they want to do more powerful things with it and maintain larger and larger systems with it.

On the small vs large side, look at the evolution of JavaScript. It was literally meant for in-page scripting, to do small things and not be the larger system, but a mere component. Like a shell script that copies two files contrasted with the actual OS or shell implementation. But now 25 years or so later it's a vastly different language, and people are building distributed systems on top of it.


You could create nice GUI programs with Delphi with just basic Pascal knowledge, you didn't even have to know about pointers, initializers, virtual functions, templates or any of the crap that comes with C++.


My point with it, though, is that even though you could still use that straight-Pascal core, the language (Delphi) permits more. Which, I presume, many if not most advanced users and large system maintainers took advantage of (my time with it was brief, and I did only use/learn the core Pascal parts).

Python is the same way, there is still (and always has been) a core that is particularly well-suited for novices and a slightly larger core that is sufficient for any small-to-medium system. But as you gain expertise and want to use the language to do other things, or to develop larger systems, you will likely exceed that core. Delphi with Object Pascal was similar. You could still use that core, and accomplish a lot (same with Python), but you cannot guarantee experts or larger systems won't exceed that core.

And that's the language dilemma: How to appeal to both novices and experts, small and large system maintainers? The features that each will want or need are different. Go stayed pretty stable for a decade and kept to its mostly small core, but even it has added generics now because people (maintaining larger libraries, in particular) are chafing under its present constraints. And with these changes, you'll see a (potential, may not happen I suppose but I'd be surprised) major shift in the way the language is used by more expert users that pull it away from its previous model.


> Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features.

this has been true for a while, the 'zen of python' was lost a long time ago.

i think this is partially because of how much commercial popularity it has, and all the different types of things people need to do with python.


> you can generally understand it at a glance

You're probably right about the availability of documentation, but I also think Python is much easier to generally understand at a glance. Less features, less quirks means the language is easier to learn.


Dissenting voice here. I did not like the book. It's dark and unpleasant and contra other people here I don't think it speaks to any particularly interesting truths about how supposedly smart kids can be misled.

edited to add: I arrived at this opinion when I first read the book sometime in the early 90's, which I think is decades before the author's bigotry became public.


I read the author's Homecoming series in the 90's. That doesn't outright show his bigotry but my lord, it hints heavily towards it.


> In my experience people complain about Obj-C syntax when what they actually dislike are verbose Cocoa/Foundation/etc APIs

If so, that’s a real shame. Foundation may be the single best-designed standard library for a (non-functional) language ever.


I agree, Foundation is a gem! The method naming is one of the assets - the names are clear, regular, and usually fairly obvious. The downside to that regularity and clarity is that the names are long.

One CoreFoundation example at random:

    CFURLRef CFURLCreateCopyDeletingLastPathComponent(CFAllocatorRef allocator, CFURLRef ref);
I think nearly everyone who reads that prototype will immediately understand what it does, but there's no denying it's a mouthful.

Tack on some unfamilar square-brackets and intersperse argument names, and it's understandable that people will conflate the syntax with the APIs.


For me Foundation lacks composability. This method should be really two: CreateCopy (I assume it already exist) and mutating DeleteLastPathComponent.

I don't mention immutable by default behavior because it was long ago and written in C.


CoreFoundation is not written in ObjC, it's C only (although toll-free bridged).


It’s really unfortunate that Apple’s blown gaming so badly. I built a mid-high range gaming PC during the first year of the pandemic. The awful software that PC gamers have to put up with, from the basic stuff like NVidia’s driver software updates that they seem to want to be a social network to the ASUS labyrinth of random apps + UI just to update various bits of motherboard support where it’s not clear what you actually need and what’s actually cosmetic to the MSI daemons to support RGB lights on RAM modules that cause some games to crash at launch Just Because.

Windows gaming is a real shitshow. But that’s where the games are. You can avoid running most of this crap. But you wouldn’t have to put up with it in the first place on the Mac, because there’s an assumed baseline of non-scummy software and vendors would get called out and shunned.


Note that the precipitating event was Wallace’s Fox contract coming to an end. This wasn’t ideological ragequit.

But this probably is a consequence of Fox having gone full Trumpy/facist (see: Tucker Carlson) and CNN willing to buy names for their new streaming service, which I think they correctly view as the future of live news (if there is a future outside of TikTok or TikTok-alikes).


It’s reasonable for people with center-right, centrist, or left-leaning politics to distrust Fox affiliates. Some of them are in fact still owned by the same company as Fox News.

TV network affiliates can be either independently owned or owned & operated by the network. Disney did not acquire either the Fox TV network or the Fox TV O&O stations in the recent Fox studio sale to Disney, likely because Disney already owns the ABC TV network and strategic ABC affiliates.


Not familiar with Raku, but that grep call seems like it would be quite a bit slower than the Ruby equivalent at runtime if it’s anything like a normal grep. Is there some magic there that would make that not so?

Edit: clarity


“grep” is how raku spells what is elsewhere called “filter” or “where”.


Note how much more concise and yet readable the equivalent Ruby is.


If you want to play code golf you can do static imports and write this:

    int numberOfAuthors = arr.stream().map(getAuthor).distinct().collect(counting());
You still save a few parentheses and one method call in Ruby (.compact vs .stream() and .collect()) and the method names are shorter. Mostly it's a matter of static vs dynamic typing and naming conventions, not a consequence of Ruby code blocks. And is it worth shortening at this point?

BTW I know uniq is a thing in unix, but I hate this naming decision.


> There were analog HDTV standards before we all moved to digital

8-bit computers likely wouldn't be able to keep up with the bandwidth requirements of those systems either.


Not the original 6510, but there are some very fast 8-bit processors out there. If you compress the color space, they may be able to flip every pixel 30 times per second.

Also, nothing stops you from implementing an 8-bit CPU with a modern process and push it into the multi gigahertz range except perhaps the fact it’ll be too small for current machinery to manipulate.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: