If you had the ear of a language creator, what would you say - what could they do to make a language that you would use? 
2 Likes
Please contribute to elixr-lang/elixir GitHub project.
Now seriously ā¦ I would say that he should look at how Elixir is developed and see how things are working ā¦ Secondly I would say something like:
Ask yourself what developers would be interested in your language and why. Then think about solutions which would interest them.
Just for example Elixir is not first language which provides a stable API for writing concurrent code, but I absolutely love how concurrency topic was solved.
For people who are working on framework I would do literally everything to prevent them from working on them, hahah
Pretty similar case ā¦ take a look how Phoenix framework (which is basically library) have solved lots of things.
At end I would please to not create a cases which could produce huge stacktrace.
2 Likes
Two things:
- Do NOT do anything that the JS/NodeJS ecosystem did (especially the unusable stacktraces).
- Do NOT ever force any form of static typing onto the user. Make it at least opt-in.
4 Likes
Eh, Iām highly highly against that, it introduces such huge classes of bugs that just outright canāt happen on well typed languages, and I utterly absolutely hate maintaining such projects with their host of bugs and impossibility to trust any change you makeā¦
1 Like
Well, someone asked for my opinion and I wrote my opinion.
I worked both with Golang and with Typescript. Golang is just horrible and 95% of my problems are related to the language bitching about some type specific things. Itās just annoying.
In Typescript, I mostly just type my stuff with interfaces but it also often gets in my way. External libs either miss type information or they are just wrong. D3 is especially hard to work with. Also everything that is related to DOM elements. And I cannot even check if a variable matches a certain interface, thus having to have a type property on certain interfaces.
Iāve worked with PHP for a long time and never had any type related issues. The addition of type hints was nice but it was all optional so one could use it in places where it makes sense.
I also love the way Elixir handles it with pattern matching, therefore I do not understand why everyone wants to force a strict type system onto Elixir.
Just my 2 cents. (But I guess we both had the same discussion a few times already on the Elixir forum 
)
3 Likes
Iām not fan of golang and can write a book about what I think is wrong with it on so many levels, but the type handling in it is correct though extremely limited, but if there was a type issue that it reported then there was definitely a bug in the code that was caught by that check. Sadly its type handling is so deficient that it wonāt catch āmostā typing related bugs, but what it does catch is definitely bad codeā¦ >.>
3 Likes
Tips for language / framework creators? Sure, I have one!
Please donāt!
To expand on that: we have way too many of them already. I believe itās high time for our community to start preparing for formal certification and stricter regulation. The ātoyā aspect of programming swung a bit too far in its own direction IMO.
Basically anything and everything you can think of has already been done ā but it (1) is not in the language you like ā syntax is a taste, people! itās not a hard requirement for anything! ā or (2) doesnāt have all the features you want. Of course, many people code these things just for fun and wouldnāt accept PRs so I guess that explains why so many end up rolling 98% similar languages and frameworks on their ownā¦
We could all use some more math and, in general, a little more scientific, background. I absolutely get the excitement of programming ā Iāve been doing it since 12 years old! But I believe more of us should start keeping their toy projects to themselves (especially the people who arenāt receptive of PRs).
2 Likes
No, disagreed. Any time you āwaste on fighting the compilerā youāll gain back by peace of mind and less runtime bugs. I have been working more with Rust than with Elixir lately and for a good amount of projects and tasks having static and strong typing is a sanity saver.
Elixir is quite fine on that front ā you donāt want static typing, well, it doesnāt have it. And you can opt-in to stricter checks with guards and pattern matching (and, to an extent, using Dialyzer for success type checking).
2 Likes
For the love of Turingās ghost please hire a professional technical writer to thoroughly document your language and its standard library. Iām not joking; I remember a time when the best thing about C# and the .NET Framework was its documentation.
3 Likes
Absolutely. A lot of technical docs require a fair amount of effort to navigate ā not to mention to even understand what the thing is doing and why should the visitor consider it.
2 Likes
No, I just had to parse external JSON with a format that was slightly dynamic. Go sucks for that because it wants everything to be typed beforehand which makes those dynamic inputs rather difficult.
2 Likes
Goās JSON parser is untyped, it involves a lot of type casting and testing, one of the things Iāve had to do in golang. It definitely handles dynamic fine, it was the typed handling that was a huge pain. This was a year or three ago though.
1 Like
My first tip isā¦
KISS
KISS, an acronym for " keep it simple, stupid " or " keep it stupid simple ", is a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design and unnecessary complexity should be avoided.
I know itās a bit of a clichĆ© but it really is important imo. Sometimes you can play with the balance depending on the benefits (they really have to be worth it) but for things like languages and frameworks, it could be all the difference between make or break. I think Ruby and Rails got things right here - theyāre incredibly simple to get started with (even if more complex under the hood).
If fact thatās just given me an idea for a new thread 
3 Likes
Do not use Markdown/CommonMark for documentation. Use more expressive and configurable format like ASCIIDoc.
This is absolutely trend that I cannot understand. Markdown was designed for writing blogposts with almost not typesetting. Yet for some reason people thought that it will be a great format for documenting code, which need few more additional stuff, that was never a plan for MD (cross document references, math, graphs, tables, definition lists, etc.). Just stop and use ASCIIDoc for gods sake.
4 Likes
I tried using ASCIIDoc for a while but itās still lacking features in comparison to ReST or LaTeX. Nowadays my generators just use pandoc so it can consume almost anything so use whatever is appropriate. ^.^
2 Likes
Any examples how btw?
2 Likes
Examples for what? Pandoc? Itās documentation is pretty top notch and they have lots of examples. It can consume a LOT of formats and also output a LOT of formats, itās basically the imagemagick version of text. 
1 Like
Yep. Iād love to use it more but lately I canāt get enough time or energy to read for more than a few minutes without getting tired. 
2 Likes
What features did you miss? Especially agains ReST, because TeX is completely out of the league.
2 Likes
Hmm, it was many years ago last I dealt with them, but the tooling was a big thing. It was much easier to plugin new functionality into ReST, as well as ReST I recalled having a lot better page handling functionality in regards to how you reference things and put footnotes and so forth. I last touched asciidoc about 5 or 6 years ago so I honestly barely remember it anymoreā¦ ^.^;
And yeah, LaTeX is significantly beyond anything they can do, so thatās what I generally prefer myself.
2 Likes