Riverfount

Um espaço para meus devaneios, sejam em TI ou em Filosofia

Na prática de desenvolvimento, é comum ver blocos de código duplicados, copiados e colados em diferentes partes de um sistema. Parece inofensivo; afinal, “funciona”. Mas com o tempo, essa abordagem se torna um problema sério. É aqui que entra o princípio DRY — Don't Repeat Yourself — um dos fundamentos mais importantes da engenharia de software moderna.

O que é o princípio DRY

O princípio DRY afirma que cada informação, comportamento ou lógica de negócio deve ter uma única representação dentro de um sistema. Repetir código é repetir responsabilidade, e cada duplicação se transforma em um ponto a mais para corrigir quando algo muda.

Aplicar DRY significa centralizar responsabilidades, promovendo clareza, consistência e reutilização.

Por que o DRY é essencial

  • Manutenção simplificada: Se uma regra existe em apenas um ponto, basta atualizá-la uma vez para refletir sua mudança em todo o sistema.
  • Legibilidade e clareza: O código torna-se mais previsível, direto e fácil de entender.
  • Consistência entre módulos: As mesmas entradas sempre produzem as mesmas saídas.
  • Reutilização e escalabilidade: Abstrações bem definidas permitem evolução sem retrabalho.

Aplicando DRY na prática

1. Evitando repetição com funções

Sem DRY:

# Cálculo duplicado de imposto
def calcular_total_produto(preco, imposto):
    return preco + (preco * imposto) 


def calcular_total_servico(preco, imposto):
    return preco + (preco * imposto)

Com DRY:

def calcular_total(preco, imposto):
    return preco + (preco * imposto)

Agora, produtos e serviços usam a mesma função, reduzindo manutenção e riscos de inconsistência.

2. Aplicando DRY com classes e herança

Sem DRY:

class Funcionario:
     def __init__(self, nome, salario):
         self.nome = nome
         self.salario = salario

    def calcular_bonus(self):
        return self.salario * 0.10
        
        
class Gerente:
    def __init__(self, nome, salario):
        self.nome = nome
        self.salario = salario 
    
    def calcular_bonus(self):
        return self.salario * 0.20

Com DRY e Orientação a Objetos:

class Funcionario:
    def __init__(self, nome, salario):
        self.nome = nome
        self.salario = salario
        
    def calcular_bonus(self):
        return self.salario * 0.10


class Gerente(Funcionario):
    def calcular_bonus(self):
        return self.salario * 0.20

A herança elimina código repetido e mantém a lógica consistente entre tipos de funcionários.

3. Centralizando configurações

Sem DRY:

API_URL = "https://api.meusistema.com"
print("Enviando dados para https://api.meusistema.com")

Com DRY:

CONFIG = {
    "API_URL": "https://api.meusistema.com"
}

print(f"Enviando dados para {CONFIG['API_URL']}")

Quando for necessário mudar o endpoint, basta atualizar apenas um local.

4. Evitando duplicação de dados

Sem DRY:

usuarios = [
    {"id": 1, "nome": "Alice", "email": "alice@example.com"},
    {"id": 2, "nome": "Bob", "email": "bob@example.com"}
]

emails = ["alice@example.com", "bob@example.com"]

Com DRY:

usuarios = [
    {"id": 1, "nome": "Alice", "email": "alice@example.com"},
    {"id": 2, "nome": "Bob", "email": "bob@example.com"}
]

emails = [u["email"] for u in usuarios]

Assim, o código sempre obtém dados derivados diretamente da fonte original.

Quando não aplicar DRY cegamente

DRY é poderoso, mas abstrações em excesso podem transformar um código simples em algo complexo demais. Se duas partes do sistema compartilham apenas semelhanças superficiais, manter a duplicação temporariamente pode ser a melhor escolha. O equilíbrio é o segredo: Deduplique apenas quando houver real benefício em termos de clareza, manutenção e consistência.

Conclusão

O princípio DRY é mais que uma boa prática: ele reflete uma mentalidade de engenharia. Pensar em sistemas DRY é pensar em código sustentável, modular e de longo prazo.
Evitar repetição não é apenas sobre reduzir linhas, é sobre projetar bases sólidas para a evolução natural do software.



Riverfount
Vicente Eduardo Ribeiro Marçal

Os Type Hints transformaram a forma como escrevemos e mantemos código Python. Desde que foram introduzidos oficialmente no Python 3.5+, eles se tornaram essenciais em projetos que buscam clareza, segurança e manutenção mais fácil.

Mesmo sendo uma linguagem dinamicamente tipada, o Python se beneficia muito dessas anotações estáticas, especialmente em callables — funções, métodos e classes. Neste artigo, vamos entender por que usar Type Hints é uma prática que vale o investimento.

O que são Type Hints e por que importam

Type Hints (ou dicas de tipo) e Type Annotations (anotações de tipo) permitem indicar qual tipo de dado é esperado em parâmetros e retornos de funções — tudo sem alterar a execução do código. Isso fornece uma camada de documentação automática e dá às ferramentas de análise a capacidade de detectar erros antes da execução.

Com isso, o código fica mais previsível e mais fácil de entender, especialmente em equipes ou projetos de longo prazo. Vejamos, então, alguns pontos que nos auxiliem a compreender as vantagens de usar o Type Hints em nosso dia a dia.

1. Clareza na intenção

Callables anotadas explicitamente mostram a intenção do desenvolvedor. Em vez de adivinhar o tipo esperado, qualquer pessoa que leia a função entende rapidamente seu contrato de uso.

from typing import Sequence

def calculate_total(items: Sequence[float], discount: float = 0.0) -> float:
     """Calcula o total com possível desconto."""    
     subtotal = sum(items)
     return subtotal * (1 - discount)

Esse tipo de clareza se traduz em APIs mais legíveis e documentação quase desnecessária.

2. Melhor suporte a ferramentas

Ferramentas como mypy, Pylance (VS Code) e PyCharm são projetadas para aproveitar as anotações de tipo ao máximo. Elas oferecem:

  • Verificação estática de tipos antes da execução.
  • Autocompletar mais inteligente.
  • Detecção de inconsistências de tipo em tempo de desenvolvimento.

Esse feedback imediato reduz bugs e melhora a produtividade do time.

3. Código mais fácil de manter

Em projetos grandes, anotações de tipo funcionam como uma documentação que nunca fica desatualizada. Elas:

  • Eliminam a necessidade de abrir implementações para entender uma função.
  • Tornam refatorações mais seguras.
  • Diminuem erros ao passar parâmetros incorretos.

Manter consistência nas anotações é o segredo para que o benefício se estenda por toda a base de código.

