Author Topic: Hunchback aka inquisitivemind.  (Read 125849 times)

Offline Glom

  • Saturn
  • ****
  • Posts: 1102
Re: Hunchback aka inquisitivemind.
« Reply #195 on: July 13, 2012, 09:45:39 AM »
We must now know what our Jay thinks of different languages.
HTML
CSS
Javascript
Java
C++
C#
French
Perl
VBA

I have used all of these.  VBA is a mainstay of work based around Excel.  I also shoe horned Java into my workscope and am now exploring it for personal use.  I used HTML and CSS of course for my website and sometimes for some things at work.  Javascript goes with the work stuff though I never used it for my website.  I used C++ at Uni and did some stuff early on in my career using it before I learnt Java.  C# was a brief flirtation.  I used Perl a lot during a particular role at work as it is favoured among a section of the reservoir engineering community.  And Frenchmen appear to be quite common in the subsurface department along with, increasingly, Italians, but I don't know Italian.

Offline Count Zero

  • Mars
  • ***
  • Posts: 380
  • Pad 39A July 14,1969
Re: Hunchback aka inquisitivemind.
« Reply #196 on: July 13, 2012, 10:24:49 AM »
Reading the last page or so, I'm reminded of the scene in "Cinema Paradiso" after the Neopolitan has rebuilt and taken-over the theater.
Previously (in a small subplot), the town priest used to pre-screen the movies and ring a little bell to order the projectionist to cut-out "pornography" (i.e. kissing) to protect the town's morals.  At the grand reopening, the priest watches helplessly as the people watch an unedited movie.  His hands twitch, trying to ring a little bell that is not there.

In my mind, in this thread, the wandering conversation is the kissing, the priest is a visiting BAUT moderator, and the bell is his "close thread" button.   ;D
"What makes one step a giant leap is all the steps before."

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3787
    • Clavius
Re: Hunchback aka inquisitivemind.
« Reply #197 on: July 13, 2012, 03:53:20 PM »
We must now know what our Jay thinks of different languages.

I haven't used all of them, so we might have to suspend the T-shirt rule for this post.

HTML/CSS.  Not really a language as computer scientists would use the term, because it isn't Turing-complete[1].  It's considered a markup language in the sense that it attaches properties to static data in a dynamically invariant way.  As I said, Clavius is hand-coded HTML, without CSS.  So in the sense that someone can build and maintain a reasonably large web site whose source remains human-readable, HTML/CSS is a clear win.

However, as with all things, people can resist trying to "own" it.   Hence one of the shortcomings is the lack of a clear, persistent, enforceable standard for the language, leading to the colossal inability to parse it deterministically across all clients, and the reliance on vendor-specific "extensions" to the language in the grasp for market share.  So while it's elegant in its simplicity and utility, it will likely remain hopelessly polluted until it is deprecated and replaced.

CSS (style sheets) arose from the inevitable compromise between graphic designs and the architects of the worldwide web.  The original intent was that plain text would be acceptable on the web (as was the norm for the bulletin boards it was designed to replace), but the author could add optional "markup" to suggest how an intelligent client could display it more meaningfully.  But within only a few years, this had degenerated into the need to be "pixel-compatible" among Netscape and Internet Explorer.  And efforts to interest professional graphic artists in web content production fell flat until the technology allowed them to practice their art.  "Well, it might display differently in a different browser," got a universal middle finger from artists.  Hence CSS was born in the artistic sense to give content developers more control over the layout engine.  But from the computer-science standpoint, CSS also provides the property of inheritable data classes.  This offers the clear win of having a single point of truth in a data set:  e.g., I'm going to specify the typeface, color, and size of text for things like headings, and subheadings can inherit and use as much of that as they want.  If you change your heading color to robin's egg blue, you only have to change it one place.

The syntax and meaning of CSS statements are clear and mostly self-evident, so CSS would be considered a transparent[2] language.  HTML and CSS are meant to go hand-in-hand, so I lumped them together.

