> On Dec 6, 2020, at 18:11, Lloyd R. Prentice <
ll...@writersglen.com> wrote:
>
>
> As an author/indie-publisher with an advanced degree in public affairs communication, I see Nitrogen as a powerful tool for human-to-human communication. To fulfill this potential several things must be emphasized:
>
> 1. Easy to learn and use — even by non-professional programmers
> 2. Fluency in all modes of human communication — text, images, audio, video
> 3. Easy to interface with or embed into other open source software
> 4. Easy to interface with networked hardware and sensors
> 5. Easy to coevolve with technology advances
> 6. Easy to deploy with high security
>
> Clearly Nitrogen 2.4.0 falls far short of this idealistic vision. But it’s far closer than any other web-tech stacks I’ve looked into. An actively involved community is the key to closing the gaps.
[tl;dr — I need a life.]
Thank-you Lloyd for making explicit these essential goals!
I agree with your assessment that Nitrogen might fall short but it's
further along than analogous frameworks. Interestingly enough, I find
that a lot of potential anti-features actually work to the user's
advantage; to wit:
-- The lack of an ORM (loosely defined, of course there are no
objects per se). How one interacts with datastores is left up to
the user. For example, it's entirely possible to sequester all
SQL code from Erlang code. In terms of optimization and
reusability, this is huge.
-- No magic. The closest Nitrogen comes to doing something without
explicitly being told to is routing requests to modules. Reading
the code will give a fair understanding of what's going on
without understanding a baroque configuration.
-- Explicitly named functions. Okay, so this is an Erlang
(anti-)feature but still, it's trivial to figure out what module
a function is being called from by looking at the function call.
-- Freedom from MVC. While abstraction is sometime great, so it
immediacy. I'm reminded of Perl's guiding principle (at least it
used to be) "Make the easy things easy and the hard things
possible." You can implement MVC but for easy tasks, you don't
have to.
-- Agnosticism. Use whatever libraries you want, how you want. I'm
a firm believer in using UUIDv4 for surrogate keys in DBs.
You're not? Fine. I'm a Bootstrap fan. You're not? Fine
again. Being shoehorned into someone else's idea of what's the
Right Way too often leads to copious amounts of code (or worse:
configuration) trying to work around the mismatch.
So about this rebar3 stuff...
I think it's quickly becoming a standard way of developing, managing,
and deploying Erlang applications. It's pretty well known in the
community and conforming to its conventions will make life easier for
new Nitrogen developers. There's a balance with this: it's another
thing to learn if you don't know it (seemingly at odds with your point
#1) but it absolutely aligns with your goal #3. Given the
availability of rebar3 documentation and assistance available, I think
the pros outweigh the cons.
If we were to undertake this work, I foresee a few benefits, at least
for certain user cohorts:
-- (Easier) Elixir integration. There are two benefits: all of the
Elixir based libraries become available if we keep an eye towards
easy integration; and our user base potentially expands to not
only current Elixir devs but also non-BEAM developers who might
shy away from Erlang because of its unfamiliarity. (I personally
would benefit from integrating with the Elixir based Nerves
project, see your points #3 and #4.)
-- Container deployment. OTP applications are almost trivially
deployed on Docker. As it stands, if you want to do it with the
existing Nitrogen, you're kinda on your own (and there are tricky
bits). In the enterprise there's a big difference between
"Erlang application" and "Docker container" when you're asking
your systems group to manage it. (At least in my experience.)
-- Did I mention familiarity?
All of this is to say, I firmly agree with your notions of emphasizing
the human and appreciate the reminder that technology and incremental
changes should be focused on achieving your stated goals.
> Jesse and I have been kicking around the idea of a series of shorter project-oriented books that could possibly reach across the remaining items on my list above. But time and energy are serious constraints so we would much appreciate ideas and involvement from the Nitrogen community. What well-documented amazingly cool demo projects would you like to build or see built, published, and promoted?
There are a number of demos/plugins/applications/techniques (take your
pick) that I think would be beneficial:
-- Database access! What does it look like to interface with an
RDBMS? How is SQL managed? How are schemas created and
maintained? What's an appropriate level of abstraction?
-- DTL (Django Template Language) integration. How can page design
be separated from back-end processing? How do DTL templates
interact with #template{}? Is it possible to specify page
interactions from the DTL (or template HTML) side instead of
relying on Erlang code?
-- User and group management; login/logout; session management. How
many times have you sat down to write an application and first
had to either hack out user/group CRUD before you could get to
the business problem? Would a selection of plugins to manage
these common tasks be helpful? How about an AD/LDAP interface?
-- API management. Even if there's a page I can visit to, e.g., add
a user, how can I leverage that code as part of an API? How can
such a system be self-documenting and discoverable?
I'm 100% sure this list could go on. It should also not be taken as a
shortcoming of the framework that these functionalities are not baked
in. (See "Agnosticism" above.) But providing some starting points
would be wicked user friendly.
I apologize for the length of this email; you hit me where I live. I
firmly believe that expressive languages and libraries do more to
advance practical goals than any amount of fancy bit twiddling (when
fancy bit twiddling isn't actually called for). I don't want to knock
out a prototype and then re-write it to make it production-ready; I
want to write production code from line one.
b.