"RT" [FoRK] Programming languages, operating systems, despair and anger
Thiago Silva
http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html
Achei hilário, com alguns pontos interessantes. Transcrição, na integra, abaixo:
------
Or, the State of the End-User Environment / Programming Onion...
So, in a confluence of events, I have been lately looking at Scala and
yesterday spent some time looking at Pike / Thompson / Google et.
al.'s "Go" language for "systems programming." And Guido halts Python
syntactic evolution before the job is done...
And it fills me with despair and anger.
Language designers in general: You are IN THE WAY. Go here:
http://www.rebol.com/oneliners.html
...then do us all a favor and don't resist the urge to fall on that
wakizashi when your shame overcomes you.
First of all, neither Scala nor Go is anything more than incremental
evolution; Go in particular put me over the edge. It's merely the
latest of a series of languages from these same people (former god-
like heroes to me) --- most recently Limbo, each successive one of
which implements the same ideas in barely, idiosyncratically, every-so-
slightly different ways. And so for 20 years now these folks ---
*the* shining lights, in many ways, of "practical" programming
language, operating systems, and general systems research --- have
continued to fail to "get" the fundamental practical needs of everyday
programmers working in The Real World. "Go" is just another language
written first for the compiler and only secondarily for the programmer
--- and stuck in a 70s mindset* about the relationship of that
programmer to the (digital) world within which they live and work!
(But hey, it compiles fast! Which is, of course, THE problem that
really needs addressing.) (Or rather, a fast-forwarded 70s mindset
projected into a fictional future. I get the sense that Google is a
bit Star Trek-ish; an anachronistic-nostalgic future that doesn't
really exist outside of its own fictional milieu. I mean --- it took
'em 200 years to figure out the implications of the transporter
buffers --- and then they didn't even take advantage of them
consistently? GMAFB. But I digress.)
I think Carl Sassenrath may be the only person on the planet working
in this area that accurately perceives the "pain" involved in general,
everyday, practical programming and is *actually* trying to address
it. Too bad his solution is locked in closed source, in corporate
lock-in, and in a company that *clearly* is suffering from a
completely schizophrenic (lack of) "business model" --- no doubt due
to the influence of investors and suits and isolation. (Not to
mention suffering from ghastly-ugly, mondo-1989 graphic design of its
built-in GUI toolkit components and hence all application UIs.)
(Other candidates for clue include Eric Meijer who, unfortunately,
seems to have been unable to translate clue to practice in many ways,
despite lots of "enterprise-scale" innovation; and Alan Kay, who has
some real ideas ("Worlds" == absolutely awesome idea) but is
apparently suffering from "research / think tank / industry alumni"
inability to reduce research to practical practice.) (Wolfram might
get it... maybe, part of it... but let's not go there, same lock in
probs as Carl's gig but a whole lot worse, and a lot of other issues
too.)
What do we do? Communication, coordination, automation, analysis, and
visualization / animation / interaction. That's IT. Over a few-dozen
basic kinds of information and in a handful of typical hardware
environment / architectural scenarios. Come on!
J.H.C, folks, it's nearly 2010. Let's get a few things straight:
- most programming involves schlepping a few but complex data types
between different string representations
- programmers have become plumbers and documentation-archaeologists
mostly, which is sad and uninteresting
- programming languages are for *programmers* --- not compilers and
compiler-writers
- until you make the everyday, "simple" things simple, it will
continue to be a dark art practiced by fewer and fewer
- any language that makes you explicitly import an IO module to
read a file or stdin is fucked
- declarations are a pointless anachronism (same for explicit
memory management)
- if I have to understand category theory to write a program that
does IO, IT IS A NON STARTER!
- less stupid line-noise syntax and punctuation, people
SIMPLE GUI PROGRAMMING! Remember BASIC? Logo? Zero to graphics in
three minutes, max. How the hell are kids supposed to learn to
program these days? Even Python's learning curve is too high, IMHO,
though it's probably the closest thing to a reasonable starting ground
that has any real traction. And the GUI bar is raised these days:
kids and non-developers (and busy developers w/o time for little,
interesting toy projects *just because project set-up cost is so high
in almost any language / environment!) need to be able to throw
together complex multi-agent 3D microworlds with minutes. (Yes, I'm
aware of Kodu and friends. It's a start, maybe; but it needs its
textual equivalent; enough with the "only visual programming" crap,
it has shown its limits.)
If you provide some binding / embedding to Tk and you think that's
sufficient to satisfy your GUI needs, then IT'S A NON-STARTER! If you
DO NOT provide a CANONICAL cross-platform GUI toolkit, IT'S A NON-
STARTER!
If it's more than 5 readable lines to produce a "hello, world" web
server --- NON STARTER!
If sending an e-mail isn't a one-liner --- NON STARTER!
Getting a web page or making a simple http post > 1 line --- NON
STARTER!
Figuring out the number of days between two dates > 1 line --- NON
STARTER!
While I'm on a rant, FUCK JSON. I mean, first fuck XML thoroughly and
nastily, but let's call it like it is -wrt- JSON. Anything that
forces me to do this shit:
{
'someSymbolicKeyAsString': 'someUriValueAsString'
}
...is BROKEN BY DESIGN!
NO MORE TUNNELING CRAP IN STRINGS!!!
*REAL WORLD*, modern datatypes, built-in, literal, batteries-included
PLEASE!!! If the following aren't first-class types with first-class
literal constructors / representations supported *at the language
level* then your new programming language ISN'T EVEN ON THE PLAYING
FIELD:
- symbols AS SUCH
- numbers AS A SINGLE TYPE
- strings NOT AS BYTE ARRAYS
- a single, universal aggregate type (cf. Lua tables, more or
less; Rebol blocks)
- e-mail addresses, file / directory paths, and general URI types
- date and time constructions with simple operator arithmetic
- generic markup constructs (cf. Meijer "Unifying Documents [etc.]")
- domain names and IP addresses
- regexes and structural regular expressions
- generalized patterns for pattern-based dispatch
- quantities --- numbers with attached dimensionality
- booleans and *potentially tri-state logic support*
- ranges and slices
- some controlled ability to do open classes
- concurrency constructs AS SUCH
Also: if your language doesn't include a CPAN / CRAN / etc. repo and
package-distribution capability BUILT IN, it's again a non-starter!
Dammit, people!
And let's get a few things straight: I don't care if it's the OS,
language, or language-integrated runtime (as opposed to externalized
"standard library" or even worse third-party library) but:
- the "operating system" or runtime should provide *real world
abstractions*, too
- higher-level stuff BUILT IN, like:
- person, group, social network, presence, identity,
authority, permission, etc.
- media objects: audio, video, pdf, still images, etc. (just
a few!)
- pages, bookmarks, notes, tasks, todo lists, other lists,
calendars, events, etc.
- spreadsheets, charts, diagrams, formulas, maps, etc.
- tagging rather than hierarchy --- EVERYWHERE
- workspace, context, orthogonal persistence, location-
transparency
- context awareness, "cluestreams", user activity,
remembrance agents enabled / made easy
- not just multi-core single-machine or homogeneous-cluster
programming, but rather:
- a heterogeneous, loosely-connected, multi-device, multi-
input, user-centered universe-of-tools
- multiple machines, multi-machine-aware tools and objects
- programmable / multi-machine clipboard / clipping /
plumbing
- scheduling (i.e. cron), rules, etc. (e.g. things like
"Puppet" unnecessary!)
- caching / replicated / fully versioned home dirs, drop
boxes, etc.
- deep support for both client- and server-side personalizable
HTTP and mail services
- handling of disconnection / replication / synchronization
- dispense with application-level balkanization of data!
- composition and re-use
Grrrr.... it's pretty damn sad that something as limited and now-
ancient as bash represents some kind of optimum of productivity for
many real-world "everyday programming" tasks --- and yet fails so
miserably for so many other everyday programming tasks due to lack of
data abstraction and richness.
If I have to write one more polyglot bash / awk / python script to
gather data from log files on a bunch of different machines, demux
that into a time-ordered event stream, pipe it through something to
munge it into some slightly different format, ship that off via post
to some web address and get some JSON back, parse that into some other
shit, do some computation over it like aggregation or date math over
time stamps with unlike representations, wrap the results up in an
HTML table and send that table in a MIME-enabled e-mail to myself I
think I am going to *explode.*
90% of the shit that gets written doesn't even involve anything as
complicated as finding set partitions. Really.
Somebody do something about this, before I LOSE MY FUCKING MIND!?!?!
jb
--
Thiago Silva
Computer Science
M.Sc. Candidate at Federal University of Pernambuco
jabber/gtalk: tsi...@jabber-br.org
http://blog.sourcecraft.info
Ronaldo Ferraz
construção de compiladores e linguagens. Tem que virar o manifesto do
campo. :)
R.
Eduardo Habkost
>
> rant recente sobre PLs:
>
> http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html
>
> Achei hilário, com alguns pontos interessantes. Transcrição, na integra, abaixo:
http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054580.html
(copiada abaixo)
Os problemas são reais, mas esperar que uma ferramenta ou um projeto vá
conseguir tratar todos eles de modo aceitável é utópico. E mesmo se sonharmos
alto e acharmos que todos eles serão resolvidos, logo aparecerão soluções e
tecnologias novas, e essas novas soluções e tecnologias por sua vez estarão
mal-integradas, e lá vamos nós de novo.
E depois disso chove gente oferecendo uma bala de prata, dizendo "se todo mundo
usasse _essa solução aqui_, esses problemas todos seriam resolvidos". Alguns
dizem que o problema é padrão de comunicação, outro oferece um sistema de
tipos, outros culpam o sistema operacional, e por aí vai.
----------
> 90% of the shit that gets written doesn't even involve anything as
> complicated as finding set partitions. Really.
between different utopian ideals that partially implement what you
describe in the rest of your email.
[...]
What you describe is a massive undertaking - and one rife with
problems that when resolved result is a mess of not quite right
solutions. Your platonic ideals will not help you here.
--
Eduardo
Ronaldo Ferraz
quarenta anos já. Mas isso não deve impedir pensar em como evoluir o
que temos atualmente.
Eu me lembro das duas linguagens que o Tiago comentou aqui
recentemente: Pi e Ginger. Cada uma delas, ao seu modo, pushes the
envelope a little bit propondo conceitos novos e formas novas de se
olhar para problemas. A evolução deve ser incremental e eu não acho
que o autor do texto quis dizer que tudo deva acontecer da mesma
forma.
As palavras-chave acima são todos e massive. Todos não é necessário e
massive é uma boa forma de dizer para não fazer nada. :)
Para mim, chega de linguagens C-like (Go et al) que não tentam criar
novas formas de compreender o campo. Não acredito na hipótese forte de
Sapir-Whorf, mas sou fã de Alan Perlis. ;)
R.
Guaracy Monteiro
>
> rant recente sobre PLs:
>
> http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html
>
> Achei hilário, com alguns pontos interessantes. Transcrição, na integra, abaixo:
>
> ------
E eu fiquei triste ao ler o texto. :-)
Certamente as coisas devem ser simples e poderosas sem a complexidade
e o desperdício que ocorre hoje. Como diz o texto: "Linguagens de
programação são para programadores".
Acho que a utopia é um bom começo. O problema é que o pessoal não
consegue transformar a utopia em realidade. Ter que montar um palco
para resolver um problema simples não tem sentido.
Aí o cara pega aquela linguagem, melhora um pouquinho aqui, descarta
aquela parte lá, da um novo nome e pronto. E aí sai um C ligeiramente
modificado que agrega pouco ou nada para os programadores.
Ele citou Rebol. Eu acho que é um ótimo ponto de partida para quem
deseja começar alguma coisa nova e não apenas um C diferente. Também
acho recomendável dar uma atenção especial as idéias do texto na
tarefa.
--
Guaracy Monteiro