Web Development Framework Question

uncannymanny · Mar 23, 2015

Try Django. Sets you up with a minimal but nice admin that is easily customizable and allows you to use a myriad of front end template frameworks. Also Python is awesome.

rembrat · Mar 23, 2015

The best PHP framework, IMO, at the moment is Laravel 5 or Laravel 4.2 if you haven't migrated to the latest release. It has everything you would want from restful routing, auth, session messages, caching, events, validation, templating, you name it. It uses Eloquent ORM for your database work but you can swap it out if you prefer Doctrine. I haven't used it in an actual project yet because our clients fucking suck but every time I've played around with it on my free time I've had such a blast tinkering with it. And I know you're thinking PHP is a nightmare but the code you write in Laravel is expressive and downright beautiful.

Only downside I can think of is there arent a wealth of plug and play plugins available so you'll have to create your own implementation of say a dashboard but Laravel makes that easy. And considering the framework is bleeding edge you'll need to meet a bit more server requirements than say a Wordpress.

EDIT: And I didn't even mention development time is cut down drastically because Artisan will generate just about anything you ask it to and migrate your database and seed it as well. And it's customizable to run your jobs via the CLI. Really fun stuff.

Blacken · Mar 23, 2015

The two Big Ones for server-side, non-enterprise application development remain, I think, Django and Rails. I'd say that Rails is a better go-to, partly because ASP.NET MVC is more or less Rails with the serial numbers filed off but also because Python feels to me to be interminably sluggish and boring, but Django isn't a terrible call. I would say it's the only major web framework that isn't trying to be spiritual kin to Rails, which is why it may be worth a look--it's a different mindset.

Laravel is an okay two-year-old-Rails knockoff in an inferior language on a vastly inferior toolchain--I nearly spit out my coffee at the idea that any part of its existence is "bleeding edge"--and that a PHP stan has to hype Artisan as a thing when Rails (and everything else, but Rails mostly) has done generation and migration for literally a decade is, to me, telling.

Don't use Wordpress, whatever you do. As a blog engine it's tolerable. Not much else.

rembrat · Mar 23, 2015

Oh, Blacken, <3.

A few things:

- I don't do Rails or Python so I can't talk about it. I do, however, work with PHP and JavaScript, however smelly and gross that may be to you, it's no longer 1995, and it's no longer "cool" to throw shade at these two guys. So come off it. I mentioned Laravel, which IS the best PHP framework, because it is what I know.

- I merely meant to imply that you can't take a Laravel app and throw it onto a GoDaddy server and expect it to work.

And, honestly, who gives a shit what community did what first. Fuck, dude, your kind really sucks.

HillysLastWalk · Mar 23, 2015

Why not use Visual WebGUI. Especially now that's it is free?: http://visualwebgui.com/

In fact, I think it's perfect for what you are trying to accomplish, especially since you need to do it fast and you say you are 'stale' on the latest advancements.

Here's what it boils down to: You get to open a Visual Studio Visual Web GUI project and code it (with some gotchas you have to worry about, like MessageBox's aren't Modal - but there are ways to work around that) as if you were making a VB6 application.

Do you want to design a screen that the User sees? Why not drag-and-drop controls to a "Form", compile it, and have VWG take care of all the tech for you. They handle all the JQuery/Javascript/CSS/whatever. You just deploy your DLL's to IIS and you are done. It's event based programming with C# (or VB if you choose) brought to the web. So easy and without a lot of the web headaches.

So you can fuck around for days, no weeks, continually fighting this battle to figure out all the latest tech, and getting it to work, and potentially to work on more than one browser (including Mobile) -- or you can drag-and-drop shit, not have to worry about it, and quickly and faster then these guys with their frameworks put business logic into code - so you can actually have something that works. Someone with experience could prototype you a log-in screen to an application front page, that works, in like an hour or two. Try that with those other frameworks! You, just from articles in their Wiki, could get it done in less than a day. Yes, just a simple prototype, but it goes to show you how quickly the pages will fly.

Plus, if you really need to customize stuff, and get your hands deep into the underlying tech, you can. But it's really not that often that you need to do something like that.

Blacken · Mar 23, 2015

rembrat said:
- I don't do Rails or Python so I can't talk about it. I do, however, work with PHP and JavaScript, however smelly and gross that may be to you, it's no longer 1995, and it's no longer "cool" to throw shade at these two guys. So come off it. I mentioned Laravel, which IS the best PHP framework, because it is what I know.

Perhaps you should endeavor to know better things.

And, honestly, who gives a shit what community did what first. Fuck, dude, your kind really sucks.

If it weren't for where innovation and, frankly, generally better software is made, nobody would care who did something first. But that's not the point; Ruby (in terms of tooling) and Rails (in terms of web applications) have iterated upon the concepts and tooling that they largely pioneered much faster than anyone else, and it shows. Mind you; I don't use Rails. When I do web, I use Scala and Play. But I would not recommend it to other people, because I have the perspective to understand that its upsides to me (a strong type system, a comprehensible threading model, an easy route to massive scale) don't apply to most people. Rails's do.

If the OP is going to use a knockoff of Rails that's years out of date, he already knows ASP.NET, and vNext/MVC 5 runs on Linux with either Mono or CoreCLR. So why PHP? Why PHP, ever, but why PHP here? PHP and Laravel have scant few upsides, except "well, I might already know PHP and learning is hard." It is a middling reimplementation on top of a bad stdlib and bad tools, and the whole rotten mess are amplified by the worse-is-better community (congratulations, you have a better community than Go! wait...) and the borderline-incompetent core team that's so bad that Facebook built HHVM just to avoid the whole lot of them.

I don't have a "kind" when it comes to this, unless you can find somebody who works daily in Ruby, Scala, and C# who happens to do large-scale web infrastructure. I do, however, have a very long history of PHP (I was maintaining a patch set on PHP 5.4 not too long ago) and nothing breeds contempt like knowing something cold.

