It’s called Dune now: https://github.com/ocaml/dune

Dune supports Reason syntax out of the box and will pick up all *.re files automatically.

Don’t forget pijul!

Seriously, though, I don’t think there is any “github plus something” that is going to break the github hegemony. Github won because it offered easy forking while Sourceforge was locked in a centralized model. Sourceforge won because it was so much easier than hosting your own repo + mailing list.

The thing that will get people away from github has to have a new idea, a new use case that isn’t being met by github right now, and which hasn’t been proposed before. That means that adding hg won’t do it – not because hg is worse than git (honestly, git’s terrible, and hg is fine), but because hg’s already been an option and people aren’t using it.

Adding email commits won’t do it, because that use case has been available for a long time (as pointed out elsewhere in these comments) and people aren’t using it.

Until something new is brought to the table, it’s all “let’s enter a dominated market with a slight improvement over the dominant tech”, and that’s just not going to be enough.

I’m afraid you’re not going to find a sympathetic ear in sr.ht. I am deeply fond of git and deeply critical of hg.

The GitHug hegemony has nothing to do with its basis on git. If git were the product of GitHub, I might agree, but it’s not. If you really want to break the GitHub hegemony you should know well enough to throw your lot in with the winning tool rather than try to disrupt two things at once.

Ah, that was a misleading edit, I’ve clarified the article text. Originally I had OCaml in the explicit sum type category with a note about polymorphic variants, but I realized that was similar to Ceylon so I moved it to the implicit sum type category without appropriately updating the pros/cons. Ultimately, I realized that a more nuanced description of the design space around sum types is warranted, which you can now find in the article (i.e. sum types can be broken down as named vs. anonymous, declared vs. inferred, and matched vs. casted).

I think “Swift is not a dynamic language” is a decent point. I’m not sure what you mean by dynamically typed, but I’m going to use specific examples of the dynamism I use when writing Cocoa programs in Objective-C to illustrate how I mean dynamism.

A couple of common cases where I use dynamic language features, because the design of Cocoa seems to lend itself to doing so:

• when preparing the display of collections of data (e.g. table views, collection views), I want to be able to say “this property appears in this place”, and “this UI change affects this property. I can do that by composing selectors based on the name of the property being displayed, or by using KVC which is an Objective-C technology that does the same thing.
• when validating the availability of UI actions (e.g. menu items, toolbar items, buttons), I want to be able to ask “are the preconditions for performing this action satisfied?”. I do that by extracting the preconditions to a method whose name is derived from the action’s selector, and then asking the relevant controller object to perform that selector.

Another thing I often do which has nothing (much) to do with dynamism but which Cocoa was designed with as an axiom and that Swift does not support is to use nil as the message sink.

I’m sympathetic to the idea that Objective-C as a language has shortcomings and that a different language would make Apple platform development more accessible. Shortly before Swift was announced I wrote that there already were tons of languages with ObjC bindings, because “ObjC bindings” are just FFI calls to a small handful of runtime functions. My hope at the time was that a language built in such a way - exposing the object runtime but hiding the complexity of all the C interop and memory management - would be the future. It’s not an unreasonable expectation, as Apple had integrated the open source PerlObjCBridge and PyObjC, and had developed MacRuby. But Swift is not that, it is a different model of computation that also has language support for Cocoa and (some) ObjC features.

Savings?

What I don’t understand is if you are not working in NYC anymore, and only working on your own and getting donation, why doesn’t he move to anywhere but NYC to minimise his personal expense?

I’m sure there are cities in the US with 80% the fun of NYC at lower than 80% of the cost.

Something to consider is that JavaScript has an extreme audience. People who barely consider themselves programmers, because they mostly do design use it, or people just doing tiny modifications. Nearly everyone building a web application in any kind of language, framework, etc. uses it.

I think the reason there is so much bad stuff in JavaScript is not only something rooted in language design. JavaScript isn’t so much worse than other popular bad languages, it just has a larger base having even more horrible programmers and a lot of them also build some form of frameworks.

Don’t get me wrong, JavaScript is not a great language by any stretch, but blaming the ecosystem of a language who certainly has at least a few of the bright minds designing and implementing (working at/with Google, Mozilla and Joyent for example) it should not result in something so much more unstable.

Of course this doesn’t mean that it’s not about the language at all either. It’s just that I have yet to see a language where there isn’t a group writing micro-libraries, doing bad infrastructure, doing mostly worst-practice, finding ways, to work around protections to not shoot yourself in the foot, etc. Yes, even in Python, Rust, Go, Haskell and LISP that exists.

Maybe it’s just that JavaScript has been around for ages, many learned it do so some animated text, they wrote how they did it, there is a ton of bad resources and people that didn’t really learn the language and there is a lot of users/developers that also don’t care enough, after all it’s just front-end. Validation happens on the server and one wants to do the same sending off some form and loading something with a button, updating some semi-global state anyway.