4. Estabelecendo contratos explícitos

Ao usar Type Hints, você cria contratos claros — o que é essencial em APIs, bibliotecas e interfaces entre módulos. Esses contratos tornam o comportamento mais previsível e aumentam a confiabilidade do sistema. Em outras palavras: quem usa sua função sabe exatamente o que esperar dela.

Quando não anotar variáveis locais

Embora as anotações sejam úteis, nem tudo precisa ser anotado.
Para variáveis locais cujo tipo é óbvio, a inferência do Python faz um excelente trabalho:


# Desnecessário 
items: list[float] = [10.5, 20.0, 30.75] 
# Melhor assim 
items = [10.5, 20.0, 30.75]  # Tipo inferido como list[float]

Use anotações locais apenas em três situações específicas:

  • Quando a inicialização é complexa e o tipo não é evidente.
  • Em variáveis de classe.
  • Quando você precisa forçar um tipo específico.

Boas práticas para Type Hints em callables

  • Seja específico: use list[str], dict[int, str], etc.
  • Use o operador | para parâmetros com múltiplos tipos possíveis (ex.: int | str).
  • Use X | None em vez de Optional[X].
  • Documente exceções que os tipos não representem.
  • Mantenha consistência: uma vez que começar a usar type hints, aplique-os em todo o projeto.

Exemplo avançado


from typing import Iterable, Callable 

def process_data(
    data: Iterable[int],
    transformer: Callable[[int], int] | None = None,
    threshold: int = 0
) -> list[int]:
    """Processa dados aplicando transformação e filtro."""
    if transformer is None:
        transformer = lambda x: x
    return [transformer(x) for x in data if x > threshold]

Esse exemplo mostra como é possível expressar claramente a intenção e o comportamento, mesmo em funções mais complexas.

Conclusão

Usar Type Hints em callables é uma das formas mais eficazes de melhorar a qualidade e a legibilidade do código em Python. Eles unem o melhor dos dois mundos: dão à linguagem a segurança da tipagem estática sem perder sua natureza dinâmica e ágil. Adotar esse padrão não é apenas uma questão de estilo — é um passo estratégico para construir bases de código mais seguras, fáceis de entender e prontas para escalar.

P.S.: Uma informação importante

O Python não realiza validação de tipos em tempo de execução, mesmo quando as anotações de tipo estão presentes no código. As Type Hints têm caráter apenas informativo e não afetam a execução do programa em si. No entanto, essas anotações são amplamente utilizadas por IDEs e ferramentas de análise estática, como o mypy, que verificam a consistência dos tipos e ajudam a identificar possíveis erros antes da execução, tornando o desenvolvimento mais seguro e previsível.



Riverfount
Vicente Eduardo Ribeiro Marçal

Você sabe qual é a forma mais Pythonic de verificar tipos em seu código? Se ainda usa type() para testar variáveis, talvez esteja limitando o potencial do seu projeto sem perceber. Entender a diferença entre type(), isinstance() e o conceito de duck typing pode transformar a maneira como você escreve código mais limpo, flexível e verdadeiro ao estilo do Python.

Entendendo a diferença entre type() e isinstance()

Em Python, é comum verificar o tipo de uma variável em um if. Dois padrões clássicos são:

type(var) == str
# ou
isinstance(var, str)

Ambos funcionam, mas a escolha entre eles afeta diretamente a flexibilidade e o design do seu código. Neste artigo, vamos analisar as diferenças, entender por que isinstance() é a melhor escolha na maioria dos casos e, por fim, ampliar o tema com um conceito essencial: duck typing.

O problema com type()

A comparação via type() verifica se o tipo exato da variável corresponde ao especificado. Isso parece simples, mas geralmente limita o comportamento orientado a objetos e ignora herança e polimorfismo.

Exemplo:

class MyString(str):
    pass

my_var = MyString("hello")

print(type(my_var) == str)      # False
print(isinstance(my_var, str))  # True

Aqui, type(my_var) == str retorna False porque my_var é de tipo MyString, não exatamente str. Já isinstance() reconhece que MyString é uma subclasse de str e retorna True.

Por que isso é um problema?

  1. Herança: type() ignora subclasses, quebrando a extensibilidade.
  2. Polimorfismo: força verificações rígidas de tipo e impede que objetos diferentes sejam tratados pela mesma interface, contrariando um princípio central da programação orientada a objetos.

As vantagens de usar isinstance()

A função isinstance(obj, classe) verifica se um objeto é instância da classe ou de qualquer subclasse dela. Isso alinha seu código com boas práticas e com a filosofia dinâmica do Python.

Vantagens principais:

  • Aceita herança naturalmente.
  • Melhora a clareza do código.
  • Permite múltiplos tipos.

Exemplo:

def process_data(data):
    if isinstance(data, (str, bytes)):
        print("Processando string ou bytes.")
    else:
        print("Tipo de dado não suportado.")

process_data("hello")
process_data(b"world")
process_data(123)

Quando ainda faz sentido usar type()

Os casos em que type() é realmente útil são raros. Ele é usado quando é necessário garantir que o tipo seja exatamente aquele, sem considerar herança. Exemplos típicos incluem:

  • Metaprogramação: frameworks que precisam saber o tipo exato para controle interno.
  • Validação precisa: bibliotecas que não devem aceitar subclasses por motivos de segurança ou consistência.
if type(obj) is dict:
    # Garante que obj é exatamente um dict

Mas mesmo nesses cenários, o uso deve ser justificado e contextualizado.

Indo além: o poder do duck typing

Em Python, a ênfase não está em “de que tipo é o objeto”, mas em “o que o objeto sabe fazer”. Essa filosofia é conhecida como duck typing.

A ideia vem da expressão:
“Se anda como um pato e grasna como um pato, deve ser um pato.”

Em vez de verificar explicitamente o tipo, verificamos se o objeto possui os métodos ou atributos necessários para uma tarefa. Isso torna o código mais flexível e idiomático.

Exemplo:

def process_data(data):
    try:
        text = data.decode()  # funciona se 'data' tiver o método decode()
        print("Extraído via decode:", text)
    except AttributeError:
        print("Objeto não é compatível com decode().")

O código acima não se preocupa se data é bytes, uma subclasse ou outro objeto que implemente decode. Ele simplesmente tenta usar o método. Se funcionar, ótimo; se não, é tratado graciosamente.

Vantagens do duck typing

  • Remove checagens desnecessárias de tipo.
  • Facilita a extensão de comportamentos.
  • Segue o princípio “Easier to ask forgiveness than permission” (EAFP).

Outro exemplo:

# Verificação tradicional
if isinstance(data, str):
    resultado = data.upper()
else:
    raise ValueError("Esperado string")

# Abordagem com duck typing
try:
    resultado = data.upper()
except AttributeError:
    raise ValueError("Objeto não implementa upper()")

A segunda forma é mais natural e extensível, típica de APIs Pythonic bem projetadas.

Comparativo rápido

Característica type(var) == str isinstance(var, str) Duck Typing
Checagem Tipo exato Tipo ou subclasse Comportamento/métodos
Herança Ignora Considera Irrelevante
Flexibilidade Rígida Moderada Máxima
Legibilidade Menor Boa Contextual
Boa prática Evite Use normalmente Prefira quando possível

Conclusão

Ao escrever código em Python, entender a diferença entre comparar tipos, verificar instâncias e avaliar comportamento é um passo essencial para dominar o estilo e a filosofia da linguagem.

  • Use isinstance() para a maioria dos casos.
  • Use type() apenas quando o tipo exato é crítico.
  • E, acima de tudo, pratique duck typing sempre que possível.

Essa mentalidade tornará seu código mais elegante, expressivo e verdadeiramente alinhado ao jeito Python de programar.



Riverfount
Vicente Eduardo Ribeiro Marçal

Dando continuidade ao artigo “O que é uma API REST? Explicação Detalhada para Desenvolvedores”, esta segunda parte aprofunda-se em um método HTTP essencial que não foi coberto anteriormente: o PATCH, destacando seu papel na atualização parcial de recursos. Enquanto no artigo inicial exploramos os métodos GET, POST, PUT e DELETE para operações completas de criação, leitura, atualização e exclusão, aqui explicamos como o PATCH permite modificações mais precisas e eficientes, sem a necessidade de substituir o recurso inteiro.

Além disso, como as APIs REST são uma forte implementação do protocolo HTTP, entender os códigos de status retornados pelo servidor é fundamental para um desenvolvimento eficaz e para os consumidores da API interpretarem corretamente o resultado das requisições. Nesta parte, exploraremos os códigos mais comuns e seu significado prático para o ciclo de vida das requisições REST.

Método PATCH: Atualização Parcial de Recursos

O método PATCH é destinado a aplicar modificações parciais a um recurso existente, diferentemente do PUT, que exige o envio da representação completa do recurso para substituí-lo. PATCH permite enviar apenas os campos que precisam ser alterados, tornando as requisições mais leves e eficientes, especialmente úteis em aplicações onde pequenas mudanças são frequentes.

Por exemplo, imagine uma API para gerenciamento de usuários. Se você deseja atualizar apenas o e-mail do usuário com ID 123, uma requisição PATCH adequada seria:

PATCH /api/usuarios/123
Content-Type: application/json

{
  "email": "novoemail@exemplo.com"
}

Neste caso, somente o campo “email” será alterado, enquanto os demais dados permanecem inalterados. O servidor pode responder com um código 200 OK acompanhando a representação atualizada do recurso, ou 204 No Content se não devolver corpo na resposta.

Diferença entre PATCH e PUT

Característica PUT PATCH
Atualização Substituição completa do recurso Modificação parcial
Envio do recurso Representação completa Apenas alterações
Idempotência Sim Nem sempre, mas pode ser
Uso típico Atualizar todo recurso Atualizar partes específicas

Códigos de Status HTTP Usados em APIs REST

Os códigos de status são mensagens padrão do protocolo HTTP que indicam o resultado da requisição, contribuindo para a interpretação e a resposta adequadas na comunicação entre cliente e servidor.

Códigos mais comuns e seus significados:

  • 200 OK: Requisição bem-sucedida, geralmente ao recuperar ou modificar recursos.
  • 201 Created: Recurso criado com sucesso em resposta a uma requisição POST.
  • 204 No Content: Requisição realizada com êxito, sem conteúdo a ser retornado (ex: DELETE, PATCH sem corpo).
  • 400 Bad Request: Requisição mal formada ou inválida.
  • 401 Unauthorized: Falha na autenticação, sem permissão para acessar o recurso.
  • 403 Forbidden: Cliente está autenticado, mas não autorizado a acessar o recurso.
  • 404 Not Found: O recurso requisitado não existe.
  • 405 Method Not Allowed: Método HTTP não suportado pelo recurso.
  • 409 Conflict: Conflito na requisição (ex: duplicação de recurso).
  • 500 Internal Server Error: Erro inesperado no servidor.

Exemplo prático com criação de recurso

Ao criar um usuário via POST, o servidor responde:

HTTP/1.1 201 Created
Location: /api/usuarios/123
Content-Type: application/json

{
  "id": 123,
  "nome": "João",
  "email": "joao@example.com"
}

Exemplo prático com atualização parcial (PATCH)

Requisição:

PATCH /api/usuarios/123
Content-Type: application/json

{
  "telefone": "999999999"
}

Resposta:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "nome": "João",
  "email": "joao@example.com",
  "telefone": "999999999"
}

Conclusão

Concluímos esta série de dois artigos sobre API REST, nos quais consolidamos um entendimento sólido sobre os princípios e práticas que tornam uma API RESTful eficiente e alinhada às necessidades modernas de desenvolvimento. No primeiro artigo, exploramos os fundamentos da arquitetura REST, demonstrando como os métodos HTTP convencionais estruturam o ciclo de vida dos recursos em uma API, a importância da comunicação stateless, e o papel da padronização na construção de interfaces interoperáveis e escaláveis. Na sequência, aprofundamos a discussão ao destacar o método PATCH como uma alternativa para atualizações parciais, essencial para operações mais eficientes e flexíveis, além de detalhar a relevância dos códigos de status HTTP para garantir clareza e robustez na comunicação entre cliente e servidor.

Esses conceitos, juntos, formam a base para o design e implementação de APIs REST que atendem tanto às expectativas dos consumidores quanto às demandas de escalabilidade e manutenção do backend. Compreender e aplicar corretamente tais práticas é fundamental para engenheiros de software que desejam construir sistemas interconectados, seguros e responsivos. O aprendizado contínuo e a adoção das melhores práticas REST são essenciais para acompanhar a evolução tecnológica e assegurar soluções de alta qualidade no desenvolvimento web e além. Esta série pretendeu não só informar, mas também inspirar a prática efetiva e consciente na criação de APIs RESTful.



Riverfount
Vicente Eduardo Ribeiro Marçal

Introdução

APIs REST (Representational State Transfer) são um padrão amplamente adotado para comunicação entre sistemas distribuídos, especialmente na web. Elas definem um conjunto de princípios que permitem que aplicações se comuniquem de forma simples, eficiente e escalável usando o protocolo HTTP. Este artigo detalha os conceitos fundamentais, a arquitetura REST e traz exemplos práticos para facilitar o entendimento.

