(untitled)

I'm knee deep into Java because it's what my university teaches. I'd like to build on this so I can actually be employable. What resources would you recommend to fill in any gaps and start getting good at Java? >inb4 new language

>>3499 https://javaranch.com/

>>3499 learn the spring framework https://spring.io/ It's really exploding, seeing job adds for it all over. Just google around for tutorials, I know Udemy has some stuff on it as well.

>>3501 Not OP. But what would be a good project to put on a portfolio? I already know the basics of spring. Just haven't found anything interesting to make with it.

>>3511 Find an idea you like somewhere where projects are hosted and tweak it. Don't use their code but build your own version from the ground up. Personal use only.

If you have a hobby, you can do a web app related to that. For example, you could do some sort of recipe sharing site if you enjoy cooking. Projects like that make you more human to the recruiters/interviewers.

>>3499 This is my favorite book on java by far, just skip to the third/fourth chapter. It introduces a bunch of stuff they probably didn't teach you in your java classes in school, but are really useful for doing complicated stuff in a small amount of code in java. https://lainchan.org/%CE%BB/res/2.html#2183

>>3511 Everyone has a hard on for e-commerce these days, make some sort of a e-shop. Make sure the search engine allows a lot of complicated filters and what not, might be hard to find a good data set for it but there are some good DVD data sets out there if you good around. Make sure to get a payment api like stripe in there. Tying in FedEx or UPS's shipping API might be a good idea too. Write a couple of raw SQL quires in there ( probably in the filters ) where its faster than the ORM to show you know SQL well enough to address bottlenecks. >>3513 Also, what this guy said, don't just do dummy projects ( although dummy projects are a must ) but make a site around a hobby or interest of yours. I've had past students do stuff like soundcloud aggregators, prodcast aggregators. One thing I liked a lot was a image scraper / search engine for deviant art where you would give the app your 3 favorite artist and it would examine the strokes and lines and return similar artist based on that. http://freemusicarchive.org/ is not a well kept up site, but it does have a pretty awesome API and over all load of assets you could play with if you cared about it. If you post a project idea here I'll tell you how practical it is and what libs you need to start learning to do it. Most of my students work in Python, but I'm originally a Java guy, so I might not be "as" up to date on Java as some, but I still use it for all my windows apps and Adobe stuff.

Once you're confident enough about the stuff mentioned in other posts (or even before), you could try messing around with Clojure. It won't necessarily teach you much about Java or the Java ecosystem unless you dig into its innards or use a lot of Java libraries, but it'll allow you to learn stuff you simply can't from plain Java. It's a functional Lisp, what else is there to say?

>start getting good at Java To really understand Java you need to start learning about the JVM itself. The virtual machine is the real technology behind Java. People treat it like it's a magical machine that lets their program run. You can set yourself apart by being familiar with how it works and how to tune and customize it.

>>3544 Do you have any resources I should look into?

>>3513 >>3526 Sorry for replying this late. Thanks for the thoughtful advise, lains. I've been meaning to do some of the things you mentioned but never really found the time nor the energy to pull it off. Also, about doing a project that revolves around a hobby. I do have a few things that interest me, like music. But my tastes are wide and my needs few so it's going to be hard to come up with a good idea. Besides, been looking for some cheap Java hosting provider and I didn't see very good options. Once I'm through with midterm exams in my uni I'll be sure to give it a try.

>>3604 Yeah. This book is pretty detailed about virtual machine technology. It talks a lot about the JVM too.

>>3499 So here's my take as a security fuarrrk who has to read EVERYONE'S bad java. Practical Advice: 1) Your school's idea of what good Java is, is not the same as good Java. Just learn what makes them happy and do that. 2) Nobody agrees what good Java is. 3) If you want to work at a bank first go read the gang of four design patterns book. Banks worship that soykaf. Then go learn J2EE. If you are lucky the banks might use struts, or even spring if they are fancy. Expect some old soykaf. 4) If you want to work for the kind of modern software company that uses Java, like a hedge fund, or a startup, or Google, learning the more modern Java web frameworks would be a plus. Vert.x is cool in that regard. Honestly most companies outside the bank zone are going to care a lot more about you generalist algorithms skills than specific web browser crap. 5) Why not write an Android app? Things not to do: 1) Please god don't write those OOP factory object puzzles every Indian contractor since 1998 has loved. For fuarrrk's sake, make your code operate with less than 30 levels of indirection. 2) Same goes for your exception handling. If I have to traverse 9 levels of exception handlers to figure the fuarrrk out what's wrong, I'm a very grumpy person that day. 3) But do write some fuarrrking error handling code.... 4) and don't forward your stack traces to the user. Come the fuarrrk on people. 5) Lambda's are a privilege, not a right. 6) No, annotations don't solve everything. 7) Follow the best practices of the framework. 8) Stop writing business logic in "view" code. 9) Learn how to use filters effectively.

>>3501 It's already well established... it's actually old as fuarrrk. It's also big, and really complicated, and not great for beginners imho. >>3511 Write something relevant to your target employment situation. Wanna work for a bank? Write a trading platform. Wanna work for Google? Write some misinformed machine learning soykaf. >>3513 He'll learn more making something from scratch. >>3531 Man. No. Unless you are already super confident with FP, I would steer clear of clojure. Clojure makes Haskel look minimalist. Nobody understand clojure. >>3544 Nah, you can get away with misunderstanding the JVM for decades. And the whole point it exists is so you don't have to understand it. You'll fight me on that point, I imagine, but you can write a lot of Java without understanding the JVM.

