This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-05-31
Channels
- # announcements (1)
- # babashka (27)
- # beginners (33)
- # cider (22)
- # clj-kondo (1)
- # cljdoc (2)
- # cljs-dev (8)
- # clojure (96)
- # clojure-australia (7)
- # clojure-europe (24)
- # clojure-nl (1)
- # clojure-taiwan (1)
- # clojure-uk (7)
- # clojuredesign-podcast (4)
- # clojurescript (23)
- # clojureverse-ops (1)
- # conjure (11)
- # cursive (29)
- # datahike (1)
- # datascript (8)
- # datomic (4)
- # emacs (1)
- # figwheel-main (1)
- # fulcro (3)
- # helix (7)
- # jobs (4)
- # lsp (6)
- # malli (3)
- # off-topic (35)
- # pathom (6)
- # re-frame (4)
- # releases (1)
- # sci (18)
- # shadow-cljs (14)
- # sql (1)
- # tools-deps (11)
- # xtdb (6)
Have you actually seen/worked on extensive documentation that tries to enforce having one sentence per line? If so, how did it go? Would you generally be in favor of or against it? source: https://asciidoctor.org/docs/asciidoc-recommended-practices/#one-sentence-per-line
I wrote my master's thesis in LaTeX, and chose to have one line per sentence. Git commits became more specific, and that alone made it worth it. These days, I don't think I'd bother.
Diffs look much better, that's right. I also think it kind of promotes writing shorter sentences but that's just a hunch. :thinking_face:
have tried it, and found it to be really hard and invasive to remember to do, and in the end, not worth the effort
I did not realize/remember that https://docs.asciidoctor.org/asciidoctor/latest/manpage-backend/.
> By starting a new line at the end of each sentence, and splitting sentences themselves at natural breaks between clauses
Oh that's right, thanks. I missed the second part. That's even more extreme than what I had in mind... Regardless, I think that the principle is quite similar in both cases.
Btw that's only the case in the semantic linefeeds approach, the rest don't seem to split up sentences
'one sentence per line' sounds painful to follow but I'm not a fan of word-wrap at a fixed column count either. When reading the source code (particularly in docstrings) it can read unnaturally, because the newline was placed in whatever position column N was Sentences are organised in phrases, placing a newline after each phrase if needed tends to be naturally readable (I think some literature follows this style?)
(<-- EX-PHP programmer)
In spite of all of PHP's quirks, there were a bunch of reasons why PHP became popular. We take for granted the incremental development workflows available today, but PHP has had incremental workflows as the default for a long time and without any complicated tooling (just save and refresh). For simple websites, state management for PHP was also pretty good. All state was stored in a relational database and html pages were generally derived from that state using pure functions. Deployment for php was also incredibly easy, just copy your project to the webserver. It's not to say that PHP exemplifies the epitome of software development, but I think it does show how straightforward tooling and a functional approach to state management can allow people to start building useful software without a steep learning curve. I think some of the negative press PHP has received is sort of a simpson's paradox. PHP is a lot easier to get started with and there's a lot more useful code that's written by inexperienced programmers. There's a lot less useful code in other languages written by people with similar levels of experience.
CFML (ColdFusion) suffers from that same paradox: very easy to get started with, lots of functionality out of the box, so a lot of ânon-programmersâ were able to build quite complex web projects with it â and produced unmaintainable codebases along the way, giving CFML an even worse rep.
The âvictim of successâ pattern seems to come up a lot in programming. Lots of people using it = lots of crap written in it and about it.
Yeah, although CFML isnât exactly something Iâd consider âsuccessfulâ â it certainly had a very active community back in its heyday but itâs more of a niche language than Clojure these days. That said, there used to be a lot of (US) government CFML code (back when the government often preferred proprietary systems with commercial support).
To be fair, I think a lot of my own personal prejudice against PHP stems from people trying to invent Rails for PHP, which just drove me nuts.
that too. there were people who tried to Java-ize PHP which made things worse IMO
Oh yeah, big time.
PHP itself isn't really as terrible as curmudgeon-me likes to claim.
CFML has cfWheels â which is quite literally a Rails clone (but the frameworkâs codebase is horrendous).
If the framework's codebase is ugly, then it's a better "clone" that I initially though :rolling_on_the_floor_laughing:
Is it considered a common practice on Clojure to use markdown on docstrings? Or is the idea quite silly? I know that core functions don't do that, but I'm curious if someone else does it...
backtick-delimited code will be rendered nicely under clojure-mode
other items not. But I still use bullet points since they're readable anyway
http://cljdoc.org supports it so I think more and more people are using MD in docstrings these days (I think several auto-doc projects support it â but http://cljdoc.org is the most common now I think).
This is exactly the reason why clojure-style-guide seems to recommend it: https://github.com/bbatsov/clojure-style-guide#leverage-markdown-in-docstrings
(so Iâm using MD on nearly all my docstrings in my OSS projects now)
I use markdown in some docstrings for rewrite-clj, code blocks can sometimes be hard to edit, but looks real nice on cldjoc.
Nice, I'm thinking about rendering docstrings as markdown on Chlorine/Clover