One of the advantages of doing this seemingly weird projection is that you can treat "local" maps (for some definition of local) as flat rectangular grids without introducing a lot of errors: drawing straight lines between two points, measuring the distance / angle between them, etc., just by dealing with a flat piece of paper. VERY convenient, but the farther you are from the center of the projection, the higher the errors that are introduced.
If your planet is tiny, it's very easy to figure out that it's a ball, a child can see it with their bare eyes. The planets in "Outer Wilds" are like that.
Because this planet is larger, smart people trying to figure out how it works used simple tools and measurements to conclude that it's a ball, we know that Greeks and Romans figured this out, I'm sure other civilisations did too.
Greg Egan's "Incandescence" has people who live somewhere where you can discover, in this same way, General Relativity. There's a small but noticeable difference between the simple linear results we'd see for Newtonian physics in rudimentary experiments and what they can observe and they figure out why. Since they have no context for what it means to observe this and have (to their memory) always lived somewhere this happens, they aren't terrified by this discovery any more than we were terrified to discover how our Sun must work - so much hydrogen in one place that it undergoes spontaneous nuclear fusion which releases so much energy that we can easily see by it even after it is no longer directly visible, OK cool, I still need groceries.
It’s easy to see that the surface of the earth is a ball - or at least a curved surface - simply by going to the seaside and watching ships dip below the horizon before they fully disappear.
The ancient Greeks proved it was a ball and measured the dimensions of it using mathematics, but the concept of a curved earth was known to seafarers long before that.
Can you add methods to any type? There is an example of adding a method to a builtin type (string) -- can you add also add a method to a union type?
Any plans to add some sort of enum type? If yes, will it be possible to add methods to enums?
How do you support (or intend to support) Unicode? It says "Strings use ASCII encoding" -- why not UTF8?
The example with a timeout channel does not show how / when the timeout will be triggered. Is this a special kind of channel?
It says "Packages will be synchronized to the $HOME/.nature/package directory" -- will this respect the XDG standard directory structure, which defaults to $HOME/{.cache,.local,.config}?
1. nature can add methods to built-in types, example
fn int.to_string() {
}
I haven't considered whether union types can add methods, so I tested it, and it seems to be possible, but this may cause some unexpected behavior, so maybe I should disable this possibility for now.
type test_t = int|null
fn test_t.hello() {
println('hello world')
}
2. Enum support is planned. I plan to use type declarations. Why hasn't enum been added yet? Nature has adopted a conservative syntax design, and I hope to hear more opinions and avoid affecting existing functionality as much as possible when adding syntax features.
type weekly = enum {}
So methods can be added to enums.
fn weekly.found() {
}
3. UTF-8 should be solvable via a library. I haven't thought much about UTF-8 yet, but if it can enhance nature's usability, I'll implement it as soon as possible. Usability is a key focus for nature moving forward.
4. Select{} timeout handling does require a special timer channel, which will be addressed in the standard library. Currently, it can only be handled via ch.try_recv() and ch.try_send(), which do not block the channel.
5. Actually, this is the first time I've heard of the XDG standard. I will study and understand the specification.
---
I am not an experienced programming language designer, so thank you for your questions. I will carefully consider them.
I can confirm this: I downloaded the old version of the app (on a Windows laptop), isolated it so that it would not auto-update, and then used it to download all my books (after the deadline had passed) and convert them with Calibre, which got rid of the DRM crap. You have to do both the downloading and the conversion on the same computer -- other than that, it worked perfectly for my more than 100 books.
> Fred Brooks, in Chapter 9 of The Mythical Man-Month, said this: Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious. That was in 1975. Eric Raymond, in The Cathedral and the Bazaar, paraphrased Brooks' remark into more modern language: Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious.
Long live Clipper -- one of my first paid gigs. Amazing platform to write (compiled!) console-based applications with a DB living locally or on a networked drive. Something which does not exist anymore as a market.
Same here, good memories, compiling took up to 30 minutes, so during compiling we always went for a game of billiards. Coming back you found out that the compilation had crashed after 5 minutes, fix bug and start the same routine.
I don’t recall compilation being slow. The Clipper app for small businesses that my father created used overlays because it couldn’t fit in memory, yet compilation was still fast (all of this was happening on an XT). Linking, on the other hand, was painfully slow, but one could use Turbo Linker if overlays weren’t needed—TL was unbelievably fast. Later, Blinker came along. It was slower than TL but offered excellent support for overlays (and a bunch of other useful features) while still being much faster than MS Linker.
Same here. I really enjoyed working with Clipper. The fun ran out when my application was bursting through the available memory though. It would be nice to have a 64 bit linux/macos/windows Clipper-like compiler.