Conceitos Fundamentais de REST

REST não é um protocolo, mas um conjunto de restrições arquiteturais para criar APIs, proposto por Roy Fielding em 2000. Para que uma API seja considerada RESTful, ela deve seguir princípios essenciais:

  • Cliente-Servidor: Separação entre cliente (que consome a API) e servidor (que fornece dados e serviços).
  • Sem estado (Stateless): Cada requisição do cliente para o servidor deve conter todas as informações para ser compreendida e processada, sem depender de informações de requisições anteriores.
  • Cacheável: As respostas podem ser armazenadas temporariamente para melhorar o desempenho.
  • Interface uniforme: Padronização das interações, onde cada recurso é identificado por uma URL única e manipulável via métodos HTTP.
  • Sistema em camadas: A arquitetura pode ser composta por uma cadeia de servidores intermediários para balanceamento de carga, segurança, etc., invisíveis ao cliente.
  • Código sob demanda (opcional): Possibilidade do servidor enviar código executável, como scripts, ao cliente para expandir funcionalidades momentaneamente.

Componentes de uma API REST

Recursos

Um recurso é qualquer entidade que possa ser identificada e manipulada via API — um usuário, um produto, um pedido, etc. Cada recurso é expresso por uma URI (Uniform Resource Identifier). Por exemplo:

GET https://api.loja.com/produtos/123

Nesse exemplo, “produtos/123” é o recurso que representa o produto com id 123.

Métodos HTTP

REST utiliza os métodos HTTP para realizar operações CRUD (Criar, Ler, Atualizar, Deletar) nos recursos:

  • GET: Recuperar dados (ex: listar produtos)
  • POST: Criar novo recurso (ex: cadastrar um novo produto)
  • PUT: Atualizar recurso existente (ex: alterar informações de um produto)
  • DELETE: Remover recurso (excluir um produto)

Formato das Respostas

As APIs REST geralmente retornam dados formatados em JSON (JavaScript Object Notation), que é legível tanto por humanos quanto por máquinas. Exemplo de resposta JSON para um produto:

{
  "id": 123,
  "nome": "Camiseta",
  "preco": 49.90,
  "estoque": 20
}

Parâmetros da Requisição

  • Route Params: Parâmetros na própria URL para identificar recursos específicos, ex: /produtos/123.
  • Query Params: Parâmetros na URL para filtros, paginação, ordenação, ex: /produtos?categoria=camisetas&page=2.
  • Headers: Metadados da requisição, como autenticação, tipo de conteúdo esperado etc.
  • Body: Dados enviados em POST/PUT, usualmente em JSON.

Exemplo Prático

Suponha uma API REST para gerenciamento de uma lista de tarefas:

  • GET /tarefas: Retorna todas as tarefas
  • GET /tarefas/5: Retorna detalhes da tarefa com ID 5
  • POST /tarefas: Cria uma nova tarefa com dados enviados no corpo da requisição
  • PUT /tarefas/5: Atualiza a tarefa 5
  • DELETE /tarefas/5: Exclui a tarefa 5

Exemplo real de requisição POST para criar tarefa

POST /tarefas
Content-Type: application/json

{
  "titulo": "Estudar APIs REST",
  "descricao": "Ler e praticar criação de APIs RESTful"
}

Resposta:

201 Created
{
  "id": 10,
  "titulo": "Estudar APIs REST",
  "descricao": "Ler e praticar criação de APIs RESTful",
  "status": "pendente"
}

Benefícios da Arquitetura REST

  • Escalabilidade: Devido à independência sem estado, facilmente escalável.
  • Flexibilidade: Pode ser consumida por diversos clientes, como web, mobile, IoT.
  • Padronização: Uso dos métodos HTTP e formatos de dados padrão facilitam integração.
  • Desempenho: Cacheamento ajuda na redução da carga e melhora a performance.
  • Evolução gradual: Fácil adicionar ou modificar recursos sem impactar clientes existentes.

Considerações Avançadas

  • HATEOAS (Hypermedia as the Engine of Application State): A API fornece links em suas respostas para que o cliente descubra dinamicamente as operações disponíveis em cada recurso, reduzindo o acoplamento.
  • Versionamento: Para evitar quebras, APIs REST frequentemente versionam suas endpoints, ex: /v1/tarefas.
  • Autenticação e Segurança: Uso de tokens (ex: JWT), OAuth e HTTPS são essenciais.



Riverfount
Vicente Eduardo Ribeiro Marçal

O Problema da Explicação na Teoria da Consciência


O maior problema na Teoria da Consciência não é a teoria em si, mas a enorme dificuldade de se postular uma teoria científica unificada sobre a Consciência. Isso porque o principal debate que as Ciências e a Filosofia da Mente deveriam fazer não é sobre a Natureza da Consciência, mas sim sobre a Natureza da Explicação sobre a Consciência. Da mesma maneira que Agostinho afirmava saber exatamente o que é o tempo, mas não sabia como explicá-lo. Esse debate propõe que, na teoria da consciência, temos um predicamento similar com uma ligeira modificação, pois, em certo sentido, trabalha-se exatamente com o que pensamos sobre a consciência, mas não se tem ideia de como explicá-la em uma teoria científica unificada.

Assim, num certo sentido, estamos na mesma situação de Agostinho, com uma ligeira distinção, ou seja, a dificuldade não está em saber falar sobre o objeto estudado, no caso a Consciência, mas em não termos como explicar, fundamentar a partir de uma teoria científica unificada a respeito do objeto estudado.

Na mesma direção, o pesquisador americano Chalmers em seu artigo intitulado Facing up to the problem of Consciousness (Enfrentando o problema da Consciência – numa tradução livre) afirma ser a consciência o problema mais intrigante de toda a Ciência da Mente, pelo fato de sabermos intimamente o que é uma experiência consciente, mas é, simultaneamente, a mais complexa experiência a ser explicada, pois nos últimos anos tanto a Ciência como a Filosofia da Mente tem obtido bons resultados no estudo de diversos fenômenos, manifestações e estados conscientes, contudo a Consciência tem sido teimosamente resistente às abordagens que dela são feitas.

