I like this idea, It'll be good to have the best of both worlds. Is there a way to optimize search engine visibility for such short urls? perhaps with a good title, meta tags having keywords etc.? Is there a HTML meta tag that gives the search engine crawlers an alternate hierarchical url for the same page? I believe setting up the server to do this is not too difficult.
Lines of code per second for compiling the compiler. Or a standardized set of programs like language benchmark game. Not to say that they are not susceptible to problems, but they have much more information than the compiler compilation speed.
"A good programmer uses the most powerful tool to do a job. A great programmer uses the least powerful tool that does the job." I believe this, and I always try to find the combination of simple and lightweight tools which does the job at hand correctly.
Awk sometimes proves surprisingly powerful. Just look at the concision of this awk one liner doing a fairly complex job:
zcat large.log.gz | awk '{print $0 | "gzip -v9c > large.log-"$1"_"$2".gz"}' # Breakup compressed log by syslog date and recompress. #awksome
Ehh. Until the 'job' gets extended and then your simple tool makes it exponentially more complex and you have to rewrite it with the more powerful tool.
The nice thing about a 1-liner is you only lose a few minutes to throwing it out entirely and rewriting it to fit a new purpose. Dwelling on what might be needed is of limited utility, because of the very real possibility that what's actually needed in the future is wildly different from what you spent all that time planning for.
This is fine. I often "prototype" my automations as shell scripts, to explore what I actually want the tool to handle. Once it gets longer than 20 or so lines, it's time to move to a better language, but I don't mind rewriting. This is a chance to add error handling, config, proper arguments, built-in help texts and whatever else.
I started to add error handling to my shell scripts and often never rewrite them.
Defo agree with the sentiment that you should always be happy (and able) to rewrite a shell scripts, dont let its scope creep.
I don't mind long(ish) shell scripts as long as the program flow is fairly linear. Too many function calls is the smell that makes me rewrite.
Exactly. I end up re-implementing my scripts if they outgrow the original scripting language anyway, because it's a good time to add proper argument and error handling, logging, etc.
A 5 min job that probably won't get extended saving you from having to spend 20 mins coding something up is better than, feeling annoyed that you have spent the 20 mins coding up the original implementation and then extend it.
Hopefully, you also get the benefit of additional knowledge on that future implementation as well. Why wouldn't this just be a net win?
Unless you're talking about writing hack after hack after hack, eventually leaving yourself with some incomprehensible eldritch monstrosity, in which case, don't do that?
If I understand this correctly, it will gzip every line separately instead of gzipping them together... it's not really the most effective but it does work
Wow, this is amazing. It really shows how complexity should be managed in the tool so that the user can do the naive thing and have it be accidentally optimal
It is surprising to people who expect them to behave like shell pipelines and redirections though. I somehow never got bit by it, but have definitely corrected other's awk scripts who didn't know about this feature.
Elm handicaps my attempts of "making impossible states impossible" because:
- I can't have Sets of arbitrary Types they must be `comparable`. I cannot create a custom comparable type.
- Records, Bool and custom Union Types are not `comparable`
- Bool and Simple Union Types could have been comparable if their comparison worked like they were Enumerated Types. Elm does not have Enumerated types.
Elm is a walled garden (as advertised). Agreed this is annoying (for me coming from Haskell). But it does have a great learning experience for those new to FP.
Can you (or anyone) point me to the files where this `comparable` logic is implemented in elm compiler? I'll try my hand at least making Bool and Record types Comparable. Or maybe implement comparable Enumerated Type in elm which behaves mostly like custom Union Type.
Even if you find the place in the `elmc` code base, fix it and make a PR: it will not be accepted. This is the walled garden aspect of Elm.
Either you accept the walls or you go with PureScript (which could be described as "Elm without the walls"; but then there is a lot more to learn and a whole plethora of frameworks where Elm has the one-to-rule-m-all-FW baked in).
I think if someone implements this thing without breaking backward compatibility, then it will be valuable even as a fork of the original elm compiler. I think the License allows this.
Also, Evan has not closed this issue since 2015. Most probably it is about "too much work to get it right" rather than "I'm not convinced that we need it".
I think type classes is how one would want to fix this. Haskell and PureScript have 'm. But them come with a lot, A LOT, of work. Especially to get the std lib to use them!
With comparability you can use the operators (<,>,<=,>=,==,/=,etc.) on various types. This is not how Elm usually works. I.e. the `map` function is different for `List.map`, `Dict.map`, `Maybe.map`, etc.
In Haskell and PS you have type classes. Some types can be mapped, some can be compared, etc. Then the type class defines what functions should be implemented for such type in order to be part of the type class.
You think it's a small change, but it is pretty much what sets Elm and PS apart. Errors can also get a lot more complex with code that leans heavily on type classes.
FWIW this post is about PureScript, not Elm. The library is an implementation of the Elm Architecture in PureScript. Elm is a language. The framework that goes along with it is called "The Elm Architecture". The Architecture can be implemented in any language. Here's an implementation in TypeScript: https://github.com/gcanti/elm-ts
Did you find better alternatives? I'm currently trying to learn a bit of Elm. So far it's basically the only "Javascript framework" that I've been able to get up and running, while still understanding how things actually work.
I'm also this kind of i-want-to-know-how-things-work person and also never managed to stay at learning React, Vue etc. But a few months ago, I discovered Svelte and I absolutely love it. I recommend you to give a shot to their excellent tutorial which you can finish in < 1 hour https://svelte.dev/tutorial/
Looks like purescript development requires node, purescipt compiler, and spago build tool. I have set these up. In future I'll try to learn Flame framework and then adapt my elm code to this.
I can’t express how useful using Dhall as the configuration format for Spago has been compared to the standard JSON, YAML, or TOML files have been. Having typed configuration with function and can grab environment variables opens a lot of possibilities. One place that has been nice is changing target locale to build with an env var pointing to a different source folder for translations. Overriding packages is just merging two records. Normally this would have to all be handled in a in the build tool or using a non-terminating config language, as a result Spago and PureScript’s package system get to be much simpler.
The fact that Dhall’s aesthetics mirror those of PureScript (including Unicode) is a cherry on top.
I agree, this can be shocking for many casual users. I think there is an option to save a "plain SVG" as opposed to "inkscape SVG". Does "plain SVG" also include such information?
A few months ago I tried my hand at this because it had some better defaults. Also, I didn't like camel case variables everywhere in Hugo. Then, I gave up when I realised that Zola does not even allow YAML config files. Nit picks everywhere..
Hey there's some healthy skepticism about YAML on zola's side. In particular, the maintainer believes encouraging people to use a broken/dangerous (in terms of remote-code execution in some implementations) serialization format is not a good idea, even though Rust YAML parser is safe from that.
There's also a concern for maintenance: maintaining the zola codebase to support more serialization formats is more work. If more contributors get involved regularly, it will be less of a problem.
In fact, zola started supporting YAML frontmatter for compatibility reasons lately, but it's explicitly stated in the docs this is not the recommended/supported way to do things.
