siefca

This is funny because in this area the most valuable good is NOT knowledge, yet the dinosaurs behave like it was, protecting the wrong thing.

Yes – the "consciousness is an illusion" line often seems to fold back on itself: if it's an illusion, then there's still something it is like to experience that illusion, so we're back at square one.

Also interesting around 09:36. He hints that parts of the scientific community tend to avoid this territory. Intuitively you'd think exploring unknowns should be fun – so why the reluctance?

Speculation: B. Kastrup sometimes frames this as a first-person / third-person divide with historical roots: modern science won its freedom by focusing on third-person, publicly measurable claims, while bracketting first-person and "ultimate" questions.

Not a literal written deal, but a cultural boundary that still bubbles up and shapes what feels legitimate to study – i.e., culture quietly sets the constraints on what counts as rational inquiry.

Author here. This is an essay written in dialogue form about why "AI is/isn't conscious" debates often fail due to level confusion: we mix objective descriptions (models/behavior) with first-person investigation (what it's like).

I propose a stratified view of knowing. "Level zero" is the checkpoint where a thought is directly present in lived experience, independent of whether it was generated internally or externally.

Bankster is a money/currency toolkit (not a ledger, not market data). I needed one coherent model for ISO + custom + crypto currencies, and I wanted the semantics to be "data-first" and predictable – i.e., behavior contracts instead of implicit assumptions.

Docs:

README: https://cljdoc.org/d/io.randomseed/bankster/2.1.1/doc/readme

Contracts: https://cljdoc.org/d/io.randomseed/bankster/2.1.1/doc/bankst...

Agreed! There are many things in IT industry that are prone to this kind of almost magical thinking, and "boundaries" / "tight coupling" is one of them. I realized that when tried to actually compare some stuff I had been doing at work through years, being fascinated with uncoupling things. Well, if you start measuring it, even at the top level (time, people, money spent) then it is so clear that there are obvious tight couplings at architecture level (like data on wire containing some structure or transferring a state of application), and it is very tempting to remove them. But then we may actually find ourselves having a subtle tight coupling, totally not obvious, but effecting in a need of two teams or even two tech stacks and a budget more than twice the size because of communication / coordination costs.

IMHO it is completly doable to do a state transfer with HTML to a mobile device instead of writing a separate application using a separate technology. Then we can deal with coupling server-side, e.g. "view's team" can use some templating system and "core team" can play with logic using JSP-Model2 architecture or something similar.

Even worse^2, client-side validation may differ from server-side validation and from database-side validation. I cannot imagine client-side checking for a validity of a phone number using freshly downloaded database of current carriers and assignment rules in different countries, I prefer to maintain it server-side, even though it could be possible (thanks to guys from Google and their Libphonenumber). But again, I don't trust the client, so it needs to be re-validated later. Then it will be converted to some native data structure on order to make things faster and unified, a later it will go to a database with its own coercion and validation routines just before application will do a query. This validation trusts the format so it will just make sure the result of conversion is correct. But then the query itself carries a validation aspect: when the number must be unique in some context, it will return error, which will bubble up to user.

I remember writing about first official releases of Clojure around 2010 when I was an editor at heise online Poland. At the same time I was coding libraries in Ruby and one thing was drawing my attention: lazy enumerators.

During works on I18n library with pattern interpolation in Ruby I had chosen to use lazily executed methods which could be stacked with the dot operator, giving nice processing pipelines. Around that time I was reading about Clojure and it hit me how much easier would this be in this language, with function composition and sequences, not mentioning the Delays or Futures.

I think Clojure was the first language I decided to learn before conding anything serious. It took me like 2 years to really give it a try, and leave Ruby world, so in 2013 I was making notes explaining how the basics work, and in 2014 started writing a tutorial in Polish called "Poczytaj mi Clojure" (which could be freely translated as "README Clojure" (README meaning both "Clojure, read to me" and "read me [some] Clojure". Through all 2015, during my sabatical, while sitting in a cafeteria almost every day, I coverd built-in special forms, functions, type systems, collections, sequences, macros and more, publishing it online.

In 2016 I started sharing first programs on Github. So I probably need about 2 more years to become advanced, according to "Teach Yourself Programming in Ten Years" – https://www.norvig.com/21-days.html

I remember trying Hydrox for documentation and so called literate programming approach, playing with function arguments and building macros changing positional args into named ones, using core.async and multimethods to build network bots, learning macros and protocols. I've made some free software libraries through the years, and I think I finally am able to build more complex systems.

Since I occasionally have a tendency to go into details too much, or to (re-)write things from scratch, I found Clojure to be the first language giving me enough power to finish those things in less than couple of weeks (1-2 months tops), and go back to a main project to continue. In other lanugages I tried for years I was kind of sinking into sub-projects (which needed to be taken care of) and hadn't enough energy to go back and resume works on more generic, systemic level.