>>3949 >Please god don't write those OOP factory object puzzles every Indian contractor since 1998 has loved This phenomenon exists because Java is an inadequate language. While it's true that factories are boilerplate, it's also true that not using factories reduces the flexibility of your code. Factories allow you to abstract away constructors, an inflexible feature of the Java language. They allow you to change the concrete class being constructed by new without changing code that uses the factory. This author provides interesting analysis on the matter: http://journal.stuffwithstuff.com/2010/09/18/futureproofing-uniform-access-and-masquerades/ >The author painted himself into a corner by not futureproofing: he was calling a constructor directly but now needed it to construct a different class. >Worse, the callsite was outside of code he had control over. >Meyer’s idea of uniform access to fields is really a small piece of a larger idea: Can users define their own abstractions that are syntactically identical to built-in behavior? >Can we swap out default language-provided behavior with our own logic without having to change the calling convention? >Unfortunately, this is a case where the answer is “no.” >In all of the dominant static OOP languages, calling new will always return an instance of a fixed class. >There’s no way to replace it with our own logic. >We’re stuck with factories. http://journal.stuffwithstuff.com/2010/10/21/the-language-i-wish-go-was/ >Uniform access talks just about properties but I consider that part of a much larger question: “Can I replace built-in functionality with a user-defined abstraction without having to change each callsite?” >Wherever the answer is “no”, you find boilerplate. >For example, in most languages a constructor call must always return the named type henceforth and forever. >To get around that, you see people hide them behind abstract factories or factory methods. He also explains how Go was designed similarly to Java in this regard. http://journal.stuffwithstuff.com/2010/12/14/the-trouble-with-constructors/ Factories are a much hated and ridiculed pattern; insight about why they occurred to begin with and turned into the best practice helps design better languages that don't have the same problems Java has. >>3950 >you can get away with misunderstanding the JVM for decades >you can write a lot of Java without understanding the JVM. I don't dispute that. Way too many programmers never even read the great Java tutorials written by the Sun/Oracle people. They learn Java through their school or some course. Only a select few will ever read the Java specification. Even fewer will ever understand what the JVM even does or try to interface with it directly. My point is Java isn't actually the star here; the JVM is. Focusing on the JVM allows you to transcend Java. There are too many languages implemented on top of it that can trivially interoperate with well used and tested Java code; that's a recipe for success right there.

>>3959 > because Java is an inadequate language Java is a fair language. It's an easy version of C++. When programming in C++ you have a huge mental overhead because every time you need to reason about pointer/reference/value, stack/heap, and doing garbage collection manually, Java keeps things straightforward and has a nicer grammar than C++ (try to combine friend classes and templates, for instance). Java operates at the same level of C++, losing a bit of its raw bare metal power, while offering some flexibility that C++ doesn't provide (reflection), with a cleaner syntax. However, great power demands great responsibility, and the inverse is true, that's the reason that Java is like kicking dead whales down the beach for games (due it's inability to explicitly manage memory allocation) and C++ is perfect for this task (and Rust too, maybe). Flexibility doesn't come for free. If you try to reduce the necessity of using design patterns by enriching the language, you have to sacrifice something. Groovy operates on the same level of Ruby, and that's why its performance is like kicking dead whales down the beach. Scala went in another direction and offers a lot of flexibility without sacrificing performance, but at the expense of putting a lot of load on the compiler. Scala's compiler is a monstrosity, and the usage of all that sexy stuff like case classes and the powerful type inference system will be paid at compile time.

>>3961 >Java is a fair language. It's an easy version of C++. ... Java operates at the same level of C++, Java offers 1 method of abstraction - Classes. You need to design your whole code around that single concept. I think that's what >>3959 meant by "inadequate". C++ offers multiple ways to solve the same problem, letting the user choose what is best. Java is to C++ what Python is to Perl. They are not comparable at all. >losing a bit of its raw bare metal power, >a bit lol

>>3962 >I think that's what >>3959 meant by "inadequate". Do you think so? I thought he was stating that mantra: "languages that need design patterns are broken", which I strongly disagree. Are Java, C, and C++ broken? I don't think so. Every time that some rubyst repeat this mantra I got sick. Ruby can do amazing feats with its language constructs, but its performance is horrible. >lol JVM's JIT is the most advanced JIT compile on Earth, and Java's performance is reasonable. You know, they made Apache Spark on top of it, using Scala. Scala operates on the same performance level than Java because it's statically compiled, and its compiler it's a behemoth as I mentioned before. Would Groovy, Python (pure Python) or Ruby be adequate for this task? Obviously not.

