What I wish we had was a "man" equivalent to provide every-day examples of how to use the tool "correctly" (although I'm aware there's stuff like "bro" pages), as well as another tool to explain why some tool / option even exists and how they're "expected" (by the creator / maintainers) to be used. As I've gotten into the habit of reading man pages I've become increasingly aware of how many options certain tools provide, but in many cases I really cannot fathom why those options are available or in what kind of situation they might be used.
Consider SAP. It's complicated to say the least, but a lot of that complexity comes from both it's generality, it's flexibility, and the quality of the solutions it solves underneath.
Any solution you write in SAP could be written in a much simpler manner using simpler tools, but doing so would and getting your solution to the quality of what you can get in SAP would be hugely expensive and take a lot of time.
In that way we subsidize each other, but in doing so, we often make things much more complicated than they strictly need to be to solve any particular problem.
Now this is a different class from things that are just shitty design. Those exist in abundance, and it's unfortunate, but that's life.
Fundamentally, we don't really do discoverability well because volunteers are fickle as hell, and commercial interests are profit-focused.
If you could marry up the advantages of text/files, live code, visual layouts, data visualization and perhaps machine learning in the future, maybe you could come up with a huge jump in productivity and being able to handle complexity.
The main thing that stops people from beelining down this path is the sheer quantity of yak-shaving involved. We're all impatient and have near-term goals, and glue-and-iterate gets us there without having to engage in a non-linear deconstruction and analysis of what's going on.
[0] http://www.red-lang.org/ [1] http://www.vpri.org/html/writings.php
(please, no one mention stephen)
Is that really such an advantage? What kind of advantage does having source code scattered in files have over Smalltalk's Change Log? The Change Log greatly simplifies having live code, and having a runtime environment where you could crash the system with a runtime change. Source code in text files complicates this. It's also a powerful development tool all by itself. What's more, it's just a clever use of a text file!
The graphical nature of the Smalltalk environment also really helped to make it accessible. Erlang lives mostly in text terminals.
I'm still not convinced of the 'image' mechanism, it's really nice to have implicit and automatic persistence but it glues the code so strongly to the data that it starts to hamper collaboration. Being able to easily pull a bunch of stuff from one machine to another and to integrate it with stuff that was already there is something that other programming languages have solved very well (together with DVCSs), Smalltalk seems a step backwards in that regard.
Though there are times I wished for an easy way to hibernate an entire session for later re-use.
It never caught on but it was an interesting path not taken in terms of what an operating system could be.
(I understand there are physical constraints that prohibit super low-latency memory lookups (of unconstrained size) in 0+epsilon time (where epsilon is small))
A link to a transcript would be cool.
Edit: There's a transcript of the iPad question here: https://news.ycombinator.com/item?id=8857113
This isn't really true, it's just a snobby idea the French have somehow successfully convinced us of. (It goes along with the idea that they have the most "refined" culture or something).
In order to learn French and its vocabulary, English speaker will found a lot of similarity but from the more formal side of their vocabulary. That would lead English speaker to think French is more precise, I don't think the French have something to do with this.
That's BTW a common mistake English speaker make when evaluating some French speaker proficiency. The fact that I use rarely used words does not mean that I have a large vocabulary, it is just the opposite.
Few years later, English feels restrictive and too simple. French aggregated many influences from centuries at a crossroad, and it seems it kept a lot in order to be able to add subtle layers of information by using particular sets of words fitting together well to propel metaphores and other succint yet precise description of the world.
Now I say that, on average, about mainstream incarnations of both En and Fr, surely you can find poetic and tailor made English wording, in France it seemed part of the culture, but recently it's been on the way out, only elders speak a bit that way.
> We built a prototype of the emulator in C, but it quickly became obvious that we could not achieve the level of performance desired in C. Examination of code emitted by the C compiler showed it took very poor advantage of the Alpha's dual-issue capabilities. A second implementation was done in Alpha assembly language and is the basis for the current product.
First pass in C. Final, in Assembly.
Chip at the time was a first-generation DEC Alpha AXP 500 which had a 512 KB B-cache and two 8 KB caches.
https://en.wikipedia.org/wiki/DEC_Alpha
Let's say its present day and you want to fit into a 256K L2. What language toolchains are available? How far can one go with JIT?
I'm pretty sure Chuck Moore (yes, he's still around) would be able to fit the interpreter and an entire OS into the L1 cache with room to spare. Forth technically is an interpreter.
As you imply, the interpreter will be dwarfed by the code needed to talk to the rest of the OS. As an aside, this is why I was initially very excited about the JVM when Java first came around. Compiling down to a FORTH style language should give you pretty impressive benefits.
Virtual machines were very popular for a long time, but I'm not entirely convinced that we've really pushed the concept as far as it can go.
I remember back in the day someone was working on a Forth version of OpenStep. Weird, but there were some funky Forths then too. I so wish they had succeeded.
The APL, J and K languages are known for being very fast; I vaguely remember one reason being given that their programs are so terse and high-level, they're compact enough to fit in cache. Not sure if the interpreter would though.
Also, I suspect most of the memory related slowdown with interpreters is due to the indirections in memory representation of data/code, not the interpreter itself falling out of cache.
Those are the one that come to mind when I think of simple and very powerful tools. There are many others. So I think Alan Kay and friends have demonstrated that we have made things complicated for dubious reasons.
But what has been built with these tools? If OMeta was really better, wouldn't we be using it to parse languages by now? They already have a successor Ohm, which is interesting, but I also think it falls short.
I'm searching desperately for a meta-language to describe my language, so I would use it if it were better.
I think they generally do the first 90%... but skip out on the remaining 90% (sic) you need to make something more generally useful and usable.
It has been done many times. There was a Camp Smalltalk initiative to standardize such a mechanism back in the early 2000's. Anyone could code something up that does this for a particular dialect in a matter of minutes.
1) People just get started and get used to not really understanding the interface they are working with. Who hasn't felt like they were playing whack-a-mole with CSS layout? This means lack of conceptual clarity fails isn't notable.
2) Nobody ends up noticing just how complex the rules are.
It was 9 years from when I started looking for a tutorial like http://book.mixu.net/css/ to when I actually found it. That is...really quite bad.
This describes English perhaps more so.
> and it seems it kept a lot in order to be able to add subtle layers of information by using particular sets of words fitting together well to propel metaphores and other succint yet precise description of the world.
It's your native language, so of course you might think that (especially when added with this snobby French cultural ideal).
Also how can England be more influenced by countries as an Island ? the naval conquests, the commonwealth ? I don't know history much, but it seemed to me they kept a very cohesive identity except for the not so French/English feedback loop.
http://www.oilshell.org/blog/2016/12/27.html
I tend to agree and most of my shell is either written from scratch, or copying and adapting small piees of code that are known to work. I take ownership of them rather than using them as libraries.
That is even the case for the Python interpreter, which is the current subject of the blog.
I'm not quite sure, but I think OMeta falls even shorter than the typical piece of software. I'm not saying it's not worthwhile -- it seems like a good piece of research software and probably appropriate for their goals. But to say it generalizes is a different claim.
[0] https://groups.google.com/forum/message/raw?msg=alt.language...
Worse, the French apparently teach young students to write in a way that they consider profound, and the Anglosphere considers imprecise drivel.
In physics, we don't know what the fundamental rules are, we can only see complicated outcomes and have to infer (guess) what the rules might be.
In computing, we know what the fundamental rules are (universal computation; whether that's turing machines, lambda calculus, sk logic, etc. they're all equivalent in power), but we have to deduce what the complicated outcomes are.
In a limited way. Because we're making systems that involve people. Important and relevant aspects of human nature must go far deeper than our present understanding.
People (outside of Ericsson) just haven't bothered to take much advantage of Erlang's strengths. Erlang speaks network wire protocols very efficiently, so if you want graphical Erlang sessions, you just need to write Erlang applications that act as e.g. X11 clients. Which is what things like Erlang's own Observer application does, complete with the ability to use the graphics toolkit Tk. (Or, if you like, you could expose an HTTP server serving a web-app with live updates over a websocket, like https://github.com/shinyscorpion/wobserver. Or an VNC/RDP server. It's really all equivalent in the end.)
Unlike Smalltalk where the graphical capabilities are part of the local console framebuffer, Erlang's approach allows you to interact with a running Erlang node graphically irrespective of your locality to it—which is important, because, in the modern day, your software is very likely a daemon on a headless server/cloud somewhere.
This is true of every Erlang system I have developed, so, I concur.
I am no genius, but I was able circa 2008 to develop a significant production system in Erlang, while learning Erlang on the job over a period of 3-4 months. I had never programmed in a functional language before (C++ was my forte). In 2008, the tooling and environment surrounding Erlang was far less supportive than it is today, so the barrier now should be lower.
If you want to talk about a huge barrier to entry (for me, anyway), it's the Great Wall of Haskell. I found it a great deal harder to learn Haskell. I have only written one small utility in it and still don't claim to know the language. And that's after using Erlang for many years.
Also, these days, Elixir is reputed to lower whatever barrier to entry there is for Erlang.