[conspire] 21st century web platforms

[Nick Moffitt]

On 14Feb2020 11:04am (-0500), Ruben Safir wrote:
> > 1: That the old ALGOL-related iteration structures weren't cutting it in
> > the 21st century.  Whether we wanted cool message-passing tricks from
> > Smalltalk or sequence comprehension tricks from Haskell, we just were
> > getting tired of wrapping *everything* in 1960s-style loops.
[...]
> I don't think you can really get rid of ALGOL any more than you can get
> rid of 4 wheeled automobiles.  It is here to stay.  You can hide it with
> message passing systems but is just hiding it, and message passing
> systems tend to be brutish and insecure.  I'm not opposed them, but they
> are hardly paneceas.  Security troubles with objective-C are built into
> the language becuase of string code injections.  In fact, all these
> systems are vulnerable to code injuction to DCOM, et al systems.

No one is talking about getting *rid* of loops.  But often it is clearer and more efficient to express operations as sets, or as combinations of filters on a sequence.

I'm not sure what sort of insecurity you describe with message-passing.  Are you using the phrase in the sense in which Smalltalk and Ruby use it?

> I would also like to hear more about template/dispatch/ORM/action model.



>  I also had a question about
> 
> 

> I am also curious about FLASK.  There is no Apache with flask?  

Use whatever HTTPS-terminating server you want, really.  You can hook flask into Apache if you want to be 90s about it, or you can run a (say) gunicorn server on localhost to run your appservers and proxy it through whatever front-end Web server you prefer.

> I find the explanation of FLASk a bit humerous.

You have to be careful, because Flask did start out as a joke.  The author of a WSGI library was laughing at the "one-file Web framework" trend of 2007 or so, and released Werkzeug bundled with Jinja and some glue code as a single file.  It turned out to be incredibly useful!

> <<Micro simply means that Flask is small. It doesn’t come with a
> particular set of tools or libraries that other popular Python
> frameworks like Django or Pyramid provide. Flask is designed with
> extensibility in mind. It only provides a core set of features and
> relies on extensions to do the rest. Right out of the box Flask doesn’t
> provide any support for accessing the database, form validation,
> authentication, file uploads and so on. To add these functions to your
> application you have to use extensions. Because you can choose the
> extensions you want, you end up with lean stack without any extra cruft.>>
> 
> Umm- that cruft makes your applicaitons work and this sounds stikingly
> similar to the original Apache concept.  I find the differences between
> libraries and extensibility as been a false flag.  But maybe I don't
> understand it.
> 
> What is C?
> 
> main(argv, argc){
> 
> return 1;
> }
> 
> 
> the rest is extensions...

Exactly.  And Flask has a wide body of library code for you to assemble in the way you need.

The Rails motto of "code, not configuration" is an enticing one, for this.  Instead of giving you a giant Microsoft Office-type all-singing-all-dancing Application to Configure, you get individual libraries of code you can include and plug together.

The actual downside to this is that you get a network effect as the possible interactions between pieces multiplies.  This isn't completely avoided in a monolithic application, however, and many "unsupported configuration" situations would be problematic module interactions in another architecture.