>>3961 I have zero problems reasoning about values, pointers, references and stacks. Java also contains those elements: primitive types like int exist; every object is effectively a pointer, nullable even; I've yet to learn a language that does not have a stack. These things are fundamental building blocks present in pretty much every single programming language out there. If someone has trouble grasping pointers, they won't understand Java's object references either. Have you seen the silly debates over whether Java is pass-by-value or pass-by-reference? It's a symptom of inadequate education. Java does not free you from resource management either. Memory is garbage collected, but memory is not the only resource you can acquire. There are also files, network sockets, database connections, threads of execution, pretty much anything related to the operating system or something equally non-trivial. You will be manually managing those resources. You will be writing finally blocks that ensure files are closed before your method returns. People tried to tie the resource's lifetime to the object's lifetime with finalizers and it didn't work so well. Turns out Java is not so different from everyone else. Java does not operate and will never operate at the same level as C++. Java is designed to be compiled to its own instruction set and run virtualized on top of the JVM. C++ targets actual hardware architectures. >>3962 By "inadequate" I meant the language had flaws that led to undesirable boilerplate code becoming best practice. The flaw I was talking about is the fact constructors can only return objects of one type. People can't change the constructor implementation to return a subtype or something. So they create generic interfaces and return concrete objects that implement those interfaces from factory methods; that way they can change the actual type of the constructed object whenever they want without breaking users of their library. Better object-oriented languages like Smalltalk and Ruby are immune to this. You can simply redefine the new method of a class so that it returns whatever you want to return. Can't redefine new in Java. Ruby for one also doesn't require interfaces, for it is duck typed. Even if it had interfaces, there would have been no need for things like singleton classes. In Java, singletons are needed because classes cannot implement interfaces. In Ruby, classes are objects. >C++ offers multiple ways to solve the same problem, letting the user choose what is best. The language may offer you many ways to solve problems. However, the authors of libraries will inevitably pick one of them, and it will be forced upon you. If that approach proves to be insufficiently flexible down the road for the library's maintainers, you can bet they will come up with a bunch of "best practices". >>3966 >languages that need design patterns are broken What I actually said is the "factory classes" pattern probably arose as a way to get around one specific limitation of the Java language. Java is obviously not broken. It clearly works, has a quality implementation and is able to support projects of huge sizes. It's undeniable though that the mere existence of something like factories are symptoms of something bigger. It's not specific to Java either; C++ also has it, C# also has it. Even Javascript sometimes displays this symptom. Why? Because as languages they have the same flaws. Doesn't mean they're all worthless language. It means we can learn from those mistakes and avoid repeating them in the future. It means Java might even be able to mitigate them in future versions; Java has gotten a lot more pleasant in versions 8 and above. >Every time that some rubyst repeat this mantra I got sick. Ruby can do amazing feats with its language constructs, but its performance is horrible. I'm talking about languages, you're talking about the quality of their implementations. Don't dismiss dynamic languages. The JVM's lineage can be traced back to the Self VM, an implementation of a dynamic prototype-based language. Tracing JIT compilers are dynamic language technology. It's ironic how Java, one of the most static languages available, got much of its performance enhancements when the JVM adopted technology that analyzed code at runtime and aggressively optimized "hot spots" in the code. The same people who worked on these beautiful systems have gone on to work on Javascript virtual machines. I don't think there's any doubt that eventually Javascript will match every other major language out there as far as quality of implementation is concerned. There are enormous amounts of money backing Javascript implementations right now.

>>3967 >I have zero problems reasoning about values, pointers, references and stacks. You dude should be an awesome programmer. Every time that I try to program in C++, such decisions (should I allocate this on heap or stack, should I use reference or pointer, etc.) drains my mental energy. The grammar is also very cumbersome, specially when dealing with templates. I have nothing but respect to C++ programmers. But I see Java as a "easy mode" C++. After all it was the main language that inspired James Gosling when creating Java, many design decisions were made taking C++ into consideration. You are an educated person and every claim you make is supported by a solid argument. I apologize for comparing you to the fuarrrking Ruby fanboys that see Ruby as a silver bullet. And I learnt a lot with your explanation. Thank you, sir.

>>3959 >My point is Java isn't actually the star here; the JVM is. Focusing on the JVM allows you to transcend Java. There are too many languages implemented on top of it that can trivially interoperate with well used and tested Java code; that's a recipe for success right there. I wont dispute that, but I think the majority of people who might write Java wont be given the opportunity to use an alternative JVM language. That Legacy lockin tho. >While it's true that factories are boilerplate, it's also true that not using factories reduces the flexibility of your code. Factories allow you to abstract away constructors, an inflexible feature of the Java language. They allow you to change the concrete class being constructed by new without changing code that uses the factory. Of course, that's the rationale for using them, but I think it can be said that people over design the living fuarrrk out of Java programs. You see the factory pattern pop up in situations where the class instantiations are unlikely to ever change. dbConnectionFactory - hmm, must be all kinds of ways to instantiate a db connection underneath that right? No it just talks to an Oracle DB2 instance in a single, vanilla way. Guess we need to future proof our perpetual reliance on DB2. >Java is a fair language. It's an easy version of C++. Actually you see the factory nonsense in C++ too - and worse, once people can make pointer puzzles. And then people figure out they throw in some C idioms there too. See this member is actually a struct of function pointers >.< >losing a bit of its raw bare metal power, Yeeeeah. Just being able to fully control reference vs. value semantics let's speed things up way more than a bit. >Are Java, C, and C++ broken? I don't think so. All languages are broken. Most programmers in those languages write horrible code. > Ruby can do amazing feats with its language constructs, but its performance is horrible. C++ is my favorite language, and I'm not afraid to admit it's about as easy to use as an angry pit viper, and about as safe. >Better object-oriented languages like Smalltalk and Ruby are immune to this. You can simply redefine the new method of a class so that it returns whatever you want to return. Can't redefine new in Java. To be fair, Smalltalk and Ruby suffer from their own OOP puzzles in this manner. Sans factories, but people find a way to squeeze in too much indirection. >It's undeniable though that the mere existence of something like factories are symptoms of something bigger. It's mostly because people who should be building tool sheds build cathedrals. >You dude should be an awesome programmer. Every time that I try to program in C++, such decisions (should I allocate this on heap or stack, should I use reference or pointer, etc.) drains my mental energy. Use the stack unless you can't use the stack. Pass by value when you can afford to. Doesn't use a template till you have to. What's so draining about that?

