Blue text on dark green background is not very colorblind friendly. Even if you don't use fancy javascript or css, a strong colorscheme with proper contrast does wonders.
The impression the page design had on me was highly different. Does the developer really want me to use the language? If so, why not invest only a bit amount of time in thinking about it's presentation?
This is pretty clearly an archival site. The links under "Current (more-or-less) Emerald information" point to a university site updated in 1998 and a mothballed Sourceforge repo with no activity since 2005.
With even a tiny bit of CSS (which can be inlined in the head tag if you don't want an extra fetch), you end up with this: https://jmn.link/css-example.jpg . That's 152 bytes of non-minified CSS to accomplish that.
Going further, if you drop the table-based layout, then you can get something equally as small, that doesn't break horribly on mobile.
Of course, none of this was really an option when this page was created (look at the age of all the links in it).
From my memory, creates an object, gets all the other active nodes in the cluster, moves them to that node and then back to the original node, showcasing the object passing feature of the language.
I recently took a compilers course from Hutchinson, and he talked a bit about the design behind object passing in Emerald from a compilers point of view, how once you have garbage collection, it's easy to implement moving objects between nodes of programs. Interesting concept that I was surprised to find wasn't as commonplace!
One issue is that at scale, communication costs dwarf almost every other cost. So, sending objects between nodes isn't as critical as you might think it is for distributed systems.
(I was also in Norm's class! It was awesome, and also got me over the Rust hype to some degree)
I guess he means that you don't need speed for distributed applications, which is a bit misquided because nobody said you did, and that's not what Rust claims to do well.
Oftentimes the biggest cost associated with communication is latency, and the one thing that hasn't changed over the past few decades is the speed of light.
Garbage collection isn’t absolutely necessary with lifetime/liveness or explicit frees. Furthermore, at scale in production, if a GC were absolutely necessary, then it’s vital to have a concurrent, incremental collector like c4 because GC 30 sec pauses and sharding up app servers with 2 GiB heaps is unacceptable in the real world.
This is another gem of weird internet design. Note especially the animations on hovering over images, and color choices on some of the linked pages. It somehow sort of works though. http://insti.physics.sunysb.edu/~siegel/
If they want to be thematic, they should make the word Emerald in emerald green, which this background is not. Readability should not be sacrificed for some theme or branding dealie.
Most of the comments seem to be about the page design, for a page that was probably created in the 90s. Nevertheless, Emerald the language is pretty fascinating, and way ahead of its time (it was developed in the mid to late 80s). They had strong static typing, including getting co-/contravariance right a decade before Java got it wrong! It was the first object-oriented language that I know of to have a statically-typed structural type system. In fact, the technique that Go uses to implement dynamic dispatch was independently invented 20 years earlier in Emerald. And its objects were mobile, which very few languages even today attempt.
Emerald objects can move from one node to another. So, for example, if an object on machine X wants to perform computation using data on some remote machine Y, the object can move to Y and have (fast, local) access to Y's data, then move back to X when it is done. So the computations themselves are mobile. This required some cleverness in the implementation, because a process's stack might even be split between multiple machines (I might be remembering that wrong).
The code snippet on the page looks incredibly clean and readable, exactly how I wish modern languages would look like. Too bad Algol-style syntax is no longer used that often (except for Delphi).
Among other things, they also show how we keep reinventing the wheels (with slightly different paint jobs).
Our biggest achievement nowadays seems to be clients asking for data in the shape preferred by the client - with data being in a primitive tree like format with anemic types.
Or a bit more complicated neural nets.
We still haven't moved beyond van neumann architectures.
54 comments
[ 1.8 ms ] story [ 126 ms ] threadhttps://benchmarksgame-team.pages.debian.net/benchmarksgame/
Going further, if you drop the table-based layout, then you can get something equally as small, that doesn't break horribly on mobile.
Of course, none of this was really an option when this page was created (look at the age of all the links in it).
https://en.wikipedia.org/wiki/Kilroy_was_here
(I was also in Norm's class! It was awesome, and also got me over the Rust hype to some degree)
You can't just throw a detail like that and not tell us more. :D
That may have been true 10 or 20 years ago when networking was much slower.
Oftentimes the biggest cost associated with communication is latency, and the one thing that hasn't changed over the past few decades is the speed of light.
But really, they didn't pick emerald, they picked 'screamin green'(#55ff55)
Emerald(#50C878) would have been a much better choice(but still a bad one)
Can you explain what you mean by that?
FYI I vouched for your comment, it was [dead] for some reason. But I found it relevant and interesting.
http://www.emeraldprogramminglanguage.org/TSE-1991-paper.pdf
But it hasn't seen much use outside of the 1980s in academia. I doubt you'll find much on it.
Among other things, they also show how we keep reinventing the wheels (with slightly different paint jobs).
Our biggest achievement nowadays seems to be clients asking for data in the shape preferred by the client - with data being in a primitive tree like format with anemic types.
Or a bit more complicated neural nets.
We still haven't moved beyond van neumann architectures.