[OT] college

[Joakim]

On Sunday, 2 September 2018 at 19:30:58 UTC, Nick Sabalausky 
(Abscissa) wrote:
> On 09/02/2018 05:43 AM, Joakim wrote:
>> Most will be out of business within a decade or two, as online 
>> learning takes their place.
>
> I kinda wish I could agree with that, but schools are too much 
> of a sacred cow to be going anywhere anytime soon. And for that 
> matter, the online ones still have to tackle many of the same 
> challenges anyway, WRT successful and effective teaching.
>
> Really the only difference is "physical classroom vs no 
> physical classroom". Well, that and maybe price, but the 
> community colleges have had the uni's well beat on price for a 
> long time (even manage to do a good job teaching certain 
> things, depending on the instructor), but they haven't made the 
> uni's budge: The best they've been able to do is establish 
> themselves as a supplement to the uni's, where people start out 
> with some of their gen-ed classes at the (comparatively) cheap 
> community colleges for the specific purpose of later 
> transferring to a uni.

That's because what the current online efforts do is simply slap 
the in-class curricula online, whereas what really needs to be 
done is completely change what's taught, away from the incoherent 
mix of theory and Java that basically describes every degree 
(non-CS too), and how it's tested and certified. When that 
happens, the unis will collapse, because online learning will be 
so much better at a fraction of the cost.

As for sacred cows, the newspaper business was one of them, ie 
Journalism, but it's on death's door, as I pointed out in this 
forum years ago:

https://en.m.wikipedia.org/wiki/File:Naa_newspaper_ad_revenue.svg

There are a lot of sacred cows getting butchered by the internet, 
college will be one of the easier ones to get rid of.

On Sunday, 2 September 2018 at 21:07:20 UTC, Nick Sabalausky 
(Abscissa) wrote:
> On 09/01/2018 03:47 PM, Everlast wrote:
>> 
>> It's because programming is done completely wrong. All we do 
>> is program like it's 1952 all wrapped up in a nice box and bow 
>> tie. WE should have tools and a compiler design that all work 
>> interconnected with complete graphical interfaces that aren't 
>> based in the text gui world(an IDE is just a fancy text 
>> editor). I'm talking about 3D code representation using 
>> graphics so projects can be navigated  visually in a dynamic 
>> way and many other things.
>
> There are really two main, but largely independent, aspects to 
> what you're describing: Visual representation, and physical 
> interface:
>
> A. Visual representation:
> -------------------------
>
> By visual representation, I mean "some kind of text, or UML-ish 
> diagrams, or 3D environment, etc".
>
> What's important to keep in mind here is: The *fundamental 
> concepts* involved in programming are inherently abstract, and 
> thus equally applicable to whatever visual representation is 
> used.
>
> If you're going to make a diagram-based or VR-based programming 
> tool, it will still be using the same fundamental concepts that 
> are already established in text-based programming: Imperative 
> loops, conditionals and variables. Functional/declarative 
> immutability, purity and high-order funcs. Encapsulation. 
> Pipelines (like ranges). Etc. And indeed, all GUI based 
> programming tools have worked this way. Because how *else* are 
> they going to work?
>
> If what you're really looking for is something that replaces or 
> transcends all of those existing, fundamental programming 
> concepts, then what you're *really* looking for is a new 
> fundamental programming concept, not a visual representation. 
> And ance you DO invent a new fundamental programming concept, 
> being abstract, it will again be applicable to a variety of 
> possible visual representations.
>
> That said, it is true some concepts may be more readily 
> amenable to certain visual representations than others. But, at 
> least for all the currently-known concepts, any combination of 
> concept and representation can certainly be made to work.
>
> B. Physical interface:
> ----------------------
>
> By this I mean both actual input devices (keyboards, 
> controllers, pointing devices) and also the mappings from their 
> affordances (ie, what you can do with them: push button x, tilt 
> stick's axis Y, point, move, rotate...) to specific actions 
> taken on the visual representation (navigate, modify, etc.)
>
> The mappings, of course, tend to be highly dependant on the 
> visual representation (although, theoretically, they don't 
> strictly HAVE to be). The devices themselves, less so: For 
> example, many of us use a pointing device to help us navigate 
> text. Meanwhile, 3D modelers/animators find it's MUCH more 
> efficient to deal with their 3D models and environments by 
> including heavy use of the keyboard in their workflow instead 
> of *just* a mouse and/or wacom alone.
>
> An important point here, is that using a keyboard has a 
> tendency to be much more efficient for a much wider range of 
> interactions than, say, a pointing device, like a mouse or 
> touchscreen. There are some things a mouse or touchscreen is 
> better at (ie, pointing and learning curve), but even on a 
> touchscreen, pointing takes more time than pushing a button and 
> is somewhat less composable with additional actions than, 
> again, pushing/holding a key on a keyboard.
>
> This means that while pointing, and indeed, direct manipulation 
> in general, can be very beneficial in an interface, placing too 
> much reliance on it will actually make the user LESS productive.
>
> The result:
> -----------
>
> For programming to transcend the current text/language model, 
> *without* harming either productivity or programming power (as 
> all attempts so far have done), we will first need to invent 
> entirely new high-level concepts which are simultaneously both 
> simple/high-level enough AND powerful enough to obsolete most 
> of the nitty-gritty lower-level concepts we programmers still 
> need to deal with on a regular basis.
>
> And once we do that, those new super-programming concepts 
> (being the abstract concepts that they inherently are) will 
> still be independent of visual representation. They might 
> finally be sufficiently powerful AND simple that they *CAN* be 
> used productively with graphical non-text-language 
> representation...but they still will not *require* such a 
> graphical representation.
>
> That's why programming is still "stuck" in last century's 
> text-based model: Because it's not actually stuck: It still has 
> significant deal-winning benefits over newer developments. And 
> that's because, even when "newer" does provide improvements, 
> newer still isn't *inherently* superior on *all* counts. That's 
> a fact of life that is easily, and frequently, forgotten in 
> fast-moving domains.

Ironically, you're taking a way too theoretical approach to this. 
;) Simply think of the basic advances a graphical debugger like 
the one in Visual Studio provides and advance that out several 
levels.