Nesse sentido, a Consciência é um conceito híbrido e por isso não é um único problema para a Teoria da Consciência ou para a Filosofia da Mente, mas por podermos atribuir ao conceito Consciência significados como: manifestação, fenômeno e estado de consciência, entre outros, de modo a termos como grande dificuldade para qualquer tentativa de se teorizar sobre a Consciência, primeiro saber o que se entende por Consciência. Diversos debates tomam um único sentido desse termo, negligenciando os outros possíveis, mas isso tem por efeito proporcionar mais críticas do que aceitação, principalmente pela ideia de se ter feito uma petição de princípio, i. e., toma-se a Consciência para definir-se a si própria.

Podemos então perceber que temos uma particularidade que torna ainda mais complexa nossa tarefa, ou seja, a própria circunscrição ou delineamento do objeto de estudos, pois o mesmo transfigura-se em diversos outros objetos que podem ser estudados como Consciência. Ou seja, todos os fenômenos de consciência carecem de explicação e muitos deles foram ou, em certa medida, estão prestes a ser explicados.

Contudo, a Consciência em si ainda resiste às abordagens metodológicas das Ciências e da Filosofia. Compreende-se a grande dificuldade em se abordar a Consciência enquanto tema para discussão na Filosofia da Mente e, por isso, Chalmers, em seu artigo, a divide em dois tipos de problemas: 1) os problemas fáceis (the easy problems) e 2) os problemas difíceis (the hard problems). Sua proposta é mostrar que os problemas fáceis estão relacionados aos fenômenos, manifestações ou estados conscientes que já foram explicados, ou estão prestes a ser, via a metodologia científica padrão, ou como diz Chalmers: “[...] Os problemas fáceis da consciência são aqueles que estão diretamente suscetíveis pelos métodos padrões da ciência cognitiva, em que um fenômeno é explicado em termos de mecanismos neurais ou computacionais [...]”, e os problemas difíceis são todas as questões envolvendo a experiência subjetiva, à qual consideramos ser uma experiência da Consciência, que teimosamente resistem a esses métodos padrões das ciências e também da filosofia. Afirma ainda que, realmente, os problemas difíceis da consciência são problemas de experiência. Quando pensamos e percebemos, há um zumbindo no processamento da informação, mas há também um aspecto subjetivo, há algo como ser um organismo consciente. Este aspecto subjetivo é a experiência.

Essas experiências subjetivas da Consciência são, também, denominadas de Qualia. Os Qualia (no singular Quale) são as experiências que vivenciamos e não aquilo que experimentamos. Um exemplo muito utilizado, dentre os vários possíveis, é sobre a percepção de um objeto vermelho. O fenômeno que temos é de alguém, ou nós mesmos, percebermos um objeto vermelho, contudo os Qualia é a experiência subjetiva individual e impenetrável de como, esse alguém ou nós mesmos, temos a sensação/vivência do vermelho ou, em outras palavras, como a vermelhidão do objeto nos atinge. É algo extremamente subjetivo, e pode nos remeter — sem entrarmos no mérito polêmico da questão — ao problema da existência das outras mentes proposto por Descartes. Em outras palavras, o problema dos Qualia está no fato do sujeito ter acesso privilegiado a essa experiência, pois é pessoal, subjetiva e interior, contudo a explicação da Teoria da Consciência deveria utilizar-se de métodos que permitissem atingir esse acesso privilegiado em si e não apenas falar sobre ele.

Destarte, temos o problema delineado. A necessidade de explicarmos a experiência consciente, ou seja, os Qualia e não somente expormos sobre tais experiências. Qual método pode se mostrar eficaz em propiciar acesso direto sem o subterfúgio da descrição subjetiva de uma manifestação, fenômeno ou estado de consciência, que como afirma Chalmers pode conter um ruído, um zumbido que interfere no processo de compreensão dos Qualia. Postulamos um problema o qual ainda está longe de se conseguir uma resposta, principalmente uma resposta unificada entre as Ciências e, também, com a Filosofia. Quiçá, consigamos ter respostas a essas questões um dia!

#Filosofia #Consciência #Teoria #Qualia



Riverfount
Vicente Eduardo Ribeiro Marçal

Sistemas, Auto-Organização e Informação: Uma Interrelação

  • Esse texto foi originalmente apresentado como comunicação no VI Simpósio de Filosofia e Ciência Universidade e Contemporaneidade: Produção do Conhecimento e Formação Profissional promovido pela FFC – UNESP – Campus Marília em 2005.

Introdução

Temos como propósito nessa comunicação apresentar algumas considerações sobre nosso estudo na área de Filosofia da Mente e Ciência Cognitiva, principalmente nosso estudo sobre Sistêmica, Auto-Organização e Informação e a inter-relação existente entre essas áreas. Para isso iniciamos com a conceituação de Sistemas e o que os caracteriza, bem como da Auto-Organização e Informação, para apontarmos nas considerações finais a inter-relação existente, principalmente no fato de compreendermos a informação como motor propiciador da auto-organização secundária.

1. Sistemas

Consideramos sistema um conjunto não vazio de elementos que mantém relações entre si. Von Bertalanffy corrobora com essa definição ao apresentar que um sistema é conhecido não somente pela soma de todas as características dos elementos que o compõem, mas também das relações que estes elementos têm entre si, dessa forma não é nada estranho encontrar um sistema onde o todo seja maior — ou mesmo menor — que a soma de suas partes. O conhecimento da totalidade dos elementos de um sistema e de todas as relações envolvidas entre eles pode nos dar, a partir da análise do comportamento de todo o conjunto, o comportamento do sistema.

Diante dessa definição de sistema, nos colocamos as seguintes perguntas: o que são elementos? E o que são relações? Pessoa Jr. nos auxilia na elucidação dessas questões ao afirmar que um elemento é uma entidade primitiva que a cada instante está em um dentre vários estados possíveis ou, colocado de outra forma, possui um dentre vários atributos possíveis. Já as relações são definidas, por Pessoa Jr., como sendo as alterações de estado dos elementos condicionadas, ou condicionando, as alterações de estado de outro elemento no mesmo instante de tempo ou num instante posterior.

Essas relações podem ser exclusivas entre os elementos do sistema, a isso chamamos de sistema fechado, pois implica em que o sistema não mantém nenhum tipo de relação com o ambiente externo a ele. Ou podemos ter um sistema aberto, onde os elementos mantêm relações entre si como, também, relações com o ambiente onde está situado.

Tais definições, de elementos e relações, são importantes, pois para a Teoria Geral dos Sistemas, um sistema é caracterizado por sua estrutura ou organização e não pela identidade somatória de seus elementos.

2. Auto-Organização

Uma das características fundamentais de um sistema é a condicionalidade de relação entre seus elementos. Como definimos acima, uma relação entre dois elementos está no fato da alteração de estado de um dos elementos condicionar ou ser condicionada pela alteração do outro. Segundo Ashby, essa condicionalidade é a principal característica da organização de um sistema.

