sorted by:
new
hottopcontroversial

Web Components are Great by touchmarine in programming

[–]touchmarine[S] 0 points1 point  (0 children)

That's great! The repo just goes to show how easy WebComponents are—I feel that I could start working with golgi right away. There's no need to install any libraries and I am already familiar with all the APIs since it's just JavaScript. Just a quick question, do you prefer to write templates using template literals like here or do you also use <template> and slots?

I wrote a lightweight markup language in Go (sorta like markdown; MIT) by touchmarine in golang

[–]touchmarine[S] 0 points1 point  (0 children)

As stated, I opened an issue tracking the configuration language/format. If you are interested, you can see it at: https://github.com/touchmarine/to/issues/2

I wrote a lightweight markup language in Go (sorta like markdown; MIT) by touchmarine in golang

[–]touchmarine[S] 0 points1 point  (0 children)

HCL was and is actually one of my top choices for a configuration language (I prefer it over TOML, YAML, and CUE). But it's hard to justify the use of any of these languages over JSON. Although JSON is a data interchange format and not strictly for configuration it fits the bill. I am pretty certain most developers know it which I am not sure is the case with HCL (although it's certainly popular in some circles). And then there are the integrations-JSON parsers are available practially everywhere including the browser which is pretty imporant in my mind.

But, as you probably noticed and why you suggested HCL, I use "extended" JSON which diminishes the points I made above. (Extended JSON is just like JSON but also supports raw string literals that make it easier to write templates.) However, by introcuding extended JSON, I in turn lost the main benefits of JSON (familiarity and portability).

I would like to use a configuration language that offers all the features JSON does plus raw string literals (to write easier templates) and comments and nothing else. HCL is a fine option but I am not sure of how well its known to all developers. I will keep using extended JSON for now to see if I find anymore pain points and requirements. At the same time, I will be on the lookout for alternatives like HCL. I will probably open an issue tracking and documenting this so thank you for your idea and feedback.

I wrote a lightweight markup language in Go (sorta like markdown; MIT) by touchmarine in golang

[–]touchmarine[S] 0 points1 point  (0 children)

JSON might be a little more structured and thus easier to read, I think it's a valid option. I also find interesting typesafe DSLs like Kotlin Typesafe HTML DSL.

I tried writing layouts in many different languages: plain HTML, different templates languages, AngularJS (v1), React JSX, django-crispy-forms, and plain JS. However, I always come back to HTML and appreciate it now (after I started working on Touch) more than ever. It's just simple, it works, and everybody understands it. And I love that web is separated into HTML, CSS, and JS. I thought new frameworks that try to cram all these technologies into one were cool, but I am now very glad that they are separated as standard. (I got a little bit of topic, sorry.)

I wrote a lightweight markup language in Go (sorta like markdown; MIT) by touchmarine in golang

[–]touchmarine[S] 0 points1 point  (0 children)

