Seems to be a hot topic, a friend and colleague published this in December 2016 and I can thoroughly recommend it (Uses Go as an implementation language):
With any new skill you need to be willing to sink a lot of time into it. And you need to be fine with being absolutely terrible at it in the beginning.
I usually tell people who want to learn to draw to go to http://johnkcurriculum.blogspot.com/2009/12/preston-blair-le..., get the Preston Blair book, and start doing these exercises by master animator John K (creator of 'Ren & Stimpy'). You will get a lot better, a lot faster. These exercises focus on simple cartoon characters who wear a lot of their construction on the outside; once you can draw cartoon characters, you can keep drawing more of them if that's your thing, or you can build on top of that and start learning anatomy and drawing more complicated characters. (Or do both.)
There's other well-regarded drawing courses on the internet and someday I should probably pick a new one to send noobs to, what with John K kind of being an asshole - but I learnt a hell of a lot when I worked under him, and he is really good at teaching this stuff.
Most of what I know about drawing more complicated figures came from a combination of Bridgeman's "Constructive Anatomy" and Loomis' "Figure Drawing for All It's Worth", and a life drawing teacher who hewed very closely to Glen Vilppu's drawing manual. If you can fit some life drawing classes into your life then TAKE them, you will learn a ton.
Also: Make a space in your life to do this. I ride the bus a lot, and before the advent of smartphones, I'd have little to do to amuse myself besides stare out of the window, read a book, or pull my sketchbook out and draw. Maybe draw some idea floating around my head, maybe draw something I glimpsed out the bus window, maybe something based on my fellow passengers, maybe just some cubes, or the hand I wasn't drawing with. I got a lot of practice in without feeling like I was making myself "practice". Whatever you may be learning, if you regularly drop yourself into a time and place with nothing much to do besides the thing you wanna learn, then you'll do it more often.
Don't blow several hundred bucks on a ton of paints, or on pro software and a Wacom tablet. Just start with a few hardback sketchbooks and some pens and pencils. Oh, and not mechanical pencils. Just grab like a pack of Ticonderoga 2.5Bs, they're cheap and pretty good. And try holding them so that the side of the point addresses the paper for a lot of the beginning of your drawing; this will do several things for you:
* it will train you to keep your wrist fairly steady, and to draw more with your entire arm; keeping your wrist straight and steady will help keep the Carpal Tunnel Fairy away.
* it will make your initial lines light, and prone to fade away as your hand brushes the paper; this keeps you from bearing down to gouge an impossible-to-erase line in the paper, and gives you more room to make mistakes before having a dark, illegible mess of lines you can't draw over.
Don't get lost in trying to save a drawing, either. Paper's cheap, turn the page and try the same subject again, or a new one.
When you make a picture you like, hang it over your drawing board, turn it into your computer's backdrop, and keep trying to draw something better than it. You may find yourself hating it because you start seeing all the mistakes. That's great - go draw something new that doesn't make those! (This may take many tries, some mistakes are harder to stop making than others.)
Don't worry about "your style". If someone points out a mistake in your drawing and you find yourself wanting to say "but that's my style!", then you are just covering up your weaknesses unless you can actually sit down and bust out a version of the drawing that Does It Right. When you can do that you can legitimately say "dis mah style". Steal stylizations from artists you love (you're looking at other people's art, right? A lot?), make your own based on reality.
You will find a lot of people declaring "rules" of drawing. Always do this, never do that. The truth of the matter (IMHO) is that all rules of art are actually just warnings: "never do this" really means "if you do this without thinking about what you're doing it'll probably turn out badly". Know the rules, know which ones you're breaking, and break the fuck out of them while staying well within the boundaries of the other rules you know.
(I spent a decade in the LA animation scene, then burnt out and draw comics now. If you wanna look at my work to decide if I'm someone who you should listen to in this, it's all at http://egypt.urnash.com)
I've just discovered generative testing due to clojure.spec. Describing specs for your data works not only to help validate data structures but can be plugged in as properties for generative testing.
After the "aha" moment it was followed by a feeling that I've wasted so much time writing specs just to validate data structures and writing specs just to see if my functions are working as they should.
This is one of the things I wish was obvious in my learning track right after vim/emacs will help you code faster.
Will help you in a very limited way. Unfortunally, you will need to hunt from several places to go after any half-decent implementation of any decent-enough language.
But do anything first. So, take this tutorial and complete it. If after it you wanna move...
I'm working in my own language, and after read like hundreds of links/blogs/books/etc, you will find that a lot of that is heavily biased torwards parsing, LISPys, FORTHs, and ultra-heavy-monads-worship or academic complexting that will make your head spin. After all that read, I'm still confused. Because a lot of things are not simpler or obvious in the way how make a blog or a ecommerce site can be.
Syntax is very important, but after read a lot, I think that do the parsing stuff is not the very best first step.
INSTEAD DO THE AST WALKER. Seriously. Get clear how the the AST can be processed and focus in that. Changes in the AST will cause heavy impacts in your parsing stuff, and a lot of question need to get clarified first. For example, from the link above:
My first questions? How make a REPL, a debugger, how implement pattern matching, type checking, if a interpreter can be fast enough, if possible to avoid to do a whole VM for it, etc...
Exist a LOT of practical questions that are left as "a exercise for the reader" that need clarifications.
So, my advice:
- Get a list of what do you want for your language. Then think harder and try to remove features and get to the core of it.
- From the above, start to understand the details. For example: I wanna to do GO-style concurrency, so... how implement GO-style concurrency? If that is not solved, your syntax is pointless. That is why try to fill the "core" of the language as much as possible before to commit to the GUI (aka:syntax) of it.
- Then do a interpreter. Is FAR easier. Even if you wanna do a compiler, start here is more easier.
- On the side, play with your syntax, and imagine how write in the language could be. Then start to think "to make this syntax do that, how I can do inside the guts of the compiler"? But you can delay the parser for a while.
When the time come for the parsing, probably is better to do as a top-down parser and/or pratt-parser. I don't waste time with parser generators. If your disagree, ok with me ;)
I have find that use F# is great for this stuff. However, OCalm have more code-samples (ie: ML languages are made for this!). Lisp will work great if your are insane to like that ;). Hardcode C-developer? Tons of code to look, but not very much in clarity to see.
Exactly. I'm in the pursuit of build one. My first questions? How make a REPL, a debugger, how implement pattern matching, type checking, if a interpreter can be fast enough, if possible to avoid to do a whole VM for it, etc...
Exist a LOT of practical questions that are left as "a exercise for the reader" that need clarifications.
In the end, the parsing steps can be summarized as:
- Do lisp/forth if wanna do the most minimal parsing and do a lisp
Or:
- Use a parse generator, if not care about the quality of this
Or:
- Use a top-down parsing by hand, if wanna some control
ANY OTHER OPTION is non-optimal, and will divert from the task, EXCEPT if you wanna do something novel.
If will let aside the parsing stuff, we can put more in the hard and more rewarding aspects.
Hey, that looks like Norton Commander in the browser! Even the icon is an homage to the original. Neat.
Also TIL that "orthodox" file manager is an actual term, and there's even a huge online book about them [1]. That's funny, we used to call then just "file managers"... ;)
I always find it frustrating when people pontificate about how the GPL should work who have never done the hard work to enforce it (BTW, I'm always looking for volunteers who want to help in the really really boring work of enforcing the GPL, but I rarely get any takers once I start describing what the work entails).
I've done and/or led more GPL enforcement than anyone on the planet, for more than a dozen different copylefted projects, and I've done it as a volunteer, as an employee of both FSF and Conservancy, and for GPLv2-only, GPLv3-or-later, and LGPLv2.1 works.
While I love, as a purely intellectual exercise over a nice meal, to talk theory with people who only have a theoretical understanding, real world experience with the licenses is the center of drafting good copyleft licenses. The GPL might as well be the ISC license if its clauses are never enforced, so enforcement is really the litmus test on how the license is working and what changes are needed. If the author or anyone else would like to get involved with "field research" and help in Conservancy's enforcement efforts for Linux, Samba, BusyBox and other projects, I'm easily contactable.
Anyway, I think what Christopher Price and others in this thread are really looking for is the copyleft-next project. It's Richard Fontana's project that's attempting to redo copyleft licensing from first principles and from (initially) a theoretical basis. I'm a fan of the project as I do think a "redrafting from ground up done in a community fashion" is a good idea to try in parallel to the existing functioning copylefts like GPL.
But saying "GPL is broken, therefore we need a GPLv4" is not terribly helpful. GPL is on the verge of collapse not for most of the reasons pundits say it is, but because (a) it's widely violated, (b) few people are willing to enforce, (c) some of those who enforce won't follow community Principles when they do, and (d) there is heavy political opposition from wealthy corporations and trade-associations against those who do enforce, even when they commit to follow published community Principles.
IMO, those are the biggest problems GPL has now, and I work every week to seek to solve those.
Sure, having been involved with copyleft policy since the early 1990s, I keep a private bug list of GPLv3 (i.e., things I'd like to see in GPLv4). But, it's far from my top priority, and it shouldn't be the community's top priority, IMO, either.
"rather about systemic risks in using any sort of proprietary software whatsoever"
There actually are under common distribution and licensing models. I used to think Stallman et al were vastly overstating the situation. These days, I think he was mostly right based on what companies did & do. I'll give you a few data points for your consideration.
1. Privacy/security. Proprietary vs open-source is false dilemma given first, secure system was a proprietary system (Burroughs B5000) that shared source with users. You can share source for vetting, local builds, or whatever while charging for it. Yet, most software comes as a binary where devious things are easily hidden. Many easily prevented 0-days and backdoors (esp undocumented FTP or SSH) have been found in proprietary systems over time. Even firewalls per Grimes' regular assessments. People are running out of room trying to find all the places Windows 10 is tracking users. They can't even turn them off. Leads to next risk.
2. Control. This is really most important. A fully, OSS product lets you use it however you choose. A proprietary licensed product, esp if not perpetual, can arbitrarily change how your product is allowed to be used later down the line. They can legally shut you out of certain benefits. This is getting common with app stores, DRM restrictions, games. I used to get games I could use permanently. Now, I often have to get online to access profile for even single-player games. The vendor, despite protest of users, plans to take service down after some time to force us to buy more expensive stuff. They also put ads in there because we can't turn them off so why not. Control is very important and many major companies are abusing the fact that "our" devices/software are actually "their" devices/software we merely get licensed to use only how they want to. Future-proofed against this with FOSS.
3. Lockin. Proprietary vendors often use obscure storage formats or communication protocols to make it hard to extract your data. They use custom API's to reduce portability. The result is that, after you build on them enough, you're effectively stuck with them since a move would cost exhorbitantly more than just paying an obscene licensing fee again. Such lock-in lets companies effectively stop innovating and benefiting their customers while their customers are powerless to do anything since the business, its apps, or its data just go bye-bye. Open storage, protocols, and API's can mitigate this but they (esp Microsoft) have nasty habits of subverting those with extensions or undefined behavior. So, FOSS clearly has a win here as you can just use the source itself to get off the platform if you want or pay someone to improve it.
4. One company I know specializes in proprietary hardware they sell but with FOSS software. In a discussion, the lead engineer told me he refused to use proprietary in their products since he was burned badly by one. The issue is the right to inspect code to debug and fix the dependency. You don't have it with proprietary & the vendor might not give a shit once you've already paid them. He (and FOSS advocates) argue that the complexity & bug-rate with modern software make it imperative to have source to ensure anything you build on it works correctly now and later.
5. Legal risks. No secret that licensing is often a minefield where compliance can be tricky. Vendors make it hard unnecessarily & overcharge. Business Software Alliance represents them telling customers' employees they'll get bounties if they snitch about instances of this then suing the crap out of small and mid-sized firms that didn't pay Microsoft, Oracle, etc enough. Big firms stay patenting software stuff, even cut n paste is Microsoft's haha, that they use to sue any competition or even users cloning to escape a bad platform. Recently, Oracle's argument that API's are copywritten essentially says nobody can make an alternative that's backward compatible and Oracle's users should be legally forced to be stuck with them. All these risks, except patent suits, are nonexistent when you use FOSS software. Plus, working with predatory companies seems wrong on principle.
6. Abandonware/bankruptcies. Company gets tired of supporting something or goes out of business. They can force you to keep buying something while basically not updating or supporting it any more. Lots of games and old apps in that status that are still fun/useful today but have to use emulators due to no source or legal restrictions. Impossible with FOSS as someone can roll up sleeves and code.
So, there's some datapoints that have and currently are burning up companies that invested in proprietary instead of open solutions. The major FOSS techs from 10 years ago still exist in some updated form with many others in development. Clearly systemic risk on one side of the equation with very little on other. What you think? :)
- https://interpreterbook.com