Entretanto, para os propósitos da presente comunicação, o conceito fundamental referente à organização do qual necessitamos é o de auto-organização. Ou seja, a possibilidade de novas formas de organização surgirem sem que haja um agente catalisador do processo.

Segundo Debrun, a auto-organização é um processo que se dá a partir do encontro de elementos distintos, sem vinculação causal anterior e, principalmente, sem uma interação supervisionada por qualquer dos elementos.

Essa definição de Debrun envolve duas modalidades de auto-organização. A primeira modalidade, chamada de Auto-Organização Primária, se dá na interação não-supervisionada de elementos distintos, que não possuíam nenhuma espécie de relação causal anterior e que, ao se encontrarem, podem desencadear uma dinâmica geradora de padrões simples e instáveis.

A segunda modalidade é a Auto-Organização Secundária, que compreende a possibilidade de um sistema, atuando de forma autônoma sobre si mesmo, passar de um estado de menor complexidade para um estado maior de complexidade. É o que Debrun, chama de complexificação. Assim, temos que a auto-organização secundária, ocorre em sistemas já organizados que buscam uma complexificação maior de suas relações.

3. A informação numa perspectiva não-antropomórfica

O conceito de informação é um tanto controverso. Desde seu significado de notícia, novidade ou dados até à possibilidade de uma mensagem enviada por diversas vias, sejam elas materiais ou imateriais, tais como cartas, telegramas, telefone, sinais de rádio etc.

Contudo, tais usos manifestam uma compreensão antropomórfica do termo, entendido como mensagem lingüística, significativa e inédita (para o receptor), transmitida entre seres humanos. Esta compreensão antropomórfica do conceito de informação nos leva a três características primordiais, a saber: linguagem simbólica humana, significado e novidade ou ineditismo.

No intuito de buscarmos uma compreensão não-antropomórfica da informação, afirmamos, junto com Shaeffer em sua interpretação de Stonier, que a informação é genuinamente um elemento ontológico, juntamente com a energia e a matéria. Assim, segundo Shaeffer, Stonier compreende a informação como propriedade fundamental do universo, buscando fundamentação para sua tese em Aristóteles que propunha a ordem como parte integrante da realidade. A compreensão de Aristóteles, que implica dizer que a ordem é parte integrante da realidade, pode ser apreendida de seu escrito De Anima, onde explica a natureza da vida com base em sua doutrina metafísica da natureza geral das coisas.

Um segundo passo em direção a um conceito não-antropomórfico de informação é uma derivação do primeiro. O teórico Zeman nos auxilia nesse segundo passo ao apresentar a informação, a partir de sua origem etimológica, como a medida de organização de um sistema. Nessa compreensão a informação se mantém, mesmo quando não utilizada por algum sistema diferente do sistema fonte de informação, como padrão organizacional dos sistemas.

Essa concepção de medida quantitativa nos leva para o terceiro passo em direção à desantropomorfização da noção de informação, a saber: a informação enquanto negaentropia.

Para compreendermos esse terceiro passo, temos que recorrer à Teoria Matemática da Comunicação de Shannon e Weaver. Estes apresentam, já em seu primeiro capítulo, a noção da informação enquanto a medida da liberdade de escolha entre as mensagens prováveis. Pois, ao se escolher uma mensagem, entre as prováveis, a mensagem escolhida transporta unidade de informação, as outras não.

Essa unidade de informação transportada por uma mensagem é uma decisão entre duas alternativas, por exemplo, animal e não-animal. Assim, com duas perguntas é possível decidir-se por uma em quatro possibilidades, do mesmo modo que com três é possível decidir-se por uma em oito possibilidades, o que nos leva à conclusão de que o logaritmo de base dois das possíveis decisões pode ser usado como medida da informação. Assim, se temos duas possibilidades de mensagem, a unidade de informação transportada é log2 4 = 2, caso tenhamos três possibilidades de mensagem, então a unidade de informação transportada será de log2 8 = 3, e assim sucessivamente.

Tal cálculo é semelhante ao da entropia, e Shannon e Weaver estão cientes disso. Contudo a entropia é o grau de desordem de um sistema, e se temos que, na Teoria Matemática da Comunicação, a medida da unidade de informação é correspondente à medida de entropia de um sistema, então temos uma contradição aqui, pois no segundo passo afirmamos que a informação é a medida de ordem de um sistema, e aqui estamos apontando para a informação como um correlato à medida de desordem de um sistema. Como resolver essa contradição?

Como proposta de solução dessa contradição, assumimos a posição de Pereira Jr. e Gonzales. Primeiramente devemos compreender que existem dois níveis de análise. O primeiro foca somente a fonte de informação, sendo que quanto mais organizada menor será sua medida de unidade de informação. O segundo propõe uma correlação entre o sistema fonte de informação e o sistema receptor da informação, ou seja, a correlação entre dois sistemas. Caso essa correlação seja inexistente, i. e., igual a zero, não haverá transmissão de informação; caso seja maior que zero, menor ou igual a um, ocorrerá a transmissão de informação. Solucionando, assim, a contradição que aparentemente se nos apresentava.

4. Considerações Finais: A informação como motor da auto-organização secundária

Num primeiro momento, analisamos e definimos um sistema, que basicamente é a interpretação do todo não apenas pela somatória da identidade de suas partes, mas pelo complexo formado por suas partes e as relações por elas condicionadas. Tal complexo é matematicamente descrito por um conjunto de equações de múltiplas variáveis com forte interdependência, ou seja, que não tem solução simples por isolamento das variáveis. Rapoport denomina esse tipo de sistema de complexidade organizada, cujo organismo vivo é um exemplo evidente.

Em seguida, trabalhamos o conceito de auto-organização como o processo iniciado pelo encontro de elementos realmente distintos, sem ingerência de uma instância controladora, que dará forma a um novo sistema ou elevará a complexidade de um sistema já existente.

Apresentamos o conceito de informação numa perspectiva não-antropomórfica, a partir da Teoria Matemática da Comunicação, como medida de organização, ou negaentropia, de um sistema. Assim definido, o conceito de informação é aplicável à análise de todos os fenômenos nos quais existe comportamento organizado e especificamente dirigido para um objetivo.

A partir das conceitualizações efetuadas argumentamos com o objetivo de levar à compreensão de que a informação é o motor que dá início ao processo de complexificação de um sistema, ou seja, é a informação que propicia a um sistema sua passagem de uma complexidade menor para uma complexidade maior, sem gerenciar tal processo.

