This would be completely logical if MP3s from Taylor Swift were found organically in nature everywhere we looked. Unfortunately (or fortunately), this isn't the case, so there are no "natural rights" to be asserted here, as is the case with things like food, water, and shelter.
There is a natural right to freely copy information. Our civilization is based on our ability to tell young people the stories we heard from our elders. And we are part of nature.
So, in your opinion, someone taking part in commerce is completely justified in simply copying software without paying a dime to the author, and using that software to then, in turn, make money ? Who gets to decide when one person's rights trump another person's rights ?
I think "king of the web" is gonna look a lot different in the future than it does today and did in the past. JavaScript will be, for the foreseeable future, the king of the web front end, and I suspect it'll also hold a strong role on the back end. It may even be unstoppable on both ends because of the incredible resources being thrown at it.
However, systems management, deployment, provisioning, data aggregation, log/event analysis, etc. on a large scale becomes more important by the day, and if there is an area where Perl is still quite popular, it is in those back end tasks. There are trendy tools in newer languages, but you'd be hard press to find very large deployments (at least on Linux or other UNIX) without a few hundred thousand lines of Perl running some elements.
Perl 6 with concurrency built-in, grammars and the most advanced regular expression engine in the world, seems very well-suited for that future. Being somewhat familiar for old school sysadmins who've always relied on Perl for their scripting tasks is a bonus (Python has made some inroads in that space in recent years, particularly with Red Hat and Ubuntu/Debian shipping many system utilities that are written in Python).
Anyway, on the web front, I think we need a reasonable database abstraction layer (e.g. Perl DBI/DBD), at the very least, before it gets elevated to "always available" on hosting providers. I'd say give it another year, and we'll have a pretty good Perl 6 web development ecosystem to work with.
Seems pretty immature. No interpolation (in either module), but I hadn't seen the SLang. That's a wonderful example of creating a DSL! But, probably not gonna be using it in production today.
I haven't read the tut yet but… could I write a language like python with that tutorial? If not, what would it be the best tutorial for indented syntax like python?
There is a trick for parsing "indented" syntax which is not covered by this tutorial: the lexer (not the parser) keeps track of indentation. Lexer inserts Indent and Descent tokens, which the parser considers like { and } tokens in a C syntax language.
Now your parser implements a context-free grammar although the language is not context-free.
First, if you know Python, play with writing your own interpreters, parsers, etc. in Python itself. It'll be slow, sure, but you'll learn a lot.
Next, try using the python ast modules for taking 'real' python code, and turning it into an AST which you can then do stuff with. For instance, you could take a subset of python, and turn it into C, or Javascript, or whatever. This will be fun, but don't expect to be able to turn all python into those other languages, there's just WAAY too many edge cases, differences in scope, etc. But for a subset of the language, however much you choose to use, it's pretty fun.
In general, parsing syntax should be the LEAST complex issue in writing a programming language. Playing with the above ideas in Python will be a lot of fun and you'll learn a lot anyway.
Some resources to look for... writing a LISP in python:
Another way to approach it is to drop markers using a preprocessor after indentation. A group of friends and I were hacking on something similar and were trying to allow Lisp syntax sans parentheses. We created a preprocessor that would wrap indented child lines with the appropriate parentheses. Here's the OCaml file below:
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.
Writing an interpreter is much, much harder than implementing a simple, straightforward compiler.
Interpreter is unavoidably convoluted, it is full of very complex things like environment handling, it cannot be split into smaller parts in any sane way.
Compiler, on the other hand, is nothing but a trivial sequence of very simple tranforms (as simple as you like), each is nothing but a couple of term rewriting rules. You do not need a Turing-complete language to implement a compiler.
Maybe if the compiler is very simple. But I have said:
"""
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...
"""
REPL, debugger, no-VM and other stuff look easier with interpreters than compilers.
However, I will be happy to be wrong: I wanna the simplest way to get where I want to.
Currently: Working with F#, wanna REPL, debugger, AGDTs, pattern-matching, go-like concurrency, iterators, semi-functional...
Where I hit a big block is how do interop with a interpreter (ie: Call .NET methods) and that look easier with a compiler...
I wish I could use the Swift compiler from the command line instead of having to download a 10GB XCode monster over my shitty 14kb modem that will take a couple of years.
It's part of the Command Line Tools, which is about 160 Mb on my computer. If you install Homebrew you should get a prompt to install the tools (or try to run gcc from the command line).
If I'm not mistaken, you can use the installation guidelines on swift.org, and just skip the Xcode related parts. I believe you just need to run the downloadable packages and install them, and they shouldn't require Xcode or anything. Then just add Swift's bin folder to your shell path.
In real world? Php, Python, Ruby and Javascript still reign supreme.
Mobile is another story since main platforms are controlled by corporations, but if it were for the hobbyists neither java nor swift would have had a chance.
It's worth noting that development workflow in small businesses and startups is rapidly shifting towards being more "corporate" though. Whereas a decade ago the tools necessary to write quality code needed a dedicated person to manage, now they can easily be set up and used in a few days by a single developer. That's going to drive the language of choice too - if used a typed language isn't going to be any harder than used a dynamic language then there's little reason to use a dynamic one.
In what sense are there no innovative projects in academia? Of all the criticisms that could be made of academic research and projects, this one just doesn't make sense!