PHP is cancer. I'm sorry you wub it so and that you haven't managed to branch out into something with a little less open hate for its users, but recommending its spread is gross.

Blacken · Mar 23, 2015

HillysLastWalk said:
Why not use Visual WebGUI. Especially now that's it is free?: http://visualwebgui.com/

We have some WebGUI LOB apps lying around. I would caution that WebGUI provides a very limited sort of tooling, and getting out of the "sort of OWA five years ago" look-and-feel is, by the accounts of folks I know who've done these projects, a difficult task (and the stock L&F lends itself to teeth-grinding workflows). For internal LOB stuff I can see an argument for it, but it sounds like he's talking about serving customers, not coworkers. There are probably customer pools that are quality-inelastic, and so I'm sure there exist markets where it'd make sense, but when you put a WebGUI thing next to something Ember/Angular/etc. there's a game of "one of these things is not like the other" to play and WebGUI does not win.

It's always struck me as more of a prototyping tool than a finished-work tool. Whether that makes sense or not is, obviously, up to the OP, but I wouldn't go there.

rembrat · Mar 23, 2015

Your a snob and I'll learn something "better" when I'm paid to learn it.

SumnerH · Mar 23, 2015

+1 on Django or Rails. Working in either Python or Ruby is a whole lot nicer than C# (there is no way I'd recommend learning PHP now unless there's a job on the table). I'm on the flip side from Blacken--I find Python more conducive to well-written, readable, maintainable code than Ruby, whereas Ruby feels a little more dated/Perl-y, but it's relatively close. They're both really nice languages, it probably comes down more to the framework differences. Django tends to be a little slower to adopt new features,

Rails is more bleeding edge--that has pluses and minuses. Django went for a comparitively long time without built-in migrations--there were several competing 3rd party options, and eventually one was selected as the official one (with some tweaks). That competition ultimately resulted in a somewhat more intuitive and better-thought-out solution than Rails migrations, IMO, but the cost was a few years of manual migrations or nonstandard/third party stuff. That's typical (not universal, but common)--Rails gets stuff first by more of a fiat implementation, Django lets the market shake things out for a while and is slower to arrive at an official solution.

Most of the outright feature differences are small, it's more a question of which style you prefer. Rails' asset pipeline is nice and there's nothing similar in core Django. Django's form validation is a little slicker than Ruby's. Ruby's fixtures/unit testing is much slicker. Django's internationalization/translation support is a lot nicer. Django has integrated user authentication, Ruby requires a 3rd party package--but devise (on of those 3rd party packages) is well-maintained, easy to install, and almost a de facto normal solution for typical Rails cases.

uncannymanny · Mar 23, 2015

rembrat said:
Your a snob and I'll learn something "better" when I'm paid to learn it.

You should try learning them. Development is one of the few careers where you can learn something on your own and almost immediately get paid to use it. My only regret is not having enough time to learn all of the things I want to.

SumnerH said:
+1 on Django or Rails. Working in either Python or Ruby is a whole lot nicer than C# (there is no way I'd recommend learning PHP now unless there's a job on the table). I'm on the flip side from Blacken--I find Python more conducive to well-written, readable, maintainable code than Ruby, whereas Ruby feels a little more dated/Perl-y, but it's relatively close. They're both really nice languages, it probably comes down more to the framework differences. Django tends to be a little slower to adopt new features,

Rails is more bleeding edge--that has pluses and minuses. Django went for a comparitively long time without built-in migrations--there were several competing 3rd party options, and eventually one was selected as the official one (with some tweaks). That competition ultimately resulted in a somewhat more intuitive and better-thought-out solution than Rails migrations, IMO, but the cost was a few years of manual migrations or nonstandard/third party stuff. That's typical (not universal, but common)--Rails gets stuff first by more of a fiat implementation, Django lets the market shake things out for a while and is slower to arrive at an official solution.

Most of the outright feature differences are small, it's more a question of which style you prefer. Rails' asset pipeline is nice and there's nothing similar in core Django. Django's form validation is a little slicker than Ruby's. Ruby's fixtures/unit testing is much slicker. Django's internationalization/translation support is a lot nicer. Django has integrated user authentication, Ruby requires a 3rd party package--but devise (on of those 3rd party packages) is well-maintained, easy to install, and almost a de facto normal solution for typical Rails cases.

Very good breakdown. I might steal and minify this for clients.

HillysLastWalk · Mar 23, 2015

Blacken said:
We have some WebGUI LOB apps lying around. I would caution that WebGUI provides a very limited sort of tooling, and getting out of the "sort of OWA five years ago" look-and-feel is, by the accounts of folks I know who've done these projects, a difficult task (and the stock L&F lends itself to teeth-grinding workflows). For internal LOB stuff I can see an argument for it, but it sounds like he's talking about serving customers, not coworkers. There are probably customer pools that are quality-inelastic, and so I'm sure there exist markets where it'd make sense, but when you put a WebGUI thing next to something Ember/Angular/etc. there's a game of "one of these things is not like the other" to play and WebGUI does not win.

It's always struck me as more of a prototyping tool than a finished-work tool. Whether that makes sense or not is, obviously, up to the OP, but I wouldn't go there.

So does this boil down to the Look and Feel? And that's it?

So why is it that Visual Web GUI can't have a more modern feel? I think it can.

I also think that VWG is used for customers, and not just coworkers. When was the last time you actually used it?

I'm not saying any of this to be facetious, I'm generally curious. As again, I have a feeling that this is the best thing for this guy, and I think you are providing a very simplistic view to my simplistic view!

Sometimes I think more people are turned off from VWG not because of the tech, but because they can't put "ruby on rails" or "django" on their resume. A programmer has to keep his skills up! And go through the headache of getting butt-fucked by web tech!! ... for it to be worth it. But that's just my view from being around programmers for a decade plus - you know the same guys that job hop every couple of years for the sole reason of keeping their resume fresh.

