dawidloubser's comments

I guess this will push more and more bloggers to start looking at static site generators like Hugo ( https://gohugo.io/ ) and either hosting themselves, or on one of the many "built in" cloud hosting providers that it supports.

I have been focusing on film-based photography for 15+ years - mostly printing in the darkroom, but also often scanning - and can wholeheartedly recommend Vuescan on Linux.

About 6 years ago, however, I switched exclusively to the open-source XSane [1] and it operates my old scanner(s) beautifully, with all features including the transparency unit.

Try it out if you don't have a highly unusual scanner with driver issues. My workflow involves:

1. XSane for scanning (to 16bit TIFF)

2. exiftool [2] to tag my images with full metadata from my notes: camera, lens, aperture, film, datetime etc just like your digital camera would

3. Darktable [3] to manage my library, cropping, sharpening, adjustments, and tagging

It's a little bit of work - but nowhere near as much as taking and processing 4x5in photographs, and the "digital end results" are very satisfactory.

If I may, an example image: https://www.flickr.com/photos/dawidloubser/35944112383

[1] http://www.sane-project.org/ [2] https://exiftool.org/ [3] https://www.darktable.org/

PlayVS | Senior engineers (front-end, back-end, full-stack) | Santa Monica, CS | Full-time | Onsite

The official high school esports league platform -

We work with game publishers and high school governing bodies to build and operate sanctioned leagues across the country. The challenges we solve on a daily basis are exciting and relevant. We’re looking for top talent to help us create the world’s first full-stack sports platform.

React, Redux, Ramda, Node.js, Web sockets, Redis.

https://www.playvs.com/careers or send your resume and examples of your work to: [email protected]

For anybody else excited when they hear "open" and "AGI" in the same sentence, if you don't know the OpenCog project, the wiki (especially if downloaded in book form) makes for fascinating reading:

https://wiki.opencog.org/w/The_Open_Cognition_Project

I don't quite think so. There are specific laws governing the use of of, say, photographic equipment within a private property.

If a web server, on other other hand, willingly serves content to both a browser being operated by a human, as well as screen-scraping software, then it shouldn't try to prescribe how the screen-scraper uses that information.

It would be the equivalent to, every time, asking somebody that works in the museum if you can take a picture, and them saying "yes", and then wanting to complain (or sue) afterwards.

Actually, it's not. In your analogy, the storefront is completely passive and unaffected.

What is actually happening, is that somebody is walking into the store, asks a question about the stock or the price of the products on sale, which the store employee willingly answers.

Then, all of the sudden, the store wishes to control what you do with the answer that was willingly given to you.

This is clearly absurd - and so too is wanting to control what people do with publically-available HTTP data. If it's public, it's public.

I personally do feel that LinkedIn is within their full rights to attempt to detect and restrict content being served to screen-scraping agents, but they must then accept that screen-scraping agents must be allowed to use any means necessary to impersonate a "normal" user browsing the (public) information that they publish.

This can't be a one-sided freedom.

Well... for some of us, when you say "functional programming", you say "Haskell". And it certainly had all of those features, and much more, more than 20 years ago.

I really like another poster's recommendation that it be called "combinator-oriented programming". Because, while ES, Java, and even Rust, supports rich combinator-oriented programming, I wouldn't dare call any of them functional programming languages.

Though, one has to admit, with ES6 now even supporting elegant currying, coupled with a good functional programming library like Ramda, and immutable data structures (Immutable JS), ECMAScript comes pretty close if you really want it to.

The difference is, any code anywhere can "drop out of" the functional world, whereas a functional language like Haskell enforces functional purity throughout.

Good times to be a software engineer, nevertheless!

As long as Ethereum apps are powered by a deeply-flawed programming language (Solidity) and VM (EVM), this will happen over and over again.

Writing provable, secure software is difficult, and highly unlikely if your environment doesn't force the correct mindset. Solidity (poorly named) was made with the primary goal of being easy for JavaScript / Node hackers to use.

The cost of this is now illustrated through the repeat 'hacks' of bad 'smart contracts'.

Agreed. As a photographer, I use and love Guetzli, and it offers a bona fide size reduction of more than 30% over typical JPEG compression algorithms at a similar visual quality level.

But it's extremely computationally-intensive, taking over a minute to compress a single web-resolution image on my i7 laptop.

I can't see it being practical in a high-volume server scenario.

Ever since reading this essay 14 years ago (has it really been that long?!) I have always thought:

Haskell. He's talking about something like Haskell - but with whatever additional powers of abstraction and simplification mankind manages to dream up.

I say this, because I have yet to find such an elegant way of expressing computation. But, on the other hand, I have yet to find a "serious" language with as many performance land-mines, which possibly might just not matter given orders of magnitude more memory and computing power.

Given a couple of orders of magnitude, who cares that String = [Char]. It's damned elegant.

For everything else, I'll bet we will use the "C" of the 21st century - Rust :-)

JavaScript will probably continue tracking functional languages like Haskell for many years, albeit remaining without the type system that make them truly useful.

Thank you for re-posting this long-forgotten essay, and taking me down memory lane...

WASM is not positioning itself as a high-level application development platform. It's specifically meant to co-exist with ECMAScript (which is the app "glue"). It's meant to out-source computationally-intensive functions to, nothing more.

If you embrace only the good / modern parts of ES6/ES7, you can really write elegant, modern, functional-style code. Not sure there is much left to complain about, other than the lack of built-in type system, which many others (but certainly not me) argue is a good thing.

WASM is going to make Rust [1] shine like nothing before. I love that all the Mozilla articles keep mentioning it together with C/C++.

Unfortunately, writing Rust is an order of magnitude more difficult thatn writing ECMAScript, so hopefully it doesn't create a negative response from hordes of ES developers that want to check out this WASM thing.

But it's so much more suited than C/C++ (the other obvious candidates). In a nutshell, WASM is not really intended for higher-level languages with garbage collectors, etc. For that kind of work, I'd stick with ECMAScript.

[1] : https://www.rust-lang.org/

Java's type system and FP features are really weak compared to Haskell's :-) But it compares favourably with ES6's, until you start using ImmutableJS, and ES6 currying. Then Java lags far behind...