>>3968 >drains my mental energy This is why I like studying the implementations of languages. It really clears up these mists of cargo cult that most programmers parrot. >should I allocate this on heap or stack >should I use reference or pointer When your function returns, the stack will unwind back to the region where the function was originally called. Technically, the data is still there on the stack immediately afterwards. However, as the program continues to execute, new data is likely to be allocated on top of it, destroying the old contents and replacing them with new data. Allocating on the stack therefore ties the object's lifetime to the scope of the function. Stack allocation is just decrementing a pointer by the size of the object; less flexible but extremely fast. This is the reason why functions that return pointers to stack-allocated variables are incorrect; they are likely to point to locations in memory that have been clobbered by the programming language's own stack allocation mechanism. If the variable's type is complex, this new data is unlikely to match the object's structure, producing a corrupted object. Results are unpredictable; undefined. It's also notable that the stack size is determined by the operating system. If I remember correctly Linux uses 8 MB for process stacks by default and this can be configured on a per-process basis to something as low as 16 KB. Threads are actually processes on Linux, so these limitations apply to them too. The overhead of execution stacks directly influences how many parallel processes you can have running on your system: the smaller the stacks, the more threads you can have executing simultaneously. What is known as a "heap" is more often than not just a linked list of memory blocks managed by a memory management library such as the C standard library. It is completely independent of the execution stack. When there are no free blocks, it asks the operating system to map big chunks into the virtual address space of the process. It then cuts those blocks up into smaller chunks and adds them to the free blocks list. When you ask for memory, it gives you one of those blocks that matches the size you asked for. When you free memory, it adds your block to its list of free blocks; later it may get used again. If there are too many free blocks, it may ask the operating system to unmap them; if there are too few, it may ask it to map more blocks. If there are two adjacent free blocks, it may merge them into a single big block. So stack allocations are fast but are intertwined with the program's execution. Dynamic memory allocation is more expensive and involves heavy wizardry behind the scenes, what with all the linked lists and system calls, but it pays off: you can have memory that outlives functions. Another conclusion is that stacks may be limited in size. Don't allocate a 3 megabyte image on the stack; use dynamic memory allocation instead. If you're willing to interface directly with your operating system, there are even better approaches such as memory-mapped I/O. Also, since you shouldn't allocate big things on the stack, you shouldn't pass those things by value either. You'll be dynamically allocating memory to those structures and passing around pointers to the memory by value. Pointers are essentially a number, a processor word, they fit in a register. They are among the most natural data types known to the computer. Before C, there was the language B and it had only one data type, the word, which worked as both the pointer type and the integer type, nothing else was really necessary. So when you pass pointers around it's really just a number that symbolizes the huge memory block that was dynamically allocated. Not completely unlike variables in Java, or symbols in Lisp. >The grammar is also very cumbersome, specially when dealing with templates I agree. I don't envy the people who write and maintain C++ compilers. I have no idea how it's even possible to parse that language. >But I see Java as a "easy mode" C++ C++ has every language feature Stroustrup has ever heard of and then some. Java is a simpler language. By removing features, the language becomes much easier to understand. It's easier to form a mental model of it. I don't fully understand C++ even though it was the first language I ever learned; don't think I will ever fully understand it either. >I apologize for comparing you to the fuarrrking Ruby fanboys that see Ruby as a silver bullet. The hipster fanboys have thankfully migrated to Javascript. Ruby is becoming a more mature language. Read the timeless classic Smalltalk-80 book if you want to see what a dead serious object-oriented language looks like.

I got the anon's point. Factory methods can pollute the code, but they are a necessary evil in some cases. Consider, for instance, using the Java Persistence API: (1) EntityManagerFactory emfactory = Persistence.createEntityManagerFactory( "Eclipselink_JPA" ); EntityManager entitymanager = emfactory.createEntityManager( ); If it isn't a boilerplate code, I dunno what is. You have a factory method creating a factory object for creating an EntityManager. It would be way more convenient to create an EntityManager with: (2) EntityManager emfactory = new org.eclipselink.EntityManager(<params>); , however, JPA is only the API specification, the implementation comes from a provider such as EclipseLink or Hibernate. If you write code like in (2), you create coupling between your implementation and EclipseLink implementation. If EclipseLink's team decide to refactor this class, you are screwed, your code will break; By following the code style of (2), the implementation code can change whatever it wants, providing that it conforms to the API specification. You can even put the string that represents the provider in a configuration file to be read at startup time. Unfortunately such boilerplate is necessary in Java for achieving this loose coupling, and it would be necessary in C# and C++ as well.

>>3970 >I think it can be said that people over design the living fuarrrk out of Java programs Yes. Nobody wants to be stuck walking on eggshells around their own code but that's what happens when you release a poorly-thought out API to the world. You cannot fix things if the fix involves breaking binary compatibility with code that uses your library. You will have to support it forever. So people have released books like Effective Java, 2nd Edition. These books teach you to be a defensive motherfucker who writes the most obtuse interfaces man can possibly think of. Indirection is good. Opaqueness is good. Everything is private. Everything is a method. No, you cannot clone my god damn object, it's singleton. No, you cannot inherit from my god damned class, it's final. Anything to stop users from unknowingly depending on your implementation details and forcing you to maintain that soykaf forever. Same reason people give you void pointers to opaque structures in C. They do not want you to ever touch the damn thing, not even once in your life. They're reserving their right to change the binary layout of the structure. If you touched it directly, the compiler would generate constant offsets in order to access the structure's fields, and from then on your compiled program would just totally break if they changed the layout of the structure such as by adding, removing or reordering fields. When that inevitably happens, what do you do? You go to their issue tracker cry about it and now they have to revert their hard work because it broke someone's working program. Can't have that, so enjoy those void pointers! >You see the factory pattern pop up in situations where the class instantiations are unlikely to ever change. People are conditioned to be defensive. They learn that the language is inflexible, so they work around it -- by default. It's not a conscious case-by-case evaluation. It's ensuring that 100% of cases get handled. >dbConnectionFactory - hmm, must be all kinds of ways to instantiate a db connection underneath that right? >No it just talks to an Oracle DB2 instance in a single, vanilla way. Guess we need to future proof our perpetual reliance on DB2. That's exactly how people think. That's exactly how I used to think. >Just being able to fully control reference vs. value semantics let's speed things up way more than a bit. Because you can put values on the stack or even in registers. Objects that are explicitly dynamically allocated are harder to optimize. >To be fair, Smalltalk and Ruby suffer from their own OOP puzzles in this manner. Sans factories, but people find a way to squeeze in too much indirection. Got some examples? It's been too long since I last programmed in Ruby. I think I only remember the good parts. I do remember this completely pointless thing: https://ruby-doc.org/stdlib/libdoc/singleton/rdoc/Singleton.html From the standard library no less.