Javascript.  File under "Probably Should Not Exist."  This language was born inside Netscape as the result of internal turmoil over how best to support rich content on the WWW.  The company's master plan was to use Java as the language for the "serious" rich-content engine, and the lighter-weight Javascript as the casual method.  Hence the name, even though the language bears little if any resemblance to Java and is controlled by completely different groups.  Back then, the philosophy was still that everyone should be able to make a basic web page using only simple text editors and hand-written code, even if authoring tools would develop later.

Integrating Java with the web browser proved as practical as integrating an elephant with a Cadillac, so the notoriously buggy and resource-intensive Java never really caught on for rich WWW content.  Further, the decision was made early on that Java rich content would be restricted to "applets" and that it would interact with browser internals only through the plug-in architecture.  This made it difficult to mix rich and static content, such as is now provided in the Document Object Model.  Hence Javascript was lighter, easier to develop in, and better integrated with the page content as the content authors perceived it.  Therefore for all its faults, it fits better what authors were looking for.  And with much use comes the demand for a fuller feature set, which led to an organic and disorderly expansion of the language.

Today Javascript is aimed largely at making a web page seem more like an interactive desktop program.  It's clearly what users want out of the web experience some 20 years after its inception, but the undisciplined approach to expansion exposes a risk.  Everyone wants faster cars, but no one wants to wear seat belts.  So the problem is no so much with Javascript as a language as it is with the architecture that makes something like Javascript necessary.

Java.  One has to carefully distinguish between Java the language and Java the phenomenon.  As a language it leaves much to be desired.  It was designed when object-oriented programming was considered to be the final evolution of computational paradigms.  This would not be so bad if classes weren't the only available aggregation of data and functionality.  Everything is a class in Java, even things that shouldn't be.  Further Java's object model is crippled.  There is no multiple inheritance, leading to notoriously unnavigable class hierarchies that do little more than correct the object model.  There is no guaranteed destruction of objects.  And polymorphism is poorly supported.

One of the things the Java language gets right is introspection, the ability to programmatically inspect and traverse an anonymous data object.  It was one of the first languages to support it and thus one of the first languages to effectively use local/remote transparency[3].  And in contrast to broad failures of its object model, a finer-grained expression of the inheritance it does support makes class hierarchies and roles somewhat clearer.  One can, for example, define an interface and implementation class.

Java the phenomenon bears more attention.  There's good and bad.  Among the good is a vast infrastructure of solid commercial code that can be relatively easily deployed to implement a business computing model.  And at the other end is the emergence of virtual machines compact enough to run on mobile devices; Java's resource requirements were previously legendary.

Foremost among the bad is the personality cult.  Those who use Java a lot often fall under the spell of thinking that because Java is good for some things, it should be used for all things.  This has led to some highly inappropriate uses of Java in contexts system programming and to some frankly anti-engineering activity in companies that rely heavily on software:  Java evangelists persuade the use of Java where it is clearly counterindicated.  Strings in Java are inexcusably mis-implemented.  And then you have the chronically broken interoperability promise:  Java has had 20 years to become a "write once, run everywhere" language, but has suffered for the same length of time from brittle dependency on its runtime environment.

C++.  C++ is three of my favorite languages.  As the first object-oriented language intended for commercial use, it suffers from trying to be everything to everyone simply because no one yet knew what they wanted.  It got the object model right in the sense that not everything has to be an object.  You can write largely unmodified C and have it work also as C++; it's an almost pure superset of its parent language.  And it provides a simple inheritance model that includes multiple inheritance.

The problem with any object-oriented language is how strongly to type it.  C++ typing is based largely on C typing, and that leads to severe problems in polymorphism that C++ could solve only with the unholy kludge of templates.  But in a remarkable turnaround, the Standard Template Library turned that weakness into a strength and gave the language a set of robust built-in data structures.  Only with the advent of the STL does it make sense to write an application in C++.