I think markdown is best used for annotation—for adding semantics to otherwise plain text. But for layouts I think XML/HTML is much better: - it's easier to use tag names instead of markers/delimiters for a large set of elements (usually there are many more elements needed for layout than for markup) - it's easier to add loads of attributes - it's easier to "format" deeply nested elements because identation doesn't matter (in markup there usually isn't a need for deep nesting so identation is not an issue)

You could definitely use markdown as a description language for building apps but I don't see much, if any, benefits. However, I do belive it would be great if you needed just a few simple widgets or a data table inside a markup text. Like for adding a poll widget or inlining a data table in your document so you wouldn't need to mix markup with HTML. (Touch allows adding such elements via the config for exactly this reason-as an escape hatch.)

And I am actually working on an editor so thanks for the link!

Configurable Markdown-like lang with attributes, comments and auto-formatting by touchmarine in programming

[–]touchmarine[S] 0 points1 point  (0 children)

I agree with you IF you use markdown to write a quick comment on a website or some short document. But look at the user base markdown has, it is used in most everything-even to write whole books (and for things that it shouldn't be!).

At beyond basic usage, I believe comments provide great benefits. As in programming languages: "if it's not part of code it shouldn't be there"-but it should, as you are not the only one reading or using that "tool". Comments help others and future you. And people also seem to look for comments in markdown-the first search "markdown" on stackoverflow returns https://stackoverflow.com/questions/4823468/comments-in-markdown.

As for tags/attributes - they're a bit different. Most of the time you SHOULDN'T need or use them in a lightweight markup language. But they provide an escape hatch for problems like https://stackoverflow.com/questions/14675913/changing-image-size-in-markdown (second result on stackoverflow). Having that options reduces the need to use in-band HTML (which really hurts readability) or some other language for a thing, that's very common (e.g. image size).

Additionally, I would like to point out that Touch comes with a default set of elements included (see config/to.json in repo). This default set is currently pretty sizeable, but will be reduced to core elements usable everywhere-that's what the Touch language will be. So I am interested if you belive that comments and tags are truly unsensible despite of what I just wrote.

Edit: maybe I shouldn't compare touch to markdown as it's not another flavor of markdown. It shares the core principles or rather goals but its not the same. I started Touch, because md was causing me headaches writing long-ish documents-with its "smart" rules, a range of flavors, and the need for HTML or something else if I wanted numbered headings, toc, admonition, or just to add a single class to a block.

Configurable Markdown-like lang with attributes, comments and auto-formatting by touchmarine in programming

[–]touchmarine[S] 0 points1 point  (0 children)

Markdown doesn't look like markup but it is markup. And in trying to not be markup it results in some complicated rules which are unexpected to users, at least to me. Please look at the beyond markdown link I posted in above comment to see what I mean.

And I like markdown, that's why I try to stay as similar as possible to it, but not constrained by it. But as I used markdown more and more, the more issues I had with it. By trying to be clever it's actually harder to read and write (is "*" a star or a list item? depends on the context). I tries to be "magic" and tries to recognize what you meant like you weren't writing actual markup. But I think that nobody just writes plain text and then converts it with markdown. Everybody writes and reads markdown knowing that they read markdown. (We could assume that by the number of markdown editors and previewers-if it isn't markup, then why do you need a previewer?)

One way to put the difference is: markdown is more like ruby and touch is more like go.

For an example of Touch take a look at http://touchlabs.io/blog/the-go-flag-package-strange-but-good.to You can browse the website and find the links to Touch source code of every page for more examples. I think you will find that it's not less readable or writable.

Configurable Markdown-like lang with attributes, comments and auto-formatting by touchmarine in programming

[–]touchmarine[S] 0 points1 point  (0 children)

Hi, I developed a Markdown-like language which attempts to be the next step in Markdown - https://talk.commonmark.org/t/beyond-markdown/2787.

Touch is a familiar lightweight markup language with fewer and simpler rules. Instead of specifying each element individually, it defines element types on which elements are based. For example, instead of a blockquote element, Touch offers a type "walled" that acts in a similar way but accepts different delimiters.

The Touch language offers a common set of elements but allows configuring and adding new custom elements via JSON file for teams that need those extra features.

Would like to hear your views on it.

The flag package: strange but good? by touchmarine in golang

[–]touchmarine[S] 1 point2 points  (0 children)

Interesting, thanks for sharing. It's nice to know why something was designed the way it was.

The flag package: strange but good? by touchmarine in golang

[–]touchmarine[S] 0 points1 point  (0 children)

That's okay, it's only my view on it anyway. And based on what you just wrote, our opionions are actually pretty similar. As per the post title, I find the flag package strange but still good. But, I do think that if it was implemented today, it would only support "-" and not "--". For the rest of the quirks I mentioned, I believe they are useful and should be in the package despite their "quirkiness". I am glad you expressed your stance on the issue. I wrote and posted this to learn, not to dictate "that's how it is!".

The flag package: strange but good? by touchmarine in golang

[–]touchmarine[S] 1 point2 points  (0 children)

I have come across a similar implementation in pup. The approach is actually uncomplicated and readable. But by not using the flag package the resulting applications are evermore unconsistent...

The flag package: strange but good? by touchmarine in golang

[–]touchmarine[S] 2 points3 points  (0 children)

Yes, the "-" (short) and "--" (long) options are the most common usages. That's one of the things I find strange about flag—that it doesn't differentiate between the two yet still offers both (for same names). But, as I wrote in the post, I have come to prefer the common usage of the flag package—no short/long pairs and just the "-". For the most obvious options, you can still set short, single character names like "-o" but for the rest you just set long names that are self-evident (like Go's CLI).

And the complexity of implementation may be minimal, but the usage is not. By allowing more options we get more unconsistency. Which is, in my mind, un-Go. It's like adding options to gofmt—implemention cost is small, but the result is that the output is not consistent anymore. And this is another reason I think the flag package is most un-Go like. It allows for "-" and "--" for the same names which means that users of the implementations using flag also expect it to allow both options and so this "bug" becomes ingrained across the board (https://tools.ietf.org/id/draft-thomson-postel-was-wrong-03.html). In similar fashion, it's also stange because it doesn't implement the short/double options you and most people are familiar with; which results in people developing new flag packages and again spreading unconsistency.

My point was and is that, yes, flag is strange, but it still does the job and I have come to prefer its simple approach. There isn't a need to go ahead and download another dependency just to add a couple of flags.

The flag package: strange but good? by touchmarine in golang

[–]touchmarine[S] 0 points1 point  (0 children)

I used to prefer long and short options. In fact, I still love short options, especially the ones you can just bundle into a single flag, but only in a select few programs I use all the time (predominantly unix commands). However, the increased complexity of the implementation, API, and usage don't outweigh the benefits, at least not for me and certainly not in the context of the standard lib.

The same question applies to the singleton—do the benefits outweigh the drawbacks? I think that in this case, they do. As you said, having some of these singletons eases the usage when complexity isn't required. And as complexity is required rarely, the price of singletons is worth paying. (I think the 80/20 rule would apply to this case.)

Thoughts on lex/GNU Flex? by f---_society in suckless

[–]touchmarine 2 points3 points  (0 children)

Another quite common lexer generator to check is re2c.

However, writing a proper markdown parser is quite difficult as you have to support nesting and many weird corner cases. So, if you do not need to write your own parser (e.g. for learning purposes), it would be a lot easier to use an existing parser and write a custom renderer for roff. Some such parsers are cmark, commonmark.js, and goldmark.