>>3976 >Got some examples? Smalltalk, my go to example is the design of the "Supercollider" DSP / music DSL. Supercollider is technically it's own language, but it's just small talk with some music stuff bolted on. Basically the everything is an object idea means that it's really difficult to see the web of crap that your objects are made of unless you debug your program. And there's not really a good debugger. >ruby My go-to example of over-designed ruby is metasploit framework, though you could find much worse I think. It's slow and harder to read than it should be. I've seen much much worse, just not in public code. Just to give a theoretical example: Ruby programmers like to write lots of decorators. Sometimes the composition of your object isn't determined at runtime. Ruby programmers can make it really hard to figure out what the hell a method does at the time it's being used if they want to.

>>3966 >JVM's JIT is the most advanced JIT compile on Earth...(blah blah blah) You said Java is "a bit" slower than C++. That is incorrect for any sensible definition of "a bit". https://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html

>>3967 You seem to be ignoring the details and implying everything is that same. >I've yet to learn a language that does not have a stack. In Java you cannot interact with the stack in any meaningful way. A Java programmer who does not know what a call stack is is not limited in any way. A C++ programmer who does not understand how the call stack works will definitely get into trouble sooner or later. >If someone has trouble grasping pointers, they won't understand Java's object references either. Again, it's not as simple as that. A C++ programmer can perform arithmetic on pointers to access nearby objects or smaller parts of a data structure, calculate the size of objects in memory etc. Java references are not comparable. >The language may offer you many ways to solve problems. However, the authors of libraries will inevitably pick one of them, and it will be forced upon you. I don't think you are speaking from experience here. Boost::asio for example allows your callbacks to be straight function pointers, lambdas or you can inherit from their base class and implement a virtual function. Error handling is done through error codes or exceptions. It is still the user's choice. >>3968 >You dude should be an awesome programmer. You need to get a better bullsoykaf detector. >>3967 has a lot of shallow opinions he has picked up from programming threads but doesn't display any real world experience.

Read Certificate study books for Java. Certification tests often consist of trick questions that rely on your accute knowledge of how the language works. After that, I suggest programming something for fun that makes use of a lot of different things. Start with a poker game. Or maybe a program that sorts, saves, and displays files. Basically you want to write programs that involve a lot the sort of code you'd be writing for a commercial product. So in the job interview, you can reference it as experience with "this" or "that".

>>3987 Sadly this is one of the best answers in terms of getting a real job.

>>3985 >In Java you cannot interact with the stack in any meaningful way. Just because programmers don't see or touch it doesn't mean Java doesn't have it. Every time you make a method call, it's a new stack frame. >A Java programmer who does not know what a call stack is is not limited in any way. Really? Some exception leaks through the handlers and logs a huge call stack. What are you gonna do? Call a wizard to debug it for you? Stack is a really basic data structure that is pretty much omnipresent. If you think it is acceptable to not have even a basic understand of what a stack is, I don't know what to say to you. >Java references are not comparable. It's true that one cannot do pointer work with Java references. However, both support indirection which is a much more important and pervasive concept. When people say that "references are enough for most cases" they are talking about indirection. >I don't think you are speaking from experience here. I have never used boost myself but have read its documentation and worked with code that uses it. I have direct experience using many other C++ libraries, some of which date back to times where the STL didn't even exist. If you think boost is representative of most C++ libraries out there... Then it is you who lacks experience.

>>4001 >Just because programmers don't see or touch it doesn't mean Java doesn't have it. Every time you make a method call, it's a new stack frame. Yeah but you can't mutate the stack to your will by directly accessing it. #gogogadgetAssembly >Really? Some exception leaks through the handlers and logs a huge call stack. What are you gonna do? Call a wizard to debug it for you? I lot of people who read stack traces don't know what a call stack is >.< >It's true that one cannot do pointer work with Java references. However, both support indirection which is a much more important and pervasive concept. When people say that "references are enough for most cases" they are talking about indirection. Depends on whether you need safety or performance. C++ let's you do both. I think most Java programmers don't realize how often their RAM is expended by needles copying. Someone gave a figure like, the average C++ program takes up 1/2 the ram of the equivalent Java program. This difference limits Java's scope and appeal, especially in embedded systems where memory aint cheap. >I have never used boost myself but have read its documentation and worked with code that uses it. Maybe you are jaded by your experiences? idk man, C++ in the pre-Java world had different use cases. I think it's a nasty language to use for writing the kind of things people like to write in Java. I wouldn't want to write bank software in it. However, if I had to write anything that performs, acts in real time, is responsive, or does anything non-standard with memory, Java just could not cut it, and simply knowing that's an option is an advantage over Java in many case.

