Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How many programming languages, can one reasonably master?

175 views
Skip to first unread message

Ali M

unread,
Feb 9, 2018, 5:54:39 PM2/9/18
to
I think the tcl group, is probably one of the better
places one can ask this question

How many programming languages, can one reasonably master.

tcl was designed from the started to be used with other languages
( https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy )

How many programming languages, do you think one person should target to learn?
How many is too many? And how many is too few?

Personally, I dont think I can master more than many 3 languages
Since I already know Sql, this leaves me with 2 free slots

Thanks
Ali

Rich

unread,
Feb 9, 2018, 6:25:17 PM2/9/18
to
Hard to really say, I guess it depends upon the individual.

My list of "languages learned" in one form or another would include:

Atari Basic
Basic/XL (also on the now anchient Atari)
6502 Assembly
Apple Basic
Apple UCSD Pascal
Turbo Pascal
8088 assembly (more dabbling than anything, but once one learns an
assembly, the others are /not that different/, in most
cases)
A Pascal that ran on a CDC Cyber 7800 who's name I have long forgotten.
Fortran
CDC Cyber 7800 assembly (this one was 'weirder' than most)
Csh
Bash
Perl
Tcl
C

And I've recently dabbled in some Nim and D.

Did I 'master' all of these, no.

Could I write a program in all of them now without reference to docs,
also no.

At various points in time, one or more were my 'go-to's for problem
solving.

But my 'recent' list tracks closely to your count of "three":

Tcl, Bash, C (C only very occasionally, when performance *really*
matters)


But the real reality is that there is the aspect of the abstract
concept of "how to design an algorithm to instruct a computer to
perform a task" which is language independent, and then there is the
"make concrete the abstract algorithm in a particular language".

Once one learns how to do the first ("design algorithm") then
performing the second part (making it concrete) is generally only a
matter of learning the rules of the chosen language rather than
relearning "how to program". So the real part to strive to master is
the "how to design algorithm" part that is language independent. Much
of the rest will just flow along from that knowledge.

Brad Lanam

unread,
Feb 9, 2018, 7:02:54 PM2/9/18
to
Familiarity with the languages other people like and use would be useful.

Since you know SQL, I would choose languages that have the best database
interfaces.

It also depends on what area of expertise you are working towards.

Also mastering both a scripting language and a lower level language (when
you need real speed) would be useful.

I had perl mastered, but not sure how effective I would be with it if
I tried to jump into it again. Right now I can program Bourne Shell, PHP,
C, Tcl/Tk.
(Basic, Fortran, PL/1, Pascal, COBOL, C, PHP, Bourne Shell, Perl, Tcl/Tk)

Gerald Lester

unread,
Feb 9, 2018, 7:03:11 PM2/9/18
to
On 02/09/2018 05:25 PM, Rich wrote:
> Ali M <tclwa...@gmail.com> wrote:
>> I think the tcl group, is probably one of the better
>> places one can ask this question
>>
>> How many programming languages, can one reasonably master.
>>
>> tcl was designed from the started to be used with other languages
>> ( https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy )
>>
>> How many programming languages, do you think one person should target to learn?
>> How many is too many? And how many is too few?
>>
>> Personally, I dont think I can master more than many 3 languages
>> Since I already know Sql, this leaves me with 2 free slots
>
> Hard to really say, I guess it depends upon the individual.
>
> My list of "languages learned" in one form or another would include:
> ...
>
> But the real reality is that there is the aspect of the abstract
> concept of "how to design an algorithm to instruct a computer to
> perform a task" which is language independent, and then there is the
> "make concrete the abstract algorithm in a particular language".
>
> Once one learns how to do the first ("design algorithm") then
> performing the second part (making it concrete) is generally only a
> matter of learning the rules of the chosen language rather than
> relearning "how to program". So the real part to strive to master is
> the "how to design algorithm" part that is language independent. Much
> of the rest will just flow along from that knowledge.

I'd think most people can keep three to five languages loaded in their
brains and ready to use at any time. With up to a dozen or so in
warm/cold storage.

Once you understand how to do the language independent part and have
picked up four or so languages, then brining a new one up to ready is a
matter of a couple of days or weeks at most. Bring back up one you used
before but "put away" is even shorter.

That all being said, except for the most trivial of programs, it is
always better to consult the man/help/docs than guess.

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

Robert Heller