C#.  I've only used it for a few toy programs.  I see it as a language that tries valiantly to correct many of the flaws in Java.  It's a detail, I know, but I consider one of its major strengths to be first-class support for "get" and "set" methods that can have programmatic content.  Let's say you represent a mechanical pocket feature as a class.  A uniform pocket has a profile, a depth, a draft angle, and a fillet radius.  If you're going to machine the pocket out of aluminum, the fillet radius can't be smaller than your smallest round mill bit.  If you're going to injection-mold it, the draft angle can't be 90 degrees.  C# allows you to assign values to these data members, but allow for code to be called in specific cases to do things like validate the input.  In other languages you have to use the data visibility constructs to restrict access to those data members, and the client program has to know what "setter" method to call.

French.  The Fortran of natural languages -- old as hell, way too many dialects, and impossible to parse.  Further, they seem to have banished all their consonants to Germany.  This would be a usable language if the pronunciation didn't overload to so many written forms, all with different grammatical meanings.  How many ways can you spell "/uh/"?  And how many things can it mean?  Also gets minus points for having its own personality cult.

Perl.  The way it's used today tempts me to file it under "Probably Should Not Exist," but in fact Perl arose as a good idea.  It has just gotten way, way out of hand.  In Unix there is a "shell" program that implements the command-line interface.  The shell gives you a usable (but somewhat syntactically opaque) Turing-complete function set, so that in addition to typing single commands you can write looping and decision constructs and use variables.  Unix also provides a program called awk, named after the initials of its authors, that provides extensive pattern-matching on text, and implements a rule-based approach:  if you recognize this pattern in the input, do this action.  Perl attempts to unify those highly useful functions under one roof.

However, to say that Perl has evolved organically from its roots as the "super" shell to something unholy and despicable is the understatement of the year.  A large amount of very useful code has been written in Perl.  And there is no doubt that it's an extremely powerful language for system programming.  But Perl evangelists don't see why their adage, "There's always more than one way to do it," ends up proliferating all those various ways to do it such that no one is really sure what the code does anymore.  It's hard to write transparent Perl.  Further, the Perl cult has at times lauded code obfuscation, smugly illustrating the most obscure and arcane way to do something as examples of the power of their preferred tool.  As I tell my clients:  "Don't be clever; be clear."  So as a result, "expert" Perl programmers are more apt to write code that no one but they can maintain.  This is rarely commercially viable.  I've seen companies have to throw out hundreds of thousands of lines of Perl because the developer left and none of the other Perl programmers could figure it out because they typically do things one of the other many ways to do it.

Perl's type system is a disorganized mess.  Billed as a weakly-typed language, it instead introduces a new concept of contexts, which is simply an implicit fiasco of type conversions and interpretations that the programmer must learn and obey.  And the same identifiers behave differently in different contexts, which are created in part by different prefix symbols:  $ for scalars, @ for arrays, and % for association lists.  And its storage model is also a disorganized mess.  The runtime system handles memory allocation by means of garbage collection, but the introduction of an anonymous reference data type creates ambiguity in the reference counting, leading to huge memory-leak problems in persistent (i.e., long-running) Perl programs.  In short, in attempting to avoid the problems of static and strong typing and explicit memory handling, Perl has simply duplicated them in a way that makes it harder to debug.

In case it's becoming obvious, I don't admire language evangelism.  I consider it to be counterproductive and childish.

VBA.  Never used it.  With that said, I've used a few dialects of Basic simply because I studied compiler design under Tom Pittman, a principal contributor to Tiny Basic.  It was "mandatory."  Once you strip Basic of line numbers, the resulting structured basic is a highly usable language that is among those surviving the test of time.  I personally have never found the need to program for anything running a modern Microsoft operating system[4].

NOTES

[1]  Computer science pioneer Alan Turing proposed a theoretical model for computation based on a few simple abilities.  These abilities can be extended to programming languages, since a language implies an underlying computational model.  One of them is the ability to execute different program steps based on the value of stored data.  Another is the ability to change the contents of that same stored data.  This results in useful constructs such as decision structures and repetition structures which are deemed essential to any non-trivial computation.

