7 ms·
What you did there is very cool! I am speaking for both LX as presented in the old link and the new work that you are doing. Personally I have given up creatin
by axilmar 7y ago
What you did there is very cool! I am speaking for both LX as presented in the old link and the new work that you are doing.
Personally I have given up creating a new programming language about a decade ago because I realized no matter what language I create, people will not use it, it it comes from a random github page.
Also, existing languages cover almost all business needs and while languages like LX provide a lot of improvements, the cost of change seems to be greater than the cost of not having these improvements.
As for ideas, what I'd like to see in a programming language is signal-based programming: the execution flow of a program is not 'one instruction after the other' but reactions to signals. A program shall be built by wiring output signals to input signals.
I'd also like to see types morph based on run-time conditions.
The most fundamental problem of all the current programming languages is that types are too rigid and don't allow for catching all the possible outcomes. For example, a File morphs between a closed file and an opened file, however in current systems any operation can be applied to a file, irrespectively of whether the file is actually opened or closed.
I believe that the combination of signal-based programming and type morphing will increase the reliability of programs, leaving only bugs that cannot be proven to be solved due to their nature (aka like the halting problem).
I may not be necessarily correct, but I have a strong belief in the above.
- wwright 7y agoYou should check out Idris: https://www.idris-lang.org/ https://www.idris-lang.org/
- heavenlyblue 7y ago>> For example, a File morphs between a closed file and an opened file, however in current systems any operation can be applied to a file, irrespectively of whether the file is actually opened or closed. But not in Rust. As a matter of fact anything based on intuitionistic logic could do that for you (e.g. use-only-once, must-use, etc).
- Shoop 7y agoThe thing you are referring to with open and closed files is called typestate. Check out its implementation in the Plaid programming language: http://www.cs.cmu.edu/~aldrich/papers/onward2009-state.pdf http://www.cs.cmu.edu/~aldrich/papers/onward2009-state.pdf
- codetrotter 7y agoThere was a post here on HN about typestates in Rust too yesterday. For anyone that didn’t see it: https://news.ycombinator.com/item?id=21413174 https://news.ycombinator.com/item?id=21413174
- RossBencina 7y agoSee also: https://edwinb.wordpress.com/2016/10/21/state-machines-all-the-way-down/ https://edwinb.wordpress.com/2016/10/21/state-machines-all-t...
- _bxg1 7y agoMy own realization that I'll probably never do anything on the frontier of language design hasn't killed my interest in designing a language, but redirected it. These days my thoughts drift towards novelty and niche domains. What would be the most interesting way of describing a subset of things? The most fun? The most intuitive? What's a way to break a specific domain down into a vocabulary that lets you populate it while forgetting you're even using a computer? I think there's still a lot to explore even if you aren't shooting for maximum productivity or even general-purpose programming.
- dhash 7y agoothers say typestates, but Scala and Haskell have had IndexedStateT for the purpose of typelevel-state-machinery and it works really well with (somewhat lesser) boilerplate and semantics + FP. To me, it's particularly useful for anything resembling a protocol. Signal based processing is Observables/reactive streams, which provide a sane interface to use. This is (one of) the problem with new languages: library ecosystem access. It's why Scala/Clojure/Kotlin is one camp of languages and Zig/Rust is in another - both Java and C have a ton of great libraries written in them, with ones that add signals-first approaches via libraries.
- hyperpallium 7y ago> no matter what language I create, people will not use it, it it comes from a random github page. Speaking as a fellow sufferer, how did perl, python, php, lua, ruby start getting used? They were pre-github, but jq really did start that way: https://github.com/stedolan/jq https://github.com/stedolan/jq. The key to being used is a usage: a problem to apply it to. If there's a problem that people need solved, and your language is much better than the alternatives, then people will use it, post about it, rave about it. If JSON wasn't popular, jq wouldn't be popular. OTOH your actual interest is in more abstract ideals. This is crucially important work, but you may be right that no one will use it... instead, they'll be interested in the ideas you are interested in. Finding a needed application of your ideas will generate use.
- axilmar 7y ago'Random github page' means there is a plethora of new programming languages to chose from (due to easiness of sharing projects that github allows) and studying of them all to see if they solve any new issues or improve things so much that it makes economic sense to work on this new language becomes increasingly more difficult. In the pre-github days, candidate programming languages were fewer and solved yet-almost-unsolved important problems. The more you go into the past, the easier it is to get your foot in the door.
- hyperpallium 7y ago> studying of them all to see if they solve any new issues But you don't find them that way - you look for a solution to your problem, and you come across them. That's why they say "scratch your own itch"; someone else might have that itch too. You search for JSON transformation, you get jq (that's how I found it, some years ago). You're right that it was easier earlier. But there are new-unsolved-important problems all the time --- and "solutions to problems" radically narrows the search space.
- nunodonato 7y agoInteresting thoughts about signals. Aren't callbacks somewhat similar? (As in JavaScript for example)
- jcelerier 7y agoYou can look into SIGNAL, esterel, lustre, Céu... dataflow programming has been developped since the 80s and has some markets where it is extensively used (avionics, digital audio and digital art, simulation...)