unread,
Feb 9, 2018, 10:15:30 PM2/9/18
to
Another way to look at it is that there are only a handfull of distint
languages. Once you know a "root" language, learning any "child"
language based on the root language is fairly trivial. It then becomes just a
matter of learning a few details and looking up things like API calls in the
documentation, since all programming languages have only limited set of
syntaxes (based, more or less, on the root language's syntax).

>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

Robert Heller

unread,
Feb 9, 2018, 10:15:30 PM2/9/18
to
I know well:

BASIC
FORTRAN
SNOBOL
Pascal
LISP
C/C++
JAVA
Tcl
csh
bash
JavaScript
SQL
HTML
6502 Assembler
68000 Assembler
VAX-11 Assembler
CDC Cyber Assembler
DCL
Various Microprocess Assembler (8008, 8080, 8051, several others).
PostScript
PHP

Languages I have some knowledge of, but never really learned

COBOL
Smalltalk
APL
PL/1

I currently use Tcl and C/C++ (and some csh and bash) on a dailly basis.
I use JAVA, PHP, JavaScript, HTML, and SQL some.

>
> Thanks
> Ali

Donal K. Fellows

unread,
Feb 10, 2018, 12:14:30 PM2/10/18
to
On 10/02/2018 03:15, Robert Heller wrote:
> C/C++

You really ought to distinguish these two. They've diverged quite a bit
in practice.

Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.

Luis Alejandro Muzzachiodi

unread,
Feb 10, 2018, 6:55:39 PM2/10/18
to
And which would be the reason for that?. If you says for job, it depends of the market's vogue. If you says hobby, well, you can to learn brainfuck and be happy ;-)
Other topic it's how much deep you need to know about a language. To be honest, sometimes a copy-paste is all you need to get the expected result. This remember me the "chinese room argument", but this is other story ...

Jake

unread,
Feb 10, 2018, 7:40:49 PM2/10/18
to
Cool discussion.

Tcl is arguably the first true scripting language, Ousterhout coined the term. This would be in contrast with a "system language," like C. The theory is that you can write high performance implementations in a system language, then orchestrate that code with a scripting language.
In that model, you should learn one of each.

The bad news is that in the real world, you are going to learn many more then 3 languages. Some people are pedantic about the term "programming language," but I am not. You are going to know a shell, like bash or pwsh, to at least a limited degree. You are going to know several markup languages, inevitably more than one scripting language, its pretty unavoidable to know even just a single query language, but if you know one, sql is your best bet.

The good news is you dont need to learn all of it before you can be useful to yourself and others. Just make something.

Donal K. Fellows

unread,
Feb 11, 2018, 6:53:54 AM2/11/18
to
On 11/02/2018 00:40, Jake wrote:
> Some people are pedantic about the term "programming language," but I am not.

Anyone who claims that, say, C is a programming language but Tcl is not
is wrong, no matter how pedantic they claim to be. (The converse is also
true, but I don't think there's many people who would claim that Tcl is
a programming language but C is not.) All a programming language is is a
way of describing to the computer what you want it to do in a way that
can be reused. Even a macro recording system is a (very crude and
inflexible) programming scheme.

The distinction between compilation and interpretation is a distinctly
lesser one. (I've seen interpreters for C and compilers for Tcl, so what
does that mean for the distinction between the two?)

sled...@gmail.com

unread,
Feb 11, 2018, 1:08:20 PM2/11/18
to
Seems to me the key (operative) word here is "master".
I know many who have the ability to program in many languages; but few who have 'mastered' any.

Does having written 360 or System 7 assembler for the space program mean that I have mastered the language - not in my mind.

Does having written prototype models for System R (which went to market as SEQUEL) in APL means that I have mastered the language - not in my mind.

It's like my perspective on flying and skiing: people have suggested that I am an expert\master - every time I do one or the other, I learn something new. Similarly, every time I think I may have 'mastered' tcl\tk, almost each and every response on this forum tells me I haven't.

Ali M

unread,
Feb 11, 2018, 1:15:18 PM2/11/18
to
On Sunday, February 11, 2018 at 6:53:54 AM UTC-5, Donal K. Fellows wrote:
> On 11/02/2018 00:40, Jake wrote:
> > Some people are pedantic about the term "programming language," but I am not.
>
> Anyone who claims that, say, C is a programming language but Tcl is not
> is wrong, no matter how pedantic they claim to be. (The converse is also

I dont think he was referring to Tcl at all in that context
I think he was referring to technologies bash, html, css ...

Powershell is an interesting example, since the makers of Powershell do insist that Powershell is not a programming language, rather they promote it as an automation technology, that has a programming language


> The distinction between compilation and interpretation is a distinctly
> lesser one. (I've seen interpreters for C and compilers for Tcl, so what
> does that mean for the distinction between the two?)
>
> Donal.


As i said in my first post, i am a strong believer in the language dichotomy approach for software development

And i can give few example

Fogbugz - i cant find the source article i read on this, but i think it was on the joelonsotware blog, in summary joel describe his development methodology as have two teams, one team creating fogbugz, using a high level dsl,
and another team creating the dsl and tools around it

Games Development - i saw some videos about games development where the team was again divided mainly in two, one team creating the low level technical tools that provide basic special effect, and another team creating the actual game

My personally experience - my main field is business intelligence, and one of the most productive teams i worked with, was a team that had once developer creating tools for the rest of developers that used those tools to create the data warehouse

I do think that tcl fits well in this model, and i do think that one of the better future direction for tcl is to make it easier to create tcl extension in low level languages such as c, c++, rust, ada, go
And not just focus on adding features to tcl or making tcl a bigger language

I remember there was a post about python on hackernews a while ago, and one of the comments that caught my attention, was someone asking if creating language extension has becomes a lost art

I think that one advantage tcl can have on python and other dynamic high level language, is that i easier to extend tcl using c, rather that extend python
(i dont personally have a first hand experience on this, but this is the impression that i have from reading about both languages)

Christian Gollwitzer

unread,
Feb 11, 2018, 2:08:19 PM2/11/18
to
Am 11.02.18 um 19:15 schrieb Ali M:
> I think that one advantage tcl can have on python and other dynamic high level language, is that i easier to extend tcl using c, rather that extend python
> (i dont personally have a first hand experience on this, but this is the impression that i have from reading about both languages)
>

And it's wrong. The basic facilities are similarly complex to extend
Python or Tcl. Even maybe a little better for the standard stuff, in
Python there exists a predefined function to unpack parameters with a
fixed structure (PyArg_ParseTuple), you can feed it a string like "si"
to mean that first a string and then an integer is expected, whereas in
Tcl you need to call Tcl_Get*FromObj sequentially and manage the error
conditions yourself. Further, Python has "named arguments" built into
the language, i.e. if you want to handle defaults, it is easy to do with
another C function.

Docstrings are another plus at the Python side, it is a built-in help
string which can be set and queried in a predefined way.

It's a bit more annoying to write the Python init functions, however. In
both cases one can use SWIG to do all of this from a C header file and
not bother with the raw Tcl or Python C API at all.

Christian

Uwe Klein

unread,
Feb 12, 2018, 4:06:37 AM2/12/18
to
Am 11.02.2018 um 19:15 schrieb Ali M:
> Fogbugz - i cant find the source article i read on this, but i think
> it was on the joelonsotware blog, in summary joel describe his
> development methodology as have two teams, one team creating fogbugz,
> using a high level dsl, and another team creating the dsl and tools
> around it

Yup.

Abstraction.

And there is a third step:
Define interfaces first.²

Even my hardware projects were mostly capabilities engines
( burried in some programmable logic device )
driven by DSL programming loaded from a FiFo with exactly
one branch command : reset FiFo, start from beginning.
or fall through work on the final commands to finish/postprocess
a long aquisition cycle.

Super flexible to use.
Though I found that quite a lot of people can't wrap
their mind around the idea. They persist on munging things.

²
Define all the interfacing you need to the environment.
IF it is hardware: connect all those to your PLD device
as I/O
( Here you can finalize the hardware and send it off
for production.)

Create the engine inside the PLD.
test it.

create the task specific programming to run your
hardware.

Uwe

Uwe Klein

unread,
Feb 16, 2018, 4:10:01 PM2/16/18
to
Am 11.02.2018 um 19:08 schrieb sled...@gmail.com:
>> Personally, I dont think I can master more than many 3 languages
>> Since I already know Sql, this leaves me with 2 free slots
>>
>> Thanks
>> Ali
>
> Seems to me the key (operative) word here is "master".

The trap afaics often is in using
paradigms and/or techniques
from one language in another one
where they work but do not "fit".


My fist microcontroller asm language was MCS51 ( Intel 8051 )

MCS51 knows about a range of complex jump on condition commands.

the next one was one of Microchip's 12 and 14 bit wide controllers.

Those only know about skip next command on condition.


So with slack face and lidded eyes I wrote myself a bunch
of macros that emulated those nice MCS51 commands.

Then I trapped myself by using those for "skip on condition".
Outch.

A guy I worked was careful to put everything into its own
subroutine.

sub reset_stack
clr stackptr.
return.
:-)

ifind...@gmail.com

unread,
Feb 21, 2018, 8:38:19 AM2/21/18
to
On Friday, February 9, 2018 at 5:54:39 PM UTC-5, Ali M wrote:
Well, having started with entering programs with sense switches, believed that PL/1 was heaven, and passed through many other languages to get to old age, I tend to think that there is no limit, except for time, on the number of languages you can become proficient in.

I find that all procedural languages are basically the same, and its the libraries that provide the wrinkles and headaches.

If you want, you can code up anything in bash, but for a lot of work a language with an object oriented support structure make is considerably easier. My only observation about Tcl is that for truly large projects, you have to think a lot about namespace issues which do not exist in the same sense with something like C/C++.

I also find that a language with refined exception handling and debugging support make life easier. Some aspects of Tcl in that area leave me annoyed, such as the ::errorInfo contents pointing the a line in a proc instead of a line in a source file.

As to extensions for Tcl, its hard for me to imagine that is is complex. With a small set of cpp macros I can whip up an extension in C++ in minutes.

While I find javascript a particularly unforgiving language to work with, it does appear to me that its to main route to a broad range of software development goals, and its tight integration with web interfaces makes me think it should definitely be on one's list these days.

Brad Lanam

unread,
Feb 21, 2018, 11:12:08 AM2/21/18
to
On Wednesday, February 21, 2018 at 5:38:19 AM UTC-8, ifind...@gmail.com wrote:
> If you want, you can code up anything in bash, but for a lot of work a language with an object oriented support structure make is considerably easier. My only observation about Tcl is that for truly large projects, you have to think a lot about namespace issues which do not exist in the same sense with something like C/C++.

Try putting your main modules into their own namespace.
My project isn't that large, but I'm having no namespace issues.
0 new messages