>>4002 >Yeah but you can't mutate the stack to your will by directly accessing it I did not claim otherwise. >I lot of people who read stack traces don't know what a call stack is >.< That's unfortunate. Reminds me of my school days. My best friend, upon seeing an error message with a stack trace, would immediately dismiss it without reading a word and bang his head on the screen for hours trying to debug the code. It was cringeworthy to watch >I think most Java programmers don't realize how often their RAM is expended by needles copying Most people don't profile their code to begin with. Evidence-based optimization is a relatively new idea. >Someone gave a figure like, the average C++ program takes up 1/2 the ram of the equivalent Java program. I don't find this to be surprising. The memory allocation patterns of the JVM is different than the pattern produced by C++ with RAII or manual memory management in C. >This difference limits Java's scope and appeal, especially in embedded systems where memory aint cheap. And yet things like Java Micro Edition exist. Java somehow manages to run on smart cards. It's actually pretty interesting. The book I posted in >>3947 talks about it. >Maybe you are jaded by your experiences? Perhaps. I write C nowadays but C++ was the first language I learned; I was 14 at the time. I used some truly monstrous C++ libraries back then. I have also used some pretty OK ones too.

>>4001 Your response makes no sense. You said >>3967 >I have zero problems reasoning about values, pointers, references and stacks. Java also contains those elements: primitive types like int exist; every object is effectively a pointer, nullable even; I've yet to learn a language that does not have a stack. If someone has trouble grasping pointers, they won't understand Java's object references either. I said >>3985 >In Java you cannot interact with the stack in any meaningful way. A Java programmer who does not know what a call stack is is not limited in any way. A C++ programmer who does not understand how the call stack works will definitely get into trouble sooner or later. >Again, it's not as simple as that. A C++ programmer can perform arithmetic on pointers to access nearby objects or smaller parts of a data structure, calculate the size of objects in memory etc. Java references are not comparable. >>4001 >Just because programmers don't see or touch it doesn't mean Java doesn't have it. Seriously how is this at all relevant to the post you are responding to? >Really? Some exception leaks through the handlers and logs a huge call stack. That's called a stack trace not a call stack and that's really not what we are talking about here. >Stack is a really basic data structure that is pretty much omnipresent. If you think it is acceptable to not have even a basic understand of what a stack is, I don't know what to say to you. You keep oversimplifying everything. It's not about stack the data structure. It's about understanding how your program's memory is laid out and how the CPU accesses data from the call stack as your program runs and functions are called. In C++ you need to understand this otherwise you will have segmentation faults. In Java the user does not need to know because it is all hidden. >It's true that one cannot do pointer work with Java references. However, both support indirection which is a much more important and pervasive concept. No. In C++ pointers are a form of indirection because the alternative is using the stack. In Java everything is a reference so understanding what a reference means does not matter. There is no alternative. No consequences for ignorance. >If someone has trouble grasping pointers, they won't understand Java's object references either. Do you understand now why that is bullsoykaf? >I have never used boost A fuarrrking C++ expert who has never used Boost. Stop talking soykaf about a language you obviously know nothing about then.

>>4005 >Most people don't profile their code to begin with. Evidence-based optimization is a relatively new idea. yeah but it's like... a good idea. >I don't find this to be surprising. The memory allocation patterns of the JVM is different than the pattern produced by C++ with RAII or manual memory management in C. It's better. Not different. It has artery clogging levels of over allocation. >And yet things like Java Micro Edition exist And it's so cancer that everything that ever used it is moving away. The soykaf on smart cards doesn't have strings FFS. Embedded Java has about the same appeal for most embedded developers as "infected scrotum" Just look at Dalvik/ART/Whatever Google monstrosity is current. Google had to reimplement everything to make it work and it still.... doesn't always work. >Perhaps. I write C nowadays but C++ was the first language I learned; I was 14 at the time. I used some truly monstrous C++ libraries back then. I have also used some pretty OK ones too. I think you'd like it better now. The bad old days were bad.

>>4011 >In Java the user does not need to know because it is all hidden. Make a recursive function and watch as it overflows the stack. You call this hidden? It is most definitely not. >In Java everything is a reference. Not everything. int is not a reference. Values of primitive types are always copied around; they are passed by value. If you pass an int to a method that expects an Object, the language will autobox the int into an Integer instance and pass a reference to the object instead. This reference might well be an object ID, a memory location, whatever the implementation uses to indirectly refer to the object. The reference itself is passed by value; it works exactly like an int or a pointer, it just happens that the value stands for some object rather than a number. These primitives, including references to objects, are all allocated on the JVM stack by Java bytecode instructions; only the objects themselves are allocated dynamically. >understanding what a reference means does not matter. There is no alternative. No consequences for ignorance. There are plenty of consequences. In Java, objects are always passed by reference. They can be modified outside your code and many times this surprises people. You have clone() semantics for making copies of objects, you have hash codes and equals methods, all because comparing references does not compare objects. The whole reference thing is analogous to pointers. It works in the exact same way as passing pointers to things in C. The fact you can't do pointer arithmetic on references doesn't change anything. Java even has the rather aptly-named NullPointerException. This design has serious implications and if you don't understand them you will be surprised. You're the one who's simplifying things. Java is not this abstract language that hides details like these away from you. It simply swaps out some complicated hardware details with the simpler Java Virtual Machine details. That's why I said learning about the JVM is important. >C++ expert I never claimed to be one. Even if I was some kind of authority on the matter there would be no way to prove it to you without revealing my identity. The fact I haven't used boost implies exactly nothing about my C++ skills. I never used it because I learned new languages and stopped caring about C++. What I have experience with is some of the things boost uses under the hood, like the ICU libraries for Unicode. >>4014 >I think you'd like it better now. Yeah probably. I can see the language's getting a ton of updates.

>>3544 My senior developer of trust laughs at this notion

>>4027 It's pretty typical lainchan trolling for someone to decry the thread and just sage page it into the ground when he doesn't like conclusions of the thread. >>4025 Listen captian sagepost, if you don't like the thread you don't need to reply. >>4017 I think the updates are definitely helping the language, but the big difference is that it is used in a more appropriate context nowadays.