In conclusion: this guy will be banging out apps quickly with VWG. So he's going to be swayed because the Look and Field that he's looking for can't be achieved? Do we know that? Or is that just guessing?

HillysLastWalk · Mar 23, 2015

locknload said:
You are correct in that there needs to be a fine polished level of the finished project that will be in front of actual customers.

And VWG is stopping you from this, how?

ethangl · Mar 23, 2015

locknload said:
just worried I'm going to head down a path and they kick myself later due to limitations of what I pick or realized I overlooked something new I wasn't aware of.

Not to be glib but this doesn't sound like the kind of project where you have to worry about that -- Rails, Django, Laravel, etc, would all be fine... there will be decent arguments for all of them, and the worst thing to do is debate it and not get started, so I would just pick one (Rails), budget half a day, and see how you like working with it.

Blacken -- what do you think about Meteor?

uncannymanny · Mar 23, 2015

:huh:

crystalline · Mar 23, 2015

Blacken said:
Why PHP, ever, but why PHP here? PHP and Laravel have scant few upsides, except "well, I might already know PHP and learning is hard." It is a middling reimplementation on top of a bad stdlib and bad tools, and the whole rotten mess are amplified by the worse-is-better community (congratulations, you have a better community than Go! wait...) and the borderline-incompetent core team that's so bad that Facebook built HHVM just to avoid the whole lot of them.

Wow. That was a serious hate, Mr. Orwell.

Since you mentioned Go- what do you think its future is? I don't know very much about recent innovations in concurrency, but it feels like that's going to be a big deal in the future.

I have done basic parallel work with Python and it's a mess. PyCloud seemed like they would drive forth a new Python paradigm but then they got acquired and dropped out of sight. Other things (Spark) seem too heavyweight. Interested to get an informed take.

Please don't hurt me, though.

SumnerH · Mar 23, 2015

crystalline said:
Wow. That was a serious hate, Mr. Orwell.

Since you mentioned Go- what do you think its future is? I don't know very much about recent innovations in concurrency, but it feels like that's going to be a big deal in the future.

I have done basic parallel work with Python and it's a mess. PyCloud seemed like they would drive forth a new Python paradigm but then they got acquired and dropped out of sight. Other things (Spark) seem too heavyweight. Interested to get an informed take.

Please don't hurt me, though.

I don't do my back-end work in Python or Ruby (not that this sort of web site needs a parallel back-end--this looks like a pretty simple web app that'll be database and network bound, and can be reasonably written in Django or Rails entirely without complicating things with unnecessary parallel programming or whatever).

The idea that your entire stack should always be written in one language is classic "all I have is a hammer" myopia--most people are already using heavily optimized C code in the form of a SQL database or key-value store, they just don't think about it because it's written by someone else. It's not at all unusual for me to drop down another language for certain pieces of the site or integrating needed libraries or whatever. Right tool for the job and all.

crystalline · Mar 23, 2015

Yes, I was hijacking the thread a bit. (Sorry!). My perspective is that I do a reasonable amount of compute-bound work that would benefit from concurrency. The stuff starts in Python but doesn't have to be there. The key question is: how do you _easily_ manage concurrency, including minimal code to set up, good error handling, and debugging? Python fails on all three. Go seems from the outside like they have solved this. Will this come to other languages? Are other languages going to supplant others because of this feature, or is it just not a big deal in the wider world?

Blacken · Mar 23, 2015

rembrat said:
Your a snob and I'll learn something "better" when I'm paid to learn it.

I'm not a snob, I'm being better educated and more experienced than you are and I dare to express opinions borne of that education and experience that hurt your feels.

Waiting for other people to pay you to do the barest minimum (if that) to keep out of the category of "can be replaced by a Romanian with a passing education" is adorable, though.

crystalline said:
Wow. That was a serious hate, Mr. Orwell.

You can't truly hate something without knowing it, you know?

Since you mentioned Go- what do you think its future is?

Okay, so...Go has problems. They aren't technical--it is technically uninteresting, it's a statically linked Java 1.4 with a spotty stdlib--but rather cultural.

