[HN Gopher] Elixir 1.11
___________________________________________________________________
Elixir 1.11
Author : nifoc
Score : 301 points
Date : 2020-10-06 14:38 UTC (8 hours ago)
(HTM) web link (elixir-lang.org)
(TXT) w3m dump (elixir-lang.org)
| areichert wrote:
| Pretty stoked for this. I started learning Elixir a few months
| ago [0] and it's been a great balance of fun + practical. Way
| easier to get up and running compared some other FP languages
| I've dabbled with in the past :P
|
| Also shameless plug: we're currently working on an open source
| messaging product called Papercups [1] if anyone is looking for
| an Elixir project to hack on!
|
| [0] https://www.papercups.io/blog/elixir-noob
|
| [1] https://github.com/papercups-io/papercups
| princevegeta89 wrote:
| I know you from your previous ShowHN, good luck, your product
| looks great!
| areichert wrote:
| Thank you :)
| ch4s3 wrote:
| I know support for the map.field syntax in guards is a bit
| controversial, but I'm really excited about it!
| pmarreck wrote:
| I actually already built that functionality in the past using
| macros so it might be similar
| auraham wrote:
| I love Elixir. I would like to see more improvements in iex,
| something like ipython for python.
| lytedev wrote:
| I'm very interested in hearing about some specifics!
| svnpenn wrote:
| Does anyone know a fast mirror for Erlang? Every time I try to
| download its very slow:
|
| https://github.com/erlang/eep/issues/12
| anonymousDan wrote:
| Are there any plans for JIT compilation for elixir/Erlang and if
| not why not?
| jetpackjoe wrote:
| Yes! See
| https://twitter.com/josevalim/status/1304399735445426176
| lawik wrote:
| Slated for release in OTP 24 I think. This covers the spproach
| they use: https://youtu.be/lM7UV95Rpyo
|
| Most interesting take-aways from benchmarks are some cases
| where RabbitMQ processes 30-50% more messages per second. And
| where a native Erlang JSON library beat NIF C library in some
| specific tests. The PR link covers this info.
| thepratt wrote:
| https://github.com/erlang/otp/pull/2745 may be what you're
| after.
| dcolkitt wrote:
| Question from someone who's never tried Erlang/Elixir but is
| interested.
|
| If you're starting a greenfield project in 2020, is there any
| reason to use baseline Erlang instead of Elixir? I get the
| impression that Elixir is a strict improvement (besides legacy
| compatibility). But this is a very very uninformed impression.
| dnautics wrote:
| It's not an improvement if you prefer prolog syntax (for the
| record, I personally don't). Everyone likes to say that syntax
| doesn't matter, but it can affect your time-to-POC, example
| comprehension, debugability, especially if you're starting a
| greenfield project.
|
| Otherwise, I would say stick with elixir. It is more
| opinionated about how to do tests, how to organize your code,
| how to do documentation, how to deploy, how to use libraries,
| all of which will make your life way easier, especially for a
| greenfield project.
| ihumanable wrote:
| I work in Elixir most of the time but can read and write Erlang
| reasonably well, here's my two cents.
|
| Elixir's syntax was inspired by ruby and so if you've used ruby
| or look at ruby code and think, "yea, I get what's going on
| here" then you will likely find working with Elixir's syntax
| preferable to Erlang. Erlang's syntax was based off of Prolog
| and so it will be less familiar, unless you have done a bunch
| of Prolog programming.
|
| Elixir layers on a bunch of things that are very nice to have
| at a language level, the ability to rebind names is probably
| the one that most impacts code. In Erlang you can't rebind a
| variable, so Erlang code ends up either using lots of very
| small functions of having variables like `n` `n2` `n3`. It's
| not that you can't write good, clean, easy to reason about code
| in Erlang, but if you are coming from a language with
| mutability and variable rebinding, it's a bit of a culture
| shock. I find that Elixir hits a nice medium ground to allow
| you to wrap your head around immutable data structures,
| functional programming, actor model, OTP without ALSO having to
| climb the hills of unfamiliar syntax and some limitations (like
| variable rebinding) that aren't strictly necessary.
|
| From a tooling standpoint, I find Elixir to be a bit more
| pleasant than Erlang. Mix (build tool) is great, ExUnit (unit
| testing) is great, ExDocs (docs generation) is great, Hex
| (package management) is great. The Elixir community has somehow
| stayed pretty unified when it comes to tools and for the most
| part they work really well.
|
| From an interoperability standpoint, you really don't leave
| anything behind choosing to use Elixir over Erlang. Erlang
| dependencies work just fine, and the interop is so easy, here,
| I'll give you an example.
|
| Want to use an Erlang module directly from your Elixir code,
| here's an example of how to use the timer module.
| :timer.seconds(1)
|
| That's it, that's the interop, you don't have to import
| anything weird, you don't have to fence off your code, you
| don't have to juggle types from Elixir types into Erlang types
| and back again. Want your Erlang interop to look more like
| elixir, two lines of code. alias :timer, as:
| Timer Timer.seconds(1)
|
| Overall the Erlang and Elixir communities are friends (and
| Gleam, LFE, and all the other BEAM Languages). It's a very
| positive community all working to build great functionality on
| top of the really cool piece of tech that is the BEAM VM.
| PopeDotNinja wrote:
| Speaking for myseld, rebinding variables in Elixir is my
| least favorite part of the language, and I specifically avoid
| using the feature.
| sodapopcan wrote:
| I'm on the fence about re-binding variables. I don't really
| mind it and have gotten used to the pin operator when I
| need it. I actually use variable re-binding quite a bit but
| always _only_ in situations where I want a prime.
| def foo(bar) do bar = decorate(bar)
| {:ok, bar} end
|
| I like that better than calling it something like
| `new_bar`. I kind of wish there was prime syntax along the
| lines of `bar' = decorate(bar)` but I can deal with re-
| binding when only used like this (and really, the stakes
| are low). More complex cases can generally always be
| handled with piping.
| dnautics wrote:
| you shouldn't do it in your code, and code linters (well,
| credo) can check for it and yell at you. I think you might
| have to activate it currently.
|
| I 100% guarantee you don't miss it in your REPL.
| ihumanable wrote:
| Yea, I'm mostly approaching this from the point of view of
| learning any new language is climbing a learning curve. If
| you are coming from most of the mainstream languages (java,
| javascript, python, etc) you are going to want to rebind
| things because that's how imperative languages roll.
|
| This is probably colored from my own experience of going
| from Python (mainly) to Elixir (mainly). As a toy example,
| imagine having to remove all the negative numbers from a
| list in the middle of a function.
|
| Most python programmers would reach for a list
| comprehension after learning about list comprehensions
| (which is great because they are more FP)
| my_list = [number for number in my_list if number >= 0]
|
| So you pick up Elixir and you are trying to do the
| equivalent thing after reading through the docs
| my_list = for number <- my_list, number >= 0, do: number
|
| And that works fine, it's my_list is exactly what you
| expect, no negative numbers.
|
| Let's try the same thing in Erlang MyList =
| [X || X <- MyList, X >= 0]. ** exception error: no
| match of right hand side value
|
| As a new user coming to the language, trying to do
| something so simple and getting a somewhat opaque error
| message is a significant degree of friction.
|
| I have found that when I want the old value of a variable
| to no longer be available rebinding the name is a great way
| to ensure that. If in the future I decide that I need the
| old value later on in the function I can always just change
| the bind to some other name easily enough, but it prevents
| me from using state when I meant to use updated_state.
|
| Not to say one way is better than the other, I just found
| this use of rebinding to work well for me by making it
| "impossible" to use the old / stale / out-of-date value.
| napsterbr wrote:
| Personally I see no reason to start a new project with Erlang
| unless you really enjoy its syntax (perhaps for someone who has
| a solid background in Prolog?).
|
| With Elixir you get everything in Erlang plus a lot of
| extremely powerful libraries/frameworks (e.g. Ecto and
| Phoenix), macros, a friendlier syntax etc.
| zach_garwood wrote:
| I think it's mostly a matter of taste which syntax you prefer.
| Where Elixir has the most advantage, in my opinion, is Mix, the
| language's build tool / project config / task runner. You use
| the command line tool to compile your project, run your tests,
| and any other user-defined task you'd like. And you use the Mix
| module to define your project's dependencies, environments, and
| build targets in Elixir code. It's a really nice all-in-one
| Swiss Army knife compared to the cobbled-together build
| processes from disparate tools found in other languages.
| randito wrote:
| If you're interested in Erlang/Elixir, you might want to watch
| this video: https://www.youtube.com/watch?v=JvBT4XBdoUE (GOTO
| 2019 * The Soul of Erlang and Elixir * Sasa Juric)
|
| It shows off the power of the BEAM VM -- and kind of makes you
| stand back and go "whoa.. how do they do that?"
| nemetroid wrote:
| I used Erlang in some university courses, and once wrote a
| simple crud app in Elixir/Phoenix, so my experience is somewhat
| limited.
|
| Erlang's syntax is unusual, but after grasping the concepts I
| always found the language logical and easy to understand. On
| the other hand, I haven't been able to get comfortable with
| Elixir. It's a significantly larger language, which comes with
| higher complexity (but also lets you write code at a higher
| level of abstraction). I often found myself only half-
| understanding the code I was writing (and I always make an
| effort to fully understand what I'm doing).
|
| And personally I find the Elixir syntax to be among the most
| confusing and inconsistent (especially when compared to
| Erlang).
|
| Nevertheless, if I was making something web related, I would
| definitely go for Elixir (because of Phoenix). If I was making
| something lower-level, I would probably consider both options.
| tres wrote:
| Runtime configuration is my favorite new feature of this release.
|
| Dancing around runtime vs compile time configuration seemed like
| it was one of the "harder" parts of dropping into Elixir.
|
| edit: grammar
| strzibny wrote:
| Same. Same.
| josevalim wrote:
| The official release announcement can be found here:
| https://elixir-lang.org/blog/2020/10/06/elixir-v1-11-0-relea...
|
| It provides more context, links, and other improvements over the
| CHANGELOG. I am not sure if it is possible to update the link in
| the post though.
| dang wrote:
| Ok, we changed to that from https://github.com/elixir-
| lang/elixir/releases/tag/v1.11.0. Thanks!
| josevalim wrote:
| Thank you!
| scns wrote:
| @dang can update it
| ramchip wrote:
| It's great to see some type checking sneaking in Elixir :)
| bostonvaulter2 wrote:
| I'm really excited for the runtime configuration updates and the
| compile time tracking updates.
| princevegeta89 wrote:
| All I could only ask for today is just a better ide support. I
| don't like vscode; even though the plugin for intellij has
| improved, there is still a lot to be desired
| pselbert wrote:
| The IDE type tooling is getting better all the time thanks to
| Elixir-LS. There was a 0.6 release a couple of days ago with a
| ton of improvements [0]. Better auto-completion triggers and
| Ecto completion come to mind as huge quality of life
| improvements.
|
| 0: https://github.com/elixir-lsp/elixir-
| ls/blob/master/CHANGELO...
| princevegeta89 wrote:
| Is this supported in IntelliJ ?
| pselbert wrote:
| No idea. It is the foundation of VSCode and most of the
| other plugin systems powered by the language server
| standard.
| bot41 wrote:
| I started to learn Elixir and Phoenix awhile ago. I liked it but
| stopped due to (i) there's no job opportunities near me for
| Elixir and I wanted to the learning/projects I do on my own to
| help me in interviews; and (ii) it's not a strongly typed
| language which I have come to learn is my favored type of
| language
| sergiotapia wrote:
| We're hiring for Elixir engineers, and specifically a Senior
| Elixir developer:
| https://www.joinpapa.com/careers/6IexFa6irc36vwF6aKXkE6/seni...
| freedomben wrote:
| Elixir/Phoenix is my hobby. I build personal projects on it.
|
| I was able to find a few jobs, but not a ton (this was a couple
| years ago). The jobs that are out there all wanted experience
| but obviously that's hard to do with a new platform. I got an
| interview with one company that I thought understood that I
| only had a few months experience as a hobbyist (which means
| I'll be doing a lot of Googling even for common APIs) but they
| rejected me. At this point my experience with professional
| Elixir has not been positive.
|
| I love the language but I'll probably just stay a hobbyist, at
| least until things change.
| FeistyOtter wrote:
| It is an interesting (but probably very subjective)
| observation that the majority of companies with a rare or
| esoteric stacks hire only experienced devs with the stack and
| refuse to train them themselves. Maybe it is because they are
| smaller and lack resources. And on the contrary, in my
| experience, large companies based on common languages like
| Java, C#, JS and the like dedicate huge resources for
| training their junior programmers from the grounds up.
| ativzzz wrote:
| Which ultimately makes those rare and esoteric stacks less
| likely to survive because experienced engineers who don't
| have experience with those particular stacks have no ways
| of getting those jobs without experience in those jobs.
|
| Companies like Jane Street make more sense. They use ocaml
| but they don't expect you to have any ocaml experience
| coming in, but they also have plenty of resources for
| training and hiring talented engineers.
| joelbluminator wrote:
| Think about young startups that aren't sure when the next
| round of cash will come and their personnel stay there on
| average 2, 2.5 years. Spending 6-8 months on getting a
| new developer productive with a new language is super
| expensive for such a company. In fact, employing juniors
| in general is pretty risky for such a company.
| ativzzz wrote:
| Of course, the startup is doing what it takes to survive.
| I'm not saying this approach is wrong in any way. I'm
| just saying that this will result in these niche stacks
| staying niche and have a much smaller dev pool to hire
| from, now and in the future.
| paublyrne wrote:
| A senior developer though should be able to get
| productive with a new language in a few weeks. It's not
| such an investment ....
| joelbluminator wrote:
| Sorta true, often times not really. You can ship code
| that most likely works, but I'd still prefer a senior who
| knows the stack over you if I was the founder. You're
| saying in depth knowledge of a framework / language
| counts for nothing?
| bcrosby95 wrote:
| Phoenix is a fine web framework. But with the shared-nothing
| approach of designing webapps, they tend to be pretty simple to
| both isolate and make concurrent regardless of your stack. I
| think BEAM languages are much more interesting for backends
| where a shared-nothing approach isn't an acceptable solution,
| and I feel like that's where its power and uniqueness over
| other languages really shines.
| peruvian wrote:
| I had this issue too, even before the pandemic. In fact back
| when I was looking even if there were Elixir job postings they
| often strongly preferred a Ruby/Rails background on top of
| that, which I didn't have.
|
| I just decided it's one of my hobby languages. If a job comes
| out of it in the future, that's awesome.
| strzibny wrote:
| I will give an opposite experience. I was hired with zero
| previous knowledge of Elixir or functional stack (well,
| except Haskell course at uni). The other dev actually came
| from C# background (I came from Ruby). 100% remote.
| andy_ppp wrote:
| I'm starting to see more and more jobs here in London,
| including one with live view.
| pmarreck wrote:
| > near me
|
| You _are_ experiencing the same global pandemic the rest of us
| are, right? Remote work and all that? (It's honestly not for
| everyone. I prefer some physical facetime myself or I... "get
| disconnected")
|
| > not a strongly-typed language
|
| While this guarantees elimination of a class of bug, pattern
| matching plus guards cover most of the potential bug surfaces
| there IMHO. I know the language creators have been considering
| some directions to go, there
| bot41 wrote:
| That is a good point and I am working remotely in my current
| job until next year at least. I think my time and effort is
| best put into trying to get a job in the tech stack I know at
| the moment rather than trying to switch.
| joelbluminator wrote:
| Pandemic or no pandemic, most jobs are at least local to the
| country. If he is from Russia it's way harder for him to get
| a job in a U.S / EU company. Also - if it's hard for him to
| get an Elixir job now (and let's assume he knows if it's hard
| or not and heard of the concept of remote), while Elixir is
| past it's peak, is it a good bet to keep going the Elixir
| route?
| triplejjj wrote:
| > "Elixir is past it's peak"
|
| I would really appreciate any data that backs this up. Or
| is this a personal observation written as if it was a
| consensus? Because if we are going by personal experiences,
| the community definitely feels bigger and more active than
| before to me.
| joelbluminator wrote:
| https://insights.stackoverflow.com/trends?tags=elixir
|
| Now you may say Stackoverflow isn't a good measurement.
| In Tiobe Elixir hasn't made it to the top 50
| https://www.tiobe.com/tiobe-index/
|
| There is little reason for me to believe Elixir is before
| it's peak, the data is showing otherwise. Elixir's
| contemporaries (Rust / Go / Kotlin) are at a totally
| different place usage wise. So I tend to think this is it
| for Elixir, it's all down hill from here. If you have
| data showing otherwise please let me know.
| triplejjj wrote:
| That's very little data to make such broad claims.
|
| Up until 2017 or so, you could see the Elixir community
| active on StackOverflow with answers from Jose, Chris and
| most maintainers. Then the community collectively moved
| to Elixir Forum. Wouldn't you prefer to ask questions
| where the maintainers can also answer? Per the Elixir
| Forum stats, the number of active users keep growing.
|
| I won't comment on TIOBE because you can find plenty of
| critique elsewhere. For example, in the Redmonk rank,
| Elixir does fairly well on the GitHub axis, and is ahead
| of contemporaries like Clojure and Julia, and ahead of
| other functional languages like Haskell, Ocaml, Erlang,
| and even F#.
|
| I strongly believe Elixir is before its peak. Elixir is
| most likely still growing, just not at the same pace as
| languages like Rust or Kotlin.
| joelbluminator wrote:
| OK found something to help us quantify this debate
| https://towardsdatascience.com/these-are-the-real-stack-
| over...
|
| Now this is interesting because this counts question page
| views, not questions asked.
|
| You can choose Elixir in that embedded tool, it's too bad
| its only for 2017-2018 but it still validates my point.
| My guess is the numbers for 2019-2020 are worse for
| Elixir.
| triplejjj wrote:
| I don't see how this is any better. Most traffic on SO
| comes from search engines and if the questions and
| answers are elsewhere, such as in the Elixir Forum, then
| search engines will lead devs away from SO.
|
| You say the language is in decline and none of this is
| solid evidence that's the case. It just says Elixir devs
| are not really active in Stack Overflow, which anyone in
| the community would be able to quickly point out.
| joelbluminator wrote:
| > and is ahead of contemporaries like Clojure and Julia,
| and ahead of other functional languages like Haskell,
| Ocaml,
|
| That's kinda my point. These are the languages you should
| compare Elixir to, the esoteric ones. Not to PHP, not to
| Node or not even Ruby. I doubt this is going to change
| much.
|
| What I said about Elixir (lack of jobs) is also true for
| the languages you listed.
| joelbluminator wrote:
| Also, looking at the numbers in the UK on Linkedin: 132
| Elixir jobs for the entire UK (ruby has 1941, php has 4832,
| java 10973). I'm not saying it's impossible but 132
| mentions is not a lot. And it's not as if no one is
| fighting you for these Elixir jobs, quite a few people
| still want these jobs. Is Elixir still being chosen for new
| projects by startups or is it all python / go / rust ? The
| numbers for Elixir are very low.
| derefr wrote:
| People who are hiring for roles using smaller languages
| _know_ that there are few people local to them who are
| practitioners in the language. They tend to do one of two
| things about that:
|
| 1. They don't even bother advertising a position in local
| geographical "general" job boards. (Job postings on
| LinkedIn cost money for every day you have them up;
| they're a waste of resources if you can predict with high
| confidence that nobody will find the role through there.)
| Instead, they'll advertise _globally_ but targeted to the
| language 's community (i.e. language-specific job boards,
| forums and chat groups, newsletters, etc.) This is where
| the people using the language are looking, too, anyway,
| because they _also_ know that there are too few local
| opportunities for it to make sense to invest the time in
| checking local job-boards for a job matching their
| skillset.
|
| 2. They don't bother hiring _for_ the language. Instead,
| they hire for "experience with [relevant language
| paradigms]" and "experience with any of [similar, more-
| popular languages]" and then expect the new hire to learn
| the language on the job.
|
| My personal job-criterion for hiring Elixir devs is "a
| polyglot in several different language paradigms, fluent
| in at least one functional language." I find that that
| filter actually predicts _better_ whether they 'll be a
| good Elixir dev, than actual experience using Elixir
| does.
|
| -----
|
| As an aside, there's also the fact that languages like
| Erlang/Elixir (or the MLs, or the Lisps, or Prolog,
| or...) tend not to be languages used for _everything_ in
| a company, but instead tend to be languages used for the
| _secret sauce_ core component of a company. A lot of the
| time, companies don 't talk about using these languages,
| _even though they do_ , because they consider them a
| _competitive advantage_ over their rivals in whatever
| niche they occupy.
|
| Heroku is an obvious example: much of their architecture
| _was_ written in Erlang [nearly everything at first], but
| they never advertised that fact once in any official
| capacity. Likewise, HFT firms never mention they 're
| using ML or Prolog, but many do, because trading bots are
| often just souped-up expert systems. The only time you
| find these things out, is when having a beer with ex-
| engineers from those companies.
| joelbluminator wrote:
| While you may be right, looking at job boards is the only
| objective measurement I can make. Maybe the jobs are
| hiding under different names, in different places. Who
| knows. To me, seeing there's little jobs and that there's
| a clear decline in Stackoverflow Trends, and that Elixir
| isn't even in the top 50 in Tiobe, this all means
| something. Hearing of people saying they can't get a job
| - means something. I'm sure if you're in one of the major
| tech cities in the U.S, you could probably land an Elixir
| job. You can also land a Haskell job. Or Ocaml or
| anything else under the sun. This means little for most
| people who don't live there.
| lostcolony wrote:
| I'll echo this - when I've worked in polyglot shops,
| specifically on a team that did a lot of Erlang, we hired
| for "exposure to functional paradigms", not Erlang. The
| only places that looked to hire the specific language
| (and even that was negotiable) were places that just had
| Java. And the average quality of applicants was
| universally worse.
| joelbluminator wrote:
| It's a common practice to at least say what stack you're
| working on on a job ad. If it's not a requirement I
| usually see "We use Rails but don't expect you to know it
| already".
| lostcolony wrote:
| The JD was, obviously, far more descriptive than the four
| words I listed there. I'm saying the actual, relevant
| requirement, not the description of the job.
| lawik wrote:
| I see plenty of new startups in Elixir and haven't had
| any real issue finding Elixir client work since I
| switched to it. Elixir is not nearly as ubiquitous as
| Ruby was and I don't think it will be. I don't think
| that's necessary either. For people playing the numbers
| game I guess Java, Python and JS are the languages to
| pick.
| joelbluminator wrote:
| It's not as ubiquitous as Ruby is currently either,
| despite Ruby declining quite a lot you can't really
| compare the 2.
|
| There are a lot of happy devs who can find Elixir work,
| it depends a lot on location, past experience etc. I do
| think the number of jobs advertised is fairly low
| compared to demand. SO on one hand it could lead to high
| salaries. On the other hand it could lead to not all
| people landing a job (which if you look at the comments
| some people here are complaining about).
| colecut wrote:
| What exactly leads you to believe that Elixir is past its
| peak?
| samgranieri wrote:
| I recommend starting up a side project to learn a language.
| That's how I learned Ruby, and consequently Ruby on Rails 15
| years ago.
| cuddlecake wrote:
| What's a good side project, if one is not really interested
| in the problem space of the side project?
|
| I.e. I mostly just program for money, so how do I motivate
| myself to do a side project I'm not interested in, just to
| learn the language?
|
| I wonder if I could ask my employer for two weeks of time to
| "rewrite" parts of our backend in Elixir, just so I could
| scratch that itch, without any of the consequences of it
| actually reaching production.
|
| Like a programming language sabbatical
| ianleeclark wrote:
| > IEx also has been improved to show the documentation for Erlang
| modules directly from your Elixir terminal.
|
| This is a really nice change for those of us who straddle both
| languages. I've done a fair bit of work with both ets and the
| crypto module and having to jump into and out of firefox felt at
| odds with the rest of the development experience.
| andy_ppp wrote:
| Also the online Erlang docs are arguably even more utilitarian
| than iex docs output...
| elcritch wrote:
| That made me laugh, but it's true. The Erlang docs are like
| 1980's brutalist architecture. Functional but utilitarian.
| But it's great to have the Erlang docs in IEx; it's my
| favorite docs interface.
| ch4s3 wrote:
| Yeah, IEx's h/1 function is great. I just wish it had some
| sort of built in search for when you don't really know
| exactly the Module and function you're looking for.
| vincnetas wrote:
| "Functional BUT utilitarian" ?
|
| You mean "Functional AND utilitarian" because for me these
| both are very welcome features.
| lostcolony wrote:
| The conjunction here is purely to taste, since
| utilitarian implies functional, as well as not
| particularly attractive; both are correct (as would just
| 'utilitarian', since it's not a loss of information,
| implying as it does the functional aspect).
| andy_ppp wrote:
| I read that comment less literally and more like "they
| just about work for their function, but damn they ugly"
| :-)
| lostcolony wrote:
| Sure, but do you interpret "functional and utilitarian"
| as meaning anything different? Utilitarian tends to imply
| functional + ugly.
| dj_mc_merlin wrote:
| The Common Lisp _Hyper_ Spec on the other hand looks like it
| was written by a monk obsessed with dictionaries.
___________________________________________________________________
(page generated 2020-10-06 23:00 UTC)