<bjorkintosh>
my 'new language' language is ... <drum roll>
<bjorkintosh>
java.
<bjorkintosh>
I had never taken a proper look at it until now.
<bjorkintosh>
it's a (mostly) imperative language with some object overhead is what I see so far.
<bjorkintosh>
all methods are imperative programs. and there's an object hierarchy wrapped in classes.
<bjorkintosh>
when squinted at right, is OO not similar to a small database with stored procedures?
<beneroth>
I take you talk about vlang now, not java, right?
<bjorkintosh>
java.
<bjorkintosh>
it's the new shiny language on my block :-D
<bjorkintosh>
I know absolutely nothing about vlang.
<beneroth>
C# used to be the better Java
<bjorkintosh>
no doubt.
<bjorkintosh>
but C# and .Net do not have graalvm.
<beneroth>
both are in my view languages to ensure minimum productivity when you have/want a mass of bad exchangeable programmers (as enterprises want it), and crippling with verbosity and boilerplate for good programmers
<bjorkintosh>
beneroth: that is a desirable outcome for enterprise software.
<bjorkintosh>
they know it sucks so they create a low level threshold for systems development.
<bjorkintosh>
it mirrors a bureaucracy quite well.
<bjorkintosh>
it's a tradition going all the way back to COBOL.
<beneroth>
yeah, I suspect the whole concept of enterprise software is wrong, but I might underestimate the value of bad software (vs. non-existing software)
<bjorkintosh>
it's better if it exists and is used.
<beneroth>
I think big software dev teams are a bad way to make software
<bjorkintosh>
otherwise you end up with a bunch of scrap paper everywhere.
<beneroth>
I know one of the guys involved with the very first java runtime. It was a classic case of "we made a bad proof-of-concept, to implement the proper version next. Sales-People ran with the bad prototype and it became the basis so some things couldn't get fixed later anymore"
<beneroth>
hm.. it was not really much genius, I believe. the genius was in the Pascal P-Code, the only idea that lead to java was to re-implement that a bit broader.
<bjorkintosh>
the jvm is a stupendous feat.
<bjorkintosh>
the much maligned java language is ridiculously simple.
<bjorkintosh>
I did not know this until a few days ago.
<bjorkintosh>
but in that simplicity arises the complexity of expression. in any case, I'm going to learn it because graal is a superb piece of software development I'm interested in understanding well.
<beneroth>
I learned myself C++ in (late) teens (because I wanted to do GameDev), than got educated as software dev where I had to learn Java as part of the curriculum. Coming from C++ it was a pretty restricted environment, and Generics instead of C++ templates were a lot less powerful while having unforeseeable runtime performance hiccups
<beneroth>
so outside of that I tried to stay away from Java and was mostly successful
<beneroth>
what's graalvm? new runtime implementation?
<beneroth>
there were big steps forward and some good innovations in java runtimes in the last 15 years
<bjorkintosh>
yes. it's an improved JDK for the JVM.
<beneroth>
why not use graalvm but instead of java with another JVM language like clojure?
<beneroth>
the java byte code is good, I believe that
<beneroth>
(though it's mostly a concept taken over from Pascal, not really invented out of nothing)
<beneroth>
for my taste is java too verbose. More verbosity than C++ with less of the benefits, I think (for my way of programming)
<beneroth>
it might well be that Java is now a better language than C# (which basically evolved into a mix of separate, incompatible context-depending dialects while looking like a single language), and certainly it will be a much better language than 20 years ago
<bjorkintosh>
well, the verboseness is meant to improve readability. you don't create java programs outside of an IDE. it's not a scripting language afterall.
<bjorkintosh>
it's not a notation for thought (like APL is)
<bjorkintosh>
and it's not a language for exploring ideas either, though you can.
<bjorkintosh>
so within the IDE, you have all the nice completions and whatnot. the problem arises when one tries to use the tool (java) outside its wide range of uses. and it's wiiiiiiide.
<bjorkintosh>
so, for instance, you wouldn't try to roll your own object system in java. there's no point. whereas in languages like lisp and tcl and lua, it's a walk in the park.
<bjorkintosh>
they're in the end just tools. knowing how to use them well for their intended functions makes life easier.
alexsotodev has joined #picolisp
<beneroth>
true. my issue with verboseness is not the initial writing, but the maintainability - rewriting. Some kind of changes, in a verbose language, easily turn into effort where a complete rewrite from anew becomes easier than changing the existing codebase.
<beneroth>
I'm also suspicious about the common notion that "code is more often read than written". From my experience, I'm not so sure that this is true.
<bjorkintosh>
beneroth: there's a simple reason: documentation suuuuucks.
<bjorkintosh>
if documentation were great and straightforward, there'd hardly be a need to do so. but it's an auxiliary effort and managers want to see things running.
<bjorkintosh>
the fact that we have to revert to google, reddit, stack overflow, irc, forums and docs just to wrap our heads around code is proof enough that documentation sucks. knowing how to read the code meaningfully is a bonafide super power.
<beneroth>
I find documentation easy. Its very time consuming, but not that difficult (at least for me). It is as you say: it often doesn't get prioritized.
<beneroth>
bad managers will do bad managing. Change that, not symptoms.
<beneroth>
bjorkintosh, we (as an community/industry) should teach new devs to read (and eventually write) RFCs. They're concise and precise.
<bjorkintosh>
and boring.
<bjorkintosh>
attempts at systems specification have been made many times over.