Related and fun: the Fremont Cabal Internet Exchange[1]. The person who started it has a great blog[2] about all kinds of related things. There’s a really good interview[3] with him about how it started and what it takes to run it on the On The Metal podcast (highly recommended in general)
I discovered Red (and its predecessor Rebol) a few months ago and was really excited about it - very interesting blend of ideas that seems to hit a sweet spot for GUI scripting. Then I discovered it doesn’t have 64-bit support and it seems the community is debating about whether it even should, as it would require a significant overhaul. This makes it a no-go at least for Mac users unfortunately.
> and it seems the community is debating about whether it even should as it would require a significant overhaul
It's true that Red supports 32-bit platforms only, but porting toolchain to 64-bit is a planned transition, which was never "debated about"; Catalina just forced this issue on most developers, including the Red team, and the actual question was if addressing it should come before all the other priorities, to the detriment of overall speed of development and release of major features.
Thanks for clarifying. I certainly didn’t mean to disparage Red at all - the language seems interesting and the project admirable. I’m really eager to dive in and explore, but I’m on Catalina so I can’t yet.
The debate thing was just the impression I came away with. Things like this post[0] from late 2018 saying
> We are currently 32-bit only, and need to decide the best path for adding 64-bit support, should we elect to do so.
(and some other back-and-forth I can’t find at the moment) left me thinking it was an open question. I’m glad to hear it’s on the roadmap.
IIRC it was said in the context of the next major release (0.6.5), i.e. concentrate on 64-bit support ASAP or instead focus on the planned milestones that were already in the pipes. As you said, there was back-and-worth discussion in community chat, where the team tried to gather some feedback from macOS developers and gain a perspective on how urgent this issue is.
Really unfortunate that you cannot give Red a try, but I think it's still worth checking out in a VM of your choice. Drop by one of the Gitter rooms if you need help to get started:
You’re right about Neovim’s effect on Vim improvements and lighting a fire in Bram.
Even if neovim goes belly-up (unlikely), or totally diverges (slightly less unlikely), they’ve done a huge service to the vim community simply by existing and offering compelling, thoughtful enhancements while respecting the core spirit of vim - and being exceptionally mindful of practicality in how they approach changes.
Probably one of the best-ever examples of a fork that is Doing It Right.
I’m torn by the idea of replacing vimscript with lua. I honestly enjoy both languages (vimscript is not as bad as its reputation!) but they each shine in different use-cases. Lua is more ergonomic for writing programs/plugins, but vimscript is more ergonomic for interactive use (and maybe config files, more below).
For non-vimmers, a good analogy is the shell: would you want to replace sh with a more robust language like lua? Few people seem to enjoy writing larger programs in sh, and are quick to jump to perl/python/ruby once a script crosses some complexity threshold. However, I doubt many people would want to give up sh for interactive use. Mainly[0] due to omitting “cruft” like parens/quotes/commas, and also pipe syntax. Minimal example:
ls -laht | grep foo
is nicer than
grep(ls(‘laht’), ‘foo’)
especially when you’re doing thousands of commands of varying complexity every day.
Vimscript is similar, again mainly due to omitting “cruft” like parens/quotes/commas, and also some specific sugar. Minimal examples:
iabbr cosnt const
is nicer than
iabbr(‘cosnt’, ‘const’)
and
s/foo/bar/g
is nicer than
sub(‘foo’, ‘bar’, ‘g’)
especially when you’re doing hundreds (thousands?) of commands of varying complexity every day.
Besides setting options, the vast majority of the “meat” of my config file boils down to these types of commands, and is thus much more readable with the cruft omitted, even though I only have to type it once.
This could probably be addressed with some light syntax sugar on top of lua, and I think I remember seeing some comments from the Neovim folks about this very thing, but I’m not able to find anything concrete at the moment. Does anyone know where this stands?
—
[0] Of course, another issue (for both shell-scripting and vim) is the huge amount of tools built on top of the existing language, which we may be remiss to abandon. For shells, it’s probably practically impossible. For vim, I suspect it is possible, though it would be painful enough to merit a long hard think.
I you are having your editor change "cosnt" to "const", or "isntall" to "install", you are programming your fingers to be unable to type them correctly. You will regret it, but it will be too late.
Silly as this product is, as a kid I always wished for something like this to up the immersiveness of video games. Maybe it would be doubly effective now with VR.
Getting it in a reasonable form factor and some practical issues (stinking up the house) seem like roadblocks, but I wouldn't be surprised to see something like this come back around, focused on gaming.
I was always thinking about cinemas - especially since I first saw a "4D movie", in which they augment the usual 3D movie experience with tactile effects generators - air blowing at you to simulate wind, small amounts of water suddenly being sprayed at you, etc. It really added to the immersiveness of what you were watching, and the only thing lacking was smell effects.
Rafflecopter | Sr. UI Engineer (Clojurescript) | Boulder or Remote
Looking for someone with a deep knowledge of ClojureScript - and the browser environment in general - who can help build and evolve (and open source) our internal reagent-powered UI toolkit. Should be able to blur the line between frontend/backend development - care about getting small UI details right and not be afraid of diving into to server-side Clojure when the need arises. Bonus points for experience w/ a variety of past/present UI toolsets & techniques.
We're a small, smart team/company run by developers & we care a _lot_ about UI development. You'll be hard-pressed to find a team more dedicated to making a great product, or an environment more amicable to this kind of work.
Email me (ceo, product/ui lead) directly: jr@rafflecopter.com
Looking for a CSS/HTML master to help build UI's & own the "front-front end" of our application stack.
At the end of the day HTML/CSS are just tools. What you really do is breathe life into interfaces that millions of people use every day. You get the details right. You make computing enjoyable, an experience which is too often the opposite.
We have a ton of interesting work to do and you'll be hard-pressed to find a team that cares more about making great products, or an environment more amicable to this kind of work. Come focus on perfecting your craft in a place where the CEO cares as much about it as you do.
We don't really care where you went to school, job title buzzwords, or any of that. This is a position where a portfolio speaks louder than any credentials. We want to see your work!
(Note: this is _not_ a design position. We're evaluating the quality of the implementation, though of course it's impossible to entirely separate the two - like writing/acting).
We'd also like to hear more about the projects you've worked on, what your role was, what went right/wrong, etc... We're looking for real experience.
Remote is absolutely OK, though we do have some bias towards local candidates. (Boulder/Denver area)
To apply, email jobs@rafflecopter.com or me personally at jr@rafflecopter.com
As a designer I would never hand over my designs to one of those chop shops. Any designer worth his salt can code his own designs. I don't trust the psd2html services to give me high-quality, semantic, robust markup and CSS.
You're probably more talented than you realize, but I wouldn't expect all designers to know html. I know a few designers that are amazing, but clueless with html. I think the skills are quite often mutually exclusive -- which is a good thing for you as the exception.
I've met a few talented web designers who don't grok html, javascript and css, but (so far) no product ux designers. Depending on the type of product you're building, someone like this may be exactly who you really need.
Working with a good ux designer will completely change your understanding of the role of design in product development. They can play a pivotal role in defining and shaping your product. And yes, a person with these qualities almost invariably can also code. Understanding the underpinning technologies of the web remains nearly inextricably entwined with understanding the design potential of the web.
As an aside, I think a platonic ideal founding team would have 2-3 people who share varying degrees of business, design and technical acumen. Each person has a defined role, but they also relate to their co-founders' roles in a meaningful way. Really understanding what it means to be GREAT at something often requires educating yourself enough to become mediocre at it. Completely partitioned specialization is for companies big enough to need HR departments.
1: https://fcix.net
2: https://blog.thelifeofkenneth.com
3: https://oxide.computer/podcasts/kenneth-finnegan