Psst, here's a functional example of a code snippet taken from our website (Hyperlambda code). Try implementing the same in C#, Java or (sigh!) C++ ... :/
I assume everyone reading the above code can instantly understand what it does ...
The above is 5 lines of code. Its C# or Java equivalent would probably require hundreds of lines of code, and at least half a dozen classes, in addition to (consuming) some 25 to 50 different existing classes ... :/
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
strcpy is a bunch of lines if you don't have it in your standard library. Everything in this example is hiding complexity somewhere, just like all code ever written.
I like "less code" as a principle, but I'll add more SLOC if I think it makes what I'm trying to do clearer:
Simply wiring up your HttpClient, ensuring you're disposing your ContentResponse object, and correctly parametrise it would require 10x as many lines of code as the Hyperlambda 5 liner above. Then do it twice (two invocations), add the required boiler plate code for threading, and ensure you wait for the code to return before you move beyond the join invocation, and you're probably looking at a lot more code, at least 10x as much code as the Hyperlambda example, probably even more than that. If you disagree, feel free to prove me wrong. You've got the Hyperlambda code up there - By all means, port it to C# and let's see what produces most code and complexity ...
Every one can undertand what it does. Try implementing it in Hyperlambda, which will atleast require 100s of lines of code to implements this Awesome functionality. And hence by your logic it can be deduced Hyperlambda is psychosis.
You showed encapsulated code as an example, so did I.
You showed encapsulated code as an example, so did I.
No, I showed three of the fundamental building blocks in Hyperlambda (3 slots), which are similar to "functions" in structure, and how these 3 fundamentals solves an actual problem, being retrieving 2 HTML documents in parallel, and waiting for both documents to download.
I have demonstrated a better example of how to run any app with just one line of code. It does all you say and do in just one line.
If reducing number of line is yard stick.
One of the yard stick yes, but definitely not the most important of all. A sane programmer would and should choose modularity, for a non trivial programm, always over LOC. A few extra lines which gives better extensibility and readability is instead good and promoted as a good programming atticate.
Beautiful, but of course creating libraries that simplifies things is possible in all languages. When I was doing my LOC count, I considered the bare bones implementation using HttpClient from .Net ...
Najs code though :)
Edit;
result of the operation are ignored
I didn't see this one before now, but no, my example does not ignore the result of the operation. That's the purpose of the [join] keyword in Hyperlambda. It waits for the [fork] invocations to finish, and returns the result of the invocations to the caller. To access the content of the first for instance would be as easy as follows.
get-value:x:@join/0/**/content
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Psst, here's a functional example of a code snippet taken from our website (Hyperlambda code). Try implementing the same in C#, Java or (sigh!) C++ ... :/
I assume everyone reading the above code can instantly understand what it does ...
The above is 5 lines of code. Its C# or Java equivalent would probably require hundreds of lines of code, and at least half a dozen classes, in addition to (consuming) some 25 to 50 different existing classes ... :/
strcpyis a bunch of lines if you don't have it in your standard library. Everything in this example is hiding complexity somewhere, just like all code ever written.I like "less code" as a principle, but I'll add more SLOC if I think it makes what I'm trying to do clearer:
Not in C#
Simply wiring up your
HttpClient, ensuring you're disposing yourContentResponseobject, and correctly parametrise it would require 10x as many lines of code as the Hyperlambda 5 liner above. Then do it twice (two invocations), add the required boiler plate code for threading, and ensure you wait for the code to return before you move beyond thejoininvocation, and you're probably looking at a lot more code, at least 10x as much code as the Hyperlambda example, probably even more than that. If you disagree, feel free to prove me wrong. You've got the Hyperlambda code up there - By all means, port it to C# and let's see what produces most code and complexity ...Every one can undertand what it does. Try implementing it in Hyperlambda, which will atleast require 100s of lines of code to implements this Awesome functionality. And hence by your logic it can be deduced Hyperlambda is psychosis.
No, I showed three of the fundamental building blocks in Hyperlambda (3 slots), which are similar to "functions" in structure, and how these 3 fundamentals solves an actual problem, being retrieving 2 HTML documents in parallel, and waiting for both documents to download.
I have demonstrated a better example of how to run any app with just one line of code. It does all you say and do in just one line.
If reducing number of line is yard stick.
Reducing the LOC is always a "yard stick" yes.
One of the yard stick yes, but definitely not the most important of all. A sane programmer would and should choose modularity, for a non trivial programm, always over LOC. A few extra lines which gives better extensibility and readability is instead good and promoted as a good programming atticate.
Actually, your code does nothing useful beside generation of useless traffic (result of the operation are ignored) :)
In the Java framework I'm working on, your code will look like this:
Wish I have more time to work on this framework...
Beautiful, but of course creating libraries that simplifies things is possible in all languages. When I was doing my LOC count, I considered the bare bones implementation using
HttpClientfrom .Net ...Najs code though :)
Edit;
I didn't see this one before now, but no, my example does not ignore the result of the operation. That's the purpose of the [join] keyword in Hyperlambda. It waits for the [fork] invocations to finish, and returns the result of the invocations to the caller. To access the content of the first for instance would be as easy as follows.