Would you consider releasing a less powerful version of the language with a smaller binary? Like a baby version? I’d be really curious what it could do do do do do do do.
Most the weight of the binaries is in the GameShark framework. You can get a tiny binary by erasing all files under /bin except shark(.exe) and system.shar
Wow 12 billion and it was 6 years ago? Where does the time go ... I thought I remembered when one video just reached the 2 billion or 4 billion mark, or 2^31 or 2^32, and it was newsworthy
There’s potential for a whole family of Shark languages. Put them on product hunt, and it’ll be a run-away success. Hopefully they’ll be memory-safe at last.
As a language purist, I'm slightly saddened by the removal of the colon to indicate the beginning of an indented block on the next line.
I believe Cobra did the same and it always bogs my mind why that darned colon can't be left in peace. When you are reading line N, you already know that the next line will be indented, if there is a colon, that is. It is all about making the reading experience as pleasant and meaningful as possible.
Other than that: don't mind my gripes and congrats with the project. It looks good! :-)
It's frowned on in HN and I don't think I've ever done it (writing a comment that's just praise) but I think this is just so cool and can't wait to try and make a 2D game with it. I think your idiosyncratic grammar is actually charming and the sign of a creative mind. Hope you don't let the negative comments get you down.
If Javascript is the target and the baseline benchmark, I wonder what is the rationale not using Javascript directly? Surely, the Python syntax is not the sole motivation, isn’t it?
JS has its own warts, what better way to avoid them than not going that way in first place? Plus JS is still evolving, so devs would need to play catch-up to support all the latest features.
I think most people would disagree with that. The ecmascript versions even changed their naming from numbered to release year reference because they wanted to move fast and acknowledge a commitment to consistent/frequent release cycle. That's why they moved from es6 naming to say es2015 etc.
Compare that to something like Lua which is notoriously slow and deliberate with changes.
I tend to think with JS's willingness to adopt any and every hot/contemporary programming trend and it's inability to purge anything (or "break the web"), it's unfortunately destined to age like milk, but I guess time will tell.
> Care must be taken if you assign a given key to the null value: some platforms remove keys assigned to null from tables making them invisible to the in and not in operators.
It is really important to specify the exact behaviour and make sure all platforms behave the same way. You can't write portable programs if the behaviour differs from platform to platform.
Not happening. If you compile something to Lua assigning a key to nil will erase it, python and javascript will keep it. Pheraps making a special NullObject value to fill these slots would be a good idea, but you could not interact seamlessly with the target system and probably get a speed penalty.
Having the exact behavoir in all platforms is not possible in some cases, and these are the cases left 'undefined' in the handbook.
Why not remove the ability to set a key to the null value then? Raise an error in the compiler. It seems pretty undesirable to have undefined behavior in the language, and if high performance is one of your goals, remove the ability for users to do the low performance things.
Hey that looks pretty fun, thanks for sharing it & count me in, I'll try it. I like these zippy little lightweight languages that happen to have docs and SDL bindings and so on...
BTW how did you arrive at the name?
Edit: Running the linux build script, bit of an issue:
Just tell GCC to shut up and try again, if persistent make an issue in GH.
Shark used to stand for SHAred ARKitecture, since the language can compile to lua, python and javascript using the shared architecture found in the three. Now it stands for nothing really.
> Just tell GCC to shut up and try again, if persistent make an issue in GH.
That seems like a cavalier approach to type warnings. Sure, it may not be an issue, most of the time, but type warnings are there to highlight/suggest potentially bad code, e.g., poorly thought out or insufficient consideration given to typing, overflows, etc.
For a one-off or bit of hobby code, I'm quite happy to compile without warnings and/or to ignore whatever warnings my code generates, but for something I am sharing with others, especially releasing and hoping they will adopt, I crank the warnings to 11 and make sure compiles are clean, without pragmas.
The code compiles and runs very cleanly and smoothly under win32 and linux mint. This is probably an issue of size_t being different sized in a platform or the code using int64_t everywhere but int is 32 bit. Thanks (and is not ironic).
OK, I think I understood your meaning, checked with GPT just in case.
> The developer's suggestion to "tell GCC to shut up" means to use the appropriate flags or options to suppress the warnings or errors generated by GCC.
> There isn't a specific GCC flag to ignore unexpected arguments. However, you can use the -Wno-error flag to disable the treatment of warnings as errors, which will allow the build to continue even if warnings are generated.
OK, same issue flag or no flag, guess I'll file it. Wondered if there was some release or something that was more direct than the build script, thanks. Edit: filed #1
I'm going through the handbook and some things don't seem satisfactory.
Division always yelds a floating-point number, so the following doesn't work, you have to explicitly use floor():
min = time / 60
sec = time % 60
Also
var x = [1, 2, 3]
x[1] /= 2
It's weird that now x includes one float and 2 integers. Besides, x[1] == 1 evaluates to false because a float never equals an integer.
The description of 'for' loops is not complete. For example, does range(1, 10) go from 1 to 10 or from 1 to 9? What is the value of the iteration variable after exiting the loop?
The example to handle a variable number of arguments calls the function callee() with 0 to 4 arguments. So it IS possible to have functions with a variable number of parameters. What's the goal of this example, then?
Division yielding always a float is a python issue, in python you would use the floor division to get integers, but you cant do the same in plain shark because other target platforms might not have it.
You can disregard and ignore most floating to int conversions and checks if youre NOT targeting python. Other platforms generally have just double precision and no integers (incluiding the C and Java ones) but not happening in python.
In your example x[1] == 1 yields true in any platform. So dont worry.
The for loop will iterate exacly end - start times with a start of 0 if missing and finish after end - 1 has executed.
Using the iteration variable after loop exit is undefined behavior, some platforms keep the last value stored like python and javascript, others will make a wild assignment to a global variable every time like lua or the C/Java editions.
Functions do NOT have variable lenght calls, if you read the code a second time, what its doing is looking up an array based in arguments length, and proceeding to switch on each case.
Hope this helped, will update the handbook if something is unclear.
The standard python distro does lift a good 27-30 MB depending on version and offers lots of optional (but generally useful) libraries. The standard shark SDK distro lifts under 13 MB and also offers some precompiled libs (mostly game and graphics related). I dont know how heavy is python with utilities stripped but shark weigths 50 KB and depends barely on libc, this includes the interpreter, compiler, linker and standard libraries like system.path and system.io. In this respect shark is very even with lua and many small-medium sized lisps.
Shark doesnt solves any problem you could not solve with other languages, its just better at handling a whole wide range of problems others cant solve. Have you dreamed making the frontend and backend of your site in the same language, or building the same game in PC, Mobile and Nintendo 3DS from the same codebase and just a few commands? I do, and shark is my attempt at doing it.
> Have you dreamed making the frontend and backend of your site in the same language, or building the same game in PC, Mobile and Nintendo 3DS from the same codebase and just a few commands? I do, and shark is my attempt at doing it.
Sorry, you might think that I am rude, but I am not.
I quite applaud your determination and your good will to work so hard and release an usable programming language. I didn't do that.
I was just wondering if a Python like language is a good fit for front-end programming.
I never dreamed about using one tool for everything but it happened. Nowadays I use C#/.NET for almost everything.
There sure are. I just pasted the readme in the comment box here (so Chrome would check the spelling) and removed the correctly spelled words to leave:
hability, dependences, plataforms, enviroments, aplications, writting, appart, inmediately
I liked NIM btw. But shark is not about a faster python, it ofers quite a few advantages: speed, size, hackability, ambiguity and lookahead free grammar, and foremost an insane portability and repertorie of libraries to use. The shark compiler is a few thousand lines but its output can be run as python, javascript, lua, java and native.
> Imagine a programming language with the syntax of python
I am not sure when the python syntax become such a beacon of quality, but that makes me genuinely sad; Especially with looking at all the other syntax (swift, kotlin, F#/ocaml, rust) out there.
That is not my experience having to deal with a Python codebase for the first time in my life recently. I do not enjoy attempting to understand the magical annotations everywhere, the terse, cryptic syntax of list comprehensions, random syntax trivia like array[::-1], tons of line noise in regular expressions, having to __format__ "private" symbols like this, and so on.
I obviously don't have experience with Python, but the only good thing about the syntax to my eyes is the vertical space savings you gain by doing away with curly braces.
Magical annotations? Do you mean decorators? Or maybe types? Whether they're present at all depends on the code base, and most probably have neither.
[i*i for i in range(10)] is hardly terse or cryptic.
Python regular expressions are much like regular expressions anywhere else, so you're not really criticising Python there. You might need extra backslashes if you were trying to do them without raw strings (r'\s*' == '\\s*'), but that's hardly unique to Python either.
> having to __format__ “private” symbols like this,
But…that’s not how you format “private” symbols in Python, conventionally; single leading underscore is; double leading is for identifiers you want mangled with classnames, and double leading and trailing is for special methods.
As a long-time Rust programmer, I agree that the syntax is not the most readable around.
That being said, string concatenation is only marginally related to syntax. It's a matter of semantics, which go much deeper. There is a very good reason for which string concatenation isn't simpler in Rust.
>Shark was born in an attempt to fix some python issues I have spotted with the years: Python is slow
I constantly hear this, but are there some actual use cases where this commonly matters? Yes, yes, looping is slow in Python, but whenever someone in real life complains about Python being slow execution of the program still takes so little time that even if Python has 10 times slower it wouldn't make much of a difference.
Or have I just misunderstood this completely and python actually is unusably slow for common things?
> Or have I just misunderstood this completely and python actually is unusably slow for common things?
I use python for some side-projects at work and for most of my personal stuff and it's mostly fine, but its general slowness/big memory footprint implies that you can't just write stuff the "easy" way, you have to use the "fast" API or else it's terrible, and that's infuriating. It's as though the power of your machine is partially hidden from you and you have to go around that limitation.
It also feels like it "should" be faster than it is, which compounds the frustration.
OTOH many performance losses come from using the wrong algorithm, often implicitly (wrong SQL query, wrong caching policy, wrong data structure), and Python is generally fine in that respect, much more than many other high-level languages in fact: the pythonic way is usually also algorithmically efficient.
I write a lot of python code at work. Mostly tools, but sometimes protocol libraries for our testing framework and while I've sometimes gotten complaints about performance of some of my tools usually when I end up profiling the tool it spend most of its time outside of python. Which is why I am a bit curious why many people think python is so slow it is not worth even using.
Your notion of “common things” may not be universal. In the sciences where Python is extremely popular, many common things are quite computationally demanding and feel the slowness of Python quite acutely and the slowdown certainly does make a difference. Looking at this shark thing, they appear to be concerned with games and interfaces, which have their own demands and likely have similar problems where the performance difference is very tangible.
I've used lots of obscure cli tools and the ones written in python are always so slow to the point where it's just annoying. Maybe python is meant to glue things together but many people just ignore that and write everything in python anyway.
Could you give examples? Because I know that there is subsection of people who simply refuse to use a CLI tool if they hear it was written in python, but I really want to get my hands on one so I can see for myself.
Datadog's "agent," a monitoring daemon that customers install on their hosts, used to be mostly Python but is now mostly Go for performance reasons. I wasn't around when that happened, so I don't know if it was mostly a CPU/memory thing or mostly a GIL/throughput thing.
I love Python, but even if Go wasn't faster, trying to deploy Python dependencies on customer hosts sounds like a nightmare compared to compiling and distributing a single binary.
Throughput. Of course it won't be obvious if you aren't running parallel implementations of your backend in python and C++/Rust/etc to compare your cloud billing, but 10x slower means 10x more compute requirements for the same service quality, doesn't it? And you have to pay for that. Maybe price doesn't increase linearly, but I'm sure it does increase.
Parellelism is a good reason to not use Python since GIL is what it is.
But I would argue whatever you gain back from lowered hosting expenses probably aren't worth the extra development time & costs that come with lower level languages, but yes that depends on what you are writing.
> But I would argue whatever you gain back from lowered hosting expenses probably aren't worth the extra development time & costs that come with lower level languages, but yes that depends on what you are writing.
I mean... I've used both python and go. And in my opinion, python doesn't really have much higher developer velocity.
I'd never do web dev in C++, but Rust seems like a mixed bag. It is a bit notorious for having a steep learning curve. But once people are productive, it's arguably a higher level language than python.
> I'd never do web dev in C++, but Rust seems like a mixed bag. It is a bit notorious for having a steep learning curve. But once people are productive, it's arguably a higher level language than python.
Having done back-end in Python, TS and Rust, my experience confirms this: Rust is a very high language once you're past the steep learning curve.
However, the times are changing. There is an energy and components crisis and there are plenty of reasons to believe that it's going to grow much worse / more global. I suspect that at some point in the very near future, we'll need to relearn to code for a finite set of resources instead of just assuming that "the cloud" will solve it for a few more dollars.
Not sure if this answers your question, but the lack of (real) threads in Python is a big blocker if you are running any kind of performance-related code, e.g. a back-end. Yes, you can kinda emulate threads with processes, but suddenly, your code becomes much more complicated and all the readability benefits of using Python disappear.
For a very long time, OCaml had the same problem. Now that OCaml has finally entered the multicore era, I will see if I can get back in touch with the OCaml magic :)
> but are there some actual use cases where this commonly matters?
> Or have I just misunderstood this completely and python actually is unusably slow for common things?
I don't know what you mean by common, but common sense tells me "common" things shouldn't be slow.
Python was a glue language, ok for small scripts. And it's good at what was designed to do. Trying to use Python for everything is like trying to use Javascript for everything: a bad judgment. And JS is way faster than Python.
Python is Visual Basic rehashed, the greatest thing for a zillion wannabe programmers because they are too lazy to learn something else.
>Python is Visual Basic rehashed, the greatest thing for a zillion wannabe programmers because they are too lazy to learn something else.
This is what I think most python haters actually hate. For some reason there is hate when someone makes things work faster (production time) than you with what you feel is inferior language.
I learned to program with C++ and Java and I've dabbled with multiple languages. Currently I write everything I can with Python. I seriously do not see the benefit of making things run 10 or 100 or even 1000 times faster when everything already is fast enough for real life. I even coded my last embedded project with CircuitPython instead of C and just to check it out and I really can't feel the difference between the end products.
>Javascript for everything: a bad judgment.
There is inherently nothing wrong with writing most things in JavaScript the reason why we hate most JavaScript applications is Electrum - meaning the fact that it requires entire extra browser with it.
Of course there will always be somethings where performance is key, but these are usually specific things and require purpose made solutions - and you know what? If you write that solution in C (and probably Rust) you can literally just call that library from cPython.
>And JS is way faster than Python.
I feel suspicious of this. What JavaScript on V8 has going for it is JIT, but I don't know if the difference between node and pypy is significant enough.
> This is what I think most python haters actually hate. For some reason there is hate when someone makes things work faster (production time) than you with what you feel is inferior language.
Not entirely sure what you have in mind. For me, Python is a pretty good language for prototyping. But, after having worked professionally with it a few years, it's not a language I trust in production. Way too many manners to break stuff during a further refactoring without realizing it, no matter how many tests you have written.
> There is inherently nothing wrong with writing most things in JavaScript the reason why we hate most JavaScript applications is Electrum - meaning the fact that it requires entire extra browser with it.
Erm. The main reason to not use JS is not Electrum, it's "undefined is not a function". That and the thousand of other interesting choices made by the specs.
> Of course there will always be somethings where performance is key, but these are usually specific things and require purpose made solutions - and you know what? If you write that solution in C (and probably Rust) you can literally just call that library from cPython.
Writing Rust code for CPython is indeed pretty easy.
Note, however, that developers who prefer Rust to Python do so for reliability reasons, not for performance reason. Writing Rust code for Python won't help much there.
> I feel suspicious of this. What JavaScript on V8 has going for it is JIT, but I don't know if the difference between node and pypy is significant enough.
I benchmarked a few algorithms a while ago (not complete applications) and JS was at least 10x faster than CPython on pretty much all benchmarks. Of course, on I/O-bound applications, JS is going to have a similar performance profile as Python.
> Python is Visual Basic rehashed, the greatest thing for a zillion wannabe programmers because they are too lazy to learn something else.
This is needlessly inflammatory - characterizing Python programmers as lazy, stupid, or "not real programmers" has no place here. Many (very successful) businesses have been built using Python and, while they could have been written in other languages, there are always tradeoffs (developer experience, memory safety, package ecosystem, etc).
> Imagine a programming language with the syntax of python, the hability to run in the browser and whose package has the size and speed of lua. Welcome to…