>>4032 What context would you say C++ is appropriate for?

>>4040 Not >>4032 but when C-like speed is required but you need a way to manage genericity and classes would be a decent example. Depending on how you structure your programs, you may be fine with C forever, but there's a point where doing things in C++ can be simpler.

>>4042 Makes sense. Do C++ compilers have a stable ABI nowadays? I remember years ago binaries produced by different compilers used to be incompatible; using C++ libraries was an exercise in frustration for me. It got to the point people exported C APIs to make use of SysV ABI, despite implementing everything in C++.

>>4017 >Make a recursive function and watch as it overflows the stack. You call this hidden? It is most definitely not. That's called a leaky abstraction. >Not everything. int is not a reference. Values of primitive types are always copied around; Ok, I was wrong about Java primitives. But this is only the rule of the language. There is nothing stopped the JVM from passing primitives by reference too. The difference is that C++ pointers/values are artifacts of the underlying hardware, not just an arbitrary language design. >The whole reference thing is analogous to pointers. In the sense that they share the same basic idea. Like how cars are analogues to airplanes because they both carry you from A to B. >You're the one who's simplifying things. Java is not this abstract language that hides details like these away from you. I accuse you of not understanding C++ well enough to have this discussion. You accuse me of not understanding Java well enough to have this discussion? Fine. I don't care. >I never claimed to be one. Even if I was some kind of authority on the matter there would be no way to prove it to you without revealing my identity. My point was that you kick around a lot of opinions you seem to have stolen from other people and don't have the experience to back them up. That's the impression I get from your posts. >The fact I haven't used boost implies exactly nothing about my C++ skills. You made a generalization about C++ libraries but you've never used Boost, the biggest and most used collection of libraries in the ecosystem. That instantly discredits your opinions. >>4032 >Listen captian sagepost, if you don't like the thread you don't need to reply. Many of the sage's are because this thread is supposed to be about Java not C++.

>>4044 1) It's valid to compare C++ to Java for literally dozens of reasons. 2) can we not go around saging? If you don't like the thread you don't have to be in it.

>>4044 >leaky abstraction I don't think so. The JVM is specified to be a stack machine. It's exactly what it says on the tin. >There is nothing stopped the JVM from passing primitives by reference too. It already autoboxes primitives into their corresponding classes. The Java specification even requires that certain ranges of values compare equal with == -- this implies the JVM is required to cache instances of those classes so that the same object is always returned. >The difference is that C++ pointers/values are artifacts of the underlying hardware, not just an arbitrary language design. Indirection mechanisms are fundamental building blocks of computing machines. It doesn't matter if it's a physical machine or a software computer. There will be some kind of mechanism to refer to stuff. Pointers are values. On x86_64 they are 64 bit integers that represent parts of the 64 bit address space available to the processor. Java references are values that uniquely identify an objects within a given JVM process. Lisp implementations resolve symbols with respect to a table that maps them to actual objects; every scope has one such table. >My point was that you kick around a lot of opinions you seem to have stolen from other people and don't have the experience to back them up. I don't know why but you're making a lot of assumptions about me. If you think I'm wrong, explain why. If you don't want to, that's fine too. >That instantly discredits your opinions. Not really. My opinions stand on their own regardless of whether or not I used boost. The other stuff I used was not erased from history the moment boost was created.

>>4053 The mods like seem to enforce "play nice" and I don't think saging is playing nice. Other words we might have to discuss who's arguments are most "on the spectrum." >Indirection mechanisms are fundamental building blocks of computing machines. It doesn't matter if it's a physical machine or a software computer. There will be some kind of mechanism to refer to stuff. No, it just doesn't matter in some situations. Machines are real ya know. Being able to control real memory opens up all kinds of opportunities. Neither are correct in all situations. I wouldn't allow bank software people to write C++ anymore.

>>4054 Fine. The parts of my argument you don't understand or are deliberately ignoring are not worth pursuing. Enjoy your Java thread. >>4063 >Sage is an attempt to kill the thread. Nothing else. I don't think Lainchan has enough traffic for sage to have any realistic effect on a thread's lifetime.

>>3976 Are you really arguing against loose coupling? > No, you cannot inherit from my god damned class, it's final. Every method in Java is virtual by default, the opposite of C++. This harms performance due dynamic binding, but the worst thing is that it encourages the use of inheritance for code reuse. Either document a class for inheritance or prohibits it. If you don't see a reason for people extending your class, put final on it. People will be able to use your code using composition. Using inheritance without a "IS A" relationship causes a lot of pain in the posterior code maintenance.

>>4072 >Are you really arguing against loose coupling? Absolutely not. I do it all the time. Nowadays I do the C void pointers thing. I just think it's stupid how the language provides all these features and people avoid them defensively. Might as well exclude things like public fields from the language. The language should be designed so it does the right thing by default. The right thing is private data with methods to interface with the object. In Java, this means writing amd maintaining lot of boilerplate. In a hypothetical better language, variables and methods use the same syntax and binary interface; accessing a field looks like and behaves the same as calling a method. Both source and binary compatibility are secured by default. This isn't some out of this world notion either: C# has properties; Javascript bolted this feature onto the language.

>>4074 I got your point. But please consider that we are constantly pursuing the "perfect" programming language, but nobody knows exactly what "perfect" is. Scala was supposed to be a "Java killer", it has marvelous features indeed, but it failed in kicking Java's butt in terms of acceptance. Kotlin will also fail, I'm sure of this. Scala's scalability is praised for some programmers, but it's target of heavy criticism from some others. The "zen of Python" is considered by some programs the "right way" for doing programs in every language, but others (including myself) thinks that it's silly pursuing the "only best way to solve a problem". Five years ago it was exciting for me learning a new language every year, but now I'm tired of this. The world has enough programming languages.

