831–840 of 993 posts
Is there a reason people don't choose Perl much anymore? It's a fine scripting language and supports the UNIX C API almost full stock. ^ Another Siracusaism, who's still - by his own admission - a Perlhead.
Earlier quoted context omitted.
> and multiprocessing is a dead end. Why is multiprocessing a dead end?
Huge overhead for process communication, weird interface, weird semantics, etc.
I wonder what the consequences of this are given Python's apparently very poor energy consumption profile: https://thenewstack.io/which-programming-languages-use-the-l... It appears to consume over 17x more power than JavaScript, 40x more power than Java or 75x more than C/Rust. The only language which performed worse than it in terms of pure power consumption was Perl. While I'm sure these results aren't exactly ind…
Earlier quoted context omitted.
It has nothing to do with static vs. dynamic. There's no reason that being an early-binding language that a string has to be iterable itself, and the proposal to change this was only rejected as it broke too many things[1] and couldn't be automatically fixed. Point in the GP's favor: Fixing it would definitely not be a problem with an early-binding language! In fact, the nigh-impossibility of automated refactoring pu…
What’s supposed to be the surprising thing? Are you confusing pass and break and expecting it to print 1?
Earlier quoted context omitted.
This is the top comment? Not very useful.
Sorry. I'm as surprise as you are. I figured I'd take a small hit the karma and I feel better about getting this off my chest. This comment is more highly rated than some links I've submitted that made it to the front page.
Holy Crap! What a lot of irrational, hyperbolic hate for Python. I think everybody should spend their first couple of years working in Fortran IV on IBM TSO/ISPF. No dependency management because you had to write everything yourself. Or maybe [edit: early 90's] C or C++ development where dependency management meant getting packages off a Usenet archive, uudecoding and compiling them yourself after tweaking the config…
I love python as a scratch pad for playing around with code, but I don’t think I would put anything into production written in it. It’s just too hard to debug and maintain and deploy once it gets to even a medium amount of complexity. Interactive python and Jupiter notebooks are an absolute joy to work with though.
Earlier quoted context omitted.
> Actually, if your type system is powerful enough, you don't need to test. That's the source of the "if it compiles, 99% of the time it works right" people mention about Haskell (and even more so languages like Idris etc). Types only eliminate certain tests. You will always have system tests, acceptance tests and unit tests. One should use types to augment their system reliability. Types will not catch logical error…
> Types only eliminate certain tests. You will always have system tests, acceptance tests and unit tests. Yes, so let's eliminate them with types, instead of doing them. "Acceptance tests" are not concerned with programming. > Types will not catch logical errors in your code. Actually, depending on the type system, it will. That's how program logic is tested as "proof" and programs, implementations of algorithms are…
If you have to point to something like Idris I don't think you're making a real world argument yet.
Earlier quoted context omitted.
And what exactly are Flask and Django missing to merit more packages doing the same thing? Routing requests and managing HTTP fundamentals is a solved problem. There is literally zero value in adding another framework when the real complexity is in business logic.
That’s the issue. These are routing requests and not much more. I recommend looking around at java, node, php, c# web frameworks for more details on what a web framework should do. Sqlalchemy and other hobby libs can extend flask and django but those are similarly limited.
Django does routing, forms, ORM, templates, APIs, GIS, you name it. Flask is more minimialist and expects third-party package for this.
Django also has a very extensive ecosystem of libraries for managing the common web use cases.
Earlier quoted context omitted.
"From JavaScript" also includes another side: When your frontend is in JS, your backend can be a simple REST API. And building a REST API requires much less framework than building a server-side-rendering webapp does, so it's tempting to use Go or Rust or whatever you like.
You’ll need (probably) at least: -Database connection -An ORM -Middleware against attacks / rate limiting -Caching -Jobs / workers -A rendering engine for email and maybe pdf -Some sort of admin/backend -Logging -Validation I’ve written an API once from scratch. Actually twice. First time in Modena, because it was all the hype, but it was arcane. Then Sinatra, where I ended up creating all of the above. Rails is exce…
Holy Crap! What a lot of irrational, hyperbolic hate for Python. I think everybody should spend their first couple of years working in Fortran IV on IBM TSO/ISPF. No dependency management because you had to write everything yourself. Or maybe [edit: early 90's] C or C++ development where dependency management meant getting packages off a Usenet archive, uudecoding and compiling them yourself after tweaking the config…
"It is a poor workman who blames his tools — the good man gets on with the job, given what he's got, and gets the best answer he can." —Richard W. Hamming[0] I have rarely "chosen" to use Python at work, but it has never failed to get the job done. [0] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2041981/
Not to say I have any real complaints about Python.