Para tanto, devemos lembrar que a Segunda Leia da Termodinâmica nos ensina que todo sistema físico que for isolado de seu meio tende a ter sua entropia maximizada, ou seja, um sistema fechado terá uma redução de sua energia livre, i. e., a energia de um sistema que pode realizar algum trabalho no ambiente; e aumento de sua energia térmica incapaz de realizar trabalho, em outras palavras o sistema tende a afastar-se de uma situação mais organizada para uma situação desorganizada/caótica.

Temos aqui um impasse, pois buscamos argumentar sobre o fato da informação ser o motor que inicia o processo de ampliação da organização de um sistema e a Segunda Lei da Termodinâmica, mostra que a natureza de um sistema é tender justamente para a sua total desorganização. Como responder a esse impasse?

Devemos, então ressaltar que a Segunda Lei é referente a sistemas isolados, ou seja, sistemas fechados que não mantém nenhuma relação com o meio. Em sistemas abertos, como mencionado, há uma relação com o meio. Essa relação propicia uma troca com o meio, essa troca favorece o equilíbrio do sistema impedindo, assim, o aumento de sua entropia. Como diz Rapoport, em relação aos seres vivos, é o alimento ingerido que serve não apenas como fonte de energia, mas principalmente, como fonte de energia livre, compensando o aumento da entropia.

Podemos concluir com Rapoport e com o que vimos discorrendo até aqui sobre a informação como medida da negaentropia, o aumento da entropia destrói a informação e, conseqüentemente, o inverso também é verdadeiro, ou seja, que a informação reduz a entropia.

Enquanto elemento redutor da entropia, a informação propicia não somente a manutenção do equilíbrio do sistema, mas também a possibilidade de aumentar sua complexidade organizada, ou seja, a informação não apenas supre os organismos vivos da energia utilizada nos processos vitais, mas aumenta a complexidade organizada que os caracteriza como sistemas vivos.

Logo, a informação fornecida pelo meio é processada pelo sistema que pode dar início ao processo de auto-organização secundária, ou seja, o processo de aumento da complexificação de um sistema. A informação é responsável pelo “start” do processo, contudo não é reguladora e nem supervisora do mesmo, pois o processo é de auto-organização, não possuindo um centro regulador.

Referências

ASHBY, W. R. Principles of the Self-Organizing System. in Von FOERSTER, H. & ZOPF, G. W. (orgs.), Self-Organizing Systems. Londrines:Pergamon, 1962.

BROENS, M. C. & GONZALES, M. E. Q., Information, Life and Evolutionary Robots: a systemic approach. Não Publicado, s/d.

D’OTTAVIANO, I. M. L. & BRESCIANI FILHO, E. Conceitos Básicos de Sistêmica. in D’OTTAVIANO I. M. L. & GONZALES, M. E. Q (orgs). Auto-Organização – Estudos Interdisciplinares. Campinas:UNICAMP, Centro de Lógica, Epistemologia e História da Ciência, 2000. (Coleção CLE, volume 30).

DEBRUN, M. A Idéia de Auto-Organização. in DEBRUN, M. et. all, (orgs.) Auto-Organização Estudos Interdisciplinares. Campinas:UNICAMP, Centro de Lógica, Epistemologia e História da Ciência, 1996. (Coleção CLE, volume 18).

PEREIRA JR., A. & GONZALES, M. E. Q., Informação, Organização e Linguagem. in ÉVORA, F. R. R., Espaço Tempo. Campinas:UNICAMP, Centro de Lógica, Epistemologia e História da Ciência, 1995.

PEREIRA Jr., et. all. Auto-Organização na Biologia: Nível Ontogenético. In DEBRUN, M. et. all, (org.) Auto-Organização Estudos Interdisciplinares. Campinas:UNICAMP, Centro de Lógica, Epistemologia e História da Ciência, 1996.

PESSOA JR., O. Medidas Sistêmicas e Organização. in DEBRUN, M. et. all. (orgs.). Auto-Organização – Estudos Interdisciplinares. Campinas:UNICAMP, Centro de Lógica, Epistemologia e História da Ciência, 2000. (Coleção CLE, volume 18).

RAPOPORT, A. Aspectos matemáticos da análise geral dos sistemas. in VON BERTALLANFY, et. all. Teoria dos Sistemas. Tradução de Maria da Graça Lustosa Becskeházy, Rio de Janeiro:FGV – Instituto de Documentação Editora Fundação Getúlio Vargas, 1976.

SCHAFFER, R., Informação e Naturalismo Esclarecido: O “Realismo Informacional”. in GONZALES, M. E. Q. et all (org.). Encontro com as Ciências Cognitivas. Marília:Unesp-Marília-Publicações São Paulo:Cultura Acadêmica, 2001.

SHANNON, C. E. & WEAVER, W. The Mathematical Theory of Communication. Urbana, Chicaco, London:University of Illinois Press, 1949.

VON BERTALANFFY, L. Teoria Geral dos Sistemas. Tradução de Franscisco M. Guimarães. Petrópolis:Vozes, 1973.

ZEMAN, J. Significado Filosófico da Noção de Informação. in ZEMAN, j., et. all., O Conceito de Informação na Ciência Contemporânea. Tradução de Maria Helena Kühner, Rio de Janeiro:Paz e Terra, 1970.

#Filosofia #Informação #Ciência #Sistemas #Sistêmica



Riverfount
Vicente Eduardo Ribeiro Marçal

Filosofar com Arte


Simplesmente por buscar compreender o incompreensível ter diante de si uma imensidão inatingível mas saber em seu íntimo no âmago de si mesmo que estás sozinho e desvelado Saber mais do ser-em-si É estar sem amarras ou marcas sem mistérios ou máscaras porque estás diante de si mesmo e tens que contemplar a verdade, nua e cura que te define A verdade do ser o que é e do não-ser que não é A verdade de não compreenderes a si mesmo ao recusar o devir Sabendo somente que o conhecimento te satisfaz Numa onda fugaz De dor e prazer O puro saber pelo puro saber Em fim, descobrirás O sentido que tanto buscas É o prazer infinito que só o conhecimento pelo conhecimento Pode proporcionar.

#Filosofia #Arte #Poesia



Riverfount
Vicente Eduardo Ribeiro Marçal

Arte e Filosofia

Hoje me permitirei divagar Dando asas às minhas emoções Pelos caminhos oníricos seguir

Hoje me permitirei não pensar Deixando fluir a libido Pulsando a vida que em meu peito arde

Hoje me permitirei ser arte Arte que vislumbra a verdade No jogo eterno da mimésis

Hoje simplesmente me permitirei Viver, cantar, dançar, lembrar Que na razão forte de todo mestre Bate um coração vivo que na arte floresce