>>4087 There is no perfect language. What we can do is observe how people are using the language and try to improve future ones. If people are creating massive webs of indirection via "OOP puzzles" like factories, something's up. There's a problem somewhere that's making all this necessary. Factories allow you to abstract new away, so I can only assume new is the problem. It always returns instances of a concrete type while factory methods can return instances of any type, including abstract classes and interfaces. So it's pretty clear to me that new is too limited for what programmers were trying to use it for. They realized that methods were able to return any type and started using them as a substitute for new -- that's what I think is the origin of factories. I posted some examples of languages that don't exhibit this symptom; turns out they don't need factories because they turned new into a method that could be overridden. new became a method that every class had. Every class was invisibly turned into a factory by the programming language itself and programmers were none the wiser. That's what we can do. There isn't really a perfect language, just slightly better ones than the last. People will find flaws in them as well. Java is an important language despite all it's flaws. Lots of useful code is written in Java. It's not going anywhere anytime soon. >Five years ago it was exciting for me learning a new language every year, but now I'm tired of this. The world has enough programming languages. I have the opposite opinion. I like programming languages more than anything else and have learned way too many

>>4088 >I have the opposite opinion. I like programming languages more than anything else and have learned way too many What I would say is that many of the cooler languages don't have enough software. More people would use Haskell if there was a workable web framework etc... that kind of thing. One of the things that keeps Java relevent is the large corpus of workable libraries.

>>4092 Haskell is quite old. But I'm sick of languages like Kotlin and Elixir. If you want to program to the BEAM virtual machine, use fuarrrking Erlang. Elixir is for pussies. Kotlin is for pussies, too.

>>4094 "Kotlin is a statically-typed programming language that runs on the Java virtual machine and also can be compiled to JavaScript source code or uses the LLVM compiler infrastructure. Its primary development is from a team of JetBrains programmers based in Saint Petersburg, Russia.[2] While the syntax is not compatible with Java, Kotlin is designed to interoperate with Java code and is reliant on Java code from the existing Java Class Library, such as the collections framework." Well, for the OP, this might be something to learn since it's obviously going to be an annoying trend for a while. From what I can tell it commits all the syntactical sins of Java and Javascript and welds them together.

>>4092 Haskell has three web frameworks One of them asked to be removed from the techempower benchmarks because it was something like four times slower than ruby on rails

>>4092 >What I would say is that many of the cooler languages don't have enough software That's why I say the JVM is the real star behind Java. Java isn't really the platform, the JVM is. Implement a language on top of it and you have binary compatibility with vast amounts of Java software. It's like C++ and it's C compatibility. >>4100 That's hilarious. Do they know why it was slow?

>>4105 Idiomatic Haskell is pretty slow, which is a shame because Yesod is one of the coolest web frameworks out there in terms of features and guarantees it can offer. (Ur/Web offers that and then some more, but good luck learning it.)

>>4105 Yeah, but software is kind of a problem. Sooner or later it'll break and you'll be back to writing Java again. And as nice as your code may look, the interface layer will have to take into Java. I've never seen a Scala codebase that didn't have some actual Java floating about. To me, the JVM is not the *star* because being chained to the Java ecosystem is actually a downside. Haskell, and Erlang would not be attractive to me if they had the JVM on their side. Java does have lots of software, but most of it is bloat, and needs to be rewritten. >>4107 Why do you think that is? I'm not an expert on the subject, but from what I've seen Haskell written in the normal way is prone to copying things constantly. I'd be curious to see something like a "machine level" functional language, that gave you full access to pointers and what not, but encouraged a functional style. Although: "I believe one conclusion I've heard some people draw from that is that those benchmarks are actually more about things like JSON parsing/encoding performance than about the web framework. It would certainly be nice to have a well-optimized Snap entry, but I just don't have the time. I imagine that's a large part of it." and "Also the quality of Database bindings. Having seen the yesod benchmark using MySQL it's no wonder it's so slow as the low level MySQL library uses safe ffi calls which block the rts. We should change to postgres there as it supports blocking in ghc Land so it uses the resources more efficiently." (https://www.reddit.com/r/haskell/comments/3wb0zx/what_happened_to_haskell_on_the_web_framework/?st=j8eju9t7&sh=8d06c6b8) It sounds more like "not enough optimizing developers" from what I can see.

>>4108 >Sooner or later it'll break and you'll be back to writing Java again That's fine and unavoidable. Everything being written in one language is a pipe dream; Go people are fond of that idea. For the longest time we've had heterogenous systems written in many languages. For example, a C program consuming a Fortran math/scientific computing library. This is possible because they adhere to a de facto standard ABIs like SysV. Python libraries like numpy are able to use the same Fortran libraries. Jython runs on top of the JVM and can directly interface with Java code. Any process can embed the JVM inside it and talk to the virtualized code running on top of it; instead of calling methods directly through a Java ABI, it can ask the JVM to call methods on its behalf and return the results to the host program. The CLR can do this too. Scheme, Lua and Javascript are designed to be embeddable.

>>4109 >That's fine and unavoidable. Everything being written in one language is a pipe dream; Go people are fond of that idea. For the longest time we've had heterogenous systems written in many languages. For example, a C program consuming a Fortran math/scientific computing library. This is possible because they adhere to a de facto standard ABIs like SysV. Yeah but dude... I'd rather maintain Fortran than Java. It obviates the advantages of the JVM having so much software if you have keep maintaining Java's stifling ecosystem underneath your spiffy new language.

>>4110 Important libraries have developers dedicated to improving them. We can simply use the libraries without having to touch the code ourselves. This is true even when you develop in Java.