The culture of Go comes from Rob Pike and the Plan 9 debacle, where a few very smart people spent thirty years blissfully ignorant of everyone else's advances in technology. Keith Wesolowski had a good article about this that I agree with more or less in its entirety. Golang's core team thought Go would appeal to C++ developers when they released it. I do not know a single C++ developer who takes it seriously, because it addresses problems that modern C++ developers have already addressed, better. Instead they picked up a bunch of people who left Node, Ruby, and Python; both groups (though predominantly Node and Ruby Python's gone through the growing-up process already) historically are populated with lots of loud neophiles and when they had something new to hump and it had Google's name on it (see also: Angular), they went for it. Given the dominance of this audience, I found in my travels there that there is not a lot of low-level technical expertise in the community. That leads to a lot of puffery about how "oh, X makes it better than Y" (where Y is almost invariably the JVM) based on ill-conceived notions that are rarely congruent with how systems actually work. "Go is better because Go is better" is ostriching bullshit. To this end, I think the future of Go is kind of "it will fall off as soon as the New New Hotness comes out."

(Aside: while I will shit on PHP 'till the cows come home the community has a few smart people, among them Fabien Potencier, who somehow persist through the slop of the people they're building tools for; I hold them in high regard. I think they're making a mistake and throwing good money after bad, because the underlying system that rembrat humps so furiously is broken, but maybe, a decade from now, they'll prove me wrong.)

For some positivity: Rust, on the other hand, is super-promising, being built by and for adults who know software is almost useless if it isn't secure, and I have the highest respect for that entire team. They're kind of "Ruby: The Good Parts" in a lot of ways, and I'm excited to see what they do.

The key question is: how do you _easily_ manage concurrency, including minimal code to set up, good error handling, and debugging?

One thing: Go is emphatically not good for error handling. "Return an (err, result) tuple from every method call and force manual checking" is atrocious compared to something like Scala, where you can use the Try monad (and that word has a terrible rep because of a bunch of Haskell jerks, even that article is a little gross because it starts off with type theory stuff you probably don't care about, but monads are honestly super easy) to easily and fluidly chain operations while collating, handling, and recovering from errors.

Go's concurrency handling is pretty minimal; "Goroutines" are not some new thing in Go, they're just green threads (which are not concurrent, though with some manual threadpools and other crap you can parallelize them). For single-system parallelization, you seem to be pretty much describing problems that I find to be best solved with something like Akka (Scala) or Cellulose (Ruby)--shared-nothing, actor-model gizmos that can be thrown on an arbitrary runtime substrate to Do Their Stuff. Personally I think the syntax and semantics of both Akka and Cellulose are dog-simple, I don't think Go's focus on it helps there (and could even hurt, though that's just a hunch).

For multi-machine, I think Spark is a much more promising solution (Akka supports it but clustering that is wacky). It's not perfect. Setting stuff up kind of sucks (and while Zookeeper has a thoroughly undeserved rep for being "hard", it is hard to set up correctly--unless you use Netflix's Exhibitor, then it's easy). But it's a fast, fault-tolerant solution for either batch or streaming, it forces you to write fairly good code to use it, and I find it very easy to debug.

Everybody is really just reimplementing Erlang with these things, so that's an option too. Elixir runs on the Erlang VM and is, to hear it told, really nice; I've never used it.

SumnerH · Mar 23, 2015

crystalline said:
Yes, I was hijacking the thread a bit. (Sorry!). My perspective is that I do a reasonable amount of compute-bound work that would benefit from concurrency. The stuff starts in Python but doesn't have to be there. The key question is: how do you _easily_ manage concurrency, including minimal code to set up, good error handling, and debugging? Python fails on all three. Go seems from the outside like they have solved this. Will this come to other languages? Are other languages going to supplant others because of this feature, or is it just not a big deal in the wider world?

I haven't written anything more than toy programs in Go. Its support for multithreading with goroutines/channels/select seems fairly elegant for a relatively explicit multithreading model, though if you're going to hide the details I think I prefer an actor model approach a la Erlang/Scala over a more coroutineish one, but like I said my experience with Go is extremely limited.

I've written a video editing package in python that handles simultaneous decoding of multiple videos and other things, albeit with a lot of work farmed out to other languages where it makes sense. Python's actually not bad for a large class of concurrent programming, because it's more OS-agnostic than OS-independent--that it makes it easy to get at OS-specific mechanisms for handling interprocess communication and locking, instead of hiding behind some language-builtin threading abstraction and making multi-processing difficult (Java, I'm looking in your direction).

I'm a big believer in multiple processes rather than threads for concurrency in the vast majority of cases--threads have a time and place, but being explicit about what you're sharing usually forces rational design that's easier to think about and more maintainable in the long run. And OS engineers spent a ton of effort implementing memory protection; throwing that out just to avoid allocating a SHM segment seems counterproductive. There are certainly some limited times when threads make sense, but they're wildly overused (in large part because of Windows-specific implementation details and because a few stupid platforms like Java insisted on threads as the only easily accessible option for a long time).

The decision to choose processes vs. threads should be driven by the question: do I really want to share all my memory, or do I want memory protection between contexts of execution with a few segments of data explicitly shared? That at its core is the actual difference between threads and processes.

To take the case of the video editing package, it's not unusual for newer video codecs--especially proprietary ones--to have subtle bugs that cause segfaults or memory corruption; by keeping each video decoder in its own process, you could recover from such things without crashing the whole editor, and do better error handling in terms of restarting or failing on limited areas of data instead of crashing the whole editor. Those decoder processes might be multithreaded or multiprocessed themselves, as well. For a more ubiquitous example, see Google Chrome which runs tabs in separate processes so that there's security isolation and so that a bug that gets tickled in one will crash just that tab instead of torpedoing the whole browser.

Now, Python certainly sucks for in-Python threading. Often you're farming things out to native-code libraries that release the GIL, so it's not an issue--but for some programs it's a legit problem.

SumnerH · Mar 23, 2015

Blacken said:
Go's concurrency handling is pretty minimal; "Goroutines" are not some new thing in Go, they're just green threads (which are not concurrent, though with some manual threadpools and other crap you can parallelize them).

I thought goroutines were multiplexed across OS threads, but googling says that's only to prevent blocking I/O. If that's true and my google fu isn't leading me astray, that's pretty lame.

Blacken · Mar 23, 2015

Ehh. Disagreeing with SumnerH is a fraught endeavor, but I'll go there. There are lots of places where multi-process make a ton of sense--compositional, command-line-based stuff is my jam, and I write a lot of that stuff in a very modular manner. From both a practical and a theoretical perspective, I think composition at the process level falls down with modern web stuff and heavily transactional (i.e., non-stream-based) stuff, which is what most of the web is. Video stuff makes a lot of sense to decompose, request handling doesn't. I use queues and the like for offloading background jobs, and there I'd agree there's a place for process segmentation, but for the handling of an actual request? Keep it in-process so you can more easily trace the entirety of it in a debugger. And resource sharing becomes an issue--using a single thread to both compute and serve requests is why (most) Ruby and Python web apps make nginx nearly a requirement whereas Java doesn't have that problem (yeah, Twisted or EventMachine, but then you have to write very non-idiomatic code and that's a drag--or worse, use Node).

And while Chrome's process sandboxing for tabs is great, in theory, in practice it is still not particularly safe (Chrome will crash quite regularly for some users in some situations) and does bring with it some consequences in terms of the way V8 works that increases resource utilization--particularly CPU usage--to a degree that makes my laptop a campfire on my groinal region.

Blacken · Mar 23, 2015

SumnerH said:
I thought goroutines were multiplexed across OS threads, but googling says that's only to prevent blocking I/O. If that's true and my google fu isn't leading me astray, that's pretty lame.

There is a way to add more OS threads on which they can run, but I believe that's a there-be-dragons thing.

HriniakPosterChild · Mar 23, 2015

uncannymanny said:
Also Python is awesome.

Blacken · Mar 23, 2015

Eh. Pry alone makes Ruby fly a bunch better, IME. (IPython has some of the features of pry-rescue and pry-byebug, but it's clunky and harder to use.)

crystalline · Mar 23, 2015

Blacken said:
I use queues and the like for offloading background jobs, and there I'd agree there's a place for process segmentation, but for the handling of an actual request? Keep it in-process so you can more easily trace the entirety of it in a debugger.

So this is the key point for me. I do a lot of big data/big compute stuff. I am entirely with Sumner that multi-process parallelization is where I want to be. I'd further say that you'd like to be there too. The problem is our debugging tools work better in-process. If we had good multiprocess debuggers (and error handling), multi-process has the big advantage of easily transferring to multi machines. And almost everything that people invest money in has to scale to many machines.

Let me talk a bit about why python's multi process support stinks from my perspective. (I don't have deep knowledge about Go, Scala, Erlang etc.)
Problems:
- You can't serialize all code objects, so you can't use functions as first class multiprocess objects. I end up having to copy files to remote machines. Not ideal, but workable. PyCloud was solving this before they disappeared into Facebook.
- Poor multiprocess error handling / debugging. In theory you want exceptions to propagate back to the controlling process. In practice this doesn't work. In the past you couldn't even easily get stdout/stderr from remotes. IPython parallel has been solving this, but they're too heavyweight, not secure, and it's basically one guy who is great, but they dont have a team to fix their tough problems, like inability to interrupt remote processes.
Forget debugging. And if you can't debug, almost all of Python's (or any high level glue language) advantages go away for me.

I've mostly given up hoping for good ways to do multiprocess work in Python. I too use threads for debugging ease at times.
I could go on a longer story about why I think Python isn't the future for data work despite the huge community around it now. But I won't unless you're interested.

One more comment on PHP - it could be worse. At least Perl is largely dead.

(Maybe this should be broken out)

Blacken · Mar 24, 2015

No, I don't particularly want to use multi-process systems; I've thought about this quite a bit and have not come to that conclusion hastily. I am unworried about the statistical possibility of process failure, minimizing its main value prop, and most environments exacerbate the downsides of multi-process. Resource utilization gets bad--COW, for example, doesn't work in environments with compacting garbage collectors (which is a serious memory-duplication issue) so preforking isn't a magic bullet. There are just straight-up places where "the Unix way" eats a big mouthful of dirt, and I think, for the majority of web and transactional stuff, this is one.

I don't fault the debugging tools for not being good at multi-process debugging. The problem is intractable. Going stepwise in a multiprocess environment essentially throws timing and concurrency out the window in such a way as to make the results useless, at least for my purposes. It's not a useful mode of tooling for me. (Debugging inside a single process is less of a problem because you're designing with express interlocking in mind; you can much more easily treat it as a discrete simulation and attack the problem that way. Distributed systems must be designed with RPC in mind; I have yet to hear a compelling argument to do so for a single logical service that will be a single atom of a microservice environment, and the problems I encounter are ones of horizontal, not vertical, scaling. Hence, no real benefit to multi-process.)

As far as the problems you describe, I believe that DCell does code migration, but I haven't looked closely as it's not a problem I seek to solve and I wouldn't try to solve it in Python anyway.

Blacken · Mar 24, 2015

And, y'know--I would rather pick Perl over PHP literally any day of the week. Perl is inferior Ruby, but PHP is a bad, slow Java, and an inferior Ruby's a lot better for almost anything I can think of than a bad, slow Java. ("Slow" being an important bit there--speed is a feature, and I do sometimes use Java over Scala because I know javac's behaviors and the JMM well enough to find it predictable and controllable in ways that Scala often isn't.)

Honestly, and I say this with the very specific caveat that I'd never try to write anything large in it, I think Perl gets an unjustified bad rap because it enables programmers to disappear up their own assholes. It's not alone in this; almost every language I use on a regular basis (Scala, Ruby, JavaScript, C++) enables a user to do this. But it's a choice to do so or not, and having that choice available means that I can do some very powerful things very easily and then hide it behind a sane facade. Building DSLs in Ruby or Scala is much the same--if you look at the code of a powerful and full-featured Ruby DSL you may literally shit yourself blind, but you never have to look.

But then, my C# game engine (C# isn't one of the above languages, but I am determined) heavily leverages reflection and runtime compilation, so this is kind of a natural mode of thinking for me anyway.

Blacken · Mar 24, 2015

IDEs are more of a wart than a help in dynamic programming languages. I'd just start with whatever text editor you're comfortable with. (When I write Python, it's all in Sublime Text.)

rembrat · Mar 24, 2015

How on earth do you remember long vendor packages or long namespaced classes without an IDE? Or do the language you write in not have this issue? Is my PHP showing?

rembrat · Mar 24, 2015

locknload said:
So looking into a few options last night decided to throw myself into Django with Bootstrap for the styling today and get some sample stuff written. Any python enthusiasts have an IDE of choice? Probably going to start with JetBrain as I can't stand Eclipse.

Jetbrain seems to be the standard at the moment. I love their PHPStorm8. Sublime Text and Atom are cool for fast little projects but I see no reason not to use an IDE especially if you're building a large scale app.

Blacken · Mar 24, 2015

rembrat said:
How on earth do you remember long vendor packages or long namespaced classes without an IDE? Or do the language you write in not have this issue? Is my PHP showing?

Namespaces in Ruby or Python are generally fairly flat.

The amount of state I keep in my head at any time when working with any of these is so small that a text editor is fine. (I would argue that there is an element of you're-doing-it-wrong if a system is insufficiently encapsulated so you can't do that. I write Scala and C# in ST3 without too much trouble, too, though I'll use IDEA and Visual Studio because of the better debugging tools.)

crystalline · Mar 24, 2015

locknload said:
So looking into a few options last night decided to throw myself into Django with Bootstrap for the styling today and get some sample stuff written. Any python enthusiasts have an IDE of choice? Probably going to start with JetBrain as I can't stand Eclipse.

IDEs are another big discussion.

I also use a text editor for Python. If you're a beginner, have a terminal window open with a recent IPython. Use %pdoc, %psource, ??<function>, and dir(object) a lot.

Blacken said:
Namespaces in Ruby or Python are generally fairly flat.

The amount of state I keep in my head at any time when working with any of these is so small that a text editor is fine. (I would argue that there is an element of you're-doing-it-wrong if a system is insufficiently encapsulated so you can't do that. I write Scala and C# in ST3 without too much trouble, too, though I'll use IDEA and Visual Studio because of the better debugging tools.)

However I don't think a text editor is optimal. Blacken, I think we have different needs to some extent since I'm doing more interactive work with data and often don't know what the results should look like until I do it. That means I need a little more interactive feedback than someone coding up a suite or site or backend, but still I think IDEs are useful more generally. To me, the standard for IDEs for dynamic languages is that shipped with Matlab. Matlab's language is _terrible_ for big projects, but the debugger is decent, and that's the key. It's easy to drop into running code at any point and inspect code and step through it. The editor is also OK and does reasonable completion (and supports Emacs keybindings). You can get at the namespaces by completion in the editor or in the command window, which is a REPL loop.

Python has clones of the Matlab IDE: Spyder, Komodo, etc, but they are all terrible last time I used them. There are other IDEs like PyCharm, Netbeans, Wing and PyDev but the ones I tried I didn't find useful.

Editorial: if Python actually had any real commercial effort behind it, it would be pretty easy for a team to make an awesome Python data IDE with embedded IPy notebook, IPy console, editor, etc. But the problems left to be solved are boring ones about how to make the parts interact robustly, and no one's paying to get that done.

LNL: a big obstacle to IDEs is that people typically really like their text editor of choice and so there's a big hurdle to jump into an IDE's editor. If you have a text editor you love use that. If you don't care about the editor you're using there's often no big downside to using an IDE so you might as well use one.

SumnerH · Mar 24, 2015

rembrat said:
How on earth do you remember long vendor packages or long namespaced classes without an IDE? Or do the language you write in not have this issue? Is my PHP showing?

In addition to what Blacken said, IDE vs. non-IDE is a choice between using different components each of which you can select individually vs. one behemoth integrated package.

But the editor portion of your non-IDE solution doesn't have to be something stupid like notepad. I use vim. I hit TAB to complete (as in most dynamic languages, the completion is a bit more open-ended than in statically typed languages, but it's still generally effective):

And I get on-the-fly documentation in the status line. As soon as I typed zip

And instant error checking after each line is typed (this should be "if a == 0:"):

And I have good code navigation support. If there's a call to, say:

do_some_stuff()

I can jump from there into the definition of do_some_stuff, look at what it does, and pop back to where I came from no problem (it's a full stack, so if I'm in do_some_stuff and then drill down into another function I can pop back first to do_some_stuff's definition and then back to here where I started).

Most of this has been around in vim and emacs for 20+ years.

Blacken · Mar 24, 2015

What crystalline is saying is an indictment of Python's community (not Python-the-tech, the language and runtime are fine) rather than an endorsement of IDEs and heavyweight tooling. And that's a large part of why I'll cape up for Ruby--Python tooling being in the same miserable state it was when I started learning it in 2008 or so is a nontrivial part of why I suggested Ruby and Rails rather than Python and Django. I honestly don't know anybody moving to, rather than away, from Python in 2015, and...well...there are reasons for that. Everybody else--Node, the JVM, the CLR, even Go--has made big strides that Python seems to have not had time for. Maybe because they were too busy having to write 2to3 and friends. :buddy: (Seriously though, whoever thought requirements.txt or PyPI in general were good ways to run a library repo should have their heads boiled.)

I mean, the Ruby world has plenty of IDEs, but most folks work composably, and it shows. I write web code, I do data modeling, I do systems-level stuff. I do it all just fine in ST3 (or vim if I'm running remotely, I switched last year but I kept around my vim package configs). My REPL is a cmd-tab away because Pry is the best REPL I have seen in any language outside of Smalltalk and is perfectly happy doing hot-reloading of code and all the fun stuff you normally think an IDE does. And when something goes wrong, I am not confronted with errors from a tool that may itself not be doing the right thing (because I am the tool who would have not done the right thing).

(Yeah, I know the "everybody uses Python for stats" thing. Network effects are certainly a thing, but our folks use Clojure or Scala for that. Turns out the JVM has badass numerics stuff, who knew?)

SumnerH · Mar 24, 2015

Blacken said:
What crystalline is saying is an indictment of Python's community (not Python-the-tech, the language and runtime are fine) rather than an endorsement of IDEs and heavyweight tooling. And that's a large part of why I'll cape up for Ruby--Python tooling being in the same miserable state it was when I started learning it in 2008 or so is a nontrivial part of why I suggested Ruby and Rails rather than Python and Django. I honestly don't know anybody moving to, rather than away, from Python in 2015, and...well...there are reasons for that.

There's almost certainly a sample bias there--as someone who uses Ruby, you're going to see people moving toward you. My experience is exactly the opposite, I see more people jumping on Python every year and Ruby's lost some of the buzz it had 5 years ago or so. I'm probably guilty of sample bias there as well. (TIOBE has its problems, but FWIW it's showing Python as both higher rated and more upward trending than Ruby. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html )

I find the first half of the post odd because the difference in communities is probably the biggest reason I prefer Python over Ruby. The Python community has, to me, been a lot more helpful at answering questions--it's a little older culture with less internet flamewar culture attached, and a bit more well-rounded and less skewed toward web dev in general (which actually helps with both web dev and other questions, IME). There is definitely a community bias against IDEs in the Python world (much as there is in the Unix C/C++ world compared to the Microsoft C/C++ world), but that's for good reasons, IMO. Obviously this is very much a YMMV area.

crystalline · Mar 24, 2015

Blacken said:
What crystalline is saying is an indictment of Python's community (not Python-the-tech, the language and runtime are fine) rather than an endorsement of IDEs and heavyweight tooling. And that's a large part of why I'll cape up for Ruby--Python tooling being in the same miserable state it was when I started learning it in 2008 or so is a nontrivial part of why I suggested Ruby and Rails rather than Python and Django. I honestly don't know anybody moving to, rather than away, from Python in 2015, and...well...there are reasons for that.

Agreed. I jumped into this thread to ask about Go because of my frustrations with Python. I suspect Python is headed out as a data language. I talked about its failures to do concurrency well. And on the problems with its debuggers/IDEs. I doubt there will ever be a good JIT for it; the principal problem is dynamic typing with lack of type hints. Core Python tech is fine (although a fast JIT runtime would be nice). The data tech is warty - syntax and arrays are bolted on to CPython and it shows, plotting has a great core but terrible backends, and debugging is stuck in 1992.

I'll note that Sumner uses his editor for completion and in contrast you're using your REPL for completion. That's what I do too - IPython is a decent REPL.

The main things holding data people to Python are LAPACK/ATLAS out of the box (Numpy), good plotting libs (matplotlib and now the ipython notebook), legacy libraries (including Scipy) and familiarity. I see gradual change to something else. Maybe that will be Clojure or Scala.

SumnerH said:
Most of this has been around in vim and emacs for 20+ years.

My experience with code completion and navigation in emacs is... difficult. There are 982 options, most of which write their own parser with all of the attendant bugs, or worse, use text matching from source files you point it at with no semantic analysis. Most/all only work with a subset of languages, generally C/C++, and I use Java, C, C++, Python, and a few others. If you have pointers to a good solution please let me know, it's been a while since I looked. Meanwhile the Emacs people are fighting about political reasons to add code parsing. Emacs is another environment with good tech and bad community.

Edit: to respond to Sumner: from my perspective using Python I see lots of people moving towards it but just for expediency. Those may jump at a new solution. I think the core - at least as a data language - is going nowhere. Its general-purpose usefulness may keep it around, but there's not enough effort being put in to fix core problems. This post says that (but I remembered it saying more strongly that "No one wants to spend money making the core of Python/Numpy better".) The author's new company is mostly busy selling custom installations inside banks, and they have been able to keep some public core work going, on conda, numba, etc. We'll see where Python goes. For the near future it's the best solution for me, though I'll keep exploring others.

Sumner, Blacken etc. -thanks for the discussion on the merits of these languages, and for the pointers to actor-model approaches and Scala etc.; this was what I was hoping for.

SumnerH · Mar 24, 2015

crystalline said:
My experience with code completion and navigation in emacs is... difficult.

Yeah. I switched from emacs to vim during the great GNU vs. Lucid/XEmacs wars of the late 1990s.

Blacken · Mar 24, 2015

SumnerH said:
There's almost certainly a sample bias there--as someone who uses Ruby, you're going to see people moving toward you. My experience is exactly the opposite, I see more people jumping on Python every year and Ruby's lost some of the buzz it had 5 years ago or so. I'm probably guilty of sample bias there as well. (TIOBE has its problems, but FWIW it's showing Python as both higher rated and more upward trending than Ruby. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html )

You're inferring something I didn't imply. :buddy: Most of the people I know aren't leaving Python for Ruby, they're leaving Python for Scala, Clojure, Go, and (lately) Rust. Three of which crib very heavily from Ruby in terms of an ethos around tooling and systems. Python is an odd duck, though not as odd as Go, and it's just hard to do anything, you know? Like, venv is a bad hack to address bad design decisions that won't ever be fixed because Python's caught itself the Javas in terms of breaking things, except for the core language that they broke and will forever regret.

It should not be hard to computer. I feel that Python makes it harder to computer than almost any other dynamic interpreted language I know of (that's not a pro-Ruby statement but just in general).

I find the first half of the post odd because the difference in communities is probably the biggest reason I prefer Python over Ruby. The Python community has, to me, been a lot more helpful at answering questions--it's a little older culture with less internet flamewar culture attached, and a bit more well-rounded and less skewed toward web dev in general (which actually helps with both web dev and other questions, IME). There is definitely a community bias against IDEs in the Python world (much as there is in the Unix C/C++ world compared to the Microsoft C/C++ world), but that's for good reasons, IMO. Obviously this is very much a YMMV area.

I said almost this, verbatim, when I was hesitant about getting into Ruby. Ruby's culture sucked for a long time. And the people who stuck it out will acknowledge this. But I was relieved, when I ended up getting into this (I started using Python in 2006 or 2007, I started using Ruby last February), that the shitheads have, by and large, toddled on to the new sexy thing. Ruby's not cool anymore, and that's a plus. The well-known jerks of the past now hang around Node and Go and similar--just around the time that Ruby can be said to have matured, in terms of stack and libraries, into something you can mostly trust. (Downside is, dudes like Steve Klabnik have moved on too, working on other stuff--a lot of the old "good guys" from that flamewar era are now doing Rust, as it happens, and it's one of the reasons I'm excited for it.) The web-dev focus of Ruby seems to likewise be eroding. I know Rails developers, and I hate most of them, but I am heartened that the culture around Ruby is definitely moving away from being that language used to drive Rails.

And I never had problems getting answers to questions when I was dealing with Python. I had problems not mailing the Python core team a bag of dogshit for their terrible decision-making around stuff that should be simple, like functional constructs. It's just so fucking hard to write simple code and it always discouraged me from bothering with it except when I had to.

crystalline · May 6, 2015

One of the principal objections raised above about Python as a numeric language is the inability of the interpreter to reliably infer types. That makes JITting hard. To take two examples, Matlab and JavaScript have much better JIT engines in large part because the JIT can determine types.

I just saw that the core Python team is looking to introduce type hinting into the core language in Python 3.5-3.6.
http://sdtimes.com/python-3-5-include-type-hinting/
https://mail.python.org/pipermail/python-ideas/2014-August/028618.html

This has the potential to change what I said above about Python never becoming the mature numerics language to rule all others. It has other nits, but a good fast JIT would overcome what I think is now the biggest obstacle. We'll see. This is not going to happen quickly. The real question is whether PyPy and numba start using these type hints. I think it's a nobrainer that numba will soon.

However, the syntax is quite hairy and is only going to make Blacken more likely to be mailing the development team bags of refuse.

Edit: van rossum says he thinks one of the biggest pluses to type hints is better IDEs. So to who ever lamented bad IDEs above- this will improve IDEs too.

Blacken · May 7, 2015

It is indeed ugly and helps reinforce that the Python team should probably not be trusted with toys that could potentially present a choking hazard (to say nothing of a major piece of technical infrastructure), but I don't think this will matter as much given that serious numerics are mostly just routing numpy/scipy primitives.

crystalline · May 7, 2015

Blacken said:
It is indeed ugly and helps reinforce that the Python team should probably not be trusted with toys that could potentially present a choking hazard (to say nothing of a major piece of technical infrastructure), but I don't think this will matter as much given that serious numerics are mostly just routing numpy/scipy primitives.

I don't know that much about how tech companies use python for the web but I have a decent sense about how scientists and engineers use numerics-
Check out numba. It exists because not all numerics tasks can be implemented easily in numpy/scipy/BLAS primitives. Large scale codes that are professionally developed can usually move everything out of Python at the expense of complexity and C glue, but the majority of (serious) science and engineering codes are not professionally developed. That's the niche for JITs - and it's a big one. Numba, matlab's JIT, qnd the enthusiasm for running numpy on PyPy all speak to the demand for this.

It may be that Python misses the boat entirely on fast JITs, and by the time Python gets there the numerics world will have moved on - to distributed arrays and fully distributed computation, as things like blaze are shooting for. But my guess is there will be users for a good JIT in python for years to come.

Edit: or maybe I mistake the size and profitability of the market segment that I am referring to. After all, if it were so important, wouldn't someone have put in the resources to push numpy on PyPy by now? Regardless the main reason JavaScript has good JITing VMs and Python does not is static typing in Javascript. So I think its a good sign for the future that van Rossum sees the need for type hinting.

Blacken · May 7, 2015

JavaScript doesn't have static typing. asm.js has type hinting, but is largely unimportant except with regard to Firefox (maybe Chakra and extra-maybe V8 down the line, but not really yet). JavaScript has good JITting VMs because there is literally no alternative for the overwhelming majority of software in general use today. It was evolve-or-die, except there was no "die" option available.

I'm familiar with numba, and I think that it's a smart project patching around stump-dumb and, IMO, ultimately fatal failures of a badly managed community. I tend to think that the market you describe is smaller than you think and probably too small to be truly viable in the long run--I think that between the 2/3 split and the generally atrocious universe of tooling Python's already done a lot to render itself irrelevant. I can't speak to scientific pursuits, but the financial modeling folks who used to use Python are now using C# or F# or Scala or Haskell, and that doesn't bode well long-term.

SeoulSoxFan · May 7, 2015

Take a look at Craft CMS (www.buildwithcraft.com) based on Yii & Twig. The content modeling flexibility & the out of the box functionality is currently best in class IMO.

crystalline · May 7, 2015

Oof on JavaScript, sorry. I'm not a JIT person but have been told by JIT developers that Python's object/type system is much harder for a JIT to make sense of than JavaScript's.

Agreed that Python is shooting itself in the foot and risks irrelevance.

Scientific Python is huge and drives the python numerics community in my view. Most of the numerics startups like the pandas guys, and Enthought, and Continuum, came from academic science and are trying to make money selling to finance firms. Apparently you're saying that's not working.

Anyway, type hinting is a good idea for a dynamic language meant for speed/numerics. Hopefully it will come to fruition and bring a nice unified fast JIT to python eventually.

AlNipper49 · Apr 19, 2017

bumping to see what people's current thoughts on this are

Web Development Framework Question

Member

Member

Member

Robespierre in a Cape

Member

Member

Banned

Robespierre in a Cape

Robespierre in a Cape

Member

Member

Malt Liquor Picker

Member

Banned

Banned

Member

Member

Member

Malt Liquor Picker

Member

Member

Robespierre in a Cape

Malt Liquor Picker

Malt Liquor Picker

Robespierre in a Cape

Robespierre in a Cape

Member

Robespierre in a Cape

Member

Robespierre in a Cape

Robespierre in a Cape

Member

Robespierre in a Cape

Member

Member

Robespierre in a Cape

Member

Malt Liquor Picker

Robespierre in a Cape

Malt Liquor Picker

Member

Malt Liquor Picker

Robespierre in a Cape

Member

Robespierre in a Cape

Member

Robespierre in a Cape

I Want to Hit the World with Rocket Punch

Member

Huge Member