Also, used as a scripting language in the GIMP.
Except RISC-V, because RISC-V. Or, I expect, because they must have gathered statistics from a big chunk of real-world (mostly C and -compatible) code and got a bit fat nothing for the usage of the overflow flag—not because it's useless but precisely because you couldn't get at it from (compiler-independent) C.
If floating point extensions aren't present, there aren't even flags.
-- https://idris2.readthedocs.io/en/latest/faq/faq.html
At this point, the creator has described it as "Pac-Man complete", able and easy to implement a game like Pac Man. (Or itself - it compiles to Scheme but is written in itself.)
Dependent types are still rather new; I believe Idris and its libraries are one of the largest, if not the largest, body of general-purpose software that uses them. (F* maybe?) How to use dependent types properly in a standard library seems be an ongoing development.
(This might sound strange to people unfamiliar with dependently typed langs, but infinite streams etc., servers that "loop forever" doing request-repsonse can still be modeled without TC.)
However it appears that Idris is Turing complete https://cs.stackexchange.com/questions/19577/what-can-idris-... https://gist.github.com/porglezomp/b7bbbecbac1c2289fc890a53d... so I'm confused.
Note also the use of Fuel -- this is to provide "fuel" for the computation, but it's a data structure which can only decrease in 'size' -- which is used by the compiler to prove totality (termination).
("codata" is a way to model 'infinite' computations as data structures.)
[1] https://en.wikipedia.org/wiki/Hacker_News
[2] https://en.wikipedia.org/wiki/Arc_(programming_language)
If you hadn't gone with Scheme, what's another language you'd have considered for this project?
* I really enjoy using numeric towers and it is upsetting to me every time I go to another language where I can't just work with rationals as a default.
* Having statistics functions, a GUI library, and a plot library all part of the standard distribution is wonderful. Dependencies are kept to a minimum, which I appreciate. Everything feels coherent and not over-engineered.
* Poking around in the large standard library was straight forward and not difficult. I added candlesticks [1] to the plot library without understanding much of the plot library's design or implementation details. I think this would have been much more involved in many other languages.
Where I perceive Java as nicer than Racket:
* I wish Racket had real threads like Java. Having futures and places for actual concurrency / parallelism is not as nice.
* I wish Racket had the rich data structures built in as Java has. You need to reach for an external library for a sorted data structure; this is not ideal.
* Java's performance is great and its future is promising. Java already has some great GCs including low pause time GCs, Project Valhalla will add value objects to Java, and Project Loom will enhance the concurrency functionality offered in Java.
I don't have much JavaFX experience, but my perception is that it would be fine and just as "cumbersome" as Racket's GUI and plot libraries.
[1] https://docs.racket-lang.org/plot/renderer2d.html?q=candlest...
These days, I've been using PowerShell for economy data and some options stuff:
For example, the MIR formality [0] project of the Rust programming language to formalize MIR (their intermediate language) was first prototyped in Racket [1], then rewritten in Rust. [1]'s readme give a rationale:
> For the time being, the model is implemented in PLT Redex. PLT Redex was chosen because it is ridiculously accessible and fun to use. It lets you write down type system rules and operational semantics and then execute them, using a notation that is very similar to what is commonly used in published papers. You can also write collections of unit tests and fuzz your model by generating test programs automatically.
> The hope is that PLT Redex will prove to be a sufficiently accessible tool that many Rust contributors will be able to understand, play with, and extend the model.
> One downside of PLT Redex is that it doesn't scale naturally to performing proofs. We may choose to port the model to another system at some point, or maintain multiple variants.
[0] https://github.com/rust-lang/a-mir-formality
[1] https://github.com/rust-lang/a-mir-formality/tree/1f40120f09...
I prefer guix. Every day of the week.
The Guix package collection is also sizeable and growing exponentially-- within a few years, it'll probably outgrow most Linux distros in terms of size.
When you run e.g. Python, the runtime written in C is indeed being executed. If nothing else in the world was written in C except the Python runtime, IMO it would still be fair to say that C is widely used. A security flaw in C compiler could potentially cause a vulnerability in any Python program.
The question was "is Scheme used for anything in production?" and it is correct to say "yes it is used for HN" even if HN is not directly written in Scheme.
The lack of static types was annoying; Typed Racket helped, but was so slow I only enabled it during unit tests (more precisely: Typed Racket functions can be faster than those written in normal Racket, but calling them from normal Racket functions will be slow as it performs run-time checks)
https://github.com/Warbo/theory-exploration-benchmarks/tree/...
I wrote an article about it in Russian (almost 15 years ago), for some reason google translate doesn’t work for archive url: https://web.archive.org/web/20210506123442/http://fprog.ru/2...
scheme@(guile-user) [5]> (exp (* (atan 1) -2))
$9 = 0.20787957635076193
scheme@(guile-user) [5]> (expt 0+1i 0+1i)
$10 = 0.20787957635076193+0.0i
a problem c/c++/java/js/python/rust/go can't handle after decades of progress. even my favorite R can't work this problem. scheme ftw.
>>> from math import atan, exp
>>> exp(atan(1)*-2)
0.20787957635076193
>>> 1j**1j
(0.20787957635076193+0j)
1i is an imaginary number. We are discussing the difficulty in calculating i^i, not whether a language can do atan(1).
Many problems are quite challenging.
It might have been better for you to have been a little more direct-- "I like that exponentiation of complex types just works in Scheme; I don't think that works in other languages!"
I'm not sure why you think scheme is unique in being able to do this-- indeed, it's one of the examples of std::pow on cppreference:
https://en.cppreference.com/w/cpp/numeric/complex/pow
> std::cout << "i^i = " << std::pow(i, i) << '\n';
> i^i = (0.207880,0.000000)
I also hope it wasn't a way to humblebrag that you have a kid in middle school that knows math that lots of other people around here don't (having forgotten it from alg2/precalc or just having trouble reading your comment). Know your audience and prevailing context, and be clear.
> exp(-2 * atan(1))
[1] 0.2078796
> 1i ** 1i
[1] 0.2078796+0iIs your complaint just that some popular languages don’t have complex numbers as part of the core/stdlib?
1. At the REPL, if you type `T` (true), and you get back `T`, the test passes.
2. Define factorial. Then type `(/ (factorial 100) (factorial 99))`. If you get back 100, the test passes.
3. Type `(atanh -2)`. If you get a complex number, the test passes. If you get the correct complex number [namely -0.5493061443340549+1.5707963267948966i] extra credit. Far too many non-Lisp languages return NaN or throw an exception.
Languages that force you to be more verbose and don't let you build your own ultra-powerful abstractions seem to work better for large teams where you can force everyone to adopt a standard style. This makes onboarding much easier too.
I think the same problem applies perfectly well to developers who "create their own little ecosystem of classes and functions nobody else can understand" -- I don't think [0] would be made any harder to understand by having macros involved.
[0]: https://old.reddit.com/r/programming/comments/15s0lp6/how_we... (only picking on it because I saw it recently)
But I guess they look simple and uniform at a superficial, syntactic level. If you can't follow that it's your fault, if you can't follow Lisp code it's Lisp's fault...
Not because of any fault with Scheme per se (afaik), just that contributors to Julia are more likely to know Julia than Scheme, so it makes sense from a maintanence point of view.