[2]  Transparency is a desirable property of programming languages and the programs written in them that one can look at them and get a reasonably correct idea of what they're trying to do.  For a program to be transparent means that one who knows the syntax of the language can read the code and say, "Oh, I see, it's checking to make sure an account balance has not gone negative."  For a language to be transparent means that the syntax and the semantics are closely related and reasonably self-evident.

[3] Local/Remote transparency is the pattern where two programs running on different computers communicate over a network and exchange data, but the details of that communication are hidden at the application logic level.  So a program may say, "Create a mechanical pocket feature out of this profile curve and some additional information," and obtain a description of the resulting geometry.  But under the hood the program may have packaged up the profile curve and other data, sent to a remote computation server over a network, and obtained the result back over the network.  This naturally requires the two programs to agree on the format of exchanged data.  Programming languages that allow introspection of data objects can write a general function to traverse any object and render it in a form suitable for network transport.  Non-introspective languages such as C++ implement local/remote transparency only with great difficulty; either the data objects have to be specified in a meta-source, or tedious marshalling and unmarshalling functions have to be written manually for each object.

[4] Surprisingly, DOS and Windows 3.x live on as embedded operating systems, even in life-safe applications.  Star Trek: The Experience used Windows 3.1 on its motion-base controller.  Science and engineering have moved in large measure to Linux, which is also the OS of choice in the Internet infrastructure.  The financial market is still based on old IBM operating systems.
"Facts are stubborn things." --John Adams

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3787
    • Clavius
Re: Hunchback aka inquisitivemind.
« Reply #198 on: July 13, 2012, 03:59:26 PM »
NOTABLE OMMISIONS

C.  Probably the single most successful programming language ever.  It's successful because it has a clean syntax, a useful type system, free development tools, an an enormous public library of highly useful functionality.  A vast amount of code continues to be developed in C today.  On the negative side, some people don't get pointers and memory management.  Especially people who only know Java.  Others get it, but rightly argue that it makes it difficult to maintain commercial code in C.  Arguments persist that C is not a high-level language, and this may have some teeth to it.  But the level of abstraction in a language is not the sine qua non of its effectiveness and utility.

Fortran.  Another long-term warhorse, although unlike C it has required several substantial makeovers across the decades in order to remain viable.  C was designed right from the start.  Fortran was created before much work had been done in formal specification of languages.  The reason it's still viable is that for heavy computations it's still the most efficient language.  NASA is still coding in Fortran, although they mandate the modern dialects.  We engineers have several widely-used computational kernels that no one frankly wants to debug again, and they're in Fortran because that was the appropriate language of choice when the need for them arose.  At this point it requires less effort to maintain Fortran compilers than it does to re-implement and retest all these kernels again in a newer language.

Lisp.  Fortran is the Gene Kranz of the programming world.  Lisp is the Bob Dylan of the programming world.  Lisp syntax is predicated on the most elegant and basic element:  the s-expression.  So is its data model.  It was and remains the most accessible example of functional programming, and many other "modern" languages and their programmers could learn many things from Lisp programmers.  For example, why "free variables" are bad.

Unfortunately its simplicity and elegance are its downfall, since the way Lisp is typically written requires help matching up all those parentheses.  One of the language's most powerful constructs, the lambda expression, has found its way into -- of all places -- Perl.  Perl supports a functor-literal.  Lisp isn't very transparent.  Operations such as car and cdr derive from obscure details of its original implementation and aren't immediately evident as list operators.  Reading and writing Lisp requires thinking in the functional-programming paradigm, which is a difficult gear to shift for programmers working in more declarative languages such as C or Java.

PHP.  For better or worse, PHP is the other language that runs the web.  While it retains much of the same syntactic nonsense as Perl, it pares it down to the case where instead of multiple ways to do things, there may be only two ways to do any one thing.  This makes it a cleaner, more commercially viable language.  As with many modern languages, and object-oriented object model has been initially tacked on, and then revised, meaning that at least three distinct code base types exist.  PHP is notorious for security problems on the web, not because the language is insecure but because PHP programs are not written typically to be secure.

