HN user
Brown noise in Chuck. Adjust the filter cutoff (freq) to your desired comfort level.
CNoise noise => LPF lpf => dac;
noise.mode("flip");
lpf.freq(120);
while(true) {
1::second => now;
}quickjs [1] has native support for Cosmopolitan, is meant to be easily embeddable, and is included as part of the standard Cosmopolitan distribution. It looks like qjs also has patches for recent-ish versions of the Typescript compiler as well. Someone has made a nodejs-style project called txiki.js [2] using vanilla qjs. Maybe it would build with Cosmopolitan with some tweaking. But if you're thinking of packaging a whole browser engine like Electron that might be a Sisyphian effort.
[1] https://bellard.org/quickjs/ [2] https://github.com/saghul/txiki.js/
Yes! With spork/netrepl and Conjure in Neovim
Apparently there's also a data processing library for Nim called Arraymancer[0] that's inspired by Numpy and PyTorch. It claims to be faster than both.
Some people don't like systemd because it rolls a bunch of other functionality beyond 'just init' into a giant monolithic beast. The advantage is that distro maintainers are able to present an extremely usable and stable system like Ubuntu, Arch or any of the other mainstream distros. For most people that just want to use their computer to do regular stuff like browse the internet and edit photos and stuff, systemd or otherwise doesn't really matter because you pretty much never need to touch those parts of the system. Alternate init systems are for power users or people with particular constraints. For example, one of the reasons Alpine Linux is able to be so small is because it uses OpenRC instead of systemd.
Personally, I use a non-systemd distro because my computers all have tiny-sized HDDs by today's standards and I hate having to read a bunch of documentation every time I want to create a new system service. To me, it's easier to just write an ordinary shell script. I don't need all the ridiculous logging capabilities that systemd offers. Regular old plain text is enough for me.
If it is indeed a union mount mechanism, then that's truly a remarkable feature. Reading the documentation makes it sound like something akin to an symbolic link but perhaps not in the actual filesystem; I still can't tell if it's implemented in the kernel/FS or just the shell (or to what extent the two are integrated). If it's just the shell then this seems to be a shining example of where the POSIX interface is holding us back. In Linux, they've tried to implement union mounts a number of times (as UnionFS, aufs, and OverlayFS) because it's almost too complicated to get right for Unix-style filesystems and you need a bunch of kernel-level code. Do you happen to know if it was possible to create the ASSIGNs programmatically? Does deleting/renaming files in the ASSIGN work like you'd hope?
Like a union mount?
export VAR="$VAR:whatever else"
The problem isn't with the mathematical concept of monads, it's that Monad is a typeclass in a hierarchy along with other totally abstract category theoric classes introduced at different stages and people use them with varying levels of knowledge and ignorance so things are placed arbitrarily and there are a bunch of ambiguities. Just look at this [0] mess. Is that really what we want?
[0] https://wiki.haskell.org/wikiupload/d/df/Typeclassopedia-dia...
Well said. This is exactly my gripe with Haskell monads. There are too many places where the hierarchy isn't uniform and there are a bunch of special monads like IO and List. It leads to the same ambiguous "is a" problem of complicated OO hierarchies and is one of the reasons they don't compose well.
The ironic thing is that these algabraic effect systems have a feel/control flow pattern that's quite similar to exception handling from the OO languages or interrupt handlers in low-level code.
It's much easier to just say "this piece of code is impure, it may do X, Y, and Z and if so then ..." than to try and shove everything ad-hoc into the abstract math tree. But then you lose the purity of your language and it's really awkward in a language whose primary concern is purity. That may be a reason why algebraic effects seem a bit more natural in OCaml.
The profusion of Category-theoric abstractions and some of the more recent purely functional norms in Haskell are like the PhD-level version of `AbstractVisitorContextFactoryBuilder` which, aside from all the unnecessary cognitive load, lead to enormous dependency graphs of the npm variety.
Personally, I wonder if uniqueness types in languages like the sadly forgotten Clean (a close relative of Haskell) would have been better than the whole Monad/Arrow thing. All of that abstract theoretical stuff is certainly fascinating but it's never seemed worth all the bother to me.
On the other hand, in SML you get all the benefits of strong HM type inference/checking, immutability by default, etc, etc.. while also still being able to just `print` something or modify arrays in place. SML's type system isn't higher-order like Haskell's so its solution to the same problem Haskell solves with type classes isn't quite as elegant but otherwise SML is the C to Haskell's C++.
I believe the 'problem' that it solves is universal network transparency between pieces of anything. It's a library that can be used from basically any language that has a C FFI on any system with a C compiler to do IPC with anything else supporting same using a uniform and relatively simple API.
In addition, every closure is also a 'state container,' as it were. This is how some functional languages e.g. Erlang emulate mutation. A function holds the desired state in a closure and evaluates to a new function closure with updated state. It's also how a stateful object system can be trivially implemented in Scheme.
A few of pieces of the Erlang OTP infrastructure are actually just an elaborate mechanism to reintroduce global mutable state i.e. the process registry or Mnesia.
In my state, most of the programs the community colleges offer are aimed either at credential acquisition or for transfer to a university; there are no four year programs. However, many of the teachers at these schools are also PhDs moonlighting from local universities where they teach upper-level subjects and the community college offers a handful of classes that are at the 300/junior level for certain subjects. The thing that's really missing from the community college curriculum that would shake up the university pricing model is the ability to get a Bachelor's degree. At least in my state, it doesn't seem like there would be too much of a stretch to accommodate the additional educational resources it would require. Some people go to a university because they want access to first-class facilities, professors, student networking, and the like. In fact, the tuition at my local university more than doubled after they managed to get their basketball team into the NCAA Final Four one year. But many people don't care about this kind of thing; they just need their 'certificate of passage of this particular social ritual'.
When I first heard of this, I was also quite intrigued. But I wonder if it might actually be vulnerable to some of the darker patterns of human 'social markets' if implemented in its freest form; we already have something that has the structure, if not the character, of a liquid democracy: Twitter. In such a system, people with a lot of allocated votes would end up with considerable de-facto power that would nonetheless be constantly volatile to emotional outburst no-confidence tectonics if you were allowed to re-allocate your vote at any time/the voting distribution was monitored in real time. You'd also almost certainly end up with Zipfian popularity gravity wells where some representatives were more popular simply because they're more popular, perhaps without genuine merit.
My point is that mv is a compiled C program, not a shell builtin or piece of shell syntax, that you may nonetheless call in a shell script to extend the functionality of the shell. rename is another such compiled C program. To say that it's awkward to batch rename files with mv may be true, but that's a deficiency of an external C program being used beyond its original purpose. Since we're using external programs anyway, you can just use one that's actually designed explicitly for the purpose renaming files.
By your own logic, your own UNIX solution to the file renaming problem is "not shell" since it uses the mv "utility". Or do you mean rename is not POSIX? The shell language certainly is lacking for almost anything beyond its original purpose of gluing together pipelines/graphs of UNIX commands; it's a largely unintentional DSL from the time before many modern notions of language ergonomics had become established. The point is, there is an array of solutions to reduce the nuisance of having to deal with the language equivalent of a stone knife such as programs like rename or actual general-purpose scripting languages. Sure, you can cut most things with a stone knife with enough time and effort but why would you if you have a bunch of sharp, metal knives within easy reach?
Linux, at least, has rename(1) where you can just use the same syntax as Windows ren.
Just out of curiosity, what was the purported outcome/why wasn't it worth it?
I once made something similar after reading a blog post here on HN [1] just to see how easy it is to make something like this. Mine [2] uses passphrases to generate keys with the Argon2 algorithm and then uses NaCl's secretbox for encryption. I also made a version for use on streams. It's not up to snuff for industrial use, but it's really easy to use if you just want to encrypt some files with a password and also very simple if you want to modify it for your own purposes.
By MIT scheme, do you mean MIT/GNU scheme? A few schemes implement their debuggers in terms of call/cc (or delimited counterparts) and exceptional conditions like errors or breaks hand control to a new 'depth' of REPL where anything in the environment can be inspected (or redefined) in-context before possibly trying to continue or doing any unwinding. If your scheme has no debugging apparatus, it shouldn't be too hard to implement something a little more useful than sprinkling in print statements. Even without wading into continuations, implementing a macro that does tracing should be possible.
Already been patched in any case.
https://gitlab.freedesktop.org/xorg/xserver/commit/50c0cf885...
In context, I believe the author means that having a build system which splits into independent, simultaneously executing processes (such as `make -j 5` or some such) tends to have an advantage over ASDF's monolithic process model which doesn't take full advantage of multiple cores/CPUs.
Yeah, it only teaches you about term rewriting, boolean logic, iteration vs. recursion, algorithm complexity, higher-order functions, data structure design, closures, generics, statefulness, environments, mutability, concurrency, stream processing, modularity, interpreter design and implementaion, lazy evaluation, nondeterminism, logic programming (i.e. search/constraint), low level computer architecture, memory models, and the design and implementation of virtual machines, garbage collectors, and compilers. Just a total waste of time unless you're doing Lisp.
After looking up a couple images -- that game appears to use Wang tiles. They're also sometimes used for terrain textures in video games to make seamless mosaics with less obvious repetition.
Worse is better/creative limitation/blub paradox: Smalltalk, like Lisp, is too powerful; you can do essentially anything you desire in a bunch of different ways. Too much flexibility makes it harder for a clear use case to emerge and having too many choice points only makes pathfinding through the solution space more difficult unless you've made a bunch of firm decisions beforehand. Other languages like Go or Python make many of these decisions for you. It seems like the ideal pattern in these ultra-expressive languages is to construct a much more restricted DSL which can ultimately lead to a proliferation of completing solutions a la the JS ecosystem.
Inner platform/walled garden: Almost all Smalltalk systems basically implement their own operating system complete with their own integrated graphics system/window manager, process scheduler, and so on. It's an amazing environment for creating applications but it doesn't play well with the outside world and there isn't a straightforward way to 'shake' an image down to just your application. Deployment usually comes with the overhead of the entire Smalltalk system and interop with native can be somewhat limited. Imagine if Java applications only ran within Eclipse.
Zipf's law: The popular languages are so popular that their communities generate their own gravity (i.e. lots of effort tends to attract more effort). Despite Smalltalk's many appealing qualities (ergonomics, simplicity, maturity, robustness..) it stands in the shadow of giants; many people don't even know it's there or can't invest the effort to give it a shot so it never achieves critical mass.
This appears to be a system in the Smalltalk lineage but based on Node and JavaScript and currently seems only to target MacOS. It uses Self/Smalltalk's UI system and is based on ideas by Alan Kay (of Xerox PARC fame and one of the creators of Smalltalk). The web interface looks and feels similar to a web-capable Smalltalk variant called Lively Kernel[1] but in a less-mature state of development and with more of a focus on text.
For those wondering what it's like to program in Pharo or why there aren't a lot of code snippets floating around in Pharo materials: it's because the way you program in Pharo somewhat different than most languages. Pharo is an IDE in the true sense, i.e. while it's technically possible to open up a workspace (text editor) window and write a new class all on one screen this is not how things are done in practice.
Programming in Pharo is usually done either in the class browser or the debugger so that you're only ever seeing the code for one method (called a message in Pharo) at a time. Pharo and other Smalltalk variants tout simplicity of syntax but leave off the fairly complicated class hierarchy and message coupling semantics ergo the necessity for an extremely powerful browser. In the browser, messages for each class are further separated into 'protocols' such as methods for 'accessing' or 'initialization' (these are not part of the Smalltalk syntax, just a convenient layer of organization). At each level in the hierarchy, the Pharo code browser gives you a nice template to edit when you want to make a new package, class, or message. The overall effect is that you're only ever working with a handful of lines at a time and, indeed, Pharo will warn you if it thinks your message is too complex. Doing things this way actually makes everything quite manageable. One of the nice features of being pure OO is that everything is a pure black box so you just need to know that a class exists and take a peek at its interface to use it effectively.
To that end, Pharo actually has an excellent search tool that's not present in other Smalltalk variants like Squeak or Cuis. It does some kind of intelligent voodoo and can find anything from definitions to instantiated objects to senders and receivers of a certain message and so on. You can also open up a playground window to experiment with whatever code in the REPL style. But it's actually a little bit more robust than a traditional REPL because of the pure OO nature of Smalltalk. The thing you get back from evaluation isn't just some text. It's an object with all the associated possibility of reflection and manipulation (which can all be done from a UI, not just from evaluating more code).
One of the things Pharo does better than almost every other language is debugger integration. Pharo is like LISP in the sense that you can start an application, have it encounter an error (or just pause execution at will), drop into the debugger and change some stuff, reify whichever execution stack frame, then resume the program as if nothing ever happened. This is the essence of the other common Pharo workflow: write some partial code and then fill it in incrementally in the debugger until you have a fully functional and bug-free application. In addition, Pharo has its own robust unit testing system called Sunit that, coupled with the debugger workflow, creates a fantastically ergonomic TDD experience.
No matter where you are in the Pharo environment, Smalltalk code gets full treatment (E.G. syntax highlighting, code completion). So what does the syntax look like? Well, it actually has that concatenative elegance of Forth plus a few other constructs. Pretty much everything is a message send. Message sends come in three flavors: unary, binary, and keyword. Constructs like conditionals are also just message sends. In addition, there are first-class lambdas (called blocks in Smalltalk). Here's the canonical factorial program:
"Factorial function" fac := [ :n | (n = 0) ifTrue: 1 ifFalse: [ n * (fac value: (n - 1)) ] ].
where " ... " is a comment, ':=' is assignment, '[ ... ]' is a block, ':n' is the block's argument, arithmetic operators are actually binary message sends, things like 'ifTrue:' are keyword message sends (unary message sends are similar but don't have colons or parameters e.g. 'SomeObject new.'), and the statement is terminated with a period. Apparent recursion is fine because Smalltalk uses late binding. Aside from some syntax for strings and class declaration, that's basically it.
Pharo also has a lot of other nice features such as keeping a log of code changes in case of program crash or power outage, an integrated package manager/version control system, and optional git integration. It's all pretty easy to use and overall the system is quite impressive with a high degree of polish and decent performance (comes close to or exceeds node in my experience). However, as others have stated, it's a walled garden. All UI interaction happens within the Pharo environment with no option for native. If you want to break out on UNIX, you have write some kind of server and use sockets or the filesystem (which isn't a huge handicap in the grand scheme of things). On the other hand, application deployment is a little iffy. There's no readily apparent scheme to pare an image down to just what your project uses and then distribute that; users would have to install your package from within their own Pharo environment.
You should have a look at Void Linux[1] (if you ever wanted to give Linux another shot). It uses runit for init instead of systemd and offers musl as an actively supported alternative to glibc. Its package manager is similar to the one in Arch in that it provides both rolling-release binary packages as well as a ports-style build system. Void also incorporates OpenBSD's LibreSSL by default. Everything else is kept as minimal and simple as possible.
Just want to add a little volume to the general opinion here that collecting user data, no matter how anonymous, is a terrible idea for a product whose only appealing quality is that it respects its users privacy.
Data is both highly alluring and addictive as evinced here by Mozilla potentially willing to shoot itself in the foot to get some. What's to keep this from becoming a frog in a boiling water kind of situation? How can I trust that Mozilla is going to adhere to their own stated standards? The easiest answer is that I won't have to because I can just use something else. Personally, the only reason I use Firefox is because it's slightly less convenient to set up a secruity-patched version of Chromium.
Other people in this thread have made the excellent points of the fact that not enough people opting in to data collection is in itself a critical piece of data. Moreover, things such as "Which top sites are users visiting?" can be answered by looking at data from page ranking services and then they can go to those sites on their own testing equipment to answer their other questions. A little investment in acquiring this data by not spying and maybe getting a wider array of testing equipment is probably less costly than the potential for loss in market share that they're already struggling to hold.