For example, one visualization I was talking about on IRC a 
decade ago and which I still haven't seen anybody doing, though I 
haven't really searched for it, is to have a high-level graphical 
visualization of the data flowing through a program. Just as 
dmd/ldc generate timing profile data for D functions by 
instrumenting the function call timings, you could instrument the 
function parameter data too (you're not using globals much, 
right? ;) ) and then record and save the data stream generated by 
some acceptance testing. Then, you periodically run those 
automated acceptance tests and look at the data stream 
differences as a color-coded flow visualization through the 
functions, with the data that stays the same shown as green, 
whereas the data that changed between different versions of the 
software as red. Think of something like a buildbot console, but 
where you could zoom in on different colors till you see the 
actual data stream:

https://ci.chromium.org/p/chromium/g/main/console

You'd then verify that the data differences are what you intend- 
for example, if you refactored a function to change what 
parameters it accepts, the data differences for the same external 
user input may be valid- and either accept the new data stream as 
the baseline or make changes till it's okay. If you refactor your 
code a lot, you could waste time with a lot of useless churn, but 
that's the same problem unit or other tests have with refactoring.

This high-level approach would benefit most average software much 
more than unit testing, as you usually don't care about 
individidual components or hitting all their edge cases. That's 
why most software doesn't use unit tests in the first place.

Note that I'm not saying unit tests are not worthwhile, 
particularly for libraries, only that realistically it'd be 
easier to get programmers to use this high-level view I'm 
outlining than writing a ton of unit tests, much less effort too. 
Ideally, you do both and they complement each other, along with 
integration testing and the rest.

In other words, we don't have to get rid of text representations 
altogether: there's a lot of scope for much better graphical 
visualizations of the textual data or code we're using now. You 
could do everything I just described by modifying the compiler to 
instrument your functions, dumping log files, and running them 
through diff, but that's the kind of low-level approach we're 
stuck with now. Ideally, we'd realize that _certain workflows are 
so common that we need good graphical interfaces for them_ and 
standardize on those, but I think Everlast's point is that's 
happening much slower than it should, which I agree with.

On Sunday, 2 September 2018 at 21:19:38 UTC, Ola Fosheim Grøstad 
wrote:
> So there are a lot of dysfunctional aspects at the very 
> foundation of software development processes in many real world 
> businesses.
>
> I wouldn't expect anything great to come out of this...

One of the root causes of that dysfunction is there's way too 
much software written. Open source has actually helped alleviate 
this, because instead of every embedded or server developer who 
needs an OS kernel convincing management that they should write 
their own, they now have a hard time justifying it when a free, 
OSS kernel like linux is out there, which is why so many of those 
places use linux now. Of course, you'd often like to modify the 
kernel and linux may not be stripped down or modular enough for 
some, but there's always other OSS kernels like Minix or Contiki 
for them.

Software is still in the early stages like the automative 
industry in the US, when there were hundreds of car 
manufacturers, most of them producing as low-quality product as 
software companies now:

https://en.m.wikipedia.org/wiki/Automotive_industry_in_the_United_States

Rather than whittling down to three large manufacturers like the 
US car industry did, open source provides a way for thousands of 
software outfits, individual devs even, to work on commonly used 
code as open source, while still being able to specialize when 
needed, particularly with permissive licenses. So, much of that 
dysfunction will be solved by consolidation, but a completely 
different kind of consolidation than was done for cars, because 
software is completely different than physical goods.