XML.  Again, not strictly a programming language but a markup language.  It is widespread in the industry today, and growing.  It attempts to generalize a data structure taxonomy into elements and attributes that are defined by the application such that parsing data streams can be modularized into a syntax-level parser (the XML parser) and an application-level parser (e.g., a financial package reading spreadsheet data).  While billed as both human-readable and machine-readable, most practical applications of XML fail badly at human readability.  Also for most applications there is a 5-to-1 overhead ratio for XML encoding, meaning that the payload occupies only 20 percent of the total volume of data exchanged.

If you understand HTML you'll understand XML because the tagging syntax is nearly identical.  However, if you think that XML is the best way to encode a structured data stream for your application, then I'll bet you dollars to donuts you're wrong.

Pascal/Modula.  This is one of the most amusing tales in the field of computer science -- the story of how the revision to a programming language managed to eliminate everything its predecessor did right while committing new and grave errors.   Pascal was created as a teaching language by Niklaus Wirth, and because students tended to want to program in the languages they learned in college, the language escaped out into industry.  It was ruthlessly strongly typed, and eventually required the "variant record" kludge to implement type-casting.  C quickly took over as the procedural language of choice.  Not to be undermined, Wirth went back to the drawing board and came back with Modula-2, which introduced a pre- object-oriented abstraction, the module.  He also inexplicably required the language's keywords to be in upper case, and eliminated the variant record that got around his sadistic type system (which he retained and further tightened, but to which he added useful intrinsic types).  A great deal of commercial code in the 1980s was written in Pascal, but very little in Modula; it remained solely a teaching language.

COBOL.  If you write COBOL, I will have someone come to your house and punch you in the face.
"Facts are stubborn things." --John Adams

Offline nomuse

  • Jupiter
  • ***
  • Posts: 859
Re: Hunchback aka inquisitivemind.
« Reply #199 on: July 13, 2012, 05:22:04 PM »
The dilemma of design is that the decisions you make early on have the most profound effect on the viability of the end product, but you rarely know enough at the early stages to make informed decisions.


Yup.

If I was still in school, I'd be tempted to write my thesis on how the functional process impacts the artistic process in theater.  We've learned, more or less, how to manage the endemically small budgets, but all designers suffer through having to commit to paper (so the shop can start hammering wood) before critical artistic information is collected.  And there is no going back -- almost never is an opening delayed.  So tech week becomes this wonderful time when what you spent six weeks building doesn't work with the final version of the choreography (or whatever), and you have only hours to come up with a replacement.

I'm there this moment.  The choreography is changed, the set is just delivered and the transitions are completely different, the band is playing in unexpected places, and there are script cuts... and I have something like forty sound cues to revise before tonight's final dress.  And this is "Willie Wonka."  These aren't drop-needle cues, these are ten-hours-per-finished-minute soundscapes.

Offline cjameshuff

  • Mars
  • ***
  • Posts: 372
Re: Hunchback aka inquisitivemind.
« Reply #200 on: July 13, 2012, 05:39:56 PM »
I used HTML and CSS of course for my website and sometimes for some things at work. 

My own opinion: CSS is unnecessarily convoluted, crippled by compromises, and could be vastly improved with a few trivial modifications...like variables and numeric expressions. For example, you can use it to produce a 3 column flexible (resizing to fit your browser window) layout, but it requires stupid amounts of copy and paste, and modifying it requires recomputing values scattered all around the CSS...

In contrast, abusing a table gives you immediate, controllable, reliable results with a fraction of the work, despite being the "wrong" way, using semantic structuring of data (the table) to do layout (which should only concern presentation of data).

