101–110 of 131 posts
I recommend reading Exercises in Programming Style by Cristina Lopes as a good starting point.
I know formal education often gets a lot of criticism around HN, but I think the approach the article is talking about is heavily mirrored in most university computer science curriculums. Universities tend to focus on paradigms and patterns, and typically force a student to learn at least 3 languages throughout their education (much more if they want to). Just in my undergrad I learned C, C++, C#, Objective C, Swift,…
Those like myself doing compiler related classes got to additionally explore Forth, Oberon, Oberon-2, Active Oberon, Modula-2, Modula-3, Eiffel, Ada, Concurrent C, Objective-C, *Lisp, Sather, C+@ [1] among a few others I cannot remember now.
As Wirth puts it, it is all about algorithms and data structures, in an abstract way.
[1] - In case you never heard about this obscure relative of C++ at Bell Labs, http://www.drdobbs.com/article/print?articleId=184409085&sit...
1. A great book that covers multiple paradigms of programming is Roy and Haridi's "Concepts, Techniques and Models of Computer Programming" https://mitpress.mit.edu/books/concepts-techniques-and-model... . This stands hand in hand with the better known SICP.
2. Folks in the CS and programming world seem to ignore bleeding edge work being done in the arts space. To get a broader view of languages than "characters that go into a plain text file", expose yourself to the live-ness of the following -
2.ø Smalltalk - one of the first fully available language and runtime that is still usable today.
2.a Max/MSP/Jitter - by David Zicrelli and Millet Pickette's - Visual data flow programming language with decades of dominance in the Computer Music scene.
2.b SuperCollider - for architecture lessons as well as another multi-paradigm language.
2.c Impromptu - a Scheme based live coding environment for music and visuals by Andrew Sorenson. Normal REPLs will bow in front of most "live coding" languages used for music.
2.d Ixilang by Thor Magnusson - another live coding language, where the language is in a sense inseparable from its run time environment. The current running behaviour of a textual program could also depend on how the program evolved.
In short, break out of normal modes of thinking and attain Turing nature, at which point you can proclaim that all languages have Turing nature and yet retain your discriminating view.
I feel we are starting to lose the plot. The problem isn't about learning another language or which to use next. Instead it is about how to solve and represent complex problems and systems in code. Any language is a means to an end, not the end itself. Focusing on languages and language constructs is of value to those in academia and those working solely in the domains of computing and computer science. For the rest,…
I think that learning C before C++ might hurt you. https://www.youtube.com/watch?v=YnWhqhNdYyk
It seemed like the point of the presentation was really that C and C++ should be thought of as totally separate languages. As long as that's remembered, I think the opposite is probably true: knowing C helps a lot to learn C++ (and vice versa) as opposed to learning either from scratch.
Earlier quoted context omitted.
There are three problems with "Don't mandate a programming language" -- I'm a lecturer and I've done it for advanced practicals in later years. * Students expect to be able to get help when they have problems. There is a good chance no member of staff knows Julia / Moonscript / ... * Some languages make tasks trivial -- while this is nice when you are in the real world, if I want to test student's ability to create s…
> Students expect to be able to get help when they have problems. There is a good chance no member of staff knows Julia / Moonscript / ... For this I have two answers. Past the first year people shouldn't be getting help with "my code won't compile". They should be able to develop the skills needed to search that on google and find SOF links. The second answer is a question: Why don't members of staff know "Julia / M…
If the bug is a shallow/algorithmic bug, that's reasonable. Recently I was helping someone debug some javascript code. Eventually, we found the problem was that, in javascript, that [11] > If the student understands how to use the abstraction then they have likely learned something far more valuable. If you're assigning labs that consist of basic idioms that can be whisked away by common library functions then you might consider changing your curriculum to focus more on solving problems rather then codifying solutions.
This I just have to disagree with. I think it's valuable for students to learn how to implement quick sort. It's useful to learn how to implement big-integer arithmetic. It's useful to learn how you can "fake" Java-style inheritance with structs and function pointers, so you really understand what's going on under the hood.
Of course long term, you wouldn't typically implement these things yourself, but understanding the fundamentals is important.
Also, if I set a practical which involves (for example) connecting to a HTTP server, intending them to do the raw connection themselves, and they use a 3 line python program, using the standard library, have they really learnt anything at all?
There certainly is a place for giving students more freedom, particularly in later years. It's clear the modern world is moving into "slap together 50 javascript/python packages with string" type programs (and that's because it's a great way to be productive quickly), which universities don't currently teach that well. But don't throw the baby out with the bathwater!
I've been programming for 20+ years, and recently moved over to Python. Sure, I could code on day one and figure out how to get programs working pretty easily. But the nuances with it are still things I need to work on a lot. I still don't program Pythonicly, I program like a C programmer writing Python. In fact, I probably program in all languages like I would a C programmer, and that's not good enough, in my opinio…
Like you, I'm basically a C programmer at heart. But, to get efficient at some of the Maple code I had to write for my graduate work, I learnt a number of their functional tools so I now think quite a bit about using some of those as part of my toolset. I'm still largely a C-style programmer, though.
Working with the SymPy project helped me in my Python style.
I used to arrogantly think I could be productive in any language given a week or so to adapt. I often used the phrase "a good dev is a good dev in any language." That belief was rather abruptly broken when I joined a project using C++/CX it was so far outside of my previous experience that I had a really bad time of it. I happily picked up the actual language very quickly. It was the surrounding ecosystem of compiler…
During my Master's (and my Ph.D.) I was using a finite element approach developed by a former Ph.D. of my supervisor(s). So, I asked for the code. I got back a mess of C++ and it was dependent on a linear algebra C++ library that wasn't around in the same form. I spent some time trying to reason out what he was trying to do, gave up and wrote my own in Fortran in about as much time as I spent trying to understand his.
A few recommendations on this, since at where I work a talk is organized on this very topic today. 1. A great book that covers multiple paradigms of programming is Roy and Haridi's "Concepts, Techniques and Models of Computer Programming" https://mitpress.mit.edu/books/concepts-techniques-and-model... . This stands hand in hand with the better known SICP. 2. Folks in the CS and programming world seem to ignore bleedi…
Earlier quoted context omitted.
It seemed like the point of the presentation was really that C and C++ should be thought of as totally separate languages. As long as that's remembered, I think the opposite is probably true: knowing C helps a lot to learn C++ (and vice versa) as opposed to learning either from scratch.
This is true, but there's a 'surface simularity' problem. It's easy to go from writing C to writing old-fashioned 'bad' C++. Modern C++ really is a different beast.
True, modern C++ is quite different. But, there's nothing from preventing a C programmer from starting as a "bad" C++ programmer and learning new techniques as they go.