267 karma · joined December 3, 2013
Or are you talking about something more specific, like mutable data structures that provide immutable snapshots of the backing data?
One can take this thought further. Red vs green light have real physical properties that affect one's subjective experience of them. For example different colors' physical properties change the way that they are perceived in low light conditions, the way they are perceived when placed next to other colors, etc. So at the end of the day even if hypothetically one person's qualia for red is swapped for green, you end up with a green that acts an awful lot like a red for all intents and purposes in the brain.
Edit: So my personal hunch is that qualia can't be meaningfully said to exist.
Con figma dev environment for me please.
https://advancedweb.hu/a-categorized-list-of-all-java-and-jv...
It seems like it's a real mistake that people make. I guess one could categorize it as a more specific case of misunderstanding a distribution of values. (In the same vein as mean vs median, outlier skewing, assuming unimodal vs bimodal distribution, etc.)
I may be misunderstanding your question, but in general you wouldn't be doing anything type-specific with an Optional's value unless you were in a part of your code that knows the type at compile time. For example, a data structure might return an Optional<T> from a get() method, but all it's doing is returning the T or an empty.
> Besides all references types are already nullable/(optional)... so what's the point?
1. It's nice to explicitly say if a value might not exist than to be unsure if a null object is meaningful.
2. It can force consumers of an Optional to deal with the empty case (versus forgetting to null check)
3. Null might mean something like "this value was accidentally never initialized" versus "I am explicitly indicating an empty value"
4. It can give better developer ergonomics with convenience methods or monadic style (such as with Scala's Option type, where you could .map() on an Option, or merge multiple Options together)
I found this interesting paper on the subject of non-commutative reducers: "Nondeterminism in MapReduce Considered Harmful?" https://www.microsoft.com/en-us/research/wp-content/uploads/...
They can be surprisingly great communicators.
When I felt sick as a child I would do this with the pattern on our wallpaper to distract myself from the discomfort. Edit: Or to help myself fall asleep by doing something similar with the "noise" you see when closing your eyes.
It scares me because it feels similar to the mindset I have when watching a movie. What if I become more interested in the plot than the well-being of the main character?
Software can be art in itself. Consider quines [1]. (Programs that, when run, produce themselves) They serve no real world purpose, and I consider them beautiful. Kind of like the restrictive format of a haiku. (Edit: Or perhaps tesselations, e.g. Escher's work [3])
I particularly enjoy what this artist(?) has done with their 128 language uroborus quine. [2]
Edit 2: I expect the objection will be that this is not functional, or a "product", however the uroboros quine does have practical uses. E.g. as a system stress test. If it were marketed as a stress test, its artistic value would still be apparent to a programmer examining its structure.
[1] https://www.nyx.net/~gthompso/quine.htm
If you're following this paradigm, for all your core objects they:
-Will be immutable, meaning calling methods on them will not change their state. (except for potentially some transparent optimizations, eg in-memory caching)
-Should not have methods that have side effects (i.e. purely functional)
If this is the case, then choosing whether your classes are objects or simple data structs is only a matter of code organization. ie do you want objects to carry around their methods with them, or have those functions live separately.
If you want to share method implementations among objects, you have the option of using inherited methods/types for a more OOP solution, or the typeclass pattern for a more FP solution. (Though the typeclass pattern has significant syntactical baggage in Scala)
In this contrived example, you can tell that formatting a title is not affected by user preferences, but formatting the body is. (And additionally that formatting a body has no information about the other fields of an entry)
def formatRssFeedEntries(userSettings: UserSettings, data: List[Entry]) {
val titles = data.map(entry => formatTitle(entry.title))
val bodies = data.map(entry => formatBody(entry.body, userSettings))
...
}Remote: Yes
Willing to relocate: Yes, within the Bay Area
Technologies: Scala, PostgreSQL, functional programming, JVM, Play! Framework, web APIs, streaming, and more
Résumé/CV: https://drive.google.com/file/d/19Qalh5BVP7wbGxeI8P0eIpUe5b3...
Email: mopierotti@gmail.com
Experienced full stack engineer. I'm open to a wide variety of domains, but I have a special interest in work involving functional programming and/or ML/AI.
1) If you're only using the generated column for filtering/sorting rows, you'd be better off using indexes on expressions? (https://www.postgresql.org/docs/current/indexes-expressional...)
2) Therefore, if you're instead interested in returning the generated columns' values, this feature would be useful in proportion to how expensive the expression you're using is, because you're saving time by precomputing the column rather than computing at query time.
Edit: I can also see the benefit of removing the burden on the person performing the query to have to remember the details of the expression, or in the server case, not having to duplicate the expression across code bases.
At my company we built a UI on top of Slick that lets users of our web app define complex triggers based on dynamic fields and conditions which are translated to type-safe SQL queries.