(Edit: here's an example of what I'm talking about: http://matthewjamestaylor.com/blog/perfect-3-column.htm)


Javascript goes with the work stuff though I never used it for my website.  I used C++ at Uni and did some stuff early on in my career using it before I learnt Java.

I do most of my non-embedded work in C++. It is at times a terrible language (particularly when templates are involved), but it has many useful features that C lacks, and I often need the performance that can't be had in higher level languages. The advantages of C++ over C apply less to embedded systems...due to memory usage, code size, etc. Embedded systems often don't even have a heap (making the STL rather less useful), and templates can easily generate multiple versions of a piece of code for different types...a powerful feature for desktop programming, and a quick way to eat up flash space for a microcontroller. The stronger typechecking is nice and the OO features provide some benefit with essentially zero overhead when not using virtual functions, but it's very common to just use plain C in embedded systems.

The Java language is not terrible, but is unnecessarily verbose, omitting useful features like operator overloading, and fails to reach its potential as a high level language by trying too hard to look friendly to C/C++ developers, while failing to replace C/C++ due to its heavy VM based runtime. Languages like Objective C, Smalltalk, and Ruby show what Java should have been aiming for. And when I used it, the standard library was awkward to use and full of holes...some containers mysteriously missing functions that others have, one piece of functionality being supported but not the complementary piece of functionality you'd expect to be there, etc...


I used Perl a lot during a particular role at work as it is favoured among a section of the reservoir engineering community.

That's terrifying. I'm of the opinion Perl should be classified as an esoteric language, and not considered for actual use. I honestly do not know why anyone uses it. It's a vast mass of ad-hoc feature additions, bizarre interactions, special cases, special variables, "contexts" that completely change the meaning of code...it has operators that hold state, that don't do the same thing twice in a row. It lacks named arguments for its functions...everything's passed in an array. It has different prefixes for variables of different types...and sometimes you can refer to a variable using the "wrong" prefix to do something special, like referring to an array as a scalar to get its length. And it'll often "helpfully" flatten arrays for you (replacing nested arrays with their contents), making it difficult to create a hierarchical data structure...and so on.

I mentioned Scheme before...it's pretty much Lisp stripped down to the basics and given a clean start, with a reputation for minimalism and academic use that it's starting to grow out of. My implementation of choice is Gauche, a Scheme intended for general purpose scripting, with a BSD license and very easy integration with C/C++ code. Another dialect of Lisp is used by Emacs.

And I have yet to encounter a situation where XML is the best, or even a particularly good solution. It seems to get automatically used by default just because it works and everyone else is using it. It has numerous faults...its tagging structure is CPU intensive to parse and not amenable to multithreaded processing, and horribly redundant. I often see the fact that it compresses well stated to be an advantage...I still haven't figured out how people can think that. (it compresses well because it's an inefficient way of representing data)
« Last Edit: July 13, 2012, 05:50:21 PM by cjameshuff »

Offline Echnaton

  • Saturn
  • ****
  • Posts: 1490
Re: Hunchback aka inquisitivemind.
« Reply #201 on: July 13, 2012, 05:48:29 PM »
COBOL.  If you write COBOL, I will have someone come to your house and punch you in the face.
I wish we'd known each other in 1980.  A good face punch would have been more instructive than learning COBOL on punch cards.
The sun shone, having no alternative, on the nothing new. —Samuel Beckett

Offline DataCable

  • Earth
  • ***
  • Posts: 138
Re: Hunchback aka inquisitivemind.
« Reply #202 on: July 13, 2012, 07:28:32 PM »
A good face punch would have been more instructive than learning COBOL on punch cards.
And less painful?
Bearer of the highly coveted "I Found Venus In 9 Apollo Photos" sweatsocks.

"you data is still open for interpretation, after all a NASA employee might of wipe a booger or dropped a hair on it" - showtime

DataCable2015 A+

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3787
    • Clavius
Re: Hunchback aka inquisitivemind.
« Reply #203 on: July 13, 2012, 09:38:58 PM »
CSS ...like variables and numeric expressions.

That's a very good suggestion.  Any time you can create a "single point of truth" in software, you've improved it.

Quote
...making it difficult to create a hierarchical data structure...and so on.