JavaScript is used from people programming services and systems with it (Joyent, et al.) to a hobby web designer. I think that different approaches also lead to very different views on what is right and what isn’t. Looking at how it started and how the standards-committee has to react to it going into backend, application and even systems programming direction probably is a hard task and it’s probably a great example of how things get (even) worse when trying to be the perfect thing for everything, resulting in the worst.

On a related note: I think the issue the community, if you even can call it like that (there are more communities around frameworks rather than the language itself, which is different from many other scripting languages) doesn’t seem to look at their own history too much, resulting in mistakes to be repeated, often “fixing” a thing by destroying another, sometimes even in different framework-layers. For example some things that people learned to be bad in plain JavaScript and HTML get repeated and later learned to be bad using some framework. So one starts over and builds a new framework working around exactly that problem, overlooking other - or intentionally leaving them out, because it wasn’t part of the use case.

A lot of Java frameworks predate maven - e.g. Spring was distributed as a single enormous jar up until version 3 or so, partly because they didn’t expect everyone to be using maven. I think there’s still a cultural hangover from that today, with Java libraries ending up much bigger than those in newer languages that have had good package management from early on (e.g. Rust).

Even including all transitive libraries, my (quite large) Android app Quasseldroid has 21 real dependencies. That’s for a ~65kLOC project.

In JS land, even my smallest projects have over 300 transitive dependencies.

It’s absolutely not the same.

In technical terms, npm does not differ much from how python does package management. Culturally, however, there are a big difference in how package development is approached. Javascript has the famous left-pad package (story). It provided a single function to left-pad a string with spaces or zeroes. Lots of javascript libraries are like it, providing a single use case.

Python packages on the other hand usually handle a series of cases or technical area - HTTP requests, cryptography or, in the case of left-pad, string manipulation in general. Python also has PEP8 and other community standards that mean code is (likely to be) more homogeneous. I am using python here as that is what I know best.

Because npn micro-libraries tends to be much worse than most other languages.

It’s a problem there too.

JSON replaces these problems with different ones. Different tools will use different constructs inside JSON (named lists, unnamed ones, different layouts and nesting strategies).

In a JSON shell tool world you will have to spend time parsing and re-arranging JSON data between tools; as well as constructing it manually as inputs. I think that would end up being just as hacky as the horrid stuff we do today (let’s not mention IFS and quoting abuse :D).

Sidestory: several months back I had a co-worker who wanted me to make some code that parsed his data stream and did something with it (I think it was plotting related IIRC).

Me: “Could I have these numbers in one-record-per-row plaintext format please?”

Co: “Can I send them to you in JSON instead?”

Me: “Sure. What will be the format inside the JSON?”

Co: “…. it’ll just be JSON.”

Me: “But it what form? Will there be a list? Name of the elements inside it?”

Co: “…”

Me: “Can you write me an example JSON message and send it to me, that might be easier.”

Co: “Why do you need that, it’ll be in JSON?”

Grrr :P

Anyway, JSON is a format, but you still need a format inside this format. Element names, overall structures. Using JSON does not make every tool use the same format, that’s strictly impossible. One tool’s stage1.input-file is different to another tool’s output-file.[5].filename; especially if those tools are for different tasks.

will break once the format is changed slighly

Doesn’t this happens with json too?
A slight change in the key names or turning a string to a listof strings and the recipient won’t be able to handle the input anyway.

the output accidentally contains a space.

Or the output accidentally contact a comma: depending on the parser, the behaviour will change.

No, jq doesn’t exis…

Jq is great, but I would not say JSON should be the default output when you want composable programs.

For example JSON root is always a whole object and this won’t work for streams that get produced slowly.

On the other hand, most Unix tools use tabular format or key value format. I do agree though that the lack of guidelines makes it annoying to compose.

Hands up everybody that has to write parsers for zpool status and its load-bearing whitespaces to do ZFS health monitoring.

In my day-to-day work, there are times when I wish some tools would produce JSON and other times when I wish a JSON output was just textual (as recommended in the article). Ideally, tools should be able to produce different kinds of outputs, and I find libxo (mentioned by @apy) very interesting.

I spent very little time thinking about this after reading your comment and wonder how, for example, the core utils would look like if they accepted/returned JSON as well as plain text.

A priori we have this awful problem of making everyone understand every one else’s input and output schemas, but that might not be necessary. For any tool that expects a file as input, we make it accept any JSON object that contains the key-value pair "file": "something". For tools that expect multiple files, have them take an array of such objects. Tools that return files, like ls for example, can then return whatever they want in their JSON objects, as long as those objects contain "file": "something". Then we should get to keep chaining pipes of stuff together without having to write ungodly amounts jq between them.

