trails through the ecosystem: language sequence
Thinking of how I might design a robust computer science learning thread using today's open source tools. See caveats at the bottom. Python is oft circled as a great first language, but then what? From a practical standpoint, I'd say: leverage your Python to tackle a second OO language: Java (not JavaScript yet). Then leverage your Java, which need not be super polished, to tackle Clojure. That'll be a first LISP-family language and will start to formalize ground covered, making the concepts more clear. Pick up concurrency concepts here. Finally: back to Python i.e. take what you've learned on this circle tour to move into concurrency with Python if you wish, and with new fondness for a LISPish mindset. From here you're ready to branch to whatever your career calls for: more C family? More Apache stuff (Tomcat?). I'd say you've got even going on the language side with this point to start tackling DB world and its SQL/noSQL APIs. In sum: Python first Bridge to Java Tackle concurrency in Clojure (runs on JVM) back to Python, add more layers and polish === DB stuff: SQL + noSQL In between all this comes installation and simple sysadmin devops baby steps i.e. just learning the above interactively will bring an OS shell and perhaps an IDE into focus. Speaking of IDEs, that's a good place to introduce version control, where you can back end your code plane (screens) straight into some repository. Caveats: Note that I'm not talking about theory, not trying to outline general principles, hardware abstractions, parsing / compiling (back to theory of data structures, parse trees etc.). I'm imagining all that as content and/or background, while the above simply tracks an evolving skills set in terms of language and exposure to specific APIs. An alternative would be a more traditional LAMP stack approach, which still works as a thumbnail guide: L -- OS level on down to hardware A -- All lower level server processes e.g. httpd M -- Persistence Layer (keeping / updating state) P -- Application layer (hosted processes e.g. PHP's) i.e. it remains useful to break it down that way. Kirby
I'd say you've got even going on the language side with this point to start tackling DB world and its SQL/noSQL APIs.
"...got enough going"... Influential on this little essay was OSCON 2015, just finished. The big takeaway for me was big enterprises have finally bought in to the open source paradigm not just as an inventory of free tools but as a style of working that produces results. Management is retraining to make the internal development environment look almost the same as the public open source development world (same tools, same techniques, same small "two pizza teams" with committed committers). Instituting these practices, including sharing and maintaining one or more open source projects, as a way of throwing one's hat in the ring, is not just a way of improving inhouse productivity but of way attracting a productive brand of geek, the kind used to working with these tools to begin with. So we had Walmart Labs (first time), standardizing on Node.js + a lot of noSQL (e.g. Cassandra and Mongo), and PayPal (again), which is all about Apache Inside (talking the whole ecosystem of Apache Foundation projects, a lot of them ever more mission critical within the enterprise). PayPal calls in "InnerSource" i.e. using Open Source internally. Pictures: https://www.flickr.com/photos/kirbyurner/albums/72157653861631353/page1 Kirby
In sum:
Python first Bridge to Java Tackle concurrency in Clojure (runs on JVM) back to Python, add more layers and polish === DB stuff: SQL + noSQL
On Sun, Jul 26, 2015 at 1:36 PM, kirby urner <kirby.urner@gmail.com> wrote:
I'd say: leverage your Python to tackle a second OO language: Java (not JavaScript yet). Then leverage your Java, which need not be super polished, to tackle Clojure. That'll be a first LISP-family language and will start to formalize ground covered, making the concepts more clear. Pick up concurrency concepts here.
I think there are a lot of good paths, and I see the logic of what you propose. But as someone who uses both Clojure and Python, I'd like to remind you that Clojure introduces far more novelty than just the concurrency constructs. The biggest difference is that all the fundamental data structures are immutable, which lends itself to a rather elegant programming style that in most languages is only available for numbers and maybe strings. Once you embrace this, it really changes the way you code, and going back to a programming language that doesn't support immutable data well can feel painful.
Finally: back to Python i.e. take what you've learned on this circle tour to move into concurrency with Python if you wish, and with new fondness for a LISPish mindset.
Yeah, as I point out above, in my experience most students don't want to go back to Python once they've embraced Clojure's way of doing things, because they can't employ those techniques well in Python. Also, Clojure is fairly opinionated about being anti-OO (at least, in the sense of the way people usually think about OO). So once you've drunk that Koolade, OO starts to feel kind of clunky and limiting as a way to organize programs. But that's probably a good thing. Even among mainstream programmers, OO is "on the way out", getting replaced by things like component entity systems, inheritance-less interfaces, traits, multimethods, etc.
Python first Bridge to Java Tackle concurrency in Clojure (runs on JVM) back to Python, add more layers and polish
Right. My path for students looks more like: Racket first Bridge to Python and/or Java as a way to understand mainstream languages and paradigms and gain the ability to interact with the vast majority of code out there. With these three languages under their belt, they can probably read and write code in most languages reasonably well. Clojure as a language that fuses this all together: functional goodness similar to, and in some respects better than Racket, interoperation with Java and Javascript ecosystems. Other languages worth "dipping one's toe into" could be: C++ for low-level programming Javascript for mainstream client-side web programming Haskell for pure functional Scala for a functional/OO hybrid with an intricate type system and a robust dataflow ML to understand the style of pattern matching over abstract data types
Other languages worth "dipping one's toe into" could be:
C++ for low-level programming Javascript for mainstream client-side web programming Haskell for pure functional Scala for a functional/OO hybrid with an intricate type system and a robust dataflow ML to understand the style of pattern matching over abstract data types
The paths you describe look excellent. I am in the low foothills of Clojure at the moment. Here's a blog about my first published Clojure program: http://controlroom.blogspot.com/2015/07/ramping-up.html The Clojure programmers on the Google Group are already telling me ways to refactor. Thanks for your insights. Next I have more followup based on my experiences at OSCON this year. edu-sig seems an appropriate venue. Kirby
In sum:
Python first Bridge to Java Tackle concurrency in Clojure (runs on JVM) back to Python, add more layers and polish === DB stuff: SQL + noSQL
I've continued to refine this model and have distilled what I consider vital content to three tracks: 1. Python -> Java -> Clojure (in that order) 2. XML / HTML / CSS / DOM -> JavaScript 3. SQL -> noSQL with an emphasis on: 1. Graphics 2D & 3D (Turtle / Tractor) 2. Server side Web Frameworks (e.g. Flask) 3. Data Wrangling (includes visualizations) Then the next question is how to provide a unified Ux i.e. we don't want to keep switching learning environments (OSs & IDEs). I've been seeking advice on the Clojure list regarding IDEs of choice, having proposed a candidate that also works for the others. I'm not billing this as a CS degree course given I'm already operating in the dot com, not dot edu domain. These would be certificate series, same as usual. The design is purposeful about getting to JavaScript on the server, not just in the browser. That's our jumping off point to Node.js which might be tacked on to the JavaScript track. https://nodejs.org/ In a next iteration of an on-line school, I'm assuming students each get an EC2 instance on AWS. That's not the blueprint we're currently using at my workplace, but the intent is the same: provide students with a way to engage with the material *without* having to download a lot of stuff to their own devices. The Ubuntu desktop stays in the cloud, playing the role we use Windows for today, with Eclipse for an IDE. In terms of marketing, yes I'm looking at grades 10 - 16 i.e. we can start up with Python, a little SQL, a little HTML / CSS in high school, in conjunction with everyday mathematics and other STEM topics. Accelerated high schoolers already take college level courses and sometimes gain early college admission. Individual locales can decide what credit applies. In Michigan, high schoolers get to take on-line courses in proctored settings known as Nexus Academies. However, we would expect the bulk of our students to have already completed high school before tackling something like Java then Clojure. But just because we help students meet local requirements in grades 10 - 16 doesn't preclude a more general many-walks-of-life population from diving in. Most our students today have been adults. Outreach to high schoolers is still a new idea and some bureaucratic wheels might need to turn before that's feasible (for any dot com certificate series school, not just ours). I expect many on-line schools to be tossing a hat in that ring, regardless of what we do or don't do. Distance learning is still in its infancy and there's room for many brands of pioneer. Kirby
L -- OS level on down to hardware A -- All lower level server processes e.g. httpd M -- Persistence Layer (keeping / updating state) P -- Application layer (hosted processes e.g. PHP's)
i.e. it remains useful to break it down that way.
participants (2)
-
kirby urner -
Mark Engelberg