Win a copy of Zero to AI - A non-technical, hype-free guide to prospering in the AI era this week in the Artificial Intelligence and Machine Learning forum!

Christopher Webster

Greenhorn
+ Follow
since Sep 13, 2020
Cows and Likes
Cows
Total received
3
In last 30 days
3
Total given
0
Likes
Total received
6
Received in last 30 days
3
Total given
18
Given in last 30 days
12
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christopher Webster

This is a classic question, but I often find it helps to think about practical examples.

  • A framework would be something like Java Enterprise Edition, or Spring, where pretty much all your code is tightly coupled to the framework, because you are coding to the framework's requirements and it calls your code (as Campbell points out).  You cannot easily swap one framework for another e.g. from JEE to Spring - without a lot of re-writing.  And often you can't mix two different frameworks together without a world of pain.
  • A library is something that you call from your code e.g. a Maths or DateTime library or a JSON parser etc, where it's easy to swap one for another, and all you have to change is the specific call to the library function because the library does not affect the rest of your code.  You can also mix and match different libraries for different things.


  • I think JEE and Spring have both evolved over the years to allow greater flexibility in how you use their frameworks (indeed, Spring was invented as a deliberate effort to avoid the complexity and tight coupling of J2EE), but you still end up with a lot of coupling between your application and the framework, whichever one you use.

    Meanwhile, web development seems to be full of frameworks too, which seems like a nice money-making exercise for some folks...
    2 days ago
    Yeah, if I were interested in working with Java I'd probably have to actually go and RTFM on Streams and Lambdas and stuff!    

    I like the two sets solution - it's nice and clear what's happening and it does the job with a minimum of boilerplate.  
    2 days ago
    Interesting points, Tim.  

    My own experience with Java started in 1996, when the JDK offered what seemed to me like a minimal set of functionality and I struggled to think of anything I could usefully do with it. Maybe a failure of imagination on my part, but it certainly felt like a bare-bones language to me at least. OTOH it was a heck of a lot easier to get started with than C...

    I started with Python later in its life-cycle, when the "batteries included"philosophy already felt like a core element of the language and it certainly felt a lot richer than core Java did, but I guess I missed the pre-history here.

    I think Campbell's point about object equality also relates to C's legacy, the idea that we would care more about whether an object reference refers to the same location than whether two instances of Person contain the same attribute values.  Another reason why I prefer Scala and its nice friendly case classes!
    2 days ago
    There's a lot of history behind Java now - 25 years or more - so things have evolved a great deal, as Tim points out.

    Also, there are key philosophical differences in how different language communities treat these questions.

  • Python was always intended as a "batteries included" language, with a comprehensive set of standard functions implemented (mostly) in a consistent  "Pythonic" style. The idea is that people should be able to pick up Python quickly and starting achieving their goals as quickly as possible.
  • Scala was also largely intended to provide a lot of functionality in the standard libraries (especially the Collections), although the Scala community has at times resisted the full "batteries included" approach. Scala is also a "big" language with a complex type system, which adds to the challenge of getting started with Scala (although you can just ignore a lot of the fancy stuff).
  • Java started out as a very small language (unlike Scala) with a minimal set of libraries (unlike Python) and a tendency to leave it up to individual developers to roll their own functionality for particular purposes.  My experience is that this led to a lot of re-inventing the wheel, multiple competing libraries to do basic things, and glaring gaps and inconsistencies e.g. why did it take 20 years to clean up the mess around dates and times in Java?

  • So it's also a question of what the original goals of the language were and what the community around that language sees as a priority.
    2 days ago
    Well, this post caused me to wonder how I would do this in Java, as I haven't written any Java for about 10 years.  I came up with this, but it looks way too clunky and krufty to be a good solution (IMO):



    I've never worked with the more "functional" stuff in Java (it shows   ), so then I tried Scala, where the Collections functions do most of the work for you, giving me this:


    There have to be better ways of doing this in a functional style, but it was fun playing around, anyway.  
    3 days ago
    There are also different ways to use your threads.  For example, Akka uses very lightweight Actors to distribute work for concurrent "reactive" processing, and is available for Scala or Java.  Kotlin has coroutines, which are similar and built into the language.

    But it still boils down to what you're trying to do, what your resources are, and where you're trying to do it. No free lunches.
    3 days ago
    @Will:

    Spark can run on your laptop reading/writing data to flat-files locally, or it can run in cluster mode on various distributed platforms (HDFS, Hadoop, Kubernetes, Cassandra, ...), as well as being available as a service from major cloud providers like Google (Dataproc), Azure, Amazon.

    So you can learn or experiment with Spark on your laptop, develop code there, then deploy the same code to run on a cluster in the cloud.

    Databricks is the company behind Spark (as well as the proprietary Databricks data platform), so check out their website for tutorials and background info on Spark:

    https://databricks.com/spark/about

    There are also lots of interesting talks - about what you can do with Spark and how people are using it in the real world - available online from the various conferences e.g. https://databricks.com/sparkaisummit/north-america-2020
    As the author hasn't replied, here's my personal take as an occasional user of Spark since around 2014.

    Scala:

    * AFAIK Spark is still written in Scala, which means new features appear in the Scala APIs first.
    * This means the Scala API is usually a bit ahead of the others, and it will never be behind them.
    * Personally, I find Scala is a very natural language for this kind of processing (which is why Spark is based on it), so I am most comfortable with the Scala API.  YMMV of course.

    Python:

    * Python is very widely used with Spark, as it is a much more popular language than Scala generally, and it is often used by data scientists.
    * Python is also a popular choice for people who use interactive notebook interfaces, like Jupyter, with Spark (although you can also use Scala with notebooks these days).
    * But the Python API is usually a little behind the Scala API, and some features are slower/harder to implement in Python than in Scala.
    * So Python is a good choice for data scientists or if you are not concerned about having the very latest API features.

    Java:

    * There is no good reason to use Java with Spark.  
    * Although Java now offers Lambdas etc, it is still really clunky to write good functional code with Java compared to Scala.
    * And Python is a much nicer language for data science and notebooks etc.
    * If you're using Spark, pick a language API that works well with Spark and does the things that Spark does well.




    Another interesting GOTO 2020 talk on why you don't need all that JavaScript:

    Cay Horstmann wrote:...Of course it was tempting to use ScalaJS or Elm, but I figured that this just adds one more thing that can go wrong...



    This brief overview of Rust and Elm from GOTO 2020 makes some interesting observations about Elm in terms of reliability.  As somebody who has never got remotely close to mastering JS, I'm grateful for anything that can help me make fewer errors...

    Junilu Lacar wrote:...The more I think about it the more it makes sense and it will give me a chance to get into a more functional-style of thinking about design...


    Just in case you're still looking at functional Kotlin, this might interest you:

    https://arrow-kt.io/

    It's a set of libraries providing functional voodoo for Kotlin (a bit like Scalaz or Cats in Scala).  I haven't done much with it (yet...), but it does include nice things like Options, which I think are a much better way of dealing with the "billion dollar mistake" than using nullable types.

    I like what I've seen of Kotlin so far, but it sometimes seems like it's "Scala for Java people who don't like functional programming"... YMMV  

    2 weeks ago

    Junilu Lacar wrote:As the older generations of programmers retire or change roles or change careers, there are fewer people to teach all the hard lessons that were learned to the new generations coming in.



    You might find this talk reminds you of the Good Old Days, Junilu!

    -
    2 weeks ago
    Have you considered trying a different language?  It's true that programming is generally a language-agnostic skill i.e. once you have learned to program in one language, you should find it relatively easy to transfer those skills to another language.  But not everybody finds every language as comfortable for them personally.  So it may be that - for you - Java is not the right language to start with.

    I know quite a few people who've started coding via Python, which in many ways is much easier for new programmers to start with, and there are tons of excellent materials available.  Python is also very widely used in the industry so it is not just an academic toy language, but a really useful practical tool.  Several former colleagues learned Python via the Coursera "Python for everybody" course, which they reckoned was really good:

    https://www.coursera.org/specializations/python

    I also like the "Head First" books, which use lots of hands-on exercises, are generally good fun to work with and very well structured. There's a great "Head First Python" book (get the most recent edition, as Python 3 is now the standard so no point looking at Python 2 stuff), as well as "Head First Object Oriented Analysis & Design".  There is also a "Head First Java" book, but the last edition I saw was from 2005, so it is probably too far out of date to use as a practical tutorial now (you don't want to be trying to install a JDK 1.2 compiler in 2020...).

    So it may be that you will find a different language, like Python, or perhaps a different approach, more comfortable in helping you learn the basics and making them stick.

    But whichever approach you choose, you have to practice - programming languages are like natural languages: you learn them by using them, not by reading about them.



    2 weeks ago
    Side topic, I know, but hey, languages are my jam, as the saying goes...

    As Paul points out, "Whom" is an objective case form of "who":

    Direct object (originally accusative) e.g. "Whom did you meet?"
    Indirect object (originally dative) e.g. "To whom did you write?"

    The problem in modern English is that we have very few case distinctions, basically just for pronouns like I/me, he/him, she/her, we/us, they/them. English speakers are not used to analysing grammatical case, so they tend not to recognise that who/whom is a similar pair and don't realise there is a systematic distinction here. As this confusion has been going on for a very long time (English lost most of its grammatical cases centuries ago), most of the time we just use "who" in everyday speech and writing, including common sayings like "It's who you know...".

    But if you look at a related language such as German, where case distinctions between subject (nominative), direct object (accusative) or indirect object (dative) are much more common (every time you use the word for "the"), and are also related to grammatical gender and number, then my experience is that German speakers normally use the German equivalents of who/whom (wer/wen/wem) correctly.

    So I guess the real problem is that grammatical case is mostly a deprecated feature in English. A bit like our spelling...  



    3 weeks ago
    A little late to this discussion but here's my $0.02...

    I work mostly on database stuff these days, rather than application programming    so my opportunities for doing TDD are limited, and my experience with it is also limited.  But I have tried to do TDD on some applications (using Python, Scala, Kotlin) and although I certainly didn't do it thoroughly (mostly just unit tests), I found it really useful in helping me to factor out the key functionality and making sure these bits worked reliably.  

    It's especially useful if you're working in a more functional programming style, because your functions are typically fairly small, mostly without complex side effects, and ideally re-usable. Ensuring these are testable (and tested) right from the outset means you know you can rely on these building blocks as you build up your application.

    The other massive benefit is when you make changes to your code: you can fire off the tests and within a couple of minutes you'll find the unexpected consequences of your changes being displayed as errors by your testing tools.  What's not to like?

    So I'm no export on TDD, just another grunt developer who's tried at least some of the techniques in the real world, and I'm definitely keen to adopt TDD more consistently and thoroughly when I get the opportunity to do so.

    As for the "money-making" question, I think that's a total red herring.  TDD tools are free and open-source, usually well documented for free online, so there are no costs if you want to try it out.  If the people who come up with these tools and the great ideas behind them can make a few dollars by selling useful books on the subject (and there are plenty of these on the market - like this one), then good luck to them - nobody forces you to buy them, and they deserve some reward for their efforts.  You get paid for your work, and so should they.

    So just try it out on a real project and see how it works for you.

    PS: I recently picked up this book which looks like an interesting attempt to teach TDD and other techniques in a more realistic context.  It gets good reviews too. All I need is the time to work through it...  
    1 month ago