Because a framework can't bring new language primitives, such as types?
1,560 karma · joined January 18, 2012
GitHub issues for taggable discussions.
Zoom.us for calls and beer hangouts.
Google Docs for collaborative writing.
Screenhero for pairing/reviewing together.
Part of that trade-off is that JavaScript can't make the same guarantees about what happens when you pass an object into a function. It's harder to be confident that a given program is correct.
Immutability is just a part of the "simple made easy"[1] ethos of Clojure and I think most Clojure programmers will argue that taking the time to understand that philosophy _is_ worth the investment.
The abstraction that hides mutable data structures is transient[1], not vars, refs, agents and atoms.
Those abstractions are all to do with mutable references, not mutable data. They're there to make sure that you have safe ways to coordinate state in concurrent environments.
I agree that immutability can be annoying in languages that weren't designed with it in mind, but the languages that were almost always make it easier, safer and performant to create copies rather than mutate data.
If you're writing Clojure or Haskell and you think you're going to save yourself time by "just creating a map and mutating its structure" then you're misunderstanding the purpose of the language. These constraints are what enable the guarantees and contracts those languages make.
Next.js also focuses on client side JavaScript, but happens to render at the server first, so that there's something there for users before the client bundles have downloaded, parsed and been executed.
You could think of it as a more configurable create-react-app that supports server side rendering, with a convention over configuration approach to pages and links.
However, when things went wrong we ended up with cryptic error messages and often when `terraform up` failed, then `terraform destroy` would fail too, leaving us using AWS console to jump in and start clearing up the resources. Particularly painful because AWS has no awareness that your stack came from a Terraform config, so you have to navigate through the subresource menus destroying things one-by-one.
We ended up switching over to Cloudformation. The extra verbosity does suck, but the tooling for running/updating stacks feels far safer. We can review the changeset when we update the stack, view a realtime event log as resources are created, deleted or updated, and best of all we can always tear the stack down from a single point.
typeof (class {}) === "function"
I can already see that a big part of the appeal for classes is that they keep your code looking neat and succinct (as opposed to throwing .prototype and Object.create all over the place.
I'd much rather be writing code that looked something like the below, than having to think about super, static, own properties, constructors, private fields etc.
// provided by some view library
let Component = {
state: null,
setState(state) {
Object.assign(this.state, state);
this.forceUpdate();
}
// ...
}
let Counter is Component {
get state() {
return { count: 0 };
},
inc() {
let { count } = this.state;
let { step } = this.props;
this.setState({ count: count + step });
},
render() {
let { count } = this.state;
return <button onClick={this.inc}>{count}</button>;
}
}
render(<Counter step={2} />);
// let Counter is Component
let Counter = Object.create(Component);
Wordpress and co are easy, but they're fundamentally much more complex than static sites.
Jekyll is quite simple, but it can be hard to use in comparison.
That said, `this` is here to stay and to me, function bind feels like a pretty great way to write code that feels natural, without the danger of extending the prototypes for Array and Object.
The difference is that this sticks as close as possible to Clojure's API _for data_, rather than trying to be a functional programming utility belt.
Function bind syntax will be controversial, so I've also included a compatibility interface, so you can use Zaphod from Babel-free JavaScript (https://zaphod.surge.sh/compat/)
By default, it's impossible to use workspaces without frequent switches to the trackpad, which wouldn't be so bad, but without installing third party software it's not really possible to create shortcuts or start remapping keys either. Even once you've installed and started Kwm, Karabiner and Seil, the botched keyboard layout renders the Alt key useless for wm shortcuts. There's not even a keyboard shortcut that makes a window fullscreen without removing it from its workspace!
So much of the system lives in this unconfigurable space. As a Linux user, if my window manager isn't working for me, then I just install another one and start again with a fresh _and customizable_ blank slate.
Ironically the things that don't frustrate me about the chance from Linux to Mac are the things the author identified in the article. My editor works just the same in both OSes and Homebrew could be a lot worse.
And I get it, the OSX experience is a system that is averaged out to be comfortable and intuitive for everyone from musicians to graphic designers to programmers and business people. As a result, the user experience punishes power users the most.
If you primarily identify as a programmer and use a Mac on a day-to-day basis, go pick up a cheap Chromebook, throw a linux distro on it, and see how it feels. If it's not quite right, tweak it. If you get it working, great - you've just saved yourself ~$1000 and a vendor lock-in. If not, all you've lost is $150 and a few hours of your life.
There aren't enough large tech companies in the area for there to be any sponsored degrees available, which probably means that when the funding finishes, the research will start to dry up and the interesting researchers will leave with it. Take away the research and what's left is a department of third-rate lecturers. That's not an inspiring way to learn.
Will the NHS get some of the £350m? Maybe, maybe not. It's likely to be up for discussion. Will the post-Brexit government allot research funding for CS departments in North Wales? Not a chance.
> 20 FREE deploys per month
So I can only run the `now` command 20 times each month? What are you using to track how many times I've run it already? IP? NPM username? Package name?
>1MB size limit per file
Is this at deployment time or is this also enforced at runtime? If I deploy a 900kb sqlite file, then add 200kb of records to it at runtime, what's going to happen?
> Perfect for open-source demos, classrooms, tutorials & testing.
Are 20 deploys per month really enough to use in a teaching context? I'd love to use this tool in the web tech module I teach at my university, but I think most students would burn through 20 deploys in a week, let alone a month. Is there any chance this limit could be re-thought for teaching purposes?
I wouldn't mind if some of the other restrictions were changed, but free tiers that halt development til the start of next month don't sound great for learning to me.
From what I've seen, players pick it up fairly naturally and it doesn't seem to impede gameplay. The major drawback would be that games need to be designed specifically with this in mind.
There are still a few hiccups with hibernation. Using a tiling WM meant I needed to remap all of the chrome keys to get stuff like brightness and volume working.
I got it refurbished for £120 (~$170) before I set off backpacking in Asia and it's been the perfect laptop. Lightweight and decent battery life.
I do a lot of vector drawing and the trackpad fidelity isn't great, but that's hardly something you can ask for on such a cheap little machine.
Battery lasts for 5-6 hours. The laptop itself has survived intense use travelling through India, Sri Lanka, Thailand and Cambodia, including having the corner of the screen melted by accident in the Himalayas.
Haven't found anything lightweight that works better than Lubuntu out of the box (trialed Xubuntu, Ubuntu, Debian, ElementaryOS and some Arch flavours). Getting a dual boot up and running was easy.
My work is mainly fullstack, so I sit mostly between a terminal and a browser. An effective configuration with a tiling window manager is a must with this size of screen and being a TMUX/Vim user helps cut down the number of workspaces I need.
Couldn't recommend it more for travelling programmers!
Many of these "solved problems" have also been solved with the other languages, albeit not always at the surface level. For Node specifically:
WebSockets -> SockJS, Socket/Engine.io
Concurrency -> Generator Functions
Testing -> import assert from 'assert' and npm test
Syntax -> Some great improvements with ES6 and solid styleguides (airbnb, standard) + eslint as an autoformatter
The major win here for Go is that as a new platform it was designed with simplicity in mind. These features are probably easier to pick up in Go than any of the alternatives, which is great. However, don't make the mistake of thinking that Go is the first language to solve these problems.
import { readFile, writeFile } from 'fs';
import { clone } from 'lodash';