I've always been deeply into it, and using it for years at work, so no good off-hand reference. I'd be picking one as random as any web search that you'd perform, sorry!

I should never have learnt Haskell. It messes with your mind [1] whenever you write in any other programming language, yet you can hardly ever use it in practice. Well, certainly here in South Africa.

[1] Obligatory link: http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/0441...

I think you're missing the core use-case of WASM. It's not for general app development, which will stay with JS.

It's meant to provide plug-able, high-performance functions for heavy computational tasks - crypto, game rendering, heavy in-browser data analysis, etc etc.

I double JVM in WASM makes sense at all - though somebody will probably do it in anyway. WASM is not meant to be good at Garbage Collection, etc. It's not a design goal at all.

Hear hear! Java was on a great trajectory before being stagnated by corporations and politics. Such a pity, because now we have to re-invent it.

The silver lining, is that many things usually get better the second time around. Let's see what WASM hold - it's pretty limited in its current form.

As a Java engineer, I'm enjoying ES6/7 development much more these days.

I wanted to point out, however, that Java 8/9 has excellent support for basic functional programming features, with an equally-nice syntax for lambdas, but with a good type system (via Functional interfaces) to boot.

The thing that I get hung up time and again, with ES6/7, is lack of a type system. We write some complex ES6/7 + Immutable JS apps (e.g. in the financial services domain), and haven't managed to extract full value from Flow or TypeScript just yet, due to library constraints etc.

Kinda like the Java VM, 20 years ago :-)

I would like to argue that, in most of these cases, it's not "code quality" that is at fault, but "design quality" (before coding) - which is often absent entirely.

The problem with design, in software, is not that most people forget to do it. It's that they never learn to do it. It always comes back to bite you.

I don't want to start a discussion on design, and how most people mess it up because of lack of skill or experience therein. But hacker culture seems to be allergic to design, and hacker culture seems to be what everybody strives for these days.

It's been interesting to watch so many ECMAScript / React libraries inch towards a Functional-reactive / streams-based paradigm. I can't wait to see which one becomes the de-facto standard, like how Redux is currently the de-facto implementation of the "flux" pattern in React applications.

Of course, https://cycle.js.org/ is one of the original attempts at a pure and simple implementation, and if you haven't studied it yet, it's wonderfully enriching to understand and play with - even if you don't end up using it in a project. (you may use Cycle.js with React, but it is agnostic of UI library)

As a software engineer in the third world, doing work mostly in the corporate space, I observe a near un-crossable chasm between the mindset required to understand and use Functional / Functional-Reactive platforms, and the mindset of your typical developer - doing .NET, Java EE or Spring. I fear it may be some time before we see adoption of libraries like these in the mainstream "day job" software world.

I don't mean to say that FRP is always "better" - but rather that it is beyond the comfort zone of typical corporate devs, despite the simplification its adoption may entail. Don't know if engineers outside of South Africa encounter the same problem?

Will this, by any chance, increase the number of open-source apps available in f-droid? Every now and then, I spot a wonderful app that is only not available due to dependencies on one or two proprietary Google APIs or components.

I'm trying to run a totally open-source android installation, and have opted-out of Google entirely. It's worked out fairly well so far, but the app choices are fairly limited, of course.