willtim

> I really enjoy working with python over any other language.

I assume you mean, "over any other language I have tried" ?

As someone with a mathematical background myself, I am always surprised at how many data scientists and quants are ignoring more mathematically principled languages like F#, OCaml and Haskell.

I am more productive in a language with an expressive type system (e.g. Haskell) than one without. Thinking about types not only guides me towards a working solution quickly, but the checker catches all my minor mistakes. In Haskell, you can actually defer all type errors to runtime if you want to. But I have never felt this makes me more productive.

The issues discussed in that link, such as concurrency, lack of atomicity and failure are all factors that make bi-directional sync a hard problem. Yes POSIX provides few guarantees and so that burden rests on the application code above. The formal model must consider the race conditions and failure modes, it is not "the easy part". I do acknowledge there is a modelling gap to overcome and some problems with POSIX, but I disagree that its the hardest part of the problem.

That's really the job of the filesystem to protect against corruption using checksums. ZFS will do this and hopefully more will follow. I suppose a file sync tool could detect a change of contents with no change of mtime, but that would be expensive.

I disagree. POSIX, although somewhat dated, has provided a good enough abstraction layer for filesystems and OSs. My proof of this is the number of different and successful filesystems for Unix/Linux. If the abstraction didn't work, everyone would be forced to use the same filesystem.

The issues and subtleties are with bidirectional sync. It is not "the easy part". Dropbox didn't get it right in the past, we have no proof they have it right now.

> there's a million fiddly things to get right, and Unison hasn't had that much usage

Unison is the only bidirectional sync tool that I trust to get the details right. It is backed by a formal model with various proofs of correctness. Such models are also easily representated in OCaml; which I can assure you is more than a fine language, especially if one cares about correctness. Dropbox has struggled to get these details correct in the past (see the paper "Mysteries of DropBox", by Unison's author Professor Benjamin Pierce). TLDR, Pierce teaches these Python hackers how to fix their broken code.

Yes Java has many issues, but writing complex GUI apps in plain C in this day and age is the wrong thing to do. The early Gnome founders learned this the hard way which led to Mono, which at least had automatic memory management. I fear this OS is destined to become like Samsung Tizen, which is riddled with security holes. It's not as if we don't have excellent libre languages, e.g. Rust and OCaml.

I applaud the open nature of this phone, but using the Gnome stack looks to me like a mistake.

My time is not free

To quote Dijkstra, testing shows the presence, not the absence of bugs. If you want to actually prove the absence of these classes of bugs then you need a static type system.

It's a nice error message, but it's a runtime error, it might not happen until weeks into production. It's technically just a crash with a useful error message. "strict typing that enforces type declarations" is generally called static typing, and does not necessarily always require annotations or declarations. It spots such errors at compile time using static analysis.

What language are you going to try and improve? Add static types to Python? Or make Java purely functional? Often one needs to start again. Mirth looks much better than most.

I was making the point that this would never get to Emacs mainline. But sure, no reason why it couldn't end up in a fork, but the fork is not going to give you the same "taste of freedom" ;)

Quoting the Emacs web site:

"To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves."

I've been working on my own encrypted and de-duplicated backup solution using libsodium. It's early days and progress is slow with limited spare time, but it works well enough for my own use already. I wanted to avoid any closed source or even lesser-used open-source encryption.

https://github.com/willtim/Atavachron

I respect this position, but we must also recognise that it makes Go less of a general purpose language (as is often claimed) and more a domain-specific language (with the domain being systems/network programming).

Why not allow call-by-name parameters to functions? That would enable library authors to build whatever error handling conveniences they wanted. This feature dates all the way back to ALGOL-60.

Sure the entire input list will need to be consumed, but not every element of the output will need to be determined if we are only taking the top 10.

Laziness enables many compositions to work efficiently, whereas with a strict language, you'd have to fuse the operations to get the same efficiency. More examples here: http://augustss.blogspot.com/2011/05/more-points-for-lazy-ev...

This was probably the theory behind their decisions. While I agree that the lack of expressiveness might discourage some incidental complexity, for example premature or unecessary abstractions, the inherent complexity of a problem will remain. Removing expressive power, in general, will lead to ad-hoc and cumbersome workarounds. For example, look what the Kubenetes codebase had to do to work around the lack of generics: https://medium.com/@arschles/go-experience-report-generics-i...

Sounds like you perhaps have experience of dynamically-typed languages? Haskell is statically typed, compiled, has a scalable multi-threaded runtime, a very good FFI; and was designed around the notion that large programs should be built by composing small programs.

It's around 10 dollars, but then I have less than 1 TB. I recently starting backing up my RAW files remotely, so this number is set to increase significantly (!) I am very interested in S3 alternatives. I haven't looked at the Amazon Glacier options either, but I suspect the retrieval times make it awkward to query/verify backups.

I disagree with the author's explanation as to why all questions are algorithmic. I suspect the real reason is due to the US dominance in tech and the popularity of algorithmics in US academia. Indeed the parts of computer science to do with logic, formal methods, semantics, mathematics of program construction etc are, I am told, often described in the US as "Eurotheory". This is a great shame. A new graduate arrives at Google fully trained in algorithms as mandated, but is unlikely to need to implement any of them during their career. It is far more likely that they will need to glue existing systems together, consume APIs, author APIs etc. "Eurotheory" would much better prepare them for this.

As an example, consider that we could be asking questions on API design: get candidates to work through their semantics/axioms (introductory forms to create objects, methods to transform and eliminate them). Get them to write out high-level testable properties such as the way objects compose, associate, commute etc. Using types to enforce invariants etc

A huge shame. I backup my optical media to S3, but I also use M-DISC "mineral discs" which hopefully will last much longer. Sadly they were not available back then.

Yes, but it's still a great pity, as Haskell, a descendent of ML (the "meta-language") is a suberb fit for writing a compiler.

It depends entirely on whether the big project still has an elegant and complete formal grammar. Hand-rolled parsers are only common in industrial languages because many have grown to be far too complex and ad-hoc, requiring e.g. additional analysis and disambiguation during parsing. It is not a situation to aspire to.

Sounds like he (edit: or more accurately, the university) has hasn't taught them enough functional programming and Haskell.

I'm a Haskeller, but it's great to see OCaml improving significantly with every release. It's a win for typed functional programming in general.

My company proxy kept triggering endless Google captcha games. I switched to DuckDuckGo.

I'm not sure there is consensus that Mars is much more likely to have had life. As the article states, Venus had liquid water for 3 billion years versus 400 million for Mars.

Using C# as an example, foreach and IEnumerable are baked into the language as is try/catch and more recently Async/Await. These are all just library functions in Haskell and often more general (e.g. forM in Haskell works for any Monad not just IO). Because they are library functions they can be changed/customized very easily. In C#, how could foreach be made to support a different stream type, exceptions be made checked or Async/Await be made to suspend across stack frames?

For this reason, Haskell is probably closer to a general purpose language than many of the imperative systems programming languages (especially Go).

> if you see Spring as existing to correct issues with the underlying Java language, then I'm highly skeptical that you've ever had meaningful experience with either one.

Let's please avoid personal attacks if at all possible. Spring started out with the dependency injection framework and "aspect-oriented programming". It was marketed as an alternative to EJB. Web frameworks and other add-ons came later. If you don't see DI and AspectJ as working around Java's weaknesses, then I encourage you to try a more expressive language.

In an expressive language (e.g. Clojure or Haskell), DI and AspectJ could be, for example, replaced by reifying a program as data and using modular interpreters. One interpreter using mock data, another talks to the database, uses transaction boundaries and logs. This sort of solution is unfortunately just not very practical in Java.