I am working on a battle simulation for the game 'The Bazaar'.
I was quite frustrated with how the original devs handled monetization going into open beta, which sparked my motivation.
Trying out Kotlin for the first time and having a blast so far!
Also using an ECS architecture for the first time. It's quite a different way of reasoning about things, but it definitely helps with the dynamic fights that need to be simulated.
Thanks for the heads up!
But that's what I figured, based on how they dealt with the other trackers and overlays.
I am planning to open source it (when I am at least somewhat happy with the implementation) but without any references to the bazaar.
It just so happens that it uses items with cooldown and similar systems that deal with burn, poison, haste etc. ;)
You can then bring your own items and play out the simulations and maybe your items just so happen to be based on the bazaar or maybe you create your own custom items based on lord of the rings or whatever.
Right now, the project's primary purpose is to be an interesting problem that needs to be solved and helping me learn new things.
Btw. your tool looks great! A shame that team tempo is against these kinds of community driven tools
I think gp is right, and I don't think it's gatekeeping. I thought this about Java, it was easy to criticize its verbosity, but I realized how insignificant this is when actually practicing it. There's probably way more interesting and deeper criticism to make about Java.
About the first steps of a newcomer, there's always going to be some level of "don't worry about this now, we'll see what this means later" for any language. I remember this to be the case for every tutorial I read to learn a language. And it's fine, as long as you can try stuff and it doesn't get in the way.
I'd say it's more important for a language and its vocabulary to be well structured and well documented for a newcomer and Java does quite good on this front.
GP is right. If the words public static keep you from learning how to program you were never going to learn anyway. If I introduce someone to soccer and they quit because they couldn't figure out how to put their shoes on, chances are they werent going to learn how to play no matter what.
I think the converse(?) to this though is that the words public static are inconsequential.
Sure, if you are incapable of learning what a couple adjectives mean you won't go far, but that holds for much more than software.
Rather it's not important that the ball is big and blue so much as that you can kick it across the field - learning what the ball means can come later, but it's just unimportant noise (to start).
Java is pretty bad at this, though, insisting on specifying unimportant details up front rather than allowing for qualification. This is OK for a large monolithic application with complex requirements and a litany of edge cases, but inappropriate for many smaller use cases.
Did you know that the first thing John Wooden did with incoming freshman collegiate basketball players at the most prestigious program in the country was teach them how to properly put on their socks?
I still feel like the author is missing the forest for the trees. Bash is not great to write e.g. a red black tree in or do complex image processing, but you don't have to maintain a Java install, download libraries, or setup an editor with an LSP (and really, calling java script.java 10 asdf? Why do I need to invoke Java at all? At that point, I'm probably going to wrap it in a script anyways...)
Python has its own issues but it's a small, embedded install that you don't have to accept 5 different licenses for and worry about it being able to get the same version...
And bash? That's what pacman -S jq is for - anything I can't easily do in bash or batch I just offload to a small utility written in python or rust.
pacman -S jdk-openjdk, this is the reference java implementation and it has the exact same license as the Linux kernel. And java has never done such a breaking change as python did.
There is also jre-openjdk-headless, for 140 MB. How is that any different than Python?
This "java too heavy" is like 30 years out of date, if it has ever been true.
> And java has never done such a breaking change as python did.
I'm not really sure that's true? Java 8 to afterwards, there are breaking changes that mean a lot of old enterprise stuff can't easily move forward, or worse, bytecode incompatibilities mean source-code-less stuff can't be used anymore...
The whole thing about Graal is mentioned almost as an afterthought, my point is that the language etc. is so poorly designed as to be prohibitive to interface with unless...well you're on Java. Yes there are bridges etc, but a big point of the shell, bash, etc. is easy interoperability between many programs, etc.
Java is still today stuck in a mentality of "it doesn't exist if its not in Java", which is why yes, 30 years later, it is still "too heavy". Assuming you are the effective Operating System is an extremely heavy assumption.
> and it has the exact same license as the Linux kernel
Also, I neglected to touch on this point more, perhaps license is not the right word, as much as distribution - I don't know if you have ever tried building the JDK (not simple), or worked with the official JDK vs the open one (not the same functionality), or tried to access old versions of the SDK on the official websites, or had to deal with their installers, etc.
Giant headache and all around.
Not to mention, even if your pacman command works, this is still simply not comparable, the example I used was for installing a jq binary because JRE simply doesn't include this functionality by default...
And now you need the overweight pom/gradle mess to interface with the Java libraries because <insert technical debt reasons here>
The official JDK is the OpenJDK for several years.
Under Sun there were differences, but Oracle open-sourced every last difference and now there is only some Oracle branding logo as the only difference (and maybe some tiny proprietary codec, but your code will run on both the same way).
> If you want to introduce someone to programming, you probably don't want them to worry about what all those 'magic words' do.
I learned Java when i was 15 or 16, reading some random book first and then I stole 35 euros from my mother's purse and bought a copy of "Java how to program" by deitel and deitel[1]. The recommended version at the time was Java 5, and the SJCP certification was still issued by Sun Microsystems.
I can tell you, "public static void main" is not going to be the problem.
[1]: looking back (i'm in my 30ies now) sometimes I wonder if i would have been better off buying weed or alcohol (or both)
So you believe that your experience is a universal one for all learners? Cognitive load is a real consideration in teaching, and having to ignore and filter text is challenging for some folks.
The boilerplate around a main function is 10 units of load. Everything else you have to know to write a simple program is 500-600 units of load. The boilerplate is a rounding error, and just does not matter.
As mongol said in a top-level comment, Java isn't a great language for programming "in the small". It's not a great language for a casual user - or rather, there are languages that are significantly better. If you want to introduce someone to programming in a semester course, "public static void main" isn't going to be a significant hurdle. If you want to introduce someone to programming as a 14-year-old, maybe don't start with Java.
Why? Java is a small language with not many concepts, that is typed so many of your first attempts will be caught with helpful messages at compile time, and it fails safely at runtime with error messages pointing to an exact line number. Besides, it is a language that is actually used in the industry and has one of the biggest ecosystems. It's also plenty performant, can be low-level enough for learning about all kinds of data structures/algorithms, including concurrent ones and has probably the best tooling (IDE, debugger, etc)
What other language would you start with?
And isn't it easier to introduce concepts one at a time? For that reason implicit classes makes sense, and also for the occasional scripting, as in doing something one-off, but it is not as trivial that I can do it with piping 3 commands together.
True. But you need to know too many of them to get anything to run.
> that is typed so many of your first attempts will be caught with helpful messages at compile time
But it doesn't feel that way. It doesn't feel "helpful", it feels nitpicky. It feels like I have to get everything exactly right before anything will run. For a raw beginner, that's very frustrating. It is (emotionally) better to have something run as far as it can run, and then crash. (I agree that exceptions pointing to the line number are very nice.)
Again, for a semester class, the startup overhead for learning Java is too small to worry about - it's maybe a day or two. But for someone on their own, not in a class, a day or two is a huge investment to put in before they can get something running!
What would I start with? Something with a REPL. (It could be a language that is normally compiled, but there needs to be a REPL. Raw beginners need to be able to get something, anything, to work as quickly as possible.)
Yeah, you want to start with basic imperative programming with as little cargo-cult nonsense in the way as possible.
Your csci 101 kids will not benefit from unpacking what it means to compile an object-oriented language down to bytecode to run on a virtual machine. It's not that it's not valuable knowledge, they just won't have the context to make meaningful heads or tails of it.
related: I still puke a little remembering the requirement that students work on assignments in emacs on terminal machines rather than their text processor of choice(which was fine for me, but why on god's green earth would you put usability warcrimes like 'hjkl' in the way of someone just starting to learn? No wonder nobody in the early naughts wanted to learn to program...).
A lot of people learn to program from declarative languages like spread sheets. We should all be happy we have access to defective versions of assembly at too high a level but be angry that we had to use too low level an editor?
I think this is a really important point, even though I suspect you're joking.
Along with all the BS boilerplate text this specific post talks about eliminating, which is great, we simply forget how much legacy tech BS we just assume.
Beginner programmers should not have to know what a "file" is, or what an "editor" is, or that they need an "editor" to "edit" a "file". This is technical debt: these are implementation details which should be invisible.
This goes double for "compilers" versus "interpreters" and "source code" versus "binary code". FFS the noun _code_ means _a system for rendered text unreadable_.
You have a computer. You are talking to it in words, words which resemble English because that is one of the simplest world languages when you think about scripts -- writing systems -- as well as sounds. Hangeul is easier but only works for Korean which is harder than English. Grammatically Chinese is simpler, but spoken Chinese has tones which are very hard, and written Chinese is insane. Typed Cyrillic is no harder but handwritten gets weird and complicated and Russian is much harder than English. And so on.
English wins and so we talk to computers mostly in English.
So, you have a computer, and you type on it in English. That is all you should need to know: how to enter text, how to correct it when you get it wrong, and that is it.
BASIC has a great virtue which all the Unix and even the Lisp fans forget:
It's designed to work at a command prompt. Type a command, the computer does it. Give it a number, it remembers it for later.
This is a profound and important metaphor. It eliminates all the 1960s/1970s legacy BS about "files" and "folders" and "editors" and "compilers". Beginners don't need that. Let them learn that later if they prove to have real aptitude and want to pursue this.
Type a bare expression, the computer does it. Number it, the computer remembers it for later. That is all you need to get writing software.
And just like Python sorted out the problem of spoiled whiny little baby C programmers whinging about their pathetic obsessions with indentation patterns by making indentation semantic so everyone has to comply, line numbers in BASIC are a vital simplifying unifying mechanism, so lean on them: for beginners, make line numbers syntactic.
Don't force kids to learn pro tools like nomenclature and hierarchies. Give them a toy that they can get started with.
At first, they can structure their programs with line numbers, and they learn about leaving space, about RENUMBER commands, about LIST x TO y ranges, and stuff like that, because we are not using a bloody Commodore 64 any more.
But give them IF...THEN...ELSE and WHILE...WEND and REPEAT...UNTIL and named procedures so they can learn structure and not GOTO.
All the rest is baggage and should be deferred as late as reasonably possible.
The reason we use the words "code" and "coding" how's the history behind it. Originally it referred to translating an algorithm description into machine code. Indeed something less readable. The first compilers were called "automatic coders". I.e. their input wasn't code, their output was. Originally the word "compiling" referred to putting together an image of library functions. Something more similar to linking. The terminology shifted and drifted as time went on.
This seems to be very dismissive of all the physical evidence we _do_ have.
Text isn't the only way to store information, i.e. we can draw lots of conclusions from fossils, ruins or even sediment layers etc.
I was quite frustrated with how the original devs handled monetization going into open beta, which sparked my motivation.
Trying out Kotlin for the first time and having a blast so far!
Also using an ECS architecture for the first time. It's quite a different way of reasoning about things, but it definitely helps with the dynamic fights that need to be simulated.