Show HN: The Shark Programming Language
github.com
github.com
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! :-)
+1
I get not having kids, but 12 billion views, c'mon
https://en.wikipedia.org/wiki/List_of_most-viewed_YouTube_vi...
Now it looks like there are 10+ videos greater than 2^32, and Baby Shark has blown past that
I feel very out of touch...
https://www.samsclub.com/p/kellogg-baby-shark-cereal-26-4-oz...
Why so many do's?
-Shogun
… very, very slowly. What language isn’t evolving?
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.
I noticed one thing in the handbook:
> 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.
Having the exact behavoir in all platforms is not possible in some cases, and these are the cases left 'undefined' in the handbook.
Hope this clears things a bit ;)
Cheers, -Shogun
BTW how did you arrive at the name?
Edit: Running the linux build script, bit of an issue:
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.
Edit: Typo check O _ O
> 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
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.
Shogun
What is shark missing?
Cheers, - Shogun
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
var x = [1, 2, 3]
x[1] /= 2
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?
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.
- Shogun
Do we need Python in the front-end? Why?
- Shogun
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.
But you got the answer for your original question, right?
Your original title had "realease" too.
Cheers, -Shogun
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.
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.
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.
[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.
That‘s not random syntax trivia. It‘s a slice. Pretty generic and straighforward.
That said system languages have a disadvantage, they can't even concatenate two strings 'simply'.
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.
>sharks can't write it
ngmi
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?
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.
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.
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.
> 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.
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).
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.
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.
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 :)
… ChatGPT