The source code is parsed to an AST, which is then executed. It began with a Java-Applet. When WebAssembly appeared, I ported it to C++ with a JS/HTML interface and added graphics. Recently I converted the C++ part to C, which halved the size of the wasm file.
Really liked that! Congratulations on your work, it is very inspiring. I am also trying to build small languages, for fun, I think the web could use more languages.
One example that is quite amazing in my opinion is Pyret, I think you might like it, check it out at https://www.pyret.org
For server/desktop delivery, which is C++ original and major domain, for which those "costless abstractions" were developed, no.
It's not like Stroustrup, Stepanov and co had web assembly and constrained mobile devices loading webpages in mind when designing C++.
The idea of "costless abstractions" was about them not losing runtime speed -- not costless in code size. So the parent's comment doesn't really apply.
JavaScript still can be easy if you ignore the rest of the ecosystem.
Thing is, sooner or later, at the very least you find yourself wanting something like lodash or jQuery[1]. Ironically, the latter also came into existence to make programming across different browsers simpler back in the bad old days (of not that long ago), and did an admirable job of that.
Unfortunately jQuery, and similar libraries of the mid-noughties era, provided the breach in the dam that's seen us swamped in a torrent of new, sometimes baffling, and on occasion arguably unnecessary platforms, libraries, and tools, which have made the process of developing for the client a much more intimidating process for those starting out.
[1] Although these days you'd be surprised by how much of what jQuery offered is now built into the browser APIs and works consistently across them.
It's Jevon's Paradox [1] applied to the browser, where increasing the efficiency in which the browser can be scripted paradoxically causes websites to become slower and harder to build. Not because JavaScript itself (or any of the libraries built on top it) got worse, but because by allowing developers the ability to script more and more complex applications, sites became slower, and developer tools became heavier to support these more complex demands.
That sounds similar to Wirth’s Law. In general the more efficient a computer’s hardware is, the more bloated its software will be, so the slower the whole system will run.
I think that the raw-hardware-power aspect is actually a special case of ease of development - in that case, it's the ease of not having to think about low-level consequences of your abstractions or spend effort on optimizing your code!
Javascript is really cool when you learn it. However, the moment you dip into libraries you are dependent on someone else's work. Then you run into a problem because Native doesnt let you use a specific library, and googling your issue recommends that specific library. You use something else, it works alright. Months later you re-write everything anyway.
I don't really get this. How is any language's stdlib _not_ someone else's work? The language itself is "someone else's work".
The only difference, in my mind, between a "standard library" and a "third-party library" is the level of trust. If a third-party library is widely used by a community and known to be built by trustworthy people, I don't see how it's functionally different from a "standard" library.
EDIT: To clarify, I'm only trying to make a general statement about libraries, not the trustworthiness of any particular language's library landscape.
There are languages which do a much better job of reducing or eliminating possible "blast radius" of a bug in a dependent library. Functional/immutable languages such as Elixir come to mind (for example, you can literally reduce the scope of a library to an individual function). This is not one of those languages.
I’m a huge fan of these sorts of simple programming languages. I consider the simplicity of Purebasic and TI-83/89 Basic to be one of the main reasons I was able to successfully get into programming in high school despite not having any programming classes. I was also simultaneously learning x86 ASM and while that was also super fun, my Basic programming was far ahead of my ASM. Being able to successfully build simple games in Basic is extremely motivating when learning to code.
`end` as block delimiter makes much noise. Python code looks clean because it only uses indentations to delimit blocks. But this makes it at least difficult to refactor the code and to reformat it automatically.
I'm not sure why you are downvoted. Your statement is just an opinion, but it's your language and you are perfectly entitled to aesthetic judgements like that.
The . kind of reminds me of Smalltalk, which uses it to end statements (instead of the ; we all know from other languages at the time)
I agree with the parent, but for visual reasons: I think the dot is easily missed/forgotten when quickly glancing at your code, and that there is a visual imbalance between a 5 character starting statement (while) and a single character to end the block (the dot likely being the tiniest character available on top).
From my experiences working with beginners, I think the keyword "end" would be more clear to them. It would be great to have it as a synonym for ".", if nothing else. I think we can all agree that what constitutes "line noise" is pretty subjective.
I think there's more value to be had in building better learning resources around programming languages than continually trying to simplify them at the expense of power.
Besides that, if someone is already looking for a simple scripting language, Lua already exists. I personally prefer its syntax as well.
A person might make a language so they can learn to make a language. How could Lua exist if a person had no idea the tradeoffs in implementing various languages? You do not know the person's reasons.
You're absolutely correct, and making your own programming language implementations to generally improve as a programmer, for fun, or to get better at implementing programming languages is great. It can become a daunting task very quickly.
I was basing the person's reasoning after the original poster's reply:
> There are so many programming languages - but imho not a real easy one for beginners.
I've noticed that in functional languages, the presence of enumeration operators makes indexing in any case almost entirely unnecessary. Perhaps the original problem was just a "design smell" all along.
That's only half-true. Understanding all of Lua is hard, specially if you want to get into optimizing your code, but for simple tasks it's an incredibly easy to learn language. That being said, it really depends on the resources you're using to learn; Tutorials meant for programmers that bombard you with slang and exotic concepts will confuse newcomers.
Lua was made specially for non programmers. I think it is really intuitive and easy. I agree with the comment that perhaps understanding optmisation details is hard. But that's hard in every language.
Nice work! I would love it if we could get something like a codepen.io for this language, so we could share and debug code with people learning to program.
Well... it was easy to learn. It really isn't easy to fully learn it as it used to be.
I think there's a fundamental gulf between "easy language" and one that you'd want to do work in long term, and the history of Python is a great case study in that. If there aren't any "easy, real languages", well, if you want to fix that you'd better carefully study the reasons why all the easy languages have stopped being easy on their way to becoming real languages or you'll just repeat the mistakes of the past.
What do you think makes Python more difficult to learn now than it used to be? It seems to me that there are even more tutorials now. Also, the confusion between learning 2.7 or 3+ is pretty much completely gone at this point, while the base core of the language remains as simple and readable as the older version in my opinion.
I don't think the number of tutorials matters, otherwise Haskell monads would be super easy to learn. ;-)
Python circa 2000 was a language that was easy to learn. [1] What you saw was basically what you got. Python in 2018... well... it has grown lots more features, which might not show up in tutorials but a beginner will see them as soon as they look at actual code. List comprehensions, generators, context managers, metaclasses, async/await, decorators, 2/3 split, ABCs, etc. Useful? Yes. Easy to learn or understand for a newbie? Maybe not so much.
Never mind that setting up an environment is no longer as easy as creating a 'lib' directory somewhere in $PYTHONPATH and unzipping files in there. Now we have many package managers, virtual environments, competing Python versions, you name it. Back in the day I started a Python "project" with a single file and worked from there, growing as necessary. Nowadays I see new projects with a dozen files and directories. Again, there are (presumably) reasons for all this, but easier it certainly is not.
Welp, Python+numerics/stats stack is really messy; new stuff like coroutines can be a mindfuck. But what of what was once easy in Python is now harder?
"It really isn't easy to fully learn it as it used to be."
If you carve out the Python 2.0-ish subset and taught a class on that, it would be as easy as it ever was. But if your students take that knowledge and go to the Django tutorial, they're going to find themselves missing several concepts, and Django doesn't even use everything in Python, being rather old itself.
That said, I still think I'd rather take a Python 2.0-ish subset and teach students that, than give them some new custom language that they can't expand on or use in the field. Python 2.0-ish is still pretty useful and there's a clean upgrade track if you do want to continue down that road. And even the latest Python is still, at worst, middle-of-the-pack on language difficulty, if not still trending towards the easy side in the list of top 10-20 languages. But it's definitely a non-trivial upgrade path now.
A few things come to mind... Installing it. Setting up a project. Learning the whole language. Reading other people's code. Understanding how things work behind the scenes. Less surprising code, in the sense that it does what you expect.
I would add, "finding a third-part library", but that was mostly because there were not as many. :) Then again the current glut of libraries is a bit of mixed blessing. I can look for a library that does X and find dozens of them. Very few of them will be mature or do what I want. But that has more to do with the ecosystem than with Python-the-language.
One thing all modern languages (including Python) miss is the dead simple drawing functions of BASIC. They have no place in a regular language, but are super useful and intuitive in teaching programming. I tried teaching my kids Python at one point with a turtle graphics library but it was still annoying and complicated compared to BASIC where your drawing commands literally just "appear" on the screen.
Python has a lot of weird/surprising corner cases. In fact I'd argue that Ruby, a similarly capable language, has a lot fewer warts, which is why it consistently surprises me that Python is "doing better than" Ruby.
But even Python requires installing the dev environment etc.
I can see the use for this, for throwing people with no experience into "coding right away".
If you just apt-install IDLE I think you can be up and running very quickly. I did a relatively thorough survey when I first started learning python a couple of years ago and found PyCharm simpler for the course I was doing -- basic text handling, and a little CLI based interactive stuff.
Don't get me wrong, I like Python. If you're a non-programmer and you want to start programming, and you want to be useful and to be able to automate stuff quickly, you should learn Python.
Especially where math and statistics stuff is concerned -- I have a friend who recently started programming, and Python was his entry point. Unfortunately, the environment problems that everyone says are solved are still a pain. I had to troubleshoot his setup a lot; in particular it was a pain to make sure that if he called `python` from the command line it would be the same version as his IDE.
And Python as a language is just kind of big. It's the same problem that Javascript suffers from -- sure, you can learn just the basic stuff, but will that help you when you're looking at other people's code online? Will that help you if you're checking out an OS project? That kind of ecosystem matters for accessibility.
Both Python and Javascript have this philosophy of "there should be a library for everything". But what that means is that there's a ton of extra stuff just floating around, and no matter how much you tell people to ignore it, they don't. It's not a bad thing, in a lot of ways it's a very good thing. But it has consequences.
Python adds onto that with the idea that everything should be readable. So there are multiple ways to iterate over an array, and the syntax sometimes subtly changes so the code looks cleaner. These are, again, not bad things. But they have consequences. They increase the number of concepts you're wrapping your head around.
Compare Python with TI-83 Basic. A much, much smaller standard library that you can teach even a brand new programmer in like, a month. A few interesting restrictions (limited variables) that subtly push towards more advanced concepts (I learned how pointers worked on the TI-83 before I know what the word meant).
I think this is why people gravitate towards platforms like the Pico-8. There's something refreshing about being in a bounded environment where all of the concepts are kept small. Learning to program for the first time is about experimenting and learning to go in depth with a couple of concepts, not learning a wide variety of concepts.
That friend I was talking about eventually went back to doing a lot of programming in Excel instead of Python. Python was more powerful, and he played with it a bit, but he has an entire grasp around how cells in Excel interact with each other, so he's able to do creative stuff by just thinking about the stuff he already knows. He can write a program on paper without being at a computer. In contrast, when he wanted to do something creative in Python, he had to go Google "how do I do X"?
I do a lot of "creative" work in Excel too. Finance/business stuff where the shape of the problem itself is ill-defined. It's a whiteboard, not a "programming language" -- nothing that isn't visible will ever happen; nothing is programmed.
----
I had to write codes for my dissertation in Matlab because that's what my advisor knew. Matlab is popular in research because so many ideas are already whiteboarded in matrix formalisms. I feel like Python is like this, but for object-oriented programming: rewriting my dissertation codes in Python gives me uglier code because of numpy, but it's easier to package it in such a way that it can be reused and extended. (I.e. it's not its mathematical nature, it's "parameterizable encapsulation". This is even better seen in something like Flask).
I think you're saying that Python isn't great at procedural programming. I disagree -- the syntax is simple and it's there -- it's just that not a lot of relevant open source projects rely on a procedural style. Contrast: Python isn't great at functional programming; it's very hard to express ideas like functors and monads.
> I think you're saying that Python isn't great at procedural programming.
No, I'm saying it has weaknesses as a first programming language for beginners. Of course Python is practical, that's why it's so insanely popular.
The reason my friend went back to Excel wasn't because of a weakness in how Python is structured or what types of programs you can write in it. He left it because he didn't like needing to look up how to do things, or look to see what library supported what function. Excel is limited and inflexible, but he knows the "API" by heart, so when he's doing something creative, he's spending more time thinking in depth about the concepts he already knows, and less time learning new concepts.
Python is just big. There's a lot of it. There are multiple ways to do everything. That's good, and I like that about the language. But it's also kind of bad. You can ignore a lot of it, but that takes effort and it limits what resources/tutorials you can look at online. Being able to grab someone else's code off the Internet and learn from it or change it for your own projects is nice. But if you want to do that for Python, you need to be good at the language first.
That's what I think the strength of very small languages are. You can hold them entirely in your head without too much effort, so as a beginner you're able to spend more time applying them, which is often the fun part of programming for a beginner anyway.
Yeah, but your examples (TI Basic, Pico8) all imply that a first programming language has to follow a procedural style.
There's no reason whatsoever it should be so. I knew some odds and ends before college but had my introduction to programming with a SICP-like (but much simpler, I wasn't a CS major at MIT) course in Scheme that was taught by the creator of Lua. Like SICP, it emphasized a "compositional", mostly functional style. The next course was data structures in C.
So of course, a "First Course in Programming with Python" will be nothing like a "First Course in Programming with ZX Basic" (which yeah, encouraged you to peek and poke into memory directly, etc). A "First Course in Programming with Haskell" will be even more different. But some may argue that those who have cut their teeth on Haskell are better prepared for anything.
At any rate -- Haskell is really difficult but Scheme was until recently pretty popular.
It's not about procedural programming -- it's about the size of the language.
If you know of a functional language who's entire manual and standard library can fit on 2 or 3 sheets of paper, then fine, use that. But Python certainly isn't that language. Neither is Javascript. Neither is Haskell.
Doesn't mean you can't start on it. Heck, one of my very early languages was C++. But that doesn't mean it's beginner-friendly. Remember, I'm not talking about what your first programming class in college or high-school would be. I'm talking about, "can you sit down over a weekend with zero programming knowledge and end up with at least a basic understanding of how the entire language and runtime works?"
Scheme... yeah, I guess I can see Scheme being OK. But you're really missing the entire point of what I'm saying. The reason I brought up Excel in the first place was to drive home that how good the system is overall for practical, real-world purposes does not matter.
I bring up examples like TI Basic because if you want to teach someone TI Basic, you can hand them just a calculator and then give them one HTML file (https://www.ticalc.org/programming/columns/83plus-bas/cherny...) and that's it. You're done. They'll be able to figure out the rest.
TI Basic is a fantastically designed beginner language. Not because it's procedural. Because it introduces a small number of concepts that force the user to be creative and encourage them to organically discover more advanced topics on their own without an internet tutorial. It's fantastic because it's so small that even a beginner can look at any other example program on the web, even if written by an expert, and generally speaking know what it's doing.
My first thought (before seeing this comment) was that it reminded me of my first programming language, the TI-BASIC that shipped with Texas Instruments graphic calculators in the US. :)
I have found that immutability is actually simpler to understand (and, potentially related, results in fewer bugs per LOC written), it's just that everyone's (including mine!) first language is usually procedural/mutable so that seems to be what is "easy"
I can't fathom why you've been downvoted. I think you're absolutely correct: there's nothing "obvious" about either flavor.
It's really clear, in hindsight, why we started out with mutability (and self-modifying code and all sorts of "crazy" bit-twiddling goodies from the age of hardware-specific software).
But I don't think it takes too much imagination to envision a world in which immutability becomes the default, even (or especially) for beginners!
Now that RAM is relatively cheap and garbage collection algos are pretty decent, immutability should be the default, because it eliminates an entire class of bugs while enabling benefits like "easy" lock-free concurrency, etc.
Here's a project I'm excited about, I think it's the first fully-functional/immutable/declarative cross-platform GUI library in existence https://github.com/boydm/scenic Still pretty rudimentary but has made great strides in a year and the demo is pretty amazing (especially given how NOTORIOUSLY gui toolkits are typically OOP/procedural/mutable)
The source code is parsed to an AST, which is then executed. It began with a Java-Applet. When WebAssembly appeared, I ported it to C++ with a JS/HTML interface and added graphics. Recently I converted the C++ part to C, which halved the size of the wasm file.