Are you a programmer?

[SL33TBL1ND]

Self-taught NWNscript and FPI. Never had any formal (or indeed informal) teaching on general purpose programming. But I am starting C# next year.

 

[feather240]

A small bit of Python and a minuscule piece of C#.

 

[Lyx]

Java
I hate programming, and the DB stuff was the worst of it.

That's because programming languages have no really adequate datastructures to represent tables... and database-tables in turn are not really efficient for most of the relational stuff for which they are used.

So, you end up spending most of your time with converting container-structures from one conceptual format to another, which are both not optimal for what you tried to represent in the first place. Unfortuatelly, there also isn't really a good alternative to databases yet. I hate situations like that - it seems to pointless and a waste of energy, and yet one has no other choice than to put up with it.

 

[Buzz Killington_v1legacy]

I used to be a software developer until I quit and went to grad school for something only tangentially computer-related. I started out as a kid (longer ago than I care to remember) with TRS-80 BASIC (the really old kind with line numbers).

I've used Java, C, C#, SQL, Pascal (for a couple of small utility things), and a few proprietary languages I'd really rather forget about.

 

[Veylon]

Took college classes in computer programming.

I know C++, though I also took VB (which is useless for most things) and learned a little C# and Java (which are nearly identical). And before all that, Windows on my first computer came with QBasic, which was what got me started on programming in the first place.

 

[shadow skill]

Java
I hate programming, and the DB stuff was the worst of it.

That's because programming languages have no really adequate datastructures to represent tables... and database-tables in turn are not really efficient for most of the relational stuff for which they are used.

So, you end up spending most of your time with converting container-structures from one conceptual format to another, which are both not optimal for what you tried to represent in the first place. Unfortuatelly, there also isn't really a good alternative to databases yet. I hate situations like that - it seems to pointless and a waste of energy, and yet one has no other choice than to put up with it.

Classes are perfectly fine for representing tables, the real problems are that OOP deals with state, relational databases do not have state. It is the same reason why web programming is such a pain. What compounds the problem is that lots of application programmers or system programmers more specifically the guys who write the ORMs we are trying to use nowadays are not primarily DBAs. This means that most ORMs are broken at the conceptual level and do things like not support referential integrity at the database level in some cases. (Active Record at least prior to Rails 3.) What these developers do not get is that having the interface developer create the code that maintains referential integrity defeats the entire purpose of using a relational database in the first place! Without that the database is nothing more than a series of flat files and you mine as well use excel spreadsheets are your database at that point instead of wasting your time on a database of any kind.