I have no idea how much people have tried doing this or anything similar. Is there prior art?

powershell uses objects for its pipelines, i think it even runs on linux nowaday.

i like json, but for shell pipelining it’s not ideal:

• the unstructured nature of the classic output is a core feature. you can easily mangle it in ways the programs author never assumed, and that makes it powerful.

• with line based records you can parse incomplete (as in the process is not finished) data more easily. you just have to split after a newline. with json, technically you can’t begin using the data until a (sub)object is completely parsed. using half-parsed objects seems not so wise.

• if you output json, you probably have to keep the structure of the object tree which you generated in memory, like “currently i’m in a list in an object in a list”. thats not ideal sometimes (one doesn’t have to use real serialization all the time, but it’s nicer than to just print the correct tokens at the right places).

• json is “java script object notation”. not everything is ideally represented as an object. thats why relational databases are still in use.

edit: be nicer ;)

Yes, that’s how it works in Rust too: shadowing often replaces assignment (and you can even “change” type of the variable, that feels like a dynamically typed language!). To my surprise, this shadowing-as-usual makes me much more aware of shadowing and actually prevents shadowing bugs.

I don’t know if Kotlin has it, but one thing that is useful for shadowing is a warning for if you don’t use a variable. In that case, the code provided would provide warnings because they don’t use one of the num’s.

I didn’t think of trying that…

I thought he was using 32-bit already? On my system, __NR_pause is defined to be 29 (his number) in asm/unistd_32.h, and 34 in asm/unistd_64.h. He’s also using eax over rax… Perhaps using int 80h and not syscall uses the 32-bit abi?

When web agencies/developers say “full stack”, in my experience they mean “jack of all trades, master of none”.

I always interpreted it as a way of saying “I am unaware of any abstraction layer lower than the virtual machine”.

When web agencies/developers say “full stack”, in my experience they mean “jack of all trades, master of none”.

I worried as much.

[…] perhaps mobile app development is a good route? It’s definitely a market with demand right now.

Thank you. I will take a look at that.

https://github.com/lukasz-madon/awesome-remote-job/ may also help.

Thanks for that too!

If your site is so dependent on JavaScript that it doesn’t work at all in browsers that get shut out by "browsers": [ ">0.25%", "not ie 11", "not op_mini all" ], I would suggest that your problem isn’t with your implementation but with your design.

One could automatically create optimized bundles for the different browsers, and send the appropriate one to the browser, according to the User-Agent HTTP header.

But unfortunately, the ethics of accessible, diverse and welcoming web contents has long gone.
Now the web is platform and a product, and people should just buy the stereotypical industrial offer.

Please visitor, conform!

This is where good defaults come in. I don’t think this is the sort of thing that a developer should be configuring at all, unless there’s a specific browser that they need to support.

I like this essay, and it makes me think about a couple things.

…the length and detail of a name should be proportional to its scope: A variable that is referenced across multiple files ..

It’s funny, because I like to write CoffeeScript, and you can’t really do that: variables are file-scoped by default. It’s a preference thing. (Some people like to shadow lexical bindings? not I)

Another issue with picking long names vs short names is that often (depending on language), naming is itself a leaky abstraction, because you just know it’s gonna allocate an entire word if you want “int cc_exp = credit_card_expiration; ..cc_exp..”. I don’t think all languages give you aliases for free. We also contort to make things fit 80 characters. Variables can’t have spaces (except Common LISP?), most can’t have dashes, I really want subscripts!—it feels like those password prompts: “5-8 characters, alphanumeric only”. At least we don’t have 8.3 FILENA~1. We learned to name files! (except the pain with spaces, again..) The tools often give naming a hard/constrained time, since it’s somehow never a priority.

I wish a lot of code were just a little more wasteful/redundant to be a lot more readable.

There are even actively maintained OCaml QML bindings, lablqml.

This is one of the features inspired by Clojure. In Clojure, #(foo %) is short for (fn [x] (foo x))

There’s also the pipe operator |> which passes the result of the expression on the left side as the first argument of the function on the right.

https://elixirschool.com/en/lessons/basics/pipe-operator/

Scala also has _, which in _ + 1 is an alias for x => x + 1, or in the case of f(_), is an alias for x => f(x). Oleg Kiselyov has an interesting take on it.

I’m not that familiar with Elixir (only having done a few basic distributed algorithms in it), but this feature has piqued my interest even further in the language, thanks for the handy tip!

I only recently saw my first example of a stack-based language. My thought was that it seems terribly difficult, as a programmer, to keep in mind what the stack contains at any given point in time. Is that something one gets used to over time?

Forth may omit variable names, but makes up for it with many word names.

For the non-german folks here, du is the german personal-pronoun for you so the title reads: Like you but more intuitive :)

Also “dust” means dork or idiot in Norwegian.