This is important.  I always advise to understand the shape of your data first.  The algorithms and modules will follow more or less naturally from that.  If you have to compromise on the shape of your data, then you will waste effort manipulating it in awkward ways.

Quote
Another dialect of Lisp is used by Emacs.

...to great advantage.  It's always amusing to hear IDEs and other editors promise to provide "an Emacs interface," when in fact all they provide are the default Emacs key bindings.  They always look funny when I ask where I should install my elisp.  One of the cardinal rules for design (in any domain) is never to promise what you can't deliver.
"Facts are stubborn things." --John Adams

Offline Count Zero

  • Mars
  • ***
  • Posts: 380
  • Pad 39A July 14,1969
Re: Hunchback aka inquisitivemind.
« Reply #204 on: July 13, 2012, 10:33:24 PM »
Forth?
"What makes one step a giant leap is all the steps before."

Offline Glom

  • Saturn
  • ****
  • Posts: 1102
Re: Hunchback aka inquisitivemind.
« Reply #205 on: July 14, 2012, 12:26:30 AM »
I thought variables were supposed to be introduced in CSS 3.

Offline Not Myself

  • Earth
  • ***
  • Posts: 217
  • Unwanted Irritant
Re: Hunchback aka inquisitivemind.
« Reply #206 on: July 14, 2012, 02:41:00 AM »
Since you're casting a wide net, may as well include things like TeX and LaTeX.  And PostScript.  And if you think French is hard to parse - well, I'd put it comfortably in the easier-to-parse half of the natural languages I know.
The internet - where bigfoot is real and the moon landings aren't.

Offline Echnaton

  • Saturn
  • ****
  • Posts: 1490
Re: Hunchback aka inquisitivemind.
« Reply #207 on: July 14, 2012, 07:22:40 AM »
A good face punch would have been more instructive than learning COBOL on punch cards.
And less painful?
Pain is transitory, but a well learned lesson can last a lifetime.
The sun shone, having no alternative, on the nothing new. —Samuel Beckett

Offline Noldi400

  • Jupiter
  • ***
  • Posts: 627
Re: Hunchback aka inquisitivemind.
« Reply #208 on: July 14, 2012, 01:13:01 PM »
Well.

Reading all this, I'm not entirely sure whether to be be relieved or saddened that I drifted out of programming in the early 90s.

I started with an odd little language called TI Basic, then learned Xbase/Clipper with a few forays into RPG II, then into C++; mostly self taught along with a sort of collaberative tutoring from other programmers in the little computer shop where I worked for a couple of years.

That was the period during which id Software boasted that Doom was "the number one cause of decreased productivity in businesses around the world" and we worked hard at supporting this claim. The boss - who was the most avid player of any of us - finally had to forbid play during working hours, which led to a lot of "working late" at our shop.
"The sane understand that human beings are incapable of sustaining conspiracies on a grand scale, because some of our most defining qualities as a species are... a tendency to panic, and an inability to keep our mouths shut." - Dean Koontz

Offline cjameshuff

  • Mars
  • ***
  • Posts: 372
Re: Hunchback aka inquisitivemind.
« Reply #209 on: July 14, 2012, 02:20:07 PM »
I thought variables were supposed to be introduced in CSS 3.

Possibly, I haven't touched CSS 3. Looks like it's a proposal, and there's resistance to the idea...variables are "too complicated" and "confusing" for the poor designers. Somewhat incredibly, some people are arguing that the ability to parameterize a CSS file would reduce reusability...


Forth?

Another language that requires you to pull out your brain and re-seat it sideways. Very simple to build a compiler/interpreter for, rather compact in resulting code size and resource usage, and unfortunately quite easy to write incomprehensible code in.

For a very similar language, look at PostScript. You've probably already got software for running it...if you're on a Mac, Preview.app will automatically produce a PDF, if you're on Linux, you can probably figure out a few options. There's even a partial Javascript/HTML5 implementation: http://logand.com/sw/wps/index.html