More seriously though, it's a very central topic to the software world since many things in this world deal with how to work with information. And note taking is a very central thing when working with personal information.
48 karma · joined January 7, 2017
More seriously though, it's a very central topic to the software world since many things in this world deal with how to work with information. And note taking is a very central thing when working with personal information.
My take on the assessment of pain is that any entity with some self sustained direction (in life) will be able too suffer or feel pain when faced with sensations that signal an obstruction to that direction. If the entity is able to self correct the path after such sensory input, I claim that the entity can experience pain.
With that in mind: A calculator has no self sustained direction. And no sensory input to help with self correction either. So it naturally cannot feel pain.
A chicken has a self sustained direction. It lives (moves on its own) and at least want to continue to do so. It also has the ability to self correct when given sensory input. So it can feel pain, and you can (given the reasoning above) be cruel to chickens. Even without an assessment of whether the chicken is conscious or not.
To be conscious, to go into that as well, is in my book to be able to use reason and to be able to reflect on things. So that new sensory inputs are created and assessed based on other already experienced sensory inputs. I.e. to be able to self adjust ones path (in life) seemingly, from an external observer, without any new sensory input.
With that definition one should be able to construct experiments with chickens to decide whether they are conscious or not, or merely acting subconsciously, autonomously.
With that definition of consciousness it should also be possible to define an AI that is conscious. And given the definition of pain above, it should also be possible to inflict pain on (and be cruel to) an AI. The morality of inflicting pain on different subjects is a different story though... :-)
Cheers
Definitely would be great to see this project gain mindshare and funds. Also, for the ones who wonder what it is they reach when clicking the link for this "Show HN", there is an about-post here: https://logseq.com/blog/about
On a more serious note: I see no issue with software being a service and costing money if it's built on a standard that leaves the data in the owners hands and in the owners own structures. I.e. Markdown files synced using infrastructure like OneDrive/Dropbox/whatever with some nice features on top of it and a nice UI can cost whatever and no one should complain. Because if that software goes away the data is in the owners hands and in a standardized format supported by many other tools.
That should be the preferred way we build software btw. And to take it to the next level we should create more general purpose (and standardized) database tools that are user friendly, treat them in similar fashion as files by syncing with user owned Infrastructure and we might just get to the point where more rigid data structures can be used in a similar manner as what I described above for files. That future would be great.
It seems to me what you're complaining about is less about Microsoft and more about capitalism and greed in general.
When taking about inflation it's also always good to remind one self that the pool of money also changes. And the fact that housing usually is connected to mortgages, which in turn expands the amount of available money. But this paragraph has nothing to do with your comment so I'll just stop there!
- Org-mode data format
- Software implementation that understands the data
- Emacs
- ...
The syntax is very well thought out as well. Specification here: (https://orgmode.org/worg/dev/org-syntax.html)Maybe it's a bit late to hope for wide software adoption for the org-syntax. Markdown has in a way taken that space already. But... I'm still hoping! ;)
If the data for a particular need of mine was in a standardized format, it wouldn't matter which tool I used as I could switch at any point in time.
The post mentions Excel as the go-to tool. What I would have liked the author to be able to say instead is - "use spreadsheet-data as the first data-container for the data needed". If a better data-format, more specialized for my need exist, migrate to that instead. The tool to interact with that data should be the secondary choice. Something that could be reevaluated at a later time if needed, without loosing past data due to lock-in effects.
Double thumbs up to Kungsgeten!
Indeed, PowerShell is onto something. Such delight it is to work with. Especially when you start to build your own tools for it.