#Arte #Poesia #Filosofia



Riverfount
Vicente Eduardo Ribeiro Marçal

Viver na justiça

Sempre é necessário relembrar que a busca por justiça passa, necessariamente, pela indignação e denúncia da injustiça que acontecem a nossa volta. Denunciar a injustiça é viver em desacordo com as estruturas sócio-política-econômicas de seu tempo.

Nossa sociedade está profundamente marcada pelo domínio externo do hemisfério norte. Vivemos em um modelo neo-liberal imposto sem possibilidades de libertar-nos. Segundo Darcy Ribeiro, para compreendermos esta relação de dominação devemos considerar quatro principais tensões:

  1. as disputas entre as potências imperialistas industriais;
  2. a oposição entre os povos atrasados e seus exploradores;
  3. o antagonismo entre o campo capitalista e o socialista e
  4. as tensões inter-socialistas.

Estas tensões, foram estabelecidas por Darcy Ribeiro no início dos anos 70, quando ainda existia o socialismo soviético, mas não podemos deixar de ver como são atuais, mesmo entendendo que sem o socialismo soviético as tensões se reduzam às duas primeiras.

Esta conjuntura nos coloca no meio de uma disputa de nós mesmos. Somos objetos da ganância dos países desenvolvidos que nas disputas de mercado acabam por ficar com nossa produção, afinal o melhor por nós produzido é exportado. Pior que isso é que acabamos por ter a necessidade de importar para suprir o mercado interno. Desse modo, o círculo vicioso gerador de dependência se eterniza. Sem mencionar o fato que nosso povo não é sequer considerado mão-de-obra, mas simplesmente massa marginalizada, excedente da força de trabalho que o sistema produtivo modernizado não consegue incorporar. Não consegue e nem tem intenção de incorporar pela extrema especialização que o trabalhador necessita hoje em dia. E não é o caso de se defender a não especialização da mão-de-obra pro mercado de trabalho, pelo contrário. Contudo, o sistema é mais excludente do que inclusivo.

Outra característica do sistema é que aqueles que conseguem ser incorporados ao mercado temem, cada vez mais, o crescimento numérico dos excluídos, pois, com a expansão avassaladora do sistema econômico capitalista neoliberal, as massas marginalizadas deixaram de crescer apenas biologicamente, mas, crescem também, por achatamento das classes intermediárias.

Estamos certos de que este processo acontece desde 1492, e que simplesmente somos fantoches nas mãos das nações dominantes, escondidas atrás de uma pretensa política internacional desenvolvimentista. Desenvolvimento que não ocorre, pois não é o que realmente promovem. Não temos condições de desenvolvimento autóctone; se o tentamos, o primeiro passo de represália dos países desenvolvidos é o boicote. O que temos, então, é uma sociedade fundamentada na injustiça social e econômica.

O sistema é mais sutil do que imaginamos, pois promove, de forma sorrateira e imperceptível, um descompromisso com a vida. Afinal estamos todos na busca de manter nosso meio de subsistência e acabamos por não atender àqueles que estão a nossa volta. Buscamos, num individualismo exacerbado, legitimar as posses e a acumulação dos bens materiais, não importando a situação do próximo e, assim, justificando o aumento da desigualdade social.

Quando nos rendemos aos ditames do mercado, da exclusão social das maiorias e, principalmente, ao perder a solidariedade como compromisso com dignidade humana, desfigurada por uma sociedade que dá exagerado valor ao capital, nós, enquanto membros dessa sociedade, estamos nos conformando com tal sistema e sendo seu coadjutor, legitimando, assim sua atuação.

Não podemos, é claro, dizer que esta é a regra geral. Percebem-se várias tentativas da sociedade civil organizada para minimizar os flagelos impostos por um sistema individualista e promotor do acúmulo a qualquer custo. Mas há a grande necessidade de que todos se conscientizem do papel solidário que cada um ocupa na sociedade e, assim, tome consciência de sua função e seja a voz que denuncia as ações de injustiça que rebaixa o próximo à condição sub-humana.

Assim, devemos estar prontos para intervir na história, promovendo a justiça e re-estabelecendo as relações justas e a dignidade humana que se caracteriza pela libertação do jugo da opressão de um individualismo egoísta que nos faz pensar que o mundo gira em torno de nosso umbigo e que as pessoas são servis a nossos propósitos. Não devemos, como muitos fazem, relegar a um futuro pós-mortem essa vida boa que podemos ter no aqui agora. Uma vida boa fundamentada no Bem-Estar-Social e na qual compreendemos o verdadeiro sentido da Rês-Pública, ou seja, da coisa pública, daquilo que pertence a todos.

Esse modo de viver deve considerar que a vida humana tem precedência. Essa precedência deve ser marcante no modus vivendi da sociedade, pois o ser humano é um todo complexo e sua dignidade humana é um valor, como afirma Kant, inestimável. Assim, temos que agir com o outro como um fim-em-si-mesmo e não como um meio para alcançarmos nossos objetivos.

A sociedade Latino Americana e Brasileira é incrivelmente injusta, impondo a milhões de pessoas a miséria, a exclusão e um modo de vida sub-humano. Relegando a seus jovens uma situação insuportável diante da necessidade de emprego e a escassez do mesmo no Mercado de Trabalho. Portanto, é dever daqueles que pretendem viver numa sociedade justa e solidária denunciar as mazelas estruturais causadas pelo sistema neo-liberal.

Aqueles que almejam viver numa sociedade justa e solidária compreendem que estão diretamente ligados a todo o processo histórico em que a justiça social está sendo almejada e não vivem suas vidas como se a dos outros não importasse.

Compreendem que suas ações versam diretamente sobre a transformação de toda a sociedade, para que toda a sociedade na qual estiver inserido seja também transformada numa sociedade justa e solidária, por viver de forma justa e solidária.

Diante de tantas mazelas, existe uma esperança, que não é meramente futura, mas a partir de hoje: a boa notícia para o ser humano marginalizado e excluído pelo sistema opressor é que existem pessoas comprometidas com a transformação social onde vivem.

Portanto, anunciemos essa utopia que visa dar esperança ao nosso povo sofrido e marcado pelo sistema neo-liberal e injusto. Busquemos realizá-la como sociedade civil organizada, sendo um farol no mar agitado do neocolonialismo que nos é imposto. De onde podemos contemplar a esperança de, juntamente com o todos os seres humanos, vivermos num Reino dos Fins, como vislumbrava Kant.

#Filosofia #Justiça #Solidariedade



Riverfount
Vicente Eduardo Ribeiro Marçal