Then there is the fact that a developer who uses some of these conceptually broken ORMs will have to end up duplicating code that already exists in the DB in real life. If they used the ORM to create the database then every other interface that uses this broken database has to have code to handle things that could, and perhaps should have been handled by the database, which just increases the number of points of failure. OOP paradigm is the least of our problems when it comes to dealing with databases. Ignorant ORM developers are a much bigger problem. (Ignorant not because their tools sometimes do not support certain features of modern DBMS'; but because they actually believe lacking support for this type of functionality is desirable.)

 

[Tekkawarrior]

Java <- the worst programming language ever invented

erm what? It's like one of the best languages you can ever deal with.

 

[Eclectic Dreck]

Yes.

In order of Proficiency:

Java
ASP
PHP
C/C++

 

[Smooth Operator]

I could say I'm a hobby programmer, it's real easy to create stuff without extra resources except knowledge, and that is found in ample supply.
Things I've worked with sofar:
- Assembler (for microcontroller programming, it's god-awful)
- Pascal
- C, C++, C#
- ASP/.NET (that was a sort of mixed bag of awful)
- SQL,PHP,Javascript
- VB
- Java
- Python
- and most recently Ruby (best of the lot hands down)

 

[Eclectic Dreck]

Java
I hate programming, and the DB stuff was the worst of it.

That's because programming languages have no really adequate datastructures to represent tables... and database-tables in turn are not really efficient for most of the relational stuff for which they are used.

So, you end up spending most of your time with converting container-structures from one conceptual format to another, which are both not optimal for what you tried to represent in the first place. Unfortuatelly, there also isn't really a good alternative to databases yet. I hate situations like that - it seems to pointless and a waste of energy, and yet one has no other choice than to put up with it.

Actually, data structures has been the most interesting part of my CS degree thus far. That said, I'm not at all sure how you could say that "you end up spending most of your time with converting container-structures from one conceptual format to another, which are both not optimal for what you tried to represent in the first place". I mean, what is a database but a data structure that can be sorted and searched? I'll grant you that most examples are just conceptual solutions to a problem but I can't see why you'd say that they are non-optimal. Are you suggesting perhaps that a tree (for example) should be a primitive data type?

 

[DazZ.]

Started off teaching myself C++ and Java, but then ended up going towards web development. So PHP,SQL,ASP,Javascript, and AS2&3 if that counts. Had a college course with VB, which when I already knew C++ I thought was pointless.

Web Development is what I want to do, and seeing as I'm on a payroll for it I guess I could say it's what I do already. Used to want to make games, but I'd likely prefer doing that as a hobby so I get to make what I want.

 

[Mechsoap]

Im learning some basic for a little project i will soon start with some friends.

 

[Lyx]

Classes are perfectly fine for representing tables, the real problems are that OOP deals with state, relational databases do not have state. It is the same reason why web programming is such a pain. What compounds the problem is that lots of application programmers or system programmers more specifically the guys who write the ORMs we are trying to use nowadays are not primarily DBAs. This means that most ORMs are broken at the conceptual level and do things like not support referential integrity at the database level in some cases. (Active Record at least prior to Rails 3.) What these developers do not get is that having the interface developer create the code that maintains referential integrity defeats the entire purpose of using a relational database in the first place! Without that the database is nothing more than a series of flat files and you mine as well use excel spreadsheets are your database at that point instead of wasting your time on a database of any kind.

Then there is the fact that a developer who uses some of these conceptually broken ORMs will have to end up duplicating code that already exists in the DB in real life. If they used the ORM to create the database then every other interface that uses this broken database has to have code to handle things that could, and perhaps should have been handled by the database, which just increases the number of points of failure. OOP paradigm is the least of our problems when it comes to dealing with databases. Ignorant ORM developers are a much bigger problem. (Ignorant not because their tools sometimes do not support certain features of modern DBMS'; but because they actually believe lacking support for this type of functionality is desirable.)

IMO, while what you describe are all important issues, they are just symptoms of something bigger: That there is any seperation of data and code, at all. It of course fits the von Neumann design, but i guess we both are aware about the issues with that shism, right? It's like we constantly seperate data and instruction, just so that later we can then again patch both together (which is the whole reason for approaches like OOP, actors, prototypes, and so on - what we're trying to represent, are entities that include behaviours and information - not a stack of data and a stack of instructions, isolated from each other.

By storing data in a database, and then using a program to work with it, we just again create such a shism, and then try to patch it together again on a higher abstraction level. Of course, there is a reason why this is done - it is features that programming languages lack:

- relational addressing and lookup (all current programming languages do not really have an idea of complex hierachies. In the end, we still just have a bunch of memory postit notes, linked together via pointers - without any sense of "space/location" (addressing!). Compare this with a filesystem, where there are super and subdirectories - sure, you can emulate it in programming languages, but it's not the same)

- Persistence. The way how nowadays memoryallocaters work, mean that running an application is "construct and discard after use". It is not meant to allow dumping and then later reloading from disk.

- Concurrency. Though, actors are attempting to lessen this problem for programming languages.

So, what i'm trying to get at is: We use databases, because programming languages lack certain features, but then constantly have to deal with translating and interfacing another data/instruction chasm.

 

[DaJoW]

Doing a Bachelors in Computer Science at Uppsala University, Sweden. So far, we've done SML, C, Java and an assembly.

 

[Slippers]

I'm studying EE. I had to learn basic programming in C, C++, C sharp, Python and PHP as part of the course.

 

[CIB]

Am I programmer? Hell, yes!

Which languages do I know? That's an odd question, it's a bit like asking what vehicles you can drive. Sure, there are different cars, but the difference is mostly simple stuff like the size or the side the steering wheel is on.

I usually go by python, since I know all the details and quirks of that language, but I can handle most OOP-style languages out there sufficiently, provided a good reference/tutorial. Io is still a mystery for me, though.

What I actually define my skills by, is the concepts I understand and have worked with. This includes some low level stuff, like understanding how CPUs, memory, etc. work, experience with text processing, language design, SQLesque databases, socket networking, 2d rendering, openGL and game design.

 

[TheJoojo]

Doing a Bachelors in Computer Science at Uppsala University, Sweden. So far, we've done SML, C, Java and an assembly.

Seems like you are one year ahead of me.

 

[shadow skill]

Classes are perfectly fine for representing tables, the real problems are that OOP deals with state, relational databases do not have state. It is the same reason why web programming is such a pain. What compounds the problem is that lots of application programmers or system programmers more specifically the guys who write the ORMs we are trying to use nowadays are not primarily DBAs. This means that most ORMs are broken at the conceptual level and do things like not support referential integrity at the database level in some cases. (Active Record at least prior to Rails 3.) What these developers do not get is that having the interface developer create the code that maintains referential integrity defeats the entire purpose of using a relational database in the first place! Without that the database is nothing more than a series of flat files and you mine as well use excel spreadsheets are your database at that point instead of wasting your time on a database of any kind.

Then there is the fact that a developer who uses some of these conceptually broken ORMs will have to end up duplicating code that already exists in the DB in real life. If they used the ORM to create the database then every other interface that uses this broken database has to have code to handle things that could, and perhaps should have been handled by the database, which just increases the number of points of failure. OOP paradigm is the least of our problems when it comes to dealing with databases. Ignorant ORM developers are a much bigger problem. (Ignorant not because their tools sometimes do not support certain features of modern DBMS'; but because they actually believe lacking support for this type of functionality is desirable.)

IMO, while what you describe are all important issues, they are just symptoms of something bigger: That there is any seperation of data and code, at all. It of course fits the von Neumann design, but i guess we both are aware about the issues with that shism, right? It's like we constantly seperate data and instruction, just so that later we can then again patch both together (which is the whole reason for approaches like OOP, actors, prototypes, and so on - what we're trying to represent, are entities that include behaviours and information - not a stack of data and a stack of instructions, isolated from each other.

By storing data in a database, and then using a program to work with it, we just again create such a shism, and then try to patch it together again on a higher abstraction level. Of course, there is a reason why this is done - it is features that programming languages lack:

- relational addressing and lookup (all current programming languages do not really have an idea of complex hierachies. In the end, we still just have a bunch of memory postit notes, linked together via pointers - without any sense of "space/location" (addressing!). Compare this with a filesystem, where there are super and subdirectories - sure, you can emulate it in programming languages, but it's not the same)

- Persistence. The way how nowadays memoryallocaters work, mean that running an application is "construct and discard after use". It is not meant to allow dumping and then later reloading from disk.

- Concurrency. Though, actors are attempting to lessen this problem for programming languages.

So, what i'm trying to get at is: We use databases, because programming languages lack certain features, but then constantly have to deal with translating and interfacing another data/instruction chasm.

I get you now. I would argue however that rather than using databases because other languages lack certain features, we use the SQL domain specific language variants because we do not want to have to handle the same common tasks over and over again.

At the end of the day almost every program we write is really nothing more than a language. I have written a sort of pseudo ORM just to map sql parameters to objects so I would not have to write the connection/query code every time I needed to interact with the database. While it made utilizing the database easier for day to day operations, the code was a damned nightmare with recursive functions for introspection and attribute look up (I wrote a class just to allow me to decorate table model class properties with attributes that corresponded to the sql stored procedure parameter names I was using.), and because this is a .net 2 application I had to do recursion without closures! (Lambdas) I have pretty much given up on that and decided to start prototyping an mvc version of the interface using .net 4 and Entity Framework because I realized that I was creating a DSL that was tied very tightly to the current structure of the database. If I was going to do that I should just use a real ORM that is not so tightly coupled to my own application requirements.

It is the same principle with SQL in general, it makes more sense to create a DSL for dealing with data that we do not need to rewrite every single time to at least find information. All languages include information about the data they have to manipulate. There is no way to completely separate data from instructions. You need data in order to describe instructions, and instructions to describe data. For one reason or another people attracted to our field do not seem to understand that this issue is ontological. They become used to thinking of program components separately from one another. Perhaps because their background tends to be highly mathematical, and some mathematicians have this strange belief that mathematics is not a language that describes reality and is therefore not composed of various axioms.

In my own case I am terrible at math but love language and learning about how languages are put together and the psychology that the semantics of natural language communicate. Whereas an abstract equation can be readily broken into separate parts because of the axioms that define mathematics a language (or application) that needs to deal with real objects does not have that luxury in all cases.

What that means for us poor people who have to deal with databases is that we will never get away from either using a language designed specifically to describe and manipulate the data stored inside the database or writing our own language with a non specific language over and over and over.

The ORM is of course the best solution to this ontological problem, but too many of the people who make these things do not recognize the issue as ontological and cling to this idea that the world that exists in their heads is the way that the world can and more importantly should be. We would not have to cry tears of blood if more ORM developers were open to the idea of actually supporting the features RDBMS' already have. It is one thing not to support something because it is hard to do, it is another thing to be opposed to supporting something because of a theological argument based on demonstrably false axioms.

This nonsense further attracts people that know even less than these system programmers(They do know more than I do about OOP.) who also dislike using SQL correctly; (In part because they do not get it.) which makes figuring out how to use certain functionality of ORMs that do have decent support for things like stored procedures such as Entity Framework in the case of .net a pain in the ass since so many of the hits for using the tool link you to Linq queries.

TL;DR:

I get what you are saying and agree, but I think the problem is not with lack of features but ontological. ORMs fix this problem as best as we can hope, however too many people have a religious hatred of the modern functionality of RDMS' so we don't use these tools correctly and/or they just plain lack support for certain things because the tool designer is ignorant.

 

[JezebelinHell]

RC Controller Programming (robotics)
KAREL (robotics)
C++
Silktest
Some sort of Basic a long time ago
Self taught HTML & CSS but taking classes now in Web Development.
At some point I am going to have to pick Visual Basic or Java as a focus. Looks like that may be a debate.